整顿的一份对于线上故障的排查处理教训汇总，不谈具体的案例，只是一些思路和教训。

线上故障是一件让人很“缓和”的事件，之所以用缓和这个词，是因为临时找不到更好的词汇形容遇到时的心态。

对于运维人员来说，呈现故障，可能意味着: 尽职、麻烦、质疑、加班、绩效、无尽的报告等负面词汇，但也意味着: 机会与挑战。前者大家都好了解，后者也是很重要的，为什么呢？

故障的机会与挑战

一、有一部分故障是大家都没有预料到的。

集体对故障的产生是不必担责的，只须要善后就能够这种。

比方机房忽然断电了这种大故障，复电后各种故障就呈现了，开不了机、服务启不起来、启动程序又不对、配置丢了、网络不通、数据异样等等。

这种状况就十分锤炼人啦，只有呈现过一次，个别你之后就会对此我的项目的全局把握比拟清晰了，并且个别遇到这种大局面，也正是展现你台下十年功露脸的最好机会，但可遇不可求。

小故障当然也有学习的价值，遇到得越多，对教训的晋升和当前对问题的全面剖析能力都有帮忙。

二、有一部分故障是集体操作失误导致的。

咱们常常说，人总是会犯错的嘛，但这样喃喃自语说多了后就会让人产生懈怠、忽略，经验或集体导致故障后，成长更快。

说一个小故事，我在之前一个项目组时，简直每个人都有造成过线上故障，于是一旦新人来后，我都会笑着给新共事说，不要怕故障，咱们都等着看你体现啦！

一般来说大家的心态都是这样的: 刚接触时(小心翼翼)，一段时间后(肆意妄为)，在触发故障后(后续做事会不盲目地思考影响面，对小事很审慎)，心愿新入行的同学们早日迎来本人的专属故障而后冲破到第三阶段吧！

三、不破不立。

老板和业务方个别对运维的次要诉求就是稳固，平时这也不让动、那也不让动。

本人发现个隐患、提出想被动修复，个别失去的回答有: 写个计划研究吧、节后再看看、你找谁再确认一下、有空大家再开会讨论、下期我的项目再搞吧等等等。

但如果是故障期间，你说不这样搞就复原不了、或者不搞就算复原了也保持不住一天，大家就会空前的反对你。

我很早前实习做网工的时候，办公室接入有 4 条电话线，有 2 条不通，但交换机上和房间内的各种走线太乱基本找不出线来，常常有投诉，但真要去拆开理线时大家又不配合。

某天我切实气不过，于是把几条线都轻轻拔了，大家各种反对帮助，于是很快就理顺了那一坨网线和电话线，美滋滋~。

当初想起来当然还有更失当的方法，也必定不会倡议谁被动这样干。但如果是故障曾经不可避免产生了，那能争取一下还是争取一下吧。

如何正确的面对故障

故障的产生是不可避免的，依据墨菲定律，有可能产生就必定会产生。本文所说的故障，次要是指计划外事件所触发的故障，一般割接变更窗口工夫内触发的问题个别不算作故障。

次要是为了说一下对于故障须要留神的中央和倡议做的一些事件。

本文就按个别的工夫线来走，粗略分为这三个阶段：

1. 事先: 还未产生，可能存在隐患，做一些筹备工作；
2. 事中: 故障开始啦！次要是做一些排查、剖析、解决工作；
3. 预先: 故障曾经解决啦！做一些善后事务。

阶段一：故障产生前

熟话说有恃无恐嘛，做足筹备是必须的，这一阶段次要内容就是做筹备工作。

一、惯例筹备事项

1. 被动巡检

包含例行巡检和突击巡检，重点是理解零碎以后是否存在问题。

很多中央的巡检曾经变成了很随便的模式了，要么就是给个万年不变的脚本让一线人员上机去跑一下、生成个空报告，或者罗唆就外包进来让一些看似业余的厂商的实习生对一些通用中间件啥的来走个过程。

集体感觉此阶段很重要，应该由外围专家团队来进行，太忙的话一季度或半年一次总行吧。

2. 监控零碎

