it系统运维故障处理流程（非常详细）零基础入门到精通，收藏这篇就够了

最新推荐文章于 2025-11-27 13:57:04 发布

原创最新推荐文章于 2025-11-27 13:57:04 发布 · 715 阅读

19 ·

CC 4.0 BY-SA版权

文章标签：

#运维 #面试 #职场和发展

程序员同时被 3 个专栏收录

1645 篇文章

订阅专栏

计算机

1632 篇文章

订阅专栏

互联网

1347 篇文章

订阅专栏

【摘要】本文尝试借鉴“复盘”的关键内涵，建立一条围绕“确定故障复盘方式、梳理故障应急时间轴、还原故障处置行动、根因分析及经验沉淀、问题及改进措施跟踪、编写故障报告并发布”六个步骤的故障复盘改进方法。

【作者】彭华盛，超过10年金融领域运维工作，期间负责参与企业运维组织、流程、工具的建设，包括多项重大业务系统及数据中心工程性项目实施，数据中心工作流程构建，运维平台规划与研发等工作、多项行业标准编写，参与编写《运维数字化转型》《运维数据治理》、《运维前线》、《变局中的证券机构：数字化转型与创新》等书。

数智万物下，运维组织面临不断变化的内外部环境，不仅要应对每天海量信息轰炸，还需要对信息进行有效思考，沉淀经验转化为能力，推动学习型组织文化。通常来说，学习包括三种：一种是向前人学习，比如看书，吸收前人的归纳总结，获得知识；第二种是周边经验学习，比如向周围的朋友、领先的资讯知识、举一反三经验等学习；第三种是向自己（个人或组织）学习，通过自己的分析、讨论、思考，将自己经验转化为能力或知识。而“向自己学习”，最常见方法就是复盘，即对过去所做事情重新思考、分析，找出影响结果的因素，将好的行为或不足之处进行梳理，形成自己的经验知识，并最终转化为能力。

本文尝试借鉴“复盘”的关键内涵，建立一条围绕“确定故障复盘方式、梳理故障应急时间轴、还原故障处置行动、根因分析及经验沉淀、问题及改进措施跟踪、编写故障报告并发布”六个步骤的故障复盘改进方法。

1、关于复盘

上个月在《3.3.1 构建持续提升的故障管理能力》中，我将故障管理闭环周期分为“故障预防、故障发现、故障响应、故障定位、故障恢复、复盘改进”，其中“复盘改进”是从“总结改进”中改动而来，相比“总结”，“复盘”需要有一定套路和方法，强调客观回顾、持续学习。

我尝试用我个人时间管理例子对比一下总结与复盘的差异。以前我的时间管理相对随意，比如将日常临时性安排登记为任务，不定期反思收获。今年以来，我使用手帐做时间管理，用法如下：每天上班路上登记当天需关注事项，在每天的碎片时间段中将己完成事项标注“done”，下班路上则根据手帐上己完成事项串起一天过程，通过手帐仪式感的例行反思，能持续在每日复盘中收获，比如：

哪些待安排事项没安排好：这类事不一定我自己亲自做，但需要自己提前安排任务，作好计划。

哪些需要提前沟通的事没有做：这类事只需要提前沟通即可减少后续的被动。

哪些工作可以做得更好：针对已经完成的工作。

哪些目标没完成：忘了？未就绪？延续到下一天？暂停？

与预期不符的事背后合理的理由是什么：工作总会有些不顺，关键要调整心态。

相比而言，以前的不定期反思是“总结”，最近的每日时间管理手帐可以归为“复盘”。前者主要是反思总结，后者则在反思总结基础上增加了一些因素：持续性（每天）、有方法（登记目标事项，标注完成）、我（亲身经历者）、串起过程（回顾过程）、收获（影响目标的分析，收获经验）。

可能通过“复盘”一词原意可以进一步抽象复盘关键要素。复盘来自围棋，指棋手在下完一盘棋后，重新在棋盘把对弈过程摆一遍，看哪里下得好，哪里下得不好，以从全局角度重新分析、研讨棋局过程，了解不足与优点，找到更好的经验方法，从而提升棋力。综上，我们可以将复盘归纳为5个要素：持续性复盘（复盘棋局是常规操作）、参与者真实经历（棋手）、描述完整经历（对弈过程）、分析研讨对错（分析、研讨棋局）、转化为能力（收获经验，提升棋力）。

