Что делать, если у вас нет выделенного SRE?

Если вы дочитали до этого места, вы уже поняли, что SRE это очень полезные ребята. Они за порядок, предсказуемость и сон по ночам. Но очень возможно, что сейчас вы сидите и думаете: "Это всё замечательно, товарищ автор. Но у меня нет отдельной команды инженеров надежности. У меня есть два с половиной разработчика, один сервер в аренде и стартап, который может не дожить до внедрения всех этих практик".

Я вас прекрасно понимаю. Книги по SRE часто пишутся для тех, у кого есть выделенная команда SRE и это для них норма. А что делать простым смертным?

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

Перестаньте геройствовать и начните измерять

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

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

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

  • главная страница сайта должна открываться за 3 секунды;
  • оплата корзины должна проходить без ошибок в 99% случаев;
  • утром с 9 до 11, в час пик, сайт не должен падать.

Вы только что создали свои первые SLO. Вы их даже можете записать на стикере и прилепить на монитор.

Признайте, что идеальной надежности не бывает

Теперь, когда у вас есть цели, разрешите себе иногда их нарушать. Для новичков звучит странно, но это и есть магия Error Budget.

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

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

Вы говорите команде и продукту: "Господа, у нас есть бюджет на ошибки и он равен 1% времени. Пока мы в него укладываемся, мы имеем право рисковать и выкатывать фичи побыстрее. Но как только мы превысили лимит (например, наш сайт уже лежал два часа на этой неделе), всё, объявляем мораторий на выпуск новых фич и следующие две недели (или до восстановления бюджета) мы только фиксим баги и повышаем надежность. Вот документ, где мы это фиксируем, распишитесь, что прочитали и поняли".

Это превращает бесконечный спор "фичи против стабильности" в прозрачный процесс.

Автоматизируйте свою боль

В маленьких командах люди часто тонут в рутине. Это называется Toil. Например: - каждый день вручную перезапускать фоновую задачу; - сто раз в день отвечать в чате на вопрос "А почему у меня не грузится?". - вручную наливать данные на тестовый стенд.

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

Правило простое: если вы делаете что-то руками второй раз - напишите скрипт. Если третий - скрипт должен выполняться по расписанию сам.

Ставьте предохранители

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

В маленькой команде вы не можете позволить себе войну. Выход - Feature Flags.

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

Это снимает почти весь страх перед деплоем.

"Разборы полетов"

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

Это самое сложное, но самое важное. В маленькой команде проще простого найти козла отпущения. Вместо этого после каждой аварии садитесь и пишите простой документ с ответами на три вопроса:

  1. Что случилось?
  2. Почему мы этого не заметили раньше?
  3. Что мы сделаем, чтобы это больше не повторилось?

Никаких имен, только факты и действия. Это и есть культура без обвинений (Blameless Culture).

Не изобретайте велосипеты, используйте готовые инструменты

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

Наличие выделенного SRE это не панацея

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

  1. Определите, что значит "хорошо".
  2. Договоритесь, сколько "плохого" вы готовы терпеть.
  3. Автоматизируйте скучное.
  4. Не ищите виноватых, ищите причины.

Ваша цель не достичь "шести девяток" (99,9999% надежности) любой ценой. Ваша цель перестать бояться собственного сервера по ночам и начать тратить время на создание полезных фич, а не на тушение вечных пожаров.

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