Deci, iată chestia cu SLA-urile și SLO-urile: sunt *ținte.* Echipele fac tot posibilul pentru a le îndeplini și, din punct de vedere istoric, o fac adesea. Când o întrerupere încalcă SLO, compania care le promite ar putea fi nevoită să plătească o penalizare contractuală. Dar acesta este software... Se pot întâmpla lucruri neașteptate!
Abhimanyu
Abhimanyu25 oct., 01:48
În calitate de ingineri backend, luăm adesea AWS DynamoDB/S3 și disponibilitatea celor patru 9 la valoarea nominală. Dar întreruperea de 14 ore ne-a reamintit că valorile comercializate ≠ realitate. Proiectați întotdeauna dispozitive de siguranță pentru sistemele critice!
Totul ține de managementul riscului, în cele din urmă: 1. Cât timp de funcționare promite furnizorul și cât de mult poți avea încredere în el? 2, Cât de mult ar fi un impact asupra afacerii tale dacă SLO ar fi încălcat? Care este planul tău B când se întâmplă acest lucru (întreruperea furnizorului). Aveți măcar un plan B?
Software-ul devine destul de dezordonat în comparație cu alte industrii și trebuie să fim capabili să gestionăm această dezordine, să trăim cu ea, să o îmblânzim și să o ocolim. Totul pentru că software-ul este în continuă schimbare! Sincer, este ceva care face ingineria software cu adevărat provocatoare + interesantă!!
42,62K