SRE

《SRE Google运维解密》读书笔记
引言：曾经，觉得写接口改Bug不好玩了，就此带着热情走进了运维世界，探索这奇妙的监控、容器、自动化…。幸得茅哥的引路，让自己在运维的世界越走越远。近些天，我确定了新的方向，再次燃起我眼睛里无限探索的渴望；今天结束或许就是自己人生中最后一个运维相关岗位的工作日。假使将来有时间，我将把这些年的运维笔记整理升华发布于此。

认识运维

软件的生命周期
- 需求分析需求分析工程师、产品经理
- 软件设计架构工程师
- 程序编码研发工程师
- 软件测试测试工程师
- 运行维护运维工程师
研发工程师和运维工程师的矛盾
- 研发是由功能性需求（通常与业务需求直接相关）驱动的。渴望随时随地发布新功能，没有任何阻拦。
- 运维是由非功能性需求（例如可获得性、可靠性、性能等）驱动的。希望一个东西在生产环境中正常工作了，就不要再进行任何改动。
运维基本工作：发布、监控、日志、告警
运维职责
- 保障业务系统的稳定性。
- 加快业务对应用的迭代周期，提升IT对业务的支撑能力。
- 给业务提供资源保障。
- 减少费用支出。
运行维护是软件生命周期中持续时间最长的阶段，运维工程师是一个非常重要的角色。

认识SRE

什么是SRE
- 站点可靠性工程师（ Site Reliable Engineer ）
- SRE的职责是运维一个服务，该服务由相关的系统组件组成，为最终用户提供服务（可以是内部用户或者外部用户）。
- SRE的终极责任是确保该服务可以正常运转。为达成这个目标，SRE需要完成以下一系列工作：开发监控系统，规划容量，处理紧急事件，确保事故根源被跟踪修复等。
什么是LCE
- 发布协调工程师（ Launch Coodination Engineer ）
- LCE的职责是建立发布新服务检查列表，建立发布流程，变更管理，保障在快速迭代下服务的可靠性。
研发工程师和SRE工程师
- 研发工程师：设计，构建软件系统。
- SRE：专注于整个软件系统的生命周期管理，从设计一直到部署。
SRE的基本工作
- 深度参与开发阶段工作，对应用程序的设计实现方式、依赖库、运行时的资源消耗都有严格的规约。
- 强调对问题和故障的自动处理，而非人工干预。
- 按照SRE的约定，开发人员自行负责程序上线部署更新，毕竟开发人员对自己的程序更熟悉，易于处理程序上线过程遇到的问题。
优化工作
- 可用性改进
  - 百分之百的可用性是不现实的，需要达到这个目标的成本通常远超于所能获得的价值，设置容错率，既保证用户体验又不影响创新和部署的速度。 SLO
- 延迟优化
- 性能优化
- 效率优化
  - 如果能够通过密切关注一个服务的容量配置策略，进而改进其资源利用率，这可以非常有效地降低系统的总成本。
SRE终极目标
- SRE团队应该倾向于将基本的运维工作全部消除，全力投入在研发任务上。
- 目标是整个系统应该可以自主运行，可以自动修复问题。
- 终极目标是推动整个系统趋向于无人化运行，而不仅仅是自动化某些人工流程。

避免琐事

琐事
- 手动的，重复性的，可以被自动化的，战术上没有持久价值的工作。
如何避免琐事
- 负责运维的整个服务的团队成员必须要有足够的时间编程，否则他们会被运维工作所淹没。
- 任何的手工操作必须控制在百分之50的时间内，至少保留百分之50的时间用于自动化开发上。

工程化

工程工作
- 符合长期战略的，会对你的服务进行长久性改善的工作。
- 通常是有创新性和创造性的，着重通过设计来解决问题，解决方案越通用越好。
- 例如：编写优化自动化脚本；监控部署，系统参数调优，架构设计优化；自动化重复工作。
工程化
- 使用软件工程的方法解决复杂的运维问题
- 最简化
  - 法国诗人 Antoine de Saint Exupery 曾经写道：不是在不能添加更多的时候，而是没有什么可以去掉的时候，才能达到完美。这个原则同样适用于软件的设计和构建。例如API的参数最少化。
- 模块化

自动化

自动化的价值
- 一致性
- 平台性（可以理解为普遍性，广泛适用，符合成本收益）
- 修复速度更快，行动速度更快
- 节省时间
如果我们持续产生不可自动化的流程和解决方案，我们就继续需要人来进行系统维护，如果我们需要雇佣人来做这项工作，就像是用人类的鲜血、汗水和眼泪来养活机器。这就像一个没有特效但充满了愤怒的的系统管理员的Matrix世界。
- 一位负责Google数据中心集群上线流程的SRE Joseph Bironas
演变：自动化、系统化、自治系统
1. 没有自动化
2. 外部脚本进行自动化
3. 外部通用脚本进行自动化
4. 系统内部脚本进行自动化
5. 系统内部机制自动化

