专栏首页祝威廉运维=平台+数据

运维=平台+数据

运维会比开发更加重要

运维的发展日新月异,曾几何时,运维仅仅是被认知为跑机房,装系统,设计网络,给开发擦屁股。但是现在运维变得极度重要,运维职责也更加细化,譬如稍大点的公司就将运维划分为基础运维,网络运维,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 条评论
登录 后参与评论

相关文章

  • 运维之殇

    让人推荐快速学习的方式,却也是极度无奈之举。而且运维也不是一日练成的。就算大师提供了很好的指导,也终究是拿自己的线上产品练手了,这样显然是得不偿失的。现如今,一...

    用户2936994
  • MLSQL v1.1.7.1 Bug修正版发布

    v1.1.7发布后,很快就有小伙伴说在Python使用过程中存在并发创建环境存在问题,例如ISSUE-915, 除此之外还有local本地文件冲突等引起的莫名问...

    用户2936994
  • MLSQL 1.3.0开发版中最新三个MPIPs--调度,资源,缓存

    MPIP 是新Feature提案。全称 MLSQL Project Improvement Proposals 。当然这个是学习Spark 的 SPIP,作为一...

    用户2936994
  • DevOps让运维人做到去运维化认知

    在这次的DevOpsdays大会上了,我的演讲主题是《DevOps,驱动应用从运维走向管理》,我为什么分享这样的主题?

    用户1593318
  • 运维挑战:如何构建复杂环境下的适应性系统

    “我们渴望构建一种能够描述市场、顾客及组织等世界万物的模型,并利用它为未来制定完美的战略。但很不幸,那是做不到的,而且永远做不到。未来具有VUCA特性,...

    彭华盛
  • 云计算和 AI 时代下的运维转型

    花名“谦益”,是公众号“Forrest 随想录”的作者,多届 ArchSummit 运维专题明星讲师和优秀出品人,TGO 杭州分会会员。目前专注于云计算和人工智...

    用户1682855
  • GOPS2018--腾讯运维体系专场回顾

    听说4月14日腾讯社交网络运营部八位大咖倾巢出动,齐聚深圳圣淘沙酒店。所谓何事? 当然是GOPS全球运维大会--腾讯运维体系专场了,几位老师给大家带来了一场思想...

    织云平台团队
  • 运维知识体系v3.1 & Web缓存知识体系v3.0

    前段时间,发现新运维社区的赵班长(赵舜东)更新了一版《运维知识体系 v3.1》其中新增了一些目前比较火的、成熟的开源工具和解决方案,也包括容器编排,微服务框架l...

    公众号: 云原生生态圈
  • 代理单点故障如何解决(面试必备)

    如今 Twemproxy 凭借其高性能的优势, 在很多互联网公司得到了广泛的应用,已经占据了不可动摇的地位,

    程序员小王
  • 一个简单的购物商城,记录一下。

    py3study

扫码关注云+社区

领取腾讯云代金券