引言：系统稳定性就像阳光、空气、水一样，只有失去了才知道珍贵。谨以此文写给稳定系统后面默默支撑的朋友，以及不稳定系统背后勇于担当、拼命挣扎的朋友们。
—本文节选自《网易后台技术中心分布式白皮书》
可用率是衡量系统稳定性的指标，任意时刻系统工作正常的概率称为可用率，而所谓“工作正常”是指系统能达到它许诺的服务质量 SLA （ Service Level Agreemenet）。各类系统SLA差别较大，典型的SLA有：
1）memcache等key-value服务SLA通常是99.9%的读写请求在5s内返回。
2）hadoop系统的SLA是确保计算任务在每天早上7:00前完成，按时完成率98%,即全年发生延误次数不超过7次；
要想打造一个真正个高可用（稳定）的系统，必须确定可用率目标。根据业务特点重要程度定义SLA指标，过高过低都不行，一般来说，核心业务的SLA较高，非核心业务或者离线计算业务SLA要求较低。按照一定时间周期统计可用率，使用可用率衡量SLA达成情况，将可用率作为团队的重要考核指标。如上表所示，业界通常使用几个9来衡量可用率，以amazons3为例，其承诺可用率为4个9，即99.99%，那么一年中最多52分钟不可用。做到4个9难度很大，相当有技术含量，按照我们的经验，从发生故障到运维响应和修复故障，整个过程控制在半个小时内就算不错了（包括周末和半夜哦），所以4个9意味着一年最多出两次故障。aws大牛James hamilton说过单机房的可用率最高4个9，如果一个系统号称是4个9，但是没做跨机房高可用方案，那就是耍流氓，是在碰运气。
理想情况下，系统应该自动统计可用率，然而实际业务却很复杂，因此大多采用事故评审机制评审事务造成的不可用时间，人工统计维护可用率。举个例子，一个系统可能有多个重要程度不等的功能点，针对多租户又有不同的SLA要求，不同事故可能影响不同功能点，影响不同租户，很难自动计算出一个可用率。既然很多时候是人工统计可用率，必然存在作弊可能性。关于可用率最常见的误区是“隐瞒事故”，这种行为虽然提高了账面可用率，殊不知小错误易藏，大问题难躲，如此不重视可用率，把风险隐藏起来，草草了事，对长期可用率有很大伤害。
可用率 = MTBF / (MTBF MTTR) ，其中MTBF，Mean Time Between Failure，是平均无故障时间，而MTTR，Mean Time To Repair，是平均修复时间。从上述计算公式可以看出，可用率与MTBF成正比，与MTTR反比,因此提高可用率的办法也可以分为故障避免和故障快速修复两类。
一、故障避免措施
运行好好的系统不会无缘无故的出问题，一定是发生了某些变化，引发变化最可能因素是：1）线上变更，包括上线、扩容等等，只要碰到线上系统的都算。2）软硬件故障，包括进程异常退出，操作系统死机，磁盘故障，网络故障，服务器故障等。3）负载变化，最常见的是负载上升。
故障避免措施也相应的分为三类
变更管理措施。
（1）不管是代码发布上线还是配置修改不管是扩容，还是缩容；不管是变更1台机器，还是百台机器，只要碰着线上都算是线上变更。
（2）所有变更都应该经过测试和演练。以我们自己的云计算项目为例，我们会准备功能测试环境，性能测试环境，联调环境，演练环境，B级线上环境（不太重要），A级线上环境等。一个线上变更，应该经过各种环境测试验证，确保变更不会影响系统本身以及关联系统。测试验证之后，一般是灰度发布上线，而且通常先发布到不重要B级环境，稳定一段时间之后再发布到A级环境。
（3）此外，线上变更应该是可验证和可回滚的。一方面，一定要有一些手段要验证上线结果，持续观察一段时间确认上线成功。另外一方面，线上变更不可能100%成功，务必准备一个回滚方案,遇到升级不成功时第一时间回滚，而不是在线上定位和修复问题。
2.软硬件故障。
由于在大型分布式系统中，磁盘、服务器等软硬件故障是常态，容错应该作为一个系统特性，在设计之初就充分考虑。
（1）简化问题。降低系统出错概率的首要原则是尽可能简化设计，简化架构，简化算法，O(N2)复杂度但简单可靠的算法不见得不能用。尽量避免过早优化，或者只能小幅度提升性能的优化。
（2）提高组件可用性，譬如使用可靠的硬件，使用成熟的开源软件，使用成熟的云计算服务。
（3）通过冗余提高容错能力。冗余可细分为信息冗余，计算冗余和时间冗余三种。信息冗余技术包括，多副本、纠删码等，可应对数据丢失故障。计算冗余是指使用多份物理设备，或者服务进程，单个故障不影响整体可用性，避免出现单点故障。时间冗余涵盖重试、重传等技术，能处理瞬时故障，保证服务成功。容错技术的副作用是掩盖系统自身BUG，加大了系统测试和调试的难度，因此任何容错行为都应该有日志记录。
3.过载处理。
一个没有过载保护措施的系统，遇到过载时所有请求都会超时，服务能力下降为零！过载保护措施必不可少。
（1）做好容量规划，增强弹性扩容能力，避免过载。
（2）过载保护。系统应当可以识别有效请求和无效请求（请求排队太久，发起请求的客户端已经超时，所以请求无效），过载时只处理有效请求，不处理无效请求，不做无用功，尽其所能提供服务。
（3）过载隔离。故障隔离的目标是减小故障影响面，避免系统雪崩，常用技术是超时、防水隔板、泳道模式、保险丝模式.[1]
二、故障修复措施
故障避免措施说了一大堆，但是故障终究难以避免，当出现故障时，关键是降低故障恢复时间:
1.可运维的系统。充分而及时的报警，详细的系统日志和系统运行状态，好用的问题诊断工具，性能分析工具，运维工具，这些都是可运维系统的特征。
2.训练有素的运维团队，没有高素质的运维，以及成熟的管理机制，很难保障系统稳定。
小结
如何打造一个高可用系统？说起来容易做起来难，一切尽在细节中，在于严瑾和坚持，在于事故中磨练出来的团队。
参考文献[1]也谈过载保护和隔离。
http://www.bitstech.net/2013/09/06/graceful-degrading/
数据管理公众号
长按二维码，关注数据管理
联系客服
