This post is also available in English.
This post is also available in Espagnol.
Dacă te-ai aventurat vreodată în orașul SRE, există șanse foarte mari să fi întâlnit deja unele dintre personajele mele preferate: SLO, SLA și SLI. Sunt foarte asemănătoare, dar poartă pălării foarte diferite. Cu doar ultima literă care diferă, cine nu le-ar zăpăci?
Bonusul meu de Crăciun în acest articol este să te ghidez în acest labirint fără de sfârșit și să clarific cine este cine. Luând-le în ordinea apariției: SLO-urile sau obiectivele la nivel de serviciu ne spun care este ținta noastră pentru disponibilitatea sistemului. Dacă sunteți un SRE, probabil că nu trebuie să le definiți singur, aveți nevoie și de alți membrii din compania dumneavoastră care să vă ajute să selectați ceea ce este mai recomandabil și mai specific pentru organizația dumneavoastră. Concluzia este că trebuie să le aveți și trebuie să fie alese în raport cu SLA-urile la care s-a angajat compania ta. SLA-ul sau acordul privind nivelul de servicii promite că, dacă serviciul dvs. este sub un anumit nivel de disponibilitate pe care l-ați consimțit, atunci se va plăti un fel de penalizare. Practic, clientul își primește banii înapoi dacă SLA-urile scad sub un anumit prag.
Nu în ultimul rând, SLI-urile sau indicatorii de nivel de serviciu sunt utile, deoarece măsoară probele de succes ale sistemului dumneavoastră. Acest lucru se întâmplă prin observarea comportamentului serviciului dvs. și indicând dacă sistemul dumneavoastră a funcționat în cadrul SLO-ului pentru un anumit interval de timp.
Nu este aceasta o explicație aridă? Să ne aventurăm în ceva mai concret.
SLA este acordul pe care compania dumneavoastră îl încheie cu clienții dumneavoastră.
SLO-urile sunt obiectivele pe care trebuie să le atingă echipa ta pentru a îndeplini SLA-urile.
SLI-urile reprezintă cifrele reale ale performanței sistemului dvs.
Dacă ați definit SLO-uri proaste atunci practicile dvs. SRE, experiența clienților și cadrul DevOps se vor deteriora vizibil. Aveți nevoie de SLO-uri bine definite pentru a onora SLA-ul la care s-a angajat compania dumneavoastră și, odată ce aveți SLO-urile bine definite, veți avea nevoie și de SLI-uri bine definite pentru a măsura performanța sistemului dumneavoastră.
Destulă teorie: să vedem cum arată și cum se comportă un SLO rău versus un SLO bun.
Obiectivul SLO-ului RĂU:
Asigurați-vă că timpul de funcționare al aplicației este satisfăcător.
Valoarea SLO-ului RĂU:
Disponibilitate
Pragul SLO-ului RĂU:
Încercați să mențineți sistemul cât mai mult posibil.
Fereastra de observare a SLO-ului RĂU:
Monitorizare continuă fără interval de timp specificat.
Motivul SLO-ului RĂU:
Ne dorim ca sistemul să fie disponibil de cele mai multe ori.
Acum trecem la un SLO bun.
Obiectivul SLO-ului BUN:
Asigurați-vă că timpul de răspuns API corespunde așteptărilor utilizatorilor.
Valoarea SLO-ului BUN:
Timpul mediu de răspuns al punctelor finale API.
Pragul SLO-ului BUN:
Mențineți un timp mediu de răspuns de 200 de milisecunde pentru 95% din solicitările API.
Fereastra de observare a SLO-ului BUN:
Monitorizare continuă pe o perioadă continuă de 7 zile.
SLO-ul RĂU este rău pentru că: este vag și subiectiv, nu are metrici cuantificabile, are un prag nedefinit și nu are fereastră de observație.
Ceea ce face ca un SLO să fie bun: este specific și măsurabil, este centrat pe utilizator, este cuantificabil și realizabil și are un interval de timp definit.
Distingeți un SLO bine definit deoarece se concentrează pe un aspect crucial al calității serviciului, oferă claritate, măsurabilitate și alinierea cu așteptările utilizatorilor, care sunt elemente esențiale pentru monitorizarea și evaluarea eficientă a fiabilității serviciului.
Probabil vă întrebați unde se poziționează Elastic în cadrul definirii SLO-ului bun și rău. Odată cu actualizarea la versiunea 8.11 a lui Elasticsearch, promovăm SLO-urile chiar din interfața de utilizare, fiind organizate ca o listă de tablou de bord, care oferă utilizatorului un rezumat rapid a ceea ce se întâmplă în cadrul fiecărui SLO.
Utilizatorul primește un istoric a SLI-urilor în vizualizarea detaliată a unui SLO, diagrame de ardere (burn rates) a bugetului de erori și alertele active curente. De asemenea, SLO-urile sunt ușor de configurat în Kibana, folosind Stack Management.
Sper că v-am făcut suficient de curioși pentru a vă inspira în crearea propriilor dvs. SLO-uri și SLI-uri în Elasticsearch care vă vor ajuta să respectați pe deplin SLA-urile.
Vă doresc un Crăciun fericit!