TS

本文是对 解决问题的一些方法内容的改写与补充！

首要的问题

对于发生在线上的问题， 最紧要的事项一定是“以最快最有效的方式解决问题，降低对线上业务的影响”，然后才是深挖问题，探求根本原因，防微杜渐，未雨绸缪。
而对于非线上问题，客观上会有“相对多一点的处理时间、多一些的分析和处理方法”。

1 接触与了解

从总体着眼，从细节入手！

确认基本相关信息是必须执行的首要环节，也是后续处理问题的基础。
如果无法清楚地辨别或陈述问题的基本信息，那么，此时要面对的将不仅仅是问题本身！
不明确和不充分的信息资源，将极大地制约问题处理的效率和效果。

问题的基本信息概括起来，主要包括两个方面：在怎样的背景环境下？发生了怎样的问题？
进一步的细分，可能涉及如下内容：

1.1 问题现象的描述

• 问题的直观现象
• 问题的初始级别
• 问题发生的时间、地点、报告人
• 问题发生的阶段和场景：新安装阶段、实验阶段、生产场景、维护场景。。。
• 问题发生前的操作

1.2 问题的边界与归属

从现象和场景，来判断是自身的问题？还是外部问题？
实质上，这是在确认自身在问题处理中的角色定位：该发挥怎样的作用和达到怎样的效果，由谁来处理、跟进、协助。

如果是自身的问题，那么当前的问题级别和影响是什么？
对应级别和影响的问题，应由对应级别和影响的人去解决，因为这涉及到相应的应急方案措施、资源调动和投入。

如果是外部的问题，那么谁是相关人？需要提供哪些必要的信息？需要进行哪些必要的分析？

1.3 当前状态和进展

确认是自身的问题后，就需要进一步了解问题的详细信息。

- 设备版本信息
- 设备使用信息：单方使用还是多方共用。。。
- 设备相关配置、流程、服务、网络状态

- 收集设备当前日志，并开启Debug级别日志
- 报错信息来源与内容

- 获取设备远程登录信息
- 客户及现场工程师的联系方式

- 已采取的步骤、操作、方案。。。问题状态和现象发生了怎样的改变；
- 当前投入的资源：参与问题处理的人员及角色定位；

1.4 问题定性

根据收集到问题信息，清楚地辨别问题性质，是探寻问题本质的第一步，也决定着后续处理的方向。

产品问题？ --- 需求问题？ --- 情绪发泄？
原生问题？ --- 由其他问题引发的衍生问题？
个别？ ---  共性？
偶发？ ---  频繁？
。。。。。。

1.5 下一步的信息

• 在当前处理状态下，问题的发展趋势；
• 下一步的人力或物质资源的需求；
• 下一步的步骤、操作、方案。。。；

2- 定位与分析

从总体着眼，从细节入手！

2.1 一般性流程

precondition status  -->  configuration & data flow  -->  log&infos flow  -->  troubleshooting flow

• 每一个环节的前提条件是否成立？
• 每一个环节的配置和数据流是否正确？
• 依据每一个环节的日志或信息，能够获取怎样的判断依据？

问题定位和分析的过程，实质上是具体业务流程的“映射”，顺序和步骤大致相同，遵循着业务数据的流向。
每一个业务环节和阶段的日志和配置信息，都是判断的依据。
因此，熟悉业务环节和阶段是问题定位与分析的基础要求。

2.2 常用的定位与分析方法

a. 场景区分

针对不同阶段和场景，侧重点不同。
例如：

• 如果问题发生在全新安装或全新集成阶段，那么问题发生的原因更可能与误操作、误配置、流程错误相关。
• 如果问题发生在产品使用阶段，那么要首先确认问题发生之前的状态、操作信息、业务使用背景、备份配置等。

b. 最小环境与分解排除

• 最小环境法：正向流程分析（业务起点至终点），从最基本因素开始排查，逐步添加其他因素进行判断。
• 分解排除法：反向流程分析（业务终点至起点），根据业务原理流程，逐步查找有效信息，排除干扰项，缩小范围。

c. 对比与替换

• 对比：跟正确的做比较，不同的便是可疑的。纵向，同一事物不同时间段的对比；横向，同一时间段不同事物的对比。
• 替换：分阶段分区域，逐步调换对象，分别验证。换数据、换配置、换模块、换设备、换环境。。。换人。

d. 重现与模拟

