质量是公司的生命线！这个口号喊出去容易，做起来还是有挑战的，很多公司的口头禅也都是这个。
线上的产品成型，涉及的角色有销售，运营，项目，产品，测试，研发，运维，客服等等。但是交付给用户体验的最后一道关卡是运维。
运维负责将代码放到机器上供用户使用，一旦出现问题，运维也是第一个收到消息，他需要直接解决或者联合其他人员一层一层的定位修复。
服务的稳定保障分三个阶段：事前，事中，事后。要想SLA服务可靠性如99%，99.9%，99.99%，99.999%，那么必须在事前做的足够好才行，这也是告警体系需要发挥的的价值。
为什么一定要建设告警体系？
地震来了，要不要先通知你跑人？这就是告警体系的作用。
事前考验的是我们的架构能力和体系建设能力；事中考验的是我们的经验和技术能力；事后就需要我们复盘吸取教训完善事前和事中。
事故一般什么时候发生？
普通的正常的业务迭代研发上线，只要服务集群足够不会有太多的冲击，就算有也不会是致命的。
活动冲击才是致命的，德鲁克总结说企业有两个基本职能：营销和创新。
恰恰公司运营活动是经常有的，这个大家应该都遇到过。活动前期准备工作我们会考虑到各种因素，但是大型活动心里还是有担心的怕有遗漏的怕出事故。
因此一个活动要做好，必须有动员能力，战备能力，后勤能力， 任何一个环节出现问题都是致命的。
动员能力：相关人员一定要参与核心会议，比如明天活动8点开始，没通知运维在岗就完蛋了。
战备能力：准备方案，进行方案的讨论和对应人负责落地。
后勤能力：除了相关的核心技术人员要在岗，还有技术经理，运维经理，架构师，甚至总监都要在岗，因为一旦出了问题，他们的经验会发挥超级大的价值，加快服务恢复速度。
事前的告警能力？
有没有发现，这个时候忽略了一个很重要的工作要做，就是告警。你想想兄弟们要去干仗了，家伙事带齐准备冲，但是前面有地雷，你要不要得到告警做应变，还是当炮灰。知己知彼才能百战不殆，监控体系的建设是至关重要的！
监控体系建设
关于建设监控体系可以分三个阶段来建设，可根据轻重缓急和团队的配置来做并不断完善
第1阶段：主机监控
参与角色：SYS系统运维+DBA数据库运维。
这个阶段是最基础的，你需要保障应用process，port，机器负载，数据库负载等，一定要做的100%的监控到位且能发出报警信息。
第2阶段：应用性能监控
参与角色：SRE应用运维+DEV运维研发
这个阶段关注的应用的可靠性，将应用的性能发挥到最优，给予研发同学最直接的支持。比如找出频繁GC的代码，SlowSql，最大优化tps，rt等等
第3阶段：日志监控
参与角色：SRE应用运维+DEV运维研发
这个阶段关注的是业务数据全局观，也就是上帝视角。如服务HTTP200成功率，失败率，平均响应时间，日志归集统一查看等等
第1-3阶段：持续优化
1,告警规则：
监控面对的是不同的业务部门，不同的产品，那么要根据这些创建合适的触发告警的规则。
设定告警级别：1级，2级， 3级，4级。具体的1，2，3，4级重要程度，可以根据业务关注的点来设定。
设定阀值：将维度，指标，阀值与告警级别关联。
2,告警通知：
设置通知：邮件，IM，短信，电话。1，2级别可以用电话+短信通知。 3级可以是短信+IM。4级可以只是IM。
设置告警分组：不同产品负责人只收到对应产品的告警信息。如果你创建一个大群什么信息都往群里丢，干扰消息多了大家会开启免打扰模式。
设置值班组：对应的值班组的人员接收全部告警信息且需在岗并努力恢复服务解除告警。
3,业务可视化
这个非常重要！你需让收到通知的人，点击通知里面的链接能跳转到一个可视化的页面，从而帮助他分析问题，快速解决问题。这个可视化是一个非常重要的监控系统平台，需要持续的去建设。
打比方，我们之前遇到个场景，用户说登录不了，同时我们也收到了java服务挂掉的报警，我们先将日志记录并将服务启动。但是服务依然没有恢复，这个时候经过分析判断可能是负载高接着去扩容机器，发现依然没有恢复，最后发现是数据库挂了。
这就是解决问题没有解决在根本点上，白白浪费了时间。当然其中告警系统也故障了，理论来说数据库挂掉你应该收到消息。任何时候告警信息一旦收到，你第一时间去看的应该是大盘。用上帝视角去排查，会加快问题的解决速度。这就是业务全局可视化的重要性。
总结：
告警体系是需要花精力花功夫持续建设的，所谓的养兵千日用兵一时真的是最好的形容了。
在稳定时期你做的这些对业务方是无感的，也会觉得没什么价值。 但是如果一旦出了事故，你努力3个月想拿一个A到头来结果等来一个D，而且整个团队都是D，那真是RILE！
运维保障服务的稳定性就是给公司创造的最大价值，做不了王，那就做王背后的男人吧。
