Ocena dojrzałości DevOps

Sprawdź, co spowalnia wasze wydania, od potoku po produkcję.

Wypróbuj tę analizę stanu zdrowia w czasie rzeczywistym

Czym jest Ocena dojrzałości DevOps?

Ocena dojrzałości DevOps obejmuje całą drogę od commita do produkcji w pięciu grupach: Potok CI/CD, Wydania i wdrożenia, Niezawodność i operacje, Automatyzacja bezpieczeństwa i zgodności oraz Platforma i infrastruktura. Zespół ocenia 15 obszarów, takich jak częstotliwość integracji, ograniczanie ryzyka wdrożeń, zrównoważone dyżury czy zgodność jako kod, na pięciostopniowej skali od poziomu Ad hoc do poziomu Zoptymalizowany. Zespoły, które rzadko wydają oprogramowanie, zwykle dobrze znają objawy: ręczne kroki przy każdym wydaniu i dyżury, które wyczerpują ludzi. Oceny pokazują, który obszar jest prawdziwym wąskim gardłem. Ponieważ każdy poziom ma swój opis, programiści, inżynierowie SRE i osoby odpowiedzialne za produkt oceniają ten sam obszar według tych samych kryteriów, a różnice w ich ocenach wskazują, od czego zacząć.

Wymiary

Potok CI/CD

Jak skutecznie zespół buduje oprogramowanie, integruje zmiany i otrzymuje informację zwrotną dzięki zautomatyzowanym potokom.

  • Automatyzacja buildów

    Jak niezawodnie i automatycznie oprogramowanie jest budowane i weryfikowane.

    1. Ad hocBuildy są ręczne, powolne i podatne na błędy.
    2. Rozwijający sięIstnieje podstawowa automatyzacja, ale jest krucha lub niekompletna.
    3. ZdefiniowanyBuildy działają niezawodnie przy umiarkowanym poziomie automatyzacji.
    4. ZarządzanyBuildy są w wysokim stopniu zautomatyzowane, a informacja zwrotna jest szybka i wiarygodna.
    5. ZoptymalizowanyAutomatyzacja buildów działa płynnie i stabilnie, jest stale optymalizowana, a awarie zdarzają się niemal wcale.

  • Częstotliwość integracji

    Jak często programiści integrują zmiany ze wspólną bazą kodu.

    1. Ad hocIntegracja odbywa się rzadko, co prowadzi do dużych i ryzykownych scaleń.
    2. Rozwijający sięZespół próbuje integrować zmiany częściej, ale wciąż brakuje konsekwencji.
    3. ZdefiniowanyCodzienna integracja jest powszechna i ogranicza konflikty przy scalaniu.
    4. ZarządzanyIntegracja jest ciągła i stabilna w całym zespole.
    5. ZoptymalizowanyIntegracja niemal w czasie rzeczywistym, małymi i bezpiecznymi porcjami zmian, zapewnia szybki przepływ pracy.

  • Informacja zwrotna z potoku

    Szybkość i przejrzystość informacji, które potok przekazuje programistom.

    1. Ad hocInformacja zwrotna jest powolna, niejasna lub niewiarygodna.
    2. Rozwijający sięInformacja zwrotna istnieje, ale często jest opóźniona lub zaszumiona.
    3. ZdefiniowanyInformacja zwrotna z potoku pojawia się w miarę szybko i pozwala podjąć działania.
    4. ZarządzanyInformacja zwrotna jest szybka, jasna i wspiera sprawne iteracje programistów.
    5. ZoptymalizowanyInformacja zwrotna jest natychmiastowa i precyzyjna, co pozwala pracować w tempie najlepszych zespołów.

Wydania i wdrożenia

Jak bezpiecznie, przewidywalnie i często zespół dostarcza zmiany użytkownikom.

  • Automatyzacja wdrożeń

    Poziom automatyzacji i powtarzalności wdrożeń.

    1. Ad hocWdrożenia są ręczne, ryzykowne i podatne na błędy.
    2. Rozwijający sięWprowadzono pewną automatyzację, ale stosuje się ją niekonsekwentnie.
    3. ZdefiniowanyWdrożenia są w większości zautomatyzowane i przewidywalne.
    4. ZarządzanyWdrożenia są w pełni zautomatyzowane, a niepowodzenia zdarzają się rzadko.
    5. ZoptymalizowanyCiągłe wdrażanie zapewnia bezpieczne, szybkie i odwracalne wydania.

  • Ograniczanie ryzyka wdrożeń

    Jak skutecznie zespół minimalizuje ryzyko podczas wydań.

    1. Ad hocWydania to ryzykowne wdrożenia typu „big bang”.
    2. Rozwijający sięZespół w pewnym stopniu ogranicza ryzyko, ale w niewielkim zakresie.
    3. ZdefiniowanyFlagi funkcji i stopniowe wdrażanie są stosowane regularnie.
    4. ZarządzanyWydania są mało ryzykowne dzięki solidnym zabezpieczeniom i monitorowaniu.
    5. ZoptymalizowanyZaawansowane strategie wydań zapobiegają awariom i umożliwiają natychmiastowe wycofanie zmian.

  • Częstotliwość dostarczania

    Jak często wartość trafia do użytkowników.

    1. Ad hocWydania są rzadkie, nieprzewidywalne i bardzo nieregularne.
    2. Rozwijający sięRytm wydań się poprawia, ale wciąż jest nierówny.
    3. ZdefiniowanyZespół wydaje zmiany według przewidywalnego harmonogramu.
    4. ZarządzanyCykle wydań są częste i niezawodne.
    5. ZoptymalizowanyCiągłe dostarczanie zapewnia szybki i bezpieczny przepływ wartości.

