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

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

Запознайте се с философията на мониторинга, родена в продължение на няколко десетилетия от моите задължения в различни екипи за мониторинг. Тя беше до голяма степен повлияна от истинската библия на Роб Евашчук Моята философия за предупреждение (Моята философия за уведомяване), включена в книгата за Google SREи книга от Джон Алспау Съображения за дизайн на предупреждение (Бележки за настройване на предупреждения).

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

Какво е CASE?

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

• Context-heavy (контекстно обвързан)
• Aподлежащ на действие (практическа стойност)
• Sбазирано на симптоми (акцент върху симптомите)
• Eценени (степен)

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

За да улесните запомнянето, представете си, че имате нужда от СЛУЧАЙ [тоест случай, причина - бележка на преводача], за да обоснове всеки сигнал. :слънчеви очила:

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

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

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

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

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

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

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

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

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

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

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

Действаем - практическа стойност

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

Вижте мненията на imgur.com

Какво трябва да направя? Какво искаш?

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

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

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

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

Симптомно базиран – акцент върху симптомите

Независимо дали ви харесва или не, вие работите в разпределена система (Kavaj)2. В резултат на това вие използвате различни тактики, за да изолирате услугите и да ги защитите от повреда (Trainor et al.)3. И въпреки че забавено събиране на боклук или блокирана заявка към база данни показва проблеми, няма нужда да бързате да ги коригирате, ако потребителите нямат проблеми в близко бъдеще.

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

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

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

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

Избягвайте известия след инцидент

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

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

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

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

Уведомленията, базирани на причина, са приемливи в умерени количества

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

Оценено – оценка

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

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

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

Заключение

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

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

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

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