DevOps 成功实践的五条建议

架构师 Dan Zentgraf 对成功实践 DevOps 提出了五个方面的建议，包括系统操作、环境管理、异常处理、度量和持续改进、松散耦合。

在系统操作方面，Dan 认为，不论用什么结构来理解，DevOps 交付系统是一个应用系统中所有变化的中心代理。这种集中性对所有应用运行所在环境都适用，包括生产和再生产环境。这保证应用总是在一种已知的状态下和一种配置已知的环境中运行。到达那种状态不仅仅需要对开发新功能的原则和所在框架有一个清晰的了解。它更需要对原则的应用和遵守，开发团队必须尊重一些因素才会更有效。

从环境管理角度来看，Dan 指出，允许软件系统运行的多环境总是存在。我们有生产环境，当然同时也要有一些质量保证和测试环境。这些质量保证环境是开发团队验证某一给定的变化会产生所预期的效果的地方。这些环境常常被视为仅次于生产环境，但是事实是测试环境中错误的信息会导致生产中断。这种依赖意味着开发团队必须严肃地对待这些环境。这是成功的 DevOps 交付所依赖的。

严肃对待这些环境的第一步是保证所有的环境都真正的具有代表性。确认某一质量保证环境中某一假定的配置对生产环境来说是一个好的代理，这是一项工程性工作。在这条基线建立之后，保持这种状态就会变得更加简单直接。

环境管理的第二步是保证所有的变化都通过质量保证环境得到提升，而后再进入到生产当中。因为一项应用应该被视为一个整体，所以对生产环境任何方面不经过质量保证环境的的配置变化都是不允许的。这要求我们改变自己的观点，不要再认为变化很容易或者自己所做的变化和其他的不同。除了明显的减小风险和提高可靠性的好处外，这种做法也能减少环境维护和同步的花费。这种方法意味着环境总是在一种已知的状态中运行，同时也意味着减少了管理多环境配置的重复工作。

第三条是异常处理，即使用一种统一的环境管理方法，紧急情况也会出现。在环境中异常事件应该非常的罕见。一个严重的事件经常是由外部因素导致的。平台中的供应商 Bug 或者紧急安全补丁就是很好的例子。这些不应该是由内部因素导致的变化。

处理异常情况时，我们应该把异常当做重要的事件并且应该及时矫正并反思。矫正必须着眼于环境的再同步。例如，如果标准的变化传递系统不是用来将变化适用于突发性环境，这个变化必须被加到标准的变化传递系统中。不管这个变化是如何被适用的，也必须有一个事后处理过程来解释异常发生的原因，更要要的是解释如何减小异常再次发生的机率。

在度量和持续改进方面，Dan 认为，用 DevOps 方法来传递软件变化为我们提供了充分的机会来度量和改进程序。除了标准系统的一致性外，DevOps 方法的高频率也提供了更多的数据点。各种各样的度量对象，如周期、数据包缺口和程序故障，都是常见的度量之物。这些度量不是典型的运维度量，如可用性和可用时间。相反，它们以保证可用性和可用时间为工作方针。其他好的追踪记录对象是对程序有效性和效率的度量。维护应用系统所需的工作时间、维护 DevOps 基础设施所需要的时间和向给定环境交付所需的等待时间都是很好的度量对象。

一个 DevOps 交付方法也能让应用系统拥有强大的检测仪功能。这些度量只能针对特定应用的，但是它们揭示了运行情况和用户体验反馈等等。因此，这些度量告诉我们是否应该主动比较操作环境、识别应用系统中的瓶颈或者管理容量需求。

松散耦合是最后一条建议，Dan 指出，DevOps 交付中的工具必须松散地耦合到它们被部署的环境中去。这意味着开发团队必须能够在不对整个系统进行重大分裂的条件下替换某个工具。从架构上讲，有一些方法来实现这个目的。例如，将注意力集中于那些使用网络服务 APIs 作为基本整合原理的工具就是部署运用 DevOps 工具时的流行做法。不管用什么技术方法，开发团队必须意识到改变某一工具对团队整体部署变化的能力有一定程度的影响。当开发团队想替换某一工具时，他们必须谨慎地分析所带来的影响并将它和替换所带来的好处进行权衡。

除此之外，Dan 还分析了 DevOps 的价值：敏捷开发的一般原则是开发团队应该一直以可持续的速度不断地交付软件。与此同时，基于相关的虚拟化和云计算，许多新的操作工具和基础设施已经可以为我们所用。虽然很多研发团队已经主动采取了敏捷开发的方法，但是他们开发的软件常常不能被用户接受，因为他们的程序充满了缺陷、易出错的手工任务或者和运维相关的延迟。同时，竞争日益激烈的市场环境给业务主管带来了巨大的压力，因此他们要求在更短的周期里把新软件和特性交到客户手里。敏捷开发、新运维技术和市场需求导向这三个因素正在使人们重新思考应该如何看待软件开发。这三种趋势的共性是变化的速度增加了。那种把用户所需要的软件功能搁置几个月再去开发的做法已经无法被接受了。软件只有使用的时候才有价值，快速的得到那种价值在今天的市场上显得尤为重要。这种转变使人们质疑团队开发软件的种种假设，而质疑的结果就是 DevOps 的问世。

DevOps 倡导一种软件交付的根本性变化。这么做的好处却是更加快速频繁地交付更高质量的软件。用一种结构性的方法去将应用系统视为一个统一的整体能帮助开发团队进行协调合作。那种协调合作能够通过一种系统的方法来支持，从而更加高效地交付和提高用来交付整个系统的功能。DevOps 方法支持以稳定、多周期渐进式改进为特点的敏捷开发，并且提供给开发团队持续地按用户要求交付有价值的软件所需的结构和洞察力。这才是开发部署软件的要义所在。

InfoQ 中文站的读者对 Devops 的实践有何经验要分享？欢迎发表自己的看法。