Senior DevOps

TeamLead DevOps

Предисловие

На протяжении почти 7 лет работы DevOps-инженером я терпеть не мог мониторинг, алерты и всё, что с ними связано. Не только ненавидел их настраивать, но и особенно — разгребать утром после ночного дежурства.

Сидишь, просматриваешь десятки алертов, глаза замыливаются, а контекста — ноль. Хочется просто нажать волшебную кнопку и сразу понять, что сломалось и как починить.

Наконец появился ИИ — и с ним — надежда. Представьте: приходишь утром, завариваешь кофе, заходишь в Slack — а там каналы взрываются от алертов. Упало что-то, кончилось место, пошли странные ошибки.

Тратишь полчаса на расследование — и выясняется: коллеги из соседнего отдела провели нагрузочное тестирование, положили полинфраструктуры и забыли предупредить.

При этом у нас 10 продовых стендов и три облака: Yandex, AWS, DigitalOcean. В каждом — свои базы, Kubernetes, стек мониторинга: VictoriaMetrics, Grafana, Loki, Alertmanager, «кролики», «редиски». Всё это нужно держать в голове, чтобы решить хотя бы один инцидент.

Однажды терпение лопнуло. Мы с коллегой решили создать помощника — ИИ-агента, который будет иметь доступ ко всей инфраструктуре и выдавать полный контекст по алерту, писать команды и советовать действия.

PoC (Proof of Concept)

У нас была идея и желание. Нужно было быстро собрать прототип. В наличии: Kubernetes, стек мониторинга и три облака. Всё это следовало подключить к боту с правами только на чтение.

Мы услышали про n8n — инструмент для оркестрации. Решили попробовать. Удивились, сколько уже появилось MCP-серверов — специальных шлюзов для связи ИИ с внешними системами.

MCP — это специальный протокол общения между ИИ и внешними сервисами.

Оказалось, для всех наших систем уже есть MCP-серверы: для Alertmanager, VictoriaMetrics, Yandex Cloud, Kubernetes. Подняли alertmanager-mcp, vmetrics-mcp, yandex-tool-kit, k8s-mcp и с помощью ИИ написали workflow в n8n.

Но начались проблемы. Оказалось, не все ИИ одинаково полезны. Одни хороши в генерации текста, другие — в поиске, третьи — в работе с MCP.

Сначала попробовали корпоративную Gemini. Она не хотела работать с MCP: то подпись не нравилась, то вызывала один и тот же инструмент по 100 раз. Полный провал.

Перешли на Claude. Сначала казалось — работает. Но агент уходил в бесконечные циклы: вызывал одни и те же инструменты снова и снова. Галлюцинировал.

После часов гугления поняли: обычная модель слишком прямолинейна. Нужен режим thinking mode — с рассуждением.

И — о чудо — заработало. Модель начала понимать, что пустой ответ от сервиса — это ненормально. Мы начали тюнить промпт, чтобы агент лучше понимал задачу. После множества итераций добились вменяемого результата.

Промпт стал строго структурированным: задавал текущую среду, дату, доступные инструменты и правила их использования. Например:

• vmetrics — для запросов к VictoriaMetrics. Только с правильными временными диапазонами.
• k8s_mcp — для получения состояния подов. Контекст берётся из таблицы соответствий.
• loki — только для поиска ошибок в логах. Диапазон — не более часа.
• yandex-cloud-toolkit — только для Compute, VPC, IAM, YDB, S3. Не работает с managed-сервисами.
• argocd_mcp — только для получения статуса приложения. Запрещено запрашивать список всех приложений.
• alertmanager_mcp — для управления silences. С проверкой на дубли.

Были чёткие правила:

• Не выдумывать данные — только то, что вернули инструменты.
• Не вызывать один и тот же инструмент с одинаковыми параметрами больше двух раз.
• Если инструмент вернул пустой ответ дважды — остановиться.
• Если лог уже показал причину — не запрашивать дополнительные метрики.

Формат ответа — строго по шаблону в Slack:

• Начинается с эмодзи: 🔴 (critical), 🟡 (warning), 🟢 (остальное).
• Диагноз — кратко, в одном предложении.
• Что нашёл — с цифрами: restarts, exitCode, ошибки в логах.
• Список действий — 1–3 шага.
• Проверено — какие инструменты вызваны и что вернули.
• Трейс — только вызванные инструменты с отметками ✓ или ✗.

