Привет! Я Сергей Житинский, основатель Git in Sky. Мы занимаемся эксплуатацией ИТ-инфраструктуры и разрабатываем открытую методологию Agent-Ops. О ней я уже рассказывал на Хабре.

19 октября я был на митапе OPS Talk by Sber. На стенде PSLC поговорил с Александром Шаповаловым, который представился архитектором методологии. После встречи захотелось прочитать материалы подробнее и разобраться, как подход Сбера соотносится с нашей работой.

В AI-Disrupt PSLC много знакомого: агенты, контроль решений, сохранение опыта. Но выбирать между PSLC и Agent-Ops, на мой взгляд, незачем. Они описывают работу с разным масштабом: сопровождение продукта в целом и конкретную задачу на инфраструктуре. Покажу это на примере и расскажу, что сравнение подсказало для развития Agent-Ops.

Что описывает каждая методология

PSLC — Product Service Lifecycle, жизненный цикл сервиса продукта. Нужно и восстановить сервис сейчас, и изменить продукт, знания или процедуры, чтобы проблема не повторялась. В PSLC этому соответствуют две петли: исполнение сервиса и работа над надёжностью и доверием.

В Agent-Ops мы подробнее разбираем отдельный случай. Чего хотим добиться? Какие факты собрали? Кто вправе разрешить изменение? Что делать, если команда ушла, а ответ потерялся? Как убедиться, что помогли сервису?

Этот путь состоит из восьми шагов: намерение, доказательства, диагностика, план, утверждение, контролируемое изменение, проверка и извлечение уроков.

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

Представим один инцидент

Представим: после релиза интернет-магазина вырос объём журналов. На диске базы данных заканчивается место, оформление заказов замедляется.

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

Внутри этой работы появляется задача на инфраструктуре. Можно ли расширить том? Допустимо ли удалять старые журналы? Какие данные необходимо сохранить? Здесь пригодятся правила Agent-Ops.

Фиксируем цель: вернуть запас места и нормальную обработку заказов, сохранив данные. Собираем наблюдения, время и источники. Агент проверяет гипотезу о росте журналов и готовит план. Если срок хранения неизвестен, запрашивает его у владельца. Убедительный ответ модели не заменяет этого решения.

Инженер оценивает план, уполномоченный человек его утверждает. Отдельная программа проверяет разрешение и условия, затем выполняет согласованное изменение. В текущей редакции Agent-Ops этого исполнителя запускает человек. После работы проверяем и свободное место, и обработку заказов.

Если ответ на запрос расширения тома не получен, перед повторной попыткой проверяем, выполнилась ли операция. Объект пересоздали — прежнее разрешение на него не переносится. Часть этих связей Agent-Ops уже позволяет проверять программно.

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

Общие принципы и разные границы

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

PSLC подробнее описывает команды, знания, платформу и связь с разработкой. Agent-Ops — происхождение фактов, основания решения и условия выполнения изменения. Области пересекаются: в PSLC тоже есть требования к контролю действий.

Есть и важная граница совместимости. PSLC предусматривает автономное исполнение допущенных сценариев. Agent-Ops v0.5.1 требует человеческого решения и отдельного запуска исполнителя человеком для каждого реального изменения. Использование PSLC рядом с Agent-Ops не отменяет этого требования.

Схемы и офлайн-проверки Agent-Ops ещё не означают готовность исполнителя для production. Ограниченный профиль изменений относится к изолированной тестовой среде; промышленную реализацию предстоит испытать.

Agent-Ops также использует идеи AI-Disrupt PDLC, работы Сбера о разработке. Эти заимствования указаны в методологии.

Какие ресурсы нужны команде

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

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

В небольшой компании несколько человек могут одновременно писать код, обслуживать серверы и разбирать инциденты. Тогда вопрос другой: кто настроит новую платформу, обновит инструкции и проверит рекомендации агента? Если всё это добавится к прежним обязанностям, автоматизация может увеличить нагрузку.

Есть и третий вариант — команда с постоянным подрядчиком. Часть инструментов, редкую экспертизу и подмену специалиста можно получать извне. Но нужно заранее договориться, кто принимает решения, какими доступами пользуется подрядчик и как передаёт знания. Временная проектная команда тоже должна оставить после себя возможность сопровождать результат.

Agent-Ops мы хотим сделать удобным прежде всего для небольших команд. Это не мешает крупной компании применять его правила, а небольшой — использовать PSLC при наличии нужных ресурсов.