Книга Бена Хоровица — это рассказ о том, как выживать в кризисах, технических долгах и организационных провалах. Хотя автор пишет про управление компанией (Horowitz — сооснователь Andreessen Horowitz и бывший CEO Loudcloud/Netscape), его идеи идеально ложатся на реалии SRE.
Почему? Потому что Site Reliability Engineering — это постоянное балансирование между:
- Стабильностью и скоростью («Можно ли выкатить фичу, если p99 latency выросла?»)
- Контролем и доверием («Как дать Dev-командам свободу, не ломая продакшен?»)
- Техническим долгом и инновациями («Чинить легаси или переписывать на Go?»)
«Никого не волнуют твои проблемы» (и это нормально)
Цитата из книги:
«Когда ты в кризисе, никто не придёт тебя спасать. Никто. Ты сам должен найти выход.»
Как это относится к SRE?
-
Когда упал продакшен, бизнес не хочет слышать про «сложную архитектуру» — им нужно решение.
-
Когда разработчики залили баг, объяснения типа «это не наша зона ответственности» не работают.
Что делать?
Фокусироваться на решении, а не на оправданиях.
Готовиться к войне в мирное время:
-
Документировать runbooks для всех критичных сервисов.
-
Проводить regular chaos tests, чтобы знать слабые места.
«Худшее решение — это никакого решения»
Хоровиц пишет: «Даже плохое решение лучше, чем паралич анализа».
Пример из SRE-практики:
Ситуация: База данных перегружена, но команда неделю спорит: «Шардировать или кэшировать?».
Проблема: Пока идёт дискуссия, пользователи страдают.
Решение по Хоровицу:
-
Выбрать самый быстрый вариант (например, добавить read-only реплику).
-
Зафиксировать техдолг и запланировать долгосрочное решение.
«Нанимайте под профессиональные слабости, а не сильные стороны»
Неочевидный совет от Хоровица:
«Если ты отлично разбираешься в инфраструктуре, найми того, кто знает то, чего не знаешь ты.»
Применяем к SRE-командам:
-
Если ваша команда сильна в мониторинге, но слаба в capacity planning — ищите эксперта по прогнозированию нагрузок.
-
Если все говорят «у нас нет проблем с безопасностью», но никто не проводит pentest — пора брать Security Engineer.
Вывод: SRE-группа должна закрывать все аспекты надёжности, а не только любимые технологии.
«Правило 90/90»: почему технический долг убивает
Хоровиц рассказывает про «правило 90/90» в разработке:
«Первые 90% кода делаются за 90% времени. Оставшиеся 10% — ещё за 90% времени.»
Аналог в SRE:
-
Вы можете быстро накрутить алерты в Prometheus, но настроить точные SLO окажется в 10 раз сложнее.
-
Можно запустить Kubernetes, но отполировать его под 99.99% доступности — это отдельный ад.
Как бороться?
Честно оценивать трудозатраты (не говорить «сделаем за неделю», если нужен месяц).
Выделять «дни техдолга» (например, 20% времени на улучшение мониторинга).
«Военное и мирное время для компании» (и для SRE)
Хоровиц разделяет два режима работы компаний:
-
«Военное время» (кризис, борьба за выживание).
-
«Мирное время» (стабильность, развитие).
Как это выглядит в SRE?
| Критерий | Военное время (кризис) | Мирное время (стабильность) |
|---|---|---|
| Приоритет | «Любой ценой поднять продакшен!» | «Улучшить архитектуру для будущего» |
| Риски | Роллбэки, костыли | Постепенные улучшения |
| Коммуникация | Жёсткий контроль, частые стендапы | Делегирование, долгосрочное планирование |
Ошибка: Действовать в «мирном» режиме, когда всё горит (или наоборот).
Вывод: почему SRE должны прочитать эту книгу?
«The Hard Thing About Hard Things» — это не про успехи, а про провалы. И SRE, как никто другой, знают, что:
-
Надёжность строится на тысячах мелких решений.
-
Идеальных систем не бывает — есть только компромиссы.
-
Лидерство — это не про контроль, а про принятие сложных решений.
Финалка:
«Если ваша система никогда не падает — вы либо врете, либо переплачиваете за инфраструктуру.»
