Предстартовая проверка: что доказать до первого рабочего диалога

Установленная система ещё не готова к рабочему потоку. Процесс может отвечать на пробу связи, но не видеть базу; канал — принимать сообщения, но отправлять их не тому агенту; инструмент — иметь слишком широкие права; резервная копия — существовать только в отчёте. Запуск без проверки превращает пользователей в бесплатных тестировщиков.

Предстартовый обзор связывает технические и процессные условия. В AiHummer /healthz подтверждает живой шлюз, а /readyz оценивает настроенный набор зависимостей и может вернуть неготовность. Эти сигналы важны, но не заменяют пользовательский путь. Практический вопрос: какие доказательства нужны владельцу, эксплуатации и безопасности, чтобы открыть ограниченную первую волну?

Зафиксируйте точную границу запуска

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

Назначьте владельцев решения. Продукт подтверждает полезность и текст; эксплуатация — доступность и восстановление; безопасность — идентичность, права и данные. Общее «все посмотрели» затрудняет остановку. У каждого блока есть конкретный критерий и подпись ответственного.

Определите стоп-условия до трафика: ложное действие, чужой контекст, потеря сообщения, неизвестный результат записи, недоступная передача человеку.

Проверьте инфраструктуру по слоям

Начните с службы и локальных проб, затем пройдите внешний DNS, TLS и обратный прокси. Одинаковый ответ локально и с пользовательского маршрута подтверждает разные участки. /readyz читается вместе с перечнем проверок, а не как абстрактная зелёная лампа.

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

Намеренно остановите тестовую зависимость и убедитесь, что сигнал меняется, а инструкция ведёт к восстановлению.

Пройдите данные, права и секреты

Используйте тестовые учётные записи с минимальными областями. Проверьте разрешённое чтение и запрещённую запись, прямой URL без права, истёкший ключ и отзыв подключения. Секреты не должны попадать в подсказку, карточку одобрения, публикацию или журнал.

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

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

Моделируемый сценарий

Команда запускает внутреннего помощника по регламентам. Тестовый сотрудник пишет из выбранного мессенджера, задаёт вопрос по действующему документу и получает ответ со ссылкой на источник. Затем спрашивает о правиле, которого нет. Система признаёт пробел и предлагает владельца процесса.

Следующий тест пытается создать задачу. Черновик содержит тему и ссылку на диалог, но запись происходит только после подтверждённого маршрута. Контрольное чтение возвращает идентификатор. При повторе того же события новая задача не появляется.

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

Восстановите, а не просто скопируйте

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

Проверьте откат обновления до рабочего запуска. Если миграция меняет данные, замены бинарника недостаточно. Решите, кто закрывает трафик и на какую точку возвращается. Учение должно использовать тестовые данные и не затрагивать рабочую среду.

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

Решение первой волны

Соберите короткий протокол: версия, сценарий, результаты проб, права, источники, канал, отказные тесты, восстановление, стоп-условия и владельцы. Непройденный блокер означает перенос либо уменьшение области, а не устное исключение.

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

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

Решение о допуске

Предстартовая проверка завершается не общим впечатлением, а решением по конкретному маршруту. Назовите владельца, дату, версию конфигурации и перечень доказательств. Отдельные результаты «канал отвечает», «инструмент читает» и «оператор видит эскалацию» ещё не доказывают, что полный путь работает вместе. Сквозной тест начинается входящим сообщением и заканчивается наблюдаемым результатом или безопасным отказом.

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

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

Через несколько дней после допуска повторите короткий набор на рабочем контуре с безопасными данными. Это не заменяет мониторинг, зато ловит расхождение между принятой сборкой и фактической настройкой. Любое существенное изменение канала, прав или инструмента возвращает затронутые проверки в статус ожидания.

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

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