Серия Hoplites · Часть 2 из 3: Как мы это используем
В первой части этой серии мы представили Hoplites, наших облачных агентов. В этом посте мы углубимся в рабочие процессы, которые на данный момент показали свою эффективность при работе с Hoplites.
Hoplites меняет целые рабочие процессы в Paxos: от проактивной очистки бэклога, которая раньше откладывалась на потом, до межкомандного взаимодействия между отделами комплаенса, операций и разработки при работе с нашими внутренними инструментами, что помогает нам более эффективно обслуживать наших клиентов.
От забытых тикетов к объединенным изменениям
Инженеры первыми начали использовать Hoplites. Они не перенесли свои основные рабочие нагрузки на Hoplites (хотя запуск Hoplites до появления Claude и Codex Remote привел к тому, что некоторые крупные функции были полностью разработаны через Slack на мобильных устройствах); они взялись за часто создаваемые и забытые задачи. Это некритичные, но полезные для гигиены кода задачи: очистка флагов функций, удаление неиспользуемых конфигураций, обновление владельцев кода (codeowners), небольшой рефакторинг, исправление мелких багов и обновление наших внутренних инструментов.
Время цикла для pull-реквестов: человеческих, с поддержкой ИИ и от Hoplites
Hoplites изменил процесс с «тикет → назначение → запуск локального агента → контроль pull-реквеста» на одно сообщение @Hoplites в Slack — небольшое, но существенное сокращение усилий. Поскольку промпт и агент находятся в Slack, где рецензенты могут проактивно участвовать в обсуждении, инженеры быстро поняли, что время цикла для изменений, предложенных Hoplites, невероятно мало. В результате мы видим, что гораздо больше простых запросов на изменения начинаются и заканчиваются обсуждением с Hoplites, и только сложные запросы оформляются в виде тикетов.
Открытие внутренних инструментов для не-инженеров
Ранее в этом году растущие объемы данных, продуктов и юрисдикций Paxos подтолкнули нас к улучшению наших внутренних инструментов и дашбордов. Эти инструменты обслуживают почти все команды в Paxos, но особенно отделы операций, комплаенса и разработки.
Мы сделали ставку против low-code решений с перетаскиванием элементов: в мире ИИ мы можем получить лучшее из обоих миров — участие не-инженеров в создании внутренних инструментов при сохранении тщательности, проверок и контроля, которые дают прямые правки кода. Именно здесь Hoplites проявил себя наилучшим образом.
Hoplites позволяет указывать выделенные профили агентов (по сути, hoplite с выделенным системным промптом); если профиль не указан, используется стандартный. Для наших внутренних инструментов у нас есть профиль pax-admin со встроенными ключевыми знаниями о репозиториях, бэкенд/фронтенд стеках и распространенных ошибках при внесении правок в pax-admin. Вот пример взаимодействия:
Сотрудник отдела операций исправляет небольшую проблему с помощью hoplite pax-admin
«Мультиплеерный» ИИ между инженерами и непосредственными пользователями внутренних инструментов привел к буму внутренних разработок в Paxos, дав нам более глубокое понимание наших продуктов и лучшие способы обслуживания клиентов. Все это происходит в рамках тех же элементов контроля: pull-реквесты, созданные агентами, имеют те же требования к рецензентам (два человека, как минимум один из них инженер), те же стандарты непрерывной интеграции и безопасности, что и код, написанный инженерами.
Несколько вещей, которые мы узнали в процессе
- Использование выделенного Slack-хендла @pax-admin работает гораздо лучше, чем @Hoplites --agent pax-admin или полагание на недетерминированную агентную маршрутизацию.
Использование выделенного Slack-хендла @pax-admin работает гораздо лучше, чем @Hoplites --agent pax-admin или полагание на недетерминированную агентную маршрутизацию.
- Около 50% диалогов с @pax-admin инициируются не-инженерами; люди, которые ежедневно пользуются внутренним дашбордом, лучше всех знают, что нужно исправить или изменить.
Около 50% диалогов с @pax-admin инициируются не-инженерами; люди, которые ежедневно пользуются внутренним дашбордом, лучше всех знают, что нужно исправить или изменить.
- Владение собственными инструментами позволило нам реализовать богатые интеграции внутри Slack, например, «View Preview Deployment», перенаправляющую на развернутую версию приложения, или функционал «Notify Reviewers» / «Fix All Comments».
Владение собственными инструментами позволило нам реализовать богатые интеграции внутри Slack, например, «View Preview Deployment», перенаправляющую на развернутую версию приложения, или функционал «Notify Reviewers» / «Fix All Comments».
Становясь правой рукой дежурного инженера
Hoplites — это не просто облачный агент для написания кода. Мы дали Hoplites доступ к отличному pup CLI от Datadog и создали выделенного агента @triage — это было потрясающе. Вот он в действии:
Расследование инцидента в процессе выполнения нашим hoplite для триажа
Один паттерн, который мы заметили на раннем этапе: во время инцидентов многие участники одновременно запускали своих собственных агентов. Это имело свою цену: токены — да, но, что более важно, внимание самих участников. Все следили за локальным чатом вместо того, чтобы делать то, что мы ожидаем от людей: исследовать дашборды, проверять логи и действительно думать. Перенос этого контекста в Slack, за единого агента, активируемого тегом @triage, позволил команде сосредоточиться, зная, что агент следит за проблемой.
Ожидание полного анализа первопричин (RCA) от агента может занять некоторое время. Мы создали «Investigation Leads», которые проактивно собирают ключевые мониторы, логи, подозрительные пути в коде и pull-реквесты в режиме реального времени, позволяя участникам кликнуть и связать все воедино до того, как RCA будет завершен. Затем hoplite для триажа выводит готовый RCA в виде Datadog Notebook с полным обоснованием и полезными виджетами:
Ответ от hoplite для триажа после завершения RCA
Задачи по триажу составляют около 30% от всех запущенных агентов Hoplites, и мы встроили весь жизненный цикл реагирования на инциденты в одного агента, дав ему возможность:
- Оценивать серьезность инцидента в соответствии с нашей матрицей серьезности инцидентов
Оценивать серьезность инцидента в соответствии с нашей матрицей серьезности инцидентов
- Создавать документы с ретроспективой инцидента (с выделенной командой «Run Retrospective» после завершения RCA или простым @triage retro please)
Создавать документы с ретроспективой инцидента (с выделенной командой «Run Retrospective» после завершения RCA или простым @triage retro please)
- Автоматически подтягивать полный контекст канала при запуске в Slack-канале #incident-*
Автоматически подтягивать полный контекст канала при запуске в Slack-канале #incident-*
Это стало важнейшим инструментом для наших дежурных инженеров, некоторые команды даже автоматически вызывают @triage при получении любого пейджа. Помимо инженерии, отдел операций активно использует его для понимания и расследования различных проблем перед обращением к инженерам. Результат: меньше ручных усилий при реагировании на инциденты и более быстрое решение проблем для наших клиентов.
Обеспечение безопасности наших систем, данных и агентов
Волна LLM повысила ставки в обеспечении безопасности наших систем и представила новые векторы атак; Hoplites является как новым вектором атаки в Paxos, так и инструментом, который все чаще используется для того, чтобы мы оставались на шаг впереди.
Hoplites выполняет диалоги на удаленных вычислительных мощностях с полной изоляцией сети и файловой системы, предоставляя минимальный набор привилегий, необходимых для конкретных инструментов (например, Github, Datadog). Чтобы защитить нашу среду и обеспечить строгое соблюдение нормативных требований, мы поддерживаем жесткие границы и средства контроля во всех рабочих процессах агентов:
- Строгие проверки и CI-шлюзы: Pull-реквесты, созданные агентами, подчиняются тем же требованиям к рецензированию, непрерывной интеграции и безопасности, что и код, написанный инженерами, без каких-либо исключений.
Строгие проверки и CI-шлюзы: Pull-реквесты, созданные агентами, подчиняются тем же требованиям к рецензированию, непрерывной интеграции и безопасности, что и код, написанный инженерами, без каких-либо исключений.
- Изоляция данных и секретов: Агентам явно запрещен доступ к секретам, данным клиентов и персональной информации (PII), что гарантирует отсутствие прав на чтение или запись конфиденциальной информации.
Изоляция данных и секретов: Агентам явно запрещен доступ к секретам, данным клиентов и персональной информации (PII), что гарантирует отсутствие прав на чтение или запись конфиденциальной информации.
- Полная аудируемость: Каждый диалог, взаимодействие и лог исполнителя сохраняются и доступны для аудита через наш веб-интерфейс, обеспечивая полную прослеживаемость того, кто дал запрос агенту, какой код был изменен и что именно выполнил агент.
Полная аудируемость: Каждый диалог, взаимодействие и лог исполнителя сохраняются и доступны для аудита через наш веб-интерфейс, обеспечивая полную прослеживаемость того, кто дал запрос агенту, какой код был изменен и что именно выполнил агент.
Веб-приложение Hoplites, демонстрирующее полную прозрачность аудиторского следа диалогов
Далее
Каждый из описанных выше рабочих процессов начинается одинаково: сотрудник описывает задачу в Slack, агент Hoplite выполняет работу, а человек проверяет результат перед отправкой. В заключительной части этой серии мы расскажем о том, что изменилось в Paxos: о влиянии на наш бэклог и время цикла, архитектуре «под капотом» и о том, в каком направлении мы развиваем Hoplites дальше.
Если вам интересны подобные задачи, возможно, вам понравится работать с нами: Карьера в Paxos.
