migration-architect

迁移架构师

等级： POWERFUL
类别： 工程 - 迁移策略
用途： 零停机迁移规划、兼容性验证与回滚策略生成

概述

迁移架构师 Skill 提供一套全面的工具与方法论，用于规划、执行和验证复杂的系统迁移，并将对业务的影响降到最低。该 Skill 将成熟的迁移模式与自动化规划工具相结合，以确保系统、数据库和基础设施之间的顺利过渡。

核心能力

1. 迁移策略规划

• 分阶段迁移规划： 将复杂迁移拆分为可管理的阶段，并设定清晰的验证关卡
• 风险评估： 在执行前识别潜在故障点及缓解策略
• 时间线估算： 基于迁移复杂度和资源约束生成切合实际的时间线
• 利益相关方沟通： 创建沟通模板与进度看板

2. 兼容性分析

• Schema 演进： 分析数据库 Schema 变更的向后兼容性问题
• API 版本管理： 检测 REST/GraphQL API 及微服务接口中的破坏性变更
• 数据类型验证： 识别数据格式不匹配及所需的转换
• 约束分析： 验证引用完整性与业务规则变更

3. 回滚策略生成

• 自动化回滚计划： 为每个迁移阶段生成完整的回滚流程
• 数据恢复脚本： 创建时间点数据恢复流程
• 服务回滚： 结合流量管理规划服务版本回滚
• 验证检查点： 定义成功标准与回滚触发条件

快速开始 — 规划 → 检查兼容性 → 生成回滚

所有路径均相对于此 Skill 文件夹；示例输入位于 assets/ 中，预期输出格式位于 expected_outputs/ 中。

# 1. Generate the migration plan from a spec (copy assets/sample_database_migration.json)
python3 scripts/migration_planner.py --input migration_spec.json --format json -o migration_plan.json

# 2. Check schema/API compatibility — exits non-zero unless fully compatible (CI gate)
python3 scripts/compatibility_checker.py --before assets/database_schema_before.json --after assets/database_schema_after.json --type database --format json -o compatibility.json

# 3. Generate the rollback runbook from the plan
python3 scripts/rollback_generator.py --input migration_plan.json --format both -o rollback_runbook

输出环环相扣：migration_plan.json（包含 phases、risks、estimated_duration_hours）作为第 3 步的输入；compatibility.json 报告 overall_compatibility 以及 breaking_changes_count / potentially_breaking_count。

关卡： 在以下两个条件满足之前，迁移不予批准：(a) compatibility_checker 以退出码 0 结束（overall_compatibility: compatible），或每一项破坏性/潜在破坏性变更均已由负责人书面明确接受；(b) 计划中的每个阶段都存在对应的回滚运行手册。每次 Schema 修订后，需重新运行这两项检查。

迁移模式

数据库迁移

Schema 演进模式

1. 扩展-收缩模式（Expand-Contract）

   • 扩展： 在现有 Schema 旁新增列/表
   • 双写： 应用同时写入旧 Schema 与新 Schema
   • 迁移： 将历史数据回填至新 Schema
   • 收缩： 验证通过后移除旧列/表

2. 并行 Schema 模式

   • 新旧 Schema 并行运行
   • 使用功能开关在两个 Schema 之间路由流量
   • 验证并行系统之间的数据一致性
   • 在有充分把握时完成切换

3. 事件溯源迁移

   • 在迁移窗口期内将所有变更捕获为事件
   • 将事件应用到新 Schema 以保持一致性
   • 支持回放能力，以应对回滚场景

数据迁移策略

1. 批量数据迁移

   • 快照方式： 在维护窗口期内进行全量数据复制
   • 增量同步： 借助变更追踪实现持续数据同步
   • 流式处理： 实时数据转换管道

2. 双写模式

   • 迁移期间同时写入源系统与目标系统
   • 为写入失败实现补偿模式
   • 在一致性至关重要处使用分布式事务

3. 变更数据捕获（CDC）

   • 将数据库变更流式推送至目标系统
   • 迁移期间保持最终一致性
   • 支持对大规模数据集实现零停机迁移

服务迁移

Strangler Fig 模式

1. 拦截请求： 通过代理/网关路由流量
2. 逐步替换： 增量实现新服务功能
3. 退役旧系统： 新组件证明稳定后移除旧服务组件
4. 监控： 在整个迁移过程中跟踪性能和错误率

graph TD
    A[Client Requests] --> B[API Gateway]
    B --> C{Route Decision}
    C -->|Legacy Path| D[Legacy Service]
    C -->|New Path| E[New Service]
    D --> F[Legacy Database]
    E --> G[New Database]

并行运行模式

