Эксплуатация сайта

Минимальный регулярный контроль:

• открывается ли сайт;
• доступны ли критичные страницы;
• работает ли публикация;
• работают ли основные формы и поиск, если они есть;
• не истекает ли домен;
• создаются ли резервные копии;
• понятна ли текущая версия;
• нет ли битых критичных ссылок.

Проверяйте реальные пользовательские сценарии, а не только главную страницу.

Изменение считается выпущенным не когда разработчик закончил код, а когда новая версия:

1. подготовлена; 2. проверена; 3. опубликована; 4. повторно проверена в публичной среде.

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

Минимум:

• главная;
• изменённая функция;
• публикация;
• важные языковые переходы;
• поиск;
• критичные ссылки;
• мобильное отображение.

Не считайте успешный deploy доказательством того, что пользовательский сценарий работает.

До аварии нужно знать:

• можно ли вернуть предыдущую версию;
• кто принимает решение;
• кто выполняет откат;
• что произойдёт с данными;
• что проверять после восстановления.

Rollback, впервые обсуждаемый во время сбоя, почти всегда сложнее.

Записывайте только изменения, полезные для эксплуатации:

• дата;
• версия;
• что изменилось;
• кто выпустил;
• есть ли миграция данных;
• известные ограничения.

Не превращайте публичную историю в технический commit log.

Минимальный пакет:

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

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

Чаще всего полезнее короткие рабочие инструкции, чем 100-страничный технический том:

• как войти;
• как опубликовать;
• как обновить перевод;
• кто владеет доменом;
• как выпустить изменение;
• где резервные копии;
• что делать при сбое;
• кому передавать проблему.

Документация должна соответствовать реальному процессу.

Проведите реальные сценарии:

• создать публикацию;
• исправить её;
• обновить перевод;
• заменить документ;
• найти ответственного;
• понять текущую версию;
• эскалировать техническую проблему.

Если разработчик нужен для каждой опечатки, передача ещё не закончена.