浑浑噩噩地工作了几年，从事的内容从最开始的项目交付，然后技术支持，再然后测试与集成，再到目前的时而开发接触浅显代码，时而维护处理客户问题，时而做些测试，难以具体定性从事着什么。
技术上，很难说哪点擅长，有些感触的是某些处理问题的方法和思路却可以通用。简单总结如下，仅作个人记录与改进。
获取基本的相关信息（后续处理问题的基础）
在怎样的背景环境下？发生了怎样的问题？
如果无法清楚地辨别或陈述问题的基本信息，那么，此时要面对的将不仅仅是问题本身！
问题的归属（自身的问题？还是外部问题？）
问题现象的描述
级别及影响（影响层面、时间和资源投入等）--- 对应级别和影响的问题，应由对应级别和影响的人去解决
当前问题处理参与人员
确认相关版本（Component）
发生时间
发生的阶段：新安装阶段？维护阶段？。。。
发生前的操作
设备信息：单方使用？多方共用？。。。
当前日志收集
远程登录信息
。。。。。。
问题定性（本质） --- 清楚的辨别和描述问题
产品问题？ --- 需求问题？ --- 情绪发泄？ ......
原生问题？ --- 由其他问题引发的衍生问题？
个别？ --- 共性？
偶发？ --- 频繁？
......
详细信息获取
报错信息来源与内容
相关配置与流程状态
Open debug level log
网络状态
服务状态
文件相关属性：目录地址、权限、所属关系、格式、链接。。。
。。。。。。
辅助信息获取
https://confluence.int.net.nokia.com/display/Unify60/Get+more+effective+information+from+intranet
常用问题分析方法
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-久拖不决。。。不了了之