业务运维部门的岗位价值与DCOS

标签: 运维 | 发表时间:2015-06-10 08:49 | 作者:taowen
出处:http://segmentfault.com/blogs

岗位价值有:

  • 权限缩小
  • 提供操作安全的保险服务
  • 提供操作的可扩展性
  • 提供业务和资源能见度
  • 屏蔽资源的部署细节
  • 静态资源调平
  • 动态资源调平
  • 故障处理和善后

权限缩小

通过配置文件修改一个后台参数需要登录权限,文件修改权限,甚至进程起停权限。这些运营环境的权限需要尽可能的收归到很少的人的手里以控制风险。业务运维初期以人工接口的方式提供服务,后期以web应用的方式提供自助服务。如果后台开发人员做得比较完善可以直接提供web应用提供自助服务。但是很多时候业务开发部门的主要 KPI 不是提供运维的方便性,所以使得业务运维部门需要自己去开发这些管理性质的 web 应用。
常规的新服务器上架版本发布都需要登录权限,文件修改权限等几乎不受限制的权限。运维提供人工接口或者web应用的方式把权限缩小之后对外提供服务。

提供操作安全的保险服务

操作安全可以量化为操作次数与操作引起的故障的比例关系。运维部门初期以认真仔细的工作态度提供高标准的操作服务。后期以高可重复性高一致性的自动化系统提供安全保险,把每一次都不大一样的人工操作变成每次执行相同的脚本由计算机执行。业务运维售卖的是一种保险服务,其实质和保险公司一样是以风险来核算成本的。
传统的操作安全也存在两点问题:

  • 即便是自动化的脚本并不能带来一致性的保障。因为每次执行自动化脚本都可能对现网状态产生影响,人工的手工操作会使之雪上加霜。实际上每次自动化执行之前的现网状态都可能不同,结果是一台服务器使用的时间越久运维风险越高。
  • 版本交付方式的多样化,操作现网环境的多样化极大地提高了风险系数。通过标准化版本交付方式,标准化进程和服务起停与依赖管理方式可以用一套自动化系统对接各种差异化的应用,减少中间的胶水脚本带来的操作安全隐患。携程出的运维事故说明了其操作安全是没有保障的。当我们把一个数据中心上的硬盘整体格式化之后,其上的应用多久可以恢复很好的度量了操作方面的水平。

低风险的操作是频繁变更的前提,也是提高业务敏捷性的前提。

提供操作的可扩展性

可以迅速地完成跨数据中心海量 IP 的操作变更
操作的完成速度是频繁变更的前提,也是提高业务敏捷性的前提。

提供业务和资源的能见度

与权限收归性质的后台 web 应用类似。理论上来说后台开发会提供一些管理类的界面去查看业务的运营指标,以及程序和资源效率方面的监控指标。但是因为业务部门的 KPI 是以收入为导向的。很多运营决策用的指标,性能调优性质的指标,故障判别类的指标都需要由业务运维部门来采集展示和告警。

屏蔽资源的部署细节

从 IDC 选址,专线规划到给进程配置文件配置 IP 地址。让开发人员关心逻辑与逻辑拓扑,屏蔽了部署细节,减少了开发的工作量。让昂贵的专业开发人员专注于更有价值的事情上。

静态资源调平

利用虚拟机,container,同机部署多个进程等各种手段提高主机的利用率。合理规划机架和出口分布,提高网络的利用率。
静态资源调平主要靠优化部署来完成。两次调平之间一般需要调用比较慢的重部署流程(比如ssh执行脚本起停进程等),甚至可能包含人工操作环节。
静态资源调平的颗粒度是 IP。

动态资源调平

动态资源调平一般说法是动态扩所容。和静态资源调平的主要的区别是一般不以部署流程去调平资源,而是以更快的调整负载均衡,起停进程的方式完成,完全不能包含人工操作环节。
动态资源调平要求运维必须从 IP 级别的管理水平提高的到进程和服务级别。

故障处理和善后

大部分时候业务都会提供高可用的系统。运维仅需要在故障之后,对故障机做重启或者下架替换等善后操作。有的时候,运维需要以冷备和自动切换的方式提供等级弱一个级别的可用性保障。
故障处理时,运维需要进程初步的故障定位。进程和服务的依赖管理可以帮助运维定位到问题。

数据中心操作系统(DCOS)

以 mesosphere 和 hashicorp 等新一代创业公司为代表,开始提出数据中心操作系统(DCOS)的概念。实质上是复制了 google/twitter 等大公司的标准化运维系统。
数据中心操作系统(DCOS) 提供方的愿景是提供一个通用的标准化运维系统高效率可靠安全地管理数据中心。直接与开发方对接,以 docker 容器等标准化的方式交付版本,以进程和服务描述的方式标准化搭建进程和服务。数据中心操作系统与开发方有一个非常清晰和低成本的接入接口,完全省去了运维这个角色写胶水脚本的必要性,从而彻底颠覆这个岗位。
运维目前需要开发的操作和监控类的 web 应用不再需要定制开发,数据中心操作系统(DCOS)提供可定制的操作和监控模块,只需要配置就可以接入,形成 web 应用,不需要代码开发。
当一家DCOS的产品公司可以低成本的与各种中小开发商对接之后,中小开发商可以大幅裁剪运维部门。而DCOS公司可以获得可观的经济收益,从而进一步地开发更完善的产品。DCOS实现的技术关键在于,docker的标准化版本交付技术,smartstack为代表的路由托管技术使得不标准业务改造为标准业务的成本急剧降低。
puppet/chef 是让运维写脚本编程写cookbook。而DCOS则可能直接让写脚本地这个胶水岗位消亡。DCOS显然比 puppet/chef 等公司更具有颠覆性。

