В этой рецензии в блоге SSP SOFT разберем книгу Павла Рудницкого «SRE. Новый подход к управлению инфраструктурой» (БХВ‑Петербург, 2026, 176 страниц). Автор объясняет, как оценить надежность сервиса в метриках, посчитать бюджет ошибок и проанализировать аварию. Студентам, стажерам и младшим разработчикам (джунам) книга дает понимание терминов, на котором инженеры эксплуатации говорят с разработчиками и бизнесом, а заодно поможет с ответами на некоторые вопросы на собеседованиях.
Книгу «SRE. Новый подход к управлению инфраструктурой» можно найти в каталоге на сайте издательства БХВ. Напомним, что на все бумажные книги по компьютерным технологиям от издательств «БХВ‑Петербург», «Alist» и «Фолиант» доступен промокод SSPSOFT на скидку 25% как подарок читателям Хабра от нашего блога. Промокод действует только на сайте БХВ.
Что такое SRE и как с ним обстоят дела в России
Прежде чем углубиться в рецензию на книгу, поговорим о самом термине SRE. Концепция инженерии надежности сайтов (Site Reliability Engineering, SRE) родилась в Google. Широкой публике подход стал известен в 2016 году, когда компания выпустила первую книгу об эксплуатации сервисов. Идея концепции в том, чтобы управлять инфраструктурой как инженерной задачей.
Согласно концепции Google, надежность получает метрики, у команды появляется допустимый запас сбоев (бюджет ошибок, error budget),после аварий идет разбор проблемы. Концепцию SRE часто сравнивают с DevOps (практика совместной разработки и эксплуатации), но SRE добавляет конкретные метрики вроде достижения требуемого уровня доступности сервиса и правил дежурств инженеров.
В России зрелая практика SRE сосредоточена в основном в крупных компаниях. В июне 2026 года команда внутренней платформы наблюдаемости Sage из Т‑Банка рассказала на Хабре о внедрении целей уровня сервиса (Service Level Objective, SLO). Платформа обслуживает более 7000 инженеров и принимает около 18 млн точек метрик в секунду на запись, а по подсистеме метрик описаны 7 услуг и 29 SLO. Для обучения есть курсы, например четырехмесячная программа Яндекс Практикума для опытных ИТ‑специалистов.
Рынок труда в РФ для SRE‑специалистов в целом выглядит привлекательно. По зарплатному калькулятору Хабр Карьеры (материал от 18 июня 2026 года) медиана для SRE составляет 320 тыс. рублей в месяц. У джунов в среднем 178 тыс., у мидлов 253 тыс., у сеньоров 420 тыс. Такие цифры опубликованы в блоге с образовательными партнерами, поэтому мы приводим их в рецензии только как ориентир.
Качество внедрения SRE на широкой выборке в российских компаниях оценивается скорее как удовлетворительное по 5-балльной шкале. При этом, авторы российского разбора метрик пишут, что на российском рынке SRE пока не стал де‑факто стандартом, а внедрение нередко сводится к установке инструментов типа Prometheus (система с открытым исходным кодом для мониторинга ИТ‑инфраструктуры) и подключению визуальной панели мониторинга (dashboard) Grafana.
Блог OTUS в материале о пяти ошибках внедрения называет «театром SLO» ситуацию, когда цели записаны в документах, но в работе их никто не использует. Тут нюанс, что авторы обоих текстов работают на рынке обучения и услуг, так что их оценка не беспристрастна. Хотя картина применения SRE при этом выглядит правдоподобно.
Наша оценка в SSP SOFT такая, что SRE в России растет неровно. В банках, маркетплейсах и в крупных интернет‑компаниях практика зрелая, в остальных случаях за новым названием часто стоит прежняя эксплуатация с SRE‑оберткой «для директора».
Для вдумчивых и педантичных джунов в этом шанс. Рынок нуждается в людях, которые умеют считать надежность и вести разбор аварий, а русскоязычных вводных книг по теме мало. Книга Рудницкого закрывает именно эту нишу, и дальше переходим, собственно, к рецензии.
Для кого эта книга
Автор в предисловии адресует книгу читателям с опытом системного администрирования. Книга обзорная, технических деталей в ней немного, поэтому воспринимается относительно легко. Читателю по ходу изложения предлагаются идеи и подсказки, куда двигаться дальше, а конкретные инструменты читатель подбирает под свою задачу. Лучше всего книга подойдет для такой аудитории:
студентам и стажерам, которые хотят понять, как устроена эксплуатация ИТ‑сервисов в реальном мире;
джунам в поддержке, системном администрировании и DevOps, которым нужен системный подход вместо набора разрозненных советов;
бэкэнд‑разработчикам, которые хотят разговаривать со службой эксплуатации на одном языке и понимать, почему им отказывают в релизе;
администраторам небольших компаний, где инфраструктуру ведет один‑два человека, а подражание практикам Google недостижимо в принципе;
руководителям групп (тимлидам) и менеджерам, которым нужны аргументы для разговора о надежности с бизнес‑подразделениями.
В целом, для аудитории, которая ждет пошаговых руководств, книга покажется слишком общей. Опытным SRE‑инженерам из крупных компаний она тоже мало что добавит, хотя главы про общение в команде и управление нагрузкой полезны всем.
Обзор глав
Главы 1–4. Принципы, общение и цифры надежности
Первая глава задает рамку для всей книги. Суть ее в том, что инженерия опирается на измерения, риском нужно управлять, рутину нужно автоматизировать, сложность держать под контролем, а о происходящем сообщать руководству и дежурным сменам открыто.
Наглядный пример у автора про деньги. Сервис приносит миллион рублей в год. Переход с доступности 99,9% на 99,99% сокращает допустимый простой с 8 часов 45 минут до 52 минут и возвращает примерно 914 рублей выручки. Но у этого возврата есть цена. Любое улучшение надежности имеет довольно высокую цену, и такой расчет хорошо остужает любителей добавить к надежности «еще одну девятку».
Вторая глава посвящена коммуникациям в команде. Автор советует завести три чата (общий для запросов, для анонсов изменений и для аварий), единую систему задач и правило «у каждой задачи один заказчик (stakeholder) и один владелец».
Третья глава учит оценивать требования, учитывать регуляторные ограничения, обращаться с прототипами и считать деньги, например сравнивать аренду облака с покупкой железа для собственной серверной. Автор приводит показательный случай, когда биржа Coinbase за один квартал потратила 65 млн долларов только на мониторинг Datadog и это имело смысл для бизнеса.
В четвертой главе разбираются показатель уровня сервиса (Service Level Indicator, SLI), цель уровня сервиса (SLO), соглашение об уровне сервиса (Service Level Agreement, SLA), бюджет ошибок и индекс Apdex. Для старта предлагается взять 99,95% и окно в 30 дней, собрать статистику и постепенно подстраивать цель. Хорошо описан и «парадокс надежности». Слишком надежный сервис приучает не мониторить его сбои, и однажды падение бьет по всей цепочке взаимосвязей этого сервиса и его пользователей.
Главы 5–7. Мониторинг, журналирование, трассировка и профилирование
Пятая глава начинается с модели опроса (pull) и модели отправки (push), затем переходит к четырем золотым сигналам (задержка, трафик, ошибки, насыщение) и обзору хранилищ метрик. Автор сравнивает Cacti, Zabbix, Graphite, InfluxDB и Prometheus с его потомками Mimir, Cortex, Thanos и VictoriaMetrics, не скрывая личных симпатий и антипатий как автора.
В главе 5 есть примеры запросов на PromQL для расчета SLO и Apdex, четыре уровня приоритета аварий (от P1 до P4) и самый практичный фрагмент главы. Это оповещения (alert) по скорости выгорания бюджета ошибок.
Автор показывает, что оповещение при 0,1% ошибок за 10 минут срабатывает слишком чутко, ведь на такую ошибку уходит всего 0,02% месячного бюджета. Вместо него предлагается схема с несколькими окнами, где 2% бюджета за час, 5% за 6 часов или 10% за 3 дня считаются поводом поднять тревогу.
В шестой главе сравниваются агенты сбора (rsyslog, Fluent Bit, Grafana Alloy, Vector) и хранилища журналов (ELK, Grafana Loki, VictoriaLogs, ClickStack). Объясняется роль очереди сообщений, ротация и бытовая, но ловушка удаленного файла журнала, который продолжает держать открытый процесс. Найти такой «файл‑призрак» поможет команда lsof. Отдельное хранилище для журналов аудита автор считает обязательным.
Седьмая глава вводит трассировку (trace и span) и OpenTelemetry с тремя обязательными компонентами (инструменты, коллектор, экспортер). Затем идут бэкенды Jaeger, Zipkin, Grafana Tempo и VictoriaTraces, непрерывное профилирование на eBPF, синтетический мониторинг (Uptime Kuma, Gatus) и мониторинг на стороне пользователя (Real User Monitoring, RUM). Автор называет OpenTelemetry очень ресурсо‑затратной схемой, которая тем не менее окупается на микросервисной архитектуре, и при этом не рекомендует экспериментальный OpenTelemetry User Monitoring.
Глава 8. Управление инцидентами
Глава описывает жизненный цикл аварии от уведомления до разбора. Ответственный по инциденту (Incident Commander, IC) сортирует событие, оповещает людей и изолирует проблему. Коммуникационный Ответственный (Communication Commander, CC) отвечает за связь с пользователями, профильные эксперты (Subject Matter Experts, SME) подключаются по запросу.
После аварии сотрудник со статусом IC пишет так называемый «посмертный анализ (постмортем)» с временной шкалой и причиной. На это обычно дается 3–5 рабочих дней, а следом проводится совещание всех причастных к инциденту сотрудников.
Автор подмечает, что фраза «на сервере кончился диск» описывает симптом, но задача IC дойти до причины как это случилось. Для ротации дежурств советуют иметь в штате от 4 до 8 человек, а страницу статусов работоспособности ИТ‑инфраструктуры нужно разместить независимо, чтобы крупная авария не отключила ее вместе с остальными ресурсами. Для новичков описан путь IC. Сначала он встает «тенью» рядом с опытным коллегой, затем берет смены самостоятельно.
Главы 9–10. Конфигурация и релизы
Девятая глава объясняет переход от «домашних питомцев» к «скоту» (pets vs cattle), сравнивает декларативные и императивные инструменты и коротко обходит Terraform и OpenTofu, Ansible, Pulumi, Puppet, Chef, cloud‑init и Netbox. Центральная часть главы описывает конвейер (CI/CD) для инфраструктуры как код (Infrastructure as Code, IaC).
Код хранится в системе контроля версий, проходит проверку корректности и проверку плана изменений (terraform plan), а затем дополнительные этапы вроде проверки форматирования. Заканчивается глава советом, который пригодится каждому. Если можно не писать собственный инструмент, его не пишут. В десятой главе автор утверждает, что проблемный релиз и ошибка конфигурации вместе дают около 80% сбоев в устоявшихся платформах (это личная статистика автора и его коллег). Далее сравниваются сине‑зеленое развертывание (blue‑green), канареечное развертывание (canary) и полная остановка с запуском (Stop and Go), разбирается откат с учетом баз данных и версионирование API.
Глава 11. Безопасность
Автор исходит из того, что инженер эксплуатации должен понимать угрозы, даже если в компании есть отдельные специалисты по кибербезопасности. Он делит нарушителей на воров ресурсов, вымогателей и целевых атакующих, разбирает этапы атаки по MITRE ATT&CK, объясняет подход сдвига безопасности влево (Shift‑Left) со статическим (SAST) и динамическим (DAST) анализом и проверкой зависимостей (SCA), спецификацию состава ПО (SBOM), цифровые подписи и взаимную аутентификацию по TLS (mTLS).
В главе есть популярное объяснение терминов OAuth, OIDC с токенами JWT и SAML, а также читателю поясняется о неизменяемых операционных системах вроде Talos и об автоматическом обновлении зависимостей через Renovate. Для начинающего читателя это хороший справочник терминов, которые звучат в каждом разговоре о безопасной разработке.
Глава 12. Работа команды, время и платформа для разработчиков
Последняя глава самая беллетристическая. Автор приводит правило Google о том, что на текущую рутину должно уходить не больше половины времени, а остальное отдается улучшениям и автоматизации. Он предлагает единую точку входа для запросов и недельную ротацию «фронтмена». Затем идут GTD, матрица Эйзенхауэра, Waterfall, Agile, Scrum и Kanban.
Завершает книгу тема самообслуживания. Внутренняя платформа разработчика (Internal Developer Platform, IDP) строится с ограничителями (guardrails), квотами и политиками на OPA или Kyverno, чтобы пользователь не смог случайно «уронить соседей».
Актуальность версий ПО
Текст книги подготовлен в 2025 году, издана она в 2026-м. Автор почти нигде не привязывается к номерам версий и описывает именно принципы и практики. Если сверить названные в книге инструменты с состоянием на конец октября 2026 года, то картина такая:
Prometheus. По данным endoflife.date последняя версия 3.15.1 вышла 21 октября 2026 года, а долгосрочная поддержка (LTS) закреплена за веткой 3.13 (3.13.5). Модель опроса, метки и проблема кардинальности из книги остались прежними. Начиная с ветки 3.0 Prometheus также принимает метрики по протоколу OpenTelemetry (OTLP).
Zabbix. Книга упоминает расширение TimescaleDB, которое поддерживается с версии 6.0. Сейчас на странице загрузок значатся ветка 7.4 (7.4.16), долгосрочные 7.0 (7.0.32) и 6.0 (6.0.49), а версия 8.0 находится на стадии релиз‑кандидата (8.0.0rc2).
OpenTofu. Автор называет его форком Terraform после смены лицензии, и это верно. Проект развивается в линейке 1.x, по данным endoflife.date актуальны 1.13.5 и 1.12.11 (релизы от 29 октября 2026 года).
VictoriaTraces. Книга предупреждает, что продукт молод. По дорожной карте проекта до общедоступной версии (GA) еще нужно зафиксировать структуру данных и обязательство по обратной совместимости.
Grafana OnCall. Книга называет его среди систем управления дежурствами, но открытая версия, по сообщению Grafana Labs от 11 марта 2025 года, переходит в режим поддержки и архивируется к марту 2026 года. В качестве замены компания предлагает облачный Grafana Cloud IRM. Этот пример устарел.
Jira. Atlassian объявила об уходе из России в марте 2022 года, в августе 2023 года стало известно о блокировке учетных записей, а продажи новых лицензий Data Center по факту прекратились с марта 2026 года. Автор рядом называет YouTrack, Redmine и Vikunja, так что альтернативы читатель найдет в самом тексте.
Подведем итоги: основу содержания книги составляют практики, которые не зависят от версий инструментария (SLO, бюджет ошибок, разбор аварий, конвейер для IaC, стратегии релизов), а приложения OpenTelemetry, Prometheus, Grafana и VictoriaMetrics остаются стандартом отрасли.
Примеры конкретных команд и конфигураций перед использованием стоит сверять с текущей документацией. Читателю в России пригодится и сам подход автора. Он прямо советует считать бюджет, прежде чем подключать платные облачные мониторинги, и объясняет, как собрать собственный стек на открытом исходном коде (open source).
Как читать книгу джунам, стажерам и использовать для подготовки к техсобесу
Рекомендуются как минимум 2 главы к прочтению перед собеседованием. Четвертая глава объясняет термины надежности, восьмая показывает, как выглядит работа инженера, когда в три часа ночи что‑то упало. На собеседованиях на роль DevOps, SRE и эксплуатации чаще всего спрашивают как раз об этом. Вот вопросы, на которые после прочтения этих глав условный джун сможет ответить своими словами:
чем SLO отличается от SLA и откуда берется бюджет ошибок;
почему оповещения строят по скорости выгорания бюджета ошибок и чем плох сигнал на каждый всплеск (алерт);
как выглядит разбор инцидента и почему лучше обходиться без поиска виноватых;
в каком случае выбирают сине‑зеленое развертывание, а в каком канареечное;
чем модель опроса отличается от модели отправки в мониторинге.
Чтение книги лучше сочетать с практикой. Поднимите на отдельном компьютере Prometheus с Grafana, снимите метрики с любого тестового сервиса и посчитайте для него SLI и SLO по формулам из пятой главы. Через пару‑тройку вечеров такой работы термины SRE перестанут быть абстракцией. Примеры из книги проверяйте руками на своем тестовом ПК.
Мнения автора воспринимайте исключительно как мнения, а не догмы. Он негативно отзывается об InfluxDB и с воодушевлением говорит о VictoriaMetrics. Это его личный опыт, и он не заменяет собственного теста на ваших данных. Хаос‑инженерии в книге нет, планирование емкости упомянуто вскользь, поэтому эти темы стоит добирать из других источников.
Как рекомендуемый шаг можно взять оригинальную книгу Google об SRE и «The Site Reliability Workbook». Они подробнее и сложнее, но после книги Рудницкого читаются заметно легче.
Заключение
Главная полезность книги «SRE. Новый подход к управлению инфраструктурой» в том, что она показывает надежность на языке метрик и бюджетов. Расчет цены лишней девятки в уровне доступности, бюджет ошибок, оповещения по скорости выгорания, структура разбора аварий и конвейер для IaC превращают абстрактные термины в рабочие приемы, которые можно применить уже сразу.
Отдельно и хорошо описано внимание к сотрудникам. Ротации дежурств, защита от выгорания, фронтмен, обсуждение без обвинений и единая точка входа для запросов описаны так, как их действительно строят в зрелых командах.
Вторая сильная сторона заключается в реалистичном масштабе. Автор последовательно показывает, что SRE частично пригоден к соблюдению даже в маленькой компании с одним администратором, советует начинать с простого, сдерживать стремление все усложнить и что не следует писать лишний код. Книга очень компактная (176 стр.), читается быстро, а обилие названий инструментов с короткими оценками экономит время на «гугление». Для студентов, стажеров и джунов это один из самых удобных русскоязычных входов в тему, а для практиков будет как хорошая шпаргалка для разговора с бизнес‑подразделениями и разработкой.
Немного о SSP SOFT как компании — у нас почти всегда есть открытые вакансии, мы 19 лет занимаемся заказной разработкой ПО и ИТ‑аутсорсингом (входим в Топ-50 ИТ‑компаний России по рейтингу RAEX). Ждем резюме специалистов, готовых работать оффлайн в Москве (ЦАО) или в Томске, а также удаленно из любой точки России. Подробности о вакансиях читайте на странице ХХ.ру и пишите отклики напрямую в ЛС руководителю службы найма в ТГ (можно и на почту job@ssp‑soft.com). Не забудьте добавить «секретную фразу» в сопроводительное письмо: «Увидел(а) вашу вакансию на Хабре».
Успехов в освоении SRE!
Нам будет приятно, если заглянете в наш телеграм‑канал SSP SOFT. Там мы публикуем разные полезности из мира ИТ, советы для поддержания здоровья и продуктивности, проводим конкурсы с призами.