Выкатывать софт в одиночку не обязательно должно ощущаться как жонглирование бензопилами.

Вам не нужна огромная DevOps‑платформа или тяжёлые процессы «как в большом энтерпрайзе», чтобы релизы были надёжными. Нужно только чуть‑чуть структуры — ровно столько, чтобы защитить себя от ночных аварий, потерянного контекста и моментов «чёрт, а как я в прошлый раз это деплоил?».

Эта структура может жить в одном документе: одностраничном DevOps‑мануале.

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

Что такое одностраничный DevOps‑мануал?

Думайте о нём как о карманном руководстве по работе вашего приложения в проде:

• как деплоить
• как откатывать
• как разруливать инциденты
• что должно быть выполнено до нажатия на «deploy»
• минимальные правила, которые не дадут вам случайно положить прод

Он не пытается описать вообще всё. Его задача:

• быть читаемым за 2–3 минуты
• зафиксировать ваши ключевые операционные привычки
• заменить хаотичные разовые решения на повторяемые шаги

Храните его в репозитории как ONE_PAGE_DEVOPS.md и обновляйте по мере того, как набираетесь опыта.

Давайте разберём ключевые блоки.

1. Шаблоны ранбуков: сделайте повторяющуюся работу скучной (в хорошем смысле)

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

Ранбуки превращают этот хаос в пошаговые, копируемые инструкции.

Ранбук — это короткий структурированный документ, который отвечает на вопросы:

• Что это за задача?
• Когда её нужно выполнять?
• Как именно её делать, шаг за шагом?
• Как понять, что всё сработало?

Не нужно отдельный файл под каждую мелочь. В своём одностраничном мануале задайте простой шаблон ранбука и опишите 2–5 самых частых задач.

Пример шаблона ранбука:

### Runbook: [Название задачи]

**Назначение:** Зачем существует эта задача (1–2 предложения).

**Когда запускать:** Триггеры или ситуации.

**Предварительные проверки:**
- [ ] Есть ли сервисы, которые нужно перевести в режим обслуживания?
- [ ] Нужно ли сначала снять бэкапы?

**Шаги:**
1. Шаг 1
2. Шаг 2
3. Шаг 3

**Проверка результата:**
- [ ] Логи выглядят нормально
- [ ] Health‑чеки проходят
- [ ] Ключевой пользовательский сценарий работает: [описать]

**План отката:**
- [ ] Как откатить изменения или смягчить последствия, если что‑то пошло не так

Заполните хотя бы пару таких ранбуков:

• «Деплой новой версии»
• «Запуск миграций БД»
• «Рестарт приложения / worker‑сервиса»

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

2. Плейбуки инцидентов: не импровизируйте, когда всё горит

Когда прод лежит, ваш мозг — самый ненадёжный инструмент.

Поэтому команды создают плейбуки инцидентов: заранее прописанные пошаговые сценарии для самых вероятных аварий. Вам тоже стоит это сделать — только в упрощённом, «соло‑дружественном» формате.

В вашем одностраничном DevOps‑мануале должно быть 1–3 плейбука инцидентов на такие сценарии, как:

• приложение живо, но очень тормозит
• API отвечает 5xx‑ошибками
• база данных перегружена или недоступна

Каждый плейбук отвечает на вопросы:

• Первые действия: что проверить в самую первую очередь?
• Путь диагностики: какие метрики/логи/инструменты смотреть и в каком порядке?
• Временные меры: как быстро уменьшить ущерб?
• Когда откатываться или выключать фичи?

Пример плейбука: «API возвращает всплеск 5xx»

### Incident Playbook: всплеск 5xx в API

**Симптомы:**
- Доля ошибок > 5% дольше 5 минут
- Пользователи жалуются на ошибки при загрузке данных

**Первые действия (по порядку):**
1. Проверить прод‑логи на новые типы ошибок.
2. Проверить последнюю задеплоенную версию и время деплоя.
3. Если деплой был в последние 30 минут — подготовиться к откату.

**Диагностика:**
1. Проверить загрузку CPU/памяти на app‑серверах.
2. Проверить подключения к базе и медленные запросы.
3. Проверить статус сторонних API на предмет их аварий.

**Быстрые меры:**
- Если ошибки начались сразу после деплоя — откатиться на предыдущую версию.
- Если база перегружена — временно отключить некритичные фоновые задачи.

**После инцидента:**
- Написать 5–10 буллетов: что случилось, что починило ситуацию.
- Добавить новые шаги или проверки в этот плейбук.

Цель не в идеальности. Цель — не начинать каждый раз думать с нуля, когда вы в стрессе.

3. DevOps‑ограждения: командная безопасность с простой соло‑организацией

