如何在中小企业中实施SRE

发表于 更新于 分类于 本文字数： 5k 阅读时长 ≈ 5 分钟

区别

在大型企业中都会有SRE的专职部门，负责整个系统的可用性，但是在中小企业中一般不会设置这种部门，可能会有个把人在运维组织里做SRE相关的事务，或者根本没有。组织架构的部分可以参考SRE的组织架构 | 樱桃沟夹事

组织文化

这个是大型企业和中小企业都一致的。我们需要将可靠性作为一个业务指标，使其能够在其他业务要求优先的情况下进行谈判和交易。而不是只把产品功能和收入，DAU作为唯一的指标。

SRE通过定量的方法，明确了运营可靠性与顾客满意度的关系。

通过优先考虑长期的、客观的成功度量标准，SRE促进了可靠性的持续谈判，其结果得到了更广泛的组织目标的支持。

错误预算被认为是一个基本的，不变的属性，任何SRE文化有效性都可以通过它来判断。将可靠性提炼为单一的数字方便传播。

如何建立SRE思想

首先我们要知道SRE是以客户为中心，真正从客户角度了解使用产品的体验和痛点。因此我们知道有些内部问题可以通过降级，熔断的方式来处理。

整个研发团队需要拥有一套明确定义的工程原则和发布门禁。

  1. 有助于产品体验标方面标准化整个公司的生产准备。比如响应时长，资源冗余度，是否需要3AZ，是否需异地跨厂商的灾备等等。
  2. 设定整个组织的服务质量期望。这个可以根据不同的产品和功能模块进行不同的设置。在一些ToB的企业中还可以针对不同等级的客户来设置不同的服务质量。
  3. 不同开发阶段的特性和产品都要设定服务质量期望。比如产品或者模块刚beta版本上线，那整个SLA的要求跟正式版本肯定会更低。

在整个软件的开发周期中引入商业团队，以便每个人都能有正确的期望。

  1. 因为需要商业团队来确定未来一年的期望规模，研发团队根据这个规模来确定整体架构等等。这个之前在iClick的时候，我们CTO就需要销售来确认客户未来1年的使用规模，你可以一次不准，但是不能老是不准。
  2. 商业团队更知道客户对于哪些功能模块更着急，如果有不同客户针对不同功能有不同的优先级，那就产品和商业团队最终权衡优先级排期。
  3. 产品发展路线图，这个不光是给研发团队看的，也是给商业团队看的。

这样促进工程师和商业团队的持续沟通，以便最大限度的减少大量新客户加入时的意外情况。

在内部发布基于价值的路线图

  1. 路线图需要有明确的更新节奏
  2. 过程尽可能自助，方便任何干系人都可以找到最大的挑战并根据需求发出危险信号。

老实说这个对于大部分组织来说都比较难，毕竟大部分组织的价值就是利润。

使用Kano模型来演示并权衡新特性和SRE工作

  1. 产品可靠性
  2. 可扩展性
  3. 可观测性

把这些内容和产品新特性放入到一个笛卡尔坐标中，一次来分析哪些是最高优先级的。

人人都是SRE

在中小企业中，因为资源有限，人才招聘也比较困难。因此就需要每个人都是SRE。

SRE的成功还需要有深入的同理心、影响力和组织能力，以倡导变革和无责的组织文化。在很多企业中，很多工程师都说自己是背锅的，这种就是有害的组织文化，导致有些人多做多错，不做不错。

拥抱“谁构建，谁维护”的理念，因为每个人都会为了改善他们的生计而更有动力去发布但凡有一丁点价值的特性，导致更多新功能涌现。因此在较小的组织中创建一个专用的SRE资源，最好是通过广泛地分担职责来实现。

  1. 共享环境发展而不是集中控制，共担责任和对话。
  2. 比如业务负责代码的可用性。
  3. 运维负责基础中间件的可用性。

审计问题和问题定位

好了，前面都是说的是思想和方向问题，那接下来就是说的是具体操作了。

