明确目标

明确要解决的业务或者技术问题

• 设立标准：怎么样算解决？当前的状况是什么样？理想的状况是什么样？
• 明确问题：当前有什么问题，带来了什么问题

粗估成本收益

• 投入的成本：包括设计，实现，验证，切换
• 获得的收益：显性的，包括功能，效率，故障率，等等；隐形的，包括结构，使用，扩展，等等

对业务和系统有深刻的认知

• 千万注意：什么样是一整套方案，什么样是打补丁方案。前者从根本上解决问题，后者解决表面问题
• 在整体的基础上，确定影响范围

敢想：做正确的事

• 清楚认知当前的本质问题，然后做正确的解决方案
• 针对本质的问题和解决方案，不妥协。考虑拆分项目，分批次实现等方案，来降低复杂度
• 针对细节的问题和解决方案，可以适当妥协。但不能危害整体的目标

确定整体范围

评估影响范围：外部

• 影响哪些对外接口
• 影响哪些外部业务和系统
• 影响哪些外部使用方

评估影响范围：内部

• 影响哪些内部核心数据结构
• 影响哪些内部底层模型
• 影响哪些内部业务和系统
• 影响哪些内部使用方

制定整体计划

整体要有期望

• 有deadline要求：根据deadline倒推计划
• 无deadline要求：推算一个相关靠谱紧凑的计划

成功标准明确

• 明确定义成功和失败标准，能清楚的衡量这些标准，能简单的获得基准数据

广度优先 vs. 深度优先

• 广度代表了对整体的把握，广度意味着优先全面思考问题，不遗漏主要的影响范围
• 深度代表了对细节的把握，深度意味着在某个相对独立的领域的认真细致的梳理，不遗漏任何细节
• 先广度 -> 后深度
• 广度往往不能并行，深度往往可以并行

穷尽多种方案

• 方案往往不止一种，把不同思路的可对比的方案罗列出来，进行比较
• 比较的点要能逻辑说明好坏，或者数字比较优劣
• 讨论并选择最合适的方案，然后执行

制定执行计划

能并行执行

• 合理拆分，接口清晰，标准明确
• 此时再细致考虑资源问题，根据并行度投入资源

设计切换和回滚方案

实现排查问题的机制和工具

设立测试基准和新老逻辑/数字比对基准

• 测试是标准化的，测试组件/case也是标准化的

常见策略

拆分

• 多条业务线，一条一条拆分进行
• 几个步骤，拆分进行；未进行的步骤使用原有方案或者毛招方案

比对

• 同时运行新老两个流程，比对结果是否正确
• 当结果完全一致或者正确率达到一个阈值时，进行切换

适配

• 对使用方来说，接口保持不变，因此没有任何变化
• 把新实现的逻辑适配到老的接口上

概述

业务表征点

• 请求量
• 响应时间
• 数据量

系统表征点

• CPU负载
• 内存压力
• IO压力：网络，硬盘
• 存储压力：数据库，缓存
• 中间件压力：消息队列
• Java：JVM

第三表征点

• 系统监控／报警
• 系统日志

排查方式

排查思路

• 最核心的系统／接口是什么？
• 过去一段时间，bug／故障最多的地方是哪里？
• 门店数／订单量／…翻2/5/10倍之后，最先支撑不住的点在哪里？

排查流程

• 排查范围／排查点
• 排查&发现问题
• 确定问题的影响范围并按优先级排序
• 逐一解决问题

先思考，再动手

• 切忌手太快，发现一个解决一个。但解决的未必是重要问题
• 切忌排查不全面，贸然动手引起联锁反应

思考全面，方案全面

• 灰度策略，回滚策略，分支策略，要全面

逻辑和数据

• 逻辑上是好方案
• 数据上（预评估和后评估）是好结果
• 不断分析badcase迭代优化