认识达内从这里开始

我们都知道，一个人对一个产品的认知程度决定了他对这个产品的喜好以及使用频率等等，而大多数的用户对产品的认识都是比较片面的。

今天，我们就通过对案例的分析来给大家简单介绍一下如何才能正确的认识DevOps，下面我们就开始今天的主要内容吧。

1、误区一

第一个常见的误区：DevOps只适合于初创型的互联网公司，这也是很多人经常会表达的一个观点。

DevOps实践确实是被那些互联网独角兽公司所倡导，包括优秀的公司比如谷歌、亚马逊、Netflix、Etsy，这些公司都在倡导DevOps相关的方法实践，虽然也许他们不把它称为DevOps。

实际上，这些公司并不是生来如此的，每个公司成长过程都是一样的，都会经历很多问题、坎坷，也经历过IT跟不上业务的发展导致业务停滞的风险。

我们把他们叫做独角兽公司，因为在神话里独角兽是一种长着犄角和翅膀的白马，这些公司都是从普通的”马驹”公司进化成了独角兽公司，他们也会遇到传统公司所碰到的问题，包括高危代码导致的灾难性的失败、不能快速发布功能、不能应对市场上竞争的变化、不能扩大规模，以及开发和运维相互对立而不能相互信任等。

但是这些公司采用了一些比较好的方法和实践，促进他们成功完成了转变。这里我收集了一些资料，这些公司都或多或少都进行了很多架构上的、技术实践上的，以及文化的转型。

-亚马逊在2001年时，他们那时的系统叫做奥比杜斯，奥比杜斯是亚马逊流域下游一个很有名的城市，他们这个的系统就以此命名。这个系统是一个很大的单体应用，面临很多系统的问题。2002年的转型大家都非常熟悉了，他们CTO说我们必须要转成SOA的架构，所有不按这个原则工作的人都要被fire掉，他们通过强力的转型，开启了SOA架构的路线。现在亚马逊被认为是在技术领域非常成功的公司，因为他在很久之前就开始做这些技术转型的工作。

-2009年推特也遇到了很复杂的情况，他们把前端巨石架构的RubyonRails系统花了一年多时间做重构。

-Etsy是手工艺制品销售网站，为了提升工程能力，公司在2009年花很大的代价，用两年时间去解耦原来一个叫做Sprouter的系统。这个案例我们在第二期会进行详细分析。

-Facebook经历了快速成长后，在2009年运维已经接近崩溃，无法跟上用户的增长，到处救火，于是开始进行技术和文化上的变革。

-2011年领英在IPO之后同样面临了很大的困境，技术已经无法完全跟上业务和用户的发展，他们做了一个决策，整整两个月时间，不做任何新功能的开发，而是去解决环境部署和技术架构的技术债。

类似的案例其实非常多，可以说这些成功的公司背后都经历了很多也许不为人知的努力，他们因为改变了技术架构、技术实践，改变了文化的氛围，才有可能不断走向成功。DevOps不仅是初创公司可以使用，它其实是一种普适技术，所有类型的公司都可以采用DevOps的方法和实践帮助取得比较好的成果，后面会逐步看到这些方法和技术实践是什么。以上是第一个误区。

2、误区二

第二个误区，DevOpsReplacesAgile，有些人认为是不是DevOps就会替换掉Agile。

正确的说法应该是DevOps的方法和实践是与敏捷相适应的，我们认为DevOps是敏捷之旅的一种逻辑延伸。

敏捷是DevOps的使能者，因为做了敏捷，具备小团队快速发布和持续交付的能力，才能进一步做好DevOps。

但是DevOps实际上是在超越敏捷的，大家读过《敏捷宣言》，有一句是”可工作的软件大于面面俱到的文档”，每个迭代结束之后它会得到一个潜在可交付的版本，但是我们认为DevOps已经在超越这个目标，把目标扩展为”让代码一直处于可部署的状态”。

通过每日频繁的签入代码到主干上，经过一系列的构建、自动化测试，能够很快在类生产环境甚至生产环境看到这次变更所带来的影响。DevOps不是替换敏捷，而是敏捷之旅的延伸，把目标做进一步的扩展。

3、误区三

第三个误区，DevOps与ITIL不兼容，这可能是很多做运维的朋友最大的困惑。1989年提出的ITIL是非常经典的方法论，影响了一代又一代运维实践者。