审计问题

  1. 审计你以及拥有的东西，你需要更好的了解你的系统，审计它并记录风险。明白是什么东西会摧毁你的业务。这个部分是需要你跟干系人多次沟通后才能得出的。跟上级主要是沟通他忧虑的问题，跟下级主要是了解现在的情况以及他们发现的问题。
  2. 容量问题：如果你不知道你自己系统的极限所在，就不能一直安全地、有规划的扩展现有规模
    1. 你需要确认你的系统容量是多大。
    2. 提升容量的前置时间有多长。这个现在有了云计算了，整体速度会比较快了，但是一些数据库系统的扩容依然是比较缓慢的。
    3. 是否还有可扩展的空间，还是需要特定的使用模式。就比如你如果依赖redis，那它单点的上限就是9000 qps，你要突破这个上限就必须变成分布式，但是代码上也要分开key。
  3. 安全问题
    1. 每个人的访问权限，外部用户的访问权限，可不能跨用户，跨租户的这种访问权限必须控制好。
    2. 内部员工账户控制：各种堡垒机，wiki系统，ci/cd系统等等。这个我们通常都是用openLDAP来统一控制账号和密码和认证组处理。但是具体的组权限控制都是各自系统来处理。
    3. 密码管理器：这个主要是公共的一些账号，我们一般是绑定到一个统一的手机上，这样方便统一来进行。个人账号就直接1password或者各个系统都有的密码管理器，类似keepassX这样的。
    4. 审计日志：我们首先要确认哪些程序的日志需要审计，审计日志要包含哪些内容，审计日志需要保留多久。这个看你需要申请的安全标准。
    5. 防火墙：这个从管理上我们要求所有服务器上都不能有公网IP，内网出去都必须使用nat方式出去。同时在安全组中设置对外只暴露公共业务端口，防止有人意外监听了。还有如果是web业务，那WAF防火墙也是要必须的。
  4. 第三方厂商：这个需要仔细检查你的账单，各个厂商的合同。因为有些账单可能是年付的，你未必马上就清楚。
  5. 托管供应商，云厂商，专线厂商
  6. DNS
  7. 域名
  8. CDN
  9. SSL证书：所使用证书的厂商，证书的部署方式，如何检查证书的有效性，私有根证书的有效性
  10. 安全：安全厂商
  11. 以上厂商如果有问题了，我们如何切换。
  12. 备份
  13. 制作一个快速的基础设施图。如果在云上，有些云厂商支持terraform，使用这个会简单一点。
  14. 需要的设备是否都齐全。
  15. 是否都可以重制。
  16. 非紧急时刻练习整个流程。
  17. 测试你的备份。这个数据库这边是要全量和增量都要进行验证。

问题定位

事件分类：这个一般需要提前确认好报警处理流程，这个在原先公司里叫RTO（Recovery Time Objective）流程，也就是如果SLA是99.99%的话，那我们需要在4.3分钟完成恢复，不然本月的SLA就是不达标了。

  1. 业务影响是什么？
  2. 我们是要立即处理还是可以延后处理？
  3. 我们是线上定位问题还是紧急故障转移？

下面这个就是这个RTO的操作流程是如何产生并定义的：

  1. 测量方法：
  2. 从哪里？也就是数据来源是哪里？
  3. 使用什么工具？
  4. 何时？
  5. 在哪种环境中？
  6. 该测量的预期结果：这个是需要用文字精确定义的。如：最近5分钟x事务的P99始终超过500ms，但是一小时前P99都没有超过100ms。这些定义也可以作为SLI的一个参考。
  7. 明确系统的心智模型：这个整体上就是对于这个系统的每个组件，以及组件之间的请求都要非常了解，这个也是每个SRE必备的，虽然现在可以有codewiki.google这种工具，但是还是需要你把这个东西印在自己大脑中的。
  8. 如果我们不能知道系统为什么崩溃，那表明我们系统的心智模型是不完整的。
  9. 我们需要逐步的完善这个模型
  10. 以图表或者文本形式写下这个模型。
  11. 基于模型迭代：一旦我们有了模型，就可以迭代和改进它，直到发现问题
  12. 制定一个假设：比如流量突然翻了十倍就会导致达到xxx服务性能上限。
  13. 定义需要哪些数据来证实或否定这个假设。
  14. 收集这些数据并对其进行评估以决定是否拒绝该假设。
  15. 重建和验证
  16. 跟创建模型假设时候所做的分析相反。
  17. 根据已假设的部件来重建系统。这个过程中我们使用已有的测量数据，并查看这些部件的总和是否诠释了我们所看到的系统，也有可能是部件之间的互相作用可以解释我们正在经历的事情，而不是任何单个部件。这个在微服务框架的系统更是如此。
  18. 下一步：定位问题方法论的核心思想是明确我们的心智模型，并意识到我们的模型和现实之间的偏差。

确定改进方向

前提： 不要为了一些连自己都左右矛盾的事而竭尽全力。这种改变必须是对全局有所改善，且必须恰逢其时。有时候还没有到，那这种事情可能无法推进和吃力不讨好。

通过上面的审计问题和问题定位后，我们内心有了大致要改进的内容，但是要改进这个不是一个人可以干的，是需要研发部门整体协作，有时候可能还要商业团队来支持。

改进计划：

  1. 解释你为什么现在要这样做？
  2. 列出改变的收益、风险以及成功的概率
  3. 准备好讨论影响
  4. 准备好妥协
  5. 讨论为什么其他团队会抗议
  6. 如果我们不做这个改变，请列出风险
  7. 有测试和部署计划
  8. 有归滚步骤

