运行稳定性问题的关键 - 可用性
复盘更多的是基于事后的总结与提升。那么我们如何发现、测量稳定性问题呢?那么我们就需要请出今天的主角了——可用性。
可用性作为评价业务稳定性的一个重要指标,它可以通过数据量化、建立基线的方式来发现业务中存在的周期性问题,并由此更有针对性的进行服务质量改进。
那么,什么是可用性呢?可用性是指在一个指定的时间间隔内,对于一个功能个体来讲,总的可用时间所占的比例。换句话说,是指在指定的时间段内,系统能够正常运行的概率或占比。对于我们现在的互联网业务来说大部分都属于「实时」、「在线」,即Real-Time Online System,实时在线系统。对于我们的大部分业务说上面所指的指定时间段,应该就是7*24小时。
可用性的结果经常使用小数点或者百分比表示。我们通常使用一个被称为几个九的度量,对应小数点后连续9的个数。比如,“五个九”就是指该系统在指定时间段内有0.99999(或者99.999%)的可用性。
比如,某系统在一个指定的时间段内,如1天,即24小时。同时我们的监测粒度是分钟,即1440分钟。在我们监控的1440分钟内,系统正常运行了1430分钟。那么在这个指定的时间段内,该系统的可用性即为1430/1440≈0.99306(99.306%)。也就是我们常说的2个9。
那么,99.306%这个值就代表该系统处于正常可用的Availability状态占比,那么1-99.306%得到的0.694%这个值就代表该系统处理异常不可用的Unavailability状态占比。简单的罗列为公式,即为:
业务在线总时长 = 业务的正常可用时长 + 业务的异常不可用时长
更进一步,可用性就是指:
可用性=业务的正常可用时长 / 业务在线总时长
理解了什么是可用性,接下来我们讲一下如何建立可用性。建立可用性的方法有很多,常见的方法有几种:
拨测法即是按照各业务的应用、功能、模块进行周期性测试其运行状态是否正常的一种方法。
举例:我们业务有一个名为A的模块,那么就周期性的(比如,每5分钟一次)对这个模块使用模拟用户行为的方法对其运行状态进行抽样检查。如果该模块运行正常,就记为Availability,如果为非正常,就记为Unavailability。累加至一个时间周期内(比如,1天)Availability状态的占比即是这个模块的可用性。
那么,如何判断业务或模块是否正常呢?我们以一个web类型的业务为例,我们可以检查该服务下的主页、分类页或内容页的关键内容。一般来说,我们可以匹配指定页面Head、Body、bottom的指定字段或关键字。如果可以匹配到指定的一个或一组字段或关键字,那么即为正常,反之为异常。我们可以通过脚本、Nagios、Zabbix等工具来实现对业务的周期性拨测。
这种方法的优、缺点都很明显。优点是这种方法实施难度较低且可以与通过模拟用户行为的方式来测量,也业务实际情况可以比较吻合。但通过这种周期性抽样的方法,存在抽样样本不足或偏差的问题。比如每5分钟拨测一次,如果故障出现和修复都在这5分钟内完成,那么拨测法就很难去捕获到这种错误。
日志分析法即是通过各业务的应用、功能、模块日志进行分析得到可用性的一种方法。
举例:我们业务有一个名为A的模块,那么就周期性的(比如,每小时一次)对这个模块上1个小时日志进行分析。从日志层面区分出正常请求在占比,即是这个模块在过去1个小时的可用性。还是以web类型的业务为例,我们可以从日志中将2XX、5XX状态分别进行统计、分析,可以理解2XX即是Availability,5XX即是Unavailability。(3XX与4XX可以按照实际的业务情况再考虑是否参与分析)
这种方法上很明显的解决了拨测法抽样样本不足或偏差的问题,但也存在与实际业务影响指数可能会存在较大差别的情况。比如,我们在过去1个小时的错误都发生在1分钟内,剩余的59分钟业务都是正常的。很显然这样得出来的可用性和实际业务情况是有一定偏差的。那么怎么解决这种偏差呢?日志分析阈值法就应运而生了。
日志分析阈值法是在日志分析法的基础上添加了状态阈值判断的一种可用性计划方法。
举例:我们业务有一个名为A的模块,我们通过日志分析法得到,这个模块每分钟正常情况下的请求数约为10W次,那么我们可以设置一个阈值为10次。这10次的意思就是指,我们容许在1分钟内发生万分之一以内的错误。如果1分钟内发生的错误在10次以内,我们就认为在过去1分钟的状态为正常,就标记为Availability。如果1分钟内发生的错误超过10次,那么我们就认为在过去1分钟的状态为异常,就标记为Unavailability。最后再统计Availability状态的占比即是这个模块的可用性。当然这个阈值需要根据业务的实际情况进行调整。
这种方法上就很好的解决了拨测法抽样样本偏差与日志分析法差生实际业务影响脱节的不足,达到很好的一种平衡。
还有一个问题,如果一个业务由A、B、C三个模块构成,那么怎样通过模块的可用性,怎么算出业务的可用性呢?简单的方法就是通过最三个模块可用性的平均值即可。但这存在与业务目标相悖的问题。那么我们可以通过与业务目标对齐,进行加权平均的方法。比如A模块对业务来说更加关键,那么我们在计算可用性时就给出A模块更多的权重;C模块是业务的旁路系统,那么就可以在计算时降低对C模块的权重。以此类推,我们得出的可用性就可以尽可能的贴近业务及其目标了。
我们还可以通过利用像基调、博睿这种第三方的测试平台的节点,对业务进行更加广泛的拨测,以提高采集样本的精度,减少其偏差。当然其结果也受限于第三方平台及链路间的稳定性的影响
对于有客户端的业务,我们可以通过在客户端关键路径上进行打点,然后将用户的打点日志集中至服务端后再进行集中分析。这种方法虽然可以反应出最真实的用户状态,但也存在实施成本相对 较高、日志上传延迟等问题。
计算可用性的方法有远不至上面写的几种,并且并有哪一种方法可以解决所有的问题和痛点。从成本、收益、时间等角度选择一种或多种最合适自己业务或团队的方法,用于持续改进业务的服务质量才是王道。
以上就是运维稳定性问题的关键–可用性的详细内容,更多请关注php中文网其它相关文章!
上一篇: 可用性测试
下一篇: Go 语言在渗透测试领域的可行性分析
推荐阅读
-
稳定人工智能开年首个大模型:专用代码、支持 18 种编程语言、100K 上下文以及可离线运行的苹果笔记本电脑
-
稳定人工智能公司发布无需图形处理器即可本地运行的稳定代码 3B 模型
-
软件工程可用性测试:改善软件、网站和产品用户体验的关键部分
-
运行稳定性问题的关键 - 可用性
-
光纤网络机房和网络电缆:构建高速、稳定网络的关键
-
Kafka 高可用性之谜:深入剖析其架构原理和关键技术--副本数量与分布:适当增加副本数量可以提高容错能力,但会增加网络开销和存储成本。合理分配副本,保证副本在不同Broker上尽可能分散,可以降低单点故障的影响。 数据复制策略:Kafka 支持同步复制(在响应客户端之前同步 ISR 中的所有副本)和异步复制(响应客户端后异步复制到其他副本)。同步复制提供更强的数据一致性,但会牺牲写性能;异步复制则相反。根据业务对一致性和性能的需求,选择合适的复制策略。 监控和报警:实时监控代理、分区和复制状态,设置阈值警报,及时发现并处理异常情况,是保证高可用性的必要条件。 V.总结
-
小红书大产品部架构 小红书产品概览--经过性能、稳定性、成本等多个维度的详细评估,小红书最终决定选择基于腾讯云星海自研硬件的SA2云服务器作为主力机型使用。结合其秒级的快速扩缩、超强兼容和平滑迁移能力,小红书在抵御上亿次用户访问、保证系统稳定运行的同时,也实现了成本的大幅降低。 星海SA2云服务器是基于腾讯云星海的首款自研服务器。腾讯云星海作为自研硬件品牌,通过创新的高兼容性架构、简洁可靠的自主设计,结合腾讯自身业务以及百万客户上云需求的特点,致力于为云计算时代提供安全、稳定、性能领先的基础架构产品和服务。如今,星海SA2云服务器也正在为越来越多的企业提供低成本、高效率、更安全的弹性计算服务。 以下是与小红书SRE总监陈敖翔的对话实录。 问:请您介绍一下小红书及其主要商业模式? 小红书是一个面向年轻人的生活方式平台,在这里,他们发现了向上、多元的真实世界。小红书日活超过 3500 万,月活跃用户超过 1 亿,日均笔记曝光量达 80 亿。小红书由社交平台和在线购物两大部分组成。与其他线上平台相比,小红书的内容基于真实的口碑分享,播种不止于线上,还为线下实体店赋能。 问:围绕业务发展,小红书的系统架构经历了怎样的变革和演进? 系统架构变化不大,影响最深的是资源开销。过去三年,资源开销大幅增加,同比增长约 10 倍。在此背景下,我们努力进行优化,包括很早就开始使用 K8S 进行资源调度。到 18 年年中,绝大多数服务已经完全实现了容器化。 问:目前小红书系统架构中的计算基础设施建设和布局是怎样的? 我们目前的建设方式可以简单描述为星型结构。腾讯云在上海的一个区是我们的计算中心,承载着我们的核心数据和在线业务。在外围,我们还有两个数据中心进行计算分流,同时承担灾备和线上业务双活的角色。 与其他新兴电子商务互联网公司类似,小红书的大部分计算能力主要用于线下数据分析、模型训练和在线推荐等平台。随着业务的发展,对算力的需求也在加速增长。
-
云服务器+家用电脑(无公网 IP)Pinode 节点部署教程--理论上,无论你身在何处,只要能上网,就能运行一个固定 IP 的 Pi 节点节点!(注:不能直接部署独立云服务器)本方案相对运营商公网 IP 有以下优势:拥有稳定的固定 IP(阿里云 IP),解决了运营商不分配公网 IP 或分配动态 IP 的问题 ②节点部署在本地电脑上,相对安全。因为是使用阿里云的专网,稳定性也很强。希望对大家有用,帮助大家解决没有公网的节点部署问题。第一步:环境准备 1、本地电脑配置: ①操作系统:推荐 WIN10 专业版(目前节点容器只支持 2004 专业版) ②内存:推荐 4G 及以上 建议:https://item.taobao.com/item.htm?spm=a2126o.success.0.0.61 b94831SbZESt&id=6346663414282,阿里云服务器租用:阿里云(推荐1核2G以上,ECS共享s6,带宽3-5M即可,以下两个链接都可以,选择一个合适的即可)https://www.aliyun.com/minisite/ goods?userCode=is7i4iav
-
对话NGC蔡岩:从机制创新到价值沉淀,解析DeFi产品开发逻辑 |链捕手 - 真正的DeFi产品首先要有足够的安全性和稳定性,如果能在此基础上有一些功能创新,那就非常好了。像 Uniswap 这样逐渐成为 DeFi 基础架构的产品,可遇而不可求。 链式捕手:固定利率协议之前关注度比较高,但观察下来发现,大部分协议还是类似于传统金融CDO(抵押债务凭证)的玩法,风险系数很高,您如何理解这块业务的价值和风险? 蔡岩:确实有些定息协议类似CDO玩法,背后绑定一个债券,但并不是所有的定息协议都是这样的玩法,像这种CDO玩法的主要代表项目是88mph,背后绑定的是Aave、Compoud这样的借贷协议,在此基础上做定息和浮息债券;像APWine,背后同样是Aave,它会发行期货收益代币来锁定你的收益;Notional本身是做借贷市场的,在此基础上做定息协议。 非 CDO 的玩法,比如 Horizon,更像是一个利率撮合器,背后需要用户通过拍卖产生更合适的目标收益率;像 Saffron、BarnBridge 等是通过风险分级来定义不同的收益率。总的来说,创新还是挺多的。 价值层面是创新和想象力,因为在传统金融领域,比如银行做固定收益证券,或者评级机构给风险分级,这些业务都非常大,利润也很丰厚。而 DeFi 的对口业务给了类似业务很大的想象空间。尤其是固定利率协议的成熟产品不多,尝试各种微创新是很有意义的。 风险程度还是要具体到不同的玩法,比如,在 Aave、Compoud 等借贷协议的固定利率协议背后,如果这些借贷协议受到攻击,与之绑定的固定利率协议也会受损。 同样,如果自己做借贷市场,可能更需要更强的开发能力。再有,如果该程序的机制或参数设计不当,同样会导致协议运行不稳定,并可能造成大量用户清盘。 总的来说,风险在于固定利率协议的设计,这是一个非常复杂的过程,需要不断地尝试和出错。 链式捕捉器:刚刚提到背后是Aave/Compound的固定费率协议风险较大,您认为Aave最大的不确定性和创新点分在哪里? 蔡岩:其实爱钱进一直被认为是走在行业前列的项目,他们的迭代速度非常快,比如率先尝试闪贷、推出新的经济激励模式、推出目前业内首个安全模块、尝试L2解决方案等等。 而在主要的借贷业务上,他们又十分谨慎,比如在抵押率、清算系数等风险参数的设计上相对于其他借贷协议较为保守,并不会存在为了吸引更多借贷资金而降低风险的要求。 与许多 DeFi 项目一样,即使 Aave 进行了多次审计,也无法保证不存在漏洞。前段时间,Aave 刚进入 V2 阶段时,白帽黑客就指出了某个漏洞。 之前的创新点可能是闪电借贷,这是当时业内独一无二的新产品功能,也为 Aave 带来了不少收益。当然,也有人批评闪电贷只能方便黑客实现资金效益的最大化,但工具本身并没有错,未来闪电贷肯定会有更多的应用场景。 其次是安全模块的设计,这有点像项目本身的储备金库,保障项目的安全性,这也是爱维开创的先河。说实话,目前大多数项目都没有做到代币模式的良性或正向运营,也做不到像Aave一样的安全模块,这是一个不小的门槛。 Chaincatcher从某种程度上来说,挖矿模式是DeFi财富效应的根本支撑,但Aave的CEO却说挖矿机制带来的动力是不可持续的,您怎么看这个观点? 蔡岩:"挖矿机制 "不可能失效,因为它是一种激励机制,或者说是项目冷启动的一种方式。但流动性开采亚博体育手机客户端不会一直高涨。比如去年11月的流行性挖矿高APY持续了一两个月就崩盘了,导致DeFi市场大幅回调。 Aave、Uniswap、Synthetix等项目真正爆发进入市值前15名也是在今年2月,我更倾向于这是头部DeFi长期价值的体现。虽然大家都喜欢抢高APY的矿机,但我个人很少参与挖矿,所以我并不觉得流动性挖矿是DeFi的基本面支撑。
-
透彻理解不稳定的关键词和应用场景,面试必问,小白都能懂!