当技术为组织所累时怎么办？将你的组织架构旋转90度！

DevOps 发展 告令人鼓舞，但是理想很丰满，现实很骨干，目前大多数 (尤其是成长型) 技术组织的现状却令人堪忧，他们的不仅交付能力远远达不到高效能组织的水平，而且还深陷各种困局：

方轮子困局 (Too Busy To Improve)

组织普遍存在“Too busy to improve”的恶性循环 (downward spiral)，下面是常见的场景：

• 业务压得喘不过气

• 系统耦合历史负担重

• 老系统还要升级（换轮子）

• 工程师质量参差不齐

• 机房容量刚好又不够，还得搬家迁机房

• 这么多事情凑在一块难免还要出故障

• 一出故障被老板挑战更加束手不敢试错

谷仓在国内也被称为烟囱或者竖井，通常出现在严格职能型组织中，表现为职能团队间信任不足，合作欠佳摩擦不断，各职能团队像一个个严实林立的谷仓一样，故而得名。下面是一个典型的场景：

• 业务领导：我们的增长太慢了，为啥我们不能比竞争对手更快推出产品/p>

• 产品管理：技术团队不给力，大量需求堆积无法推进，技术的问题怪不了我们！

• 研发团队：没有按时交付项目不能怪我们，我们要求的机器运维一直拖着没有到位，运维的老大该换换了！

• 运维团队：客户都快气疯了，我们大部分时间在救火保障系统稳定性，不要再扔东西给我们了，我的团队都快跑光了…

影子 IT 和“谷仓式”系统建设

当研发不给力，无法满足业务团队的交付要求时，业务团队倾向于自立门户，成立独立的研发团队，有的甚至会另起炉灶，自建独立的技术甚至运维体系。因为相关团队游离于正常研发之外，直接汇 给业务线，所以也称为影子 (shadow)IT。影子 IT 相当于再造一个“谷仓”，对企业造成的“损害”包括：

• 重复功能建设和维护带来的重复投资

• 打通“谷仓”系统间交互的集成和协作成本高昂

• 不利于业务的沉淀和持续发展

阿里巴巴发展的早期经历过很多次“谷仓”式的系统建设，详见附录 [7]。

注意，影子 IT 并非只有弊端，也可能带来意外的竞争激励和创新。

开发和运维之间的紧张关系

在开发和运维分离的严格职能型组织中，双方的 KPI 目标常不一致甚至是冲突的：

• 开发要更多更快的交付新功能，要变更；

• 运维则要尽可能保证现有系统的稳定性，不要变更。

目标冲突造成双方的天然紧张关系。

二、原理

系统制约原理

W.Edwards Deming 曾指出 [附录 9]，It is the system, not the people working in the system that determines a systems performance，系统的性能主要由系统本身决定的，而不是系统中工作的个人。

康威法则给我们的启示：软件系统的接口结构会映射组织的沟通结构，如果组织架构不合理，就无法建立一个高效的系统架构。一般在系统架构调整时，要提前考虑相应的组织架构的调整，两边联动才能产生效果。详见 [附录 12]。康威法则是近年流行的微服务架构背后的组织原理。

DevOps 原理

有些组织会更进一步组织端到端的跨职能产品研发团队，如下图，这种组织模式能够在团队内形成反馈闭环，交互沟通开销小。但是如果系统架构仍然是单块的，根据康威法则，组织架构和系统架构不匹配，就无法避免单块交付模式必然存在的跨团队协作沟通（例如多团队协调集成回归测试）和交付件传递 (hand-offs) 问题，整体效率仍然受限，无法达成真正的敏捷。

传统项目型组织 vs 现代产品平台型组织

下图是传统严格职能和项目型组织，典型的职能划分为业务方，研发团队和运维团队。

该组织模式的优点包括:

1. 围绕核心业务和技术产品组织团队，团队内形成闭环，打破谷仓壁垒

2. 以微服务方式组织团队，各团队可以独立开发，测试、发布和迭代各自的微服务，互不干扰，沟通协调成本小。微服务架构是一种演进式架构，利于组织业务的不断迭代演进。

3. 核心业务领域服务和技术基础设施 (IaaS/PaaS) 能够形成标准化体系化的产品，沉淀为组织中台资产，便于组织重用、集成和规模化创新。

4. 全部业务、研发和运维围绕产品开展工作，统一目标，大家都是产品驱动，分别服务于内外不同客户，避免技术驱动 vs 业务驱动的陷阱，避免研发和运维的紧张关系。

5. 研发人员容易形成业务领域知识积累，成为领域专家，更关注业务价值，积极参与组织业务方向的制定，保持组织人才的稳定性。

四、组织案例

