Dziiiing! Jest 3 nad ranem, śnisz piękny sen, a nagle - dzwonek. W tym tygodniu masz dyżur i coś najwyraźniej się wydarzyło. Zautomatyzowany system wzywa do ustalenia, co się stało. To ważny moment w zarządzaniu nowoczesnymi systemami komputerowymi, ale przyjrzyjmy się, jak można uczynić powiadomienia bardziej przyjaznymi dla ludzi.
Poznaj filozofię monitorowania, która narodziła się podczas kilku dziesięcioleci moich dyżurów w różnych zespołach monitorujących. Znacząco wpłynęła na nią prawdziwa biblia od Roba Ewaschuka. (Moja filozofia powiadomień), zawarta w książce o , oraz książka Johna Olspo (Uwagi dotyczące ustawiania powiadomień).
, i — dziękuję za pomoc w redakcji postu.
Czym jest CASE?
Postanowiłem wymyślić ładny akronim, jak w przypadku lub Nazywam to metodą CASE.Opisuje ona cztery kwestie, na które należy zwrócić uwagę przy pracy z automatycznym monitorowaniem:
- (przywiązanie do kontekstu)
- (praktyczna wartość)
- (akcent na symptomy)
- (ocena)
Kiedy stosujesz CASE, podchodzisz do powiadomień z określoną dawką zdrowego sceptycyzmu i nie budzisz ludzi w nocy. Należy regularnie oceniać monitorowanie pod kątem użyteczności i efektywności. Gdy człowiek otrzyma powiadomienie, będzie miał lepsze modele mentalne i większą pewność siebie.
Aby łatwiej to zapamiętać, wyobraź sobie, że potrzebujesz CASE [czyli powodu – przyp. tłumacza] do uzasadnienia każdego powiadomienia. :sunglasses:
I po co to wszystko?
. Z wielu powodów. I CASE nie usunie ich wszystkich. Ale z nim w nocy będziesz budzić się po lepszych powiadomieniach. Ta metoda obejmuje różne procesy organizacyjne, które również mogą w tym pomóc.
Urok metod RED i USE polega na tym, że dzięki nim nie tylko wiemy, jak pracować, ale także komunikujemy się nawzajem w zrozumiałym języku. Mam nadzieję, że z metodą CASE łatwiej będzie omawiać powiadomienia, które chronią nasze systemy, ale nie dają spokoju kolegom.
Istotą sprawy jest stworzenie w organizacji takiej kultury, w której do powiadomień podchodzi się ze zdrowym dystansem. Powiadomienia mogą być tworzone z uzasadnieniem, ale nie ma pewności, że później nie stracą na wartości. Dlaczego skonfigurowaliśmy to powiadomienie? Czy jego kryteria były niedawno przeglądane? Z pomocą CASE można znaleźć odpowiedzi na te pytania.
Context-Heavy — związane z kontekstem
Trzecia rano — to nie jest najlepszy czas na czytanie wiadomości, w których jest wiele mądrych słów. Aby skutecznie zareagować, potrzebne są informacje. W idealnym przypadku powinny to być informacje o konkretnej problemie, przy którym kontekst jest oczywisty, i powiadomienia powinny być skonfigurowane tak, aby to było możliwe. To «obserwacja» i «orientacja» z Na tę konfigurację warto poświęcić czas, ponieważ ciągłe rozpraszanie ludzi jest jeszcze droższe. Szanujmy się nawzajem.
Problemy mają wiele źródeł. Szczególnie ponure.
Jak pomóc dyżurnemu? Przede wszystkim dyżurny widzi powiadomienie, dlatego wszystkie hipotezy opiera na jego podstawie. Potem przegląda instrukcje i pulpit nawigacyjny, ale czy zawsze są tam dane dotyczące konkretnego powiadomienia, a nie tylko ogólne informacje? Olspo doradza „myśleć, jak można zinterpretować powiadomienie lub na nie zareagować” (slajd 29). Dobre powiadomienie jest skierowane do dyżurnego, a nie tylko skonfigurowane na podstawie wartości progowej.
Dlatego oto pomysły na poprawę kontekstu powiadomień:
- Pokaż użytkownikowi coś użytecznego i stworzonego specjalnie, a nie tylko standardowe instrukcje lub pulpit nawigacyjny. Kiedyś z kolegami używaliśmy pulpitów do śledzenia, dostosowanych do konkretnych powiadomień. To pomoże, jeśli problem jest znany, a w innych przypadkach tylko wprowadzi w zakłopotanie. Tu trzeba znaleźć równowagę.
- Opowiedz o historii powiadomienia: jest nowe? Często się pojawia? Jest sezonowe?
- Pokaż ostatnie zmiany w stanie systemu. Czy ostatnio coś się zmieniło? (Na przykład wdrożenie lub włączenie/wyłączenie funkcjonalności.)
- Pokaż relacje i dostarcz informacje do modelu mentalnego: zależności systemu powinny być wyraźnie widoczne, najlepiej z oznaczeniem ich funkcjonalności.
- Szybko skontaktuj użytkownika z zespołem: czy widzi bieżące incydenty, czy może dowiedzieć się, kto jeszcze w firmie otrzymał powiadomienie? Program Aktywowane?
Idealnie, program zarządzania incydentami daje wskazówki, jak poprawić kontekst powiadomień podczas badania incydentów. Zawsze jest coś do zrobienia!
Actionable — praktyczna wartość
Czy dyżurny powinien coś zrobić w odpowiedzi na powiadomienie? Jeśli nie ma potrzeby działania lub nie wiadomo, co robić, po co budzić? Należy unikać powiadomień, które irytują dyżurnych i nie wymagają działań.
Co robić? Czego potrzeba?
Kiedyś, gdy systemy były proste, a zespoły małe, ustawialiśmy monitoring, aby po prostu być na bieżąco. Powiadomienie o wzroście obciążenia doprowadzi nas do kontekstu, jeśli później usługa zacznie mieć problemy. W dużej skali takie powiadomienia tylko wprowadzają w błąd, ponieważ nasze systemy zawsze działają w stanie degradacji różnej intensywności. To szybko prowadzi do i oczywiście do utraty wrażliwości. Dlatego dyżurny ignoruje lub nawet filtruje takie powiadomienia i nie zawsze reaguje na nie, jak należy. Nie daj się wciągnąć w tę pułapkę! Nie ustawiaj wszystkich powiadomień bez wyjątku, aby później wysyłać je na e-mail do jakiegoś zapomnianego folderu.
Oto jak wygląda powiadomienie o praktycznej wartości:
- Powiadomienie wymaga działania, a nie tylko przekazuje wiadomości.
- To działanie jest trudne lub ryzykowne do zautomatyzowania. Jeśli można zautomatyzować działanie, po prostu to zróbcie, przestańcie zawracać ludziom głowę!
- Powiadomienie zawiera pilne zalecenia w postaci (SLA) lub (RTO). Wtedy dyżurny może zaangażować program zarządzania incydentami w organizacji.
Chcę wyjaśnić: nie mówię, że powiadomienia powinny przychodzić tylko w najważniejszych SLO (cele poziomu usług) dla API. Monitoring SLO stale się dzieli i wymaga jednolitego podejścia do wszystkich usług. Oczywiście będziesz śledzić najważniejsze SLO dla klientów, którzy płacą. Ale SLO infrastruktury, na przykład baz danych, również muszą być monitorowane. Niedługo będziesz musiał zająć się wewnętrznymi klientami i ich wspierać. I tak w nieskończoność.
Symptom-based — akcent na symptomy
Czy ci się to podoba, czy nie, pracujesz w rozproszonej systemie (Kawadz). W rezultacie stosujesz różne taktyki, aby izolować usługi i chronić je przed awariami (Treynor i in.)3. I chociaż przedłużające się zbieranie odpadów lub zablokowane zapytanie do bazy danych wskazują na problemy, nie należy się nimi zajmować, jeśli użytkownicy nie napotkają problemów w najbliższym czasie.
To ważne sygnały i mogą mieć praktyczną wartość, ale jeśli nie przeszkadzają użytkownikom, to nie są na tyle pilne, by odciągać uwagę dyżurnego. Powiadomienia oparte na przyczynach to migawki naszych mentalnych modeli dotyczących awarii systemu. Lepiej śledzić ważne objawy niż próbować wymienić wszystkie możliwe przyczyny awarii.
Aby powiadomienia miały praktyczną wartość, skoncentruj się na , które są istotne dla użytkowników. Jewaszczuk nazywa to „monitorowaniem dla użytkowników”. Pamiętaj, że tę filozofię trzeba stosować w całej organizacji. Jeśli w usłudze pojawią się pilne problemy w głębi infrastruktury, odpowiednia drużyna zajmie się nimi. Ochrona systemów przed takimi awariami to zupełnie inna kwestia (Treynor i in., rozdział o strategiach minimalizacji krytycznych zależności).
Objawy nie są tak zmienne
Richard Cook przypomina, że w złożonych systemach jest mnóstwo wad, niedociągnięć i problemów. Próba wymienienia wszystkich możliwych przyczyn to syzyfowa praca. Starasz się opisać problemy, a one ciągle się zmieniają. Cindy Shridharan uważa, że „systemy nie muszą być w doskonałym stanie każdego sekundy” i lepiej zastosować bardziej ludzki sposób ( („Nadzór nad systemami rozproszonymi”), 7).
Unikaj powiadomień o zdarzeniach
Zazwyczaj do naprawy incydentów ustawia się powiadomienia o przyczynach. I te ograniczone powiadomienia o zdarzeniu dają fałszywe poczucie pewności, ponieważ system za każdym razem wymyśla nowe sposoby na awarię.
Nie oszukuj się powiadomieniami o przyczynach. Lepiej pomyśl:
- Dlaczego powiadomienie oparte na symptomach nie zauważyło problemu?
- Czy poprawa kontekstu byłaby przydatna dla użytkownika?
- Jak poprawić narzędzia monitorowania, aby szybciej stawiać diagnozy, zamiast gromadzić powiadomienia o incydentach?
Narzędzia monitorowania w diagnostyce będą pomocne tylko wtedy, gdy potraktujesz je jako sposób na przejście od objawu do rozwiązania. Bez tej informacji zwrotnej po prostu zasypią cię spóźnionymi powiadomieniami i wykresami o przeszłych awariach — a ani słowa o przyszłych problemach. To doskonała okazja dla organizacji, aby przejść z obrony do ataku. A programiści i menedżerowie produktów będą mieli takie same oczekiwania i jasne cele. Sprawa — CASE (:wink:) — jest jasna dla każdego powiadomienia.
Powiadomienia oparte na przyczynach są akceptowalne w umiarkowanej ilości.
Czasami nasz system prawie nie pozostawia nam wyboru w zakresie powiadomień opartych na przyczynie. A czasami dyżurni doskonale rozumieją, że objaw koniecznie prowadzi do awarii, co oznacza, że ma praktyczną wartość. Może po prostu nie jesteś pewien, co się dzieje, i konfigurujesz powiadomienia na wszelki wypadek. Miejmy nadzieję, że ta akcja jest tymczasowa, dopóki nie poprawimy systemu, aby rozwiązać problem z wydajnością.
Pamiętaj o innych komponentach CASE, kiedy zajmujesz się takimi sytuacjami. To, że jest to tymczasowe, nie oznacza, że można się tym nie przejmować.
Evaluated — ocena
Jakiekolwiek zmiany w systemie (nowy kod, nowa infrastruktura, cokolwiek nowego) rozszerzają zakres awarii (Kuk, 3). Czy to powiadomienie wciąż działa zgodnie z oczekiwaniami? Jasne i aktualne modele mentalne systemów oraz doświadczenie w reagowaniu na niektóre powiadomienia wspierają — to kluczowe cechy . Wady w systemach nieustannie ewoluują i musimy za nimi nadążać.
Należy regularnie oceniać jakość każdego powiadomienia, aby działały zgodnie z oczekiwaniami. Szanowni liderzy! Waszym zespołom będzie znacznie łatwiej, jeśli pomożecie im ustalić ten proces! Oto kilka pomysłów na ocenę:
- Użyj , lub inne metody testowania powiadomień. Zespół może to zrobić samodzielnie, nie angażując ciężkiego systemu zarządzania incydentami!
- Włącz zbieranie danych o wszystkich powiadomieniach związanych z incydentami w programie zarządzania incydentami. Zaznaczaj te użyteczne, szkodliwe, nieodpowiednie, niezrozumiałe itp. Wykorzystaj je jako feedback.
- Odpowiednie powiadomienia rzadko się rozsyłają i są starannie weryfikowane. Upewnij się, że wszystkie linki działają, prowadzą do właściwego kontekstu itd.
- Jeśli powiadomienie nigdy nie działa lub działa zbyt często, coś jest nie tak. Napraw je lub usuń. Uważaj na nadmierną bierność lub aktywność!
- Ustaw dla powiadomień znaczniki czasowe z datą ważności. Jeśli data ważności minęła, oceń powiadomienie przy użyciu metody CASE i zaktualizuj znacznik czasowy. Regularnie sprawdzaj daty ważności, jak w przypadku jedzenia.
- Uprość proces poprawy powiadomień. Użyj monitorowania w kodzie i przechowuj powiadomienia w repozytorium Git. Pull requesty pomagają angażować zespół, a ty będziesz mieć historię przeszłych powiadomień. Nie będziesz obawiać się zmieniać powiadomień ani pytać o zgodę tych, którzy za nie odpowiadają.
- Zbieraj feedback dla powiadomień, nawet jeśli to tylko , aby dyżurni oznaczali powiadomienia jako bezużyteczne lub uciążliwe. Umieść w samym powiadomieniu link lub wezwanie do działania i regularnie przeglądaj feedback.
- Ustal w zespole zasadę — niech dyżurni pracują nad uproszczeniem dyżurów, gdy mają mało pracy. Niech po tobie wszystko stanie się trochę lepsze niż przedtem.
Podsumowanie
Uważam, że metoda CASE pomaga programistom i organizacjom dyskutować na temat konfiguracji i wysyłania automatycznych powiadomień. Jeden programista może rozpocząć ocenę powiadomień według metody CASE, a następnie dołączy do niego całe organizacje z innymi programistami, kierownictwem i programami zarządzania incydentami, aby utrzymać powiadomienia w dobrym stanie. Nie są potrzebne żadne szczególne narzędzia ani skomplikowane procesy.
Cała branża powinna zastanowić się nad czynnikiem ludzkim podczas dyżuru, nie rezygnując z najwyższej jakości obsługi klienta. Wszystkie te narzędzia i praktyki można i należy doskonalić. Mam nadzieję, że metoda CASE w tym pomoże.
Ciesz się udoskonalonymi powiadomieniami!
Źródło: habr.com
