Инфраструктурные регламенты, которые заменяют героические исправления

Почему инфраструктура превращается в героические авралы

Инфраструктура превращается в героизм, когда обычные задачи живут в памяти одного человека, а не в общем процессе. Деплой, который должен быть скучным, начинает зависеть от строгой последовательности: обновить один сервис, перезапустить другой, очистить очередь, подождать две минуты, потом проверить логи. Если эту последовательность знает только один человек, у команды нет процесса. У неё есть привычка.

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

Потом всё остаётся в чате. В спешке кто-то пишет «починил» или «поменял ключ», но не указывает сами шаги, что изменилось и как убедиться, что система снова здорова. Следующему человеку остаётся только гадать. А догадки создают стресс, а стресс ведёт к новым сокращениям пути.

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

Срочность подпитывает этот цикл. Когда продакшен ломается, записывать шаги кажется медленнее, чем просто чинить проблему. Команды пропускают чек-лист деплоя, пропускают заметки по инциденту и обещают всё задокументировать позже. Позже почти никогда не наступает.

Вот почему runbook так важны. Они убирают неопределённость из рутинной работы и снижают зависимость команды от привычного спасателя — человека, который знает странный порядок перезапуска, скрытую проблему с доступом или ту самую команду для бэкапа, которая один раз сработала в 2 ночи.

Какие задачи нужно записать в отдельный регламент

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

Хороший runbook — это не огромная инструкция на всё подряд. Он покрывает задачи, которые могут сломать продакшен, задержать релиз или оставить команду в тупике, когда одного человека нет рядом.

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

Чаще всего стоит начать с деплоев. Команды нередко говорят, что у них есть процесс, но на деле он живёт в голове одного инженера: запустить миграцию, очистить кэш, перезапустить worker, проверить дашборд, немного подождать и только потом переключить трафик. Запишите этот порядок. Укажите, кто это делает, что проверить до и после и как выглядит успех.

Секреты требуют такого же подхода. Ротация паролей, замена API-ключей, смена service account и просроченные учётные данные часто вызывают тихие сбои. Люди помнят решение только потому, что однажды занимались этим полгода назад. В письменном регламенте должно быть указано, где хранится секрет, кто может его менять, что нужно перезапустить после изменения и как подтвердить, что новое значение работает.

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

Найдите работу, которая останавливается, когда одного человека нет

Используйте простой тест: что останавливается, когда один человек берёт выходной?

Если деплои ставятся на паузу, восстановление базы ждёт или никто не может исправить сломанный секрет без одного инженера, проблема очевидна. Команда всё ещё зависит от памяти одного человека.

Задайте этот вопрос для каждой повторяющейся инфраструктурной задачи: кто может сделать это сегодня от начала до конца, не обращаясь к привычному эксперту? Используйте реальные имена. Если ответ — один человек, отметьте эту задачу.

Рискованная работа часто прячется на виду. Задача может выглядеть задокументированной, но реальные шаги лежат где-то ещё: в истории shell, в черновике на одном ноутбуке, в личной заметке или в командах терминала, скопированных из старого инцидента. Это всё равно работа, завязанная на одного человека.

Есть несколько признаков, которые повторяются снова и снова. Один человек знает точные команды и порядок. Задача зависит от личных заметок. Только у одного человека есть нужный доступ или токены. Люди говорят: «Спроси у Сэма, он обычно это делает». Работа затрагивает продакшен, и никто не хочет гадать.

Сначала берите задачи, которые могут навредить живым системам. Поставьте на верх списка деплои, откаты, восстановление, ротацию секретов, изменения DNS и аварийный сброс доступа. Если ошибка там может положить продукт, не оставляйте это в голове одного человека.

Такое часто встречается в небольших продуктовых командах. Один инженер знает флаги deploy-скрипта. Другой хранит заметки по восстановлению в локальном текстовом файле. У основателя есть единственный админский логин для платёжного или почтового сервиса. Все действуют из лучших побуждений, но один больничный превращает обычную проблему в долгий простой.

Напишите чек-лист деплоя, которым действительно можно пользоваться

Большинство неудачных деплоев ломается не из-за плохого кода. Они срываются потому, что шаги живут в голове одного человека. Чек-лист деплоя превращает эту проверку памяти в обычную рутину.

Начните с обычного сценария. Не пытайтесь в первый же день описать все редкие исключения. Если команда обычно выкатывает из main в продакшен после успешных тестов, сначала опишите именно этот путь. Редкие ветки можно добавить позже.

