Кейсы

Блог

О компании

Контакты

Решения

Калькулятор: инженер или поддержка?

новое

Быстрее находим причины проблем в инфраструктуре и готовим проверенные инженерные решения

Детерминированные инструменты собирают факты и сравнивают реальное состояние с IaC и политиками. AI помогает анализировать изменения, логи и зависимости. Инженеры Git in Sky проверяют решения, согласуют изменения и отвечают за результат.

Пройти readness assessment

Обсудить пилот AI-SRE

Меньше времени до решения

AI-SRE не добавляет ещё один слой инструментов. Он сокращает путь от сигнала до проверенной инженерной гипотезы.

Быстрее формируется evidence package

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

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

AI связывает факты и предлагает варианты причин, но не выдаёт предположение за доказанный root cause.
Знания перестают быть только в головах

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

RCA и corrective actions превращаются в новые проверки, правила и runbooks, а не остаются документом в Confluence.
Сохраняется контроль над production

Изменения выполняются только в рамках согласованных доступов и human approval gates. AI не получает неконтролируемых прав.

Когда AI-SRE имеет смысл

Мы не обещаем, что AI-SRE автоматически снизит стоимость любой инфраструктуры. Экономический эффект оценивается по baseline и ограниченному пилоту.

Подходит:

✓ Критичная инфраструктура 24×7
✓ Высокая стоимость простоя
✓ Несколько облаков, кластеров или сред
✓ Разрозненные источники мониторинга и логов
✓ Длительный RCA
✓ Дефицит senior SRE
✓ Слабая документация
✓ Повторяющиеся инциденты
✓ Расхождение IaC с реальным состоянием
Может не окупиться:

— Небольшая статичная инфраструктура
— Редкие изменения
— Низкая стоимость простоя
— Отсутствие базовой observability
— Отсутствие владельцев процессов
— Невозможность предоставить технический контекст

Как работает AI-SRE

Девять этапов — от сбора фактов до обновления runbooks. Каждый этап проверяем и контролируем.

Сбор фактов

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

Данные из разных систем приводятся к единой структуре: временные метки выравниваются, форматы унифицируются, источники маркируются
Сравнение с declared state

Реальное состояние сравнивается с IaC, архитектурными решениями, политиками безопасности и baseline. Расхождения — это факты, а не интерпретации.
Формирование evidence package

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

AI анализирует evidence package: ищет связи между фактами, аномалии, известные паттерны. Формирует и ранжирует гипотезы с привязкой к evidence. Гипотеза — это не вывод, а версия для проверки.
Проверка инженером

Инженер Git in Sky проверяет гипотезы: подтверждает, отклоняет, запрашивает дополнительные данные. Итоговое решение — всегда за человеком.
Согласование изменения

Изменение проходит согласование в рамках agreed-upon approval process. Границы доступа определены заранее, действия логируются.
Согласование изменения

Изменение проходит согласование в рамках agreed-upon approval process. Границы доступа определены заранее, действия логируются.
Обновление harness и runbooks

Результаты инцидента превращаются в новые проверки, правила, runbooks и ограничения. Контекст инфраструктуры обновляется — следующий инцидент будет диагностироваться быстрее.

Сервисы для построения инфраструктуры в облаке

Миграция на одну из трех облачных платформ Cloud.ru: Evolution, Advanced или Облако VMware. Каждая платформа предлагает широкий выбор вычислительных мощностей, управляемых сервисов и инструментов для миграции. Можно использовать ресурсы одной платформы или объединить их по внутренней сети облака.

Evolution Compute

Виртуальные машины для развертывания сервисов
Evolution Managed Kubernetes

Управление контейнерными приложениями в кластере Kubernetes
Evolution Load Balancer

Сервис для балансировки сетевого трафика
Direct Connect

Выделенное высокоскоростное физическое подключение между офисом или центром обработки данных и облаком
Cross-Platform Connection

Безопасная и надежная связь ваших ресурсов между платформами Cloud.ru

Этапы работ

Аудит текущей инфраструктуры

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

Разрабатываем целевую архитектуру, планируем этапы миграции и рассчитываем необходимые ресурсы и бюджет
Настройка сетей и резервирование

Настраиваем сети и обеспечиваем резервирование при развертывании отказоустойчивой геораспределенной инфраструктуры
Реализация миграции в облако

Настраиваем облачную инфраструктуру, поэтапно переносим сервисы, подключаем мониторинг и резервное копирование
Передача в эксплуатацию

Проводим тестирование отказоустойчивости, обучаем персонал и передаем полную документацию
Поддержка и сопровождение

Обеспечиваем круглосуточную поддержку, соблюдение SLA и предоставляем рекомендации по развитию

С чего начать

Три уровня — от диагностики готовности до постоянного managed-сопровождения.

Agent-Ops Readiness Assessment

Диагностика готовности инфраструктуры и процессов к AI-assisted эксплуатации.

Инвентаризация инфраструктуры

Аудит IaC

Аудит observability

Оценка документации

Оценка incident management

Карта источников фактов

Оценка рисков доступа

Проект структуры harness

Список приоритетных сценариев

План пилота

Обсудить assessment

AI-SRE Pilot

Ограниченный проект на одном сервисе, кластере или группе серверов с измерением before/after.

Один ограниченный инфраструктурный контур

3–5 источников фактов

Один основной диагностический сценарий

Baseline по текущему процессу

Evidence package

Human approval gates

Измерение before/after

Итоговый отчёт с ограничениями

Обсудить пилот

AI-SRE Managed Service

Постоянное сопровождение инфраструктуры с развитием Agent-Ops harness и инженерной ответственностью

Мониторинг и анализ алертов

Incident management

Диагностика и RCA

Плановые операции

Подготовка изменений

Контролируемая remediation

Работа с техническим долгом

Обновление runbooks

Отчётность

SLA и инженерная эскалация

Обсудить сопровождение

Эффект подтверждается измерениями

Мы не публикуем проценты до появления собственных подтверждённых данных. Показываем, что именно измеряем.

Alert > Evidence
Alert > Первая гипотеза
MTTR
Человеко-минуты на сбор контекста
Доля senior-эскалаций
Повторные инциденты

Демонстрация

До появления клиентского кейса показываем controlled demo. Это не результат клиента — это лабораторная демонстрация подхода.

Описание системы

Kubernetes-кластер, 3 nodepool, PostgreSQL, Redis, Nginx Ingress.
Тип инцидента

Деградация latency на одном из сервисов после планового обновления.
Входные данные

Алерт из Prometheus, логи пода, конфигурация деплоймента, история изменений в Git, метрики latency.
Ручной процесс

Инженер вручную собирает логи, сравнивает конфигурации, ищет изменения — 18 минут до первой гипотезы.
Evidence package

Система собирает факты за 40 секунд: diff конфигураций, график latency, список изменённых ресурсов, владельцы.
Гипотезы AI

Модель предлагает 3 версии — resource limits, сетевая политика, версия библиотеки.
Инженер

Проверяет гипотезы, подтверждает resource limits как root cause. Отклоняет 2 другие.
Результат

40 секунд до evidence package, 4 минуты до подтверждённой гипотезы.
Ограничения

Демонстрация на изолированном кластере. Результат не гарантирует такого же эффекта на инфраструктуре клиента без пилота.

AI-SRE работает на базе открытой методологии Agent-Ops

Принципы, lifecycle, базовые схемы и шаблоны публикуются открыто. Клиентские данные, topology, доступы, thresholds и внутренние runbooks остаются закрытыми.

Перейти к Agent-OPS Framework