产品经理眼中的SRE——01零碎概念

产品经理眼中的SRE——01零碎概念

SRE(Site Reliability Engineering)是谷歌对一类面向软件系统的全生命周期的管理，优化流程，保障每个节点的工程师职位的定义。在《Google运维解密》这本书里提到“DevOps”是SRE核心理论的普适版，可面向更多的行业场景于组织架构。而DevOps是一个弹性的理论+实践方案，是一个更适合自发自创的管理模式或工作模式。

SRE本身就可以在技术、行业、场景等不同维度进行针对性的研究与学习，那为什么要说在产品经理眼中的SRE？—— 因为我们大多数能推出去快速兑现的不是人或方法论（当然大神们自带流量的不在范围内），一般是产品，是工具，是一种能够承载着理念的平台。

理念是否重要或者方法论是否好站住脚是个值得讨论的问题，因为在很多情况下除了业务本身，下挂的所有环境和平台或是硬件都不存在不可替代的说法，你一个web服务上面是运行的电商业务，那么围绕着这个电商业务所能组件的团队层级和功能划分其实是相对确定的：业务类型、用户分类去划出产品、设计、运营；业务模式与终端服务划出架构、开发等，当我们说到运维的时候可能只是一个补充环节了，甚至开发也一样，什么架构模式、什么web中间件、MQ、存储服务等等都可以公式化地给出运维需求，其实问题不大，只是在规模与量级出现指数增长时，量变必然引起质变。所以我们反过来看，假若我们以运维、开发为核心的时候就会审视自己团队的经验、技术栈、去匹配合适的上层服务和业务类型，有点另类，但是其实业务层的人想的就是下层的服务和运维就应该给我智能适配，自我诊断，像人体的免疫系统一样，运维的最高境界就是无感知运维嘛，但是无感知并不是自我诊断，而是亲业务的，业务类比婴儿，下层服务就像母亲一样，无微不至地照顾着业务，生怕你病了，痛了，还要看看你周围的生活环境是不是干净的，天气是不是要凉了，你感冒的风险有多高等等。新手母亲需要做到每一个细节，生怕出错，但是随着时间积累，你就完全熟悉自己的孩子了，这孩子喜欢吃啥，去哪玩，睡觉蹬被子不，你可能就会有侧重了。我们在维护一个系统的时候，其实怕的就是看不到的东西，你的内部环境现在的并发数在什么程度的区间内，你的数据库持久化对磁盘的影响趋势等，但我们没有必要去过于担心会漏掉这漏掉那，你需要清楚自己的系统的关键属性与参数，以及如何实时的与它们进行交互和指令，所以SRE并不是在做一件事情或是很多事情，而是在持续演进、熟悉，找到最优。

本文将围绕SRE进行一些核心理念与实践的描述，可能较为零散，可作为闲读

关于团队目标一致性，产品研发与运维或SRE的目标很难在一个软件版本全生命周期中每个关键节点上保持一致性，但是在整体流程的最终输出或可量化的指标上，是存在一致性目标的。

关键概念

• “错误预算”：任何产品不是也不应该做到100%可靠。而应该考虑以下几个问题：
  1.1. 用户使用习惯下的服务可靠性；
  1.2. 若此服务可靠性不够，是否有替代品；
  1.3. 可靠性产生的影响是否影响用户的使用模式。
  “错误预算”的效果是使SRE和产品研发有一致目标：保障业务+快速上线 （某种平衡点）

• 那些基础却核心指标参数
  在很多工作流程中，我们都会下意识的只看那个关键的数据或信息，例如log里看ERROR和时间戳、工单或告警看环境参数和紧急程度。而我们在变更的过程中更是需要关注某些“关键”的指标：

  • 版本号：在上线部署和回滚的唯一性标识
  • 应用ID：围绕某个应用进行变更的ID
  • 环境tag:承载变更的环境（集群、主机）的标签

  诸如此类的核心指标是需要团队在整个流程运作前进行制定，类似接口的规范定义，但是不同的是此类指标及参数的定义是流转在整个软件生命周期中的。

• 监控系统的输出内容
  监控系统是SRE作为故障交互的一个主要媒介，故障内容的输出是完全自定义的，但是在软件上线后所能产生的众多海量数据中，SRE需要关注的和利用的数据实则是需要根据不同场景与需求进行调控的。但是从软件的本身运行情况和承载的运行平台来看，核心输出的为一下三个维度的数据：

  • 告警警报（alert）
  • 工单（ticket）
  • 日志（logging）

• 黄金指标
  SRE眼中的4个监控黄金指标：延迟、流量、错误和饱和度，老实说，这四个指标其实还是面向业务去筛选出来的比较关键的监控指标，在很多场景下，不同的运维或监控需求都会给每个指标赋予不同的权重，还有就是度量指标的确定，这个是需要你对业务环境与运维场景有一定深度的熟悉与了解的，例如在流量上，Web服务请求可以有很多种维度的监控度量指标：动静态请求的区分，业务类型的区分（流媒体、普通格式资源等），又或是session并发数或网络I/O等等。所以当我们铺天盖地地去介绍监控功能的性能及参数时，试着从上往下看，从业务侧和出口去追溯监控环节的核心点，至于监控原理、采集方式等，重要但是还不能那么地让人觉得有说服力。

• 自动化
  其实在说自动化的前面应该先提确立自动化的前提条件，业务模式的分析、环境分布的分析、以及资源规划的分析等等，但是如果在全局去谈论自动化，我们更像是在梳理业务、环境、人员等工作的降本增效方面的事情了，这里我们想要聚焦SRE，所以就不会大篇幅地去讲标准化和CI项的梳理关键了。