W 2009 roku dwóch inżynierów z Flickr stanęło na scenie konferencji Velocity i powiedziało coś, co brzmiało jak science fiction: wdrażają kod po 10 razy dziennie. John Allspaw i Paul Hammond nie mówili o magicznym skrypcie. Mówili o tym, że developerzy i administratorzy przestali się kłócić i zaczęli ze sobą rozmawiać. Dla większości obecnych w sali brzmiało to mniej więcej jak opowieść o jednorożcach.
DevOps to nie jest stanowisko. To nie jest narzędzie, które kupisz od vendora na trzyletnią licencję. To w pewnym sensie odpowiedź na pytanie: co się dzieje, kiedy firma przestaje udawać, że development i operations to dwa wrogie plemiona?
Kiedy mury przestają mieć sens
Przez dekady utrzymywaliśmy podział: programiści piszą kod, admini dbają o to, żeby serwery działały. Brzmi rozsądnie do momentu, w którym okazuje się, że nikt nie jest odpowiedzialny za to, co dzieje się między kodem a produkcją. Gene Kim opisał to w The Phoenix Project (2013) jako permanentny stan wojny: Dev chce zmian, Ops chce stabilności. Każdy ma rację. Nikt nie wygrywa.
Prawo Conwaya z 1968 roku mówi, że architektura systemu odzwierciedla strukturę komunikacji w organizacji. Jeśli Dev i Ops rozmawiają przez tickety w Jirze raz na tydzień, system będzie wyglądał dokładnie tak, jakby go projektowały dwa wrogie departamenty. Bo tak właśnie było.
Co się stało w Flickr w 2009 roku
Allspaw i Hammond zrobili coś banalnego i rewolucyjnego jednocześnie: posadzili ludzi w jednym pokoju. Nie stworzyli nowego działu. Nie wdrożyli frameworka. Po prostu przestali traktować deployment jak wydarzenie wymagające trzech tygodni planowania i approval od pięciu komitetów.
Dziesięć wdrożeń dziennie nie było celem. Było efektem ubocznym tego, że zespół przestał się bać produkcji. Automated testy, monitoring, rollback w 30 sekund. Żadna magia, same nudne procesy powtarzane setki razy, aż przestały być stresujące.
DORA i rzeczy, które da się zmierzyć
DevOps Research & Assessment, dziś część Google Cloud, od lat bada zespoły, które twierdzą, że robią DevOps. Ich State of DevOps Report to jedno z niewielu badań, które nie jest próbą sprzedania Ci kolejnego narzędzia. Mierzą cztery rzeczy: jak często wdrażasz, jak długo trwa wdrożenie, jaki procent deploymentów pada, jak szybko naprawiasz błędy.
Najlepsze zespoły wdrażają kod setki razy dziennie. Najgorsze raz na kwartał. Różnica nie leży w budżecie ani w stacku technologicznym. Leży w tym, czy ludzie ufają sobie na tyle, żeby puścić kod na produkcję bez miesięcznego change freeze.
Czego DevOps nie rozwiązuje
DevOps nie naprawi złego kodu. Nie zastąpi testów, których nikt nie pisze. Nie sprawi, że menadżer przestanie wymagać commitmentu na datę, którą wymyślił w windzie. To nie jest pigułka szczęścia dla organizacji, która przez 15 lat budowała silosy i teraz chce je zburzyć jednym sprintem.
Widziałem firmy, które zatrudniły \“DevOps Engineera\” i uznały, że problem rozwiązany. Sześć miesięcy później ten człowiek siedział sam w pokoju, pisał Ansible playbooki, a Dev dalejrzucał paczki przez mur z dopiskiem \“u mnie działa\”. DevOps jako tytuł na wizytówce to w pewnym sensie przyznanie, że niczego nie zrozumieliśmy.
Co zostaje po szumie
Kubernetes, Terraform, GitLab CI – to wszystko narzędzia. Potrzebne, użyteczne, czasem wręcz niezbędne. Ale DevOps to nie pipelines i nie dashboardy w Grafanie. To pytanie: czy Twój zespół jest w stanie naprawić produkcję o trzeciej w nocy, nie szukając winnego, tylko przyczyny?
Najlepsze zespoły, które spotkałem, robiły retrospektywy po każdym poważnym incydencie. Nie po to, żeby kogoś ukarać. Po to, żeby następnym razem system padł trochę później albo wcale. To nie jest filozofia, to higiena pracy.
DevOps przetrwa, bo rozwiązuje prawdziwy problem: firmy, które dostarczają oprogramowanie szybciej, wygrywają z tymi, które tego nie robią. Reszta to szczegóły implementacyjne.
Źródła
- Kim G., Behr K., Spafford G., “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win”, IT Revolution Press, 2013.
- Conway M.E., “How Do Committees Invent?”, Datamation, 1968.
- DevOps Research & Assessment (DORA), “State of DevOps Report”, Google Cloud, program badawczy prowadzony od 2014.
- Allspaw J., Hammond P., “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”, Velocity Conference, 2009.
Zdjęcie: MART PRODUCTION / Pexels
