Антипаттерны SRE: Чего делать не стоит¶

Вы прочитали эту книгу. Вы знаете про SLO, error budget, blameless postmortem и принципы Google. Вы горите желанием внедрить SRE в своей компании.

Астанавитес!!! :)

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

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

Самый главный антипаттерн номер 1: SRE как "команда пожарных"¶

Руководство решает: "Наши продукты чаще падают, чем работают. Давайте наймем SRE, они будут сидеть и чинить все, что ломается, а еще будут заниматься problem-менеджментом и еще чем-нибудь, потом придумаем". Нанимают десяток инженеров, дают им доступ к консолям и говорят: "Теперь вы отвечаете за надежность".

В результате SRE превращаются в элитную службу спасения. Они тушат пожары днем и ночью, их дергают в каждый инцидент, они не успевают заниматься профилактикой, автоматизацией или архитектурными улучшениями. Разработчики рады: "Отлично, есть кому передать проблемы". Но на деле надежность не растет, потому что причины сбоев не устраняются.

SRE в своей классической формулировке это не команда чинильщиков или ремонтников. SRE это команда "не допускать аварий", а если авария случилась, то они должны "сделать так, чтобы это больше никогда не повторилось".

Когда SRE тушат пожары, а в свободное время занимаются еще чем-нибудь, они не борются с рутиной (toil). А если инженер тратит больше 50% времени на ручную работу и тушение пожаров, он перестает быть SRE по определению, он становится просто администратором на подхвате.

SRE должны иметь возможность сказать "нет". Нет, мы не будем чинить этот сервис вручную в пятый раз, мы напишем скрипт. Нет, мы не будем дежурить за этот сервис, пока разработчики не обеспечат минимальную наблюдаемость. Нет, мы не будем сидеть в чатах поддержки клиентов. Нет, мы не будем собирать встречи и пинать всех подряд для решения PRB.

Главная метрика успеха SRE не количество потушенных пожаров, закрытых проблем, написанных алетов, проверенных постмортемов, а количество пожаров, которые вообще не случились, и время, которое инженеры потратили на развитие, а не на тушение.

Представьте, что вы наняли врача, чтобы он сидел в вашей гостиной и ждал, пока с кем-то из семьи что-то не случится. Он быстро накладывает швы, всех спасает. Все счастливы. Но никто не убирает острые углы, не учит детей безопасности, не делает прививки. Но вы наняли не врача, вы наняли фельдшера скорой. SRE - это врач, который должен сделать так, чтобы скорая вызывалась как можно реже.

Очень важный антипаттерн 2: SLO как формальность или средство для отмазки¶

Вариант А. Команда пишет SLO просто потому, что "так надо". Выбирают 99,9%, потому что "все так делают и это красиво выглядит на слайдиках". Никто не проверяет, достигаются ли эти SLO, и что вообще означают эти цифры. SLO живут своей жизнью в документации, к которой никто не обращается.

Вариант Б. SLO превращается в дубину. Одна команда говорит другой: "Вы нарушили наш SLO, мы не можем релизить". Или руководитель использует SLO как инструмент наказания: "У вас SLO 99,5% в прошлом месяце, лишаем вас премии".

В варианте А SLO становятся бессмысленным бюрократическим ритуалом. Никто не принимает на их основе решений, никто не использует error budget. Это бесполезная трата времени и сил.

В варианте Б SLO убивают культуру сотрудничества. Разработчики начинают врать в метриках, чтобы показать хорошие цифры. Команды перестают помогать друг другу, потому что помощь другому означает риск для собственных показателей. Вместо общей цели "сделать продукт лучше" возникает внутренняя конкуренция. Цель - не соблюдать SLO с пользой для продукта, а "не получить оценку D на ревью".

SLO это инструмент для принятия решений, а не для отчетности. Error budget это не планка, за которую наказывают, а индикатор, который говорит: "сейчас риск слишком высок, давайте немного затормозим с изменениями и подкрутим надежность".