监控零碎的三个次要作用:

1. 一眼看过来能确认以后是否有故障，并确定故障影响范畴；
2. 记录故障中各组件异样的产生工夫、指标的稳定状况，以便预先关联剖析；
3. 监控告警不分家，告警能无效告诉到人很重要。

3. 日志零碎

肯定要有集中化日志零碎，将各个主机、组件的日志后会集到一个中央进行查看。

否则排查时，开十几个窗口到处找日志看就很低效和麻烦了，而且集中起来后一旦什么组件因故障不吐日志了，也很容易确定。

如果临时没条件，最次也要将所有的文件日志同步到一个中央来，比方集中的 syslog 服务，ELK 日志收集等都能够思考。

4. 隐患排查

1. 通过对架构进行剖析，评估可能存在的故障点。
   关键设备的性能有余、设施老化等显性的隐患；

   配置寄存在易失性缓存外面，共享资源隔离水平不够，全流程波及的网络节点过多等隐性隐患；

   监控零碎本身的可用性，告警形式和门路是否繁多，如果监控零碎挂了，或告警门路断了呢？

2. 业务剖析，每次特殊性业务发展前进行评估。
   年初大促能不能顶住，新增接口的性能状况，数据迁徙时是否在规定窗口期间实现，新增的数据空间够不够等。

二、准备动作（针对故障的筹备工作）

1. 人员调配

按各自的职能和代表立场进行调配，搭配出一个最佳人员合作名单，个别的人员分类形式有：

1. 一线人员: 最相熟我的项目环境的理论保护人员；
2. 二线专家: 最相熟某组件或架构的人员，最好每组件或环节要定出首要负责人。
   比方测试、开发、产品、数据库等都须要推出一个第一联系人，防止推诿；
3. 小组指挥: 团队 leader, 经验丰富，能过滤烦扰信息、协调小组突击、分割各方声援的人员；
4. 总指挥: 最能拍板、牌面最大、谁都能协调得动的人员，个别是大小 BOOS；
5. 内部人员: 各路相干人员，如厂商专家、合作伙伴、上下游业务零碎、对外客服或公关，还有其余一些能出力的人脉。

集体感觉，这两头最要害是负责“路由”角色的人，一是能不能隔离内部的烦扰信息，并且把有价值信息带进来，二是能将切实有效的计划传递下来给领导去拍板很重要（有些影响大的措施，很多人只能私下说，却不敢公开说）。

2. 故障分级

先有一个共识性的规范，确定在故障产生时各方须要投入的资源，不至于“杯弓蛇影”又或者是“狼来了”。

常见的分法: 个别故障、重大故障、重大故障，小、中、大，I 级、II 级、III 级、IV 级。

分类根据：

1. 按影响水平来分：业务全副中断、业务局部中断、用户感知较小、用户无感知；
2. 按未复原工夫来分：10 分钟都没解决，30 分钟没解决，1 天没解决；
3. 按须要染指的工夫分：须要 24 小时内响应，须要 10 分钟内响应，须要即时响应；
4. 按须要染指的人员级别分：至多要辨别是否须要大 BOOS 染指吧。

级别的动态变化：

1. 刚产生时，会依据景象及预计须要投入的资源先长期定一个级别；
2. 处理过程中如果有其它新增变量，如较长时间都还未解决，又或者引发多米诺骨牌了，就须要将级别进行晋升；
3. 故障处理完毕后，最终通过综合剖析，依据对整体的影响水平，再对级别进行定性。

其它注意事项：

1. 什么级别触发什么动作？
2. 什么状况故障须要降级？
3. 不同级别对应不同的投入资源。

3. 应急预案

预案的要点：

1. 针对最可能产生的事件：一线人员、开发人员、架构设计人员 这些应该是最分明的人；
2. 针对最不能接受的事件：秘密数据丢了、透露了，数据库、缓存崩了，登录零碎崩了这些；
3. 长期事件：大型流动前、大革新前、大领导来访、大客户试用等等；
4. 针对未知的事件：为防止不知所措，总得有个万金油的角色和小组来先长期顶一会儿。

