От R&D-прототипа к надёжному ПО

Определите результат, видимый пользователю

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

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

Наблюдайте поведение и нагрузку

В главе Google SRE о мониторинге выделены задержка, трафик, ошибки и насыщение ресурсов. Для исследовательского сервиса свяжите их с задачей пользователя: успешный HTTP-ответ может содержать непригодный результат.

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

Сделайте выпуск воспроизводимым

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

Сохраните связь выпуска и результатов приёмки. При изменении поведения это позволит понять, какая версия проверялась и прошла ли новая версия тот же путь.

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

Проверяйте восстановление отдельно

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

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

Оформите решение о готовности явно

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

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