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

鉴于以上的讨论,我给Dev即将转到DevOps的同学们的建议是：

1. 试做一个有经验的Ops,放下编程语言,从命令行开始,从Shell开始；
2. 理解操作系统的哲学,Unix-like下管道连接一切命令,文件代表一切配置；
3. 理解Ops的核心指标,比如高可用,兼容稳定,可重入,故障容灾；
4. 在坚持Ops-style的前提下,通过程序设计思想将DevOps的代码脚本的产出层次化,模块化,使之达到高复用；

Dev和Ops的另外一个区别是,以往Dev注重的是具体功能开发,而Ops天生要关注的是系统的整体管理.

功能开发注重逻辑的正确,1＋1=2；但是Ops要求业务和结果导向,有时1+1可能是无穷大,比如磁盘满了.

补充1：编程语言和Shell在DevOps的关系

从自动化部署工具来看他们的关系,Python/Ruby通过业务逻辑把产生出相关文件和Shell语句通过下面两种方式执行：

1. 基于ssh；
2. 基于Agent(姑且认为是RPC的一种方式).

因此Python/Ruby作用是：编排和启动Shell语句的作用；具体实现功能,则仍是Shell语句.

根据这种关系,我们不难发现以上两种方式存在现实的局限性：

1. 众多命令执行情况下,ssh效率不高；
2. Agent效率虽然高,但是开发和调试成本很高,另外Agent对于Ops是透明、不可控的,一线Ops在Agent出了问题后,很难介入调试.

我的建议是在shell做文章,即基于shell脚本的机制完成远端业务逻辑的工作,通过ssh或者agent调用脚本执行功能,这样提高了效率又便于Ops参与脚本的编写和调试.

结论：DevOps的落点是Ops,Python/Ruby的落点是shell和commands.

Python/Ruby的优势是业务逻辑,文件处理等,莫用Python/Ruby去实现shell和commands擅长的.

补充2：编程语言在DevOps的意义

Python/Ruby体现的重要性是程序设计的思想,shell和commands的重要性在于,系统最终由他们改变.

以前是Ops玩shell和commands,现在是DevOps通过Python/Ruby玩shell和commands,所以本质还是shell和commands.

就像互联网和传统行业一样,有互联网传统行业转的更好,但是没有互联网传统行业一样转；而如果没有传统行业,估计饭都吃不上,互联网也就不存在了.

补充3：操作系统能力模型

根据前面的结论,我认为DevOps的核心竞争是在Shell和Commands的竞争.而操作系统能力的提升也将是Shell和commands的提升.

试想如果没有yum/apt,没有sed,没有iptables,没有virsh这样的指令,我们是否寸步难行?答案当然是肯定的.

有人说,可以通过c/python/ruby实现,反正都有api,这是错误的轮子思路.

我可以肯定的说,我们几乎没有能力超越先贤们历经数十年累积的成果.即便可以我们做出来类似的东西,也很难超越这些既有的工具,这些工具优秀之处除了智慧,还有时间以及实践的检验.

但是有一件事我们是可以做的,就是把操作系统业务能力提升起来.我认为的操作系统能力模型里,唯缺此一项.

我们不需要再写一个iptables,sed,yum/apt,我们可以包装他们,通过命令的组合和逻辑的判断,衍生出专用的业务能力.

RedHat下有不少好的例子,比如service iptables save的功能.此功能的意义如下：

1. 提供了统一的调用方式,并且封装业务逻辑,便于其他脚本使用；
2. 统一的文件存放位置,便于自动加载,管理和备份；
3. 同时提供了restore的命令.

这就是一种操作系统的能力.这种能力在Linux的一些分支上是没有的,我们就必须自己编写脚本实现此功能.但是写来写去,写得最好也就是跟RedHat大同小异,但是却花了我们的宝贵的时间.

试想在拥有这种能力的RedHat上面,DevOps开发一个批量保存iptables的功能是否更容易呢?

练手：

1. 是否可以基于iptables实现一个命令,在添加一条iptables规则时,先检测是否存在同样的规则,避免重复?
2. 是否可以基于sed实现两个命令,delete_line和delete_line_by_no：第一个命令给定一个表达式和一个文件名删除含有表达式的行；第二个命令根据行号删除指定文件行?
3. 实现一个命令,安装memcached,根据传入的参数设定监听地址,内存大小和监听端口等.

（编辑：ASP站长网）