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必须提供的性能潜⼒。
参考

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。