阿里云宕机故障 - 思考如何保障系统的稳定性

本文转载于本人的微信公众号中的文章，最新文章请关注右侧公众号。

目录
背景与挑战
何为系统稳定性
影响系统稳定性因素
如何保障系统稳定性
总结

一、背景与挑战

1. 背景

3月3日凌晨，阿里云宕机故障 --- 惊魂三小时的故障，让华北地区不少公司的APP、网站和内部系统纷纷瘫痪。消息瞬间占领的社交、媒体的头条。有网友调侃道到，“一大波程序员、运营和运维从被窝爬起来去公司干活了”、“ 阿里云一年一宕机，今年特别早”。
  拥有雄厚资金、技术和大量的人才的阿里云尚且如此，那么我们中小公司又要如何见招拆招？
  在《微服务架构实践》文章中提到，我们面对的业务主要满足两大类业务需求：面向餐饮企业在餐饮新零售下的经营需求、运营需求和面向产品及运营团队。可以理解为我们就是为餐饮企业提供信息化解决方案的ISV。没错就你大脑中浮现的，类似给三大运营商、电力企业等承接做信息化系统的公司。
  公司的SaaS平台中，有一条产品线 --- 外卖（此外卖非彼美团、饿了么外卖）姑且称之为“云平台外卖”，我们在哪些方面做了稳定性、又是如何落地的？我们从一个用户视角的订单全生命周期流程中，来看下我们“云平台外卖”处在什么环节：

• 以普通用户的视角来看，一个外卖订单从下单后，会经历支付、商家接单、配送、用户收货、售后及订单完成多个阶段。

• 以技术的视角来看，每个阶段依赖于多个子服务紧密配合，确保订单顺利完成。

2. 挑战

• 流程较长且实时性要求高
  外卖订单业务是一个需要即时送的业务，对实时性要求很高。从用户订餐到最终送达用户，一般在1小时内。如果最终送达用户时间变长，会带来槽糕的用户体验。

• 订单量高且集中
  一天内订单量会规律变化，订单会集中在中午、晚上两个“饭点”附近，而其它时间的订单量较少。这样，饭点附近系统压力会相对较大。

我们的“云平台外卖”是处在商家接单的环节；商家接单，也是一个非常复杂的处理流程，我们抽象成简单的流程：

我们面临的挑战:

• “实时”接单无延迟

• “实时”接单无丢单

任何一种情况发生，客户都会面临着营业额减少甚至客户门店被外卖平台关闭的风险。

二、何为系统稳定性

软件系统的稳定性，很难有一个恰当的模型表述。如果采用数字量化的话，我们也可以采用SLA服务协议说明系统的稳定性。
正所谓“千里之堤，溃于蚁穴”，看似无关紧要的代码片段可能会带来整体软件系统的崩溃。

三、影响系统稳定性因素

软件系统稳定性影响因素比较多，我们从软件工程开发过程中，梳理出常见的因素：
我们要在软件设计的阶段，要充分考虑系统稳定性因素；一旦考虑不周，当线上系统面临快速增长的业务时，噩梦就会连连。

四、如何保障系统的稳定性

1. 系统稳定性保障的指导思想

• 负反馈调节法

• 确定目标，并加入控制条件；根据反馈结果不断调整，朝着可能性空间缩小的方向发展，使目标差在一次次控制中慢慢减少

2. 系统稳定性保障的基本准则

• 规范流程

• 自己不作死

• 不被队友搞死

• 多部门间的协作联动

3. 系统稳定性保障的技术措施

我们从多个方面通过严谨的流程、架构、技术、测试以及运维保障系统等手段来保障系统的稳定性。但是，要保障系统的持续健康运行，还需要多部门间的积极的协助联动。

五、总结

上述梳理，我们知道线上系统故障主要是：

• 自身系统的问题

• 外部系统的问题

• 基础设施的问题

所有的软件系统问题，最终症结在于架构、产品质量和技术工程方面的问题。
需求千万条，质量第一条。架构不合理，开发运维两行泪。

-EOF-