IT:从运维到运营

Wesley13 等级 186 0 0

本文转自公众号:傲寒荐书,作者:陈傲寒

IT运维?IT运营?

都是 IT Operations,有什么区别?

IT运维管理?IT运营管理?

都是 ITOM,有什么区别?

一字之差,只是翻译不同,还是另有玄机?

其实,中文真的是一门更精确的语言 :-)

  • IT运维是“活着”,IT运营是“活得好”;

  • IT运维更多是被动式“维持”,IT运营更多是主动式“经营”;

  • IT运维更多是面向基础设施面向软硬件,IT运营更多是面向业务面向服务面向人;

  • IT运维的关键词是“稳定”、“安全”、“可靠”;IT运营的关键词是“体验”、“效率”、“效益”;

  • IT运维管理工具更多是关注故障防范和修复的“监管控”,IT运营管理工具开始更多应用性能、用户感知、快速交付、数据分析和可视化。。。

企业IT正站在这样一个拐点上,要么从运维走向运营,要么从运维走向被代维

***正文之前的说明: IT运维和 IT运营都非常重要,运维是运营的基础,任何一个组织,首先是要活着,之后才要追求活得好,是 IT Operations的不同发展阶段, 今天的 IT运维部门的工作内容其实包括本文所说的 IT运营。***

大多数ITOM领域的从业者,一直以来都约定俗成地把ITOM(IT Operation Management)翻译成IT运维管理,相应的也把IT Operations叫做IT运维。 近两年来,开始有越来越多的人使用“IT运营管理”和“IT运营”这样的说法,对应的英文是一样的,但这里“运维”和“运营”是同样的意思吗? 两者之间有什么异同?

关于这个问题,仁者见仁智者见智。 有人认为其实运维就是运营,用个新名词只是哗众取宠的噱头而已; 有人认为运维是面向IT设施的,运营是面向业务服务的; 有人认为运维是关注IT指标,运营是关注业务指标的; 甚至有人说,运维是“眼前的苟且”,运营是“诗和远方”:-)

总体来看,大多数人认为两者含义并不完全一样,很多人都认为IT运营比IT运维的层次更高, 有些成熟度较高的大型IT组织已经提出并在执行“从IT运维到IT运营”的发展规划。 但即使在提出这类理念和计划的组织内部,对于究竟什么是IT运维管理,什么是IT运营管理,也还没有非常清晰的分析和定义,更多的是将传统IT运维管理领域之外的一些新内容笼统的归到IT运营管理的部分里去。 我在和某个正在执行此规划的IT组织中的某位高管交流时,他就提到: “From Operations to Operations? 连定义都没搞清楚,怎么能成为指导方向和发展目标? ”

他的问题让我这个ITOM的老兵也开始思考“IT运营”这个新“翻译”的真正含义,以及近几年来它日益流行的真实原因,在和许多同业交流之后,笔者在此分享一下我关于这个问题的一些想法和心得,作引玉之砖,希望能带来更多同业的讨论和指教。

首先,IT运维和IT运营,英文都是IT Operations,在老外来看,并无区别,是指关于IT运行的所有事情。 而中文之所以有两种不同的翻译,是因为IT Operations包括的内容很多,IT运维和IT运营两种中文译法分别侧重其中某一部分的内容,假如归纳成一句话的话,可以说IT运维管理关注的是“活着”,而IT运营管理则有更高层次的需求,不仅要“活着”,还要“活得好”。

先看个实例,某大型数据中心IT服务能力的愿景是“以业务为中心,交付稳定、安全、高效的IT运营服务,构建业界领先的IT运营能力,支撑企业的持续发展和战略成功。 ”这个愿景中,“稳定、安全”就是解决活着的问题,属于传统IT运维管理的范畴,“以业务为中心”、“高效”、“业界领先”则属于如何“活得好”的范畴,更多的是IT运营管理的范畴。

能力建设是有循序渐进的过程的,任何一个组织,首先都要解决“活着”的问题,然后才有可能追求“活得好”,因此,过去三十年,在大多数IT组织面临IT设施规模快速扩张,IT应用数量不断增多,IT运行压力越来越大的挑战时,首先要确保IT系统“活着”,也就是能够持续“运行”,稳定“运转”,通过日常“维护”工作让系统少出故障,出了故障能快速“维修”,“维持”系统的正常“运转”。 这个阶段把IT Operations翻译成IT运维,把ITOM翻译成IT运维管理,无可厚非。

