成为工程师 - 如何提升系统稳定性(1)

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 成为工程师 - 如何提升系统稳定性(1)

今日内容


今天开始,我们进入到【系统铁三角】的最后一个版块,也就是【稳定性】板块。


这个板块的内容重要且多,我会分成多篇文章来给你讲。你不用着急,我会用容易理解的方式给你铺陈。


全部看完以后,我相信你对如何让系统跑得“稳”,会有完全不同的认识以及信心。


今天我们先来做一个概览,来看看稳定性到底涉及到哪些方面的内容,为什么我们会需要花好几篇文章来讲稳定性。


01稳定性的重要性


在讲具体稳定性方面的内容前,我们先来聊一个话题,那就是,稳定性到底重不重要?如果稳定性都不重要的话,我们就没有必要做那么多展开了


我们从一个角度切入来看,那就是:如果服务不可用,会有怎样的影响?


我们看下图:


从公司收益的角度来看,会有两方面损失:


【直接损失】比如你的产品需要充值才可以使用,然后你的充值服务挂了,用户想充值都充值不了,这就是最真金白银的损失,是公司收入的损失。


【订单损失】订单往往涉及到佣金。比如一个电商平台,每一笔成交的订单,平台都可以抽取佣金。如果交易服务持续不可用,订单就生成不了,佣金就损失了。佣金也是公司真金白银的直接收入。从用户体验的角度来看


【热搜(社会舆论)】一个国民级应用如果不可用了十几二十分钟,铁定上热搜,造成不好的影响。


【信任感】用户使用一个产品,也许是他很重要的时候。比如外卖平台,用户中午要吃饭,然后发现外卖平台怎么都登录不了。但饭总要吃啊,于是就去别的平台点。久而久之,用户对你的信任感就丢失了,也就不再来了。


【直接影响】比如有些用户对某些产品是重度依赖,依赖到不可或缺。例如支付类的产品,现在在医院看病都可以使用手机支付,然后某天突然支付不了检测费药费了,你说严不严重?


这三方面最后造成的就是对产品口碑的影响,继而开始慢慢地损失用户。而损失用户这种慢性地负面影响最终也会对公司的收入造成影响。


大家可以看到,最后所有的影响都是指向收入损失,而收入最终影响着企业的存活和发展。


02故障的种类


在聊完了稳定性为什么重要以后。我们来思考一个问题,服务跑得好好的,为什么会挂呢?服务之所以出问题,那一定是发生了故障。所以,我们来看看故障的种类。


我们看下面这张图:



【变更类】:变更不只是【代码变更】,还包括【配置变更】和【数据变更】。这些变更,无论是参数改错了,还是DB数据订正错了,都可能导致严重的故障。


【容量类】:比如一款秒杀商品上架,上游流量扩大了100倍,服务直接就崩了。再比如做压力测试,直接一下子压力打得太大,直接把线上服务器打崩。


【依赖类】:在现在分布式架构盛行的背景下,一个微服务的直接和间接依赖是非常多的。下游的某个服务、缓存、DB如果挂了,自己就会被“牵连”,无法提供正常服务。


【固件类】:机器的硬件故障,例如硬盘坏了,电容烧了等等。还有一种叫做区域性灾害,比如某个地方施工,一铲子把地下的光缆给铲断了。


【安全类】:例如黑客的攻击。比如做DDOS攻击、水平权限攻击、伪造大量造成缓存穿透的请求等等。

这些故障类别里有一个点值得关注,那就是:只有变更类的故障是由我们主动的行为造成的,而其他的故障多


少属于飞来横祸但他们依然会造成严重的影响。


所以,即使是无妄之灾,我们也要想办法优化和避免。这是稳定性非常非常难的一个原因。


03系统可用性指标


我们讲了稳定性既重要又困难,那就需要有一个指标去衡量稳定性做的如何,并且以此为尺,衡量各种改进的效果。


稳定性的衡量可以看如下这张图:


上图公式中,分母是MTTF+MTTR,分子是MTTR。什么意思呢?我来解释一下


【MTTF】是指平均正常时间,也就是MeanTimeToFailure。比如一个系统,平均每跑一个小时就会挂一次,那MTTF就是60分钟。


【MTTR】是平均修复时间,比如说每次修复故障需要10分钟,那MTTR就是10分钟。