Пишите каждое действие так, будто уставший коллега будет выполнять его в 6 вечера. Используйте точные команды, точные экраны и точные точки согласования. «Задеплоить API» — слишком расплывчато. «Слить pull request, дождаться CI, проверить release tag, запустить команду деплоя, проверить health endpoint» — уже гораздо лучше.

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

Например, укажите, что должно произойти после старта сборки, после запуска job деплоя, после ответа health check и после того, как логи или система отслеживания ошибок в течение нескольких минут остаются тихими. Если ожидаемого результата нет, чек-лист должен подсказать, что делать дальше.

Поставьте шаг отката прямо рядом с рискованным шагом. Не прячьте его в другом документе. Если миграция базы данных может сломать приложение, следующая строка должна объяснять, кто принимает решение об откате, какую команду он запускает и как он проверяет, что старая версия снова здорова.

Согласования тоже важны. Назовите роль или человека, который даёт финальное разрешение перед изменениями в продакшене. Это убирает неловкие паузы и догадки в последний момент.

Потом проверьте черновик на человеке, который его не писал. Попросите его пройти всё один раз без подсказок. Если он останавливается с вопросом «Какой tag использовать?» или «Где смотреть ошибки?», значит, в чек-листе всё ещё есть пробелы. Именно такой тест делает runbook полезным для всей команды, а не только для автора.

Задокументируйте изменения секретов и доступа

Проблемы с секретами часто превращаются в аврал, потому что у никого нет полной картины. Срок действия токена заканчивается, коллега теряет доступ, CI-задача падает, а решение живёт либо в истории чата, либо в голове одного инженера.

Начните с инвентаря. Для каждого секрета запишите, где он хранится, кто за него отвечает, что его использует и что сломается, если он изменится. Записывайте API-ключи, пароли баз данных, облачные учётные данные, service account, SSH-ключи и ключи подписи в одном формате, чтобы людям не приходилось гадать.

Сделайте запись практичной. Назовите источник истины, например менеджер паролей или хранилище секретов. Укажите человека или команду, которая утверждает изменения. Перечислите каждое приложение, worker, cron-задачу или внешний сервис, который использует секрет. Затем запишите реальные шаги ротации по порядку.

Этот порядок важен. «Поменяйте ключ» — этого недостаточно. Людям нужен порядок действий: создать новые учётные данные, сохранить их в нужном месте, обновить приложение или задачу, проверить, что всё работает, и только потом отозвать старые. Если пропустить порядок, люди сломают продакшен, пытаясь его починить.

Восстановление доступа требует такой же детализации. Если кто-то потерял админский доступ к облаку, Git-хостингу, CI или менеджеру паролей, опишите утверждённый путь. Укажите, кто подтверждает личность, кто может выдать доступ и что делать вне обычного рабочего времени.

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

Когда это сделано хорошо, проблемы с доступом становятся скучными. Именно этого и хочется в 2 часа ночи.

Потренируйте восстановление до того, как оно вам понадобится

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

Запустите таймер с первого шага. Отслеживайте, сколько времени занимает загрузка бэкапа, импорт данных, запуск сервисов, прогрев кэшей и возвращение приложения в рабочее состояние. Команды часто ошибаются в оценке. То, что кажется восстановлением за 15 минут, легко может занять час, когда перестраиваются индексы и догоняют worker-ы.

Потом проверьте продукт так, как это сделал бы пользователь. Могут ли люди войти? Совпадают ли файлы приложения и object storage с базой данных? Безопасно ли перезапускаются очереди, cron-задачи и webhooks? Показывает ли мониторинг после этого нормальные сигналы? Данные могут восстановиться чисто, а продукт при этом всё ещё будет наполовину сломан.

Запишите точку, в которой тот, кто реагирует на инцидент, перестаёт пробовать случайные исправления и переключается на запасной план. Будьте точны. Если после восстановления не проходит проверка входа или основная база данных всё ещё работает нестабильно после заданного времени, дежурный должен точно знать, когда переходить к откату или failover.

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

Процедура восстановления должна включать время выполнения, проверки после восстановления и решение «стоп или идём дальше» простым языком. Если только один человек знает, как восстановить продакшен, у вас ещё нет процесса. У вас есть зависимость.

Пример для небольшой команды

У команды из пяти человек был только один способ деплоя: основатель поздно вечером открывал ноутбук, запускал несколько команд по памяти, смотрел логи и надеялся, что ничего странного не всплывёт. Это работало достаточно часто, чтобы никто не спешил что-то менять.