IT运维管理阶段的关键词是“稳定”、“安全”、“可靠”,关注可用性指标(MTTR、MTTF、MTBF等)、可靠性指标(RTO、RPO)和安全合规。 相应地,在技术、工具和流程上,都以稳定、安全、可靠作为最优先考虑的要素:

  • 技术上,倾向选择稳定成熟的技术架构和产品,愿意为提升可靠性支付大量溢价,上得起小型机的就上小型机,买得起大机那就大机,能备份的地方就备份,尽量采用全冗余架构;

  • 流程上,首先从事件管理和变更管理做起,主要目标是能确保故障事件得到追踪和及时解决,以及管控变更避免人为故障多发,关注重点还是在提升可用性;

  • 工具上,采用“监-管-控”架构,其中监控更关注设备级监控,重点发现故障节点,“管”就是配合实现变更和事件流程,至于“控”,此时上配置自动化工具,更关心的是实现配置的标准化和合规检查,重点还是在增强可靠性减少故障,而非减少运维人员工作量。

在以“活着”为主要目标,以“稳”为主要形态的IT运维和IT运维管理发展多年后,越来越多的IT组织开始走出这个解决基本生存需求的阶段,从“被动维持”走向“主动经营”,追求如何“活得好”,近十年来,APM、BSM、云计算、运维大数据等新的理念、技术和工具的出现、发展和变迁,都和IT正逐步开始从运维走向运营有密切关系,时至今日,从全局角度来看,可以说企业IT已经站在了从运维到运营的一个重要拐点上。

IT运营是建立在良好的IT运维的基础上的,没有“活着”,“活得好”就无从谈起。 但怎样才叫活得好呢? 换言之,IT运营追求的目标究竟是什么? 比IT运维多了哪些东西呢?

与IT运维更多地是面向基础设施不同,IT运营更多的是面向业务、面向服务,本质上是面向人。 我们说某个人活得好不好,如何判断呢? 大多数人认同的马斯洛需求层次理论说,在解决了基本的生存问题和安全感之后,一个人要感觉自己活得好,是需要有社会认同和自我实现的。 对于CIO来说,他所管理的IT组织假如能让三类人满意,我们就可以说这个IT组织已经从基本的IT运维阶段走到IT运营阶段,已经处在活得好的状态了。

哪三类人呢?

用户、老板和IT人。假如IT组织是一个独立公司的话,这三类人基本对应着客户、股东和员工,CIO如果是公司老板,就会知道其实这三类人是哪个都得罪不起的:客户不满意会流失,企业就没有生存之本;股东不满意会换人,说明企业没有竞争力;员工不满意会换地儿,企业就缺乏持久发展的能力。尽管行业特点和企业文化不同会带来优先级和侧重点的不同,但本质上,一个有长远发展前景的卓越公司,往往是做到了让客户、股东和员工都满意的公司。

IT运维阶段,IT组织更多地还是在解决三类人的基本需求,让用户能用,让老板批钱,让员工干活,当然也希望大家更满意,但受限于阶段性能力和各方面因素,先能保证这些基本需求就已经很不容易了,而做到这些,在相当长时间内也已经足够,主要因为几个原因:

  • 各企业信息化之初,能够利用IT实现对业务和管理流程的优化、固化和自动化,就已经达到目标;

  • 初期系统以内部员工为主要用户,且没有同类系统做对比,用户对系统效率和体验的容忍度高;

  • IT部门在企业内部的IT能力供给上基本是垄断的,用户没有其它选择。

因此,过去虽然IT部门提供的即使只是满足基本需求的服务,大多数情况下也并没有多大问题。 但短短十年间,互联网和移动互联网大潮席卷世界的每个角落,每天用着微信滴滴淘宝携程的用户们的胃口已经越来越高了,过去能够忍受的一些小问题也已经变得忍无可忍了:

  • 人家网站那么快,咱们的系统怎么都是老和尚,点一下鼠标要等一炷香才动一下?

  • 人家网站第一次用没人教我就全部自己搞定,咱们系统怎么培训几回我都搞不清怎么用?

  • 人家网站一看就是赏心悦目高大上,咱们系统怎么就总是Low逼的不行?

  • 人家网站免费邮箱都无限容量,咱们怎么花那么多钱还每人限收发10M内邮件?

