Дзііііііінь! На гадзінніку 3 раніцы, вы глядзіце цудоўны сон, і раптам - званок. На гэтым тыдні вы дзяжурыце, і, відаць, нешта здарылася. Аўтаматызаваная сістэма кліча разабрацца, у чым справа. Гэта важны момант кіравання сучаснымі кампутарнымі сістэмамі, але давайце паглядзім, як зрабіць апавяшчэння зручней для людзей.
Знаёмцеся з філасофіяй маніторынгу, якая нарадзілася за некалькі дзесяцігоддзяў маіх дзяжурстваў у розных камандах па маніторынгу. На яе шмат у чым паўплывала сапраўдная біблія ад Роба Евашчука (Мая філасофія апавяшчэнняў), уключаная ў кнігу па , і кніга Джона Олспа (Заўвагі па наладзе абвестак).
, и - Дзякуй за дапамогу ў рэдагаванні паста.
Што такое CASE?
Я вырашыў прыдумаць прыгожую абрэвіятуру, як у або . Я клічу гэта метад CASE. Ён апісвае чатыры моманты, на якія трэба звярнуць увагу пры працы з аўтаматычным маніторынгам:
- (прывязка да кантэксту)
- (практычная каштоўнасць)
- (акцэнт на сімптомы)
- (адзнака)
Калі вы карыстаецеся CASE, вы ставіцеся да апавяшчэнняў са здаровым пафігізмам і не абуджаеце людзей па начах. Трэба рэгулярна ацэньваць маніторынг на прадмет карыснасці і эфектыўнасці. Калі чалавек атрымае апавяшчэнне, у яго будуць лепшыя ментальныя мадэлі і больш упэўненасці.
Каб лягчэй запомнілася, уявіце, што вам патрэбен CASE [гэта значыць кейс, прычына — заўв.перакладчыка], каб апраўдаць кожнае апавяшчэнне. :sunglasses:
І навошта гэта ўсё?
. Па многіх прычынах. І CASE не ўхіліць іх усё. Але з ім па начах вы будзеце прачынацца ад больш якасных апавяшчэнняў. Гэты метад ахоплівае розныя арганізацыйныя працэсы, якія таксама дапамогуць у гэтай справе.
Хараство метадаў RED і USE у тым, што з іх дапамогай мы не толькі ведаем, як працаваць, але і гаворым адзін з адным на адной мове. Я спадзяюся, што з метадам CASE будзе прасцей абмяркоўваць апавяшчэнні, якія абараняюць нашы сістэмы, але не даюць спакою калегам.
Сутнасць у тым, што трэба стварыць у арганізацыі такую культуру, дзе да апавяшчэнняў ставяцца са здаровым пафігізмам. Апавяшчэнні могуць стварацца па справе, але не факт, што пазней яны не страцяць каштоўнасць. Чаму мы наладзілі гэтае апавяшчэнне? Ці даўно пераглядаліся яго крытэры? З CASE на гэтыя пытанні можна знайсці адказы.
Context-Heavy - прывязка да кантэксту
3 раніцы - не лепшы час, каб чытаць паведамленні, у якіх шмат разумных слоў. Каб эфектыўна адрэагаваць, патрэбная інфармацыя. У ідэале гэта павінна быць інфармацыя аб канкрэтнай праблеме, па якой адразу зразумелы кантэкст, і трэба настройваць апавяшчэнні так, каб гэта было магчыма. Гэта «назіранне» і «арыентацыя» з . На гэтую наладу не шкада выдаткаваць час, таму што ўвесь час адцягваць чалавека - яшчэ даражэй. Давайце паважаць адно аднаго.
У праблем шмат крыніц. Асабліва прывіды.
Як дапамагчы дзяжурнаму? Перш за ўсё дзяжурны бачыць апавяшчэнне, таму ўсе гіпотэзы ён будуе на яго аснове. Потым ён глядзіць інструкцыі і дашборды, але ці заўсёды там ёсць дадзеныя па канкрэтным апавяшчэнні, а не проста агульная інфармацыя? Олспо раіць «думаць, як можна інтэрпрэтаваць апавяшчэнне або адрэагаваць на яго» (слайд 29). Добрае апавяшчэнне арыентавана на дзяжурнага, а не проста настроены па парогавым значэнні.
Таму вось ідэі, як палепшыць кантэкст апавяшчэнняў:
- Пакажыце карыстачу нешта карыснае і створанае адмыслова, а не проста звычайныя інструкцыі ці дашборд. Раней мы з хлопцамі выкарыстоўвалі дашборды для расследавання, настроеныя на канкрэтныя апавяшчэнні. Гэта дапаможа, калі праблема вядомая, і толькі заблытае ў іншых выпадках. Тут трэба знайсці баланс.
- Раскажыце аб гісторыі апавяшчэння: ён новы? Ён часта спрацоўвае? Ён сезонны?
- Пакажыце нядаўнія змены ў стане сістэмы. Нядаўна што-небудзь змянілася? (Напрыклад, дэплой ці ўключэнне/адключэнне функцыяналу.)
- Пакажыце адносіны і дайце інфармацыю для ментальнай мадэлі: залежнасці сістэмы павінны быць выразна бачныя, пажадана з указаннем працаздольнасці.
- Аператыўна звяжыце карыстальніка з камандай: ён бачыць бягучыя інцыдэнты або можа даведацца, хто яшчэ ў кампаніі атрымаў апавяшчэнне? Праграма актываваная?
У ідэале праграма кіравання інцыдэнтамі дае парады, як палепшыць кантэкст апавяшчэння пры расследаванні інцыдэнтаў. Тут заўжды ёсць над чым працаваць!
Actionable - практычная каштоўнасць
Дзяжурны павінен нешта зрабіць у адказ на апавяшчэнне? Калі нічога не трэба рабіць ці незразумела, што рабіць, навошта разбудзілі? Трэба пазбягаць апавяшчэнняў, якія дастаюць дзяжурных і не патрабуюць дзеянняў.
Што рабіць? Што трэба?
Раней, калі сістэмы былі простымі, а каманды маленькімі, мы настройвалі маніторынг, каб проста быць у курсе спраў. Апавяшчэнне аб тым, што нагрузка на кучу вырасла, дасць нам кантэкст, калі потым сэрвіс будзе працаваць са збоямі. У вялікім маштабе такія апавяшчэнні толькі заблытаюць, таму што нашы сістэмы заўсёды працуюць у стане дэградацыі рознай ступені цяжкасці. Гэта хутка прыводзіць да і, вядома, да страты адчувальнасці. Таму дзяжурны ігнаруе ці нават фільтруе такія апавяшчэнні і не заўсёды рэагуе на іх, як трэба. Не трапляйцеся ў гэтую пастку! Не настройвайце ўсе апавяшчэнні запар, каб потым адпраўляць іх на пошту ў якую-небудзь богам забытую тэчку.
Вось як выглядае апавяшчэнне з практычнай каштоўнасцю:
- Апавяшчэнне патрабуе дзеянні, а не проста паведамляе навіны.
- Гэта дзеянне складана ці рызыкоўна аўтаматызаваць. Калі дзеянне можна аўтаматызаваць, дык вазьміце і аўтаматызуйце, хопіць прыставаць да людзей!
- Апавяшчэнне змяшчае тэрміновыя рэкамендацыі ў выглядзе (SLA) або (RTO). Тады дзяжурны можа задзейнічаць праграму кіравання інцыдэнтамі ў арганізацыі.
Жадаю ўдакладніць: я не кажу, што апавяшчэнні павінны прыходзіць толькі па найважнейшых SLO (service-level objectives, мэты ўзроўня абслугоўвання) для API. Маніторынг SLO стала драбніцца і дзеліцца і патрабуе аднолькавага падыходу да ўсіх сэрвісаў. Зразумела, што вы будзеце адсочваць найважнейшыя SLO для кліентаў, якія вам плацяць. Але SLO інфраструктуры, напрыклад баз даных, таксама трэба адсочваць. Хутка вам давядзецца займацца ўнутранымі кліентамі і падтрымліваць іх. І так да бясконцасці.
Symptom-based - акцэнт на сімптомы
Падабаецца вам гэта ці не, але вы працуеце ў размеркаванай сістэме (Кавадж). У выніку вы выкарыстоўваеце розныя тактыкі, каб ізаляваць сэрвісы і абараніць іх ад збояў (Трэйнар і інш.)3. І хоць які зацягнуўся garbage collection ці задуманы запыт да базы дадзеных паказваюць на непаладкі, не трэба кідацца ўстараняць іх, калі ў карыстачоў не будзе праблем хуткім часам.
Гэта важныя сігналы, і яны могуць мець практычную каштоўнасць, але калі яны не мяшаюць карыстачам, то гэта не настолькі тэрмінова, каб адцягваць дзяжурнага. Апавяшчэнні на аснове прычыны - гэта здымкі нашых ментальных мадэляў аб сістэмным збоі. Лепш адсочваць важныя сімптомы, чым спрабаваць пералічыць усе магчымыя прычыны збою.
Каб апавяшчэнні мелі практычную каштоўнасць, засяродзьцеся на , важных для карыстальнікаў. Еващук называе гэта "маніторынгам для карыстальнікаў". Памятайце, што гэтую філасофію трэба ўжываць па ўсёй арганізацыі. Калі ў сэрвісу недзе ў глыбіні інфраструктуры ўзнікнуць тэрміновыя праблемы, імі зоймецца адпаведная каманда. Абарона сістэм ад такіх збояў - гэта зусім асобнае пытанне (Трэйнер і інш, раздзел аб стратэгіях для мінімізацыі крытычных залежнасцяў).
Сімптомы не такія зменлівыя
Рычард Кук нагадвае, што ў складаных сістэмах куча заган, недахопаў і праблем. Спрабаваць пералічыць усе магчымыя прычыны - Сізіфава праца. Вы спрабуеце апісваць праблемы, а яны ўвесь час мяняюцца. Сіндзі Шрыдхаран лічыць, што "сістэмы не абавязкова павінны кожную секунду знаходзіцца ў ідэальным стане" і лепш выкарыстоўваць больш чалавечны падыход. («Назіранне за размеркаванымі сістэмамі»), 7).
Пазбягайце апавяшчэнняў па факце інцыдэнту
Звычайна для выпраўлення інцыдэнтаў наладжваюцца апавяшчэння для прычын. І гэтыя абмежаваныя апавяшчэнні аб факце здарэння ствараюць ілжывае пачуццё ўпэўненасці, бо сістэма кожны раз прыдумляе новыя спосабы зламацца.
Не падманвайце сябе апавяшчэннямі аб прычынах. Лепш падумайце:
- Чаму апавяшчэнне на базе сімптомаў не заўважыла праблему?
- Ці будзе карысна палепшыць кантэкст для карыстальніка?
- Як палепшыць інструменты маніторынгу, каб хутчэй ставіць дыягназ, а не назапашваць апавяшчэння аб які здарыўся?
Інструменты маніторынгу для дыягностыкі дапамогуць, толькі калі вы будзеце ўспрымаць іх як спосаб перайсці ад сімптому да рашэння. Без гэтай зваротнай сувязі вас проста заваляць запозненыя апавяшчэнні і дыяграмы аб мінулых збоях - і ні слова аб будучых. Для арганізацыі гэта выдатная магчымасць перайсці з абароны ў атаку. А ў распрацоўшчыкаў і прадуктовых менеджэраў будуць аднолькавыя чаканні і зразумелыя мэты. Кейс — CASE (:wink:) — для кожнага апавяшчэньня ясны.
Апавяшчэнні на аснове прычыны памяркоўныя ва ўмеранай колькасці
Часам наша сістэма амаль не пакідае нам выбару ў плане апавяшчэнняў на аснове прычыны. А часам дзяжурныя цудоўна разумеюць, што сімптом абавязкова прывядзе да збою, а значыць утрымлівае практычную каштоўнасць. Можа быць, вы проста не ўпэўненыя, што адбываецца, і наладжваеце апавяшчэння для перастрахоўкі. Будзем спадзявацца, што гэтае дзеянне патрабуецца часова, пакуль мы не зменім сістэму, каб вырашыць пытанне зніжэння прадукцыйнасці.
Памятайце пра іншыя кампаненты CASE, калі разбіраецеся з такімі сітуацыямі. Калі гэта часова, ня значыць, што можна ня думаць галавой.
Evaluated - ацэнка
Любыя змены ў сістэме (новы код, новая інфраструктура, ды што заўгодна новае) пашыраюць асартымент збояў (Кук, 3). Гэта апавяшчэнне сапраўды ўсё яшчэ працуе, як чакалася? Выразныя і актуальныя ментальныя мадэлі сістэм і вопыт рэагавання на некаторыя апавяшчэнні ў падтрымку - гэта ключавыя рысы . Дэфекты ў сістэмах увесь час развіваюцца, і мы павінны паспяваць за імі.
Трэба пастаянна ацэньваць якасць кожнага апавяшчэння, каб яны працавалі, як чакалася. Паважаныя кіраўнікі! Вашым камандам будзе значна прасцей, калі вы дапаможаце ім наладзіць гэты працэс! Вось некалькі ідэй па адзнацы:
- выкарыстоўвайце , або іншыя метады тэсціравання апавяшчэнняў. Каманда можа зрабіць гэта сама, не задзейнічаючы цяжкавагавую сістэму кіравання інцыдэнтамі!
- Уключыце збор дадзеных аб усіх апавяшчэннях, звязаных з інцыдэнтамі, у праграму кіравання інцыдэнтамі. Адзначайце карысныя, шкодныя, недарэчныя, незразумелыя і т. д. Выкарыстоўвайце іх як фідбэк.
- Правільныя апавяшчэння спрацоўваюць нячаста і старанна правераны. Пераканайцеся, што ўсе спасылкі працуюць, указваюць на патрэбны кантэкст і г.д.
- Калі апавяшчэнне не спрацоўвае ніколі ці спрацоўвае занадта часта, з ім нешта не так. Паправіце яго ці выдаліце. Сцеражыцеся празмернай пасіўнасці ці актыўнасці!
- Наладзьце для апавяшчэнняў пазнакі часу з тэрмінам прыдатнасці. Калі тэрмін прыдатнасці скончыўся, ацаніце апавяшчэнне па метадзе CASE і абновіце пазнаку часу. Рэгулярна правярайце тэрмін прыдатнасці, як у ежы.
- Спрасціце працэс паляпшэння апавяшчэнняў. Выкарыстоўвайце маніторынг у выглядзе кода і захоўвайце апавяшчэння ў рэпазітары Git. Пул-рэквесты дапамагаюць прыцягваць каманду, а ў вас будзе гісторыя мінулых апавяшчэнняў. І вы перастанеце баяцца мяняць апавяшчэння або пытаць дазвол у тых, хто за іх адказвае.
- Наладжвайце фідбэк для апавяшчэнняў, нават калі гэта проста , каб дзяжурныя пазначалі апавяшчэнні як бескарысныя або дакучлівыя. Убудуйце ў само апавяшчэнне спасылку або заклік да дзеяння і рэгулярна праглядайце фідбэк.
- Усталюйце ў камандзе правіла - хай дзяжурныя працуюць над спрашчэннем дзяжурства, калі мала працы. Хай пасля вас усё стане крыху лепш, чым было да.
Заключэнне
Я лічу, што метад CASE дапамагае распрацоўнікам і арганізацыям абмяркоўваць наладу і адпраўку аўтаматычных апавяшчэнняў. Адзін распрацоўшчык можа пачаць ацэнку апавяшчэнняў па метадзе CASE, а потым да яго далучыцца ўся арганізацыя з іншымі распрацоўшчыкамі, кіраўніцтвам і праграмамі кіравання інцыдэнтамі, каб падтрымліваць апавяшчэння ў добрым стане. Для гэтага не патрэбныя ніякія асаблівыя прылады ці складаныя працэсы.
Уся галіна павінна задумацца аб чалавечым фактары падчас дзяжурства без шкоды для першакласнага абслугоўвання кліентаў. Усе гэтыя прылады і практыкі можна і трэба ўдасканальваць. Спадзяюся, метад CASE дапаможа ў гэтым.
Атрымлівайце асалоду ад удасканаленымі апавяшчэннямі!
Крыніца: habr.com