最新要闻

广告

手机

iphone11大小尺寸是多少?苹果iPhone11和iPhone13的区别是什么?

iphone11大小尺寸是多少?苹果iPhone11和iPhone13的区别是什么?

警方通报辅警执法直播中被撞飞:犯罪嫌疑人已投案

警方通报辅警执法直播中被撞飞:犯罪嫌疑人已投案

家电

SRE Google 运维解密读书笔记一:SRE 方法论概述

来源:博客园

SRE Google 运维解密,是 SRE 领域的启蒙之作,讲述了 Google 的 SRE 实践,SRE 就是从 Google 流传出来的。本文是读书笔记,第一篇,概述 SRE 方法论。帮大家把书读薄,当然,也加入了一些我的个人理解,希望对你有帮助。


(资料图片仅供参考)

为何需要 SRE

传统的 sysadmin 的方式,偏手工运维,机器越多所需运维工程师越多,对于 Google 的体量(毛估估现在大概有几百万台机器)和增长速度,成本(人工成本、管理成本等)不可承受。

因为目标不同、技术背景不同、对可靠性理解不同,传统运维和产品研发团队之间,很容易形成巨大的鸿沟,有时会上升到部门之间的信任和尊重层面。比如拿变更举例,研发部门想要:“随时随地发布新功能,没有任何阻拦”,传统的运维团队想要的则是:“一旦一个东西在生产环境中正常工作了,就不要再做任何改动”。这样的两个团队,是没法很好的合作的,尤其是在 Google 的体量和增速下,得改。解法就是 SRE。

Google SRE 概述

Google SRE 的创始人是 Benjamin Treynor Sloss,研发出身,2003 年加入 Google,被任命领导一个 7 人小组(现在,SRE 团队已经上千人了),负责“生产环境维护”。Google 当时的增速是非常快的,如果按照传统的玩法,招人的速度完全无法匹配机器增速,怎么做这个“生产环境维护”的工作呢?

Benjamin Treynor 是资深研发,自然就会考虑用软件工程的手段来解决遇到的各类问题,所以 Google SRE 首先,得具备研发技能,用研发技能来解决各类生产维护重复工作。他们具备如下特质:

  • 对重复性、手工性的操作有天然的排斥感
  • 有足够的技术能力快速开发出软件系统以替代手工操作

但是,做过运维的人都知道,总有一些日常运维的工作无法避免,有时根本没时间写代码,比如处理工单、手工操作,尤其是在基础设施平台工程不完备的情况下。这可咋整?

Google 提出了 50% 的原则,即日常运维的时间不能超过 50%,即需要至少拿出一半以上的时间来做工程研发,釜底抽薪,用工程手段解决手工操作。那有的时候,日常运维工作繁重,超过了 50% 时间分配原则,怎么办?把相关工作交给产品研发团队的 leader,让他来帮忙消化掉一部分工作。研发 leader 一看,运维侧的工作好多啊,是不是我们的软件不够鲁棒、很多应该自动处理的逻辑没有自动处理,就会去改进,形成正向循环。当然,这个机制需要公司管理层强力推动。如果遇到一个研发团队说,运维的活你们运维干不完,干不完可以招人啊,管理层也不作为,就完了。

DevOps 还是 SRE

Benjamin Treynor 认为,SRE 是 DevOps 模型在 Google 的具体实践,带有一些特别的扩展

SRE 技能组成

实际的人员组织来看, SRE 团队分两类人,一类就是纯研发,一类是具备八九成研发能力,同时还懂一些 UNIX 知识、网络知识。如果国内运维团队想要转型为 SRE 组织,就这个技能要求就很难达成(其实除了 Google,其他国外的公司也很难做到)。咋办?

国内的组织的做法:一个人能力有限,弄个团队来顶上,团队里既有只懂研发的人,又有只懂网络的人,又有只懂操作系统的人,应该就可以了吧。个人的看法是,这个做法基本是对的,但是不完全够。因为虽然是一个团队,但是不同的小组或个人的知识仍然是无法完全共享的,这使得在做工程决策、实践的时候,没法做到像 Google SRE 那样如臂指使。

