一、基本思维方法

分析归纳法：比如报障处理，可以通过对报障进行归类，分成几种类型，分析每种类型对应的处理方法，形成常见报障处理步骤

2W1H法：即what-why-how思考方式，比如新接触系统，可以通过了解这个系统是做什么的，有哪些功能模块？建设这个系统的目标是什么？系统如何实现这些目标，已实现了哪些？来快速熟悉系统。对于需求等其他问题，同理。

复盘迭代法：对于工作中遇到的问题和处理方案，通过复盘的方式进行反思总结，考虑是否有改进地方，应用到后续工作中。比如运维跟踪机制，通过对每周故障的复盘分析，总结运维经验并进行共享，可以更有针对性的改进系统，提升运维稳定性。

二、延伸思维方法

清单法：对于必要做的事情，可以通过列成清单，逐条check的方式，避免遗漏。比如形成日常工作计划清单、代码/sql注意事项检查清单、上线检查清单等。

逐层追问：通过逐层对自己追问的当方式完成问题的分解或原因的探索。

（1）连续问为什么：对于需求模糊、问题原因不清的情况，可以通过逐层追问【为什么】的方法明确信息。比如客户报障，分析为什么出现报障？（是存量数据/交易/批量/累积造成的问题？）如果是XX，分析为什么出现XX问题？怎么解决？临时性的方案？根本性的方案？进行连续追问（交易-变更/历史bug-模块；批量-相关存储过程-数据/模块-相关系统）

（2）逆向推演：对于计划不明确的项目需求，可以使用逐层追问【要实现当前目标，我必须在什么时间节点完成什么目标】的方法，以倒推方式明确各时间节点计划。

（3）头部法则：对于众多工作/需求，不知道从何下手时，可通过逐层追问【这之中最重要的是什么】的方法，明确当前最重要的工作当中 最重要的部分中 最重要的部分.....直至明确当前应当做的事。

第三选择：当需求讨论发生冲突时，考虑我们有没有第三选择？把双方条件列出来，共同思考满足双方条件的方案。当情绪不佳时，思考有没有第三选择？是不是可以选择不愤怒、不烦躁的情绪方式。

联机思考：对于不熟悉/涉及多系统的问题，可以通过与书本、互联网、同事、同领域人员交流讨论的方式，整合提取问题的答案/风险。

三、体系思维方法

细分法：问题可以看成更基本的问题集合，通过不断细分解决问题

系统分析法：从时间和空间两个维度分析问题，构建系统框架。从时间维度考虑，即思考这个主题的发展脉络，形成回路；从空间角度考虑，即通过自下而上、逐层深入探究的方式，建立层级。通过回路和层级形成系统。

通过基本和延伸思维方法的经验累积，利用细分法和系统分析方法，来构建体系。

比如故障的运维，可分为故障发生-故障发现-故障处理-故障复盘-故障改进与预防几个阶段。

故障的发现可细分为几个来源：（1）开发人员自主发现（代码/日志分析等的）（2）监控预警（3）内部/外部客户报障。监控又可以分为几个层级：硬件-网络-系统-应用-业务-端（前端/app等）监控，每个层级都有对应的监控基线，按头部原则每个层级可能还涉及核心部分监控、次核心部分监控、非核心部分监控等。

故障的处理按时间维度可分为故障预判、故障通知、故障定位、故障决策和故障恢复几个阶段。处理故障时以恢复业务为首要原则，故障排查和恢复并行，及时共享故障处理进展。

故障的改进则围绕“如何发现故障”、“如何应急处理”、“如何彻底消除隐患”的思路输出可落地执行的改进项，可从代码质量管控、变更管控、监控完善、应急方案完善、灾备演练等角度细分考虑。

参考其他公司，运维保障体系的发展历程为纯人工-脚本化-工具化-平台化-自动化-智能化运维，自动化的基础为运维各阶段的标准化/流程化/数字化。我们外围团队故障发现阶段的监控目前处于人工+脚本+zabbix的工具化阶段，客户报障还处于纯人工阶段，故障处理大部分处于人工阶段。我认为目前需要从故障发现着手，先尝试对常见故障进行分类和标准化报障模板、处理方案，再结合工具来实现部分报障自动化运维。

四、创造性思维

我认为创新的灵感主要来源于两方面，一是厚积薄发——针对某领域某类问题的长期钻研，经验累积到一定程度后迸发的灵感；二是跨领域的类比，通过找到二者的联系，对思路/模式进行类比应用。具体应用的IT运维，可以从几个角度考虑：

技术类——新技术的引入或原有技术的输出：

比如ATM引入人脸识别技术；OPEN BANK的建设；GAPS输出学校缴费功能等

效率或性能提升类——流程/机制优化或系统本身优化/自动化

比如ecif通过优化索引，提升对公关系人查询效率；ESB通过建设自助报文查询平台、提升测试环境报障处理效率；核心分库提升稳定性等

节省经费或创造收入：

比如通过缩减短信模板，降低短信费用；通过自动化测试，节省人力成本等