DevOps i ciągłe dostarczanie

Oceń dojrzałość DevOps i ciągłego dostarczania w Twoim zespole w obszarach CI/CD, wdrażania, niezawodności, bezpieczeństwa i inżynierii platform, aby wskazać, co należy poprawić.

Proszę biegać w TeamRetro

Mierz i poprawiaj dojrzałość DevOps oraz ciągłego dostarczania

Silne praktyki DevOps i możliwości ciągłego dostarczania odróżniają zespoły, które wdrażają bezpiecznie i szybko, od tych ugrzęzłych w ręcznej pracy i kruchych wydaniach. Obejmując cały cykl życia dostarczania — od potoków CI/CD i zautomatyzowanych wdrożeń po niezawodność, bezpieczeństwo i inżynierię platform — ta ocena pomaga zespołom zobaczyć, gdzie znajdują się na krzywej dojrzałości, od działań doraźnych po w pełni zoptymalizowany, zautomatyzowany przepływ. Oceniając każdą możliwość względem jasnych poziomów dojrzałości, zespoły odkrywają wąskie gardła, uzgadniają priorytety i wytyczają praktyczną ścieżkę ku szybszemu, bezpieczniejszemu i bardziej zrównoważonemu dostarczaniu oprogramowania.

Wymiary

Potok CI/CD

Jak skutecznie zespół buduje, integruje i uzyskuje informacje zwrotne dzięki zautomatyzowanym potokom.

  • Automatyzacja budowania

    Jak niezawodnie i automatycznie generowane oraz weryfikowane są kompilacje oprogramowania.

    1. DoraźnyKompilacje są ręczne, powolne i podatne na błędy.
    2. WschodzącyIstnieje podstawowa automatyzacja, ale jest krucha lub niekompletna.
    3. ZdefiniowanyKompilacje działają niezawodnie przy umiarkowanej automatyzacji.
    4. ZarządzanyKompilacje są wysoce zautomatyzowane z szybką, niezawodną informacją zwrotną.
    5. ZoptymalizowanyAutomatyzacja kompilacji jest płynna, stabilna i ciągle optymalizowana, z niemal zerowymi awariami.

  • Częstotliwość integracji

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

    1. DoraźnyIntegracja zachodzi rzadko, prowadząc do dużych i ryzykownych scaleń.
    2. WschodzącyZespół próbuje częstszej integracji, ale niespójności pozostają.
    3. ZdefiniowanyCodzienna integracja jest powszechna i ogranicza konflikty scaleń.
    4. ZarządzanyIntegracja jest ciągła i stabilna w całym zespole.
    5. ZoptymalizowanyIntegracja niemal w czasie rzeczywistym z małymi, bezpiecznymi zestawami zmian umożliwiającymi szybki przepływ.

  • Informacja zwrotna z potoku

    Szybkość i przejrzystość informacji zwracanych programistom z potoku.

    1. DoraźnyInformacja zwrotna jest powolna, niejasna lub niewiarygodna.
    2. WschodzącyInformacja zwrotna istnieje, ale często jest opóźniona lub zaszumiona.
    3. ZdefiniowanyInformacja zwrotna z potoku jest dość terminowa i przydatna.
    4. ZarządzanyInformacja zwrotna jest szybka, jasna i wspiera szybkie iteracje programistów.
    5. ZoptymalizowanyInformacja zwrotna jest natychmiastowa, precyzyjna i umożliwia elitarną szybkość inżynierską.

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. DoraźnyWdrożenia są ręczne, ryzykowne i podatne na błędy.
    2. WschodzącyWprowadzono pewną automatyzację, ale stosowaną niespójnie.
    3. ZdefiniowanyWdrożenia są w większości zautomatyzowane i przewidywalne.
    4. ZarządzanyW pełni zautomatyzowane wdrożenia z niskim wskaźnikiem awarii.
    5. ZoptymalizowanyCiągłe wdrażanie z bezpiecznymi, szybkimi i odwracalnymi wydaniami.

  • Ograniczanie ryzyka wdrożeń

    Jak skutecznie zespół minimalizuje ryzyko podczas wydania.

    1. DoraźnyWydania to wysoce ryzykowne wydarzenia typu „wszystko naraz”.
    2. WschodzącyIstnieje pewne ograniczanie ryzyka, ale jest ono ograniczone.
    3. ZdefiniowanyRegularnie stosuje się flagi funkcji i etapowe wdrożenia.
    4. ZarządzanyWydania są niskiego ryzyka, z solidnymi zabezpieczeniami i monitorowaniem.
    5. ZoptymalizowanyZaawansowane strategie wydań zapobiegają przestojom i umożliwiają natychmiastowe wycofanie.

  • Częstotliwość dostarczania

    Jak często wartość jest dostarczana użytkownikom.

    1. DoraźnyWydania są rzadkie, nieprzewidywalne i bardzo zmienne.
    2. WschodzącyRytm wydań się poprawia, ale pozostaje niespójny.
    3. ZdefiniowanyZespół wydaje według przewidywalnego harmonogramu.
    4. ZarządzanyCzęste, niezawodne cykle wydań.
    5. ZoptymalizowanyCiągłe dostarczanie zapewnia szybki i bezpieczny przepływ wartości.

