1. 软市首页
  2. 软件开发

我对 SRE 的理解

• 软件开发

我对 SRE 的理解

落地过程中，可先从如下三个抓手系统解决:

  • 可控性

  • 可观测

  • 稳定性保障最佳实践

可控性方面，包括如下三个主要维度：

  • 发布管理

    • 重点解决发布导致的人为稳定性问题

    • 包括发布前重要变更评审和发布中变更动作管理等

  • 操作管理

    • 重点解决黑屏操作导致的人为稳定性问题

    • 包括统一集群操作入口、集群操作权限管理、集群操作审计等

  • 设计评审

    • 重点解决软件系统设计阶段应用稳定性保障最佳实践

    • 包括集群方案评审和重要功能设计评审等

可观测方面，包括如下几个重要维度：

  • 监控

    • 重点解决软件系统运行态的感知能力

    • 包括监控收集/可视化系统的搭建和维护等

  • 日志

    • 重点解决软件系统的问题可排查能力

    • 包括日志收集/存储/查询/分析系统的搭建和维护等

  • 巡检

    • 重点解决软件系统功能是否正常的主动探测能力

    • 包括巡检服务的搭建、通用巡检逻辑的开发维护等

  • 告警

    • 重点解决异常的及时触达需求

    • 包括告警系统的搭建、告警配置管理、告警途径管理、告警分析等

稳定性保障最佳实践，是从历史问题和业界实践方面抽象出意识、流程、规范、工具，在系统设计之初就融入其中，并在系统整个生命周期中加以使用，如通过模板固化最佳实践：

  • 项目质量验收标准

  • 项目安全生产标准

  • 项目发布前 checklist

  • 项目 TechReview 模板

  • 项目 Kick-off 模板

  • 项目管理规范

  • etc.

一个例子：

维度

评估项

可观测

  1. 是否提供了标准的 metrics API/p>

  2. 是否可以将日志持久化到日志系统/p>

  3. 是否配置了监控/p>

    1. 是否有对跌零因子的监控/p>

    2. 是否有服务降级的监控/p>

    3. 是否有限流的监控/p>

    4. 是否配置了对关键依赖方的可用性监控/p>

    5. 监控是否分级/p>

  1. 是否配置了告警/p>

    1. 是否有对跌零因子的告警/p>

    2. 是否有服务降级的告警/p>

    3. 是否有限流的告警/p>

    4. 是否配置了对关键依赖方的可用性告警/p>

    5. 告警是否分级/p>

  1. 是否可以配置巡检/p>

  2. 使用使用了 structured log 便于进行 log 的查询、分析/p>

可灰度

  1. 是否使用了具有灰度能力的 workload/p>

可回滚

  1. 是否使用了均有回滚能力的 workload/p>

  2. 组件是否进行了版本控制/p>

  3. 配置是否进行了版本控制/p>

可保护

  1. 是否有限流措施/p>

  2. 是否有降级措施/p>

  3. 是否配置了探针/p>

    1. 是否配置了 livenessProbe/p>

    2. 可被访问时，是否配置了 readinessProbe/p>

    3. 初始化耗时时，是否配置了 startupProbe/p>

  1. 是否有快速失败的能力/p>

    1. 是否有超时结束能力/p>

  1. 依赖方不可用时:

    1. 是否会持续对依赖方带来日常或更高压力/p>

    2. 是否会对上游带来反向压力如连接数、处理延时)

  1. 己方不可用时：

    1. 对上游的影响是否可控/p>

    2. 恢复时是否可以控制请求压力/p>

  1. 是否可以无损重建/p>

  2. 是否多副本部署/p>

  3. 是否配置了非亲和性/p>

  4. 是否跨 AZ 部署/p>

  5. 是否有处理预案

  6. 是否均有访问管理/p>

  7. 服务是否稳定性运行，是否会影响数据资产/p>

  8. 服务是否稳定性运行，是否会泄露敏感信息/p>

  9. 是否区分组件处于关键链路还是旁路/p>

  10. 是否有「爆炸半径」的整理/p>

  11. 是否有「跌零因子」的整理/p>

可控成本

  1. 是否配置了 limit resources/p>

  2. 变更是增加还是降低用户成本/p>

  3. 变更是增加还是降低平台成本/p>

易于运维

  1. 是否可以做到变更配置时无需重建实例/p>

  2. 是否有白屏化运维途径/p>

  3. 是否有「端到端管控链路」流程图

  4. 是否有「端到端数据链路」流程图

为了便于理解，可以再针对 check 项形成分级，便于交流和进行项目稳定性评估：

级别

标准

L0

  • 可观测、可灰度、可回滚 均不满足

L1

  • 可观测、可灰度、可回滚 满足 50% 以上要求

L2

  • 可观测、可灰度、可回滚 满足 90% 以上要求

L3

  • 可观测、可灰度、可回滚 满足 90% 以上要求

  • 可保护满足 50% 以上要求

L4

  • 可观测、可灰度、可回滚 满足 90% 以上要求

  • 可保护满足 90% 以上要求

  • 可控成本满足 50% 以上要求

L5

  • 可观测、可灰度、可回滚 满足 90% 以上要求

  • 可保护满足 90% 以上要求

  • 可控成本满足 90% 以上要求

当最佳实践可以通过文档进行规范化，接下来就可以提供工具或服务将其低成本应用，使得稳定性保障最佳实践成为基础设施。

SRE 需要在稳定性相关的方法论和实践方面不断迭代，自上而下设计，自下而上反馈，合理、可靠保障稳定性。

共赢，携手服务业务

再回顾下软件系统生命周期中的两类角色：

  • 产品/基础技术研发：专注于设计和构建软件系统

  • SRE：专注于整个软件系统生命周期管理，包括从其设计到部署，历经不断改进，最后顺利下线

这两类角色是相互协作、相互服务的关系，拥有共同的目标：满足业务需求，更好服务业务。

SRE 通常会横向支撑多个项目，对线上问题的类型、解决实践有更为全面的理解和思考，基于此会形成最佳实践的理论、工具或服务，为研发提供理论、工具的支持，也可以在此基础上产品化稳定性保障解决方案，为更多的客户服务，创造更大的价值。

产品/基础技术研发对业务需求、功能/技术细节有更深入的理解，一方面直接带来业务价值，一方面可通过实践为稳定性保障带来切合实际的需求，进一步和 SRE 共同保障稳定性。

两种类型的角色，需要朝着共同的目标并肩协作，与业务共同发展，实现共赢。

小结

SRE 由于工作的性质，在横向方面会服务大量的业务，以实践积累对稳定性保障问题域的深入理解和稳定性保障重要性的深刻认知，在纵向方面会通过技术手段将稳定性保障最佳实践进行沉淀和应用；同时眼光又是与研发、业务一齐向前看，综合技术和管理创造价值。

以上是从个人角度对 SRE 及稳定性保障的理解，重点在于 解决问题 和 创造更大的价值。

References

  • 豆瓣 SRE

    https://book.douban.com/subject/26875239/

  • wikipedia: Site reliability engineering

    https://en.wikipedia.org/wiki/Site_reliability_engineering

  • wikipedia: Controllability

    https://en.wikipedia.org/wiki/Controllability

  • wikipedia: Observability

    https://en.wikipedia.org/wiki/Observability

  • site: google sre

    https://sre.google/

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览91442 人正在系统学习中

来源：阿里巴巴中间件

声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！

上一篇 2020年11月27日
下一篇 2020年11月27日

相关推荐

首页
软件超市
企服市场
会员中心