Jak napisać runbook dla funkcji AI, którą utrzymuje twój zespół

Gdzie zwykły runbook usługi nie wystarcza

Zwykły runbook zakłada, że awarie objawiają się błędami. Funkcje AI potrafią zawodzić, zwracając HTTP 200: pewna siebie błędna odpowiedź, pętla narzędzi, która dalej zużywa tokeny, agent przekazujący człowiekowi każdą sprawę. Niektóre przyczyny leżą poza twoim kodem, na przykład przeciążony dostawca, zmiana wersji modelu albo nowy rodzaj danych wejściowych. Dyżurny może też nie wiedzieć nic o promptach ani ewaluacji. Runbook musi zamienić to wszystko w kontrole, które osoba bez specjalizacji wykona o trzeciej w nocy.

Najpierw sklasyfikuj objaw

• Wolno: opóźnienie powyżej celu, widoczne w czasie do pierwszego tokenu, opóźnieniu całego żądania, długości kolejki i czasach odpowiedzi dostawcy
• Niedostępna: błędy od dostawcy lub z własnego serwowania; Anthropic dokumentuje na przykład 429 rate_limit_error i 529 overloaded_error
• Drogo: tokeny lub koszt na żądanie albo sprawę powyżej budżetu, często przez pętle, ponowienia lub rosnący kontekst
• Błędnie: nieudana ewaluacja kanarkowa, wyniki strukturalne nieprzechodzące walidacji, rosnąca liczba eskalacji albo zgłoszenia użytkowników
• Poza granicami: akcje wykraczające poza oczekiwane limity, skok odrzuconych wywołań narzędzi albo podejrzenie prompt injection

Przykładowe wpisy runbooka

Każdy wpis wymienia pierwsze kontrole, bezpieczne działanie i właściciela. Poniższe wpisy są hipotetyczne i dotyczą asystenta dla klientów.

1. 1

   Wolno

   Z rozbicia śladu sprawdź, czy czas zjada dostawca, wyszukiwanie czy narzędzia. Jeśli wolny jest dostawca, przełącz na przetestowaną trasę zapasową albo ogranicz ruch, który nie jest pilny. Właściciel, jeśli problem nie ustąpi: zespół platformy.

2. 2

   Niedostępna

   Sprawdź status dostawcy i typy błędów. Ponowienia wymagają backoffu z jitterem i budżetu; książka SRE Google'a pokazuje, jak ponowienia na kilku warstwach mnożą obciążenie przeciążonego backendu. Jeśli błędy się utrzymują, włącz trasę zapasową albo ścieżkę bez AI. Właściciel: zespół platformy.

3. 3

   Drogo

   Wypisz sprawy z największą liczbą tokenów w ostatniej godzinie; pętle widać jako wiele wywołań na sprawę. Ustaw limity wywołań narzędzi lub tokenów na sprawę albo wyłącz dotknięty przepływ. Właściciel: zespół funkcji.

4. 4

   Błędnie

   Uruchom kanarkowy zestaw ewaluacyjny na konfiguracji produkcyjnej, z syntetycznymi danymi testowymi i narzędziami zapisującymi zastąpionymi atrapami lub odizolowanymi, żeby test nie wywołał prawdziwych działań biznesowych. Jeśli nie przechodzi po niedawnej zmianie promptu lub wersji modelu, wycofaj tę zmianę. Nie przywracaj po prostu starszego indeksu wyszukiwania: może nadal zawierać wycofane dokumenty albo nieaktualne uprawnienia, więc najpierw zastosuj bieżące usunięcia i reguły dostępu albo zostaw obecny indeks i eskaluj. Jeśli nic się nie zmieniło, zbierz przykłady dla właścicieli i nie zmieniaj promptów na dyżurze. Właściciel: zespół funkcji razem z właścicielem merytorycznym.

5. 5

   Poza granicami

   Wyłącz narzędzia zapisujące albo całą funkcję, zabezpiecz ślady, cofnij poświadczenia przy podejrzeniu nadużycia i postępuj według procesu dla incydentów bezpieczeństwa. Właściciel: bezpieczeństwo.

Przełączniki do zbudowania przed pierwszym incydentem

Większość powyższych działań zadziała tylko wtedy, gdy ktoś wcześniej je zbudował i przetestował:

• Feature flaga, która wyłącza ścieżkę AI i wraca do poprzedniego procesu albo wyświetla jasny komunikat
• Osobny przełącznik dla każdego narzędzia zapisującego i tryb tylko do odczytu dla agentów
• Przypięta wersja modelu i trasa zapasowa, która przeszła zestaw ewaluacyjny
• Limity kosztów i częstotliwości na klienta, użytkownika lub sprawę

Przećwicz każdy przełącznik w zaplanowanym ćwiczeniu. Książka SRE Google'a mówi to wprost o trybach awaryjnych: ścieżka kodu, której nigdy nie używasz, często po prostu nie działa.

Odpowiedzialność i eskalacja

Książka SRE Google'a zaleca wczesne ogłaszanie incydentu i jasne warunki, na przykład gdy potrzebny jest drugi zespół, awarię widzą klienci albo problem pozostaje nierozwiązany po godzinie skupionej analizy. Rozdziela też role: dowodzącego incydentem, lidera operacyjnego, którego zespół pod jego kierunkiem jako jedyny zmienia system, i osobę od komunikacji. Funkcje AI dodają jeszcze jedną rolę. To, czy odpowiedzi są błędne, może wymagać oceny właściciela merytorycznego, na przykład kierownik działu szkód przy asystencie do obsługi szkód, więc wpisz tę osobę do runbooka razem ze sposobem kontaktu.

Jak utrzymać runbook w aktualności

Każdy postmortem powinien dodać albo poprawić jakiś wpis. Zmiany u dostawcy też należą do runbooka: nowa wersja modelu, zmieniony limit wywołań, data wycofania. Sprawdź, jakie dane śladów dyżurni faktycznie widzą, bo potrzebna im treść może być celowo wstrzymana. Praktyczny następny krok: rozpisz pięć klas dla jednej funkcji na podstawie sygnałów, które już zbierasz, i zaznacz każde miejsce, gdzie brakuje sygnału albo przełącznika.

Inżynieria i architektura AI