Czym jest retrospektywa DevOps?
DevOps (połączenie słów „development” i „operations”) to zestaw praktyk i narzędzi, które pomagają organizacji dostarczać aplikacje i usługi szybciej niż w tradycyjnych procesach wytwarzania oprogramowania. Retrospektywa DevOps gromadzi programistów i osoby z zespołu operacyjnego na jednym spotkaniu, aby wspólnie przyjrzeć się ostatnim wydaniom, incydentom i temu, jak ze sobą współpracowali. Tablica ma cztery kolumny. Udane wdrożenia dotyczą tego, co poszło dobrze w ostatnich wydaniach. Obszary do poprawy zbierają problemy, od luk w testach automatycznych po brakujące runbooki. Współpraca i kultura to przyjrzenie się temu, jak dev i ops pracują razem, w tym dyżurom, przekazywaniu pracy i postmortemom. Narzędzia i procesy to miejsce na zmiany w pipeline, infrastrukturze i monitoringu. Przeprowadźcie ją po dużym wydaniu lub awarii albo regularnie, co miesiąc lub co kwartał. Dbajcie o to, by nikogo nie obwiniać, żeby ludzie mówili o tym, co naprawdę się wydarzyło, i wyjdźcie ze spotkania z kilkoma zmianami, z których każda ma właściciela. Kolejne wdrożenia pokażą, czy zadziałały.
Format retrospektywy DevOps
Udane wdrożenia
Co poszło dobrze podczas ostatnich wdrożeń?
Zacznij od tego, co zadziałało w ostatnich wdrożeniach, i zapytaj, co sprawiło, że się udało, żeby można to było powtórzyć.
Obszary do poprawy
Z jakimi wyzwaniami się mierzyliśmy i co możemy poprawić?
Nie szukaj winnych. Pytaj, co się wydarzyło i co utrudniało pracę, i szukaj luki w procesie lub narzędziach, która stoi za każdym problemem.
Współpraca i kultura
Jak usprawnić pracę zespołową i budować kulturę DevOps?
Porozmawiajcie o tym, gdzie dev i ops wciąż przerzucają pracę przez mur i co sprawiłoby, że utrzymanie usługi stanie się wspólną odpowiedzialnością.
Narzędzia i procesy
Jak możemy zoptymalizować nasze narzędzia, technologie i procesy?
Szukajcie ręcznych kroków, które warto zautomatyzować, i procesów z nadmierną liczbą przekazań. Wybierzcie zmianę, która zaoszczędzi najwięcej czasu albo usunie największe ryzyko.
Kiedy należy skorzystać z niniejszego przeglądu retrospektywnego
- Po dużym wydaniu lub wdrożeniu, aby sprawdzić, jak poszło.
- Co miesiąc lub co kwartał, aby stale usprawniać sposób budowania i utrzymywania oprogramowania.
- Gdy w pipeline budowania i wdrażania ciągle pojawiają się te same wąskie gardła lub awarie.
- Po wprowadzeniu nowych narzędzi, technologii lub procesów, aby sprawdzić, czy pomagają.
- Po poważnym incydencie lub awarii, aby znaleźć przyczyny źródłowe i uzgodnić działania zapobiegawcze.
Proponowane pytania lodołamacze
- Gdyby dało się zautomatyzować jedno ręczne zadanie, które by to było i dlaczego?
- Podziel się niedawnym momentem „aha” albo lekcją związaną z praktykami DevOps.
Czy chciałby Pan/Pani, aby Państwa zespół wykonał ćwiczenie rozgrzewkowe, a nie tylko odpowiadał na pytania na głos? Przejrzyj bezpłatne lodołamacze →
Pomysły i wskazówki dotyczące spotkania retrospektywnego
- Nie szukajcie winnych, wtedy ludzie powiedzą, co naprawdę działo się podczas incydentów i wdrożeń.
- Zaproście zarówno development, jak i operations. Każda strona widzi problemy, których druga nie dostrzega.
- Większość czasu poświęćcie na to, co zmienić, a na dawne błędy tylko tyle, ile trzeba, by je zrozumieć.
- Każde uzgodnione działanie powinno mieć właściciela i termin.
- Wymieniajcie z imienia osoby, dzięki którym wydania przebiegły gładko, a incydenty zostały naprawione. Ta praca często umyka uwadze.
- Od czasu do czasu zmieniajcie format, żeby retrospektywa nie spowszedniała.