SRE Google 运维解密--管理

一、迅速培养SRE加入on-call

在SRE团队的职责中，主动性任务和被动性任务兼有，每个SRE团队都坚守的一个重要目标是：利用积极主动的办法，去减少和限制被动性工作的产生。

SRE培训课程

推荐的培训方式	错误的培训方式
设计一个具体的、有延续性的学习体验，以便学员跟进	通过给学员安排一些烦琐的工作（处理警报/工单）来培训
鼓励反向工程，利用统计学来思考问题，以及多思考问题的本质	要求严格按照现有的操作过程，检查列表，或者手册来执行命令进行训练
鼓励学员分析失败的案例，分享好的事后总结来阅读	将故障掩盖起来，以便躲避指责
创造一些受控的，但是逼真的场景让学员利用真实的监控环境和工具来修复	在学员加入on-call之后，第一次遇到问题时才会去尝试修复
在团队内以角色扮演的形式学习理论上可能发生的问题，让大家在这个过程中交流彼此的解决问题的方式	在团队中将知识隔离起来，创造出一些只在某个领域内的专家
给学员创造条件让他们参与见习on-call，和实际轮值的on-call工程师交流经验	在学员还没有对服务有全在认识的情况下，就要求他们成为主on-call
让学员与SRE老手一志共同修订培训计划中的某个部分	认为on-call培训素材是静态的，非专家不可更改
帮学员一起找到一个具有一定复杂度的项目，帮助他们在整个技术栈内建立自己的地位	将新项目全部分配给SRE老手，新手SRE只能做一些零工

培养SRE加入on-call的计划图

X轴代表工作类型的范围，从抽象的，一直到具体的工作。
Y轴代表时间，从上至下，新加入的SRE逐步学习和掌握加入on-call轮值必备的知识和技能。

培训初期：重体系，而非混乱

系统性、累积性的学习方式

在系统中加入某种顺序性，以便新的SRE成员可以建立某种学习路径。

任何类型的系统性培训都要比直接处理随机出现的工单和琐事要好。但是我们应该有选择性的将一些理论性和实践性的学习组合到一起：一些新成员经常会用到的、系统的抽象概念应该优先，而学员也应该尽早进行真实的实践操作。

了解任何一个技术栈，都需要一个起点。我们应该考虑将培训按照类似作用分组，还是按照常用的执行顺序分组。例如，一个实时、直接面向用户的服务系统，可以按以下顺序进行培训：

请求是如何进入系统中的
前端服务
中层服务
基础设施
整体

可以采用on-call培训检查列表的形式，归纳和管理培训项目、内容。

可以考虑在服务访问权限控制的配置中实现一种分层模式，第一层权限允许学员以只读访问组件的内部信息，接下来则是允许修改生产环境状态，最终学员会逐步拥有系统的最高权限。

目标性强的项目工作，而非琐事

SRE是天生的问题解决者，所以我们应该给予他们一个难题去解决。

Google内的标准做法是，所有的工程师都会被分配一个初始项目，给他们提供足够的基础设施知识，同时让他们可以为服务做一点小的但是有意义的贡献。让新的SRE成员将时间同时分配在学习和项目工作中可以给他们一种参与感和效率感。这比让他们专攻两者中的任意一个要好。

常见的新手项目类似于：

在服务技术栈中增加一个小的，但是用户可见的功能修改，接下来跟随这个修改一直到发布到生产环境中。了解开发环境的配置和二进制文件的发布流程可以确保他们和开发团队联系密切。
针对现有的服务监控盲点增加新的监控，新手需要了解监控逻辑，同时将这些异常情况与系统知识相结合。
选择一个还没有被自动化的痛点进行自动化，使得新的SRE可以给团队成员减轻一些负担，从而受到团队的欣赏。

培养反向工程能力和随机应变能力

SRE在运维复杂系统或超大规模系统时，需要具备以下关键能力：

在日常工作中，他们会遇到从未见过的系统，必须要具有很强的“反向工程能力”；
在海量规模下，很多异常情况都很难检测，他们必须具有统计学知识，用统计学而不是流程化的方式去发现问题；
当标准的流程不工作时，他们必须能够随机应变，解决问题；

反向工程：弄明白系统如何工作

工程师对他们从未见过的系统都很好奇——工作原理是什么?通过对系统工作原理的基本理解，同时愿意深入研究调试工具、RPC框架，以及系统的二进制文件来理解其中的数据流动，SRE就能够在陌生环境中更高效地处理始料未及的额外难题。

统计学和比较性思维：在压力下坚持科学方法论

我们应该培训SRE新员工从一入职就成为好的数据分析者。在紧急情况处理的有限时间中，SRE只能在几百个可能的选择中选择几个动作去执行，缓解故障。因为时间通常是有限的，SRE必须能够有效地在决策树中进行抉择。

随机应变的能力：当意料之外的事情发生时怎么办

假设某个SRE按照手册修复某个问题，但是没有成功。该故障系统的开发团队无法联系，这时候怎么办呢？

当然要临场发挥！

通过学习多种解决不同问题的工具可以保障工程师有多种手段处理问题。在非常复杂的故障排除过程中，SRE通常需要利用很多未经验证的假设来进行决策。在SRE培训初期加入一些关于决策“陷阱”的描述，以及关于如何能够及时抽身，从更高层面换一个角度去思考问题的解决方案，是非常有价值的。

下面是一个培训新员工逐步掌握应变能力的例子：反向工程某个生产环境服务

