Код

Код — это место, где вы просите Status200 AI поработать в ваших репозиториях, как попросили бы агента для программирования: исправить ошибку, написать тесты, объяснить код, внести изменение. Он открывается на поле, где вы пишете просьбу, с выбранными в нём репозиторием и веткой и всеми задачами под ним; страница задачи — это разговор, в котором можно ответить. Status200 запускает задачи и сам, из исключений, трассировок и расследований. Runner клонирует репозиторий, пишет изменение в новой ветке, собирает и тестирует его и открывает pull request. Каждый из них проверяет и сливает человек: Runner может отправлять ветки и открывать pull request, и ничего больше.

Попросить ИИ в репозитории#

1. Откройте раздел «Код»#

   Откройте Продукты → Код. Раздел открывается вопросом Что должен сделать ИИ? над полем, где вы пишете просьбу; под ним — все задачи, сначала новые. Пока репозиториев нет, вместо этого он предлагает Подключить GitHub (см. Перед началом). Репозитории в боковом меню перечисляет репозитории, в которых может работать ИИ, а те, до которых GitHub App больше не дотягивается, сворачивает под Не подключено. На странице каждого репозитория есть такое же поле для этого репозитория.

2. Выберите репозиторий и ветку#

   Поле открывается на репозитории, который вы выбрали последним. Выберите другой в его нижней строке, а рядом — ветку, от которой начнётся задача: основную ветку репозитория с пометкой По умолчанию, пока вы не выберете другую. ИИ создаёт свою ветку от выбранной и открывает в неё свой pull request.

3. Скажите, что нужно#

   Опишите своими словами изменение, ошибку или вопрос. Пока ничего не попросили, «Код» предлагает несколько в разделе Попробуйте попросить.

4. Добавьте контекст#

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

5. Запустите задачу#

   Нажмите Запустить задачу или клавишу Enter. Откроется страница задачи, и работа ИИ будет появляться там по ходу дела.

Просьба несёт не больше 10 элементов контекста. Токены, ключи, пароли и адреса электронной почты в том, что читает Status200, скрываются до того, как их увидит ИИ, как и везде, где Status200 AI читает ваши данные.

Разговор задачи#

Страница задачи — это разговор: что попросили и какой контекст добавили, затем ход ИИ — шаги, которые он делает, по мере того как он их делает (файлы, которые он прочитал и изменил, что он искал, какие команды выполнил), его ответ, файлы, которые он изменил, с их diff, и pull request. Вверху страницы видно, где работает задача (её репозиторий и ветка, от которой она начата), сколько строк она изменила, с кнопкой её pull request, и в каком состоянии задача:

Чтобы продолжить, напишите в поле внизу, которое остаётся на виду, пока разговор прокручивается: ответьте ИИ, добавьте контекст или попросите изменений. Каждый ответ — следующий ход той же задачи: он работает в той же ветке и отправляет изменения в тот же pull request, пока тот открыт. Задача делает один ход за раз, поэтому поле ждёт, пока ИИ работает. Журнал каждого хода — дословная запись того, что в нём было сделано.

Кто может читать репозиторий, читает и его задачи. Чтобы попросить ИИ, ответить или остановить задачу, нужно право изменять репозиторий, и чтобы увидеть diff изменения — тоже: остальные видят, какие файлы изменились. Задачи, которые Status200 запускает сам (ниже), тоже находятся в своём репозитории, как разговоры, в которых можно ответить.

Как проходит запуск исправления#