4. 工具箱

常用命令汇合、罕用 SQL、长命令，罕用小工具、脚本、密码本、通信录、业务架构图、网络拓扑图、设施地位表等等放在一个不便的中央。

常常产生的一些难堪事件:

1. 一大长串命令或 SQL 敲错几个字符；
2. 几个帮助人员围着操作人员看他缓缓敲键盘干着急，巴不得推开他本人上；
3. 筹备的脚本或命令一执行，发现服务器上没这个命令，要么现装、要么还得传上去；
4. 某主机、数据库、零碎登不下来，明码找不到、又不晓得谁有；
5. 软件不晓得装在哪，或者目录下有多个实例不确定是哪一个；
6. 间断关上十几个日志文件都没有用的内容；
7. 紧急去到机房，半天不能找到设施在哪；
8. 筹备打电话分割外援或告诉谁，才发现没有存手机号码，一问周边人都没有，到群外面喊半天对方也没看到。

5. 牢靠的环境

电脑不牢靠，关键时刻开不了机、软件打不开、键盘鼠标又坏了，这些事件工夫长了就必定会遇失去。解决办法:

1. 公司借用共事电脑；
2. 家庭备用一个老电脑；
3. U 盘或移动硬盘放着常用工具集；
4. 弄清楚家左近最近的网吧路线。

网络要么慢、要么卡、要么罗唆连不上。解决办法:

1. 牢靠的公司网络，牢靠的家庭宽带（南电信北联通）；
2. 手机双卡 (挪动 + 电信 / 联通) 随时开热点或切运营商；
3. 备用网络，隔壁公司、楼下小店、左邻右舍；
4. 与机房的共事或机房值班人员平时多熟络一些，要害时候能帮你按一下电源，再熟一些可能顺便就帮你解决了。

6. 合作形式

大家提前说好，优先用什么形式配合，省得配合上呈现问题，个别规定：

1. 在公司的相干人员都抱上笔记本就近坐到一起来，最好能霸占住一个会议室；
2. 近程则肯定要拉一个在线会议，次要人员操作时投屏，非次要人员不谈话时静音；
3. 内部专家电话接入时，肯定要免提扩音，防止转述时呈现歧义(个人经历过此教训)；

4. 在长时间排查解决时，要有一个行政协调人员，个别是我的项目领导或现场负责人负责。

   负责打饭、订饭、泡面、协调会议室、上报进度等辅助工作。

   （个人经历，某次众人集中排查到深夜，我忽然有了一个点子，须要 A 配合，后果他去泡面了，A 回来后正要动工时，须要配合的 B 又去泡面了，最初等人齐多耗了 20 分钟）

7. 演练

比拟惯例一些的就是生产环境切换演练和平安演练了，再降级一步就是测试环境内专家出题进行演练，终极形式当然就是生产环境进行破坏性演练了。

阶段二：故障事中

故障解决的根本流程：上报 -> 疾速复原 -> 排查 -> 处理 -> 察看确认。

1. 上报

上报和抢修应该是不抵触的。

先报再查很有必要，常常遇到一些共事发现故障了，认为须要先察看一下，要收集一些信息后才晓得上报时如何表述。

我是感觉没必要，棘手一个电话，或发个音讯，说一句“以后工夫，发现 XX 景象，疑似 XX 故障，速声援”，并不耽搁排查。

先上报以便疾速初步定一个故障级别，而后事中每隔一段时间或进行要害操作后，也应该上报一下。

2. 疾速复原

线上问题应先求疾速复原，再去剖析起因或根治措施。

我也遇到过很屡次故障，一群人缓缓排查剖析，找出一个解决办法给领导或客户，拍板后就做，而后再看有没有成果。

其实这种形式很不好，就如同原本就有主备环境，呈现故障的时候，先探讨 10 分钟确认是否有必要切备机，一样很难堪。

备机难道不应该是随时可切的吗？如果不能随时切换那就阐明这不是合格的备用环境。

有人会说，我都没有排查，不晓得问题起因，拿什么去解决呢？万一切换后也没成果怎么办呢？

