مهاجرت داده: پروژهای که همه دستکم میگیرند
در برآورد پروژههای سازمانی، یک قلم هست که تقریباً همیشه کمتر از واقع نوشته میشود: انتقال داده از سامانهٔ قدیمی.
دلیلش هم روشن است. در جلسه، مهاجرت داده شبیه یک کار فنی محدود به نظر میرسد — جدولها را میخوانیم، تبدیل میکنیم، مینویسیم. تا وقتی که فایل واقعی را باز میکنید و میبینید ستون «کد ملی» در هزار و دویست ردیف خالی است، در سیصد ردیف شمارهٔ تلفن دارد، و در چهل ردیف نوشته «ندارد».
چرا این کار سختتر از انتظار است
دادهٔ واقعی هیچوقت به تمیزی مدل داده نیست. سامانهٔ قدیمی ده سال کار کرده و در این ده سال، کاربران راههایی برای دور زدن محدودیتهایش پیدا کردهاند: توضیح سفارش را در فیلد آدرس نوشتهاند، مشتری تکراری ساختهاند چون سامانه اجازهٔ ویرایش نمیداده، تاریخ را دستی وارد کردهاند.
قواعد جدید سختگیرترند. نرمافزار جدید معمولاً اعتبارسنجی بهتری دارد — که مزیت است، تا لحظهای که میبینید چهل درصد رکوردهای قدیمی از این اعتبارسنجی رد نمیشوند.
هیچکس دقیقاً نمیداند دادهٔ درست کدام است. سه جا شمارهٔ مشتری هست و مقادیرشان یکی نیست. کسی که میدانست کدام معتبر است، سه سال پیش رفته.
حجم، مسئله را عوض میکند. اسکریپتی که برای هزار ردیف در ده ثانیه اجرا میشود، برای ده میلیون ردیف نه ده هزار ثانیه، بلکه گاهی چند برابر آن طول میکشد.
پیش از هر برآوردی، این را انجام دهید
نمایهسازی داده. قبل از نوشتن حتی یک خط کد مهاجرت، دادهٔ واقعی را بررسی کنید. برای هر جدول مهم:
- چند ردیف دارد؟
- در هر ستون کلیدی، چند درصد خالی است؟
- مقادیر یکتا چند تاست و توزیعشان چطور است؟
- چند رکورد تکراری محتمل هست؟
- ارجاعهای شکسته چند تاست — سفارشی که مشتریاش وجود ندارد؟
این کار معمولاً یکی دو روز میبرد و تفاوت بین برآورد و حدس همین است. ما در پروژههایی که این مرحله را قبل از قرارداد انجام دادهایم، تقریباً هیچوقت غافلگیر نشدهایم؛ و در آنهایی که نکردهایم، تقریباً همیشه شدهایم.
تصمیم دربارهٔ دادهٔ بد را کارفرما میگیرد، نه شما. برای هر دستهٔ مشکل، سه گزینه هست: اصلاح دستی، اصلاح خودکار با یک قاعدهٔ مشخص، یا انتقالندادن. این یک تصمیم کسبوکاری است. تیم فنی نباید خودش انتخاب کند که چه چیزی «به اندازهٔ کافی مهم نیست».
چقدر تاریخچه لازم است؟ سؤالی که کمتر پرسیده میشود و بیشترین صرفهجویی را دارد. آیا واقعاً به سفارشهای دوازده سال پیش در سامانهٔ جدید نیاز دارید، یا دسترسی خواندنی به سامانهٔ قدیمی برای موارد نادر کافی است؟ در بیشتر پروژهها، انتقال دو تا سه سال اخیر بهعلاوهٔ همهٔ دادههای پایه، پاسخ درست است.
نگاشت، جایی که وقت واقعی میرود
برای هر فیلد در سامانهٔ جدید، باید بدانید از کجا میآید. سه حالت وجود دارد و هر سه شایعاند:
نگاشت مستقیم. نام مشتری به نام مشتری. سادهترین و کمشمارترین.
نگاشت با تبدیل. تاریخ شمسی به میلادی، مبلغ ریال به تومان، وضعیت عددی به وضعیت نامدار. اینجا مراقب باشید: تبدیل واحد پول، شایعترین اشتباه پرهزینهٔ مهاجرت در پروژههای ایرانی است. سامانهٔ قدیمی ریال ذخیره میکرده و جدید تومان، و کسی متوجه نشده تا وقتی مشتری فاکتور دهبرابری دیده.
فیلدی که مبدأ ندارد. سامانهٔ جدید چیزی میخواهد که قبلاً ثبت نمیشده. باید تصمیم بگیرید: مقدار پیشفرض، خالی گذاشتن، یا تکمیل دستی بعد از مهاجرت.
نگاشت را در یک سند بنویسید و کارفرما تأییدش کند. این سند بعداً تنها مرجع برای جوابدادن به «چرا این عدد فرق دارد؟» است.
اجرا: چند بار، نه یک بار
اشتباه بزرگ این است که مهاجرت را یک رویداد در شب راهاندازی فرض کنید.
روش درست، اجرای مکرر است. اسکریپت مهاجرت را بنویسید و روی کپی دادهٔ واقعی اجرا کنید. نتیجه را بررسی کنید. اصلاح کنید. دوباره اجرا کنید. تا روز جابهجایی ممکن است ده تا پانزده بار این چرخه تکرار شود.
برای اینکه این ممکن باشد، دو چیز لازم است:
اسکریپت باید قابل اجرای دوباره باشد — یعنی اجرای مجدد نباید داده را دو برابر کند. همان اصلی که در کارهای پسزمینه گفتیم، اینجا هم برقرار است.
نتیجه باید خودکار بررسی شود. گزارش تطبیق بنویسید: تعداد مشتری در مبدأ و مقصد، جمع مبالغ فاکتورها در هر دو، تعداد رکوردهای رد شده به تفکیک دلیل. بررسی چشمی چند نمونه، بررسی نیست.
آن جمع مالی را جدی بگیرید. اگر جمع کل فاکتورها در دو طرف یکی نباشد، جایی داده گم یا تکرار شده و پیدا کردنش بعد از راهاندازی چند برابر سختتر است.
روز جابهجایی
سه الگو، به ترتیب ریسک:
قطع و انتقال. سامانهٔ قدیمی خاموش میشود، مهاجرت اجرا میشود، سامانهٔ جدید بالا میآید. سادهترین و برای بیشتر سازمانها قابل قبول، اگر پنجرهٔ زمانی کافی باشد. کلید کار این است که مدت اجرا را از قبل اندازه گرفته باشید — روی حجم واقعی، نه نمونه.
مهاجرت مرحلهای. دادههای پایه از قبل منتقل میشوند و فقط تراکنشهای اخیر در پنجرهٔ کوتاه. پنجره را کوتاه میکند، پیچیدگی را زیاد.
اجرای موازی. هر دو سامانه مدتی همزمان کار میکنند. کمترین ریسک ظاهری و بیشترین هزینهٔ پنهان: ورود دوبارهٔ داده، تناقض بین دو سامانه، و کاربری که نمیداند کدام معتبر است. اگر این را انتخاب میکنید، باید از روز اول مشخص باشد کدام سامانه مرجع است.
در پروژههای نوسازی که با الگوی خفهکننده پیش میروند، مهاجرت هم تکهتکه انجام میشود و همین یکی از دلایل جذابیت آن الگوست.
و همیشه مسیر بازگشت داشته باشید. پشتیبان کامل قبل از شروع، و یک تصمیم از قبل گرفتهشده دربارهٔ اینکه در چه شرایطی برمیگردیم. تصمیمگیری دربارهٔ بازگشت در ساعت چهار صبح، تصمیم خوبی نمیشود.
بعد از مهاجرت
هفتهٔ اول، کاربران چیزهایی پیدا میکنند که هیچ گزارش تطبیقی پیدا نمیکند — چون فقط آنها میدانند «این مشتری باید بدهکار باشد».
کانالی برای این گزارشها بگذارید و یکی دو نفر را برای رسیدگی سریع اختصاص دهید. اعتماد به سامانهٔ جدید در همان هفتهٔ اول ساخته یا خراب میشود.
و سامانهٔ قدیمی را فوراً حذف نکنید. دسترسی خواندنیاش را دستکم چند ماه نگه دارید. تقریباً همیشه به آن رجوع میشود.
اگر پروژهای دارید که پای سامانهٔ قدیمی در آن است، بخش داده را زودتر باز کنید تا دیرتر. ما در نرمافزار سفارشی نمایهسازی داده را قبل از برآورد انجام میدهیم، چون این تنها راهی است که عددی که میگوییم با عددی که در پایان درمیآید یکی بماند.