Google内部最受欢迎的一门培训课程就是“如何反向工程某个生产环境服务”。例如：整个Google新闻团队——包括SRE、开发工程师、产品管理团队等——都去参加团建了。目的地是百莫大三角区。我们已经30天没有他们的消息了。课程学员作为新组建的Google新闻SRE团队成员，需要自行搞清楚整个服务端到端的工作原理，以便能保障它继续运行。

学员会经过一系列交互性的、目的性很强的练习，在Google基础设施中跟踪他们浏览器发出的某个请求。
在整个过程中的每一段，我们强调学习利用多种方式来发现生产服务之间的连接关系的重要性。这样可以防止某些连接关系被遗漏。
我们还会让学员跟踪另外一个来源请求，这会展示出我们一些最初的假设范围太窄，产生的是错误的结果。
接着还会让学员学习通过其他方式了解服务原理。
在课程末尾会给每个学员分配一项任务，每个学员需要和自己团队的资深SRE共同选择未来on-call系统的一部分。利用课程中学到的知识，该学员需要自行构建出整个技术栈的组件图，同时与资深SRE讨论。

有抱负的on-call工程师的5个特点

on-call轮值一般不是SRE的主要目标，但是生产环境运维经常会需要响应某种类型的紧急事故。

对事故的渴望：事后总结的阅读和书写，定期举办事后总结的阅读活动，可以潜移默化地构建起SRE的知识库，培养他们理解生产环境的能力和应对问题的能力。事后总结同时也是未来进行抽象化故障演习时的良好材料。
故障处理分角色演习：这个活动同时也被称为“命运之轮”，是成员每周共同学习的好机会。具体过程类似桌游RPG游戏，设定一个主持人，再选择2个团队成员作为主on-call和副on-call。主持人宣布某个警报发生了，这个on-call团队需要进行调查和现场处理报警。主持人事先准备好了一个场景，很可能是以前发生过的故障，但新成员没经历过，老成员也忘了的事故。主持人需要随着问题的展开而提供更多的信息，甚至要扮演成其他团队成员来回签问题。因为虚构的场景不一定是完善的，所以主持人需要对过程中的干扰因素进行说明、干预。
破坏真的东西，并修复它们。
- 当有多数据中心部署的系统时，可以将流量从一个系统中切走，将该实例作为练习使用。
- 或者搭建一个小型、但是功能齐全的QA实例，用作培训。
- “一起来摧毁一个搜索集群”：从系统的某一个正常状态出发，慢慢将环境中某个组件逼近瓶颈，通过监控系统观察对上下游的影响。
- - 作为一个团队，我们讨论哪些性能特点可能会在过程中受到影响。
  - 在实际操作之前，我们进行一次调查，让所有参会的人都提出一个针对系统行为变化的假想和背后的逻辑。
  - 具体执行操作，验证之前的假设，并且从罗中说明为什么系统会出现这样的现象。
  - 这个团体活动，每个季度会进行一次，有助于在生产环境中发现存在的Bug——有时系统并不像我们想象的那样优雅降级。
维护文档是学徒任务的一部分。很多SRE团队要维护一个"on-call学习检查列表"。该列表中包含一系列阅读材料，以及关于系统的各种技术和知识的完整列表。学员必须充分掌握该列表才能进行见习on-call。该学习检查列表对不同的人来说作用也不同：
- 对学员来说
- - 这个文档可帮助学员了解运维系统的边界
  - 通过学习这个文档，学员可以了解系统的重要组件，以及背后的原因。
- 对导师和管理者来说
- - 学员的学习进度可以通过检查列表来反映。
  - 学员今天学习的是哪一节
  - 哪一节是最让人困惑的。
- 对其他团队成员来说
- - 文档成为一种社会契约，只有掌握这个文档的员工才能加入on-call。这个学习检查列表成为一个知识的标准，所有的团队成员都必须符合这个标准。
尽快、尽早见习on-call
- 开始时可以安排学员只接收工作时间的警报信息，让他们利用自己的好奇心驱动自己去熟悉警报背后的系统逻辑。
- 在一个警报发生时，学员并不是问题解决的负责人，他们可以亲眼观察故障发展，而不是在事后学习，在故障解决后的某个时机，on-call可以和学员一起讨论背后的处理逻辑和过程。
- 反向见习学员，安排学员成为主on-call，但是资深的on-call成员会在一边观察，让学员独立检查问题，资深SRE可以提供积极的帮助但不能做任何修改操作。

二、处理中断性任务

一些类型的运维负载是可以预计并且计划的，但是更多的负载都来自于未预料的地方，可能会牵扯某个人很长时间，甚至需要某个人现场决策这件事情是否可以稍后处理。

运维工作中的负载基本上可以分为三大类：

紧急警报
工单
日常运维任务

如何决策对中断性任务的处理策略

以下是SRE团队使用的比较多的指标：

中断任务的SLO，即预期的响应时间
排除的中断性任务有多少
中断性任务的严重性程度
中断性任务的发生频率
可以处理某种中断性任务的人有多少

不完美的机器

从某种意义上讲，人类可以被称为不完美的机器。人会感觉无聊，人的处理器（指思维方式）工作原理不清楚，用户界面（指沟通方式）也不太友好，效率也不高。

在工作中需要能认识到人的这些缺陷，以取长补短。那么怎么考虑和做出这些决策呢？