1. Вы нажимаете Запустить задачу в разделе «Код» или Исправить с ИИ в нерешённом исключении, или задачу запускает другая кнопка или триггер (см. Где начинаются задачи исправления).
2. Задача ставится в очередь своего репозитория, и её берёт Runner, которого выбирает репозиторий: один из ваших Runner-ов или глобальный Runner, если репозиторий не выбрал ни одного (см. Выбор Runner для репозитория).
3. Runner получает контекст задачи. Для просьбы это её слова, добавленный контекст и разговор до этого момента; для исключения — его тип, сообщение и трассировка стека.
4. Он клонирует репозиторий в собственное рабочее пространство и создаёт ветку. Исправление исключения называется oneuptime-fix-exception-, за которым идут первые символы id запуска. Просьба начинается от ветки, выбранной при её отправке, и её pull request открывается в эту ветку. Ответ вместо этого работает в ветке открытого pull request задачи.
5. Агент кода, работающий на провайдере LLM вашего проекта, читает код и пишет изменение. Вызовы LLM делает сервер Status200, поэтому у Runner никогда нет API-ключа вашего провайдера, а каждый вызов учитывается и попадает в журналы ИИ. Исправление исключения, медленной трассировки или инцидента по ходу работы читает и продакшен: исключения, трассировки, журналы и метрики сервисов репозитория (см. Телеметрия продакшена в исправлении).
6. На собственном Runner агент кода собирает и тестирует своё изменение так, как сказано в AGENTS.md репозитория, до любого коммита и исправляет то, что не проходит (см. Проверка перед pull request).
7. Runner делает коммит, отправляет ветку, открывает pull request (для просьбы — только если изменён код) и удаляет рабочее пространство.

Страница, с которой запустили задачу, показывает её статус в реальном времени. Каждая задача перечислена в своём репозитории в Продукты → Код: её страница — это её разговор, а в Журнал каждого хода записана строка на каждый файл, который Runner прочитал или записал, и на каждую выполненную им команду.

Каждый запуск ограничен бюджетами, которые соблюдает сервер: не более 40 вызовов LLM и 100 000 выходных токенов. Запросы запуска к телеметрии продакшена учитываются в тех же 40 вызовах. Запуск, достигший одного из них, завершается сводкой проделанной работы, а не ходит по кругу. Запуски исправлений также учитываются в дневных лимитах ИИ проекта, если проект их задаёт.

Где начинаются задачи исправления#

Эти кнопки появляются только там, где они могут запустить задачу. Если ИИ для проекта выключен, не показывается ни одна из них, а в боковом меню исключения нет AI Assistance. Улучшить журналирование и Улучшить трассировку появляются, как только подключён репозиторий, а Ускорить с помощью ИИ — только у трассировки, которую стоит исправить (см. Обозреватель трассировок). Кнопка Исправить с ИИ у функции появляется только для собственного кода приложения, который занимает не меньше 5 % времени или памяти профиля либо чья доля выросла на 3 п. п. или больше по сравнению с окном, с которым его сравнивают (см. Непрерывное профилирование).

Чтобы открыть страницу AI Assistance исключения, откройте исключение в Продукты → Наблюдаемость → Исключения и выберите AI Assistance в его боковом меню. Решённое или архивированное исключение сначала нужно пометить как нерешённое.

Status200 AI также запускает задачи исправления сам: из расследования, которое находит изменение в коде, из расследования, завершившегося без вывода из-за нехватки телеметрии, и из AI Insights об исключениях и медленных трассировках. У каждого источника свой переключатель; см. Автоматические исправления кода.

Телеметрия продакшена в исправлении#

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

В описании pull request сказано, что запрашивал агент и что это показало. Другие задачи, например регрессионные тесты и улучшения журналирования или трассировки, продакшен не запрашивают.

Что агент может читать, решает сервер Status200, исходя из самой задачи:

• Только чтение. Запросы выполняются на сервере Status200, никогда на Runner, у которого нет учётных данных для чтения телеметрии. Ничто из того, что они делают, не может изменить ваш проект.
• Этот проект и только сервисы, к которым относится этот репозиторий. Сопоставлять их вам не нужно: это сервисы, для которых Status200 находит этот репозиторий, так же как он находит репозиторий исправления, — трассировки стека их исключений проходят через его файлы, они названы так же, как он, или это единственный репозиторий проекта. Телеметрию другого сервиса прочитать нельзя.
• Никаких приватных инцидентов, а токены, ключи, пароли и адреса электронной почты скрываются до того, как агент увидит результат, как и везде, где Status200 AI читает ваши данные.
• Ограничено. Не более 12 запросов за запуск, и каждый учитывается в 40 вызовах запуска.

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

Проверка pull request по продакшену#

