专栏首页博文视点BroadviewSRE之道:创造软件系统来维护系统运行

SRE之道:创造软件系统来维护系统运行

小编说:本文作者Ben Treynor Sloss,Google 运维团队的高级副总裁,SRE 名称的发明者,在这里提供了他对SRE 的定义。 本文选自《SRE:Google运维解密》

大家都知道, 计算机软件系统离开人通常是无法自主运行的。那么,究竟应该如何去运维一个日趋复杂的大型分布式计算系统呢?雇佣系统管理员(sysadmin)运维复杂的计算机系统,是行业内一直以来的普遍做法。而Google 的做法是——SRE。

SRE 团队通过雇佣软件工程师,创造软件系统来维护系统运行以替代传统模型中的人工操作。

SRE 究竟是如何在Google 起源的呢? 其实我的答案非常简单:SRE 就是让软件工程师来设计一个新型运维团队的结果。当我在2003 年加入Google 的时候,我的任务就是领导一个由7 名软件工程师组成的“生产环境维护组”。当时,我的整个职业生涯都专注于软件工程,所以很自然,我按照自己最习惯的工作方式和管理方式来组建了这个团队。

时过境迁,当年的7 人团队已经成长为公司内部1000 余人的SRE 团队,但是SRE 团队的指导理念和工作方式还是基本保持了我最初的想法。

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

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

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

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

(a) 对重复性、手工性的操作有天然的排斥感。

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

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

SRE 模型成功的关键在于对工程的关注。如果没有持续的、工程化的解决方案,运维的压力就会不断增加,团队也就需要更多的人来完成工作。传统的Ops 团队的大小基本与所服务的产品负载呈线性同步增长。如果一个产品非常成功,用户流量越来越大,就需要更多的团队成员来重复进行同样的事情。

为了避免这一点,负责运维这个服务的团队必须有足够的时间编程,否则他们就会被运维工作所淹没。因此,Google 为整个SRE 团队所做的所有传统运维工作设立了一个50% 的上限值。传统运维工作包括:工单处理、手工操作等。设立这样一个上限值确保了SRE 团队有足够的时间改进所维护的服务,将其变得更稳定和更易于维护。这个上限值并不是目标值。随着时间推移,SRE 团队应该倾向于将基本的运维工作全部消除,全力投入在研发任务上。因为整个系统应该可以自主运行,可以自动修复问题。我们的终极目标是推动整个系统趋向于无人化运行,而不仅仅是自动化某些人工流程。当然,在实际运行中,服务规模的不断扩张和新功能的上线已经让SRE 够忙了!

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

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

虽然SRE 模型带来了一些优势,但也存在一些问题。Google 面对的一个持久性的难题就是如何招聘合适的SRE。首先SRE 要和产品研发部门招聘传统的软件开发工程师竞争。

其次,由于SRE 要求同时具备多项技能,市场上具有相关从业背景和经验的人就更少了。由于SRE 模型也比较新,行业内关于如何建立和维护SRE 团队的相关信息并不多。最后,SRE 团队建立之后,由于SRE 模型中为了提高可靠性需要采取一些与常规做法违背的做法,所以需要强有力的管理层支持才能推行下去。例如:由于一个季度内的错误预算耗尽而停止发布新功能的决定,可能需要管理层的支持才能让产品研发部门重视起来。

本文分享自微信公众号 - 博文视点Broadview(bvbooks),作者:博文视点

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2017-02-21

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • SRE生存指南:系统中断响应与正常运行时间最大化

    近20年是互联网技术飞速发展的20年。互联网业务的快速发展不仅直接带来了流量、安全等方面的不确定性,同时也促进了技术架构的快速演进——技术架构变得越来越复杂,而...

    博文视点Broadview
  • 书单丨5本书感受运维技术的魅力

    站点可靠性工程(SRE)专注于如何确保系统稳定、可靠地运行。本书基于一个金字塔层次结构模型,深入浅出地介绍了关于SRE的方方面面,涉及监控、事故响应与回顾、测试...

    博文视点Broadview
  • 业界大咖谈敏捷(下篇)

    《洞悉敏捷》一书客观全面地介绍了全球正在使用的各种敏捷方法的价值、原则、架构、过程和适用场景。除敏捷知识讲解外,书中还记录了13位享有盛名并且受人尊敬的敏捷大咖...

    博文视点Broadview
  • 我所理解的SRE、PE和应用运维(上)

    SRE这个概念我个人印象中应该14年下半年左右听到的,当时只知道是Google对运维岗位定义,巨牛逼的一个岗位,在网上查到SRE是叫网站稳定工程师,只要是保障稳...

    赵成
  • 《Google SRE 运维解密》读书笔记

    Google SRE算是行业的标杆,运维中的特种兵。简单来说,就是SRE很贵,很能干,而且主要是巧干。换句话说,不懂开发的运维,不是真正的SRE. 翻译版的这本...

    jeanron100
  • Python学习笔记 - 02: 用Python Client连接ElasticSearch操作数据

    Python Elasticsearch Client 是 ES 官方推荐的 python 客户端,这里以它为工具操作 elasticsearch

    双面人
  • 零基础入门 23: UGUI ScrollView

    今天要分享的内容,是近期内关于UGUI的最后一篇,UGUI里的滚动视图ScrollView,后期的内容会根据项目实用的功能组件进行分享。

    韩东吉
  • Spring学习总结

    关于Spring也大体了解了一下,其原理比较简单,不过思想却是比较复杂,什么IOC,什么DI,什么AOP……

    the5fire
  • 微博遭鹿晗恋情暴击瘫痪,如何把微博服务器搞炸的?

    人生处处是惊喜。国庆假期最后一天,当红流量小生鹿晗于正午 12 点,在微博公布恋情。 ? 微博一经发布后,瞬间刷爆朋友圈、各大网站头条,还导致了微博一时间瘫痪。...

    Java高级架构
  • SQL 高级查询 ——(层次化查询,递归)

    层次化结构可以理解为树状数据结构,由节点构成。比如常见的组织结构由一个总经理,多个副总经理,多个部门部长组成。再比如在生产制造中一件产品会有多个子零件组成。举个...

    Lenis

扫码关注云+社区

领取腾讯云代金券