Dzisiaj o popularnym ale chyba najbardziej nierozumianym buzzwordzie „DevOps„. Wiele firm rekrutując na to stanowisko myśli o typowych „Operations” a już zupełnym nieporozumieniem są (oczywiście wg mnie) osobne zespoły składające się jedynie z „DevOpsów” – bo zwykle to oznacza tyle: „od dzisiaj będziesz adminem, tu jest twój telefon„.
Kiedyś to było…
Dawno dawno temu, aplikacje i systemy były tworzone przez zespół programistów, testowane przez zespół testerów, wdrażane przez zespół wdrożeniowców i utrzymywane przez zespół supportu. Taki podział, jak można się domyślać rodzi „my” i „oni” w przerzucaniu się pracą czy odpowiedzialnością za jakiś fragment procesu (instalacji, testowania, you name it…). Problemy i nieporozumienia często powodowane są niezrozumieniem intencji.
W końcu ktoś odkrył, że podziały, tworzą kolejne podziały co w ostateczności wpływa na czas dostarczenia oprogramowania czyli koniec końców rozbiło się o pieniądze.
Kultura DevOps
DevOps według mnie to właśnie kultura pracy, w której ludzie z Operations są członkami zespołu developerskiego. Aplikacje i systemy, które tworzymy często składają się przynajmniej z kilku procesów, nie mówiąc już o systemach typu microservice, które mogą ich mieć nawet kilkaset. Im większa entropia systemu, tym bardziej kluczowa jest współpraca pomiędzy ludźmi o różnych funkcjach i umiejętnościach. Bliską współpracę można sprowadzić do pracy w tym samym zespole deweloperskim (dev + ops). Od jakiegoś czasu pracuję w modelu dev + ops w zespole (można powiedzieć że po obu stronach) i mam kilka spostrzeżeń odnośnie organizacji pracy:
- Ops bardziej myśli o tym jak to będzie wyglądało na produkcji
- Dev myśli o tym, żeby zrobić to prosto i dobrze
- Pomysły: „nie automatyzujmy tego tylko opiszmy kroki w dokumentacji” są usuwane jak tylko się pojawią
- Security mocno na tym zyskuje – Ops’y zwykle dużo o tym wiedzą
- Wiele uproszczeń zostało wprowadzonych po sugestiach od Opsów
- Wykorzystano więcej gotowych narzędzi zamiast pisać tony kodu
Po jakimś czasie, ciężko mi sobie wyobrazić jak było można wydawać soft do klientów, którzy instalowali go w swojej serwerowni i musieli czytać wielostronicowe dokumentacje instalacji i utrzymania, które były napisane głównie przez programistów.
Rozwiązania oferowane jako SaaS czy te sprzedawane „on premise” to już nie tylko kod napisany przez zespół, a również serwer www, firewall, load balancer, DNS i wiele innych. Kto jak nie Ops wie jak to wszystko skonfigurować i co najlepsze – zautomatyzować. Żeby nie było, że tylko programiści jednostronnie zyskują na obecności w zespole kogoś bardziej przypominającego admina – Operations również zyskali kilka nowych umiejętności – jak np. znajomość procesu testowego, testy infrastruktury (np. serverspec), lepsze spojrzenie na architekturę systemu i zrozumienie wielu decyzji projektowych.
Podsumowanie
DevOps rozwiązuje wiele problemów. Część spraw z dziedziny „operations” jest nawet rozwiązywanych zanim kod trafi na produkcje. Można więc zadawać sobie pytanie – czy po prostu nie można było się dogadać?
No matter how it looks at first, it’s always a people problem.
Gerald M. Weinberg, Secrets of Consulting
A jaki jest Twoje zdanie na temat kultury DevOps? Jakie są Twoje przemyślenia?