高可用

《可伸缩架构：面向增长应用的高可用》读书笔记

2017-11-13  本文已影响143人  zlup

术语定义

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

可用性

导致低可用性的原因：

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

风险管理

收集风险模型的来源：

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

风险模型：


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

服务和微服务

定义服务的指导原则：

如何响应服务故障？

如何确定故障？

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

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

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

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

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

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

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

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

达到STOSA，要满足的条件：

管理STOSA应用的STOSA组织

服务所有者负责：

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

基于STOSA的组织架构

SLA的性能检测方法：

云服务

基于云的服务基本类型：

可伸缩的计算选项：

上一篇下一篇

猜你喜欢

热点阅读