SLO должны быть согласованы с бизнесом. Если клиенту реально важно, чтобы сервис работал 24/7, SLO будет высоким. Если клиент может подождать час - SLO будет ниже. И тогда решения о нарушении SLO принимаются сообща, без обид и без страха наказания.

SLO это как стрелка уровня топлива: "пора заехать на заправку, иначе мы заглохнем". Вы не наказываете водителя за то, что загорелась лампочка уровня топлива. Вы останавливаетесь, разбираетесь, заправляетесь и едете дальше.

Антипаттерн 3: "У нас есть SRE и теперь мы можем не думать о надежности"¶

Разработчики с облегчением выдыхают: "Теперь за надежность отвечает SRE. Мы можем спокойно пилить фичи, пусть они следят, чтобы ничего не падало". Код пишется без учета наблюдаемости, без обработки ошибок, без тестирования. "Нам некогда об этом думать, нам надо пилить фичи, SRE разберутся".

SRE не могут сделать надежным то, что изначально спроектировано и реализовано плохо. Надежность закладывается на этапе проектирования, а не достраивается потом сверху.

Если разработчики не встраивают в свой код метрики, логи, трейсы, корректную обработку ошибок и таймауты, то тут SRE беспомощны. Они могут настроить инфраструктуру идеально, но если код сам по себе ненадежен, система будет падать.

Кроме того, в классической модели SRE, которую популяризировала Google, SRE не просто "следят", а разделяют ответственность с разработчиками. Разработчики сами дежурят по своим сервисам, сами видят боль своих ошибок. Это мотивирует писать более надежный код.

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

В идеальном мире разработчик на вопрос: "как я узнаю, что мой код сломался в проде?" отвечает сам, а SRE помогает ему построить правильную наблюдаемость.

SRE - это как инструктор по вождению. Он сидит рядом, помогает, страхует, показывает правильные движения. Но руль держит сам ученик. И если ученик из правого ряда поворачивает налево - инструктор может это предотвратить, и он может потом вместе с учеником разобрать ошибку и научить не делать так больше.

Антипаттерн 4: "Мы внедрим SRE за три месяца"¶

Руководитель ставит задачу: "К концу квартала у нас должна быть внедрена SRE-культура. Назначаем ответственного, пишем план. А то мои начальники будут ругаться". Через полгода пытаются подвести итоги, но ничего не изменилось, люди устали, а надежность не выросла.

SRE это не проект с фиксированным сроком. Это культурный сдвиг. Это изменение того, как команды работают, как принимают решения, как относятся к рискам и ошибкам.

Вы не можете "внедрить SRE" как новую CRM-систему. Вы можете начать применять SRE-практики: ввести SLO, начать проводить postmortem, автоматизировать рутину. Но чтобы это стало культурой, нужно время. Годы, а не месяцы.

Внедрение SRE должно быть итеративным. Начать с одного сервиса, одного пилотного проекта. Выбрать сервис, который достаточно важен, но не критичен настолько, чтобы ошибки стоили компании миллионов. Внедрить SLO, настроить наблюдаемость. Показать результат. Затем масштабировать на следующие сервисы.

Ожидания должны быть реалистичными. За три месяца можно сделать пилот. За год внедрить практики в нескольких ключевых командах. За три года изменить культуру в масштабах компании.

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

Антипаттерн 5: Blameless postmortem как "никто не виноват"¶

Проводится postmortem после крупного инцидента. Ведущий говорит: "У нас blameless культура, поэтому мы не ищем виноватого". Все сидят, рассказывают, что случилось. Записывают пункты действий. Расходятся. Никаких выводов о том, кто и почему принял неверное решение, не делается. Имена не называются, ответственность не фиксируется.

Blameless часто путают с безответственностью. Но blameless это не про "никто не виноват". Это про "мы ищем причины в системе, а не в человеке".

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

Blameless postmortem должен быть честным и конструктивным. Вместо вопроса "кто виноват?" задаются вопросы: "почему решение казалось правильным в тот момент?", "какие процессы или условия привели к тому, что ошибка стала возможна?", "что в системе мы должны изменить, чтобы следующий человек не совершил ту же ошибку?"