稍微改进一下的做法是:团队里仍然要招聘一两个 SRE 专家,姑且称为 SRE COE,既懂开发又懂运维的那种,统筹所有工作,然后那些单方面的技能人才,辅助 SRE COE 来完成工作,相对会更靠谱一些。

SRE 方法论

SRE 团队的职责:可用性改进,廷迟优化,性能优化,效率优化,变更管理,监控,紧急事务处理以及容量规划与管理。要转型的团队注意了,用软件工程的手段达成以上目标,就说明你们团队转型成功了:)

在保障服务 SLO 的前提下最大化迭代速度

变更是万恶之源,生产环境中的故障,大概有 70% 都是变更引起的。屁股决定脑袋,运维团队就希望尽量别有变更,研发团队要上线新 feature,那就需要频繁变更,咋整?Google 提出了 “错误预算” 的理念。

产品首先得确定 SLO,比如某个服务的季度 SLO 目标是 99.99%,那不可用的 Quota 预算就是 0.01%,每个月按照 30 天来算,一个季度 90 天,允许的不可用分钟数是:

90 * 24 * 60 * 0.01% = 12.96 分钟 ≈ 13 分钟

只要服务的季度不可用时长低于 13 分钟,随便折腾,但是一旦超过了 13 分钟,说明 Quota 用光了,就不能随意上线了,非得要上线,行么?也行,VP 审核通过吧。那意思就是:你看这个研发团队,上线老是出问题,不可信赖,现在又要上线了,SRE 是不准备放行了,VP 大佬来决策吧,VP 大佬也非要允许上,那就上。

咋样,这个方法听着不错吧。贵司可以试试。这里要注意,服务要想减少故障时长,是需要有良好的基础设施保障的,比如研发上线发现问题,想回滚,结果部署系统不可靠,这找谁说理去。所以,错误预算这个方法可以用,但是不同的公司,SLO 的阈值得谨慎制定,没有金刚钻不揽瓷器活,基础设施很烂,SLO 就定低点吧。

SLO 谁来定?

SLO 应该是业务来定,但是SRE 要提供一些信息,告诉业务达成什么样的 SLO 要付出什么样的成本,业务有了这些信息了,再来确定制定什么样的 SLO。比如某个业务不盈利,就是个实验性质的业务,SLO 低一点很正常,具体要看业务本身的决策,所以 SLO 的制定需要业务拍板。

监控系统

核心要学习的是:每个需要通知到人的告警,必须对应 Runbook,即预案手册。如果一个告警发出来,没有人响应,没有相应的动作执行,这个告警就是无效的。Runbook 链接一般配置在告警规则里,比如 Grafana、Nightingale、Datadog 的告警规则配置,都支持这么干。告警规则的 Runbook 预置率是一个很好的告警治理指标。

有些告警可以不用立即处理,但是至少得创建个工单留待后续处理。

应急事件处理

提前准备好 Runbook,即预案手册,比即兴发挥,效果好 3 倍。

变更管理

要自动化!要自动化!要自动化!自动化完成以下项目:

  • 采用渐进式发布机制
  • 有良好的监控系统,可以快速发现问题
  • 当问题发生时,可以安全回滚

需求预测和容量规划

要考虑的点包括:

  • 自然增量:随着用户自然增长带来的增量
  • 非自然增量:比如市场活动
  • 周期性压测:这点很关键,这点很关键,这点很关键,通过压测才知道你的系统瓶颈在哪个微服务,才能把系统原始资源和业务容量对应起来

资源部署

扩容需要部署资源,变更也需要,这就是 Borg 的作用,其他公司可以采用类似 Kubernetes 的方案。不管使用什么方案,能够快速、正确的完成部署,最大化资源使用,就可以了。

效率与性能

SRE 也需要关注服务性能,提升了性能,其实就是提高了资源利用效率,同样的硬件可以支撑更大量的客户。NetFlix 有专门的 Performance 工程师,Google 的话 SRE 一并干了这个事情。

小结

SRE 团队的职责:可用性改进,廷迟优化,性能优化,效率优化,变更管理,监控,紧急事务处理以及容量规划与管理。我们要用软件工程的思维来解决这些问题,完活。留个问题:

SRE 要不要修改业务代码?

比如增加一些监控埋点,或者优化一个算法提升软件性能,或者换了一个更合理的存储?欢迎大家留言讨论 :)

关键词: