Как внедрить SRE в компании?¶

Как не сделать из хорошей идеи организационный кошмар¶

99% компаний, которые заводят у себя "SRE-инженеров" не понимают, для чего это им, чем SRE должны заниматься и какой результат должны приносить. Если вы думаете, что внедрение SRE - это просто нанять несколько инженеров с модным словом в резюме, вы обречены. Вы получите не команду, которая превращает хаос в порядок, а дорогой косметический ремонт в горящем здании. 99% неудач происходят потому, что компании внедряют название роли, не понимая сути дисциплины. В итоге появляются "затыкатели дыр", "спецназ L3+", "вечные дежурные", "тушители пожаров" и прочая чушь за 500000 рублей в наносекунду.

Типичные "анти-SRE" паттерны¶

Затыкатели всех дыр¶

Компания нанимает "SRE", чтобы они реагировали на все инциденты и быстро их "чинили". Их KPI — скорость ответа на алерт и количество закрытых тикетов. Чем они занимаются: бегают от одного пожара к другому и чинят сломанное вручную. Их работа — чисто реактивная. Результат: Система не становится надёжнее, люди выгорают через полгода. Это не SRE, это дорогая техподдержка.

Обслуга продакшена¶

SRE назначаются ответственными за всё, что работает в продакшене: развёртывание, конфигурация, мониторинг, резервное копирование, они же отвечают за инциденты, за проблемы, за риски и еще кучу разного, что в них накидали. Разработчики не несут никакой операционной ответственности за то, что и как написали. Чем они занимаются: бесконечная рутина (toil): деплой, мониторинг, исправление проблем в чужих сервисах, бесконечные встречи, созвоны... Результат: SRE превращаются в сисадминов. Пропасть между Dev и Ops только углубляется. Это полная противоположность философии SRE.

Спецназ L3+¶

Компания создаёт элитную команду "супер-инженеров", которые разбираются со сложнейшими, глубинными проблемами, куда обычные DevOps не могут добраться. Чем они занимаются: Расследуют самые загадочные инциденты, оптимизируют запросы на миллисекунды, копаются в ядрах Linux. Результат: Они становятся "жрецами", знания которых сконцентрированы в одном месте и никому не передаются. Они решают проблемы, но не предотвращают их появление в других командах. Это не SRE, это команда performance-инженеров или архитекторов.

Почему так происходит?¶

Все эти паттерны объединяет одно: компания пытается решить операционную проблему (тушение пожаров, дежурство, сложные расследования), не меняя системных причин её возникновения. "Нам нужны люди, которые будут делать это быстрее и лучше". А нужно думать: "Нам нужны процессы и культура, которые сведут необходимость в этом этом к минимуму".

Правильный путь: внедрение SRE как культурной трансформации¶

Внедрение SRE - это не про создание команды и найм инженеров. Это изменение способа работы всей инженерной организации. Это путь в четыре этапа.

Этап 0: Диагностика, прежде чем что-либо делать¶

Задайте себе честные вопросы:

Почему? Зачем нам SRE? Конкретно: "Мы хотим снизить количество инцидентов на 50%", "Мы хотим ускорить вывод новых функций без потери стабильности", "Мы хотим перестать терять деньги из-за простоев".
Что болит? Горим в инцидентах каждую неделю? Не можем выпускать релизы? Разработчики тратят 30% времени на поддержку?
"Важна ли надежность для нашей компании?" "Готовы ли мы добавить в продукт работы, специально предназначенные для повышения надежности?" "Готовы ли мы отвлечь людей от работы над функциями, чтобы сосредоточиться на проблемах надежности, когда возникнет необходимость?" "Готовы ли мы отменить выпуск релиза на основании того, что цели уровня обслуживания не были достигнуты?"
Готовы ли мы к переменам? Готово ли руководство менять процессы и метрики успеха? Готовы ли разработчики нести больше ответственности за свой код в проде? Готовы ли начальники нести ответственность за свои решения?

