一、理想 vs 现实
根据 2016 年 DevOps 发展报告 [附录 1]：高效组织比低效组织的发布频率高 200 倍，交付周期快 2555 倍，故障恢复时间快 24 倍，变更失败率低 3 倍。
DevOps 发展报告令人鼓舞，但是理想很丰满，现实很骨干，目前大多数 (尤其是成长型) 技术组织的现状却令人堪忧，他们的不仅交付能力远远达不到高效能组织的水平，而且还深陷各种困局：
方轮子困局 (Too Busy To Improve)
组织普遍存在“Too busy to improve”的恶性循环 (downward spiral)，下面是常见的场景：
业务压得喘不过气
系统耦合历史负担重
老系统还要升级（换轮子）
工程师质量参差不齐
机房容量刚好又不够，还得搬家迁机房
这么多事情凑在一块难免还要出故障
一出故障被老板挑战更加束手不敢试错
谷仓 (Silo) 困局
谷仓在国内也被称为烟囱或者竖井，通常出现在严格职能型组织中，表现为职能团队间信任不足，合作欠佳摩擦不断，各职能团队像一个个严实林立的谷仓一样，故而得名。下面是一个典型的场景：
业务领导：我们的增长太慢了，为啥我们不能比竞争对手更快推出产品？
产品管理：技术团队不给力，大量需求堆积无法推进，技术的问题怪不了我们！
研发团队：没有按时交付项目不能怪我们，我们要求的机器运维一直拖着没有到位，运维的老大该换换了！
运维团队：客户都快气疯了，我们大部分时间在救火保障系统稳定性，不要再扔东西给我们了，我的团队都快跑光了…
影子 IT 和“谷仓式”系统建设
当研发不给力，无法满足业务团队的交付要求时，业务团队倾向于自立门户，成立独立的研发团队，有的甚至会另起炉灶，自建独立的技术甚至运维体系。因为相关团队游离于正常研发之外，直接汇报给业务线，所以也称为影子 (shadow)IT。影子 IT 相当于再造一个“谷仓”，对企业造成的“损害”包括：
重复功能建设和维护带来的重复投资
打通“谷仓”系统间交互的集成和协作成本高昂
不利于业务的沉淀和持续发展
阿里巴巴发展的早期经历过很多次“谷仓”式的系统建设，详见附录 [7]。
注意，影子 IT 并非只有弊端，也可能带来意外的竞争激励和创新。
项目制的弊端
目前大部分研发组织仍然采用传统的项目制研发模式，研发人员跟着项目走，一个项目刚做完，很快会被安排到一个新的项目上重新开始。若干个项目下来，研发人员的项目经验会增长，但是普遍没有产品归属感 (ownership)，无法形成业务领域知识沉淀，简单讲就是不通业务。长期会造成研发人员工作积极性和创造性下降，跳槽频繁稳定性低的问题。顾问型和外包型公司大多是项目制的，类似问题尤其明显。
技术驱动 vs 业务驱动的陷阱
大部分技术组织对外宣传都称自己是技术驱动的，但是在业务和技术分离的职能型组织中，实际情况是技术部门根本谈不上驱动，顶多是支持，有的还常是背锅的角色。道理很简单，一方面业务方在董事会上肯定比技术方更擅长高谈阔论和画饼，更容易获得老板的好感；另一方面，交付效率和系统稳定性最终靠下游的技术方落地，这些东西是老板能直接感知的，一出问题，业务方在上游是比较容易转移注意力的，最后背锅的自然是下游的技术方。技术方加班加点一般都无怨言，但是轮到背锅却是有苦说不出。
开发和运维之间的紧张关系
在开发和运维分离的严格职能型组织中，双方的 KPI 目标常不一致甚至是冲突的：
开发要更多更快的交付新功能，要变更；
运维则要尽可能保证现有系统的稳定性，不要变更。
目标冲突造成双方的天然紧张关系。
二、原理
系统制约原理
W.Edwards Deming 曾指出 [附录 9]，It is the system, not the people working in the system that determines a systems performance，系统的性能主要由系统本身决定的，而不是系统中工作的个人。
Deming 认为，在给定的上下文 (系统组织) 中，个人一般会自激励尽最大努力做到最好。但如果系统本身设置是有问题，则会极大制约系统内部个人的发挥。所以，针对上述困局，我们不能简单责备系统中的个人，而是应该跳出来从系统组织纬度去思考和调整，才可能找到根本性的解决之道。
康威法则
Melvin Conway 在 1967 年提出所谓康威法则 [附录 8]，指出组织架构和系统架构之间有一种隐含的映射关系：
Organization which design system […] are constrained to produce designs which are copies of the communication structures of these organization. 设计系统的组织其产生的设计等价于组织间的沟通结构。
康威法则给我们的启示：软件系统的接口结构会映射组织的沟通结构，如果组织架构不合理，就无法建立一个高效的系统架构。一般在系统架构调整时，要提前考虑相应的组织架构的调整，两边联动才能产生效果。详见 [附录 12]。康威法则是近年流行的微服务架构背后的组织原理。
DevOps 原理
IT 运维管理畅销书《凤凰项目》[附录 13] 的作者 Gene Kim 在调研了众多高效能 IT 组织后总结出支撑 DevOps 运作的三个原理 (The Three Ways: The Principles Underpinning DevOps)[附录 2]，见下图：
原理一：系统思考 (System Thinking)
开发驱动的组织，其能力不是制作软件，而是持续的交付客户价值。价值从业务需求开始，经过研发测试，到部署运维，依次流动，并最终以服务形式交付到客户手中。整个价值链流速并不依赖单个部分 (团队或个人) 的杰出工作，而是受整个价值链最薄弱环节 (瓶颈) 的限制。所以局部优化通常无效，反而招致全局受损。
Gene Kim 特别指出：Any improvements made anywhere besides the bottleneck are an illusion. 在瓶颈之外的任何优化提升都只是幻象。
系统思考要求我们加强团队合作，培养流式思维和瓶颈约束意识，优先找出瓶颈并针对性地优化。
原理二：强化反馈环 (Amplify Feedback Loops)
过程改进常通过加强反馈环来达成。原理二强调企业和客户之间、组织团队间、流程上和系统内的反馈环。没有测量就没有提升，反馈要以测量数据为准，通过数据优化改进系统。
原理三：持续试验和学习的文化 (Culture of Continual Experimentation And Learning)
在企业管理文化层面强调勇于试错、持续试验、学习和改进的文化。
三、组织架构转型
传统职能式组织 vs 现代跨职能微服务组织
Adrian Cockcorft 是前 Netflix 云架构师，在经历 Netflix 大规模微服务架构的成功实践后，他提议现代组织要打破谷仓式职能壁垒，拥抱基于微服务的跨职能产品团队组织模式 [附录 3]。
目前大部分研发组织仍严格划分职能，职能间交集少，如下图所示。标准的研发流程以产品经理和研发团队 (包括用户体验团队) 反复多次讨论新功能需求开始；研发团队再将新功能用代码实现；然后代码被提交质量保证团队进行测试，这中间又涉及双方的多次会议交互；测试通过后提交 DBA 和运维上线，这中间又涉及和 DBA、系统、网络和存储管理员的多次交互 (一般通过工单系统)。整个流程缓慢充满各种会议协调开销。
有些组织会更进一步组织端到端的跨职能产品研发团队，如下图，这种组织模式能够在团队内形成反馈闭环，交互沟通开销小。但是如果系统架构仍然是单块的，根据康威法则，组织架构和系统架构不匹配，就无法避免单块交付模式必然存在的跨团队协作沟通（例如多团队协调集成回归测试）和交付件传递 (hand-offs) 问题，整体效率仍然受限，无法达成真正的敏捷。
康威法则告诉我们，软件系统的接口结构会反映组织的社交结构。所以如果组织要真正转型到微服务架构，就必须围绕微服务产品组织团队，基于 DevOps 模式开展工作。组织内不再以流水线方式设置产品经理，用户体验经理，研发经理等独立职能角色。每个核心产品 (实现为微服务) 有一个经理，即负责管理和监督团队，也负责微服务软件研发和交付的各个环节，从概念到发布。组织内不再有独立的运维团队和职能细分，只有负责基础设施产品 (IaaS/PaaS) 的平台团队，提供自动化和自助式平台 UI Portal 或 API，支持各个产品团队持续交付微服务。
从下图我们可以看出，现代跨职能微服务组织相当于将传统严格职能式组织旋转了 90 度。DevOps 运动和微服务架构本质上是一种组织架构的重组 (Re-Org)，而不是单纯的技术问题。
传统项目型组织 vs 现代产品平台型组织
在 ThoughtWorks 推荐的 IT 领导力畅销书《精益企业：高效能组织如何规模化创新》[附录 4] 一书中，作者指出传统严格职能和项目型组织的弊端，同时提议学习高效能组织转型为现代产品平台型组织。
下图是传统严格职能和项目型组织，典型的职能划分为业务方，研发团队和运维团队。
该组织模式的弊端包括：
各个职能团队间易产生谷仓困局
业务方和研发团队如缺乏信任易产生
影子 IT 和谷仓式重复系统建设
业务驱动和技术驱动的陷阱
纯项目驱动易造成：
研发和运维的目标不一致造成天然紧张关系（求快求多 vs 求稳）
下图是现代产品平台型组织，为大部分高效能组织所采用，总体思路不复杂：
业务和产品研发闭环，围绕微服务产品组织跨职能交付团队
平台团队和运维围绕 IaaS/PaaS 基础设施产品开展研发和运维工作，为内部客户提供标准化平台服务
业务产品团队通过标准 IaaS/PaaS 平台，以自助方式持续交付价值到客户手中
该组织模式的优点包括:
围绕核心业务和技术产品组织团队，团队内形成闭环，打破谷仓壁垒
以微服务方式组织团队，各团队可以独立开发，测试、发布和迭代各自的微服务，互不干扰，沟通协调成本小。微服务架构是一种演进式架构，利于组织业务的不断迭代演进。
核心业务领域服务和技术基础设施 (IaaS/PaaS) 能够形成标准化体系化的产品，沉淀为组织中台资产，便于组织重用、集成和规模化创新。
全部业务、研发和运维围绕产品开展工作，统一目标，大家都是产品驱动，分别服务于内外不同客户，避免技术驱动 vs 业务驱动的陷阱，避免研发和运维的紧张关系。
研发人员容易形成业务领域知识积累，成为领域专家，更关注业务价值，积极参与组织业务方向的制定，保持组织人才的稳定性。
四、组织案例
Netflix 的 BusDevOps 组织架构
Netflix 是一家技术强大的互联网公司，但是它却是没有技术 CTO 职位的，产品团队和技术团队 (包括 UI 前端工程团队、Discovery 搜索工程团队和 Platform 平台团队等) 全部汇报首席产品 CPO，产品驱动是该公司的核心文化要素之一，Netflix 称其为 BusDevOps 组织架构 [附录 6]。
Netflix 的云平台工程团队主要承担基础服务 PaaS 平台的建设和运维，对外统一向各个业务线输出标准化的平台服务，赋能整个组织开展基于 DevOps 模式的微服务持续交付和创新。该团队和传统运维团队不同，它是架构、框架中间件、云平台、持续交付，可靠性和性能工程，基础领域服务和大数据服务等的一个混合闭环团队。
PaaS 是云平台工程团队的核心产品输出。它是在 AWS IaaS 基础之上的再次抽象封装，向上支撑 Netflix 的应用服务。PaaS 平台是 Netflix 基础技术服务能力的沉淀，核心组件大都产品化并且开源，称为 NetflixOSS，详见 [附录 10]。
阿里巴巴中台战略
2015 年底，阿里巴巴集团宣布启动 2018 年中台战略 [附录 11]，构建符合 DT 时代的更灵活创新的“大中台、小前台”组织机制和业务机制：作为前台的一线业务会更敏捷，更快速适应瞬息万变的市场；中台将集合整个集团的运营数据能力、产品技术能力，对各前台业务形成强力支撑。
阿里巴巴的“大中台、小前台”战略架构共分四个抽象层次，从下至上依次为：
第一层（最底层）是基础设施服务 IaaS(Infrastructure as a Service) 层，负责计算、网络、存储、监控、发布、机房和数据中心等基础设施。
第二层是技术平台服务 PaaS(Technical Platform as a Service) 层，负责中间件、大数据基础服务和研发工具链等。第一 + 第二层在阿里体系中统称为技术中台。
第三层是共享服务层，是阿里多年研发运营沉淀下来的核心商业能力模块（包括用户，商品，店铺，营销等等），被抽象和封装成公共服务 API，供上层调用和集成，阿里把该层也称为业务中台。
第四层（最上层）是前台业务层，按照不同业务线（陶宝、天猫、聚划算等）划分，再根据不同的用户体验（PC，无线，第三方接入）构建不同的表示层。
总体上，阿里的“大中台、小前台”体现了：
五、更大视角
上面谈了很多组织架构问题和相应的调整策略，最终的目标是通过组织敏捷达成业务敏捷，快速响应瞬息万变的市场需求，组织敏捷同时有赖于：
技术领先：灵活的架构依赖于领先的技术能力，PaaS 云平台，持续交付流水线，自动化和监控测量等基础技术能力是微服务架构的先决条件。
流程保障：研发型组织的交付能力取决于价值流 (Value Stream) 在组织内到客户手中的流速，价值流的速度取决于企业和客户之间，组织团队间，流程上和系统内各个环节的闭环反馈和持续改进。流速越快，交付能力越强，客户响应就越及时，体验就越好， 相应的客户给与企业的回报就更多。良性健康的循环能够推进企业业务持续不断的演进。价值流可视化工具非常有用，可以帮助组织定位瓶颈，加快价值流速度，可参考 [附录 5]。
人才和文化：不管是组织流程，还是技术架构，如果脱离人才密度就是空中楼阁。良好的企业文化能吸引和聚集优秀人才，人才和文化是企业基业常青的根基。
六、结论
根据 DevOps2016 报告，高效能组织和低效组织的生产率有数量级上差异，目前大多数技术组织仍然深陷各种困局中。
Netflix 和阿里巴巴等高效能组织的一线实践表明，DevOps 和微服务架构是技术组织突破困局和转型升级的最佳实践。DevOps 和微服务转型本质上是一种组织架构重组 (Re-Org)：将技术组织旋转 90 度，从半职能半矩阵式组织转型到面向市场的跨职能混搭协作式组织，组织围绕微服务产品构建团队和开展研发运营。组织内部团队达成闭环，组织和市场之间达成闭环，更快更灵活地响应市场需求。
组织架构，流程，人才密度和文化等非技术因素对企业 DevOps 和微服务架构转型的成败至关重要。
不能将产品和技术简单割裂，在产品导向的组织内，没有技术驱动还是业务驱动一说，也没有项目驱动一说，只有产品和客户 (外部和内部) 驱动。互联网发展到今天，社会、产业、产品、技术早就密不可分，任何创新基本都是一体化推进的，“业务制定需求、技术团队负责做出来”的甲方乙方模型底下是落后的观念、残缺的认知和狭隘的本位主义思想，能否击败这些挑战将会成为互联网公司的分水岭。
CIO之家 www.ciozj.com 公众号:imciow