标签：这不   相关信息   备份   哪些   排序   解决问题   tom   nic   htm   

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

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）

你只是问题处理流程上的一个环节或者节点，从整个流程上去审视本身的作用，做好该做的事，会更好促进问题解决！
从整个事件流程去观察一个阶段和环节；从一个时间范围去观察共发事件的相互影响；从一个周期去观察时间范围。

3.4 问题闭环

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

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 - 另一种方式

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

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

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

最后， 套用一首现代诗《你见或者不见我》来做结束吧。

《爱处理不处理》

处理，或者不处理
领导就在那里
不悲 不喜

分析，或者不分析
现象就在那里
不来 不去

定位，或者不定位
原因就在那里
不增 不减

沟通，或者不沟通
我的绩效就在你手里
不舍不弃

解决问题
或者
让问题永远跟着你
黯然 交瘁
无言 迷醉 

Anliven - 问题，不解决就拉倒！

标签：这不   相关信息   备份   哪些   排序   解决问题   tom   nic   htm   

原文地址：https://www.cnblogs.com/anliven/p/9123980.html