Міграція даних - небезпечна чи істотна?

Відділ розробки програмного забезпечення моєї компанії стикається з проблемою, що міграція даних вважається потенційно небезпечною, особливо для моїх менеджерів.

Фон полягає в тому, що наші клієнти використовують велику кількість даних низької якості . Причини цього лише частково пов'язані з нашою якістю програмного забезпечення, а скоріше з історією даних: більшість з них були перенесені з попередніх систем , деякі помилки викликали (переважно бізнес) невідповідності в записах даних або випадки випадкових випадків на сторона замовника (що наше програмне забезпечення допускається помилково).

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

Особисто я вважаю міграції даних в якості складової частини програмного забезпечення розвитку і що міграція даних можна було бачити , даних , що рефакторинг в коді. Я думаю, що міграція даних є важливою для створення програмного забезпечення, яке розвивається . Без цього нам би довелося створити хворобливе програмне забезпечення, яке дещо працює навколо поганої структури даних.

Я прошу вас:

• Які ваші думки щодо міграції даних, особливо для реальних випадків життя, а не лише з точки зору розробника?
• Чи є у вас якісь аргументи проти думок моїх менеджерів?
• Як ваша компанія справляється з міграцією даних та труднощами, викликаними ними?
• Будь-які інші цікаві думки, що належать до цієї теми?

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

1. Це означає розробити десятки перевірок рівня безпеки даних (в основному це запити sql).

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

3. Вдосконалення інструмента за допомогою ітерацій та досягнення максимальної якості, підтримуваної KPI.

4. Перевірка узгодженості даних після міграції. Це допомагає приймати рішення GO / NOGO на D-Day.

Зрештою, міграція даних - надзвичайно вигідна вправа, яка має відбутися через 3 - 5 років.

1. Це дозволяє підвищити можливість платформи підтримувати бізнес.

2. Це дозволяє впорядкувати базу даних.

3. Він готує ІТ-платформу для бізнес-інструментів нового покоління (ESB / EAI, портали, платформи Self-Care, звітування та обмін даними, ви їх називаєте).

4. Він реорганізовує потоки даних "DIY" між платформами, що накопичилися роками, швидким та брудним "тимчасовим" способом для виконання "нагальних вимог".

5. Перш за все це дозволяє команді з виробництва ІТ, яка краще пізнає свою платформу та сприяє поглядам на те, що можна робити. Такі вигоди важко виміряти, але коли ви дізнаєтесь про багатьох клієнтів, це врахування стає очевидним. Компанії, що відхиляються від міграцій, залишаються у наступному рівні, сміливі лідирують у пакеті.

Це трохи схоже, коли підвал вашого будинку забивається пиломатеріалами. Одного ранку вам доведеться вийняти все і повернути назад тільки потрібні речі, а решту викинути. Після цього ви можете знову використовувати свій підвал ;-)

Ще одне фундаментальне враження полягає в тому, що в наш час очікування клієнтів завжди в русі, як і в "замовники завжди більш вимогливі". Таким чином, що завжди буде значна частина конкурентів даної компанії в пошуку цих нових тенденцій з очевидним наміром збільшити свою частку ринку. Як вони це зроблять, - адаптуючи свою пропозицію, щоб дотримуватися тенденції або навіть керувати тенденціями, і це тягне за собою постійне перепрофілювання бізнесу. Якщо ваша ІТ-платформа занадто жорстка, це призведе до перетягу вашої власної здатності до подружжя або передує тенденціям ринку на власній стороні і, в кінцевому рахунку, для збереження вашої власної частки на ринку. Іншими словами, в рухливому ринку інертність є рецептом нерелевантності.

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

Наведені вище міркування насправді відповідають лише половині запитань у заголовку "Міграція даних - небезпечна чи істотна". Так, міграція даних є важливою, але вони також небезпечні? На цей рахунок багато речей в ІТ-то тоді небезпечні. За визначенням, все, де ставки високі , небезпечно; особливо якщо ви не ставитесь до справи серйозно. Але це насправді найпоширеніша модель в ІТ. Не приймаючи датацентров або високу доступність і відмовостійкість серйозно це небезпечно.
Чи означає це, що сьогоднішні компанії повинні відмовитися від цих стовпів сьогоднішнього ландшафту інформаційних технологій? Напевно ні!

