“DevOps 的阴暗面”：左移的代价和降低成本的方式

类似“我构建、我运行”，或“测试、安全、数据治理左移”等话题很是流行。将事务移动至软件开发的早期阶段，赋权于工程师，并将控制权转移是能带来确实好处的。

但是，如此一来的代价是什么？这对参与其中的开发人员而言又意味着什么？

从开发人员的角度看，优势很明显；可以获得更多权力、能在开发周期更早的阶段解决问题，还可以缩短反馈循环。然而开发人员的责任范畴也将超出代码，囊括安全、基础架构和其他“被左移”的东西。重要的是，随着这些领域中最佳实践的不断发展，维护的成本和需求也会变得很高。

有什么方案能让我们在维持 DevOps 的同时左移呢？我们又要如何打破阴暗面的束缚？让我们快来看看吧！

将部分软件开发生命周期活动向左移动，意味着将其移至软件开发流程的早期阶段，从而赋能开发者。据《DevOps 现状报告》称，具有最佳 DevOps 实践的公司可降低超 50% 的变更失败率，代价是其部署频率更高（从最高的每天部署多次，到最低的六月才部署一次变更）。

原因很明显，开发人员在表现最佳的公司中不必忍受漫长的反馈周期。举例来说，将测试从“部署发布”环节挪到“开发构建”环节，就意味着开发人员能更早地发现问题，而不用在几天乃至几周后才等到 QA 验证变更。如果将测试再左移一步至“计划设计”阶段，那么开发人员将不必再花费实践构建存在设计缺陷的代码。

然而，这并不是万金油。左移也意味着开发人员必须学习测试方法、工具（如 TDD、JUnit、Spock，以及 GitHub Actions 等构建编排工具）。

此外，左移的不仅仅是测试，安全、数据治理等更多东西也都在向左移动，而所有这些都将增加开发人员的认知负担。开发人员必须学会这些工具、采用最佳实践，并随着最佳实践的变化，在最新的基础设施上维护代码。

从一方面来说，没人指手画脚的感觉很棒，开发人员不用再等别人批准，可以更快地迭代编写更好的代码，更短的反馈周期也让错误发现和修复更加轻松。

但另一方面，这些增长的认知符合是可量化的，开发人员需要花费更多的时间和精力学习所有的工具和技术。有些人开发者不希望如此，他们只想专注于编写自己的代码，并解决业务问题。

举例来说，有的开发人员可能会很高兴尝试部署工具，并能够将部署管道从 Jenkins 迁移到 Spinnaker，从而获取原生、开箱即用的金丝雀支持。但其他开发人员可能就不太喜欢摆弄这些工具，尤其是在自己已经手忙脚乱的时候。

这些额外的责任不是毫无代价的，实际的成本取决于公司规模和其计算基础设施的复杂度。对于规模较小的公司，工作的人少，负责的组件或服务也不多，认知负荷并不高。毕竟大家都知道彼此在干什么，上下文交接花不了多少功夫。这种情境下，将部分 SDLC 工作左移可以消除人为障碍并赋予开发人员更多权力，从而带来立竿见影的好处。

即使是 Netflix 这类大型公司，也有手动管理解决方案的空间。举例来说，如果某个应用在接收生产流量前有需要预热的缓存，那么负责该应用程序的团队就可以创建一个手动管理的部署流水线，以确保在观测自定义的预热期间后，才允许程序接受流量，这样一来，重新部署也不会导致性能下降。

然而，IT 基础设施的复杂性也会随着公司的发展而增加，维护数十个相互关联的服务不再轻松，甚至有时想找到服务各自的负责人也困难起来。此时，公司将会面临一个抉择：是要重新引入会对生产力造成负面影响的看门狗实践，还是找到一条铺好的路（paved path），一条通过预定义解决方案编码最佳实践，消除心理负担，让开发人员能够集中精力解决业务问题的大路。

这条路的铺设和维护都需要投资；必须要有人能识别出痛点、组织调动开发人员能用于与路交互的工具，编写文档、投资开发人员培训教育。也必须要有人能观测离群点，如果这条铺好的路解决方案没能让程序性能更好，是否需要借鉴目前正在进行的实践，并将其纳入这条路中。

