前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >值得大家关注的【服务目录】

值得大家关注的【服务目录】

作者头像
彭华盛
发布2020-07-17 10:09:23
2K0
发布2020-07-17 10:09:23
举报
文章被收录于专栏:运维之路运维之路

一、梳理一些背景知识

完善知识体系先从专业背景知识开始。

1、看IT服务在IT组织角色演进

在金融企业中,IT组织架构通常包括以下职能:IT规划管理,即根据公司战略及业务发展,设计IT体系架构和部署线路;IT研发管理,即根据现有IT系统架构和系统,受理业务功能优化需求,支持业务开展;IT运维管理,即提供基础设施环境支持,确保业务连续性、可用性、安全性,提供IT运营服务支持;以及,其他IT项目管理、人员管理、外包管理等。在这样的组织架构中,IT部门主要承担成本中心角色,主要以技术提供者身份出现,强调被动支持业务需求与运行保障。随着业务与科技的快速发展,IT系统环境发生了巨大变化:架构层逐渐从本地化转向云化、虚拟化,应用层的应用数量激增,迭代速度加快,业务复杂度与系统架构越来越复杂,系统间关联度高,数据量呈指数级增长等,而现有被动支持业务需求的成本中心的工作模式将受挑战。因此,IT部门需要由被动向主动转型,首先是向强调IT主动服务能力的服务中心角色转型,目标是打造敏捷型的团队,提升IT交付效能,更好的支撑业务发展的需要。在实现服务中心后,下一步是关注并致力主动利用数字化技术创造新的业务机会,从IT资源中寻求更多的业务突破,引领业务创新,即由服务中心向业务创新中心转型。在实现业务创新中心的同时,近年来不少商业银行在向利润中心转型,为企业外部市场提供IT服务,从而为企业创造更多收入。

上面的演进可以看出,IT服务是当前大部分IT组织需要推进的建设方向,事实上这也是ITIL一直在强调的IT服务管理。

2、ITIL前世今生

ITIL前世今生大概这样:二十世纪80年代末,英国政府为了政府部门信息系统管理标准化而制定的一套标准。发展至今天,ITIL目前到了第五个版本ITIL4,是一套IT服务管理的最佳实践方法,很多中大型企业的IT部门仍以ITIL或与ITIL相近的最佳实践作为标准。

ITIL一共有5个版本,分别是:ITIL V1,ITILV2,ITIL V3,ITIL 2011,ITIL4。大体看,V2以前主要提倡流程管理的思路,V3以后则强调IT服务,服务则涉及服务战略、服务设计、服务转换、服务运营、持续的服务改进。最新的ITIL4,在原来的版本上整合了一些敏捷、DevOps、精益、IT治理、领导力等工作方法,将IT组织内的运维、研发、测试与IT组织外的业务、客户的协同整合到了一个整体的方法,提供一个数字服务的管理模式。ITIL4的具体内容我需要去学习一下,具体内容大家可以上网找找,这里提供V3的一个经典的架构图:

3、ITIL与ISO20000、ITSS是什么关系?

ISO20000是国际标准化组织参考ITIL设立的标准,国内很多金融企业或乙方企业去评这个认证。因为要认证,也说明ISO20000主要提供一个管理框架,提供一些相对明确的评估标准,而ITIL是一套最佳实践供企业参考,同时提供个人学习考取认证。我觉得,ISO20000更像是ITIL的一个缩小版的标准。

ITSS是工业和信息化部制定的一套标准,也是一套标准,从人员、过程、技术、资源几方面进行标准化,采用PCDA持续优化的方式推进IT组织的完善。ITSS发展至今天,里面包括了很多标准,涉及面很广,如果去ITSS的官网你会发现很多IT的标准都有,大家在找一些体系的东西时可以到上面取经。这些标准中,ITSS.1这个与运维相关的标准与ISO20000有一些相似之处。

总的来说,ITIL是最佳实践,ISO20000、ITSS是国际和国内的两个标准,个人学习认证找ITIL,企业认证找后面两个。

4、ITIL与ITSM是什么关系?

ITSM (ITService Management),从原本意义看是一套IT服务管理方法论,现在大部分企业将ITIL作为ITSM的指导思路,并形成一个信息化的IT服务管理系统。通常会包括IT服务台,并以生产变更、事件、问题、配置、发布等服务支持流程,以及服务可用性等服务管理流程。国内很多企业在推进ITSM时,通常仍以服务支持流程为主,比较少关注服务的价值交付,这也就是你会发现大家一讲ITSM通常只会想到生产变更、事件、问题、配置、发布等服务支持流程,实际上还有很多东西可以去完善,比如接下来要讲的服务目录。

