Raz, dwa, trzy, DevOps patrzy

Podobnie jak konteneryzacja i chmura, słowo lub dla ścisłości zlepek słów, DevOps nie daje o sobie zapomnieć. Hype się kręci na całego, ludzie zmieniają stanowiska, social media pękają w szwach, a rekruterzy dostają kociokwiku, szukając przedstawicieli rzekomo nowego, lepszego IT.

Jakieś 10 lat temu Google popatrzyło na swoją infrastrukturę, jak również i ludzi, którzy na niej pracują, krytycznym okiem. Obserwacja ta sprawiła, że zdecydowali oni zmienić podejście do zarządzania produkcją. Okazało się bowiem, że kiedy zespoły R&D (Developers) zajęte są tworzeniem nowych funkcji, wydawaniem nowych wersji oprogramowania, zespoły utrzymania (Operations) robią wszystko, co w ich mocy, aby utrzymać stabilność i ciągłość działania środowiska – zespoły w gruncie rzeczy działały w dwóch, zupełnie różnych kierunkach. Jak nad tym się chwilę zastanowić, to nie ma w gruncie rzeczy nic w tym nowego, ani zaskakującego. Dwa zupełnie różne cele do zrealizowania i do tego kompletnie różne umiejętności, doświadczenia i miary sukcesu sprawiały, że zespoły raczej nie pałały do siebie zbytnią miłością. Nie było w tym niczyjej winy, ani błędu po żadnej stronie, nikt nie był gorszy, czy też lepszy. Sytuacja, która miała miejsce wynikła z określenia celów i rzetelnej ich realizacji przez każdy z zespołów.

Widząc to Ben Treynor, jeden z liderów zespołów utrzymaniowych w Google wymyślił prawdziwego Frankensteina IT – zamiast mieć zespół Ops złożony z samych adminów postanowił do nich dołączyć Developerów. Tak powstał Site Reliability Engineering i związana z tym pozycja SRE, która łączy w sobie opisane wyżej dwa światy. Według Google SRE są odpowiedzialni za stabilność i utrzymanie środowiska produkcyjnego, jak również w tym samym czasie za wprowadzanie nowych funkcji i innowacji na warstwie operacyjnej. Generalnie przyświeca im założenie, że należy wszystko automatyzować i zamiast bezmyślnego klikania w interfejsy w celu powtarzania jakichś funkcji należy do tego używać kodu. Dzięki tej zmianie stosunkowo łatwo integrują się oni z działami programistycznymi, co sprawia, że jedni mogą czerpać wiedzę od drugich – upodabnia się sposób myślenia, narzędzia i podejście, pojawiają się podobne problemy i zagadnienia, a to zdecydowanie zbliża i łączy zespoły, a nie je dzieli.

SRE… A to nie DevOps? Nie do końca. Słowo DevOps w otaczającej nas rzeczywistości najczęściej używane jest przez rozbestwiony HR i przez pewne niezrozumienie lub może zbyt szybkie postawienie znaku równości, nabrało nieodpowiedniego znaczenia. Ogólnie można powiedzieć, że DevOps, będący nieco młodszym zagadnieniem, został stworzony, aby pomóc organizacjom (między innymi IT) zaimplementować podejście zwinne (agile) oraz wytworzyć zdrowe relacje pomiędzy zespołami Ops i Dev. DevOps to zmiana organizacyjna, która ma na celu zakopanie topora wojennego i sprawienie, że Admini nie będą wyżynać wiosek pełnych Developerów, a magowie z krain R&D nie będą posyłać burzy meteorów do serwerowni. Podejście DevOps ma pokazać, że wspólnymi siłami wszyscy będą mieli lepszą atmosferę pracy i zrozumieją wysyłki drugiej strony, często poprzez udział w pewnej części jej obowiązków.

SRE i DevOps z założenia są podobnymi ideami adresującymi podobne potrzeby organizacji. W skrócie można je jednak rozróżnić w następujący sposób – gdy zespoły pracujące w idei DevOps podnoszą problemy, rozumieją je, a następnie aby je rozwiązać przesyłają do działu Dev, natomiast SRE znajdują problemy i rozwiązują je wewnątrz zespołu, przekazują do działu Dev jedynie w przypadku, gdy dotyczy to twardego kodu aplikacji. Tak więc DevOps zawsze będzie bardziej konserwatywne w działaniach, podczas gdy SRE bardziej agresywne. Drugą główną różnicą jest to, że DevOps jest ruchem inicjującym zmianę, a SRE faktyczną zmianą i w sumie nazwą roli.

Dobrze, to na koniec czy można by powiedzieć, że jest się Inżynierem lub Architektem DevOps? A czy można powiedzieć, że jest się Inżynierem Agile, lub Architektem Chmury? To tak, jakby będąc mechanikiem zajmującym się silnikami diesla powiedzieć, że jest się Architektem Nafty. Zasadniczo jakieś ziarno prawdy w tym jest, ale może bardziej precyzyjnie byłoby określić się jako SysAdmin pracujący w metodologii DevOps, lub SRE.

Artykuł został opublikowany na łamach IT Professional.