前言

在技术工作中，对于产品/基础技术研发和 SRE 两种角色，通常会有基于「是否侧重编码」的理解。对于产品研发转做 SRE ，经常会产生是否要「脱离编码工作」的看法，或者认为是否要「偏离对产品/基础技术的推进」。

基于过往的技术研发和稳定性保障的经验，分享下个人对 SRE 的理解，探讨「面向产品/基础技术的研发」和「稳定性保障」两种角色之间的协作关系，更好地为业务服务。

SRE 概述

书的豆瓣链接：https://book.douban.com/subject/26875239/

• 职责：保障基础设施的稳定性和可扩展性
• 核心：解决问题
• 方法：通过操作类事务积累问题经验，通过编码等方式提升问题的解决效率

软件生命周期

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

稳定性保障价值

针对稳定性的影响，直接参与处理客户问题的同学会更有体感：

• 通过问题发生时客户直接反馈的影响程度、紧急程度，感受到稳定性给客户带来的焦虑

• 通过问题处理结束后客户的反馈，感受到客户对稳定性保障的感谢或愤怒

• 通过事后在营收状况、客户规模变化，感受到稳定性对业务营收的影响

• 通过产品规划的的延期，感受到稳定性对产品迭代的影响

稳定性保障的价值由此凸显：

• 保障客户的产品体验，满足客户对约定的可靠性诉求

• 加速业务迭代，满足业务对稳定性诉求，业务注意力集中在更快速推出满足客户需求的功能

SRE 如何保障稳定性

• 人为导致，依赖专家经验
• 一系列因素综合导致
• 不可避免
• 100% 保障没有必要

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

• 可控性

• 可观测

• 稳定性保障最佳实践

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

• 发布管理

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

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

• 操作管理

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

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

• 设计评审

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

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

• 监控
• 重点解决软件系统运行态的感知能力
• 包括监控收集/可视化系统的搭建和维护等
• 日志
• 重点解决软件系统的问题可排查能力
• 包括日志收集/存储/查询/分析系统的搭建和维护等
• 巡检
• 重点解决软件系统功能是否正常的主动探测能力
• 包括巡检服务的搭建、通用巡检逻辑的开发维护等
• 告警
• 重点解决异常的及时触达需求
• 包括告警系统的搭建、告警配置管理、告警途径管理、告警分析等

• 项目质量验收标准
• 项目安全生产标准
• 项目发布前 checklist
• 项目 TechReview 模板
• 项目 Kick-off 模板
• 项目管理规范
• etc.

共赢，携手服务业务

• 产品/基础技术研发：专注于设计和构建软件系统
• 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/

近期好文：