5、DevOps将替换ITIL吗?

我个人观点是:DevOps将推动ITIL的进化,ITIL仍将作为运维组织IT服务管理的核心指导思想。因为:

从涉及的面来看,ITIL大于DevOps,相比较的话更体系化(当然也有些人,尤其是DevOps厂商或Dev的同学把DevOps的含义扩展开了,这里暂指比较标准的定义);

从最佳实践的指导上,ITIL有更为明确说明,比如组织的设置、角色的定义、流程的规划与设计等等,DevOps更多是一种指导思想;

DevOps在自动化、精益、敏捷等方面的思路,将推动ITSM与ITOM融合,以支持DevOps思想的落地。

从目前市场上新一代的ITSM管理系统来看,己经对以前ITSM的系统交互体验进行了优化,表单的敏捷配置,支持与ITOM的监控、自动化、云平台、CMDB等系统互联互通等方面进行优化改造。

6、SLA、SLO和SLI

SLA(Service Level Agreement):服务水平协议,是IT服务提供方和被服务方之间就服务提供中关键的服务目标及双方的责任等有关细节问题而约定的协议。

SLO(Service Level Objective):服务质量目标,服务提供方与服务需求方对服务期望,比如系统可用性是4个9,还是3个9。

SLI(Services Level Indicator):服务质量指标,SLO需要通过一系列SLI技术指标指标细化并量化,比如上面的可用性可能会转化为运行时长,故障时间等,性能的话会转换为响应时长、成功率等。

三者的细节可以在《google SER运维解密》一书中有一章专门进行介绍。这里推荐做运维数据平台的同学关注一下SLI,是一个很有意思的切入点,具体的内容后续我再梳理一下。

二、聊聊服务目录

云的自助式,所见即所得,按需获取,量化服务成本等特点已在IAAS、PAAS、DAAS上得到验证,在IT数字化空间中,XAAS(一切皆服务)是IT组织的一个转型方向。在IT组织内部将IT能力标准化,形成服务目录,企业中用户能够像进入电商系统上,找到自己所需要IT支持的服务,并申请服务,同时用户能够在线获得服务的反馈,并利用社交化的手段对服务水平进行评价推动IT服务质量的持续提升。这里的IT服务目录是将IT所有内部、外部服务加以整合、标准化,为服务供需双方提供线上连接的工具,并与服务台、知识库、自动化、云平台等连通,提供人工、半自动化、全自动化多样的能力。

服务目录主要为了应对以下问题:

  • 业务不知道IT能够提供什么服务,有些业务认为和“电”相关的都和IT有关,有些认为只有软件开发才与IT有关。
  • 业务、IT对于IT服务的定义或期望不匹配,是否所有系统的可用性都应该是4个9,所有IT需求都应该是一周内迭代上线?
  • IT作为成本中心,源源不断的消耗公司资源,IT价值是好是坏如何衡量?IT服务是否有成本?有限的成本应该往哪个方面倾斜?
  • 以成为中心为基础的IT组织充当被动的角色,缺少可量化的服务质量水平与清晰的计划,主动的持续优化服务质量。
  • IT服务的支持以经验导向为主,IT组织缺乏一个有效的、便捷的、一站式的服务协同工具,IT可以快速上架服务,业务可以透明的获知服务反馈,管理上可以基于服务交付数据进行持续优化。
  • IT组织内团队如何保持激励机制,需要提供工作机制推动IT组织内由被动向主动转型,提升IT价值。
  • IT组织关键的价值链是什么?每条价值链路实际运营情况如何?如何持续提升?
  • ……

下面我梳理一下服务目录的一些信息。

1、服务目录概述

服务目录定位为IT服务的集合,在具体某个服务上需要定义服务,在服务的交付上与云思想类似,即将IT组织的能力标准化,线上化,用户可以按需在服务目录上查找自己需要的服务,并进行申请,比如像IAAS云厂商对外提供的服务能力:

在具体构建IT服务目录时,我们首先需要对IT服务进行分类,参考BMC的服务目标框架可以划分如下:

  • 业务服务:针对产品或业务中相对独立,可归纳为单独流程的服务,比如咨询、销售、售后等。
  • 共享技术架构服务:针对一些原子或底层的服务支撑,是大部份IT服务的组成部份,比如基础设施,网络、平台级的服务。
  • 技术服务:针对应用系统可用性,资源交付等服务支撑,是为了业务连续性或计算要求而提供的服务
  • IT配套服务:针对研发、咨询、业务支持、桌面、账号、权限等配套服务支持。

