微服务并不能修复你破碎的组织文化

我们常常关注技术中的设计模式，而忽略了我们社会结构中也存在类似的模式。通过审视我们与别人的沟通，可以找到许多技术性问题的解决方案。让我们来谈谈当你和讨厌的人类沟通时，你需要知道的五件事。

 

1. 技术并不是灵丹妙药

用著名的思想领袖Jane Austen的话来说，写代码的技术人员总要有一个容器，这是一条举世公认的真理。

Jane Austen是《傲慢与偏见》一书的作者，该书的第一句话是：有钱的单身汉总要娶位太太，这是一条举世公认的真理。

难道不是吗？让我们来解构这个不言而喻的假设。别误解我的意思——容器是令人愉快的！但让我们面对现实：我们不可能通过巧妙的使用操作系统内核特性来解决给定组织的绝大多数问题。如果运维团队和开发团队之间发生了争执——也许他们都面临着一些设计不当的DevOps孤岛（竖井），彼此之间莫名其妙地卡住了——那么cgroups 和 namespaces将无法解决这个问题。

译者注：大型组织内部总是存在一种所谓的“孤岛思维”(silo mentality)，即团队成员通常仅仅关注各自的职能部门或业务单元。如此有限的关注，阻碍了组织的个别部门对整体运营卓越性的促进作用。

开发人员喜欢将lib库与应用程序绑定在一起，想象着无限可移植性。安全部门的人员为未修补的安全漏洞而哭泣，因为feature开发速度是如此的理想，安全请求被忽略了。运维部门开始很高兴，因为他们以为可以升级底层基础设施而不影响任何应用程序的lib库，直到，他们意识到包含完整操作系统的重量级容器根本无法维护，他们才开始感到沮丧。

但是，你会说，在我们的组织里，我们正确的做事(希望“正确”这个词没有那么糟糕)！我们在运行时注入信任凭证，并在每个环境中运行完全相同的容器。甚至我们只提供静态链接二进制文件的轻量级容器。好的，但是不同测试环境的流量模式和数据可能不太一样。正如一个古老的笑话所说:

建议：将“staging”重命名为“theory”。“这在理论上行得通，在产品上行不通。”—Najaf Ali

译者注：就像这个悖论：In theory, everything works in production.

在实际生产环境中，没有什么可以替代测试。容器与测试正交，而跨组织沟通对于明确目的和意图至关重要。根据Charity Majors的说法，可观察性（Observability）是真理的一个基本原则。无论在哪里划定责任界限，不当奖惩机制引起的固有冲突将继续表现出来。Andrew Clay Shafer将任何运行系统的状态称为“连续半故障”状态。要维护一个鲁棒的容错系统，良好的工具是必要的，但还不够。

译者注：Charity Majors的说法：

• Monitoring is for operating software/systems

• Instrumentation is for writing software

• Observability is for understanding systems

在持续交付中依靠健康检查（health checks），开始是很好的，直到，健康检查充满了欺骗和谎言，因为它说一切都是OK，并且所有运行实例都在负载均衡设备中，但就是没有工作。(我的on-call PTSD可能正在显现。)

在一个日益复杂的世界里，我们如何评价我们朝着微服务乌托邦的进展？我们如何知道什么时候该修正航向？似乎总有一些新的，并且必须做的事情，我们该如何应对？我真的必须编排我的容器吗？他们可以即兴演奏爵士乐吗?

 

2. 良好的团队互动氛围：自己培育！因为这个买不到

我们头脑中充满了复杂分布式系统的繁杂组件，而且越来越多的状态使得我们无法适应必然不完整的心智模型。微服务不是由代码行数定义的，而是由单个服务覆盖的范围和广度定义的。而且，微服务并不会阻止你的“两个披萨”团队之间在吃披萨的时候互相交谈。(还有，这些人有多饿，披萨有多大?)，那么多没有回答的问题!

Adrian Cockcroft指出，单体架构和微服务其实一样复杂，单体架构只是隐藏了复杂性。好了，我们去分拆那个可怕的庞然大物——单体架构，然后在微服务世界里摇滚！这将解决所有问题！清晰的抽象和定义良好的接口听起来很棒，直到，你意识到你正在将复杂性，以及任何一组权衡中固有的冲突，移动到堆栈的另一部分，Tim Grosscalls称之为“复杂性守恒”。

如果你搞不定一个单块应用，别指望微服务能够拯救你!  —— 杨波 ：微服务架构核心20讲

把团队拆分成独立小团队并不能改变这样一个事实：团队在任何给定时刻都必须同意界限在哪里。在20世纪60年代，康威（Mel Conway）的著作，今天已经谈论很多。“How Do Committees Invent?”一文，除了标题，因为很多人都不知道。而今天，康威定律已经成为标题党。

