即日起在codingBlog上分享您的技术经验即可获得积分,积分可兑换现金哦。

运维从跑腿到云背后的发展史

微信 运维帮 15℃ 0评论
本文目录
[隐藏]

1.作者介绍

肖云朋,美菜网运维总监,超过 8 年运维管理经验,长期专注于运维管理和运维自动化方向,对基于 CMDB 的运维自动化、持续集成、DevOps 有深入的理解和实践经验,深谙如何构建以 SLA 为目标的运维体系的构建。在此之前,曾就职于网易、豌豆荚运维部门,发起以 CMDB 为核心,结合虚拟化、TSDB、持续集成构建的自动化运维系统,服务于大规模分布式移动互联网的跨地域服务的部署发布与运维管理。 

2.正文

运维是一个名词相当丰富的领域,抛开各种丰富的技术名词,单就职位名称就很多:OP、SA、DBA、DEVOPS 、SRE、云工程师等等。这样一个领域,到底这些职位之间的分工和联系是什么?是什么导致了这些分工?到底运维的目标是什么?

要聊运维的目标,需要先聊聊运维的发展。运维这个职位大约是受到技术支持和 IT 这两个计算机还主要以提供工具给非计算机专业人士使用时衍生的工作影响而产生的,产生的背景是互联网的兴起,需要 一个对内部开发人员和广大产品受众负责的维护人员,这就是最早的运维。

2.1.1、运维 1.0 —— 初始化

这个时候的运维是一个通称,负责从机房、服务器选型,软硬件初始化,服务上下线,配置监控,盯监控等,运维和开发之间没有太明确的分工,一般就是业务无关的事情都由运维来做,因为业务一般不大 ,业务的运维形态也不固定,运维内部也无明确的分工,基本是遇到什么问题解决什么问题。有时候甚至是一些开发兼职做运维工作,这时候运维只有一个工种,就是 OP。

2.2.2、运维 2.0 —— 专业化

随着业务发展,通用运维的非专业性问题开始变的严重,这时候业务无关的事情已经从量变到质变,任意一个方向的问题都已经不再是会配置就能解决的了。这时候运维会开始出现以专业技能明确的分工, 在不同的公司可能会有略微不同,但大致会分为:

  • IDC: 或者叫网络工程师,擅长的是网络连接方面,主要负责机房建设。

  • SA: 擅长的是服务器初始化、调优等,主要负责提供服务器和与业务无关的各种基础设施(如 DNS 等)。

  • DBA: 擅长的是数据访问、安全方面,主要负责如 MySQL 数据库,很多公司也会把如非关系型,缓存等放在 DBA 组维护。

  • OP: 擅长的是消化开发的需求,自行补充分工未明确的服务。 OP 就是 1.0 阶段通用运维的延续,只是不再负责不擅长的专业领域分工工作,但还是要在专业领域不充分时,满足各种开发需求。

2.3.3、运维 3.0 —— 工具化

运维工作是离不开辅助工具的,但一般运维都是被需求赶着走,找各种开源或自己应急写的脚本工具来辅助日常运维工作。但随着需求的快速增长,运维开发能力不足、开源工具又往往不能很好的适应公司 的业务,能够趁手的工具变的越来越少。DEVOPS 这个职位就变的应运而生,这个职位的目标就是开发各种趁手的运维工具来辅助运维工作,或者提供给开发自主运维。这时候是个工具集大爆发的阶段, 各种开源、自行开发的工具、系统。 DEVOPS 的职责在满足运维的工具需求的前提下,要严格控制工具的量和工具间的衔接,保障大量工具的使用成本不至于太过复杂。

2.4.4、运维 4.0 —— 平台化

这个阶段是公司的运维业务基本趋于稳定(主要指运维业务,不一定是公司业务),团队划分和工具爆发的学习、沟通成为瓶颈,运维对一整套解决方案的需求变得非常强烈。当然很多时候我们并不想经历 3.0 阶段,所以很多时候我们会在 2.0 阶段就开始考虑构建统一的运维平台,但这会面对一个问题,运维形态不稳定会造成统一平台的抽象是不稳定的,是很难构建这个系统的。

这个阶段 DEVOPS 的工作是最为重要的,根据公司的运维业务特征,构建一整套运维平台,让各分工的运维团队都能在这个平台上完成运维工作。同时这个阶段还有一个重要特征就是随着运维业务形态的 稳定,运维各专业领域提供的基础设施几乎 100% 覆盖到开发的需求,初始阶段的 OP 的服务目标就从初期支持开发的各种需求,转变为将开发的项目按照公司的运维基础设施部署、保障稳定运行,也就 转变为 SRE 的角色。这时候 SRE 是项目架构师的实际实施者,SRE 是为项目提供更好的运维架构,维护服务间的依赖关系,构建高可用方案等。