1. 双重执行： 同时运行新旧服务
2. 影子流量： 将生产流量同时路由到两个系统
3. 结果比对： 比较输出以验证正确性
4. 逐步切换： 根据信心逐步提高切换到新系统的流量比例

金丝雀发布模式

1. 小范围发布： 将新服务部署给一小部分用户
2. 监控： 跟踪关键指标（延迟、错误、业务 KPI）
3. 逐步扩大： 随着信心增加提高流量比例
4. 全面发布： 验证通过后完成迁移

基础设施迁移

云到云迁移

1. 评估阶段

   • 盘点现有资源和依赖关系
   • 将服务映射到目标云的等效服务
   • 识别需要重构的厂商特定功能

2. 试点迁移

   • 优先迁移非关键工作负载
   • 验证性能和成本模型
   • 优化迁移流程

3. 生产迁移

   • 使用基础设施即代码以保证一致性
   • 在迁移期间实现跨云网络互通
   • 保持灾难恢复能力

本地到云迁移

1. 直接迁移（Lift and Shift）

   • 对现有应用的改动最小
   • 快速迁移，后续再优化
   • 使用云迁移工具和服务

2. 重新架构

   • 按云原生模式重新设计应用
   • 采用微服务、容器和无服务器架构
   • 实施云安全和弹性扩展实践

3. 混合方案

   • 将敏感数据保留在本地
   • 将计算工作负载迁移到云端
   • 在各环境之间实现安全连接

迁移的功能开关

渐进式功能发布

# Example feature flag implementation
class MigrationFeatureFlag:
    def __init__(self, flag_name, rollout_percentage=0):
        self.flag_name = flag_name
        self.rollout_percentage = rollout_percentage
    
    def is_enabled_for_user(self, user_id):
        hash_value = hash(f"{self.flag_name}:{user_id}")
        return (hash_value % 100) < self.rollout_percentage
    
    def gradual_rollout(self, target_percentage, step_size=10):
        while self.rollout_percentage < target_percentage:
            self.rollout_percentage = min(
                self.rollout_percentage + step_size,
                target_percentage
            )
            yield self.rollout_percentage

熔断器模式

当新系统出现性能下降时，实现自动回退到旧系统：

class MigrationCircuitBreaker:
    def __init__(self, failure_threshold=5, timeout=60):
        self.failure_count = 0
        self.failure_threshold = failure_threshold
        self.timeout = timeout
        self.last_failure_time = None
        self.state = 'CLOSED'  # CLOSED, OPEN, HALF_OPEN
    
    def call_new_service(self, request):
        if self.state == 'OPEN':
            if self.should_attempt_reset():
                self.state = 'HALF_OPEN'
            else:
                return self.fallback_to_legacy(request)
        
        try:
            response = self.new_service.process(request)
            self.on_success()
            return response
        except Exception as e:
            self.on_failure()
            return self.fallback_to_legacy(request)

数据验证与对账

验证策略

1. 行数验证

   • 比较源端与目标端的记录数
   • 考虑软删除和被过滤的记录
   • 实施基于阈值的告警

2. 校验和与哈希

   • 为关键数据子集生成校验和
   • 比较哈希值以检测数据漂移
   • 对大型数据集使用抽样

3. 业务逻辑验证

   • 在两个系统上运行关键业务查询
   • 比较聚合结果（求和、计数、平均值）
   • 验证派生数据和计算结果

对账模式

1. 差异检测

   -- Example delta query for reconciliation
   SELECT 'missing_in_target' as issue_type, source_id
   FROM source_table s
   WHERE NOT EXISTS (
       SELECT 1 FROM target_table t 
       WHERE t.id = s.id
   )
   UNION ALL
   SELECT 'extra_in_target' as issue_type, target_id
   FROM target_table t
   WHERE NOT EXISTS (
       SELECT 1 FROM source_table s 
       WHERE s.id = t.id
   );
   

2. 自动修复

   • 针对常见问题实施数据修复脚本
   • 使用幂等操作以便安全地重复执行
   • 记录所有修复操作以留存审计追踪

回滚策略

数据库回滚

1. Schema 回滚

   • 维护 Schema 版本控制
   • 尽可能使用向后兼容的迁移
   • 为每个迁移步骤保留回滚脚本

2. 数据回滚

   • 使用数据库备份进行时间点恢复
   • 通过事务日志回放实现精确的回滚点
   • 在迁移检查点保留数据快照

服务回滚

1. 蓝绿部署

   • 迁移期间保持上一服务版本运行
   • 如出现问题，将流量切回蓝色环境
   • 在迁移窗口期间维护并行基础设施

2. 滚动回滚

   • 逐步将流量切回上一版本
   • 回滚过程中监控系统健康状况
   • 实施自动回滚触发机制