康威写道，任何组织设计的系统(广义上)，都会产生一个设计，其结构与组织的通信结构一致。这就是康威定律。

与流行的观点相反，康威定律并没有说组织结构图必须看起来完全像死亡星球（death-star）的 架构图，粗略地检查一下康威定律和死亡星球的设计模式，我们就会相信该计划永远不会扩展。无论您围绕热排气口做出什么样的设计决策，再多的工业级任务调度也不能使你的组织免受康威定律的影响。

 

 

译者注：

软件行业中经验丰富的人将熟悉以下流行的反模式：

• 系统是用不可思议的钱秘密建造的。

• 只允许少数人用这个系统，其他人只能看。

• 系统在最低价值目标上展示过一次，但是之后，一些外星人开着蹩脚的飞船过来把它炸烂了。

• 然后资金耗尽，项目废弃。

• 在原始版本的悲剧性失败之后，“2.0”基本上以相同的方式执行，结果基本相同。

• 整个系统的成本远高于它所能实现的任何利润。

• 这也是慢的要命——千年隼号在一光年之外，用一天的时间就超过了它:)

现在它有一个名字：死亡星球设计模式。

康威定律中最重要的词是沟通。在这个充分分拆的微服务世界里，如何沟通和处理重大变更？那么schema迁移呢，因为状态是真实的？(存储状态的麻烦之处在于你的值一直存在于其中。对于任何可能对记录系统产生不利影响的事情，货币类型都会变得非常敏感）。

创造性问题解决者有一套方法绕过我们认为不方便的流程。如果你允许在“紧急情况”下更改流程，那么(提示)你会看到“紧急情况”经常发生。

邓巴数，一个人能与多少人保持稳定的社会关系的认知极限，被证明是有效的。如果在较大的组织中工作，你需要一个小组来进行交流，但是这些小组应该是跨职能的，以消除瓶颈和误解。交流不仅是指与我们人类的声音交谈，或回复没完没了的电子邮件，而是像Consul的gossip协议一样，我们需要在组织中进行交叉对话，以保持沟通顺畅。

 

我们都听说过：“我们只通过API进行通信”，但是技术本身并不能解决所有的沟通问题。如果你启动了API的新版本，这是否意味着你将永远弃用旧版本？标记良好的版本控制是否足以满足所有API使用者的当前需求？未来的、冲突的、重叠的需求呢？在某种程度上，你们必须彼此交谈。(还要带上一些披萨！)

计算机科学只存在两个难题：缓存失效和命名。 ——Phil KarIton.

 

3. 技术是由人组成的

技术，就像电影《超世纪谍杀案》，是由人组成的 。

Andrew Clay Shafer认为90%的技术是部落主义和时尚。工具是重要的，但是人是人类设计的任何复杂系统的组成部分。我们都看到，为了维持业务连续性的必要性，必须进行很高成本的迁移，而这些迁移都出了问题，持续数年的直接迁移（lift-and-shift）项目只完成了部分目标，而“DevOps计划”的持续时间仅够某个人完成升职副总裁。仔细研究驱动这些决策的动机，即使通过重构观察结果，通常可以揭示这些次优决策的可能成因。

没有人使用shell脚本编辑简历。我敢打赌，所有写过的janky bash都是为了解决一个真正的问题。当我们开始变得更花哨时，往往会有比“把事情做好”更不纯粹的动机，即使没有，意图本身也无法创建可维护的软件。在技术的炒作周期中，“幻灭的低谷”是我们所有人梦想与现实相遇时的落脚点。一个IT项目的结果是：不管轮胎着火的速度有多快，它肯定会燃烧很长一段时间。软件只有在退役时才“真正完成”，在完成之前，第一天很短，第二天直到宇宙热寂。

 

译者注：技术炒作周期，我们倾向于过高估计技术在短期内的影响，并低估其长期影响。幻灭的低谷：Trough of Disillusionment。

Simon Wardley的《拓荒者、定居者、城市规划者》就是一个很好的心智模型。虽然概念验证可以完成并交付，但是维护则需要更长的时间，并且在生产环境中正运行着一个正在进行的项目。熵持续增加，正如热力学第二定律所解释的那样。

 

 

译者注：

拓荒者：是非常聪明的人。他们能够探索未被发现的概念，未知的土地。但他们失败了很多次，创造的东西有一半时间不能正常工作。他们有很多“疯狂”的想法。他们建造了第一个电源（Parthian Battery，400AD）和第一台数字计算机（Z3,1943）。

定居者：是才华横溢的人。他们可以将半烘焙的东西变成对更多观众有用的东西。他们建立信任。他们建立了理解。它们使可能的未来真正发生。他们将原型转变为产品，使其可制造，倾听客户并使其盈利。他们建造了第一批计算机产品（例如IBM 650及更高版本），第一台发电机（Hippolyte Pixii，西门子发电机）。 

城市规划者：是非常出色的人。他们能够利用规模经济来获取某些东西并将其工业化。他们想方设法让事情更快，更好，更小，更有效，更经济，更好。他们采取存在的东西，并将其变成商品或公用事业（例如与电力，爱迪生，特斯拉和西屋公司）。他们是我们赖以生存的工业巨头。

 

你想要的是每个角色中的杰出人物。

显然，努力迭代IT改进很重要，但它不是最终状态和目标。我们都参加过这样的会议，参与者不是在倾听，而是在等待轮到他们发言。正如Astrid Atkinson所说，软件是由情感组成的，我们需要考虑我们对彼此的影响。庆祝通过DevOps认证就像庆祝从幼儿园毕业一样。“恭喜你！你学会了不吃蜡笔，还学会了和其他孩子好好玩耍！”

译者注：Astrid Atkinson还说道：In a place where everyone is basically competent, feelings are all that's left.在一个人人都能胜任的地方，剩下的就只有情感了。

这是否意味着DevOps没有兑现通过合作而提高效率的承诺？一点也不。与DORA (DevOps Research and Assessment)的专业人员交流：当我们将IT改进作为中心任务时，可测量的影响就会显现出来。我们买不到DevOps，尽管生态系统中的一些人会承诺某个特定工具会提供DevOps。我们必须生活在DevOps中，向更好的方向改变是我们每天的选择，是通过倾听和共情的行动做出的选择。工具可以提供帮助，也确实有用，但它们不能让我们关切更多。

 

4. 好围栏成就好邻居 

边界对象和抽象提供了“围栏”的结构。容器是很好的边界对象，但它们并没有消除Dev隐喻(真实)和Ops隐喻(真实)之间的有限空间。当你实现微服务时，多微才是微服务？即使一个定义良好的微服务，它可以很好地完成一件事(在某种程度上)，一个好的准则是微服务的健康检查是否能够明确地回答这个问题。如果向这个健康检查发送询问消息：“Is this working?”，得到的回答是：“Wellllll...,”,说明这个微服务还不够微。

决定什么是你的，什么是别人的，是人与人之间良好相处的基础。在Eric Brewer的CAP定理中，在一致性、可用性和分区三个属性中，你可以选择包含分区的任意两个。正如分布式系统专家Caitie McCaffrey所言，分布式系统就是“物理和数学”。在一个包含多个时区的分布式系统中，分区是不可避免地，而等待10个小时，为了总部的同事醒来并做出决定，这对任何人来说都不乐意。但是去中心化决策意味着将权力分配给边缘节点的人们，尽管有时很难说服。

容器赋予开发人员的选择权利。在别人的命令和你确信自己需要的东西之间，总是存在着一种张力。对工具和架构进行深思熟虑，这样做出的决策可能会有所帮助，可以将我们从那些没有给我们带来明显好处的决策中解放出来。容器化可以帮助定义工具或项目的范围和目标，将系统解构到人类认知可以理解的规模，从而让我们理解系统的复杂性。

持续发布可以做到关注点分离。我们希望这是有效的，但又会不引入不必要的障碍。众所周知，“混乱之墙”是真实存在的，它建立在这样一种紧张关系上：一方面有动力推动变革，另一方面又想获得稳定的回报。值得花时间重构的是：构建正确的抽象使得团队能够独立运转。而且，没有人能够一开始就做到正确，因为“正确”是随着时间推移而演进出来的。

 

我们希望在组织的工作约束条件下，赋予人们尽可能多的代理权。要确定适合组织的约束，需要与团队沟通。采用TCP模式而不是UDP模式，你需要SYN/ACK去理解其他人真正想要什么。非暴力沟通：即重述你所听到的，是检视与人沟通的有效方式。（ps：技术人员特别欣赏这种逻辑！）

 

5.  避免“悲伤即服务”

后见之明的优点是，我们可以回头看看并识别拐点。当下你很难看到未来的变化，但是很快你需要运维自己的数据中心，你的付费单位也将是虚拟机。周围的嬉皮士会说微服务已经过时了，并向你推销无服务(serverless，即不能ssh登录的服务器），但是我们在这里讨论的是企业采购的实际情况，企业正在认真对待容器技术。容器集群更有利于工作负载布局的利用率和灵活性，而容器化抽象有助于更好的可移植性。这也同样适用于那些面向公共云的组织。

W. Edwards Deming是质量控制领域的领军人物，他说：“变革不是必须的，生存也不是注定的”。（译者注：也就是说，任何一个组织，可以不做任何变革，但其生存也就得不到保障。换句话说，组织要保证能生存，就必须准备做出变革。）变革是困难的，不变革则更糟糕。工具是必不可少的，但需要更加关注的是：如何实现工具以及如何在组织中培养文化和实践。事实证明，编写一个马尔可夫机器人来解析Hacker News的头版并不是必须的，而你必须立即将所有东西投入到生产中。

 

无论你是刚刚开始实现技术升级和组织变革，还是已经实施微服务并期待它的美好前景，都值得考虑我们行为的why和how，而不仅仅是what。如果遗留系统不重要，你可以关掉它。但你的客户和现金流都在这些遗留系统上。另起炉灶的“绿地项目”固然很好，但现实是，双模态IT框架是一个谎言。让一些人必须无限期地停留在“悲伤”模式中，而另一些人却在“兴奋”模式中突飞猛进，这是可笑的。变化是一个连续的过程，当然，任何变革都不是瞬时发生的。

 

译者注：Gartner Research的双模态IT框架认识到传统的开发实践已不再适用于企业应用程序需求不断增长的组织。相反，双模态IT战略需要两条平行的轨道，支持数字创新优先级的快速应用程序开发，以及现有的应用程序维护和运营稳定项目。

Greenfield Projects 相对于 Brownfield Projects而言。绿地项目不受先前项目的限制，棕地项目是指在先前项目之上的修改和升级。

当我们分担责任和拥有代理权限时，当我们克服习得的无助而积极倾听时，我们就能成功。不要做一个命名管道，你不是“键盘即服务”。假如我们都能阅读代码，那么在代码提交中添加修改细节可能比很快过时的注释有用得多。告诉未来：你为什么要做那件事。不然他们可以读代码，但不知道你想要做什么。口口相传就像从不把状态写到磁盘上，而是写到这内存缓冲区中。没有流程图，没有检查清单，也没有交付清单，如果有这些会让一切变得更好。正如电影《公主新娘》告诉我们的那样：“如果有人说的不同，就在显示其他别的”。每一个组织都有“自己做事的方式”，因为流程就是过去的失败在组织身上结下的伤疤。

 

译者注：电影《公主新娘》：Anyone who says differently is selling something。如果一个人前言不搭后语，就一定是葫芦里有药要卖。

800个单位的DevOps容器交付，其中600个交付到兴奋模式下的人，而另外200个交付到悲伤模式下的人， 但是在悲伤模式下的人并不触碰这200个DevOps单元。DevOps是你所做的事情，而不是别人为你做的事情，尽管使用当今最出色的工具。把事情做的更好是我们共同做出的决定。

容器是必要的，但并不足够。为了建设一个我们共同生活的未来，我们必须共同努力。

 

---

本文作者Bridget Kromhout是微软云开发的主要倡导者。她学的是计算机科学，重点是在理论上，但她现在的工作是非常具体的（如果云可以被认为是具体的话）。在做了15年的运营工程师后，她放弃了随叫随到的工作，转而飞来飞去。她经常在科技会议上发言，也是项目委员会成员，她领导着devopsdays全球组织和明尼阿波利斯的DevOps社区。

本文翻译得到了国内顶尖微服务、分布式、互联网方向技术专家的review，以下是各位专家对本文的评论（ 排名不分先后）：

小剑：技术当然并不是灵丹妙药，微服务也一样，抛开场景和人空谈技术是没有意义的。但是微服务和相关的技术如devops，敏捷，容器，自动化等组合在一起，在适当的组织架构和公司文化下，还是能充分体现其价值。作者所说的不能忽略人的因素我表示理解和认同，技术和使用者就是要相互配合才能相得益彰。微服务实施如果失败，通常往往更多是和人还有人所在的组织有关。

老曹：很精彩的文字，人的复杂性、围栏边界、流程伤疤、真的不错。但原作者很多地方点到为止，没有展开，利于思考，不利于实施。本文是架构师的地图，不是程序员的导航。

李伟山：微服务是解决问题的一种思路，不是万能钥匙，文章给了我们很好的思考角度和纬度，能写出来的都是我们能遇见的问题，还有些隐藏的问题，是我们在真正面对需求或问题时才能碰到，架构的演化是循序渐进的，不是一鞠而就，文章是架构者很好的起点。

李晓时：非常赞同「技术不是灵丹妙药」，记得有位名人讲过「人不能作技术的奴隶」。任何问题，经过规约都会指向人的问题，只有解决了人的问题，才可能彻底地从根本上解决系统问题。DevOps就是通过人和系统的关系，人和人的关系解决问题。另外，关于单体，不能众口铄金，它曾经并且继续发挥不可替代的作用，微服务也并不是万金油。还有，似乎没有规范要求我们开发出单体，也似乎没有规定一个应用系统只能存在于一个war包中并部署。

杨波：这篇文章是不错的，强调组织结构和沟通问题重于技术问题，但是翻译还是比较生硬，一般程序员很难理解，作者本身经验很丰富，有深入思考，但是一般的开发人员没有经历和思考过，很难有共鸣，所以会曲高和寡。