我们的目的是描述如何复制我们参与过的或观察到的 DevOps转型的成功经验,驳斥那些说 DevOps在某些场景里行不通的谬论。
以下是我们听说过的关于 DevOps的一些最常见的误区：
误区1: DevOps只适用于创业公司。
虽然谷歌、亚马逊、Netflix和Etsy等互联网“独角兽”公司是 DevOps的先行者,但这些公司在过去都面临过巨大的风险,而且他们所遇到的问题和传统企业相比并无二致:软件的高风险代码容易导致灾难性故障,无法快速发布新功能来击败竞争对手,存在安全合规性问题,服务无法扩容,开发和运维彼此高度不信任等。
然而,这些公司都能够适时地改变它们的架构、技术实践和文化,如今他们都创造出了惊人的 DevOps成果。正如信息安全高管 Branden Williams博士所说:“不要管 DevOps是适合独角兽还是马,只要跑得快就能抵达目的地。”
误区2: DevOps将取代敏捷。
DevOps的原则和实践与敏捷方法一致,许多人认为 DevOps是自2001年开始的敏捷之旅的合理延续。敏捷通常是 DevOps效率的保障,因为它专注于让小
团队向客户持续交付高品质的代码。
如果我们每次迭代的目标不限于“潜在可交付的代码”,而是扩展到让代码始终处于可发布状态,让开发人员每天都把代码提交到主干,并在类生产环境中做功能演示,那么许多DevOps相关的实践就会浮现。
误区3: DevOps与ITIL不兼容。
许多人认为, DevOps与1989年发布的ITIL( Information Technology
Infrastructure Library,IT基础架构库)或ITSM( IT Service Management,IT服务管理)是背道而驰的。ITIL广泛影响了好几代运维实践者,并且它依然在演进,是一个不断发展的实践体系,旨在稳定地支撑世界级的IT运维,而且横跨服务战略、设计和支持等流程和实践.
DevOps实践可以与ITIL流程兼容。然而,为了支持 DevOps所追求的更短的发布周期和更频繁的部署,ITIL流程的许多方面需要完全自动化,以解决配置和发布管理流程相关的许多问题,例如保持配置管理数据库和最终软件库是最新的。由于 DevOps需要在服务事件发生时进行快速的定位和恢复,因此这些其实还是和ITIL的服务设计、事件和问题管理方面的原则相一致。
误区4: DevOps与信息安全及合规活动不兼容。
传统控制手段(例如职责分离、变更审批流程、项目结束时的手动安全审查)的缺位,可能会令信息安全和合规审计人员感到失望。
然而,这并不意味着采用 DevOps的公司里没有有效的控制,只是它并不一定体现在项目结束时的安全和合规性活动中,而是集成到了软件开发生命周期的每一项日常工作中,因此会得到更好的质量、安全性和合规性。
误区5: DevOps意味着消除IT运维,即“ NoOps”。
许多人错误地将 DevOps解释为完全消除IT运维的职能,然而,这种情况是很少见的。虽然IT运维工作的性质可能会发生改变,但它仍然像以前一样重要。IT运维团队要在软件生命周期的早期就与开发团队开展合作。在代码部署到生产环境中后,开发团队也要继续与运维团队合作。
IT运维不只是工单驱动的手动操作,而是能够通过自助服务平台和API来提升开发人员的生产率，让他们能自助地创建开发环境、测试和部署代码、监控和显示业务运行的状态等。通过这种方式,IT运维人员变得更像是开发人员(或者QA和信息安全人员),融入到了产品开发过程中,而该产品则人员在生产中用来安全快速地测试、部署和运行IT服务的平台。
误区6: DevOps只是“基础设施即代码”或自动化。
所展示的许多 DevOps模式要自动化,但是 DevOps还需要文化规范和架构,以便在价值流中实现共同的目标。而这远远超越了自动化的范畴。DevOps最早的拥护者之一 Christopher Littl是一名技术主管,他写道:“ DevOps不仅是自动化,就像天文学不只是望远镜一样。”
误区7 DevOps仅适用于开源软件。
尽管许多 DevOps成功案例发生在使用LAMP栈Linux、Apache、MySQL、PHP)等构建软件的公司,但实现 DevOps与所使用的技术无关。在使用
Microsoft. NET、 COBOL和大型机汇编语言以及SAP甚至嵌入式系统(如惠普 LaserJet打印机固件程序)等编写应用程序的公司, DevOps也能取得成功。
DevOps咨询热线......
深圳青蓝咨询服务有限公司
电 话：0755-86950769
官 网：www.shzhchina.com
邮 箱：peixun@shzhchina. com
地 址： 深圳市南山区高新南一道06号TCL大厦B座3楼309室
深圳地铁1号线高新园站C出口