什么是“流状态”？ flow state是一个软件工程行业内被普遍接受、人尽皆知的理念。“在状态里”可以提升生产力，也可以提升创造性，进入这个状态可以鼓励员工真正地掌握和优化某个他们负责的任务和项目。但是如果有其它事情打断他们，他们就会失去这个状态。所以我们的目标是尽可能让员工工作在这个状态下。
认知流状态：富有创造性和参与感。最大化某个成员在这个状态下的时间是非常好的，这个员工将会产生出很强的创造力，成果丰硕。同时这个员工也会更满意自己的工作。不幸的是，很多SRE成员花费了很多时间进入这个状态，但是被各种事情所打断而无法持续导致很沮丧。又或者，这些人没有试着去进入这种状态，而是一直处于不停被打断的模式中。
认知流状态：愤怒的小鸟。在SRE环境下，员工在项目工作和中断性工作模式下找到某种平衡一般是更好的。
- 有些工程师把on-call当作是一段时间之内的专职工作，他们追寻问题原因，与其他人协作，在可以明显改善系统整体健康程度的过程中感到极大的满足；
- 有些工程师把on-call当作是中断性任务，紧急警报给他们造成了很大压力，他们可能是在进行项目工作的同时兼职on-call，处理中断任务，这使得他们处于一种不停被打断的工作环境中，压力巨大；
- 当某个SRE去全职处理中断性任务时，中断性任务就不再是中断性的了，处理工单、系统改进、修复问题等突然有了明确的目标、界限，以及清晰的反馈：修复了某个bug，或者是紧急警报不报发生了。之前的项目工作反而是分心的事情了。

将一件事情做好：来自Google的SRE团队管理经验

这里关注的焦点是整个团队如何管理中断性任务，以便确保整个团队可以正常工作，从而使得团队成员都能成功。

分心指数。

工程师能够被分心的方法太多了，例如某个名为Fred的SRE星期一正常上班，他今天不是on-call，也不负责处理中断性事务。很明显他希望能够进行他自己的项目工作。但是下列任何一件事都可能随时发生：

Fred的团队使用随机工单分配系统，某个需要今天处理的工单被分配给了他。
Fred的同事目前负责on-call，收到了一个紧急警报。发出警报的组件Fred最熟悉，所以这个同事过来咨询。
某个用户将某个工单的优先级提高了，这个工单是上周Fred轮值时就在处理的。
某个已经持续了三四周的发布到Fred的时候突然出现了问题，Fred需要停下手中的事情检查发布的状态，回滚这个发布等。
某个用户过来咨询一个问题，因为Fred为人和善。
等等。

最后的结果是，虽然Fred有一整天的时间分配给项目工作，他还是很容易被分心。我们可以说某种程度的干扰是不可避免的，也是有意为之的。这是正确的，每个人都有甩不掉的Bug，同事之间也会有关系的产生与职责的分配。

然而作为团队来说，是有一些管理方式能使更多的员工不受干扰的。

极化时间

为了限制干扰数量，我们应该减少上下文切换（指工作类型、环境等的改变）。某引起中断性任务是无可避免的，但因中断事件给工程师带来的上下文切换的成本是昂贵的。在项目工作中，一次20分钟的中断性任务，需要产生两次上下文切换，而这种切换会造成数个小时的生产力的丧失。

为了避免这种经常性的生产力丧失，我们应该延长每种工作模式的时间，一天甚至半天也可以。这种策略与“挤时间”策略工作得很好。

极化时间意味着，当每个人来上班时，他们应该清晰地知道自己今天是否只是做项目工作，还是只是做中断性工作。然后，去坚持和排除分心的事情。

实际一点的建议

一般性建议，如果中断性任务的量对一个人来说太高，那么应该增加一个人负责。这个概念同样适用于工单，以及紧急警报。
on-call，主on-call工程师应该专注于on-call工作，如果他负责一周on-call工作，那么他在这一周应该完全被排除在项目进度之外。如果某个项目非常重要，不能等待一周，那这个人就不应该参与on-call。管理人员不能期望员工在on-call的同时还能在项目上有所进展。
工单，如果目前你是随机分配工单给团队成员，请立刻停止。这样做对团队的时间非常不尊重，也和让员工尽可能不被打扰的目标背道而驰。工单应该有全职人员负责，同时保证占用合理的时间。
持续性的运维工作，例如变更发布、配置文件修改等，尽可能地让整个团队共同负责这件事。定义一个发布管理者的角色来由on-call和其他中断性任务处理者来承担。
负责中断性事务，或者不负责。理想情况下，应完全由on-call工程师负责处理那些中断性事务，非轮值的工程师不应该被搅入其中。

减少中断

如果团队中需要很多人同时进行中断性任务，那么可能这种负载是不能持久的。有一系列方式可以降低整体的工单负载。

实际分析工单。如果工单的根源问题没有人去修复，整个团队不会有任何进展，每个人都会不停地被同样的问题不停地打扰。我们应该定期进行工单与紧急警报的整理会议，在这个会议上应该讨论出现的每一类中断性问题，看是否能够找到根本原因。如果该问题是可以在合理时间范围内修复的，应该暂停临时处理措施，对警报做临时的静音处理，然后去从根源上修复它。
尊重自己，也尊重用户。这条格言主要适用于用户产生的中断性任务。如果工单很多，解决方法繁琐，我们可以使用一些策略来缓解这些问题。
- 团队应该为自己的服务设置合理的服务水平。
- 将某些事务推回给客户解决是可以的。