有很多世界级IT运维流程横跨整个服务的策略、设计和支持等很多方面，但是我们认为DevOps的实践实际上可以与ITIL流程做兼容。具体有三个方面：

第一，为了支持更短的前置周期和更高的部署效率，很多ITIL流程需要自动化，通过自动化的方式提升效率。

第二，为了解决配置和发布管理流程方面的一些问题，我们强调DevOps需要保持配置管理数据库以及软件库的及时更新。

第三，DevOps需要快速探测和恢复故障，在这个背景之下ITIL里关于服务的设计、事故、问题管理的这些流程其实是仍然适用的。

ITIL与DevOps其实是可以兼容的，之前有一个文档《企业级DevOps成功之路》，里面谈到DevOps里有很多组成部分，包括敏捷、持续交付、精益，还有轻量级的ITSM，如何把ITIL流程做效率上的优化，与DevOps频繁发布变更的模式相匹配等，所以我们认为本质上二者是可以兼容的。

4、误区四

第四个误区，DevOps和信息安全、合规性之间不兼容。

很多人觉得DevOps缺乏传统的控制方式，比如职责隔离，不同人有不同权限、做不同事情，DevOps讲究跨界，鼓励开发人员自服务的方式做环境申请、部署和发布。

又比如说传统的控制方式有很严格的变更审批的流程，以及在整个项目末尾人工进行非常完善的安全review的活动。

DevOps没有这些活动，但是不代表没有安全控制，反过来，很多做DevOps的公司的安全性、合规性甚至会超过原来传统控制方式的公司。因为DevOps其实是把原来项目末尾做的安全和合规性的检查注入到了每个阶段，变成日常工作的一部分。

我们经常说在DevOps里是没有单独的测试阶段的，但是它把测试已经融入到每个阶段，测试在DevOps场景里是每个阶段都要做的实践，而不是一个单独的阶段。没有传统的控制方式，并不意味着DevOps没有安全和合规性的要求，反而它会更强。

DevOps

5、误区五

第五个误区，DevOps没有Ops或者说排斥了IT运营。

诚然在DevOps场景里IT运营或者运维的职责会发生一些变化，但是这种角色仍然是非常重要的。

我们的运维更早的会介入到软件生命周期里，可能会与开发一起工作。反过来，开发也会在代码部署到生产之后，与运维一起去持续工作。变化是我们更强调自动化，通过自动化替代原来手工处理工单的一些工作。

运维最大的变化是通过一系列自服务平台的创建和开发，能够把自己原来基于人工的环境的建设、维护、发布、部署等等这些能力赋能给开发，通过赋能给开发的方式，提升流程生产效率。

从这个角度讲，IT运营或运维其实更像是一种开发，开发的产品是一个平台，让开发人员可以快速、安全、可靠的用这个平台去完成经常操作的场景，比如部署、环境分配等。从这个角度讲，并不是说没有运营或运维，反过来运维的职能会有些变化，更强调赋能给开发，提升自服务能力。

6、误区六

第六个误区，DevOps仅仅是基础设施即代码。

因为很多人在谈DevOps强调的是自动化，强调的是Puppet、Chef、Ansible这种工具，我们认为这远远不够。

很多DevOps模式确实需要自动化，但是那些成功的公司不仅仅有技术范畴的改进，更有公司组织结构的调整、文化氛围的调整，让整个共享目标在IT的价值流里快速交付，这已经远远超出了自动化的范畴。

这里有一句很经典的话：”DevOps不仅是自动化，就像天文学不仅是望远镜那样”。我们要超越技术的范畴去看更广阔的改进空间。

7、误区七

第七个误区，DevOps只为开源软件服务。

很多成功的故事都是用LAMP技术栈，比如Linux、Apache、MySQL、PHP，但是这些其实与取得DevOps的成果是无关的，我们看到很多成功案例可以用微软.Net、大型机系统、SAP软件，或者是一些嵌入式软件等，都可以做DevOps转型，在《DevOpsHandbook》这本书里也提到很多，包括ATM机这种复杂的嵌入式的系统也可以做DevOps转型。

作者：张乐

公众号：DevOps时代

【免责声明】：本内容转载于网络，转载目的在于传递最新信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。