DevOps 文字培训
为什么要建立反馈机制，让生产部署更安全？
在你所在的竞争激烈的市场中，如果想快速服务客户并持续满足需求，就很难再让质量保证和运维部门与开发团队分开。然而，大多数开发人员虽然抱怨组织内的官僚程序，但当有机会在自己的团队中与质量保证和运维专家协作时，仍会担心独立进行无人监督的生产部署。这就需要采用相应的技术和措施，让生产部署更安全。
如何让 DevOps 工作持续流转
为了让工作持续顺畅地流转，大多数成功的 DevOps 组织都会频繁地将小批量变更部署到生产系统。这样，DevOps 团队中的每个人都能评估和理解变更，并在必要时予以修复。
仅构建自动化部署流水线还不够。你需要将运维遥测集成到部署流水线中，以便迅速了解变更在生产和预生产环境中的结果。此外，组织应建立共同认识：DevOps 团队中的每个人都要对整个价值流和部署流水线的健康与持续运行负责。
利用遥测实现更安全的部署
在证明变更和部署能够按设计和编码目标运行之前，不要将其标记为“已完成”。部署之后，密切监控发生变更的模块的指标、可能新增的指标，以及系统中其他可能受到变更影响的组件的指标。
即使使用预生产环境运行自动化测试，并通过遥测基础设施监控被测系统，生产系统仍然会出现问题。虽然无法预防所有问题，但可以做好充分准备，在问题发生时加以解决。如果某项变更导致部署流水线中断，就召集解决问题所需的所有领域专家，恢复流水线的正常运行。以下是三种常用的问题解决方法：
- 关闭该功能： 这是解决问题最简便的方法，无需紧急部署代码。只需用功能开关关闭该功能。你不用立即修正部署中的错误部分，DevOps 团队可以花时间正确找出根本原因并改进方法，使此类问题今后不太可能再次出现。
- 向前修复问题： 部署新代码来解决问题。在传统 IT 组织中，向前修复是处理生产问题的一种高风险方式。但在 DevOps 组织中，如果具备测试自动化、自动化部署和全面的生产遥测，这种方法可以非常有效、高效且安全。
- 回滚变更： 移除有误的代码，希望问题随之消失。
让开发人员从实际运维中获得反馈
轮换安排 DevOps 团队成员承担运维职责，让他们处理实际发生的运维事件。这样，价值流中的每个人都能切身了解下游工作中心面临的挑战和职责。安排开发人员、测试人员、架构师、设计师、经理和主管承担非计划内运维值班，让他们在凌晨 3 点接到事件告警电话。这会让价值流中的每个人切实了解，日常工作中作出的决定会带来怎样的后果。
这样的轮换有助于运维专家不再感到孤立无援。DevOps 团队的每个人都能协助在修复生产事件、减少技术债务和开发新功能之间取得恰当的平衡。显然，当架构师和开发人员凌晨 3 点被叫醒时，事件会比以往更快得到解决。
当开发人员受邀观察客户如何使用软件时，他们经常会恍然大悟，发现应该立即改进的地方。架构师、设计师、开发人员和测试人员在内部观察软件工程生命周期中的下游工作中心时，也会有类似收获。一旦明白自己的工作对下游工作中心的影响，他们就能从新的角度改进工作质量和完善成果，帮助下游工作中心取得更好的表现。DevOps 团队的每个人都开始把非功能性运维需求纳入日常工作和待办列表。只有在 DevOps 组织中建立快速、持续的反馈循环，才能做到这一点。
让开发人员运维自己的系统
真实生产系统中获得的经验很难传递给开发团队。因此，Google 等一些领先的 DevOps 组织让开发团队在产品首次发布期间及发布后负责软件运维。产品由开发人员管理时，运维工程师担任顾问。在证明产品在生产环境中已充分稳定约 6 个月后，才移交给运维团队。只有当生产中的产品通过一系列检查，才能完成移交，例如检查过去和当前的缺陷、遥测覆盖范围、非工作时间事件、松耦合架构设计，以及变更和部署安全性。
如果产品在由运维团队管理期间暴露出此前未发现的重大设计和编码问题，可以移交回开发人员。在由开发人员管理的阶段，他们负责使软件恢复稳定，运维工程师则担任顾问。
总结
本章介绍了多种方法，用来确保 DevOps 组织的部署流水线顺利且更安全地运行。
这些方法体现了 DevOps 团队中开发人员与运维工程师相互尊重、密切协作的典范。
