Как объяснить продукту, что такое SRE и чем они занимаются.¶

Или почему вам не нужны "пять девяток"¶

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

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

SRE это не "те ребята, которые всё ломают"¶

Давайте разберём главные мифы и заменим их правдой.

Миф 1: "SRE — это команда, которая говорит "нет" нашим релизам".

Правда: SRE — это команда, которая говорит: "Давайте посчитаем риск и выпустим релиз безопасно".

• Пример: Вы хотите выпустить новую функцию "мгновенная оплата" в пятницу вечером. Старый подход: SRE панически кричит "Нет! Всё упадёт и нам до весера понедельника все поднимать!". Новый подход: SRE смотрит на дашборд с Error Budget: "У нас осталось 40 минут простоя на этой неделе. Давайте выпустим фичу для 1% пользователей и понаблюдаем. Если метрики будут в порядке, то увеличим до 5%. Если что-то пойдёт не так — мы сразу отключим новую фичу одной кнопкой, потратив всего 2 минуты из бюджета. Мы управляем этим риском".

Миф 2: "SRE занимаются только тем, что тушат пожары".

Правда: Их главная цель сделать так, чтобы пожаров не было. Они тушат их только тогда, когда не успели их предотвратить.

• Аллегория: Пожарные. Плохой подход - они только тушат дома. Хороший подход - они проверяют проводку, устанавливают датчики дыма, проводят учения, чтобы люди знали, как эвакуироваться. SRE - это пожарные-инженеры, которые проектируют огнеупорные здания.

Чем же они занимаются?¶

1. Они переводят ваши хотелки в язык надёжности (SLO)¶

Вы говорите: "Пользователи не должны злиться из-за тормозов". SRE переводят это в цифры и спрашивают: "Какой уровень тормозов пользователи готовы простить? Начиная с каких показателей будет считаться, что "наступили тормоза"?" - "Хорошо ли, если 1 из 100 запросов к поиску будет медленнее 2 секунд?" - "Согласны ли мы, что создание виртуальных машин может быть недоступно 10 минут в месяц?"

Эти договорённости называются SLO (Service Level Objectives). Это контракт с пользователем о качестве сервиса, выраженный в конкретных числах. Если SLO выполняется - мы спокойно выпускаем фичи. Если нарушается - мы знаем, что пользователи реально страдают, и нужно заняться стабильностью, а не новым функционалом.

2. Они управляют "бюджетом на риск" (Error Budget)¶

Допустим, мы договорились, что наш сервис может быть недоступен не более 43 минут в месяц (это SLO 99,9%). Эти 43 минуты и есть Error Budget.

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

3. Они строят автопилот для рутины¶

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

SRE выявляют всю такую рутину (toil) и автоматизируют её:

• автоматическое масштабирование при росте нагрузки,
• автоматическое переключение на резервный дата-центр при сбое,
• автоматический откат релиза, если что-то пошло не так.

Результат для вас:

• Разработчики тратят больше времени на фичи, а не на поддержку.
• Инциденты решаются быстрее, часто ещё до того, как вы о них узнаете.
• Вы можете спать по ночам (и SRE тоже).

Конкретные примеры: что SRE сделают для вашего продукта¶

Сценарий 1: Вы запускаете большую рекламную кампанию.

• Без SRE: В день запуска сайт ложится под нагрузкой. Вы теряете деньги и репутацию. Все винят друг друга.
• С SRE: За месяц до запуска кампании SRE по вашим прогнозам нагрузки рассчитывают необходимую capacity, настраивают автоскейлинг и проводят нагрузочное тестирование. В день X система держит удар, вы спокойно наблюдаете за ростом конверсии.

Сценарий 2: Пользователи жалуются, что сервис иногда глючит.

• Без SRE: Разработчики месяц ищут причину, перебирая код. Жалобы продолжаются.
• С SRE: У них есть датчики (мониторинг), которые сразу показывают: проблема в 95% случаев возникает у пользователей с Марса при оплате через MarsPay. Они локализовали проблему за час, передали ее в разработку, разработчики пофиксили её за день.

Сценарий 3: Вы хотите зайти на новый рынок (например, на Марс).

• Без SRE: Пользователи из Марс-сити жалуются на дикие задержки. Вы не понимаете почему.
• С SRE: Они знают, что задержка - ключевая метрика. Они разместят копии вашего сервиса в марсианских дата-центрах и настроят маршрутизацию трафика так, чтобы пользователи из Марс-сити ходили к ближайшему серверу. Скорость вырастет в 5 раз.

Что вам, как продакту, нужно делать с SRE?¶

1. Пригласите их в самое начало. Когда задумываете новую большую фичу - позовите SRE на планирование. Они подскажут:

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

2. Договоритесь о SLO для вашего продукта. Сядьте вместе и честно ответьте: "Какую надёжность ждут наши пользователи? Что для них "работает хорошо"?" Когда мы начнет считать, что наступило "плохо"?. Это самый важный диалог. Без него вы будете говорить на разных языках.

3. Смотрите на один и тот же дашборд. Попросите SRE сделать для вас понятный бизнес-дашборд с ключевыми метриками (оно же SLO Dashboard, или "Модель здоровья продукта"): доступность, скорость, успешность операций. Это должен быть ваш единственный источник правды о здоровье продукта. Не спрашивайте "всё ли у нас хорошо?", просто посмотрите в дашборды на графики.

Подитожим :)¶

Представьте, что вы бегун. Разработчики - это тренер, который ставит технику. Продакт — вы, который выбирает цели (пробежать марафон, улучшить время на стометровке). А SRE - это ваш физиотерапевт, диетолог и эксперт по кроссовкам.

SRE следят, чтобы вы не получили травму от перегрузок (система не упадёт под пиком); подбирают питание для повышения вашей ввыносливости (оптимизируют ресурсы); выбирают кроссовки, которые уменьшают время на секунду (ускоряют работу системы). Их цель - не бежать за вас, а сделать так, чтобы вы могли бежать быстрее, дальше и без травм.

Хорошие SRE не будут говорить вам "не беги". Они скажут: "Ваш бюджет травм (Error Budget) позволяет нам пробежать этот спринт. Давайте наденем наколенники (сделаем канареечный релиз) и побежим. Если почувствуем боль - сразу остановимся (откатим). И завтра мы сможем бежать снова".