ACM通信
实践
容器无法修复你破碎的文化(以及其他残酷的事实)
图片来源:Andrij Borys Associates / Shutterstock
我们太过关注技术上的反模式，而忽略了社会结构内部的类似问题。剧透警告:通过观察我们与他人的互动，我们可以找到许多看似技术性困难的解决方案。让我们来谈谈在与这些讨厌的生物——人类共事时你想知道的五件事。
1.科技不是万灵药
著名的思想领袖简·奥斯丁(Jane Austen)说，拥有任何生产代码的技术人员都需要容器平台，这是一个举世公认的真理。
果真如此吗?让我们来解构一下这些不言而喻的假设。不要误会我的意思，容器是令人愉快的!但让我们现实一点:我们不太可能通过明智地应用内核特性来解决给定组织中的绝大多数问题。如果你的运维团队和开发团队之间存在争议，也许他们都面临着一些考虑不周的DevOps竖井莫名其妙地卡在他们之间，那么cgroups和命名空间将无法解决这个问题。
开发团队喜欢将依赖项与应用捆绑在一起，想象无限的可移植性。安全部门的某些人正在为未打补丁的cve而哭泣，但功能速度是如此令人渴望，以至于安全部门的请求被置若罔闻。平台运营商知道他们可以在不影响任何应用程序的依赖关系的情况下升级底层基础设施而感到高兴(好吧，不那么粗暴)，直到他们意识到装载完整操作系统的重量级应用程序容器根本没有得到维护。
啊，但是，你会说，在我们的组织，我们做这是正确的(充分的非可怕的“正确”的价值)!我们在运行时注入凭据，并在每个环境中运行完全相同的容器。我们甚至可以只使用静态链接的二进制文件发布轻量级容器。好吧，但是在不同环境中测试的交通模式和数据可能不太一样。正如一个老笑话所说:
提案:将“分期”更名为“理论”。“这在理论上行得通，但在实际生产中行不通。”
纳杰夫·阿里
在真实的生产环境中进行实验是无可替代的;容器是与之正交的，而跨组织的沟通对于目的和意图的清晰是至关重要的。在慈善专业人士看来，可观察性是福音的一个基本原则。无论在哪里划定责任界限，不当的激励所固有的冲突继续显现。Andrew Clay Shafer将任何正在运行的系统的状态称为“连续的局部故障”;良好的工具对于运行健壮的容错系统是必要的(但不是充分的)。
在您的持续交付中依赖运行状况检查是很好的，直到运行状况检查充满欺骗和谎言，因为它说一切都是200 OK，所有这些实例都停留在负载平衡器中，但什么都没有工作。(我可能表现出了随叫随到的创伤后应激障碍。)
在一个日益复杂的世界中，我们如何评估我们朝着集装箱商店乌托邦的进展?我们怎么知道什么时候该改正呢?当我们发现似乎总是有一些我们上个月应该做的新事情时，我们会怎么反应?我真的必须编排我的容器吗?他们能即兴表演爵士乐吗?
2.良好的团队互动:建立，因为你不能购买
我们在头脑中掌握着复杂的分布式系统的复杂组成，越来越多的状态我们无法放进那些必然不完整的心智模型中。微服务不是由代码行定义的，而是由单个服务覆盖的范围和广度定义的。而且，微服务不会阻止你的两个披萨团队为了吃披萨而相互交谈。(还有，这些人有多饿，披萨有多大?有这么多没有回答的问题!)
Adrian Cockcroft指出，一个整体和微服务一样复杂;只是隐藏起来了。好了，我们要解构这个可怕的庞然大物，继续在微服务的世界里摇摆。这将解决一切问题!干净的抽象和定义良好的转换听起来很不错，直到您意识到您正在将决策的结果(以及任何折衷中固有的冲突)转移到堆栈的另一部分，Tim Gross称之为“复杂性守恒”。
进入个性化的团队并不能改变团队必须在任何特定时刻就界限所在达成一致的事实。梅尔·康威(Mel Conway)写于20世纪60年代，如果没有标题，他的话题本可以用在今天，因为《委员会是如何发明的?》在很大程度上掩盖了主题;今天，它可能会变成标题党。
Conway写道，任何设计系统(广义定义)的组织都会产生一个设计，其结构是该组织通信结构的副本。这就是著名的康威定律。
与普遍的看法相反，康威定律并没有说你的组织结构图必须看起来完全像你的死星软件架构图，而且粗略地检查一下会让我们相信这个计划无论如何都不会扩展。无论您围绕热排气口做出什么样的设计决策，再多的工业强度作业调度也不能使您的组织免受康威定律的影响。
康威定律中最重要的一个词是沟通。在你令人兴奋的解构世界中，如何处理关于破坏性更改的沟通?模式迁移呢，因为状态是真实的?(关于存储状态的麻烦之处在于，您的值经常存在于此。金钱类型的人对任何可能对记录系统产生不利影响的事情都非常敏感。)
创造性的问题解决者有一种绕过我们认为不方便的过程的方法。如果您的重量级变更控制过程适用除了如果是紧急情况，那么(剧透)你将会看到令人惊讶的高比率的“紧急情况”——抱歉——不抱歉。
邓巴数字，一个人可以与之保持稳定社会关系的人数的认知极限，是明显有效的。如果在一个较大的组织中工作，你将需要在较小的小组中沟通，但这些小组应该是跨职能的，以消除瓶颈和误解。沟通不仅仅意味着用人类的声音交谈或回复没完没了的电子邮件;就像Consul的八卦协议一样，我们需要在我们的组织中进行相声以保持沟通顺畅。
我们都听说过“我们只通过api进行通信”，但技术本身并不能解决所有的通信问题。如果您启动了一个新版本的API，这是否意味着您可以弃用旧版本的API ?标记良好的版本是否足以满足所有API使用者的当前需求?未来的、冲突的、重叠的需求呢?总有一天，你们得互相谈谈。(带点披萨来!)
3.科技，就像Soylent Green，是由人组成的
安德鲁·克莱·谢弗(Andrew Clay Shafer)喜欢认为90%的科技是部落主义和时尚。工具很重要，但人是任何人类设计的复杂系统中不可或缺的一部分。我们都见过昂贵得离谱的迁移出了问题，因为保持业务连续性的需要，长达数年的提升和转移项目只完成了一小部分目标，“DevOps计划”只持续足够某人的副总裁升级完成。研究驱动这些决策的动机(即使通过观察结果来重建)通常可以揭示次优决策的可能成因。
没有人使用shell脚本进行résumé-driven开发;我敢打赌，所有的废话都是为了解决真正的问题。当我们开始变得更有幻想时，通常会有比“让我们把这个做好”更不纯粹的动机，即使没有动机，单凭意图也不能创造出可维护的软件。当梦想与现实相遇时，我们都会陷入幻灭的低谷。无论一个给定的IT项目导致了什么缓慢燃烧的轮胎火灾，它肯定会燃烧很长一段时间。当软件退役时，它就“完成”了;在那之前，第一天是短暂的，而第二天会持续到宇宙的热死。
Simon Wardley的《拓荒者，定居者，城市规划者》是一个很好的思维模式。虽然概念验证可以“完成”到交付，但将其操作化需要更长的时间，并且保持其在生产环境中运行是一个持续的项目。熵增加，正如热力学第二定律所解释的。
在一个日益复杂的世界中，我们如何评估我们朝着集装箱商店乌托邦的进展?
显然，努力进行迭代的IT改进很重要，但这不是最终状态。我们都参加过这样的会议，人们与其说是在听，不如说是在等着轮到自己发言。正如阿斯特丽德·阿特金森所说，软件是由感觉构成的。我们需要考虑对彼此的影响。为DevOps中的人员认证就像庆祝他们从幼儿园毕业一样。“恭喜你!你学会了不吃蜡笔，还学会了和其他孩子好好玩耍!”
这是否意味着DevOps未能实现通过协作提高效率的承诺?一点也不。与DORA (DevOps研究与评估)的优秀人员交谈，当我们以IT改进为中心时，研究显示出了可衡量的影响。我们不能购买DevOps，尽管生态系统中的一些人可能承诺某个特定工具可以提供什么。我们必须活在其中;向更好的方向改变是我们每天做出的选择，通过我们同情地倾听和同情地行动。工具可以也确实有帮助，但它们不能让我们在乎。
4.好篱笆造就好邻居
边界对象和抽象提供了所需的结构，容器是很好的边界对象，但它们不能消除隐喻(或太真实)的开发人员和操作之间的界限空间。当你实现微服务时，微是怎样的微?即使您有一个定义良好的服务，它可以(在一定程度上)很好地完成一件事，一个好的标准是服务的运行状况端点是否可以明确地回答。如果“这个有用吗?”的答案是“嗯……，这种服务还不够微。
决定是什么你的是什么他们的是每一个兄弟姐妹竞争的基础détente。在Eric Brewer的CAP定理中，您可以选择一致性、可用性和分区容差中的两个，只要其中一个是分区容差，因为正如分布式系统专家catie McCaffrey所说的，这是“物理和数学”。在一个包含多个时区的分布式系统中，您不可避免地会有分区，等待总部醒来并做出决定的10个小时对任何人来说都不是一个好时间。但是去中心化的决策意味着将权力分配到你的人力边缘节点(有时很难推销)。
容器促进了开发人员的选择;在别人指示的东西和你确信自己需要的东西之间总是存在着矛盾。对工具和架构做出深思熟虑的决定会有所帮助;考虑周全的约束可以让我们从那些不能给我们带来明显好处的决定中解脱出来。容器可以帮助定义给定工具或项目的范围和范围，将系统解构为人类的尺度使我们能够理解它们的复杂性。
能够重新生成构建允许关注点分离。我们希望这是有效的，但不引入不必要的障碍。众所周知的困惑之墙是真实存在的，它建立在发布更改的动机和获得稳定性奖励之间的紧张关系上。构建正确的抽象来授权独立的团队是值得花时间迭代的(不，没有人会立即正确，因为“正确”会随着时间的推移而发展)。
我们希望在为我们的组织工作的约束条件下，赋予人们尽可能多的代理权。为了确定合适的约束条件，您需要与您的团队进行交谈。考虑TCP而不是UDP;你需要SYN/ACK来真正理解其他人想要什么。非暴力的交流，即重申你所听到的，是一种有效的核对和人际交流的方式。(额外奖励:技术人员会欣赏这种逻辑的!)
5.避免悲伤是一种服务
事后看来，我们可以回顾并认识到拐点。目前很难认识到变化，但运营自己的数据中心、以虚拟机为单位的货币的时代正在走向一个明确的中间阶段。我们当中的潮人会说这一切都结束了，并向您推销无服务器(即您不能ssh到的服务器)，但我们在这里谈论的是企业采用的现实情况，他们正在认真对待容器。应用程序容器集群更有利于利用和灵活地放置工作负载，而使用容器抽象有助于更好的可移植性，包括对于那些希望使用公共云的组织。
质量控制领域的领军人物w·爱德华兹·戴明(W. Edwards Deming)说，“没有必要改变。生存并不是必须的。”改变是困难的。不改变更糟糕。工具是必不可少的，但是我们如何实现这些工具，如何在我们的组织中发展文化和实践，需要更多的关注。事实证明，并不是必须要写一个马尔可夫机器人来解析Hacker News的首页，然后yolo绝对所有的东西立即生产!
无论您是刚刚开始实现技术和组织变化，还是已经有了遗留微服务，都值得考虑为什么而且如何我们的行为，不仅仅是什么。如果遗产不重要，你可以把它关掉。但这是你的客户和钱所在的地方。美化令人兴奋的新项目是很好的，但现实是双峰IT是一个谎言。告诉人们，有些人必须无限期地保持“悲伤模式”，而另一些人则以“了不起的模式”迅速前进，这是荒谬的。变化是连续的;绝对的，每一个变化都不会在同一时刻发生。
当我们分担责任，发挥主动性，当我们从习得性无助转为积极倾听时，我们就成功了。不要成为一个有名的管道;你不是键盘即服务。假设我们都能阅读代码，在提交消息中添加细节比即将过时的注释要有用得多。告诉未来的你你为什么做那件事;他们可以阅读，但不知道你的意图。口头的传统就像从未写过的状态;刷新这些缓冲区。没有流程图，没有清单，没有购物清单，没有勾勾框，可以让一切变得更好。“任何说不同话的人都是在推销某种东西。公主新娘教我们。企业有“我们做事的方式”，因为过程是过去失败的伤疤。
你不可能收到一个装有800个DevOps的集装箱，并让其中的600个以出色模式分发给用户，而处于悲伤模式的用户只能看着另外200个DevOps却不碰它们。DevOps是你自己做的事情，而不是供应商用当今最闪亮的工具为你实现的事情。向更好的方向改变是我们共同做出的决定。
工具是必要的，但不是充分的。为了建设一个我们都能共同生活的未来，我们必须共同建设。
相关文章
在queue.acm.org
分布式系统的验证
Caitie麦
https://queue.acm.org/detail.cfm?id=2889274
在质量保证中采用DevOps实践
詹姆斯罗氏
https://queue.acm.org/detail.cfm?id=2540984
数字图书馆是由计算机协会出版的。版权所有©2018 ACM, Inc.
没有找到条目