Status200 знает, что ваш код делает в продакшене, поэтому может проверить pull request с тем, чего не видно при чтении диффа. Включите Проверять запросы на слияние по данным продакшена на странице Настройки репозитория в разделе «Код», в блоке Дополнительные настройки, и каждый pull request, который открывает или обновляет человек с правом записи, получит один комментарий о том, что продакшен показывает о меняемом коде. Комментарий обновляется на месте при каждом push, а страница Проверки по продакшену репозитория в разделе «Код» хранит каждую проверку, с кнопкой Проверить снова.

Когда продакшен что-то показывает, Status200 AI читает это рядом с диффом и добавляет На что обратить внимание: несколько коротких пунктов, каждый из которых опирается на факты. Это работает, только пока ИИ включён для проекта, не чаще 10 раз в день для одного pull request и 100 раз для репозитория, и учитывается как любой вызов ИИ; факты читаются каждый раз и без него. Если продакшен ничего не показывает об изменении, Status200 ничего не публикует.

• Только агрегаты. Комментарий содержит количества, длительности и имена кода: никогда не сообщение исключения, строку журнала, название инцидента или персональные данные.
• Публичные репозитории получают ссылку. Pull request публичного репозитория может прочитать кто угодно, поэтому там комментарий только ссылается на проверку в Status200, которую могут открыть лишь участники проекта. Комментарий проверки по продакшену в разделе Дополнительные настройки на странице Настройки репозитория может публиковать Только ссылка на проверку везде или Проверка, даже в публичном репозитории.
• Внешние участники не могут её запустить. Pull request проверяется сам, только когда его автор и тот, кто отправил в него изменения, могут писать в репозиторий. Pull request любого другого человека - внешнего участника, из форка, от бота - проверяется, когда человек с правом записи пишет в нём комментарий @oneuptime production review или нажимает Проверить снова в разделе «Код».
• Только чтение. Проверка ничего не клонирует и ничего не запускает из pull request. Его дифф и заголовок — это данные для Status200 AI, а не инструкции: у ИИ нет инструментов, а то, что он пишет, вставляется в комментарий как текст.

Переключатель включён для репозиториев, которые GitHub App подключает с этого момента. Репозиторий, подключённый до его появления, оставляет его выключенным, пока вы его не включите.

Проверка перед pull request#

Репозиторий описывает, как его собирать и тестировать, в AGENTS.md в своём корне — файле, который читают агенты для написания кода. Прежде чем что-либо менять, агент кода читает AGENTS.md репозитория (или его CLAUDE.md, если AGENTS.md нет) из ветки, с которой начинается задача, и работает так, как там сказано. Если нет ни того, ни другого, он узнаёт это из CONTRIBUTING.md репозитория, README, скриптов пакета, Makefile или CI-воркфлоу. В Status200 ничего настраивать не нужно.

Ничто из pull request, пришедшего из форка, никогда не читается как инструкции репозитория: доработка отклоняет такой pull request, а ревью читает базовую ветку.

Команды, заданные в репозитории#

Раздел «Код» больше не спрашивает команды установки, сборки и тестов, но репозиторий, у которого они есть, заданные раньше или через API или Terraform, сохраняет их. Они показаны только для чтения на карточке Команды сборки и тестов в разделе Дополнительные настройки на странице Настройки репозитория, а Удалить команды удаляет все три. Пока задана хотя бы одна из них, каждый запуск исправления на собственном Runner также проверяет ими своё изменение до открытия pull request:

1. Когда агент кода заканчивает, команды выполняются по порядку в корне репозитория, на Runner, в клонированном рабочем пространстве. Каждой даётся до 15 минут, и она выполняется с CI=true, чтобы ничто не ждало ввода; первый сбой останавливает проход.
2. При сбое конец вывода упавшей команды возвращается тому же агенту кода как задача на починку, с указанием исправить собственное изменение, а не ослаблять или пропускать тесты, и команды выполняются снова. Он делает не более 2 попыток починки. Они делят бюджет LLM запуска, а их правки попадают в тот же коммит, что и исправление.
3. Итог — пройдено, не пройдено или пропущено (команды не заданы или глобальный Runner) — записывается в раздел Verification описания pull request и сохраняется в pull request задачи.

