Создай свой Runbook: Перестань быть героем, начни строить систему
Герой — это админ, который в 3 часа ночи в одиночку поднимает упавший сервер. Профессионал — это тот, кто создал Runbook (или Playbook), по которому этот сервер может поднять любой дежурный инженер за 15 минут.
Runbook — это подробная пошаговая инструкция по решению конкретной проблемы или выполнению стандартной операции.
Из чего состоит хороший Runbook:
Название: Чёткое и понятное. Пример: "Восстановление работы веб-сервера после сбоя БД".
Контекст: Когда применять эту инструкцию? Какие симптомы у проблемы? Пример: "Сайт отдаёт ошибку 503, в логах приложения ошибки подключения к PostgreSQL".
Пошаговые действия: Команды, которые нужно выполнить, скриншоты, куда нажать. Каждый шаг должен быть атомарным и проверяемым.
Проверка результата: Как убедиться, что проблема решена? Пример: "Выполнить curl -I site.com, ожидаемый ответ — HTTP/2 200".
План отката (Rollback): Что делать, если инструкция не помогла или сделала хуже?
Контакты: К кому обратиться за помощью, если ничего не помогает.
Где хранить?
Начните с простого: корпоративная Wiki (Confluence, Notion) или даже репозиторий в Markdown-файлах. Главное — чтобы это было доступно всей команде.
Взгляд архитектора:
Runbook — это способ кодификации знаний. Он снижает зависимость от конкретных людей, ускоряет решение инцидентов и является основой для дальнейшей автоматизации. Задача архитектора — не просто решать проблемы, а создавать систему, которая решает их предсказуемо и масштабируемо.
#devops #sre #runbook #architect #стратегия
Герой — это админ, который в 3 часа ночи в одиночку поднимает упавший сервер. Профессионал — это тот, кто создал Runbook (или Playbook), по которому этот сервер может поднять любой дежурный инженер за 15 минут.
Runbook — это подробная пошаговая инструкция по решению конкретной проблемы или выполнению стандартной операции.
Из чего состоит хороший Runbook:
Название: Чёткое и понятное. Пример: "Восстановление работы веб-сервера после сбоя БД".
Контекст: Когда применять эту инструкцию? Какие симптомы у проблемы? Пример: "Сайт отдаёт ошибку 503, в логах приложения ошибки подключения к PostgreSQL".
Пошаговые действия: Команды, которые нужно выполнить, скриншоты, куда нажать. Каждый шаг должен быть атомарным и проверяемым.
Проверка результата: Как убедиться, что проблема решена? Пример: "Выполнить curl -I site.com, ожидаемый ответ — HTTP/2 200".
План отката (Rollback): Что делать, если инструкция не помогла или сделала хуже?
Контакты: К кому обратиться за помощью, если ничего не помогает.
Где хранить?
Начните с простого: корпоративная Wiki (Confluence, Notion) или даже репозиторий в Markdown-файлах. Главное — чтобы это было доступно всей команде.
Взгляд архитектора:
Runbook — это способ кодификации знаний. Он снижает зависимость от конкретных людей, ускоряет решение инцидентов и является основой для дальнейшей автоматизации. Задача архитектора — не просто решать проблемы, а создавать систему, которая решает их предсказуемо и масштабируемо.
#devops #sre #runbook #architect #стратегия
🔥3❤2
🧠 Skills: Ты единственный, кто знает как это работает. Поздравляю, ты создал себе тюрьму
Коллеги, давайте честно. У каждого из нас есть тот самый сервис, скрипт или конфиг, про который знает только один человек. Ты. И каждый раз, когда ты уходишь в отпуск — телефон не замолкает. Это не уважение к твоей экспертизе. Это Bus Factor = 1, и он убивает и команду, и тебя.
Я это называю "знаниевый монополизм". Он возникает не из жадности — он возникает из того, что некогда было написать документацию, некогда объяснить коллеге, некогда сделать нормальный runbook. И вот ты незаменим. Звучит как комплимент, пока не звонит телефон в 23:47 в субботу.
Хороший runbook — это не просто список шагов. Это живой документ с метаданными: кто владелец, когда последний раз тестировался, какой канал для эскалации, сколько времени займёт выполнение. Именно это отличает документ, который реально используют, от того, что пылится в Confluence с 2021 года.
Шаблон runbook, который реально работает:
Зачем это нужно:
Системы меняются, но документация часто — нет. Решение: триггеры на ревью runbook при изменении инфраструктуры. Когда меняется инфраструктурный код — автоматически флагируются связанные runbook-ы для обновления. Это не бюрократия. Это то, что позволяет тебе нормально спать в отпуске.
Итог: Незаменимых специалистов не бывает — бывают люди, которые не успели или не захотели передать знания. Runbook — это не слабость. Это признак зрелого инженера, который думает о команде, а не только о своей незаменимости.
#skills #documentation #runbook #sysadmin #teamwork #admin_future
Коллеги, давайте честно. У каждого из нас есть тот самый сервис, скрипт или конфиг, про который знает только один человек. Ты. И каждый раз, когда ты уходишь в отпуск — телефон не замолкает. Это не уважение к твоей экспертизе. Это Bus Factor = 1, и он убивает и команду, и тебя.
Я это называю "знаниевый монополизм". Он возникает не из жадности — он возникает из того, что некогда было написать документацию, некогда объяснить коллеге, некогда сделать нормальный runbook. И вот ты незаменим. Звучит как комплимент, пока не звонит телефон в 23:47 в субботу.
Хороший runbook — это не просто список шагов. Это живой документ с метаданными: кто владелец, когда последний раз тестировался, какой канал для эскалации, сколько времени займёт выполнение. Именно это отличает документ, который реально используют, от того, что пылится в Confluence с 2021 года.
Шаблон runbook, который реально работает:
---
title: Перезапуск кластера PostgreSQL при split-brain
id: RB-DB-003
version: 1.2.0
last_updated: 2026-04-15
last_tested: 2026-03-01
owner: @your_name
slack_channel: "#infra-oncall"
estimated_duration: 20-40 минут
risk_level: high
requires_approval: true (Роман или тимлид)
---
## Когда использовать
- Alert: "PostgreSQL replication lag > 300s"
- Alert: "Primary node unreachable"
- Симптом: приложение пишет ошибки "could not connect to server"
## Шаг 1 — Диагностика (5 мин)
Проверяем состояние кластера:
$ patronictl -c /etc/patroni/config.yml list
Ожидаемый вывод: один Leader, остальные Replica
## Шаг 2 — Проверка репликации
$ psql -h localhost -U postgres -c "SELECT * FROM pg_stat_replication;"
Если пусто на мастере — реплика отстала или отвалилась.
## Шаг 3 — Failover (только если мастер недоступен)
$ patronictl -c /etc/patroni/config.yml failover --master <node> --candidate <replica>
ВНИМАНИЕ: действие необратимо без ручного вмешательства.
## Шаг 4 — Проверка после failover
$ patronictl -c /etc/patroni/config.yml list
$ psql -h <new_master> -U postgres -c "SELECT pg_is_in_recovery();"
Ожидаемый результат: false (мы на новом мастере)
## Контакты эскалации
- L2: @colleague_name (Telegram)
- L3: вендор поддержки (тикет в портале)
## История изменений
- 1.2.0 (2026-04-15): добавлен шаг проверки pg_stat_replication
- 1.1.0 (2026-02-01): обновлён путь конфига Patroni
Зачем это нужно:
Системы меняются, но документация часто — нет. Решение: триггеры на ревью runbook при изменении инфраструктуры. Когда меняется инфраструктурный код — автоматически флагируются связанные runbook-ы для обновления. Это не бюрократия. Это то, что позволяет тебе нормально спать в отпуске.
Итог: Незаменимых специалистов не бывает — бывают люди, которые не успели или не захотели передать знания. Runbook — это не слабость. Это признак зрелого инженера, который думает о команде, а не только о своей незаменимости.
#skills #documentation #runbook #sysadmin #teamwork #admin_future