TS - 解决问题的一些方法

How to resolve the problem?

获取基本的相关信息（后续处理问题的基础） 

在怎样的背景环境下？发生了怎样的问题？

如果无法清楚地辨别或陈述问题的基本信息，那么，此时要面对的将不仅仅是问题本身！

      

       问题的归属（自身的问题？还是外部问题？）

 

       问题现象的描述

       级别及影响（影响层面、时间和资源投入等）--- 对应级别和影响的问题，应由对应级别和影响的人去解决

       当前问题处理参与人员

 

       确认相关版本（Component） 

       发生时间

       发生的阶段：新安装阶段？维护阶段？。。。

       发生前的操作

       设备信息：单方使用？多方共用？。。。

       当前日志收集

       远程登录信息

       。。。。。。

 

问题定性（本质） --- 清楚的辨别和描述问题

产品问题？ --- 需求问题？ --- 情绪发泄？ ......

原生问题？ --- 由其他问题引发的衍生问题？

个别？ ---  共性？

偶发？ ---  频繁？

。。。。。。

 

详细信息获取

报错信息来源与内容

相关配置与流程状态

Open debug level log

网络状态

服务状态

文件相关属性：目录地址、权限、所属关系、格式、链接。。。

。。。。。。

 

常用问题分析方法

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

每一个环节的前提条件是否成立？

每一个环节的配置和数据流是否正确？

依据每一个环节的日志或信息，能够获取怎样的判断依据？

 

      场景区分：针对不同阶段和场景，侧重点不同。

      例如：如果问题发生在全新安装或全新集成阶段，那么问题发生的原因更可能与误操作，误配置，流程错误相关。

            如果问题发生在产品使用阶段，那么要首先确认的问题发生之前的状态、操作信息、业务使用背景、备份配置等。

 

最小环境：从最基本因素开始排查，逐步添加其他因素进行判断 --- 正向分析 --- 业务起点至终点

分解与排除：根据业务原理流程，逐步查找有效信息，排除原因，缩小范围 --- 反向分析 --- 业务终点至起点

 

对比：跟正确的做比较，不同的便是可疑的。纵向---同一事物不同时间段的对比， 横向---同一时间段不同事物的对比

替换：分阶段，逐步调换对象做验证 --- 换内容、换配置、换文件、换网元、换lab。。。

 

重现（在真实环境观察或模拟问题的发生）： get more infos 、 open trace 。。。

模拟（虚拟环境）：simulator --- 一般验证基本流程和配置

 

相似案例 ： 从相似案例中获取有效信息，推动当前问题的解决

 

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

 

。。。。。。

 

无奈的”三板斧“

重置（配置）

重启（服务--》模块--》系统--》组或集群--》硬件平台）

重装（！）

 

过程中

      尽可能保留相关信息（log 、 screenshot、等等），作为后续处理和问题回溯的资料，例如：在相关登陆程序中启用log保留功能

      重大影响及关键操作一定要获得双授权（customer and local）

 

      及时更新状态并知会相关人

更新信息应包括：当前状态、Next action、可能的预计结果、时间点、你的困境和需求、。。。

 

问题处理的过程中，很有可能又引入新的问题出现，此时面对多个问题，应持续关注根本问题，合理排序，逐个解决，如无必要，不建议同时处理多个问题。

低头解决问题， 抬头看问题状态（自己的角色与作用、进展、性质、customer和high level的反馈。。。）

。。。。。。

 

全局关注（whole picture）

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

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

 

问题闭环

Root Cause analysis (RCA) and Escape Defect Analysis (EDA)

探求问题的本质和处理流程的改善。

 

Customer认知

无论是外部还是内部customer，一般情况下，可预先假定他们是“高贵、繁忙，迫切而又茫然”的。
    高贵 -----有了情绪，分分钟就能“Management Escalation”到high level发起challenge
                    保持问题状态适当update频率
    繁忙 -----总是没时间的，极有可能没法及时回复
                    连环E-mail，连环Call；引入high level，持续请求。
                   从第三封邮件开始，明确申明这是第几次请求恢复，并设置默认选项和时间点，  作为以后的凭证。
    迫切 -----无论问题怎样， customer总是希望能够得到最快的解决。
                   慎重承诺deadline。
    茫然 -----通常不具备相关知识背景，或者了解很少很基础的一部分。
                   最初接触到的问题信息和表述，很可能不准确、不完整，未必反映问题的本质。必要时，信息需要亲自重新获取、确认和对比。
                   需要他们做某些操作时，提供详细的步骤！
如果“恰好”遇到一个“耐心好，时间充裕，懂产品”或者"肯钻研"的customer......However,everything has two sides......你懂的。

换位思考

假定此时你是customer，来理解customer的利害点和需求，

受限于信息不对等，理解会存在偏差，不存在“感同身受”，只是尽可能地“设身处地”去了解。

别把自己的感知强加给他人！你的理解可能只是你的主观感受，不是客观的实际状态。

 

情绪控制与沟通协作

人与人的区别比人与动物的区别都要大，个体的巨大差别（知识背景、技能状态、秉性喜好、利害冲突等等），必然会出现难以理解的情况。

对于过程中出现难以理解的事物，只能说。。。尽量避免情绪上的对立。

普通人一旦有了对立情绪这个内因，必然会导致态度上的消极，事物上的拖延，于己于人于事无益！

一个可行的方法：

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

尽心 ----- 愿意花费工作之外的时间和精力。

尽力 ----- 工作时间之内，力所能及地做些额外的事情。

尽责 ----- 基于事情本身完成职责之内的事情。

如果心中有“猛虎”，就把这理解为只是一份工作中的一个task而已，如果task的安排具有合理性（时间、技能、目标、资源。。。），那就遵从这个合理性的安排。

就事论事，简单直接的基于事情本身来开展，基于本职尽责。这是共同协作完成事情的基本要求，同时这也是沟通与协作基础。

万一，那么，如果。。。控制不住内心的“猛虎”，怎么办？------ 凉拌！（换task、换人、换岗位、换公司、创业吧）

 

另外一种应对方式（如果你认为这是对的）：

            1-疑似我的问题，请拿出是我的问题的证据，否则就不是我的问题。。。拒不处理！

            2-第三方的问题。。。不做必要分析，问题透传

            3-是我的问题，但存在技术性问题向”非技术性问题“转换的可能性，于是。。。”其实这不是问题，这是需求，这是体验差的抱怨。。。。。。“

            4-过多引入其他人员。。。人多事情杂，问题仍在处理中

            5-多次频繁索取信息。。。问题本身影响微小，逐渐不再被关注

            6-问题个别罕见。。。没有足够的信息支持分析，请在问题重现时，及时提供更多信息。。。

            7-久拖不决。。。不了了之