制订这种策略可以在尊重用户与尊重自己之间选择一个更好的平衡点。如果某个中断性任务的处理非常复杂，耗时很长，但是却不需要SRE具有的高级权限来完成。这时应该考虑将这种请求交给用户自己完成。例如，如果用户需要贡献一些计算资源，我们可以实现准备好代码，或者配置文件的改动模板，同时给用户清晰的指示让他们来完成这些步骤，最后发给SRE评审。一定要记住，如果客户需要某种事情发生，他们应该自己准备好，花一定的精力来做这件事。

这个解决方案的一个问题是要在尊重用户和尊重用户之间寻找一个平衡点。我们的指导思想应该是确保用户发来的请求应该是有意义的、合理的，同时提供了所有需要准备的材料。

同样，我们处理这样的请求也应该是非常及时而且有效的。

三、通过嵌入SRE的方式帮助团队从运维过载中恢复

Google 的SRE团队的标准政策要求团队在项目研发和被动式工作之间均匀分配时间。在实际工作中，这种平衡可能会被每天工单数量的不断增加而被打乱，甚至持续数月之久。长时间承担非常繁重的Ops类型的工作是非常危险的，团队成员可能会劳累过度，不能在项目工作上取得任何进展。当一个团队被迫花费过多时间解决工单的时候，他们就会减少花在改进服务上的时间，服务的可扩展性和可靠性肯定会随之变差。

解决这种问题的一种方式，是给处于过载状态的团队临时调入一个SRE。调入该团队后，该SRE应该关注于改善这个团队的行事方式，而不是简单地帮助团队清理积压的工单。通过观察团队的日常工作，提出改善性意见，该SRE可以帮助团队用全新的视角来审视自己的日常工作。这往往是团队本身的成员做不到的。

注：采用这种方式时，只需要调入一名SRE就够了。同时调入两名SRE不一定会产生更好的结果。

当你开始构建自己的第一个SRE团队时，采用本章中的方法可以帮助避免团队走入歧途，退化成那种只专注于工单处理的传统运维团队。

接下来的部分是给即将嵌入团队的SRE的一些指导。

第一阶段：了解服务，了解上下文。在嵌入团队的过程中，你的主要工作是清楚地表达团队目前的流程和工任务习惯对于该服务的可扩展性有利或有弊的原因。提醒该团队，日益增加的工单不应该由更多的SRE来处理，只有在系统复杂度上升的时候才会增加新人。寻找该服务可以继续自动化或进一步简化的空间。随着服务规模的扩大，Ops模式下的团队通过增加更多的管理员来解决运维问题，而SRE则相反，他们通过编写软件系统或消除系统瓶颈的方法来解决这个问题。这样，运维一个服务所需的人数不会与服务的负载同步增加。
- 确定最大的压力来源。在你对服务了解足够深刻、可以讨论设计和部署问题之后，应该花一些时间来根据历史上各种服务中断造成团队压力的程度将其排序。需要留意的的，可能存在一些很小的问题，但由于团队的历史和视角问题，却正在给团队带来很大负担。
- 找到导火索。在你确定了该团队现有的最大问题后，下一步就应该关注那些即将要发生的紧急情况。大部分时候，即将发生的紧急情况是以一个新的、没有被设计成自我管理的子系统的形式出现的。其它的来源还包括：
- - 知识代沟
  - SRE直接参与开发的功能变得越来越重要
  - 对“未来的一件大事”的过度依赖，团队成员有时会忽略某种问题长达几个月时间，因为他们相信“马上上线”的新解决方案能够解决该问题。
  - 开发团队和SRE都视而不见的警报
  - 任何有客户投诉，并且缺乏一个正式的SLI/SLO/SLA的服务
  - 任何一个容量规划都是“增加更多的服务器”的服务
  - 事后总结中的待办事项仅仅只有“回滚导致服务故障的变更”的服务
  - 现有的SRE以“我们什么也不知道，开发者才明白”来应对的关键组件
第二阶段：分享背景知识。在了解团队内部动态和找到痛点之后，你应该通过建立一些最佳实践来为改善状况做准备。例如，建立书写事后总结的机制，辨别琐事的来源，确定每个琐事的最佳解决方案等。
- 书写一个好的事后总结作为示范。事后总结体现了团队的集体推理能力，不健康的团队进行的事后总结往往是无效的。一些团队成员可能把书写事后总结看作是一种惩罚，甚至是无用的。在你嵌入一个团队提供指导时，不要去回顾之前的事后总结，并一一评论，这样做对团队没有帮助，还可能推动团队进入防御模式。你应该亲自负责下一次事后总结的书写。你应该与on-call工程师合作写一个非常好的、对事不对人的事后总结。这个文档可以用来向团队解释他们是如何通过永久性修复根源问题而受益的。永久性地修复根源问题长期来看可以减少事故对团队成员的时间的影响。
- 将紧急事件按类型排序。在我们简化的模型中有两种紧急事件：
- - 不应该存在的紧急事件，这些紧急事件会导致Ops工作或琐事的发生。
  - 其他的紧急事件可能会让on-call成员感到压力巨大，又或者使他愤怒地敲击键盘。这类紧急事件实际上是日常工作的一部分，团队需要通过构建对应的工具来控制压力。
