Dziiiiin! Kell on 3 öösel, sa näed imelist und ja järsku tuleb kõne. Olete sel nädalal valves ja ilmselt juhtus midagi. Automatiseeritud süsteem helistab, et teada saada, mis viga. See on tänapäevaste arvutisüsteemide haldamise oluline aspekt, kuid vaatame, kuidas märguandeid inimeste jaoks paremaks muuta.
Tutvuda seirefilosoofiaga, mis on sündinud mitme aastakümne jooksul minu tööülesannetest erinevates seiremeeskondades. Teda mõjutas suuresti Rob Evaštšuki tõeline piibel (Minu teavitusfilosoofia), mis on lisatud raamatusse , ja John Alspaughi raamat (Märkused hoiatuste seadistamise kohta).
, и — täname abi eest postituse redigeerimisel.
Mis on CASE?
Otsustasin välja mõelda ilusa lühendi nagu või . Ma kutsun seda CASE meetod. Ta kirjeldab nelja punkti, millele automaatse monitooringuga töötades tähelepanu pöörata:
- (kontekstiga seotud)
- (praktiline väärtus)
- (rõhk sümptomitel)
- (hinne)
Kui kasutate CASE-i, suhtute teavitustesse terve ükskõiksusega ega ärata inimesi öösel üles. Seire kasulikkust ja tõhusust tuleks regulaarselt hinnata. Kui inimene saab teate, on tal paremad vaimsed mudelid ja suurem enesekindlus.
Et seda oleks lihtsam meeles pidada, kujutage ette, et vajate JUHTUMIST [st juhtumit, põhjust - tõlkija märkus] iga hoiatuse põhjendamiseks. :päikeseprillid:
Ja miks see kõik on?
. Paljudel põhjustel. Ja CASE ei kõrvalda neid kõiki. Kuid sellega ärkate öösel paremate märguannete peale. See meetod hõlmab erinevaid organisatsioonilisi protsesse, mis aitavad ka selles küsimuses.
RED ja USE meetodite ilu seisneb selles, et nende abiga me mitte ainult ei tea, kuidas töötada, vaid räägime ka omavahel ühte keelt. Loodan, et CASE-meetod muudab meie süsteeme kaitsvate, kuid meie kolleege hõivatud teatiste arutamise lihtsamaks.
Asi on selles, et peate looma oma organisatsioonis kultuuri, kus teatisi koheldakse terve ükskõiksusega. Teateid saab luua kindlal eesmärgil, kuid pole tõsi, et need hiljem väärtust ei kaota. Miks me selle teatise seadistasime? Kui kaua aega tagasi on selle kriteeriumid üle vaadatud? CASE abil saab neile küsimustele vastused leida.
Context-Heavy – konteksti sidumine
Kell 3 öösel ei ole parim aeg lugeda sõnumeid, mis sisaldavad palju nutikaid sõnu. Tõhusaks reageerimiseks vajate teavet. Ideaalis peaks see olema teave konkreetse probleemi kohta, mille kontekst on kohe selge, ja teated tuleks seadistada nii, et see oleks võimalik. See on "vaatlus" ja "orienteerumine". . Sellele seadistusele pole häbi aega kulutada, sest pidev inimese tähelepanu hajutamine on veelgi kallim. Austagem üksteist.
Probleemidel on palju allikaid. Eriti kummitused.
Kuidas saan korrapidajat aidata? Esimene asi, mida valveametnik näeb, on teatis, mistõttu ta koostab kõik hüpoteesid selle põhjal. Seejärel vaatab ta juhiseid ja armatuurlaudu, kuid kas konkreetse teatise kohta on alati andmed, mitte ainult üldine teave? Alspaugh soovitab "mõelda sellele, kuidas saaksite teatist tõlgendada või sellele vastata" (slaid 29). Hea märguanne keskendub tööl olevale inimesele, mitte ainult läve järgi konfigureeritud.
Siin on mõned ideed teavituskonteksti parandamiseks.
- Näidake kasutajale midagi kasulikku ja spetsiaalselt loodud, mitte ainult tavalisi juhiseid või armatuurlauda. Varem kasutasime poistega konkreetsete teatiste jaoks konfigureeritud uurivaid armatuurlaudu. See aitab, kui probleem on teada, kuid ajab teisi ainult segadusse. Siin tuleb leida tasakaal.
- Rääkige meile teatise ajaloost: kas see on uus? Kas see töötab sageli? Kas see on hooajaline?
- Kuva süsteemi oleku hiljutised muudatused. Kas midagi on viimasel ajal muutunud? (Näiteks juurutamine või funktsioonide lubamine/keelamine.)
- Näidake seoseid ja esitage mentaalse mudeli jaoks teavet: süsteemisõltuvused peaksid olema selgelt nähtavad, eelistatavalt koos funktsionaalsuse viitega.
- Ühendage kasutaja kiiresti meeskonnaga: kas ta näeb käimasolevaid intsidente või saab teada, kes veel ettevõttes on teate saanud? Programm aktiveeritud?
Ideaalis annab intsidentide haldamise programm nõu, kuidas parandada intsidentide uurimise teavitamise konteksti. Alati on, mille kallal töötada!
Tegutsetav – praktiline väärtus
Kas korrapidaja peaks teatele reageerides midagi ette võtma? Kui te ei pea midagi tegema või pole selge, mida teha, miks te ta üles äratasite? Peate vältima märguandeid, mis häirivad töölkäijaid ega nõua tegutsemist.
Mida ma peaksin tegema? Mida sa tahad?
Varem, kui süsteemid olid lihtsad ja meeskonnad väikesed, seadistasime jälgimise lihtsalt selleks, et asjadega kursis olla. Märguanne, et hunniku koormus on suurenenud, annab meile konteksti, kui teenus peaks hiljem rikki minema. Suures plaanis tekitavad sellised märguanded vaid segadust, sest meie süsteemid töötavad alati erineva raskusastmega halvenemise seisundis. See viib kiiresti selleni ja muidugi tundlikkuse kadu. Seetõttu eirab korrapidaja selliseid teateid või isegi filtreerib neid ega reageeri neile alati vastavalt vajadusele. Ärge langege sellesse lõksu! Ärge seadistage kõiki märguandeid järjest ja saatke need e-postiga mõnda jumalast hüljatud kausta.
Praktilise väärtusega teade näeb välja järgmine:
- Teatis nõuab tegevust, mitte lihtsalt uudistest teatamist.
- Seda toimingut on raske või riskantne automatiseerida. Kui toimingut saab automatiseerida, siis automatiseerige see, lõpetage inimeste kiusamine!
- Teatis sisaldab vormil kiireloomulisi soovitusi (SLA) või (RTO). Seejärel saab valveametnik aktiveerida organisatsiooni intsidentide haldamise programmi.
Tahan selgitada: ma ei väida, et teated peaksid tulema ainult API kõige olulisemate SLO-de (teenusetaseme eesmärkide) kohta. SLO monitooring on pidevalt killustatud ja jagatud ning nõuab sama lähenemist kõikidele teenustele. On selge, et jälgite teile maksvate klientide jaoks kõige olulisemaid SLO-sid. Kuid ka infrastruktuuri SLO-sid, näiteks andmebaase, tuleb jälgida. Varsti pead tegelema siseklientidega ja neid toetama. Ja nii edasi lõpmatuseni.
Sümptomitepõhine – rõhk sümptomitel
Kas teile meeldib või mitte, töötate hajutatud süsteemis (Kavaj). Selle tulemusena kasutate erinevaid taktikaid teenuste isoleerimiseks ja nende kaitsmiseks ebaõnnestumise eest (Trainor jt)3. Ja kuigi hilinenud prügivedu või seiskunud andmebaasipäring viitavad probleemidele, ei ole vaja kiirustada nende parandamisega, kui kasutajatel lähiajal probleeme ei teki.
Need on olulised signaalid ja võivad omada praktilist väärtust, kuid kui need kasutajaid ei häiri, siis ei ole saatja tähelepanu hajutamiseks piisavalt kiire. Põhjuspõhised teatised on meie vaimsete mudelite hetktõmmised süsteemi rikke kohta. Parem on jälgida olulisi sümptomeid, kui proovida loetleda kõik võimalikud ebaõnnestumise põhjused.
Märguannete tähenduslikuks muutmiseks keskenduge , kasutajatele oluline. Evaštšuk nimetab seda "kasutajate jälgimiseks". Pidage meeles, et seda filosoofiat tuleb rakendada kogu organisatsioonis. Kui mõnel teenusel on kusagil sügaval taristul kiireloomulised probleemid, tegeleb nende eest vastav meeskond. Süsteemide kaitsmine selliste rikete eest on täiesti eraldiseisev teema (Trainer et al., peatükk kriitiliste sõltuvuste minimeerimise strateegiate kohta).
Sümptomid ei ole nii varieeruvad
Richard Cook tuletab meile meelde, et keerulised süsteemid on täis vigu, puudusi ja probleeme. Kõigi võimalike põhjuste loetlemine on Sisyphose ülesanne. Üritad probleeme kirjeldada, kuid need muutuvad kogu aeg. Cindy Sridharan usub, et "süsteemid ei pea olema iga sekund ideaalses korras" ja parem on kasutada inimlikumat lähenemist ( (“Hajutatud süsteemide jälgimine”), 7).
Vältige teateid pärast vahejuhtumit
Tavaliselt on põhjuste teatised konfigureeritud juhtumite parandamiseks. Ja need piiratud teated juhtunu fakti kohta loovad vale turvatunde, sest süsteem pakub iga kord uusi viise, kuidas murda.
Ärge laske end eksitada põhjuste teadetest. Parem mõtle:
- Miks sümptomitepõhine teatis probleemi ei märganud?
- Kas oleks kasulik konteksti kasutaja jaoks parandada?
- Kuidas saab seiretööriistu paremaks muuta, et diagnoosida kiiremini, mitte koguda juhtunu kohta teateid?
Diagnoosimise jälgimistööriistad aitavad ainult siis, kui arvate, et need on viis sümptomilt lahenduseni liikumiseks. Ilma selle tagasisideta pommitatakse teid lihtsalt hiliste teadete ja graafikutega mineviku ebaõnnestumiste kohta ja mitte sõnagi tulevaste ebaõnnestumiste kohta. See on suurepärane võimalus organisatsioonile liikuda kaitsest rünnakule. Ja arendajatel ja tootejuhtidel on samad ootused ja selged eesmärgid. Juhtjuht – CASE (:wink:) – on iga teate puhul selge.
Põhjuspõhised teatised on mõõdukas koguses talutavad
Mõnikord jätab meie süsteem meile põhjuspõhiste teatiste osas vähe valikuvõimalusi. Ja mõnikord saavad töölolijad suurepäraselt aru, et sümptom viib kindlasti ebaõnnestumiseni ja seetõttu on sellel praktiline väärtus. Võib-olla pole te lihtsalt kindel, mis toimub, ja seadistate märguandeid ohutuse tagamiseks. Loodetavasti on see toiming ajutine, kuni saame jõudlusprobleemi lahendamiseks süsteemi muuta.
Nende olukordade lahendamisel pidage meeles teisi CASE-i komponente. See, et see on ajutine, ei tähenda, et saaksite oma peaga mõtlemise lõpetada.
Hinnatud – hindamine
Kõik süsteemi muudatused (uus kood, uus infrastruktuur, kõik uus) laiendavad tõrgete hulka (Cook, 3). Kas see teatis töötab ikka ootuspäraselt? Selged ja ajakohased süsteemide mentaalsed mudelid ja kogemus mõnele tugiteatisele vastamisel - need on peamised omadused . Süsteemide vead arenevad pidevalt ja me peame nendega sammu pidama.
Peate pidevalt hindama iga teatise kvaliteeti, et tagada nende ootuspärane toimimine. Kallid juhid! Teie meeskondadel on palju lihtsam, kui aitate neil seda protsessi luua! Siin on mõned hindamisideed:
- Kasutage , või muud teavituste testimismeetodid. Meeskond saab seda ise teha, ilma et peaks lootma raskele intsidentide haldussüsteemile!
- Kaasake kõigi intsidentidega seotud teatiste kogumine oma juhtumihaldusprogrammi. Märgi kasulikuks, kahjulikuks, sobimatuks, ebaselgeks jne. Kasutage neid tagasisidena.
- Õigeid teateid käivitatakse harva ja neid testitakse hoolikalt. Veenduge, et kõik lingid töötaksid, osutaksid õigele kontekstile jne.
- Kui teatis ei käivitu kunagi või käivitub liiga sageli, on selles midagi valesti. Parandage see või eemaldage see. Hoidu liigse passiivsuse või aktiivsuse eest!
- Määrake aegumiskuupäevadega teatiste ajatemplid. Kui aegumiskuupäev on aegunud, hinnake teatist CASE meetodil ja värskendage ajatemplit. Nagu toidu puhul, kontrollige aegumiskuupäeva regulaarselt.
- Lihtsustage teatiste täiustamise protsessi. Kasutage jälgimist koodina ja salvestage teatised Giti hoidlas. Tõmbetaotlused aitavad kaasata meeskonda ja annavad teile varasemate märguannete ajaloo. Ja te ei karda enam märguandeid muuta ega nende eest vastutavatelt isikutelt luba küsida.
- Seadistage märguannete jaoks tagasiside, isegi kui see on lihtne , nii et valveametnikud märgivad teated kasutuks või pealetükkivaks. Manustage teatisse link või üleskutse tegevusele ja vaadake regulaarselt oma tagasisidet.
- Kehtestage meeskonnas reegel – laske töölolijatel töötada, et töökohustusi lihtsustada, kui tööd on vähe. Olgu kõik pärast sind veidi parem kui enne.
Järeldus
Usun, et CASE-meetod aitab arendajatel ja organisatsioonidel arutada automatiseeritud teatiste seadistamist ja saatmist. Üks arendaja saab hakata teatisi hindama CASE-meetodil ja seejärel ühineb kogu organisatsioon teiste arendajate, haldus- ja intsidentide haldamise programmidega, et hoida teatised heas vormis. See ei nõua spetsiaalseid tööriistu ega keerulisi protsesse.
Kogu tööstus peab tööl olles mõtlema inimtegurile, ohverdamata tipptasemel klienditeenindust. Kõiki neid tööriistu ja tavasid saab ja tuleks parandada. Loodan, et CASE-meetod aitab selles.
Nautige täiustatud märguandeid!
Allikas: www.habr.com