PDF容器无法解决你破碎的文化（以及其他残酷的真相）
复杂的社会技术系统是困难的；
晚间11点档新闻。
Bridget Kromhout
我们常常专注于技术上的反模式，却忽略了我们社会结构中类似的问题。剧透警告：许多看似技术难题的解决方案，可以通过审视我们与他人的互动来找到。让我们来谈谈在与那些被称为“人类”的讨厌生物共事时，你需要了解的五件事。
1. 技术不是万能药
根据著名的思想领袖简·奥斯汀的说法，这是一个普遍公认的真理，即任何拥有生产代码的技术人员都必须想要一个容器平台。
真的是这样吗？让我们解构那些不言而喻的假设。别误会我的意思——容器很棒！但让我们面对现实：我们不太可能通过明智地应用内核特性来解决一个组织中绝大多数的问题。如果你的运维团队和开发团队之间存在争执——也许他们都在与一些考虑不周的DevOps孤岛对峙，而这个孤岛莫名其妙地卡在他们之间——那么cgroups和命名空间也无法解决这个问题。
开发团队喜欢将他们的依赖项与应用程序捆绑在一起的想法，幻想无限的可移植性。安全部门的某个人正在为未修补的CVE哭泣，但功能交付速度是如此令人向往，以至于安全部门的恳求无人理睬。平台运维人员很高兴（好吧，没那么暴躁了），因为他们知道他们可以升级底层基础设施，而不会影响任何应用程序的依赖项，直到他们意识到那些承载完整操作系统的重量级应用程序容器根本没有得到维护。
啊，但是，你会说，在我们的组织里，我们做得对（对于足够非糟糕的“对”的价值观而言）！我们在运行时注入凭据，并在每个环境中运行完全相同的容器。也许我们甚至运送只包含静态链接二进制文件的轻量级容器。好吧，但是跨各种环境测试的流量模式和数据可能不太接近。正如老笑话所说
提议：将“staging（预发布）”重命名为“theory（理论）”。“它在理论上可行，但在生产环境中不行。”——Najaf Ali
在你的真实生产环境中进行实验是无可替代的；容器与此正交，而跨组织沟通对于目的和意图的清晰至关重要。可观测性是关键，这是Charity Majors福音的基本信条。无论责任线划在哪里，错位的激励机制中固有的冲突都会继续显现。Andrew Clay Shafer称任何运行系统的状态为“持续局部失败”；良好的工具对于运行健壮的容错系统是必要的（但不是充分的）。
依赖于持续交付中的健康检查当然很好，直到健康检查充满了欺骗和谎言，因为它说一切都是200 OK，所有这些实例都留在负载均衡器中，但实际上什么都不工作。（我可能在表现出我的随叫随到创伤后应激障碍。）
在一个日益复杂的世界中，我们如何评估我们在迈向容器商店乌托邦方面的进展？我们如何知道何时纠正方向？当我们觉得总有新的事情我们上个月就应该做的时候，我们该如何反应？我真的必须编排我的容器吗？它们也许可以即兴爵士乐？
2. 良好的团队互动：构建，因为你无法购买
我们的大脑中保存着我们复杂分布式系统的错综复杂的组成，并且越来越多的状态是我们无法放入那些必然不完整的心理模型中的。微服务与其说是用代码行来定义的，不如说是用单个服务覆盖的范围和广度来定义的。而且，不，微服务不会阻止你的“两个披萨团队”在披萨上相互交谈。（还有，这些人有多饿？披萨有多大？太多未解答的问题了！）
Adrian Cockcroft指出，单体应用与微服务一样复杂；只是它被隐藏起来了。好吧，所以我们将解构那个可怕的单体应用，并在微服务世界中继续摇滚！这将解决一切问题！干净的抽象和明确定义的交接听起来很棒，直到你意识到你正在将决策的后果（以及任何权衡取舍中固有的冲突）转移到你堆栈的另一部分，Tim Gross称之为“复杂性守恒”。
分解成独立的团队并不能改变这样一个事实，即团队必须在任何给定时刻就边界在哪里达成一致。在20世纪60年代写作时，Mel Conway可能是在谈论今天——除了标题，因为“委员会是如何发明的？”非常掩盖了重点；今天它将是一篇标题党文章。
Conway写道，任何设计系统（广义定义）的组织都将产生一个设计，其结构是该组织沟通结构的副本。这被称为康威定律。
与流行的看法相反，康威定律并没有说你的组织结构图必须看起来完全像你的死星软件架构图，并且对两者进行粗略检查都会让我们相信该计划永远无法扩展。无论你在热排气口周围做出什么设计决策，任何工业强度的作业调度都无法使你的组织免受康威定律的影响。
康威定律中最重要的词是沟通。在你令人兴奋的解构世界中，关于破坏性变更的沟通是如何处理的？模式迁移呢，因为状态是真实存在的？（存储状态的麻烦之处在于你的价值通常存在于那里。货币类型对任何可能对记录系统产生不利影响的事情都非常敏感。）
有创造力的问题解决者有一种绕过我们认为不方便的流程的方法。如果你的重量级变更控制流程适用于除紧急情况外的所有情况，那么（剧透警告）你将会看到令人惊讶的高比例的“紧急情况”，并对此感到抱歉。
邓巴数，即个人可以维持稳定社会关系的人数的认知极限，已被证明是有效的。如果在更大的组织中工作，你需要以小组形式进行沟通，但这些小组应该是跨职能的，以消除瓶颈和误解。沟通不仅仅意味着用我们的人类声音交谈或回复没完没了的电子邮件线程；就像Consul的gossip协议一样，我们需要组织内部的串音来保持沟通畅通。
我们都听说过“我们只通过API进行沟通”，但仅靠技术并不能解决所有沟通问题。如果你发布了API的新版本，这是否意味着你将永远能够弃用旧版本？良好标记的版本控制是否足以满足你所有API消费者的当前需求？未来的、冲突的、重叠的需求呢？在某个时候，你将不得不互相交谈。（带些披萨来！）
3. 技术，就像Soylent Green，是由人组成的
Andrew Clay Shafer喜欢评论说，90%的技术是部落主义和时尚。工具很重要，但人是任何人为设计的复杂系统中不可或缺的一部分。我们都见过那些荒谬的昂贵的迁移失败，那些耗时多年的举升和转移项目，由于必须维持业务连续性，只完成了其目标的一小部分，以及那些“DevOps 倡议”，其持续时间仅足以完成某人的副总裁级别晋升。检查驱动这些决策的动机（即使是通过观察后果来重建），通常可以揭示次优决策的可能起源。
没有人用shell脚本进行简历驱动的开发；我敢打赌，所有写过的糟糕的bash脚本都是为了解决实际问题。当我们开始变得更花哨时，通常会有比“让我们把它做好”更不纯粹的动机，即使没有，仅凭意图也无法创建可维护的软件。幻灭低谷是我们所有人在梦想遇到现实时都会到达的地方。无论任何IT项目造成什么缓慢燃烧的轮胎火灾，肯定都会燃烧很长时间。软件只有在退役时才算“完成”；在那之前，第一天很短，而第二天会持续到宇宙的热寂。
一个好的心智模型是Simon Wardley的“先锋、拓荒者、城镇规划者”。虽然概念验证可以“完成”到足以交付的程度，但使其可操作化需要更长的时间，并且使其在生产环境中运行是一个持续进行的项目。正如热力学第二定律所解释的那样，熵会增加。
显然，努力进行迭代式IT改进很重要，但这不是最终状态。我们都参加过那些会议，人们与其说是倾听，不如说是等待轮到自己说话。软件是由情感组成的，正如Astrid Atkinson所说。我们需要考虑我们对彼此的影响。对人们进行DevOps认证就像庆祝他们幼儿园毕业。“恭喜！你学会了不要吃蜡笔，并与其他小朋友好好相处！”
这是否意味着DevOps未能实现其通过协作带来更高效率的承诺？绝非如此。与DORA（DevOps Research and Assessment）的优秀人士交谈：当我们以IT改进为中心时，研究中会显示出可衡量的影响。我们无法购买DevOps，尽管生态系统中的某些人可能会承诺给定的工具可以提供DevOps。我们必须践行它；为了变得更好而改变是我们每天通过我们富有同情心的倾听和富有同情心的行动所做出的选择。工具可以并且确实有帮助，但它们不能让我们关心。
4. 好篱笆造就好邻居
边界对象和抽象提供了必要的结构，容器是很好的边界对象，但它们并没有消除隐喻的（或非常真实的）开发和运维之间的边缘空间。当你实施微服务时，微服务有多“微”？即使你有一个定义明确的服务，可以（在某种程度上）做好一件事，一个好的标准是该服务的健康端点是否可以明确回答。如果对“这是否在工作？”的回答是“嗯……”，那么该服务就不够微。
决定什么是你的，什么是他们的，是每一次兄弟姐妹竞争缓和的基础。在Eric Brewer的CAP定理中，你可以选择一致性、可用性和分区容错中的两个，只要其中一个是分区容错，因为，正如分布式系统专家Caitie McCaffrey所说，“物理和数学”。在一个包含多个时区的人的分布式系统中，你不可避免地会遇到分区，等待总部醒来并做出决定绝不是一个好主意。但分散决策意味着将权力分配给你的边缘节点（有时很难推销）。
容器促进了开发人员的选择；在别人规定你需要什么和你确信自己需要什么之间总是存在张力。对工具和架构做出深思熟虑的决策会有所帮助；经过深思熟虑的约束可以将我们从那些没有给我们带来明显好处的决策中解放出来。容器可以帮助定义给定工具或项目的范围和影响，将系统解构到人类规模使我们能够理解它们的复杂性。
能够重现构建允许关注点分离。我们希望这是有效的，但又不会引入不必要的障碍。众所周知的混淆之墙是非常真实的，它建立在交付变更的激励和因稳定性而获得奖励之间的张力之上。构建恰到好处的抽象来授权独立团队是值得花时间迭代的（而且，不，没有人能立即做对，因为“对”会随着时间推移而演变）。
我们希望在对我们的组织有效的约束范围内，尽可能多地赋予人们自主权。要确定适合你的约束，你需要与你的团队交谈。以TCP而不是UDP来思考；你需要SYN/ACK才能真正了解其他人想要什么。非暴力沟通，你可以在其中重述你听到的内容，是检查你的人际沟通的有效方法。（奖励：技术人员会欣赏这种逻辑！）
5. 避免悲伤即服务
事后诸葛亮总是容易的，我们可以回顾过去并认识到拐点。在当下识别变化更难，但运营你自己的数据中心的时代，你的货币单位是虚拟机，正走向明确的中间状态。我们中的潮人会说这已经结束了，并向你推销serverless（这只是你无法ssh进入的服务器），但我们在这里谈论的是企业采用的现实，他们正处于认真对待容器的阶段。应用程序容器集群更适合工作负载放置的利用率和灵活性，并且使用容器化抽象可以实现更好的可移植性，包括对于那些展望公有云的组织。
质量控制领域的领导者W. Edwards Deming曾说过：“没有必要改变。生存不是强制性的。” 改变是艰难的。不改变更糟糕。工具是必不可少的，但我们如何在我们的组织中实施工具并发展文化和实践需要更多关注。事实证明，没有必要编写一个马尔可夫机器人来解析Hacker News的首页，然后立刻将所有内容都yolo到生产环境中！
无论你刚开始实施技术和组织变革，还是面临已经拥有遗留微服务的可能性，都值得考虑我们行为的原因和方式，而不仅仅是内容。如果遗留系统不重要，你可以直接将其关闭。但这是你的客户和资金所在。赞美令人兴奋的全新项目固然很好，但现实情况是，双峰IT是一个谎言。告诉人们他们中的一些人必须无限期地停留在“悲伤模式”，而另一些人则在“超棒模式”中飞速前进，这很荒谬。改变是在一个连续统上的；绝对不是所有改变都在同一瞬间发生。
当我们分担责任并拥有自主权，当我们超越习得性无助走向积极倾听时，我们就会成功。不要做有名管道；你不是键盘即服务。假设我们都可以阅读代码，那么在你的提交消息中添加详细信息可能比很快过时的注释更有用。告诉未来的你，你为什么做那件事；他们可以阅读，但不知道你的意图。口头传统就像从不将状态写入磁盘；刷新那些缓冲区。没有流程图，没有清单，没有购物清单式的勾选框可以让一切变得更好。“任何说不同的人都在卖东西”，正如《公主新娘》教导我们的那样。组织有“我们做事的方式”，因为流程是过去失败的伤疤组织。
你不能交付一个装有800个DevOps单元的集装箱，并让其中的600个给处于超棒模式的人，而处于悲伤模式的人可以看看另外200个，但不能碰它们。DevOps是你做的事情，而不是供应商使用当今最闪亮的工具为你实施的东西。为了变得更好而改变是我们共同做出的决定。
工具是必要的，但不是充分的。要构建一个我们都能与之共存的未来，我们必须共同构建它。
Bridget Kromhout 是微软的首席云开发倡导者。她的计算机科学学位重点是理论，但她现在处理具体的事物（如果云可以被认为是实实在在的）。在做了15年的运维工程师之后，她将随叫随到换成了空中飞行。作为技术会议的常客和项目委员会成员，她领导着全球的devopsdays组织和明尼阿波利斯的DevOps社区。她与Arrested DevOps一起播客，在bridgetkromhout.com上写博客，并且活跃在你附近的Twitter世界中。
相关文章
分布式系统的验证
Caitie McCaffrey
提高系统正确性信心的实践指南
https://queue.org.cn/detail.cfm?id=2889274
在质量保证中采用DevOps实践
James Roche
融合软件开发的艺术与科学
https://queue.org.cn/detail.cfm?id=2540984
糟糕的软件架构是人的问题
Kate Matsudaira
当人们不能很好地合作时，他们会做出错误的决定。
https://queue.org.cn/detail.cfm?id=2974011
版权所有 © 2017 归所有者/作者所有。出版权已授权给。
最初发表于Queue vol. 15, no. 6—
在数字图书馆中评论这篇文章
更多相关文章
João Varajão, António Trigo - 评估IT项目成功：感知与现实
这项研究对实践、研究和教育具有重要意义，因为它为IT项目成功提供了新的见解。它通过报告项目成功（而不仅仅是项目管理成功）扩展了项目管理知识体系，基于几个客观标准，例如项目后期阶段客户对可交付成果的使用情况、客户对项目相关支持/维护服务的雇用、客户签订新项目以及客户向潜在客户推荐供应商。研究人员可以找到一套标准，他们在研究和报告IT项目的成功时可以使用这些标准，从而扩展当前对评估的看法，并有助于得出更准确的结论。
Abi Noda, Margaret-Anne Storey, Nicole Forsgren, Michaela Greiler - DevEx：真正驱动生产力的因素
开发者体验侧重于开发者的生活体验以及他们在日常工作中遇到的摩擦点。除了提高生产力外，DevEx 还通过提高效率、产品质量和员工保留率来推动业务绩效。本文提供了一个实用的框架来理解 DevEx，并提出了一个测量框架，该框架将来自开发人员的反馈与他们与之交互的工程系统的数据相结合。这两个框架为领导者提供了清晰、可操作的见解，让他们了解要衡量什么以及在哪里集中精力以提高开发者生产力。
Jenna Butler, Catherine Yeh - 设身处地为他人着想
新冠疫情在许多方面改变了人们的工作方式，但许多结果本质上是自相矛盾的。对一个人有效的方法可能对下一个人无效（甚至对同一个人在第二天也无效），我们尚未弄清楚如何准确预测什么对每个人都有效。正如你在此处描述的综合角色中所看到的，有些人与隔离和孤独作斗争，很难在社交上与他们的团队建立联系，或者发现混合工作与远程团队的时间压力令人难以承受。其他人则喜欢这种新发现的工作方式，享受更多与家人共处的时间、白天锻炼的更大灵活性、更好的工作/生活平衡以及更强烈的为世界做出贡献的愿望。
© 保留所有权利。