对铺路的投资是为减轻开发人员的认知负荷。让开发人员能不再操心所有被左移的东西，并专心提供价值，解决核心业务问题。例如，依靠 CLI 工具（如 Netflix 的 newt）或内部开发者门户网站（如 Spotify 的 Backstage），一键启动所需的所有基础架构，而不再需要手动设置 GitHub 仓库、CI/CD 流水线、AWS 安全群组和扩展策略等云资源，上述这些都可以且应该是开箱即用的。

此外，如果能有专家负责迁移过程，开发人员就不必处理迁移多引发的认知负担。比如，流媒体后端服务 Netflix 必须更新才能适配 AWS 示例元数据 API 从而提高安全性，那这种情境下，已铺好的路便会随之对开发人员透明地进行变更。将 AWS 设置封装为代码，可在不新增认知负担或中断的情况下，利用铺好的路推出对服务的变更。

最后，仅仅一条铺好的路是无法覆盖所有随公司发展而不断开发的服务、组件的最佳实践，只有创建并维护多条铺路，并确定这些道路之间的共同点并加以复用，这些都是需要额外的投资。

举例来说，Netflix 流媒体服务需要服务于数百万用户，其对延迟和可用性的要求与 Netflix 员工内部使用的工具是完全不同的。这两类用例都有其各自的最佳实践，金丝雀发布和红黑发布有益于流媒体应用，但这对内部工具而言没有多大意义，后者的流量水平可能无法提供金丝雀发布所需的可靠信号。另一方面，这两类用例也可能拥有持续测试、集成等共同点，因此，将这两类场景作为单独的构件并复用于不同铺路而言是合理的。

第一步是确定左移带来的实际问题。对小型跨职能团队而言，最困难的地方可能是需要确定到底左移什么。如果团队正困扰于部署的失败率，那么团队或许应当投资于测试和 CI/CD 管道。

即使是没能立刻找到正确的解决方案，在解决方案之间迁移并不需要太多的时间和精力。最坏的情况也只是在错误的痛点选择了错误的问题去解决。然而，如果能找到正确的杠杆点，那么即使是不完美的解决方案也能带来一定改善。举例来说，如果基于 Jenkins 的 CI 管道难以管理，那么迁移至 GitHub Actions 或许会不错，但如果要应对的服务数量不多，那么这种迁移将得不偿失。

实际的开发者体验将在这里扮演关键的角色；听取开发人员意见、观察开发工作，并以此找出实际存在的问题是至关重要的。

没有这些思考的左移将是无脑的跟风，而非解决自身实际存在的问题。作者也见过有些试图模仿大公司中流行实践的决定，或许有的时候这会是正确选择，但通常情况下，人们所面对问题并不相同。对其他公司而言是反模式的方案或许才是你最合适的选择。如果你的问题非常简单，那么能用单体架构解决的问题是无需投资于微服务编排的（虽然单体架构通常来说是真正的反模式）。

另一个需要考虑的问题是构建还是购买，多数公司都患有“自食其力”综合征，宁愿自己开发解决方案也不愿意选择第三方工具。但从另一方面来说，这些三方工具也是需要彼此集成，并集成至已有的内部工具，才能提供无缝的开发者体验。从作者个人角度来看，如果问题是公司独有，或与公司核心业务紧密相关，那么投资于定制解决方案或许是值得的。

最后，为了确保自己没有偏离航道，我们应跟踪部署频率（部署至生产的频率，每月，每周，还是每天？）变更失败率（部署失败频率）等指标，以及启动服务和重新配置服务（或服务群）所需的时间指标。

综合这些指标，我们能对高质量代码交付能力和开发人员的非编程时间做出预估，希望这些能帮你在 DevOps 之旅中迈出下一步。

原文链接：

https://www.infoq.com/articles/devops-shifting-left/

声明：本文为 InfoQ 翻译，未经许可禁止转载。

点击底部阅读原文访问 InfoQ 官网，获取更多精彩内容！