- 你应该将团队遇一以的紧急事件分为琐事的和非琐事的。将这个列表提交给团队并且清晰地解释哪些紧急事件应该被自动化，而其他的紧急事件则是运维服务必须承担的工作。
第三阶段：主导改变。为了确保团队在未来可以自我调节，我们需要帮助他们建立一个良好的SRE心理模型。
- 从基础开始。你的第一个目标应该是为团队制定一个服务等级目标SLO。SLO非常重要，因为它对于事故的后果提供了量化分析的依据，同时它也提供了某个流程改变的重要性依据。
- 获取团队成员的帮助。请克制住自己急切的心情，按下面去做：
- - 找到一个可以由某个团队成员完成的有价值的工作。
  - 清晰地解释这项工作是如何以一个永久的方式解决事后总结中出现的问题的。
  - 自己亲自作为代码更改和文档修订的评审者。
  - 在两到三个问题上重复这个过程。
- 解释你的逻辑推理过程。随着团队逐渐复原，你需要将注意力放到解决那些造成运维过载的日常决策中去。这个过程中会遇到团队成员的反对，你需要对你的决策进行充分的解释。如果你不解释逻辑推理过程，或者解释得不够充分，就可能会造成团队也形成这种懒惰的风气。所以一定要避免。
- 提出引导性问题。一定要是提出引导性问题，而非指责性的问题。以鼓励别人思考基本理念的方式来提出问题。

以下宗旨需要提供给SRE团队：

从技术角度，最好是量化的角度指出团队需要改变的原因。
提供一个详细、具体的“改变”作为例子。
解释SRE经常采用的“常识”背后的逻辑推理过程。
提供可伸缩的方式来解决崭新情况所必需的核心理念。

作为最后一个任务，你需要写一份报告，重申你的观点、例子和逻辑推理过程。同时该报告应向团队提供一些待办事项，来保证他们会实践你所传授的东西。你应该将该报告组织成一份检查报告，解释成功路上的每一个重要的决策。

在大部分的工作已经完成后，即使你的嵌入式工作已经结束，但仍然应该参与设计评审和代码评审。在未来几个月中持续关注这个团队，确保他们正在慢慢提高自己的容量规划能力、紧急事件处理能力和部署发布过程。

四、SRE与其他团队的沟通与协作

沟通：生产会议

生产会议通常每周进行一次，这个频率使得有足够时间积累素材以使得会议有价值，同时又不至于太频繁。在这个会议中，SRE团队向自己——以及邀请的嘉宾——描述服务的目前状态。这个会议目标是：

在会议结束后，每个参会者对服务的状态了解程度达到一致。
通过将在生产中获取的知识应用到服务中来以便改善服务。
- 详细讨论服务的运维表现
- 将服务的性能与设计、配置或者实现结合起来讨论
- 对于如何解决问题提供建议

生产会议要设置一个会议主席，经常是由很多不同的SRE成员轮流担任。

议程

组织生产会议有许多方法，所以说严格规定如何运行这些会议是不恰当的。但提供一个默认的议程以开拓思路是有必要的。以下是一个议程的模板。

日期：2017-06-13

参与者：a,b,c,d

公告

某某大型事故造成错误预算耗尽

之前的待办事项评审

xxxx事项

事故回顾

某某大型事故
- 主要过程与处理措施

紧急警报回顾

vpn线路丢包率监控：本周报警1次，由上海电信至北京移动机房侧的ipsec vpn丢包，而公网线路并无故障
- 用时约50分钟，手动将ipsec vpn改为gre vpn
- 已经安排对在用ipsec vpn，都预先准备一条gre vpn作为备用，发生故障时采取手动应急切换，以缩短处理时间

非紧急警报回顾

没有

监控系统修改/静音

主机AA、主机BB的网卡进、出口流量报警逻辑与阀值进行了调优

计划中的生产变更

集群AA预计在下周三实施XXXX维护
- 需要预先切走流量

资源

已经有至少2个集群的数据库主机，在每周会触发几次cpu负载高的报警了，目前的cpu利用率均值为50%
主机CCC的磁盘空间使用率增加偏快，近一周已经增长了30%

关键服务指标

指标A
指标B

项目更新

新项目DDD下周发布

出席人员

SRE团队成员
主要的产品负责人
有合作关系的产品研发团队
那些忙碌却重要的参会者可以通过事先提供个人反馈和引导的方式参加，或者使用事先填写的议程的方式参加

一些SRE团队会将该会议分段，任何仅针对SRE的问题都在前半部分出现。

使用Google Docs或wiki这样的可以多人协同编辑的功能，可以非常有效地进行会前多人并行议程准备。

SRE的内部协作

一般来说，单人项目最终肯定失败。做成任何高价值的事情都需要很多人共同协作。

SRE的内部项目协作的建议

项目负责人非常重要，他们要为项目提供一个长期愿景，确保所有的工作都与这个愿景有关，设置正确的工作优先级。
标准的“分而治之”的策略很适合用于跨地域项目，将项目拆分成尽可能多的合理大小的部分，努力确保每一个组件都可以被分配给一个小组。
只有当团队的目标是提供某个功能或解决某个问题时，才是最高效的。这样确保了团队中的每个人都知道整个团队对他们的期望，并且知道只有该组件完全集成并使用在主项目中，他们的工作才算完成。
执行软件工程最佳实践，每一个组件都应该有设计文档并应该在团队内部评审。标准化是很重要的。例如编码风格指南。随着时间推移逐步建立一个最佳实践的集合。
当面交流，让项目的领导者亲自与其他成员会面，如果时间和预算都允许，应该组织一个团队会议进行互动。
采用一个适合当前项目状态的项目管理方式。不管多么雄心壮志的项目也要从小规模开始，所以项目管理成本应该相应保持较低的水平。随着项目的发展逐渐改变项目的管理方式。如果增长迅速，那么也有必要开展更全面的项目管理。

