文档结构  
翻译进度:已翻译     翻译赏金:0 元 (?)    ¥ 我要打赏

哦,你认为你在实践DevOps(Development和Operation的组合)?检测你对DevOps到底有多深刻的认识和经验的时候到了!接受所有关于DevOps的炒作是很容易的,但很难找到它的缺点——这是没有人愿意公开谈论的事实。

1. DevOps对与Dev(开发)来说比起对Ops(运营)来说意义更大

DevOps源自于开发者的需求。DevOps针对项目生命周期的初期(开发/测试)对工具进行了优化。他们在提供一些简单的运营环境原型方面表现良好。但是,大部分的DevOps工具都更符合开发者的需求,而不是运营团队的需求。大部分工具都不是应对现在复杂的生产环境或大型关键应用,从零开始搭建的。就像是世界最快的短跑运动员Usain Bolt(尤塞恩·博尔特,牙买加运动员),突然被呼吁跑马拉松一样。

第 1 段(可获 2.45 积分)

2. Ops可以变得更敏捷,而不必从零开始

很多人都会抱怨IT运行手册。这我理解。这些运行手册查阅起来很慢,需要人工执行,缺乏自动化。很多人认为所有这些流程都应该扔掉,用DevOps工具来取代它们。但是你一定要想清楚,你是不是在倒洗澡水的时候把婴儿——你现有的正在运行的IT流程——顺便扔掉了(得不偿失)。这些流程是经过实战检验的。有的时候在某些场景下,我们要考虑清楚,是否运行手册和工作手册的自动化可能比DevOps更合适。

第 2 段(可获 1.09 积分)

3. DevOps 不适用于复杂的生产环境

你希望搭建一个LAMP堆栈(Linux+Apache+Mysql+php)然后运行一些集成测试吗?没有什么比DevOps能做得更好的了。

想要管理和维护一个带有使用了Master-Master复制和多个Slave的联合数据库的,6层的,基于规则的,负载均衡的应用吗?没有什么比DevOps能更快地破坏这个环境的了。

事实上,DevOps并不是唯一选择——尤其对于复杂的生产环境。开发者的需求与运营团队的需求不是总会100%重合的。

第 3 段(可获 1.14 积分)

4. 实施DevOps使情况变好之前,会先使得情况变坏

有些时候,部署DevOps的感觉像是离开了主路而转向了一条小路。DevOps工具用一种全新的方式来实现运营。它们不会使用我们一直以来耳熟能详的而且行之有效的标准IT实践。它们通过一套全新的菜谱和配方来搭建环境,而这些与传统的运行手册和工作手册交集很小。在转换的过程中总会有一些事情被遗漏。因此如果DevOps是你唯一的自动化策略,你要做好情况会变坏一阵的准备。

第 4 段(可获 1.28 积分)

5. 开源有时比不上经过实战检验的传统方式

我是开源的狂热粉丝。但同时我在内心是持反面意见的。十年前,当每个人都在支持专有软件而唱衰开源时,他们大多数都错了。开源带来的好处比起人们归功于它的更多。

十年后的今天,每个人都在唱衰专有软件,转过头来支持开源。闭源不好——开源好,就好像开源自动意味着更好一样。人们观点的钟摆摆动得太远了。不是所有的开源软件都经过实战检验,而且不是所有经过实战检验的软件都是开源的。对于IT运营来说,经过实战检验的软件经常比开源更为重要。毕竟,你会搭乘一架刚刚投入使用的飞机吗?

那么,你要怎么做呢?完全相信或者完全不信吗?最好的情况是,DevOps成为打开你的视野,让你看到硬币另一面的钥匙。在当今的IT中,采用敏捷实践(Agile Practice)能带来太多的好处,但如果你没有意识到其负面影响并为之做好准备,你可能要承担为相关人员带来乱七八糟的麻烦的责任。

第 5 段(可获 2.5 积分)

文章评论