基础设施回滚

1. 基础设施即代码

   • 对所有基础设施定义进行版本控制
   • 维护回滚用的 terraform/CloudFormation 模板
   • 在预发布环境中测试回滚流程

2. 数据持久化

   • 迁移期间将数据保留在原始位置
   • 实现数据同步回原始系统
   • 在两个环境中维持备份策略

风险评估框架

风险类别

1. 技术风险

   • 数据丢失或损坏
   • 服务停机或性能下降
   • 与依赖系统的集成失败
   • 生产负载下的可扩展性问题

2. 业务风险

   • 服务中断导致的收入影响
   • 客户体验下降
   • 合规与监管问题
   • 品牌声誉影响

3. 运营风险

   • 团队知识缺口
   • 测试覆盖不足
   • 监控与告警不完善
   • 沟通不畅

风险缓解策略

1. 技术缓解措施

   • 全面测试（单元、集成、负载、混沌）
   • 带自动回滚触发机制的灰度发布
   • 数据验证与对账流程
   • 性能监控与告警

2. 业务缓解措施

   • 利益相关方沟通计划
   • 业务连续性流程
   • 客户通知策略
   • 收入保护措施

3. 运营缓解措施

   • 团队培训与文档建设
   • 运行手册的编写与测试
   • 值班轮换规划
   • 迁移后复盘流程

迁移运行手册

迁移前检查清单

• 迁移计划已审阅并获批
• 回滚流程已测试并验证
• 监控与告警已配置
• 团队角色与职责已明确
• 利益相关方沟通计划已启动
• 备份与恢复流程已验证
• 测试环境验证已完成
• 性能基准已建立
• 安全评审已完成
• 合规要求已核实

迁移过程中

• 按计划顺序执行迁移阶段
• 持续监控关键性能指标
• 在每个检查点验证数据一致性
• 向利益相关方同步进展
• 记录所有偏离计划的情况
• 若未达到成功标准，执行回滚
• 与依赖团队协调
• 保留详细的执行日志

迁移后

• 确认所有成功标准均已达成
• 执行全面的系统健康检查
• 执行数据对账流程
• 监控系统性能 72 小时
• 更新文档与运行手册
• 下线遗留系统（如适用）
• 召开迁移后复盘会议
• 归档迁移相关产物
• 更新灾难恢复流程

工具与技术

迁移规划工具

• migration_planner.py: 自动生成迁移计划
• compatibility_checker.py: Schema 与 API 兼容性分析
• rollback_generator.py: 生成完整的回滚流程

验证工具

• 数据库对比工具（Schema 与数据）
• API 契约测试框架
• 性能基准测试工具
• 数据质量验证流水线

监控与告警

• 实时迁移进度看板
• 自动回滚触发系统
• 业务指标监控
• 利益相关方通知系统

最佳实践

规划阶段

1. 从风险评估开始： 在规划前识别所有潜在故障模式
2. 为回滚而设计： 每个迁移步骤都应有经过测试的回滚流程
3. 在预发布环境中验证： 在类生产环境中执行完整的迁移流程
4. 规划灰度发布： 使用功能开关和流量路由实现可控迁移

执行阶段

1. 持续监控： 在整个过程中同时跟踪技术指标和业务指标
2. 主动沟通： 让所有利益相关方随时了解进展和问题
3. 记录一切： 保留详细日志，以便迁移后分析
4. 保持灵活： 准备好根据实际运行表现调整时间计划

验证阶段

1. 自动化验证： 使用自动化工具进行数据一致性和性能检查
2. 业务逻辑测试： 端到端验证关键业务流程
3. 负载测试： 验证系统在预期生产负载下的性能
4. 安全验证： 确保安全控制措施在新环境中正常运行

与开发生命周期集成

CI/CD 集成

# Example migration pipeline stage
migration_validation:
  stage: test
  script:
    - python scripts/compatibility_checker.py --before=old_schema.json --after=new_schema.json
    - python scripts/migration_planner.py --config=migration_config.json --validate
  artifacts:
    reports:
      - compatibility_report.json
      - migration_plan.json

基础设施即代码

# Example Terraform for blue-green infrastructure
resource "aws_instance" "blue_environment" {
  count = var.migration_phase == "preparation" ? var.instance_count : 0
  # Blue environment configuration
}

resource "aws_instance" "green_environment" {
  count = var.migration_phase == "execution" ? var.instance_count : 0
  # Green environment configuration
}

Migration Architect 技能提供了一套全面的框架，用于规划、执行和验证复杂的系统迁移，同时将业务影响和技术风险降至最低。结合自动化工具、成熟模式和详细流程，组织能够自信地开展即使是最复杂的迁移项目。