五、SRE参与模式的演进历程

Google内部只有很少一部分的服务是在一开始就由SRE负责运维的，这就意味着SRE需要有一个评估服务的流程，该流程确保服务符合SRE的要求，同时与研发团队协商如何改善任何不足之处，以及确定最终交接给SRE运维的流程。

1、最经典的PRR模型（生产就绪程度评审——Production Readiness Review）

PRR评审可以在服务的生命周期的任一阶段开始。该流程根据服务的具体细节来找出在可靠性方面的欠缺之处。通过PRR流程，SRE寻求运用他们所学到的经验来确保服务生产运行中的可靠性。只有通过PRR评审，SRE团队才会同意承担该服务的运维责任。

2、SRE参与模型

SRE承担重要服务的生产运维责任，是为了提高该服务的可靠性。SRE会考量该服务的几个方面：

系统的体系结构和跨服务依赖
指标的选择、度量和监控
紧急事件处理
容量规划
变更管理
性能：可用性、延迟和资源效率

SRE参与运维服务的目标是在这些方面进行改善，这样可以让该服务的生产运维变得更容易。

3、替代性支持

不是所有的Google服务都有SRE的紧密参与，因为：

许多服务不需要高可靠性和高可用性，可以通过其他方式支持该服务。
开发团队的数量总是会超过SRE团队的可支持的数量。

当SRE无法对某项服务提供全方位的支持时，我们会提供其他选项，如文档和咨询工作。

文档，SRE对内部的技术与那些被广泛使用的系统提供了开发指南，记录了生产运维中的最佳实践。开发者可以通过遵循这些建议，实现其中描述的方案来提高他们的服务质量。
咨询工作，SRE的发布协调工程团队LCE的大部分时间都是与开发团队进行咨询工作。

当一个服务已经发展到了一个转折点，这时它们会开始在运维过程中遭遇生大困难，同时这些服务对用户来说又越来越重要。因此有必要进行长期性的SRE参与。

4、PRR:简单PRR模型

当SRE接到来自研发团队的生产运维接管要求时，他们需要评估该服务的重要程度和目前团队的可用性。如果该服务的确值得SRE支持，并且SRE团队和研发团队同意调动人力资源来促成这一支持，那么SRE会与研发团队一起启动PRR评审流程。

PRR评审的目标如下：

验证该服务符合公认的标准的生产部署方式和运维方式，同时该服务负责人已经准备好与SRE一起工作，利用SRE的知识改进服务。
提升服务生产环境的可靠性，并最小化可预见的故障的数量和严重程序。PRR会关注SRE所关注的生产环境的所有方面。

在必要的改进全部实施之后，SRE认为该服务已经“准备好”之后，一个SRE团队会接管所有的生产运维职责。

一共有三个不同但是相关的SRE参与模型，它们是简单PRR模型、早期参与模型、框架和SRE平台模型。

简单PRR模型通常是针对已经推出并且即将由SRE团队接管的服务，主要包含以下几个阶段：

参与。SRE管理层首先需要决定具体由哪个SRE团队接管服务，并选择1~3名SRE成立一个临时性的服务接管小组。该小组负责与研发团队对以下事项进行讨论，并就PRR流程、最终目标以及结果达成一致：
- 为该服务建立一个SLO/SLA 。
- 为可能的、为了提高可靠性的破坏性设计变更制定计划。
- 制定交接计划和培训计划。
分析。这是一个工作量比较大的阶段。SRE评审者将仔细学习该服务的一切知识，开始对其生产方面的缺陷进行分析。SRE的目标是度量该服务自身的成熟程度，以及SRE最关注的运维方面的情况。他们还会审阅服务的设计文档以及具体实现，以确保遵循生产环境的最佳实践。这个评估过程可以评估该服务对紧急事件响应的需求程度，以及是否具有良好的运维操控性。通常，SRE会在这个阶段专门建立和维护一个PRR检查列表，该列表是基于领域专业知识而专门建立的。检查列表中的项目可能包括：
- 对于服务进行的更新是否立刻影响到系统中大比例的部分？是否合理？
- 服务的依赖是否合理？
- 该服务在连接关键的远程服务时，是否需要较高的网络服务质量？
- 该服务是否会将错误日志发送到中央日志记录系统进行分析？该服务是否报告所有的会造成降级回复，或者会造成最终用户请求失败的特殊情况？
- 所有用户可见的请求失败情况都有度量和监控吗？报警策略是否合适？
- 该检查列表可能还会包括该SRE团队所遵循的运维标准和最佳实践，即使一个功能完善的但是没有遵循该SRE团队的“黄金标准”的服务配置，可能需要重构。
- SRE也会查看最近事故与对应的事故总结，以及列出的待办事项。
改进和重构。上一步中的分析工作会形成一系列对于该服务改进的建议，如下：
- 将每个改进建议按照其对服务可靠度的影响而排序，制定一个优先级顺序。
- 与研发团队讨论和协商这些建议，达成一个共识。
- SRE和产品研发团队同时参与，协助对方进行重构，或者实现额外的功能。
培训。生产运维的责任通常是由整个SRE团队共同承担的。为了确保整个团队都有所准备，领导PRR的SRE评审者负责对团队的培训，这也包括整理运维服务所必需的文档。
- 设计概述
- 对系统中各种请求的处理流进行深入探讨
- 生产环境部署模式的描述
- 对系统运维各个方面的手动练习
“接手”服务。该阶段将涉及将各种生产运维职责和所有权逐步转移给SRE，其中包括部分的运维操作、变更管理流程以及访问权限控制等。
持续改进。SRE团队必须在面对服务的持续改进的同时维护服务的可靠性标准。随着平时的生产运维，新变更的评审，紧急事件的处理，特别是书写事后总结，以及对于根源问题的分析，该SRE团队逐步加深对系统的了解。这些运维经验会形成一系列的最佳实践，并记录在“生产指南”和其他文档中。

