系统可用性

        一个网站、系统的战术包括可用性战术、可修改性战术、性能战术、安全性战术、可测试性战术、易用性战术。可用性是在某个考察时间，系统能够正常运行的概率或时间占有率期望值。它是衡量设备在投入使用后实际使用的效能，是设备或系统的可靠性、可维护性和维护支持性的综合特性。采用可用性战术将会阻止错误发展为故障，或者至少能够把错误的影响限制在一定范围内，从而使系统恢复成为可能。对于一个软件和系统，出现故障、不可用的现象是非常重大的事故，那么如何衡量系统的可用性和提高系统系统的可用性呢？

衡量系统的高可用性，一般通过SLA，全称Service Level Agrement，也就是有几个9的高可用性。我们经常可以看到很多公司会宣称自己的系统可以达到99.99%、99.999%等。

工业界通常通过统计故障发生到恢复的时间的方法来测量SLA。一般以年度为单位，统计一年内的系统不可用总时长。具体对应关系如下表：

   对于 SLA 指标来说，9 的数字越多可用性越高，宕机时间越少，系统就可以在给定的时刻内高比例地正常工作。然而对系统的挑战就越大，投入的成本也会越高。 比如 5 个 9 要求系统每年只宕机 5 分钟左右，而 4 个 9 要求每年宕机时间不超过一个小时。这就使得系统需要在设计、基础设施、数据备份等不同层面采取多种方式，甚至增加基础设施投资来保证可用性。

不同系统的可用性要求也是不同的，比如：淘宝、京东等这些电商系统用户量很多，不同区不同时刻都有大量的用户在使用系统，这必然对系统的可用性要求很高。

据以往这些系统的故障统计和不准确地测试数据推测，它们目前的可用性是在 3 个 9 到 4 个 9 左右。相对而言，企业类的工作软件因为通常只在工作时间被使用，或只在某些特定的地区使用，或只给某部分人某一特定时间使用，可用性的需求就会低一些。

       提高系统的可用性有三方面：

错误检测包括三个战术，第一个是信号或者响应，采用组件主动询问方式，在一个系统或网站中即一个组件发出一个信号，并希望在预定义的时间内收到一个来自审查组件的响应，该战术可以用在共同负责某项任务的一组组件内。第二种方式监视组件采用被动方式，就好像我们给老师汇报阶段学习，在系统或网站中即一个组件定期发出一个心跳信息，另一个组件收听该信息。心跳还可用于传递数据。第三个是异常：异常处理程序通常将错误在语义上转换为可以被处理的形式，异常通常与引入异常的程序在同一个进程中。

错误恢复就是回滚，回到之前的状态，分为六种战术，第一种是表决，运行在冗余处理器上的每个进程都具有相等的输入，它们计算的值都发给表决者，表决者发现异常则终止进程，该方法用于纠正算法的错误操作或处理器的故障，通常用在控制系统中。第二种是主动冗余：所有的备份的组件都以并行的方式对事件做出响应，它们的状态都相同，但每次只使用一个组件的响应而丢弃其余组件的响应；主动冗余通常用在客户机或服务器的配置中，在这种配置中，即使发生错误，也可在极短的时间，通常为几毫秒内恢复，比如门户网站采取的策略。第三种是被动冗余：主组件对事件做出响应，并通知其它备用组件必须进行的状态更新。第四种是备件：备件是计算平台配置用于更换各种不同的故障组件。出现故障时，必须将其重新启动为适当的软件配置，并对其状态进行初始化。第五种是Shadow操作：出现故障的组件可以以“Shadow模式”运行，这样可以在系统恢复前模仿工作组件的行为。第六种是状态再同步：主动和被动冗余战术要求所恢复的组件在重新提供服务前更新其状态。错误预防就是设置进程监听器，当一个事物出现错误时，从进程中删除事物。

影响可用性的因素有很多，包括系统故障、基础设施故障、数据故障、安全攻击、系统压力等等。

可用性的保障涉及到很多层面，其中包括但不限于了：

软件的设计、编码、测试、上线和软件配置管理的水平

工程师的人员技能水平

运维的管理和技术水平

数据中心的运营管理水平

依赖于第三方服务的管理水平

对待技术的态度

一个公司的工程文化

领导者对工程的尊重

保障系统的高可用，并不是一个简单的事情，真正的保证高可用，还是需要大量实践的！