不知从哪天起,过去和企业IT八竿子打不着的“人家”一下子蹦出来,成了IT部门的变相竞争对手了,没抢走用户,但把用户满意度抢走了。更要命的是,随着云计算各种aaS的风起云涌,这些“人家”未来没准儿真的要来抢走用户了。假如IT部门不能与时俱进,还是停留在满足基本需求的运维上,而不主动向追求卓越的运营迈进,提供更有竞争力的优质IT服务,那就很可能会在几年后会碰到更大的挑战。

而在IT运营阶段,与IT运维阶段的关键词“稳定”、“安全”、“可靠”不同,关注的关键词变成了“体验”、“效率”、“效益”。回顾前面我们提到某大型数据中心的愿景中“以业务为中心”、“高效”两个运营关键词,其实“以业务为中心”就对应着“以用户为中心”,业务就是以用户为中心的吗,而用户关心的就是体验(稳定可靠也是体验的一部分)。“高效”则包含着高效率和高效益两个含义,一个关注敏捷性,交付速度、响应速度,一个关注成本收益,关注服务获取效率。

(假如说IT运维以“稳”为主,那么IT运营则以”敏“为主,在技术架构选择和IT管理流程和系统的建设上面,IT运营阶段都和传统IT运维阶段的关注重点有所转变,从而带来了新旧架构、新旧工具、新旧方法并存甚至交汇的复杂情况,Gartner在提的Bimodal,联想所说的双态IT,也都在反映这种状态。)

让我们围绕三类人的需求简单看看IT运营比之IT运维阶段要面临的新挑战,以及应对挑战在出现的一些新的理念、工具和技术:

让用户满意

用户大致有两类,个人用户和业务部门:

个人用户,不论是内部用户还是外部用户,更关心的是体验,体验主要是易用性、容错性和响应速度;要提升体验,对于IT运营管理领域就带来了新的要求,要在传统的设备和组件监控的基础上,增加端到端的用户体验感知能力、应用性能的深入探测和分析能力、应用及系统性能瓶颈的发现和优化能力。

越来越多IT组织开始关注用户体验,从而纷纷部署包括外部模拟仿真探测、流量数据分析、日志数据分析、嵌码采集探测等各种针对应用性能管理的手段工具 ,造就了近年来APM市场热度飙升。

这些采用不同手段的APM工具虽然有功能重叠的部分,但各有其侧重点,多种工具的部署能带来数据和功能的丰富性和多样性,对于准确测量和提升客户体验是有必要的,事实上在那些特别重视用户体验的IT组织里,已经或者正在进行全方位的工具部署,并在尝试在各种专业分析工具之间架设运营大数据工具,集成多样化数据,提供数据的统一可视化和整合分析等能力,提升故障和优化点的定位分析能力,深度改善用户体验。

业务部门,除了关心最终用户的体验,更关心交付效率,与之相应的,IT部门开始在各个环节上采用新架构、新技术和新工具,从各个环节上提升效率,加快业务服务的交付速度。

  • 提高采购流程和硬件上架的效率:IaaS云和资源池模式改变了传统的按需采购模式,通过资源整合,将资源规划和资源准备的工作批量前移,极致地提高了预算、采购和硬件上架的效率;

  • 提高系统部署和应用发布更新的效率:采用各种云管理工具、云管理平台及DevOps工具,通过自动化部署、配置管理等功能组件的组合,或从横向的系统层次上,或从纵向的应用发布运行链条上,或者协同配合,不同程度地提高了应用组件甚至是整个业务系统的交付和发布效率,实现对业务部门交付需求的及时甚至实时响应,达到“敏捷”的程度。

让老板满意

让用户满意是让老板满意的基础,假如业务部门天天在老板那儿告状,老板怎么都满意不了。但是即便业务部门都说你好话了,老板就会满意了吗?要是你真的这么认为,说明你太不了解老板这种动物了。

