服务稳定性研究-认知篇

1,565 阅读5分钟

小知识,大挑战!本文正在参与“程序员必备小知识”创作活动。

在移动互联网时代,用户群的积累比之前更容易,但同样,也会因为糟糕的用户体验,而快速流失用户,哪怕是号称独一无二的 12306 网站,也在不断优化系统来提升用户体验;而在后移动互联网的物联网时代,软件工程师需要和硬件工程师配合,来保证提供的服务稳定和可靠。对,我们的产品就是为了实现用户价值,并提供非凡用户体验

如果说良好用户体验是增长的基础,那么良好的操作性、稳定的使用体验就是用户体验的基础,排除掉软件可操作性(这一块需要依靠专业的设计师),剩下的就是客户端(这里的客户端包括各种小程序、WebApp、H5 页面等)和服务端,这一切都基于我们软件工程师来构建可靠、稳定的软件系统。然而,随着我们服务的用户量越来越多,服务复杂度也越来越高,我们的系统为了可维护性,也会在业务架构和系统架构上进行调整,现在流行的微服务架构也因此应运而生。然而微服务架构也并不是没有副作用,例如它会增加维护成本和系统稳定性建设的成本。

那么,什么是系统稳定性?这里我们引用百度百科的定义:系统稳定性是指系统要素在外界影响下表现出的某种稳定状态。为了方便,本文阐述的系统主要指软件系统。那么如何衡量系统稳定性的高与低呢?一个常用的指标就是服务可用时长占比,占比越高说明系统稳定性也越高,如果我们拿一整年的数据来看,常见的 4 个 9(99.99%)意味着我们系统提供的服务全年的不可用时长只有 52 分钟!它其实是一个综合指标,为什么这么说?因为我们在服务可用的定义上会有一些差别,常见的服务可用包括:服务无异常、服务响应时间低、服务有效(逻辑正确)、服务能正常触发 等。

服务稳定性研究-三大认知

1 我们无法做到百分百的可靠、可用,要基于成本收益进行权衡

我们实在很难计算我们设计的系统有多少的可用性,因为影响一个系统的稳定性的因素实在是太多,除了软件设计,还有硬件,还有第三方的服务,包括网络,以及“挖掘机”。

工业界中,通常会把服务不可用的因素分成两种:一种是有计划的,一种是无计划的。

无计划的

  • 系统级的故障 – 包括主机、操作系统、中间件、数据库、网络、机房中的电源以及外围设备;
  • 数据和中介的故障 – 包括人员误操作、硬盘故障、数据错乱;
  • 还有:自然灾害、人为破坏、以及供电问题。

有计划的

  • 日常任务:备份、容量规划、用户和安全管理,后台批处理应用;
  • 运维相关:数据库维护、应用维护、中间件维护、操作系统维护、网络维护;
  • 升级相关:数据库、应用、中间件、操作系统、网络、包括硬件升级。

统称为,天灾、人祸、灵异事件(未知之迷)、变更。

我们很多时侯以为我们知道,其实我们还有很多不知道的因素,我们只看到了冰山一角。我们思考一下,如果要达到5个9的可用性,在一年内只能是5分钟的不可用时间,如果按一年只出1次故障,就要在五分钟内恢复故障,这意味着什么?

如果你没有一套科学的牛逼的软件工程的管理,没有先进的自动化的运维工具,没有技术能力很强的工程师团队,怎么可能达成这个目标。

要做出高可靠、可用的稳定系统,就需要一套严谨科学的工程管理,其中包括但不限于:

  • 软件的设计、编码、测试、上线和软件配置管理的水平
  • 工程师的人员技能水平
  • 运维的管理和技术水平
  • 数据中心的运营管理水平
  • 依赖于第三方服务的管理水平

深层次的东西则是对工程这门科学的尊重:

  • 对待技术的态度
  • 一个公司的工程文化

说到底,可靠性和可用性的提升,是需要成本和投资的。要做到100%的可靠、可用,是一项无法完成的工作,更是一项高昂的支出。

2 一切都可能失效,要为失败进行设计(Design for failure)

我们的系统构建在硬件、操作系统等基础设施之上,依赖中间件、数据库、网络,依赖于三方系统,所有的这些都有可能失效,我们必须基于这些都会失效进行设计,Design for failure,为失败做准备,为此,专对性的做可靠性设计和可用性设计。而这些需要大量的权衡,没有一个万能的方案。

3 所有的设计是否有效,需要演练验证

我们所有的设计是否有效,应该像物理学、化学一样,要得到验证,没有验证的东西都是不可信的。我们应利用FMEA分析法,根据故障场景和后果进行可靠性设计验证、可用性设计验证、各种故障预案做实验,证明如我们期望的一样运行。