Метод на CASE: хуманен мониторинг

Дзииииииинь! На часовника е 3 часа сутринта, вие гледате чудесен сън и изведнъж — звънене. Тази седмица дежурите и очевидно нещо се е случило. Автоматизирана система призовава да разберете какво става. Това е важен момент в управлението на съвременните компютърни системи, но нека видим как да направим уведомленията по-удобни за хората.

Запознайте се с философията на мониторинга, която се роди в продължение на няколко десетилетия дежурства в различни мониторинг екипи. Тя беше значително повлияна от истинската библия на Роб Еващук. My Philosophy on Alerting (Моя философия на уведомленията), включена в книгата по Google SRE, и книгата на Джон Олспо Considerations for Alert Design (Замисли по проектиране на уведомления).

Кели Дън, Ариджит Мукхери и Максим Петаццони — благодаря за помощта в редактиране на публикацията.

Какво е CASE?

Реших да измисля красиво съкращение, както при метода USE на Брендан Грегг или метода RED на Том Уилки.Наричам го метод CASE. Той описва четири момента, на които трябва да обърнете внимание при работа с автоматичен мониторинг:

• Context-heavy (привързаност към контекста)
• Actionable (практическа стойност)
• Symptom-based (акцент на симптомите)
• Evaluated (оценка)

Ако използвате CASE, вие се отнасяте към уведомленията с известен здравословен хладнокръвие и не будите хората през нощта. Трябва редовно да оценявате мониторинга за полезност и ефективност. Когато човек получи уведомление, той ще има по-добри ментални модели и повече увереност.

За да запомните по-лесно, представете си, че ви е нужен CASE [тоест случай, причина — прим. на преводача], за да оправдаете всяко уведомление. :sunglasses:

И защо всичко това?

Дежурството може да бъде мъчително. По много причини. И CASE няма да премахне всички тях. Но с него през нощта ще се будите от по-качествени уведомления. Този метод обхваща различни организационни процеси, които също ще помогнат в това отношение.

Прелестта на методите RED и USE е, че с тях ние не само знаем как да работим, но и говорим на един и същ език. Надявам се, че с метода CASE ще бъде по-лесно да обсъждаме уведомленията, които защитават нашите системи, но не дават покой на колегите.

Същността е, че е нужно да създадем в организацията култура, в която уведомленията се възприемат с здравословен апатизъм. Уведомленията могат да се създават по важни въпроси, но не е факт, че по-късно те не губят стойност. Защо настроихме това уведомление? Отдавна ли бяха преразгледани критериите му? С CASE на тези въпроси можем да намерим отговори.

Context-Heavy — свързване с контекста

3 часа сутринта — нещо повече от невъзможен момент за четене на съобщения, в които има много умни думи. За да реагираме ефективно, ни е нужна информация. В идеалния случай това трябва да е информация за конкретен проблем, по който моментално да е ясен контекстът, и трябва да конфигурираме уведомленията така, че това да е възможно. Това е "наблюдение" и "ориентиране" от цикла НОРД. За тази настройка не е жалко да се отдели време, тъй като постоянното отвличане на вниманието на човек е още по-скъпо. Нека се уважаваме взаимно.

Проблемите имат много източници. Особено призраците.

Как да помогнем на дежурния? Първото, което дежурният вижда, е уведомлението, затова всички хипотези той изгражда на неговата основа. След това разглежда инструкциите и таблата за управление, но винаги ли там има данни за конкретното уведомление, а не просто обща информация? Олспо съветва "да мислим как можем да интерпретираме уведомлението или да реагираме на него" (слайд 29)1. Добро уведомление е ориентирано към дежурния, а не просто настроено на прагово значение.

Ето затова идеи как да подобрим контекста на уведомленията:

• Покажете на потребителя нещо полезно и специално създадено, а не просто обикновени инструкции или табла за управление. По-рано ние с колегите използвахме табла за управление за разследвания, настроени на конкретни уведомления. Това ще помогне, ако проблемът е известен, а в други случаи само ще обърка. Тук трябва да намерим баланс.
• Разкажете за историята на уведомлението: ново ли е? Често ли сработва? Сезонно ли е?
• Покажете последните промени в състоянието на системата. Нещо променено наскоро? (Например, деплой или включване/изключване на функционалност.)
• Покажете зависимости и дайте информация за менталната модели: зависимостите на системата трябва да са ясни, желателно с указание за работоспособността.
• Бързо свържете потребителя с екипа: вижда ли текущите инциденти или може ли да разбере, кой друг в компанията е получил уведомлението? Програмата управление на инцидентите активирана?

В идеал сценарият за управление на инциденти предоставя съвети как да подобрите контекста на уведомлението при разследване на инциденти. Винаги има какво да се подобри!

Действаща — практическа стойност

Служителят по дежурство трябва ли да предприеме нещо в отговор на уведомлението? Ако няма какво да се направи или не е ясно какво да се прави, защо будите хората? Трябва да се избягват уведомления, които дразнят служителите по дежурство и не изискват действия.

View post on imgur.com

Какво да правим? Какво е нужно?

По-рано, когато системите бяха прости, а екипите малки, настройвахме мониторинга просто за да сме в течение. Уведомление, че натоварването в клъстера е нараснало, ще ни даде контекст, ако после услугата работи с проблеми. На голямо ниво такива уведомления само ще объркат, тъй като нашите системи винаги работят в състояние на различна степен на деградация. Това бързо води до умора от уведомления и, разбира се, до загуба на чувствителност. Затова служителят по дежурство игнорира или дори филтрира такива уведомления и не винаги реагира на тях както трябва. Не попадайте в тази капан! Не настройвайте всички уведомления, само за да ги изпратите по имейл в някаква забравена папка.

Ето как изглежда уведомлението с практическа стойност:

• Уведомлението изисква действие, а не просто съобщава новини.
• Това действие е трудно или рисковано за автоматизация. Ако действието може да бъде автоматизирано, просто го автоматизирайте, стига с натоварването на хората!
• Уведомлението съдържа спешни препоръки под формата на споразумение за ниво на обслужване (SLA) или целево време за възстановяване (RTO). Тогава служителят по дежурство може да задейства програмата за управление на инциденти в организацията.

Искам да уточня: не казвам, че уведомленията трябва да идват само по най-важните SLO (цели за ниво на обслужване) за API. Мониторингът на SLO постоянно се разбива и дели и изисква единен подход към всички услуги. Ясно е, че ще следите най-важните SLO за клиентите, които ви плащат. Но SLO за инфраструктурата, например бази данни, също трябва да се следят. Скоро ще трябва да се занимавате с вътрешни клиенти и да ги поддържате. И така до безкрайност.

Симптоматично — акцент върху симптомите

Харесва ли ви или не, но работите в разпределена система (Кавадж)2. В резултат на това използвате различни тактики, за да изолирате услугите и да ги защитите от сривове (Трейнор и др.). И въпреки че продължителното garbage collection или забавен запит към базата данни указывают на проблеми, не трябва бързо да ги отстранявате, ако потребителите нямат проблеми в близко време.

Това са важни сигнали и те могат да имат практическа стойност, но ако не пречат на потребителите, не е толкова спешно, че да отвлекат дежурния. Уведомленията на базата на причина са снимки на нашите ментални модели за системен срив. По-добре е да следите важни симптоми, отколкото да се опитвате да изброите всички възможни причини за срив.

За да имат уведомленията практическа стойност, фокусирайте се на индикаторите за производителност, важни за потребителите. Евщук го нарича "мониторинг за потребителите". Помнете, че тази философия трябва да се прилага в цялата организация. Ако в услугата възникнат спешни проблеми дълбоко в инфраструктурата, съответният екип ще се заеме с тях. Защитата на системите от такива сривове е съвсем друг въпрос (Трейнер и др., раздел за стратегии за минимизиране на критични зависимости)3.

Симптомите не са толкова променливи

Ричард Кук напомня, че в сложните системи има множество недостатъци, дефекти и проблеми.4. Опитването да се изброят всички възможни причини е Сизифов труд. Опитвате се да опишете проблеми, а те постоянно се променят. Синди Шридхараан смята, че "системите не е необходимо всяка секунда да се намират в идеално състояние" и е по-добре да се използва по-човешки подход ("Distributed Systems Observability" ("Наблюдение на разпределените системи"), 7)5.

Избягвайте уведомления за инциденти

Обикновено за коригиране на инциденти се настроят уведомления за причините. И тези ограничени уведомления за факта, че нещо се е случило, създават фалшиво чувство на сигурност, тъй като системата всеки път измисля нови начини да се провали.

