最近系统又出了几次故障,虽然每次复盘都会做一些改进,但是,如果系统的完善一直靠故障来驱动,这个代价就有点大了。所以尝试系统化的梳理一下,看看还有哪些方面我们没有涉及到的,及时补齐。

整体思考

一个系统,可以在总体上以下面的视角来看:

系统对外承接用户,对内创造价值;为此,系统作出两个保证:

  • 提供功能性保证:这个是系统的本质,只有提供一系列功能,才能引流,才能创造价值
  • 提供稳定性保证:系统尽最大努力保证,在任何情况下,都对外提供符合预期的功能,当然,只能尽最大努力,至于结果如何,就是我们说的SLA了。

总体上,我们分为两个部分讨论:一个是如何保证稳定性,一个是当稳定性被打破时,我们要做出哪些响应,以及为什么。

稳定性保证

要梳理清楚一个系统如何做出稳定性保证,先从一个系统的边界和组成开始:

常见的系统基本包括:

  1. 用户/流量:系统总要承接流量,或者是直面外部的用户,或者其他系统的流量,我们统一抽象为用户。这一块基本面临两个问题:

    • 容量问题
    • 风险问题
  2. 指令/配置:现在的开发模式,例如,配置化,模版化,引擎化等等,都造成一个现象就是一个系统的输入不只是用户流量,而且包括很多系统自身的指令,配置等,这些操作会让系统从一个状态转移到另外一个状态。这部分输入可能存在的问题是:

    • 很容易成为盲点:一个开发随意打开了一个线上开工谁都不知道,结果导致系统的状态发生变化,或者系统隐藏bug被触发。
    • 造成的影响可能会更加严重:因为这些指令或者配置往往会很大程度让系统发生根本性改变,一旦出错,系统的损失会更加巨大
  3. 第三方依赖:这是常见的问题,现在基本都是微服务架构,所以,这块的一些常见工作大家基本都知道,比如,超时控制,降级等

  4. 功能/性能:这块基本取决于系统的逻辑+数据,虽然我们期待在经过测试之后,功能以及性能没有问题,但是大家都知道这基本不可能

  5. 数据:系统的核心,现实资产的抽象,一般我们都是通过冗余来保证数据的稳定性。

  6. 资源:底层支撑层,例如,CPU,内存等

上面在每一个点都有可能出现问题,我们需要经常思考如何应对:

故障还是发生了

我们尽量做出稳定性承诺,但大家都知道,故障还是可能发生,一旦故障发生,我们要启动下面的流程:

里面的每一步都需要逐步完善和细化,但目标是明确的:

  1. 事中:快速止损。为了实现快速止损,需要快速定位,为了快速定位,需要运维的报警体系,需要各个业务平台的协同定位等等一系列流程
  2. 事后:尽量恢复和补救。两个层面:对内,挽回资产,对外,补偿用户。这两个一定要思考清楚,一个故障不只是恢复了那么简单,要考虑清楚对公司资产,对用户的种种影响。

流程建设

只有当即使做了好多工作,还是发生故障之后,才会知道流程的重要性。

系统化思考

思考系统稳定性的时候,具体到每个系统都要差异,但是,有一些系统性的思考方式我觉得可以通用的: