ITIL理论自译概述.docx

上传人:b****8 文档编号:10932593 上传时间:2023-02-23 格式:DOCX 页数:26 大小:666.33KB
下载 相关 举报
ITIL理论自译概述.docx_第1页
第1页 / 共26页
ITIL理论自译概述.docx_第2页
第2页 / 共26页
ITIL理论自译概述.docx_第3页
第3页 / 共26页
ITIL理论自译概述.docx_第4页
第4页 / 共26页
ITIL理论自译概述.docx_第5页
第5页 / 共26页
点击查看更多>>
下载资源
资源描述

ITIL理论自译概述.docx

《ITIL理论自译概述.docx》由会员分享,可在线阅读,更多相关《ITIL理论自译概述.docx(26页珍藏版)》请在冰豆网上搜索。

ITIL理论自译概述.docx

ITIL理论自译概述

第一章ITIL流程解析

总体来说,ITIL的包括六大操作性流程(五大服务支持流程+一个服务台流程,严格来说,其中服务台应该属于功能,而非流程)和五大战术流程(五大服务提供流程)。

如果说企业的IT战略属于“战略层”的话,我们可以把服务提供称之为“战术层”,把服务支持称之为“运作层”。

每个ITIL流程都包括五大要点:

流程目标、基本概念、主要活动、好处与风险,以及关键绩效指标与报表。

所有流程的结构图如下:

图1:

ITIL十大流程及其服务台结构图

从ITIL的整体架构来看,2002年PaulGraham等专家所著的《ICTInfrastructureManagement》一书中,把ITIL流程之间的关系描绘成如下图。

该图中突出了安全管理的重要性。

信息系统的安全管理也正是IT治理(ITGovernance)的主要内容之一。

图2:

ITIL整体架构

以下我们简要地分析10大流程和帮助台的模块。

一、ITIL的五大战术流程(五大服务提供流程)框架图如下:

1、服务级别管理(ServiceLevelManagement)

本流程通过对IT服务绩效的协商、监控、评价和报告等一整套相对固定的运营流程来维持和改进IT服务的质量,使之既符合业务需求同时又满足成本约束的要求;通过采取适当的行动来消除或改进不符合级别要求的IT服务。

2、IT服务财务管理(FinancialmanagementofITServices)

该模块主要用来全面核算IT服务运营成本,并按照向客户提供的服务项目进行分摊,同时为管理层提供IT投资决策所需的详细资料;还用来对支持IT服务运营的IT资产和资源进行成本效益管理。

IT服务财务管理的主要工作包括:

预算、会计、收费和报表。

3、IT服务持续性管理(ITServiceContinuityManagement)

IT服务持续性管理是指确保发生灾难后有足够的技术、财务和管理资源来确保IT服务持续性的流程。

它包括:

灾难恢复设施的需求分析、灾难恢复计划的制定、计划的更新、测试的执行以及必要时进行实际的灾难恢复等方面。

持续性管理主要通过确保服务运营所需的IT技术和服务设施能够在要求和约定的时间期限内得到恢复,为总体的业务持续性管理提供支持。

4、可用性管理(AvailabilityManagement)

简单地说,可用性管理是在正确使用资源,方法及技术的前提下,保障IT服务的可用性。

当企业营运越来越依赖IT,为了维持竞争力,IT必需避免或减小预期外的当机时间。

可用性管理在深入探讨那些资源和测量是维持最佳营运状态所必要的,希望能让资源的使用最有效。

该流程确保IT服务的设计符合业务所需的可用性级别;对实际的可用性、可靠性以及可维护性进行测度和监控并提交相应的报告以确保有关协议目标的实现;优化IT基础设施的可用性并为改进服务绩效提供建议;减少某段时间内事故对IT可用性影响的频度和持续时间。

5、能力管理(CapacityManagement)

能力管理的目的主要是调整营运需求和IT资源的平衡。

简单地说,能力管理是要确保在合适的时间合适的地点以合适的成本提供合适的资源。

该流程用来分析当前的业务需求和预测将来的业务需求,并确保这些需求在制定能力计划时得到充分的考虑;确保当前的IT资源能够发挥最大的效能,提供最佳的服务绩效;确保组织的IT投资按计划进行,避免不必要的资源浪费。

二、ITIL六大操作性流程(五大服务支持流程+一个服务台职能,严格来说,其中服务台应该属于职能,而非流程)框架图如下:

图4:

服务支持流程框架图

1、服务台(ServiceDesk)

服务台就是通常所指的帮助台和呼叫中心,只不过服务台的概念应该更广一些。

它是一种服务职能(Function),而不是管理流程。

服务台每天为IT用户提供服务窗口。

用户对IT服务存在不满、疑问和建议等,可以反馈到服务台。

服务台同时也是用户使用IT服务的登录点,因此服务台直接映射到IT服务品质。

另外,服务台也要负责尽快地协助顾客恢复服务的运作,比如提供使用索引、修正,或针对某一意外事件的补救措施。

但是服务台不负责意外事件的分析,这种深入分析属于问题管理和事故管理的范畴。

2、配置管理(ConfigurationManagement)

配置管理指识别和确认系统的配置项、记录并报告配置项状态和变更请求、检验配置项的正确性和完整性等活动构成的过程。

配置管理的目的:

维持配置管理数据库(CMDB)中每个IT基础建设的配置记录;提供配置项目(CI)的报表,报表包括一些管理信息如问题记录、变动记录、版本信息、状态信息和关系信息等。

配置管理相当于ITIL的实体控制中心,用来控制和协调各个IT基础架构组件,从而能够更好地支撑服务台的工作。

3、事故管理(IncidentManagement)

事故(Incident)是指任何不符合标准操作且已经引起或可能引起服务中断和服务质量下降的事件(Event)。

事故管理的目的就是在出现事故的时候,能够尽可能快地恢复服务的正常运作,避免业务中断,以确保最佳的服务可用性级别。

事故管理是处理IT的危机并要从中恢复运转,例如有一段时间无法提供服务,这需要将工作转移到另一套系统,而这并不应是平常会遇到的。

我们必须发展一套在面临IT危机时能够恢复正常运转的计划和应急解决方案。

4、问题管理(ProblemManagement)

问题是导致一起或多起事故的潜在原因,问题管理的目的尽量减少服务基础架构、人为错误和外部事件等缺陷或过失对客户造成影响,并防止它们重复发生的过程,以维持一个稳定的IT服务环境。

问题管理一般有发现问题、记录问题、分类问题和分析问题几个过程,从而达到持续维护问题数据库,并实现错误控制的目的。

5、变更管理(ChangeManagement)

变更是指,对已批准构建或实施的或已在维护的硬件、软件、网络、应用系统、环境以及相关文档所做的增加、修改或移除。

变更管理的目的是要确保在IT服务变动的过程中能够用标准化的方法,有效地监控这些变动,以降低或消除因为变动所引起的问题。

这里的“变动”是指一些在IT基础建设项目上的动作所造成一个新的状态;所有在配置项目上的变动都必需纳入变更管理的控制范围。

变更管理不仅要求找到解决问题的方法,更需要变更IT基础设施,以从根本上解决问题或事故。

6、发布管理(ReleaseManagement)

发布管理流程从全局的角度监察IT服务的变化,并确保经过完整测试的正确版本得到授权进入正式运作环境。

发布管理设计和实施有效的程序来分发IT系统的变更,保障所有软件模块的安全性,确认所有的最终软件库中软件是安全可靠的。

同时发布管理还要结合变更管理,准确发布确切内容和首次发布计划。

以上我们简单分析了每一个功能模块的主要目的。

从总体来看,IT服务管理不同于IT管理的一个重要原因在于,IT服务管理更加追求主动式管理的效果,ITIL主动式管理的思想就体现得比较明显,如下图所示的主动式管理。

图5:

主动式管理框架图

第二章ITIL系列专题

ITIL(ITInfrastructureLibrary)是事实上的IT服务管理国际标准。

IT基础设施库(ITIL)包含着如何管理IT基础设施的流程描述,它以流程为导向、以客户为中心,通过整合IT服务与企业业务,提高企业的IT服务提供和服务支持的能力和水平。

ITIL可引导组织离效和有效地使用技术,让既有的信息化资源发挥更大的效能。

(一)IT服务管理从哪里开始?

在ITIL的《规划实施服务管理》中有下面一段话:

  首先实施哪一个流程,这个问题被经常问到。

“我应该首先实施哪个流程?

”真正的答案是:

所有的。