Якщо ви жартуєте, ви можете стверджувати, що "Літати небезпечно, якщо ви не використовуєте літак, виготовлений професіоналами". Це те ж саме для міграції даних. Якщо його виконують та проводять професіонали, це не небезпечніше, ніж літати у добре спроектованому та добре керованому літаку. І рентабельність інвестицій у тій же пропорції порівняно з наземними засобами транспорту.
Якщо доручити професіоналам, більшість міграцій добре контролюються успіхами, а рівень відмови + відмови вкрай низький.

Ваших менеджерів слід попросити запитати себе "Хоча більшість компаній успішно проходять проекти з міграції даних, що зробить нашу компанію настільки різною, що замість цього вона зазнає невдачі? І чи може вона пройти без неї?"

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

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

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

Я працював у страховій компанії та займався міграцією даних для основної системи. Ну, там було всього 4 рази. Отже, ось мої коментарі:

У моєму випадку міграція даних є обов’язковою, оскільки, регулюючи, ми повинні зберігати дані не менше 10 років, і ми не можемо дозволити підтримку подвійної системи в довгостроковій перспективі. Інша причина полягає в тому, що користувачі очікують, що вони можуть продовжити свою роботу з новим додатком. Якщо вони не можуть знайти предмет, над яким вони працюють, ваш додаток поганий, а ще гірше, коли дані невірні.

Ну, міграція даних - жахливий звір, і це реально, тож з цим зверніться. Це ризиковано, але його можна мінімізувати, звертаючись до нього раніше і обережно. Як керівництво, є чотири великі процеси, які слід враховувати при міграції даних:

1. Відображення даних. Карти майстра (та їх поєднання) до нової системи
2. Очищення даних. Карти виключення в даних, тобто дані, поєднання яких у новій системі вважається недійсним. Якщо можливо, займайтеся бізнесом, щоб виключити дані, які неможливо відобразити і потенційно зламати нову систему, і підготуйте рішення
3. Фактична міграція даних. Існує багато стратегій виконання міграції даних. Наприклад: великий чуб, поступовий
4. Звіт про консолідацію. Якщо обидві системи працюватимуть паралельно, як створити правильний та послідовний звіт

Подія з ретельним планом, лайно трапляється! Спеціальна група повинна бути готова вирішувати проблеми, пов'язані з міграцією.

1) Які ваші думки щодо міграції даних, особливо для реальних випадків життя, а не лише з точки зору розробника ?:

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

2) Чи є у вас якісь аргументи проти думок моїх менеджерів?

Так, міграція ризикована, але це також факт життя, тому займайтеся цим. І боротися з цим якомога раніше.

3) Як ваша компанія справляється з міграцією даних та труднощами, викликаними ними?

Моя компанія - з більшим успіхом бере участь охоронців активно в процесі міграції. Ми переглядаємо наявні дані якнайкраще на перших етапах проекту та закликаємо замовника покращити якість даних, перш ніж ми розпочнемо міграцію. Іноді ми насправді цього вимагаємо.

4: Будь-які інші цікаві думки, що належать до цієї теми

Моя порада - розділити процес міграції на два етапи: Перетворення та очищення даних. Перетворення є досить прямим вперед - питання відображення старих системних об'єктів до нової нової системи. З іншого боку, чистка даних може бути дуже хитрою (як було сказано вище). Максимально залучіть клієнта та розпочніть процес якомога раніше. Майте на увазі, що погані дані будуть погано відображатися на вашій новій системі - іноді абсолютно без причин. Коли нова система не працює, замовник рідко звинувачуватиме дані, які, здається, працюють у старій системі.

Якщо дані, які ви плануєте перенести, наразі погані, їх потрібно виправити, чи ви робите міграцію чи ні. Неправильні дані = марні дані.

Міграція ризикована, це правда. Але так є у кожного великого ІТ-проекту. Існують способи зменшити ризик, і їх, безумовно, слід планувати наперед в рамках міграції.

По-перше, у вас завжди повинен бути спосіб повернутися до системи, як зараз. Другі міграції слід робити на тестових серверах, які створені саме для міграції. Нерозумно робити міграцію, не маючи можливості перевірити її спочатку. По-третє, весь код для міграції повинен знаходитися у контролі джерела.

