Source و Target هر دو دقیقاً یک میلیون Row دارند؛ ۱۰۰ Batch از ۱۰۰ Batch سبز است، Checksum برابر و Job error صفر است. آیا مهاجرت داده درست انجام شده؟ هنوز نه. ممکن است هر دو Count برابر باشند اما یک رکورد کم و یک رکورد تکراری باشد؛ Checksum با Canonicalization ضعیف تفاوت را پنهان کند؛ تومان به ریال اشتباه تبدیل شود؛ Timestamp جابهجا، رابطه شکسته یا Delete در CDC گم شده باشد.
این راهنما یک Data Migration Evidence Protocol میسازد: Scope و Source Snapshot → Mapping/Transform Rules → Batch/Checkpoint/Replay → Target Snapshot → Reconciliation چندلایه → Exception/Repair → Cutover/Rollback → Result/Correction. هدف، ادعای محدود و قابلردیابی دربارهی Population مشخص است؛ نه سبزکردن یک Job.
پاسخ کوتاه: تست مهاجرت داده چیست؟
تست مهاجرت داده بررسی میکند که دادهی داخل Scope از Source با Snapshot و مرز زمانی مشخص، طبق Mapping و Transform نسخهدار، بدون فقدان/تکرار/تغییر نامجاز و با Semantics و روابط مورد انتظار به Target رسیده است. این بررسی Schema، Population، Row/Field، Aggregate، Relationship و Business invariant را همراه با Pending/Exception و محدودیت Evidence میسنجد.
| Dashboard | آنچه ثابت میکند | آنچه ثابت نمیکند |
|---|---|---|
| Job succeeded | Runner طبق Exit semantics خاتمه یافته | کاملبودن یا درستی داده |
| Count برابر | Cardinality کل برابر است | همان Entityها یا نبود Duplicate |
| Checksum برابر | Digest ورودی Canonicalشده برابر است | درستی Canonicalization و Semantics |
| Schema ایجاد شد | DDL بخشی از Target اعمال شده | Mapping، Constraint behavior یا Data |
| Batch سبز | Batch status سبز است | Checkpoint، Replay safety و Reconciliation |
مرز این مقاله با TDM، ETL و Cutover سیستم لگسی
مدیریت داده تست مالک Request/Fitness/Provisioning/Cleanup یک Data Pack است. تست Data Pipeline Ingestion/Transform/Stream/Replay را در محصول داده پوشش میدهد. تست سیستم Legacy مدرنسازی، Characterization و Cutover کل سیستم را مالک است. این مقاله فقط Evidence لازم برای Migration Run و Reconciliation Source-to-Target را میسازد.
| Intent | مالک | خروجی |
|---|---|---|
| داده مناسب تست بسازیم | TDM/Fitness | Data Pack |
| Pipeline دائمی داده را تست کنیم | Data Pipeline | Data Product Evidence |
| یک Population را منتقل و تطبیق دهیم | همین مقاله | Migration/Reconciliation Evidence |
| سامانه قدیمی را جایگزین کنیم | Legacy modernization | Characterization/Cutover portfolio |
Migration، Replication، Backfill، Restore و Provisioning یکی نیستند
| عمل | هدف | ریسک ویژه |
|---|---|---|
| Migration | انتقال مالکیت/ساختار یا بستر | Mapping، Cutover، Point of no return |
| Replication/CDC | همگامسازی تغییر پیوسته | Lag، Ordering، Delete، Replay |
| Backfill | پرکردن داده تاریخی/مشتق | Window، Recompute، Duplicate effect |
| Backup/Restore | بازسازی State ذخیرهشده | Restore validity و Recovery point |
| Test provisioning | تحویل Dataset برای Test | Fitness، Privacy، Isolation، Cleanup |
زنجیرهی هویت Migration را Pin کنید
«مهاجرت شنبه شب» شناسه نیست. Source/Target System و Schema، Mapping، Transform code، Build، Run، Batch، Snapshot، CDC position، Reconciliation و Cutover باید شناسههای جدا داشته باشند. بدون این زنجیره، Repair یا Re-run ممکن است روی نسخهی دیگری اجرا شود.
Program/Product → Migration/Scope → Source System/Schema/Snapshot/Position → Mapping/Transform/Build/Run → Batch/Checkpoint/Exception → Target System/Schema/Snapshot → Reconciliation/Result → Cutover/Decision/Correction
Migration Scope Contract
Scope فقط فهرست Table نیست. Entity، Tenant، تاریخچه، Attachment، Derived view، Archive، Deleted record، Data class و Exclusion را ثبت کنید. Success claim و Not claimed را قبل از Result بنویسید تا یک Subset سبز به کل Source تعمیم داده نشود.
MigrationScope {
scopeId, businessPurpose,
includedEntities, excludedEntities,
sourceObjects, targetObjects,
historicalRange, tenantScope,
dataClasses, sensitivityClasses, policyRefs,
qualityQuestions, riskIds,
successClaim, notClaimed,
assumptions, unknowns, version, digest
}
Source Snapshot باید یک مرز زمانی واقعی باشد
اگر Table A ساعت ۱۰:۰۰ و Table B ساعت ۱۰:۲۰ خوانده شود، Count و روابط ممکن است از دو State متفاوت بیایند. Snapshot method، Isolation semantics، Source position، Object set و سیاست Concurrent write را ثبت کنید. مستند PostgreSQL نشان میدهد Repeatable Read یک Snapshot پایدار میدهد، اما حتی آن هم Semantics و محدودیتهای خودش را دارد؛ مرجع: PostgreSQL Transaction Isolation. رفتار را برای Engine واقعی خود بررسی کنید.
SourceSnapshot {
snapshotId, sourcePosition, snapshotMethod,
isolationSemantics, capturedAt, timezone, clockSource,
consistentObjectSet, concurrentWritePolicy,
cdcStartPosition, cdcEndPosition,
schemaDigest, rowPopulationManifest,
retention, access, redaction,
limitations, digest
}
Full Load و CDC را با Gap یا Overlap طراحی کنید
Full Load تا Position مشخص و CDC از Position مشخص باید به هم متصل شوند. Gap میتواند Change را گم کند و Overlap بدون Idempotency میتواند Effect تکراری بسازد. Start/end position، Catch-up lag، Ordering، Tombstone/Delete و Reconnect semantics را در Run Manifest نگه دارید.
| مرز | Failure | Evidence |
|---|---|---|
| Full load → CDC | Gap یا overlap | Snapshot/CDC positions + replay test |
| Reconnect | Event دوباره یا گمشده | Resume token + idempotency key |
| Out-of-order | State قدیمی روی جدید | Sequence/version rule |
| Delete | Target ghost record | Tombstone lineage |
| Long transaction | Cutoff ambiguity | Commit position and policy |
Mapping Contract؛ Spreadsheet بینسخه کافی نیست
هر Mapping باید Field، Type، Transform، ترتیب Rule، Null/default، Enum، Precision/scale، Rounding، Timezone، Encoding، Normalization، Key/Relationship/Delete و Provenance را تعریف کند. Oracle مستقل از Transform تا حد ممکن از تکرار همان اشتباه جلوگیری میکند.
MappingRule {
mappingId, sourceField, targetField,
sourceType, targetType, transformRule, ruleOrder,
nullSemantics, defaultSemantics, enumMap,
precisionScale, roundingMode,
timezoneRule, encodingRule, normalizationRule,
keyRule, relationshipRule, deleteRule,
provenanceRule, oracleId, version, digest
}
Null، Empty، Missing و Default را یکی نکنید
| Source state | Target rule نمونه | ریسک |
|---|---|---|
| NULL | NULL یا governed default | ساخت Fact جعلی |
| Empty string | حفظ یا Normalize طبق Basis | ازبینرفتن معنای «واردشده ولی خالی» |
| Field missing | Schema-evolution rule | اشتباه با NULL |
| Legacy sentinel | Map نسخهدار | -۱/۱۹۰۰-۰۱-۰۱ بهعنوان داده واقعی |
| Default target | فقط با Source/authority | پنهانکردن Missing migration |
Type، Precision، Scale و Rounding
Cast موفق به معنای حفظ معنا نیست. Integer overflow، Decimal scale، Floating representation، Boolean/Enum، Large object truncation و Collation باید Boundary و Property داشته باشند. برای مقدار پول، Currency و Unit بخشی از داده است؛ Money Contract و Reconciliation مالی جزئیات بیشتری دارد.
| ریسک | Test | Oracle |
|---|---|---|
| Decimal→Integer | Boundary/negative/max/scale | Exact governed conversion |
| Float | Tolerance پیشتعریفشده | Domain precision، نه arbitrary epsilon |
| Enum | تمام Source values + unknown | Versioned map |
| Text length | grapheme/byte boundaries | No silent truncation |
| LOB | size/digest/content sample/full policy | Explicit validation scope |
زمان، منطقه زمانی و Calendar
Timestamp without timezone، Local time، UTC instant، Date-only و Duration را جدا کنید. DST/Offset، precision، epoch، ambiguous time و Cut-off ممکن است تغییر معنایی بسازند. در داده فارسی، UTC instant را Canonical نگه دارید؛ Asia/Tehran و تاریخ جلالی View هستند مگر Domain Contract چیز دیگری بگوید.
Unicode، فارسی، RTL و شناسه
ی/ی، ک/ک، نیمفاصله، ارقام فارسی/عربی/لاتین، NFC/NFD، Collation و RTL/LTR میتوانند Equality، Sort، Search یا Unique key را تغییر دهند. Normalization را خودکار «پاکسازی» ننامید؛ Rule باید Field-specific باشد و Raw lineage یا Source reference را حفظ کند.
Persian migration test values (fictional) digits: ۱۲۳ | ١٢٣ | 123 letters: ی/ي | ک/ك spacing: space | ZWNJ normalization: NFC and NFD variants direction: RTL label + LTR stable ID time: UTC instant → Asia/Tehran view → Jalali presentation
Key Mapping و Provenance
Source key ممکن است در Target Surrogate تازه بگیرد. Crosswalk باید Source key reference را به Target key وصل کند و Version/Batch/Transform lineage داشته باشد. Plain PII را برای Traceability ذخیره نکنید؛ Reference یا Hash تحت Policy کافی است. Collision، Merge، Split و Re-parenting را صریح مدل کنید.
| حالت | ریسک | Evidence |
|---|---|---|
| 1→1 | Wrong mapping | Crosswalk + row compare |
| N→1 merge | Loss/precedence ambiguity | Merge rule + source set |
| 1→N split | Missing child | Expected cardinality/invariant |
| Re-key | Broken foreign/logical link | Relationship reconciliation |
| Dedup | False merge | Match policy + review sample |
Referential Integrity شرط لازم است، نه Business Integrity
Foreign key سبز فقط رابطهی فیزیکی تعریفشده را میسنجد. رابطهی منطقی میان Storeها، Event و Ledger، Version و History یا Tenant boundary ممکن است Constraint دیتابیس نداشته باشد. Invariantهای کسبوکاری را جدا بنویسید: هر Callback حداکثر یک Effect، جمع Breakdown برابر Total و Child متعلق به همان Tenant.
Delete، Tombstone، Archive و Retention
مهاجرت فقط Insert/Update نیست. Hard delete، Soft delete، Tombstone، Expiry، Legal hold و Archive semantics باید در Scope و CDC حاضر باشند. Ghost record در Target میتواند هم Privacy و هم Business behavior را نقض کند. Retention/Deletion authority را از تیم Migration اختراع نکنید.
Batch Contract، Checkpoint و Resume
MigrationBatch {
batchId, partitionRule,
sourceRange, targetRange, inputCount, outputCount,
startedAt, completedAt,
checkpointBefore, checkpointAfter, resumeToken,
idempotencyKey, retryPolicy, replayPolicy,
duplicatePolicy, orderingPolicy,
status, evidenceManifestId,
supersedes, digest
}
Batch سبز باید Range بدون Gap/Overlap، Checkpoint durable، Resume token و Evidence داشته باشد. Retry تنها وقتی امن است که Transform/Load idempotent یا Compensation تعریف شده باشد. Restart از ابتدا ممکن است Duplicate بسازد؛ Resume از Position اشتباه ممکن است Loss ایجاد کند.
Reconciliation چندلایه؛ Count کافی نیست
| لایه | سؤال | Failure نمونه |
|---|---|---|
| Schema | Object/type/constraint/index مطابق Contract؟ | Default یا collation متفاوت |
| Population | همان Entity keyها حاضرند؟ | یک Missing + یک Duplicate |
| Row/Field | Mapping هر مقدار درست است؟ | Null/round/timezone mismatch |
| Aggregate | Count/sum/distribution per partition؟ | خطاها همدیگر را خنثی کردهاند |
| Relationship | فیزیکی و منطقی حفظ شده؟ | Orphan یا cross-tenant link |
| Invariant | قاعده دامنه برقرار است؟ | دو Effect برای یک Event |
| Journey | Target داده را درست مصرف میکند؟ | Storage صحیح، application mapping غلط |
مستندات رسمی AWS DMS Data Validation نمونهای از مقایسه Source/Target و وضعیتهای Pending، Suspended و Failed ارائه میکند و محدودیت/هزینهی Validation را نیز میگوید. آن را قابلیت یک ابزار بدانید، نه استاندارد جهانی یا جایگزین Business invariant و Mapping Oracle.
Reconciliation Contract قابلکپی
Reconciliation {
reconciliationId,
sourceSnapshotId, targetSnapshotId, comparisonAsOf,
population,
sourceCount, targetCount,
missingSourceCount, missingTargetCount, duplicateTargetCount,
fieldMismatchCount, invalidTransformCount,
relationshipViolationCount,
aggregateChecks, invariantChecks,
samplePolicy, fullComparePolicy, tolerancePolicy,
pendingCount, suspendedCount,
verdict, limitations, digest
}
Checksum را با Canonicalization و Scope بخوانید
Checksum به ترتیب Row/Column، Encoding، Null representation، Float/Decimal، Timestamp، Whitespace و normalization حساس است. اگر Source و Target Schema متفاوتاند، Hash خام ممکن است همیشه متفاوت یا با حذف Fieldهای مهم ظاهراً برابر شود. Canonical form، Field set، ordering، algorithm/version و Partition را در Evidence ثبت کنید.
Full Compare، Sampling و Risk
Full row compare هم همیشه ممکن یا بیهزینه نیست؛ Validation میتواند Source/Target را تحت بار بگذارد. Sampling برای Discovery یا Confidence محدود مفید است، اما Pass نمونه به Population کامل تعمیم نمییابد. Stratified/risk/change-based sample، Seed، Population، Inclusion probability و Claim limit را ثبت کنید.
| روش | مزیت | محدودیت |
|---|---|---|
| Full key compare | Missing/Duplicate گسترده | هزینه و key requirement |
| Partition aggregate | سریعتر و Locator بهتر | خطاهای جبرانی |
| Row/field full | Mismatch دقیق | Transform/canonical complexity |
| Risk-stratified sample | تمرکز روی Edgeها | عدم اثبات کل Population |
| Journey/invariant | Semantics مصرف | Coverage محدود سناریو |
Tolerance را پیش از Result تعریف کنید
Tolerance برای Measurement uncertainty یا Transform مجاز است، نه پاککردن Failure. Absolute/relative tolerance، Unit، Field/Population، دلیل، Authority و Boundary را قبل از مقایسه Pin کنید. برای Money یا Count گاهی Tolerance باید صفر باشد؛ برای Float ممکن است Domain-specific باشد.
Exception Registry؛ Pending و Suspended مساوی Pass نیستند
MigrationException {
exceptionId, entityKeyRef, batchId, category,
observation, expected, actual, evidenceRefs,
severity, status, ownerCapability, decisionAuthority,
disposition, rationale, repairPlan,
reconcileAgain, dueAt, digest
}
Missing Source، Missing Target، Duplicate، Transform mismatch، Relationship violation، Validation error و Cannot compare را جدا کنید. Exception بدون Owner/Disposition/Expiry نباید در Count موفق حل شود. «Suspended» یعنی نتوانستهایم مقایسه کنیم، نه اینکه داده درست است.
Repair، Resync و Reconciliation دوباره
Repair باید Source/Mapping version، Entity، prior/new value reference، Authority و Evidence را حفظ کند. Patch مستقیم Target ممکن است Provenance را نابود کند یا CDC بعداً آن را برگرداند. پس از Repair، همان Layerهای متاثر را Reconcile و Result قبلی را Supersede کنید؛ سبزکردن Exception table کافی نیست.
Performance و Safety خود Migration
Throughput بالا اگر Lock، Replica lag، Storage saturation یا App latency بسازد موفقیت نیست. Rate limit، Maintenance window، resource guardrail، Kill switch، Restore point و Incident path تعریف کنید. Validation نیز Query و Network cost دارد؛ سرعت را کنار Source/Target health و Correctness بسنجید.
| Metric | Guardrail | Stop نمونه |
|---|---|---|
| Rows/sec | Source p95 latency | عبور پایدار از Threshold |
| CDC lag | Change loss/duplicate | Position discontinuity |
| Validation rate | DB CPU/IO | خطر سرویس |
| Exception rate | Category concentration | Failure class ناشناخته |
| Batch duration | Checkpoint freshness | Resume unsafe |
Privacy و Security؛ Production Copy پیشفرض نیست
مهاجرت Validation به PII واقعی نیاز قطعی ندارد. Purpose، minimization، access، encryption، retention، deletion و audit را با Authority سازمانی تعیین کنید. Masking و Pseudonymization ریسک را کاهش میدهند اما ناشناسبودن یا Compliance را تضمین نمیکنند؛ Synthetic نیز خودکار Safe/Representative نیست. برای انتخاب راهبرد، داده واقعی یا مصنوعی و برای Privacy، ملاحظات حریم خصوصی TDM را ببینید.
Cutover Contract؛ Migration Pass خودکار Go نیست
CutoverPlan {
cutoverPlanId, mode,
entryCriteria, freezePolicy, writeRouting,
cdcCatchupThreshold, finalReconciliationId,
decisionAuthority, goDecision, goRationale,
rollbackTriggers, rollbackTarget, rollbackProcedure,
pointOfNoReturn, communications, monitoringWindow,
exitCriteria, digest
}
Final Reconciliation، Open exceptions، CDC lag، Application smoke، Operational readiness و Business timing ورودی تصمیماند. Test Result یک توصیه یا Evidence است؛ Authority Go/No-Go را Policy تعیین میکند. Point of no return را صریح کنید.
Rollback را تمرین کنید؛ Backup وجود دارد کافی نیست
Rollback ممکن است Schema/Data را برگرداند اما Email، Message، Payment request یا External side effect را پس نگیرد. Restore target، Recovery point، Write freeze/routing، Reverse mapping، CDC handling، External-effect compensation و Reconciliation پس از Restore را تمرین کنید. Dual write نیز Consistency را تضمین نمیکند و Divergence evidence میخواهد.
Evidence Manifest و Result
MigrationResult {
resultId, migrationId, runId,
scopeId, sourceSnapshotId, targetSnapshotId,
mappingVersion, transformBuildId,
batchManifestId, reconciliationId,
exceptionCountsByState, pendingCount, suspendedCount,
verdict: HOLD | INCONCLUSIVE | READY_FOR_REVIEW,
unknowns, limitations, residualRisk,
evidenceManifestId, supersedes, digest
}
READY_FOR_REVIEW را Production Go ننامید. Manifest باید Snapshot/Mapping/Batch/Comparison/Exception/Cutover rehearsal را پیدا کند و Access/Retention/Redaction داشته باشد. Evidence تولیدکنندهی Transform تا حد امکان تنها Validator نباشد.
Correction و Affected-decision analysis
اگر Mapping اشتباه، Snapshot ناسازگار یا Validator ناقص کشف شد، Result قدیمی را بیصدا تغییر ندهید. Correction با prior/new digest، Scope متاثر، Re-run/Reconcile refs و Query تصمیمها/مصرفکنندگان بسازید. Target اصلاحشده بدون اعلام به Downstream ممکن است Resultهای قبلی را نامعتبر کند.
آزمایشگاه فارسی: مهاجرت Checkout کاملاً خیالی
این Lab کاملاً ساختگی و جدا از هر شرکت، بانک، PSP، کاربر، پرداخت یا سامانهی واقعی است؛ شبکه و Production واقعی ندارد و توصیهی بانکی، مالی، حقوقی، مالیاتی، امنیتی، حریم خصوصی یا انطباق ایران نیست. Entityهای خیالی Order، PaymentAttempt، PSP Stub، Callback Event، Ledger Entry و Reconciliation Job هستند.
| Transform خیالی | ریسک | Oracle |
|---|---|---|
| نمای تومان برچسبخورده → IRR canonical ×۱۰ | Unit confusion | Exact Money mapping |
| Local Tehran view → UTC instant | Offset/order shift | Known instant pairs |
| ی/ی و ک/ک | False merge/key collision | Field-specific NFC rule |
| Callback→Ledger relation | Duplicate effect | یک Effect برای Event ID |
| Soft delete→Tombstone | Ghost record | Delete lineage |
Tenant/Order/Attempt/Event/Ledger/Run/Batch/Snapshot/Evidence شناسههای جدا دارند. مقدارها فقط IRR خیالی و نمای تومان صریحاند؛ ارقام فارسی/عربی/لاتین، Unicode NFC، RTL/LTR، UTC/Asia-Tehran و Jalali نمایشی پوشش داده میشوند. هیچ نام، موبایل، ایمیل، IP، حساب، PAN، CVV2، OTP، Cookie، Token، Credential، Log یا Screenshot واقعی استفاده نمیشود.
Fixture: یک میلیون Row سبز در برابر ۲۱۳ Finding
Fixture مستقل `SYN-DATA-MIGRATION-RECONCILIATION-۰۱` با Node.js و بدون Dependency بیرونی اجرا شد. Dashboard یک میلیون Source Row، یک میلیون Target Row، ۱۰۰/۱۰۰ Batch، Checksum MATCH و صفر Job error را دید و `MIGRATION_PASS` اعلام کرد. ممیزی ۲۱۵قاعدهای همان ورودی را با دقیقاً ۲۱۳ Finding به HOLD برد.
| گروه | قاعده | نمونه |
|---|---|---|
| Identity | 18 | Source/Target/Schema/Mapping/Build/Run |
| Scope | 18 | Entity/Range/Class/Claim/Unknown |
| Snapshot | 18 | Position/Isolation/Object set/CDC |
| Mapping | 22 | Type/Null/Money/Time/Key/Delete |
| Batch | 20 | Range/Checkpoint/Resume/Idempotency |
| Reconciliation | 22 | Missing/Duplicate/Field/Relation/Invariant |
| Exception | 18 | Category/Evidence/Disposition/Repair |
| Cutover | 18 | Entry/Freeze/Go/Rollback/Exit |
| Governance | 19 | Owner/Authority/Correction/Limit |
| Forbidden + Relations | 42 | مطلقگویی و سازگاری قراردادها |
نسخهی اصلاحشده `MIG-SYN-۳۱`، Snapshot `SNAP-SRC-SYN-۳۱` و CDC positions را Freeze کرد، Mapping تومانِ برچسبخورده به IRR و Time/Unicode/Delete rules را نسخهدار ساخت، Batch ۰۴۲ را به Checkpoint/Resume/Evidence بست، یک Exception را با Provenance Repair کرد و Reconciliation صفر Missing/Duplicate/Mismatch/Violation و صفر Pending/Suspended ساخت. نتیجه `READY_FOR_MIGRATION_EVIDENCE_REVIEW` با صفر Finding بود؛ نه اثبات Privacy/Compliance، Truth Source، پوشش خارج Scope، Business correctness یا Production Cutover.
Automation و AI
Automation باید Snapshot/position، Mapping digest، Batch range/checkpoint، Validation query/version، Exception و Manifest را تولید کند. AI میتواند Mapping candidate، anomaly cluster یا SQL draft پیشنهاد دهد؛ نباید Mapping را بدون Domain review اعمال، PII دریافت، Tolerance اختراع، Mismatch را خودکار Repair، Provenance را overwrite یا Go/Risk acceptance صادر کند. Prompt/model/input/output و Human decision را ثبت کنید.
معیارهای سالم و Countermetricها
| Metric | کاربرد | Countermetric |
|---|---|---|
| Rows/sec | توان انتقال | Mismatch/DB impact |
| Reconciliation coverage | Population/Layer بررسیشده | Validator blind spots |
| Exception age | پیری اختلاف | False repair/reopen |
| CDC lag | فاصله Position | Loss/duplicate/order |
| Resume success | تابآوری Batch | Duplicate effect |
| Cutover duration | Window عملیاتی | Correctness/rollback readiness |
| Correction latency | سرعت اصلاح Claim | Affected consumers reached |
۳۴ Anti-pattern مهاجرت داده
- Count برابر را اثبات Migration دانستن.
- Checksum برابر را اثبات Semantics دانستن.
- همه Batch سبز را Completeness دانستن.
- صفر Job error را Correctness دانستن.
- Schema success را Data success دانستن.
- Referential integrity را Business integrity دانستن.
- Sample pass را تعمیم به Population.
- Production copy را الزامی دانستن.
- Masking را تضمین Anonymity دانستن.
- Synthetic را دارای ریسک Privacy صفر دانستن.
- Automation را حذف خطای انسانی دانستن.
- ETL success را Migration pass دانستن.
- CDC lag صفر را نبود Lost change دانستن.
- Exactly once را شعار بدون Scope.
- Retry را همیشه امن دانستن.
- Rollback را بازگرداننده همه External effectها دانستن.
- وجود Backup را Restore proof دانستن.
- Dual write را تضمین Consistency دانستن.
- Source را همیشه Oracle دانستن.
- Target را همیشه Oracle دانستن.
- Null و Empty را یکی گرفتن.
- Timezone را فقط Display دانستن.
- Rounding mismatch را بیخطر دانستن.
- Unicode normalization را بدون اثر Identity دانستن.
- Delete را از Scope حذفکردن.
- Orphan را فقط FK error دانستن.
- Reconciliation را Row count نهایی دانستن.
- Pending را Pass دانستن.
- Suspended را Pass دانستن.
- Repair بدون Provenance.
- Mapping خودکار AI بدون Review.
- Repair خودکار AI.
- Migration pass را Cutover Go دانستن.
- Cutover موفق را Business correctness دانستن.
چکلیست ۳۲نقطهای Migration Owner
| حوزه | کنترل |
|---|---|
| Identity | Migration/Source/Target/Schema/Mapping/Build/Run/Cutover Pin شده؟ |
| Scope | Entity/Tenant/Range/Class/Include/Exclude/Claim/Unknown روشن است؟ |
| Snapshot | Position/Isolation/Object set/Concurrent write/CDC boundary ثبت است؟ |
| Mapping | Null/Default/Enum/Type/Precision/Time/Unicode/Key/Delete versioned است؟ |
| Oracle | Transform و Validator استقلال کافی دارند؟ |
| Batch | Range/Gap/Overlap/Checkpoint/Resume/Idempotency/Evidence روشن است؟ |
| Reconciliation | Schema/Population/Field/Aggregate/Relation/Invariant پوشش دارد؟ |
| Validity | Canonicalization/Sample/Tolerance/Pending/Suspended محدود شده؟ |
| Exception | Category/Owner/Authority/Disposition/Repair/Reconcile-again دارد؟ |
| Safety | Rate/Resource/Kill switch/Restore/Incident path آماده است؟ |
| Privacy | Purpose/Minimization/Access/Retention/Deletion/Redaction دارد؟ |
| Cutover | Entry/Freeze/Routing/Catch-up/Go/Rollback/Point-of-no-return روشن است؟ |
| Result | Manifest/Unknown/Limit/Residual risk/Authority جدا هستند؟ |
| Correction | Supersedes و Affected-decision/consumer query وجود دارد؟ |
Pilot سیروزه
| بازه | کار | خروجی/Guardrail |
|---|---|---|
| روز ۱–۵ | یک Entity chain و Scope/Identity | فقط داده ساختگی/مجاز |
| روز ۶–۱۰ | Snapshot و Mapping Contract | Time/Null/Key/Delete |
| روز ۱۱–۱۵ | سه Batch و Resume drill | Checkpoint/Idempotency |
| روز ۱۶–۲۰ | Reconciliation چندلایه | Pending/Suspended صریح |
| روز ۲۱–۲۵ | Exception/Repair/Rollback rehearsal | Provenance + Reconcile again |
| روز ۲۶–۳۰ | Result و Scale/Adapt/Stop | Countermetric + claim limits |
جمعبندی
تست مهاجرت داده از مقایسه Count شروع میشود، اما آنجا تمام نمیشود. Population و Snapshot/Position را Freeze کنید، Mapping و Transform را نسخهدار سازید، Batch را با Checkpoint و Replay Evidence ببندید، Reconciliation را از Schema تا Business invariant لایهبندی کنید و Pending/Exception را پنهان نکنید. سپس Cutover و Rollback را به Authority و Result محدود وصل کنید؛ Job سبز فقط یک Signal است.
سؤالات متداول
آیا برابر بودن تعداد رکوردهای Source و Target کافی است؟
خیر. یک Missing و یک Duplicate میتوانند Count را برابر نگه دارند. Key population، Field/Transform، Relationship، Aggregate و Business invariant را روی Snapshotهای هممرز بررسی کنید.
Checksum برابر چه چیزی را ثابت میکند؟
فقط Equality بایتهای Canonicalشده با Algorithm/Scope مشخص را. اگر Field مهم حذف، ترتیب/Encoding متفاوت یا Transform معنایی باشد، Checksum بهتنهایی کافی نیست. Canonicalization و محدودیت را ثبت کنید.
بهترین روش تست Migration با CDC چیست؟
Snapshot/Full-load position را به CDC start/end وصل کنید، Gap/Overlap و Replay/Ordering/Delete را آزمایش، Catch-up و Pending را بسنجید و Reconciliation نهایی را در Comparison-as-of مشخص اجرا کنید.
آیا برای تست مهاجرت باید داده Production را کپی کنیم؟
الزاماً نه. Test objective و Fidelity/Risk تعیین میکند Synthetic، generated، masked/subset یا دادهی مجاز دیگری لازم است. هر راهبرد Privacy و Utility validation و Policy سازمانی میخواهد.
Migration Pass یعنی Cutover مجاز است؟
خیر. Migration Result یکی از ورودیهاست. Open exception، CDC lag، Application/Operational evidence، زمانبندی، Rollback readiness و Residual risk نیز لازماند و Authority تعریفشده تصمیم Go/No-Go میگیرد.
