专家：原理不成立，实测无明显增强

DevOps的出现有其必然性。在软件开发生命周期中，遇到了两次瓶颈。第一次瓶颈是在需求阶段和开发阶段之间，针对不断变化的需求，对软件开发者提出了高要求，后来出现了敏捷方法论，强调适应需求、快速迭代、持续交付。第二个瓶颈是在开发阶段和构建部署阶段之间，大量完成的开发任务可能阻塞在部署阶段，影响交付，于是有了DevOps。

DevOps的三大原则：

• 基础设施即代码(Infrastructure as Code) DeveOps的基础是将重复的事情使用自动化脚本或软件来实现，例如Docker(容器化)、Jenkins(持续集成)、Puppet(基础架构构建)、Vagrant(虚拟化平台)等
• 持续交付(Continuous Delivery)** 持续交付是在生产环境发布可靠的软件并交付给用户使用。而持续部署则不一定交付给用户使用。涉及到2个时间，TTR(Time to Repair)修复时间，TTM(Time To Marketing)产品上线时间。要做到高效交付可靠的软件，需要尽可能的减少这2个时间。部署可以有多种方式，比如蓝绿部署、金丝雀部署等。
• 协同工作(Culture of Collaboration)开发者和运维人员必须定期进行密切的合作。开发应该把运维角色理解成软件的另一个用户群体。协作有几个的建议：1、自动化(减少不必要的协作);2、小范围(每次修改的内容不宜过多，减少发布的风险);3、统一信息集散地(如wiki，让双方能够共享信息);4、标准化协作工具(比如jenkins)

附上DevOps的定义： DevOps(Development和Operations的组合词)是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例**。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

对自动化运维体系的需求，是随着业务的增长、对运维效率和质量的要求不断提高而产生的。

在很多初创公司和中小型企业里，运维还停留在“刀耕火种”的原始状态，这里所说的“刀”和“火”就是运维人员的远程客户端，例如SecureCRT和Windows远程桌面。

在这种工作方式下，服务器的安装、初始化，软件部署、服务发布和监控都是通过手动方式来完成的，需要运维人员登录到服务器上，一台一台去管理和维护。这种非并发的线性工作方式是制约效率的最大障碍。

同时，因为手动的操作方式过于依赖运维人员的执行顺序和操作步骤，稍有不慎即可能导致服务器配置不一致，也就是同一组服务器的配置上出现差异。有时候，这种差异是很难直接检查出来的，例如在一个负载均衡组里面个别服务器的异常就很难发现。

随着业务的发展，服务器数量越来越多，运维人员开始转向使用脚本和批量管理工具。脚本和批量管理工具与“刀耕火种”的工作方式相比，确实提升了效率和工程质量。

但这个方式仍然有很多问题。

• 第一是脚本的非标准化的问题。不同运维人员写的脚本在所用的编程语言、编码风格和健壮性方面存在巨大差异，同时这些脚本的版本管理也是一个挑战。
• 第二是脚本的传承问题，人员的离职和工作交接，都会导致脚本无法很好地在运维人员之间传承和再利用，因为下一个运维人员可能无法理解和修改前一个运维人员编写的脚本功能。
• 第三是批量管理工具的选择。不同的管理人员选择不同的批量管理工具必然会带来管理混乱的问题，也无法很好地实现在运维人员之间互相备份工作的需求。

因此，对构建自动化运维体系的要求变得越来越迫切。通过自动化运维体系来实现标准化和提高工程效率，是唯一正确的选择。那么如何建设自动化运维体系呢?

本案例研究分为三个大的方面：

• 第一个是为什么要建设自动化运维体系，就是解决“3W”中的Why和What的问题，即为什么和是什么。
• 第二个是介绍我司各个运维子系统是怎样设计、运行和处理问题的，解决“3W”中的How的问题，也就是怎样去做的。
• 第三个是对我司在自动化运维过程中遇到的一些问题的思考，做一个总结。

一、建设自动化运维体系的原因

先来看一下我们为什么要建设一个自动化运维体系。首先来看运维遇到的一些挑战，如下图所示。

（编辑：淮安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!