5、PRR:简单PRR模型的演进——早期参与模型

PRR模型主要适用于那些服务已经发布，已经规模化，SRE的参与是在生命周期的后期才进行的。PRR的一个演进版本——早期参与模型，是指在开发周期的早期就引入SRE来实现显著的额外优势。早期参与模型本质上是将SRE尽早投入到研发过程中，SRE会参与设计和后面的各阶段，最终在“构建”阶段或其后任何一个阶段接管。

早期参与模型的优势和风险

设计阶段。越是在服务生命周期的后期，设计决策的纠正成本越高。在设计阶段与SRE合作可以预防未来很多类型的问题或事故的发生。
构建和实现。构建阶段涉及生产中的很多方面，例如指标选择和度量，运维和紧急事件中的控制功能，资源的使用率和效率等。在这个阶段，SRE可以通过建议使用现存的类库和组件来影响和优化具体实现，或者直接帮助构建某些控制系统。SRE在这个阶段的参与有助与未运维操作更便利，同时允许SRE在发布之前就获得运维经验。
发布。SRE可以帮助实现广泛使用的发布模式和控制系统。发布过程中的平稳有助于保持运维负载很低，同时可以维持在发布之后的发展势头。
发布之后。发布时的系统稳定性一般来说可以减少研发团队的优先级冲突问题。研发团队不需要提高服务的可靠性与增加新功能之间进行抉择。
从服务脱离。有时候一个服务最终不值得SRE全职管理，这很可能是在发布之后决定的，或者SRE可能曾经参与服务但从未正式接管。因为该服务不能达到预测的使用规模，在这种情况下，SRE早期参与的努力与成果成为该新项目发展失败的整风险的一部分。SRE团队将被重新指派，之前所吸取的经验教训可以纳入新的参与过程中。

6、不断发展的服务：框架和SRE平台

经验教训

“接手”每个项目需要2~3个SRE，该过程通常持续两到三个季度。
由于各个服务中软件实践的不同，每个生产功能的实现方式都不同。为了达到PRR标准，部分新功能通常需要重新实现。
虽然通过对常见的服务问题和故障的评审揭示了一定的模式，但并没有办法容易得在其他服务中复制这些修复和改进。如服务过载的处理和数据热点的处理。
SRE软件工程对于服务的贡献往往是本地的，建立能够通用的解决方案有很多困难。

影响SRE的外部因素

外部因素传统上会对于SRE组织和它多方面的资源造成影响。

跟随行业趋势，Google内部也在逐步向微服务转变。于是，需要SRE提供支持的数目和SRE需要负责的服务数量都增加了。因为每项服务都有一个基础固定的运维成本，就算是很简单的服务也需要更多的人手。微服务同时意味着部署时间应该较短，这是以前的PRR模型所不可能满足的。
招聘合格的SRE很困难，代价也很高。我们一直没有足够的SRE来支持全部服务，且在SRE入职后，他们的培训时间相比一般的研发工程师也更长。
最后，SRE这个组织有义务满足数量庞大且不断增长的目前没有SRE支持的开发团队的需求。这个义务促使SRE支持模型的扩展，使其远远超出了原有的概念和模式。

结构化的解决方案：框架

为了有效应对这些情况，很有必要开发一个能符合以下指导思想的模型：

最佳实践代码化，将生产环境中运行良好的最佳实践代码化，这样服务可以通过简单地使用这些代码，自然而然地成为“生产就绪”。
可重复使用的解决方案，常见并易于共享的技术实现，用于改善可扩展性和可靠性的问题。
带有通用控制界面的通用生产操作平台，生产设备的统一接口，统一的运维控制机制，以及统一的监控、日志以及服务配置。
更简易的自动化和更智能的系统，通用的控制接口使自动化和智能化达到一个以前不可能达到的水平。例如，SRE可以用一个统一的视图查看关于一次故障的全部相关信息，不用收集和分析来自不同数据源的原始数据。

基于这些指导思想，在我们支持的每一个环境中（Java,C++, Go），建立了一系列SRE支持的平台和服务框架。利用这些框架构建的服务可以共享那些按SRE支持平台设计的代码，SRE和开发团队共同维护这些框架。这种变革使得产品研发团队可以利用符合SRE标准的框架来设计应用程序，然后再花时间按SRE规范改造程序。

应用程序由一些业务逻辑组成，而这些业务逻辑依赖于各种基础设施组件。SRE所关注的生产问题主要集中在一项服务的基础设施相关的部分。服务框架以一个标准化的方式实现了基础设施部分的代码并且预先解决了常见的各种生产问题。每一个问题都被封装在一个或多个框架模块中，每一个框架都为问题所在的领域或问题相关的基础设施依赖提供了一个完整的解决方案。框架模块解决了前面提到的SRE的多个关注的重点，如：

性能指标的度量和选择
请求日志记录
流量和负载管理的控制系统

