• 手动执行应用功能的测试，没有对不同部署环境进行测试• 长时间的手动验收测试周期
• 带有唯一识别码的日志• 通过持续部署的方式发布版本• 有故障处理预案• 关键应用有健康检查状态API• 使用自动化运维工具处理运维任务• 整理分析关键线上功能使用数据
• 集成化需求• 自成研发体系• 自主进化的持续集成和持续交付流水线• 配置中心和CICD集成• 智能自动化
• 基于日志实现服务链路追踪• 完备的部署方式，方便回退• 通过脚本通过预案处理故障并记录分享• 所有应用都有健康检查状态API• 使用自动化运维平台处理运维任务• 建立所有应用使用情况指标收集分析流程
• DevOps是长期存在的稳定团队，责任明确• 自动化的绩效机制• 为团队定期组织培训• 每个团队会各自跟踪划外的工作任务backlog， 有计划和计• 团队成员可基于项目目标与上下游沟通 • 可量化的流程控制，识别低效和瓶颈
• 被组织的需求• 遵从研发理论方法• 使用源代码管理工具，手动和脚本相结合的构建• 结合脚本配置管理• 基于脚本的自动化
专家
• 临时组成DevOps团队，后期解散• 结果过程相结合的团队绩效机制• 部分成员自己寻找培训• 工作任务有跟踪，单一入口• 团队成员对业务成果有总体了解，并不了解整体的组织目标• 部分进行共同决策和问责
• 被记录的需求• 凭借经验研发• 没有源代码管理规范和工具，专门的，手动的构建• 手工配置管理• 无自动化
• 可跟踪性需求• 善于过程控制• 集成源代码管理和团队协同，分析构建流程，洞察构建效率，开展集成测试• 采用配置中心• 自动化框架与平台无缝集成
• 完善的自动的分布式服务链路追踪• 自动化的灰度滚动更新，可随时回退• 自动预防故障，隔离故障域• 尝试自动恢复异常应用，无法恢复就及时报警• 使用AIOps智能处理运维常见任务• 根据线上功能使用数据指导新需求的提出
• 开发和运维独立，极少协作• 完全结果导向的团队绩效机制• 团队成员避免培训• 工作任务很少跟踪，多入口• 团队成员只了解自己的工作• 需要专门的沟通和协调
• 基础设施代码化• 基于容器的微服务架构或无服务架构• 设计考虑到业务功能、运维功能、运营功能• 环境齐全，手工维护
产品架构和设计
• 基础设施具备多层次的自动扩展能力• 无状态的，相互独立的应用，服务• 设计考虑到业务功能、运维功能、运营功能、自我演进、业界参考设计• 环境齐全，智能维护
测试和验收
高级
AWS DevOps 能力成熟度模型
中等
• 基础设施自动化和手工混合模式• 采用SOA架构模式• 设计考虑到业务功能、运维功能• 有开发、测试、集成、生产环境
• 已建立标准的代码风格和代码复杂度要求，单元测试覆盖率超过80％。• 通过持续集成定时运行单元测试、集成测试、性能测试• 实现关键业务的完全自动化集成测试
• 实现持续发布• 新代码自动触发流水线实现从静态代码扫描到自动化测试完成的端到端的功能验证• 利用混沌测试验证持续的可靠性和自愈能力
• DevOps是全栈团队• 自管理的绩效机制• 团队成员都是持续的学习者• 所有团队跟踪同一个共享的backlog，有计划内和计划外的任务• 团队成员是跨职能授权团队的一员• 有效的知识共享和个人授权
• 基础设施具备自动扩展能力• 松耦合的服务流• 设计考虑到业务功能、运维功能、运营功能、自我演进• 环境齐全，自动维护
• 对代码风格、复杂度和单元测试盖率有一定要求• 使用脚本生成测试环境并通过持续集成运行自动化测试• 实现部分自动化集成测试
基础
• 基础设施手工操作为主• 单体式应用程序架构• 设计只考虑业务功能• 有开发、测试、生产环境
• 基础架构或应用功能的测试，是由一个单独的测试团队，根据测试文档手动完整执行• 有准生产环境做手动集成测试• 部分功能实现自动化测试
管理实践和工程实践
• 中心化管理的服务日志• 用脚本化的方式发布版本• 手动处理故障• 关键应用有报警机制• 使用简单脚本处理运维任务• 具备基础的线上功能使用数据收集
运维和运营
• DevOps独占开发资源，共享运维资源• 结果过程相结合的个人绩效机制• 团队成员需要培训• 每个团队各自跟踪 backlog，无计划外任务• 团队成员了解业务成果和整体组织目标• 共同决策和问责
文化和团队
初级
• 零散的服务日志• 手动发布版本• 没有故障管理• 没有报警需要的监控度量机制• 手动处理运维任务• 缺失线上功能使用数据收集
• 结构化需求• 熟练运用研发方法• 源代码分支管理和提交标记，每次代码提交进行构建，至少每日进行集成• 使用配置管理工具的配置管理• 基于工具的自动化
