Czy Twój zespół inżynierów odczuwa zmęczenie alertem? Zadaj te 8 pytań

Zmęczenie alarmowe jest częstym problemem wśród zespołów inżynierskich, które obsługują operacje i utrzymują infrastrukturę.

Problem zwykle wynika z przypadkowego podejścia do pisania alertów w miarę rozwoju zespołów i korzystania z coraz większej infrastruktury o coraz większej złożoności. Jest to całkiem normalne – wraz ze wzrostem firmy lub zespołu często potrzeba czasu, aby ukształtowała się kultura obserwowalności i solidne praktyki ostrzegania.

Łatwo jest tworzyć alerty, które są zbyt czułe, zbyt hałaśliwe i zbyt ostrożne. Na początku wszystko wydaje się być godne uwagi, ponieważ lepiej być ostrożnym i maksymalizować sygnał produkcyjny na wczesnych etapach produktu.

„Wraz z rosnącą liczbą i złożonością funkcji i infrastruktury ulepszanie alertów jest zwykle spychane na dół listy priorytetów”

Oczywiście to podejście nie jest skalowalne zbyt dobrze, ale wraz ze wzrostem liczby i złożoności funkcji i infrastruktury, ulepszanie alertów jest zwykle znacznie niższe na liście priorytetów. Rezultatem jest wiele na wpół znaczących alertów, szumów, przełączania kontekstu i wielozadaniowości dla inżyniera dyżurującego. W skrajnych przypadkach członkowie zespołu wypalają się, alerty są ignorowane, a Twój zespół dyżurny przechodzi od poprawy jakości usług do ciągłego gaszenia pożarów bez znaczącego wpływu.

Jak wszystkie firmy, Intercom nie jest odporny na te nieefektywności. Dlatego opracowaliśmy stosunkowo lekki proces walki ze zmęczeniem czujności.

Jak myślimy o strategii ostrzegania

Pojęcie „dyscypliny alertów” jest podstawą kontrolowania alertów. Podobnie jak praca nad funkcjami, do alertów i strategii ostrzegania należy podchodzić w sposób przemyślany, ustrukturyzowany. Jednak w przeciwieństwie do pracy nad funkcjami nie jest to coś, co można dobrze zaplanować z wyprzedzeniem.

W końcu jest bardzo mało prawdopodobne, że będziesz w stanie przewidzieć stan operacyjny i hałas nowej funkcji przed jej wysłaniem. Musisz monitorować alerty w regularny, zaplanowany sposób, aby trud ostrzegania nie wkradł się do niezrównoważonych poziomów.

8 pytań, które należy zadać podczas oceny alertów zespołu

Wprowadziliśmy regularne sesje przeglądu alertów dla zespołów zajmujących się częstymi alertami. Początkowo miały one miejsce raz – lub wiele razy – w ciągu sześciotygodniowego cyklu inżynieryjnego, ale stały się bardziej rozproszone, gdy stan alertów i monitorów poprawił się do bardziej łatwego do opanowania poziomu.

Każda sesja przeglądu alertów rozpoczyna się od uporządkowanej listy alertów, które zostały uruchomione w poprzednim okresie, uporządkowanej według częstotliwości ich uruchamiania. Korzystamy z platformy PagerDuty jako źródła alertów, a jej funkcje analityczne dostarczają nam informacji potrzebnych do określenia częstotliwości alertów i reakcji. Alerty, które mają największy udział w ogólnym hałasie (tj. najczęściej pożary), są przeglądane w pierwszej kolejności.

Każdy alert przechodzi następnie przez listę kontrolną pytań:

1. Czy ostrzeżenie jest nadal aktualne?

Wszelkie alerty wywołane przez przestarzałe lub niekonserwowane systemy nie powinny przeszkadzać dyżurnemu inżynierowi i należy je natychmiast usunąć.

2. Czy ostrzeżenie jest wykonalne?

Jeśli inżynier dyżurny otrzyma alert, czy może zrobić coś w tej chwili, aby naprawić lub poprawić przyczynę? Jeśli alert nie jest praktyczny i użyteczny, należy go usunąć. Cotygodniowe podsumowanie problemów lub pogorszenia wydajności może być lepszym miejscem na informacje zawarte w alercie.

3. Czy informacje zawarte w ostrzeżeniu są natychmiast przydatne, nawet jeśli nie są możliwe do podjęcia działań?

Informacje alarmowe możemy podzielić na dwie szerokie kategorie.

• Sygnały: te alerty ostrzegają, że system działa na swoim limicie, ale nie musi oznaczać, że ma to wpływ na usługę. Przykładem może być jeden z twoich serwerów pracujących na 100% CPU. Jeśli usługa nadal działa dobrze, czy dyżur powinien poświęcić cenny czas na dochodzenie? W końcu Twój serwer działa wtedy z najlepszym stosunkiem pracy do kosztów!
• Objawy: Te alerty są uruchamiane, gdy ma to wpływ na obsługę klienta. Przykładem może być liczba błędów HTTP 5XX, które Twoja usługa zwraca do wywołujących.

