Dziiiin! Jest 3 w nocy, masz cudowny sen i nagle ktoś dzwoni. W tym tygodniu jesteś na służbie i najwyraźniej coś się wydarzyło. Automatyczny system dzwoni, aby dowiedzieć się, co jest nie tak. Jest to ważny aspekt zarządzania nowoczesnymi systemami komputerowymi, ale przyjrzyjmy się, jak sprawić, by powiadomienia były lepsze dla ludzi.
Zapoznaj się z filozofią monitoringu, zrodzoną na przestrzeni kilkudziesięciu lat moich obowiązków w różnych zespołach monitorujących. Duży wpływ na nią miała prawdziwa Biblia Roba Evashchuka (Filozofia Mojego Powiadamiania) zawarta w książce pt i książka Johna Alspaugha (Uwagi dotyczące konfigurowania alertów).
, и — dziękuję za pomoc w edycji posta.
Co to jest PRZYPADEK?
Postanowiłem wymyślić piękny skrót typu lub . Nazywam to Metoda CASE. Opisuje cztery punkty, na które należy zwrócić uwagę podczas pracy z automatycznym monitorowaniem:
- (związany z kontekstem)
- (wartość praktyczna)
- (nacisk na objawy)
- (stopień)
Jeśli korzystasz z CASE, traktujesz powiadomienia ze zdrową obojętnością i nie budzisz ludzi w nocy. Monitorowanie powinno być regularnie oceniane pod kątem przydatności i skuteczności. Kiedy dana osoba otrzyma powiadomienie, będzie miała lepsze modele mentalne i większą pewność siebie.
Aby ułatwić zapamiętanie, wyobraź sobie, że potrzebujesz PRZYPADKU [czyli przypadku, powodu - notatka tłumacza], aby uzasadnić każdy alert. :okulary słoneczne:
I dlaczego to wszystko?
. Z wielu powodów. A CASE nie wyeliminuje ich wszystkich. Ale dzięki niemu obudzisz się w nocy z lepszymi powiadomieniami. Metoda ta obejmuje różne procesy organizacyjne, które również w tej kwestii pomogą.
Piękno metod RED i USE polega na tym, że przy ich pomocy nie tylko wiemy, jak pracować, ale także rozmawiamy ze sobą tym samym językiem. Mam nadzieję, że metoda CASE ułatwi omawianie powiadomień, które chronią nasze systemy, ale zajmą naszych kolegów.
Chodzi o to, że musisz stworzyć w swojej organizacji kulturę, w której powiadomienia będą traktowane ze zdrową obojętnością. Powiadomienia można tworzyć w konkretnym celu, ale nie jest faktem, że nie stracą później na wartości. Dlaczego skonfigurowaliśmy to powiadomienie? Jak dawno temu zmieniono jego kryteria? Dzięki CASE można odpowiedzieć na te pytania.
Kontekst-ciężki - wiązanie kontekstu
Trzecia w nocy nie jest najlepszą porą na czytanie wiadomości zawierających wiele mądrych słów. Aby skutecznie reagować, potrzebujesz informacji. Idealnie powinna to być informacja o konkretnej sprawie, dla której kontekst jest od razu jasny, a powiadomienia powinny być skonfigurowane tak, aby było to możliwe. To jest „obserwacja” i „orientacja”. . Nie jest wstydem spędzać czas na tej konfiguracji, ponieważ ciągłe odwracanie uwagi osoby jest jeszcze droższe. Szanujmy się nawzajem.
Problemy mają wiele źródeł. Zwłaszcza duchy.
Jak mogę pomóc oficerowi dyżurnemu? Pierwszą rzeczą, którą widzi dyżurny, jest powiadomienie, więc na jego podstawie buduje wszelkie hipotezy. Następnie przegląda instrukcje i dashboardy, ale czy zawsze znajdują się tam dane dotyczące konkretnego powiadomienia, a nie tylko informacje ogólne? Alspaugh radzi „zamyślić się, jak zinterpretować powiadomienie lub odpowiedzieć na nie” (slajd 29). Dobre powiadomienie skupia się na osobie dyżurującej, a nie tylko skonfigurowanej progiem.
Oto kilka pomysłów, jak ulepszyć kontekst powiadomień:
- Pokaż użytkownikowi coś przydatnego i specjalnie stworzonego, a nie zwykłą instrukcję czy dashboard. Wcześniej wraz z chłopakami korzystaliśmy z pulpitów śledczych skonfigurowanych pod kątem określonych powiadomień. Pomoże to, jeśli problem jest znany, ale tylko zdezorientuje innych. Musimy tu znaleźć równowagę.
- Opowiedz nam o historii powiadomienia: czy jest nowe? Czy to często działa? Czy ma to charakter sezonowy?
- Pokaż ostatnie zmiany stanu systemu. Czy coś się ostatnio zmieniło? (Na przykład wdrożenie lub włączenie/wyłączenie funkcji.)
- Pokaż zależności i podaj informacje dla modelu mentalnego: zależności systemowe powinny być wyraźnie widoczne, najlepiej ze wskazaniem funkcjonalności.
- Szybko połącz użytkownika z zespołem: czy może zobaczyć trwające incydenty lub dowiedzieć się, kto jeszcze w firmie otrzymał powiadomienie? Program aktywowany?
W idealnym przypadku program zarządzania incydentami będzie zawierał porady dotyczące ulepszenia kontekstu powiadamiania w ramach dochodzeń w sprawie incydentów. Zawsze jest nad czym pracować!
Możliwość działania – wartość praktyczna
Czy dyżurny powinien coś zrobić w odpowiedzi na zgłoszenie? Jeśli nie musisz nic robić lub nie jest jasne, co robić, dlaczego go obudziłeś? Należy unikać powiadomień, które denerwują dyżurujących i nie wymagają działania.
Co powinienem zrobić? Co chcesz?
W przeszłości, gdy systemy były proste, a zespoły małe, konfigurowaliśmy monitorowanie, aby być na bieżąco. Powiadomienie o wzroście obciążenia sterty da nam kontekst w przypadku późniejszego nieprawidłowego działania usługi. Na dużą skalę takie powiadomienia będą powodować jedynie zamieszanie, ponieważ nasze systemy zawsze działają w stanie degradacji o różnym nasileniu. To szybko prowadzi do i, oczywiście, do utraty wrażliwości. Dlatego dyżurny ignoruje lub wręcz filtruje takie powiadomienia i nie zawsze na nie reaguje w miarę potrzeb. Nie wpadnij w tę pułapkę! Nie konfiguruj wszystkich powiadomień z rzędu, a następnie wysyłaj je e-mailem do jakiegoś zapomnianego folderu.
Oto jak wygląda zawiadomienie mające wartość praktyczną:
- Powiadomienie wymaga działania, a nie zwykłego raportowania wiadomości.
- Zautomatyzowanie tej czynności jest trudne lub ryzykowne. Jeśli działanie można zautomatyzować, to zautomatyzuj je i przestań dręczyć ludzi!
- Ogłoszenie zawiera pilne zalecenia w formularzu (SLA) lub (RTO). Oficer dyżurny może następnie aktywować program zarządzania incydentami organizacji.
Chcę wyjaśnić: nie mówię, że powiadomienia powinny dotyczyć tylko najważniejszych SLO (celi poziomu usług) dla API. Monitoring SLO jest stale fragmentaryczny i podzielony i wymaga takiego samego podejścia do wszystkich usług. Oczywiste jest, że będziesz śledzić najważniejsze SLO dla klientów, którzy Ci płacą. Jednak obiekty SLO infrastruktury, takie jak bazy danych, również muszą być monitorowane. Już niedługo będziesz musiał zajmować się klientami wewnętrznymi i wspierać ich. I tak w nieskończoność.
Oparte na objawach – nacisk na objawy
Czy ci się to podoba, czy nie, pracujesz w systemie rozproszonym (Kavaj). W rezultacie stosuje się różne taktyki izolowania usług i ochrony ich przed awarią (Trainor i in.)3. I chociaż opóźnione usuwanie elementów bezużytecznych lub zatrzymanie zapytań do bazy danych wskazują na problemy, nie ma potrzeby spieszyć się z ich naprawą, jeśli użytkownicy nie będą mieli problemów w najbliższej przyszłości.
Są to ważne sygnały i mogą mieć wartość praktyczną, jeśli jednak nie przeszkadzają użytkownikom, to nie jest to na tyle pilne, aby odwrócić uwagę pracownika obsługi. Powiadomienia oparte na przyczynach to migawki naszych modeli mentalnych dotyczących awarii systemu. Lepiej jest śledzić ważne objawy, niż próbować wyliczać wszystkie możliwe przyczyny awarii.
Aby powiadomienia miały sens, skup się na , ważne dla użytkowników. Evashchuk nazywa to „monitorowaniem użytkowników”. Pamiętaj, że tę filozofię należy stosować w całej organizacji. Jeśli usługa ma pilne problemy gdzieś głęboko w infrastrukturze, odpowiedni zespół się nimi zajmie. Ochrona systemów przed takimi awariami to zupełnie osobna sprawa (Trainer i in., rozdział poświęcony strategiom minimalizacji krytycznych zależności).
Objawy nie są tak zmienne
Richard Cook przypomina nam, że złożone systemy są pełne wad, niedociągnięć i problemów. Próba wyliczenia wszystkich możliwych przyczyn jest zadaniem syzyfowym. Próbujesz opisać problemy, ale one cały czas się zmieniają. Cindy Sridharan uważa, że „systemy nie muszą być w idealnym stanie co sekundę” i lepiej zastosować bardziej ludzkie podejście ( („Monitorowanie systemów rozproszonych”), 7).
Unikaj powiadomień po zdarzeniu
Zazwyczaj powiadomienia o przyczynach są skonfigurowane tak, aby korygować zdarzenia. A te ograniczone powiadomienia o fakcie zdarzenia stwarzają fałszywe poczucie bezpieczeństwa, bo system za każdym razem wymyśla nowe sposoby na włamanie.
Nie daj się zwieść zawiadomieniom o przyczynie. Lepiej pomyśl:
- Dlaczego powiadomienie oparte na objawach nie zauważyło problemu?
- Czy pomocne byłoby ulepszenie kontekstu dla użytkownika?
- W jaki sposób można ulepszyć narzędzia monitorujące, aby szybciej stawiać diagnozę, zamiast gromadzić powiadomienia o tym, co się wydarzyło?
Narzędzia monitorujące do diagnozy pomogą tylko wtedy, gdy pomyślisz o nich jako o sposobie przejścia od objawu do rozwiązania. Bez tej informacji zwrotnej będziesz po prostu bombardowany spóźnionymi powiadomieniami i wykresami dotyczącymi przeszłych niepowodzeń – ani słowa o przyszłych. Jest to świetna okazja dla organizacji, aby przejść od obrony do ataku. A programiści i menedżerowie produktu będą mieli te same oczekiwania i jasne cele. Przypadek - CASE (:wink:) - jest jasny dla każdego powiadomienia.
Powiadomienia oparte na powodach są tolerowane z umiarem
Czasami nasz system nie pozostawia nam dużego wyboru w zakresie powiadomień opartych na przyczynie. A czasami dyżurujący doskonale rozumieją, że objaw na pewno doprowadzi do awarii, dlatego ma wartość praktyczną. Być może po prostu nie jesteś pewien, co się dzieje i konfigurujesz powiadomienia, aby zachować bezpieczeństwo. Mamy nadzieję, że to działanie ma charakter tymczasowy do czasu zmiany systemu w celu rozwiązania problemu z wydajnością.
Radząc sobie z takimi sytuacjami, należy pamiętać o pozostałych składnikach CASE. To, że jest to tymczasowe, nie oznacza, że możesz przestać myśleć głową.
Oceniony - ocena
Wszelkie zmiany w systemie (nowy kod, nowa infrastruktura, cokolwiek nowego) poszerzają zakres awarii (Cook, 3). Czy to powiadomienie nadal działa zgodnie z oczekiwaniami? Jasne i aktualne modele mentalne systemów i doświadczenie w reagowaniu na niektóre powiadomienia wsparcia - to są kluczowe cechy . Wady systemów stale się rozwijają i musimy za nimi nadążać.
Musisz stale oceniać jakość każdego powiadomienia, aby mieć pewność, że działa zgodnie z oczekiwaniami. Drodzy liderzy! Twoje zespoły będą dużo łatwiejsze, jeśli pomożesz im w przygotowaniu tego procesu! Oto kilka pomysłów na ocenę:
- Stosowanie , lub inne metody testowania powiadomień. Zespół może to zrobić sam, bez konieczności polegania na systemie zarządzania poważnymi incydentami!
- Włącz zbiór wszystkich powiadomień związanych z incydentami do swojego programu zarządzania incydentami. Oznacz jako przydatne, szkodliwe, nieodpowiednie, niejasne itp. Wykorzystaj je jako informację zwrotną.
- Właściwe powiadomienia są uruchamiane rzadko i są dokładnie testowane. Upewnij się, że wszystkie linki działają, wskazują właściwy kontekst itp.
- Jeśli powiadomienie nie uruchamia się nigdy lub uruchamia się zbyt często, coś jest z nim nie tak. Napraw to lub usuń. Uważaj na nadmierną bierność lub aktywność!
- Ustaw znaczniki czasu powiadomień z datami wygaśnięcia. Jeżeli data wygaśnięcia upłynęła, oceń powiadomienie metodą CASE i zaktualizuj znacznik czasu. Podobnie jak w przypadku żywności, regularnie sprawdzaj datę ważności.
- Uprość proces ulepszania powiadomień. Używaj monitorowania jako kodu i przechowuj powiadomienia w repozytorium Git. Żądania ściągnięcia pomagają zaangażować zespół i zapewniają historię wcześniejszych powiadomień. I nie będziesz już bać się zmieniać powiadomień ani prosić o pozwolenie osób za nie odpowiedzialnych.
- Skonfiguruj informacje zwrotne dla powiadomień, nawet jeśli jest to proste , aby funkcjonariusze dyżurni oznaczali powiadomienia jako bezużyteczne lub natrętne. Umieść link lub wezwanie do działania w samym powiadomieniu i regularnie przeglądaj swoje opinie.
- Ustal w zespole zasadę – pozwól dyżurującym popracować nad uproszczeniem obowiązków, gdy pracy jest mało. Oby wszystko po Tobie było trochę lepsze niż było wcześniej.
wniosek
Wierzę, że metoda CASE pomaga programistom i organizacjom omówić konfigurowanie i wysyłanie automatycznych powiadomień. Jeden programista może rozpocząć ocenę powiadomień metodą CASE, a następnie cała organizacja połączy się z innymi programistami, zarządem i programami zarządzania incydentami, aby utrzymać powiadomienia w dobrym stanie. Nie wymaga to żadnych specjalnych narzędzi ani skomplikowanych procesów.
Cała branża podczas pełnienia obowiązków musi myśleć o czynniku ludzkim, nie rezygnując przy tym z najwyższej jakości obsługi klienta. Wszystkie te narzędzia i praktyki można i należy udoskonalać. Mam nadzieję, że metoda CASE w tym pomoże.
Ciesz się lepszymi powiadomieniami!
Źródło: www.habr.com