Asumați-vă responsabilitatea serviciului după instalare

Definiți serviciul de care depind utilizatorii

Instalarea în mediu face software-ul disponibil. Operarea îl menține util pe măsură ce se schimbă utilizatorii, dependențele, traficul și cerințele. Un generator de cod nu elimină acest lucru continuu.

Pentru un export fictiv de clienți, utilizatorii au nevoie de mai mult decât o pagină accesibilă. Au nevoie de înregistrările permise în formatul cerut, într-un timp acceptabil. Au nevoie și ca serviciul să împiedice accesul la datele altei organizații.

Numiți responsabilul înainte de lansare. Consemnați cine răspunde în afara programului normal, dacă aceasta face parte din angajamentul serviciului. Un furnizor poate executa o parte din lucru, dar organizația are în continuare nevoie de un traseu clar pentru decizii și comunicare.

Alegeți semnale care susțin acțiunea

Un indicator de nivel al serviciului, sau SLI, măsoară o proprietate definită a comportamentului serviciului. Un obiectiv de nivel al serviciului, sau SLO, stabilește o țintă pentru acel indicator pe o perioadă precizată. Alegeți ținta pornind de la nevoile utilizatorilor și capacitatea operațională.

Ghidul SRE de la Google explică această abordare și folosirea unui buget de erori pentru deciziile de fiabilitate. Nu copiați ținta altui serviciu fără a-i verifica sensul. Ghidul SLO, exemplu de politică a bugetului de erori.

Pentru export, definiți ce înseamnă o cerere eligibilă reușită. Separați refuzurile așteptate de defecțiunile sistemului. Documentați excluderile, astfel încât un indicator să nu se poată îmbunătăți doar prin ascunderea cererilor dificile.

Evitați înregistrarea exporturilor complete în loguri pentru o vizibilitate mai bună. Colectați informațiile minime necesare diagnosticării problemei și protejați accesul la ele.

Pregătiți răspunsul la incidente

Decideți cine coordonează, cine investighează și cine comunică. Rolurile pot fi combinate într-o echipă mică, dar responsabilitățile trebuie să rămână clare. Păstrați o evidență a observațiilor și acțiunilor.

Ghidul Google privind răspunsul la incidente pune accent pe coordonare și comunicare alături de reducerea tehnică a impactului. O corecție tehnic corectă poate totuși lăsa utilizatorii neinformați sau mai multe persoane să facă modificări contradictorii. Răspuns la incidente.

Un agent poate rezuma loguri sau compara ipoteze în limitele aprobate pentru date. Nu trebuie să dobândească autoritate nerestricționată în producție deoarece incidentul este urgent. Folosiți o procedură definită de escaladare pentru accesul excepțional.

Exersați recuperarea și finanțați mentenanța

Testați procedura de recuperare cu date fictive reprezentative. Identificați ce nu poate anula revenirea codului, inclusiv înregistrările șterse sau mesajele deja trimise. Notați timpul și informațiile necesare restaurării serviciului.

Atribuiți lucrul continuu: actualizări de dependențe, verificări ale accesului, reînnoirea certificatelor unde este cazul, schimbări de capacitate și corecții ale documentației. Un serviciu fără capacitate de mentenanță acumulează obligații după epuizarea bugetului de lansare.

După un incident, alegeți îmbunătățiri care tratează cauzele observate. Legați-le de implementare și verificare. Astfel se închide ciclul de viață: dovezile operaționale schimbă ce specifică și construiește echipa în continuare.