一、在运维的过程中,需要记住一个原则:如果报警发给了 一个不能短期内解决问题 的人。 那么应该反思这个报警是否有合理的必要。

二、告警信息,需要定制分发,制定告警策略,重点需要关注以下几个方面原则。
哪些业务需要告警?
哪种故障需要告警?
告警等级如何划分?
故障依赖关系如何定义?
告警信息如何汇集?
如何做到精准有效的告警?
最终的目的就是少收告警信息,自动处理故障,自动恢复服务,当然,这是一条漫长的路。
如果不解决以上问题,将会被告警信息所淹没,最终如题主所言,影响运维工作。
对于监控的告警信息,处理的好,将会提高我们的故障响应速度,处理的不好,会影响我们的工作情绪,适得其反。试想,当一天收到1000封告警信息,是否还会去逐一查看监控告警信息?是否还能分辨是否重大故障,还是一般故障?
对于误报,漏报,会让人对信息的警觉性放松,时间久了,还会导致对接收监控信息有反感。所以,对于监控告警信息的发送,是一件特别慎重的事情。总结一下,对于监控告警信息,我们有以下的需求:
1.基于业务类型,将告警信息发送给相应的业务用户,例如IDC人员,WEB运维,CDN运维,网络运维,不同的人员管理不同的设备,因此需要把故障发送给相关用户处理。
2.基于故障级别,对一个故障,将不同的故障级别发送给不同用户,例如5分钟内的故障发送给运维一线人员,10分钟发送给运维部门主管,30分钟发送给运维部门经理。重特大故障发送部门相关领导。
3.基于时间发送,比如业务维护期,告警无需发送。

4.故障的相关依赖关系,当A服务发生故障时,发送一般告警,当A,B服务故障时候,发送业务故障告警。
5.对出现故障的服务尝试用相关命令或者脚本进进行操作处理,尝试自动恢复,例如重启服务,重启服务器等。
RIIL 区别于一般的软件厂商,通过软件+服务+咨询+培训一站式交付模式,致力于提供匹配客户需求的解决方案,让客户能够真正把产品用起来,实实在在感受产品带来的价值
RIIL 区别于一般的软件厂商,依托锐捷强大平台,拥有遍布全国的销售、售前支持及售后保障网络,为客户提供便捷有力的本地化原厂服务
RIIL 在软件产品方面具备面向管理者、基于业务、可视化管理的特征,其中IT健康指数、业务雷达等创新管理功能拥有国家专利保护
RIIL 在全国具备大量的成功案例,南北车集团、中石油、清华大学、华南师范大学以及政府一半以上部委等等500多个优质行业客户都是RIIL的忠实用户
对于大多数运维程序员来说,时时刻刻都需要关注服务器和系统程序可能出现的问题并提前解决。今天我们就通过案例分析来了解一下,运维程序员如何快速处理线上问题。
任何一旦掉进坑里,明智的做法一定是:跳坑_>填坑_>避坑,线上故障处理的过程也一样,优先级从高到低,线上故障处理的目标如下:
跳坑
‘跳坑’——快速恢复线上服务,或者将对线上服务的影响降到低。
线上服务的可用性决定着服务者的客户利益,影响着公司的收益。一旦线上环境不可用,无法服务用户,给公司/团队带来经济利益损失的同时,更为严重的会给公司/团队带来恶劣的名声。所以一般公司都会对线上环境提出稳定性和可靠性的要求,这也是团队乃至部门的kpi。为此,遇到生产故障后的一要务是:恢复生产服务,即使不能完全恢复线上服务,也要想尽办法将对线上服务的影响降到低。
填坑
‘填坑’——找到问题原因,根本上解决问题。
在恢复线上服务,尽大限度减掉对用户/公司/团队带来的影响后,我们需要彻查问题,搞清楚故障发生的根本原因,从根本上解决问题。通常情况下,‘填坑’和‘跳坑’是同步在做的,完成‘填坑’也就意味中‘跳坑’成功,但是也有一些紧急情况下的特别‘跳坑’方法,比如重启服务,或者服务降级/熔断等等,实际并未在当时完成‘填坑’,而是先采取非常规手段‘跳坑’,之后再慢慢‘填坑’。
避坑
‘避坑’——举一反三,消灭隐患。
找到了根本原因,解决了问题之后,我们需要举一反三,以此及彼,想想在这个故障排查和处理过程中,那些环节存在弱点?那些流程/规范/制度需要优化?这类问题是否在其他系统或者团队中也存在?通过这样的反思和自我批评,形成一份线上事故报告,不断完善流程,避免再次踩坑,也在团队中交流经验,共同提高。
线上故障处理的思路
依据线上故障处理的目标及目标的优先级,线上排障的一目标是恢复线上服务或者降低对线上服务的影响,关键点在于快速二字,在‘跳坑’-‘填坑’之后,再行回溯总结,以便‘避坑’。因此,可以将线上故障处理的步骤分为:
故障发现
故障定位
故障排除

故障回溯
其中前三步是‘跳坑’行为,后面一步包含了‘填坑’和‘避坑’。
上述步骤并不是说要从上到下顺序进行,建议在不乱阵脚的情况下,并行去做,因为通常线上故障后会紧急启动故障处理程序,运维、开发、测试、产品各个角色都会参与进来,这时候分工下去,并行去做,不断汇总消息,做出判断,以求快速排障,恢复服务。这个思路类似于操作系统的fork/join设计思想,目的在于提高效率。
在无法快速找到故障原因的时候,需要果断跳过故障定位环节,直接进行故障排除,比如采用服务降级、服务器扩容等手段,确保对线上服务降到低且可控。北京北大青鸟建议可以等到线上服务’撑’过去之后,我们再慢慢定位故障原因,根本上解决问题。


