《业务高速发展的运维困局，如何保证系统稳定性？》要点：
本文介绍了业务高速发展的运维困局，如何保证系统稳定性？，希望对您有用。如果有疑问，可以联系我们。
随着业务的快速发展,运维体系也逐步的完善起来.业务的稳定性和服务质量也在监控、可用性等体系的相互环抱下健康地成长.所有的问题、故障及影响稳定性的因素都在可控、可收敛的范围内,一切都向着好的方向发展.
这一切的背后真的和看起来一样美好吗?实则不然,业务的高速发展势必会留下种种隐患和问题.想想你是否也被类似的种种问题困扰着：
抛出这些问题,我们再透过问题逐一看看它背后的实质是什么?
它的根本原因还是我们采用了通过广布点、高覆盖等方式并加以「查漏补缺」的方法来尽可能地减少因为监控点缺失而导致的业务异常时监控漏报的情况.
对,没错.初衷是好的,但结果往往事与愿违.特别是在监控点数量及业务复杂度不断提高时,由此监控报警带来的信息噪音就会越来越大.当报警信息量达到一个临界点时,所有的报警都将成为噪音甚至污染.而监控报警系统的用途也会在达到这个临界点后,像「多米诺骨牌」一样瞬间垮掉,走向另一方向的无底深渊.
从实际的情况来看,情况可能并不乐观.经常会出现运维与业务同学在对标、讨论问题时,大家都是在相互「鸡同鸭讲,不知所云」.
对,或许问题的根结就在这里.我们做的大量监控是否能对业务指标的稳定及提升起到正向的帮助呢?
特别上述第 2、3 点提到的情况从根本上讲就是 运维与业务同学没有在同一语境导致的. 一边是业务数据导向思维,一边是技术数据导向思维.
当然不是了,「业务大盘」就是在这种环境和情况下应运而生.「业务大盘」并不单单是一个工具、报表或平台,它是一种基于业务关键指标为导向的技术化驱动思维方式,让运维及业务等多方在相同语境下沟通的方法.
首先,运维同学需要去转变思路,站到业务方的立场上去考虑问题. 抛开所有的技术指标不谈,先与业务同学进行尝试沟通,了解他们最关心的指标是什么?
明确了一系列关键指标后,再从中提取最为关键的 1~3 项.为什么还要再次提取呢?
因为 业务的关键、核心路径很重要,避免什么指标都去关注,结果就是什么都关注不到位的情况出现.
明确了关键指标后,我们再按照可用性体系的方法对关键指标进行建设.除了关键业务指标外,我们同时需要从以下几个纬度进行分析：
为了减少解决误报的情况,可以结合环比、同比,甚至基线指标综合使用.
有了相应的「业务大盘」指标数据结果后,因为是 基于业务核心指标为导向,就更容易将运维及业务相关同学放到同一语境下进行沟通,所以目标就更加清晰、解决问题的方向也更加聚焦.效率提升也就水道渠成.
当然,只有不断地与业务同学对标,改进及优化相关的核心指标才能持续地享受「业务大盘」带来的享受与快感.
基于「业务大盘」,我们是否还可以玩出更多的花样,以进一步提升业务的稳定性.欢迎关注计划近期出品的「让运维稳定性走在业务前面——灾备演练」
文章来自微信公众号：高效运维开发；作者：胡杨
转载请注明本页网址：
http://www.vephp.com/jiaocheng/3760.html