老板要的不只是结果,也一定会追求高效率和高效益,同样的成果,能否用更低的成本达成?我们现在的成本收益水平,对应业界同行,是人傻钱多还是精明高效?说要追求“业界领先”,怎么就是领先了?不能说技术更新应用更多就是领先吧?总要有个从效益角度的衡量方法吧?假如IT部门是一个独立运营的实体,作为给钱的股东,也是要问这些问题的。

效益本质上是投资回报率,成本越低,效益越好,做的事情越有用,效益越高。要追求高效益,首先面临的难题是要有一套成本收益的衡量体系,没有量化方法,既搞不清楚IT部门当前在同业中所处的水平,更无法通过指标考核的方式推动IT部门不断提高效益水平。在没有这套衡量体系的时候,往往只能采用一些非常粗线条甚至感性的衡量方式,比如看每年的IT采购金额、IT员工数量、工业标准产品的采购单价等,导致很多IT部门在采购时往往要求厂商保证提供同行业最低价,可当大家都这么要求的时候,显然很难真正起到效果。更为重要的是,由于每个企业在业务和IT服务方面存在的差异性,这些粗线条指标并不能反映IT部门的效率和效益水平。

ITIL体系中早就提出了IT服务财务管理的概念,许多IT组织在过去十年尝试了一些BSM(业务服务管理)和ITFM(IT财务管理)的项目,一个重要动因就是试图建立IT效益的衡量体系,可在内部IT部门中成功者寥寥,主要原因是全部精力投入到基础运维工作中还忙不过来,另一方面也和缺乏特别成功的最佳实践有关。

不过随着大家的不断尝试,伴随近年来IT架构的演进和公有云的兴起,一些走在前面的IT部门已经看到了建立IT效益衡量体系的可能性,并开始在某些架构层级上开始尝试性的探索:他们采用服务分层、成本归集、各自对标的方式,对DC层、IaaS层、PaaS层的资源单位成本、资源利用效率、能源单位成本、能源利用效率和人员运营效率进行分别统计和分析,并分别和IDC、IaaS云、PaaS云的外部供应商市场价位水平做对照,来衡量自己的效率和效益水平。

IT效益衡量体系的建立,也让IT自己可以从效益角度分解目标,推动IT内各个部门能够逐年不断提升效率和效益水平,让IT部门的思考方式从成本中心转变到利润中心。近年来绿色数据中心概念和PUE指标被关注,都反映了这一变化趋势。

要注意的是,即使建立了效益衡量体系,要让它真正发挥作用,离不开大量的数据统计和数据分析,以及关键效益指标的可视化和透明化,很多IT组织开始尝试建立IT运维/运营大数据平台,引入可视化和BVD概念,也都和追求IT效益可衡量有密切关系。而这些也会带来额外的投入,IT组织可以根据自身的规模和目标优先级,在有必要的情况下,选择合适和成熟的切入点,分步尝试,逐渐建立效益衡量体系。

让员工满意

互联网企业的火热和各行业互联网+的热闹,都带来了IT人才的争夺,如何吸引和保留高素质的IT员工,已经成为许多IT部门不得不面对的新问题。要让IT员工满意,前面的两个满意(用户满意和老板满意)也是个重要基础,否则IT部门自己地位都不高,员工也没有成就感,士气低迷,满意度很难高起来。

