漫谈SRE之对事不对人的文化

序言

     风不在，雨不停，最近很忙，忙如狗。。。但是感觉上是瞎忙，但是却又不得不做。。。。

    告警治理是个博弈的活儿，一直想做，但是没有太大的动力去推动。。。只有故障之后，才会再次去做这些事，要不然没人关注。。。故障是最博眼球的东西了，会大大提升很多事的优先级。

告警治理

     每个人每天的时间是一样的，但是只要同时处理超过三件事，基本上事事都会以悲剧结尾，每天就那么点时间，短信告警如水一般发送到手机上，你还会看么？

    短信告警，很直观的告警，出现了告警，看一样告警。。。出现大量告警，忽略。。。不做任何处理，慢慢的，就会忽视真正的大故障。

    心生倦怠，这就是为什么再美的东西看久了也会产生厌烦的心理。

    那么问题来了，告警如何定义？每天发生几次告警才能及时的处理？

    随便上网一搜，各种各样的监控工具，各种各样的监控项，各种通用的监控。。。一般人进行配置告警的时候，就会将一些基本的告警项进行配置，后续是否有进行过优化？需要的就加上。。。不需要的就去掉，通用的版本并不一定适合每个人，每个人都有特殊性。

    告警，主要是为了反映底层系统或者业务系统的问题，或者是发生了一些错误，定义告警，也就是定义关键的指标项，必须立即处理的，那么就应该发送通知，比如我的SLB的开放的端口服务，这个一挂，全部服务中断。定义了告警，那么也可以定义故障的等级。。。不根据告警来定义故障等级都是耍流氓。。。需要进行关注的，那就应该发送通知，而不应该发送告警。。。例如有些服务能自动恢复，例如虚拟机中的服务能自动迁移，不会导致服务中断。

    在定义监控的时候，可以根据两个维度来进行定义，一个是资源层，也就是IAAS层面或者是PAAS层面，在这个层面定义的告警，一般是各种关键的服务指标的定义，如果不可用，可能会影响业务层，但是有些服务是负载均衡机制的，如果没有定义这种告警，那么慢慢的又会将问题掩盖，直到服务不可用；一个是业务层，业务层发生告警，其中就代表了业务影响范围。

    最终，故障等级也就根据业务层的影响来确定故障等级。

    发生几次告警才是正常的？重大故障的除外，而普通的日常运维中，没有告警是最好的，不要超过三次告警，在神经紧张的情况下，你能处理几次故障？？？

    告警治理其实是一项长期的工作，而不是短期的突破就可以。。。每一次故障，每一次告警，你都应该有后续动作，是优化告警项？故障了告警没有发出来，你是否添加了监控的指标？告警发出来了，然后发现是误报，是不是可以修改监控项？持续优化才是王道。。。

紧急事故处理流程

     每天来一个故障，刺不刺激，紧不紧张。。。。

    来了一个故障，各大领导都来慰问你，刺不刺激，紧不紧张。。。。

    来了一个故障，有领导问你业务影响，有领导问处理进展，有领导质问你为什么还没定位到问题。。。而你，还在看各种错误日志。。。三头六臂，一目三行。。。这个时候，你是否想到了，关键时刻，一个个就会逼逼，还能干啥？？？

    有人说，你按照流程走的，不怂，这个锅你不用背。。。。但是，有没有想过，不背锅不代表不用反思。。。每一个指令下去都有可能造成更大的故障。。故障蔓延！！！你发生车祸了，但是你没死。。。是不是应该感到很开心？？？这种劝慰人的方法是不对的！！！

    这不是演练！！！但是。。。没有既定的流程！！！

    参考流程如下：

    1、 收到告警，查看关键的运维平台查看对应的错误，如果定位到错误，进行相应的处理；

    2、 没有定位到错误，通知相关责任人，发布故障，进行故障时间和故障进度的记录及通报；

    3、 继续定位错误，发现毫无进展，通知相关的产品，研发，加入进行处理故障，给每个人各自的任务，进行自查，并随时反馈最新的进展；

    4、故障处理，业务恢复；

    5、 提交故障报告。

    在这套流程中，关键点在于两个：

    1、 多人多角色，有很多人加入故障处理，但是每个人都是不同的角色，而不在是一个人既要汇报又要处理等各种事情集于一身。

    2、在故障处理过程中，无法定位问题，会加入越来越多的相关人员，不再是运维一个人来定位问题，包括产品，研发等相关角色。

        其实，对于运维来说，紧绷的神经。。。其实也没什么大不了的，最多不就是业务中断几个小时，都能恢复。。。又不是真实的物理伤害。。。所以，无须紧张，深呼吸一口气，沉着（撑着）处理。。。

对事不对人

     对事不对人，那是不可能的。。。这辈子都不可能了。。。

    出了事，人的本能就是，这个事情与我无关。。。这个事情不是我造成的。。。这个不是我的错。。。这个不是我的锅。。。

    企业文化？？那是不可能的。。追责是必须的。。。

    高层没有这种意识，他们不是没有改进机制，而他们是把追责放在了首位，他们以为这样就能让下面的人谨慎更加谨慎的操作。。。然而，并不可能，只会造成大家都在摔锅。。。只能造成大家都在畏首畏尾。。。出了问题，如果没有定位到问题，没人敢尝试去解决问题！！！！

    出发点是好的，但是多半无法执行下去。。。执行力？？？那是不可能的，人之本性！！！

    对事不对人。。。每次故障必然有本质问题，是因为代码有BUG？那就进行更多的测试。。。是因为监控没有提前发送告警？那就优化监控项，添加关键的监控指标、、、是因为手误操作，那就全部做成按钮，点一个按钮总不会出错了吧。。。

    不能预防人的错误，那就从系统着手，系统比人更加可靠，系统应该比人更了解系统。。。这就是为什么大力发展AI的原因？？？？

    对事不对人。。。一个好的故障报告能让其他部门受益，一个好的故障报告能让其他产品受益，一个好的故障报告能让同行受益。。。

    开源？那是不可能的。。毕竟家丑不能外扬、、、为啥github能通知故障了？因为不怂，就是这么叼。。。

    高层没有意识。。。对事不对人，能更好的建设产品，能更好的让各个部门之间进行协调。  

    给与你犯错的机会，但是不要在同一个地方摔倒两次。。。。那么故障演练或许也是一个不错的改进方法。

    带着镣铐跳舞，或许也能很美。。。。