Te dwie kategorie najlepiej sprawdzają się w tandemie. Osoba dyżurująca powinna reagować i rozwiązywać objawy, a sygnały traktować jedynie jako dodatkowe źródło informacji.

4. Jeśli alert jest możliwy do wykonania i jest stronicowany, czy należy się nim natychmiast zająć?

Jeśli problem nie wymaga natychmiastowego rozwiązania, nie powinien nikogo budzić w środku nocy. Zespół powinien zdecydować się na alternatywne sposoby ujawnienia informacji w alercie w takich sytuacjach, na przykład powiadomienie o Slacku lub na desce rozdzielczej lub otwarte zadanie w mechanizmie śledzenia problemów.

5. Jeśli jest możliwy do wykonania, czy istnieje element Runbook lub łącze do rozwiązywania problemów? Czy kroki są wystarczająco jasne, aby mógł je wykonać każdy inżynier w zespole?

Jednym z najgorszych doświadczeń bycia inżynierem dyżurnym – zwłaszcza nowym – jest ilość wiedzy plemiennej, która z biegiem czasu gromadzi się w zespołach inżynierskich. To onieśmielające wskoczyć do incydentu produkcyjnego o wysokiej wadze tylko po to, by zdać sobie sprawę, że nie znasz tego obszaru systemu i nie jest on dobrze udokumentowany.

„ Utrzymywanie przejrzystych, prostych i aktualnych informacji o rozwiązywaniu problemów z alertami znacznie ułatwia skrócenie średniego czasu na złagodzenie skutków incydentu i powrót do niego ”

Nawet jeśli masz doświadczenie, być może napisałeś kod tak dawno temu, że nie pamiętasz dokładnie, co powinien robić. Utrzymywanie przejrzystych, prostych i aktualnych informacji o rozwiązywaniu problemów z alertami znacznie ułatwia skrócenie średniego czasu na złagodzenie skutków incydentu i powrót do niego (MTTM i MTTR).

6. Jeśli można podjąć działania, czy istnieje link do pulpitu nawigacyjnego i czy pokazuje wszystkie znane potencjalne przyczyny?

Pulpity nawigacyjne to świetny sposób na jednoczesne wyświetlanie dużych ilości informacji systemowych, co oznacza, że ​​inżynierowie nie muszą zagłębiać się w różne dzienniki, metryki i ślady, aby znaleźć przyczynę problemu. Agregacja danych w dashboard i udostępnienie linku w ramach alertu pozwala na znacznie szybsze rozwiązywanie problemów.

7. Czy alert jest zbyt wrażliwy lub niewystarczająco szczegółowy? Czy skorzystałby na odczulaniu lub zmianie zakresu?

Wiele alertów jest przydatnych, ale źle skalibrowanych. Mogą być albo zbyt szerokie i nie strzelać za każdym razem, kiedy powinny, albo zbyt konkretne i strzelać kilka razy w przypadku tego samego incydentu, co tylko zwiększa hałas.

8. Wreszcie, czy człowiek musi dokonać remediacji?

W pewnym sensie cały kod komputerowy automatyzuje coś, co może zrobić człowiek. Dlaczego więc nie zautomatyzować naprawy problemów wywołujących alerty? Podczas gdy niektóre bardziej uciążliwe alerty, takie jak błąd w kodzie lub problem z wydajnością w systemie, byłyby trudne do naprawienia automatycznie, zautomatyzowane działania mogą rozwiązać wiele typowych problemów.

Jest to szczególnie ważne, jeśli korzystasz z platformy chmurowej, takiej jak AWS, i możesz udostępniać infrastrukturę bez martwienia się o dodatkowy sprzęt. Na przykład, jeśli węzeł w klastrze wyszukiwania wyświetla uszkodzone dyski, dlaczego nie zastąpić go automatycznie? Jeśli usługa ma mało zasobów obliczeniowych z powodu wzrostu ruchu, dlaczego nie skalować i nie dodawać dodatkowych maszyn wirtualnych lub kontenerów? Szczegółowe informacje o środkach zaradczych można następnie przesłać zespołowi za pośrednictwem kanałów bez generowania alertów, aby mogli przejrzeć je w wolnym czasie.

Czy odpowiedziałeś „nie” na którekolwiek z tych pytań?

Odpowiedź „nie” na którekolwiek z tych pytań powoduje, że zespół ma zadanie o wysokim priorytecie, aby popracować nad ulepszeniem alertu – niezależnie od tego, czy oznacza to zatrzymanie go przed stronicowaniem, usprawnienie kroków rozwiązywania problemów, zautomatyzowanie go, czy po prostu naprawienie podstawowego problemu systemowego.

Sednem tego podejścia jest robienie tego w regularny i zaplanowany sposób. Dzięki temu poziom hałasu jest niski, a Twoi operatorzy i inżynierowie dyżurni są zadowoleni i wydajni. Mogą skupić się na poprawie jakości i wywieraniu wpływu zamiast na gaszenie pożarów.

Czy interesuje Cię sposób, w jaki pracujemy w Intercomie? Chętnie z Tobą porozmawiamy – sprawdź nasze otwarte role inżynierskie.