Введение
Вот проснулись вы как-то утром и решили начать новую жизнь вместе с базой данных PostgreSQL оставив другие за бортом. Но с чего начать? Как «подкатить» и не быть отвергнутым? А ведь вы уже не молоды и «с прицепом»: с данными, нагрузкой и бизнес-логикой.
Так как в данный момент тема миграций в тренде, не могу пройти мимо и не поделится своим опытом подобных мероприятий. Данная задача не самая простая, так как требует подмены одной из фундаментальных технологий проекта — хранилище данных.
Начнем с самого простого, кто должен производить работы по миграции, какие задачи перед ними будут стоять и, собственно, план миграции. Но прежде чам начать сразу определим правила которых следует придерживаться и не стоит пренебрегать.
Правила миграции
Только миграция для бизнеса
На время проведения миграции требуется заморозить разработку новой функциональности. Сразу уточню: я подразумеваю не полную заморозку вообще всех работ, а только в части рефакторинга и создание нового большого функционала, которое сильно влияет на схему данных в базе. Для эксплуатации так же производится заморозка больших внедрений новых технологий.
Это нужно в первую очередь для того, что бы проблемы и баги возникающие при внедрении чего-то нового не смешивались с проблемами миграции. То есть, все знают как сейчас работает проект, от интерфейсов до сетевого взаимодействия и соответственно выявить аномалии работы во время и после миграции будет проще.
Только миграция для разработки
«Давайте по пути еще баги поправим?» — нет. Если не поправили баги до этого, то исправлять их во время миграции уже поздно. Периодически исправление старых багов порождает новые.
«Давайте по пути еще оптимизацию сделаем?» — нет. Оптимизация кода, если будет нужна, будет проводится в рамках миграции только в критических случаях. Если работало медленно, то пусть так же работает медленно. Мы одну технологию меняем на другую, она не должна работать хуже. Возможно она будет работать лучше, но потом.
«Давайте по пути еще рефакторинг сделаем?» — нет. Наслоение проблем миграции и рефакторинга, замедляет и первое и второе в несколько раз. Причем периодически потребуется полный откат до начального состояния.
«А может сразу архитектуру новую сообразим?» — тогда это не миграция а переписывание проекта, миграция тут не при чем.
В каждой компании есть «стена плача», «список хотелок», «wish list» и так далее. Только, как показывает практика, запуск любых параллельных улучшений начинает тормозить весь процесс. В итоге, если все же хотите сделать что-то еще кроме миграции, то к срокам миграции смело добавляйте скроки рассчитанные для вашего нового внедрения или решения и сверху еще смело прибавьте еще 30% дополнительного времени, так как сроки рассчитывались для базы данных с которой вы давно работали и можете достаточно точно просчитать проблемы.
В итоге, пусть ваш список «хотелок» останется списком «хотелок» который будет решаться планово после миграции.
Только миграция для эксплуатации
«Я тут почитал, что на другой операционной системе PostgreSQL работает лучше» — нет. Работайте с тем с чем умеете.
«Я тут почитал, что на другой файловой системе PostgreSQL работает лучше» — нет. Работайте с тем с чем умеете.
«А еще у нас в планах Лунапарк с Блэк Джеком стоит, давайте сделаем» — нет. Добавление новых технологий и процессов так же как и в разработке не получится осуществлять параллельно. Рассчитываете ресурсную стоимость внедрения
Есть список задач для текущей базы данных, эксплуатационные требования и регламенты. Соблюдаем только что что есть на данный момент. Когда миграция будет завершена, тогда все «хотелки» будут решаться планово. Как и у разработки.
В итоге
Вы хотите поменять базовую технологию — это как операция на сердце. Чешется нога? Потерпите, почешете после операции.
Состав участников
Для нормального обеспечения всех этапов миграции не достаточно одного человека , требуется собрать группу из сотрудников разных подразделений с полной или частично занятостью, в том числе по ролям:
- Координатор проекта — или директор или менеджер, кому как нравится. Главное, что бы этот человек обладал всем спектром полномочий для принятия любого решения в рамках проекта. Так как проектная группа будет включать в себя сотрудников из других подразделений, то координацию между ними должен осуществлять управленец.
- Группа разработки, в которую входят:
- Руководитель разработки проекта — главное, что бы этот человек мог принимать решения в части разработки и понимал её внутреннюю «кухню»;
- Архитектор проекта;
- Разработчики — как руки;
- Группа эксплуатации, в которую входят:
- Руководитель эксплуатации проекта — главное, что бы этот человек мог принимать решения в части эксплуатации и понимал её внутреннюю «кухню»;
- DBA;
- Администраторы — как руки;
- Тестировщики — кто то же должен проверять качетсво работ;
- «Доктор» — человек или группа людей которые могут оперативно посоветовать как что сделать и возможно помочь руками. Это могут быть как внутренние специалисты, так и внешние, так как нужны только на время миграции.
Да, некоторые специалисты могут совмещать некоторые роли, важно, что работы для этих ролей можно выполнять параллельно, то есть, на вопрос: «может ли один человек все сделать?» — ответ, «да, может», но не быстро.
Что касается «доктора», то он может быть, а может и не быть, вот только я часто сталкивался с историями, когда процесс миграции в компаниях заходил в тупик и не этом все заканчивалось. Так, одной фирме мы помогали осуществлять миграцию, они пробовали её делать сами, но при этом у них была потеря производительности в 30%, что естественно, не приемлемо. Когда же мы подняли тестовый стенд и немного «подкрутили», то производительность стала такой какой надо. Да, речь не идет о том, что просто не хватало некоторых индексов, решение было глубже. Рассчитывать на то, что «местные» специалисты, которые ни разу не работали с PostgreSQL, могут к нему быстро прийти — не стоит.
Задачи миграции
Перечислим основные задачи которые требуется решать во время миграции. Этот список моно дополнять, но учитывать, что каждая дополнительная задача будет требовать дополнительного времени для её исполнения.
Для управления
- Разрешение конфликтов — кто-то же должен разбираться в бермудском треугольнике: менеджмент — разработка — эксплуатация;
- Организация частичной заморозки разработки и эксплуатации — примимает решения о том какие работы, которые могут влиять на процесс миграции, следует заморозить;
- Организация технологического окна — конечный этап миграции: переключение проекта на новую базу данных. Это не всегда возможно сделать «бесшовно» без остановки проекта. Поэтому требуется технологическое «окно» во время которого что-то работать не будет;
- Контроль исполнения плана — наше все.
Для разработки
- Прозрачное переключение сервисов и приложениий на новую базу данных — проект должен работать как минимум так же как и до миграции. Не обязательно лучше, но обязательно не хуже;
- Изучение диалекта SQL, драйверов (коннекторов) и особенностей работы PostgreSQL — как то же надо будет продолжать жить с новой технологией.
Для эксплуатации
- Прозрачное переключение сервисов и приложениий на новую базу данных — так же как и у разработки;
- Изучение эксплуатации PostgreSQL — так же как и у разработки.
В итоге
- Проект должен поддерживать всю функциональность что и до миграции. Ничего нового, но и про старое не забыть, те же возможности, те же проблемы. Пользователи и клиенты вообще не должны заметить разницы;
- Сотрудники должны раучится работать с новой технологией;
- Проект и сервисы должны работать примерно так же по скорости и ресурсам. «Примерно» — только из-за другой архитектуры базы данных. Что-то будет работать немного быстрее, что-то немного медленней, где-то менше ресурсов будет требоваться, где-то больше. Но в среднем качество должно быть сопоставимым;
- Проект должен быть так же устойчив к нагрузкам и авариям, что и до миграции (SLA). То есть время «простоя» проекта должно быть не больше чем до миграции;
- Резервирование должно так же соответсвовать начальным требованиям.
План миграции
Для начала выделим несколько основных этапов, а потом уже будет детализировать их по отдельности:
- этап подготовки — нет, это не R&D, это изучение старого. Что мигрируем;
- этап реализации — а вот тут уже R&D, это изучение нового. Куда мигрируем;
- этап тестирования — пробуем со всем этим взлететь. Как мигрируем;
- этап миграции — как есть;
- опытная эксплуатация — тоже как есть;
Продолжение следует…