运维=平台+数据

运维会比开发更加重要

运维的发展日新月异,曾几何时,运维仅仅是被认知为跑机房,装系统,设计网络,给开发擦屁股。但是现在运维变得极度重要,运维职责也更加细化,譬如稍大点的公司就将运维划分为基础运维,网络运维,DBA, 应用运维,架构师。其实我个人认为系统架构师应该都安排在运维里,开发团队应该率属于运维团队才好。

进入云时代后,中等层次的运维慢慢会被淘汰,底层次的运维会越来越少,高水平的运维需求量则日益增长。为什么这么说呢?云时代背景下,低层次的运维主要按章循干活即可,而高层次的运维则需考虑系统架构设计,以及构建自动化的系统。这其实是反应对运维的要求会越来越高,不但要掌控产品的稳定性,做好服务保障的最后一公里,还要具有系统设计的能力。

运维现有发展方向的问题

运维也越来越朝着平台化,自动化,自助化方向发展。这种发展方式虽然可以解决问题,但是会导致碎片化以及难以标准化,不可复制,对生态也是不利的。

所谓碎片化指的是针对性的开发工具套件解决问题,比如为了解决配置问题,开发了个配置系统,比如为了部署,开发了部署系统,为了管理应用,针对不同类型的应用开发管理系统。所有这些系统都是为了解决特定一类问题而开发的,系统孤岛,很难让他们产生关联。

导致这种现象的原因在于,开发人的能力本身不足,缺乏全局观,或者各个系统本身的属性特质就导致他们难以关联。每个系统就像一个碎片,所以我们说这事碎片化。

标准化指的是,我开发的配置系统很可能跑到另外一家公司,就不能用了,因为我只是针对我的环境开发好配置系统就行,这里就带来的另外一个问题就是不可复制,也就是我开发的系统没办法很容易移植到别的地方去。

对生态不利,则是指,因为无法标准化,难以复制,每家公司各自开发自己的,无法形成社区,大家致力于统一的运维工具,则必然影响运维生态的发展。

这些问题总结起来,其实就是缺乏一个具有一定规范的容器,将所有的需求框起来东西。

运维发展新方向

之前我写过一篇文章,谈及如何用大数据思维做运维,当然这篇文章有他自己的局限性,只是谈及了运维监控,灌输一种 data based 的理念。

前面我们提及了运维发展现状,以及现有的发展模式带来的问题,解决的方式就是 Distributed OS + Data Based::

  • 使用 Distributed OS 抽象出应用的部署/管理/生命周期监控/自动化体系
  • 使用 Data-Based 思想inspect 应用内部状态,当然也包括Distributed OS,做好监控,报警,容量规划等。

如果有这么一个框,能把所有的运维需求给支撑起来,规范起来,这个框就是分布式操作系统(Distributed OS )。想想我们的单机系统,所谓应用的安装,运行,卸载,交互都是那么简单和随意。然而到分布式领域后,单机OS 退化后,导致缺乏这么一个统一底层系统。运维在这个层面自己也想了很多办法,通过puppet,通过shell,通过各种开发出来的系统。但这是运维缺乏规范和混论的时期,严重依赖于运维团队的自身的能力。

随着分布式相关应用慢慢成熟,尤其是大数据的崛起,对服务器有了更多的需求,以资源为粒度的管理需求也变得更加迫切,于是有了Google Borg,开源的则有Mesos,Yarn等。Google Borg 是个典型的。我们所有的运维需求都应该基于Borg去做。开发的服务交给Borg,后续的服务生命周期(扩容、缩容、调度)都由Borg统一接管,服务被Borg部署到哪个IDC、哪个服务器,研发人员不用关心。这个是系统层面的。当然类似Borg的 Mesos,Yarn等,都是追求一个动态调度的过程,我们也可以完全利用Borg,指定将应用安装在哪些单元(服务器群组)上,从而能够接管所有的服务。

这样,所谓前面我们提及的配置系统,部署系统,服务器监控都是在Borg提供的基础服务。就好比单机系统,你通过它安装,运行,关闭,卸载应用,你可以看服务器的资源使用情况。Borg 也是完全一样的。