监控

监控的目的
- 对真实问题进行报警
- 临时性回溯分析（例如刚刚延迟大幅度增加，有什么其它的现象也发生了）
- 优化，对比服务更新前后的状态变化，新的版本是否让软件运行得更快？
  - 例如观察某一个参数改变后产生的变化（跨时间范围的比较）
- 分析长期趋势，进行容量调整。
- 检查资源使用量随着时间的变化情况，制定合理的资源变化策略。
4个监控黄金指标
- 延迟
  - 例如站点平均响应时间等
- 流量
  - 例如每秒钟HTTP请求速率等
- 错误
  - 例如 5XX返回码等
- 饱和度
  - 例如内存剩余量、CPU利用率等等
注意：平均值、长尾值
简化，直到不能再简化
- 一个季度内都没有使用到的指标可以评估是否删除掉
- 这条告警是否可以通过自动化处理的方式解决
- 收集的数据，却没有拿来观察或者告警的可以评估是否删除掉
服务健康指标
- 低级需求：能够正常对外提供服务。
- 高级需求：SRE能够主动控制服务状态，而不是被动救火。
监控系统：数据收集、数据存储、数据可视化、告警、事故跟踪

发布工程

角色：
- 统计发布速度…
- 发布流程
  - 代码发布和配置发布的解耦
  1. 发布
  2. 执行单元测试/压测/审查代码
  3. 编程成二进制文件
  4. 系统级集成测试部署
  5. 生产环境部署
  6. 生成改动列表报告
任何组织都需要根据自生情况，寻求适合自己的发布流程策略。
迭代与稳定
- 定制SLO（服务目标水平），根据实际情况，进行调节
- 如果研发迭代导致的时间超过了我们这个月需要达到的服务目标水平，则停止这个月份的发布
- 敏捷性是建立在稳定性之上的
测试
- 单元测试：某个函数、方法的测试
- 集成测试：由多个单元测试组成
- 系统测试
  - 冒烟测试：测试核心功能
  - 性能测试：
  - 回归测试：测试之前发生过的bug，保证它不会再次发生
- 生产测试
  - 配置测试：保证生产环境的配置被正确地加载了
  - 压力测试
  - 金丝雀测试：升级部分部署节点，控制流量流入新版本和旧版本的比例

oncall

紧急事件
- 东西早晚要坏的，这就是生活。
- 故障演练，灾难恢复演习，假设可能的问题发生。
在进行oncall时，SRE需要动手运维系统，观察和调整系统的弱点，以及理解如何能大规模扩展这些系统。
根本性地解决问题：在每8～12小时的on-call期间，最多只处理2个紧急事件，这个准则保证on-call工程师有足够的时间根据紧急事件，正确地处理故障，恢复故障，撰写一份事后报告。
故障报告
- 内容：事故发生，问题发现，解决的全过程，事故的根本原因，预防或者优化的解决方案。
- 每份事故报告需要被他人审核。
oncall-培训-例如维护 XXXXX 项目
- 故障手册
- 阅读并理解以下文档
  - 数据流程图（从客户端请求到结果返回）
  - 发布流程
  - 紧急情况的演练
- 回答以下综合性问题
  - XXXXX 项目部署在哪个集群里，如何登入这个集群的生产环境
  - 有一条紧急告警”XXXXX 项目 5xx返回码数量1分钟内大于100条“，如何处理
  - 该项目的哪些方面可以简化或者自动化

团队管理

主动性SRE工作包括：软件自动化、架构设计咨询、发布流程协调等。
被动性SRE工作包括：在线调试、故障排除、处理on-call情况等等。
中断性工作会导致工程师的上下文切换（工作类型、工作环境的改变），犹如CPU需要为不同的线程计算进行切换。
计划性工作。
保持团队人员的多样性，系统工程师，软件工程师。注意团队成员间的沟通，防止认知偏差。
接手一个项目的运维，评审
- 系统的体系结构和跨服务依赖
- 指标的选择，度量，监控
- 紧急事件处理
- 容量规划
- 变更管理
- 性能：可用性、延迟和资源效率
- SLO
牺牲工程实践而做琐事，会对SRE组织整体的发展造成损害。

K8S

为什么需要K8S
- 将硬件和软件进行解耦
- 业务团队运行软件服务时不需要担心硬件故障
- 容器编排，自动重启，快速扩容，生命式管理服务，服务健康检查自动修复…
为什么需要request和limit
- 一个缓慢的不断重启的Pod，要好过一个永远不重启一直泄露资源的Pod。