Соло‑разработчики часто избегают процессов, потому что те кажутся тяжёлыми. Но несколько минимальных ограждений дают вам уровень безопасности «как у команды» практически без накладных расходов.

В вашем одностраничном мануале опишите их как жёсткие правила, а не «по возможности».

a) Защита main/production‑ветки

Никогда не относитесь к main как к черновику.

Настройте правила защиты ветки так, чтобы:

• никто (включая вас) не мог пушить напрямую в main или master;
• все изменения попадали туда только через pull request (PR).

Почему это важно даже в одиночку:

• заставляет вас остановиться и пересмотреть свои изменения;
• не даёт случайному git push отправить в прод сырые правки.

Даже PR с самопроверкой намного лучше, чем merge из случайного локального состояния.

b) Требовать успешный билд (и тесты) перед merge

Защищённая ветка должна принимать только тот код, который прошёл CI.

Настройте репозиторий так, чтобы перед merge PR в main:

• CI обязательно прогонял сборку;
• по возможности, проходили unit‑тесты или хотя бы smoke‑тесты.

Это даёт вам:

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

Это не «бюрократия для больших команд», а маленькая автоматизация, которая экономит ваши нервы.

c) Использовать PR как инструмент саморевью

Даже если вы единственный человек в репозитории, PR‑ы всё равно полезны:

• напишите короткое описание PR: что поменяли, зачем и какие риски;
• пробегитесь взглядом по diff так, будто это код другого человека;
• только потом жмите merge.

Эти 30 секунд «переключения роли» часто ловят самые очевидные ошибки.

4. Пре‑деплойный чек‑лист: ваша последняя линия обороны

Люди плохо помнят всё сразу, особенно когда торопятся.

Пре‑деплойный чек‑лист — это короткий список обязательных действий перед каждым релизом. Он живёт в вашем одностраничном мануале и должен использоваться для каждого продакшн‑изменения.

Пример пре‑деплойного чек‑листа:

### Pre-Deployment Checklist

- [ ] Все тесты проходят в CI
- [ ] В описании PR чётко указано, что изменилось и какие риски
- [ ] Миграции базы данных просмотрены и протестированы локально
- [ ] Для рискованных изменений подготовлены feature‑флаги (если используются)
- [ ] Прописан план отката (как вернуть это изменение назад)
- [ ] Проверены дашборды мониторинга (базовые метрики выглядят нормально)
- [ ] Обновлён changelog или релиз‑нотсы

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

Этот чек‑лист:

• ловит пропущенные шаги (вроде забытых миграций или сломанного cron‑задачника);
• делает релизы одинаково предсказуемыми из месяца в месяц;
• снижает тревожность, потому что вы знаете, что «домашка выполнена».

Со временем, когда что‑то всё же идёт не так, вы спрашиваете: «Стоит ли добавить новый пункт в чек‑лист?» Так вы улучшаете процесс, не превращая его в тяжёлый ритуал.

5. Относитесь к своему соло‑сетапу как к мини‑команде

Ключевой сдвиг мышления прост:

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

Пусть шаблоны, автоматизация и политики выполняют ту работу, которую в больших компаниях делают люди:

• ранбуки заменяют «знания из головы»;
• плейбуки инцидентов заменяют импровизированные «военные штабы»;
• защита веток и PR‑ы заменяют социальное давление коллег;
• проверки в CI заменяют «у меня локально всё работает»;
• пре‑деплойные чек‑листы заменяют память и героические усилия.

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

Собираем всё вместе: простой макет одной страницы

Вот пример структуры вашего ONE_PAGE_DEVOPS.md:

# One-Page DevOps Manual

## 1. Guardrails
- Защищённые ветки: main
- Никаких прямых push в main; только через PR
- CI должен проходить перед merge

## 2. Pre-Deployment Checklist
[Ваш чек-лист здесь]

## 3. Runbooks
- Деплой новой версии
- Запуск миграций БД
- Рестарт приложения/worker-а

## 4. Incident Playbooks
- Всплески 5xx в API
- Медленное приложение / высокая латентность

## 5. Notes & Improvements
- Идеи, уроки и будущие улучшения добавляйте сюда.

Этого достаточно, чтобы начать.

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

Итог: выкатывайте как команда, даже если команда — это вы один

Чтобы быть дисциплинированным в проде, не нужны корпоративные монстры‑инструменты. Нужны:

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

Так вы переводите свою работу из режима «герой всё тащит на себе» в режим system‑driven. Вы будете релизить увереннее, реже ломать прод, а когда что‑то всё же пойдёт не так — у вас будет план, написанный более спокойной версией вас самих.

Начните с одной страницы. Улучшайте её после каждого деплоя и каждого инцидента. Со временем этот документ станет тем самым тихим «тиммейтом», который помогает вам работать как команда — даже когда в комнате только вы.