服务稳定性运维保障体系建设的误区
误区一：对监控的错误期待
每每在谁在讲服务稳定性不够好时，总是会说我们的监控做的还不够好，可往往已经把监控搞的已经很全面了，服务稳定性依然没有有效的改善，反而运维被告警淹没，变的疲惫不堪。
究其原因，服务的稳定性本就不是监控能够解决的，但不是说监控就不重要，而是许多人总是把监控与告警划等号，错误的期待告警能够解决问题。
监控真正的核心作用是：
- 数据分析，帮助研发、测试、运维等技术团队测试、分析、发现、优化问题，尽可能的把问题消灭在生产环境前
- 故障自愈，日常中80%以上的问题都可以通过自动化手段解决，利用程序通过获取监控数据，可以自动的对服务进行降级、熔断、恢复、扩缩容等动作，真正的保障服务的稳定运行
而故障告警的作用则是对一些不可知、不可抗力因素和无法自动化的问题的兜底，告警的出现就一定是需要人工立即介入的事件，而人工的介入一定是有时延的，等到人去解决的时候，往往是业务已经受到了影响。正确的趋势一定是随着运维工作的深入，告警规则越来越少，如果告警规则只增未减，就一定是错误的。
误区二：监控指标的标定
我前面文章中讲过做好SRE的一个重要因素是做一个社交达人，运维团队相较研发团队离业务方较远，而技术团队中研发是与业务方互动最为频繁的，运维团队通常会陷入封闭造车的境况，或者把研发当做业务方情况，而这会造成指标的上的误差，以及真正的业务方无法理解和重视的情况。
而真正的业务方关心的指标往往是订单量、在线用户数、GMV等，但这些指标往往在业务方的系统中，技术团队通常是看不到的，所以运维团队需要主动走进业务方，与业务方共同敲定指标，将业务方的指标与技术上的指标对应上，既可以让业务方理解指标的含义，又可以让业务方理解重要性，从而获得更多的支持和重视。还有最重要的一点是，了解了业务方关注的指标，就掌握了最准确的指标，之后不管技术架构、服务模块如何的变更，都不会影响指标的准确性。
误区三：故障处理
首先故障的定义什么？故障的定级又该如何定义？业务方、研发、运维不同的视角的理解是不一样的，业务方可能认为有10个用户反馈订单异常就是故障，但也可能运维认为的很严重的某服务宕机，业务方并不觉得是故障，这些需要具体量化数值，到底什么程度算故障？一定是要在故障出现之前有准确的定义，而不是在事后复盘再做定义，要能够在故障出现的第一时间根据量化定义判断出是事件、异常、还是故障、事故。
在处理故障的过程中，技术人员通常会陷入细节陷阱，总是在最宝贵的第一时间忙于查找根因，而忘记了业务方真正关心的不是根因，而是止损、快速恢复。这是许多运维人员长期陷入的一个误区，认为解决故障的能力是特别重要的，总是把更多的时间放在了如何提高个人技术和应急处理能力上，造成这个的原因是多面的，有运维人自身认识问题，也有KPI制度的不合理问题，老板对运维的认知问题(认为运维和研发是一样的，喜欢见到运维与研发一样忙碌)，还有历史留下的繁杂技术包袱问题。但再优秀的个人，也是抵不过一个完整的预案的，应对突发故障的最好的办法是充足的预案，这才是将运维带出故障循坏的正确路径。
误区四：关于根因定位
一次故障复盘中，定位是A服务接口出现了大面积超时导致，导致接口超时的原因是下游的数据库出现响应超时，数据库出现超时的原因是出现了大量慢查导致高负载，通过分析SQL，得出源自于B服务上线的新功能。
以上是故障复盘的直接原因，基本也都能得到所有人的确定和接受，但其根本原因呢？数据库混用的设计是否合理？为什么没有做好上线检查？为什么测试环节没有发现问题？是制度流程缺陷，还是制度没有得到有效的执行？
一时的故障原因是解决了，但如果根本原因没有解决，类似的故障就永远不会减少和消失。但站在运维的角度，有没有深入思考根本原因，有没有推动过深究根本原因的解决。当然深究根本原因往往面临着谁来担责的现实问题，很多时候阻力很大，需要公司或团队的力量，但只有消除根本原因才是一劳永逸的不二法门，否则运维团队只会越做疲惫。