Regjistrime
Regjistrime të ndara, të vulosura me kohën, të ngjarjeve individuale — sinjali më i imët, i dobishëm për rindërtimin e saktë të asaj që ndodhi.
Monitorimi & Optimizimi · Hapi 06 · Faza Përfundimtare · Si Punojmë
Softueri në funksionim nuk është softuer i përfunduar.
Një sistem nuk kuptohet vetëm sepse po funksionon. Ai kuptohet sepse vëzhgohet, matet dhe përmirësohet në mënyrë të vazhdueshme bazuar në prova. Kjo fazë përfundimtare mbyll ciklin e metodologjisë OpenQCore — provat që ajo prodhon bëhen pika nisëse për pyetjen tjetër që ia vlen të hetohet.
Jo kjo pyetje
"A është sistemi ende në funksion?"
Kjo pyetje, në vend të kësaj
"A e kuptojmë me të vërtetë se si sillet ky sistem nën kushtet reale me kalimin e kohës — dhe a po udhëheq kjo kuptim drejt përmirësimit të vazhdueshëm, apo thjesht po konfirmon që asgjë nuk është prishur?"
Vëzhgueshmëri · Përgjigje ndaj incidenteve · Përmirësim i vazhdueshëm · Dëshmi · Reagime
Pse monitorimi pason vendosjen
Gatishmëria operative është një pikënisje, jo një gjendje përfundimtare.
Vendosja dhe aktivizimi konfirmojnë se një sistem funksionon në mënyrë të sigurtë dhe se personat përgjegjës për të janë të përgatitur. Ato ende nuk prodhojnë një kuptim të vazhdueshëm, të bazuar në dëshmi, mbi mënyrën se si sillet ai sistem ndërsa përdorimi i vërtetë, të dhënat reale dhe kushtet reale akumulohen me kalimin e kohës. Ai kuptim është qëllimi i kësaj faze.
Gatishmëria operative → Vëzhgueshmëria e vazhdueshme
Pse ka rëndësi disiplina e vëzhgueshmërisë
Katër sinjale tregojnë nëse një sistem është me të vërtetë i shëndetshëm.
Rishikimi Site Reliability Engineering i Google (2016) — e njëjta literaturë hulumtuese e referuar në fazën e mëparshme — identifikon katër sinjale që konsiderohen të mjaftueshme, nëse monitorohen mirë, për të kuptuar gjendjen e shumicës së sistemeve: sinjalet e arta.
Latenca
Koha që kërkohet për të shërbyer një kërkesë — duke dalluar përgjigjet e suksesshme nga ato të dështuara.
Trafiku
Kërkesa që i bëhet sistemit, matet në terma të rëndësishëm për funksionin e tij.
Gabime
Shkalla e kërkesave që dështojnë, qoftë në mënyrë eksplicite, qoftë për shkak të rezultateve të pasakta.
Saturimi
Sa afër është sistemi me kufijtë e burimeve të tij, dhe sa margjinë mbetet.
Beyer, Jones, Petoff & Murphy (red.), Site Reliability Engineering (2016).
Tre shtyllat e vëzhgueshmërisë
Të dhënat nuk janë e njëjta gjë me kuptimin.
OpenQCore strukturon vëzhgueshmërinë rreth tre llojeve plotësuese të të dhënave — një kornizë e përdorur gjerësisht në industrinë e teknologjisë dhe e formalizuar në projektin OpenTelemetry (një standard i hapur i hostuar nga CNCF) dhe në Distributed Systems Observability të Cindy Sridharan (2018).
Metrikat
Matje numerike të agreguara gjatë kohës — efikase për zbulimin e trendeve dhe aktivizimin e alarmeve.
Gjurmët
Rruga që ndjek një kërkesë e vetme përmes komponentëve të shpërndarë — thelbësore për të kuptuar ku ndodhin vonesat dhe dështimet në sisteme komplekse.
Nga sinjalet tek kuptimi
Të dhënat e papërpunuara nuk kanë vlerë derisa të interpretohen.
Regjistrimet, metrikat dhe trasat nuk janë, vetë për vete, njohuri. Ato bëhen të dobishme kur organizohen në panele që zbulojnë modele, alarme që nxjerrin në pah çfarë kërkon vëmendje, dhe në fund një kuptim që mund të udhëzojë një vendim.
Alarmim pa lodhje
Një alarm që askush s'e beson është një alarm që askush s'e lexon.
Një mënyrë e dështimit të dokumentuar mirë në ekipet e operacioneve — shpesh e quajtur lodhje nga alarmet — ndodh kur njoftimet bazohen në çdo devijim nga një numër në vend se në ndikimin e vërtetë ndaj përdoruesve ose sistemit. Rezultati është një volum i madh alarmesh që në fund injorohen, përfshirë edhe ato që kanë rëndësi.
Alarmim i Bazuar në Simptoma
Alarmet shkaktohen nga një ndikim i dukshëm — një simptomë që prek përdoruesin — dhe jo nga ndonjë metrikë e brendshme që del jashtë një intervali.
Pragje të Veprueshme
Një alarm ekziston vetëm nëse ka një veprim specifik, të përcaktuar që dikush duhet të ndërmarrë si përgjigje.
Ritmi i Rishikimit të Alarmave
Rregullat e alarmit rishikohen rregullisht dhe hiqen kur nuk tregojnë më një gjendje të vërtetë dhe të veprueshme.
Përgjigje ndaj incidenteve & postmorteme pa fajësim
Kuptoni sistemin, jo të gjeni faj.
Kur ndodh një incident, përgjigja e OpenQCore ndjek një praktikë të dokumentuar të postmortemëve pa fajësim — një koncept i formalizuar në Site Reliability Engineering të Google (2016) — në të cilën analiza përqendrohet në kushtet sistemike që lejuan të ndodhte një dështim, jo tek individi që ishte i përfshirë.
Ky dallim ka rëndësi praktike: ekipet që frikësohen nga fajësimi priren të raportojnë pak dhe të errësojnë kushtet që shkaktuan një dështim, gjë që e bën më të mundshme përsëritjen e të njëjtit dështim. Një proces pa fajësim është projektuar të nxjerrë në pah ato kushte me ndershmëri, pikërisht sepse kështu ato riparohen.
Cikël i Vazhdueshëm i Përgjigjes
Monitorimi nuk e mbyll metodologjinë. Ai e rinis atë.
Sinjalet e mbledhura gjatë monitorimit — tendencat e performancës, incidentet e përsëritura, devijimi i modelit, modelet e papritura të përdorimit — nuk raportohen dhe arkivohen thjesht. Ato bëhen prova që mund të justifikojnë rishikimin e përkufizimit të një problemi, vënien në dyshim të një supozimi arkitekturor, ose identifikimin e një problemi krejt të ri që vlen të hetohet.
Kjo është ajo që e mbyll metodologjinë me gjashtë faza të OpenQCore në një cikël në vend se një vijë të drejtë: provat e prodhuara në Monitorim & Optimizim rrjedhin përsëri në Hulumtim & Zbulim, ku procesi fillon sërish me baza më të forta se më parë.
Optimizimi i Performancës Kundër Bazës Referuese
Përmirësimi matet kundrejt të njëjtës bazë referuese që përcaktoi suksesin.
Puna e optimizimit vlerësohet kundrejt bazës referuese dhe kritereve të suksesit të vendosura gjatë Hulumtimit & Zbulimit — jo kundrejt një ndjenje të përgjithshme se një sistem është përmirësuar.
Krahasimi me Bazën Referuese
Performanca aktuale matet drejtpërdrejt kundrejt bazës referuese të regjistruar para se sistemi të ekzistonte në formën e tij aktuale.
Zbulimi i regresionit
Ndryshimet që përkeqësojnë një metrikë më parë të qëndrueshme identifikohen dhe hetohen, jo pranohen si një normal i ri.
Analiza e Tendencave të Kapacitetit
Tendencat e përdorimit të burimeve monitorohen për të parashikuar nevojat për shkallëzim para se të bëhen incident.
Monitorim i Modeleve dhe i Aspektit Specifik të AI
Sistemet e AI kërkojnë prova që monitorimi tradicional nuk i kap.
Në përputhje me analizën kontekstuale të rrezikut të prezantuar gjatë Hulumtimit & Zbulimit, komponentët specifikë për AI monitorohen për sinjale që monitorimi konvencional i aplikacioneve nuk i evidenton vetë.
Zbulimi i devijimit të modelit
Matje e vazhdueshme për të përcaktuar nëse performanca e një modeli përkeqësohet ndërsa të dhënat reale devijojnë nga ato kundrejt të cilave u ndërtua dhe u vlerësua.
Shkalla e ndërhyrjes njerëzore
Sa shpesh një rishikues njerëzor anulon një rekomandim ose vendim të gjeneruar nga AI — një sinjal i drejtpërdrejtë për vendet ku besueshmëria në sistem është, dhe nuk është, e justifikuar.
Rikalibrimi i vlerësimit
Rivlerësim periodik kundrejt provave të përditësuara, në vend që të mbështetesh pafundësisht në vlerësimin e kryer para vendosjes në përdorim.
Porta e rishikimit të optimizimit
Monitorimi përfundon me një vendim, jo vetëm me një panel kontrolli.
Evidenca e mbledhur gjatë monitorimit rishikohet periodikisht kundrejt një porte vendimmarrjeje të përcaktuar.
Vazhdo monitorimin
Sistemi po funksionon brenda parametrave të pritur — vëzhgimi vazhdon pa ndryshim të kursit.
Optimizim
Një përmirësim i saktë dhe i kufizuar justifikohet nga evidenca dhe mund të ndiqet pa rishikuar definicionin themelor të problemit.
Rikthim në Zbulim
Evidenca tregon për një problem më të gjerë se një optimizim — përgjigjja e duhur është kthimi te Kërkim & Zbulim me atë që është mësuar.
Pensiono
Evidenca tregon se sistemi më nuk justifikon kostot e tij të operimit në raport me vlerën që ofron.
Çfarë prodhon kjo fazë
Evidencë e vazhdueshme, jo një raport njëherësh.
Në varësi të shkallës së angazhimit, kjo fazë prodhon:
Paneli i vëzhgueshmërisë
Vizualizim në kohë reale i regjistrimeve, metrikave dhe gjurmëve të rëndësishme për shëndetin e sistemit dhe sinjalet kryesore.
Udhëzuesi i përgjigjes ndaj incidentit
Procedura të dokumentuara për t'u përgjigjur dhe për të zgjidhur incidentet operative.
Regjistrimet pas-incidentit
Analizë pa fajësim e incidenteve, shkaqeve të tyre sistemike, dhe ndryshimet që janë bërë si përgjigje.
Raporti i tendencave të performancës
Performanca e matur me kalimin e kohës kundrejt bazës fillestare dhe kritereve të suksesit.
Raporti i devijimit të modelit
Performanca e modelit e ndjekur kundrejt të dhënave reale dhe modeleve të përdorimit që evoluojnë.
Prapambetjet e Optimizimit
Mundësi për përmirësim të mbështetura nga evidenca, të prioritarizuara për punë të ardhshme.
Metodologjia mbyll ciklin
Evidenca bëhet pyetja e ardhshme.
Gjashtë fazat e OpenQCore — Hulumtim & Zbulim, Strategji & Arkitekturë, Dizajn i Zgjidhjes, Zhvillim & Integrim, Zbatim & Mundësim, dhe Monitorim & Optimizim — nuk formojnë një vijë të drejtë që përfundon këtu. Evidenca që prodhon kjo fazë bëhet pika fillestare për problemin e ardhshëm që ia vlen të hetohet, qoftë për të rafinuar sistemin aktual apo për të identifikuar një sistem krejt të ri.
Monitorim & Optimizim → Evidenca → Hulumtim & Zbulim
Hapi 01
Hulumtim & Zbulim
Ku fillon metodologjia — dhe ku evidenca e saj përfundimisht kthehet.
Referencat për Hulumtim dhe Metodologji
Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (red.) — Site Reliability Engineering: How Google Runs Production Systems (2016)
Burimi i sinjaleve të arta dhe koncepteve të postmortem pa faj të referuara më sipër.
Sridharan, C. — Distributed Systems Observability (2018); OpenTelemetry (CNCF)
Burimi i kornizës së tre shtyllave të observabilitetit të referuar më sipër.
NIST — Korniza e Menaxhimit të Rrezikut për Inteligjencën Artificiale (AI RMF 1.0)
Burimi i qasjes kontekstuale të rrezikut, të referuar në seksionin më sipër për monitorimin specifik të IA.