前几天偶然间看到阿里巴巴在高薪招聘DevOps工程师：
那么，什么是DevOps工程师呢，如何才能成为一个成功的DevOps工程师呢?
首先，我们来看一下DevOps是什么。
DevOps一词的来自于Development和Operations的组合，其概念早先升温于2009年的欧洲，因传统模式的运维之痛而生。
DevOps是为了填补开发端和运维端之间的信息鸿沟，从而改善团队之间的协作关系。不过需要澄清的一点是，从开发到运维，中间还有测试环节。DevOps其实包含了三个部分：开发、测试和**IT运维**。
DevOps突出重视软件开发人员和运维人员的沟通合作，通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。
换句话说，DevOps希望做到的是软件产品交付过程中IT工具链的打通，使得各个团队减少时间损耗，更加高效地协同工作。
DevOps的好处
DevOps的一个巨大好处就是可以高效交付，这也正好是它的初衷。Puppet与 DevOps研究与评估(以下简称 DORA)协会主办的2016年DevOps调查报告中，根据全球4600位各IT公司的技术工作者的提交数据统计得出结论：高效公司平均每年可以完成1460次部署。与低效组织相比，高效组织的部署频繁200倍，产品投入使用速度快2555倍，服务恢复速度快24倍。
在工作内容的时间分配上，低效者要多花22%的时间用在为规划好或者重复工作上，而高效者却可以多花29%的时间用在新的工作上。所以这里的高效不仅仅指公司产出的效率提高，还指员工的工作质量得到提升。
DevOps另外一个好处就是会改善公司组织文化、提高员工的参与感。员工们变得更高效，也更有满足和成就感;调查显示高效员工的雇员净推荐值(eNPS:employee Net Promoter Score)更高，即对公司更加认同。
对于工程师而言，他们也是DevOps的受益者。微软资深工程师Scott Hanselman说过“对于开发者而言，最有力的工具就是自动化工具”(The most powerful tool we have as developers is automation)。工具链的打通使得开发者们在交付软件时可以完成生产环境的构建、测试和运行;正如Amazon的VP兼CTO Werner Vogels那句让人印象深刻的话：“谁开发谁运行”。(You build it, you run it)
DevOps的现状
目前在国外，互联网巨头如Google、Facebook、Amazon、LinkedIn、Netflix、Airbnb，传统软件公司如Adobe、IBM、Microsoft、SAP等，亦或是网络业务非核心企业如苹果、沃尔玛、索尼影视娱乐、星巴克等都在采用DevOps或提供相关支持产品。
其实DevOps早在九年前就有人提出来，但是，这两年才开始受到越来越多的企业重视和实践。DORA 发布的最新《DevOps现状调查报告(State of DevOps)》发现，最近几年 DevOps团队的人员规模都保持着持续上涨。三年之前，只有 16%的受访者身为 DevOps团队成员，但如今这一比例几乎翻了一番(达到 27%)。
根据国外一项调查表明，在2016年，74%的受访者已经接受了DevOps，而2015年这一比例为66%;另外，在大企业中已经有81%开始接受DevOps：
为什么DevOps近两年才得以重视?
因为DevOps的发展是独木不成林的，而现在有越来越多的技术支撑。微服务架构理念、容器技术使得DevOps的实施变得更加容易，计算能力提升和云环境的发展使得快速开发的产品可以立刻获得更广泛的使用。技术的发展使得DevOps有了更多的配合。
早期时，大家虽然意识到了这个问题的，但是苦于当时没有完善丰富的技术工具，是一种“理想很丰满，但是现实很骨感”的情况。DevOps的实现可以基于新兴的容器技术，也可以在自动化运维工具Puppet、SaltStack、Ansible之后的延伸，还可以构建在传统的Cloud Foundry、OpenShift等PaaS厂商之上。
事实上，DevOps正在成为 IT行业的新标准，并且已经被业界广泛采纳，常见于云计算和容器技术。
同时，许多组织正尽力去理解 DevOps的全貌，这主要受限于他们专业知识上的缺乏和各种组织结构上的挑战。尽管面临这些挑战，DevOps还是渐渐成为一个主流运动，各个公司已经注意到DevOps加速发布的无限价值潜力：谁创新速度最快，谁频繁更新…谁就可能打通创新的任督二脉。DevOps正在改变着 IT组织发布软件的方式，这就像敏捷运动在过去十多年中所产生的影响。
DevOps工程师
现在，我们可以来看一下什么是DevOps工程师了。
采用DevOps的主要意图是在开发和运营团队之间建立更好的工作关系。有些建议是将团队安排在一起，将他们包含在彼此的流程和工作流程中，甚至创建一个能够完成任务的跨职能团队。不过在这种方式中，Dev仍然是Dev，Ops仍然是Ops。
DevOps工程师一词试图将Dev与Ops之间的差距模糊起来，并表示最好的方法是请一些可以搞定Dev角色以及处理所有Ops职能的工程师。简而言之，DevOps工程师可以是开发，主要是他们能通过运营的心态思考问题并具有以下技能：
1. 熟练使用各种操作和自动化工具的经验;
2. 强大的脚本能力;
3. 在频繁测试和增量的时候从容不迫;
4. 了解Ops问题的来龙去脉，能在源头杜绝问题扩散;
5. 技能和逻辑相对开发更全面，让团队更好的协作。
亚马逊CTO Werner Vogels认为：
把运营的责任和职能放在开发身上，从客户和技术的角度，大大提高了服务质量和包容度。传统模式只是把包带到部门墙就甩手不管了。我认为最好的方式是谁建立，谁运行……开发接触到运营，也带来了与客户的日常联系。这个客户反馈循环对于提高服务质量非常重要。
Dev迁移到DevOps角色比以往任何时候都容易。交付自动化日益改善，DevOps平台通过最少的脚本轻松就能实现自动化。
Ops工程师能否迁移到DevOps角色?当然!但相对开发可能挑战更大一些，因为转换之前，严谨的编码技巧也得学习学习。不过编码启动阵营的变化，这可能相比几年前更容易过渡一些。
开门见山，成为DevOps工程师的关键是关注以下几点。
1、零触摸式的自动化
你应该深刻了解下自动化，诸如基础设施配置，CI/CD管道，发布管理，安全补丁甚至客户反馈等所有内容的想法……这些可以让组织创新脚步更快：免去手工切换，并在引入后立即追踪并修复错误。
在这里就可以开始适度增加版本更新周期并获得客户的快速反馈，从而帮助您更快地改善产品和响应市场需求。这步可以带着你一直走向DevOps的最终涅磐。
DevOps交付管道的完全自动化，多去找找相关开源方案学习精髓之处吧，本文没什么捷径提供。
2、宽容度高的行动心态
开发在设计软件时多走一步，考虑一些常见的操作陷阱。这个环节如果开发环节就能注意到，那就非常好了，而不是遇到问题，然后才修复。
尝试通过创建一个作为设计评估模板一部分的清单来标准化这类过程。Microsoft有部分团队就总结了一些清单，其中考虑了部署和基础架构的要求。
坚信团结的力量。鼓励通过团建，跨团体游戏之类的形式相互认识。长久以往，可能会发现Slack渠道的沟通也不那么麻烦了，对每个人都开放包容，有助于更好地理解和对交叉团队的问题感同身受。
如何衡量DevOps的成功?
最终，您所有的努力都要转化为更快创新的业务目标。
DevOps策略成功的一些关键指标如下。
部署频率——部署到生产要多久?通过自动化，你可以随着每一个变化的生产进行持续部署。这是一个到达过程，每天至少一次作为目标并没有什么不妥。
代码更改的交付时间——将代码更改部署到生产中需要多久?这将衡量自动化管道的效率。目标：建议是不到30分钟，最好再结合自己实际情况调整。
回滚率——出错回滚频繁吗?这很可能意味着自动化流程需要改进，因为DevOps的整个目标是创建可预测且无错误的版本。如果回滚率高，那至少得提高回滚速度。这个是快速恢复的一个基本能力，把对业务的影响降到最低。
写在最后
真正意义上的DevOps工程师难找，这块目前为止还是个不断发展的领域。说得讽刺些，许多为这些角色做背书的公司也并不知道DevOps具体是怎么回事。所以万一你被聘成了DevOps工程师，那你就得用这个聘请理由驱动手头的事情做出改变，说的大白话一些，你得让DevOps落地跑起来。
了解更多关于**IT运营管理**方面的内容或者工具，欢迎大家前往Service Hot进行了解。