所以疾速复原这一步是否进行的要害就靠预案了，良好的预案应该标注有：A 景象对应 A 操作，B 景象对应 B 操作。

一线或应急团队的人员只有相熟预案，很快就能确定下一步该做什么。

有人可能又会问了，那要是把可能产生的每种景象都列出一个操作来，几百上千条谁能记得住？翻目录都得 2 分钟吧。

但理论状况下，应急操作最多也就三五十条，一是因为很多景象都能够用同一个办法去解，二是内容再多就须要分工了。

比方我之前所在的我的项目，如果不是业务量的问题，那最通用的也就三板斧，先回退、切备环境、再切数据中心。

对于切换：

1. 切换还有助于隔离故障现场，预先剖析也不便；
2. 要是切换也不能解决问题，那至多也排除了很多问题是吧；
3. 如果一开始就能够确定起因，修复起来比切换代价小，那当然还是举荐疾速修复。

3. 排查

排查流程次要也就两个点：收集信息 -> 剖析

故障排查注意事项

1. 优先进行最不便最快捷的查看形式。

   那种须要去执行简单命令、等一会儿能力出后果的慢动作能够放前面去操作，或者由其余共事并行去做。

2. 收集到的信息更多地用于思考排除问题。

   收集到的信息既要思考问题可能在哪，又要用于排除问题应该不在哪。

   比方呈现未知故障，先关上网站首页，能关上则入口一侧没问题，打不开多是入口节点或链路的问题，从而放大了排查范畴

3. 留神人的局限性

   首先是要确保参加排查的人员对这一块内容相熟，而后是小心他太相熟了。为什么这么说呢？

   因为人总是会偏向去做和置信本人相熟的事件，比方忽然数据库连不上了：

   开发人员偏向于去剖析代码，看看是不是如逻辑问题导致的线程或锁不开释等，DBA 偏向去排查数据库本身，主机运维第一工夫会去看系统日志和性能监控数据，网络运维第一工夫想到的是登交换机看端口状态、流量、抓包啥的。

   但团队里不是所有人都同时在线的，如果此时就一个人在值班，恰好他排查时又发现了一点和本人特长相干的可疑点，可能就会带偏大家。

我以前就常遇到这种事件，故障排查时某人说我发现起因了，约 1 分钟能解决，咱们舒了一口气，开始配合，1 分钟后景象还在，一会另一人又发现起因了，改为配合他，这样重复几次才真的找到故障起因。
所以在排查时要综合思考意见，多个方向和措施并行冲破。

4. 排查前要先发问

一问：哪个节点？

有问题的是什么货色，某个实例或某一类实例、某一类业务？

二问：什么范畴？

定位到某个实例、某个主机、某个集群、某个核心

三问：什么水平？

量级变动，如 CPU 增了多少，网络慢了多少，业务量增或减了多少。一般来说，如果业务量没有超过历史最大峰值，则大概率不是本身性能问题导致。

四问：什么工夫？

是否是业务高峰期，是否是要害定时工作执行的工夫，是否是在常见的变更日（前公司集中在星期二和星期四进行变更）。

五问：是否有什么人工例行打算遗记去做了？

如: 域名续费、https 证书到期更换、明码过期、手工迁徙数据、云实例或宽带到期续费、忘充电费(真有，我在第一家公司时自建的小机房用的是民电，行政忘了去充电费间接就停电了)。

加密证书或受权过期，当初很多证书都是有无效工夫的，比方 https 证书个别一年一签，如果没有主动更换机制很容易忘。

给上下游的或上下游给的自签证书，个别都是设置 5 年 10 年，尽管很长，但也是会到期的。

六问：前后都有什么动作？

1. 本人零碎的业务和环境变更；
2. 上下游及周边业务零碎的变更；
3. 底层设施变更，如网络设备和策略、存储设备、云或容器平台等；
4. 故障产生后其他人都进行了哪些操作。
   用于排除了有效修复措施，记录一下或者一会儿还要进行回滚。

七问：景象有什么法则？

