Миграция данных - опасно или важно?

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

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

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

Лично я рассматриваю миграцию данных как неотъемлемую часть разработки программного обеспечения, и что миграция данных может быть видна для данных, как рефакторинг для кода. Я думаю, что миграция данных необходима для создания развивающегося программного обеспечения . Без этого нам пришлось бы создавать болезненное программное обеспечение, которое в некоторой степени обходило бы плохую структуру данных.

Я спрашиваю тебя:

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

Миграция данных - это мой хлеб и масло, и очистка данных - действительно очень важный вопрос. Одна из стратегий, которую мы используем для миграции 100% данных наших клиентов, - это асимптотические инструменты для очистки данных перед миграцией.

1. Это означает разработку десятков проверок работоспособности данных (в основном SQL-запросов).

2. Обмениваясь с клиентом инструментами очистки (так как это его данные, мы разрабатываем утилиты исправлений, он проверяет их и выполняет).

3. Уточнение инструмента за итерации и достижение измеряемого качества на основе KPI как можно скорее.

4. Проверка согласованности данных после выполнения миграции. Это помогает принять решение GO / NOGO в день Д.

В конце концов, миграция данных - это чрезвычайно полезное упражнение, которое должно произойти через 3-5 лет.

1. Это позволяет повысить способность платформы поддерживать бизнес.

2. Это позволяет оптимизировать базу данных.

3. Он готовит ИТ-платформу для бизнес-инструментов следующего поколения (ESB / EAI, порталы, платформы самообслуживания, отчетность и интеллектуальный анализ данных, как вы это называете).

4. Он реорганизует потоки данных «сделай сам» между платформами, которые накапливались годами, быстрым и грязным «временным» способом для удовлетворения «срочных требований».

5. Помимо всего прочего, это дает возможность ИТ-специалистам, которые лучше узнают свою платформу и вырабатывают подходы «можно делать». Подобные преимущества трудно измерить, но когда вы узнаете много клиентов, это соображение становится очевидным. Компании, уклоняющиеся от миграций, остаются на следующем уровне, смелые лидируют.

Это немного похоже на то, когда подвал вашего дома захламлен пиломатериалами. Однажды утром вы должны вынуть все, положить обратно только то, что вам нужно, и выбросить все остальное. После этого вы можете снова использовать свой подвал ;-)

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

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

Приведенные выше соображения фактически отвечают только на половину вопроса, заданного в заголовке «Миграция данных - опасная или существенная». Да Миграции данных являются существенными, но они также опасны? На этом основании многие вещи в IT опасны. По определению, все, где ставки высоки , опасно; особенно если вы не относитесь к делу серьезно. Но это на самом деле самая распространенная модель в ИТ. Не принимая датацентров или высокую доступность и отказоустойчивость серьезно это опасно.
Означает ли это, что сегодняшние компании должны отказаться от этих столпов сегодняшнего ландшафта информационных технологий? Конечно нет!

Чтобы в шутку выразить свою точку зрения, вы можете утверждать, что «Полет опасен, если вы не используете самолет, созданный профессионалами». То же самое относится и к миграции данных. Когда он выполняется и проводится профессионалами, он не более опасен, чем полет на хорошо спроектированном и хорошо управляемом самолете. И ROI находится в той же пропорции по сравнению с наземными видами транспорта.
Когда доверяют профессионалам, большинство миграций являются хорошо контролируемыми успехами, и процент неудач + отказов крайне низок.

Ваши менеджеры должны задать себе вопрос: «Хотя большинство компаний успешно реализуют проекты по миграции данных, что может сделать нашу компанию настолько отличной, что вместо этого она потерпит неудачу? И может ли она справиться без нее?»

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

На мой взгляд, вопрос не в том, стоит ли выполнять миграцию данных, а в том, когда это делать. У вашего менеджера есть абсолютно правильное мнение о том, что ваши данные уже не только ваши, и конечные клиенты уже построили свои процедуры на них. Однако это состояние не изменится в будущем . Рано или поздно плохое качество данных станет неизбежным фактором замедления вашего бизнеса, и вы будете вынуждены выполнить миграцию. Выполнение этого под давлением и в сжатые сроки может привести к неоптимальным решениям. Кроме того, подумайте об опыте, который у вас есть сейчас и будет через 2-3 года. Что если люди, которые понимают ваши данные, покинут компанию? Вы уверены, что ваша документация адекватна?

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

Я работал в страховой компании и занимался миграцией данных для основной системы. Ну было всего 4 раза. Итак, вот мои комментарии:

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

Ну, миграция данных - ужасный зверь, и это реально, так что смотрите в лицо. Это рискованно, но можно свести к минимуму, обращаясь к нему ранее и тщательно. В качестве руководства, есть четыре больших процесса, которые следует учитывать при переносе данных:

1. Отображение данных. Карты мастера (и их комбинации) в новой системе
2. Данные очищаются. Карты исключений в данных, то есть данных, чья комбинация считается недействительной в новой системе. Если возможно, работайте с бизнесом, чтобы исключить данные, которые невозможно сопоставить и потенциально сломать новую систему, и подготовьте обходной путь
3. Актуальная миграция данных. Существует множество стратегий выполнения миграции данных. Например: большой взрыв, инкрементный
4. Консолидация отчетов. Если обе системы работают параллельно, как создать правильный и согласованный отчет

Событие с осторожным планом, дерьмо случается! Специальная целевая группа должна быть готова решать проблемы, связанные с миграцией.

1) Что вы думаете о переносе данных, особенно в реальных случаях, а не только с точки зрения разработчика ?:

Миграция является неотъемлемой частью развития систем. Если вы частично или полностью заменяете старые системы, миграция становится жизненным фактом, хочет руководство этого или нет. Если существующие данные плохие, они плохо отразятся на вашей новой системе. Таким образом, очень важно иметь хорошую стратегию миграции.

2) Есть ли у вас аргументы против мнений моих менеджеров?

Да, миграция рискованна, но это тоже жизненный факт, поэтому с этим надо бороться. И разберись с этим как можно раньше.

3) Как ваша компания справляется с миграцией данных и вызванными ими трудностями?

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

4: Любые другие интересные мысли, которые принадлежат этим темам

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

Если данные, которые вы планируете перенести, в настоящее время неверны, их необходимо исправить независимо от того, выполняете ли вы миграцию или нет. Плохие данные = бесполезные данные.

Миграции рискованны, это правда. Но так же каждый крупный ИТ-проект. Существуют способы снижения риска, и их, безусловно, следует планировать заранее при миграции.

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

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

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

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

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

Еще одним ключом к успешной миграции является развертывание большинства данных и их тестирование, пока оригинальная система все еще работает. Если вы перемещаете много записей, это может занять много времени и произойдут новые изменения. Таким образом, ваш процесс должен быть в состоянии получить изменения данных после начала миграции. Например, в SQL Server есть что-то под названием Change Data Capture, которое может помочь с этим. Вы можете сделать резервную копию оригинальной системы и одновременно включить сбор данных об изменениях. Затем вы можете восстановить резервную копию на вашем сервере миграции, протестировать миграцию, загрузить большинство данных, а затем вам нужно только загрузить измененные записи. Когда вы переносите окончательные записи, выключите исходную систему, пока миграция не будет завершена. Это одна из причин перенести большинство записей заранее, так что приложение не работает меньше всего времени. Тщательно выбирайте время переноса, не закрывайте систему начисления заработной платы в день, когда они должны обработать начисление заработной платы или отправить W2s. И делать это в часы низкого использования. Если у вас есть несколько клиентов, вы можете сначала рассмотреть вопрос о миграции одного и убедиться, что все хорошо, прежде чем делать другие. В случае возникновения проблем откатить данные одного клиента намного проще, чем 10000. Но планируйте это тщательно, если вы делаете это. данные, чем 10000, если есть проблема. Но планируйте это тщательно, если вы делаете это. данные, чем 10000, если есть проблема. Но планируйте это тщательно, если вы делаете это.

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

Посмотрите, что не так с текущими данными, можете ли вы добавить внешние ключи, ограничения, триггеры, бизнес-правила в приложение, значения по умолчанию и т. Д., Чтобы избежать этого в будущем? Когда вы очищаете неверные данные, вам также необходимо создать способ избежать попадания столь же плохих данных в будущем. Проанализируйте, почему плохие данные были распределены, и исправьте дыры в дизайне.

Миграция данных является необходимостью. Без миграции данных вы часто не можете идти вперед. Многие системы, с которыми я работал, требовали истории, доступной только из предыдущих систем Миграция - единственный практический способ сделать это. Качество данных часто является проблемой. Как правило, это должно быть решено в предыдущей системе. Это может потребовать изменения данных для восстановления качества.

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

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

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

В одной системе I, над которой я работал, новая система была частично отклонена заказчиком. Они отказались разрешить использование новых модулей ввода данных. Тем не менее, они хотели пакетной обработки из новой системы. Решение состояло в том, чтобы перенести данные за ночь до запуска пакета.

Это неизбежное зло. Я был на обоих концах, и это некоторые другие проблемы, которые усугубляют проблему.

1. Особенно на предприятии, когда компании переходят на новую систему, они хотят, чтобы она делала все, что делала старая система. Они не пересматривают свои процедуры. Они настолько ошеломлены, что просто хотят продолжать делать все одинаково. Это безопасно для них.
2. Они не занимают время, чтобы изучить новую систему или нанять людей с опытом.
3. Они хотят настроить новую систему для размещения # 1 или для управления каким-то новым аспектом своего бизнеса. Новые настройки System X X Преобразованные данные = сложные осложнения
4. Недостаточно времени уделяется тестированию.
5. Клиенты ненавидят работать параллельно / делать что-то дважды. Не могу винить пользователей, потому что им не дают времени сделать это, так как все остальные их обязанности выполняются в полную силу.

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

Что вы думаете о переносе данных, особенно в реальных случаях, а не только с точки зрения разработчика?

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

Есть ли у вас аргументы против мнений моих менеджеров?

он прав, что это рискованно. но вы можете адаптировать методы, чтобы сделать его менее рискованным.

Как ваша компания справляется с миграцией данных и вызванными ими трудностями?

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

у нас есть среда тестирования, автоматизированные тесты и ежедневная сборка сервера. также процедура теста на дым, чтобы убедиться, что основные операции и функции работают должным образом. Мы привлекаем разработчиков, QA и пользователей для тестирования сборки (которая перенесла данные).

мы используем ruby ​​on rails, который обеспечивает управление миграцией, обновлением и откатом данных. что делает нашу жизнь проще.

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

Любые другие интересные мысли, которые относятся к этой теме?

Еще одна проблема, касающаяся переноса данных для меня, - это последовательность обновления кода и переноса данных. в моем случае, опять же, мы используем автоматизированные способы справиться с этим. и всегда готов к откату.

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

Надеюсь, это поможет.

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

У каждого бизнеса есть какая-то устаревшая система, которую он должен поддерживать, и это просто нормальная стоимость ведения бизнеса.

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