По-четверте, перед початком міграції потрібні вимоги та плани тестування. Вам потрібно знати, що якщо у вас було 1,293,687 записів у старій системі, у вас є те саме в новій або ви знаєте, куди вони пішли (можливо, до таблиці винятків). Якщо ви нормалізуєте денормалізовану схему, вам потрібно обчислити, скільки записів слід закінчити перед початком роботи, а потім перевірити це. Вам потрібна документація, яка визначає, що таке відображення однієї системи в іншу. Це допоможе вашим людям із забезпечення якості перевірити, чи надійшли дані в потрібне місце.

Вам потрібно визначити, як поводитися з поточними поганими даними. Що можна очистити, для чого може знадобитися значення в обов'язковому полі, на якому написано "Невідомо", що потрібно перекинути на таблицю винятків, що потребує вручну втручання групи користувачів (вирішення, чи справді ці двоє людей є копією або Чи є в цій практиці двоє лікарів з однаковою назвою, і якщо це дубль, які дані вибирати, коли дві записи відрізняються тощо).

Запорукою успішної міграції є планування. Я виявив, що планування (яке включає написання тестових випадків та тестових одиниць) зазвичай займає більше часу, ніж власне розробка.

Наступним ключем до успішної міграції даних є забезпечення якості. Це не проект, який потрібно кидати команді з контролю якості за день до запуску. Це не проект, який слід запускати, коли QA каже, що є проблема.

Ще одним ключем до успішної міграції є розгортання більшості даних та тестування їх, поки оргінальна система ще працює. Якщо ви переміщуєте багато записів, це може зайняти багато часу, і відбудуться нові зміни. Таким чином, ваш процес повинен мати можливість витягувати зміни даних і після початку міграції. Наприклад, у SQL Server є щось, що називається Змінити захоплення даних, що може допомогти у цьому. Ви можете зробити резервну копію початкової системи і одночасно ввімкнути захоплення змін. Тоді ви можете перенаправити резервну копію на міграційний сервер, протестувати міграцію, отримати більшість завантажених даних і тоді вам доведеться лише завантажити записи, які змінилися. Коли ви мігруєте остаточні записи, вимкніть вихідну систему, поки не буде виконана міграція. Це одна з причин передчасно перемістити більшість записів, тож програма не працює за найменший проміжок часу. Добре виберіть міграційний час, не закривайте систему оплати праці в день, коли вони повинні обробляти заробітну плату чи надсилати W2. І робіть це в години низького використання. Якщо у вас є кілька клієнтів, ви можете подумати про те, щоб перенести одного першого і переконатися, що все добре, перш ніж робити інші. Повернути дані одного клієнта набагато простіше, ніж 10000, якщо є проблеми. Але плануйте це уважно, якщо ви це зробите. s даних, ніж 10000, якщо є проблема. Але плануйте це уважно, якщо ви це зробите. s даних, ніж 10000, якщо є проблема. Але плануйте це уважно, якщо ви це зробите.

Якщо міграція передбачає новий інтерфейс користувача, будь ласка, дозвольте фактичним користувачам використовувати його як частину тестування на міграцію. Потім тренуйте інших користувачів, перш ніж виходити наживо (але менше тижня, перш ніж ви будете жити, або вони забудуть). Користувачі, які беруть участь у тестуванні, допомагають розробити навчання, вони знають, які питання у них виникали і що люди повинні знати, в якому порядку. Отримайте їх, зробивши поле необхідним, оскільки, на вашу думку, це не допоможе, якщо користувачі зазвичай не мають цих даних під час введення записів. Вони просто покладуть сміття в щойно необхідне поле, оскільки вони не зможуть отримати дані в іншому випадку.

Подивіться, що не так з поточними даними, чи можете ви додати сторонні ключі, обмеження, тригери, правила ведення бізнесу у програмі, значення за замовчуванням тощо, щоб уникнути цього в майбутньому погано? Коли ви чистите погані дані, вам також потрібно створити спосіб уникнути потрапляння подібних недоброзичливих даних у майбутньому. Проаналізуйте, чому погані дані були виділені, і виправте отвори в цілому дизайні.

Міграція даних - необхідність. Без міграції даних часто не можна йти вперед. Багато систем, з якими я працював, вимагають історії, доступної лише для попередніх систем. Міграція - єдиний практичний метод цього зробити. Якість даних часто є проблемою. Як правило, цим слід займатися в попередній системі. Це може зажадати змін у даних, щоб відновити якість.

