写点什么

IT:从运维到运营

  • 2020-03-16
  • 本文字数:7002 字

    阅读完需:约 23 分钟

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 不仅活着,而且要活得好,活得精彩。


本文转载自成哥的世界公众号。


原文链接:https://mp.weixin.qq.com/s/VqphIrHZ_JTFg3nwt41YPg


2020-03-16 20:282438

评论

发布
暂无评论
发现更多内容

Android 上的 Kotlin 协程

Changing Lin

9月日更

译文:为什么超链接是蓝色的?(一)

姬翔

即时通讯系统架构设计-如何设计一款WhatsApp

OpenIM

耗时大半个月收整全套「Java架构进阶pdf」没白费,Github上点赞破十万!

Java 程序员 面试 计算机 金九银十

JVM 内存模型学习笔记(二)

风翱

JVM 9月日更

什么是数据粒度

奔向架构师

数据仓库 9月日更

中秋节如何拍月亮

卢卡多多

9月日更

Java“锁”事

中原银行

Java 中原银行

汽车行业的进化秘诀,竟在这座智慧出行乐园中……

脑极体

惊掉下巴!这本Alibaba百万年薪必备—高性能架构路线震撼出世!

Java 编程 程序员 架构 计算机

Node 编码规范 -努力做得更好

Geek_25b8d1

node.js Node 规范

JavaScript进阶(三)模块化

Augus

JavaScript 9月日更

博睿数据 短信服务监测解决方案专场直播

博睿数据

权威报告显示:BATH坐稳中国四朵云

科技热闻

边缘使用 K8s 门槛太高?OpenYurt 这个功能帮你快速搭建集群!

阿里巴巴云原生

阿里云 云原生 边缘计算

【直播预告】阿里云服务网格 ASM 产品易用性改善实践与思考

阿里巴巴云原生

阿里云 云原生

数据结构与算法:缓存置换算法

正向成长

LRU 置换算法

【优化技术专题】「温故而知新」基于Quartz系列的任务调度框架的动态化任务实现分析

洛神灬殇

Java quartz 任务调度 9月日更

linux之fping命令

入门小站

Linux

别把云原生想复杂了

dinstone

微服务 云原生 云平台

autojs自动化框架简介

IT蜗壳-Tango

9月日更

Prometheus 2.22.0 新特性

耳东@Erdong

Prometheus 9月日更

【Vuex 源码学习】第六篇 - Vuex 的模块收集

Brave

源码 vuex 9月日更

探索:北鲲云超算平台能否应用于中医药行业

北鲲云

CSS交互动画指南之transition

devpoint

CSS css3 transform 引航计划 9月日更

阿里巴巴最新最全800道Java后端面试大全(值得收藏)

Java 程序员 编程语言 java面试 java架构

网络攻防学习笔记 Day140

穿过生命散发芬芳

9月日更 网站安全基础

小小感悟

Nydia

【LeetCode】回文链表Java题解

Albert

算法 LeetCode 9月日更

产品分析:谁是利益相关者?

石云升

产品经理 9月日更

在线JSON转jsdoc工具

入门小站

工具

IT:从运维到运营_软件工程_成哥的世界_InfoQ精选文章