Niezawodność i operacje

Jak dobrze zespół obserwuje działające systemy, reaguje na problemy i dba o ich kondycję.

  • Monitorowanie i obserwowalność

    Jak dobrze zespół rozumie kondycję i zachowanie systemu.

    1. Ad hocMonitorowanie jest ograniczone lub reaktywne, a problemy są wykrywane za późno.
    2. Rozwijający sięIstnieją podstawowe dashboardy, ale w widoczności są poważne luki.
    3. ZdefiniowanyMonitorowanie zapewnia wystarczającą widoczność większości komponentów.
    4. ZarządzanyRozbudowana obserwowalność oparta na logach, metrykach i śladach umożliwia szybką diagnozę.
    5. ZoptymalizowanyKompleksowa obserwowalność zapewnia predykcyjne wnioski i automatyczne wykrywanie problemów.

  • Reagowanie na incydenty

    Jak sprawnie zespół reaguje na incydenty i je rozwiązuje.

    1. Ad hocObsługa incydentów jest chaotyczna, a odpowiedzialność niejasna.
    2. Rozwijający sięProcesy są coraz lepiej uporządkowane, ale rozwiązywanie incydentów wciąż bywa nierówne.
    3. ZdefiniowanyIncydenty są obsługiwane metodycznie, z umiarkowaną sprawnością.
    4. ZarządzanyReakcja jest szybka i skoordynowana, a MTTR niski.
    5. ZoptymalizowanyBardzo dojrzałe zarządzanie incydentami z postmortemami nastawionymi na wyciąganie wniosków.

  • Zrównoważone dyżury

    Sprawiedliwość i skuteczność procesów dyżurowych.

    1. Ad hocDyżury są uciążliwe, nieprzewidywalne lub niesprawiedliwe.
    2. Rozwijający sięObciążenie staje się łatwiejsze do opanowania, ale problemy nie znikają.
    3. ZdefiniowanyRotacja jest sprawiedliwa, a liczba alertów rozsądna.
    4. ZarządzanyDobra higiena dyżurów, dobrze dostrojone alerty i odpowiednie narzędzia.
    5. ZoptymalizowanyAlerty po godzinach pracy zdarzają się sporadycznie, a większość problemów obsługuje automatyzacja.

Automatyzacja bezpieczeństwa i zgodności

Jak głęboko bezpieczeństwo i zgodność są zautomatyzowane i wbudowane w cały potok dostarczania.

  • Integracja bezpieczeństwa

    Jak skutecznie praktyki bezpieczeństwa są wbudowane w procesy wytwarzania oprogramowania.

    1. Ad hocKontrole bezpieczeństwa są ręczne lub odbywają się późno w procesie.
    2. Rozwijający sięIstnieją podstawowe automatyczne skany, ale mają wąski zakres.
    3. ZdefiniowanyBezpieczeństwo jest zintegrowane z CI/CD, a skanowanie odbywa się konsekwentnie.
    4. ZarządzanyKompleksowe, zautomatyzowane kontrole bezpieczeństwa obejmują cały potok.
    5. ZoptymalizowanyCiągłe, inteligentne zabezpieczenia zapobiegają podatnościom na wczesnym etapie.

  • Zarządzanie podatnościami

    Jak szybko i skutecznie podatności są wykrywane i usuwane.

    1. Ad hocPodatności są wykrywane późno, a ich usuwanie trwa długo.
    2. Rozwijający sięProcesy się poprawiają, ale wciąż są niespójne.
    3. ZdefiniowanyReagowanie na podatności jest przewidywalne i mierzone.
    4. ZarządzanyPodatności są usuwane szybko i sprawnie, a zespół proaktywnie im zapobiega.
    5. ZoptymalizowanyWykrywanie, priorytetyzacja i usuwanie podatności są zautomatyzowane i działają na dużą skalę.

  • Zgodność jako kod

    Wykorzystanie automatyzacji do egzekwowania wymogów regulacyjnych, wymagań bezpieczeństwa i polityk.

    1. Ad hocZadania związane ze zgodnością są ręczne i reaktywne.
    2. Rozwijający sięWprowadzono niektóre automatyczne kontrole.
    3. ZdefiniowanyKluczowe polityki są zintegrowane z procesami automatyzacji.
    4. ZarządzanyZgodność jest rutynowo weryfikowana za pomocą automatycznych kontroli.
    5. ZoptymalizowanyZgodność jest zapewniana w sposób ciągły i egzekwowana w czasie rzeczywistym.

Platforma i infrastruktura