实施所有服务管理流程的真正价值要远大于单个流程的总和。

所有这些流程与其它流程相关,在一些案例中完全依赖其它流程。

  在理解ITIL所有流程的时候有一个前提经常被忽略,那就是经常看到而没有重视的词“IT服务”,这是IT服务管理的对象。

IT服务管理的十个流程、一个功能(服务台)都是围绕IT服务来谈的,如果你的IT组织(或部门)都没有搞清楚你的服务分类(ServiceCatalog),就来实施服务管理流程,纯属扯淡。

一些所谓的咨询公司和厂商更是如此!

餐馆里连菜谱都没有,对着白纸来谈向顾客提供餐饮服务的流程,这是不是很扯淡的事情?

  ITIL是最佳实践,不是理论,不是系统,IT服务管理是ITIL的一部分。

当你搞清楚自己正在提供或将要提供哪些IT服务时,才能够真正地实施IT服务管理。

  所以我对前面那个问题的回答是:

  实施IT服务管理的前提是建立你的IT服务目录,针对你所要提供的服务建立和完善IT服务管理流程。

连提供什么服务都搞不清楚,实施哪个流程,以何种方式实施都没用。

  附件中提供了一个桌面服务目录作为例子。

(二)认识服务管理中的概念

下面以“乱谈”的方式介绍一下服务管理中的基本概念。

  JNV,当今社会较为常见的服务提供者。

  有一天,JNV-A怀孕了,造成不能提供服务,这就是“事故”。

为了尽快恢复服务,只好到小诊所做了手术,两天后服务照常。

这个过程就是“事故管理”。

  JNV-A对“事故”做了回顾,试图找出怀孕的原因,这就进入了“问题管理”,首先回顾服务流程,是否缺少了戴套的动作,然后再检查避孕套,是否质量不合格。

这叫“问题的结构化解决”。

结果发现:

避孕套的质量不合格造成精子能够渗透,从而导致怀孕。

这样“未知原因”转化成了“已知错误”。

  为了解决这个问题,JNV-A打算更换质量更高的避孕套,要花费比原来贵两倍的钱,但与怀孕所造成的服务中断以及为恢复服务所做的手术相比,这种投资是很值得的,最终决定更换质量更高的避孕套,并实际做出了行动。

这叫做“变更管理”。

  经过此事,JNV-A想到,除了这种意料之外的“事故”,还有每月周期性的服务中断,而她的客户在此期间还在打电话请求服务。

为此她联系了JNV-B,JNV-B在JNV-A不能提供服务时为JNV-A的客户继续提供服务,这叫做“服务持续性管理”。

JNV-B的加入也解决请求过多而不能满足的问题,这叫做“能力管理”。

  JNV-A在服务过程中根据价格的不同,提供服务的质量也是不同,提供服务的环境选择也不一样,当然事前也与客户做了沟通,并得到了客户的认可,这叫做“服务水平管理”和“财务管理”。

  JNV-A手头有个小本,记录了客户的联系方式和其它爱好以及对服务环境的要求,还为出手大方的客户创新服务的花样,这叫做“客户关系管理”。

后来听说这种小本经常成为殃及客户的证据,就予以销毁,改用电话机存贮,并对客户名称进行编号隐秘,这叫做“风险控制”。

有人说还缺少一个重要的功能-“服务台”,那就留给你吧。

(三)透视IT服务

前面我谈到了IT服务管理应该从服务的归类(ServiceCatalog)开始,接下来也谈到了IT服务管理在本质上与其它服务管理是类同的。

下面我来谈谈IT服务的组成(基本的示意图如下所示)。

1、服务对象-这是IT服务组织存在前提,正是由于服务对象对IT服务的需求,才使得IT服务组织出现,设计和运营IT服务。

IT服务组织必须清晰认识自己打算服务的对象,这对后面的IT服务设计是非常重要的。

就象做餐饮服务,我针对的是什么样的消费群体,这决定了我要经营一家酒店、饭店、小吃店,还是饮料店。

  2、服务产品-这是IT服务组织存在的基础,正时IT服务组织能够针对客户对IT服务的需求,设计和运营不同的IT服务产品,才使得客户愿意为此付费。

