План миграции

Эта статья посвящена общим принципам создания плана миграции системы, что чаще всего актуально при обновлении. Основные риски, которые существуют при миграции

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

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

План миграции составляет менеджер проекта (либо тот кто выполняет его роль). В случае простых миграций его можно нарисовать в голове, в сложных случаях нужно расписать все действия по минутам, провести аудит плана, одну или даже несколько репетиций, чтобы убедиться что с приемлемой вероятностью миграция завершиться успехом, а если нет, будет получена информация об ошибках, которая позволит скорректировать план миграции и повысить вероятность его успешного завершения, при этом для пользователей никаких изменений не произойдет. Их нужно будет только уведомить о том, что сегодня миграция не случилась, и сообщить вероятную дату следующей попытки. Т.е. главное — ЛИБО МИГРАЦИЯ УСПЕШНА, ЛИБО ОНА ПЕРЕНЕСЕНА БЕЗ ПРОСТОЯ ДЛЯ ПОЛЬЗОВАТЕЛЕЙ.

Начнем с конца. Желаемое состояние после любой миграции — все пользователи имеют техническую возможность, и знают как использовать новую систему, т.е. обучены; в систему перенесены все данные из старой системы и поддерживаются как минимум все те же функции что и в старой. А для того, чтобы минимизировать простои, если что-то пошло не так, старая система не удаляется и доступна даже во время начала использования новой. Администратор при поступлении информации о критическом состоянии новой системы в любой момент может принять решение вернуться обратно к старой (ценой потери некоторых данных, которые уже успели внести в новую систему). Таким образом ПОСЛЕДНИЙ ШАГ миграции — уведомление пользователей о начале использования новой системы и переключение url которым пользователи привыкли пользоваться со старой на новую систему. Старая система должна быть доступна по альтернативному URL, её легко переключить назад, либо дать этот URL пользователям, чтобы они продолжили работу в старой системе.

Последним этапом перед переключением пользователей на новую систему должен быть перенос данных. Для того чтобы данные были целостные, перед началом переноса данных пользователей надо отключить от системы, чтобы они не вносили новых данных — тогда новая система сразу будет с устаревшими данными. Исключение - круглосуточно используемые системы, которые нельзя отключать. В этом случае все изменения сделанные после переноса данных логируются и накатываются на новую систему после того как пользователи переключены на неё. Это приводит к краткосрочному использованию системы с не самыми актуальными данными, но как правило это можно компенсировать проинструктировав пользователей.

Получаем просто правило «Скопировал базу данных — быстрой делай все по плану и переключай пользователей». Если вы делаете миграцию ночью, когда никто не использует систему, то можно делать не быстро.

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

Вы можете сделать все идеально, но пользователи которые придут в новую систему начнут делать нелогичные вещи, все сломают и придётся тратить кучу времени чтобы все починить или повторить миграцию. Знакомо? На самом деле пользователи всегда поступают логично. Только с позиции их логики, а она отличается. Поэтом перед миграцией надо поставить себя на место пользователя и подумать, знает ли он как пользоваться новой системой, какие будут отличия? Что делать нельзя, а что можно? Будет ли для него переход прозрачным и понятным, или это будет стресс? Может помимо знакомства с новым интерфейсом сделать ещё какое-то обучение, предупредить об особенностях и тонкостях?

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

1. Начать работы в 23-00 (нерабочее время)
2. Уведомить пользователей что сегодня в нерабочее время нельзя пользоваться системой, а после этого отключить возможность авторизации для всех кроме админа.
3. Поднять копию системы на отдельной виртуальной машине на URL […]
4. Установить самоподписанный сертификат для данного URL.
5. Отключить скрипты выполняемые по cron, интеграцию с телефонией, почтой и с сайтом, интеграцию с SMS оставить
6. Выполнить подготовленные скрипты миграции для обновления системы
7. Залогиниться в систему, убедиться что она работоспособна, нет явных ошибок, работают основные модули, данные актуальны
8. Проверить что система работает и в локалке и через интернет
9. Включить интеграции, которые можно протестировать без конфликтов с основной системой, проверить интеграции (список …)
10. Перенести старую систему на временный URL [old….] и выключить крон и интеграцию с телефонией.
11. Перенести новую систему на основной URL и включить все интеграции и крон
12. Проверить работоспособность новой системы и всех интеграций (план тестирования прорабатывается отдельно)
13. Принять решение об успешности миграции. Включить в новой системе возможность авторизации пользователей.
14. На одном или нескольких пользователях проверить возможность авторизоваться, возможность работы с их IP адресов, отсутствие ошибок
15. Проверить отсутствие ошибок в логах
16. Уведомить пользователей о том что миграция прошла успешно, напомнить о необходимости проверить почту, куда дублируются заявки с сайта, чтобы убедиться что ночные заявки не потерялись, а попали в систему.

Такой сценарий тоже надо предусмотреть. Более того, его необходимо проработать наиболее тщательно. Я уже не говорю про резервные копии, если до них дошло дело, значит тот кто занимается миграцией облажался по-крупному. Если в какой-то момент миграции, тот кто её осуществляет понимает, что что-то не было предусмотрено, и устранить это по-быстрому не получается, он принимает решение о переносе даты миграции. При этом если старая система работает, то нужно всего лишь сообщить пользователям о переносе даты миграции. Если она не работает, то надо восстановить её работоспособность. А чтобы это было просто сделать, нужно заранее проработать список всего что вы собираетесь ломать на время переноса и убедиться что починить это максимально просто. Это тоже надо заранее проверять. Например выключить интеграцию с почтой просто - достаточно снять одну галочку. А для включения поставить её обратно. А вот поменять доменное имя - уже сложнее, поэтому менять его нужно только когда вы уверены, что все идет по плану.

Самый неприятный сценарий — когда пользователи начали использовать систему и обнаружили какие-то ошибки. В силу сложности, многие системы не могут быть быстро протестированы достаточно хорошо, поэтому такая вероятность часто существует. В этом случае ответственный (а он должен быть на связи чуть ли не круглосуточно хотя бы неделю после миграции. Никаких переездов перед выходными или отпуском ответственного!!!!) должен оценить время устранения ошибок и целесообразность отката на старую систему (помните, пользователи как-то работали со старой версией долгое время, если что и ещё немного поработают). Если проблемы вызванные ошибками некритичны и их быстро можно устранить, то продолжаем пользоваться новой системой. Если же они мешают работе компании, то принимаем решение об откате назад, при этом нужно учитывать, что за время тестирования пользователями между системами накопились различия, и не достаточно просто переключить URL (или дать пользователями url по которому старая версия доступна), нужно ещё и накопленные за это время данные перенести.

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