我们需要一种整体的DevOps方法，将工具、工具使用者和整个组织机构视为紧密相连、相互依存的有机统一体，全面考量其中的各个因素。
译自 Thinking in Systems: A Sociotechnical Approach to DevOps，作者 Tao Hansen 是 Garden.io 的开发者关系负责人，也是 Kubernetes、Linux 和开源软件的死忠粉丝。他幻想在华盛顿州的沃什岛上加入一个有意识的社区生活修道生活，但目前还生活在......
DevOps 第一波的重点是自动化和 Dev 与 Ops 之间的协作开发。在实践中，DevOps 分成两大阵营。一派相信软件工具的力量，可以实现更快的反馈循环、宽松的交付和弹性的好处。另一派则专注于文化层面的组织变革。这派人士对 DevOps工程师的存在表示哀叹，因为 DevOps应该是整个组织无瑕疵诞生的全局实践。这两大阵营注定要重蹈过去的覆辙，将 DevOps 拆分为技术解决方案和文化实践。
我们需要一种整体的DevOps方法。一种将工具、使用这些工具的工作人员以及他们所在的更大组织视为相互依存的整体有机部分的方法。正如Ergomanic的创始人，也经常被是为 DevOps 的创造者的 Andrew Clay Shafer 所说，DevOps 是“使用软件......和人类优化操作软件的人类体验和性能......”。让我们来探讨这个定义，并考虑如何引领 DevOps 的第二波浪潮，同时解决人与他们使用的工具。
如今的开发者正深陷复杂性的泥潭。在采用Kubernetes的组织中，微服务技术栈可能那么大，而开发者所关注的部分那么小，以至于很难理解它，更难理解它如何为终端用户创造价值。
组织应对这种扩散复杂性的一种方式是建立越来越精密的平台来管理它——但这些平台本身也越来越复杂。正如System Initiative的Adam Jacobs指出的：“整个系统的组装方式？使用体验？那基本上与2009年时没什么不同。”
那些声称以正确方式实践DevOps的团队会投资进行跨域训练，直到每个人都成为“全栈”。通过训练每个人应对复杂性来管理复杂性，这降低了专业化水平，不可持续，并消耗员工。
过去卑微的CI/CD流水线现在需要由专业的DevOps工程师班子来照料。一个需要如此多手动操作、迫使开发者等待、并傲慢地抛出阻塞错误的管道，还能算是“持续”的吗？更糟的是，大多数CI/CD系统无法在本地运行，所以开发者只能等到最后一刻才针对管道的测试套件验证他们的代码。
所以，工具很糟糕，开发者也无法理解整体业务战略，因为这些信息没有被有效地传达给他们。Dev和Ops正在合作，但由于他们共同拥有的部分与整体战略脱节，他们的目标可能不一致。解决方案是什么？
DevOps 的第二波既是一种基于工具的方法，也是一种组织方法，自下而上、自上而下解决问题。它在两个层面涉及系统思维：工具层面和组织层面。
在工具层面，我们需要解决公司技术问题的系统性工具，而不仅仅是解决部分问题的工具。在组织层面，我们需要了解员工如何为整个组织做出贡献，并给予他们权力和上下文，让他们能够做出与组织目标一致的决策。
开发人员和团队负责人掌握现场的事实，而领导层掌握空中的事实。将个人任务与组织的使命声明对齐，可以确保每个人都朝着共同的目标工作。我们通过采用社会技术方法来实现这一点。
什么是社会技术系统？我们使用的软件工具如何成为其组成部分？社会技术理论家Jabe Bloom在他的演讲“Whole Work: Sociotechnicity & DevOps”中提出了社会技术系统的两大支柱：人们如何协同工作以及他们的技能如何适应这项工作。
我认为这个定义没有涵盖第三个重要支柱，即该系统中工具的使用。任何社会技术解决方案都必须结合强大的工具，这些工具改变了我们的生产方式。我们正在见证一种趋势，即朝着不仅仅是解决某些特定问题的零碎修补的工具，而是润滑工具之间锯齿状边缘的整体解决方案的工具演变。
已故哲学家贝尔纳德·斯蒂格勒（Bernard Stiegler）认为，技术构成了人类认知的一部分——也就是说，我们使用工具和技术从根本上塑造了我们的思维和对世界的理解。这意味着采用更好的工具可以改进我们的思考和工作方式。具体来说，映射组织内输入和输出错综复杂网络的工具可以帮助我们推理价值链以及我们在其中的位置。这种新型工具使用定向无环图来捕捉您的软件基础架构、微服务、测试和作业。
想象您是一个大型组织中的软件开发人员，该组织拥有成千上万的开发人员。您的团队拥有一个API，它控制小部件通过时间和空间的流动。您的API被数十个其他团队使用，但您缺乏更大价值的意识，缺乏在整个系统中的位置感。您的API如何产生业务价值？它的上游和下游依赖项是什么？如果您的API明天消失，它对业务会有什么影响？
Garden等工具可以捕捉软件的价值映射，这样您这样的团队可以随时查看他们在整体中的位置。我们越了解自己在更广泛的社会技术系统中的角色，我们就越有能力做出更好的决策，并与领导层保持一致驾驶我们的船只。
然而，理解和交互这个复杂的系统网络不仅仅是一个技术挑战，它也深深涉及人性方面。如果人——社会技术系统中的社会部分——没有专心致志地工作，那么您的软件基础架构及其服务的图就是无用的。
对于开发者来说，流动是一种无意识的、持续集中精力在一项任务上的状态。社会技术实践DevOps不仅需要复杂的工具，还需要有利于深度工作的环境。如何培养有利于深度工作的做法和文化？通过采用有利于快速流动和消除阻碍依赖的整体工具。您的GitHub Actions流水线怪兽就是快速迭代开发的阻碍依赖。
当开发者可以在本地运行流水线时，他们就有权力根据自己的想法尽快开发，无所畏惧，全神贯注。
为了达到流动状态，开发者需要行动、决策和在更大系统内看到其工作影响的权力。这种权力至关重要；没有它，想要实现流动就像逆风航行一样困难。
当团队拥有这种权力时，当他们“掌控自己的命运”时，他们的集体努力会成倍增长。Bloom建议拥有主动权的工作人员会问这样的问题：“我如何运用自己的特定技能和知识为更大利益做出贡献？”
目标是将这些工具和人员系统交织在一起，将它们视为单一的实践体系。整体 DevOps 则从更宏观的层面来观察整个人为输入系统及其输出的软件，并满足系统整体的需求。
在 DevOps 工程师成为 CI/CD 流水线的看护者之前，他们的工作是去隔离。无论他们是文化实践、技术知识还是战略的传播者，这些赋能团队都会向其他团队和个人传授他们需要掌握的习惯、方法和工具，以取得成功。
工具、使用该工具的工作人员、他们的团队和组织都高度相互依存。将任何一方从整体中分割开来，就像一个医生孤立地治疗患者的某种疾病，而不是从整体着手。社会技术 DevOps 是一种整体实践，努力实现可见性、团队和个人的主体性，并采用在系统层面处理我们复杂的服务依赖关系图的软件工具。