2、关于故障复盘

通常，一个严重的生产故障是多个层面上的连续性保障均失效的结果，比如：架构的高可用、人员应急处置能力、常规预防准备工作、监控发现能力、自动化工具应急能力等。这与海恩法则的描述统一：

海恩法则：一起重大的飞行安全事故背后都会有29个事故征兆，每个征兆背后又有300个事故苗头，每个苗头背后还有1000个事故隐患。由此可见，对隐患、苗头、征兆的忽略，是导致意想不到的安全事故发生的罪魁祸首。（《百度百科》）

海恩法则强调两点：一是事故的发生是量的积累的结果；二是人自身的素质和责任心。站在运维角度，作为业务连续性最后一道防线，可以从技术手段与管理手段进行可用性能力建设。所以，故障复盘是对事前与事中环节复盘，不仅关注引发故障根源性问题，还需要推动应急协同、工作机制、人员能力、预案管理、潜在风险、监控发现、应急工具、架构高可用、上下游系统风险等全方位的分析。区别于运维组织通常主要围绕“根因分析、编写报告、创建及跟踪问题”3个故障复盘步骤，下面我尝试将上一节总结复盘的“持续性复盘、参与者真实经历、描述完整经历、分析研讨对错、转化为能力”五个要素融入进来，梳理一条围绕“确定故障复盘方式、梳理故障应急时间轴、还原故障处置行动、根因分析及经验沉淀、问题及改进措施跟踪、编写故障报告并发布”六个步骤的故障复盘过程。

在分解上面六个步骤前，可能需要关注下面对故障复盘分解的步骤相对理想化，实际情况下由于组织每天都会有大量故障，要求每个故障都进行详细复盘无法实现，组织应该通过管理机制及工具赋能，摘取部分重点关键内容，减少故障复盘手工操作环节，让大部分故障在当天或24小时内即完成复盘，少数重要故障则细化复盘过程。

2.1 确定故障复盘方式

每个故障都是运维团队学习成长的机会，我们不要浪费任何一个故障，要让故障复盘作为故障管理的必要环节。考虑到故障复盘涉及工作量较多，建议运维组织建立多种复盘模板，针对不同复盘模板与参与人员范围来应对不同类型的故障。在模板中定义好：哪些人参加，输出什么，设计/架构/故障预防/故障处置/故障发现等执行情况，是否需要纳入日、周、月、季例会等。

基于明确的判断条件提前制定故障复盘模板，比如针对故障影响级别高低、重复性故障、权益类交易、安全风险等。建议故障复盘采用线上化的管理工具落地，高级别的故障增加一些线下的辅助手段，比如对于故障影响级别高的故障需要跨团队参与分析，包括产品或需求团队从需求或设计角度评估软件逻辑设计角度评估，开发团队从架构或程序实现角度评估，测试团队对功能性与非功能性测试角度评估，SRE从系统稳定性、应急处置效率、应急协同、监控发现、自动化处置等角度评估，运维工具团队从监控、自动化操作、日志等专项角度进行分析。整个故障分析尽量保持透明、公开，让故障参与各方能够客观的参与进来。

除了根据明确条件判断的故障复盘模板，还有一类故障可能风险级别未达到高级别，但是在某方面已存在较大的风险隐患，比如潜在架构性能及容量问题、针对协同不畅、管理流程、操作不当、人员能力、运维工具应用等问题。这类问题容易漏分析或执行跟踪不到位，建议从组织管理团队或故障流程经理驱动，以线上任务方式，指定具体责任人牵头落实复盘目标。

2.2 梳理故障应急时间轴