Мы показали коллегам. Те были в восторге. Бот выдавал готовые команды — копируй, вставляй в терминал — и проблема решена.

Production Ready

После успешного PoC решили: пора отдавать миру. Мы столько брали из open source — теперь хотим дать что-то взамен.

Но мы не хотели, чтобы люди мучались с кучей MCP-серверов и кривыми промптами в n8n. Хотели — один бинарник или контейнер, и всё работает из коробки.

Так родился SherlockOps — полноценный сервис на Go. Мы встроили более 50 интеграций: AWS, GCP, Azure, Kubernetes, СУБД. Никаких сторонних MCP-серверов — всё «под капотом».

Чтобы решить проблему с 10 стендами, добавили поддержку мультиокружений. По заголовку X-Environment сервис сам определяет, в каком кластере что упало, и переключает контексты.

Теперь DevOps-инженеру нужно просто установить SherlockOps (инструкции — в репозитории на GitHub), настроить receiver в Alertmanager — и 70% времени на разбор алертов экономится.

Есть и ручной режим — ChatOps. Просто отметь бота: @SherlockOps analyze — и он проведёт расследование по запросу.

У сервиса есть внутренний дашборд: сколько алертов обработано, какие инструменты использовались, сколько потрачено токенов и ресурсов.

Чтоб потом показывать своему big boss и доказывать, что ИИ стоит сущие копейки по сравнению с профитом.

Senior DevOps

TeamLead DevOps

Предисловие

На протяжении всего моего опыта работы DevOps-инженером (а это около 6–7 лет) я всегда терпеть не мог мониторинг, алерты и всё что с этим связано. Мало того, что я не любил всё это настраивать, но больше всего я ненавидел получать и резолвить алерты. Сидишь такой, разгребаешь всю эту кучку, и в какой-то момент глаз уже замыливается, и ты вообще не понимаешь, что происходит.

Поэтому мне всегда хотелось иметь какую-то волшебную кнопку, по нажатию на которую я бы мог получить полный контекст алерта. И, аллилуйя, появился ИИ.

Начало рабочего дня, прекрасное настроение, завариваю кофеёк, сажусь за комп и с полным воодушевлением начинаю работать. Но не тут-то было! Захожу в Slack и вижу каналы, которые просто разрываются от алертов: что-то тут упало, где-то место кончилось, где-то непонятные ошибки.

Приходится всё это начинать разгребать. И в процессе, потратив 30 минут своего времени на дебаг, я понимаю, что это, оказывается, коллеги из соседнего отдела решили провести нагрузочное тестирование, положили пол-инфраструктуры и забыли уведомить команду DevOps.

Для понимания масштабов трагедии: на моем текущем месте работы около 10 стендов (продов) и 3 вида облака. В каждом стенде свои базы, свой Kubernetes, свой стек мониторинга (vmetrics, grafana, loki, alertmanager), «кролики», «редиски»... И весь этот зоопарк нужно держать в голове, дабы решить какой-нибудь инцидент или алерт.

Но в один из дней мое терпение таки лопнуло. И мы с моим коллегой решили создать помощника, который будет иметь доступ ко всей инфре и за счет этого давать максимально полный контекст, писать уже готовые команды или советовать действия по решению проблемы.

PoC (Proof of Concept)

Итак, что мы имеем: идею и кривые руки. Думаем, надо накидать что-нибудь по-быстрому на коленке, дабы просто потестить, как это вообще будет работать.

У нас есть: K8s, стек мониторинга (vmetrics, grafana, loki, alertmanager) и клауды (Yandex, AWS, DigitalOcean). Всё это добро нам надо как-то завести в нашего бота, да так, чтобы он там не накуролесил - то есть выдать строго ReadOnly доступ.

В каких-то devops-пабликах мы как-то слышали о n8n. Думаем: кажется, это то, что нам надо, да и времени на настройку займет немного. Начинаем ресёрчить эту тулзу и удивляемся, как за такой короткий период хайпа ИИ появилось множество MCP-серверов.

MCP - это специальный протокол общения между ИИ и внешними сервисами

Оказалось, MCP-серверы существуют буквально для всего, что у нас используется в инфраструктуре. Отлично, то, что доктор прописал! Поднимаюalertmanager-mcp,vmetrics-mcp,yandex-tool-kit,k8s-mcpи при помощи самого ИИ пишем workflow для n8n (да-да, а как по-другому в наших реалиях?).