Потом небольшая ошибка превратилась в плохую ночь. У задачи для очереди истёк token сразу после релиза, и фоновые задачи остановились. Новые регистрации продолжали проходить, но письма, импорты и задачи по биллингу начали скапливаться. Снаружи приложение выглядело здоровым, из-за чего проблему было ещё труднее заметить.

Команда попыталась быстро восстановиться и обнаружила ещё один пробел. У них были бэкапы базы данных и object storage, но никто не знал порядок восстановления. Сначала база данных или файлы? А что с сервисами? Какие из них нужно держать выключенными, пока данные снова не совпадут? Они потеряли время, споря о шагах, которые стоило записать ещё несколько месяцев назад.

Решение оказалось простым. Они написали три коротких чек-листа: один для деплоя с точными командами и шагами отката, второй для токенов и секретов с ротацией и тестовыми шагами, и третий для восстановления с порядком для базы данных, хранилища, очередей и запуска приложения.

Каждый чек-лист они сделали достаточно коротким, чтобы его можно было использовать в стрессе. Один инженер отвечал за обновление деплоев, другой — за секреты, а основатель проверял изменения в восстановлении после каждого теста бэкапа.

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

Ошибки, которые поддерживают этот круг

Команды чаще всего пропускают документацию очень конкретным способом: они пишут намерения вместо действий. «Безопасно задеплоить» или «быстро ротировать секрет» звучит нормально, пока уставший человек не откроет страницу в 2 ночи. Полезный чек-лист говорит, какую команду запускать, где проверять состояние, кто утверждает изменение и когда остановиться.

Ещё одна частая проблема — фиктивный доступ. Команда говорит, что с продакшеном может работать каждый, но у одного опытного человека всё ещё остаются единственные рабочие учётные данные, единственный логин в облачный биллинг или единственный SSH-путь, который действительно работает.

Хранение важнее, чем многие признают. Runbook не помогают, если они лежат в личной заметке, старом треде в чате или в репозитории, который дежурный не может открыть с жёстко ограниченного ноутбука. Храните документы там, куда реагирующий человек сможет добраться во время инцидента, и держите вместе последние шаги по деплою, инцидентам и восстановлению.

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

Последняя ошибка — оставить документы без обновлений после инцидента. Люди чинят сервер, исправляют alert и идут дальше. А через месяц та же дыра появляется снова. Обновляйте шаги, пока детали ещё свежие. Убирайте мёртвые команды, добавляйте недостающий вывод и отмечайте разрешение, которое остановило первого реагирующего.

Небольшая команда может какое-то время жить на героизме. Но на героизме нельзя расти.

Как понять, что runbook готов

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

Начните с доступа. Один человек никогда не должен быть единственным путём к секрету, дашборду, хранилищу бэкапов или инструменту деплоя. Рабочий доступ должен быть минимум у двух человек, и оба должны его проверить.

У чек-листа должна быть и чёткая точка остановки. Это может быть неудачная миграция, отсутствующая проверка бэкапа, секрет, который не валидируется, или откат, который ведёт себя странно. Запишите точный сигнал и точного человека или команду, с которой нужно связаться. Люди совершают больше ошибок, когда чувствуют, что от них ждут импровизации.

Шаги восстановления требуют такой же проверки реальностью. Если бизнес говорит, что может пережить 30 минут простоя, а последний тест восстановления занял два часа, процедура ещё не готова. Либо ускоряйте её, либо меняйте ожидания. Надежда — это не план восстановления.

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

Этот последний пункт часто пропускают. Каждый деплой, изменение доступа или изменение бэкапа оставляет маленькие уроки. Если никто не обновляет заметки, runbook уходит от реальности. Через несколько месяцев ему перестают доверять и снова возвращаются к героическим исправлениям.

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

Что делать дальше

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

Не ждите идеального шаблона. Обычного чек-листа достаточно, если другой человек сможет пройти его без догадок. Большинство runbook начинают с простых заметок и становятся лучше каждый раз, когда команда ими пользуется.

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

Владение важнее, чем внешний вид. Если документ может редактировать каждый, но за него никто не отвечает, чек-лист быстро устаревает.

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

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

Если команда снова и снова сталкивается с пробелами в деплоях, слабыми шагами восстановления или неясной ответственностью, Oleg Sotnikov на oleg.is работает как fractional CTO и стартап-советник и помогает командам выстраивать инфраструктурные процессы и снижать риск ручной работы. Краткий внешний разбор помогает увидеть задачи, которые команда привыкла считать нормой.

Когда одна болезненная задача становится рутиной, переходите к следующей. Так героическая работа начинает исчезать.