就象餐饮服务中,要有一本菜单,告诉客户你都有哪些服务产品。

  3、基础设施-这是IT服务组织提供服务的基础,包括各种环境、各种IT组件等等,它们使得你承诺的服务产品得以实现。

这些也是IT服务成本的重要组成部分。

就象一家饭店,必须有餐厅、厨房等环境,也必须有厨具等。

  4、服务职员-这是IT服务组织实现服务最核心的要素,他们拥有不同的技能,在服务的各个环节承担不同的角色,履行其相应的职能,使得IT服务得以运营。

就象饭店中,有服务员,有大堂经理,有大厨,也有配菜,还有采购的。

  5、合作伙伴(供应商)-这是IT服务组织保障服务正常运营的重要资源,他们提供基础设施或基础设施组件以及相关的技术支持,提供IT耗材等,有时他们本身也是IT服务组织。

  IT服务与其它服务行业有很多相同之处,也有不同之处,这就象其它服务行业间一样。

IT服务逐渐会从IT技术中分离出来,成为一个产业,它的发展主要取决于服务运营模式,而不是IT技术的创新。

就象饭店,菜样翻新固然能够吸引客户,但使饭店长期生存的还是它的服务运营模式。

这样的例子不胜枚举。

(四)透视IT服务管理

其实前面已经谈到,IT服务管理与其它服务管理在原理上是相通的,在IT服务管理中所定义的术语“事故”、“问题”、“变更”等等并不是IT服务管理所特有,在其它服务管理中是通用的。

(参见专题二)。

所以说管理的原理是相通的,管理的对象是独特的。

  在服务支持的五个流程中,分别是都有其独立的管理对象,但在流程间这些管理对象又是相关的,这些管理对象可以实例化,形成记录,与IT服务相关,但不是IT服务的属性。

所以可以采用面向对象的设计方法来设计这些管理流程,也就存在如下的通用方法:

  一、设置流程经理,负责设计和改进流程,实现对管理对象生命周期的全过程管理;

  二、对管理对象进行分类,一般分为三个层:

类别(Class)、类型(Type)、条目(Item);

  三、确定优先级,优先级由影响范围和紧急程度矩阵来确定,所以需要对影响范围、紧急程度进行分级,以便构成优先级矩阵;

  四、设计对象的属性和生命周期状态;

  五、管理对象实例化后,每个实例必须有其所有者(Owner),负责该实例生命周期的状态变化。

执行活动导致状态变化的人多数情况不是实例的所有者。

  分类的一般思路:

  事故分类:

事故是与服务紧密联系的,所以事故的分类应该与服务的分类一致。

  问题分类:

首先可以在类别上分为流程、操作、故障,故障细分与配置项的细分一致;

  变更分类:

变更的分类与问题的分类一致;

  配置项分类:

按照IT组件的类型逐级细分;

  发布分类:

与服务的分类一致;

  服务交付的五个流程的管理对象都是IT服务,这五个流程分别管理IT服务的五个属性。

例如,我们提供了打印服务,通过这五个流程分别管理打印服务的可用性、持续性、容量、财务、服务水平,这些属性都可以为其规划所要达到目标,通过流程来保障目标的实现,对这些流程的管理采用“PDCA”环的方式来提高。

  如果用应用系统分类的观点来看,服务支持流程是“交易系统”,每条记录反映了一个事件或一个实物,服务交付流程是“管理信息系统”,通过对“交易数据”按“服务”汇总,反映了“服务”在一定时期的各个方面的状态。

即如果建立相应的IT系统的话,服务支持平台用数据库就能实现,服务交付平台则要用数据仓库才能实现。

(五)企业文化影响

  大家可能经常可以看到讨论实施ITIL失败或效果不佳的原因,考虑得较为全面的,会从两个方面来分析,一是管理,二是技术。

在这里我谈一下第三个方面-企业文化。

  “企业文化”这个概念很难定义,所以从以下方面,结合实际案例,谈一下企业文化的影响。

  服务意识-在IT组织实施IT服务管理时,在这个组织内就得推广服务意识的文化:

IT部门不再只是技术的提供者,而是把自己看作信息技术服务的提供者。

  例子:

当IT部门只是技术提供者时,业务部门向IT部门提出需求:

我部门需要一台打印机。

IT部门说没问题,我买一台打印机提供给你部,告诉我你想要什么型号的。

  当IT部门是服务提供者时,业务部门向IT部门提出需求:

我部门需要一台打印机。

IT部门向业务部门询问:

你是用来打印交易流水,还是打印办公文件?

如果打印办公文件,可能用到的纸张型号是哪些?

需要彩色打印吗?

是一个人使用还是会多人共享?

确定服务需求后,IT部门会建议:

根据我们对市场的了解,可以给贵部提供一台XX型号的打印机,并把设置成网络打印机,使得贵部所有人都可以使用。

这样你们就得到了我们提供的打印服务。

这项服务的成本是XX。

或者建议:

根据你们的使用人数和频度,贵部可以与XX部共享一台彩色打印机,这样你们同样得到了打印服务,而且分摊到贵部的成本是XX,同时也降低了XX部门成本。

  在一次ITIL培训中,我曾经讲到IT组织的成长模型,见下图。

参加培训的人员就说我们已经达到了第二阶段,我们把自己看作了服务提供者,当我用上面的例子来问时,他才认识到,他所在的组织并没有在实际工作体现出来服务提供者,也难怪业务部门不把他们看作服务提供者。

  绩效考核-在实施服务管理时,做的最多的事情恐怕就是建立或梳理各种管理流程,使得管理流程化、管理数字化。

其目的是要每个IT职员(包括管理者)遵循流程办事,通过流程中记录的数据反映IT职员的绩效,反映的绩效一定要与IT组织的绩效考核、奖惩相联系,否则实施IT服务管理就不会有明显效果,甚至肯定要失败。

例子:

某个IT部门,建立了工作日志系统(类似于HELPDESK的系统),要求每个员工都要在工作日志系统记录自己接受的工作、完成的情况等,到了年底,部门评优的时候,还是采用无记名投票的方式,一些大家公认不错员工被评上了,还有一些与领导关系紧密的员工被悄悄地加上了。

在第二年,大家纷纷找出各种理由不再使用这个工作日志系统,诸如,耽误工作时间了,设计得不够方便了,等等。

最本质的不再使用的原因大家都应该很清楚了。

  在谈到ITIL失败原因时,有人强调管理层的不支持是一个原因,但在实际工作中,可能经常遭遇到的“假支持”。

例如,管理层会在各种场合说:

实施ITIL是对组织有利的好事情,我们就是要把问题暴露出来,我们就是要全面反映每个人的工作成果。

但是在真正遇到问题时,管理层却采取的是掩盖问题的做法,涉及到利益时,管理层却是首先考虑自己,照顾自己的小团体。

当企业内,管理的基本原则就不被遵守时,企业都可能失败,IT服务管理注定是要失败的。

  语言统一-ITIL的推出,最重要的是它能够用来统一IT服务管理的“语言”。

统一管理术语、统一技术术语,是企业文化建设的重要环节,也是推广IT服务管理的必要基础。

例如,在当前的一些ITIL中文资料中,有的将Incident翻译成“事故”,有的翻译成“事件”;在讨论配置管理时,有人理解的配置管理数据库不仅只是记录配置项信息,还包括配置项自身(特别是软件配置项),而有人理解配置管理数据库只是包括配置项信息,软件配置项实际存贮在最终软件库(DSL)中;ITIL中的配置管理与应用开发中的配置管理是什么关系?

  这样的例子不胜枚举,想信大家都会有同样的经历:

争论了半天,我们的思路是一致的,只是由于大家对同样的词汇,所理解的定义不同才造成的。

统一语言的方法最好是遵循同样的标准文档,例如,都采用ITIL中的定义,但事实上,现在众多的出版物带给IT组织困扰,同一个词汇在ITIL、COBIT、ISO27001、PMBOK等书籍中出现了有差别的定义,或者找不到定义,这时,只要在组织内确定一个多数人认可的定义,要求大家都遵循这个定义就可以了。

  只有“语言统一”了,在组织内大家才可以方便、有效地交流,才能对目标认同,就象“一中两表”,肯定是不能达成共同目标的。

(六)认识IT业务运营

我在银行工作多年,经常看到这样成对出现的两个词:

信息科技和业务(ITandBusiness)。

在银行里也看到IT部门和Business部门,本来应该是伙伴关系,却往往成了对立关系。

IT部门经常这样抱怨:

业务部门都不清楚自己的需求,导致我们的IT系统在开发和运行期间经常需要变更。

