sre document
SLA
SLA事前

SLA事前

现在我们要做的事情就是如何提升SLA。

依据笔者的经验，事前其实是最重要的一环，如果老板就爱看表演式救火，那这一段事情是完全不用的，到时候看着事故发生的时候各种忙乱。看着就很可笑和存在感。

事前要搞的事情有如下一些事情需要做的：

  1. 可用性评审
  2. release流程
  3. 故障处理流程

可用性评审

笔者很不同意运维的同事把软件产品当作黑盒来看，如果是那样的话我们就很难深入。

架构评审

在Google里这个过程通常被称作NALSD（非抽象大系统设计），也就是把握、设计和评估大型系统的能力。通过白版图的方式，开始进行系统的资源规划，还要考虑到各种扩容和故障域，并将其设计重点放在具体的资源方案中。

在广义上NALSD分为两个阶段

基本设计阶段

  1. 可能吗？

Note

设计究竟能否实现？如果不考虑资源的限制，我们能做出更满足需求的设计？

  1. 我们还能做的更好吗？

Note

我们的设计是在O（N）时间内解决问题吗？我们能否更快地解决它，比如O（1）或者O（ln（N））

纵向扩展基础设计

  1. 这还可行吗？

Note

考虑到资金和硬件的限制，此设计是否可扩展？如有必要，分布式设计能满足哪些要求？

  1. 它有弹性吗？

Note

这个设计能否优雅地发生故障？当这个模块发生故障时会发生什么？整个数据中心出现故障时会怎么样？

  1. 我们还能做的更好吗？

Note

有些设计可以有可能通过大部分阶段，但是走到最后还是会困难重重。

容量管理

  1. 服务模块容量的计算公式。

Note

这个公式是为了以后扩容和缩容来提供可靠的依据。最好是经过压测来证明的。这个要完整并且准确的数值，那还是很依赖压测人员水平的。

计算公式里可以包含CPU，内存，GPU，网络，磁盘，LOAD 等变量信息。但是这里对于数据库这种的需要考虑数据量大小等等。

这里不需要包含上下游，因为上下游有自己的容量计算公式

  1. 业务架构是否高可用。

Note

这里主要是怕在设计阶段有单点风险。有些单点风险业务部门可接受比如停30分钟，那就不用太在意。但是这些必须要落到纸面上，防止后续扯皮。

  1. 是否具备容量分区能力。

Note

一般可以按照地域来进行分区，或者按照不同用户等级来进行分区。

基础中间件

  1. 中间件可维护性

Note

这个中间件是否开源，以及开源协议是什么，是否方便后续二次开发。

在业内是否有大量使用，公司现在是否有业务在使用中。在国内至少要几个中厂开始用才可以。（大厂很多都是自己开发了）

社区是否活跃。

  1. 对于该中间件的了解程度

Note

公司内是否有同学擅长该中间件，如果没有倾向用云厂商PAAS服务。

和同类中间件相比，该中间件的优势和劣势。

选择该中间件的的理由是什么，这种特别是在整个公司还没有用过的情况下。

这个中间件适合哪种场景，可以给未来一些业务或者现有改造有一些参考。

  1. 异常处理

Note

该中间件历史上出现过哪些故障，我们现有的版本（以及客户端版本）是否可以规避这些故障。

目前该中间件还有哪些issue是我们无法接受的。

  1. 数据安全性

Note

如何保证数据存储的安全性。

如何保证数据传输的安全性。

  1. 架构稳定性

Note

是否有成熟的集群方案，如果没有没有集群方案，那如何保证可用性。比如RabbitMQ这种就只有mirror方式。

评估使用哪种集群方案。以及集群使用了哪种分布式一致性协议，Paxos、Raft还是ZAB，这种为了防止后续大规模的问题。

该业务适合使用哪种集群方案。

这个中间件有哪些容错措施。如限流，熔断，故障转移，降级等。

  1. 数据库备份和恢复方案

Note

增量备份方案，这个跟RPO的时效是密切相关。

全量备份方案，这个也跟RPO的时效密切相关。

备份恢复和有效性验证。

数据丢失如何处理。

数据污染如何处理（比如运营同学意外更新）

RPO时效和恢复时长

  1. 硬件资源选型

Note

服务器如何选型。

中间件主要主要消耗什么硬件资源（CPU/内存/磁盘/网络）：磁盘这里要注意下，有高效云盘，ssd云盘，ESSD, 本地ssd。 而且每家跟cpu还有一定的绑定关系。网络也一样的。这个在海外云厂商上问题更大。

  1. 设计容量

Note

QPS：每秒请求

TPS：每秒事务

PCU：峰值并发用户数

  1. 性能趋势

Note

数据量：就是在数据量增加的情况下的性能变化趋势，这个也是依赖压测。

QPS量

架构健壮性

  1. 架构可扩展性

Note

业务任何模块都需要具备水平扩展能力。

水平分片，即支持多区域或分区能力 （即区域的扩展的能力，例如：中国大陆区域、北美区域、欧洲区域等。）

  1. 故障转移

