Dziiiiin! Estas la 3-a matene, vi havas mirindan sonĝon, kaj subite estas voko. Vi deĵoras ĉi-semajne, kaj ŝajne io okazis. La aŭtomatigita sistemo vokas por ekscii kio estas malbona. Ĉi tio estas grava aspekto de administrado de modernaj komputilaj sistemoj, sed ni rigardu kiel plibonigi sciigojn por homoj.
Konatiĝu kun la monitora filozofio, naskiĝinta dum pluraj jardekoj de miaj devoj en malsamaj monitoraj teamoj. Ŝi estis plejparte influita per la reala biblio de Rob Evashchuk (Mia Sciigo Filozofio) inkluzivita en la libro pri , kaj libro de John Alspaugh (Notoj pri agordo de atentigoj).
, и — dankon pro via helpo en redaktado de la afiŝo.
Kio estas CASE?
Mi decidis elpensi belan mallongigon kiel aŭ . Mi nomas ĝin CASE metodo. Li priskribas kvar punktojn por atenti kiam vi laboras kun aŭtomata monitorado:
- (kunteksto ligita)
- (praktika valoro)
- (emfazo sur simptomoj)
- (grado)
Se vi uzas CASE, vi traktas sciigojn kun sana indiferenteco kaj ne vekas homojn nokte. Monitorado devus esti regule taksita por utileco kaj efikeco. Kiam persono ricevas la sciigon, ili havos pli bonajn mensajn modelojn kaj pli da konfido.
Por pli facile memori, imagu, ke vi bezonas KAZON [t.e. kazon, kialon - noto de tradukinto] por pravigi ĉiun atentigon. : sunokulvitroj:
Kaj kial ĉio ĉi estas?
. Pro multaj kialoj. Kaj CASE ne forigos ilin ĉiujn. Sed kun ĝi, vi vekiĝos nokte al pli bonaj sciigoj. Ĉi tiu metodo kovras diversajn organizajn procezojn, kiuj ankaŭ helpos en ĉi tiu afero.
La beleco de la metodoj RED kaj USE estas ke per ilia helpo ni ne nur scipovas labori, sed ankaŭ parolas la saman lingvon unu kun la alia. Mia espero estas, ke la CASE-metodo faciligos diskuti pri sciigoj, kiuj protektas niajn sistemojn sed okupas niajn kolegojn.
La afero estas, ke vi devas krei kulturon en via organizo, kie sciigoj estas traktataj kun sana indiferenteco. Sciigoj povas esti kreitaj por specifa celo, sed ne estas fakto, ke ili poste ne perdos valoron. Kial ni starigis ĉi tiun sciigon? Antaŭ kiom da tempo ĝiaj kriterioj estas reviziitaj? Kun CASE, ĉi tiuj demandoj povas esti responditaj.
Context-Heavy - kunteksta ligado
3 am ne estas la plej bona tempo por legi mesaĝojn kiuj enhavas multajn inteligentajn vortojn. Por respondi efike, vi bezonas informojn. Ideale, ĉi tio devus esti informo pri specifa afero, por kiu la kunteksto estas tuj klara, kaj sciigoj devus esti agordita tiel ke tio estas ebla. Ĉi tio estas "observo" kaj "orientiĝo" de . Ne estas domaĝe pasigi tempon pri ĉi tiu aranĝo, ĉar konstante distri homon estas eĉ pli multekosta. Ni respektu unu la alian.
Problemoj havas multajn fontojn. Precipe fantomoj.
Kiel mi povas helpi la deĵoran oficiron? La unua afero, kiun la deĵoroficiro vidas, estas sciigo, do li konstruas ĉiujn hipotezojn sur ĝia bazo. Poste li rigardas instrukciojn kaj panelojn, sed ĉu ĉiam estas datumoj pri specifa sciigo, kaj ne nur ĝeneralaj informoj? Alspaugh konsilas "pensi pri kiel vi povus interpreti aŭ respondi al la sciigo" (lumbildo 29). Bona sciigo estas koncentrita al la deĵoranto, ne nur agordita de sojlo.
Do jen kelkaj ideoj pri kiel plibonigi la sciigan kuntekston:
- Montru al la uzanto ion utilan kaj speciale kreitan, kaj ne nur ordinarajn instrukciojn aŭ panelon. Antaŭe, la infanoj kaj mi uzis enketajn instrumentpanelojn agorditajn por specifaj sciigoj. Ĉi tio helpos se la problemo estas konata, sed nur konfuzos aliajn. Ni devas trovi ekvilibron ĉi tie.
- Rakontu al ni la historion de la sciigo: ĉu ĝi estas nova? Ĉu ĝi funkcias ofte? Ĉu ĝi estas laŭsezona?
- Montru lastatempajn ŝanĝojn al la sistema stato. Ĉu io ŝanĝiĝis lastatempe? (Ekzemple, deplojo aŭ ebligi/malŝalti funkciecon.)
- Montru la rilatojn kaj havigu informojn por la mensa modelo: sistemaj dependecoj estu klare videblaj, prefere kun indiko de funkcieco.
- Rapide konektu la uzanton kun la teamo: ĉu ili povas vidi daŭrajn okazaĵojn aŭ ĉu ili povas ekscii kiu alia en la kompanio ricevis sciigon? Programo aktivigita?
Ideale, okazaĵa administradprogramo provizos konsilojn pri kiel plibonigi la sciigan kuntekston de okazaĵaj esploroj. Ĉiam estas io por labori!
Agebla - praktika valoro
Ĉu la deĵoranto faru ion responde al la sciigo? Se vi ne bezonas fari ion ajn aŭ estas neklare kion fari, kial vi vekis lin? Vi devas eviti sciigojn, kiuj ĝenas la deĵorantojn kaj ne postulas agon.
Kion mi devus fari? Kion vi volas?
En la pasinteco, kiam sistemoj estis simplaj kaj teamoj estis malgrandaj, ni starigis monitoradon nur por resti sur la supro de aferoj. Sciigo, ke la ŝarĝo sur la amaso pliiĝis, donos al ni kuntekston se la servo poste misfunkcias. Grandskale, tiaj sciigoj nur kreos konfuzon ĉar niaj sistemoj ĉiam funkcias en stato de degenero de diversa severeco. Ĉi tio rapide kondukas al kaj, kompreneble, al perdo de sentemo. Tial la deĵoroficiro ignoras aŭ eĉ filtras tiajn sciigojn kaj ne ĉiam respondas al ili laŭbezone. Ne falu en ĉi tiun kaptilon! Ne agordu ĉiujn sciigojn en vico kaj poste sendu ilin retpoŝte al iu forlasita dosierujo.
Jen kiel aspektas avizo kun praktika valoro:
- Sciigo postulas agon prefere ol simple raporti novaĵojn.
- Ĉi tiu ago estas malfacila aŭ riska aŭtomatigi. Se ago povas esti aŭtomatigita, tiam aŭtomatigu ĝin, ĉesu ĝeni homojn!
- La avizo enhavas urĝajn rekomendojn en la formo (SLA) aŭ (RTO). La deĵoroficiro tiam povas aktivigi la okazaĵadministradprogramon de la organizo.
Mi volas klarigi: mi ne diras, ke sciigoj devus veni nur por la plej gravaj SLO-oj (servonivelaj celoj) por la API. SLO-monitorado estas konstante fragmenta kaj dividita kaj postulas la saman aliron al ĉiuj servoj. Estas klare, ke vi spuros la plej gravajn SLO-ojn por la klientoj, kiuj pagas vin. Sed infrastrukturaj SLOoj, kiel datumbazoj, ankaŭ devas esti monitoritaj. Baldaŭ vi devos trakti internajn klientojn kaj subteni ilin. Kaj tiel plu ĝis infinito.
Simpto-bazita - emfazo sur simptomoj
Ĉu vi ŝatas aŭ ne, vi laboras en distribuita sistemo (Kavaj). Kiel rezulto, vi uzas malsamajn taktikojn por izoli servojn kaj protekti ilin kontraŭ fiasko (Trainor et al.)3. Kaj kvankam prokrastita rubkolekto aŭ bremsita datumbaza demando indikas problemojn, ne necesas rapidi por ripari ilin se uzantoj ne havos problemojn en proksima estonteco.
Ĉi tiuj estas gravaj signaloj kaj povas havi praktikan valoron, sed se ili ne ĝenas uzantojn, tiam ĝi ne estas sufiĉe urĝa por distri la deĵoranton. Kaŭzo-bazitaj sciigoj estas momentfotoj de niaj mensaj modeloj pri sistema fiasko. Pli bone estas spuri gravajn simptomojn ol provi listigi ĉiujn eblajn kaŭzojn de fiasko.
Por fari sciigojn signifajn, fokusu , grava por uzantoj. Evashchuk nomas tion "monitorado por uzantoj". Memoru, ke ĉi tiu filozofio devas esti aplikata tra la tuta organizo. Se servo havas urĝajn problemojn ie profunde en la infrastrukturo, la taŭga teamo prizorgos ilin. Protekti sistemojn kontraŭ tiaj fiaskoj estas tute aparta afero (Trejnisto et al., sekcio pri strategioj por minimumigi kritikajn dependecojn).
Simptomoj ne estas tiel variaj
Richard Cook memorigas al ni, ke kompleksaj sistemoj estas plenaj de difektoj, mankoj kaj problemoj. Provi listigi ĉiujn eblajn kialojn estas Sizifa tasko. Vi provas priskribi problemojn, sed ili ĉiam ŝanĝiĝas. Cindy Sridharan opinias, ke "sistemoj ne devas esti en perfekta stato ĉiun sekundon" kaj estas pli bone uzi pli homan aliron ( ("Monitorado de Distribuitaj Sistemoj"), 7).
Evitu sciigojn post okazaĵo
Tipe, sciigoj pri kaŭzoj estas agorditaj por korekti okazaĵojn. Kaj ĉi tiuj limigitaj sciigoj pri la fakto de kio okazis kreas falsan senton de sekureco, ĉar la sistemo ĉiufoje venas kun novaj manieroj rompi.
Ne trompiĝu per kaŭzaj avizoj. Pli bone pensu:
- Kial la simptom-bazita sciigo ne rimarkis la problemon?
- Ĉu estus utile plibonigi la kuntekston por la uzanto?
- Kiel oni povas plibonigi monitorajn ilojn por fari diagnozon pli rapide, anstataŭ amasigi sciigojn pri kio okazis?
Monitoraj iloj por diagnozo helpos nur se vi pensas pri ili kiel maniero movi de simptomo al solvo. Sen ĉi tiu sugesto, vi simple estos bombardita per malfruaj sciigoj kaj diagramoj pri pasintaj misfunkciadoj—kaj eĉ ne vorto pri estontaj. Ĉi tio estas bonega ŝanco por organizo moviĝi de defendo al atako. Kaj programistoj kaj produktaj administrantoj havos la samajn atendojn kaj klarajn celojn. La kazo - CASE (:wink:) - estas klara por ĉiu sciigo.
Kial-bazitaj sciigoj estas tolereblaj modere
Kelkfoje nia sistemo lasas al ni malmulte da elekto laŭ kaŭzaj sciigoj. Kaj kelkfoje la deĵorantoj komprenas perfekte, ke simptomo certe kondukos al malsukceso, kaj tial enhavas praktikan valoron. Eble vi simple ne certas, kio okazas kaj agordas sciigojn por esti sur la sekura flanko. Espereble ĉi tiu ago estas provizora ĝis ni povas ŝanĝi la sistemon por solvi la rendimentan problemon.
Konsideru la aliajn komponantojn de CASE kiam vi traktas ĉi tiujn situaciojn. Nur ĉar ĝi estas provizora ne signifas, ke vi povas ĉesi pensi kun via kapo.
Evaluated - taksado
Ajnaj ŝanĝoj al la sistemo (nova kodo, nova infrastrukturo, io ajn nova) pligrandigas la gamon de misfunkciadoj (Cook, 3). Ĉu ĉi tiu sciigo daŭre funkcias kiel atendite? Klaraj kaj aktualaj mensaj modeloj de sistemoj kaj sperto respondantaj al iuj subtenaj sciigoj - ĉi tiuj estas la ĉefaj trajtoj . Difektoj en sistemoj konstante evoluas, kaj ni devas sekvi ilin.
Vi devas konstante taksi la kvaliton de ĉiu sciigo por certigi, ke ili funkcias kiel atendite. Karaj gvidantoj! Estos multe pli facile por viaj teamoj se vi helpos ilin establi ĉi tiun procezon! Jen kelkaj taksaj ideoj:
- Uzu , aŭ aliaj sciigaj testaj metodoj. La teamo povas fari ĝin mem sen devi fidi je peza administradsistemo de incidentoj!
- Enmetu la kolekton de ĉiuj okazaĵ-rilataj sciigoj en vian okazaĵadministradprogramon. Marku utilaj, malutilaj, netaŭgaj, neklaraj, ktp. Uzu ilin kiel sugestojn.
- La ĝustaj sciigoj estas deĉenigitaj malofte kaj estas zorge testitaj. Certiĝu, ke ĉiuj ligiloj funkcias, indikas la ĝustan kuntekston, ktp.
- Se sciigo neniam pafas aŭ pafas tro ofte, estas io malĝusta kun ĝi. Ripari ĝin aŭ forigi ĝin. Gardu vin kontraŭ troa pasiveco aŭ agado!
- Agordu sciigajn tempomarkojn kun limdatoj. Se la limdato eksvalidiĝis, taksu la sciigon per la CASE-metodo kaj ĝisdatigu la tempomarkon. Same kiel manĝaĵo, kontrolu la limdaton regule.
- Simpligu la procezon de plibonigo de sciigoj. Uzu monitoradon kiel kodon kaj konservu sciigojn en Git-deponejo. Tirpetoj helpas engaĝi la teamon kaj doni al vi historion de pasintaj sciigoj. Kaj vi ne plu timos ŝanĝi sciigojn aŭ peti permeson de la respondecaj pri ili.
- Agordu komentojn por sciigoj, eĉ se ĝi estas simpla , tiel ke deĵoraj oficiroj markas sciigojn kiel senutilajn aŭ trudemajn. Enmetu ligilon aŭ vokon al ago en la sciigon mem kaj reviziu viajn komentojn regule.
- Establi regulon en la teamo - lasu tiujn deĵorantajn labori por simpligi la devon kiam estas malmulte da laboro. Ke ĉio post vi estu iom pli bona ol antaŭe.
konkludo
Mi kredas, ke la CASE-metodo helpas programistojn kaj organizojn diskuti pri agordo kaj sendo de aŭtomataj sciigoj. Unu programisto povas komenci taksi sciigojn per la CASE-metodo, kaj tiam la tuta organizo kuniĝos kun aliaj programistoj, administrado kaj okazaĵadministradprogramoj por konservi sciigojn en bona formo. Ĉi tio ne postulas specialajn ilojn aŭ kompleksajn procezojn.
La tuta industrio devas pensi pri la homa faktoro dum deĵoro sen oferi altnivelan klientservon. Ĉiuj ĉi tiuj iloj kaj praktikoj povas kaj devas esti plibonigitaj. Mi esperas, ke la CASE-metodo helpos ĉi tion.
Ĝuu plibonigitajn sciigojn!
fonto: www.habr.com