ChatOps

Практика родилась в GitHub: в 2011 году они открыли Hubot — фреймворк на Node.js для ботов, которые жили в Campfire, а позже в Slack, и через текстовые команды деплоили, мониторили, рестартили сервисы. Само слово «ChatOps» закрепилось за подходом чуть позже, когда Джесси Ньюленд из той же компании начал рассказывать про это на конференциях. Идея с тех пор сильно эволюционировала: от «прикольный бот, который отвечает на @hubot deploy» к платформам, построенным вокруг управления инцидентами, — incident.io и Netflix Dispatch, где чат стал главным местом, откуда ведут инцидент от начала до конца. Я для своих нужд писал серию ботов для Telegram — owl_clerk_bot (личный секретарь), py-tg-moder (модерация чата), плюс пара закрытых: аналитика каналов и админские инструменты. Каждый закрывал свой класс toil. Главная ценность ChatOps не в том, что «прикольно тыкать команды в чат», а в трёх вещах: журнал аудита получается сам собой (всё видно в канале и находится поиском), низкий порог (команда и так сидит в чате, переключаться некуда), все видят всех (пятеро смотрят, как шестой выполняет действие, — это встроенный взаимный контроль). Этот лист — про то, когда и как строить слой ChatOps и где его границы со специализированными инструментами.

Что должен уметь

Главный навык на уровне L5 — спроектировать права бота под конкретную модель угроз. Бот — это учётная запись с доступом в прод; небрежный дизайн открывает новую поверхность атаки. Только чтение по умолчанию, разрушительные действия — отдельным включением и с явным подтверждением, разные боты под разные наборы прав (один супербот со всеми правами — антипаттерн), связка с центральным IAM (см. Access Control & IAM). Я регулярно вижу команды, которые заводят бота с админскими правами «для удобства», а через год не понимают, кто вообще проверяет его действия.

Понимает три уровня ChatOps: push (бот сам шлёт информацию — алерты, статусы сборок, деплои), pull (бот отвечает на запрос — /status service-x), действие (бот выполняет операцию — /deploy v2.3.4, /incident declare SEV1).
Пользуется тем, что уже интегрировано в его команде (incident.io, Slack-приложение PagerDuty, Dispatch); знает базовые команды: объявить инцидент, поднять дежурного, собрать war room.

Пишет простых ботов для уведомлений — статус сборки, завершённый деплой, маршрутизация алертов. Уровень: составной GitHub Action (notiflow) или отдельный бот (owl_clerk_bot).
Заводит запросы к боту — статус сервиса, последний деплой, кто сегодня дежурит. Бот здесь обёртка над уже существующими API; ценность в доступности, а не в новой функции.
Проектирует команды-действия аккуратно: явное подтверждение для разрушительных операций, холостой прогон по умолчанию, автоматическая запись в канал аудита.

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

L6+

Проектирует ChatOps на уровне организации: делать или покупать платформу для инцидентов, кто владеет ботами (платформенная команда или каждая своими), как это связывается с уже собранным набором инструментов.
Принимает решения на разменах: глубина ChatOps против стоимости содержания своего фреймворка; переезд между мессенджерами (Slack, Teams, Mattermost) и то, чем обернётся привязка к одному из них.

Материалы

Книги и статьи

Jason Hand — ChatOps: Managing Operations in Group Chat (O’Reilly, 2016, бесплатно). Самая полная публикация по теме — определения, уровни, антипаттерны. Старая, но фундаментальные принципы не устарели.
GitHub Engineering Blog — ChatOps at GitHub. Серия постов про ChatOps в самом GitHub — родина термина, деплой командой .deploy в комментарии к PR.
Charity Majors — Ask Miss O11y: I Don’t Want to Be On Call Anymore. Am I a Monster? (Honeycomb). Про то, каким дежурство должно быть, чтобы люди не выгорали, — и почему инструменты вокруг чата тут решают меньше, чем принятые в команде нормы.

Стандарты и платформы

Slack Bolt Framework (официальный, JS, Python, Java). Нынешний стандарт для ботов в Slack; официальный SDK, пришедший на смену Hubot там, где кроме Slack ничего не требуют.
Telegram Bot API (официальный). Бесплатный и простой вариант для команд вне корпоративного Slack. Встроенные клавиатуры, обработка нажатий, права в группах — этого хватает под большинство задач SRE.
Mattermost Bots Documentation. Для команд со своим сервером чата: требования регуляторов, изолированный контур.

