Сервер упал.
mttrly покажет почему._
/ mät·ter·ly /
Следит за VPS, собирает факты и предлагает следующий шаг. Опасное ждёт твоего подтверждения; каждый шаг пишется в аудит.
Работает на многошаговом AI-разборе - не на общих советах чат-бота.
Проверка снаружи не требует регистрации. Подключи агента, когда будешь готов увидеть сервер изнутри.
Проверка снаружи
Начни без регистрации
Проверь DNS, TLS, доступность и публичные симптомы до того, как открывать SSH.
Факты
Смотри что изменилось
Когда агент подключён, mttrly читает живое состояние сервера, а не гадает по промпту.
Подтверждение
Фикс выбираешь ты
Рискованные рестарты, команды и деплой-действия ждут явного подтверждения.
Аудит
Каждый шаг записан
Запросы, апрувы, действия и результат остаются видимыми после инцидента.
Узнаёшь?
«На моей машине работало»
Выкатил изменение, а продакшен стал белым экраном. SSH открывает стену логов, полезная строка где-то внутри, пользователи уже замечают.
«Что вообще значит эта ошибка?»
ChatGPT объяснит строку ошибки. Но он не видит статус nginx, память процесса, давление на диск и конкретный сервис, который лежит.
«Одна неверная команда — и всё»
Похоже, надо что-то перезапустить. Но какой процесс? Что ещё заденет команда? mttrly держит следующий шаг ограниченным и ждёт твоего решения.
Что mttrly делает на самом деле
Превращает инцидент на живом сервере в контролируемый цикл: заметить, разобрать, подтвердить, проверить.
- →Видит реальное состояние сервера, а не только вставленную строку лога
- →Объясняет вероятную причину обычным языком
- →Держит рискованные действия за подтверждением и аудитом
Цикл инцидента:
1. Следит и ловит
Watchdog проверяет публичные и подключённые серверные сигналы, затем отправляет симптом в дашборд, Telegram или MCP.
2. Диагностирует по фактам
mttrly проверяет процессы, логи, порты, диск, память и метки последних изменений, прежде чем объяснять вероятную причину.
3. Чинит после подтверждения
Предлагает ограниченные следующие шаги. Рестарты, команды и деплой-действия ждут явного апрува и остаются в журнале аудита.
Контроль остаётся у тебя. mttrly делает тяжёлую работу.
Как работает AI
Не чат-бот. Reasoning loop, который проверяет реальное состояние сервера и держит рискованные действия за апрувом.
Watchdog или проверка снаружи ловит симптом и отправляет его в твой workspace.
Быстрая модель определяет тип инцидента и выбирает следующий diagnostic recipe.
Scoped tools читают логи, сервисы, порты, диск, память и метки недавних изменений.
Модель связывает факты, объясняет вероятную причину и оценивает уверенность.
mttrly показывает следующие шаги с уровнем риска, а не прыгает сразу в терминальную команду.
Чувствительные действия ждут апрува из дашборда, Telegram или MCP/IDE-потока.
Агент выполняет только approved action, затем читает новое состояние и проверяет восстановление.
Ты видишь, что случилось, что изменилось и как снизить шанс повтора.
Многошаговый reasoning на инцидент • ограниченные server tools • апрувы и журнал аудита
Старый способ vs с mttrly
«Моё приложение работает?»
Старый способ:
SSH → systemctl status → docker ps → проверить процессы Занимает 5 минут. Надо знать что проверять.
С mttrly:
Спрашиваешь один раз. mttrly проверяет процесс приложения, nginx, соединения с базой и ресурсы, затем возвращает статус обычным языком.
«Почему тормозит?»
Старый способ:
Открыть htop, читать логи, сравнивать последние изменения и надеяться, что помнишь нормальный расход RAM для сервиса.
С mttrly:
Он проверяет RAM, диск, CPU, сеть, логи и последние метки деплоя, затем даёт вероятное узкое место и понятные варианты.
«Покажи ошибки»
Старый способ:
journalctl -u app -n 1000 | grep ERROR Потом листать сотни строк и гадать, какие из них важны.
С mttrly:
Он группирует повторяющиеся ошибки, находит первый новый паттерн, связывает его с недавними изменениями и предлагает безопасный следующий шаг.
«Можно деплоить безопасно?»
Старый способ:
Вручную пройти чеклист: pull, install, migrate, build, restart, verify. Пропустил шаг — платит продакшен.
С mttrly:
Профили деплоя могут выполнять pre-checks, защищённые шаги, post-checks и rollback paths для поддерживаемых режимов. Рискованное всё равно подтверждаешь ты.
Реальные сценарии
Как работают диагностические рецепты на практике
Сценарий 1: «Сайт не работает»
Запускаю диагностику... ✓ Сервер доступен (ping 34ms) ✓ Порт 80 открыт ✓ Порт 443 открыт ✗ Nginx не отвечает Проверяю статус nginx... ✗ Процесс nginx не запущен Читаю лог ошибок nginx... Найдено: "nginx: [emerg] unexpected '}' in /etc/nginx/sites-enabled/default:47" Проблема найдена: В конфиге nginx синтаксическая ошибка в строке 47. Исправь опечатку, потом я перезагружу nginx. Или: хочешь восстановить вчерашний рабочий конфиг?
30 секунд от «сайт не работает» до точного понимания что чинить.
Сценарий 2: «Всё тормозит»
Проверяю... CPU: 23% (норма) Диск: 45% занято (норма) RAM: 94% занято ⚠️ Нашёл проблему: процесс node.js жрёт 3.2GB RAM Проверяю логи на ошибки памяти... Найдено: 127 предупреждений 'JavaScript heap out of memory' Начались: 2 часа назад (сразу после деплоя) Диагноз: Утечка памяти, скорее всего появилась в последнем деплое. Варианты: 1. Перезапустить сервис сейчас (быстрый фикс, утечка вернётся) 2. Откатить на предыдущую версию (безопаснее) 3. Показать мне diff коммита чтобы найти утечку Что делаем?
Реальный анализ. Несколько вариантов. Контроль у тебя.
Начни снаружи, потом подключи изнутри
STEP 01: Запусти проверку снаружи
Сначала проверь публичный URL. Без регистрации, без агента, без доступа к серверу.
STEP 02: Подключи агента
Когда нужны факты изнутри сервера, создай аккаунт и установи outbound-агента на VPS.
Инсталлер создаёт outbound-only агента. Если хочешь проверить точные изменения, посмотри скрипт перед запуском.
STEP 03: Работай через апрувы
Используй дашборд, Telegram или MCP-инструменты, чтобы расследовать, подтверждать рискованные изменения и сохранять журнал аудита.
Твой сервер, твой контроль
✓ Подтверждай там, где работаешь
Апрувы в дашборде используют passkey для биометрического подтверждения. Telegram остаётся доступен на ходу. MCP и мессенджеры работают по отдельным trust-моделям.
✓ Не прямой SSH
Выполнение команд есть как ограниченное MCP-действие с подтверждением и аудитом. Обычный путь — диагностика, playbooks и серверные инструменты, а не свободный терминал для AI.
✓ BYOK — твой AI, твои расходы
Приноси свой ключ OpenAI/Anthropic. Без наценки, прозрачные расходы. Или используй нашу AI-инфраструктуру (3900₽/мес включает AI).
✓ Не нужно открывать порты
Агент подключается только наружу. Файрвол остаётся закрытым. Нулевая поверхность атаки.
MCP-интеграция
Работает из твоей IDE.
Подключи mttrly к Claude Code, Cursor или OpenAI Codex через Model Context Protocol. Проверяй алерты, запускай диагностику, смотри факты и запрашивай действия с подтверждением, не выходя из редактора.
Все 40 инструментовclaude mcp add mttrly --transport http https://api.mttrly.com/mcp{ "mcpServers": { "mttrly": { "url": "https://api.mttrly.com/mcp" } } }[mcp_servers.mttrly] url = "https://api.mttrly.com/mcp"Работает в продакшене
Production-метрики внутренней инфраструктуры, март 2026.
Новое в блоге
Реальные инциденты, фиксы и заметки восстановления из продакшена.
Короткие практичные разборы того серверного хаоса, который люди ищут, когда всё ломается в худший момент.
I kept telling my AI to stop using SSH. Here's what it found instead.
Claude Code had full SSH access to my server. Every time it used it, I made it switch to the monitoring bot. The difference in what it saw wasn't what I expected.
Alert fatigue almost made me turn off my own monitoring.
My monitoring sent an alert. Healthcheck said all good. Services said all running. Someone was lying — and it took me an hour to find out who.
I put an AI agent on my server. It quietly deleted my own feature.
I wanted autonomous server management. What I got was a lesson in why AI agents need a confirmation step before touching production.
Частые вопросы
Перестань бояться продакшена.
Начни с того, что видно интернету. Подключи агента, когда понадобятся факты изнутри сервера и фиксы с подтверждением.
Проверка снаружи без регистрации • Watchdog бесплатно • AI-функции от 3900₽/мес