下载APP
关闭
讲堂
部落
算法训练营
架构师训练营
企业服务
前端训练营
客户端下载
兑换中心
渠道合作
推荐作者
09｜案例：互联网典型的SRE组织架构是怎样的？
2020-04-06 赵成
SRE实战手册
进入课程
讲述：赵成
时长12:39大小11.59M
你好，我是赵成，欢迎回来。
前面三讲，我们从故障这个关键事件入手，讲解了“优先恢复业务是最高优先级”这个原则，基于这个原则，在故障发生后，我们要做好快速响应和应急，并从故障中学习和改进。在这个学习过程中，你应该也能体会到，高效的故障应对和管理工作，其实是需要整个技术团队共同参与和投入的。这就引出了大家落地 SRE 都会遇到的一个难点：组织架构调整。
那落地 SRE 必须调整组织架构吗？典型的 SRE 组织架构是怎样的？接下来，我会用两讲内容和你探讨这些问题，分享我在蘑菇街实践的一些经验。
落地 SRE 必须调整组织架构吗？
好，那我们就开始吧，先给你看一张技术架构图。
这是蘑菇街基于微服务和分布式技术的 High-Level 的架构图，也是非常典型的互联网技术架构图，自下而上共四层，分别是基础设施层、业务 & 技术中台层、业务前台层以及接入层，在右侧还有一个技术保障体系。如果你平时经常看一些架构方面的图书和文章，或者听过一些技术大会演讲的话，对这样的图应该不陌生。
你也许会问，咦，我们不是讲组织架构吗？咋一上来就说到技术架构上了？别急，我这么讲是有原因的，在讲 SRE 的组织架构之前，我们需要先明确两点内容。
第一，组织架构要与技术架构相匹配。
技术架构实现组织目标，组织架构服务并促成技术架构的实现，所以，我们不会单纯去讲组织架构，一定会结合着技术架构的现状和演进过程来分析。
第二，SRE 是微服务和分布式架构的产物。
SRE 这个岗位，或者说这个通过最佳实践提炼出来的方法论，就是在 Google 这样一个全球最大的应用分布式技术的公司产生出来的。
正是因为分布式技术的复杂性，特别是在运维层面的超高复杂性，才产生了对传统运维模式和理念的冲击和变革。
如果我们去梳理一下整个软件架构发展的历程，就可以得到下面这张图。我们会发现不仅仅是 SRE 和 DevOps，就连容器相关的技术，持续交付相关的方法和理念，也是在微服务架构不断流行的趋势下所产生的，它们的产生就是为了解决在这种架构下运维复杂度过高的问题。
这样一套架构方法体系，也构成了现在非常流行和火热的概念：云原生架构。
所以，不得不承认，这里的现实情况就是，基本所有的 SRE 经验都是基于微服务和分布式架构的，也都是在这样一个基础下产生的。大到 BAT、头条和美团等，中等规模如蘑菇街，甚至是在传统行业中落地比较突出的，如部分运营商和银行。
那么，想要引入 SRE 体系，并做对应的组织架构调整，首先要看我们的技术架构是不是在朝着服务化和分布式的方向演进。如果架构还没这么复杂，其实也没有必要引入 SRE 这么复杂的运维体系，这本身就不匹配；再就是如果没有对应的架构支持，SRE 技术层面的建设就没有切入点，想做也没法做。
总的来说，如果我们的技术架构朝着微服务和分布式的方向演进，那我们可以考虑落地 SRE，这时候，我们的组织架构就要匹配我们的技术架构，也就是说，要想在组织内引入并落地 SRE 这套体系，原有技术团队的组织架构，或者至少是协作模式必须要做出一些变革才可以。
那下面我就以蘑菇街的技术架构为例，带你一起来看，在这样一个技术架构体系下，SRE 的角色、职责分工以及协作模式应该是怎么样的。
蘑菇街的 SRE 组织架构实践
我们回到在开头给出的技术架构图，可以看到上下左右总共分了五块区域，我们就分块来看。
先看最下面的基础设施层，我们现在也定义为 IaaS 层，主要是以资源为主，包括 IDC、服务器、虚拟机、存储以及网络等部分。
这里基础设施层和所需的运维能力，其实就是我们常说的传统运维这个角色所要具备的能力。但是这一层现在对于绝大多数的公司，无论在资源层面还是在能力层面，都有很大的可替代性。如果能够依托云的能力，不管是公有云还是私有云，这一部分传统运维的能力在绝大部分公司，基本就不需要了。
接下来往上，我们来看中台这一层。这里包括两部分，技术中台和业务中台。
技术中台主要包括我们使用到的各种分布式部件，如缓存、消息、数据库、对象存储以及大数据等产品，这一层最大的特点就是“有状态” ，也就是要存储数据的产品。
业务中台层，就是将具有业务共性的产品能力提炼出来，比如用户、商品、交易、支付、风控以及优惠等等，上面支撑的是业务前台应用。
什么是业务前台呢？如果以阿里的产品体系来举例，可以类比为淘宝、天猫、盒马、聚划算这样的业务产品。
无论这些业务前台的形态是什么样，但是都会利用到中台这些共享能力。这两层就是微服务化形态的业务应用了，这些应用最大的特点就是“无状态”，有状态的数据都会沉淀到刚才提到的技术中台的产品中。
最上面是接入层，分为四层负载均衡和七层负载均衡。前者因为跟业务逻辑不相关，所以通常会跟基础设施层放在一起，由传统运维负责。但是七层负载需要做很多业务层面的规则配置，所以通常会跟中台和前台一起运维，那这部分职责应该属于哪个角色呢？我们接下来就会讲到。
中台及前台的运维职责是怎么分工的呢？
技术中台的很多部件相对比较标准和通用，而且在公有云上也相对比较成熟了，比如数据库和缓存，对于绝大部分公司是可以直接选择对应的公有云产品的，比如蘑菇街，基本都已经将这些能力迁移到了云上。
在没有上云之前，我们的中间件团队会自研对应的技术产品，这部分产品的运维也会由中间件团队自运维。很多大型的公司会有专门的平台运维团队，负责整个中间件产品的运维。
业务中台和前台这两层的运维职责，通常就是我们常说的应用运维、PE（Production Engineer）或者叫技术运营这样的角色来承担。在我自己的团队是统一用 PE 来代表的。
其实这里 PE 的职责跟我们前面讲的 SRE 的职责已经非常接近了。在国内，PE 这个角色与 Google 定义的 SRE 所具备的能力，最大差别就在于国内 PE 的软件工程能力有所缺失或相对较弱。这就导致很多基于技术中台的自动化工具、服务治理以及稳定性保障类的平台没办法自己研发，需要由另外一个团队来支撑和弥补，也就是图中技术中台的衍生部分，技术保障体系。
PE 这个角色，是我们未来引入 SRE 实践的非常关键一环，PE 要跟业务开发团队一起对业务系统的稳定性负责。
那我们接着看技术保障体系。
技术保障平台，这部分的能力一定基于技术中台的能力之上生长出来的，是技术中台的一部分，如果脱离了这个架构体系，这个技术保障体系是没有任何意义的。
所以这里我们又要强调一个理念：“运维能力一定是整个技术架构能力的体现，而不是单纯的运维的运维能力体现”。微服务和分布式架构下的运维能力，一定是跟整个架构体系不分家的。
它们的具体依赖关系，我在图中已经标示出来，你可以结合我给出的图示再体会和深入理解一下。
回到技术保障体系的建设上，我们看下架构图的右侧，它又分为效率和稳定两块。
工具平台团队，负责效能工具的研发，比如实现 CMDB、运维自动化、持续交付流水线以及部分技术运营报表的实现，为基础运维和应用运维提供效率平台支持。
这个要更多地介入到研发流程中，因为流程复杂度比较高，而且还要对接很多研发平台，如 Git、Maven、代码扫描、自动化测试以及安全等平台，所以对业务理解及系统集成能力要比较强，但是技术能力要求相对就没那么高。
稳定性平台团队，负责稳定性保障相关的标准和平台，比如监控、服务治理相关的限流降级、全链路跟踪、容量压测和规划。我们会看到这个团队主要是为稳定性保障提供支撑，平台提供出来的能力是可以直接支撑业务开发团队的，反倒是 PE 这样的角色并不会直接使用。
这个团队和人员的技术能力要求会比较高，因为这里面很多的技术点是要深入到代码底层的，比如 Java 的字节码或 Socket 网络；有时还要面对海量数据，以及低时延实时计算的处理，比如全链路跟踪和监控；甚至是门槛更高的 AIOps，还要懂专业算法。所以这个团队的建设复杂度会比较高，会需要很多不同领域的专业人员。
好了，到这里，我们从技术架构入手，层层剖析，分析了对应的人员安排和能力，你会发现，按照分层进行职责分工就是：基础设施和接入层的 4 层负载部分属于传统运维；技术中台如果自研，也就是我们常说的中间件团队，开发同学自己负责对应的工作，如果上云，则由 PE 负责；业务中台、业务前台以及接入层的 7 层负责均衡，同样是由 PE 来负责。
如果我们用一张组织架构图来展示的话，基本形态就是下图：
总结
给出这张组织架构图，我们今天的内容也就讲完了。总结一下，从组织架构的角度来讲，对于稳定性或者说 SRE 我们可以推导出一个结论：SRE 并不是一个单纯的岗位定义，它是由多个不同角色组合而成的一个团队。如果从分工来看就是：
SRE = PE + 工具平台开发 + 稳定性平台开发
同时，这里的 SRE，跟我们前面讲的运维和架构不分家一样，在组织架构上，是与承担技术中台或分布式架构建设的中间件团队在同一个体系中的。
根据我平时的交流情况看，很多的传统行业也基本是按照这样一个模式组建 SRE 体系，一方面会有向互联网借鉴的原因，另一方面，我觉得也是本质的原因，就是前面我们提到的，组织架构往往是与技术架构相匹配的，技术上如果朝着分布式和微服务架构的方向演进，那必然会产生出类似的组织模式。
讲到这里，一个典型的互联网式的 SRE 组织架构就介绍完了，但是仅有组织架构是不够的，还需要继续深入下去，看看这个组织下的每个角色是如何与外部协作，如何发挥稳定性保障的具体职能的。所以，我们下一讲就会结合具体的稳定性保障场景，来分享 SRE 与其他组织的协作模式是怎么样的。
思考题
最后，给你留一个思考题。
学习完本节课，你觉得在一个组织进行 SRE 体系建设和变革过程中，哪个角色最为关键呢？同时，哪个角色是跟你最相关的呢？
欢迎你在留言区分享，或者提出你对本节课程的任何疑问，也欢迎你把本篇文章分享给你身边的朋友。
我是赵成，我们下节课见。
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
08｜故障复盘：黄金三问与判定三原则
下一篇
10 | 经验：都有哪些高效的SRE组织协作机制？
写留言
精选留言(7)
2020-04-07从一个公司的组织架构，往往能看出公司的技术架构。另外很期待老师分享一些云原生领域在SRE下的实践。😄展开作者回复: 这是个很好的议题，我们也正在实践，我会先记下，后面有一定的积累了，我分享出来。
3
2020-04-07SRE角色不仅仅是定位某个问题，还应该具备更全的技术栈及系统思维，当业务发展到一定规模的时候，我觉得这个角色还是很有必要的。展开作者回复: 相当有必要，不可或缺。
2
2020-04-07我觉得PE这个角色很重要，需要整理业务需求和反馈，沉淀到平台工具开发团队和稳定性开发团队。又需要和业务团队沟通交流，来适配技术中台。虽然他不是一手需求设计者，也不是具体技术中台功能开发者。但是确是关键的核心枢纽。展开作者回复: 你提到的枢纽这个定义，这个定位很关键，理解透彻。
1
2020-04-071.我认为是效能和稳定性工具平台的开发。
2.在所有角色中没有重要的轻重，因为我们要的是保证系统稳定运行这一最终目标，所以，哪怕是一根稻草的重量，那也是同等的重要.
3.但是，搭建整套完善的sre是一个长期的工程，安排好优先级可以让团队和公司在在搭建的过程中获得更高的效益，毕竟效益这个东西不是快照，而是一个时间上的积累。
4.所以，我认为优先做效能和稳定性平台的开发会比较好，因为他能比较快的拿出东西，也没有那么多因地制宜的限制，在sre推进的前期，既可以降低公司的顾虑，也可以提高团队的士气。是个开刀的好口子。至于iaas和paas这两块，能用云先用云。而业务这块，这是一件任重道远的事，不适合做先头。展开作者回复: 非常棒的分享和理解！
1
2020-04-06看到老师说的，我应该主要负责监控工具和效能工具的使用和开发。
真心觉得SRE是一个十分强大的小团队，在有一定基础运维能力前提下，还要对各种工具具备开发能力。
各种技术栈
TICK,grafana
ELK
zookeeper,kafka
consul,Prometheus
同时要学习Python+golang保持开发能力
工作了8个月，给自己带来了很多技术上的成长。
我有时在怀疑我是打工的，还是领导在花钱培养我们的个人能力😂
(题外话，老师有没有阅读英文技术文章的心得，或者如何能够有效的提高自己的阅读英语技术文章的水平嘞)展开作者回复: 最好的关系是相互成就，所以只有公司和个人都有成长才是双赢。
关于英文阅读，没有什么技巧，就是多读多看，遇到不懂的单词就查，水滴石穿，必须要有这个毅力才行。其它没有任何捷径。 1
2020-04-06国内传统行业的sre组织架构是什么样了的，有必要设置sre岗位吗？作者回复: 传统行业，做的比较优秀的，比如部分运营商的SRE组织架构其实跟我分享的是差不多的。有很多还没做到这个程度，需要时间和经验的积累。
2020-04-06个人觉得技术运营或者说去年GOPS大会提及的运维运营：这个其实是个中间层，熟悉产品、懂得且能处理技术相关的问题、能针对现状提出问题；个人可能对此还有更深层次的整体设计的事情。
站在中间且能看到两头大致梳理好两头其实这是任何事情发展到中期必然要面对的问题：中台的概念个人觉得其实同样基于此。就像我们说起系统运维，这个其实同样有两头硬件设备和网络，系统只是中间而已，如果硬件方面和网络方面没有处理好系统、、、
谢谢老师的分享尤其是云原生架构图引发的反思，期待后续的课程。展开