Niezawodność i operacje

Jak dobrze zespół obserwuje, reaguje i utrzymuje kondycję działających systemów.

  • Monitorowanie i obserwowalność

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

    1. DoraźnyOgraniczone lub reaktywne monitorowanie; problemy wykrywane zbyt późno.
    2. WschodzącyIstnieją podstawowe pulpity, ale widoczność ma poważne luki.
    3. ZdefiniowanyMonitorowanie zapewnia odpowiednią widoczność większości komponentów.
    4. ZarządzanySilna obserwowalność z logami, metrykami i śladami wspierającymi szybką diagnozę.
    5. ZoptymalizowanyHolistyczna obserwowalność z predykcyjnymi wglądami i automatycznym wykrywaniem.

  • Reagowanie na incydenty

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

    1. DoraźnyIncydenty są chaotyczne, z niejasną odpowiedzialnością.
    2. WschodzącyRosnąca struktura, ale rozwiązywanie pozostaje niespójne.
    3. ZdefiniowanyIncydenty obsługiwane metodycznie, z umiarkowaną sprawnością.
    4. ZarządzanySzybka i skoordynowana reakcja z niskim MTTR.
    5. ZoptymalizowanyWysoce dojrzałe zarządzanie incydentami z analizami powdrożeniowymi nastawionymi na naukę.

  • Zrównoważenie dyżurów

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

    1. DoraźnyDyżury są obciążające, nieprzewidywalne lub niesprawiedliwe.
    2. WschodzącyObciążenie staje się bardziej znośne, ale problemy się utrzymują.
    3. ZdefiniowanyRotacja jest sprawiedliwa, a liczba alertów rozsądna.
    4. ZarządzanyDobra higiena dyżurów z dobrze dostrojonymi alertami i narzędziami.
    5. ZoptymalizowanyMinimalne alerty po godzinach; automatyzacja obsługuje większość problemów.

Automatyzacja bezpieczeństwa i zgodności

Jak głęboko bezpieczeństwo i zgodność są zautomatyzowane i osadzone w całym potoku dostarczania.

  • Integracja bezpieczeństwa

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

    1. DoraźnyKontrole bezpieczeństwa odbywają się ręcznie lub późno w procesie.
    2. WschodzącyIstnieją podstawowe automatyczne skany, ale brakuje im zakresu.
    3. ZdefiniowanyBezpieczeństwo zintegrowane z CI/CD z konsekwentnym skanowaniem.
    4. ZarządzanyKompleksowe automatyczne kontrole bezpieczeństwa w całym potoku.
    5. ZoptymalizowanyCiągłe, inteligentne bezpieczeństwo zapobiegające podatnościom na wczesnym etapie.

  • Zarządzanie podatnościami

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

    1. DoraźnyPodatności wykrywane późno, z powolną naprawą.
    2. WschodzącyProcesy się poprawiają, ale pozostają niespójne.
    3. ZdefiniowanyReakcja na podatności jest przewidywalna i mierzona.
    4. ZarządzanySzybka, efektywna naprawa z proaktywnym zapobieganiem.
    5. ZoptymalizowanyAutomatyczna identyfikacja, priorytetyzacja i naprawa na dużą skalę.

  • Zgodność jako kod

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

    1. DoraźnyZadania związane ze zgodnością są ręczne i reaktywne.
    2. WschodzącyWprowadzono pewne automatyczne kontrole.
    3. ZdefiniowanyKluczowe polityki zintegrowane z procesami automatyzacji.
    4. ZarządzanyZgodność rutynowo weryfikowana za pomocą automatycznych kontroli.
    5. ZoptymalizowanyCiągła zgodność z egzekwowaniem w czasie rzeczywistym.

Platforma i infrastruktura

