前言
在技术工作中，对于产品 / 根底技术研发和 SRE 两种角色，通常会有基于「是否偏重编码」的了解。对于产品研发转做 SRE，常常会产生是否要「脱离编码工作」的认识，或者认为是否要「偏离对产品 / 根底技术的推动」。
基于过往的技术研发和稳定性保障的教训，分享下集体对 SRE 的了解，探讨「面向产品 / 根底技术的研发」和「稳定性保障」两种角色之间的协作关系，更好地为业务服务。
SRE 概述
最早探讨 SRE 来源于 Google 这本书《Site Reliability Engineering: How Google Runs Production Systems》（豆瓣链接）。由 Google SRE 要害成员分享他们是如何对软件进行生命周期的整体性关注，以及为什么这样做可能帮忙 Google 胜利地构建、部署、监控和运维世界上现存最大的软件系统。
从 wikipedia: Site reliability engineering 中可理解到 SRE 的定义：
Site reliability engineering (SRE) is a discipline that incorporates aspects of software engineering and applies them to infrastructure and operations problems. The main goals are to create scalable and highly reliable software systems.
其中有句形象形容 SRE 工作的形容：
SRE is “what happens when a software engineer is tasked with what used to be called operations.”
即 SRE 的指标是构建可扩大和高可用的软件系统，通过软件工程的办法解决基础设施和操作相干的问题。
在 Google SRE 书中，对 SRE 日常工作状态有个精确的形容：至少 50% 的工夫精力解决操作相干事宜，50% 以上的精力通过软件工程保障基础设施的稳定性和可扩展性。
基于上述形容，我对 SRE 的了解是：
- 职责：保障基础设施的稳定性和可扩展性
- 外围：解决问题
- 办法：通过操作类事务积攒问题教训，通过编码等形式晋升问题的解决效率
软件生命周期
Google SRE 一书中，对软件工程从生命周期角度有一个很形象的形容：
软件工程有的时候和养孩子相似：尽管生养的过程是苦楚和艰难的，然而养育孩子成人的过程才是真正须要破费绝大部分精力的中央。
一个软件系统的 40%~90% 的花销其实是花在开发建设实现之后一直保护过程中的。
我的项目生命周期中，设计和构建软件系统的工夫精力占比，通常是少于零碎上线之后的保护治理。为了更好地保护零碎牢靠运行，须要思考两种类型的角色：
- 专一于设计和构建软件系统
- 专一于整个软件系统生命周期治理，包含从其设计到部署，历经不断改进，最初顺利下线
第一类角色对应产品 / 根底技术研发，第二类角色对应 SRE，二者的独特指标均是为了达成我的项目指标，协同服务好业务。
稳定性保障价值
针对稳定性的影响，直接参与解决客户问题的同学会更有体感：
- 通过问题产生时客户间接反馈的影响水平、紧急水平，感触到稳定性给客户带来的焦虑
- 通过问题解决完结后客户的反馈，感触到客户对稳定性保障的感激或愤恨
- 通过预先在营收情况、客户规模变动，感触到稳定性对业务营收的影响
- 通过产品布局的的延期，感触到稳定性对产品迭代的影响
稳定性保障的价值由此凸显：
- 保障客户的产品体验，满足客户对约定的可靠性诉求
- 减速业务迭代，满足业务对稳定性诉求，业务注意力集中在更疾速推出满足客户需要的性能
SRE 如何保障稳定性
稳定性问题通常会有这些特色：
- 人为导致，依赖专家教训
- 一系列因素综合导致
- 不可避免
- 100% 保障没有必要
线上稳定性问题，人为操作不当导致的比例很高，集中在 公布 和 线上运维 两个环节，均是高频操作。对于简单零碎，这两个环节对专家教训有较强的依赖。
产生的稳定性问题通常具备系统性的特色，即非单个性能组件缺点导致，而是由一系列因素综合作用导致，如短少监控告警导致不能及时感知，短少日志不能有助于疾速定位问题，短少良好的问题排查流程导致依赖集体能力，短少良好的协调沟通极致导致问题解决时长减少、客户影响水平加剧等。
问题是不可避免的，流量的突增、服务器 / 网络 / 存储的损坏、未笼罩的输出等，均会诱发问题的呈现。
业务对外有 SLA，向客户承诺肯定水平的稳定性，未达到时依照协定进行赔付，同时问题又不可未免，在满足外部 SLO 规范的前提下持续晋升稳定性，会带来更高的实现老本，对业务的收益增量也会更小。
SRE 须要对问题特色有深刻了解，系统性设计和施行解决方案，并抓住一段时间内的次要问题进行解决。
一种可参考的整体解决方案如下：
落地过程中，可先从如下三个抓手零碎解决:
- 可控性
- 可观测
- 稳定性保障最佳实际
可控性方面，包含如下三个次要维度：
-
公布治理
- 重点解决公布导致的人为稳定性问题
- 包含公布前重要变更评审和公布中变更动作治理等
-
操作治理
- 重点解决黑屏操作导致的人为稳定性问题
- 包含对立集群操作入口、集群操作权限治理、集群操作审计等
-
设计评审
- 重点解决软件系统设计阶段利用稳定性保障最佳实际
- 包含集群计划评审和重要功能设计评审等
可观测方面，包含如下几个重要维度：
-
监控
- 重点解决软件系统运行态的感知能力
- 包含监控收集 / 可视化零碎的搭建和保护等
-
日志
- 重点解决软件系统的问题可排查能力
- 包含日志收集 / 存储 / 查问 / 剖析零碎的搭建和保护等
-
巡检
- 重点解决软件系统性能是否失常的被动探测能力
- 包含巡检服务的搭建、通用巡检逻辑的开发保护等
-
告警
- 重点解决异样的及时触达需要
- 包含告警零碎的搭建、告警配置管理、告警路径治理、告警剖析等
稳定性保障最佳实际，是从历史问题和业界实际方面形象出意识、流程、标准、工具，在零碎设计之初就融入其中，并在零碎整个生命周期中加以应用，如通过模板固化最佳实际：
- 我的项目品质验收规范
- 我的项目平安生产规范
- 我的项目公布前 checklist
- 我的项目 TechReview 模板
- 我的项目 Kick-off 模板
- 项目管理标准
- etc.
一个例子：
| 维度 | 评估项 | |
|---|---|---|
| 可观测 | 1. 是否提供了规范的 metrics API？ 2. 是否能够将日志长久化到日志零碎？ 3. 是否配置了监控？ – a. 是否有对跌零因子的监控？ – b. 是否有服务降级的监控？ – c. 是否无限流的监控？ – d. 是否配置了对要害依赖方的可用性监控？ – e. 监控是否分级？ 4. 是否配置了告警？ – a. 是否有对跌零因子的告警？ – b. 是否有服务降级的告警？ – c. 是否无限流的告警？ – d. 是否配置了对要害依赖方的可用性告警？ – e. 告警是否分级？ 5. 是否能够配置巡检？ 6. 应用了 structured log 便于进行 log 的查问、剖析？ |
|
| 可灰度 | 是否应用了具备灰度能力的 workload？ | |
| 可回滚 | 1. 是否应用了均有回滚能力的 workload？ 2. 组件是否进行了版本控制？ 3. 配置是否进行了版本控制？ |
|
| 可爱护 | 1. 是否无限流措施？ 2. 是否有降级措施？ 3. 是否配置了探针？ – a. 是否配置了 livenessProbe？ – b. 可被拜访时，是否配置了 readinessProbe？ – c. 初始化耗时时，是否配置了 startupProbe？ 4. 是否有疾速失败的能力？ – a. 是否有超时完结能力？ 5. 依赖方不可用时: – a. 是否会继续对依赖方带来日常或更高压力？ – b. 是否会对上游带来反向压力？(如连接数、解决延时) 6. 己方不可用时： – a. 对上游的影响是否可控？ – b. 复原时是否能够管制申请压力？ 7. 是否能够无损重建？ 8. 是否多正本部署？ 9. 是否配置了非亲和性？ 10. 是否跨 AZ 部署？ 11. 是否有解决预案 12. 是否均有拜访治理？ 13. 服务是否稳定性运行，是否会影响数据资产？ 14. 服务是否稳定性运行，是否会泄露敏感信息？ 15. 是否辨别组件处于要害链路还是旁路？ 16. 是否有「爆炸半径」的整顿？ 17. 是否有「跌零因子」的整顿？ |
|
| 可控老本 | 1. 是否配置了 limit resources？ 2. 变更是减少还是升高用户老本？ 3. 变更是减少还是升高平台老本？ |
|
| 易于运维 | 1. 是否能够做到变更配置时无需重建实例？ 2. 是否有白屏化运维路径？ 3. 是否有「端到端管控链路」流程图 4. 是否有「端到端数据链路」流程图 |
为了便于了解，能够再针对 check 项造成分级，便于交换和进行我的项目稳定性评估：
| 级别 | 规范 |
|---|---|
| L0 | 1. 可观测、可灰度、可回滚 均不满足 |
| L1 | 1. 可观测、可灰度、可回滚 满足 50% 以上要求 |
| L2 | 1. 可观测、可灰度、可回滚 满足 90% 以上要求 |
| L3 | 1. 可观测、可灰度、可回滚 满足 90% 以上要求 2. 可爱护满足 50% 以上要求 |
| L4 | 1. 可观测、可灰度、可回滚 满足 90% 以上要求 2. 可爱护满足 90% 以上要求 3. 可控老本满足 50% 以上要求 |
| L5 | 1. 可观测、可灰度、可回滚 满足 90% 以上要求 2. 可爱护满足 90% 以上要求 3. 可控老本满足 90% 以上要求 |
当最佳实际能够通过文档进行规范化，接下来就能够提供工具或服务将其低成本利用，使得稳定性保障最佳实际成为基础设施。
SRE 须要在稳定性相干的方法论和实际方面一直迭代，自上而下设计，自下而上反馈，正当、牢靠保障稳定性。
共赢，携手服务业务
再回顾下软件系统生命周期中的两类角色：
- 产品 / 根底技术研发：专一于设计和构建软件系统
- SRE：专一于整个软件系统生命周期治理，包含从其设计到部署，历经不断改进，最初顺利下线
这两类角色是相互协作、互相服务的关系，领有独特的指标：满足业务需要，更好服务业务。
SRE 通常会横向撑持多个我的项目，对线上问题的类型、解决实际有更为全面的了解和思考，基于此会造成最佳实际的实践、工具或服务，为研发提供实践、工具的反对，也能够在此基础上产品化稳定性保障解决方案，为更多的客户服务，发明更大的价值。
产品 / 根底技术研发对业务需要、性能 / 技术细节有更深刻的了解，一方面间接带来业务价值，一方面可通过实际为稳定性保障带来切合实际的需要，进一步和 SRE 独特保障稳定性。
两种类型的角色，须要朝着独特的指标并肩合作，与业务独特倒退，实现共赢。
小结
SRE 因为工作的性质，在横向方面会服务大量的业务，以实际积攒对稳定性保障问题域的深刻了解和稳定性保障重要性的粗浅认知，在纵向方面会通过技术手段将稳定性保障最佳实际进行积淀和利用；同时眼光又是与研发、业务一齐向前看，综合技术和治理发明价值。
以上是从集体角度对 SRE 及稳定性保障的了解，重点在于 解决问题 和 发明更大的价值。
References
豆瓣 SRE
wikipedia: Site reliability engineering
wikipedia: Controllability
wikipedia: Observability
site: google sre
扫码理解更多技术内容与客户案例：