有了这个计划后，就需要你的总监来讨论，有可能是向上进行会审，也有可能是同级别进行分享。这个过程是十分麻烦的。因此我们还需要有一些改变计划的原则。

  1. 尽最大努力使变革尽可能简单，虽然大家都知道改变是不可避免的。
  2. 从一开始对受影响的团队表现出同理心。这个也是职场上很好的习惯。
  3. 在组织的改变发生之前，向工程部门进行演示，因为这样有助于缓解担忧，有利于项目保持良好的势头，并减少大家在项目期间对寻求帮助的抵制。

落地SRE

  1. 在关键业务服务中引入SLO和错误预算。我们不是说系统要一直正常运行，有时候我们也会为了修补线上的一些潜在问题，这个可能涉及到一个大的升级，那这个时候就会使用掉一些错误预算来进行。这个比如我们规划了明年消息的存储会有一个大的演进，在前期分析的时候我们就会把这个升级做进错误预算中，当然最后没有用到就最好，但是用到了也是在我们可控的范围内。
  2. 与你的干系人定义明确的角色和职责，以及他们每次参与SRE的期望：使用一套通用的可衡量目标和可交付成果与他们达成一致。
  3. 了解组织需要解决的关键问题是什么，并确定SRE将在哪个领域产生最大影响。抓大放小一直都是我们推崇的。
  4. 如增强可视化，这一部分又包含了日志，日志上下文，公开度量指标，trace
  5. 优化非结构化的事故管理流程
  6. 提升测试覆盖度：提升自动化和完善外部检测。
  7. 改善发布流程：发布流程一致性和发布内容的一致性检查。
  8. 确保执行层面的支持者关注并重视推进SRE的实时。也就是获得高层的授权和关注是非常重要的。
  9. 最后一点最重要：任何涉及SRE的进展，结果和成功标准都必须是可量化的。要定期征求干系人开诚布公的反馈。
  10. SLO改进
  11. 减少琐事工作量
  12. 达成OKR
  13. 客户满意度调查

设计SLO

设计SLO需要考虑如下6个要求，也就是这个SLO设计出来要包含这些内容。

灵活性

  1. 随着时间推移和业务演进而不断发展。因为业务发展的不同时期，我们对于SLO的要求必然是变化的，如上面说的beta版本和正式版本就会有很大不同。同时修改这些内容都不需要重新发布或者代码修改。
  2. 测试间隔：这个很容易理解，有些指标每分钟收集一次就行，有些指标是毫秒级的。
  3. 成功阈值：从P90到P99
  4. 聚合时间：过去1秒到过去30天。

可测试性

  1. 确定SLI或者目标
  2. 通过可靠性历史来推算正确的错误预算
  3. 延时百分位是多少
  4. 实际延迟阈值是多少
  5. 根据历史数据回测，设置阈值时估算报警频率是多少

新鲜度

  1. 产生实时数据所花费的时间。一些月度指标就没有必要都是30秒的数据。来自客户端的用户数据需要用户上传，这个依赖于上传频率。其他的基本都以秒级为单位。
  2. 时间是越短越好，取决于的你的SLO和成本要求。

成本

SLO的数据工程需求可能是巨大的，特别是对于高吞吐量或广泛分布的应用。

  1. 成本估算不用太细，细到小数点后面多少位根本没有必要。
  2. 成本组成部分是：时间序列、结构化日志数据和机会成本这3个方向。
  3. 尽可能成本控制在项目的 1/10 以内。

一般情况下公司会有统一的系统，所以计算这块的整体边际根本都是比较低的，这里比较注意的就是上面的时间序列和结构化日志的存储和队列成本。不过这一部分是非常好计算的。

可靠性

监控系统本身的可靠性也是要定义的。不能报警系统本身经常挂。

我们一般会对监控系统本身做一个health接口，然后让第三方监控定时来检测。同时监控系统本身在监测的时候都要使用主动拉的模式，而不是等待客户端来上报。

组织约束

比如一些监管的要求，有些行业必须日志都存放5年10年的，而且数据都必须在企业内部等等。

故障响应

人员分工

  1. 事故负责人：谁在做什么？ 响应是否停滞不前？ 谁有可能因为疲劳而更换？
  2. 专家团队/运维： 负责指挥团队具体执行合适的事务来解决问题，这个角色也是唯一可以在事故期间可以对线上环境进行变更的角色。
  3. 沟通（发言人）：对外发布现在事件的情况，收集现在外部对于该事件的舆论。

响应机制

  1. 由谁发起
  2. 使用的聊天工具
  3. 需要拉哪些人
  4. 多久未修复需要升级拉人
  5. 多久汇报一次状态

长期训练

在没有紧急事情的时候，可以先自我练习，然后定期进行全项目组级别的演练。