Философия SRE: Без ошибок невозможно развитие (error budgets drive innovations).

Четвертый, и, пожалуй, наиболее, неочевидный пост об очевидном :) Дисклеймер: личное мнение.

В посте “Надежда - это не стратегия” комментаторы справедливо заметили, что предусмотреть и запланировать всё на свете невозможно. Очевидно, что абсолютно надежные системы невозможны. Стопроцентной надежности нельзя требовать не только от людей, но и от роботов. Да-да, роботы тоже не обязаны быть совершенными.

Да это совершенство и не нужно. Почему?

Зайдем с классического SRE-шного понимания. 

Вот есть серверные программы, они запущены на серверах. Сервера - это такие набитые электроникой коробки. На электросети к ним, конечно, стоит защита от скачков напряжения, в помещении с ними поддерживается оптимальная температура и влажность, но даже если в датацентр не прилетает брат Челябинского метеорита, обеспечить сто процентов надежности нельзя. Это не сферический конь в вакууме облаке, это материальная физическая система, которая, как минимум, подвержена износу. Конечно, за аппаратурой надо следить, вовремя заменять (можно заменять железо не отключая сервер), и так далее, далее, наращивать надежность. В реальных компьютерных системах можно добиться очень высокой надежности. Банальный пример из SRE Book: вы ведь тоже иногда проверяете наличие интернета открытием главной страницы поисковика, мм? Впечатляющая надежность, не так ли?

И у такой надежности есть своя темная сторона. Даже две.

Во-первых, если вы требуете от системы зашкаливающей надежности, вам очень сложно что-то в ней изменить. 

Изменения - один из главных источников сбоев. 

По-простому из SRE: выкатываете вы обновление на сайт, а там конфигурация тестовой базы данных, а не основной, или еще что-нибудь в этом роде. 

По-простому из жизни: все мы сталкивались с такими людьми, у которых есть очень жесткие правила, например, в доме у каждой вещи должно быть свое место. Становится сложно избавиться от старых вещей или добавить новую :) 

Менее глупый пример: люди, которые долгое время живут одни, рано или поздно выстраивают свой быт так, что добавить туда на постоянной основе другого человека чертовски трудно.

Во-вторых, и это, пожалуй, менее очевидно, если у вашей системы зашкаливает надежность, авторы других систем, которые её используют и полагаются на нее, начинают пренебрегать защитой от сбоев со стороны вашей системы.

Это значит, что, навернувшись (или даже чуточку снизив зашкаливающую надежность по причине планового обновления), ваша система вызовет каскадный сбой. 

Пример из SRE: не полагайтесь на файловую систему или БД на хостинге, делайте бэкапы! 

Пример из жизни: гиперответственные люди, которые могут сделать всё хорошо и сами, взваливают на себя кучу задач, как на работе, так и в жизни, на них замыкается куча цепочек, окружающие привыкают полагаться на них на все сто… А потом они простывают в самый неподходящий момент. Или уходят на другую работу. Красивая, но негуманная метафора - фактор автобуса.   

Как с этим жить?  

Ненадежность невозможно запретить. Поэтому ее нужно возглавить!

Надежность технических систем SRE измеряют в девятках. Конечно, у всего этого есть мат. модель, строгие определения и всё такое (интересующимся сюда), здесь я хочу привести только суть: пусть система выполняет какие-то операции, и 99.9% из запросов обрабатываются успешно, а 0.1% - ошибки. Тогда фактическая надежность этой системы - три девятки. Если процент отказов - только 0.001%, то надежность - 99.999%, то есть пять девяток.

Разумеется, в реальности цифры не бывают такими красивыми и точными, но для компьютерных систем производится оценка и устанавливается два порога: гарантированный уровень надежности (SLA, service level agreement) и целевой уровень надежности (SLO, service level objective). Если техническая система не соответствует SLA, наступают штрафные санкции. 

SLA - это минимальный уровень надежности, который система будет обеспечивать. SLO - это максимальный уровень надежности, на который пользователи системы могут рассчитывать. 

То есть, пользователи не должны ожидать, что система будет работать лучше, чем SLO. На практике, технические системы часто работают лучше, чем SLO. У SRE даже есть практика кратковременного снижения надежности до декларированного SLO, чтобы пользователи не полагались на систему слишком сильно (это называется DiRT-test). Хотя добавить ещё одну девятку в SLO хочется всем.

Число, обратное SLO, называется бюджетом ошибок. Он используется на развитие системы и на случайные сбои. Например, если сбоев было слишком много, то всё, обновления в этом квартале не будет :)

Право на ошибку - это такой же ресурс, как время или финансы. Планируйте его использование!

Всё это замечательно, но что же в жизни?

Разрешайте себе и другим ошибаться! Определите, какой уровень надежности для окружающего вас мира готовы предоставить именно вы. Пересматривайте этот уровень регулярно и по возможности повышайте, если ресурсы позволяют.

Людям свойственно занижать надежность окружающих. Обсуждайте проблемы и помогайте эту надежность повысить (см. примеры в “Люди ненадежны”, а ещё будет пост “Не обвиняйте”).

Иногда мы сами не замечаем своей ненадежности. Оцените свою ненадежность, договоритесь об уровне надежности хотя бы с самим собой. Делайте это явно и систематически. Старайтесь быть объективными. Всегда лучше знать масштаб проблемы. В чем ваша ненадежность? Вы не выполняете дела в срок, опаздываете на встречи? Найдите, в чем вы ненадежны. Найдите причины: вы перегружены, вам не нравится то, что вы делаете, и т.д.? Подумайте, какой уровень надежности является достаточным. Возможно, имеет смысл обсудить это с окружающими.

Иногда мы сами супер-надежны. Атланты, которые держат небо на каменных руках. Это делает надёжность мира вокруг таких героев очень хрупкой. У меня будет отдельный пост про то, как важно не быть героем в обычной жизни, не работать на износ, не обеспечивать зашкаливающую надежность. И стараться не стоить системы (бизнес, семью, что угодно) на основе одного супер-надежного человека. Системы с единой точкой отказа, даже супер-надежной - ненадежны. Распределяйте свою надежность. 

Делать всё самим - это снижать надежность мира вокруг вас! Хрупкие системы не могут жить долго и не могут развиваться.

Комфортный мир, в котором приятно жить, строится не на крайностях (беспредел vs синдром отличника), а на балансе бюджета ошибок.

И да, иногда люди будут воровать ваше право на ошибку так же, как ваши деньги... А иногда вы будете проматывать его и влезать в долги... Интересная метафора, не так ли?

А как вы оцениваете свой уровень надежности? Готовы ли вы стать менее надежными, если это повысит надежность (адекватность и предсказуемость) мира вокруг вас? Пытались ли вы управлять бюджетом ошибок?

Ещё про философию SRE