Представьте, что ваш дежурный инженер не спит, не пьёт кофе и читает логи со скоростью тысячи строк в секунду — при этом не жалуется на жизнь. OpenSRE — это попытка собрать такого цифрового коллегу…
Представьте, что ваш дежурный инженер не спит, не пьёт кофе и читает логи со скоростью тысячи строк в секунду — при этом не жалуется на жизнь. OpenSRE — это попытка собрать такого цифрового коллегу из подручных материалов, используя Python и современные LLM.
Любой SRE знает ночной звонок: CPU на проде зашкаливает, а вы по SSH вспоминаете, какие команды проверяли три месяца назад. Runbook лежит в Confluence, но он устарел, а Grafana показывает метрики, требующие интерпретации. Раньше выход был один — будить старшего товарища или часами копаться в терминале, восстанавливая контекст инцидента.
Судя по описанию и структуре Python-проекта, перед нами фреймворк для оркестрации агентов, а не готовое приложение. Основная концепция — декомпозиция задач SRE на атомарные инструменты: один модуль умеет запрашивать данные, другой — анализировать логи через LLM, третий — выполнять команды в терминале. Агент собирает эти инструменты в цепочку рассуждений, получает алерт и проходит путь от диагностики до фиксации либо эскалации с human-in-the-loop. Ключевая фишка — расширяемость: вы добавляете свои инструменты под специфику вашей инфраструктуры, не переписывая ядро.
Чтобы запустить базовую версию и посмотреть на поведение агента:
1. Клонируем репозиторий: git clone https://github.com/Tracer-Cloud/opensre.git && cd opensre
2. Устанавливаем зависимости: pip install -e . — судя по наличию setup.py, проект ставится как пакет
3. Настраиваем окружение: копируем .env.example в .env и прописываем API-ключ к OpenAI или Anthropic, а также credentials для доступа к вашим системам
4. Запускаем пример: python examples/basic_agent.py — на практике нужно проверить точное имя файла в папке examples, но обычно там есть демо с симуляцией инцидента
На практике выгоднее всего начать с 'первой линии поддержки'. Настраиваете агента на обработку рутинных алертов: закончилось место на диске, упал некритичный микросервис, завис бэкап. Агент проверяет контекст, пробует стандартные фиксы — очистку логов старше семи дней или рестарт пода — и только если не справляется, будит человека с готовым summary: что случилось, какие метрики аномальны, что уже пробовали и почему не сработало. Экономия — 30–40 минут на каждый ночной вызов.
Второй рабочий сценарий — автоматизация постмортемов. После инцидента агент собирает таймлайн из логов приложения, метрик за час до и после события, коммитов, попавших в деплой, и действий команды из чатов. На выходе получаете Markdown-документ в формате 'триггер → импакт → корневая причина → действия по предотвращению'. То, на что у инженера ушёл бы час работы с копипастой, агент делает за пять минут, пока вы пьёте кофе.
Типичные грабли при первом знакомстве: даёте агенту слишком широкие полномочия. LLM иногда принимает решения с 'творческим' подходом — доходит до предложений удалить 'лишние' файлы или пересоздать все поды в неймспейсе. Начинайте с read-only доступа к логам и правами только на перезапуск конкретных некритичных сервисов. Вторая ошибка — игнорировать контекст компании. Агент не знает архитектурных тонкостей, пока вы не загрузили ему актуальную документацию. Третья — недооценивать стоимость API. При частых алертах счёт за токены GPT-4 может превысить зарплату дежурного. Нужно фильтровать флуд и кэшировать частые сценарии.
Берите, если у вас более 50 алертов в неделю, из которых 70% — рутина вроде перезапусков и очистки дисков; если команда тратит больше времени на диагностику, чем на улучшение архитектуры; и если есть чёткие runbook'и, которые можно формализовать в код. Не нужно, если инфраструктура умещается на трёх серверах — проще настроить стандартный мониторинг; если в документации полный хаос — агент только усилит бардак; или если ваши регуляторные требования запрещают автоматические действия без явного одобрения человека, как в классическом финтехе с жёстким аудитом.