Итак, вот в чем дело с SLA и SLO: это *цели.* Команды делают все возможное, чтобы их достичь, и исторически часто достигают. Когда сбой нарушает SLO, компания, обещающая их, может быть обязана контрактно выплатить штраф. Но это программное обеспечение... неожиданные вещи могут произойти!
Abhimanyu
Abhimanyu25 окт., 01:48
Как инженеры бэкенда, мы часто воспринимаем AWS DynamoDB/S3 и их доступность на уровне четырех девяток как данность. Но 14-часовой сбой напомнил нам, что рекламируемые значения ≠ реальность. Всегда проектируйте резервные системы для критически важных систем!
В конечном итоге все сводится к управлению рисками: 1. Какую доступность обещает поставщик, и насколько вы можете им доверять? 2. Какой ущерб понесет ваш бизнес, если будет нарушен SLO? Каков ваш план Б в этом случае (выход из строя поставщика)? У вас вообще есть план Б?
Программное обеспечение становится довольно запутанным по сравнению с другими отраслями, и нам нужно уметь управлять этой запутанностью, жить с ней, укрощать её и находить способы обойти её. Всё это потому, что программное обеспечение постоянно меняется! Честно говоря, это то, что делает разработку программного обеспечения действительно сложной и в то же время захватывающей!!
35,05K