Podczas awarii klienci oceniają Cię po dwóch rzeczach: jak szybko problem zostanie naprawiony i co słyszą, gdy trwa naprawa. Na pierwsze nie zawsze masz wpływ. Drugie zależy wyłącznie od Ciebie – i właśnie tu większość zespołów improwizuje.
Improwizacja zawodzi w przewidywalny sposób. Przez godzinę nikt nic nie publikuje, bo wszyscy naprawiają problem. Trzy osoby publikują trzy różne wersje. Komunikat mówi o „degradacji w klastrze eu-west”, a klienci nie mają pojęcia, czy ich to dotyczy. Ten poradnik daje Ci jednostronicowy plan, dzięki któremu rozstrzygniesz te kwestie zawczasu, oraz szablony do skopiowania.
Plan na jedną stronę
Spisz go raz, trzymaj tam, gdzie osoba na dyżurze go znajdzie, i przeglądaj dwa razy w roku.
Role
Lider incydentu: odpowiada za incydent, określa jego wagę i koordynuje naprawę.
Osoba od komunikacji: pisze i publikuje każdy komunikat dla klientów. To nie ta sama osoba, która naprawia problem – kto jednocześnie naprawia i pisze, robi jedno z tych dwóch gorzej.
Wsparcie: odpowiada na napływające pytania, podając link do strony statusu, i przekazuje dalej to, co zgłaszają klienci.
W małym zespole te same osoby pełnią kilka ról. Chodzi o to, by ustalić, kto co robi, przed awarią, a nie w jej trakcie. Jeśli połączysz to z grafikiem dyżurów, dwie pierwsze role zawsze będą miały konkretną osobę.
Poziomy ważności
Większości zespołów wystarczą trzy poziomy:
Poważny: produkt, proces zamówienia albo logowanie nie działa lub jest bezużyteczne dla większości klientów. Aktualizacja co 30 minut.
Drobny: jedna funkcja nie działa albo działa wolno lub problem dotyczy części klientów. Aktualizacja co godzinę.
Konserwacja: zaplanowane prace. Zapowiedz je z wyprzedzeniem, daj znać, gdy się zaczynają i kończą.
Kanały
Strona statusu: zawsze, przy każdym incydencie, który dotyka klientów. To źródło prawdy, do którego linkują pozostałe kanały.
Powiadomienia dla subskrybentów: powiadomienia e-mail i na czacie ze strony statusu, żeby klienci nie musieli jej ciągle odświeżać.
Baner w aplikacji: przy poważnych incydentach, jeśli Twój produkt go ma.
Bezpośredni e-mail: przy poważnych incydentach, które dotknęły kluczowych klientów, oraz na podsumowanie po incydencie.
Media społecznościowe: przy poważnych incydentach, z linkiem do strony statusu, a nie z osobną wersją wydarzeń.
Zobowiązania
Pierwsza aktualizacja w ciągu 15 minut od dowiedzenia się o problemie, który dotyka klientów.
Każda aktualizacja mówi, kiedy pojawi się następna.
Każdy incydent kończy się komunikatem o rozwiązaniu.
Po poważnych incydentach w ciągu pięciu dni roboczych publikujemy krótkie pisemne podsumowanie.
Co zawiera dobra aktualizacja
Każda aktualizacja, na każdym etapie, odpowiada na cztery pytania w tej kolejności:
Czego dotyczy problem – słowami, których używają klienci: „składanie zamówień”, „aplikacja mobilna”, „logowanie”, a nie wewnętrzna nazwa usługi.
Co zauważają: błędy, spowolnienie, brakujące e-maile.
Co mogą zrobić, jeśli w ogóle coś: obejście problemu albo „nie musisz nic robić”.
Kiedy usłyszą więcej.
Czego unikać: domysłów co do przyczyny, wewnętrznych nazw i żargonu, zrzucania winy na konkretnego dostawcę lub współpracownika oraz obietnic dotyczących czasu naprawy, jeśli nie masz pewności. „Spodziewamy się rozwiązać problem w ciągu 30 minut” to obietnica, z której klienci Cię rozliczą.
Szablony na każdy etap
Zastąp fragmenty w nawiasach. Zachowaj prosty i spokojny ton.
Badamy problem
Badamy zgłoszenia dotyczące [błędów / wolnego ładowania], gdy [klienci próbują złożyć zamówienie]. [Pozostałe części serwisu działają normalnie.] Kolejną aktualizację opublikujemy w ciągu [30 minut].
Przyczyna ustalona
Ustaliliśmy przyczynę: [problem u naszego operatora płatności / błędna aktualizacja wdrożona o 14:05]. [Płatności kartą nie przechodzą; faktury i Swish działają bez zakłóceń.] [Wycofujemy aktualizację / Współpracujemy z operatorem] i opublikujemy kolejną aktualizację w ciągu [30 minut].
Monitorujemy
Wdrożyliśmy poprawkę i [składanie zamówień] znów działa. Monitorujemy sytuację, aby upewnić się, że pozostaje stabilna. [Zamówienia złożone między 14:05 a 14:40 mogą mieć status oczekujących; zostaną przetworzone automatycznie.] Kolejna aktualizacja w ciągu [godziny] lub wcześniej, jeśli coś się zmieni.
Rozwiązany
Incydent został rozwiązany. Między [14:05 a 14:40 CET] [płatności kartą przy składaniu zamówienia nie przechodziły u większości klientów]. [Przyczyną była błędna aktualizacja, którą wycofaliśmy.] [Dodajemy kontrolę, która zatrzyma tego typu błąd, zanim wydanie trafi do klientów.] Przepraszamy za utrudnienia.
Na razie bez zmian
Nadal pracujemy nad [błędami przy składaniu zamówień]. Od ostatniej aktualizacji nic się nie zmieniło. Kolejna aktualizacja w ciągu [30 minut].
Ten ostatni komunikat jest ważniejszy, niż się wydaje. Strona statusu, która od godziny się nie zmieniła, sprawia, że klienci myślą, że nikt nad tym nie pracuje.
E-mail do klientów, których dotknął problem
Przy poważnych incydentach, które uderzyły w kluczowych klientów, krótki e-mail po incydencie jest wart więcej niż jakakolwiek strona statusu. Wyślij go od konkretnej osoby, a nie z adresu no-reply.
Temat: W sprawie dzisiejszej awarii składania zamówień
Dzień dobry [imię], dziś między 14:05 a 14:40 płatności kartą przy składaniu zamówienia nie przechodziły u większości naszych klientów, również u Ciebie. Przyczyną była błędna aktualizacja po naszej stronie, którą wycofaliśmy. [Zamówienia złożone przez Ciebie w tym czasie zostały już przetworzone.] [Dodajemy automatyczną kontrolę, która zatrzyma tego typu wydanie.] Jeśli zauważyłeś coś, co nie zgadza się z tym opisem, odpowiedz na tę wiadomość, a osobiście się tym zajmę. [Imię i nazwisko, stanowisko]
Media społecznościowe
Pisz krótko i odsyłaj po szczegóły na stronę statusu:
Widzimy błędy przy składaniu zamówień i pracujemy nad nimi. Aktualizacje tutaj: [link do strony statusu]
Składanie zamówień znów działa. Dziękujemy za cierpliwość i przepraszamy za kłopot. Podsumowanie: [link do strony statusu]
Po incydencie
Po poważnych incydentach w ciągu kilku dni opublikuj krótkie podsumowanie na stronie statusu lub wyślij je e-mailem: co się stało, jak długo trwało, kogo dotyczyło, co było przyczyną i co zmieniasz. Nasz szablon postmortemu omawia wewnętrzną analizę, która ma miejsce najpierw, oraz to, jak przerobić ją na wersję dla klientów.
Potem przyjrzyj się samej komunikacji. Ile trwało opublikowanie pierwszej aktualizacji? Czy dotrzymano obiecanych terminów aktualizacji? Czy do wsparcia trafiały pytania, na które powinny były odpowiedzieć komunikaty? Popraw plan, nie tylko system.
Niech trzymanie się planu będzie łatwe
Plan działa tylko wtedy, gdy łatwiej go stosować, niż zignorować. Kilka rzeczy robi tu różnicę:
Dowiaduj się przed klientami. Uptimecheck sprawdza Twoje strony i API nawet co minutę ze Sztokholmu, Londynu i Nowego Jorku, potwierdza każdą awarię z drugiej lokalizacji i powiadamia osobę na dyżurze, więc 15-minutowe odliczanie zaczyna się w chwili, gdy zaczyna się problem, a nie gdy wpływa pierwsze zgłoszenie do wsparcia.
Szablony gotowe w narzędziu. Strony statusu Uptimecheck podsuwają gotowy pierwszy szkic na każdy etap (investigating, identified, monitoring, resolved) w języku strony oraz Twoje własne zapisane szablony, w których {components} wstawia komponenty, których dotyczy problem.
Powiadamiaj właściwe osoby. Subskrybenci obserwują całą stronę albo tylko używane przez siebie komponenty – przez e-mail, Slack, Microsoft Teams, Discord lub webhook – a powiadomienie dostają tylko ci, którzy obserwują komponenty objęte problemem.
Zapowiadaj konserwację z wyprzedzeniem. Zaplanowana konserwacja pojawia się na stronie i trafia e-mailem do subskrybentów, zanim się zacznie.
Nasz poradnik o tworzeniu strony statusu, której ufają klienci opisuje, co umieścić na samej stronie.
Checklista
Z wyprzedzeniem wyznacz lidera incydentu, osobę od komunikacji i osoby ze wsparcia.
Ustalcie trzy poziomy ważności i częstotliwość aktualizacji dla każdego z nich.
Traktuj stronę statusu jako źródło prawdy; pozostałe kanały do niej linkują.
Opublikuj pierwszą aktualizację w ciągu 15 minut, nawet jeśli wiesz tylko tyle, że badasz problem.
Odpowiedz, czego dotyczy problem, co zauważają klienci, co mogą zrobić i kiedy usłyszą więcej.
Podaj godzinę następnej aktualizacji i dotrzymaj jej.
Zamykaj każdy incydent komunikatem o rozwiązaniu.
Po poważnych incydentach wyślij krótkie podsumowanie i przeanalizuj nie tylko naprawę, ale i komunikację.