Јединице
1. Увод у ДевОпс и Цлоуд АИ: улоге, границе, аутентификација, безбедност и тајне 2. Дизајнирање ЦИ/ЦД цевовода са вештачком интелигенцијом: ГитХуб акције и ГитЛаб ЦИ 3. Управљање инфраструктуром као код: вештачка интелигенција са Терраформом и ИаЦ-ом 4. Контејнеризација: Доцкерфиле и оптимизација слике са вештачком интелигенцијом 5. Кубернетес: Манифест, кормило и АИ-поверед оркестрација 6. Мониторинг и опсервабилност: метричка, дневник, правила праћења и аларма 7. Управљање инцидентима и постмортем: анализа корена уз помоћ вештачке интелигенције 8. Оптимизација трошкова у облаку (ФинОпс): Лов на отпад помоћу вештачке интелигенције 9. Генерисање скрипти и аутоматизације: Басх, Питхон и ПоверСхелл 10. Безбедност и управљање тајнама: ДевСецОпс и вештачка интелигенција 11. Провера производа, стратегије издавања и ток АИ рада од краја до краја
Јединица 7 / 11

Управљање инцидентима и постмортем: анализа корена уз помоћ вештачке интелигенције

Добици:

  • Способност разумевања животног циклуса инцидента (детекција, тријажа, ублажавање, решавање, постмортем), МТТД/МТТР метрика и принцип „прво ублажити, истражити касније“
  • Могућност коришћења вештачке интелигенције за сужавање хипотеза у време инцидента и израду беспрекорне постмортем скице, потврђујући сваки основни узрок подацима
  • Способност примене дисциплине писања на језику који не криви обдукцију и дељење података о догађајима тако што их маскира.

Сваки систем се на крају поквари. Разлика је у томе како се добри тимови припремају за овај неизбежни догађај и како уче. Инцидент је неочекивани догађај који омета или прети да поремети услугу: пад услуге, време одзива нагло расте, губитак података. Управљање инцидентима значи откривање, ублажавање, решавање инцидента што је брже могуће, а затим учење из њега. Ово је дисциплина која покреће ДевОпс и СРЕ (Сите Релиабилити Енгинееринг) професионалце дан и ноћ.

Две критичне метрике мере квалитет догађаја: МТТД (средње време за откривање) и МТТР (средње време за опоравак). Циљ је смањити оба. АИ овде додаје две велике вредности: брзо сумирање евиденције и метрике у време догађаја да би се сузио могући основни узрок и брзо састављање постмортем (извештај о истрази после догађаја) након догађаја. Али одлуке о току догађаја – коју услугу да искључите, вратите назад, шта да кажете купцу – су ваше.

Животни циклус догађаја

  1. Детекција: Оглашава се аларм или долази жалба корисника. Што пре то боље.
  2. Тријажа: Колико је то озбиљно? Шта је домен? Нивои озбиљности се додељују—обично СЕВ1 (најкритичнији, цео систем) до СЕВ4 (мањи).
  3. Окупите свој тим за одговор. У критичним инцидентима, командир инцидента преузима координацију.
  4. Ублажавање: Прво зауставите крварење - често враћање уназад или покривање заставе. Касније ћете пронаћи основни узрок.
  5. Решите: примените трајну исправку.
  6. Научите (постмортем): Шта се догодило, зашто се догодило, како да спречимо да се то понови?
Савет: Једна од најскупљих грешака у тренутку инцидента је одлагање заустављања крварења јер „хајде да прво дођемо до тачног узрока“. Правило: прво декремент (услуга враћања/враћања), а затим се распитајте. Враћање на познату добру верзију је често најбрже ублажавање.

Постмортем култура без кривице

Окосница здравих тимова је култура беспрекорног постмортема: циљ није „ко је то урадио“, већ „који систем и процес су дозволили ову грешку?“ је питање. Људи крију грешку ако знају да ће бити кажњени; Скривена грешка се понавља. Обдукција није извештај оптужбе, већ документ учења.

Добар обдукција укључује: резиме, утицај (колико корисника, колико дуго, колико новца), временски оквир, основни узрок(е), шта је прошло добро/лоше, и ставке акције—конкретне мере, свака са власником и датумом.

Опрез: Када пишете обдукције са АИ, обавезно елиминишите оптужујући језик (наиме „особа Кс је направила грешку“). Такође маскирајте ИД-ове клијената, интерне ИП адресе и тајне када се подаци о догађајима достављају АИ – обдукције се често широко деле.

Анализа основног узрока: 5 Зашто и АИ

Класична техника је "5 зашто": питајте "зашто?" на проблем. Питајући изнова и изнова, долазите од површног симптома до правог корена. „Услуга је пала. Зашто? Без меморије. Зашто? Дошло је до цурења. Зашто? Ажурирање библиотеке...“ АИ брзо гради овај ланац и предлаже могуће гране — али морате да проверите свако „зашто“ са својим подацима; АИ такође може да изгради разуман, али погрешан ланац.

Табела озбиљности

Ниво

Утицај

пример

интервенција

СЕВ1

Читав систем/критичан пословни губитак

Плаћање је потпуно пало

Одмах, цео тим, командант

СЕВ2

Велика дисфункција

Пријављивање није успело

Брзо, на позив + подршка

СЕВ3

Делимичан/ограничени ефекат

Извештај касни

током радног времена

СЕВ4

мали/козметички

типо

обичан радни ред

три мини кофера

Случај 1 — МТТР од 45 минута до 8 минута. Услуга плаћања је пала. Дежурни инжињер је дао маскиране дневнике и последњу информацију о коришћењу АИ и упитао „Шта је највероватнији окидач у последњих 20 минута?“ упитао је. АИ је показао да је колапс почео у истом тренутку када и последње распоређивање. Инжењер је одмах вратио ту верзију; Услуга се вратила за 8 минута. Основни узрок (грешка у групи веза у новој верзији) је затим прикладно истражен.

