DevOps 能力模型、演进及案例剖析(2)

Dev和Ops是实践性的工作,因此即便不是一名DevOps,或许你也在做着Dev或者Ops的工作.只是这不是真正的DevOps.让我们看两个场景：

1. Dev的风格是力求用Python/Ruby这类通用编程语言整合一堆的API,实现一套大系统,搞定一切Ops的工作；他们每天的工作就是在找Libs和看各种API的文档,满脑子设计思想.这种思维是Dev思维；
2. Ops的风格是力求从命令行的角度,甚至脚本都不用,一行一行的把命令敲下去完成工作；或者快速的写一个一次性脚本搞定；他们还喜欢自己编译各种系统,满世界下源码包,喜欢自己搞几个参数优化一下；他们只关心当下的结果,不关心以后的重复利用和持续集成.

这是我以前的工作中遇到的真实情况.

现在情况变了,自从Dev和Ops弄在一起变成DevOps后,又出现了几个自动化工具,搞的现在Dev不好好写代码了,Ops也不好好的写命令行,都去学习自动化工具去了.

这不是DevOps的王道.这是错误的.

即便把所有的自动化工具,不管是Ansible还是Puppet或者其他学的再熟,也只是学会了一个工具而已,很可能DevOps没当成,却变成工具的奴隶.

DevOps是先有思想,而后有工具.

现在崇尚工具的思路是非常可怕的,很多初学者误以为学会了这些自动化工具就可以把运维做好,而忽视基本功的学习,空学工具,只重其招,不重其义.

下面分享下两者的演进.

Ops的演进

案例1：以在RedHat上安装Nginx为例子,网上很多文章的步骤大概如下：

• PCRE库的安装：wget,tar,configure,make,make install
• OpenSSL库的安装,wget,make install
• nginx安装,make install

这种做法早些年是非常流行的,而且很多人对于在configure后面带的那些参数很是自得,屡试不爽.

时至今日这种方法仍然在很多初学者那里非常流行,而这种做法就是严重的反DevOps的做法.

案例2：以给Nginx增加一个虚拟站点www.devops.org为例,很多初学者一上来就打开nginx.conf开始改,这同样是严重反DevOps的.

这可能是因为一来nginx官方文档是这么改的,二来很多文章也是这么转载,或者原创这么写的.

案例3：再以网络性能优化的为例,很多Ops同学直接冲到/etc/sysctl.conf这里面疯狂的修改一通,添加了各种参数.

这仍然是反DevOps的.一来过不久以后也不知道哪些是自己改的,哪些的默认的,二来如果想用脚本批量更新也是大问题.

针对上面提到的,我认为DevOps应该是这么做的：

对于案例1：首先根据自己的系统设置好nginx的源,而设置源的方法也不是直接冲到/etc/yum.conf,而是建立一个/etc/yum.repos.d/nginx.repo文件,用于保存nginx的源信息.然后然后通过yum install nginx 安装.(如果一定非得必须特定版本,稍后讨论).

对于案例2：给Nginx添加一个虚拟站点.RPM包的结构如下

尽管这个结构不是很令人满意,但是仍然可以将就.

至少我们可以看出Redhat的潜在建议是让我们把新的站点放在conf.d下面,我建议的命名是www.devops.org.conf.

那么问题来了,如果我要暂时关闭这个站点怎么办呢?在这个结构下,我们只要把www.devops.org.conf从conf.d里移出来再reload一下就可以了……对,是移出来,不是删除.因为我们后面可能还要用.

此时www.devops.org.conf放在nginx目录下,显得有点格格不入,那么我们干脆建一个文件夹叫disabled-sites,把www.devops.org.conf放在disabled-sites下面得了,以后要是再启用该站点,就直接符号连接到conf.d下面.

再演进一步我们就有了如下的结构：

把站点放在sites-*里.available里放置所有站点的配置文件,通过符号连接到enabled目录下启用.

如果要临时关闭站点,可以删除enabled下的符号连接.这个结构就非常适合DevOps用脚本进行管理.

对于案例3：关于sysctl的修改,DevOps方法是在/etc/sysctl.d下面,按照命名规则添加一个文件,把需要添加的参数放到新文件即可.

这样一来可以方便查看自己修改了哪些,便于确认,二来可以持续集成,通过文件的形式保留自己思考的路径.

通过上面3个事例的演进,我们已经清晰的感觉到,上面三个步骤现在可以马上用脚本自动化起来.但是演进之前确实很难办到.

如果没有Ops的演进,再牛X的Dev他也无法完成自动批量管理以上的业务需求.

Dev的演进

我作为Dev的时间要比作为Ops的时间长很多.8年前从Windows转到Unix-like下,我们看下两个不同系统下,Dev的思路的差别.

写过Windows程序的人都有一个非常坚定的信念就是API,Windows系统下事无巨细都会有对应的API,尤为著名的是注册表的API,还有一个典型的是服务API(Windows Services).

你要改个啥配置,要创建一个Service都必须得用API来完成.复杂点的比如写一个端口扫描的要用到socket和多线程的API等等.这个端口扫描说来业务逻辑本身很简单,倒是程序逻辑搞的复杂的不得了.

而Unix-like的系统,沿袭着Unix的哲学其Dev的思路又是另外一套.修改配置,直接冲到文件里改,创建一个daemon/service直接写个shell脚本放到系统即可,完全不必要API.

所有的一切无论是在Dev还是Ops面前都是一目了然.前面提到的端口扫描更是直接用python/ruby/shell 直接调用nmap搞定,效率高,功能强大,稳定性和兼容性都不错.

我认为这是Dev要借鉴的,也是思想上最大的差别.

统统用API做出来的东西,一是容易让Ops一头雾水,搞不清楚,很难参与,二是有些功能实现起来要达到足够的性能,强大,稳定以及良好的兼容性是非常困难的.

nmap第一版本是1997.9发布的,历经18个年头,这样的工具我们一朝一夕是难以实现的.

关于Dev转DevOps的建议

（编辑：ASP站长网）