Control freak

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

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

Календарь релизов

Сколько в месяце рабочих дней? Пусть двадцать. А сколько дней пригодны для выкладок? Нет, не двадцать, намного меньше:

После выкладки что угодно может пойти не так. Хорошо, если вы заметите это сразу. Но если изменения таковы, что проблемы в работоспособности системы возможно отследить только на следующий день? Мало кто любит приезжать в выходные на работу, чтобы спешно разбирать инциденты, выпускать фиксы или откатывать последние изменения. А значит лучше сразу договориться, что пятница (а в общем случае – день перед любыми выходными и праздниками) является днём моратория – днём без выкладок. Итого остаётся шестнадцать полноценных дней.

Для большинства проектов тут можно остановиться, но я работаю не просто над сайтом, а над компонентом платёжной системы. Риски помешать пользователям выше в определённые дни, когда люди начинают массово платить за какие-то услуги. Приходиться расширять мораторий на три последних и три первых дня каждого месяца. Допускаю, что на других сервисах «опасные» дни могут быть другими. Важен принцип – не вносить изменения в работающую систему, когда она наиболее востребована пользователями. Сколько дней осталось для релизов? Да, совсем немного. А успеть надо…

Естественным является желание выполнить несколько выкладок в один день. Имеем право? Да, безусловно. Но и день, как месяц, не бесконечен. Выкладываемся до четырёх-пяти часов дня, не позднее – чтобы успеть отреагировать на все негативные последствия неудачного релиза и спокойно спать ночью, разумеется.

Разрешение на выкладку

Чтобы релиз случился, он должен соответствовать следующим требованиям:

• Успешное завершение тестирования. Пакет, входящих в релиз, должен быть протестирован – может быть в ручном режиме, может быть только приёмочными автотестами, может быть проверен под нагрузкой. Иногда, редко, формально тестирование не проводится вовсе, выполняется только проверка руками разработчиков. Так или иначе, отчёт с результатами тестирования должен быть обязательно.
  • Не все ошибки, найденные тестерами, мешают выкладке релиза. По согласованию с заказчиком часть исправлений может быть отложена, обычно потому, что сценарий возникновения ошибки, придуманный тестерами, практически невоспроизводим обычными пользователями. Но важно все такие проблемы зафиксировать не только как будущие задачи, но и как часть описания текущего релиза. Пригодятся.
• Заказчик принял результат. От заказчика требуется получить согласие дважды – на то, что сделанное соответствует его представлениям о том, как функционал должен был выглядеть, и на то, что с точки зрения бизнеса и маркетинга момент для релиза подходящий, не раньше и не позже идеального.
• День и время – вне моратория.
• Есть технологическая возможность выполнить релиз:
  • Наша вкладка не пересекается по времени с обновлением других, независимых компонент системы. Иначе есть риск, что при возникновении проблем не удастся сразу определить их источник.
  • Компоненты, с которыми наша должна обновляться синхронно, готовы к выкладке.
  • Настройка серверов, сетевые доступы, разрешения – все подготовительные работы проведены.
  • Все участники процесса выкладки (ответственный за релиз, админы) находятся на рабочих местах и не заняты ничем другим.

Предупреждён – значит вооружен

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

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

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

Не меньше ответственности и на службе эксплуатации, и в наших интересах как можно подробнее описать им предстоящую выкладку:

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

Надеемся на лучшее, готовимся к худшему

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

• проблемы в процессе выкладки:
  • сетевые (пропала сеть, пропали доступы, …);
  • технологические («умерла» система контроля версий, «глючит» cms, …);
  • человеческий фактор (не то выложили, забыли обновить данные, …);
• проблемы сразу после выкладки:
  • всё сломалось;
  • не сломалось, но и не работает или работает неправильно;
• отсроченные проблемы.

Для каждой потенциальной проблемы надо продумать нашу реакцию на неё, и, в любом случае:

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

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

«Рубильник»

Обожаемый мной «рубильник» – это инструмент для изменения нормального поведения портала без перевыкладки компонент:

• изменение внешнего вида страниц;
• настройка редиректа со страниц;
• ограничение доступа к страницам.

Обычно «рубильник» делается в следующих случаях:

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

Для реализации «рубильника» можно использовать либо какую-то cms, либо конфиги, управляемые эксплуатацией. Так или иначе, срабатывать «рубильник» должен мгновенно.

Удобно использовать «рубильник» при выкладке. Устанавливаем его в состояние off, выкладываемся, проверяем целостность портала и доступный только нам функционал, затем переключаем – здравствуй, пользователь!

Может быть это не совсем очевидно, но при тестировании релиза «рубильник» обязательно должен тестироваться отдельно. Какой смысл в красой кнопке, если в нужный момент она не запустит ракету, верно?

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