Stanowisko
DevOps i inżynieria platformy
Ilu ludzi musi coś zrobić, żeby zmiana trafiła na produkcję? Jeśli więcej niż dwóch, to wdrożenie jest wydarzeniem, a nie czynnością - i dlatego zdarza się rzadko.
Rozmowa wstępna
Cztery pytania, od których byśmy zaczęli
Ilu ludzi dotyka jedno wdrożenie na produkcję?
Im więcej rąk, tym rzadziej wdrażacie, a im rzadziej wdrażacie, tym większe i ryzykowniejsze są kolejne zmiany.
Jak szybko dowiadujecie się o problemie na produkcji?
Jeśli od użytkownika, to monitoring mierzy coś innego niż to, co psuje się naprawdę.
Skąd wiecie, że środowisko testowe odpowiada produkcyjnemu?
Jeśli z założenia, to część błędów z produkcji jest nieodtwarzalna gdziekolwiek indziej.
Czego nie robicie, choć wiecie, że trzeba?
Zwykle: nie porządkujecie konfiguracji i nie przeglądacie kosztów infrastruktury. Zawsze dlatego, że nic nie płonie.
Zdejmujemy pracę powtarzalną, zostawiamy decyzje o platformie
Konfiguracja środowisk, przebieg wdrożeń, zbieranie kontekstu przy incydencie i zestawianie kosztów dają się odciążyć. Decyzje o standardzie platformy i o reakcji w incydencie zostają przy inżynierze.
- Wdrożenie przestaje być wydarzeniem. - Powtarzalny przebieg z wycofaniem sprawia, że częstsze i mniejsze zmiany są bezpieczniejsze niż rzadkie i duże.
- Incydent zaczyna się od kontekstu. - Co się zmieniło w ostatnich godzinach, co jeszcze zareagowało, które usługi są powiązane - zanim ktoś zacznie szukać.
- Standard jest widoczny, a odstępstwo nazwane. - Zespół może zrobić inaczej, ale wtedy wiadomo, gdzie i dlaczego - zamiast odkrywać to przy awarii.
Zakres
Co da się odciążyć w pracy zespołu platformowego
Dwadzieścia przykładowych zadań. Każde ma punkt zatwierdzenia po stronie człowieka. Poniżej wybrane, a zakres dopasowujemy do Waszego stosu technologicznego.
Środowiska i ich konfiguracja
- Konfiguracja środowisk opisana i odtwarzalna
- Porównanie środowiska testowego z produkcyjnym
- Sygnał o rozjeździe konfiguracji
- Rejestr odstępstw od standardu (decyzja: inżynier)
Wdrożenia
- Powtarzalny przebieg wdrożenia z krokiem wycofania tam, gdzie jest możliwy
- Sprawdzenia przed wdrożeniem jako warunek startu
- Rejestr wdrożeń z zakresem zmian
- Sygnał o wdrożeniu odbiegającym od przebiegu (ocena: inżynier)
Monitoring i alerty
- Przegląd alertów pod kątem przydatności
- Wskazanie alertów o wysokim udziale trafień fałszywych (ocena przydatności: inżynier)
- Powiązanie alertu z usługą i właścicielem
- Sygnał o usłudze bez monitoringu
Incydenty
- Kontekst przy zgłoszeniu: ostatnie zmiany i powiązane usługi
- Zestawienie sygnałów z tego samego okna czasowego
- Chronologia incydentu zapisana w trakcie
- Projekt analizy po incydencie (treść: inżynier)
Koszty infrastruktury
- Koszt przypisany do usług i zespołów
- Wskazanie zasobów nieużywanych
- Zmiany kosztu wobec poprzedniego okresu
- Materiał do decyzji o zmianie konfiguracji (decyzja: inżynier)
Dzień pracy
Dzisiaj
- Konfiguracja środowisk żyje własnym życiem i rozjeżdża się po cichu
- Wdrożenie wymaga obecności kilku osób i dobrego dnia
- Przy incydencie zaczynacie od ustalania, co się ostatnio zmieniło
- Alerty przychodzą w liczbie, która zużywa uwagę zespołu
- Chronologię incydentu odtwarzacie po fakcie, z pamięci
- Koszty infrastruktury oglądacie, gdy przyjdzie faktura
Z asystą AI
- Rozjazd konfiguracji między środowiskami jest sygnalizowany
- Wdrożenie ma powtarzalny przebieg, a przy zmianach nieodwracalnych - etapy
- Incydent zaczyna się od listy ostatnich zmian i powiązanych usług
- Alerty, które nigdy nie wywołały działania, są wskazane
- Chronologia incydentu zapisuje się w trakcie
- Koszt jest przypisany do usług i zespołów na bieżąco
- Częstotliwość wdrożeń
mniejsze zmiany częściej, zamiast dużych rzadko
wdrożenie nie wymaga zebrania kilku osób
- Czas przywrócenia po incydencie
krótsza droga do przyczyny
kontekst i ostatnie zmiany są przy zgłoszeniu
- Zgodność środowisk
mniej błędów nieodtwarzalnych poza produkcją
rozjazd konfiguracji jest sygnalizowany
- Koszt infrastruktury
widać, co kosztuje i czyje to jest
koszt przypisany do usług i zespołów
Zaczynamy od wdrożeń, bo ich częstotliwość wpływa na wszystko pozostałe.
- Krok 1
Powtarzalny przebieg wdrożenia
Z krokiem wycofania i sprawdzeniami przed startem. Przy zmianach nieodwracalnych - migracjach schematu przede wszystkim - wycofanie nie istnieje i nie udajemy, że jest inaczej; tam pracuje się etapami i naprawą do przodu, a przebieg ma to uwzględniać.
- Krok 2
Zgodność środowisk
Porównanie konfiguracji i sygnał o rozjeździe.
- Krok 3
Kontekst przy incydencie
Ostatnie zmiany, powiązane usługi, chronologia zapisywana w trakcie.
- Krok 4
Alerty i koszty
Przegląd przydatności alertów i przypisanie kosztów. Na końcu, bo wymaga danych z kilku okresów.
Częste pytania
Pytania, które padają na pierwszym spotkaniu
Czym to się różni od pracy administratora systemów?
Administrator utrzymuje to, co już działa - serwery, kopie zapasowe, aktualizacje. Tu przedmiotem są środowiska, w których powstaje oprogramowanie, i droga zmiany na produkcję. Role bywają łączone w mniejszych firmach, ale problemy, które rozwiązują, są zupełnie różne.
Czy zespół platformowy może być po tym mniejszy?
Zespoły platformowe są zwykle wąskim gardłem, nie nadmiarem - każdy zespół produktowy czeka w kolejce do jednej albo dwóch osób. Odciążenie powtarzalnych wdrożeń i zbierania kontekstu przy incydencie nie zmniejsza zespołu; skraca tę kolejkę. To jest zresztą pierwsza rzecz, którą zauważają zespoły produktowe.
Czy to podlega AI Act?
Praca nad infrastrukturą nie jest zastosowaniem wysokiego ryzyka. Uwagi wymaga tylko to, żeby dane o wdrożeniach i incydentach służyły poprawie platformy, a nie ocenie zespołów ani osób, które wdrażały zmianę.
Zostało pytanie, którego tu nie ma? Umów rozmowę
Następny krok
Ile razy w zeszłym miesiącu wdrażaliście na produkcję?
Pokażemy Wam, jak wygląda praca platformowa, w której wdrożenie przestaje być wydarzeniem, a incydent zaczyna się od kontekstu.