Runbook i utrzymanie po wdrożeniu
Złożysz powtarzalną procedurę kontroli wdrożenia, reagowania i przekazania dyżuru.
1. Krótka teoria
Runbook to krótka instrukcja dla operatora, który musi działać pod presją i może nie znać historii usługi. Zapisz cel procedury, warunki uruchomienia, właściciela, wymagany dostęp, ryzyka, konkretne polecenia, oczekiwane wyniki oraz punkt decyzji o eskalacji. Po wdrożeniu sprawdź wersję aplikacji, /health, ważny endpoint, błędy, opóźnienia i stan zależności. Obserwuj ustalone okno, bo pierwszy udany request nie wyklucza późnej regresji. Dla zmiany zaplanuj okno serwisowe, komunikację i warunki cofnięcia. Rollback kodu nie zawsze cofa migrację danych; przed działaniem sprawdź zgodność schematu i dostępność kopii. W części incydentowej ułóż sekwencję: potwierdź objaw, określ wpływ, zbierz logi i metryki, zweryfikuj zależności, postaw i sprawdź hipotezę, wykonaj bezpieczną naprawę, a potem potwierdź zdrowie usługi. Dodaj kontakty i sposób przekazania dyżuru bez ujawniania sekretów w dokumencie. Po incydencie zanotuj oś czasu, przyczynę, działania, wpływ, wynik i zadania zapobiegawcze; opisuj mechanizmy, nie przypisuj winy. Procedura jest aktualna tylko wtedy, gdy zespół ćwiczy ją na danych testowych i poprawia po zmianach systemu.
2. Przykłady komend
systemctl status orders-api --no-pager
Weryfikuje proces aplikacji po wdrożeniu.
$ systemctl status orders-api --no-pager
curl -sS -o /dev/null -w '%{http_code} %{time_total}
' http://127.0.0.1:8000/health
Sprawdza kod i czas odpowiedzi endpointu health.
$ curl -sS -o /dev/null -w '%{http_code} %{time_total}
' http://127.0.0.1:8000/health
journalctl -u orders-api --since '10 minutes ago' --no-pager
Czyta logi z okna po zmianie.
$ journalctl -u orders-api --since '10 minutes ago' --no-pager
docker compose ps app-db
Sprawdza stan zależnej bazy w ćwiczeniowym środowisku.
$ docker compose ps app-db
df -h /var
Sprawdza wolne miejsce dla logów i danych.
$ df -h /var
date --iso-8601=seconds
Zapisuje czas obserwacji albo przekazania dyżuru.
$ date --iso-8601=seconds3. Zadanie praktyczne
orders-api. Uwzględnij warunki startu, właściciela, okno zmiany, kontrolę wersji i health, dwa sygnały aplikacji, sprawdzenie app-db, próg decyzji o cofnięciu, zgodność schematu, komunikację oraz końcowy zapis wyniku. Przećwicz na danych testowych wariant alertu 5xx po zmianie: zapisz oś czasu i hipotezy, wybierz test, opisz działanie i warunki zamknięcia. Dodaj krótką notatkę przekazania dyżuru i jedno zadanie zapobiegawcze.
4. Typowe błędy
- Lista poleceń bez oczekiwanych wyników i punktów decyzji.
- Brak właściciela incydentu lub kontaktu do eskalacji.
- Założenie, że rollback obrazu automatycznie cofa migrację bazy.
- Zakończenie wdrożenia po jednym HTTP 200 bez obserwacji trendu błędów.
- Wpisanie sekretów do runbooka lub notatki z incydentu.
5. Podsumowanie
Dobry runbook prowadzi od warunków startu przez kontrole i decyzje do weryfikacji oraz przekazania wyniku. Łączy wiedzę o health, logach, metrykach, zależnościach, backupie i odtwarzaniu. Regularne ćwiczenie utrzymuje procedurę użyteczną.