mttrly для On-Call инженеров

Реагируй на инциденты откуда угодно

PagerDuty разбудил тебя. Что дальше? mttrly приносит текущие факты, поддерживаемые действия, approval и проверку результата в телефон, который уже у тебя в руке.

Illustrative workflow · timing and values vary

🚨 3AM PagerDuty: High Error Rate

Woken up by alert. Need to diagnose and fix without leaving bed.

B
Bro Terminal
>_ Interactive session
⏰
3AM Alert
PagerDuty: errors spiking
→
🔍
Quick Check
CPU OK, Disk OK, RAM 94%
→
🎯
Root Cause
Memory leak from 1am deploy
→
⏮️
Rollback
Revert → restart → healthy
Before
Wake up fully, find the laptop, connect VPN and SSH, then rebuild the context across commands and logs.
Traditional on-call:
- Get laptop
- Connect VPN
- SSH into server
- Run diagnostics
- Read logs
- Reconstruct context
- Make decision
- Execute and verify
After
Use the phone already in your hand to review evidence, choose a bounded action, and see verification in one thread.
With mttrly:
- Open the incident
- Ask what's wrong
- Review diagnosis
- Choose a supported action
- Confirm when required
- See the verified result

The Problem

  • ✗Нужен ноутбук для реакции на алерты
  • ✗VPN медленно подключается в 3 ночи
  • ✗Простые фиксы занимают 15+ минут
  • ✗Нельзя выйти из дома во время дежурства

The Solution

Получи алерт в мессенджере, посмотри живые факты, выбери поддерживаемое действие и увидь проверку в том же треде. Меньше времени инцидента уходит на открытие инструментов и восстановление контекста.

Полная схема работы без постоянных SSH-сессий: управлять VPS без raw SSH как обычного интерфейса.

Боль дежурства

Ты на дежурстве на этой неделе. Ноутбук всегда заряжен, hotspot готов, а перед каждой поездкой возникает вопрос: «Я смогу восстановить прод отсюда?» Алерт в 3 ночи означает полностью проснуться, дождаться VPN, набирать команды сонными глазами и восстановить контекст до первого безопасного шага.

Почему MTTR важен

Mean Time To Resolution показывает, как долго с инцидентом живут пользователи и команда. Часто лишнее время уходит не на сам фикс, а на поиск ноутбука, открытие нужных инструментов, нужного сервера и понимание последних изменений. mttrly сокращает этот путь от фактов к действию, но не обещает фиксированный MTTR.

Workflow дежурства с mttrly

1

Приходит алерт

Срабатывает PagerDuty/OpsGenie. mttrly тоже шлёт алерт в мессенджер с начальным контекстом.

2

Быстрая диагностика

Ты: «что не так?» → Bro запускает диагностику HighLatency → сопоставляет CPU, диск, RAM, процессы, логи и метки последних деплоев → возвращает факты и вероятную область проблемы. Время зависит от сервера и набора проверок.

3

Выполнение фикса

Поддерживаемые фиксы становятся scoped requests: restart, cleanup или deploy. Runtime policy отмечает каждое действие как read-only или approval-required; bounded Investigation авторизуется отдельно и применяется только к mttrly_execute_command.

4

Проверка решения

/status подтверждает, что сервисы здоровы. Обнови инцидент. Обратно спать.

Эта последовательность опирается на action layer для реагирования на инциденты, который отделяет сбор данных от изменений.

Playbooks для типичных инцидентов

Оформи повторяемые runbooks как scoped playbooks mttrly. В текущем registry есть read-only проверки и approval-required операции: сброс page cache, очистка заранее определённых disk targets, рестарт сервисов и поддерживаемые deploy-шаги. Конкретный инструмент и класс approval видны, а не спрятаны в чужой shell history.

ДОГФУДИНГ ОСНОВАТЕЛЯ / КОНТРОЛИРУЕМЫЙ ТЕСТ

Плановая остановка nginx: восстановление прямо в Telegram-треде

Это реальный тест на собственном production-сервере основателя, а не результат клиента. Nginx остановили намеренно, а узкое правило на перезапуск было разрешено заранее.

  • +В Telegram пришёл алерт об остановке сервиса с действиями Diagnose и Restart.
  • +Policy-слой mttrly разрешил настроенный перезапуск. Outbound-агент выполнил ограниченное действие, после чего mttrly повторно проверил состояние сервиса.
  • +В треде инцидента nginx отмечен как восстановленный с простоем в одну секунду.
  • +История связывает исходный алерт с попыткой восстановления и закрытием инцидента.

Чего этот тест не доказывает

Автоматический перезапуск не является режимом по умолчанию для изменений. В обычном interactive path действие класса approval-required становится pending и ждёт Approve или Reject. Исключения записываются отдельно: применимая preauthorization или заранее одобренная bounded Investigation, которая действует только для mttrly_execute_command. Успешная произвольная команда тоже не считается восстановлением сервиса без отдельной проверки.

Прочитать полный разбор теста →Посмотреть сценарий диагностики недоступного сайта →
Telegram-тред контролируемого теста mttrly: nginx остановлен, разрешённый перезапуск выполнен, инцидент закрыт за одну секунду

Разберите шаги диагностики в сценарии «сайт недоступен» или настройте Telegram для алертов и решений.

Создать аккаунт по emailСначала проверить публичный URL