也经常会指责:

你们(业务)的流程就不清楚,我们(IT)怎么给你们做系统支持你们的业务发展?

还是先把流程搞清楚,把需求写清楚我们再谈吧。

我们知道,银行是提供金融服务的企业,为了把金融服务做好,获得市场先机和优势,就要确定其业务目标,定位其客户群体,研发其金融产品和服务,设计其服务流程,建设其信息系统,提高其服务质量。

同样的道理,不管是大企业内部的IT部门,还是处于市场中的IT公司,它们都是经营IT服务的组织,亦即它们在进行IT业务运营(ITBusinessOperation)。

如果想做好IT业务运营,是不是也应该确定其业务目标,定位其客户群体,研发其IT产品和服务,设计其服务流程,建设其信息系统,提高其服务质量呢?

答案是肯定的!

事实上,企业内的IT部门或市场中的IT公司要把IT业务运营做好,重要的是确定自身的定位和目标。

为了目标的实现,进行IT业务流程建设,为了支持IT业务流程的运转,建设相应的支持系统。

ITIL作为最佳实践,是对IT服务的提供和管理提供了指南,告诉了IT组织如何认识IT业务,从而用面向流程的方法将其做好。

所以,IT组织应该认识到,在IT组织内推广ITIL,只是将IT业务运营做好的一个必要条件,而不是充分条件。

例如,一家提供应用软件的企业,除了ITIL之外,还有许多必要条件需要去满足,诸如实施项目管理、提高质量管理等等。

(七)启动管理改进的项目

  我们都知道:

ITIL是一种最佳实践。

所谓最佳实践,就是指导做事的最好的方法,方法是用在特定环境,解决特定的问题。

所以,在一个组织内,实施ITIL就是向大家营销最好的解决IT管理问题或实现IT管理目标的方法。

那么如何才能让大家认识到它是最好的方法呢?

  我们需要通过“IT管理改进”项目证明!

在ITIL中的《规划实施服务管理》一书中,给出了实施管理改进项目的方法,见下图。

  

  建立IT服务台,实施事故管理、问题管理等流程都不是IT管理改进项目的目标,只是进行IT管理改进的方法,而实施项目是为了完成特定目标的,目标是根据当前面临的管理问题来确定的。

可以通过下述方法来确定当前项目需要完成的目标。

  通常来说,当我们面临一个事故或需要解决一个问题时,我们应该从三个方面来看:

  工具方面:

我们是不是缺少工具或工具落后,使得事故前兆没有被发现才导致事故的发生?

  流程方面:

这个事故是第一次出现吗?

我们有没有相应流程来防止同样或类似的事故不再发生?

  人员方面:

发生这样的事故是操作人员的技能不足吗?

有没有相应的知认管理使得人员的经验不断积累,技能不断提升?

  上面就是经常看到ITIL中提到的P(人员)、P(流程)、T(技术)。

当通过上述方法找到了IT管理问题的根本原因,才能确定“IT管理改进项目”的目标,才能启动IT管理改进项目。

许多ITIL项目的失败的主要原因就是没有明确的项目目标就启动项目。

 

(八)流程的管理

在实施“IT管理改进”项目时,一个重要的管理对象就是—流程,下面谈谈流程的管理。

 关于流程的基本概念

  流程—由执行人执行的一系列连接的动作、活动、变化等,以满足目的或达到目标。

流程的主要输出就是目标的结果。

  流程控制—为了有效果和有效率地执行流程,所进行的流程规划和调整。

  流程的效果—如果流程的输出达到了业务目标所要求的规范,那么流程就是有效果的;

  流程的效率—如果流程中的活动只需最小的努力就可以完成,流程就被看作是有效率的。

流程管理中的角色

  在流程的管理活动中,我们定义以下角色并赋予其相应的职能:

   流程管理员或流程总监

    其职能类似系统架构师,负责:

    负责组织内流程管理的规划,避免流程目标的重叠和遗漏;

    制定和发布流程文档规范,指导流程文档的创建;

    创建和维护流程文档库,在组织的不同层级、不同范围发布流程;

    受理流程建议,组织、协调和跟踪流程建议的落实;

    向组织各层级提供流程建设的报告。

  流程所有人

    其职能类似程序员,负责:

    制

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 高等教育 > 教育学

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1