[关闭]
@Helene 2017-09-11T10:08:15.000000Z 字数 2553 阅读 870

DevOps 的终极目标是把复杂的世界简单化

高效开发运维


随着 AI 技术在各个应用领域的落地及实践,IT运维也将迎来一个智能化运维的新时代。9月10日-11日,极客邦科技 & InfoQ 中国主办的 CNUTCon 全球运维技术大会在上海成功举行。今年大会以“智能时代下的新运维”为主题,透过国内外相关公司的领域动态及应用案例的分享,探讨未来运维趋势的发展之路。

透过 CNUTCon 大会,摸清了 DevOps 发展的必经之路

任何一种新兴技术,有如 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 的思想在开发和运维之间的一个平衡。

技术本身不是最大的障碍,真正的挑战是大家能不能用智能商业的思路来重新审视自己所有的业务,所有的流程,甚至进行全面的改造和创新。运维要用云服务的思路去做。如果一个公司内的运维团队开发出一堆工具,让做应用开发团队可以很容易地申请机器、存储、网络、中间件、安全等资源,并很容易管理、监控和部署应用,并提供运维资询。那么,这个公司就会不经意地做出一个云计算平台来了。

智能化运维落地, 前景是光明的,道路肯定是曲折的。

眼光近与眼光远,有着本质的区别。只有对智能化运维的深层次思考,才能更有动力。一个很明显的规律,凡是让能让我们的生活变得更美好、更简单、更方便的技术,一定会具有强大的生命力,也必然会成为发展趋势。

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注