如何控制软件蔓延

一开始可能很难识别软件蔓延的症状。起初可能只是微小隐患，可以被搁置一边，转而先完成优先级更高的工作。然而，如果任其发展，软件蔓延可能会削弱开发团队的能力，增加认知负荷，降低团队参与度，并扭转与松散耦合架构相关的好处。就像谚语一样：“种树的最佳时机是20年前。其次是现在。”未来的成功取决于能否在软件蔓延成为问题之前控制住它。

以下是软件蔓延的三个迹象，以及您可以做些什么来控制混乱局面，同时创造一个创新的动态环境，释放每个团队的潜力。

软件蔓延的早期症状是多次事后审查 (PIR) 表明上游变化是事件的根本原因。微服务数量的增加和环境中变更量的增加会给围绕开发人员协作和变更协调的现有规范带来压力。即使一个现代化应用的变更频率从每月一次小幅增加到每周一次，也可能导致每月的发布量增加 100 倍。因此开发人员需要调整协作方式。当开发人员协作规范无法适应快节奏的环境，生产中更有可能发生事件。

为开发人员创造一种非侵入性的方式来了解上游和下游的变更，这是遏制软件蔓延影响的好方法。在 Atlassian，我们使用 Compass（帮助团队浏览分布式架构的开发人员门户）向开发团队发送有关上游和下游服务重大变更的应用内通知。确认此通知会向变更发起人发出信号，表明负责相关服务的团队已知悉该变更。如果预计会出现任何问题，这提供了就变更进行合作的机会，从而降低了生产中出现意外影响的可能。由于事件必然会在动态环境中发生，因此开发人员在事件期间的协作对于快速恢复服务至关重要。

在上游变更为根本原因的事后审查中，恢复服务的时间通常会受到识别有问题的上游变更所花费的时间以及负责服务的团队或人员的影响。从逻辑上讲，随着时间的推移，减少识别违规上游变更所需的时间可以缩短平均恢复时间 (MTTR)。这在松散耦合架构中变得更加困难，在这种架构中，服务具有丰富的依赖关系层次结构，事件的根本原因可能在堆栈中的任何地方。传统上，事件响应者会浏览日志或变更记录，以确定可能导致事件的变更。在动态环境中，这就像拆除蚂蚁山来找到咬你的蚂蚁一样。

在 Atlassian 中，我们使用 Compass 中的动态订阅源来降低 MTTR。它显示了上游系统的所有事件以及负责该系统的团队的详细信息。这通过在事件发生期间支持开发人员协作，大幅缩短了分类时间。事件不可避免，但及时将上游变更确定为事件的根本原因对于确保最大限度地减少影响和快速恢复服务至关重要。

转向松散耦合架构是提高团队生产力和幸福感的关键要素之一，即能够在高度自主的情况下独立行动。如果不加以控制，软件蔓延可能会逆转其中一些好处，导致团队忙碌但效率低下且不开心。在与开发团队交谈时，一个常见的抱怨就是“一切都正常，直到需要与其他团队合作。”当软件蔓延成为问题时，这种情况就会加剧。快速扩张和变化的环境降低了开发人员跟踪上游或下游依赖关系应与谁互动的能力，最终导致努力按时交付的团队速度变慢且挫败感增加。

假设 Alpha 小组和 Beta 小组每周在 Jira 中遇到相同数量的问题，故事点移至“完成”。Alpha 小组花了 90% 的精力将新功能投入生产，而 Beta 小组 30% 的精力花在新功能上，70% 的精力研究如何与他们依赖的许多上游服务互动。两支小组的输出水平相同，但可能只有 Alpha 才算是工作效率高。软件蔓延放大了团队之间协作的需求。确定自主团队按需参与的明智方法是释放松散耦合环境力量的关键。

在快速增长和动态的环境中，自助提供信息的能力对于团队的生产力和幸福感至关重要。实现这一目标的一种方法是实施具有分散管理的集中式软件组件目录，这是一个集中式目录，每个团队负责创建和更新他们负责的服务。传统环境通常具有由特定团队或职能部门管理的集中式目录。但是，这跟不上分布式环境的变化速度，导致团队创建影子维基来说明谁参与和如何参与。在 Atlassian 中，我们发现去中心化方法可以减少团队间无形浪费的精力，提高自助服务能力，并创建按需互动的环境。通过提供有关上游和下游依赖关系的自助服务信息来控制软件蔓延，不仅有助于提高团队生产力，还会对团队的幸福感和参与度产生互补作用。