Дзииииин! 3 је ујутру, сањате диван сан, и одједном се јавља позив. Ове недеље сте на дужности и очигледно се нешто догодило. Аутоматизовани систем позива да открије шта није у реду. Ово је важан аспект управљања савременим рачунарским системима, али хајде да погледамо како да побољшамо обавештења за људе.
Упознајте се са филозофијом мониторинга, насталом током неколико деценија мојих дужности у различитим мониторинг тимовима. На њу је у великој мери утицала права библија Роба Евасхцхука (Моја филозофија обавештења) укључена у књигу о , и књига Џона Алспоа (Напомене о подешавању упозорења).
, и — хвала на помоћи у уређивању поста.
Шта је ЦАСЕ?
Одлучио сам да смислим прелепу скраћеницу као или . Ја то зовем ЦАСЕ метода. Он описује четири тачке на које треба обратити пажњу када радите са аутоматским надзором:
- (увезан контекст)
- (практична вредност)
- (нагласак на симптомима)
- (оцена)
Ако користите ЦАСЕ, третирате обавештења са здравом равнодушношћу и не будите људе ноћу. Праћење треба редовно процењивати у погледу корисности и ефективности. Када особа прими обавештење, имаће боље менталне моделе и више самопоуздања.
Да бисте лакше запамтили, замислите да вам је потребан СЛУЧАЈ [то јест случај, разлог - напомена преводиоца] да оправда свако упозорење. :наочаре за сунце:
И зашто је све ово?
. Из много разлога. И ЦАСЕ их неће све елиминисати. Али уз то ћете се будити ноћу уз боља обавештења. Овај метод покрива различите организационе процесе који ће такође помоћи у овом питању.
Лепота метода РЕД и УСЕ је у томе што уз њихову помоћ не само да знамо да радимо, већ и говоримо истим језиком једни са другима. Надам се да ће ЦАСЕ метода олакшати разговор о обавештењима која штите наше системе, али држе наше колеге заузетим.
Поента је да морате да створите културу у својој организацији у којој се обавештења третирају са здравом равнодушношћу. Обавештења се могу креирати за одређену сврху, али није чињеница да касније неће изгубити вредност. Зашто смо поставили ово обавештење? Пре колико времена су ревидирани њени критеријуми? Помоћу ЦАСЕ-а се може одговорити на ова питања.
Цонтект-Хеави - контекстуално везивање
3 сата ујутро није најбоље време за читање порука које садрже много паметних речи. Да бисте ефикасно одговорили, потребне су вам информације. У идеалном случају, ово би требало да буде информација о одређеном питању, за који је контекст одмах јасан, а обавештења би требало да буду конфигурисана тако да је то могуће. Ово је „посматрање“ и „оријентација“ из . Није срамота трошити време на ову поставку, јер је стално ометање особе још скупље. Поштујмо једни друге.
Проблеми имају много извора. Посебно духови.
Како могу помоћи дежурном? Прво што дежурни види је обавештење, па на основу њега гради све хипотезе. Затим погледа упутства и контролне табле, али да ли увек постоје подаци о одређеном обавештењу, а не само општи подаци? Алспаугх саветује „размишљање о томе како бисте могли да протумачите или одговорите на обавештење“ (слајд 29). Добро обавештење је фокусирано на особу на дужности, а не само конфигурисано прагом.
Ево неколико идеја како да побољшате контекст обавештења:
- Покажите кориснику нешто корисно и посебно креирано, а не само обична упутства или контролну таблу. Раније смо момци и ја користили истражне контролне табле конфигурисане за одређена обавештења. Ово ће помоћи ако је проблем познат, али ће само збунити друге. Овде морамо наћи баланс.
- Реците нам нешто о историји обавештења: да ли је ново? Да ли ради често? Да ли је сезонски?
- Прикажи недавне промене стања система. Да ли се нешто променило у последње време? (На пример, примену или омогућавање/онемогућавање функционалности.)
- Покажите односе и пружите информације за ментални модел: системске зависности треба да буду јасно видљиве, по могућности са назнаком функционалности.
- Брзо повежите корисника са тимом: да ли могу да виде инциденте у току или могу да сазнају ко је још у компанији примио обавештење? Програм активиран?
У идеалном случају, програм управљања инцидентима ће пружити савете о томе како да се побољша контекст обавештавања о истрагама инцидента. Увек постоји нешто на чему треба радити!
Ацтионабле - практична вредност
Да ли дежурни треба да уради нешто као одговор на обавештење? Ако не морате ништа да радите или вам није јасно шта да радите, зашто сте га пробудили? Морате избегавати обавештења која нервирају дежурне и не захтевају акцију.
Шта бих требао да урадим? Шта хоћеш?
У прошлости, када су системи били једноставни, а тимови мали, постављали смо надзор само да бисмо били у току. Обавештење да је оптерећење на хрпи повећано даће нам контекст ако услуга накнадно поквари. У великој мери, таква обавештења ће само створити забуну јер наши системи увек раде у стању деградације различите тежине. Ово брзо доводи до и, наравно, до губитка осетљивости. Дакле, дежурни игнорише или чак филтрира таква обавештења и не одговара увек на њих по потреби. Немојте упасти у ову замку! Немојте постављати сва обавештења заредом, а затим их слати е-поштом у неки од Бога заборављени фолдер.
Ево како изгледа обавештење са практичном вредношћу:
- Обавештење захтева акцију, а не само пријављивање вести.
- Ову радњу је тешко или ризично аутоматизовати. Ако се нека акција може аутоматизовати, онда је аутоматизујте, престаните да гњавите људе!
- Обавештење садржи хитне препоруке у обрасцу (СЛА) или (РТО). Дежурни тада може активирати програм управљања инцидентима организације.
Желим да појасним: не кажем да обавештења треба да долазе само за најважније СЛО (циљеве на нивоу услуге) за АПИ. СЛО праћење је константно фрагментирано и подијељено и захтијева исти приступ свим услугама. Јасно је да ћете пратити најважније СЛО за клијенте који вам плаћају. Али инфраструктурни СЛО, као што су базе података, такође треба да се надгледају. Ускоро ћете морати да се бавите интерним купцима и да их подржавате. И тако у недоглед.
Засновано на симптомима - нагласак на симптомима
Хтели то или не, ви радите у дистрибуираном систему (Кавај). Као резултат тога, користите различите тактике да изолујете услуге и заштитите их од неуспеха (Траинор ет ал.)3. И иако одложено сакупљање смећа или упит базе података у застоју указују на проблеме, нема потребе да журите да их поправите ако корисници не буду имали проблема у блиској будућности.
Ово су важни сигнали и могу имати практичну вредност, али ако не ометају кориснике, онда нису довољно хитни да одврате пажњу пратиоца. Обавештења заснована на узроцима су снимци наших менталних модела о квару система. Боље је пратити важне симптоме него покушавати да наведете све могуће узроке неуспеха.
Да би обавештења била смислена, фокусирајте се на , важно за кориснике. Евасхцхук ово назива „надгледањем за кориснике“. Запамтите да се ова филозофија мора применити у целој организацији. Ако нека услуга има хитне проблеме негде дубоко у инфраструктури, одговарајући тим ће се побринути за њих. Заштита система од таквих кварова је потпуно одвојена ствар (Траинер ет ал., одељак о стратегијама за минимизирање критичних зависности).
Симптоми нису толико променљиви
Рицхард Цоок нас подсећа да су сложени системи пуни мана, недостатака и проблема. Покушај набрајања свих могућих разлога је сизифов задатак. Покушавате да опишете проблеме, али они се стално мењају. Цинди Сридхаран верује да „системи не морају бити у савршеном стању сваке секунде“ и да је боље користити хуманији приступ ( („Надгледање дистрибуираних система“), 7).
Избегавајте обавештења након инцидента
Обично су обавештења о узроцима конфигурисана да исправљају инциденте. А ова ограничена обавештења о чињеници шта се догодило стварају лажни осећај сигурности, јер систем сваки пут измишља нове начине за разбијање.
Немојте да вас заварају обавештења о узроку. Боље размисли:
- Зашто обавештење засновано на симптомима није приметило проблем?
- Да ли би било корисно побољшати контекст за корисника?
- Како се алати за праћење могу побољшати да би дијагноза била бржа, а не да се гомилају обавештења о томе шта се догодило?
Алати за праћење за дијагнозу помоћи ће само ако их сматрате начином да пређете од симптома до решења. Без ових повратних информација, једноставно ћете бити бомбардовани касним обавештењима и графиконима о прошлим неуспесима — а ни речи о будућим. Ово је одлична прилика за организацију да пређе из одбране у напад. И програмери и менаџери производа ће имати иста очекивања и јасне циљеве. Случај - СЛУЧАЈ (:винк:) - је јасан за свако обавештење.
Обавештења заснована на разлозима су подношљива у умереним количинама
Понекад нам наш систем оставља мало избора у погледу обавештења заснованих на узроку. А понекад дежурни савршено разумеју да ће симптом дефинитивно довести до неуспеха, па стога има практичну вредност. Можда једноставно нисте сигурни шта се дешава и подешавате обавештења како бисте били сигурни. Надамо се да је ова радња привремена док не променимо систем да бисмо решили проблем са перформансама.
Имајте на уму друге компоненте ЦАСЕ-а када се бавите овим ситуацијама. Само зато што је привремено не значи да можете престати да размишљате својом главом.
Оцењено – евалуација
Било какве промене система (нови код, нова инфраструктура, било шта ново) проширују опсег кварова (Цоок, 3). Да ли ово обавештење и даље функционише како се очекује? Јасни и актуелни ментални модели система и искуство реаговања на нека обавештења подршке - ово су кључне карактеристике . Дефекти у системима се стално развијају и ми морамо да их пратимо.
Морате стално да процењујете квалитет сваког обавештења како бисте били сигурни да функционише како се очекује. Поштовани лидери! Вашим тимовима ће бити много лакше ако им помогнете да успоставе овај процес! Ево неколико идеја за процену:
- Користите , или друге методе тестирања обавештења. Тим може то да уради сам без потребе да се ослања на тежак систем управљања инцидентима!
- Укључите колекцију свих обавештења у вези са инцидентима у свој програм управљања инцидентима. Означите корисно, штетно, неприкладно, нејасно итд. Користите их као повратну информацију.
- Права обавештења се ретко покрећу и пажљиво се тестирају. Уверите се да све везе раде, да упућују на прави контекст итд.
- Ако се обавештење никада не покреће или покреће пречесто, нешто није у реду са њим. Поправите или уклоните. Чувајте се претеране пасивности или активности!
- Подесите временске ознаке обавештења са датумима истека. Ако је датум истека истекао, процените обавештење користећи ЦАСЕ методу и ажурирајте временску ознаку. Као и храна, редовно проверавајте рок трајања.
- Поједноставите процес побољшања обавештења. Користите надгледање као код и чувајте обавештења у Гит спремишту. Захтеви за повлачење помажу да се ангажује тим и дају вам историју прошлих обавештења. И више се нећете плашити да мењате обавештења или тражите дозволу од оних који су за њих одговорни.
- Подесите повратне информације за обавештења, чак и ако су једноставне , тако да дежурни означавају обавештења као бескорисна или наметљива. Уградите везу или позив на акцију у само обавештење и редовно прегледајте своје повратне информације.
- Успоставите правило у тиму – нека раде дежурни да би се упростило дежурство када је мало посла. Нека све после тебе буде мало боље него пре.
Закључак
Верујем да метода ЦАСЕ помаже програмерима и организацијама да разговарају о постављању и слању аутоматизованих обавештења. Један програмер може почети да процењује обавештења користећи ЦАСЕ метод, а затим ће се цела организација придружити другим програмерима, менаџменту и програмима за управљање инцидентима како би обавештења одржала у добром стању. Ово не захтева никакве посебне алате или сложене процесе.
Цела индустрија треба да размишља о људском фактору док је на дужности без жртвовања врхунске корисничке услуге. Сви ови алати и праксе могу и треба да се побољшају. Надам се да ће ЦАСЕ метода помоћи у овоме.
Уживајте у побољшаним обавештењима!
Извор: ввв.хабр.цом