Изменение, которое так и не прошло проверку, не выбрасывается: pull request всё равно открывается, с хорошо заметным разделом "Verification failed", который называет упавшую команду и заканчивается её выводом. Работа сохраняется, а решает проверяющий. Репозиторий без заданных команд отмечается как пропущенный, а не делает вид, что сборка зелёная.

Команды — это настройки репозитория, которые пишет ваша команда, и выполняются они на вашем собственном Runner: та же модель доверия, что и у шагов Bash в runbook. ИИ никогда их не пишет и не меняет. Глобальный Runner, который Status200 запускает для всех проектов, никогда их не выполняет: на глобальном Runner исправление пишется и открывается на ревью, проверка отмечается как пропущенная, а собственный CI вашего репозитория проверяет изменение. Запустите собственный Runner, чтобы исправления собирались и тестировались до открытия pull request.

После слияния исправления#

Слияние исправления ничего не исправляет, пока оно не запущено. Как только запрос на слияние с исправлением слит, Status200 ждёт записанного развёртывания, которое его содержит (см. Развёртывания и изменения), и следит в этом развёртывании за тем, для чего было исправление. Запрос на слияние задачи в Code показывает, чем всё закончилось, как и страница AI Assistance исключения, журналы ИИ инцидента и инсайт ИИ, из которого пришло исправление:

Пока развёртывание его не доставит, у исправления указано Слито, ожидается деплой, затем Развёрнуто, наблюдение в продакшене, пока за ним следят. Исправление, которого ни одно записанное развёртывание не содержит в течение 14 дней или о котором продакшен ничего не может сказать, получает Не проверено в продакшене. Автоматические исправления кода описывает правила. Регрессионный тест, улучшенная обработка ошибок, ревью и запрос в Code не отслеживаются: продакшен не может показать, что они меняют.

Прежде чем начать#

Задаче нужны три вещи. Поле просьбы в разделе «Код» и страница AI Assistance исключения проверяют все три, прежде чем предложить запуск, и сообщают, чего не хватает.

На собственном экземпляре глобальный провайдер — это один блок в config.env (Docker Compose) или в ваших значениях Helm. Для собственного Ollama:

GLOBAL_LLM_PROVIDER_TYPE=Ollama
# An address the Status200 server can reach, never localhost.
GLOBAL_LLM_PROVIDER_BASE_URL=http://ollama:11434
GLOBAL_LLM_PROVIDER_MODEL_NAME=llama3.1
# No GLOBAL_LLM_PROVIDER_API_KEY needed — Ollama is keyless.

Подходит любой поддерживаемый провайдер: см. Провайдеры LLM, где описаны все провайдеры и каждая переменная окружения.

Вы не сопоставляете репозитории с сервисами. Когда задача запускается, Status200 находит репозиторий, сравнивая пути файлов из трассировки стека исключения с вашими подключёнными репозиториями. Если ничего не совпадает, он берёт репозиторий с тем же именем, что и сервис, а затем единственный репозиторий проекта, если он один. Страница AI Assistance показывает, какой репозиторий найден.

Выбор Runner для репозитория#

Каждый репозиторий выбирает Runner, на котором в нём работает ИИ: на его странице Настройки в разделе «Код» откройте Дополнительные настройки, нажмите Редактировать на карточке Runner и выберите Runner. Репозиторий, который импортирует GitHub App, начинает на Runner по умолчанию проекта, если он у проекта есть. Репозиторий, который не выбрал ни одного, работает на Глобальный Runner, который Status200 запускает для всех проектов.

Задачи репозитория и токен для него получает только тот Runner, которого он выбрал. В проекте, где Использовать глобальные Runner-ы выключено в Сборники инструкций → Агенты runbook-ов, каждому репозиторию нужен один из Runner-ов самого проекта. На странице Runner перечислены репозитории, которые его выбрали.

Запуск собственного Runner#

Чтобы запустить Runner в другом месте, например на машине рядом с вашими репозиториями:

1. Создайте Runner#

   Создайте Runner в Сборники инструкций → Агенты runbook-ов и нажмите Показать инструкции по настройке в его строке. Команда содержит секретный ключ Runner, который может прочитать только Project Owner, Project Admin или Runbook Admin. Она выглядит так:

   Bash

   docker run --name status200-runner --restart unless-stopped \
     -e STATUS200_RUNNER_ID=<runner-id> \
     -e STATUS200_RUNNER_KEY=<runner-key> \
     -e STATUS200_URL=<your-status200-url> \
     -d status200/runner:release

2. Выберите его для репозитория#

   На странице Настройки репозитория в разделе «Код» откройте Дополнительные настройки, нажмите Редактировать на карточке Runner и выберите Runner. Runner подхватывает изменение со следующим heartbeat, примерно в течение минуты; ничего перезапускать не нужно.

3. Проверьте подключение#

   Runner появляется как подключённый на странице Сборники инструкций → Агенты runbook-ов в течение минуты-двух. Если нет, посмотрите лог контейнера (docker logs status200-runner) на предмет ошибки учётных данных или сети.

Подходит любой способ запуска контейнера (Docker Compose, Kubernetes и так далее), если у него есть эти переменные и он может достучаться до вашего экземпляра Status200 по HTTPS:

Автоматические исправления кода по расследованиям#

Когда ИИ-расследование публикует анализ первопричины в инциденте или оповещении, и его тщательная классификация рекомендует изменение в коде, карточка расследования предлагает Open Fix PR from this analysis: задачу исправления, весь контекст которой — опубликованный анализ. Кнопка скрыта, когда решение операционное, касается только инфраструктуры, внешнее, является ожидаемым отказом, ошибкой пользователя или не дало вывода. Подходящие исправления происходят без клика, пока включено Автоматически исправлять новые инциденты на Инциденты → ИИ → Настройки (и Автоматически исправлять новые оповещения на Оповещения → ИИ → Настройки). Исправление изначально выключено, в том числе в новых проектах. Без правил ИИ открывается каждое подходящее исправление; с правилами — только для того, что подходит под правило, когда у правила включено Pull request с исправлениями (у нового правила оно включено), в репозиториях кода, которые оно указывает.

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

Всё остальное совпадает с кнопкой:

• Pull request открывается готовым к проверке, написанным по опубликованному анализу, и требует репозитория, подключённого через GitHub App, — одного из указанных в подходящих правилах, если они их указывают, — и Runner в сети, чтобы в нём работать: того, которого выбрал репозиторий, или глобального Runner.
• Он учитывается в дневном лимите задач исправления этого сигнала (Daily Incident AI Fix Task Limit или Daily Alert AI Fix Task Limit, в Дополнительные настройки на его странице настроек ИИ) и в ограничении репозитория на открытые pull request, если что-то из этого задано. Если не задано, ничто ничего не ограничивает.
• Каждый триггер сначала ищет задачу исправления, уже стоящую в очереди или выполняющуюся для того же инцидента или оповещения, так что автоматический триггер и клик обычно дают одну задачу, а не два pull request. Проверка — это чтение перед записью, а не блокировка, поэтому два триггера в один и тот же момент всё же могут пройти оба.
• Запуск создаётся системой, никому не приписывается, и ничего не сливается само.

Когда исправление не удаётся#

Конфиденциальность#

Клон вашего репозитория находится в рабочем пространстве внутри контейнера Runner и удаляется, когда запуск заканчивается, успешно или нет. У Runner никогда нет API-ключа вашего провайдера LLM: вызовы LLM за него делает сервер Status200, и он же выполняет запросы к телеметрии продакшена. Status200 не хранит ваш репозиторий и не обучается на вашем коде. Журнал задачи хранит первые 300 символов вывода каждого шага, чтобы вы могли проверить, что сделал Runner, и туда могут попасть фрагменты кода. Запустите собственный Runner со своим провайдером LLM (включая локальный Ollama), и ваш код никогда не покинет вашу инфраструктуру.

В планах#

Запланировано и пока недоступно:

• Поддержка GitLab. Репозитории подключаются только через GitHub App.

Дальнейшие шаги#