任何一种新兴技术，有如 Gartner 技术曲线一样，都必然要经历螺旋式上升的发展轨迹，也必须符合技术生命周期的发展规律，即从概念提出、泡沫、破灭、冷静、成熟、应用兴起，再到重生与再创新。
十年磨一剑 DevOps 是时候过关斩将，突破防线
DevOps 正在广度和深度上“重塑”软件工程的技术与实践。像以往的重大软件变革一样，DevOps 的发展也必将经历一个由“野蛮生长”，到集体反思，再到知识体系构建，并进一步推动 DevOps 持续发展的成熟过程。DevOps 这个概念被提出快十年了，正所谓十年磨一剑，是时候创造性突破了。
对于企业来讲，在企业方向和研发战略上，一定要把握和尊重技术产业领域的发展规律。
DevOps 是核心理念，万物皆由此生
DevOps 现在是国内外都非常热的一个概念，很多人狭窄地理解为 DevOps 就是让研发部门去做运维的事，或者运维部门做研发的事情。但实际上 DevOps 的思想更多是要把整个开发流程的界限打通，产品深入到研发的内部，研发可以把信息快速反馈给产品，开发和运维或者 QA 和运维之间的界限也需要打通，形成“开发团队与运营团队之间更具协作性、更高效的关系”。
虽然 DevOps 正被广泛采用，但要改变某些企业领导者根深蒂固的陈旧思维及行为是不容易的。此外，DevOps 工具链目前相对还不太成熟，特别是一些针对特定任务的脚本和自动化工具。由于开始的重点是鼓励开发和运维思维方式的转变，他们现在仍需要成熟的工具，来避免手动切换和过多的自定义脚本造成的低效率。
AIOps 是 DevOps 的进化方向
近年来，人工智能技术备受关注，将 AI 引入 IT 运维领域，AIOps 的概念由此而生。据 Gartner 的报告宣称，到 2020 年，将近 50% 的企业将会在他们的业务和 IT 运维方面采用 AIOps，远远高于今天的 10%。
传统的 IT 运维需要管理大量的告警，极大地分散了企业的注意力，他们需要花很多时间解决无聊的问题，没有时间用于创新。借助智能算法的技术优势，原先人工需要几个小时完成的任务现在通过自动化可以在几秒钟内完成，而且能够得到更好的结果。
尽管 AIOps 还是一个新名词，但并不代表它只是未来的一种趋势而已。运维一步步发展到当前这个状态，根本上讲还是业务高速发展倒逼出来的，同时，从手动运维到运维自动化，再到 AIOps，这个过程根本上是在朝着如何更加高效运维的趋势在发展。
容器技术是 DevOps 必经之路
虽然 DevOps 是一个概念，但工具是实现 DevOps 的重要组成部分。近两年来如日中天的 Docker 就是实现 DevOps 最合适的工具之一。从物理机时代到第一代云，或者说 OpenStack 时代，再到现在的容器时代，一是时间成本降低了很多，二是底层越来越下降。
在以前，对于一个有上万台服务器的公司来说，升级 Firmware 是一个经常做的事情。到了 OpenStack 虚拟机时代，可以感觉到我们已经不再关心底层的 Firmware 这些东西了。而到了 Docker 时代，运维也不再关心虚拟机、虚拟网卡，以及虚拟网络的性能了。从裸机时代到 Docker 时代，我们越来越贴近应用。
最开始 IT 对业务是支撑的作用，比如生产汽车的公司需要 IT 做一个 ERP 系统。但是到了 Docker 时代，IT 和业务贴的越来越近，这是一个融合的时代，是 IT 和应用融合的过程。
设想，Docker 出现之前，你要搭建一个 DB 环境，你需要下载 DB 的软件，下载 DB 依赖的软件，编译，安装，配置，最终让服务可用。一旦中间有个步骤出错，还需从头再来，Ops 对这些操作轻车熟路，如果让一个 Dev 来做，痛苦之处可想而知。而用了 Docker 之后，你只需要 pull 一个镜像，run 一个容器，你的服务就可用了，所有的依赖，别人都在镜像里帮你做好了，这样是不是就容易多了？
换成公司自己开发的应用，不用 Docker 的话，在部署上线前也需要做同样的事，有了 Docker 之后，只需在一些开源的基础镜像上 build 出公司自己的镜像，以后的部署上线操作都只是 pull 镜像、run 容器的操作了，那么 Dev 做 Ops 的事就简单多了。
好工具还需要牛人掌控才能发挥其威力。即使找到了好用的工具，也需要有熟悉这个工具链，拥有相应技能的 IT 人员来提供技术支持，才能完成实现自动化的使命。
SRE 是 DevOps 在运维领域的最佳实践
SRE，是 Site Reliability Engineer 的简称，作为 Google 最早提出，又经由 Google 发展完善的一个崭新概念，是在运维模式上的全新探索，也是 DevOps 思想在运维方面的真正实践。SRE 代表了一套先进的、完整的运维体系， SRE 已成为一个涵盖运维理念、思路、组织架构、和具体实践的完整体系。
国外互联网企业将运维的角色职能扩展为 SRE，也就是用软件工程师的方法和手段，来解决运维的难题。实际上 SRE 试图平衡服务不可用以及产品快速创新、提高运维效率之间的风险，因此 SRE 是要保证用户满意度，平衡各方面因素，包括功能、服务以及性能。可以说 SRE 就是 DevOps 的思想在开发和运维之间的一个平衡。
技术本身不是最大的障碍，真正的挑战是大家能不能用智能商业的思路来重新审视自己所有的业务，所有的流程，甚至进行全面的改造和创新。运维要用云服务的思路去做。如果一个公司内的运维团队开发出一堆工具，让做应用开发团队可以很容易地申请机器、存储、网络、中间件、安全等资源，并很容易管理、监控和部署应用，并提供运维资询。那么，这个公司就会不经意地做出一个云计算平台来了。
ChatOps 是 DevOps 的终极目标
ChatOps 以聊天室，即沟通平台为中心，通过一系列的机器人去对接后台的各种服务，工作人员只需要在聊天窗口中与机器人对话，即可与后台服务进行交互，整个工作的展开就像是使唤一个智能助手那样简单自然。即“聊着天就把事情办了”。
目前流行的 ChatOps 聊天机器人主要有 Hubot（GitHub 的 bot，用 CoffeeScript 和 Node.js 开发）、Lita（用 Ruby 开发）和 Err（用 Python 开发）三种，都是开源软件，而且可以整合到开发团队在工作中经常会使用一些聊天工具例如 HipChat、Slack、Flowdock 和 Campfire 等。
ChatOps 的优点不言而喻，首先是能大大提高团队沟通和协作的成效。无论是代码的部署还是安全事件的响应，抑或团队成员的消息通知，聊天机器人都能够通过插件或脚本实时执行执行团队成员在会话中输入的每一行命令。换句话说，ChatOps 把过去团队成员在各自工具中输入命令的这个黑匣子过程前端化、透明化了。团队每个成员都能随时了解其他成员的一举一动，打造真正的无死角透明团队。
ChatOps 另外一个不言而喻的好处是非常有利于新人的培养。显然，能够直观看到团队的微观运作，对于刚入职的新手来说，比任何培训的效果都更好。
ChatOps 甚至也能给 IT 之外的部门带来重要价值，通过一个本地集中化的聊天工具，销售、营销和财务部门也能够直观看到企业 IT 基础架构的建设和运作情况，什么时候开始部署代码，哪些人负责哪些系统都是一目了然，很多时候能省去各种通知和沟通成本。
DevOps 的终极目标就是把复杂的世界简单化，在技术的不断变革探索中， ChatOps 的出现，即“聊着天就把事情给办了”，恰到好处。
智能化运维落地， 前景光明，道路曲折
眼光近与眼光远，有着本质的区别。只有对智能化运维的深层次思考，才能更有动力。一个很明显的规律，凡是让能让我们的生活变得更美好、更简单、更方便的技术，一定会具有强大的生命力，也必然会成为发展趋势。