比方每 5 分钟利用卡顿一下，CPU 使用率稳定起伏有无规律，每天几点固定呈现，做某某操作必然触发等法则。

八问：是否重现？

考虑一下测试环境是否也能重现。

九问：最近有什么内部事件？

• 流动事件: 上游有无流动，或者上游为了应答上上游的流动调整了什么；
• 突发事件: 忽然暴发的病毒、破绽，微博上的一个梗，XX 门，负面舆论，挖断光纤、顽劣天气、地震等；
• 行政事件: 例如因为行政起因要求限期整改但告诉没有送到无效负责人。

5. 先靠教训排查，再靠数据排查

   教训排查：最理解这个零碎的人，现场人员、开发人员、产品应用人员，他们可能看一眼就晓得问题在哪了；

   数据排查：就是先把曾经提供的数据都看一遍，而后通过执行一些动作获取一些数据，通过数据进行剖析。

6. 通过数据排查时

   须要的数据

   1. 各种监控指标数据
   2. 各种日志
   3. 业务数据，比方数据库的交易笔数变动
   4. 相干人员操作日志
   5. 须要被动执行一些动作能力获取的响应数据

   根底的数据分析办法

   1. 将失常和异样进行比照，例如把之前失常的监控图表和以后故障点的图表，重合起来看看看差别是什么。
   2. 关联剖析，剖析多个故障之间存在的关联剖析；
      比方主备机房连贯数据库都报网络谬误，那就阐明跨机房网络应该没问题；
      又或者故障投诉曾经找上门，但却没有收到告警，就可能是网络问题导致告警发不进去了。
   3. 排除法：某某指标失常，就证实不可能是某几类起因。

7. 无奈定位问题的故障该如何解决？

   其实只有不能很快就定位问题，个别也都是这样几板斧先长期解决着。

   1. 服务降级，不提供有异样的服务
   2. 紧急扩容，利用扩容解决资源使用率高的问题
   3. 回退版本，不能迅速确定是否和新版本有关系，就先做版本回退
   4. 切换备节点、备集群、备核心

4. 处理(正式开始解决)

1. 备份和保留原现场

   将零碎以后状态信息或环境变量记录一份，须要批改的配置文件和数据也拷贝一份，以不便验证有效时进行回退，以及预先写报告时做为资料。

   然而很多人其实都没有这样的习惯，要么是的确忘了，要么是赶时间感觉没必要，要么是感觉信念满满感觉一把能成，这样必定是不太好的。

   但比方服务启动异样，要来回改很屡次配置文件，每次操作前都手工备份一下很耽搁效率的，那有什么好的方法吗？

   解决办法当然有:

   1. 有定时备份工作，定期主动对配置文件做备份；
   2. 全局配置文件，比方搁置 git 上，每次都从 git 上改，就不必独自去备份了；

   3. putty、XSHELL 或 CRT 都是能够记录屏幕内容至文本文件的，把自动记录日志性能开启。

      当前任何时候改线上配置时先 cat 一下文件，只有内容在屏幕上呈现过就行，要复原时从日志文件外面去找，并且预先看看本人的操作记录也能够很好地梳理分明处理过程；

      当然 windows 也能够应用自带的 psr 或者其它录屏工具录着，有恃无恐。

2. 验证

   现实故障解决个别都是“收集信息 -> 假如剖析 -> 验证 -> 施行”，条件具备就应该先验证再施行，没有条件的话多集体一起讨论一下也行。

   应该防止“忽然想到啥，就立马施行”，如果故障感知不显著且工夫容许时，最好是能先在测试环境验证一下再上生产操作。

   我举以前遇到一个例子:

   某次线上故障，剖析了一会儿失去了正确的解决思路，但操作起来要几十步，次数多、命令长、两头还须要距离期待什么的。

   于是我共事就决定写个脚本，次要步骤独自列出来执行，反复步骤做成循环执行，这样的想法是很好的。

   为了赶时间就间接在生产服务器上写了一个几十行的 shell 脚本，但真执行上来，就出小事了。

   先是 shell 脚本的局部行语法不对，导致局部内容执行了，局部没执行，而后发现局部文件门路不存在 (因变量起因)，再发现这几台服务器环境其实是有差别的。
   完了，于是更大的麻烦呈现了。

   所以劝大家有条件还是每步进行一下验证为好。

