Udane wdrożenia

Co poszło dobrze podczas ostatnich wdrożeń?

Zautomatyzowany pipeline testów i wdrożeń zadziałał bez zarzutu przy ostatnim wydaniu.
Współpraca dev i ops przed wdrożeniem pomogła wcześnie wyłapać potencjalne problemy.
Przygotowany plan rollbacku pozwolił nam szybko wycofać problematyczne wdrożenie.
Obszary do poprawy

Z jakimi wyzwaniami się mierzyliśmy i co możemy poprawić?

Brak testów automatycznych dla niektórych komponentów spowodował nieoczekiwane problemy na produkcji.
Luki w komunikacji między zespołami dev i ops powodowały opóźnienia i poprawki.
Niewystarczający monitoring i alerty utrudniały szybkie wykrywanie problemów i reagowanie na nie.
Współpraca i kultura

Jak usprawnić pracę zespołową i budować kulturę DevOps?

Wzajemne szkolenia i job shadowing mogłyby zmniejszyć dystans między zespołami dev i ops.
Kultura postmortemów bez szukania winnych zachęciłaby do otwartych rozmów i nauki.
Regularne sesje dzielenia się wiedzą pomogłyby lepiej rozumieć wyzwania każdego zespołu.
Narzędzia i procesy

Jak możemy zoptymalizować nasze narzędzia, technologie i procesy?

Wprowadzenie infrastruktury jako kodu poprawiłoby spójność i ograniczyło pracę ręczną.
Przejście na architekturę mikroserwisów mogłoby poprawić skalowalność i odporność.
Inwestycja w lepsze narzędzia do monitoringu i obserwowalności dałaby nam głębszy wgląd.

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.

Najczęściej zadawane pytania

Czym jest retrospektywa DevOps?
To spotkanie, na którym development i operations wspólnie analizują ostatnie wdrożenia, incydenty i współpracę. Tablica obejmuje udane wdrożenia, obszary do poprawy, współpracę i kulturę oraz narzędzia i procesy.
Czym retrospektywa DevOps różni się od retrospektywy sprintu?
Retrospektywa sprintu dotyczy ogólnej pracy zespołu w sprincie. Retrospektywa DevOps skupia się na tym, jak oprogramowanie jest budowane, dostarczane i utrzymywane, więc częściej pojawiają się w niej wdrożenia, incydenty, pipeline'y i dyżury.
Jak często zespół powinien przeprowadzać retrospektywę DevOps?
Wiele zespołów robi ją po każdym cyklu wydań albo co miesiąc lub co kwartał. Warto też zorganizować ją wkrótce po poważnym incydencie, póki szczegóły są świeże.
Kto powinien uczestniczyć w retrospektywie DevOps?
Programiści, osoby z operations lub SRE, QA i każdy, kto ma dyżury albo odpowiada za pipeline. Cały sens polega na tym, by dev i ops spotkali się przy jednym stole.
Czym różni się od postmortemu incydentu?
Postmortem dogłębnie analizuje jeden incydent. Retrospektywa DevOps patrzy przekrojowo na ostatnie wydania i incydenty, aby znaleźć powtarzające się wzorce w procesach i narzędziach.
Czy są Państwo gotowi do przeprowadzenia tej retrospektywy?Zapraszamy do obejrzenia tej retrospektywy na żywo