但即使做到了前面两个满意,假如让IT员工每天都疲于奔命,员工满意度同样会差,也不是长久之计。要解决员工满意度的问题,有几个方面是要考虑到的:

  • 提高自动化水平:与运维阶段自动化更关注的是让标准化落地以减少故障不同,运营阶段更关注通过自动化减少员工的重复性劳动,更多地将精力放在能带来更大价值的标准制定和技术优化上面,让IT员工从技术工人变成真正的工程师;(自动化也会带来效益的提升,随着分布式、虚拟化和云计算的普及,自动化已经成为不可或缺的手段,在一些大型互联网公司,人均管理服务器数量早已超过了业界1:200的良好水平)

  • 增加人性化因素:传统运维阶段为了稳定安全不但在软硬件上投入巨大,而且往往在某种程度上不惜增加员工工作的繁琐程度,在人性化方面考虑较少。不少IT组织已经开始从几个方面进行改善:优化流程并引入新工具以减少员工的繁琐文案工作;提供场景化运维能力改善工具的易用性,让IT人员在运维和排障工作中更得心应手,提高IT系统稳定性的同时形成以工作场景为中心的运维方式;与时俱进引入新技术,在保持安全和风控水平的同时改善IT人员的操作复杂度(比如打破僵硬的网络隔离机制、实现移动化运维等);

  • 尝试和引入先进技术:为追求稳定安全,传统IT运维在技术选择和使用上偏向保守,这固然有其道理,但优秀的IT人往往是对新技术有追求的,在技术演进日新月异、新技术传播和应用速度如飞的今天,假如工作中接触不到新技术新思路,IT人的技术追求被压抑,并往往会伴生强烈的技术危机感,会导致对IT人才吸引力和保持力不够。IT部门应在技术规划中重视这一因素,在保证关键业务稳定运行的前提下,有意识有计划地不断尝试和引进新技术,确保技术的先进性,抛开其它收益不谈,但就提高员工满意度和优秀人才吸引力而言,已经是非常值得的。

以上从三个满意的角度简单聊了聊从IT运维到IT运营的一些内容,有趣的是,这些满意是递进和包含的关系,让员工满意包括让老板满意,让老板满意包括让用户满意,让业务部门满意包括让个人用户满意,但每个满意之间又都有各自的个性化内容。

要做到三个满意,让IT从“活着”到“活得好”,从重点“维”稳走向经营业务价值,意味着IT管理要更加精细化、自动化、智能化,也必须建立多样化的数据采集、多维度的数据分析/挖掘和全方位的可视化的能力,IT运营管理的架构也将在传统监管控的IT运维管理架构上有所发展和变化,以适应IT运营在体验、效率和效益方面的更多要求。

需要注意的是,IT涉及到规划、设计、开发和运营多个环节,我们更多的是从运营的角度来谈的,事实上要从IT运维走向IT运营,不仅需要运营部门(不再只是运维部门啦)的努力,也需要规划、管理和开发部门的协同配合和齐头并进。

从IT运维到IT运营,其实标志着IT组织成熟度的提升,假如借用Gartner的I&O成熟度模型来看的话,IT运维更多是在前几个阶段,而更多开始关注IT运营,则标志着IT组织走到了后两个阶段:Service Aligned和Business Partnership,开始把IT本身当做业务来运营,以客户为中心,关注客户体验,运营效率和成本收益。

以上是关于IT运维到IT运营的一些不成熟的思考,抛砖引玉,希望能得到大家的批评和指教。

从IT运维到IT运营,许多IT组织已经在路上,同样也有许多IT产品和IT服务的提供商已经洞悉到这一发展趋势,配合IT运营的要求,开发和提供了许多新的运营工具和运营服务,我们希望能够与各位有志于ITOM领域的同仁们一起,齐心协力,精益求精,共同提供优秀的ITOM产品和服务,为IT从运维到运营做一点事情,让IT不仅活着,而且要活得好,活得精彩。

本文分享自微信公众号 - 成哥的世界(forrest_thinking)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

收藏
评论区

相关推荐

