RandyShoup曾在eBay和谷歌帮助领导工程团队，是我见过的少数几个能够描述构建高效DevOps和最大可靠性系统所需的领导素质的人之一。他的两个演讲（2013年的Flowcon演讲，以及他在2000年代初期改变eBay架构的惊人工作）是我的最爱。专访RandyShoup：揭开Goog??leDevOps的改进原则本文由GeneKim根据对RandyShoup的专访整理而成，深入探讨和讲解如何改进GoogleDevOps，让我们一起了解更多。斯皮尔博士的模型具有以下四种能力：能力一：出现问题立即发现；能力二：一旦发现问题，立即集群化解决（Swarming），并作为新知识记录保存；能力三：在整个公司传播新知识；能力四：发展主导。它也是RandyShoup访谈的基础，它还阐明了一些在Google和eBay尚未被广泛讨论的实际例子。（我从RandyShoup那里学到了很多，很难用语言表达。如果你想了解更多并将其用于贵公司的实践中，你可以通过Randy的LinkedIn个人资料联系他，他目前担任咨询职务).能力1：在问题发生时立即发现问题Spear博士写道：高速公司制定详细的规则和设计以根据现有知识库捕获问题，并使用内置测试来发现问题。无论是单独工作还是团队工作，有无设备，高速公司都不愿意接受模棱两可的情况。他们事先指定：(a)预期产出；(b)谁负责什么以及按什么顺序负责；(c)产品、服务和信息将如何从上一步的负责人传递给下一步的负责人。手；(d)每部分工作的完成方式。GK（作者）：在DevOps领域，Google应该是榜样之一，尤其是在自动化测试领域。谷歌SCM团队的EranMesseri在2013年GOTOconAarhus会议的一个片段中说：“当成千上万的工程师共享同一个持续构建时会发生什么？”（讲义可在此处查看）他列出了一些值得注意的统计数据（截至2013年），以及他们如何在其能力范围内创建最快、最及时、成本最低的程序员反馈机制：15,000名程序员（包括开发人员和运维人员）4,000个同时进行的项目检查同一存储库中的所有源代码（数十亿个文件！）15,000名程序员提交了5,500次代码自动测试每天运行7500万次0.5%的工程师从事开发工具工作这是查看AshishKumar的2010QConSFPPT，您可以在其中可以看到更多关于谷歌开发团队取得的惊人数字。Q：谷歌可能是自动化测试的典范，大家想多了解一下你在那里的工作经历。答：确实，Google进行了大量的自动化测试——比我研究过的任何其他模型都多。“一切”都需要测试——不仅仅是getter/setter功能，还有所有可能出错的地方。设计测试通常是最具挑战性的。没有人花时间编写测试来检查他们认为可行的功能，但通常是测试可能出错的困难地方。实际上，这意味着团队需要进行可靠性测试。通常你想孤立地测试某个组件，而对其他部分使用模拟组件，这样你就可以在半真实的世界中测试你自己的组件，但更重要的是，你可以在模拟测试中注入失败。这样，通过不断的测试，就可以找出组件哪里不工作了。在每天的实际测试中，可能有百万分之一、百万分之一的机会这些组件无法工作（例如服务器的两个副本宕机；准备和提交阶段之间出现问题）或整个服务器在半夜宕机）。所有这些都需要每天进行大量工作来构建恢复性测试并始终运行它们。Q：谷歌现有的自动测试规则是怎么来的？A：我不知道谷歌的相关规则是如何演变而来的。我去的时候他们已经存在了。令人惊讶的是，这个大规模分布式系统中的所有组件都在不断地以这些复杂的方式进行测试。作为一个新手，我不想写没有经过足够测试的蹩脚东西。作为领导者，我特别想给团队树立一个坏榜样。下面是一个具体案例，展示了这样一个团队的一些优势。正如您可能都在著名论文（Google文件系统、BigTable、Megastore等）中读到的那样，常见的Google基础设施服务由各个团队运行——通常是一个小得惊人的团队。他们不仅编写代码，还运行操作。当这些组件成熟后，不仅要为用户提供相应的服务，还要为用户提供客户端文件库，使服务更加方便。使用现有的客户端库，他们可以模拟客户端测试的后台服务并注入各种故障场景。例如：你可以使用BigTable生产库，再加上一个模拟器，它会表现得和实际生产平台一样。你想在写入和确认阶段注入故障吗？去做就对了！我怀疑这些原则和实践来自于“苦练”，是从那些不断问“如何避免停机”的紧急情况中磨练出来的。随着时间的推移，最终的规则得到完善，形成了一个坚实的结构。能力二：一发现问题，就集群解决，记录下来，成为新知识。Spear博士写道：“Velocity公司擅长首先发现和发现系统中的问题。他们同样擅长：(1)在问题蔓延之前发现问题(2)找到并解决问题的原因，以便“问题不再发生。在这样做的过程中，他们建立了更深层次的知识，了解如何管理解决实际工作问题的系统，将不可避免的疏忽转化为知识。”GK：在我的研究中，最令人惊讶的集群问题解决的两个例子：A：丰田的Andonpullcord，负责在偏离已知模式时停止工作。据记载，典型的Toyota工厂需要拉下Andon电缆平均每天3,500次。Alcoa的首席执行官，尊敬的保罗奥尼尔，有一个减少工作场所事故的政策：必须在任何工作场所事故发生后24小时内通知他。谁需要负责报告？业务部门总经理.问：谷歌的远程文化是否类似于那些支持蜂群行为的文化，例如丰田Andon拉线和美国铝业公司CEO要求在工作场所发生事故时通知他？答：没错，两者都引起了我的共鸣。Ebay和谷歌都有责备文化-freePostMortems.（GK：JohnAllspaw也称其为无可指责的事后分析。)事后豁免是一个非常重要的规则，每当客户受到停电影响时，我们都会召开事后分析会议。正如JohnAllspaw和其他人广泛描述的那样，事后分析的目标不是让人们承担责任，而是为整个公司的学习和广泛交流创造机会。我发现，如果在公司文化中没有任何后果，事后分析可能会产生令人惊讶的动态：工程师们将自己进行比较，看看谁做得更大。例如：“嘿，我们发现了一个我们以前从未测试过的备份恢复程序”，或者“然后我们发现我们没有主动复制”。或许对于很多工程师来说，这样的场景再熟悉不过了：“我希望我没有关机，但现在我们终于有机会修好我们抱怨了几个月的坏系统了！”这将产生大量的企业学习，并且以前可以不断地发现和解决问题博士。我认为它之所以有效，是因为我们本质上都是工程师，都喜欢构建和改进系统，而暴露问题的环境会带来令人兴奋和令人满意的工作环境。问：尸检结果如何？不能只是记录下来然后扔进垃圾桶，对吧？问：您可能会觉得难以置信，但我认为最重要的部分是组织事后分析本身。我们知道DevOps最重要的部分是文化，能够组织会议，即使没有输出，也能改进系统。答：这将成为一种套路——成为我们日常生活的一部分，证明我们的价值以及我们如何优先考虑工作。当然，事后，它几乎总是一个很大的列表，列出哪些可行，哪些出错，然后你有一个待办事项列表需要插入到工作队列中（例如：backlog——所需功能列表；增强-改进的文档等）当您发现需要进行新的改进时，您最终会在某处进行一些更改。有时它是文档、流程、代码、环境或其他任何东西。但即使没有这些，仅仅记录验尸文件也会有很大的价值。你可以想象，在谷歌中，一切都可以被搜索到，每个谷歌人都可以看到每一份事后分析的文件。以后再发生类似事故时，首先要看的是事后文件。有趣的是，事后分析文档也有一定的用途。谷歌有一个悠久的传统，要求开发者自己管理所有新服务至少六个月。当服务团队需要“毕业”（即需要专门的SRE团队，或者运维工程师来维护）的时候，基本都是和SRE协商。他们要求SRE接管应用程序提交的责任。（Gene：点击查看视频，TomLimoncelli称之为“切换到启动前状态”过程，SRE审查文档、部署机制、监控概述等。视频很棒！）SRE倾向于从审查事后分析开始文档是一大步，它决定了他们是否可以“毕业”一个应用程序。问：您在Google看到过类似于PaulO'Neill和他的团队在Alcoa所做的请求吗？是否有不断降低通知/升级阈值的示例？A:GK:Spear博士描述了PaulO'Neill如何带领美国铝业的团队减少冶炼车间的伤害（令人惊叹，充满热量、压力和腐蚀性化学品），将事故率从2%降低了每年减少到0.07%，使该公司成为业内最安全的公司。令人惊讶的是，在车间事故率下降到一定水平后，奥尼尔让员工通知他可能出现的错误。确实有。当然，工作场所的事故等同于影响我们用户的停机事件。相信我，当发生影响客户的重大中断时，他们会收到通知。一旦发生事故，会发生两件事：你需要调动所有你需要的人来恢复服务，他们需要继续工作，问题直接解决（当然，这是标准程序）。我们还每周与管理层举行一次事件会议（在我的AppEngine团队中，有工程主管——我是两者之一；我们的老板，我们的团队负责人，还有支持团队和产品经理）。我们回顾我们在事后分析中学到的东西，检查接下来需要采取的行动，并验证问题是否得到了妥善解决。决定我们是否需要在必要时进行面向客户的事后分析或博客。有时我们无话可说。但是一旦情况得到控制，团队总是希望同行评审的问题少一些，改进的地方多一些。例如，“不影响客户”的问题将被称为“影响团队”的问题。大多数人都经历过“有惊无险”（nearmisses），并安排了六项保护措施，都是为了防止用户受到故障影响而设置的。结果，都失败了，只剩下一个。在我的团队(GoogleAppEngine)中，我们可能每年都会发生一次众所周知的会影响用户的中断，但当然在每种此类情况的背后都有几次“险些失手”。这就是我们拥有KripaKrishnan在这里讨论的灾难恢复的原因。虽然谷歌做得很好并且我们学到了很多东西（这就是为什么我们有三个生产备份），但亚马逊在这方面做得更好，他们的工作比其他人领先五年。（JasonMcHugh是AmazonS3的架构师，现在去了Facebook，他在QCon2009做了这个演讲，主题是Amazon的故障管理。）问：在Alcoa，工作场所事故需要在24小时内报告给CEO。Google是否有类似的升级时间表（即将问题升级到领导层）？A：在GoogleAppEngine，我们有一个非常小的团队（全球100名工程师），只有两个级别：做事的工程师和经理。当发生影响客户的事件时，我们过去常常在半夜叫醒每个人。对于每一起此类事故，十分之一的事故会升级为公司领导层。问：您如何描述Swarming是如何发生的？A：像丰田工厂，不是每个人都能保证在出现问题的时候每个人都到位去解决问题。但从文化上讲，我们确实优先考虑那些优先级为0的问题的可靠性和质量。在很多方面都是如此，其中一些比停机时间更不明显，更微妙。当您检查破坏测试的代码时，在修复之前没有其他工作要做，也不需要修复破坏更多测试的问题。同样，如果有人有类似的问题并需要帮助，你会被期望放弃一切来帮助。为什么？这就是我们确定优先级的方式——就像“黄金法则”。我们想帮助每个人前进，我们帮助每个人。当然，当您需要帮助时，他们也会对您做同样的事情。从系统的角度来看，我将其视为过山车上的棘轮或中间齿轮——防止我们滑落。这不是流程中的官方规则，但每个人都知道，如果有明显不寻常的事情影响到用户，我们会发出警报，发送一些电子邮件等。信息通常是“大家好，我需要你的帮助”然后我们去帮忙。我认为它总是有效的原因是即使没有列出正式的声明或规则，但每个人都知道我们的工作不仅仅是“编写代码”，而是“运行服务”。甚至可以在几秒钟内修复全局依赖项（例如负载平衡器、全局基础设施错误配置），并在5-10分钟内解决事件。能力3：在整个公司传播新知识。Spear博士写道：高速公司通过在整个公司（而不仅仅是发现者）中传播知识来提高新知识获取的速度。他们不仅分享了问题的结论，也分享了发现问题的过程——学到了什么，如何学到的。在较大的系统中，他们的竞争对手在发现问题后将问题和解决方案留在原地，而在高速发展的公司中，领导者会在整个公司范围内解决问题和发现。传播。也就是说，人一开始工作，就吸收公司里其他人的经验。我们将看到乘数效应的几个例子。Q：出现问题时如何传播知识？本地发现如何转化为全球进步？答：其中一部分，虽然不是***部分，是事后分析会议的文件。有迹象表明：谷歌和其他公司一样容易发生事故。每当谷歌发生引人注目的故障时，你可以肯定几乎公司里的每个人都会阅读事后分析。也许防止未来失败的最好机制是谷歌所有的单一代码库。但更重要的是，由于可以搜索整个代码库，因此很容易使用其他人的经验。不管文档多么正式和一致，更好的方法是看人们在实践中做了什么——“去看代码”。然而，也有消极的一面。一般来说，第一个使用服务的个人可能会使用一个随机配置，然后在公司内疯狂传播。突然间，“37”这样的任意设置到处蔓延。只要你让知识容易传播，容易获得，它就会四处传播，很可能会出现一些黑客。问：除了单一源代码存储库和无可指责的事后分析，是否还有其他机制可以将本地学习转化为全球改进？知识还能如何传播？答：在Google源代码存储库中最好的事情之一就是您可以找到所有内容。所有问题的最佳答案是“看代码”。其次，有优秀的文档，只需搜索即可找到。也有优秀的内部团体。就像任何外部服务一样，写“foo”将列出一个名为“foo-user”的邮件列表。你向名单上的人提问。联系开发者当然好，但在大多数情况下，给出答案的将是用户。顺便说一句，就像这个行业中大量成功的开源项目一样。能力四：以发展为先导。斯皮尔博士写道：高速公司的经理们认识到，例行公事的一部分是推出产品和服务，并不断改进产品和服务的推出流程。他们教人们如何不断改进他们的工作，并为他们提供这样做的时间和资源。这样，公司可以在可靠性和高适应性方面提高自己。这是他们与失败的竞争对手最根本的区别。高速公司的管理者不负责通过一系列指标来指挥、控制、斥责、威胁或评估他人，而是负责确保公司在以下方面有所改进：自我诊断和自我改进、问题-寻找技能，解决问题，通过在全公司范围内传播解决方案来提高效率。GK：我也很喜欢DavidMarquet的名言（《Turn This Ship Around》的作者）：“真正领导者的标志是他/她手下有多少****。”潜艇艇长拿出了更多的枪支。他的工作要点：一些黑客解决了问题，但一旦他们离开，问题又会出现，因为没有他们，他们无法保持系统正常运行。问：谷歌的领导层是如何发展起来的？答：Google几乎采用了任何一家经营良好的公司中可以找到的所有方法。我们有两条职业道路：工程师和经理。头衔中带有“经理”一词的任何人都主要负责“让事情成为可能”并鼓励他人领导。我认为我的角色是创建每个人都很重要的小团队。每个团队都是一首交响乐，与工厂完全相反——每个人都可以独奏，但更重要的是，他们都可以相互合作。我们都有过团队成员互相吼叫或不听对方讲话的糟糕经历。在谷歌，我认为最大的影响是我们构建重要工程项目的文化愿景。重要的文化规范之一，“每个人都编写出色的测试；我们不想成为一个编写蹩脚测试的团队。”同样，拥有这种“我们只雇用参与者”的文化——这对我来说非常重要。在谷歌，其中一些东西在评估和改进过程中被编纂——听起来很糟糕，因为这意味着，我们只是做了我们需要做的工作来改进。但另一方面，评估过程受到高度赞扬，几乎被普遍认为是实质性的——人们获得知识是因为他们做出了相应的贡献并且擅长他们所做的事情。我从没听说过有人因为“抱右大腿，亲右屁股”而升职的。经理和行政职位的主要标准是领导力——即，这个人是否产生了重大影响，远远超出了与你共事的团队，并且是一个“只做自己的事”的人。GoogleAppEngine服务于7年前推出，集群管理组中有一群了不起的工程师认为，“嘿，我们拥有这些用于创建可扩展系统的技术。是否可以编译一个以便其他人可以使用它？“AppEngineFoundingEngineer”的头衔是给内部员工非常尊重的人，比如Facebook的创始人。问：新经理是如何做事的？如果政府必须培养其他领导者，新任或一线经理如何理解减少工作岗位的风险？A：在谷歌，你只会得到“你已经在做”的工作，这与大多数其他公司不同，那里的一切都是关于“你希望你能做的工作”。换句话说，如果你想成为高级工程师，那就去做高级工程师的工作。在谷歌，像许多大公司一样，有很多培训资源。但在大多数情况下，关于工作方式的文化规范影响如此之大，以至于确保文化规范得以延续可能是压倒一切的趋势。就像一个强化文化规范和技术实践的自我选择过程。当然，这也与公司高层的作风有关。谷歌是一家由两位极客工程师创立的公司，其文化因高层风格而得到强化。如果你在一家指挥控制型公司，而公司的领导讨厌别人，那么这种坏消息也会在整个公司传播和强化。
