Implicit SLOs and their dangers – краткие выводы
Привет, %username%! Мне тут попалась статья "Implicit SLOs and their dangers" от одного из авторов книги "Site Reliability Engineering. How Google runs production systems" – Niall Murphy. Я ее кратенько пробежал по диагонали, обдумал малость и вот такие выводы могу озвучить.
- Неявные SLO — это когда люди просто привыкают к тому, как надежно работает сервис, и этого от него и ждут. Это как бы негласное соглашение.
- Если вы меняете SLO, будь то явный (прописанный в договоре) или неявный (тот, к которому все привыкли), это может создать проблемы: 1. Если вдруг сервис стал слишком надежным, это может сломать то, что пользователи настроили для работы с менее надежным сервисом. У них там, может, хитрые кэши, обработка ошибок, повторные попытки — все это теперь может начать барахлить, и им придется переделывать свою инфраструктуру. В общем, это может ударить по карману. 2. Если же надежность сервиса упала, то людям придется срочно строить новую инфраструктуру и исправлять старые проблемы. Это им, конечно, не понравится.
- Часто люди ориентируются не на то, что написано в договоре, а на то, как сервис на самом деле работает. Даже если вы ничего не обещали, кто-то наверняка будет зависеть от реальной работы системы.
- Самое плохое — когда реальная надежность сервиса сильно отличается от того, что люди ожидают. Например, если в договоре одно, а по факту другое. Или когда вы резко меняете то, как предоставляете сервис.
- Важно постоянно общаться с теми, кто пользуется вашим сервисом, особенно когда происходят изменения. Это поможет избежать проблем и сохранить доверие.
- Вот пример из жизни SRE: Google специально делала свои слишком надежные сервисы менее надежными, чтобы не создавать завышенных ожиданий и не лезть в чужие дела.
- Есть такое правило Хайрума Райта, которое отлично подходит для SLO: Все, что можно заметить в вашей системе, кто-нибудь обязательно будет использовать. Это касается и надежности;
- Главное, что нужно запомнить: то, что люди ожидают от сервиса, может быть даже важнее формальных SLO. И если вы собираетесь что-то менять, обязательно расскажите об этом пользователям, чтобы они не были в шоке и не потеряли к вам доверие.
А у тебя в команде есть такие неявные SLO, про которые вроде никто не договаривался, но все их ждут? Расскажи, как с этим живете – особенно если вдруг сервис стал надежнее или наоборот просел по надежности.
#SRE #SLO #DevOps #Reliability #EngineeringCulture #SystemDesign #ImplicitSLO