运维监控系统——Zabbix简介
前言对于运维人员来说,监控是非常重要的,因为如果想要保证线上业务整体能够稳定运行,那么我们则需要实时关注与其相关的各项指标是否正常,而一个业务系统的背后,往往存在着很多的服务器、网络设备等硬件资源,如果我们想要能够更加方便的、集中的监
运维安全-信息安全
本文转自 ,如有侵权,请联系删除。
数据库运维做些什么?
一. 数据库生命周期 结合软件生命周期、项目的开展,数据库的生命周期大致可分为这么几个阶段。 (https://imghelloworld.osscnbeijing.aliyuncs.com/8552b8c2942bb8ce23
HADOOP性能优化和运维
集群中任意一个节点都可以被用来提交认任务,虽然通常我们使用master节点提交任务。HADOOP客户端不参与计算和存储,专门用来上传下载文件和提交任务。 性能优化4大块: ![](https://static.oschina.net/uploads/space/2017/0406/111251_QSBe_192561.png) 具体优化如下: 1.选
IT:从运维到运营
_本文转自公众号:傲寒荐书,作者:陈傲寒_ _IT运维?IT运营?_ _都是 IT Operations,有什么区别?_ _IT运维管理?IT运营管理?_ _都是 ITOM,有什么区别?_ _一字之差,只是翻译不同,还是另有玄机?_ _其实,_**中文真的是一门更精确的语言 :-)** * _IT运维是“活着”,IT运营是“活得好”;_
MySQL运维之
**1、mysqldump备份一个数据库** mysqldump命令备份一个数据库的基本语法: mysqldump -u user -p pwd dbname > Backup.sql 我们来讲解一下备份的文件都包含了什么?\-- MySQL dump 10.13 Distrib 5.5.20, for Win32 (x86)\--
AIOps在美团的探索与实践——故障发现篇
![](https://oscimg.oschina.net/oscnet/up-45fc0178edcbec3835316f2c637b1b3f793.JPEG) 一、背景 ---- AIOps,最初的定义是Algorithm IT Operations,是利用运维算法来实现运维的自动化,最终走向无人化运维。随着技术成熟,逐步确定为Artificial
ClickHouse之DBA运维宝典
最近有位网友与我聊天,他是一名 DBA,问我在 ClickHouse 中有没有一些能够 “安家立命” 的运维 SQL 语句。我想对于这个问题很多朋友都会有兴趣,所以就在这里做一个简单的分享。 在 ClickHouse 默认的 system 数据库下(databse),拥有众多的系统表。我们对 ClickHouse 运行状态的各种信息,就主要来自于这
Debezium日常运维手机
关于Kafka-Connect: (1) 是否可以动态添加已有数据的新表?  不可以,Kafka-Connect需要配置先行。如果是已有数据的新表,无法通过修改已有的kafka-connect配置进行新表的Snapshot初始化。 建议通过table white list功能,进行新表的snapshot。然后等到稳定后,再合并到同一个Kafka-con
Flume实战案例运维篇
**Flume实战案例运维篇** **作者:尹正杰** **版权声明:原创作品,谢绝转载!否则将追究法律责任。** **一.Flume概述** **1>.什么是Flume**  ![](https://oscimg.oschina.net/oscnet/cfdbbae527024a725bbc602ba7b8e01d94f.png)
Linux 运维是做什么的
![](https://oscimg.oschina.net/oscnet/up-25a98115c12319b11895484bc9dd5ecd170.png) Linux在现在社会发展是非常受欢迎的一个行业,对于从事Linux方面工作的人来说,属于互联网背后的英雄,没有他们的付出,就没有如今的互联网时代。而在Linux从事岗位之中,Linux运维工程师
Linux日常运维小结
**1\. 如何看当前Linux系统有几颗物理CPU和每颗CPU的核数?** 物理cpu个数:cat /proc/cpuinfo |grep -c 'physical id' CPU一共有多少核:grep -c processor /proc/cpuinfo 将CPU的总核数除以物理CPU的个数,得到每颗CPU的核数。 **2\. 查看系统负载有两个常用的命
Linux运维常见面试题之精华收录
Linux运维常见面试题之精华收录 ================= **1、什么是运维?什么是游戏运维?** 1)运维是指大型组织已经建立好的网络软硬件的维护,就是要保证业务的上线与运作的正常, 在他运转的过程中,对他进行维护,他集合了网络、系统、数据库、开发、安全、监控于一身的技术 运维又包括很多种,有DBA运维、网站运维、虚
Nginx日志运维笔记
在分析服务器运行情况和业务数据时,nginx日志是非常可靠的数据来源,而掌握常用的nginx日志分析命令的应用技巧则有着事半功倍的作用,可以快速进行定位和统计。 **1)Nginx日志的标准格式(可参考:[http://www.cnblogs.com/kevingrace/p/5893499.html](https://www.oschina.net/ac
OpenKruise:解放 DaemonSet 运维之路
![1.png](https://ucc.alicdn.com/pic/developer-ecology/708e1245bd2045e682e5a1a2a5881c19.png) 作者 | 王思宇(酒祝) 前言 == [OpenKruise](https://www.oschina.net/action/GoToLink?url=https%3A%