持续交付之应用标准化模型与实践

有标准化的自动化是平台，无标准化的自动化是工具！

标准化在多个场合的交流中，始终是大家关注的焦点，无非就是What/Why/How之类的问题。当然脱离标准化，自动化是否可以运行？答案不能否定，但这样的自动化成本和代价必须要更高。因为这样，意味着每一次应用的接入都需要重新Review之前的自动化实现。其实我们不妨可以想象一下：

我们提倡标准化的核心就是基于打破职能和产品的边界差异，实现规则的统一。我记得【持续交付：发布可靠软件的系统方法】中讲到反模式，都是破坏Dev/Test/Prod环境之间的一致性（Parity）。因此基于一个标准化的自动化持续交付过程是实现环境一致性的必要条件。由此我也想到Docker所讲的不可变基础设施，其实核心的目标也是讲如何基于不可变（Immutable）来确保环境一致性。殊途同归！

过去我在不同的公司也实现过标准化，但始终没有把他系统化和理论化的总结。借助这次平台落地的机会，我们对应用标准化进行系统化的整理，并付诸实践。

优维EasyOps总结的应用标准化模型叫EasyXY模型，模型大体思路如下：

其中横向为要标准化的实体，这个标准化的实体可以基于应用的某个OS内技术栈来进行梳理，比如说从操作系统到基础环境到中间件再到上层的应用，这是标准化的Y轴。然后在基于实体要进行的标准化属性进行识别，我们称之为X轴。最终形成如下的二维象限：

基于如上的标准化属性的划分和识别，同时需要建立相应的标准化规则，否则这些属性在使用过程中依然会混乱不堪。最终构建的规则如下：

这些规则非常重要，有些规则和Heroku的12factor是相对应的，比如说代码和配置、实体与数据隔离等规则等等。为什么要建立这样的规则？只有有效的隔离，方能做到环境的快速部署和切换。

其实从一个应用的代码包交付过程来说，无非就是其环境的交付、外部依赖的交付（运行时环境、公共库、容器等等）以及应用程序包的交付。形如：

这样的分解非常重要，实现应用交付过程的解耦，让上次的自动化过程任意的组合，实现弹性应用交付。

对于每一个层次，我们又详细的定义了其标准化的执行细则，就拿业务层的标准化来说，如下图：

接下来在系统层面上要实现应用的整个应用的标准化交付管理，核心就是基于这些资源的标准化管理。

在这个应用为中心的界面中，实现了其资源的管理、关联工具和流程的管理（动作管理）。另外我们还建议这个持续交付能力端不断往持续集成（Dev）和持续测试（Test）方向去走，打造真正的持续交付链。在每次持续构建完成之后，自动触发程序包（持续集成的后置任务）上传到持续部署流程中来，如下图：

基于标准化实现端到端的持续交付链之后，达到的收益非常明显。这套标准化和自动化平台落地之后，全环境部署效率提升224倍，应用部署升级效率提升120倍，关键是因为人为部署导致故障的产生大大降低，这个数据和2015年DevOps Report给出来的数据是类似的【效率提高200倍，故障恢复效率提升168倍】，原文如下：

High-performing IT organizations experience 60 times fewer failures and recover from failure 168 times faster than their lower-performing peers. They also deploy 30 times more frequently with 200 times shorter lead times。

本篇来源于优维EasyOps平台在一个实际客户落地实施后的经验总结。