第一节中，强调了复盘“参与者真实经历、描述完整经历”两个区别于一般总结的要素，将这两个要素应用于故障复盘，第一步是要建立故障应急时间轴，时间轴需要有故障处置的关键时点。为了标准化、线上化故障处置过程，需要将故障处置关键时点进行抽象。在选择关键时点时，故障应急时间轴可以参考业务连续性领域的：MTBF（无故障时长）、MTTI（平均故障发现时长）、MTTK（故障定位时长）、MTTF（平均故障处理时长）、MTTR(平均故障响应时长)，MTTF(平均故障恢复时长)的思路，从故障发生时间、发现时间、响应时间、尝试处置时间、诊断时间、生效应急处置开始时间、故障恢复时间等梳理应急处置的关键节点。通常，MTTI=发现时间-发生时间；MTTR =响应时间-发现时间；MTTK =定位时间-发现时间；MTTF =恢复时间-定位时间。要达成这个目标，要建立线上化的应急处置协同机制，以便上述时间点能够在事中落地客观数据。理想情况下，这个线上化应急处置协同机制可以在一个应急场景工具实现，或能够将多个应急工具中的关键操作行为数据整合在一起。故障应急时间轴是围绕故障应急关键时间点的过程还原，需要关注：客观、在线、量化，这个过程相对容易抽象，适合运维工具团队落地。

2.3 还原故障处置行动

有了故障应急时间轴，下一步是让参与方参与进来围绕应急时间轴还原具体的处置行动，全面复原故障处置行为。比如：

发现方式：谁（机器、IT人员、客服、客户）、什么时候（预防、及时、较大延迟）、什么方式发现（监控、巡检、投诉）等；

响应方式：产品/研发/测试/运维/安全响应情况，监控发现后响应效率等；

跨团队协同：运维团队内、运维与其他IT条线、IT与业务线、公司与客户之间协同是否顺畅；

尝试诊断：故障发生后尝试了哪些诊断动作，是否有效，专家意见是否快速有效；

影响分析：盘中影响分析是否到位，是否有足够数据支持盘中快速判断，是否提前准备关键KPI指标分析；

危机升级：故障处置过程对于应急处置时间超长，高风险事件的危机升级机制是否到位，现场危机组织是否到位；

情况通报：故障处置过程及恢复的信息通报是否及时、准确，话术是否合理；

启动预案：预案是否完整，具备可操作性，事中是否启动预案；

处置方案：尝试诊断中的生效应急处置，或事中准确判断的处置方案是什么；

故障恢复：制定处置方案后，方案的执行过程是否及时，跨团队交付方案是否快速，应急工具是否就绪；

在上述处置过程的还原上，可以考虑关注：能力（专家、预案等）、协同（跨团队）、机制（信息扩散、危机升级等）、工具（监控、日志、链路、数据等）。

2.4 根因分析及经验沉淀

故障复盘是为了将故障处置行动过程进行分析，沉淀经验，转化为团队能力。随着业务的不断演进，系统的数据量不断扩大，技术栈越来越复杂，系统调用链路越来越长，造成信息系统中断的事件的风险场景越来越多，中断事件的频率和种类持续增长，且有相当一部份事件会造成业务中断，可用性问题越来越严峻。在前面《数智万物下，重新思考运维价值》中，用业务连续性事件起因鱼骨图总结了一下影响业务连续性因素：变更问题、维护问题、性能容量问题、操作问题/误操作、容灾/应用架构高可用、应用逻辑缺陷、版本控制、产品或功能设计不足、数据质量、高可用有效性、应急方案、技术保障方案不完善、应急预案缺失、应急演练不到位、问题跟踪不闭环、参数设置问题、配置问题、人员技能不足、流程机制不完善、外部攻击、基础设施异常、数据备份、数据丢失、监控发现及时性、故障处置时效性等，这些因素都可能是引发故障及导致故障影响升级的根因。

在故障复盘中，主要是对故障直接原因进行定位分析，但随着运维复杂性不断提升，只分析直接原因是不够的，运维在应对复杂性能力飞轮中需要更加主动。参考前面提到的海恩法则，故障根因分析需要从技术与管理两个角度进行多维度分析。技术手段主要是分析技术架构的高可用,非功能性需求的实现，运维的可观察性手段是否具备，运维监控工具的故障发现能力是否覆盖，日志等工具对于故障诊断是否有效，运维自动化工具对连续性恢复处置是否就绪等；管理手段则主要从事前预防、事中处置、事后跟踪等多方面分解，比如生产环境管控是否到位，预案是否有效，演练是否到位，对业务、运行的理解能力是否达标，协同是否顺畅等。

2.5 问题及改进措施跟踪