Инструменты

Уведомления:
- notiflow — мой составной GitHub Action для уведомлений в Telegram по завершении задачи в workflow; шаблоны статусов, повтор при 429.
- Slack incoming webhooks, Telegram bot sendMessage — нижний уровень: HTTP POST прямо из CI или системы мониторинга.
- Alertmanager с приёмниками для Slack и Telegram — алерты попадают в чат вообще без своего кода.
Боты для запросов и действий (фреймворки):
- Slack Bolt — современный фреймворк под Slack.
- Errbot — фреймворк на Python с архитектурой плагинов, работает поверх Slack, Telegram, IRC и XMPP. По моим наблюдениям, его выбирают, когда сервер свой или платформ несколько.
- Hubot — исторический фреймворк GitHub на CoffeeScript и JS. Сейчас наследие; работает, но новый проект я бы на нём не начинал.
- Lita — аналог Hubot на Ruby.
Платформы, выросшие вокруг инцидентов:
- incident.io — коммерческая, живёт внутри Slack. Объявление инцидента, war room, сводки, работа над постмортемом — всё слэш-командами. По моим наблюдениям, в сегменте стартапов доминирует.
- FireHydrant, Rootly — конкуренты incident.io с разным набором возможностей. Blameless из этого ряда исчез: FireHydrant купила его в 2024.
- Netflix Dispatch — open-source, разворачивается у себя; ведёт инцидент целиком и интегрирован со Slack.
- PagerDuty Process Automation (бывший Rundeck) — корпоративный запуск runbook’ов из чата.
Мои боты для Telegram:
- owl_clerk_bot — личный секретарь: заметки, напоминания.
- py-tg-moder — модерация чата: антиспам, капча, баны.
- Аналитика каналов с модерацией и админские инструменты для Telegram — эти два бота лежат в закрытых репозиториях, поэтому здесь без ссылок.
Связка с CI/CD: GitHub Actions с уведомлениями (в том числе notiflow), встроенная интеграция GitLab CI со Slack, шаги Argo Workflows со Slack и Telegram.

Best practices

Главный публичный кейс — Бот деплоя в GitHub (с 2012 года и до сих пор). GitHub деплоит сам github.com через ChatOps уже больше десятилетия: в комментарии к PR пишется .deploy, Hubot читает команду, запускает конвейер и постит статус обратно в PR. Что сработало: журнал получается сам собой (вся история деплоев видна в канале и находится поиском), все видят всех (тот, кто деплоит, не один), взаимный контроль встроен (деплой можно оспорить в том же треде). Что я вынес из их рассказов: главная сложность не техническая, а организационная. ChatOps требует команды, которая умеет договариваться о деплоях прямо в чате, а не протаскивать каждое действие через тикет. Если зрелости не хватает, ChatOps становится обходным путём мимо нормального ревью, и это уже проблема, а не удобство.

Три правила, которые я считаю обязательными, если бот вообще получает права что-то делать.

Только чтение по умолчанию. На /status и /who-on-call бот отвечает без всякой проверки, а вот /scale, /deploy и /incident-close идут через два шага с подтверждением, фиксацией того, кто именно попросил, и записью в канал аудита. По моим наблюдениям, главная дыра в безопасности ChatOps выглядит так: утёк токен бота — и у атакующего ровно те же права, что у самого привилегированного человека в команде.

Дальше — учётные записи. Один супербот со всеми правами означает, что компрометация одного токена отдаёт всё разом. Лучше несколько ботов под разные задачи (деплой, запросы, инциденты), у каждого свой минимальный набор прав, и учётная запись привязана к команде или системе, а не ко «всему подряд». Боты — тоже нагрузки, см. Workload Identity.

И третье: канал аудита отдельно от рабочего. Все действия бота, особенно разрушительные, дублируются в канал только для чтения. Это и артефакт для SOC 2 или ISO 27001, и то самое место, где на инциденте видно, какое действие запустило каскад.

Уведомления → запросы → действия — естественная эволюция, а не «сразу полный ChatOps». Начинать стоит с уведомлений (notiflow для CI, Alertmanager для алертов): удобство прирастает, риска почти нет. Запросы статуса добавляются вторым этапом — бот отвечает на /status, /oncall, /last-deploy поверх API, которые только читают. Команды-действия идут последними, потому что им нужны зрелая модель прав, работающий аудит и понятная процедура подтверждения. Прыжок через этапы почти всегда кончается либо дырой в безопасности, либо ботом, который «вроде работает, но никто им не пользуется».