Jak zautomatyzowana, spójna i odporna jest bazowa platforma oraz infrastruktura.

  • Automatyzacja infrastruktury

    Jak infrastruktura jest udostępniana, zarządzana i skalowana.

    1. DoraźnyInfrastruktura udostępniana ręcznie z wysokim ryzykiem dryfu konfiguracji.
    2. WschodzącyCzęściowa automatyzacja z użyciem skryptów lub narzędzi.
    3. ZdefiniowanyInfrastruktura jako kod wdrożona w kluczowych obszarach.
    4. ZarządzanyW pełni zautomatyzowana infrastruktura ze spójnymi, powtarzalnymi środowiskami.
    5. ZoptymalizowanySamonaprawiająca się, w pełni orkiestrowana infrastruktura z inteligentnym skalowaniem.

  • Spójność środowisk

    Jak spójne są środowiska deweloperskie, testowe i produkcyjne.

    1. DoraźnyŚrodowiska znacznie się różnią; problemy często specyficzne dla środowiska.
    2. WschodzącyPewna standaryzacja, ale niespójności pozostają.
    3. ZdefiniowanyŚrodowiska w większości spójne, z przewidywalnym zachowaniem.
    4. ZarządzanyWysoce spójne środowiska zarządzane poprzez automatyzację.
    5. ZoptymalizowanyW pełni odtwarzalne, skonteneryzowane i stabilne środowiska wszędzie.

  • Niezawodność platformy

    Dostępność systemu, odporność i tolerancja na awarie.

    1. DoraźnyCzęste przestoje przy ograniczonych praktykach niezawodności.
    2. WschodzącyNiezawodność nieco się poprawia, ale problemy się utrzymują.
    3. ZdefiniowanyAkceptowalna niezawodność z trwającymi usprawnieniami.
    4. ZarządzanyWysoka niezawodność z solidnymi środkami zapobiegawczymi.
    5. ZoptymalizowanyWyjątkowa odporność z automatycznym odzyskiwaniem i architekturami tolerującymi awarie.

Kiedy używać tej oceny kondycji?

  • Gdy ustalasz punkt odniesienia dla możliwości DevOps i ciągłego dostarczania w zespole.
  • Podczas planowania inżynierskiego, aby ustalić priorytety inwestycji w automatyzację, niezawodność lub bezpieczeństwo.
  • Aby śledzić postępy dojrzałości DevOps w czasie w zespołach lub w całej organizacji.
  • Gdy tworzysz lub skalujesz praktyki inżynierii platform i SRE.
  • W ramach transformacji DevOps, aby uzgodnić wspólną mapę drogową usprawnień.

Porady i wskazówki

  • Pozwól inżynierom, SRE i interesariuszom produktowym oceniać niezależnie, aby ujawnić różne perspektywy na dojrzałość.
  • Skup dyskusję na wymiarach o największym rozrzucie ocen — często ujawniają one ukryte wąskie gardła.
  • Połącz każdy nisko oceniony wymiar z konkretnym kolejnym krokiem ku następnemu poziomowi dojrzałości, zamiast dążyć do „Zoptymalizowanego” wszędzie naraz.
  • Powtarzaj ocenę kwartalnie, aby stopniowe postępy dojrzałości były widoczne i motywujące.
  • Wykorzystuj opisy poziomów dojrzałości jako wspólny język do uzgodnienia, jak wygląda „dobry” stan, zanim zaczniecie debatować nad ocenami.

Często zadawane pytania

Czym jest model dojrzałości DevOps?
To ustrukturyzowany sposób oceny zaawansowania praktyk DevOps i ciągłego dostarczania w zespole, oceniający możliwości na etapowych poziomach od doraźnego po zoptymalizowany, dzięki czemu możesz zidentyfikować luki i zaplanować usprawnienia.
Kto powinien wziąć udział w tej ocenie?
Każdy, kto uczestniczy w budowaniu, dostarczaniu i utrzymywaniu oprogramowania — programiści, SRE, inżynierowie platform, specjaliści ds. bezpieczeństwa i liderzy inżynieryjni wnoszą cenną perspektywę.
Jak oceniane są wymiary?
Każdy wymiar jest oceniany w pięciostopniowej skali dojrzałości od Doraźnego po Zoptymalizowany, z jasnymi opisami każdego poziomu, dzięki czemu zespoły mogą oceniać spójnie i omawiać uzasadnienie swoich ocen.
Jak często powinniśmy ją przeprowadzać?
Cykl kwartalny sprawdza się w większości zespołów, dając wystarczająco dużo czasu na wprowadzenie usprawnień, jednocześnie utrzymując tempo i uwidaczniając postępy w kolejnych cyklach.
Czy możemy dostosować wymiary?
Tak. Możesz dodawać, usuwać lub przeformułowywać grupy wymiarów i wymiary, aby odzwierciedlić konkretne narzędzia, kontekst i priorytety Twojego zespołu.