Netflix 的 BusDevOps 组织架构

Netflix 是一家技术强大的互联 公司，但是它却是没有技术 CTO 职位的，产品团队和技术团队 (包括 UI 前端工程团队、Discovery 搜索工程团队和 Platform 平台团队等) 全部汇 首席产品 CPO，产品驱动是该公司的核心文化要素之一，Netflix 称其为 BusDevOps 组织架构 [附录 6]。

PaaS 是云平台工程团队的核心产品输出。它是在 AWS IaaS 基础之上的再次抽象封装，向上支撑 Netflix 的应用服务。PaaS 平台是 Netflix 基础技术服务能力的沉淀，核心组件大都产品化并且开源，称为 NetflixOSS，详见 [附录 10]。

阿里巴巴的“大中台、小前台”战略架构共分四个抽象层次，从下至上依次为：

• 第一层（最底层）是基础设施服务 IaaS(Infrastructure as a Service) 层，负责计算、 络、存储、监控、发布、机房和数据中心等基础设施。

• 第二层是技术平台服务 PaaS(Technical Platform as a Service) 层，负责中间件、大数据基础服务和研发工具链等。第一 + 第二层在阿里体系中统称为技术中台。

• 第三层是共享服务层，是阿里多年研发运营沉淀下来的核心商业能力模块（包括用户，商品，店铺，营销等等），被抽象和封装成公共服务 API，供上层调用和集成，阿里把该层也称为业务中台。

• 第四层（最上层）是前台业务层，按照不同业务线（陶宝、天猫、聚划算等）划分，再根据不同的用户体验（PC，无线，第三方接入）构建不同的表示层。

总体上，阿里的“大中台、小前台”体现了：

• 核心业务领域和技术平台沉淀为中台服务化产品

• 围绕中台产品构建基于微服务的跨职能交付团队

• 强化中台产品建设支撑前端业务快速迭代演进和规模化创新，中台好比是培育和孵化业务创新生态的土壤，土壤越肥沃厚实，则其上的业务生态越繁荣。

五、更大视角

上面谈了很多组织架构问题和相应的调整策略，最终的目标是通过组织敏捷达成业务敏捷，快速响应瞬息万变的市场需求，组织敏捷同时有赖于：

七、附录

1、2016 年 DevOps 发展 告

http://www.yunweipai.com/archives/10863.html

2、The Three Principles Underpinning DevOps

https://itrevolution.com/the-three-ways-principles-underpinning-devops/

3、Adopting Microservices at Netflix: Lessons for Team and Process Design

https://www.nginx.com/blog/adopting-microservices-at-netflix-lessons-for-team-and-process-design/

4、精益企业：高效能组织如何规模化创性

https://www.amazon.cn/%E5%9B%BE%E4%B9%A6/dp/B01AS1ORWM

5、CapitalOne DevOps Dashboard

https://github.com/capitalone/Hygieia

6、Netflix Global Cloud Architecture

https://www.slideshare.net/adrianco/netflix-global-cloud

7、企业 IT 架构转型之道 (阿里巴巴中台战略思想与架构实战)

https://www.amazon.cn/%E4%BC%81%E4%B8%9AIT%E6%9E%B6%E6%9E%84%E8%BD%AC%E5%9E%8B%E4%B9%8B%E9%81%93-%E9%92%9F%E5%8D%8E/dp/B0725GPXWQ

8、康威法则

https://en.wikipedia.org/wiki/Conway%27s_law

9、A Bad System Will Beat a Good Person Every Time

https://blog.deming.org/2015/02/a-bad-system-will-beat-a-good-person-every-time/

10、Netflix 开源软件中心

https://netflix.github.io/

11、阿里巴巴全面启动中台战略

https://www.huxiu.com/article/133482/1.html

12、企业的组织架构是如何影响技术架构的

http://www.infoq.com/cn/articles/organization-arch-influence-technology-arch

13、凤凰项目：一个 IT 运维的传奇故事

https://www.amazon.cn/%E5%9B%BE%E4%B9%A6/dp/B016VW1I6U

杨波，拍拍贷基础框架研发总监。具有超过 10 年的互联 分布式系统研发和架构经验，曾先后就职于：eBay 中国研发中心（eBay CDC），任资深研发工程师，参与亿贝开放 API 平台研发，携程旅游 （Ctrip），任技术研发总监，主导携程大规模 SOA 体系建设，唯品会（VIPShop），任资深云平台架构师，负责容器 PaaS 平台的调研和架构。

今日荐文

点击下方图片即可阅读

许式伟：我与 Go 语言的这十年

文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树首页概览8747 人正在系统学习中 相关资源：截取软件够累的-其它工具类资源-CSDN文库