Runbook pomaga przejść od konkretnego objawu do bezpiecznej decyzji.

Runbook pomaga przejść od konkretnego objawu do bezpiecznej decyzji. Nie jest listą wszystkich dostępnych poleceń. Pisz dla osoby o oczekiwanych umiejętnościach, która może być zmęczona lub mało znać komponent.
Zacznij od sygnału i wpływu
Nazwij alarm, dotkniętą ścieżkę i warunki zastosowania. Podlinkuj panel i wyjaśnij obserwację odróżniającą podobne przyczyny. Dodaj właściciela, datę sprawdzenia i eskalację. Dokument musi pozostać dostępny podczas awarii aplikacji; jego lokalizacja jest częścią projektu operacyjnego.
Określ warunki i granice zatrzymania
Opisz prawa, wybór środowiska i zgody dla istotnych działań. Ustal, kiedy niewyjaśnione dane, brak kopii lub sprzeczny wynik wymagają zatrzymania i eskalacji. Nie umieszczaj sekretów. Każdy krok potrzebuje celu, oczekiwanego wyniku i kolejnej decyzji, również skutku dla pracy w toku.
Dodaj potwierdzenie i utrzymanie
Przy restarcie, powtórzeniu czy przełączeniu opisz duplikaty i wycofanie. Sprawdź ścieżkę klienta i zaległą pracę oraz zapisz działania i następstwa. Niech inna osoba bezpiecznie wypróbuje instrukcję. Aktualizuj po zmianach i incydentach. Krótka sprawdzona procedura jest pewniejsza niż długi porzucony dokument.
Przykład i dowód odbioru
Dla rosnącej kolejki instrukcja rozróżnia brak procesów, wolnego dostawcę i pojedynczą stale błędną pracę. Ogólny restart może ukryć przyczynę lub zwiększyć powtórki. Wskaż obserwację potwierdzającą każdą gałąź oraz następną ograniczoną akcję. Inna osoba powinna wybrać właściwy przebieg i sprawdzić kolejkę oraz wynik biznesowy. Niezrozumiały komunikat lub brak prawa staje się poprawką dokumentu. Odbiór nie polega na wykonaniu wszystkich poleceń, tylko na bezpiecznej decyzji z wystarczającymi dowodami. Określ również, kiedy wzrost jest oczekiwany, na przykład podczas uzgodnionej partii. W takiej sytuacji instrukcja może prawidłowo zalecić obserwację zamiast ingerencji. To pomaga odróżnić działającą procedurę od automatycznego zestawu kroków, który nie uwzględnia faktycznej sytuacji operacyjnej.
- Powiązana usługa
- Dyżury w startupie bez osobnego zespołu SRE
- Waga incydentu: praktyczna macierz eskalacji
Najczęstsze pytania
Czy dodawać polecenia?
Tak, sprawdzone oraz z warunkami, zakresem i oczekiwanym wynikiem.
Jak długa powinna być instrukcja?
Na tyle, ile wymaga konkretna ścieżka, bez niepowiązanych szczegółów.
Kto powinien testować?
Osoba inna niż autor z oczekiwanym dostępem i umiejętnościami.
Co gdy rzeczywistość odbiega?
Zatrzymaj się na ustalonej granicy, zachowaj dowody i eskaluj.
Kiedy aktualizować?
Po zmianach, ćwiczeniach i incydentach zmieniających założenia.
Od pomysłu do wykonalnego zakresu
Prześlij ścieżkę użytkownika, integracje i ograniczenia terminu. Możemy przygotować wycenę z założeniami i wyłączeniami.
Warto doczytać
Dyżury w startupie bez osobnego zespołu SRE
Mały zespół może prowadzić użyteczne dyżury, jeżeli obietnice pasują do zasobów.
Waga incydentu: praktyczna macierz eskalacji
Waga opisuje rzeczywisty lub wiarygodny wpływ biznesowy, nie dramatyzm komunikatu w logu.
Rollback czy hotfix podczas awarii produkcji
Podczas incydentu wybierz działanie najpewniej przywracające usługę przy kontrolowanym ryzyku.