Приложение работает. Что проверить перед запуском в продакшен
Приложение запустилось, нужный сценарий работает — можно выдохнуть. Но готово ли оно к пользователям? Успешный ответ на один запрос ещё не показывает, кому доступны остальные функции, кто может пользоваться диагностикой и какие ограничения действуют в рабочем окружении.
Продакшен — рабочее окружение, в котором сервисом пользуются настоящие пользователи. Интерфейс — точка обращения к приложению: пользовательская страница или функция для другой программы. У каждого интерфейса есть назначение и круг допущенных участников. Авторизация определяет, какие действия им разрешены. Она отличается от входа в систему: распознанный пользователь не обязательно имеет право управлять сервисом.
Первый шаг подготовки — сопоставить назначение интерфейсов с фактическим доступом к ним. Затем команда проверяет служебные функции и настройки, действующие после развёртывания.
Какие функции должны быть доступны пользователям
Для проверки доступа нужен перечень пользовательских и внутренних интерфейсов: их назначение, предназначенная сеть и разрешённые действия. Формулировка «для сотрудников» оставляет вопрос: для всех или только для тех, кто обслуживает сервис? Уточнение определяет ожидаемый результат проверки.
Сетевая доступность — ещё одно условие: возможность обратиться к сервису по сети не даёт права выполнить операцию.
В своей системе или разрешённом окружении проверяют, что допущенный участник выполняет предусмотренное действие, а пользователь без нужного права получает отказ. Обращение без входа и обращение вошедшего пользователя с недостаточными правами — отдельные проверки.
Скрытая кнопка управления не ограничивает прямое обращение к функции. Поэтому результат оценивают по тому, выданы ли защищённые данные и выполнена ли операция. Ни внешний вид страницы, ни один код ответа сами по себе этого не устанавливают.
Диагностика и управление: отдельный доступ
Диагностика даёт обслуживающей команде сведения о работе приложения, административные функции позволяют им управлять. Для каждой такой возможности отдельно определяется, кому и по какому пути она доступна. Условия пользовательского доступа нельзя автоматически переносить на служебный.
Ненужный отладочный режим в рабочем окружении отключают. Необходимый мониторинг — наблюдение за состоянием и работой сервиса — остаётся доступным предназначенным участникам и системам. Полное отключение служебных возможностей лишило бы команду нужных средств наблюдения.
Права приложения и ограничения рабочего окружения
Права нужны и самому приложению: оно обращается к другим компонентам и использует учётные данные. Компоненту следует выдавать минимально необходимые привилегии, а секреты — например, пароли и ключи подключения — предоставлять только тем компонентам, которым они нужны для работы.
Для каждой зависимости — другого сервиса или базы данных — определяется, какие операции приложение должно выполнять. Это описание сопоставляется с действующими правами его учётной записи. Работа под учётной записью разработчика не подтверждает права, с которыми запущен сервис.
Размер принимаемых запросов, допустимая нагрузка и время ожидания зависимостей требуют разных ограничений. Тайм-аут задаёт предел ожидания ответа; он не заменяет ограничение размера запроса. Подходящие значения зависят от операций и нагрузки: допустимую длительную обработку и большие объёмы данных нужно учитывать, чтобы настройка не мешала предусмотренной работе.
После развёртывания проверяют поведение выбранных ограничений на согласованных границах. Локальная проверка состояния приложения не подтверждает одновременно доступ по пользовательскому пути, авторизацию и все настройки окружения.
Кто проверяет систему перед выпуском
Возможный вариант распределения работы: разработчик объясняет настройки и ожидаемое поведение; инженер по тестированию (QA) выполняет согласованные проверки, фиксирует расхождения и перепроверяет исправления. Специалисты по безопасности приложений (AppSec) помогают сформулировать проверки безопасности; участие QA не подменяет специализированную проверку безопасности. Тимлид закрепляет ответственных и согласует действия по найденным проблемам. Если отдельного QA нет, исполнителя назначают из участников команды.
Список проверок составляется под конкретный сервис, с учётом его функций, зависимостей и средств наблюдения. В записи о результате нужны проверенное условие, использованные права, наблюдение и имя исполнителя. Вместо «доступ проверен» полезнее указать, с какой учётной записью выполнялось действие и совпал ли результат с ожидаемым.
При расхождении команда определяет, что исправить, кто этим займётся и как подтвердить исправление до решения о выпуске. Отметка о выполненном тесте не означает, что обнаруженное состояние приемлемо.
Повторные проверки привязывают к изменениям доступа, служебных функций, прав, операций, нагрузки и зависимостей. Проверку готовности также периодически проводят в ходе эксплуатации: её результаты помогают замечать расхождения с согласованными условиями и уточнять список.
Перед решением о выпуске участники сверяют ответы на короткий набор вопросов:
- Согласован ли перечень публичных и внутренних интерфейсов?
- Установлен ли доступ к диагностике и управлению?
- Подтверждены ли права приложения и выбранные ограничения?
- Кто выполнил проверки и остались ли расхождения?
- Какие проверки потребуется повторить после запланированных изменений?
С каким результатом завершать подготовку к запуску
Основа решения о выпуске — сопоставление ожидаемых условий с наблюдениями после развёртывания. Оно позволяет обсуждать конкретное расхождение: что должно было произойти, что произошло и можно ли выпускать сервис в таком состоянии. Успешный запуск приложения становится началом этой оценки, а не единственным её результатом.
Перед ближайшим выпуском полезно разобрать с участниками команды незакрытые пункты. Если по ним нет подтверждения или согласованного действия, готовность остаётся неясной именно в этих местах — даже когда остальные проверки пройдены.