相关 [业务 运维 部门] 推荐:

业务运维部门的岗位价值与DCOS

- - SegmentFault 最新的文章
通过配置文件修改一个后台参数需要登录权限,文件修改权限,甚至进程起停权限. 这些运营环境的权限需要尽可能的收归到很少的人的手里以控制风险. 业务运维初期以人工接口的方式提供服务,后期以web应用的方式提供自助服务. 如果后台开发人员做得比较完善可以直接提供web应用提供自助服务. 但是很多时候业务开发部门的主要 KPI 不是提供运维的方便性,所以使得业务运维部门需要自己去开发这些管理性质的 web 应用.

WebOS 全球业务部门换人,将由 Stephen DeWitt 领导

- Chrisoul - Engadget 中国版
答案是,这位曾经在 PSB Americas 任职的 Stephen DeWitt ,将会取代 Jon Rubinstein 成为 HP webOS 全球业务部门的领导人,至于一直亲力亲为,站台为 webOS 宣传的 Jon Rubinstein 则将会成为 HP 个人系统部门的资深副主席(怎么这个头衔看上去好像被架空的那种...).

惠普终将砍掉WebOS业务部门

- gamtin - cnBeta.COM
自从惠普前任CEO下台以后,惠普就决定保留原PC业务,毕竟这是惠普的核心业务. 但外媒称其将关闭2010年从Palm公司以12亿美金并购的WebOS部门. 曾经短暂出现在惠普板电脑及智能手机上的WebOS若关闭,就意味着惠普将有500名员工面临下岗. 这个部门的一些高管已离职,有一位员工透露,惠普有95%的可能性关闭WebOS部门,最迟到十一月,就会有许多人下岗.

惠普虑分拆PC部门 停止webOS设备业务运营

- applelen - cnBeta.COM
据路透社消息,最快本周四,惠普将宣布100亿美元收购英国软件公司Autonomy,并分拆个人电脑业务. Autonomy位于剑桥,它拥有许多大客户,比如宝洁. 客户使用Autonomy的软件来搜索和整理数据,比如电子邮件. 消息人士透露,惠普可能会在发布季度财报之后当天宣布此事.

宽带接入网业务向民资开放,最受考验的是主管部门的行业监管

- - 付亮的竞争情报应用
工业和信息化部于2014年12月25日发布了《关于向民间资本开放宽带接入市场的通告》,经过征求意见,最后发布的《通告》及《宽带接入网业务开放试点方案》在实操方面有了明显的提升. 对基础运营商和试点的民资企业的责权利进一步明确. 一个小的遗憾是,我提到的三点:试点城市16个有点少、试点周期三年有点长、应向所有资本开放,此次都没有改动,这应该是出于慎重的可虑.

Java应用运维

- - BlueDavy之技术blog
对于互联网产品或长期运行的产品而言,运维工作非常重要,尤其是在产品复杂了以后,在这篇blog中就来说下Java应用的运维工作(ps:虽然看起来各种语言做的系统的运维工作都差不多,但细节上还是会有很多不同,so本文还是只讲Java的). 苦逼的码农按照需求开发好了一个全新的Java Web应用,该发布上线给用户用了,要把一个Java Web应用发布上线,首先需要搭建运行的环境,运行的环境需要有JDK、APPServer,在已经装好了os的机器上装上JDK和APPServer,开发好的Java Web应用可以用maven直接打成war或ear,将这个打好的包scp或其他方式到目标机器上,准备妥当,就差启动了.

ZooKeeper运维经验

- - Juven Xu
ZooKeeper 是分布式环境下非常重要的一个中间件,可以完成动态配置推送、分布式 Leader 选举、分布式锁等功能. 在运维 AliExpress ZooKeeper 服务的一年多来,积累如下经验:. 3台起,如果是虚拟机,必须分散在不同的宿主机上,以实现容灾的目的. 如果长远来看(如2-3年)需求会持续增长,可以直接部署5台.

hadoop运维笔记1

- - 企业架构 - ITeye博客
hadoop使用中的几个小细节(二). 1 某次正常运行mapreduce实例时,抛出错误. 经查明,问题原因是linux机器打开了过多的文件导致. 用命令ulimit -n可以发现linux默认的文件打开数目为1024,修改/ect/security/limit.conf,增加hadoop soft 65535.

运维工具体系

- - SegmentFault 最新的文章
发布变更流程管理工具:做为系统接口与其他角色的工作衔接. 并提供审批环节控制发布变更的风险. 流程管理工具并不负责具体的业务操作的执行,只是作为单据系统跟踪流程和确保闭环. 告警和突发管理工具:体现业务受损的告警自动建单管理. 通过建单管理告警和突发确保流程的闭环,以及每次故障都能够总结出经验,并未度量业务的可用性提供KPI.

ES运维--快速重启_运维_SouthPark的专栏-CSDN博客

- -
修改es配置,重启集群成本巨大. ES集群已有25T数据,27个节点,24个数据节点(热盘12和hot节点,慢盘12个stale节点,3个mater节点),数据节点的启动,加入集群后需要初始化全部索引,这个过程过程很慢. 全部重启一次可能要一天,非常耗时. 重启后经常遇到少量索引一直处于unassigned状态,导致集群一直是red状态.