Отвечайте за сервис после deployment

Определите сервис, от которого зависят пользователи

Deployment делает ПО доступным. Эксплуатация сохраняет его полезность при изменении пользователей, зависимостей, трафика и требований. Генератор кода не устраняет эту постоянную работу.

В вымышленном примере экспорта клиентов пользователям недостаточно доступной страницы. Им нужны разрешённые записи в нужном формате за приемлемое время. Сервис также должен предотвращать доступ к данным другой организации.

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

Выбирайте сигналы, которые помогают действовать

Service-level indicator, или SLI, измеряет определённое свойство работы сервиса. Service-level objective, или SLO, задаёт целевое значение этого показателя за указанный период. Выбирайте его с учётом потребностей пользователей и возможностей эксплуатации.

Рекомендации Google SRE объясняют этот подход и использование бюджета ошибок при решениях о надёжности. Не копируйте целевое значение другого сервиса, не проверив его смысл. Рекомендации по SLO, пример политики бюджета ошибок.

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

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

Подготовьте реагирование на инциденты

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

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

Агент может составлять сводку логов или сравнивать гипотезы в разрешённых границах данных. Срочность инцидента не должна давать ему неограниченные полномочия в production. Для исключительного доступа используйте установленный порядок эскалации.

Отрабатывайте восстановление и выделяйте средства на обслуживание

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

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

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