Google SRE 概览
- 系统管理员模式,雇佣系统管理员运维复杂的计算机系统,随着系统变得越来越复杂,组件越来越多,相关的事件和变更也会越来越多,于是公司招聘更多的系统管理员。该模式中存在2个问题。
- 直接成本,因为团队大部分维护事件和变更的实施是依赖人工处理,团队的大小、成本与系统负载成线性相关;
- 间接成本,研发部门和运维部门的工作目标是截然不同的,甚至是互相矛盾的,由此带来的分歧与沟通问题给公司带来的间接成本往往大得多;
- GOOGLE的解决办法:SRE(Site Reliability Engineering)模式,是Google在DevOps上的具体实践,创造软件系统来维护系统运行以替代传统模型中的人工操作,用软件工程的思维和方法论完成以前由系统管理员团队手动完成的任务,通过设计、构建自动化工具来取代人工操作。
- SRE团队成员要对重复性、手工性的操作有天然的排斥感,需要有足够的技术能力快速开发出软件系统以替代手工操作;
- 传统的Ops团队,随着产品负载得增涨就需要更多的团队成员来重复进行同样的事情;
- 传统运维工作包括工单处理、手工操作等,负责运维以上产品的团队必须有足够的时间改进所维护的服务,将50%的精力花在真实的优化、开发工作上,否则他们就会被运维工作所淹没;
- Google 将 SRE 团队的运维工作限制在 50% 以下,SRE 团队应该将剩余时间花在研发项目上,SRE 管理人员应该经常度量团队成员的时间配比,想一切办法去保证这个50%的安全线。
- SRE 处理运维工作的时候的一项准则是:在 8 ~ 12 小时的 on-call 轮值期间最多应该只处理 2 个紧急事件。这个准则保证了 on-call 工程师有足够的时间跟进紧急事件,正确地处理并且恢复服务,并且要撰写一份事后报告。正常状况是是让每一天需要 SRE 响应的紧急事件都是一个合理的负载,每一个事件都可以被专业地处理。
- 所有的产品事故都应该有对应的事后故障总结,无论有没有触发警报。事后故障总结应该包括以下内容:故障发生、发现、解决的全过程,故障的根本原因,预防或者优化的解决方案。在一个故障总结中,你应该列出所有导致故障触发的因素,而不是把它当作一个承认错误的地方。
- 企业中,最主要的矛盾就是迭代创新的速度与产品稳定程度之间的矛盾,在 SRE 模型中使用的工具是错误预算;
- 公司的商业部门或者是产品部门必须建立起一个合理的可靠性目标。一旦建立,“错误预算”就是“1 - 可靠性目标”。如果一个服务的可靠性目标是 99.999%,那么错误预算就是 0.001%,在一年中的累计服务不可用时间为8.76小时。这意味着产品研发部门和 SRE 部门可以在这个范围内将这个预算用于新功能上线或者产品的创新等任何事情。
- 尽量不要把错误预算都花在一个地方。“错误预算”都可以用于什么范畴呢?研发团队需要用这个预算上线新功能,吸引新用户。理想情况下,我们应该使用这个错误预算来最大化新功能上线的速度,同时保障服务质量。这个基本模型建立起来之后,许多常见的战术策略,例如灰度发布,1% A/B 测试等就全说得通了。这些战术策略都是为了更好地使用整个服务的错误预算。
- 在 Google 有一个规则:没有不需要采取行动的警报,如果您遇到一个自己认为不需要执行操作的警报,您需要采用自动化的手段来修复该警报;
- 明确警报问题修复的责任,并跟进相关团队,提交 bug 并跟踪记录为什么会这样的问题;
- 调整警报阈值,避免用户并没有出现访问问题时候发送报警;
- 删除那些无效警报,因为它是无用的和不相关的;
- 警报,收到警报的用户需要立即执行某种操作,目标是解决某种已经发生的问题,或者是避免即将要发生的问题,如果在5分钟内没有被回应,它会找到你的替代者。如果问题落到替代者来处理,Google SRE 团队有一个送花规则,你将需要给替代者送去花和一张卡。
- 工单,意味着接受工单的用户应该执行某种操作,但是并非立即执行。尤其是监控到的故障事件在符合设计条件时,要直接自动化得在任务管理系统中生成一个任务工单。
- 日志,平时没有人需要关注日志信息,但是日志信息依然被收集起来以备调试和事后分析时使用。
- 任何需要人工操作的事情,都只会延长恢复时间。
- 通过事先预案并且将最佳方法记录在“运维手册”上通常会使 MTTR 降低 3 倍以上。在巨大的时间压力和产品压力下,运维手册中记录的清晰调试步骤和分析方法对处理问题的人是不可或缺的。
- 没有手册是一个奢侈的事情,只有在团队需要支持的事情很少的情况下可行。我们这些支持很多系统的人不能将所有内容全部放入脑子。
- 如果手册无用,就应该重建它,或删除警报和手册。因为没有足够有用的背景信息的警报是如此危险。
- Google SRE 将大部分重心放在“运维手册”的维护上,同时通过“Wheel of Misfortune”(厄运之轮)等项目培训团队成员。
- 采用渐进式发布机制。
- 迅速而准确地检测到问题的发生。
- 当出现问题时,安全迅速地回退改动。
这三点可以有效地降低变更给 SRE 和最终用户带来的时间成本和服务质量的下降。于是,变更执行的速度和安全性同时得到了提高。
- 必须有一个准确的自然增长需求预测模型,需求预测的时间应该超过资源获取的时间。
- 规划中必须有准确的非自然增长的需求来源的统计。
- 必须有周期性压力测试,以便准确地将系统原始资源信息与业务容量对应起来。
- 高效地利用各种资源是任何营利性服务都要关心的。因为 SRE 最终负责容量的部署和配置,因此 SRE 必须也承担起任何有关利用率的讨论及改进。因为一个服务的利用率指标通常依赖于这个服务的工作方式以及对容量的配置与部署上。如果能够通过密切关注一 个服务的容量配置策略,进而改进其资源利用率,可以非常有效地降低系统的总成本。
- 一个业务总体资源的使用情况是由以下几个因素驱动的:用户需求(流量)、可用容量和软件的资源使用效率。SRE 可以通过模型预测用户需求,合理部署和配置可用容量,同时可以改进软件提升资源使用效率。通过这三个因素能够大幅度推动一个服务的效率提升(但是并非全部)。
- 软件系统一般来说在负载上升的时候,会导致延迟升高。延迟升高其实和容量损失是一样的。当负载到达临界线的时候,一个逐渐变慢的系统最终会停止一切服务。换句话说,系统此时的延迟已经是无穷大了。SRE 的目标是根据一个预设的延迟目标部署和维护足够的容量。SRE 和产品研发团队应该共同监控和优化整个系统的性能,这就相当于给服务增加容量和提升效率了
- 约 10 台硬件服务器组成了一个机柜(Rack)
- 数台机柜组成一个机柜排(Row)。
- 一排或多排机柜组成了一个集群(Cluster)
- 一般来说,一个数据中心(Datacenter)包含多个集群
- 多个相邻的数据中心组成了一个园区(Campus)
- Borg 负责运行用户提交的“任务”(Job)。每个任务可以由一个或多个实例 (Task)组成(有时候甚至由几千个实例组成)。
- 当 Borg 启动一个任务的时候,它会为每一个实例安排一台物理服务器,并且执行具体的程序启动它。
- Borg 同时会不断监控这些实例,如果发现某个实例出现异常,其会终止该实例,并且重启它,有时候会在另外一台物理服务器上重启。
- 因为实例与机器并没有一对一的固定对应关系,不能简单地用 IP 地址和端口来指代某一个具体任务实例。为了解决这个问题,增加了一个新的抽象层。 每当 Borg 启动某一个任务的时候,Borg 给每个具体的任务实例分配一个名字和一个编号,这个系统称之为 Borg 名称解析系统(BNS)。
- Borg 还负责将具体资源分配给每个任务。每个任务都需要在配置文件中声明它需要的具体资源 (例如: 3CPU 核心 , 2GB 内存等)。
- Borg 还关注物理服务器的故障域属性,同一个服务的多个实例会被分散部署到多个机柜中,如果某一个任务实例的资源使用超出了它的分配范围则会被Borg重启。
- 几百台 Google自己制造的交换机用 Clos (贝尔实验室Charles Clos)连接方式连接起来创建了一个非常快的虚拟网络交换机,这个交换机有几万个虚拟端口。 这个交换机的名称叫 Jupiter。在 Google 最大的一个数据中心中,Jupiter 可以提供 1.3 Pb/s的服务器交叉带宽。Clos,A study of Non-Blocking Switching Networks(http://dx.doi.org/10.1002/j.1538-7305.1953.tb01433.x)
- Google 数据中心是由一套全球覆盖的骨干网B4连接起来的。Google 使用一个基于 OpenFlow 的软件定义网络(SDN),没有选择使用高级智能路由器连接,而是采用 了普通的非智能交换组件+集中化(有备份的)的控制器连接方式。 该控制器负责计算网络中间的最佳路径,将整个集群的复杂路由计算从具体交换硬件上分离开来,从而降低成本。
- 带宽控制器(Bandwidth Enforcer,BwE)负责管理所有可用带宽,不仅需要优化带宽的使用以降低成本,还需要解决流量迁移问题。
- 全球负载均衡系统(GSLB)在三个层面上负责负载均衡工作 :
- 利用地理位置信息负载均衡 DNS 请求。
- 在用户服务层面进行复载均衡,例如 YouTube 和 Google Maps。
- 在远程调用(RPC)层面进行负载均衡。
- 使用生成树协议或三层路由核心网络构建的传统网络的问题是从一组备选路径中选择单个“最佳路径”。
- 所有数据流量采用“最佳路径”,直到它被拥塞,然后分组被丢弃。
- 不再使用生成树协议,但同时仍然保持无环路拓扑,且同时利用所有多个冗余链路。
- Clos网络现在表现为交换机互连的方式,数据中心网络由机架顶交换机和核心交换机组成。
- 叶交换机不彼此连接,并且主干交换机仅连接到叶交换机(或上游核心设备)。
- 来自叶交换机的上行链路的数量等于主干交换机的数量。连接总数等于中心交换机数量乘以叶交换机的数量(在该图中8×4 = 32个链路)。
- Clos网络的优点是您可以使用一组相同和便宜的设备来创建树并获得高性能和弹性。
- 通信路径是随机选择的,使得业务负载均匀分布在顶层交换机之间。 如果其中一个顶层交换机出现故障,它只会稍微降低数据中心的性能。
- 目前主流的网络设备厂商也都有支持Clos网络架构方案的相关设备型号,一般用于数据中心规模的网络建设方案。
Google SRE 概览相关推荐
- Google SRE系列第三部来了!
如果系统非常安全,那么它一定可靠吗? Google曾遭遇一个有关安全性和可靠性的死循环.最终,Google的工程师用一把电钻破解了死循环. 是的,你没看错,用一把电钻. 2012年9月27日,Goog ...
- 《Google SRE》读后感
Google SRE 封面 国庆长假,出门太堵,遂待在魔都,花了三天时间将<Google SRE>中文版翻了一遍,好书一本,不管是开发人员.运维人员还是架构师,都可以读一读,受益匪浅的. ...
- D. Google SRE 管理 - 培训SRE
D. Google SRE 管理 - 培训SRE 培训课程 正确的方式 设计一个具体的,有延续性的学习体验,以便学员跟进 鼓励反向工程,利用统计学来思考问题,以及多思考问题本质 鼓励学员分析失败的案例 ...
- A. Google SRE概述
A. Google SRE概述 概述 开发与运维的关注点 开发:如何能够更快速地构建和发布新功能 运维:如何提高可用性,降低故障率 Google SRE团队组成 前提 所有的SRE团队成员都必须非常愿 ...
- GOOGLE SRE 运维模式解读
最近要整理一些关于应急响应方面的解决方案材料,又重新翻阅了一遍<SRE:Google 运维解密>这本书,非常值得我们借鉴和思考.本文将包括如下内容: SRE核心是什么 SRE工程师具有什么 ...
- Google SRE 读书笔记 扒一扒SRE用的那些工具
写在前面 最近花了一点时间阅读了<SRE Goolge运维解密>这本书,对于书的内容大家可以看看豆瓣上的介绍.总体而言,这本书是首次比较系统的披露Google内部SRE运作的一些指导思想. ...
- Google SRE最佳实践之On-Call
本系列文章将详细介绍如何从0到1快速构建SRE团队具体实战内容,敬请关注. 上期文章<一文彻底读懂DevOps与SRE来龙去脉> "On-call"言下之意就是&quo ...
- Google Mesa概览
Google Mesa的文章:https://research.google.com/pubs/pub42851.html https://gigaom.com/2014/08/07/google- ...
- SRE Google运维解密pdf
下载地址:网盘下载 自动化对Google SRE 的价值 62 自动化的应用案例 63 Google SRE 的自动化使用案例 63 自动化分类的层次结构 64 让自己脱离工作:自动化所有的东西 66 ...
最新文章
- SAP PM创建/计划MO
- Uber致人死亡或为自动驾驶肇事责任 没有判例可循
- Python web 开发:部署一个3行代码的wsgi app
- JAVA面向对象的总结(函数重载与数组)
- 第二章kNN分类算法sorted函数
- python登录网站后爬取数据_用 Python 登录主流网站,我们的数据爬取少不了它
- java.lang.ClassNotFoundException: org.springframework.web.context.ContextLoaderL,spring获取context
- 解决在使用 Qt 编译项目时出现 “C4819: 该文件包含不能在当前代码页(936)中表示的字符。请将该文件保存为 Unicode格式以防止数据丢失“ 的警告
- sqlmap —— os-shell参数分析
- 编程疑难杂症の设置正确却无效的事件代码
- 奇异值值分解。svd_推荐系统-奇异值分解(SVD)和截断SVD
- linux多线程时序问题,Linux时序竞态问题(sleep函数的实现)
- dell2100服务器组装,戴尔poweredge r730服务器配置及系统安装详解教程
- 【每日算法Day 67】经典面试题:手动开根号,你知道几种方法?
- 关于打包测试环境,百度地图报 Bmap not undefined
- python统计套利_基于python的统计套利实战(二)之协整检验
- 为什么买域名必须实名认证?这样做什么原因?
- python-docx处理word文档功能详细说明
- .NET Framework各个版本(3.0 - 3.5)
- 希尔排序选择排序时间复杂度分析