这是devops系列的第四篇文章。
前面几篇文章，分别从devops的定义和价值、落地路线图以及落地三要素进行了分析。
这篇文章开始，我会分享devops在企业或团队中具体的落地实践以及落地过程中的一些关键动作。业内关于devops成熟度模型以及落地实践的关键能力，有不同的定义。比如信通院牵头制定的devops过程模型：
当然，一线大厂及一些软件服务咨询机构也有自己的模型。没有完全标准的模型，只有适合自己的实践。结合网上的公开资料及我自己的学习实践，我总结了如下几个比较通用的落地实践和关键能力。
版本和配置管理
这一部分可以分为两个角度来讲，但版本和配置管理又有很高的关联度。
所谓的版本管理就是从软件研发交付的整个生命周期出发，从需求到研发再到线上交付，都进行规范管理，达到信息一致可追溯，版本信息标准化。从软件工程的角度来说，每次线上交付的软件产品，都是一个完成的制品，与它相关的信息，比如需求文档、设计方案、代码分支、测试用例、bug清单等，都应该与该制品关联起来，保证交付的完整性。
配置管理则比较容易理解。版本来源于变更，每个版本都有很多不同的配置信息。而且我们所谓的线上风险线上故障，大多是由变更引起的。因此配置管理也是风险控制和质量管理的一部分。
部署和环境管理
在软件研发测试阶段，总免不了频繁的编译构建和部署，特别是业务线众多，迭代频繁的企业而言，往往具有多套环境，常规的有开发环境、测试环境、uat环境、灰度环境和生产环境。为了满足多版本并行和满足不同的技术需要，往往测试环境就能分出很多套。
以我之前就职的一家公司为例：两周一个国内版本，一周一个国外版本，国内国外版本之间业务有依赖调用关系，且同时又有很多探索创新的业务是通过独立项目来快速迭代的，这部分独立项目的发布时间和固定的版本又是重叠交错，导致了服务部署和环境资源分配经常出现冲突。
我之前写过一篇文章，专门聊过这个问题，详情见：《被忽视的问题：测试环境稳定性治理》
因此我将版本和配置管理放在了第一项，因为只有先规范好标准的版本和配置管理，才方便在软件部署时，更好的利用好不同的环境资源。但这并不代表部署和环境管理不重要，恰恰相反，部署和环境管理，可以看作是一个公司软件研发的基础能力，如果最基础的能力建设做的不好，那更上层的技术实现和高效保质交付，就很难谈起。
质量内建和门禁
很多公司将产品质量的责任推给了测试团队（或者说质量保障团队），但本质来说，测试部门更多的是通过一系列手段去验证产品是否满足预期设计和要求，尽可能发现和暴露已经存在的问题。而产品的质量，从设计阶段就开始定性，编码实现阶段定量，绝不能像前文提到的在最后一环让人用锤子去保证质量。
衡量产品价值的一个关键因素是质量，产品质量也是一个长线递增的价值维度，因此质量内建的作用就凸现了出来。
质量内建的本质，和devops的文化其实很类似，目的都是让整个团队认识到质量的重要性。从最初的需求和设计环节就关注产品质量，在研发编码阶段开始定量去多维度评估，测试团队需要做的是牵头去推动质量内建的文化，建立流程制度，设定软件产品每个流转环节的准入准出标准，做好把关，并及时的协同其他团队一起去做风险预防，以确保最终线上交付的产品是高质量的。
持续集成和交付
持续集成和持续交付可以说是软件工程领域的一个重要实践，它提倡的是频繁的将团队成员提交的代码快速的进行编译构建，并且每次集成后自动进行自动化测试的验证工作，以期尽早更快的发现问题并快速修复。
持续交付并不意味着线上发布才是交付，而是在整个软件生命周期中，每次提交、编译都进行快速的验证，在每个流转环节进行快速验证，这样可以更好的保障最终交付给用户的产品，经历了多轮高密度的验证后，质量更符合预期。
可视化和可追溯
IT或者说技术人员的很多生产研发过程是不可见的，因此可视化和可追溯成了一个很好的评估devops的视角。
可视化指的是将整个研发交付过程改善为进度明确、结果可量化、过程自动化的动作。这样做的好处在于一方面避免由于人这个个体的差异导致的信息差以及误操作风险；另一方面通过标准的可视化展示，识别过程中的低效环节，这样也更利于对低效环节进行风险识别和改善。这也是我在前文《落地DevOps的路线图》中提到过的devops落地的切入点。
通过过程可视化自动化，更直观的展示，从全局视角进行风险评估和识别，驱动结果度量和持续的改进，最终确保整个交付的过程和结果是更高效，质量更好。
持续度量和改进
持续度量的目的不是为了KPI，而是结果可量化。
一个软件产品经过需求设计评审、技术设计、代码开发、测试验证等很多环节，才能保障最终的交付。这就是一个将不确定性（需求）转化为确定性（具有严密逻辑的软件系统）的过程。确定性需要一定的衡量标准来评估它是否满足预期的设计，因此是需要一定的数据度量的。
而持续度量的原因，是业务和技术本身就处在一个不断变化发展的状态，需要持续的度量和评估，才能保障软件系统的质量长期处在一定的水准之上，满足用户需要和保障业务目标达成。度量的本质，是具体的定量，而非抽象的定性。
只有持续度量，才能发现过程中的低效环节以及存在的问题，然后持续进行改进，以保障最终的交付质量。我之前写过的质量度量相关文章，详细聊过这个话题，具体内容见：
《聊聊我对质量度量的看法》、《从TMMI角度谈谈质量度量》
风险评估和兜底
软件的设计、构建和交付都是存在风险的，而每次的变更也会引入很多可能的新的风险。因此需要引入机制和方法，通过团队配合，加上工具辅助来做好风险评估和兜底。一般可以从如下五个阶段来开展：
- 风险评估：在前期设计阶段让相关人员进行充分的风险评估，而不是等到上线阶段；
- 风险预防：在技术方案设计和代码编写阶段即考虑可能出现的风险，并做好对应的冗余措施；
- 风险验证：在测试环节尽可能的去覆盖可能出现风险的点，并进行大量快速的验证，尽快发现和改善；
- 技术债务：长期迭代的后果就是背负技术债务，而持续的小范围的优化和定时的重构，则能改善大部分技术债务；
- 可用性策略：线上业务的稳定性是最重要的，业务的稳定性依托于服务的可用性，因此可以借助如混沌工程、全链路压测等手段，不断的发现线上存在的风险，并针对性做好保障可用性的措施如：限流、降级、熔断、隔离等。
devops组织文化
devops的落地需要制定一定的流程机制，来让参与的具体人员在行动中践行这些文化，潜移默化的形成工作的行为准则。而这些行为准则组合在一起，就构成了我们宣讲的devops文化。
而devops组织的作用，则是负责文化建设 团队赋能 方向引导 创造环境。通过制定落地实施流程，形成行动和响应机制，在关键节点推动项目进度，在行动中不断践行和树立devops的工作实践准则。
总结一下，统一人员认知就是树立共同目标，组织机制流程建设就是保证团队沿着正确的道路向既定目标前进，而工具和平台则是这个前进过程的支撑和加速器。
下篇文章，我会针对本文中的几项工程实践，做更详细的介绍。
