温州网站关键词推广,做信公众号首图的网站,tp5如何在自己网站后台做pv uv统计,外贸行业网站建设业务高速发展背后的困局
随着业务的快速发展#xff0c;运维体系也逐步的完善起来。业务的稳定性和服务质量也在监控、可用性等体系的相互环抱下健康地成长。所有的问题、故障及影响稳定性的因素都在可控、可收敛的范围内#xff0c;一切都向着好的方向发展。
这一切的背后…业务高速发展背后的困局
随着业务的快速发展运维体系也逐步的完善起来。业务的稳定性和服务质量也在监控、可用性等体系的相互环抱下健康地成长。所有的问题、故障及影响稳定性的因素都在可控、可收敛的范围内一切都向着好的方向发展。
这一切的背后真的和看起来一样美好吗实则不然业务的高速发展势必会留下种种隐患和问题。想想你是否也被类似的种种问题困扰着
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