针对上面的公式,我们举个例子:平均每个月出一次故障,每次故障修复需要10分钟,那么系统可用性就是99.97%,也就是我们俗称的3个9。


下面我们来看一个表格。我们一般用系统符合N个9来衡量和要求系统的稳定性。


这个图很好理解,例如我们要求系统可用性达到4个9,那全年系统不可用时间最多就是52分钟。其他同理。

一般来说,大厂对外的服务基本上都要求达到4个9。


所以,结合我们说的。首先,故障种类多且大部分都是无妄之灾,然后对服务稳定性又有非常高的要求。你就可以得出:稳定性真的是一件难上加难上加难的事情!



04如何提高可用性


我们聊了那么多重要性和困难后,还是要给方法。那如何提升可用性呢?


我们从系统可用性的公式出发来看,想要提高系统可用性,就是要降低MTTR,也就是缩短故障修复的时间。


我们可以从三个方面来降低MTTR,他们分别是:【减少故障数量】【提升发现速度】【提升恢复速度】

下面我们先一览三个方向相关的内容,这些内容在后面的几篇文章中,我会再展开来说。


01减少故障数量


我们先讲如何减少故障数量,先看下图:


这个图是我们日常的工作过程。


需求过来,然后研发,接着测试,上线,上线后系统就持续地运行。周而复始,直到这个系统下线。


为什么我放这个图?因为三个提升稳定性的方向其实都是融入在我们平时的日常工作中


研发阶段,我们可以关注【隔离】【幂等】【限流】【兼容性】等。


【隔离】不同的功能不相互影响。


【幂等】请求重复,但结果不受到影响。


【限流】在流量大的时候,自动拦截保护服务。


【兼容性】新旧代码共存时,系统能够正常服务。

测试阶段,我们可以关注【功能测试】【回归测试】【兼容性测试】【流量diff】等。


【功能测试】测试新开发的功能是不是符合预期。


【回归测试】测试新代码没有对已有逻辑造成影响。


【兼容性测试】验证新旧功能共存时,系统是否正常运行。


【流量diff】把线上流量录制下来,在待上线代码上做回放,比对结果。


上线阶段,我们要考虑【发布顺序】【压测容量】【灰度策略】等


【发布顺序】比如服务A必须在服务B之前发布,先发布服务B就会报错。


【压测容量】新功能上线,是否能够抗住业务的预期流量,我们需要先做压测验证。


【灰度策略】让新变化能够逐步地生效。比如可以让一部分内部用户先试用,这样可以降低问题的影响面。


02提升发现速度


我们接下来看如何提升发现速度。这些内容依然是在我们的日常工作中。



研发环节,我们可以关注【日志】和【打点】等


【日志】在写代码的时候加上关键的日志。比如最基础的对异常捕获后的日志、对下游服务调用的日志、出入参日志、业务关键流程的日志等等。


【打点】系统中主动上报数据到监控系统。比如电商浏览页面,你可以把用户查询的商品金额上报,然后配置对金额的监控。如果发现大量金额为0的情况,就说明可能存在系统级别异常。

运行环节,我们可以关注【监控报警】【日常巡检】【数据核对】等


【监控报警配置全面的监控,搭配上恰到好处的报警规则。


【日常巡检】周期性主动探测各种链路是否正常。


【数据核对对上下游系统的单据进行核对,发现单系统内的潜在bug。


03提升恢复速度


最后我们来说第三块,提升发现障后的恢复速度。



研发阶段,我们可以关注【工具建设】【容灾切换】【降级开关】【流控设置】等。


【工具建设】针对系统中可能存在的一些问题,建设检测或者修复的工具。例如修复缓存数据库不一致的工具。


【容灾切换】在服务发生线上问题时,快速的切换流量和设施。比如设计时考虑了备份DB和缓存,在发生问题时可以快速切换。


【降级开关】在发生异常情况时,可以绕开或者忽略某些错误情况。例如展示用户信息需要展示vip等级。如果vip等级服务挂了,可以不展示vip等级,其他信息不受影响。


【流控设置通过对流量设置上限,保护自身服务不被流量打垮。 

运行阶段,我们可以通过【限流】【禁用】【扩容】【回滚】等快速恢复。其中部分能力刚才我们已经提到。


限流】配合上面提到的限流能力,能够在运行时对流量进行调整。


