我是一个非典型的理科男户口。关注后，你可以获得最硬核的知识分享和最有趣的互联网故事。大家好，我是“非典型科学人”。今天我就和大家聊聊维稳建设相关的事情。没有稳定，一切归零。7月13日，B站主站、App、小程序均出现访问失败，页面提示“拼命加载数据”。B站的倒闭，让大家意识到“小破站”的流量原来如此惊人。上不了网站、看不到直播视频的“B站难民”纷纷涌向知乎、微博和知名游戏网站NGA。“B站崩了”“陈睿”“豆瓣崩了”等词迅速走红，就连B站的名字“蒙古上蛋”也霸占了微博热搜，火遍全网，颇为壮观.故障发生在23:00左右，直到23:45B站的网页和App才初步恢复正常访问，但直播、会员购买、部分站内互动、评论、投币等板块-操作的功能仍然不可用。B站的这件事火遍了全网，也让互联网人意识到了稳定的重要性。毫不夸张地说，没有稳定，一切都会归零。稳定性定义所谓“服务稳定性”，是指用户在使用我们的服务时，服务响应迅速、正确、高效。响应式：应用可以打开，里面的各种功能点击后有响应；正确：各项功能输出结果正确，符合预期，如支付金额正确，页面应有的内容和数据都有。等效率：前两个满足要求，还有响应效率的问题。如果服务响应突然变慢，导致用户放弃使用，也是稳定性的问题；业务发展的不同阶段采用不同的稳定性保障策略。在业务发展初期，大家只关注业务，很少考虑稳定性。随着业务的不断发展，业务规模不断扩大，各种稳定性事件频发。在这个阶段，商科学生一般负责稳定相关的事情。业务发展到相对稳定阶段后，由于业务规模较大，稳定时间的影响也越来越大。甚至会带来广泛的舆论影响，影响企业的品牌形象。在这个阶段，将有一个专门的团队负责稳定性建设。稳定性评价稳定性评价对于稳定性建设非常重要。稳定性评估不仅可以让团队快速评估系统稳定性的现状，还可以作为稳定性团队工作评估的标准。稳定性评价的悖论如果一个系统非常稳定，它就不能体现稳定团队的工作价值。如果系统经常出现稳定性故障，则稳定性团队没有做任何有价值的工作。这似乎是一个悖论。因此，我们不能简单地用系统的稳定性来判断定性团队的工作价值。必须找到一个可测量和可观察的指标来评估系统的稳定性。同步过程评估同步过程可以使用可用性指标来衡量。也就是几个9的稳定性。不同的可用性表示用户可用时间的比例。可用性计算公式目前业界衡量系统可用性有两种方式，一种是时间维度，一种是请求维度。我们先来看看这两个维度的计算公式。时间维度：Availability=Uptime/(Uptime+Downtime)请求维度：Availability=请求成功/请求总数时间维度我们先来看时间维度的系统可用性。一句话总结：时间维度就是从失效的角度来评价系统的稳定性。以发烧为例，首先要定义什么是发烧。比如体温超过37.5，是否真的发烧，要看时间长短。偶尔体温超过37.5不能算发烧。从例子可以看出，时长维度的评价包括三个要素：一是测量指标，比如体温是测量指标；二是测量指标，达到什么指标是正常的，达不到就是不正常，低于37.5度是正常的，超过37.5度是不正常的。但单一的测量并不能说明问题。我们可以多次测量它。例如，6次中至少有4次低于37.5度是正常的。如果换算成比例的话，就是67%；三是影响的持续时间，比如持续12小时以上。使用时纬度评估时只有系统故障会影响可用性，而且这个结果的计算比较粗略。偶尔出现的接口异常或者超时，没有达到失败的程度，不算不可用。时长维度也没有考虑尖峰故障和低峰故障对用户的影响，虽然时长相同，但完全不同。请求维度请求维度从请求成功的百分比角度来评价系统的稳定性。请求维度的系统可用性还包括三个关键要素。第一个衡量指标是请求成功率；第二个测量目标是当成功率达到95%时系统运行正常。三是统计周期，比如一天、一周、一个月等，我们在一个统计周期内计算整体情况，而不是看单个时间。异步流程异步流程不直接影响业务指标，但处理时间过长会影响用户体验。可以使用SLA评估异步流程评估。SLA是ServiceLevelAgreement的缩写，意思是对用户的服务承诺。SLA主要看两个指标：SLA持续时间：SLA持续时间=请求完成时间-请求发起时间。SLA的时长直接决定了用户体验。SLA完成率：SLA完成率=SLA时间内完成的数量/请求总量。SLA完成率影响用户满意度。关于稳中求进，今天就到此为止。下篇文章会详细介绍大公司是如何做服务稳定性的。关注《非典型理科男》，技术文章不会丢。什么是建筑设计？架构设计看这篇文章就够了为什么Redis这么快？重量级：2020最新JVM生态报告解读BIO、NIO、AIO总结JDK8的新特性，你知道多少？回复“资讯”，免费获得一份独家精心整理的技术资料！