通过故障原因分析得到的多个待改进事项，将纳入到故障改进中，在ITIL中将这个待改进事项定义为问题。针对2.4中提到的问题，通常会给不同的角色分派改进事项，比如：

for故障处置运维团队：加强人员对业务、运行的理解，提升监控覆盖面，加强应急预案管理，加强运行状态数据分析能力，加强运维工具的使用等；

for工具团队：加强工具的运营，提升监控覆盖面与准确率能力，提升日志等异常诊断工具能力，提升自动化工具的使用，提升运维数据分析的平台能力；

for流程经理：完善应急处置过程的协同效率，信息传输及触达效率，完善人员能力、工具平台能力的提升；

for研发：修复程序设计逻辑缺陷，提升系统健壮性，增加日志完备度与监控埋点需求，加强版本管理优化等；

for测试：提升非功能性测试、功能性测试覆盖面等；

for需求/产品：完善业务逻辑设计、功能设计；

for第三方厂商：完善硬件、软件、线路等方面的健壮性等；

建立上述问题只是开始，下一步是对问题的跟踪，需要有专项跟踪机制，比如专项的问题管理例会，问题催办进展与通报，问题与变更闭环，问题关闭的策略等。由于问题跟踪的复杂性，理想情况下问题管理应该与绩效关联上。结合管理机制，还需要建立数据驱动，绩效支持的协同方式来确保障高优先级的问题得到及时解决。在问题跟踪上，建议采用全线上的闭环，打通各关联方的工作平台，并基于线上化的问题跟踪数据进行自动化的催办。

2.6 编写故障报告并发布

最后每个故障都应该要有一份故障复盘报告。这里提的故障报告不限于一份标题为“XXXXX故障分析报告”的文档，实际上如果将前面几个步骤的数据线上化整合，就开始启动了一份故障分析报告。完整的故障报告包括：故障过程、根因、影响、问题及优化措施、故障定责，以及针对个别突出问题的专项分析。通常，ITSM、故障管理系统，或运维专家知识库可以作为故障报告的管理系统，系统最好能将故障复盘过程的时间轴关键时间点、操作内容、影响范围等数字化，减少复盘的操作性工作，并提供方便的报告检索，能够追踪问题的解决情况。

针对故障级别，报告有大报告与小报告之类区别，报告编写过程中最好能建立信息分享机制，以收集跨团队意见并修订报告，报告完成后最好能公开发布，发布不仅是问题的警戒与改进，还包括处理过程优点的公示。针对不同类型故障有不同的发布方式，比如：风险通报、专项例会、跨团队沟通、外部第三方等。

小结

故障复盘改进环节是故障管理闭环周期闭环的收尾阶段，是对事前与事中环节的分析，关注引发故障根源性问题的解决与故障事中处置效能的提升。缺少复盘的故障会重复发生，协同会更加低效，IT人力资源会被故障拖住，影响整个IT价值创造。采用“确定故障复盘方式、梳理故障应急时间轴、还原故障处置行动、根因分析及经验沉淀、问题及改进措施跟踪、编写故障报告并发布”六个步骤，可建立一条从故障中学习的方法。在落实过程中，组织应该通过管理机制及工具赋能，摘取部分重点关键内容，减少故障复盘手工操作环节，让大部分故障在当天或24小时内即完成复盘，少数重要故障则细化复盘过程。

这两年，IT行业面临经济周期波动与AI产业结构调整的双重压力，确实有很多运维与网络工程师因企业缩编或技术迭代而暂时失业。

很多人都在提运维网工失业后就只能去跑滴滴送外卖了，但我想分享的是，对于运维人员来说，即便失业以后仍然有很多副业可以尝试。

运维副业方向

运维，千万不要再错过这些副业机会！

第一个是知识付费类副业：输出经验打造个人IP

在线教育平台讲师

操作路径：在慕课网、极客时间等平台开设《CCNA实战》《Linux运维从入门到精通》等课程，或与培训机构合作录制专题课。
收益模式：课程销售分成、企业内训。

技术博客与公众号运营

操作路径：撰写网络协议解析、故障排查案例、设备评测等深度文章，通过公众号广告、付费专栏及企业合作变现。
收益关键：每周更新2-3篇原创，结合SEO优化与社群运营。

第二个是技术类副业：深耕专业领域变现

企业网络设备配置与优化服务