При этом корректирующие действия все равно назначаются на конкретных людей. Разница в том, что это не наказание, а зона ответственности за улучшение системы.

Если самолет упал из-за ошибки пилота, комиссия не говорит: "пилот дурак". Комиссия спрашивает: "почему пилот ошибся? может, он был переутомлен? может, приборы давали неверные данные? может, инструкция была неясной?" И после этого меняют правила, приборы, инструкции, чтобы ошибка не повторилась. Но ответственность за изменения все равно закрепляется за конкретными людьми.

Антипаттерн 6: Копирование практик у "взрослых" бездумно, без адаптации¶

Компания читает книги про SRE в Google, смотрит доклады и решает: "Мы тоже будем делать так же". Нанимают SRE, требуют, чтобы разработчики дежурили, внедряют сложные системы мониторинга, используют те же инструменты. И ничего не случается.

Google - это компания с масштабом, который не снился 99% бизнеса. У Google тысячи инженеров, миллиарды пользователей, собственные дата-центры по всему миру. То, что работает в Google, может убить небольшую компанию.

Например, Google требует, чтобы SRE составляли не более 50% от команды разработки. В компании с двумя разработчиками это означает одного SRE, что может быть неоправданно дорого. Google практикует, что разработчики сами дежурят по своим сервисам. В компании с одним разработчиком на сервис это означает, что человек будет на дежурстве 24/7, что приведет к выгоранию.

SRE-принципы универсальны. А вот SRE-практики - нет. Нужно адаптировать подходы под свой контекст: размер компании, критичность сервисов, бюджет, зрелость команды.

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

Представьте, что вы открываете кафе и решаете готовить, как в ресторане с тремя мишленовскими звездами. Вы покупаете редкие ингредиенты, нанимаете дорогого шефа, тратите полдня на оформление одной тарелки. Результат предсказуем, ваше кафе разорится через месяц. Вам нужны простые, вкусные блюда, которые можно приготовить быстро и продать с наценкой. При этом принципы из мишленовской кухни: качественные продукты, чистота, уважение к гостю остаются.

Антипаттерн 7: SRE только для "критических" сервисов¶

Компания решает: "SRE-практики будем применять только к самым важным сервисам, которые приносят деньги. Остальное как получится".

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

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

SRE-практики должны масштабироваться на все сервисы, но с разной глубиной. Критический платежный сервис требует SLO 99,99%, полноценного дашборда, сложной системы алертов и регулярных postmortem. Внутренний инструмент для аналитики может иметь SLO 99% и простой мониторинг. Но базовые вещи, такие, как наличие логов, базовых метрик, понятного процесса деплоя, отсутствие ручных операций должны быть везде, без исключения.

В больнице есть операционная, где требуется стерильность уровня, близкого к космической. Но это не значит, что в коридорах можно разводить грязь. Везде должна быть чистота, просто уровень требований к этой чистоте разный. Если в коридоре будет антисанитария, рано или поздно инфекция проникнет и в операционную.

Внедрение SRE это путь, на котором ошибки неизбежны. Но знание антипаттернов позволяет сделать эти ошибки менее болезненными и быстрее из них выходить.

Главное:

SRE это не про количество потушенных пожаров, а про их отсутствие. SLO это не наказание, а инструмент для решений. Ответственность за надежность разделена, а не переложена. Культура меняется годами, а не месяцами. Blameless не означает безответственный. Практики нужно адаптировать, а не копировать. И базовый уровень надежности нужен всем сервисам, а не только "приближенным".

Если вы узнали в этих антипаттернах свою компанию не отчаивайтесь. Все проходят через это. Главное вовремя остановиться, осознать и скорректировать курс. В этом и есть суть SRE: учиться на ошибках, но делать так, чтобы эти ошибки не повторялись.

Самый страшный антипаттерн - это думать, что ваша компания "единственная и особенная" и к ней эти антипаттерны не относятся. Каждая компания считает себя особенной. И все наступают на одни и те же грабли. Чем раньше вы примете, что SRE это сложно, долго, дорого и требует культурных изменений, тем выше шанс, что у вас все получится.