Эта статья посвящена общим принципам создания плана миграции системы, что чаще всего актуально при обновлении. Основные риски, которые существуют при миграции
Первым делом надо ранжировать риски, понять какие критичные, а какие не очень. Например мигрировать свежеустановленную систему просто — нет риска потери данных. А вот систему, которая используется давно и круглосуточно без простоя скорее всего не получится, но можно этот простой сократить. Для того чтобы минимизировать эти риски и требуется создавать план миграции.
План миграции составляет менеджер проекта (либо тот кто выполняет его роль). В случае простых миграций его можно нарисовать в голове, в сложных случаях нужно расписать все действия по минутам, провести аудит плана, одну или даже несколько репетиций, чтобы убедиться что с приемлемой вероятностью миграция завершиться успехом, а если нет, будет получена информация об ошибках, которая позволит скорректировать план миграции и повысить вероятность его успешного завершения, при этом для пользователей никаких изменений не произойдет. Их нужно будет только уведомить о том, что сегодня миграция не случилась, и сообщить вероятную дату следующей попытки. Т.е. главное — ЛИБО МИГРАЦИЯ УСПЕШНА, ЛИБО ОНА ПЕРЕНЕСЕНА БЕЗ ПРОСТОЯ ДЛЯ ПОЛЬЗОВАТЕЛЕЙ.
Начнем с конца. Желаемое состояние после любой миграции — все пользователи имеют техническую возможность, и знают как использовать новую систему, т.е. обучены; в систему перенесены все данные из старой системы и поддерживаются как минимум все те же функции что и в старой. А для того, чтобы минимизировать простои, если что-то пошло не так, старая система не удаляется и доступна даже во время начала использования новой. Администратор при поступлении информации о критическом состоянии новой системы в любой момент может принять решение вернуться обратно к старой (ценой потери некоторых данных, которые уже успели внести в новую систему). Таким образом ПОСЛЕДНИЙ ШАГ миграции — уведомление пользователей о начале использования новой системы и переключение url которым пользователи привыкли пользоваться со старой на новую систему. Старая система должна быть доступна по альтернативному URL, её легко переключить назад, либо дать этот URL пользователям, чтобы они продолжили работу в старой системе.
Последним этапом перед переключением пользователей на новую систему должен быть перенос данных. Для того чтобы данные были целостные, перед началом переноса данных пользователей надо отключить от системы, чтобы они не вносили новых данных — тогда новая система сразу будет с устаревшими данными. Исключение - круглосуточно используемые системы, которые нельзя отключать. В этом случае все изменения сделанные после переноса данных логируются и накатываются на новую систему после того как пользователи переключены на неё. Это приводит к краткосрочному использованию системы с не самыми актуальными данными, но как правило это можно компенсировать проинструктировав пользователей.
Получаем просто правило «Скопировал базу данных — быстрой делай все по плану и переключай пользователей». Если вы делаете миграцию ночью, когда никто не использует систему, то можно делать не быстро.
Для системы где нужно минимизировать простой, для систем с большим количеством пользователей нужна обязательно. Суть — выполнить весь план миграции за исключением окончательного переключения. Ну и пользователей беспокоить не нужно. Важно чтобы результаты репетиции были подтверждены не тем же кто осуществляет перенос а кем-то другим. Либо представителем заказчика, либо менеджером проекта. Помните, что тестирование это деструктивный процесс (надо найти ошибки, а подсознательно хочется чтобы в твоей работе не было ошибок), поэтому серьезное тестирование должно быть выполнено другим человеком.
Вы можете сделать все идеально, но пользователи которые придут в новую систему начнут делать нелогичные вещи, все сломают и придётся тратить кучу времени чтобы все починить или повторить миграцию. Знакомо? На самом деле пользователи всегда поступают логично. Только с позиции их логики, а она отличается. Поэтом перед миграцией надо поставить себя на место пользователя и подумать, знает ли он как пользоваться новой системой, какие будут отличия? Что делать нельзя, а что можно? Будет ли для него переход прозрачным и понятным, или это будет стресс? Может помимо знакомства с новым интерфейсом сделать ещё какое-то обучение, предупредить об особенностях и тонкостях?
Бывают удачные и неудачные даты для миграции. Примеры неудачных: 8 марта для цветочников, конец квартала для бухгалтерии, 1 сентября для образования. Удачными являются продолжительные выходные для всех пользователей (кроме админа, конечно), когда можно все делать неспеша.
Такой сценарий тоже надо предусмотреть. Более того, его необходимо проработать наиболее тщательно. Я уже не говорю про резервные копии, если до них дошло дело, значит тот кто занимается миграцией облажался по-крупному. Если в какой-то момент миграции, тот кто её осуществляет понимает, что что-то не было предусмотрено, и устранить это по-быстрому не получается, он принимает решение о переносе даты миграции. При этом если старая система работает, то нужно всего лишь сообщить пользователям о переносе даты миграции. Если она не работает, то надо восстановить её работоспособность. А чтобы это было просто сделать, нужно заранее проработать список всего что вы собираетесь ломать на время переноса и убедиться что починить это максимально просто. Это тоже надо заранее проверять. Например выключить интеграцию с почтой просто - достаточно снять одну галочку. А для включения поставить её обратно. А вот поменять доменное имя - уже сложнее, поэтому менять его нужно только когда вы уверены, что все идет по плану.
Самый неприятный сценарий — когда пользователи начали использовать систему и обнаружили какие-то ошибки. В силу сложности, многие системы не могут быть быстро протестированы достаточно хорошо, поэтому такая вероятность часто существует. В этом случае ответственный (а он должен быть на связи чуть ли не круглосуточно хотя бы неделю после миграции. Никаких переездов перед выходными или отпуском ответственного!!!!) должен оценить время устранения ошибок и целесообразность отката на старую систему (помните, пользователи как-то работали со старой версией долгое время, если что и ещё немного поработают). Если проблемы вызванные ошибками некритичны и их быстро можно устранить, то продолжаем пользоваться новой системой. Если же они мешают работе компании, то принимаем решение об откате назад, при этом нужно учитывать, что за время тестирования пользователями между системами накопились различия, и не достаточно просто переключить URL (или дать пользователями url по которому старая версия доступна), нужно ещё и накопленные за это время данные перенести.
Для каких-то случаев это избыточная сложность. Но там где цена простоя измеряется сотнями тысяч рублей в час, а потеря данных грозит миллионными убытками или потерей бизнеса, такие предосторожности просто обязательны (а по факту страховок ещё больше). Соизмеряйте риски!