各个公司已经注意到DevOps加速发布的无限价值潜力：谁创新速度最快，谁频繁更新…谁就可能打通创新的任督二脉。
“DevOps”一词由“开发”和“操作”组合而生，根据维基百科释义：
DevOps是一个术语，用于指代一套强调软件开发人员和信息技术（IT）专业人员的协作和沟通的实践，同时自动化软件交付和基础架构更改过程。它旨在建立一个文化和环境，其中建立，测试和发布软件可以快速，频繁，可靠地发生。
无论行业如何，今天和互联网沾边的公司都面临着开发和交付两方面的巨大压力。互联网风头吹进了各行各业，改造了每一种业务的原先外在的表现，从出租车到送货再到零售。对于传统企业，除非改变业务表现形式赋予数字化属性，否则业务可能在未来几年内就会被已经数字化的企业彻底打趴。
一旦你开始这个数字转型，接下来的挑战就是要创新速度要足够快，才能生存下去并赢得胜利。这就是DevOps的存在意义。大多数公司已经在研究如何通过敏捷原则加速开发交付，然而，现在的瓶颈卡在交付上：如果不能快速交付，先优化代码吧！
DevOps通过将文化变革与端到端软件交付自动化相结合来解决这个问题，DevOps的目标是确保频繁，可预测，无错误的版本交付，协助创新。
什么是DevOps工程师？
采用DevOps的主要意图是在开发和运营团队之间建立更好的工作关系。有些建议事将团队安排在一起，将他们包含在彼此的流程和工作流程中，甚至创建一个能够完成任务的跨职能团队。不过在这种方式中，Dev仍然是Dev，Ops仍然是Ops。
DevOps工程师一词试图将Dev与Ops之间的差距模糊起来，并表示最好的方法是请一些可以搞定Dev角色以及处理所有Ops职能的工程师。简而言之，DevOps工程师可以是开发，主要是他们能通过运营的心态思考问题并具有以下技能：
熟练使用各种操作和自动化工具的经验
强大的脚本能力
在频繁测试和增量的时候从容不迫
了解Ops问题的来龙去脉，能在源头杜绝问题扩散
技能和逻辑相对开发更全面，让团队更好的协作
根据亚马逊CTO Werner Vogels：
把运营的责任和职能放在开发身上，从客户和技术的角度，大大提高了服务质量和包容度。传统模式只是把包带到部门墙就甩手不管了。我认为最好的方式是谁建立，谁运行……开发接触到运营，也带来了与客户的日常联系。这个客户反馈循环对于提高服务质量非常重要。
Dev迁移到DevOps角色比以往任何时候都容易。交付自动化日益改善，DevOps平台通过最少的脚本轻松就能实现自动化。
Ops工程师能否迁移到DevOps角色？当然，但相对开发可能挑战更大一些，因为转换之前，严谨的编码技巧也得学习学习。不过编码启动阵营的变化，这可能相比几年前更容易过渡一些。
一些重要的转变特征
开门见山，成为DevOps工程师的关键是关注以下几点。
零触摸式的自动化
你应该深刻了解下自动化，诸如基础设施配置，CI/CD管道，发布管理，安全补丁甚至客户反馈等所有内容的想法……这些可以让组织创新脚步更快：免去手工切换，并在引入后立即追踪并修复错误。
在这里就可以开始适度增加版本更新周期并获得客户的快速反馈，从而帮助您更快地改善产品和响应市场需求。这步可以带着你一直走向DevOps的最终涅磐。
DevOps交付管道的完全自动化，多去找找相关开源方案学习精髓之处吧，本文没什么捷径提供。
宽容度高的行动心态
开发在设计软件时多走一步，考虑一些常见的操作陷阱。这个环节如果开发环节就能注意到，那就非常好了，而不是遇到问题，然后才修复。
尝试通过创建一个作为设计评估模板一部分的清单来标准化这类过程。Microsoft有部分团队就总结了一些清单，其中考虑了部署和基础架构的要求。
端到端协作
坚信团结的力量。鼓励通过团建，跨团体游戏之类的形式相互认识。长久以往，可能会发现Slack渠道的沟通也不那么麻烦了，对每个人都开放包容，有助于更好地理解和对交叉团队的问题感同身受。
你如何衡量DevOps的成功？
最终，你所有的努力都要转化为更快创新的业务目标。我后面会在这主题上写一个更广泛的文章，但DevOps策略成功的一些关键指标如下。
部署频率
部署到生产要多久？通过自动化，你可以随着每一个变化的生产进行持续部署。这是一个到达过程，每天至少一次作为目标并没有什么不妥。
代码更改的交付时间
将代码更改部署到生产中需要多久？这将衡量自动化管道的效率。目标：我的建议是不到30分钟，最好再结合自己实际情况调整。
回滚率
出错回滚频繁吗？这很可能意味着自动化流程需要改进，因为DevOps的整个目标是创建可预测且无错误的版本。如果回滚率高，那至少得提高回滚速度。这个是快速恢复的一个基本能力，把对业务的影响降到最低。
真正意义上的DevOps工程师难找，这块目前为止还是个不断发展的领域。说得讽刺些，许多为这些角色做背书的公司也并不知道DevOps具体是怎么回事。所以万一你被聘成了DevOps工程师，那你就得用这个聘请理由驱动手头的事情做出改变，说的大白话一些，你得让DevOps落地跑起来。