【禁用】直接让一台机器停止提供服务。这样可以在单机问题时,快速移除有问题的机器。


扩容】流量上涨之后,快速扩充机器抗住流量。

【回滚】撤销之前做过的线上变更。我们提到过变更有多个种类,每一种都要考虑回滚方案,保证出问题时快速消除影响。


04落地细节总览


结合上面说的内容,我们再整体一览稳定性在各个环节涉及的内容。这些内容我们会在后面的文章中展开。



会从系统设计、变更规范、故障监测、故障处理、故障复盘这几块分多篇文章来展开。


其中我们可以看到,最后【故障复盘】会用来完善之前的多个环节,这样一来,就形成了一个【增强回路】,让我们的稳定性越来越好。



05稳定性的复杂性


讲了前面那么多,我相信你已经感觉到“稳定性”这件事情很复杂。重要、风险高、环节多、要做的事情也多。


你有这样的感觉非常正常,因为稳定性确实很复杂。


在大厂,往往有很多同学专门负责稳定性。也有稳定性相关的团队,这样团队的TL级别也往往不低,直接挂在CTO的下面。


下面我就再用一张图,帮你梳理下稳定性的复杂性。


上图中,我分别从五个角度做了描述,大家看图就能全方位感知到复杂性。并且这张图里也蕴藏着解决稳定性问题的思路。


所以,如果你想要做好稳定性,你要有充足的思想准备。稳定性是对技术人综合能力的考验。除了技术方面,还有协作能力、耐心等等。


当然,最重要的是,跟着我们的系列文章往下走。当你看完所有稳定性相关的内容后,我相信你一定会很有信心做好这件事情。



今日小结




今天我们开始【系统铁三角】的稳定性内容。我们讲了“稳定性为什么重要”、“故障有哪些种类”、“如何衡量系统的稳定性”以及“如何提升稳定性”。


总的来说,稳定性是一件非常复杂的事情,但非常重要。今天我们的内容只是一个开头,后面我们会有多篇文章来展开这些细节。力求帮助你可以在实际工作中,让系统变得更稳。


强烈推荐你持续关注,这是来自大厂实实在在的干货。

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
消息中间件 缓存 监控
系统稳定性建设实践总结
2020年,注定是个不平凡的一年。疫情的蔓延打乱了大家既定的原有的计划,同时也催生了一些在线业务办理能力的应用诉求,作为技术同学,需要在短时间内快速支持建设系统能力并保障其运行系统稳定性。恰逢年终月份,正好梳理总结下自己的系统稳定性建设经验和思考。
系统稳定性建设实践总结
|
3月前
|
缓存 负载均衡 网络协议
成为工程师 - 如何提高系统的扩展性?
成为工程师 - 如何提高系统的扩展性?
|
3月前
|
存储 缓存 NoSQL
成为工程师 - 如何提升系统写性能(上)
成为工程师 - 如何提升系统写性能(上)
|
3月前
|
存储 缓存 分布式计算
成为工程师 - 如何提升系统写性能(下)
成为工程师 - 如何提升系统写性能(下)
|
6月前
|
消息中间件 监控 前端开发
研发人员如何做好日常工作的稳定性保障
本文介绍了一些研发人员如何做好稳定性建设的工作事项
220 0
|
6月前
|
监控 测试技术 持续交付
【软件设计师备考 专题 】软件质量管理:保证软件的可靠性和性能
【软件设计师备考 专题 】软件质量管理:保证软件的可靠性和性能
167 0
|
运维 监控 容灾
建设强大系统:提升高可用、可靠性和稳定性的秘诀
建设强大系统:提升高可用、可靠性和稳定性的秘诀
1179 0
|
消息中间件 监控 Java
系统稳定性保障设计总结和思考
系统稳定性保障设计总结和思考
519 0
|
存储 缓存 容灾
语音聊天开发,提升系统稳定性的容灾设计
语音聊天开发,提升系统稳定性的容灾设计
|
存储 缓存 监控
【软件测试】稳定性和可靠性测试在软件开发中的重要性
软件测试的某些方面经常会在那些刚接触流程的人中造成混淆——例如在稳定性和可靠性测试之间划清界限。 两者通常可以互换使用,并且有一个共同的目标,即确保系统可以在选定的时间范围内稳定运行。