操作路径：为中小型企业提供路由器、交换机、防火墙等设备的配置调试、性能优化及故障排查服务。可通过本地IT服务公司合作或自建线上接单平台获客。
收益模式：按项目收费或签订年度维护合同。

远程IT基础设施代维

操作路径：通过承接服务器监控、日志分析、备份恢复等远程代维任务。适合熟悉Zabbix、ELK等技术栈的工程师。
收益模式：按工时计费或包月服务。

网络安全顾问与渗透测试

操作路径：利用OWASP Top 10漏洞分析、Nmap/BurpSuite等工具，为企业提供漏洞扫描、渗透测试及安全加固方案。需考取CISP等认证提升资质。
收益模式：单次渗透测试报告收费；长期安全顾问年费。

比如不久前跟我一起聊天的一个粉丝，他自己之前是大四实习的时候做的运维，发现运维7*24小时待命受不了，就准备转网安，学了差不多2个月，然后开始挖漏洞，光是补天的漏洞奖励也有个四五千，他说自己每个月的房租和饭钱就够了。

为什么我会推荐你网安是运维人员的绝佳副业&转型方向?

1.你的经验是巨大优势: 你比任何人都懂系统、网络和架构。漏洞挖掘、内网渗透、应急响应，这些核心安全能力本质上是“攻击视角下的运维”。你的运维背景不是从零开始，而是降维打击。

2.越老越吃香，规避年龄危机: 安全行业极度依赖经验。你的排查思路、风险意识和对复杂系统的理解能力，会随着项目积累而愈发珍贵，真正做到“姜还是老的辣”。

3.职业选择极其灵活: 你可以加入企业成为安全专家，可以兼职“挖洞“获取丰厚奖金，甚至可以成为自由顾问。这种多样性为你提供了前所未有的抗风险能力。

4.市场需求爆发，前景广阔: 在国家级政策的推动下，从一线城市到二三线地区，安全人才缺口正在急剧扩大。现在布局，正是抢占未来先机的黄金时刻。

运维转行学习路线

在这里插入图片描述

（一）第一阶段：网络安全筑基

1. 阶段目标

你已经有运维经验了，所以操作系统、网络协议这些你不是零基础。但要学安全，得重新过一遍——只不过这次我们是带着“安全视角”去学。

2. 学习内容

**操作系统强化：**你需要重点学习 Windows、Linux 操作系统安全配置，对比运维工作中常规配置与安全配置的差异，深化系统安全认知（比如说日志审计配置，为应急响应日志分析打基础）。

**网络协议深化：**结合过往网络协议应用经验，聚焦 TCP/IP 协议簇中的安全漏洞及防护机制，如 ARP 欺骗、TCP 三次握手漏洞等（为 SRC 漏扫中协议层漏洞识别铺垫）。

**Web 与数据库基础：**补充 Web 架构、HTTP 协议及 MySQL、SQL Server 等数据库安全相关知识，了解 Web 应用与数据库在网安中的作用。

**编程语言入门：**学习 Python 基础语法，掌握简单脚本编写，为后续 SRC 漏扫自动化脚本开发及应急响应工具使用打基础。

**工具实战：**集中训练抓包工具（Wireshark）、渗透测试工具（Nmap）、漏洞扫描工具（Nessus 基础版）的使用，结合模拟场景练习工具应用（掌握基础扫描逻辑，为 SRC 漏扫工具进阶做准备）。

（二）第二阶段：漏洞挖掘与 SRC 漏扫实战

1. 阶段目标

这阶段是真正开始“动手”了。信息收集、漏洞分析、工具联动，一样不能少。

熟练运用漏洞挖掘及 SRC 漏扫工具，具备独立挖掘常见漏洞及 SRC 平台漏扫实战能力，尝试通过 SRC 挖洞搞钱，不管是低危漏洞还是高危漏洞，先挖到一个。

2. 学习内容

信息收集实战：结合运维中对网络拓扑、设备信息的了解，强化基本信息收集、网络空间搜索引擎（Shodan、ZoomEye）、域名及端口信息收集技巧，针对企业级网络场景开展信息收集练习（为 SRC 漏扫目标筛选提供支撑）。

