术语定义

可靠性：系统是否具备无差错地执行预期操作的能力。
可用性：为了执行预期操作，系统当前可运行的能力。
可用性百分比：（该期间的总秒数-系统宕机的秒数）/该期间的总秒数。
风险缓和：通过降低风险发生的可能性，或者降低风险发生时的严重性，来降低风险的影响。
风险管理：在解决风险和缓和风险之间做出选择。
比赛日：通过测试来触发系统中某个失败模型，然后观察你的操作人员和工程师如何进行响应，包括他们如何执行恢复计划和容灾计划。
优雅降级：在当前服务缺少某个故障服务的结果时，可以通过降低工作量来尽可能地完成工作。
优雅补偿：即使无法完全满足用户的需求，但是按照为用户提供价值的方向去改进。
服务等级协议：是一个提供某种级别可靠性和性能的承诺。

可用性

导致低可用性的原因：

• 资源耗尽
• 预期之外的压力变化
• 流动行为的增加
• 外部依赖
• 技术债务

提高应用程序可用性的五个要点：

• 时刻考虑应对故障
• 时刻考虑如何伸缩
• 缓和风险
• 监控可用性
  • 服务器监控
  • 配置变化监控
  • 应用程序性能监控
  • 人为测试
  • 报警
• 以预测和确定的方式应对可用性问题

风险管理

收集风险模型的来源：

• 开发人员的头脑风暴
• 已知的重点售后支持问题
• 已知的安全风险和漏洞
• 已知的系统不完善或缺失的能力
• 已知的性能瓶颈点
• 已知的流量峰值和变化
• 来自于业务负责人、支持人员或者用户的特殊考虑
• 已知的系统技术债务

管理系统中的风险的基本步骤：

• 识别风险
• 消除最严重的风险
• 风险缓和
• 定期检查

风险模型：

风险ID：风险的唯一标识。
系统：包含风险的系统、子系统或者模块的名称。（如：“前端”、“主数据库”、“服务A”）

所有人：负责该风险的个人（或者团队）的名称，同时也负责制订该风险的缓和计划和解决计划。

风险描述：该风险的概要描述。

标识日期：识别该风险并将其添加到模型中的日期。

可能性：该风险发生的可能性（低、中、高）。

严重性：该风险发生的严重性或者影响（低、中、高）。

风险缓和计划：描述了可以使用的或者正在使用的，用来降低该风险严重性或者可能性的风险缓和措施。

状态：该风险的当前状态。这个值通常是“活跃”、“已缓和”、“正在修复”或者“已解决”等内容。

ETA：该风险距离计划解决日期（如果有的话）的估计时间。

监控：是否对该风险的发生进行了监控。如果是，则包含实现监控的步骤。如果没有监控该风险，应该标明原因，以及计划对其进行监控的估计时间。

触发计划：如果该风险真的发生，计划如何来处理它。触发计划通常是一个管理层面的计划，而不是一个事件-响应的计划。

备注：记录任何不适合记录在风险描述中，或者不属于风险描述的信息。

跟踪ID： 如果通过一个缺陷跟踪系统或里程碑跟踪系统来管理风险，可以用该列来记录该风险在系统中的跟踪ID。

历史：该风险在过去是否已经发生过？什么时间？发生频率？等等

定期维护风险模型（如：每月、每个季度）：

• 发现新风险
• 删除旧的风险
• 更新可能性和严重性
• 检查优先级高的风险
• 检查优先级低的风险

服务和微服务

定义服务的指导原则：

• 1. 特定的业务需求
• 2. 清晰和独立的团队所有权
     一个单独的服务应该由一个3人到8人的开发团队来负责和运行。这个团队负责该服务的所有方面。
• 3. 天然隔离的数据
• 4. 共享的能力/数据

如何响应服务故障？

• 可预测
• 可理解
• 对当前情形是合理的

如何确定故障？

• 乱码响应
• 表示致命错误发生的响应
• 结果可以理解但是所需的结果不匹配
• 结果超出预期范围
• 没有接收到响应
• 接收响应很慢

如何让应用程序具有伸缩性

什么是“两次失误的高度”？

如果你曾经操作过无线电控制（R/C）飞机，可能听说过那句话“让你的飞机保持两次失误的高度”。

当你学习如何操作R/C飞机，尤其是开始学习如何进行特技飞行时，你会学得很快。失误其实就相当于高度，出现一个失误，你就失去一定的高度。当你失去太多高度时，坏事就发生了。因此，让你的飞机保持“两次失误的高度”意味着让你的飞机飞得足够高，从而有足够的高度从两个不相关的失误中恢复飞行。

为什么是两次失误？这很简单。你总是希望让飞机飞得足够高，以便可以从一次失误中恢复飞行。现在，假设你犯了一个失误，失去了一些高度。在从这个失误的恢复过程中，你还会希望飞得足够高，从而保证能够从另一次失误中恢复飞行。你可以想象一下：在恢复飞行的过程中，你通常压力很大，而且可能处于一种惊恐的情绪中，很可能做出一些反常的事情——正是这种情形让你可能产生另一个失误。因此如果你飞得不够高，就会坠机。

换一种角度说，如果你能够飞行两次失误的高度，你总有一次从失误中恢复的备份方案，即使你正在从一次失误中恢复。

什么是“由独立团队负责的服务架构（STOSA）”？

STOSA对于由多个开发团队来负责并管理一个或多个系统服务的大型组织来说，是一个重要的指导原则。

达到STOSA，要满足的条件：

• 有一个基于服务或者微服务架构建立的应用程序。
• 有多个开发团队负责构建和维护这个应用程序。
• 程序中的所有服务必须分配给某个开发团队。
• 不允许有服务被分配给多个开发团队。
• 一个开发团队可能会负责多个服务。
• 开发团队负责管理服务的所有方面，从服务架构到设计再到开发、测试部署、监控和故障处理。
• 服务之间有清晰的边界，包括文档编写良好的API接口。
• 各服务负责维护之间的服务等级协议，开发团队负责对服务进行监控和报警。

管理STOSA应用的STOSA组织

服务所有者负责：

• API设计
• 服务开发
• 数据
• 部署
• 部署窗口
• 产品变更（服务所需的所有产品变更，例如负载均衡器的设置和系统调优）
• 环境
• 服务SLA
• 监控
• 值班/突发事件响应
• 报告（向其他团队，消费者或者依赖服务，发送内部报告，以及管理服务的运行健康报告）

基础设施团队或运维团队：

• 服务器/硬件
• 工具集
• 数据库（数据本身、数据模式以及对数据的使用，通常还是由服务所属团队来管理）

基于STOSA的组织架构

SLA的性能检测方法：

• 调用延迟
• 流量
• 运行时长
• 错误率

云服务

基于云的服务基本类型：

• 原生资源
• 托管资源（基于服务器）
• 托管资源（不基于服务器）

可伸缩的计算选项：

• 云服务器
• 计算分片
• 动态容器
• 微计算（体积小、高度可扩展、基于事件驱动的运行环境）