Note

在故障发生时，需要多长的迁移时间，如果过长那是否需要灾备就要提出来并最终确认。

在故障发生时，能够迁移多大规模。这个一个是容量问题，还有一个是数据一致性的问题。

  1. 异常处理

Note

如何处理接口重复调用

如何处理数据重复消费

服务模块之间可能有哪些的逻辑处理上的问题

集群异常情况如何处理

  1. 集群整体不可用

  2. 集群性能骤降（例如：集群可能在某些个别模块达到一定程度后，集群性能整体急剧下降）

  1. 服务自我保护能力

Note

核心功能限流，熔断，降级能力。

  1. 具备对抗基础设施不可抗力因素的能力

Note

这个一般用混沌测试来进行，这个有一套单独的方法论。当年猴哥翻译了这本《混沌工程》可以很好的参考。

具备对抗网络波动的能力: 比如网络中断，响应延迟，不回FIN等等问题。

具备对抗硬件/操作系统层面的异常的能力：系统不响应，IO夯住，内存翻转等等。

发布管理

在很多公司和场景中，发布是导致故障最多的环节。所以整个发布流程很重要。

首先说一下发布原则：

  1. 对于线上后端服务来说，小步快跑原比一次性大量发布要好，小步快跑出了问题可以很快的回退，但是一次大型发布涉及的部分就非常多，要回退会比较麻烦，很多时候只能硬着头皮往前冲了。
  2. 必须走发布流程。流程怎么定义的就怎么走，不要想着绕过系统，后面会被坑的。

上面第二点我们就捧到过，原先我们有个需求，云厂商一时无法满足，当时他们产品的人找了他们研发同事直接在设备上改了。一直没啥问题，直到有一天突然要做升级，这个需求从来没有在他们内部出现过，导致我们当时在他们这个集群的服务都挂了。

  1. BUILD阶段(代码提交PR到代码编译完毕成一个新的二进制):
    1. 触发travis或者enkins job完成以下工作
    2. 检查可编译,编译成一个二进制
    3. 黑盒测试确认功能性
    4. Sonar确认测试覆盖度 > 80%
    5. 发布到maven仓库中。（要进入到发版流程的制品必须发到release分支下，该分支不允许有覆盖，沙箱和线上环境只会从release分支获取版本。）
  2. 沙箱环境
    1. 部署至沙箱环境,给沙箱环境建立稳定请求流
    2. 回归测试通过
    3. 混沌测试通过
    4. 全程沙箱监控健康(无报警)
  3. 线上环境
    1. 通知:
      1. 企业微信发布群:发布群要包含测试/业务责任人/上一级leader/上下游业务/可用性小组/安全小组/CS。非常核心的客户也需要提前通过CS通知。
      2. 业务开始发布前15分钟,同步发布的checklist,同步发布的风险。
      3. 业务开始发布时,同步xxx业务xxx模块开始发布的信息。
      4. 业务发布后10分钟同步业务关键指标。
      5. 业务有问题同步,执行操作及时同步。
      6. 发布关键指标确认完成后,群里同步xxx业务xxx模块发布结束。
      7. 发布正式通知到前线CS,需要评估风险等级(低/中/高),起始时间-终止时间,修复CSD,业务影响范围。
    2. 灰度一：免费集群等，灰度观察周期不少于1天。

发布流程

下面这个是我们自己的一个发版系统的相关流程。这里的研发不光是研发人员，也有可能是测试和运维，因为这2个岗位也需要提交变更的需求，比如线上基础服务的配置，线上自动化测试程序的镜像更新等等。

rellease

在这里我们没有看到蓝绿发布或者金丝雀发布。这些其实都集成在发版系统中了。

蓝绿发布

蓝绿发布也叫AB发布，也就是线上有2个版本，当流量在A的时候，我们先更新B的服务，经过测试后把流量切换到B上，这时候A上面的不更新。万一B上新更新的有问题，我们就直接回退流量到A上。这种交替发版的逻辑我们称之为蓝绿发布。

这种发布模式了导致了线上必然有一半的应用服务器是在空闲状态的。不过这个也需要看整体的成本分布是怎么样的。但是由于现在都是在容器平台上，所以这些资源也可以分配线上服务使用的。

金丝雀发布

金丝雀发布的含义是逐步的更新，比如线上有个服务有10个容器在跑，我们更新其中一个，这样线上对外就是10%的流量是新版本，如果出问题就是10%的流量出问题，如果还在你的SLO标准范围内就行。

当然你最好提前把流量从这个容器上摘除。验证通过后再放回流量进来。

以上两种发布模式都需要有一些前提来执行。

  1. 两个版本本身以及产生的数据是兼容，不然万一有流量分到2个版本可能会产生不同的有冲突的数据。
  2. 负载均衡设备可以根据流量标签来分配流量。
    1. 根据标签把测试流量分到新的版本上。
    2. 测试的流量可以走完完整的正常数据流，但是在数据库存储的时候标记为测试流量。
SLA