в облаке
Попробовать

Как составить правильный план деплоймента компоненты

12.02.2010 17:10

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

 

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

 

Итак, какие основные вещи следует иметь до и сделать во время деплоймента:

  1. Максимально детальный план работ, расписанный по часам, минутам и исполнителям - это поможет реально оценить необходимое для деплоймента временное окно, а так же понимать, кто когда и что должен делать. Обязательным пунктом являются бакапы всего, что может сломаться в ходе обновления.
  2. Такой же детальный план отката, на случай проблем - критически (!) важный пункт, который, из-за природного оптимизма, чаще всего никто не делает. Что соотвественно приводит к печальным последствиям, особенно если деплоймент идет в сильно сжатые сроки.
  3. Дистрибутивы всех необходимых компонент, лицензионные ключи - чтобы не оказалось так, что в самый важный момент у нас нет какого-нибудь лицензионного ключа, а люди, у которых он есть, сейчас спят (так как ранее утро) или отдыхают с семьей на природе (потому что выходные).
  4. Контактные мобильные (!) телефоны абсолютно всех людей, которые могут помочь или от которых что-либо может зависеть - это позволить максимально быстро решить любую проблему, если таковая возникнет (а она, как правило, обязательно возникнет).
  5. Доступ (заранее проверенный) ко всем необходимым серверам, наличие всех необходимых прав - как думаете, сколько времени займет срочное получение доступа к какому-нибудь серверу в выходные, из России в США, через их сервис-деск?
  6. Уведомление всех людей, которых может затронуть обновление - это необходимо сделать для того, чтобы они могли подготовиться к обновлению, а так же не проводили никакие работы с приложением во время его обновления.
  7. Оценка влияния на другие сервисы - необходимо оценить влияние нашего обновления на зависимые сервисы - можем ли мы их остановить (не нарушит ли это работу других пользователей) и не являются ли эти сервисы зависимыми.
  8. Проверка, что все остановленные на время деплоймента сервисы поднялись нормально (наши и другие сервисы) - обязательно проверить все сервисы, которые были остановлены, поднялись ли они после, например, перезапуска системы.
  9. Смок тестирование - после окончания деплоймента необходимо убедиться, что обновленный компонент работоспособен, и что соседние сервисы так же работают нормально.

 

Кстати, например именно этот чеклист в свое время (несколько лет назад), сильно помог бы нам не завалить один из первых удаленных деплойментов на европейской фабрике заказчика. Тогда все закончилось в целом хорошо - нас только сильно наругали и заставили написать lessons learnt. И конвеер на фабрике тогда не остановился, и бизнес не начал терять деньги.

 

А ведь могло бы быть и по-другому..

Еще интересные статьи на эту тему: