Wanna be a DevOps

Czy admin może zostać DevOps-em?

Krzysztof Podobiński
Delivery Architect w Cloud & Data Services, w Capgemini.

DevOps, SecDevOps to ostatnio bardzo modne słowa, które coraz częściej pojawiają się w nazwach stanowisk, opisie wymagań czy różnorakich publikacjach dotyczących IT. Po lekturze części z nich można wręcz odnieść wrażenie, że DevOps jest odpowiedzią na wszystkie problemy z zakresu IT i właściwie można by wyeliminować inne stanowiska czy metodologie. Czy jest to prawdą? Może nie do końca, jednak nawiązując do niesłabnącej popularności tej metody zacząłem się zastanawiać nad rolą „zwykłego” administratora. Czy ktoś, kto do tej pory zajmował się „klasyczną” administracją infrastruktury IT może zostać inżynierem DevOps? Czy też może musi pogodzić się z faktem, że nie ma dla niego miejsca w nowoczesnym świecie IT i będzie skazany na zajmowanie się innym, nieco bardziej archaicznym środowiskiem?

Czym jest DevOps i jakie są plusy tej metodologii

DevOps to połączenie Development and Operations – dość łatwo dopasować to podejście do programistów/developerów, którzy w tym modelu odpowiedzialni są nie tyko za pisanie aplikacji, ale także za późniejsze jej utrzymanie. A co z administratorami infrastruktury? Co z sieciowcami, specjalistami od Linux-a, Windows-a i innych systemów? Czy oni mogą odnalezć się w takim podejściu? Według mnie tak. I to nawet nie mogą, a muszą. Pomimo bardzo dynamicznego rozwoju rozwiązań opatrych o Cloud i podejścia, Infrastruktura jako Kod (Infrastructure as Code) wiedza i doświadcznie zwiazane z zarządzaniem infrastrukturą IT są cały czas bardzo potrzebne.

Moim zdaniem DevOps skupia się na połączeniu funkcji, jakie pełnią programiści i administratorzy. Można powiedzieć, że jest odpowiedzią na zależności, które występują pomiędzy tymi dwoma rolami. Efektem zastosowania tej metodologii jest znaczne skrócenie czasu wprowadzania zmian w oprogramowaniu czy testowaniu tych zmian. Dzięki temu można szybciej wytwarzać produkty i usprawnić ich dotarcie na rynek.

DevOps jako metodologia – czyli wyzwania jakie stoją przed „typowym adminem”

Aby odnaleźć się w nowym modelu i być pełnoprawnym DevOps-em trzeba zmienić podejście i sposób myślenia o swojej roli. To tylko tyle albo aż tyle. W mojej opinii DevOps to nie zestaw narzędzi czy rozwiązań; jak na przykład Jenkis, Ansible, Chef, Kubertnetes, Slack, Azure DevOps; ale przede wszystkim metodologia, filozofia tego jak się pracuje, współpracuje i komunikuje.

Po pierwsze współpraca

W „klasycznym” IT każdy administrator „uprawia swój własny ogródek”, w ramach swojej technologii i właściwie tylko tym się zajmuje. Bardzo dobrze widać to w dużych korporacjach, gdzie oddzielone od siebie systemami ticketowymi zespoły odpowiedzialne za wparcie poszczególnych technologii, do perfekcji opanowały SOA (Standardowa Odpowiedź Administrator – U mnie działa). Natomiast administrator, który chce zostać DevOpsem musi zmienić podejście ze wspomnianego wcześniej „to nie mój problem” na „to jest nasz problem”. Na co dzień, w pracy dość często dochodzą do mnie pytania od ludzi, którzy zaczynają swoją przygodę z DevOps przechodząc z klasycznych zespołów IT: – Jaki jest nasz zakres obowiązków? Za co odpowiadamy? Odpowiedź na to pytanie jest jedna: – Za to, by końcowy produkt działał poprawnie.

To oczywiście nie jest równoznaczne z tym, że sieciowiec będzie poprawiał błędny kod w aplikacji, robił commity w GitHub-ie i wdrażał całość na produkcję z wykorzystaniem CI/CD (choć osoba z tak rozległą wiedzą – Unicorn – byłaby pewnie bardzo pożądana;)). Oznacza to natomiast tyle, że jeżeli w ramach projektu wystąpi problem, to jest to problem całego zespołu i trzeba go rozwiązać. Trzeba więc wyjść ze „swojego ogródka”, „pobrudzić się” trochę inną technologią, spróbować ją zrozumieć i zacząć komunikować się z innymi. Trzeba też przyzwyczaić się do tego, że nie będziemy wiedzieć wszystkiego, że będziemy się mylić i popełniać błędy. I to ciągle jest w porządku. Sprawdzanie, testowanie, poprawianie jest wpisane w podejście DevOps (Continuous Integration, Continuous Delivery, Continuous Testing).

Po drugie komunikacja

Drugi problem to komunikacja. Adminstratorzy w zespołach DevOps-owych zwykle zajmują się rozwojem i utrzymaniem platform, na których działają aplikacje końcowe. W świecie nowoczesnych technologii aplikacje te są coraz bardziej rozbudowane, coraz bardziej skomplikowane, a co za tym idzie coraz bardziej wymagające jeśli chodzi o środowisko, na którym pracują. To powoduje więc konieczność stworzenia dedykowanej, „skrojonej na miarę” platformy. Platformy, która będzie się zmieniać i ewoluować wraz z aplikacją (DevOps wewnątrz Ops). Nie da się tego osiągnąć bez ścisłej współpracy z programistami, bez zrozumienia ich potrzeb i przedstawienia naszych. Komunikacja to podstawa, a system ticketowy to tylko narzędzie ułatwiające zarządzanie zgłoszeniami i nie zastąpi klasycznej komunikacji polegającej rozmowie i na wspólnym ustaleniu sedna problemu, a także sposobu rozwiązania, co finalnie skraca cały czas.

Podsumowując: chcąc pełnić funkcję administratora DevOps musimy zmienić nasze podejście do projektów i zacząć przede wszystkim współpracować oraz komunikować się z innymi. Oczywiście, aby zostać „pełnoprawnym DevOps-em” konieczne będzie opanowanie narzędzi takich jak na przykład CI/CD, Ansible, Puppet czy Jenkins. Choć z mojego punktu widzenia to nie powinno być problemem, w końcu jest to kolejny element którego można się nauczyć – ciągły rozwój jest przecież sednem pracy w IT.

Na koniec warto również dodać, że metodologia DevOps nie jest cudownym lekarstwem, które sprawi, że po wdrożeniu wspomnianych praktyk CI/CD, czy narzędzi takich jak Jenkins czy GiT, nagle wszystkie nasze problemy związane z siecią, bazami danych czy systemami operacyjnymi znikną. Technologie się zmieniają, ale infrastruktura ciągle jest gdzieś tam pod spodem (i wygląda na to, że szybko nie zniknie – usługi typu serverless, oferowane w chmurach publicznych nie są jeszcze wstanie dostarczyć tych samych funkcji). W związku z tym cały czas będzie zapotrzebowanie na umiejętności i ludzi z tym związanych.