Quindi ecco la questione riguardo a SLA e SLO: sono *obiettivi.* I team fanno del loro meglio per rispettarli e storicamente spesso ci riescono. Quando un'interruzione supera lo SLO, l'azienda che li promette potrebbe dover pagare contrattualmente una penale. Ma questo è software... possono succedere cose inaspettate!
Abhimanyu
Abhimanyu25 ott, 01:48
Come ingegneri backend, spesso consideriamo AWS DynamoDB/S3 e la loro disponibilità di quattro 9 come un dato di fatto. Ma il blackout di 14 ore ci ha ricordato che i valori pubblicizzati ≠ realtà. Progetta sempre sistemi di sicurezza per i sistemi critici!
Alla fine, si tratta di gestione del rischio: 1. Quanto tempo di attività promette il fornitore e quanto puoi fidarti di loro? 2. Quanto impatto avrebbe sulla tua attività se il SLO venisse violato? Qual è il tuo piano B quando ciò accade (interruzione del fornitore). Hai anche un piano B?
Il software diventa piuttosto caotico rispetto ad altre industrie, e dobbiamo essere in grado di gestire questo disordine, convivere con esso, domarlo e trovare modi per lavorarci attorno. È tutto perché il software è in continua evoluzione! Onestamente, è qualcosa che rende l'ingegneria del software davvero impegnativa e +eccitante!!
42,19K