Então, aqui está a questão sobre SLAs e SLOs: eles são *metas.* As equipas fazem o seu melhor para cumpri-las e, historicamente, muitas vezes conseguem. Quando uma interrupção ultrapassa o SLO, a empresa que as promete pode precisar de pagar uma penalidade contratual. Mas isto é software... coisas inesperadas podem acontecer!
Abhimanyu
Abhimanyu25/10, 01:48
Como engenheiros de backend, muitas vezes aceitamos o AWS DynamoDB/S3 e a sua disponibilidade de quatro 9s como garantidos. Mas a interrupção de 14 horas nos lembrou que os valores comercializados ≠ realidade. Sempre projete sistemas de segurança para sistemas críticos!
No final, tudo se resume à gestão de risco: 1. Quanto tempo de atividade o fornecedor promete e quanto você pode confiar nele? 2. Qual seria o impacto no seu negócio se o SLO fosse violado? Qual é o seu plano B quando isso acontece (interrupção do fornecedor)? Você tem um plano B?
O software fica bastante confuso em comparação com outras indústrias, e precisamos ser capazes de gerenciar essa confusão, conviver com ela, domá-la e contorná-la. É tudo porque o software está em constante mudança! Honestamente, é algo que torna a engenharia de software realmente desafiadora +empolgante!!
41,5K