Na ile zautomatyzowana, spójna i odporna jest platforma oraz infrastruktura, na której działają systemy.

  • Automatyzacja infrastruktury

    Jak infrastruktura jest przygotowywana, zarządzana i skalowana.

    1. Ad hocInfrastruktura jest przygotowywana ręcznie, z dużym ryzykiem rozjazdu konfiguracji.
    2. Rozwijający sięCzęściowa automatyzacja za pomocą skryptów lub narzędzi.
    3. ZdefiniowanyInfrastruktura jako kod jest wdrożona w kluczowych obszarach.
    4. ZarządzanyW pełni zautomatyzowana infrastruktura zapewnia spójne i powtarzalne środowiska.
    5. ZoptymalizowanySamonaprawiająca się, w pełni orkiestrowana infrastruktura skaluje się inteligentnie.

  • Spójność środowisk

    Na ile spójne są środowiska deweloperskie, przedprodukcyjne i produkcyjne.

    1. Ad hocŚrodowiska znacznie się różnią, a problemy często występują tylko w jednym z nich.
    2. Rozwijający sięŚrodowiska są częściowo ustandaryzowane, ale niespójności pozostają.
    3. ZdefiniowanyŚrodowiska są w większości ujednolicone i zachowują się przewidywalnie.
    4. ZarządzanyŚrodowiska są bardzo spójne i zarządzane za pomocą automatyzacji.
    5. ZoptymalizowanyWszystkie środowiska są w pełni odtwarzalne, skonteneryzowane i stabilne.

  • Niezawodność platformy

    Dostępność, odporność i tolerancja systemu na błędy.

    1. Ad hocAwarie są częste, a praktyki dbania o niezawodność ograniczone.
    2. Rozwijający sięNiezawodność nieznacznie się poprawia, ale problemy nie ustępują.
    3. ZdefiniowanyNiezawodność jest akceptowalna, a usprawnienia są w toku.
    4. ZarządzanyWysoka niezawodność dzięki solidnym działaniom zapobiegawczym.
    5. ZoptymalizowanyWyjątkowa odporność dzięki automatycznemu przywracaniu działania i architekturom odpornym na awarie.

Kiedy należy skorzystać z tej kontroli stanu zdrowia

  • Aby ustalić punkt wyjścia dla kompetencji zespołu w zakresie DevOps i ciągłego dostarczania.
  • Podczas planowania prac inżynieryjnych, aby zdecydować, czy następna w kolejce jest automatyzacja, niezawodność czy bezpieczeństwo.
  • Aby śledzić w czasie dojrzałość DevOps w poszczególnych zespołach lub w całej organizacji.
  • Gdy tworzycie lub rozwijacie praktyki inżynierii platformowej i SRE.
  • Podczas transformacji DevOps, aby dać zespołom wspólną mapę usprawnień.

Porady i wskazówki

  • Poproście inżynierów, specjalistów SRE i interesariuszy produktowych o samodzielne oceny, aby ujawniły się różne spojrzenia na dojrzałość.
  • Zacznijcie od obszarów, w których oceny najbardziej się rozchodzą. Często wskazują wąskie gardła, których nikt dotąd nie nazwał.
  • Dla każdego nisko ocenionego obszaru uzgodnijcie jeden krok w stronę kolejnego poziomu. Nie próbujcie od razu osiągnąć poziomu Zoptymalizowany wszędzie.
  • Powtarzajcie ocenę co kwartał, aby widzieć nawet niewielkie postępy.
  • Zanim zaczniecie dyskutować o ocenach, przeczytajcie wspólnie opisy poziomów, aby wszyscy zgadzali się co do tego, jak wygląda dobry stan.

Najczęściej zadawane pytania

Czym jest model dojrzałości DevOps?
To uporządkowany sposób oceny, na ile zaawansowane są praktyki DevOps i ciągłego dostarczania w zespole. Obszary ocenia się na kolejnych poziomach, od Ad hoc do Zoptymalizowanego, dzięki czemu widać luki i można zaplanować usprawnienia.
Kto powinien wziąć udział w tej ocenie?
Każdy, kto tworzy, wydaje lub utrzymuje oprogramowanie: programiści, inżynierowie SRE, inżynierowie platformowi, specjaliści ds. bezpieczeństwa i liderzy zespołów inżynieryjnych. Każda z tych osób widzi inną część procesu dostarczania.
Jak oceniane są poszczególne obszary?
Każdy obszar jest oceniany na pięciostopniowej skali od Ad hoc do Zoptymalizowanego, a każdy poziom ma swój opis. Dzięki temu oceny są spójne, a zespół ma konkretny punkt wyjścia do dyskusji.
Jak często należy przeprowadzać ocenę?
Większości zespołów odpowiada rytm kwartalny. Daje to czas na wprowadzenie usprawnień i pokazuje postęp między kolejnymi ocenami.
Czy możemy dostosować obszary oceny?
Tak. Administratorzy konta i zespołów mogą tworzyć w TeamRetro własne modele health check, więc możecie dodawać, usuwać lub przeformułowywać obszary tak, aby pasowały do waszych narzędzi i priorytetów.

Powiązane badania kontrolne