Не се заблуждавайте с уведомления за причините. По-добре е да помислите:

• Защо уведомлението, основано на симптомите, не забеляза проблема?
• Ще бъде ли полезно да се подобри контекстът за потребителя?
• Как да подобрим инструментите за мониторинг, за да поставяме диагностика по-бързо, а не да натрупваме известия за случилото се?

Инструментите за мониторинг за диагностика ще помогнат само ако ги възприемате като начин да преминете от симптома към решението. Без тази обратна връзка просто ще бъдете затрупани с закъснели известия и диаграми за минали повреди — и нищо за бъдещето. Това е отлична възможност за организацията да премине от защита в атака. А разработчиците и продуктови мениджъри ще имат еднакви очаквания и ясни цели. Случаят — CASE (:wink:) — е ясен за всяко известие.

Известията, основани на причина, са приемливи в умерени количества.

Понякога нашата система почти не ни оставя избор относно известията, основани на причина. А понякога дежурните наистина разбират, че симптомът непременно ще доведе до срив, а следователно има практическа стойност. Може би просто не сте сигурни какво се случва и настройвате известията за подсигуряване. Да се надяваме, че това действие е временно, докато не променим системата, за да се справим с проблема с производителността.
Помнете другите компоненти на CASE, когато се справяте с такива ситуации. Ако е временно, не означава, че можете да не мислите разумно.

Evaluated — оценка

Всяка промяна в системата (нов код, нова инфраструктура, каквото и да е ново) увеличава разнообразието от сривове (Кук, 3).4 Това известие все още ли работи, както се очаква? Ясните и актуални ментални модели на системите и опитът в отговора на някои известия в подкрепа на профилактичния подход — са ключови характеристики на организация, ориентирана към обучение.Дефектите в системите постоянно се развиват и ние трябва да настигнем.

Необходимо е постоянно да оценявате качеството на всяко известие, за да работят както очаквате. Уважаеми ръководители! Вашите екипи ще имат много по-лесна задача, ако им помогнете да установят този процес! Ето няколко идеи за оценка:

• Използвайте хаос-инженеринг, игрови дни или други методи за тестване на известията. Екипът може да направи това сам, без да използва тежка система за управление на инциденти!
• Включете събирането на данни за всички известия, свързани с инциденти, в програмата за управление на инциденти. Отбелязвайте полезни, вредни, неуместни, неясни и т.н. Използвайте ги като обратна връзка.
• Правилните известия сработват рядко и са внимателно проверени. Уверете се, че всички линкове работят и насочват към правилния контекст и т.н.
• Ако известие никога не сработва или сработва твърде често, нещо не е наред. Поправете го или го изтрийте. Внимавайте с твърде много пасивност или активност!
• Настройте срок на годност за метките на известията. Ако срокът е изтекъл, оценете известието по метода CASE и обновете срока. Редовно проверявайте срока, както при храните.
• Определете процеса за подобряване на известията. Използвайте мониторинг в код и съхранявайте известията в Git хранилище. Pull заявки помагат да ангажирате екипа, а вие ще имате история на предишните известия. И вече няма да се страхувате да променяте известия или да питате разрешение от тези, които са отговорни за тях.
• Създавайте обратна връзка за известията, дори и да е просто Google форма, за да могат дежурните да отбелязват известията като безполезни или натрапчиви. Вградете в самото известие линк или призив за действие и редовно преглеждайте обратната връзка.
• Установете правило в екипа — нека дежурните работят за опростяване на дежурствата, когато имат малко работа. Нека след вас всичко да стане малко по-добро, отколкото е било преди.

Заключение

Смятам, че методът CASE помага на разработчиците и организациите да обсъждат настройването и изпращането на автоматични известия. Един разработчик може да започне да оценява известията по метода CASE, а след това цялата организация с други разработчици, ръководството и програмите за управление на инциденти да се присъедини, за да поддържа известията в добро състояние. За това не са необходими никакви специални инструменти или сложни процеси.

Цялата индустрия трябва да се замисли за човешкия фактор по време на дежурство, без да се компрометира първокласното обслужване на клиентите. Всички тези инструменти и практики могат и трябва да бъдат подобрени. Надявам се, че методът CASE ще помогне в това.

Наслаждавайте се на подобрените известия!

Източник: habr.com