也有人会说,很多应用的安装部署是很复杂的,而且如果使用了Borg其实就使得应用必须去适配Borg才能被管理。经过我们的实际实践,大部分应用都不需要对应用进行更改,也不需要对Borg进行更改,就可以部署和管理起来。复杂的比如Hadoop体系的安装,则需要Borg进行一定程度的支持,我们抽象出了一套应用的部署方案,只要简单的写一些描述文件,Borg拿到Hadoop的发型包,就知道如何安装和管理他们了。如果你需要对Hadoop做更细致的增强或者管理,你可以开发一个第三方应用,然后通过Borg安装去管理。Borg提供了交互的API,你可以通过这些API去管理Hadoop如果生命周期,而无需知道Hadoop安装在哪。

现在很流行的容器技术,也被广泛的被Mesos/Borg调度,对Borg来说这是以资源为粒度的应用,我们前面提及的,则是以服务器为粒度的应用。

前面讲的是基础平台层面的,我们其实更多的是要对应用进行更细致的观察。在Borg之上的应用可以是非常复杂的,应用的关联也是非常复杂的,微服务的兴起导致链路非常长,所以我们有了全链路追踪的需求。一切服务都是为了帮助数据进行流转和变换,服务的状态也都反应在数据流上,这种瞬态和终态的量是非常大的,所以我们需要借助大数据的思维去做处理。

到这里就可以参考大数据思维做运维灌输的概念了。

所以未来运维可以完全依托一个固定的分布式操作系统,在其上开发各种运维工具,利用大数据相关的理念和工具,监控,追踪,分析服务的状态,解决现有的运维工具碎片化,难以复制,难于贡献生态的问题。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏容器云生态

我怀疑遇到了假的CMDB

每次读到配置管理相关的书籍时,我总在想:“这些定义很精准,流程也很残缺,但这不是真正的难题。”对于一个配置管理者来说,真正的难题不是绘制“庞大而精美”的数据...

4.5K90
来自专栏IT大咖说

大咖谈Kubernetes的建模应用

说起建模,很多小伙伴都不陌生,就是为了理解某一事物而对该事物做出的某一种抽象,是对这个事物没有歧义的一种描述,也叫建立模型。当然,建模也分系统建模,数据建模等好...

10320
来自专栏大魏分享(微信公众号:david-share)

从2015年服务器操作系统厂商收入排名谈U2L

2015年服务器操作系统收入排名 Garnter在2016年5月20日发布了服务器操作系统收入分析报告。里面包括Linux、UNIX和Windows三大类操作系...

36030
来自专栏SDNLAB

谈谈虚拟化及其安全性

虚拟化是硬件和软件工程的协作,以创建虚拟机(VM)。这被认为是计算机硬件的抽象化,使单个物理机能够当作多个机器运行。没有虚拟机,单个操作系统将会占用所有的硬件资...

393110
来自专栏程序你好

采用微服务和容器架构的五个想法

作为New Relic容器Fabric项目(我们的内部容器编排和运行时平台)的首席站点可靠性工程师(SRE),我花了大量时间与现有和潜在客户一起回答关于我们如何...

10530
来自专栏云计算D1net

开发漫谈:最受DevOps欢迎的五种工具

DevOps这个词在几年前从欧美流向大陆,主要反映了开发与运维两批人之间的矛盾与磨合。从单词的角度来讲,DevOps是开发(Development)和运维(Op...

36450
来自专栏企鹅号快讯

当Kubernetes和Tensorflow走在一起

译者|李建盛 编辑|Emily 背景介绍 Kubeflow 旨在让机器学习能够更加容易、可移植、可扩展的在 Kubernetes 上运行。其目的并不是简单的重新...

53990
来自专栏云加头条

云端架构师养成系列之二:云端负载均衡上手与实践

上周四,腾讯云技术社区继续推出了【云端架构师养成】系列分享的第二期:云端负载均衡上手与实践,邀请到的嘉宾是负责该产品的产品经理方坤丁与工程师龚飞斐。 [1496...

45090
来自专栏云计算D1net

为什么你的私有云可以很像PaaS?

在IT界数年针对私有云架构的优点的不断的争论之后,一个切实可行且企业可用(enterprise-ready)的私有云架构终于来到了我们面前。并且与其它在过去的一...

48340
来自专栏编程坑太多

『高级篇』docker之服务编排三大平台扬帆起航(21)

PS: 国内这种公司还是很多的,他们致力于帮助互联网企业来使用docker。让企业不管是传统服务,还是微服务,都可以享受到docker带来的遍历。他们的方案基本...

8430

扫码关注云+社区

领取腾讯云代金券