• 重现：在真实环境观察或模拟问题的发生，得到更多的信息，验证想法和操作等。
• 模拟：如果没有真实环境，可以建立虚拟环境（模拟器simulator）来验证基本流程、配置、数据等。

e. 相似案例

相似的问题现象大都有着相似的原因。
从前期的相似案例中，可以获取可参考的处理方法，推动当前问题的解决。

f. 试错

条件允许的情况下，有依据地多次尝试，可能会发现新的可用信息或处理方式；

g. 信息搜索

信息不仅来自公司组织内部，也广泛的存在外部空间。

• 常用搜索引擎命令
• Get technical information from the Internet

h. 获得帮助

每个人都是某一方面的菜鸟，某一细节的白痴。
我们的目标是解决问题，在必要情况下，应该及时从他人请求帮助，这没什么可耻的。
可耻的是：有方法有途径来解决问题，但却不去尝试。

• 信息获取途径汇总

3 - 处理与跟进

从总体着眼，从细节入手！

3.1 一些注意事项

• 关注根本问题：问题处理的过程中，很有可能又引入或出现新的问题，此时面对多个问题，应持续关注根本问题，合理排序，逐个解决，如无必要，不建议同时处理多个问题；
• 信息记录：尽可能保留相关信息（log 、 screenshot、等等），作为后续处理和问题回溯的资料，例如：在相关登陆程序中启用log保留功能；
• 获取权限：重大影响及关键操作一定要获得双授权（customer and local）
• 状态同步：及时更新状态并知会相关人。更新信息应包括：当前状态、Next action、可能的预计结果、时间点、你的困境和需求等；
• 自我审视：低头解决问题， 抬头看问题状态（自己的角色与作用、进展、性质、customer和high level的反馈。。。）
• 。。。。。。

3.2 无奈的“三板斧”

• 重启: 根据问题的实际情况，进行业务切换或重启（进程、服务、模块、系统、节点、集群、硬件平台等）；
• 重置：回退到上一版本的配置、回退到默认配置等;
• 重装: 软硬件系统已经彻底崩溃或损毁，重装是无奈的选择，业务短时间无法恢复；

实际上，以上操作都是“灾备方案”的步骤和内容。一个合理的灾备方案，必须备份了数据和配置信息。
在“重启、重置、重装”过程中，通过导入备份数据和配置，有利于业务的快速恢复。

3.3 全局关注（whole picture）

你只是问题处理流程上的一个环节或者节点，从整个流程上去审视本身的作用，做好该做的事，会更好促进问题解决！

• 从整个事件流程去观察一个阶段和环节；
• 从一个时间范围去观察共发事件的相互影响；
• 从一个周期去观察时间范围。

4 - 沟通与协作

4.1 换位思考

假定此时你是客户，从客户的角度来理解利害点和需求。
受限于信息不对等，理解会存在偏差，不存在“感同身受”，只是尽可能地“设身处地”去了解。
别把自己的感知强加给他人！
你的理解可能只是你的主观感受，不是客观的实际状态。

4.2 情绪控制

人与人的区别，比人与动物的区别都要大。
个体的巨大差别（知识背景、技能状态、秉性喜好、利害冲突等等），必然会出现难以理解的情况。
对于过程中出现难以理解的事物，只能说。。。尽量避免情绪上的对立。
普通人一旦有了对立情绪这个内因，必然会导致态度上的消极，事物上的拖延，于己于人于事无益！

一个可行的方法：根据当时的实际情况，来确定意愿层级 ： 尽心、尽力、尽责。

• 尽心 --- 愿意投入工作时间之外的精力和资源。
• 尽力 --- 工作时间之内，力所能及地做些额外的事情。
• 尽责 --- 基于事情本身，完成职责之内的事情。

如果心中有“猛虎”，就把这理解为只是一份工作中的一个task而已，如果task的安排具有合理性（时间、技能、目标、资源。。。），那就遵从这个合理性的安排。
就事论事，简单直接的基于事情本身来开展，基于本职尽责。这是共同协作完成事情的基本要求，同时这也是沟通与协作基础。

4.3 客户认知

无论是外部客户还是内部客户，一般情况下，可预先假定他们是“高贵、繁忙，迫切而又茫然”的。