3. 处理时的重点

   • 快，能批量执行就批量执行，能应用一键脚本就应用一键脚本；
   • 关注每一步的执行后果是否合乎预期；
   • 最好操作时旁边有集体看着一下，一是能够防止误操作，二是能够帮助公开进度。

察看确认

确认是否真的复原了，如果没有复原，那就再回到“排查 - 修复”阶段。

故障中期的其它要点：

1. 有预案的先拿出预案来，疾速确定是否能够靠预案进行；
2. 防止单独排查，排查和处理时及时将有用音讯告诉进来，踊跃申请内部的技术和行政反对；

3. 须要判断以后景象是否为最重大水平，有可能你发现的只是苗头，更坏的状况行将呈现。

   例如: 备份服务器故障，导致主库的数据未能及时迁徙走，2 分钟后主库就要满啦~

阶段三：故障前期

当然不是就这样简略的完结啦~，苦楚才刚刚正式开始啦~

要点：

1. 确认真的复原了，不要再被打脸啦；
2. 复盘，至多要压服本人吧，起因、过程、工夫线须要理分明；
3. 善后工作: 可能要继续很长时间。
   比方数据的导来导去，长期顶上的设施和组件、改了的配置都要继续地进行察看，随时筹备重启服务啥的；
4. 影响面、影响水平、损失等数据确认；
5. 整改打算，要确认可行、指标不要太高，最好还能触类旁通。
   趁这个机会把其它一些不合理的中央也提出改良一下，毕竟不出故障时有些事件是不容易推动；
6. 汇报，提前想好各种刁钻问题的应答措辞。

其它注意事项：

1. 庄重的预先模式

   比方误操作，尽管不肯定要进行什么实质性的处罚，但开个小会外部检讨一下还是有必要的，不然不仅当事人本人不器重，其余共事当前也会不器重。

   （PS: 咱们这尽管不做检讨，但默认故障之后的“故障报告 + 几十次批改 + 十余次的故障报告会”都须要当事人主导，也相当于脱了层皮。）

2. 有产出

   既是集体的教训积攒，也是公司的常识积攒，对新人培训及相熟环境很有帮忙；
   积攒到肯定数量和工夫后，针对 top3 的故障进行根治；
   对欠缺日后的各项应急预案、监控体系做为输入资料根据很有帮忙。

好了，基本上惯例的故障解决流程就完结了，说一些其它相干内容吧。

常见故障整顿

集体在这几年常遇见的以及一些常见的故障类型梳理：

1. 硬件和网络:

硬件宕机、须要停机进行的配件更换(个别是磁盘、内存)、UPS 坏了、机房空调坏了、机房进水、机房缺水。

网络个别就是交换机端口坏了，网线接口松动，谬误配置导致网络造成了环路，网络设备外部零碎有 BUG，ARP 表不够，网络黑白名单、ACL 白名单等等。

（PS: 这个机房进水和缺水还能真能遇得上，去年郑州暴雨，机房进水不就产生了吗，机房缺水 (短少洁净的空调用水) 也产生了。）

2. 数据库:

1. 误操作删除或批改了数据；
2. 高峰期进行 dump/Load 或跑大 SQL 影响了性能；
3. 在线 DDL 操作影响了性能；
4. 程序 bug 导致事务长时间未提交，线程越来越多；
5. 各种奇怪的锁；

6. 网络存储的性能问题。

   网络存储只有不是独占就很可能呈现被别的零碎争用资源导致的性能问题。

   尤其留神 NFS。

3. linux 零碎:

个别当初操作系统都比较稳定，硬件不出问题的话开机 10 年都没有啥问题。

我之前保护的设施，5、6 年没有重启过的十分多，只有正确配置好刚上线时不出问题，那就很难出问题。

能呈现的主机系统故障，少数是人为导致的。常见状况：

1. 改了要害配置