И тут начались первые проблемы. Оказывается, не все ИИ одинаково полезны: некоторые хороши, чтоб писать текст, некоторые круто справляются с поиском информации, а некоторые хорошо работают как раз с этими MCP-серверами.

И так как у нас есть корпоративная Gemini, естественно, в первую очередь мы пробуем её. Но эта гугловая LLM ну никак не хотела работать с MCP: то ей какая-то подпись не нравится, то она этот MCP вызывает по 100 раз. Короче, полная фигня.

Возможно, мы и криворукие, конечно, но после этого мы посмотрели в сторону Claude, который ну уж точно должен был отлично отработать. Написали какой-то суперпростенький промпт, и вроде бы оно даже завелось. Но и тут меня ждали большие проблемы. Агент всё время уходил в бесконечный цикл (галлюцинировал) - просто по миллиону раз дёргал одни и те же тулзы, и это только одна из бед.

(После многочасового гугления и общения с ИИ мы понимаем, что для этой задачи обычная модель ну никак не подходит, так как она слишком прямолинейная. Нужно врубать thinking mode).

И о чудо, оно работает! Модель понимает, что если мы дёргаем сервис с пустыми полями и ничего не возвращается - это ненормально. Мы начали тюнить сам промпт так, чтобы агент плюс-минус понимал, чего я от него вообще хотят. И, снова чудо, после миллиона попыток переписать этот чёртов промпт, мы добились хоть какого-то вменяемого результата.

ТЕКУЩАЯ СРЕДА: XXXX-{{ $(‘Prepare Env’).first().json.cluster }} Yandex Cloud: cloud_id: XXXXXX folder_id: {{ $(‘Prepare Env’).first().json.folder_id }} cluster label в MetricQL: cluster=“{{ $(‘Prepare Env’).first().json.cluster }}”

ВСЕГДА передавай эти folder_id и cloud_id в каждый вызов yandex-cloud-toolkit.

ТЕКУЩАЯ ДАТА: {{ $now.toISO() }}

Ты — DevOps on-call агент. Язык: ТОЛЬКО русский.

ОПРЕДЕЛЕНИЕ СРЕДЫ: Текущая среда указана в заголовке этого системного сообщения (ТЕКУЩАЯ СРЕДА: XXXX-XXX). Используй инструменты vmetrics и loki — они уже настроены на правильный endpoint текущей среды. Если среда не определена — это указано в заголовке, используй данные “как есть”.

ИНСТРУМЕНТЫ: • vmetrics — PromQL-запросы к VictoriaMetrics текущей среды. Для instant-запросов: передавай только query. Для range-запросов: ВСЕГДА указывай start=“-30m” и end=“now”. ЗАПРЕЩЕНО unix timestamps в start/end. • Data table (k8s_clusters) — маппинг cluster → kubeconfig_context для k8s_mcp. • k8s_mcp — состояние K8s ресурсов. context = kubeconfig_context из Data table (НЕ cluster label из алерта). • loki — логи из Loki текущей среды. Только для crash/OOM/ошибок приложения. start/end: строки “-30m”/“-1h”/“now”, ЗАПРЕЩЕНО unix timestamps. • yandex-cloud-toolkit — ТОЛЬКО: Compute (VM/диски), VPC (сети), IAM, YDB, S3. НЕ поддерживает: managed-postgresql, managed-mysql, managed-redis, managed-kafka и другие managed DB. Если алерт с service=“managed-postgresql” — НЕ вызывай yandex-cloud-toolkit, данных по PostgreSQL там нет. Диагностируй только по vmetrics метрикам. cloud_id и folder_id берёшь из секции ТЕКУЩАЯ СРЕДА в начале системного сообщения. ВСЕГДА передавай оба параметра в каждый вызов. Без folder_id вызов упадёт с ошибкой. • argocd_mcp — статус ArgoCD Application. Имя приложения выводи из лейблов алерта: {project}-{cluster}-{container/deployment} → например XXXXX-infra-tag-creator. Единственный допустимый вызов: get_application(applicationName=“<имя>”). ЗАПРЕЩЕНО: list_applications в любом виде — возвращает все 1745 приложений (2.4MB) и ломает агента. • alertmanager_mcp — управление silences в Alertmanager текущей среды. ДОСТУПНЫЕ ОПЕРАЦИИ:

• get_silences() — список активных silences
• post_silence(silence) — создать silence. Параметр silence — JSON объект: {“matchers”: [{“name”: “alertname”, “value”: “KubePodCrashLooping”, “isRegex”: false}], “startsAt”: “2026-03-21T12:00:00.000Z”, “endsAt”: “2026-03-21T14:00:00.000Z”, “createdBy”: “n8n-alerts-bot”, “comment”: "Silenced via@botcommand"} ВАЖНО: startsAt = ТЕКУЩЕЕ время (бери из ТЕКУЩАЯ ДАТА в начале сообщения), endsAt = startsAt + duration. Даты ОБЯЗАТЕЛЬНО в будущем (не в прошлом!). Формат: ISO 8601 с Z (UTC).
• delete_silence(silence_id) — удалить silence по ID
• get_alerts() — список активных алертов в Alertmanager SILENCE DURATION: по умолчанию 2h. Если пользователь указал другую (например “4h”, “30m”, “1d”) — использовать указанную. MATCHER: формируй из labelsRaw алерта. Обязательно включай alertname. ПОРЯДОК ДЕЙСТВИЙ ДЛЯ SILENCE:Сначала get_silences() — проверить нет ли уже active silence на этот alertnameЕсли уже есть active silence → НЕ создавать дубликат, сообщить что silence уже существует (ID, endsAt)Если нет → один вызов post_silence. ЗАПРЕЩЕНО вызывать post_silence повторно. ПОРЯДОК ДЕЙСТВИЙ ДЛЯ UNSILENCE:get_silences() → найти active silences по alertnamedelete_silence(id) для каждого найденногоЕсли delete вернул ошибку — сообщить пользователю, не повторять ОТВЕТ ПОСЛЕ SILENCE: “Silence создан на {duration} для {alertname} [{env}]. ID: {id}” ОТВЕТ ПОСЛЕ UNSILENCE: “Silence удалён для {alertname} [{env}]. ID: {id}” Если несколько active silences по alertname — удалить все, сообщить сколько удалено.

ЛЕЙБЛЫ В METRICQL: ПЕРЕД построением PromQL — проанализируй Labels (labelsRaw) алерта. Используй в запросах ТОЛЬКО те лейблы, которые РЕАЛЬНО присутствуют в labelsRaw. • Если есть project и cluster → используй их: {project=“XXXX”, cluster=“prod”} • Если project/cluster ОТСУТСТВУЮТ → НЕ добавляй их. Строй запрос по лейблам из алерта (name, job, instance, device, mountpoint и т.д.) • Выбирай из labelsRaw те лейблы, которые идентифицируют конкретный ресурс для данной метрики.

ПРАВИЛА: • Не выдумывать данные — только то что вернули инструменты. • k8s_mcp: если label selector вернул пусто — использовать pods_get по имени из Labels алерта. • Ошибка 422 “too many points” из vmetrics = ты передал unix timestamp или слишком широкий диапазон. Переключись на instant-запрос (без start/end) или укажи start=“-30m” end=“now”. НЕ повторяй тот же вызов. • ЗАПРЕЩЕНО вызывать один и тот же инструмент с одинаковыми параметрами более 2 раз. Если повторный вызов не дал новых данных — пиши финальный ответ с тем что есть. • Если инструмент вернул пустой ответ 2 раза подряд — прекращай попытки по этому направлению.

@BOTКОМАНДЫ: Когда в есть текст — это@botупоминание в треде алерта. Агент понимает свободную речь на русском и английском: • “silence 2h”, “замьюти на 4 часа”, “silence” → создать silence (duration из текста или 2h по умолчанию) • “unsilence”, “размьюти”, “убери silence” → удалить active silence по alertname • “reanalyze”, “переанализируй”, “посмотри ещё раз”, “что с этим?” → полный анализ алерта (стандартный протокол) • Любой другой текст — проанализировать алерт и ответить на конкретный вопрос пользователя

Если отсутствует — это обычный алерт, работай по стандартному протоколу.

СТОП-КРИТЕРИИ (КРИТИЧЕСКИ ВАЖНО):

Типовой план расследования:

1. vmetrics — метрики по алерту (restarts, memory, cpu, free_servers и т.д.)
2. Data table — получить kubeconfig_context (только для k8s-алертов)
3. k8s_mcp — pods_log previous=true ИЛИ pods_get (одно из двух, не оба)
4. argocd_mcp — get_application (если релевантно)
5. loki — только если pods_log не дал причину

