Печалби:
- Способност за разбиране на жизнения цикъл на инцидент (откриване, триаж, смекчаване, разрешаване, следсмъртно), показатели MTTD/MTTR и принципа „първо смекчаване, разследване по-късно“
- Възможност за използване на AI за стесняване на хипотезите по време на инцидента и създаване на безупречна следсмъртна скица, валидираща всяка първопричина с данни
- Способност за прилагане на дисциплината на писане на език, който не обвинява следсмъртното и споделяне на данни за събитието, като ги маскира.
Всяка система в крайна сметка се разпада. Разликата е в това как добрите екипи се подготвят за това неизбежно събитие и как учат. Инцидентът е неочаквано събитие, което прекъсва или заплашва да наруши услугата: срив на услугата, рязко нарастване на времето за реакция, загуба на данни. Управлението на инциденти означава откриване, смекчаване, разрешаване на инцидента възможно най-бързо и след това извличане на поука от него. Това е дисциплината, която движи DevOps и SRE (Site Reliability Engineering) професионалисти ден и нощ.
Два критични показателя измерват качеството на събитието: MTTD (средно време за откриване) и MTTR (средно време за възстановяване). Целта е да се свият и двете. AI добавя две големи стойности тук: бързо обобщаване на регистрационни файлове и показатели по време на събитието, за да се стесни възможната първопричина, и бързо изготвяне на post mortem (доклад за разследване след събитието) след събитието. Но решенията за хода на събитията - коя услуга да изключите, да върнете назад, какво да кажете на клиента - са ваши.
Жизнен цикъл на събитие
- Откриване: Прозвучава аларма или идва оплакване от клиент. Колкото по-рано, толкова по-добре.
- Триаж: Колко сериозно е? Какво представлява домейнът? Присвояват се нива на сериозност – обикновено SEV1 (най-критично, цялата система) до SEV4 (незначително).
- Съберете своя екип за реагиране. При критични инциденти командирът на инцидента поема координацията.
- Смекчаване: Първо спрете кървенето - често връщане назад или покриване на флаг. По-късно ще откриете основната причина.
- Разрешаване: Приложете постоянна корекция.
- Научете (посмъртно): Какво се случи, защо се случи, как да предотвратим това да се случи отново?
Съвет: Една от най-скъпите грешки по време на инцидента е забавянето на спирането на кървенето, защото „нека първо стигнем до точната първопричина“. Правило: първо намаляване (възстановяване/възстановяване на услуга), след това запитване. Връщането към заведомо добра версия често е най-бързото смекчаване.
Постмортална култура без чувство за вина
Гръбнакът на здравите екипи е културата на безупречен постмортем: целта не е „кой го е направил“, а „коя система и процес са допуснали тази грешка?“ е въпросът. Хората крият грешката, ако знаят, че ще бъдат наказани; Скритата грешка се повтаря. Postmortem не е обвинителен доклад, а учебен документ.
Добрата аутопсия включва: резюме, въздействие (колко потребители, колко дълго, колко пари), времева линия, първопричина(и), какво е минало добре/зле и елементи за действие - конкретни мерки, всяка със собственик и дата.
Внимание: Когато пишете аутопсии с AI, не забравяйте да премахнете обвинителния език (а именно „лицето X направи грешка“). Също така маскирайте клиентски идентификационни номера, вътрешни IP адреси и тайни, когато подавате данни за събития към AI - постмортемите често се споделят широко.
Анализ на първопричината: 5 причини и AI
Класическа техника е "5 защо": попитайте "защо?" към проблем. Като питате отново и отново, вие стигате от повърхностния симптом до истинския корен. "Услугата се срина. Защо? Липсва памет. Защо? Имаше изтичане. Защо? Актуализация на библиотека..." AI бързо изгражда тази верига и предлага възможни разклонения - но трябва да проверите всяко "защо" с вашите данни; AI също може да изгради разумна, но грешна верига.
Таблица на тежестта
Ниво
Въздействие
пример
интервенция
SEV1
Цялата система/критична бизнес загуба
Плащането отпадна напълно
Мигновено целият екип, командирът
SEV2
Голяма дисфункция
Неуспешни влизания
Бързо, на повикване + поддръжка
SEV3
Частичен/ограничен ефект
Докладът се забавя
през работно време
SEV4
малък/козметичен
печатна грешка
обикновена работна опашка
три мини калъфа
Случай 1 — MTTR от 45 минути до 8 минути. Разплащателната услуга претърпя срив. Дежурният инженер даде маскираните регистрационни файлове и последната информация за разгръщане на AI и попита "Какво е най-вероятното задействане през последните 20 минути?" – попита той. AI показа, че колапсът е започнал в същата минута като последното разгръщане. Инженерът веднага върна тази версия; Услугата се върна след 8 минути. Основната причина (бъг в пула на връзката в новата версия) беше удобно проучена.
Случай 2 — следсмъртна скица за 20 минути. След SEV2 екипът беше уморен и нямаше сили да напише доклад; често докладът се забавя със седмици. Този път те дадоха хронологията и бележките за инцидента на AI и изготвиха скица след смъртта без престъпления. AI създаде чиста рамка за въздействие, график и елементи за действие; Екипът го напълни с факти и го публикува за 20 минути. Урокът не беше загубен.
Случай 3 — уловена е грешна първопричина. В един случай AI каза „основна причина за претоварване на базата данни“ и това изглеждаше разумно. Но инженерът потвърди показателите: натоварването на базата данни беше нормално по време на инцидента. Истинската причина беше външен DNS проблем. Първоначалната хипотеза за AI беше непостоянна, но погрешна; Валидирането с данни предотврати публикуването на доклада с неправилно заключение.
Четири копируеми шаблона
1) Бърз триаж по време на инцидента:
Преживяваме производствено събитие. Маскирани симптоми: [SYMPTOM]. Последни промени: [LAST DEPLOY/CHANGE]. Дайте ми: (1) 3-те най-вероятни хипотези за първопричината по реда на вероятността, (2) командата/метрика, която ще провери всяка за 1 минута, (3) най-бързата БЕЗОПАСНА стъпка за смекчаване (напр. връщане назад). Строго погледнато; Заявете, че трябва да проверя всяка хипотеза.
2) Невинна следсмъртна скица:
Напишете безукорна следсмъртна скица от бележките за инцидента по-долу. Раздели: Резюме, Въздействие (потребител/продължителност/цена), Времева линия, Основна причина(и), Какво върви добре, Какво върви зле, Елементи за действие (всеки със собственик + поле за дата). Съсредоточете се върху именуване, процес и система. Бележки: [MASKED]
3) Анализ на 5 Защо:
Изградете верига "5 Защо", като започнете със следния симптом: [SYMPTOM]. Покажете дали има повече от едно възможно разклонение на всяка стъпка. До всяко „защо“ напишете доказателствата (дневник/метрика), които ще разгледам, за да го проверя. Накрая маркирайте кои стъпки все още не са проверени.
4) Създаване на активни елементи:
Според тази първопричина предложете елементи, които могат да се предприемат, които ще предотвратят повторението на същото събитие. Класифицирайте всеки елемент по: (a) предотвратяване, откриване или намаляване, (b) прогнозно усилие, (c) въздействие. Сортирайте по най-високо съотношение въздействие/усилие. Основна причина: [X]
Слаба подкана / Силна подкана
Слаб: „Услугата се срина, какво да правя?“
Резултат: без контекст; AI може да направи общи препоръки, които не отговарят на вашия случай, и дори може да излезе с окончателна първопричина.
Силно: „Услугата за производствено плащане дава 5xx за 5 минути. Последното внедряване беше преди 6 минути. Дайте 3-те най-вероятни хипотези за първопричината по ред на вероятността, кажете на командата, която ще провери всяка от тях, и предложете най-бързото безопасно смекчаване. Не бъдете конкретни, посочете, че трябва да проверя.“
Разлика: втората подкана дава симптома, времето и последната промяна; той изисква хипотеза + проверка + редукция и поддържа ИИ непрецизен.
Често срещани грешки
- Търсене на точната първопричина, преди смекчаване. Забавя спирането на кървенето и увеличава MTTR.
- Публикуване на първата хипотеза за ИИ без проверка. Течни, но фалшиви първопричини изтичат в доклада.
- Обвинителен език. Посмъртно написано анонимно насърчава укриването и повтарящата се грешка.
- Ориентиран към действие доклад без точки. Предложение без собственик и дата никога няма да бъде реализирано.
- Споделяне на данни за събитието без маскиране. Postmortem отива на широка публика; изтичат секретни/лични данни.
- Не подготвя предварително пътя за връщане назад. Ако обръщането не е практично, намаляването се забавя.
В обобщение
Управлението на инциденти е свързано с бързо откриване, смекчаване, разрешаване и учене от неизбежни събития; MTTD и MTTR са ключови показатели. Златното правило е „първо смекчаване, след това разследване“ и връщането към известната добра версия често е най-бързото смекчаване. AI е безценен при обобщаването на регистрационните файлове по време на събитието, стесняването на хипотезите и създаването на безупречни следсмъртни скици след събитието — но ваша отговорност е да потвърдите всяка хипотеза за основната причина с данни, да изчистите езика на обвиненията и да маскирате данните за събитието.
Задача за приложение
Помислете за минало (или измислено) събитие. (1) Накарайте AI да генерира хипотези и стъпки за проверка с шаблона „бързо сортиране на място“; Отбележете коя хипотеза може да бъде потвърдена от данните. (2) Начертайте скица на доклад, като използвате шаблона „невинен следсмъртно очертание“ и го попълнете с факти. (3) Идентифицирайте най-малко два активни елемента и задайте собственик и дата на всеки.
контролен списък
- [ ] По време на инцидента първо помислих за смекчаване (връщане назад/изключване) и оставих основната причина за по-късно.
- [ ] Проверих всяка хипотеза за първопричината на AI с дневник/метрика.
- [ ] Написах го на език, който не обвинява post mortem, фокусирайки се върху процеса и системата.
- [ ] Назначих собственик и дата на всеки активен елемент.
- [ ] Маскирах тайната и личната информация от данните за събитията, които дадох на AI.
- [ ] Зададох правилно нивото на сериозност според удара.