SRE. Путеводитель по надежности для неинженеров

Для кого эта книга

Эта книга для тех, кто слышал загадочное "эс-ар-и", и "эс-эр-и" и даже и "эс-эр-е" и не понимал кто это, что это и для чего это.

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

Эта книга для тех, кто подозревает, что "надежно" это не просто когда "всё работает", но не до конца понимает, как эту самую надежность измерить, а главное - зачем.

Эта книга — попытка построить мост через пропасть между теми, кто строит продукт, и теми, кто обеспечивает, чтобы он работал. С одной стороны — продакт, жаждущий выкатить новую фичу «ещё вчера». С другой — инженер, который этот релиз может и не пустить без уверенности, что он не обрушит прод.

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

SRE это не модная аббревиатура, а целая инженерная дисциплина и философия, основанная на теории надежности, но расширенная и модифицированная для мира программного обеспечения и сервисов.

Очень важное уточнение :)

В аббревиатуре SRE (Site Reliability Engineer) уже есть слово «инженер». Правильно писать просто «SRE» («Эс-Ар-И») или «SR-инженер», «Инженер по надёжности (SRE)». «SRE-инженер» — тавтология, не повторяйте её.

Если ты:

  • Продуктовый менеджер, который хочет понять, почему инженеры против твоего гениального плана "запустить всё и сразу в пятницу вечером";
  • разработчик, которому не интересно, как его код работает в проде, потому что ответственности за это у тебя нет;
  • начинающий инженер или студент, для которого SRE - хайповый, но непонятный термин;
  • тимлид, который чувствует, что команда тонет в "тушении пожаров", но не знает, как выстроить процессы иначе;
  • руководитель, который измеряет стабильность в девятках и думает, что SRE - это как L3, но только почему-то в два раза дороже;
  • просто любопытствующий, который хочет понять, что такое SRE и почему им так много платят :)

...то ты открыл нужную книгу :)

Если после прочтения ты поймаешь себя на мысли, что начинаешь смотреть на мир как инженер надежности (задумываешься о "точке отказа", когда стоишь в очереди в кофейне, или мысленно считаешь "девятки" доступности лифта в своём офисе) - я буду рад и буду считать свою миссию выполненной. Я так же признаю, что некоторые мои мысли могут стать поводом для здоровой дискуссии, пишите: philyuchkoff@gmail.com

Здесь не будет сложных формул (ок, будет парочка, но я их разжую) и заумного жаргона без объяснения. Будет много простых аналогий из жизни: такси, кофейни, парусные корабли, рестораны и даже законы строительства крепостей. Постараюсь перевести с инженерного на человеческий.

Эта книга — попытка систематизировать и донести принципы SRE такими, какими я их увидел и понял. Изложенные здесь взгляды — это результат моего общения с умными людьми, личного погружения в тему, огромного количества прочитанных книг, изучения опыта первопроходцев, ГОСТов 27-й серии и собственных размышлений. Плюс 29 лет моего пути — от ученика монтёра по ремонту радиотелеграфного оборудования до того, кто пишет эту книгу.

У вас есть полное право не соглашаться с моим мнением и материалами книги, это не истина в последней инстанции.

Цель книги не в том, чтобы сделать из вас Principal SRE после прочтения, я не буду грузить тебя глубинами Linux Kernel или тонкостями поиска RowHammer для эскалации привилегий в твоем Kubernetes-кластере, а дам системное понимание надежности. Чтобы в следующий раз, когда кто-то скажет: Нам нужно улучшить p95 латентности до 150 мс, чтобы уложиться в SLO, или "Модель здоровья продукта основана исключительно на SLO и без этого не работает", вы не просто кивнули, а действительно поняли о чём речь, поняли, почему это важно для продукта и какова логика принятых для этого инженерных решений.

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

27 февраля 2026 года выложил книгу в открытый доступ, но она не закончена, она постоянно будет правиться и дополняться.

29 мая 2026 года добавил несколько новых глав и переработал существующие:

Также полностью переписана глава Модель здоровья продукта, добавлена глава-разграничение SLA/SLO/SLI, написаны шаблоны и чек-листы, добавлены перекрёстные ссылки между всеми главами.