Zarządzanie · 4 min czytania
Ten o płocie między Dev i Ops
DevOps jako współodpowiedzialność Dev i Ops za kod od napisania do produkcji. Jak automatyczne pipeline'y i infrastruktura jako kod skracają drogę do klienta.
Przez lata development i operations działały osobno. Dev pisał kod i „przerzucał przez płot” do Ops.
Ops wdrażał, gasił pożary i obwiniał Dev za błędy. Dev obwiniał Ops za wolne wdrożenia.
Skąd się wziął płot między Dev i Ops?
Z różnych celów. Development był rozliczany ze zmian: nowych funkcji, terminów, zamkniętych zadań. Operations był rozliczany ze stabilności: dostępności systemu i braku awarii. Każda zmiana to ryzyko dla stabilności, więc Ops miał powód, żeby zmiany spowalniać. Dev miał powód, żeby je przepychać.
Obie strony robiły to, za co je rozliczano. Konflikt był wbudowany w strukturę. O tym, ile kosztuje czekanie między zespołami, pisałem przy okazji opóźnień w strumieniu wartości.
Czym jest DevOps?
Modelem współodpowiedzialności za to, co dzieje się z kodem od momentu napisania do momentu działania na produkcji. DevOps nie opisuje stanowiska ani zespołu. Opisuje sposób pracy, w którym ci sami ludzie odpowiadają za zmianę i za jej skutki.
Gene Kim, Jez Humble, Patrick Debois i John Willis opisują w „The DevOps Handbook” trzy zasady: przepływ (praca płynie szybko od developera do klienta), informacja zwrotna (problemy wracają szybko do tych, którzy mogą je naprawić) i ciągłe uczenie się.
Jakie praktyki za tym stoją?
Dwie są szczególnie ważne.
Automatyczne pipeline’y. Kod przechodzi przez testy, budowanie i wdrożenie bez ręcznych kroków. Mniej błędów ludzkich i krótszy czas od pomysłu do działającej funkcji. Jez Humble i David Farley nazwali to ciągłym dostarczaniem (continuous delivery): każda zmiana, która przejdzie przez pipeline, jest gotowa do wdrożenia.
Infrastruktura jako kod. Środowisko jest wersjonowane jak kod. Możesz je odtworzyć, porównać, cofnąć. Koniec z „u mnie działa”, bo środowisko developera i produkcja powstają z tego samego opisu.
Automatyzacja zmienia też rachunek ryzyka. Kiedy wdrożenie jest małe i powtarzalne, a cofnięcie zajmuje minuty, częste zmiany przestają zagrażać stabilności. Badania DORA opisane w „Accelerate” pokazują, że zespoły, które wdrażają często, mają też krótszy czas przywracania usługi po awarii.
Co zmienia się w kulturze?
Zespół przestaje szukać winnego i zaczyna szukać rozwiązania. John Allspaw z Etsy opisał praktykę analizy awarii bez szukania winnych (blameless postmortem): po incydencie pytamy, jak system pozwolił na błąd. Ludzie, którzy nie boją się kary, mówią więcej o tym, co się stało, więc organizacja uczy się szybciej.
Pisałem już o tym, że system, którego nikt nie pielęgnuje, psuje się sam. DevOps daje zespołowi narzędzia, żeby tę pielęgnację robić codziennie i bezpiecznie.
Co z tego dostajesz?
Szybsze dostarczanie poprawek i system, który się nie sypie po każdym wdrożeniu. I zespół, który zamiast winnego szuka rozwiązania.
DevOps pokazuje, że niezawodność jest wynikiem procesu. Przypadek ma w niej niewielki udział.
Narzędzie jest narzędziem. Pytanie, co z niego wyciągniesz.
Bibliografia
- Kim, G., Humble, J., Debois, P., Willis, J. (2016). The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. IT Revolution Press.
- Humble, J., Farley, D. (2010). Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley.
- Forsgren, N., Humble, J., Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
- Allspaw, J. (2012). Blameless PostMortems and a Just Culture. Code as Craft (blog Etsy).
💬 Dołącz do dyskusji na LinkedIn → Komentuj i podziel się swoim podejściem
Tomasz Żelezny
Scrum Master · Agile Coach
Pomagam zespołom robić mniej rzeczy naraz i kończyć więcej. Piszę o przepływie pracy, decyzjach i o tym, gdzie znika wysiłek zespołów.
Twój zespół może więcej niż dowozi.
Zobacz, jak pomagam