Случај 2 — обдукција за 20 минута. Након СЕВ2, тим је био уморан и није имао снаге да напише извештај; често је извештај каснио недељама. Овог пута, дали су временску линију и белешке о инцидентима АИ и направили постморталну скицу без злочина. АИ је створио уредан оквир за утицај, временски оквир и акције; Тим га је напунио чињеницама и објавио за 20 минута. Лекција није изгубљена.

Случај 3 — ухваћен је погрешан основни узрок. У једном случају, АИ је рекао „преоптерећење базе података о основном узроку“ и то се чинило разумним. Али инжењер је потврдио метрику: оптерећење базе података је било нормално у време инцидента. Прави узрок је био спољни ДНС проблем. Почетна хипотеза АИ је била течна, али погрешна; Валидација података спречила је објављивање извештаја са нетачним закључком.

Четири шаблона за копирање

1) Брза тријажа у време инцидента:

Доживљавамо производни догађај. Маскирани симптоми: [СИМПТОМ]. Последње промене: [ПОСЛЕДЊА РАЗВОЈ/ПРОМЕНА]. Дајте ми: (1) 3 највероватније хипотезе основног узрока по редоследу вероватноће, (2) команду/метрику која ће верификовати сваку за 1 минут, (3) најбржи корак БЕЗБЕДНОГ ублажавања (нпр. враћање уназад). Строго говорећи; Наведите да морам да проверим сваку хипотезу.

2) Невина обдукциона скица:

Напишите беспрекорну скицу обдукције из доле наведених белешки о инциденту. Одељци: Резиме, Утицај (корисник/трајање/цена), Временска линија, Основни узрок(и), Шта је прошло добро, Шта је лоше, Ставке акције (свака са власником + пољем за датум). Фокусирајте се на именовање, процес и систем. Напомене: [МАСКИРАНИ]

3) 5 Зашто анализа:

Направите ланац „5 Зашто“, почевши од следећег симптома: [СИМПТОМ]. Прикажи да ли постоји више од једне могуће гране у сваком кораку. Поред сваког „зашто“ напишите доказ (лог/метрички) који ћу погледати да бих га проверио. На крају означите који кораци још нису верификовани.

4) Креирање активних ствари:

У складу са овим основним узроком, предложите ставке које се могу предузети које ће спречити да се исти догађај понови. Класификујте сваку ставку према: (а) превенцији, откривању или смањењу, (б) процењеном напору, (ц) утицају. Сортирај према највећем односу утицај/напор. Основни узрок: [Кс]

Слаби промпт / Јаки промпт

Слабо: „Услуга је пала, шта да радим?“

Резултат: нема контекста; АИ може дати опште препоруке које се не уклапају у ваш случај, и чак може доћи до дефинитивног основног узрока.

Снажно: „Услуга за плаћање у производњи даје 5кк 5 минута. Последње постављање је било пре 6 минута. Наведите 3 хипотезе највероватнијег основног узрока по редоследу вероватноће, реците команди која ће верификовати сваку од њих и предложити најбрже безбедно ублажавање. Немојте бити конкретни, наведите да морам да проверим.“

Разлика: други упит даје симптом, тајминг и последњу промену; захтева хипотезу + верификацију + редукцију и држи АИ непрецизном.

Уобичајене грешке

  • Тражите тачан узрок пре ублажавања. Одлаже заустављање крварења и повећава МТТР.
  • Објављивање прве хипотезе АИ без њене верификације. Течни, али лажни основни узроци процуре у извештај.
  • Оптужни језик. Постмортем написан анонимно подстиче прикривање и понављање грешке.
  • Извештај оријентисан на акцију без тачака. Предлог без власника и датума никада неће бити спроведен.
  • Дељење података о догађајима без маскирања. Постмортем иде широкој публици; процурели су тајни/лични подаци.
  • Не припрема унапред путању враћања. Ако преокрет није практичан, смањење се успорава.

Укратко

Управљање инцидентима подразумева брзо откривање, ублажавање, решавање и учење из неизбежних догађаја; МТТД и МТТР су кључни показатељи. Златно правило је „прво ублажити, а касније истражити“ и враћање на познату добру верзију је често најбрже ублажавање. АИ је од непроцењиве вредности у сажимању дневника у време догађаја, сужавању хипотеза и стварању беспрекорних постмортем скица након догађаја – али ваша је одговорност да потврдите сваку хипотезу о основном узроку подацима, очистите језик кривице и маскирате податке о догађајима.

Задатак апликације

Размотрите прошли (или измишљени) догађај. (1) Нека АИ генерише хипотезе и кораке верификације помоћу шаблона „брза тријажа на лицу места“; Запазите коју хипотезу могу потврдити подаци. (2) Скицирајте извештај користећи шаблон „обдуктивне обрисе није крив“ и попуните га чињеницама. (3) Идентификујте најмање две ставке које се могу предузети и сваком доделите власника и датум.

контролна листа

  • [ ] У време инцидента, прво сам помислио на ублажавање (враћање/гашење) и оставио сам основни узрок за касније.
  • [ ] Проверио сам сваку хипотезу основног узрока АИ помоћу лог/метрике.
  • [ ] Написао сам га језиком који не криви постмортем, фокусирајући се на процес и систем.
  • [ ] Сваком предмету који се може предузети доделио сам власника и датум.
  • [ ] Сакрио сам тајне и личне податке из података о догађајима које сам дао АИ.
  • [ ] Исправно сам доделио ниво озбиљности према удару.