举个我以前的例子，甲方给的平安加固手册要求把 passwd 文件通过 chattr 加只读权限，又要求明码 3 月主动到期，并且不容许 root 用户近程登录。

这样做的成果是什么呢，平安加固做完了，过后没啥问题。

3 个月后某天明码到期了，普通用户登录时就提醒要批改明码，输出新密码又提醒没有权限，想改权限呢又登录不上主机，死循环了。

过后我是怎么解决的呢？我轻轻潜入机房(正式流程太长，紧急流程又分割不上要害人，机房在同一栋楼)，推个显示器逐台批改。

2. 应用程序影响

CPU 使用率高、负载高、内存应用高、磁盘应用高，基本上和主机操作系统没啥关系，优先排查利用。

例子: 某次发现一个接口调用特地卡，于是 ping 主机发现提早特地大 (上千 ms 提早)，于是找网络的人员排查，许久没后果。
又找主机的人排查，发现 CPU 负载特地高，排查许久发现负载高的起因竟然是内存使用率高，内存高是因为 slab 外面的 dentry 项太多。
绕了一大圈最初回来发现是还是因为业务程序有 bug，有个性能会高频创立关上随机文件名导致。

3. 的确存在的一些零碎 BUG 或机制导致(概率很低)；

比方以前应用 el5 时 iptable 的 ip_conntrack 链路跟踪表总是打满而后回绝连贯，改了配置后一重启 iptable 就复原原值，遇到几次才发现。

又比方内存的应用机制问题，明明还有残余内存就应用 swap 了。

4. 软件:

个别多是线程透露、内存透露、连接数太多、日志吐太多、程序 BUG。

5. 安全类：

前几年有个通过 java 中间件 weblogic 的反序列化破绽进行挖矿的事件，原理就是利用破绽先攻进来，杀死全副 JAVA 程序，并下载近程的一个程序进行挖矿。

咱们过后的客户是个国企，出网拜访都须要网络侧开指标白名单的，所以没有真的挖上矿。

但这个 java 程序总死咱们却找不到起因，一开始没往攻打这方面去想，总以为是不是本人程序哪有啥 bug，什么回退版本、改代码、抓包剖析啥都做了也没成果。

直到几天后我把一段非凡的痕迹放到百度上一搜，简直惊掉了我下巴，竟然还能真遇上攻打，长期做了个 URL 黑名单而后再降级补丁。

所以遇到灵异事件时，最好也先想一想是不是攻打导致的，还有留神 DDOS 攻打也是常有的。另外羊毛党也要防一下的。

其它要点

故障的责任算谁的？

1. 你提前发现隐患并提出来了，前面即使呈现了你也不会是主责；
2. 人员误操作那就别多解释，认了；
3. 非人员误操作，那就个体担着，如果有可能就推给厂商(拿钱当然得背锅)；
4. 治理也是口锅，什么都能够放，啥故障对内都能够说后续增强治理改良，先有态度和退让。

一份无效的故障报告因素：

1. 故障简述：三五句话阐明这次故障事件；
2. 故障过程：什么工夫产生了什么，做了什么；
3. 故障影响：对业务造成的影响，量化指标。
4. 比方影响了 XX 工夫至 XX 工夫的多少笔交易，影响 xx 用户数，影响了 N 个上下游业务零碎；
5. 故障起因：具体列举故障的根本原因；
6. 改良措施：短期长期措施，基本解决措施；
7. 其它信息（选填）：比方责任方、责任人员、故障定性、损失金额、人员处理措施、人员治理改良措施等等。

故障是如何发现的呢？

1. 监控零碎收回告警：当然覆盖面、采集工夫要正当；

2. 被动巡检剖析发现：没事时多看看监控零碎指标数据，看看日志文件总会有啥新发现的。

   比方某指标异样稳定，但还没触发告警阈值，日志文件吐了点新内容，但没有被以往关键字匹配上。

3. 内部人员发现告诉：用户投诉、上下游和周边零碎告知等。

集体感觉就“告诉数量和重要水平”来说 监控零碎发现占比 80%，被动巡检发现占比 10%，内部告诉占比 10%。