Раздел эксплуатации отвечает на вопрос «почему не работает» до того, как что-то упало: кто выполняет сборки, что стоит в очереди, где кончаются лимиты, что проверяет здоровье системы и что переезжает при переносе данных на другой сервер.
Здесь нет ни Kubernetes, ни арендованных мощностей: всё живёт на вашем сервере и в ваших браузерах, и раздел честно это показывает.
Исполнители
Исполнители — это те, кто выполняет прогоны. Видов два: встроенный — безоконный браузер в контейнере на сервере, — и Chrome с дополнением на вашем компьютере. Арендованного пула мощностей нет: собственный запас и есть сам продукт. В таблице видно имя, проект, состояние, время последней связи и версию, а рядом — честное предупреждение, если версия отстала от самой новой среди исполнителей того же вида. У встроенного рядом с именем стоит пометка «встроенный»: версии разных видов между собой не сравниваются, потому что браузеры у них разные.
Пустой список в простое — это норма, а не поломка: встроенный исполнитель не держит себя в памяти, пока работы нет, и появляется снова, когда в очередь попадает прогон. Отдельная строка «Встроенный исполнитель» есть в Настройках → Тестирование UI: доступен ли он и когда последний раз выходил на связь. Она не путается с надписью «Дополнение подключено» — та относится только к Chrome.
Состояния «онлайн», «деградация» и «офлайн» не хранятся в базе, а выводятся из давности последней связи. Поэтому они не «залипают»: как только исполнитель перестаёт выходить на связь, статус честно меняется сам.
Любого исполнителя — и встроенного, и Chrome — можно осушить: например, перед обновлением системы. Он перестаёт забирать новые прогоны и спокойно заканчивает текущий. Настройки в браузере при этом сохраняются, поэтому «Возобновить» в любой момент вернёт его в работу: осушить — это рычаг, а не ловушка.
Очередь
Здесь видно всё, что ждёт: раунды ИИ, кампании починки тестов, обходы сайта и доставки уведомлений. У каждой строки — состояние, сколько она уже ждёт и примерное время до конца по последним десяти завершениям такой же работы.
Если очередь пуста, так и написано. Отменить ожидающее можно через те же действия, что и на своих экранах, — с обязательной причиной. Этот экран ничего не перезапускает: он только показывает, что ждёт. Повторы ничего не стоят и в очередь не попадают.
Бюджеты
Лимиты показаны лестницей: до 50 %, 50–80 %, 80–100 % и сверх лимита. По каждому проекту видно, сколько снимков хранится против потолка, сколько токенов ИИ потрачено против потолка задачи и сколько минут заняли прогоны за последние семь дней. Если лимит не задан, так и написано — «без лимита».
Важно понимать, зачем это: один убежавший ИИ-прогон может съесть месячную экономию. Лестницы показывают, где стоит проект, до того как это случится. Бюджеты предупреждают и блокируют новые ИИ-запуски, но никогда ничего не выставляют к оплате — счетов здесь нет вовсе.
Проверки здоровья
Шесть общих проверок отвечают за весь сервер:
- соединение с агентом;
- тестовый исполнитель;
- база данных;
- файловое хранилище;
- публичный адрес;
- квоты и бюджеты.
И четыре проверки по проекту: визуальная конфигурация, файлы тестов, среда по умолчанию и доставка уведомлений. У каждой — понятная причина, сухие факты без секретов, подсказка «что исправить» и кнопка перехода туда, где это исправляется.
Проверка исполнителя ведёт себя по-разному. Обычно она судит по времени последней связи: свежая — хорошо, давняя — повод разобраться. Но если встроенный исполнитель работает по требованию, в простое связи и нет: проверка честно считает его доступным, а не работающим, и пустой список исполнителей для неё зелёный, а не поломка. Красной проверка становится в другом случае — когда запуск исполнителя сорвался; тогда в подробностях видна и сама ошибка.
Проверки выполняются, только пока на них смотрят: открыт экран диагностики — продукт опрашивает базу, хранилище и адреса, закрыли — опрос прекращается. Первый же вернувшийся читатель получает свежую картину. Так и задумано: сервер, за которым никто не следит, не должен заниматься проверками сам с собой.
Жёлтую проверку можно на время погасить, указав причину и срок: она вернётся сама и снова напомнит о себе. Красную погасить нельзя — сначала её нужно восстановить. Решение «продолжить без проверки» с причиной попадает в журнал аудита, поэтому им нельзя тихо прикрыть настоящую поломку.
Память в простое
В данных о здоровье системы есть отдельный раздел о памяти: сколько занято самим продуктом (текущий и пиковый рабочий набор), как ведёт себя сборщик мусора и сколько записей лежит во временных хранилищах. Это только показания — снимок ничего не запускает и не чистит, смотреть на него безопасно.
Зачем это нужно: сервер, работающий сутками, имеет свойство накапливать память. Снимок отвечает на вопрос, есть ли что накапливать: ровный рабочий набор и пустые временные хранилища означают, что ничего не утекает. Заодно в простое не тратится и процессор — внутренние циклы продукта просыпаются по событию, а не по таймеру.
И главное: в простое продукт возвращает занятую память сам. Если 15 минут никто ничего не делал — не шли прогоны, не было работы в чате и открытых экранов, — занятая память возвращается системе, а временные хранилища очищаются. Сколько минут считать простоем, задаёт переменная TEST_APP_IDLE_TRIM_MINUTES: значение 0 выключает возврат совсем. Так продукт спокойно живёт на небольшой машине рядом с другими программами.
Ждать пятнадцать минут, чтобы проверить, как это работает, не нужно: у администратора есть отдельное действие — принудительное освобождение памяти. Оно запускает ту же уборку, не дожидаясь простоя, и сразу отвечает, сколько памяти удалось вернуть системе.
Деградация
Когда общие проверки падают, продукт не делает вид, что всё в порядке: на каждой странице появляется плашка с названием упавшей проверки и ссылкой туда, где её исправлять. При этом отключаются только массовые действия, которые меняют смысл, — например «принять все безопасные» и запуск кампаний починки.
Одиночные вердикты, чтение, комментарии и запуски сборок продолжают работать. Так сделано намеренно: деградация должна мешать поспешным массовым решениям, а не останавливать работу. Решения, принятые в этом режиме, помечаются в журнале аудита.
Перенос данных
Перенос помогает переехать на другой сервер или поднять копию для проверки. Выгрузка и загрузка переносят визуальную конфигурацию, среды, переменные, покрытие, карту приложения и подписи эталонов с данными версий. Картинки эталонов едут только по отдельному запросу и с пределом в 200 МБ.
Никогда не переносятся учётные данные — они живут только в хранилище сервера, — а также токены публикаций и история прогонов. Тесты, действия и правила — это файлы: их переносят вместе с папкой проекта, потому что она под контролем версий.
Загрузка безопасна к повторам: тот же документ второй раз ответит «всё пропущено», ничего не задвоится. Перед применением есть пробный прогон, который сначала показывает точный отчёт — что создастся, что обновится и что пропустится. Сам перенос тоже записывается в журнал аудита.
Дальше: как устроены версии тестов и страницы шагов — в разделе Версии тестов и шаги.