DevOps 文字培训
如何保护 DevOps 部署流水线？
你和 DevOps 团队遵循前面学到的原则，为 IT 组织构建起有效的持续交付部署流水线后，就可以在无需外部审批的情况下进行低风险生产部署。现在，大多数生产部署都不必经过变更审批流程，因为你依靠的是合理设计的软件交付方法、自动化测试、自动化监控和环境发出的智能警报，而非单纯依赖外部审批人员。不过请记住，安全和合规仍是 DevOps 团队的重要职责。这样做既是为了满足立法机关的要求，也是为了照顾好客户。DevOps 团队当然仍需依靠组织内的安全和合规领域专家，并与他们合作。但设计安全且符合组织所处法规环境要求的系统，现在应该成为你的日常任务和习惯。
生产系统中的变更类型
- 标准变更： 风险低，无需审批。由于完全自动化且有日志记录，部署迅速。更新数据库查找表、更新内容、修改样式，以及应用操作系统、数据库或其他外部组件的标准补丁等，都属于标准变更。
- 常规变更： 风险高，需要变更咨询委员会（CAB）审批。CAB 要求提交变更请求表（RFC）以评估变更。由于委员会成员通常没有足够的知识来评估变更，前置时间较长。他们往往搁置变更，最终根据经验、直觉以及对提出变更者的偏见作出决定。
- 紧急变更： 风险高，需要高层管理人员批准。影响客户的生产系统严重错误、有问题的部署的修复、安全补丁及服务恢复等，都属于紧急变更。
无论是哪种类型的变更，你和 DevOps 团队都需要在变更管理和工作计划系统（如 Remedy 和 Jira）中记录所有变更，让团队内外的所有人都能看到相关工作。
用成功的自动化部署记录把常规变更转化为标准变更
只有提高标准变更相对于常规变更的比例，才能减少变更咨询委员会（CAB）审批，加快工作流并提高部署流水线的质量。
现在，你和 DevOps 团队可以用成功的自动化部署记录，尽可能将常规变更转化为标准变更。向 CAB 展示过去的部署记录和生产事件清单，证明自动化生产部署不会导致生产系统出现事件，或只会导致可以忽略不计的事件。
加快常规变更的部署
对仍须作为常规变更处理的事项，实现变更请求表（RFC）填写流程的自动化。将非生产系统中所有自动化和非自动化测试结果、已解决和尚未解决的事件、监控记录及日志关联到 RFC。设法简化 CAB 的工作，在 RFC 的第一个版本中就提供其需要的所有信息，尽可能加快审批。
常规变更获批后，应支持一键部署。与 CAB 定期审查常规变更的类型，识别并明确哪些条件能说服他们将常规变更转为标准变更，让 DevOps 组织的大多数变更能够自动部署。
减少 DevOps 组织的官僚程序和对他人的依赖
组织规模越大，官僚程序就越容易滋长。官僚作风会不知不觉地呈指数级增长，而且会长期存在。一旦依赖上一级权力和控制机制审批自己的工作，你就不再觉得自己有自主权，也不再觉得自己对工作成果负责。这会使上一级审批人员反复失职。
最终，该审批人员也会需要依赖另一层权力并接受其审计。这种不断恶化的循环只会延长，直到企业下一次重组。重组后，几乎有 100% 的可能出现形式略有不同的恶性循环，取代当前的循环。
企业需要记住，职责分离，以及依赖团队外部的控制机制，不仅会减慢软件交付速度、降低交付质量，还会降低组织的安全性。美国一家大型金融机构遭遇 ATM 欺诈，因为一名软件开发人员在 ATM 软件中植入了后门。外部审计人员、安全专家、合规人员和 CAB 审批人员都未能发现部署到生产系统中的欺诈性源代码。只有由开发这段代码的团队采用检查代码提交和代码评审等基本 DevOps 方法，才有可能发现这种欺诈。
为了快速、安全地交付，需要减少对他人及职责分离的依赖，因为这些做法只会妨碍 DevOps 团队承担责任。应在团队内部实施其他控制机制，如检查代码提交、结对编程、同行评审、自动化测试和监控。如果法规要求必须分离职责，DevOps 团队内置的控制仍能让审计人员和合规人员更快作出更明智的决定。
总结
DevOps 为合规和信息安全带来了新的动态环境。当基础设施以代码形式存在、系统由代码创建或销毁，且代码自动部署时，审计人员要弄清实际发生了什么并不容易。这既是新的挑战，也是建立并实施更精简、更智能的审计与合规机制，以及培养相关人员的机会。
在 DevOps 团队中，信息安全、合规以及加快部署流水线是每个人的职责。团队的一项主要目标，是让合规人员能够自助获取证明团队高质量交付所需的信息、日志、报告和指标。这些措施将简化繁琐的审批流程，甚至可以完全取消它们。
