Merrni përgjegjësinë për shërbimin pas vendosjes
PërfunduarPërcaktoni sinjale të dobishme të shërbimit, vendime për incidentet, rikuperimin dhe mirëmbajtjen. Mbajeni të dukshme përgjegjësinë për funksionimin pasi gjenerimi i kodit përfundon.
Publikuar nga TaigaSi shkruajmë
Kontrolloni çfarë keni kuptuarNjë kontroll disponueshmërie kthen HTTP 200, por eksportet nuk përmbajnë regjistrime sepse autorizimi nuk funksionon. Çfarë tregon kjo?Bëni ushtrimin
Çfarë do të mësoni
- Përcaktoni një sinjal shërbimi nga këndvështrimi i përdoruesit.
- Ndani koordinimin e incidentit nga hetimi teknik.
- Planifikoni mirëmbajtjen dhe rikuperimin si përgjegjësi të vazhdueshme.
Përcaktoni shërbimin nga i cili varen përdoruesit
Vendosja e bën softuerin të disponueshëm. Funksionimi e mban të dobishëm ndërsa ndryshojnë përdoruesit, varësitë, trafiku dhe kërkesat. Një gjenerues kodi nuk e heq këtë punë të vazhdueshme.
Për një eksport imagjinar të të dhënave të klientëve, përdoruesve u duhet më shumë se një faqe e arritshme. U duhen regjistrimet e lejuara në formatin e kërkuar brenda një kohe të pranueshme. U duhet gjithashtu që shërbimi të parandalojë aksesin te të dhënat e një organizate tjetër.
Përcaktoni personin përgjegjës para publikimit. Regjistroni kush reagon jashtë orarit normal të punës nëse kjo është pjesë e angazhimit të shërbimit. Një furnitor mund të kryejë një pjesë të punës, por organizata ende ka nevojë për një rrugë të qartë vendimesh dhe komunikimi.
Zgjidhni sinjale që mbështesin veprimin
Një tregues i nivelit të shërbimit, ose SLI, mat një veti të përcaktuar të sjelljes së shërbimit. Një objektiv i nivelit të shërbimit, ose SLO, vendos një synim për atë tregues gjatë një periudhe të përcaktuar. Zgjidheni objektivin sipas nevojave të përdoruesve dhe aftësisë për ta mbajtur shërbimin në funksionim.
Udhëzimet SRE të Google shpjegojnë këtë qasje dhe përdorimin e buxhetit të gabimeve për vendimet e besueshmërisë. Mos kopjoni objektivin e një shërbimi tjetër pa kontrolluar kuptimin e tij. Udhëzimet për SLO, shembull politike të buxhetit të gabimeve.
Për eksportin, përcaktoni çfarë quhet kërkesë e vlefshme e përfunduar me sukses. Ndani refuzimet e pritshme nga dështimet e sistemit. Dokumentoni përjashtimet që një metrikë të mos përmirësohet thjesht duke fshehur kërkesat e vështira.
| Sinjali | Çfarë ndihmon të zbulohet | Kufizimi i rëndësishëm |
|---|---|---|
| Kontrolli publik i disponueshmërisë | Shërbimi nuk mund të arrihet | Nuk verifikon një rrjedhë pune pas hyrjes së përdoruesit |
| Përfundimi dhe vonesa e eksportit | Kërkesat e vlefshme dështojnë ose zgjasin shumë | Kërkon përkufizim të saktë të suksesit |
| Kontrollet e refuzimit të autorizimit | Një kufi kritik pëson regresion | Mbulon kushtet e testuara |
| Sinjalet e burimeve dhe varësive | Një shkak i mundshëm i brendshëm | Nuk përshkruan vetë ndikimin te përdoruesit |
Shmangni regjistrimin e eksporteve të plota për të përmirësuar dukshmërinë. Mblidhni minimumin e informacionit të nevojshëm për diagnostikimin e problemit dhe mbroni aksesin tek ai.
Përgatitni reagimin ndaj incidentit
Vendosni kush koordinon, kush heton dhe kush komunikon. Këto role mund të bashkohen në një ekip të vogël, por përgjegjësitë duhet të mbeten të qarta. Mbani një regjistër vëzhgimesh dhe veprimesh.
Udhëzimet e Google për reagimin ndaj incidenteve theksojnë koordinimin dhe komunikimin krahas zbutjes teknike të ndikimit. Një korrigjim teknikisht i saktë mund t’i lërë sërish përdoruesit të painformuar ose disa anëtarë të ekipit të reagimit të bëjnë ndryshime kundërshtuese. Reagimi ndaj incidenteve.
Një agjent mund të përmbledhë regjistrat ose të krahasojë hipotezat brenda kufijve të miratuar të të dhënave. Ai nuk duhet të fitojë autoritet të pakufizuar në prodhim sepse incidenti është urgjent. Përdorni një rrugë të përcaktuar për t’ua kaluar kërkesën personave përgjegjës kur nevojitet akses përjashtimor.
Ushtroni rikuperimin dhe financoni mirëmbajtjen
Testoni procedurën e rikuperimit me të dhëna imagjinare përfaqësuese. Identifikoni çfarë nuk mund të zhbëjë rikthimi i kodit, përfshirë regjistrimet e fshira ose mesazhet e dërguara tashmë. Regjistroni kohën dhe informacionin e kërkuar për të restauruar shërbimin.
Caktoni punën e vazhdueshme: përditësimet e varësive, shqyrtimet e aksesit, rinovimin e certifikatave kur zbatohet, ndryshimet e kapacitetit dhe korrigjimet e dokumentacionit. Një shërbim pa kapacitet mirëmbajtjeje grumbullon detyrime pasi përfundon buxheti i nisjes.
Pas një incidenti, zgjidhni përmirësime që trajtojnë shkaqet e vëzhguara. Lidhini me zbatimin dhe verifikimin. Kjo mbyll ciklin jetësor: evidenca nga funksionimi ndryshon atë që ekipi specifikon dhe ndërton më pas.
Bëni ushtrimin
Shkruani një shënim njëfaqësh funksionimi për eksportin imagjinar të të dhënave të klientëve. Përfshini një sinjal të lidhur me përvojën e përdoruesit, objektivin e tij, marrësin e njoftimit, një reagim të parë të sigurt, një kufi rikuperimi dhe personin përgjegjës për mirëmbajtjen. Thoni çfarë nuk mund të zbulojë monitorimi.
Shkarkoni fletën e punës (Markdown)Heqja e kësaj zgjedhjeje fshin të gjithë përparimin e ruajtur në këtë shfletues.
Përparimi mbetet në këtë shfletues. Pa llogari, pa gjurmim.
Burime dhe lexime të mëtejshme
- Google SRE: Implementing SLOs ↗
- Google SRE: Incident Response ↗
- Google SRE: Example Error Budget Policy ↗