DevOps最佳实践的九大支柱
DevOps的领导力实践
- 领导者表现出对组织方向和团队方向的长期愿景。
- 领导者通过鼓励他们提出新问题并质疑有关工作的基本假设，从智力上激励团队。
- 领导者提供鼓舞人心的沟通，激发加入团队的自豪感，对团队说积极的话，激发激情和动力，并鼓励人们看到变革带来机遇。
- 领导者通过在行动前考虑他人的个人感受，考虑他人的个人需求并关心个人的利益来表示支持。
- 领导者通过表彰团队做得比平均水平更好的工作，表扬工作质量的提高，并称赞个人的出色工作，从而提高个人知名度。
DevOps的协作文化实践
- 这种文化鼓励跨职能的协作和共同的责任，并避免开发，运营和质量保证之间的孤岛。
- 这种文化鼓励从部门之间的失败和合作中学习。
- 在适当的情况下，使用协作工具（例如Slack，HipChat，Yammer）在端到端跨职能团队之间进行顺畅的沟通。
- DevOps系统由一个专家团队创建，并由包括Dev，Ops和QA在内的利益相关者联盟进行审核。
- 端到端DevOps工作流程的更改由一个专家团队领导，并由包括Dev，Ops和QA在内的利益相关者联盟进行审核。
- DevOps系统更改遵循分阶段进行的过程，以确保更改不会干扰当前的DevOps操作。实施阶段的示例包括：测试环境中的概念验证（POC）阶段，有限的生产和部署到所有实时环境中。
- 整个团队设置并监视关键性能指标（KPI），以始终验证端到端DevOps管道的性能。KPI包括部署新变更的时间，交付频率以及变更未能通过DevOps管道中任何阶段的测试的次数。
DevOps的针对DevOps的设计实践
- 产品的架构可支持模块化的独立包装，测试和发布。换句话说，产品本身被划分为模块，模块之间的依赖性最小。这样，可以构建，测试和发布模块，而无需一次全部构建，测试和发布整个产品。
- 应用程序被设计为模块化，不可更改的微服务，可以根据12要素应用程序的宗旨，而不是整体，可变的架构，随时准备在云基础架构中进行部署。
- 在提交到集成分支之前，使用静态分析工具预先检查软件源代码的更改。静态分析工具用于确保修改后的源代码不会引起严重的软件故障，例如内存泄漏，未初始化的变量和数组边界问题。
- 在提交到Integration / trunk分支之前，使用对等代码审阅对软件代码更改进行预检查。
- 在提交给Integration / trunk分支之前，将使用动态分析测试对软件代码更改进行预检查，以确保软件性能不会降低。
- 将软件更改与最新的集成分支版本一起集成在专用环境中，并在将软件更改提交到集成/中继分支之前使用功能测试进行了测试。
- 在签入过程中使用软件开关（即功能标签或切换按钮）对软件功能进行标记，以启用选择性功能级别的测试，升级和还原。
- 在检入代码更改的同时，将自动测试用例检入到集成分支中，同时还提供了证明在飞行前测试环境中通过了测试的证据。
- 开发人员至少每天一次定期提交代码更改。
DevOps的持续集成实践
- 软件版本管理（SVM）系统用于管理所有源代码更改。（Git，Perforce，Mercurial等）
- 软件版本管理（SVM）系统用于管理构建过程中使用的所有版本的代码映像更改。（Git，Perforce，Mercurial等）
- 软件版本管理（SVM）系统用于管理在构建过程中使用的工具，基础结构配置和测试的所有版本。（Git，Perforce，Mercurial等）
- 所有生产软件更改都保存在代码的单个主干或集成分支中。
- 用于支持每个客户版本的软件版本在单独的版本分支中维护，以支持针对每个版本更新的软件。
- 每个软件提交都会自动触发代码中该提交已更改的模块所有组件的构建过程。该系统经过精心设计，因此资源始终足以执行构建。
- 一旦触发，只要构建时间检查成功，软件构建过程将完全自动化并生成构建工件。
- 自动构建过程检查包括单元测试。
- 构建资源按需可用，并且从不阻止构建。
- CI构建足够快，可以在不到一个小时的时间内完成增量构建。
- 根据更改的复杂性，构建过程和构建资源会自动按比例放大和缩小。如果需要完整构建，则CI系统会自动水平缩放以确保构建尽快完成。
DevOps的连续测试实践
- 在将开发变更集成到主干分支之前，需要在生产环境的克隆中进行飞行前测试。（注：“生产环境”是指“产品的客户配置变化”。）
- 测试软件变更所需的新的单元和功能回归测试与代码一起创建，并同时集成到主干分支中代码是。然后，新测试将用于在集成后测试代码。
- 测试脚本标准用于指导测试脚本的创建，以确保脚本执行预期的测试目的并且可维护。
- 根据特定的软件更改自动选择测试。动态地对CT进行编排，从而可以根据软件更改的复杂程度或风险来加速或完全跳过部分CT测试套件的执行。
- 根据选择的特定测试的资源要求和可用测试时间，自动缩放测试资源。
- 版本回归测试是自动化的。如果必须手动执行部分测试，则至少有85％的测试是完全自动化的，其余的则是自动辅助的。
- 发布性能测试是自动进行的，以验证没有发布不可接受的降级。
- 蓝色/绿色测试方法用于在激活活动环境之前在临时环境中验证部署。A / B测试方法与功能切换键一起使用，可以在单独的实时环境中与客户一起尝试不同版本的代码。Canary测试方法用于在选定的实时环境中尝试新的代码版本。
- 整个测试生命周期（包括预检，集成，回归，性能和发布验收测试）将在DevOps管道中自动进行编排。每个阶段的测试套件包括一组预定义的测试，可以根据预定义的标准自动选择这些测试。
DevOps的弹性基础架构实践
- 构建和测试构建所需的数据和可执行文件会自动频繁存档，并可根据需要恢复。存档包括所有发行和集成存储库。如果需要更新版本的较旧版本，则可以根据需要检索并恢复用于构建和测试该版本的环境，并且可以在短时间内（例如，几分钟到几小时）完成该过程。
- 构建和测试过程足够灵活，可以优雅地自动处理各种异常。如果某个组件的构建或测试过程无法完成，则将报告该故障组件的过程并自动安排进行分析，但其他组件的构建和测试过程将继续。如果系统可以纠正故障原因，则会自动分析并重新计划组件故障的原因；如果不是，则将其报告并暂停。
- 系统配置管理和系统清单存储并维护在配置管理数据库（CMDB）中。
- 使用可确保幂等的配置管理工具来管理和自动化基础架构更改。
- 自动化工具用于支持不变的基础架构部署。
- 人人享有平等的表现。不同团队在构建和测试过程中的用户性能体验对于所有用户都是一致的，而不受位置或其他因素的影响。有SLA和监视工具可确保所有用户的用户性能体验都是一致的。
- 提供了故障恢复机制。存在构建和测试系统故障监视，故障检测，系统以及数据监视和恢复机制。它们是自动化的，并通过模拟故障条件进行了持续验证。
- 经常测试基础架构故障模式。
- 灾难恢复过程是自动化的。
DevOps的连续监视实践
- 日志记录和主动警报系统使检测和纠正DevOps系统故障变得容易。对于大多数DevOps组件故障，都有日志和主动系统警报，并且以快速识别最高优先级问题的方式进行组织。
- 来自每个DevOps管道阶段的每个指标的快照和趋势结果（例如，构建，工件，测试）将在过程中自动计算，并且对于开发，质量保证和运营团队的每个人都是可见的。
- DevOps基础架构组件的关键性能指标（KPI）会自动收集，计算并显示给订阅它们的团队中的任何人。示例指标包括用于CI，CT和CD进程的计算资源的可用性（正常运行时间），完成构建的时间，完成测试的时间，失败的提交次数以及由于严重失败而需要还原的更改次数。
- DevOps基础架构组件的度量标准和阈值会自动收集，计算并显示给订阅它们的团队中的任何人。示例指标包括用于CI，CT和CD进程的计算资源的可用性（正常运行时间），完成构建的时间，完成测试的时间，失败的提交次数以及由于严重失败而需要还原的更改次数。
- 流程分析用于监视和改进集成，测试和发布流程。描述性的构建和测试分析可推动流程改进。
- 预测分析用于动态调整DevOps管道配置。为了分析测试结果，数据可能表明需要将更多的测试集中在故障趋势较高的区域。
DevOps的持续安全性实践
- 开发人员受权并受过培训，可以对安全性承担个人责任。
- 组织采用安全保证自动化和安全监视实践。
- 所有正在使用的信息安全平台都通过API公开了全部功能，以实现自动化功能。
- 成熟的版本控制实践和工具可用于DevOps环境中使用的所有应用程序软件，脚本，模板和蓝图。
- 采用不变的基础架构思维方式，以确保生产系统处于锁定状态。
- 安全控制是自动化的，以免妨碍DevOps的敏捷性。
- 安全工具已集成到CI / CD管道中。
- 只有经过验证的凭据的受信任用户才能访问构建或测试计算机上关键知识产权的源代码。构建和测试脚本不包含用于访问任何具有知识产权的系统的凭据。对知识产权进行了划分，使得并非所有知识产权都存在于同一档案中，并且每个档案都有不同的凭据。
DevOps的持续交付实践
- 交付和部署阶段是分开的。交付阶段位于部署管道之前。
- 将所有通过交付指标的可交付成果打包并准备使用容器进行部署。
- 可交付使用的软件包包括足够的配置和测试数据，以验证每个部署。配置管理工具用于管理配置信息。
- 一旦实现可接受的交付措施，则来自交付管道的可交付物会自动推送到部署管道。
- 根据预定指标确定部署决策。整个部署过程可能需要几个小时，但通常不到一天。
- 分阶段部署到生产环境，以便可以及早发现失败的部署并迅速隔离对客户的影响。
- 部署具有自动恢复和自我修复功能，以防部署失败。
这是什么意思
DevOps是功能强大的工具，可为使用它的组织带来许多好处。使用DevOps有效地实现性能取决于以下最佳实践。通过遵循本博客中列举的九个实践支柱，组织可以实现DevOps必须提供的性能潜力。