• 高贵 --- 以客户满意度为最高要求，及时同步问题状态，保持适当update频率。否则，客户有了情绪，分分钟就能“Management Escalation”到high level发起challenge。
• 繁忙 --- 客户的时间是宝贵的，总是没时间的，极有可能没法及时回复和协作。保持谦逊，连环E-mail，连环Call；引入“high level”，继续搞。或者，从第三封邮件开始，明确申明这是第几次请求回复，并设置默认选项和时间点，促成客观选择。
• 迫切 --- 无论问题怎样，客户总是希望以最快速度解决。慎重承诺deadline。
• 茫然 --- 通常不具备相关知识背景，或者只了解基础的一部分。因此，最初接触到的问题信息和表述，很可能不准确、不完整，未必反映问题的本质。必要时，信息需要亲自重新获取、确认和对比。需要客户配合某些操作时，提供详细的步骤。

如果“恰好”遇到一个“耐心好，时间充裕，懂产品”或者"肯钻研"的客户，那么“However,everything has two sides......”，你懂的。

5 - 技术问题闭环

问题得到彻底解决的标志，不是问题现象的消失，而是同样的问题不再出现。
也就是说，要想使问题真正闭环，需要探求问题的本质，明确产生问题和触发的根本原因，制定有效的预防措施，并进一步改善处理流程。
这个过程，通常称为RCA/EDA（Root Cause analysis / Escape Defect Analysis)，简而言之，这是一个“问题复盘”和“制定预防措施”的过程。

如果仅仅止步于问题现象的消失，甚至满足于问题处理完成，忽略了对问题的复盘和根本原因的探求，那么这个“根本原因”将会一直潜伏和等待，直到下一个“时机”制造出“更大的惊喜”。
深挖问题，探求根因，防微杜渐，未雨绸缪，这才是业务运行的长久之计。

假设如下几种场景：

代码问题

• 是否考虑加强“Code review”环节？
• 通过多人专家review、举行review会议、采用自动代码检视工具和框架等方法是否可以有效避免代码的异常？

配置问题

• “配置改动”的授权、审核和操作环节是否足够安全，
• 能否通过“Double Authorization”、“Double Check”、操作前备份配置文件和数据等方法来充分保障？

硬件问题

• 为什么在日常巡检中没有发现？
• 原因是什么（评估指标不合理、检视频率过低、人为疏忽等等）？
• 可以采取哪种对应的改进措施（更新评估指标、提高检视频率、使用自动脚本或工具等等）？
• 备件储备和更换流程是否健全？

测试性问题

• 为什么本应该在测试阶段就应该暴露的问题，结果却没有发现？
• 是测试流程有缺失、测试用例和方法不合理、测试环境有缺陷？

特别注意

在进行“问题闭环”的过程中，有一个最容易误入歧途的关键点，也就是“最终的问题归因”。
根本原因可以是流程欠缺，可以是工具有问题，也可以是信息不准确，甚至是偶发的不可预知因素，但绝不能轻易牵扯到具体某一个人，某一个行为。
简单来说，就是绝不能轻易将“能力不足”、“工作习惯”、“性格特征”等因素来作为根本原因。

如果认定某位员工有着“能力不足”、 “工作习惯有问题”、“性格不适合”等一个甚至几个问题，却又从事重要岗位执行重要操作，那这说明这不仅仅是技术故障，也是管理问题。
换而言之，就是管理层有责任，那么这就超出了“技术问题闭环”的范围。
应该让技术的归技术，让管理的归管理，技术性的问题要对应具体的技术细节和流程，而不是具体某一个人以及行为。

6 - 另一种方式

如果你认为下面的问题处理方式是对的：

1. 疑似我的问题，请拿出充分的证据，否则就不是我的问题。。。拒不处理！
2. 第三方的问题，不做必要分析，直接透传。
3. 存在技术性问题向“非技术性问题”转换的可能性，于是“其实这不是问题，这是需求，这是体验差的抱怨。”。
4. 过多引入不必要人员和事项，人多事情杂，流程长又慢，问题仍在处理中。
5. 多次、长时间的索取不必要的信息，企图以时间来淡化微小问题的影响，迫使客户逐渐失去关注度。
6. 问题个别罕见，没有足够的信息支持分析和定位，请在问题重现时，及时提供更多信息。
7. 久拖不决，不了了之。

面对问题时，如果个体基础能力不足，却企图以抖机灵式的技巧来规避，最终都会将自身推入一个更深的大坑，“昨天总会在明天等你！”。