Google的解决方法-SRE运维技术

GoogleAdsense

Google的解决方法-SRE

SRE这种模型是谷歌尝试者，从根本上避免产生这种矛盾的结果，SRE团队通过雇佣软件工程师创造软件系统来维护系统运行，以替代传统模型中的人工操作，


SRE究竟是如何在谷歌起源的呢？其实答案非常简单，SRE就是让软件工程师来设计一个新型运维团队的结果。在2003年加入谷歌的时候，任务就是领导一个由多名软件工程师组成的，生产环境维护组，当时整个的职业生涯都专注于软件工程，所以很自然按照自己最习惯的工作方式和管理方式来组建了这个团队。时过境迁，当年的几个团队已经成长为公司内部1000多人的SRE团队，但还是SRE团队的指导理念和工作方式，还是基本保持了当初最初的想法。


SRE方法论中的主要模块就是SRE团队的构成，每个SRE团队里最基本上有两类工程师。


第1类团队中50%~60%是标准的软件，工程师具体来讲就是那些能够正常通过谷歌软件工程师招聘的流程的人，第2类，其他40%~50%则是一些基本满足。谷歌软件工程师标准具备85%~99%所要求的技能，但是同时具有一定程度的其他技能的工程师目前来看Unix系统内部细节和1~3层网络知识是谷歌最看重的两类额外的技术能力。


除此之外，所有的SRE团队成员都必须非常愿意，也非常相信用软件工程方法可以解决复杂的我认为问题，谷歌一直密切关注这两类候选人，在招聘通过之后在sre团队中的表现，但是到目前为止还没有发现他们在工作上和成绩上的显著差异，事实上由于两类工程师技术背景互补，而SRE团队经常能够寻找到全新的高效的解决问题的方法。


按照这个标准来招聘和管理SRE团队，我们很快发现SRE团队成员具有如下特点：


1，对重复性手工性的操作，有天然的排排斥感。


2, 有足够的技术能力，快速开发出软件系统，以代替手工操作。


同时SRE团队和产品研发部门在学术和工作背景上非常相似，因此从本质上来说，SRE就是用软件工程的思维和方法论完成，以前有系统管理员团队手工完成的任务，这些SRE倾向于通过设计构建自动化工具来代取人工操作。


SRE模型成功的关键在对于工程的关注，如果没有持续的工程化的解决方案，运维的压力就会不断增加，团队也就需要更多的人来完成工作，传统的ops团队的大小基本与所服务的产品负债呈线性同步增长，如果一个产品非常成功，用户流量越来越大，就需要更多的团队成员来重复进行同样的事情，为了避免这一点负责运维这个服务的团队，必须有足够的时间编程，否则他们就会被认为工作所淹没，因此谷歌为整个SRE团队所做的所有传统运维工作，设立了一个50%的上限值传统运维工作，包括工单处理，手工操作等，设立这样一个上限值，确保了sre团队有足够的时间改进所维护的服务将其变得更稳定和更易于维护，这个上限值并不是目标值，随着时间推移sr E团队应该倾向于将基本的韵味工作全部消除全力投入到研发任务上因为整个系统应该可以自主运行自动修复问题将基本的运维工作全部消除，全力投入到研发任务上，因为整个系统应该可以自主运行，可以自动修复问题，我们的终极目标是推动整个系统趋向于无人化运行，而不仅仅是自动化某些人工流程当然在实际运行中服务规模的不断扩张和新功能的上限，已经让SRE够忙的。


比如你要写一个GoogleAdsense自动判断页面上有效或无效IP浏览的开发工作，公司会怎样安排？


谷歌的经验法则是，SRE团队必须将50%的精力花在真实的开发工作上，那么我们是如何确保每个团队都是这样做的呢？首先我们必须不断的度量，每个团队的工作时间分配，依靠这个数据，SRE管理层会对。在开发工作上，投入时间不够的团队进行调整，通常管理层会要求该团队将一些常见的运维工作交给产品研发部门操作，或者从产品研发部门抽调人力参与团队轮值值班工作，此外还可以停止该sre团队的一切新增运维工作，只有管理层主动维护每个，而是阿毅团队的工作平衡，我们才能保证他们有足够的时间和精力去进行真正的创造性地自主的研发工作，同时这也保障了SRE团队有足够的运维经验，从而让他们设计出切实解决问题的系统。


我没发现谷歌SRE模型在运维大规模复杂系统时有很多优势，由于SRE在调整谷歌系统的过程中，常常直接参与开发修改代码，SRE文化在公司内部基本代表了一种快速创新，拥抱变化的文化实践证明，SRE团队运行维护改进一个复杂系统所需要的成员数量与系统部署规模成非线性增长而运维同时样的系统，用传统的系统管理员模型维护者需要更多数量的原因，最后不仅消除了传统模式中研院为团队的冲突焦点反而促进了整个产品部门水平。的整体提高，因为SRE团队和研发团队之间的成员可以自由流动，整个产品部门的人员都有机会学习和参与大规模运维部署活动，从中获得平时难以获得的宝贵知识，普通的开发人员有多少机会能将自己的程序同时跑在100万个CPU的分布式系统上呢？


虽然而SRE模型带来了一些优势，但也存在一些问题，谷歌面对的一个持久性的难题是如何招聘合适的SRE，首先，SRE要和产品研发部门招聘传统的软件开发工程师，竞争其次，由于SRE要求同时具备多项技能，市场，上具有相关从业背景和经验的人很少很少，由于SRE模型比较新行业内，关于如何建立和维护团队的相关信息不多，最后sre团队建立之后，由于SRE模型中，为了提高可靠性，需要采取一些与常规的做法所以需要强有力的管理层支持才能推行下去例如，由于一个季度内的错误预算耗尽，而停止发布新功能了，决定可能需要管理层的支持，才能让产品研发部门从重视起来。

CPA流量收购

对重复性手工性的操作，有天然的排排斥感