SRE通过构建框架模块来实现这些关注重点的标准解决方案。其结果是，因为该框架已经考虑了正确的基础设施的使用，所以研发团队可以更专注于业务逻辑的开发。

一个框架基本上是预先实现的一套使用一系列软件组件的规范。该框架还可以以一种标准的方式对外提供控制各个组件的功能。例如，一个框架可以提供如下功能：

将商业逻辑用一系列完善定义的语义组件进行组织，可以用标准术语来引用。
标准监控维度。
请求调试日志的标准格式。
管理负载抛弃的标准配置格式。
描述一个单一的软件服务器的容量，以及如何判断“过载”的方式，这样可以以一致的方式将度量结果反馈给控制系统。

各种框架在一致性和高效性上提供了很多前期收益。它们将开发者从临时的、定制的黏合和配置各种组件的工作中解脱出来。这些框架推动了跨服务的、可重用的生产解决方案，这意味着该框架的用户最终会以相同的通用方式使用服务，配置差异也很小。

Google内部支持数种语言开发的应用，这些框架在所有语言中都可用，为同样的功能暴露同样的API、行为、配置和控制组件。这样研发团队可以选择他们需求和经验的语言平台，而SRE仍然可以期待这些应用在生产中的行为相近，可以利用标准的工具进行管理。

新服务和管理优势

这种基于服务框架和通用生产平台、控制界面的结构化方法提供了一系列新的益处。

显著降低运维开销

一个基于框架和强标准而构建的生产平台能够明显降低运维开销，原因是：

它支持代码结构、依赖关系、测试、编码样式指南等的强合规性测试。这个功能还提高了用户数据的隐私度、测试和安全性的合规性。
它个有内置的服务部署、监控和自动化服务。
它使得管理大量的服务更容易，特虽是数目暴增的微服务。
部署更快：一个想法在数天之内在SRE级别支持的生产环境中全面部署。

设计中自带的通知性支持

Google内部服务数据的不断增长，意味着大部分服务既不值得SRE参与也不会被SRE维护。但是不管怎么样，没有完整SRE支持的服务可以使用SRE开发和维护的生产功能。这种做法有效地突破了SRE的编制障碍，让所有团队都能使用SRE所支持的生产标准和工具，以提高Google所有团队整体的服务质量。而且，所有用框架实现的服务都会自动从对框架模块的逐步改进中受益。

更快、更低的参与成本

这种框架模型可以使得PRR执行更快，因为我们可以依靠：

作为框架实现的一部分内置服务功能。
“接手”服务更快（通常由一个SRE在一个季度内完成）。
SRE在管理采用框架构建的服务时的认知负担降低了。

这些特性减少了SRE团队在服务交接时的评估和认证工作，同时仍然能保持对服务产品质量的高标准要求。

一种基于共同责任的新型参与模型

最初的SRE参与模型体现了两种选项：完整的SRE支持，或者基本上没有SRE支持。

一个有着公共服务结构、惯例，以及软件基础设施的生产平台，使SRE团队可以为“平台”基础设施提供支持，而让研发团队为服务的功能性问题提供on-call支持。在这种模式下，SRE承担大部分基础设施服务的软件开发和维护的责任，特别是控制系统，如负载抛弃、过载保护、自动化、流量管理、日志和监控等。

简单PRR模型

PRR早期参与模型

生产服务框架，基于生产最佳实践的代码模式在框架中进行了标准化，封装在框架内，使得使用框架成为一个被推荐的、一致的、相对简单的构建服务的方法。

以上三种参与模型仍然在Google内不断实践。然而，框架正成为Google内部构建生产完备的服务的主要力量。这也是SRE深入扩展自己的贡献的主要领域。这同时降低了管理成本，提高了整个Google的基础服务水平。

六、其他行业的实践经验

Google内有很多来自其他行业的技术专家或资深SRE，下文从4个理念着手对SRE的核心指导思想和其它行业的最佳实践进行了对比：

灾难预案与演习
书写事后总结的文化
自动化与降低日常运维负载
结构化的、理智的决策

1、灾难预案与演习

SRE的一条口号是“愿望不是策略”。SRE的文化是永远保持警惕，每年安排灾难恢复演习，SRE在演习时会在生产环境中创造真正的问题，以便能够：

确保系统按我们预想的方式应对故障
寻找系统中未预料到的弱点
寻找其他提高系统鲁棒性的方式来避免事故发生

而在其他行业中，是从以下几个方面测试团队的灾难准备情况，以及保障团队应对灾难的能力的策略：

从组织架构层面坚持不懈地对安全进行关注
关注任何细节，如果海军的大型潜艇维护
冗余容量，如通信行业的移动通信平台
模拟以及进行线上灾难演习，如航空业
培训与考核，如救生员
超乎寻常地关注对细节要求的收集与系统的设计，如军工行业
纵深防御，如核工业

2、事后总结的文化

3、将重复性工作自动化，消除运维负载

Google SRE本质上还是软件工程师，他们对重复性的、被动性的工作十分反感。

4、结构化和更改的决策

SRE团队应该越精简越好，他们所操作的东西应该更抽象而非更具体。SRE团队依赖各种后备系统和精心设计的API来运维。同时，SRE也应该对系统的运作原理、运维方式、故障模式以及应急处理方式非常了解——这些都是在日常工作中学到的。

SRE Google 运维解密--管理相关推荐

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

SRE Google 运维解密--管理

SRE Google 运维解密--管理相关推荐

最新文章

热门文章