2.5.5、运维 5.0 —— 云化


在传统互联网的领域,基本上在 4.0 这个阶段运维就算是做到维护状态了。受益于云的出现,大家又开始重新思考在互联网下,一个项目,运维的成分要有多大。这里面说到的云不是指我们购买了某种 公有云后的,就运维云化了,一般我们采用公有云,特别是购买 IaaS 的公有云,其实运维是从 OP 起步的,就是基于服务器自己做很多操作。而所谓的运维云化是通过 4.0 的平台化阶段后,公司运维 的基础设施不仅是对于运维,包括所有的开发在内都能形成统一认识,并基于这些基础设施开发业务。这时候所以运维专业领域的细节都被隐藏在一个通过自助化获取所有基础设施的云平台后边,原来的 DBA、SA、IDC、DEVOPS,还有更多的负责研究基础设施的研发工程师都被统一在一个云平台工程师的概念底下。

这个阶段的一个特征是 SRE 的角色是更加专业化,除了架构师,就算是有各种服务治理方案,开发本身对维护服务的可用性是没有概念的,特别是当一个业务是由多个开发组开发的的多个服务组成时,服务 间依赖关系、服务间依赖的可用性保障并不是开发可以保障的。这就需要 SRE 作为架构师的执行者(或者本身就是运维架构师),来为服务定制服务的高可用、扩容、监控、事件处理组件,并制定各种 状态下的运维方案,保障服务的可用性。

2.6.6、运维 6.0 —— 智能化


最终, Alpha 狗出现了 —— 我们一切努力的意义就是不再有我们。当基础设施固定下来,运维模式也最终会固定下来(当然,永远会有另一个特殊的业务形态要推倒一切模式重来,那是另一个运维循环的 开始)。SRE 将这些运维模式系统化在云平台中,开发在初始化项目从云平台申请资源时,就开始考虑采用哪种运维模式,这些模式会把包括可用性、扩容等场景的运维方案包含进来,平滑的把开发加入 运维架构中。智能化云的目标就是把所有的运维细节隐藏在云平台背后。

在这样一个运维发展过程中,有些公司按部就班,有些公司起步高,有些则跳级,这会由公司的业务形态,人员素质等决定。但如果没有经历过一些阶段,我们一般会走入一些运维的误区,典型的是会把运维 的形态想简单,导致的结果是运维工作变成一个不系统,散乱的状态,让运维的三个重要结果:快速上线、稳定运行、高效资源利用,变的不可控。

当然,在这个公有云遍地跑的世界,其实一个公司的运维形态是可以从 5.0 开始的,但前提是公司直接采用公有云提供的全套基础设施,把业务架构在这套基础设施上,但这要求公司从开发到运维对该公有 云有很好的认识,并恰好业务的需求该公有云的设施都能覆盖。但遍观目前的公有云,大约只有阿里云和 AWS 某些业务领域可以覆盖,大部分情况下,只是解决了 IDC 和 SA 能解决的 IaaS 部分,这其实 要求 OP 还要从 1.0 做起,一步步补齐。

这个发展过程也不是运维所有领域都是齐步跑的,最少我们知道在 IaaS、负载均衡、数据库方面是可以很快达到 5.0 的云化的,最复杂的是 SRE 服务解决方案,这个也是一个公司运维最应该努力实现的目 标。

附运维发展表:

欢迎投稿技术文章

一经选用送运维帮限量T恤一件,男女款都有

投稿联系微信yunweibang008

运维帮精选

运维服务进化论,从原始简单进化为科学成体系

技术干货 | 微服务架构软件的持续集成与交付

【运维帮出品】Docker运维工程师系列免费公开课

今年7月,最好的架构师都在这里…

黑客一行代码可能让您损失上千万

《2015中国移动应用性能管理白皮书》发布

DevOps高手的九项隐藏技能

Gdevops全球敏捷运维峰会杭州站,不可错过的精彩【附PPT】

好书来袭:谷歌首次披露SRE如何运行百万服务器

欢迎加入运维帮QQ技术讨论群:542812110

点我加入运维帮会员,沙龙举办城市你说了算

快乐分享,快乐生活

商务合作,请加微信yunweibang008

转载请注明:CodingBlog » 运维从跑腿到云背后的发展史

喜欢 (0)or分享 (0)
发表我的评论
取消评论

*

表情
(2)个小伙伴在吐槽
  1. 都是概念
    明明猪2016-05-13 02:04 回复
  2. 有没有完整的运维系统
    dj20122016-05-29 16:17 回复