В 2014 году Kubernetes выглядел для многих инженеров странной игрушкой от Google. Зачем городить сложную систему оркестрации, если есть виртуальные машины, Bash-скрипты и проверенные временем конфигурации? Прошло несколько лет, и Kubernetes превратился в стандарт де-факто. Он изменил подход к доставке приложений, масштабированию и эксплуатации инфраструктуры.

Сегодня мы наблюдаем похожую ситуацию. На рынке искусственного интеллекта появляется множество новых терминов: агенты, инструменты, контекст, расширения. Среди них легко пропустить технологию, которая потенциально способна изменить повседневную работу инженеров не меньше, чем когда-то изменил её Kubernetes. Речь идёт о Model Context Protocol, или MCP.

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

Почему обычный ИИ бесполезен для эксплуатации

Большие языковые модели уже умеют многое. Они пишут код, объясняют ошибки, помогают составлять документацию и даже предлагают архитектурные решения. Однако у них есть фундаментальное ограничение: они ничего не знают о вашем окружении.

Допустим, инженер задаёт вопрос:

Почему в продакшене не запускается сервис оплаты?

Обычная модель ответит набором рекомендаций:

  • проверьте состояние Pod;

  • изучите логи контейнеров;

  • убедитесь в доступности базы данных;

  • проверьте последние изменения в коде;

  • посмотрите метрики.

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

Она не может выполнить:

kubectl get pods -A

Не способна посмотреть логи:

kubectl logs payment-api-7cbbf6fbd \
  -n production

Не может открыть GitLab и изучить последние коммиты:

git log --oneline -10

Не имеет доступа к Prometheus, Grafana или Jira.

То есть ИИ умеет рассуждать, но не умеет действовать. Именно этот разрыв и устраняет MCP.

Что такое MCP

Model Context Protocol представляет собой открытый протокол взаимодействия между языковой моделью и внешними инструментами.

Проще говоря, MCP определяет единый способ, с помощью которого искусственный интеллект может использовать реальные системы.

Вместо абстрактных рекомендаций модель получает возможность:

  • обращаться к API;

  • выполнять команды;

  • читать документацию;

  • анализировать метрики;

  • взаимодействовать с системами контроля версий;

  • запускать автоматизацию;

  • получать данные из внутренних сервисов компании.

Если провести аналогию, то Kubernetes дал инженерам универсальный API для управления контейнерами. MCP создаёт универсальный API для управления знаниями и действиями искусственного интеллекта.

Как выглядит архитектура MCP

Упрощённая схема выглядит следующим образом:

Инженер
    ↓
LLM (ChatGPT, Claude, локальная модель)
    ↓
MCP Client
    ↓
MCP Server
    ↓
Инструменты и API

В качестве инструментов могут использоваться:

  • Kubernetes;

  • GitLab;

  • GitHub;

  • Jenkins;

  • Jira;

  • Confluence;

  • Prometheus;

  • Grafana;

  • Terraform;

  • Ansible;

  • внутренние API компании.

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

Kubernetes глазами MCP

Представим, что у нас есть MCP-сервер, умеющий работать с Kubernetes API.

Инженер задаёт вопрос:

Покажи все Pod в состоянии CrashLoopBackOff.

За кулисами MCP может выполнить:

kubectl get pods -A \
  -o jsonpath='{range .items[*]}{.metadata.namespace}{" "}{.metadata.name}{" "}{.status.containerStatuses[*].state.waiting.reason}{"\n"}{end}' \
| grep CrashLoopBackOff

Результат:

production payment-api-7cbbf6fbd CrashLoopBackOff
monitoring loki-write-0 CrashLoopBackOff

Следующий вопрос:

Покажи причину падения payment-api.

Тогда автоматически выполняется:

kubectl logs \
  -n production \
  payment-api-7cbbf6fbd \
  --previous

Модель анализирует вывод и сообщает:

Контейнер завершился из-за ошибки подключения к PostgreSQL. Обнаружено превышение лимита подключений.

Раньше инженер вручную переходил между терминалом, Grafana и документацией. Теперь значительная часть рутинной диагностики автоматизируется.

GitLab как источник истины