其它章节

负载均衡
- 有质量的回复
- 前端服务器负载均衡
- 后端负载均衡
- 应对过载
- 处理连锁故障
分布式
- 分布式共识机制
数据完整性
- 交付一个恢复系统，而不是备份系统

当前问题

面临的挑战

数据库瓶颈，顶配数据库空间仍然无法支撑业务发展。
慢SQL数量爆发式增长，应用稳定性岌岌可危。
# 全链路预警信息最多每天200+，系统隐患逐步暴雷。
人工运维频率高，研发幸福感下降。
长尾请求严重影响服务质量，5XX错误持续走高，影响客户体验。
# 不一致性资源长期无法收敛，资损无法解决。

解决创建用户，分配权限琐事。
- 自动化创建用户/权限分配系统
- 核心是：通过调用jenkins、yearning等平台的接口，自动创建并且分配初始化权限。
解决投放广告带来的流量激增
- 广告系统对接K8S系统，当运营人员点击投放广告时；程序先自动触发Pod的扩容，当扩容完成后，再投广告，避免流量突增导致异常。
网站崩了，为什么终端用户不能继续进行搜索游览商品（故障容忍度）
- 当主库崩了，切换到从库，代码开启只读模式，web界面上方标注维护模式，用户只能进行不需要数据库insert和update操作的行为
- 诺出现数据库insert和update操作的行为，则提示系统维护中，需要等待一段时间
故障总结与新员工
- 我们的故障总结不够详细
- 如果我们的故障总结足够详细，那么在新员工进行on-call前，通过阅读之前的故障总结能获得一定的帮助。

《SRE Google运维解密》散文相关推荐

SRE Google 运维解密--管理
一.迅速培养SRE加入on-call 在SRE团队的职责中,主动性任务和被动性任务兼有,每个SRE团队都坚守的一个重要目标是:利用积极主动的办法,去减少和限制被动性工作的产生. SRE培训课程推荐的 ...
SRE Google运维解密pdf
下载地址:网盘下载自动化对Google SRE 的价值 62 自动化的应用案例 63 Google SRE 的自动化使用案例 63 自动化分类的层次结构 64 让自己脱离工作:自动化所有的东西 66 ...
读SRE Google运维解密有感(一)
第一章读后感 SRE之道的理解:创建软件系统来运行和替换传统的人工操作. 在实际工作中: 1.我们执行重复性的工作,流程话,新建项目需要那些资源,那些账号,那些权限,制作成流程,一个项目来了相关同事按 ...
《SRE Google运维解密》读书笔记
SRE团队职责: 确保服务可以正常运转,主要方向包括: 可用性改进延迟优化性能优化效率优化变更管理 (渐进式发布) 监控紧急事务处理容量规则与管理 (N+2 模式,google--> ...
《SRE：Google运维解密》
2019独角兽企业重金招聘Python工程师标准>>> 前言问世近一年以来,<SRE: Google 运维解密>一书销量累计已两万余册.我想首先感谢各位读者对本书的支持 ...
读书笔记（SRE：Google运维解密）：第22章处理连锁故障
连锁故障是由于正反馈循环(positivefeedback)导致的不断扩大规模的故障. 连锁故障可能由于整个系统的一小部分出现故障而引发,进而导致系统其他部分也出现故障.例如,某个服务的一个实例由于过 ...
读书笔记（SRE：Google运维解密）：第27章可靠地进行产品的大规模发布
发布协调工程师(Launch CoordinationEngineering,LCE),LCE (a)广泛的经验 (b)跨职能的视角 (c)客观性好的发布流程具有的一些特征: 轻量级:占用很少的开发 ...
SRE（运维工程师）成长路上的十本书籍推荐
今天来整理一下自己在SRE成长路线上一些对自己帮助很大的书籍. 更多内容可以关注微信公众号"SRE说" 运维了解和入门的两本书书籍一:<网站运维:保持数据实时的秘技> ...
一文讲透研发，SRE，运维，DevOps 的区别
研发,SRE ,运维是工种,而 DevOps 是体系.如果拿足球来打比方,研发,SRE ,运维对应的就是前锋,中场,后卫这样的位置,而 DevOps 则是诸如 4-3-3 这样的阵型. 研发也叫研发 ...
谷歌SRE与运维工作的思考
点击上方"朱小厮的博客",选择"设为星标" 后台回复"1024"获取公众号专属1024GB资料来源 | rrd.me/fR8u9 运维部门 ...

《SRE Google运维解密》散文

文章目录

SRE

认识运维

认识SRE

避免琐事

工程化

自动化

监控

发布工程

oncall

团队管理

K8S

其它章节

当前问题

《SRE Google运维解密》散文相关推荐

最新文章

热门文章