运维困局下确保系统稳定的可行性

业务高速发展背后的困局

随着业务的快速发展，运维体系也逐步的完善起来。业务的稳定性和服务质量也在监控、可用性等体系的相互环抱下健康地成长。所有的问题、故障及影响稳定性的因素都在可控、可收敛的范围内，一切都向着好的方向发展。

这一切的背后真的和看起来一样美好吗？实则不然，业务的高速发展势必会留下种种隐患和问题。想想你是否也被类似的种种问题困扰着：

• 1. 监控报警通知的噪音太大，正常的报警通道被人为拥塞，实际阅读率极低；是不是很熟悉？试想如果一个非常重要的业务监控报警被这样淹没，而被人为的忽略，后果作为运维的你会不会后背一身冷汗？除了对监控进行分层、精简监控报警外，我们还能做些什么？
• 2. 业务数据出现异常，但报警、可用性数据却一直处在正常状态；面对前端业务同学「为什么监控没有发现？」的指责，除了说一句「对不起，下次改进提升」。我们还能做些什么？
• 3. 出现报警、可用性异常波动情况，但业务指标并没有明显波动。为了解决这个问题，明明是对业务非常有帮助的改进，但业务同学就是不理解，不支持。除了满满的无力感外，我们还能做些什么？

问题出在哪里

抛出这些问题，我们再透过问题逐一看看它背后的实质是什么？

为什么会有大量的监控报警？它的根本原因还是我们采用了通过广布点、高覆盖等方式并加以「查漏补缺」的方法来尽可能地减少因为监控点缺失而导致的业务异常时监控漏报的情况。

对，没错。初衷是好的，但结果往往事与愿违。特别是在监控点数量及业务复杂度不断提高时，由此监控报警带来的信息噪音就会越来越大。当报警信息量达到一个临界点时，所有的报警都将成为噪音甚至污染。而监控报警系统的用途也会在达到这个临界点后，像「多米诺骨牌」一样瞬间垮掉，走向另一方向的无底深渊。

大量的技术指标监控是否被业务同学认可？从实际的情况来看，情况可能并不乐观。经常会出现运维与业务同学在对标、讨论问题时，大家都是在相互「鸡同鸭讲，不知所云」。

对，或许问题的根结就在这里。我们做的大量监控是否能对业务指标的稳定及提升起到正向的帮助呢？

特别上述第 2、3 点提到的情况从根本上讲就是运维与业务同学没有在同一语境导致的。一边是业务数据导向思维，一边是技术数据导向思维。

看似不可调合的矛盾难道就没有解决办法了吗？当然不是了，「业务大盘」就是在这种环境和情况下应运而生。「业务大盘」并不单单是一个工具、报表或平台，它是一种基于业务关键指标为导向的技术化驱动思维方式，让运维及业务等多方在相同语境下沟通的方法。

问题的破解之道

首先，运维同学需要去转变思路，站到业务方的立场上去考虑问题。抛开所有的技术指标不谈，先与业务同学进行尝试沟通，了解他们最关心的指标是什么？

• 以 Web 类业务为例，业务同学最关心的可能是 UV、PV、首页打开时长等；
• 以电商类业务为例，业务同学最关心的可能是交易转换率，交易成功率等；
• 以发行类业务为例，业务同学最关心的可能是下载转换率，次日留存率等；

明确了一系列关键指标后，再从中提取最为关键的 1~3 项。为什么还要再次提取呢？

因为业务的关键、核心路径很重要，避免什么指标都去关注，结果就是什么都关注不到位的情况出现。

明确了关键指标后，我们再按照可用性体系的方法对关键指标进行建设。除了关键业务指标外，我们同时需要从以下几个纬度进行分析：

• 基线及范围：即关键业务指标的预设的基准值及活动阈值。以基线为中心，在活动阈值范围内的预期波动为正常。跳出活动阈值范围的即为异常。
• 环比：即关键业务指标同一时间周期及上一时间周期数据进行比较。比如，17 点22 的结果与 17 点 21 分的结果进行对比。如结果波动在阈值范围内即为正常，反之为异常。
• 同比：即关键业务指标在两个时间周期内相同时间点的比较。比如，4 月 25 日的17 点 01 分的结果，与 4 月 24 日的 17 点 01 分的结果进行对比。如结果波动在阈值范围内即为正常，反之为异常。

为了减少解决误报的情况，可以结合环比、同比，甚至基线指标综合使用。

写在最后

有了相应的「业务大盘」指标数据结果后，因为是基于业务核心指标为导向，就更容易将运维及业务相关同学放到同一语境下进行沟通，所以目标就更加清晰、解决问题的方向也更加聚焦。效率提升也就水道渠成。

当然，只有不断地与业务同学对标，改进及优化相关的核心指标才能持续地享受「业务大盘」带来的享受与快感。

基于「业务大盘」，我们是否还可以玩出更多的花样，以进一步提升业务的稳定性。欢迎关注计划近期出品的「让运维稳定性走在业务前面——灾备演练」

更多Linux咨询请查看www.linuxprobe.com