Џиииииин! 3 часот наутро, сонуваш прекрасен сон и одеднаш се јави. Вие сте на должност оваа недела, и очигледно нешто се случило. Автоматизираниот систем се јавува за да открие што не е во ред. Ова е важен аспект за управување со современи компјутерски системи, но ајде да погледнеме како да ги подобриме известувањата за луѓето.
Запознајте се со филозофијата на мониторинг, родена во повеќедецениските мои должности во различни мониторинг тимови. Таа беше под големо влијание на вистинската библија од Роб Евашчук (My Notification Philosophy) вклучена во книгата за , и книга од Џон Алспау (Забелешки за поставување предупредувања).
, и — Ви благодариме за помошта во уредувањето на објавата.
Што е СЛУЧАЈ?
Решив да смислам убава кратенка како или . го викам CASE метод. Тој опишува четири точки на кои треба да се обрне внимание кога се работи со автоматско следење:
- (сврзано со контекст)
- (практична вредност)
- (акцент на симптомите)
- (одделение)
Ако користите CASE, ги третирате известувањата со здрава рамнодушност и не ги будите луѓето ноќе. Мониторингот треба редовно да се оценува за корисност и ефективност. Кога некое лице ќе го добие известувањето, ќе има подобри ментални модели и поголема самодоверба.
За полесно да се запомни, замислете дека ви треба СЛУЧАЈ [т.е. случај, причина - белешка на преведувачот] за да се оправда секое предупредување. :очила за сонце:
И зошто е сето ова?
. Од многу причини. И CASE нема да ги елиминира сите. Но, со него, ќе се будите ноќе со подобри известувања. Овој метод опфаќа различни организациски процеси кои исто така ќе помогнат во оваа работа.
Убавината на методите RED и USE е во тоа што со нивна помош не само што знаеме да работиме, туку и зборуваме ист јазик меѓу себе. Се надевам дека методот CASE ќе го олесни дискусијата за известувањата кои ги штитат нашите системи, но ги држат нашите колеги зафатени.
Поентата е дека треба да создадете култура во вашата организација каде известувањата се третираат со здрава рамнодушност. Известувањата може да се креираат за одредена цел, но не е факт дека подоцна нема да изгубат вредност. Зошто го поставивме ова известување? Пред колку време се ревидирани неговите критериуми? Со CASE, овие прашања може да се одговорат.
Context-Heavy - контекстуално врзување
3 часот наутро не е најдобро време за читање пораки кои содржат многу паметни зборови. За да одговорите ефективно, потребни ви се информации. Идеално, ова треба да биде информација за одредено прашање, за кое контекстот е веднаш јасен, а известувањата треба да се конфигурираат така што тоа е можно. Ова е „набљудување“ и „ориентација“ од . Не е срамота да потрошите време на оваа поставка, бидејќи постојаното одвлекување на вниманието на некоја личност е уште поскапо. Да се почитуваме.
Проблемите имаат многу извори. Особено духови.
Како можам да му помогнам на дежурниот? Првото нешто што го гледа дежурниот е известување, па на негова основа ги гради сите хипотези. Потоа ги гледа инструкциите и контролните табли, но дали секогаш има податоци за одредено известување, а не само општи информации? Алспау советува „да размислите како може да го протолкувате или да одговорите на известувањето“ (слајд 29). Доброто известување е фокусирано на дежурното лице, а не само конфигурирано со праг.
Значи, еве неколку идеи како да го подобрите контекстот за известување:
- Покажете му на корисникот нешто корисно и специјално создадено, а не само обични упатства или контролна табла. Претходно, момците и јас користевме истражни контролни табли конфигурирани за конкретни известувања. Ова ќе помогне ако проблемот е познат, но само ќе ги збуни другите. Тука треба да најдеме рамнотежа.
- Кажете ни за историјата на известувањето: дали е ново? Дали често работи? Дали е сезонски?
- Прикажи неодамнешни промени во состојбата на системот. Дали нешто се промени неодамна? (На пример, распоредување или овозможување/оневозможување на функционалноста.)
- Покажете ги односите и обезбедете информации за менталниот модел: зависностите на системот треба да бидат јасно видливи, по можност со индикација за функционалноста.
- Брзо поврзете го корисникот со тимот: дали тие можат да видат тековни инциденти или можат да откријат кој друг во компанијата добил известување? Програма активиран?
Идеално, програма за управување со инциденти ќе обезбеди совети за тоа како да се подобри контекстот на известување за истрагите на инцидентот. Секогаш има на што да се работи!
Акционално - практична вредност
Дали дежурниот треба да направи нешто како одговор на известувањето? Ако не треба да правите ништо или не е јасно што да правите, зошто го разбудивте? Треба да избегнувате известувања кои ги нервираат дежурните и не бараат акција.
Што да правам? Што сакаш?
Во минатото, кога системите беа едноставни, а тимовите мали, поставувавме мониторинг само за да останеме на врвот на работите. Известувањето дека оптоварувањето на купот е зголемено ќе ни даде контекст доколку услугата последователно не функционира. Во голем обем, ваквите известувања само ќе создадат конфузија бидејќи нашите системи секогаш работат во состојба на деградација со различна тежина. Ова брзо доведува до и, се разбира, до губење на чувствителноста. Затоа, дежурниот ги игнорира, па дури и ги филтрира таквите известувања и не секогаш одговара на нив по потреба. Не паѓајте во оваа замка! Не ги поставувајте сите известувања по ред, а потоа испратете ги по е-пошта до некоја отпуштена папка.
Еве како изгледа известувањето со практична вредност:
- Известувањето бара акција наместо едноставно известување вести.
- Ова дејство е тешко или ризично да се автоматизира. Ако некоја акција може да се автоматизира, тогаш автоматизирајте ја, престанете да ги мачите луѓето!
- Известувањето содржи итни препораки во формуларот (SLA) или (RTO). Дежурниот потоа може да ја активира програмата за управување со инциденти на организацијата.
Сакам да појаснам: не велам дека известувањата треба да доаѓаат само за најважните SLO (цели на ниво на услуга) за API. Мониторингот на SLO е постојано фрагментиран и поделен и бара ист пристап кон сите услуги. Јасно е дека ќе ги следите најважните SLO за клиентите кои ви плаќаат. Но, инфраструктурните SLO, како што се базите на податоци, исто така треба да се следат. Наскоро ќе треба да се справите со внатрешните клиенти и да ги поддржувате. И така натаму бесконечно.
Врз основа на симптоми - акцент на симптомите
Без разлика дали сакате или не, работите во дистрибуиран систем (Кавај). Како резултат на тоа, користите различни тактики за да ги изолирате услугите и да ги заштитите од неуспех (Trainor et al.)3. И иако одложеното собирање ѓубре или барањето за застој во базата укажува на проблеми, нема потреба да брзате да ги поправите доколку корисниците немаат проблеми во блиска иднина.
Овие се важни сигнали и може да имаат практична вредност, но ако не ги вознемируваат корисниците, тогаш не е доволно итно да го одвлече вниманието на придружникот. Известувањата засновани на причини се снимки од нашите ментални модели за дефект на системот. Подобро е да ги следите важните симптоми отколку да се обидете да ги наведете сите можни причини за неуспех.
За да ги направите известувањата значајни, фокусирајте се на , важно за корисниците. Евашчук ова го нарекува „следење за корисниците“. Запомнете дека оваа филозофија мора да се применува низ целата организација. Доколку некоја служба има итни проблеми некаде длабоко во инфраструктурата, соодветниот тим ќе се погрижи за нив. Заштитата на системите од такви неуспеси е сосема посебна работа (Trainer et al., дел за стратегии за минимизирање на критичните зависности).
Симптомите не се толку променливи
Ричард Кук не потсетува дека сложените системи се полни со недостатоци, недостатоци и проблеми. Обидот да се наведат сите можни причини е сизифовска задача. Се обидувате да ги опишете проблемите, но тие постојано се менуваат. Синди Сридхаран верува дека „системите не мора да бидат во совршена состојба секоја секунда“ и подобро е да се користи почовечки пристап ( („Следење на дистрибуирани системи“), 7).
Избегнувајте известувања по инцидент
Вообичаено, известувањата за причините се конфигурирани да ги поправаат инцидентите. И овие ограничени известувања за фактот што се случило создаваат лажно чувство на сигурност, бидејќи системот секој пат доаѓа со нови начини за пробивање.
Немојте да бидете измамени од известувањата за причините. Подобро размислете:
- Зошто известувањето засновано на симптоми не го забележа проблемот?
- Дали би било корисно да се подобри контекстот за корисникот?
- Како може да се подобрат алатките за следење за да се постави дијагноза побрзо, наместо да се акумулираат известувања за тоа што се случило?
Алатките за следење за дијагноза ќе ви помогнат само ако ги мислите како начин да преминете од симптом до решение. Без оваа повратна информација, едноставно ќе бидете бомбардирани со доцни известувања и графикони за минатите неуспеси - а ни збор за идните. Ова е одлична можност за една организација да премине од одбрана во напад. И програмерите и менаџерите на производи ќе ги имаат истите очекувања и јасни цели. Случајот - СЛУЧАЈ (:wink:) - е јасен за секое известување.
Известувањата засновани на причина се толерантни во умерени количини
Понекогаш нашиот систем ни остава мал избор во однос на известувањата засновани на причини. И понекогаш дежурните совршено разбираат дека симптомот дефинитивно ќе доведе до неуспех и затоа содржи практична вредност. Можеби едноставно не сте сигурни што се случува и ги поставувате известувањата за да бидете на безбедна страна. Се надеваме дека ова дејство е привремено додека не можеме да го промениме системот за да го решиме проблемот со перформансите.
Имајте ги предвид другите компоненти на CASE кога се справувате со овие ситуации. Само затоа што е привремено не значи дека можете да престанете да размислувате со вашата глава.
Оценето - оценување
Сите промени во системот (нов код, нова инфраструктура, што било ново) го прошируваат опсегот на неуспеси (Кук, 3). Дали ова известување сè уште работи како што се очекуваше? Јасни и актуелни ментални модели на системи и искуство во одговарање на некои известувања за поддршка - ова се клучните карактеристики . Дефектите во системите постојано се развиваат и ние мора да бидеме во чекор со нив.
Треба постојано да го оценувате квалитетот на секое известување за да се уверите дека тие работат како што се очекува. Почитувани лидери! Ќе биде многу полесно за вашите тимови ако им помогнете да го воспостават овој процес! Еве неколку идеи за проценка:
- Користете , или други методи за тестирање за известување. Тимот може да го направи тоа сам без да се потпира на систем за управување со тешки инциденти!
- Вклучете ја колекцијата на сите известувања поврзани со инциденти во вашата програма за управување со инциденти. Означете корисни, штетни, несоодветни, нејасни итн. Користете ги како повратна информација.
- Вистинските известувања се активираат ретко и внимателно се тестираат. Погрижете се сите врски да работат, да укажуваат на вистинскиот контекст итн.
- Ако известувањето никогаш не се активира или пука премногу често, нешто не е во ред со него. Поправете го или отстранете го. Пазете се од прекумерна пасивност или активност!
- Поставете временски печати за известување со датуми на истекување. Ако датумот на истекување е истечен, оценете го известувањето користејќи го методот CASE и ажурирајте го временскиот печат. Исто како и храната, редовно проверувајте го рокот на употреба.
- Поедноставете го процесот на подобрување на известувањата. Користете го мониторингот како код и складирајте ги известувањата во складиштето на Git. Барањата за повлекување помагаат да се вклучи тимот и да ви даде историја на минатите известувања. И веќе нема да се плашите да ги менувате известувањата или да барате дозвола од одговорните за нив.
- Поставете повратни информации за известувањата, дури и ако тоа е едноставно , така што дежурните ги означуваат известувањата како бескорисни или наметливи. Вметнете врска или повик за акција во самото известување и редовно прегледувајте ги вашите повратни информации.
- Воспоставете правило во тимот - нека работат дежурните за да ја поедностават должноста кога има малку работа. Сè после тебе нека биде малку подобро отколку што беше порано.
Заклучок
Верувам дека методот CASE им помага на програмерите и организациите да разговараат за поставување и испраќање автоматизирани известувања. Еден развивач може да започне со проценка на известувањата користејќи го методот CASE, а потоа целата организација ќе се приклучи со други програмери, програми за управување и управување со инциденти за да ги одржува известувањата во добра форма. Ова не бара никакви посебни алатки или сложени процеси.
Целата индустрија треба да размислува за човечкиот фактор додека е на должност без да ја жртвува врвната услуга за клиенти. Сите овие алатки и практики можат и треба да се подобрат. Се надевам дека методот CASE ќе помогне во ова.
Уживајте во подобрените известувања!
Извор: www.habr.com