漏洞原理与分析：深入学习 SQL 注入、CSRF、文件上传等常见漏洞的原理、危害及利用方法，结合运维工作中遇到的类似问题进行关联分析（明确 SRC 漏扫重点漏洞类型）。

工具进阶与 SRC 漏扫应用：

系统学习 SQLMap、BurpSuite、AWVS 等工具的高级功能，开展工具联用实战训练；
专项学习 SRC 漏扫流程：包括 SRC 平台规则解读（如漏洞提交规范、奖励机制）、漏扫目标范围界定、漏扫策略制定（全量扫描 vs 定向扫描）、漏扫结果验证与复现；
实战训练：使用 AWVS+BurpSuite 组合开展 SRC 平台目标漏扫，练习 “扫描 - 验证 - 漏洞报告撰写 - 平台提交” 全流程。
SRC 实战演练：选择合适的 SRC 平台（如补天、CNVD）进行漏洞挖掘与漏扫实战，积累实战经验，尝试获取挖洞收益。

恭喜你，如果学到这里，你基本可以下班搞搞副业创收了，并且具备渗透测试工程师必备的「渗透技巧」、「溯源能力」，让你在黑客盛行的年代别背锅，工作实现升职加薪的同时也能开创副业创收！

如果你想要入坑黑客&网络安全，笔者给大家准备了一份：全网最全的网络安全资料包需要保存下方图片，微信扫码即可前往获取!

因篇幅有限，仅展示部分资料，需要点击下方链接即可前往获取

优快云大礼包：《黑客&网络安全入门&进阶学习资源包》免费分享

（三）第三阶段：渗透测试技能学习

1. 阶段目标

全面掌握渗透测试理论与实战技能，能够独立完成渗透测试项目，编写规范的渗透测试报告，具备渗透测试工程师岗位能力，为护网红蓝对抗及应急响应提供技术支撑。

2. 学习内容

渗透测试核心理论：系统学习渗透测试流程、方法论及法律法规知识，明确渗透测试边界与规范（与红蓝对抗攻击边界要求一致）。

实战技能训练：开展漏洞扫描、漏洞利用、电商系统渗透测试、内网渗透、权限提升（Windows、Linux）、代码审计等实战训练，结合运维中熟悉的系统环境设计测试场景（强化红蓝对抗攻击端技术能力）。

工具开发实践：基于 Python 编程基础，学习渗透测试工具开发技巧，开发简单的自动化测试脚本（可拓展用于 SRC 漏扫自动化及应急响应辅助工具）。

报告编写指导：学习渗透测试报告的结构与编写规范，完成多个不同场景的渗透测试报告撰写练习（与 SRC 漏洞报告、应急响应报告撰写逻辑互通）。

（四）第四阶段：企业级安全攻防（含红蓝对抗）、应急响应

1. 阶段目标

掌握企业级安全攻防、护网红蓝对抗及应急响应核心技能，考取网安行业相关证书。

2. 学习内容

护网红蓝对抗专项：

红蓝对抗基础：学习护网行动背景、红蓝对抗规则（攻击范围、禁止行为）、红蓝双方角色职责（红队：模拟攻击；蓝队：防御检测与应急处置）；
红队实战技能：强化内网渗透、横向移动、权限维持、免杀攻击等高级技巧，模拟护网中常见攻击场景；
蓝队实战技能：学习安全设备（防火墙、IDS/IPS、WAF）联动防御配置、安全监控平台（SOC）使用、攻击行为研判与溯源方法；
模拟护网演练：参与团队式红蓝对抗演练，完整体验 “攻击 - 检测 - 防御 - 处置” 全流程。
应急响应专项：
应急响应流程：学习应急响应 6 步流程（准备 - 检测 - 遏制 - 根除 - 恢复 - 总结），掌握各环节核心任务；
实战技能：开展操作系统入侵响应（如病毒木马清除、异常进程终止）、数据泄露应急处置、漏洞应急修补等实战训练；
工具应用：学习应急响应工具（如 Autoruns、Process Monitor、病毒分析工具）的使用，提升处置效率；
案例复盘：分析真实网络安全事件应急响应案例（如勒索病毒事件），总结处置经验。
其他企业级攻防技能：学习社工与钓鱼、CTF 夺旗赛解析等内容，结合运维中企业安全防护需求深化理解。