Опытные инженеры знают: очень часто причиной инцидента становится вовсе не отказ оборудования и не загадочная ошибка в Kubernetes. Виновником оказывается изменение, которое было внесено буквально несколько минут назад.

После ночного звонка дежурному инженеру приходится открывать GitLab, искать последний Merge Request, изучать историю коммитов и пытаться сопоставить время выкладки с началом деградации сервиса. В небольших командах это занимает несколько минут. В крупных организациях с десятками релизов ежедневно поиск причины может растянуться на часы.

С использованием MCP этот сценарий выглядит иначе.

Инженер задаёт вопрос:

Какие изменения были внесены перед началом инцидента?

MCP обращается к GitLab API:

curl \
  --header "PRIVATE-TOKEN: ${TOKEN}" \
  "https://gitlab.example.com/api/v4/projects/42/repository/commits"

Получив список последних изменений:

[
  {
    "id": "2f1ab3",
    "title": "Increase postgres pool size"
  },
  {
    "id": "6bc441",
    "title": "Update ingress annotations"
  },
  {
    "id": "98e2df",
    "title": "Refactor payment retries"
  }
]

Затем MCP может автоматически получить содержимое конкретного коммита:

curl \
  --header "PRIVATE-TOKEN: ${TOKEN}" \
  "https://gitlab.example.com/api/v4/projects/42/repository/commits/2f1ab3/diff"

После анализа модель формирует понятный инженеру вывод:

За три минуты до появления ошибок был увеличен размер пула подключений PostgreSQL. Конфигурация превышает максимально допустимое количество соединений на сервере базы данных. Вероятная причина инцидента - изменение параметров подключения.

По сути MCP начинает выполнять роль очень внимательного коллеги, который никогда не забывает проверить последние изменения.

Prometheus больше не требует знания PromQL

Prometheus давно стал стандартом наблюдаемости, но честно признаемся: далеко не каждый инженер помнит синтаксис PromQL настолько хорошо, чтобы быстро строить сложные запросы под давлением инцидента.

Вместо этого появляется возможность задавать вопросы на естественном языке.

Например:

Покажи рост ошибок HTTP 500 за последний час.

MCP преобразует запрос в PromQL:

curl -G \
  http://prometheus:9090/api/v1/query \
  --data-urlencode \
  'query=sum(rate(http_requests_total{status=~"5.."}[5m]))'

Ответ Prometheus:

{
  "status": "success",
  "data": {
    "result": [
      {
        "value": [
          1718567400,
          "34.7"
        ]
      }
    ]
  }
}

После чего модель сообщает:

Количество ошибок выросло с 2 до 35 запросов в секунду. Рост начался в 01:14 UTC и совпадает по времени с выкладкой версии 1.14.

Другой пример:

Какие сервисы потребляют больше всего памяти?

MCP может сформировать следующий запрос:

curl -G \
  http://prometheus:9090/api/v1/query \
  --data-urlencode \
  'query=topk(5,container_memory_working_set_bytes)'

И вернуть результат в понятном виде:

1. payment-api      4.8 GiB
2. recommendation   3.9 GiB
3. elasticsearch    3.1 GiB
4. rabbitmq         2.4 GiB
5. grafana          1.2 GiB

Инженеру больше не нужно вспоминать точный синтаксис. Он формулирует намерение, а MCP берёт на себя работу переводчика.

Terraform как диалог

Ещё одна область, где MCP способен серьёзно изменить процессы, - инфраструктурный код.

Представим запрос:

Подготовь Terraform для создания S3-хранилища резервных копий с включённым версионированием.

Модель формирует конфигурацию:

resource "aws_s3_bucket" "backup" {
  bucket = "company-backups"

  tags = {
    Environment = "production"
    ManagedBy   = "terraform"
  }
}

resource "aws_s3_bucket_versioning" "backup" {
  bucket = aws_s3_bucket.backup.id

  versioning_configuration {
    status = "Enabled"
  }
}

Но самое интересное начинается дальше.

Инженер может уточнить:

Добавь шифрование и запрети публичный доступ.

MCP дополнит конфигурацию:

resource "aws_s3_bucket_server_side_encryption_configuration" "backup" {
  bucket = aws_s3_bucket.backup.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

resource "aws_s3_bucket_public_access_block" "backup" {
  bucket = aws_s3_bucket.backup.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

После чего вместо немедленного применения создаётся Merge Request для проверки коллегами.

Такой подход гораздо ближе к существующим практикам GitOps, чем к бездумной автоматизации.

Ansible без копирования старых ролей

У многих инженеров есть специальная папка, где лежат playbook, написанные ещё во времена динозавров и CentOS 6. Эти файлы кочуют из проекта в проект, обрастая комментариями и временными решениями.

MCP может существенно упростить этот процесс.

Запрос:

Подготовь playbook для установки node-exporter на Ubuntu.

Результат:

---
- name: Install Node Exporter
  hosts: linux
  become: true

  tasks:
    - name: Create user
      user:
        name: node_exporter
        shell: /usr/sbin/nologin

    - name: Download archive
      get_url:
        url: https://github.com/prometheus/node_exporter/releases/download/v1.9.1/node_exporter.tar.gz
        dest: /tmp/node_exporter.tar.gz

    - name: Extract archive
      unarchive:
        src: /tmp/node_exporter.tar.gz
        dest: /opt
        remote_src: true

Но и здесь ключевым остаётся человеческий контроль. MCP подготавливает изменения, а инженер принимает окончательное решение.

Postmortem без боли и копирования из десяти вкладок

Любой инженер, которому хотя бы раз приходилось писать отчёт после ночного инцидента, знает: устранить проблему зачастую проще, чем потом восстановить полную картину произошедшего.

Нужно выяснить:

  • когда началась деградация;

  • кто был дежурным;

  • какие алерты сработали первыми;

  • какие изменения выкатывались;

  • какие действия предпринимались;

  • когда сервис был восстановлен;

  • какие выводы необходимо сделать.

Обычно это выглядит как археологическая экспедиция. Инженер открывает Grafana, затем GitLab, затем Slack или корпоративный мессенджер, потом Jira, после чего пытается собрать хронологию событий вручную.

MCP способен превратить этот процесс в автоматизированный сценарий.

Запрос:

Подготовь Postmortem по инциденту payment-api за последние 24 часа.

В этот момент MCP может выполнить цепочку действий:

Prometheus  → время возникновения ошибок
Grafana     → графики деградации
GitLab      → последние изменения
Jira        → связанные задачи
Kubernetes  → события кластера
Slack       → переписка дежурной смены

Например, для получения событий Kubernetes может использоваться команда:

kubectl get events \
  -n production \
  --sort-by=.metadata.creationTimestamp

Для поиска последних изменений:

git log \
  --since="24 hours ago" \
  --oneline

В результате формируется практически готовый документ:

# Postmortem: payment-api

Дата:
2026-06-15

Время начала:
01:14 UTC

Симптомы:
Рост количества ошибок HTTP 502.

Причина:
Изменение конфигурации пула подключений PostgreSQL.

Воздействие:
Недоступность сервиса оплаты в течение 12 минут.

Предпринятые действия:
- анализ логов;
- проверка метрик;
- откат Deployment;
- контрольная проверка.

Время восстановления:
01:26 UTC

Рекомендации:
- внедрить проверку параметров БД;
- добавить pre-deployment тесты;
- обновить runbook.

Конечно, инженеру остаётся проверить итоговый документ. Но экономия времени становится колоссальной.

Корпоративная документация наконец начинает работать

Практически в каждой компании существует огромный объём документации:

  • инструкции;

  • runbook;

  • архитектурные схемы;

  • внутренние стандарты;

  • описания сервисов;

  • требования безопасности.

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

MCP позволяет подключать внутренние базы знаний и использовать их как источник контекста.

Например, инженер спрашивает:

Какой порядок восстановления PostgreSQL согласно внутреннему регламенту?

Вместо поиска по Confluence модель получает доступ к документации и отвечает:

Согласно процедуре DB-017 необходимо:

  1. Проверить репликацию.

  2. Выполнить переключение на резервный узел.

  3. Убедиться в актуальности WAL.

  4. Обновить статус инцидента.

  5. Подготовить отчёт о восстановлении.

Фактически появляется единый интерфейс доступа к знаниям компании.

Самый страшный вопрос: можно ли дать ИИ доступ к продакшену?

И вот здесь у большинства инженеров возникает вполне здоровая паранойя.

Представьте следующий диалог:

Освободи ресурсы в Kubernetes.

Если у агента есть полный доступ, последствия могут быть весьма впечатляющими:

kubectl delete namespace production

Технически проблема действительно будет решена. Просто вместе с сервисами.

Поэтому безопасность становится фундаментальной частью архитектуры MCP.

Модель безопасного внедрения

Хорошей практикой считается разделение полномочий на несколько уровней.

Первый уровень - только чтение

Наиболее безопасный режим.

Разрешается:

  • просмотр логов;

  • чтение метрик;

  • анализ событий Kubernetes;

  • поиск по документации;

  • получение информации из GitLab;

  • формирование отчётов.

Например:

kubectl get pods -A
kubectl top nodes
kubectl logs deployment/payment-api

Никаких изменений инфраструктуры не происходит.

Второй уровень - подготовка изменений

Модель может создавать артефакты, но не применять их.

Например:

  • генерировать Terraform;

  • создавать Helm Chart;

  • готовить Ansible Playbook;

  • формировать Merge Request.

Инженер получает черновик:

Подготовлен Pull Request для увеличения лимитов памяти. Требуется проверка.

Третий уровень - выполнение с подтверждением

Это наиболее зрелая модель эксплуатации.

ИИ предлагает действие:

Подготовлено выполнение:

kubectl rollout undo deployment/payment-api \
  -n production

После чего ожидает решения инженера:

Подтвердить выполнение?

[Y/N]

Только после согласия запускается автоматизация.

Именно такой подход позволяет использовать преимущества MCP, не превращая ИИ в бесконтрольного администратора.

Как будет выглядеть дежурство через несколько лет

Представим вполне реальную ситуацию.

В 02:13 ночи приходит алерт.

Сегодня инженер обычно выполняет длинную последовательность действий:

  • открывает Grafana;

  • проверяет Prometheus;

  • смотрит логи;

  • ищет последние коммиты;

  • читает события Kubernetes;

  • консультируется с документацией;

  • оформляет отчёт.

Завтра сценарий может выглядеть иначе.

Почему деградировал сервис оплаты?

Ответ MCP:

Причина - изменение параметров PostgreSQL. Ошибки начались через три минуты после выкладки версии 1.14. Подготовлен откат Deployment и сформирован черновик Postmortem. Выполнить откат?

В этот момент роль инженера меняется. Он перестаёт быть оператором терминала и становится человеком, принимающим решения.

Изменит ли MCP DevOps сильнее Kubernetes?

Это звучит как громкий заголовок, но в нём есть рациональное зерно.

Kubernetes изменил способ запуска приложений.

Terraform изменил подход к управлению инфраструктурой.

GitOps изменил процессы доставки изменений.

MCP способен изменить сам способ взаимодействия инженеров с инструментами.

Мы десятилетиями адаптировались под интерфейсы систем. Изучали синтаксис PromQL, запоминали команды kubectl, переключались между десятками вкладок и собирали информацию вручную.

MCP предлагает противоположную идею.

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

Инженер формулирует намерение:

Найди причину инцидента.

Подготовь инфраструктуру для нового сервиса.

Собери отчёт по сбою.

Проверь соответствие конфигурации корпоративным стандартам.

А рутинную работу выполняет система.

Конечно, это не означает исчезновение DevOps-инженеров. Наоборот. Чем сложнее становятся системы, тем важнее архитектурное мышление, понимание последствий и способность принимать решения в условиях неопределённости.

ИИ не заменит инженера.

Но инженер, использующий MCP, вполне может заменить инженера, который продолжает выполнять всю рутину вручную.

Заключение

Когда-то Bash казался вершиной автоматизации. Затем появились системы управления конфигурациями, контейнеры и Kubernetes. Каждый этап вызывал скепсис, а затем становился новой нормой.

Сегодня MCP находится примерно в той же точке развития, в которой Kubernetes был десять лет назад. Кто-то считает его очередной модной аббревиатурой. Кто-то уже строит на его основе новые процессы эксплуатации.

Станет ли MCP следующим Kubernetes? Ответ мы узнаем через несколько лет.

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

И главное здесь - не забывать держать кнопку подтверждения поближе. На всякий случай.