Інші системи, з якими я працював, залежали від даних інших систем. Це інше, але суттєве питання. У деяких випадках дані можна повністю замінити. Інші випадки можуть бути краще вирішені шляхом об'єднання змін, включених до нових даних, у існуючий набір. Ці типи міграцій повинні включати перевірки дійсності для вхідного каналу.

Можливість перевірки та очищення існуючих даних може бути важливою особливістю системи. Це не залежить від міграції. Часто існують механізми для зміни даних, які не знаходяться під контролем системи. Це може призвести до недійсності даних. Інші проблеми з даними є наслідком помилок у програмі. Періодичне виконання процедур перевірки може допомогти визначити проблему та дозволити очищення даних, перш ніж настане час для міграції. Як зазначалося, очищення даних на ранньому етапі може полегшити міграцію.

Деякі перевірки залежать від часу і не повинні застосовуватися до даних, які не були змінені. Це звичайно з кодованими значеннями, де коди були вилучені. Потрібно мати можливість змінювати інші поля в записі, не викликаючи помилок перевірки. Це може зробити перевірку оновлення більш складною, оскільки потрібно визначити, які поля змінилися перед валідацією. Перевірка перехресного поля також може бути більш складною. Можливість розглянути деякі записи як лише для читання може допомогти в цьому випадку, оскільки можна уникнути перевірки.

На одній із систем, над якими я працював, нова система була частково відхилена замовником. Вони відмовилися дозволити використовувати нові модулі введення даних. Однак вони хотіли пакетної обробки з нової системи. Рішення полягало в тому, щоб мігрувати дані за ніч до запуску партії.

Це необхідне зло. Я був на обох кінцях, і це деякі інші проблеми, які складають проблему.

1. Особливо на підприємстві, коли компанії переходять до нової системи, вони хочуть, щоб вона робила все, що робила стара система. Вони не переглядають свої процедури. Вони настільки переповнені, що просто хочуть продовжувати робити все так само. Це для них безпечно.
2. Вони не потребують часу для вивчення нової системи або найму людей, які мають досвід.
3. Вони хочуть налаштувати нову систему так, щоб вона підходила під номер 1 або керувала якимось новим аспектом свого бізнесу. Нові налаштування системи X Перетворені дані = Складні ускладнення
4. Тестуванню присвячено недостатньо часу.
5. Клієнти ненавидять бігати паралельно / робити речі двічі. Не можна звинувачувати користувачів у тому, що їм не надано часу на це, оскільки всі їхні інші обов'язки виконуються повністю.

Якщо ваші менеджери можуть виправдати втрати продажів, не перетворюючи дані, більше потужності для них. Повідомити своїх клієнтів, що всі перетворення даних не вдасться, це не спрацює, тому що хтось інший завжди скаже їм, що це буде (як правило, ваша конкуренція.).

Які ваші думки щодо міграції даних, особливо для реальних випадків життя, а не лише з точки зору розробника?

програмне забезпечення повинно регулярно оновлюватися. щоб переконатися, що міграція збережена, вам потрібно створити резервне копіювання та тестування.

Чи є у вас якісь аргументи проти думок моїх менеджерів?

він правий, що це ризиковано. але ви можете адаптувати методи, щоб зробити це менш ризикованим.

Як ваша компанія справляється з міграцією даних та труднощами, викликаними ними?

ми маємо щоденне резервне копіювання, додаткове резервне копіювання, резервне копіювання перед кожним розгортанням у виробництво. що принаймні дозволить вам відкати, якщо трапиться щось погане.

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

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

ми використовуємо capistrano для виконання оновлення коду та міграції даних. автоматизована та проста міграція - це одне із ключових моментів, щоб забезпечити роботу виробничої системи.

Будь-які інші цікаві думки, що належать до цієї теми?

Ще одна проблема, що стосується міграції даних для мене - це послідовність оновлення коду та міграції даних. в моєму випадку, знову ж таки, ми використовуємо автоматизовані способи впоратися з цим. і завжди готовий до відкату.

виконання міграції даних вручну може перетворити базу даних у невідомий стан. і важко порівняти версію міграції даних між різними серверними середовищами.

сподіваюся, що це допомагає.

Ми не витрачаємо час, намагаючись перенести дані зі старих застарілих систем, оскільки час і інвестиції та ризик занадто великі. Ми просто рухаємося вперед із новішими системами та при необхідності інтегруємось.

Кожен бізнес має певну форму спадкової системи, яку він повинен підтримувати, і це просто нормальна вартість ведення бізнесу.

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