Runbook produkcyjny dla małego zespołu

·3 min czytania

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

Dwie wieże serwerowe połączone przerwaną ścieżką i ciągłą drogą odzyskiwania.

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.

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.