如何使服务具备高可用性

一、概述

可用性案例

在开始之前，先给大家看下可用性的badcase案例：

可用性问题后果

• 用户损失

–用户体验伤害

–经济损失

• 公司损失

–经济损失

–客户信任

–技术形象

本文探讨范围

• 以请求访问型的用户产品为示例

–用户产品

–平台化产品

–内部系统

• 目录

–高可用性定义

–如何度量

–影响要素分析

–如何保障

二、高可用性定义

可用性等级（Availability）定义

Availability = Uptime / (Uptime + Downtime)

通常情况下，Availability达到99.99%或99.999%即可称为服务具备高可用性。

从用户角度出发

• 对于提供的服务，用户能够获得符合质量预期的服务比例
• 不可用

–不可访问

–DNS解析失败、链接失败

–服务不存在，或被封禁

–服务内部错误

–低质

–慢，页面错乱、核心元素缺失

相关名词

• SLA

–服务可用性等级，常说的几个九

• MTTR

–平均故障恢复时间，即从故障发现到止损点的时间差

• MTBF

–平均故障间隔时间，即从上一次故障到本次故障的间隔时间，常用于硬件产品

三、如何度量

困难

• 部分Down

–部分功能：子系统、页面、元素等

–部分用户

–间歇性：时间难以衡量

• 一个指标

–不同功能、用户是否一视同仁？

–浏览 vs 购买 vs 优惠卷

• 服务端指标 到 用户端 的“漫漫长路”

–服务端指标 vs 用户实际感受指标

–难以全面采集（端支持）

计算方法

• 时间 => 请求计数

–有效处理的请求次数 / 总合法的请求次数

• 用户指标 << 服务指标 << 模块指标 << 详细指标

–用户指标反映用户实际感受质量

–服务指标反映服务综合质量

–细分加权求和

–分功能指标反应模块服务质量

–详细指标有助于发现和定位问题

• SLA

–服务可用性等级，常说的几个九

–计算公式：1 –（失败次数 + 超时次数）/ 总请求次数

• MTTR

–平均故障恢复时间，即从故障发现到止损点的时间差

–计算公式：(故障恢复时间点 – 故障发生时间点) / 故障次数 * 模块重要性权重 * 模块流量权重

• MTBF

–平均故障间隔时间，即从上一次故障到本次故障的间隔时间，常用于硬件产品

–计算公式：（服务总可用时间-服务总故障时间） / 总故障次数

相关度量

• 关联其他指标

–服务容量

–流量：QPS

–性能：平响

–收入

• 关注变化

–变更

• 设置预警

–报警策略

四、影响要素分析

故障分布

下图是一个常见的服务故障分布情况：

故障时间

• 计划中的” Downtime”

–非兼容性升级

–数据一致性处理

–故障演练

• 故障（Failure）导致的” Downtime”

故障位置

• 硬件故障

–机器（含机器的各组成部分，如磁盘）

–IDC设施：交换机、链路、空调、电力等

–外部设施：运营商网络

• 软件缺陷

–代码BUG

–异常应对能力

故障触发

• 外部操作变更

–硬件及系统、网络

–软件：程序、配置、数据

• 外部流量因素引发的软件故障

–漏洞请求引发：特殊请求导致系统变慢、崩溃

–请求量、频次及构成引发：超出容量

五、如何保障

原则

• 减少发生

–降低故障出现频次

• 降低影响

–一旦发生，确保尽可能小的影响面

• 加快恢复

–能够快速发现、定位、修复

方法

变更控制

• 架构环节

–Design for Failures

–单机故障

–机房/区域故障

–流量异常

–自身异常

–下游异常

–清晰的服务部署

–避免单点

–消除跨逻辑机房的交互

–合理的容量评估

–模块承担容量限额

–Cache崩溃对流量的影响

–第三方容量

–安全设计

• 编码环节

–严谨的编码，主动容错

–主动容错：函数执行失败、RPC调用失败、经过推敲的错误处理（任何一个函数、外部输入）

–超时控制

–使用NS名字服务

–重试的考虑：链路连锁反应，重试雪崩（容量计算/重试位置）

–模块隔离：高内聚、低耦合

–代码性能、安全性、可测性

–全分支覆盖自测；CodeReview

• 测试环节

–功能/性能/稳定性/兼容性/安全性测试

–交付确定性

• 上线环节

分级发布、回归测试

快速回滚

重视数据变更的风险

服务容量管理

• 服务冗余

–实例N+2

–支持熔灾 + 发布时摘流量

• 容量评估

–合理评估

–适当降低冗余

• 容量压测

–建立例行压测机制，定期获取系统容量瓶颈

–容量管理：根据流量合理部署实例，实现实例分配最优化

入口流量调度

• 能力

–流量的接入与调度能力

–粒度 && 速度

–限流：屏蔽与限制能力

–上下游的流量分配协调

–服务流量IDC调度 >> DB IDC流量激增

• 场景

–机房规模的故障

–接入故障、骨干网故障

–攻击

服务降级

• 先分级

–功能分级，开关

–区分核心功能

–流量分级，调度

–区分流量的相互影响

–区分流量的价值

• 分级场景

–服务过载：超出处理能力

–全局流量增加

–部分用户流量增加

–容量降低

–服务的子组件整体故障

–依赖的第三方服务整体崩溃

• 再降级

–功能降级

–丢弃非核心功能

–质量降级（减少计算）

–降低服务质量

–流量降级

–丢弃非核心流量

–配额

• 降级实例

–微信红包，异步延迟对账事物

–地图，基础地图功能，优先于动态路况

快速回滚

• 做好灾难恢复

–可恢复性

–备份的有效性

–恢复速度

• PaaS化

–故障自动发现，NS自动摘除

–分级发布

–一键回滚

• 自运维规范化

–备份与回滚

预案与演练

• 预案

–把预案内容转换为系统的设计和实现

–优先从系统设计和实现角度保证可用性

• 定期演练

–制造真实故障

监控报警

• 有效的指标

–整体及细分可用性

–核心业务指标

–程序指标

–依赖指标

• 回答如下问题

–会发生问题吗？

–发生问题了吗？

–哪里发生了问题？

–发生了什么问题？

–会自动恢复吗？

其他事项—可用性CheckList

• 感知

–服务关键指标

–关键依赖指标

• 隔离

–逻辑服务单元拆分

–单点消除

–核心功能逻辑独立

–核心服务资源优先

–流量成分的细分

–线上线下隔离

–容量规划

–关联解耦

–外部依赖消除

–分级发布

–变更流程规范

• 止损

–配置热加载

–快速回滚

–防攻击

–单机容错

–过载保护

–服务单元级流量调度

–服务降级

总结

• 建立对变更的控制能力（减少发生）

–架构、编码、测试、上线

• 建立对系统的控制能力（降低影响，加快恢复）

–容量管理、隔离、入口流量调度、服务降级、回滚

• 建立故障模型（减少发生，降低影响，加快恢复）

–考虑每一种可能出现的故障，以及是否都能够自动或手动应对

• 建立度量和监控（快速发现）

–对系统运转指标有清晰的度量和检测