当技术为组织所累时怎么办？将你的组织架构旋转90度！
根据 2016 年 DevOps 发展报告 [附录 1]：高效组织比低效组织的发布频率高 200 倍，交付周期快 2555 倍，故障恢复时间快 24 倍，变更失败率低 3 倍。
DevOps 发展报告令人鼓舞，但是理想很丰满，现实很骨干，目前大多数 (尤其是成长型) 技术组织的现状却令人堪忧，他们的不仅交付能力远远达不到高效能组织的水平，而且还深陷各种困局：
组织普遍存在“Too busy to improve”的恶性循环 (downward spiral)，下面是常见的场景：
业务压得喘不过气
系统耦合历史负担重
老系统还要升级（换轮子）
工程师质量参差不齐
机房容量刚好又不够，还得搬家迁机房
这么多事情凑在一块难免还要出故障
一出故障被老板挑战更加束手不敢试错
谷仓在国内也被称为烟囱或者竖井，通常出现在严格职能型组织中，表现为职能团队间信任不足，合作欠佳摩擦不断，各职能团队像一个个严实林立的谷仓一样，故而得名。下面是一个典型的场景：
业务领导：我们的增长太慢了，为啥我们不能比竞争对手更快推出产品？
产品管理：技术团队不给力，大量需求堆积无法推进，技术的问题怪不了我们！
研发团队：没有按时交付项目不能怪我们，我们要求的机器运维一直拖着没有到位，运维的老大该换换了！
运维团队：客户都快气疯了，我们大部分时间在救火保障系统稳定性，不要再扔东西给我们了，我的团队都快跑光了…
当研发不给力，无法满足业务团队的交付要求时，业务团队倾向于自立门户，成立独立的研发团队，有的甚至会另起炉灶，自建独立的技术甚至运维体系。因为相关团队游离于正常研发之外，直接汇报给业务线，所以也称为影子 (shadow)IT。影子 IT 相当于再造一个“谷仓”，对企业造成的“损害”包括：
重复功能建设和维护带来的重复投资
打通“谷仓”系统间交互的集成和协作成本高昂
不利于业务的沉淀和持续发展
阿里巴巴发展的早期经历过很多次“谷仓”式的系统建设，详见附录 [7]。
注意，影子 IT 并非只有弊端，也可能带来意外的竞争激励和创新。
目前大部分研发组织仍然采用传统的项目制研发模式，研发人员跟着项目走，一个项目刚做完，很快会被安排到一个新的项目上重新开始。若干个项目下来，研发人员的项目经验会增长，但是普遍没有产品归属感 (ownership)，无法形成业务领域知识沉淀，简单讲就是不通业务。长期会造成研发人员工作积极性和创造性下降，跳槽频繁稳定性低的问题。顾问型和外包型公司大多是项目制的，类似问题尤其明显。
大部分技术组织对外宣传都称自己是技术驱动的，但是在业务和技术分离的职能型组织中，实际情况是技术部门根本谈不上驱动，顶多是支持，有的还常是背锅的角色。道理很简单，一方面业务方在董事会上肯定比技术方更擅长高谈阔论和画饼，更容易获得老板的好感；另一方面，交付效率和系统稳定性最终靠下游的技术方落地，这些东西是老板能直接感知的，一出问题，业务方在上游是比较容易转移注意力的，最后背锅的自然是下游的技术方。技术方加班加点一般都无怨言，但是轮到背锅却是有苦说不出。
在开发和运维分离的严格职能型组织中，双方的 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]。康威法则是近年流行的微服务架构背后的组织原理。
IT 运维管理畅销书《凤凰项目》[附录 13] 的作者 Gene Kim 在调研了众多高效能 IT 组织后总结出支撑 DevOps 运作的三个原理 (The Three Ways: The Principles Underpinning DevOps)[附录 2]，见下图：
开发驱动的组织，其能力不是制作软件，而是持续的交付客户价值。价值从业务需求开始，经过研发测试，到部署运维，依次流动，并最终以服务形式交付到客户手中。整个价值链流速并不依赖单个部分 (团队或个人) 的杰出工作，而是受整个价值链最薄弱环节 (瓶颈) 的限制。所以局部优化通常无效，反而招致全局受损。
Gene Kim 特别指出：Any improvements made anywhere besides the bottleneck are an illusion. 在瓶颈之外的任何优化提升都只是幻象。
系统思考要求我们加强团队合作，培养流式思维和瓶颈约束意识，优先找出瓶颈并针对性地优化。
过程改进常通过加强反馈环来达成。原理二强调企业和客户之间、组织团队间、流程上和系统内的反馈环。没有测量就没有提升，反馈要以测量数据为准，通过数据优化改进系统。
在企业管理文化层面强调勇于试错、持续试验、学习和改进的文化。
Adrian Cockcorft 是前 Netflix 云架构师，在经历 Netflix 大规模微服务架构的成功实践后，他提议现代组织要打破谷仓式职能壁垒，拥抱基于微服务的跨职能产品团队组织模式 [附录 3]。
目前大部分研发组织仍严格划分职能，职能间交集少，如下图所示。标准的研发流程以产品经理和研发团队 (包括用户体验团队) 反复多次讨论新功能需求开始；研发团队再将新功能用代码实现；然后代码被提交质量保证团队进行测试，这中间又涉及双方的多次会议交互；测试通过后提交 DBA 和运维上线，这中间又涉及和 DBA、系统、网络和存储管理员的多次交互 (一般通过工单系统)。整个流程缓慢充满各种会议协调开销。
有些组织会更进一步组织端到端的跨职能产品研发团队，如下图，这种组织模式能够在团队内形成反馈闭环，交互沟通开销小。但是如果系统架构仍然是单块的，根据康威法则，组织架构和系统架构不匹配，就无法避免单块交付模式必然存在的跨团队协作沟通（例如多团队协调集成回归测试）和交付件传递 (hand-offs) 问题，整体效率仍然受限，无法达成真正的敏捷。
康威法则告诉我们，软件系统的接口结构会反映组织的社交结构。所以如果组织要真正转型到微服务架构，就必须围绕微服务产品组织团队，基于 DevOps 模式开展工作。组织内不再以流水线方式设置产品经理，用户体验经理，研发经理等独立职能角色。每个核心产品 (实现为微服务) 有一个经理，即负责管理和监督团队，也负责微服务软件研发和交付的各个环节，从概念到发布。组织内不再有独立的运维团队和职能细分，只有负责基础设施产品 (IaaS/PaaS) 的平台团队，提供自动化和自助式平台 UI Portal 或 API，支持各个产品团队持续交付微服务。
从下图我们可以看出，现代跨职能微服务组织相当于将传统严格职能式组织旋转了 90 度。DevOps 运动和微服务架构本质上是一种组织架构的重组 (Re-Org)，而不是单纯的技术问题。
在 ThoughtWorks 推荐的 IT 领导力畅销书《精益企业：高效能组织如何规模化创新》[附录 4] 一书中，作者指出传统严格职能和项目型组织的弊端，同时提议学习高效能组织转型为现代产品平台型组织。
下图是传统严格职能和项目型组织，典型的职能划分为业务方，研发团队和运维团队。
该组织模式的弊端包括：
各个职能团队间易产生谷仓困局
业务方和研发团队如缺乏信任易产生
影子 IT 和谷仓式重复系统建设
业务驱动和技术驱动的陷阱
纯项目驱动易造成：
研发人员没有业务领域知识积累，团队稳定性差
研发和运维只顾接项目和做项目，以做项目多产出多为 KPI，既缺乏项目业务价值的关注，也没有产品化思路和沉淀，长期造成技术体系散乱，系统耦合历史负担重，系统稳定性差，交付效率低下
研发和运维的目标不一致造成天然紧张关系（求快求多 vs 求稳）
下图是现代产品平台型组织，为大部分高效能组织所采用，总体思路不复杂：
业务和产品研发闭环，围绕微服务产品组织跨职能交付团队
平台团队和运维围绕 IaaS/PaaS 基础设施产品开展研发和运维工作，为内部客户提供标准化平台服务
业务产品团队通过标准 IaaS/PaaS 平台，以自助方式持续交付价值到客户手中
该组织模式的优点包括:
围绕核心业务和技术产品组织团队，团队内形成闭环，打破谷仓壁垒
以微服务方式组织团队，各团队可以独立开发，测试、发布和迭代各自的微服务，互不干扰，沟通协调成本小。微服务架构是一种演进式架构，利于组织业务的不断迭代演进。
核心业务领域服务和技术基础设施 (IaaS/PaaS) 能够形成标准化体系化的产品，沉淀为组织中台资产，便于组织重用、集成和规模化创新。
全部业务、研发和运维围绕产品开展工作，统一目标，大家都是产品驱动，分别服务于内外不同客户，避免技术驱动 vs 业务驱动的陷阱，避免研发和运维的紧张关系。
研发人员容易形成业务领域知识积累，成为领域专家，更关注业务价值，积极参与组织业务方向的制定，保持组织人才的稳定性。
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 和微服务架构转型的成败至关重要。
不能将产品和技术简单割裂，在产品导向的组织内，没有技术驱动还是业务驱动一说，也没有项目驱动一说，只有产品和客户 (外部和内部) 驱动。互联网发展到今天，社会、产业、产品、技术早就密不可分，任何创新基本都是一体化推进的，“业务制定需求、技术团队负责做出来”的甲方乙方模型底下是落后的观念、残缺的认知和狭隘的本位主义思想，能否击败这些挑战将会成为互联网公司的分水岭。
注意，
本文是作者个人学习思考总结，不代表任何官方意见。
本文的观点假设适用于技术团队规模超过百人以上，日流量过五千万的成长型或成熟型技术组织。对于团队规模小于百人的初创公司来说，谋活才是第一要务，组织结构优化并不着急，但本文思路仍可借鉴。
大新闻倒计时，5天！
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
今日荐文
点击下方图片即可阅读
许式伟：我与 Go 语言的这十年