上面的分类我个人觉得逻辑不是特别清晰,具体的企业实际特点进行划分,比如按IT组织有分工进行划分,划分为研发、产品、测试、运维等服务目录,或按IT组织价值链路来细分:应用连续性保障、软件交付、IT资源交付等。

服务分类的过程,是IT组织将IT具体的工作标准化,抽象归类,线上化,是对现有IT服务管理工作数字化的一个过程。以一个手机证券系统运行为例看看对应的IT服务:

  • 在哪些基础设施服务上,在哪个机房,用了多少机柜,每个月多少电……
  • 使用了哪些基础软件服务,用的是实体机还是虚拟机,或容器,使用的操作系统、数据库、中间件是什么,版本是多少……
  • 系统的可用性的保障对应了技术服务涉及的人、财、物如何分配
  • 投入了哪些人力进行用户支持服务,培训、服务台、参数维护、数据维护……
  • ……

有了上面的服务清单,SLA便不仅仅是一个协议,而是一个完全数字化的解决方案。当然,服务目录完整的建立,涉及IT服务管理全生命周期的梳理,是对IT价值链的标准化、线上化、数字化的过程,需要在规划、设计、运营多个维度进行分解。

2、服务目录的可视化表达方式

传统IT组织的服务目录的系统表现形式如下图,提供一个界面可以让人按照自己所需找到服务入口,比如这种类型:

也有一些服务目录,将服务与知识库、服务台打通,形成这样的模式:

总结一下,即是将IT所有内部、外部服务加以整合、标准化,为服务供需双方提供线上连接的工具,并与服务台、知识库、自动化、云平台等连通,提供人工、半自动化、全自动化多样的能力。这里在体验上是可以考虑借鉴我们熟悉的电商操作方式,以商户为例,当你知道你需要什么品牌、什么型号的商品时,你可以在商品目录中找到商品;当你大概知道你想要什么商品时,你可以利用统一搜索找到商品;当你不知道商品具体叫什么名称时,你可以利用在线客户。服务目录也可以包括服务的介绍、服务时效性、负责人等基础信息,功能上支持用户通过自助式检索申请服务,也可以通过联系IT服务台解决问题。在服务的具体设计上,则加入一些体验上的设计,比如对服务进行打分,服务的在线处理轨迹等功能,提升服务的质量,引入社交IM集成chatWork的解决方案等。

3、服务目录在数字化转型中的意义

上个月,嘉为贺勇总跟我分享了一个ESM(企业服务管理)的词,我找了一下资料和上面的思路很像,其实就是在企业中,IT服务台与IT服务目录解决了IT问题,而其他中后台部门或组织(比如人力、采购、结算、资金、风险、培训等)也能看到这种优势。但是,在企业中,我们不能期望这些中后台部门也去建立XX服务台、XX服务目录。不仅从成本和人力看不合适,从企业员工或一线业务角度,他们也不想知道他们遇到的问题或协同是谁来处理,他们希望企业有一个一站式的协同解决方案。此时,企业服务目录便是数字化时代企业内部协同的一个方法,这个方法当有各多的部门参与时能够发挥更大的作用,比如一个新员工入职,即可触发多种变更流程:人力资源部门设置薪资、福利,IT或资产部门提供电脑、邮件账号,办公工位等等。

在数字化时代一切皆服务的背景下,所有工作都将在数字化工作空间中开展,服务目录是一种可以连接企业内外部资源的一个协同模式,将不仅是面向IT的服务支撑。举几个类似的例子(可能这些例子没有使用服务目录的名称,但作用差不多)。

广东政务网:将大量民生的服务整合在一起,用户一站式得到政务服务。

京东:同上,只不过是将线下的商品转成线上的商品,也可以作为服务的一种。

最后用一张图关于ESM的图来收个尾:数字时代的,ITSM这种服务管理的方式结合数字化手段,可以考虑平滑的过渡到ESM。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2020-07-15,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 运维之路 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
CODING DevOps
CODING DevOps 一站式研发管理平台,包括代码托管、项目管理、测试管理、持续集成、制品库等多款产品和服务,涵盖软件开发从构想到交付的一切所需,使研发团队在云端高效协同,实践敏捷开发与 DevOps,提升软件交付质量与速度。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档