НЕМЕДЛЕННО пиши финальный ответ когда выполнено ЛЮБОЕ из условий: • Лог контейнера содержит “Killed”, “OOMKilled”, “Error”, конкретную ошибку → причина найдена, СТОП • vmetrics показал restarts > 0 и ты знаешь reason (CrashLoopBackOff, OOM, и т.д.) → СТОП • У тебя есть ответ на “почему алерт firing?” и можешь написать шаги → СТОП • Сделано 5+ вызовов → СТОП, пиши с тем что есть • НЕ делай “проверок для уверенности”, НЕ describe подов если причина уже ясна из логов • НЕ запрашивай memory/cpu метрики если лог уже показал причину краша

ФОРМАТ ОТВЕТА (Slack mrkdwn):

Severity: первая строка ответа начинается с эмодзи уровня серьёзности. Определение: по label severity из алерта (critical → 🔴, warning → 🟡, иначе → 🟢). Повышение: если root cause тяжелее label-а (например, warning но OOMKilled с сотнями рестартов) — повысь до 🔴. Понижение ЗАПРЕЩЕНО: severity ответа >= severity из label-а.

Обязательные секции (именно в таком порядке):

🔴/🟡/🟢Диагноз:<причина в одном предложении>

Что нашёл:<1-2 строки прозы с объяснением><ключевые цифры через | — restarts, exitCode, limit, лог>

1. <действие>
2. <действие>
3. <действие>

Проверено: <список вызванных инструментов с результатом>

Трейс инструментов (последняя строка): • Показывать ТОЛЬКО вызванные инструменты. • ✓ = инструмент вызван и вернул данные. • ✗ = инструмент вызван но вернул пусто или ошибку. • Не вызванный инструмент — НЕ упоминать. • Пример pod-алерт:Проверено: vmetrics ✓ k8s ✓ loki ✗• Пример disk-алерт без Loki:Проверено: vmetrics ✓ k8s ✓

Разметка:bold= один asterisk, курсив трейса =текст. ЗАПРЕЩЕНО: **, ##, —

Естественно, мы пошели сразу выпендриваться перед коллегами, какие мы крутые и какой сервис запилили. На удивление, всё это очень даже зашло. Ребята начали отмечать, что это суперудобно: порой ты просто копируешь команды, которые тебе выдал бот, вставляешь их в терминал, и алерт решён!

Production Ready

Ну что ж, после успешного PoC мы подумали: за всю свою карьеру мы столько заимствовал у опенсорс-комьюнити и почти ничего не давали взамен. Решаемся запилить сервис, который будет помогать таким же людям, как и мы, которые терпеть не могут резолвить алерты.

Но при этом мы хотели сделать так, чтобы пользователям не приходилось заморачиваться с поднятием всей обвязки из кучи MCP-тулзов и костыльных промптов в n8n. Мы хотели, чтобы человек просто взял, запустил единый бинарник/контейнер - и всё работало из коробки.

Собственно, так n8n-черновик превратился вSherlockOps- полноценный самостоятельный сервис на Go. В него мы нативно «зашили» более 50 интеграций (AWS, GCP, Azure, Kubernetes, базы данных). Больше никакого зоопарка сайдкаров! А чтобы закрыть ту самую боль с 10 стендами, мы добавили поддержку мульти-окружений: сервис по заголовкуX-Environmentсам понимает, в каком кластере упал под, и переключает контексты и эндпоинты.

И к чему мы в итоге пришли? Тебе как DevOps-у нужно всего лишь заинсталлить сервис SherlockOps (указав нужные энвы, с инструкцией можно ознакомитьсяhttps://github.com/Duops/SherlockOps). Далее в Alertmanager просто указываешь новыйreceiver, и всё - считай, ты сэкономил 70% своего времени на решение очередного алерта.

Кстати, можно даже не ждать, пока что-то сломается. Мы добавили ручной режим (ChatOps): просто тегаешь бота в треде@SherlockOps analyze, и он проводит расследование по твоему запросу в реальном времени.

Мало того, у сервиса «под капотом» есть дашборд. Там можно мониторить, сколько алертов было проанализировано, какие инструменты использовались и сколько токенов/средств он на это потратил.

Чтоб потом показывать своему big boss и доказывать, что ИИ стоит сущие копейки по сравнению с профитом