Если ответ на вопрос 4 — "нет", остановитесь. Купите лучше мониторинг подороже и наймите ещё дежурных. SRE вам не поможет, а только разочарует.

Заметьте, что ни один из этих вопросов не носит сугубо технический характер.

Этап 1: пилот. Не команда, а пилотный сервис.¶

Не нанимайте команду из 10 SRE сразу. Выделите один, самый важный или самый кривой сервис. Сформируйте рабочую группу из 1-2 будущих SRE и разработчиков этого сервиса. Внедрите полный цикл SRE-практик на этом сервисе. Затем: - соберитесь с бизнесом и установите SLO для этого сервиса - внедрите Error Budget и правила его расходования - автоматизируйте самый главный toil этого сервиса (например, деплой). - настройте осмысленный мониторинг и алертинг на основе SLO.

Измеряйте успех пилота не по субъективным ощущениям, а по цифрам: снизился ли MTTR? Увеличилась ли частота релизов? Удовлетворены ли разработчики?

Этап 2: масштабирование культуры, а не команды.¶

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

создайте центр компетенций: пусть ваши пилотные SRE станут внутренними консультантами, которые помогают другим командам внедрять SLO, автоматизацию, постмортемы.
внедрите платформу: начните строить внутреннюю developer platform - набор самообслуживаемых инструментов для деплоя, мониторинга, сбора и хранение SLO, управления инцидентами и т.п. Это позволит распространить лучшие практики (зашитые в платформу) на все команды, без увеличения штата SRE.
изменяйте процессы компании: внесите в регламенты обязательность SLO для новых сервисов, проведения постмортемов, использования Error Budget для управления релизами. И пусть ваши начальники вам в этом помогут, надеюсь, вам с ними повезло.

Этап 3: определение ролей и карьерных путей.¶

Только теперь, когда практики укоренились по всей компании, можно чётко определить, кого вы называете SRE.

SRE как роль: это инженеры, которые тратят 50%+ времени на инженерные проекты (создание платформы, инструментов, автоматизации). Их главная цель — устранять toil и повышать надёжность системно.

ProdEngineer / DevOps как роль: это инженеры в продуктовых командах, которые применяют практики SRE к своему сервису. Они отвечают за его надёжность, используют платформу от SRE.

Чёткий on-call: Дежурство - это обязанность, а не работа. Дежурят и разработчики (за свой сервис), и SRE (за платформу и кросс-сервисные инциденты). Ротации должны быть сбалансированы, а время, потраченное на инциденты, компенсируется.

В отчете Accelerate State of DevOps Report 2023 группы DORA, написано (и, надеюсь, все это понимают), что для того чтобы работа в области надежности максимально продемонстрировала свои преимущества, требуется время. Не нужно ждать результата "через два спринта".

И вы все сделали правильно, если через год-полтора:¶

Разработчики приходят к SRE с вопросом: "Помогите нам определить правильные SLO" или "Как лучше спроектировать отказоустойчивость?", а не с криком: "У нас всё упало, чините!".
Руководство обсуждает планы по релизам в терминах Error Budget: "У нас есть бюджет, можно рискнуть с этим большим изменением".
Количество ручных, срочных действий неуклонно снижается, а время на инженерные проекты растёт.
Нет отдельной "команды SRE", отвечающей за всю надёжность. Есть культура надежности, которую разделяют все.

Внедрять нужно не "SRE-инженеров". Внедрять нужно практику Site Reliability Engineering.

Это не про людей. Это про то, как вся ваша компания думает о балансе скорости и стабильности, как она расследует ошибки, как она принимает решения о рисках.

Начинайте с малого, с пилота, с одной практики. Измеряйте результат. Масштабируйте не штат, а идеи. И тогда вы получите не "тушителей пожаров", а архитекторов надёжности, которые построят вам систему, где пожаров будет так мало, что тушить их станет скучно. А это лучший результат, который только можно представить.

И никогда не забывайте рассказывать о том, что такое SRE и для чего оно нужно продуктологам, менеджерам и вообще всем вокруг. Заведите себе SRE-Evangelist'а :)