Делать своё или брать готовое. Если ChatOps нужен в первую очередь под инциденты, сегодня я не вижу убедительной причины писать собственного бота: incident.io, FireHydrant, Rootly и open-source Dispatch закрывают почти всё, что бывает нужно. Своё оправдано в трёх случаях: изолированный контур без внешнего SaaS; интеграция с самописной системой инцидентов, которой нет в готовых платформах; совсем маленькая команда, для которой Dispatch тяжёл, а коммерческая подписка не влезает в бюджет. В остальном — берём готовое и вкладываемся в интеграцию с процессами, а не в свой фреймворк.

Какой фреймворк брать. Slack Bolt — если вы живёте в Slack и никуда оттуда не собираетесь. Errbot на Python — когда платформ несколько или сервер свой. Для мелких ботов фреймворк не нужен вовсе: мои py-tg-moder и owl_clerk_bot написаны на голом python-telegram-bot, и этого хватает. Hubot и Lita — прошлое, для нового проекта я бы их не брал: развитие замедлилось, экосистема съехала на Bolt. По моим наблюдениям, Bolt со Slack доминирует в командах от полусотни человек, а Errbot и Telegram остаются там, где считают деньги.

Привязка к платформе — риск на годы. Боты на Slack Bolt срастаются с интерфейсом Slack: слэш-команды, модальные окна — всё это при переезде на Teams или Mattermost переписывается целиком. Если смена мессенджера вообще возможна — поглощение, требования регулятора, цена, — берите мультиплатформенный фреймворк вроде Errbot или прячьте слой интерфейса за собственной абстракцией. По моим наблюдениям, за три-пять лет привязка к Slack редко становится по-настоящему больно. Исключение — B2G и финансы, где смену может потребовать комплаенс.

Граница у практики двойная. ChatOps не работает там, где чат не стал рабочим местом команды: если половина людей заходит в Slack раз в день, бот превращается в ещё один канал, за которым никто не следит, и все действия всё равно идут руками. И он перестаёт окупаться, когда операция сложнее одной строки: выбор из десяти параметров, длинный мастер, разбор графика — всё это в чате получается хуже, чем в нормальном интерфейсе. Цена этого проста: команда пишет бота, гордится им квартал, а потом возвращается к CLI и веб-консоли.

Связанные листья

Toil Automation — родительская практика: ChatOps — это автоматизация, которой управляют из чата; естественное продолжение уведомлений в сторону действий.
Toil Tracking — учёт показывает, какие повторяющиеся операции пора переносить в чат: начинают с самых частых.
Personal SRE Toolkit — личные скрипты превращаются в командных ботов, когда повторяющаяся задача перестаёт быть «моей».
Incident Response — современные инструменты инцидентов (incident.io, Dispatch) — это ChatOps внутри Slack: объявление и координация идут через чат.
Severity Classification — объявление инцидента через /incident sev1 <описание> — каноническая команда ChatOps.
On-Call Rotation — запрос /oncall и эскалация через бота — стандартные сценарии.
War Room Patterns — чат как рабочая поверхность штаба; боты держат ритм сводок, ротацию ролей и работу scribe.
Access Control & IAM — учётная запись бота и его права — критичная часть безопасности ChatOps.
Workload Identity — бот — это нагрузка; аутентификация по идентичности лучше долгоживущих общих токенов.

Открытые вопросы

AI-augmented ChatOps — боты на LLM, которые суммируют алерты, предлагают шаги из runbook и генерируют черновики постмортемов из треда. Технология свежая, практики ещё формируются. Скорее всего, через пару лет это будет отдельный лист.

Две темы поменьше. Voice-first ChatOps — присутствие бота как секретаря и координатора в голосовом штабе (Zoom, Meet); пока это экзотика, но направление рабочее. ChatOps там, где правит регулятор — финансы, медицина, B2G: действия из чата упираются в формальные согласования и неизменяемый аудит; публичных практик по этому я почти не нахожу.

Я не разбирался глубоко с управлением парком ботов — как на уровне организации решать, кто за какого бота отвечает, как выводить из эксплуатации осиротевших и как проверять их права между командами. Если у вас есть формальный реестр ботов и правила вокруг него — был бы интересен опыт PR’ом.