it运维体系架构图（it系统架构图）

本篇文章给大家谈谈it运维体系架构图，以及it系统架构图对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享it运维体系架构图的知识，其中也会对it系统架构图进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、大企业应该如何高效管理自己的IT系统
• 2、智能运维是什么？
• 3、互联网时代的网络自动化运维
• 4、IT运维服务管理中知识管理的思考
• 5、ITIL图的ITIL产生的背景

大企业应该如何高效管理自己的IT系统

计算机技术在企业中的应用越来越广泛it运维体系架构图，从最初的简单计算到初级办公，到现在的大型应用系统，计算机应用越来越来越深入到企业的各个方面，企业对计算机应用系统的依存度越来越高。而基础网络系统(网络设备、线路、服务器、桌面电脑等)则是计算机应用系统的运行保障，就好比是高速公路，路通则信息通，因而基础网络系统的运行情况对现代企业各项活动开展起着非常重要的作用。为了应对基础网络的运维，各企业应用多种管理手段、技术手段对IT运维进行提升，比如划分职能科室(组)、职能人员(网络管理员、网络安全员、系统管理员、数据库管理员、现场管理等岗位)是管理手段，应用ITSM(IT服务流程管理)、桌面安全管理、网管、活动目录服务等系统是技术手段。其中有的职能重复，有的系统交叉，本文以的笔者所在企业IT运维现状为背景，探讨IT运维的发展模式，旨在优化大型企业IT运维模式，更好地为企业服务。
1 IT运维现状分析
不同企业IT运维方式大不相同。由于不同地域，不同行业计算机应用发展水平不同，造成不同企业的管理模式大不相同，比如银行系统，由于计算机普及应用较早，地域分布较广，计算机应用及运维发展较快；而某些大型企业，由于管理者偏重主营产品，忽视在IT基础设施及应用系统上的投入，因而IT运维服务处于较低水平。
同一个企业IT运维方式也存在差别。同一企业，如果规模较大，二级单位较多，由于管理方式差别，运维模式也有较大不同。比如有些企业维护人员多，有些少，有些企业采用传统方式运维，有些企业则重视应用先进的管理系统等，这些原因造成同一企业内部的差别。
2 理顺思路，建立合适的IT运维架构
IT运维的目的
IT运维的目的主要有三个it运维体系架构图：第一个是提供一个稳定高效的基础网络平台，为各种计算机应用系统的正常运行提供保障；第二个是为客户提供满意的服务，使客户端与计算机相关的故障能快速地得到解决；第三个是节省人力，提高工作效率，快速处理基础网络的故障。正是基于这样的目的，所以企业在基础网络方面不断加大投入，在管理上不断创新。
分析企业目前各个应用系统
基础网络是为应用服务的，所以it运维体系架构图我们可以分出哪些系统是属于基础网络的，哪些系统是属于企业应用类的，比如某大型企业的信息系统中，ERP、MES、LIMS等系统是属于应用服务类系统，直接面对终端用户，而网管系统、桌面安全、ITSM、数据存储备份等则是属于基础网络类的，其中ITSM是直接为用户提供服务接口的，其它则是作为IT基础管理系统。对于应用服务类的系统我们要分析其可能故障，并理清解决的流程；对于基础网络类的系统，我们则要将其置于流程之中，理清如何协作才能更好地为用户层的应用系统服务。
建立合适的IT运维架构
传统的运维框架很简单，基本是负责人制，碰到运维方面的问题时由负责人分配工作，这样的方式初期运作简单高效，但随着企业规模的扩大及计算机应用的普及，传统作业方式受很多因素影响，比如分配工作难、耗费人力多、处理问题能力要求高、工作量大等，所以企业迫切需要新的IT运维模式。
某大型国有企业，对基础IT运维相当重视，近几年相继在各分公司推广部署桌面安全系统、防病毒系统、网管系统等，各分公司也针对企业实际情况上做了一些很好的系统，比如某大型企业应用的ITSM系统、上网行为管理系统，这些系统之间有些重复，但各有侧重，那么如何使各系统有机结合，建立一个合适的IT运维框架则是必要的。笔者从某大型企业IT运维现状出发，提出一种IT运维架构，仅供讨论，如图1所示。
图1中ITSM为用户服务接口，内控则是管理接口，用户端的问题进入ITSM系统后，按问题分类或业务分工进入相应的基础网络系统或应用系统处理，各系统也需要分别建立相应的运维架构，比如防病毒系统可以建立。
图1 IT运维架构
如图2所示的运维架构。经各系统处理完后反馈给用户并进行归档，内控则对整个运维过程进行规范化控制。
图2 防病毒体系的三级运维架构
3 优化结构，建立合适的运维流程
分析IT运维需要处理的各种问题。IT运维所需处理的故障种类很多，硬件故障还是软件故障、内部网故障还是外部网故障、系统问题还是病毒问题、用户端问题还是服务器端问题，网络设备问题还是应用系统问题等，列出工作中已遇到过的问题以及可能出现的的问题，通过分析，然后再来建立我们的流程，是建立合理流程的依据。
结合组织结构，建立合适的运维流程。IT部门一般按专业划分科室，比如网络、系统、应用开发、工业控制等，这种划分是以水平层面来管理的，传统管理模式基本都是这种方式，而新的基础IT运维系统要求以专业及技术水平来进行竖直层面的分工，比如ITSM要求一线处理现场基础问题，二线处理复杂问题，经理处理全局问题及疑难问题，从而对不同层次提出了不同的技术要求，因此企业需要在水平与竖直两个层面上找到一个平衡点，来建立合适的管理模式。结合企业实际情况，经过结构优化后，建立各个系统的运维流程，图1的运维架构显示，各个系统之间是相对独立而又相互联系，因此相应的流程必定是相对独立而又相互联系的。
4 防患于未然，注重日常管理工作
建立各系统的管理办法、推广预知维修思维。正如象设备维修由最初的事后维修发展到预知维修模式一样，IT运维模式同样要注重预知维修，即是在问题出现之前，根据一些监测系统(比如网管系统)、日志记录系统等发现异常现象，将故障消灭在萌芽状态。现代企业对计算机信息系统的依赖性越来越高，要求也越来越高，比如某大型企业的MES、ERP、IC卡等系统，要求7 X 24 h工作，任何一次小小的故障都可能造成巨大的经济损失，因此减少信息系统故障率是非常重要的。要做到预知维修，具体到工作中就是要建立各个系统的管理办法，其中要包括异常监测和应急处理等内容，一些关键系统必须有日报，周报或月报。ITSM系统中的常见故障和经验汇总功能即是预知维修思维应用在现代管理上的体现。
建立完善的文档资料。网络系统里的资料再详细，也有出故障甚至丢失的可能，维护良好的文档对于IT运维很有帮助。资料整理除了要求全面，清晰外，还需要满足两个原则，一个是动态更新，过时的资料会误导对事情的了解及判断；第二个是让一个新人能看明白，完全不了解情况的新人(具备专业知识)通过资料能了解现状，则说明这是一份高质量的资料。比如，企业网络连接的文档资料，好的文档的关键不是把每个连接到各个图形的工作站(假设保持最新信息)都进行归档，而是把注意力集中到网络互联(拓扑、交换机和路由器)、服务器、网关和防火墙上。路由器和交换机没有必要用图形(类似设备的图形)表示，用简单的几何形状(如五边形、圆、方块和矩形)表示即可。例如，总使用一个八边形表示一个核心层交换机、用五边形表示汇聚层交换机、用正方形表示接入层交换机。
5 分清责任，建立相应的激励制度
不同的岗位工作方式不同，比如有的现场维护，有的远程处理；不同的技术水平要求不同的待遇，比如ITSM系统中一线技术人员与事件经理责任不同，待遇应该不同，因此企业应当推出相应的奖罚、晋升制度，以激励员工进步。本文着重于运维模式，对此不作进一步探讨。
6 结语
企业为优化生产、提高工作效率、减少成本，采用多种基础网络维护系统和生产应用系统，达到上述目的的同时，也对IT运维模式提出了更高的要求，新的运维模式要求一个清晰的运维架构和合理的工作流程， 同时更要注重日常管理工作和激励机制，这样才能更好地为企业服务。但企业在适应新的系统过程中，必然会出现一些问题，比如员工心态难适应、组织结构难协调、奖罚制度难改变等，这对很多企业是一个挑战。

智能运维是什么？

得益于IT外包服务的发达，现在的运维已经不包括搬机器上架、接网线、安装操作系统等基础工作，运维人员一般会从一台已安装好指定版本的操作系统、分配好IP地址和账号的服务器入手，工作范围大致包括：服务器管理（操作系统层面，比如重启、下线）、软件包管理、代码上下线、日志管理和分析、监控（区分系统、业务）和告警、流量管理（分发、转移、降级、限流等），以及一些日常的优化、故障排查等。
随着业务的发展、服务器规模的扩大，才及云化（公有云和混合云）、虚拟化的逐步落实，运维工作就扩展到了容量管理、弹性（自动化）扩缩容、安全管理，以及（引入各种容器、开源框架带来的复杂度提高而导致的）故障分析和定位等范围。
听上去每一类工作都不简单。不过，好在这些领域都有成熟的解决方案、开源软件和系统，运维工作的重点就是如何应用好这些工具来解决问题。
传统的运维工作经过不断发展（服务器规模的不断扩大），大致经历了人工、工具和自动化、平台化和智能运维（AIOps）几个阶段。这里的AIOps不是指Artificial Intelligence for IT Operations，而是指Algorithmic IT Operations（基于Gartner的定义标准）。
基于算法的IT运维，能利用数据和算法提高运维的自动化程度和效率，比如将其用于告警收敛和合并、Root分析、关联分析、容量评估、自动扩缩容等运维工作中。
在Monitoring（监控）、Service Desk（服务台）、Automation（自动化）之上，利用大数据和机器学习持续优化，用机器智能扩展人类的能力极限，这就是智能运维的实质含义。
智能运维具体的落地方式，各团队也都在摸索中，较早见效的是在异常检测、故障分析和定位（有赖于业务系统标准化的推进）等方面的应用。智能运维平台逻辑架构如图所示。
智能运维平台逻辑架构图
智能运维决不是一个跳跃发展的过程，而是一个长期演进的系统，其根基还是运维自动化、监控、数据收集、分析和处理等具体的工程。人们很容易忽略智能运维在工程上的投入，认为只要有算法就可以了，其实工程能力和算法能力在这里同样重要。
智能运维需要解决的问题有：海量数据存储、分析、处理，多维度，多数据源，信息过载，复杂业务模型下的故障定位。这些难题是否会随着智能运维的深入应用而得到一定程度的解决呢？我们会在下一篇文章中逐步展开这些问题，并提供一些解决方案。
本文选自《智能运维：从0搭建大规模分布式AIOps系统》，作者彭冬、朱伟、刘俊等，电子工业出版社2018年7月出版。
本书结合大企业的智能运维实践，全面完整地介绍智能运维的技术体系，让读者更加了解运维技术的现状和发展。同时，帮助运维工程师在一定程度上了解机器学习的常见算法模型，以及如何将它们应用到运维工作中。

互联网时代的网络自动化运维

互联网时代的网络自动化运维

互联网上有两大主要元素"内容和眼球"，"内容"是互联网公司(或称ICP)提供的网络服务，如网页、游戏、即时通信等，"眼球"则是借指海量的互联网用户。互联网公司的内容往往分布在多个或大或小的IDC中，越来越多的"眼球"在盯着ICP所提供的内容，互联网公司进行内容存储的基础设施也呈现出了爆发式的增长。为了保障对内容的访问体验，互联网公司需要在不同的运营商、不同的省份/城市批量部署业务服务器用以对外提供服务，并为业务模块间的通信建立IDC内部网络、城域网和广域网，同时通过自建CDN或CDN专业服务公司对服务盲点进行覆盖。因此随着业务的增长，运维部门也显得愈发重要。他们经过这些年的积累，逐步形成了高效的运维体系。本文将结合国内互联网公司的经验，重点针对IT基础设施的新一代自动化运维体系展开讨论。

一、运维的三个阶段

● 第一个阶段：人人皆运维

在早期，一个公司的IT基础设施尚未达到一定的规模(通常在几台到几十台机器的规模)，不一定有专门的运维人员或部门，运维的工作分担在各类岗位中。研发人员拥有服务器权限，自己维护和管理线上代码及业务。

● 第二个阶段：纵向自动化

随着业务量的增长，IT基础设施发展到了另外一个量级(通常在上百台至几千台机器的规模)，开始有专门的运维人员，从事日常的安装维护工作，扮演"救火队员"，收告警，有运维规范，但运维主要还是为研发提供后置服务。

这个阶段已经开始逐步向流程化处理进行过渡，运维部门开始输出常见问题处理的清单，有了自己业务范围适用的自动化脚本，开始利用开源软件的拼装完成大部分的工作。

具体表现为：各产品线有自己编写的脚本，利用如SVN+puppet或chef来完成服务器的上线和配置管理等工作。

● 第三阶段：一切皆自动

在互联网化的大潮中，越来越多的黑马团队应运而生，都曾有过短时间内用户访问量翻N倍的经历。在流量爆发的过程中，ICP的互联网基础服务设施是否能够很好的跟进，直接决定了业务内容能否满足海量用户的并发访问。

与此同时，运维系统需要足够地完善、高效、流程化。谷歌、腾讯、百度和阿里等规模的公司内一般都有统一的运维团队，有一套或多套自动化运维系统可供参照，运维部门与开发部门会是相互平行的视角。并且也开始更加关注IT基础设施在架构层面的优化以及超大规模集群下的自动化管理和切换(如图1所示)。

图1.大型互联网公司IT基础设施情况概览

二、BAT(百度、阿里、腾讯)运维系统的分析

国内的互联网公司百度、阿里、腾讯(以下简称：BAT)所提供的主要业务内容不同，IT架构不同，运维系统在发展过程中有不同的关注点。

1.腾讯运维：基于ITIL的运维服务管理

预计到2015年腾讯在全国将拥有60万台服务器。随着2012年自动化部署实践的成功，目前正在进行自动化验收的工作。在网络设备方面，后续将实现从需求端开始的全自动化工作：设备清单自动生成-采购清单自动下发-端口连接关系、拓扑关系自动生成-配置自动下发-自动验收。整个运维流程也已由初期的传统IT管理演进到基于ITIL的服务管理流程(如图2所示)。

图2.腾讯基于ITIL的运维服务管理

2.阿里运维系统：基于CMDB的基础设施管理+逻辑分层建模

CMDB(Configuration Management Database) 配置管理数据库(以下简称：CMDB)，将IT基础架构的所有组件存储为配置项，维护每个配置项的详细数据，维护各配置项之间的关系数据以及事件、变更历史等管理数据。通过将这些数据整合到中央存储库，CMDB可以为企业了解和管理数据类型之间的因果关系提供保障。同时，CMDB与所有服务支持和服务交付流程都紧密相联，支持这些流程的运转、发挥配置信息的价值，同时依赖于相关流程保证数据的准确性。可实现IT服务支持、IT运维以及IT资产管理内部及三者之间的流程整合与自动化。在实际的项目中，CMDB常常被认为是构建其它ITIL流程的基础而优先考虑，ITIL项目的成败与是否成功建立CMDB有非常大的关系。

3.百度自动化运维：部署+监控+业务系统+关联关系

百度主要面临的运维挑战包括：突发的流量变化、复杂环境的关联影响、快速迭代的开发模式以及运维效率、运维质量、成本之间的平衡等等。百度的运维团队认为，当服务器规模达到上万台时，运维视角需要转为以服务为粒度。万台并不等于"百台*100";机器的运行状态，也不再代表业务的工作状态;运维部门为研发提供前置服务，服务与服务之间关系也随着集群的扩大逐渐复杂起来。

图3.百度自动化运维技术框架

百度的自动化运维技术框架，划分为部署、监控、业务系统、关联关系四大部分，整个框架更多突出了业务与IT基础设施的融合，注重"关联关系"的联动。所谓关联关系，主要是指任务与任务之间的时序依赖关系、任务与任务之间的数据依赖关系、任务与资源之间的引用依赖关系，分别对应到任务调度、数据传输、资源定位的服务流程中，形成了多条服务链。

关联关系的运维与业务较强相关，需要有一套系统能够理清楚关系的全貌，从而在复杂的服务链上，定位运行所在的环节，并在发生故障时预估影响范围，及时定位并通知相应的部门。在这样的一套系统中，自动化监控系统非常重要。百度的技术监控框架，主要通过数据采集、服务探测、第三方进行信息收集，进行监控评估后交给数据处理和报警联动模块处理，通过API接口进行功能扩充(如图4所示)。

图4.百度自动化技术监控框架

其实无论是BAT等互联网企业还是其他行业的企业，在IT建设中都会遵循IT基础架构库(ITIL)或ISO20000服务管理的最佳实践，采用自动化IT管理解决方案以实现重要的业务目标，如减少服务中断、降低运营成本、提高IT效率等等。随着ISO20000、ITIL v3.0的发布和推广，两者已经成为事实上的某种标准。在当今企业IT管理领域，对两个标准有着很迫切的需求。特别是ISO20000的认证要求，已经成为企业越来越普遍的需求 。ITIL v3.0包含了对IT运维从战略、设计到转换、运营、改进的服务全生命周期的管理，相关方案往往覆盖了多个领域和多个产品，规划实施和工具的选择会比较纠结。如果选择开源的工具，从CMDB开始就会遇到很多的开发工作，对于很多注重成本收益比的企业，可以参考，但由于无法保证性能与效果并不一定适用。因此，成熟的商业方案会是更好的选择。

最新的iMC V7版本，围绕资源、用户、业务三个维度进行创新，发布了SOM服务运维管理(基于ISO20000、ITIL标准)等组件，增加了对服务器的管理，能很好的满足更多互联网化的场景需求。

通常认为，一个高效、好用的配置管理数据库一般需要满足6条重要标准，即联合、灵活的信息模型定义、标准合规、支持内置策略、自动发现和严格的访问控制。企业IT基础架构的元素类型、管理数据的类型往往有较多种，如网络设备、服务器、虚拟机等，因此对于多种信息的存储需要有合适的联合的方法。虽然 iMC智能管理平台在网络设备、服务器设备等方面已经能够较好的的满足，但是随着服务器虚拟化技术的发展，虚拟机正越来越多的成为IT基础架构的一大元素。因此，针对这一需求华三通信基于CAS CVM虚拟化管理系统，对服务器CPU、内存、磁盘I/O、网络I/O等更细节的重要资源以及虚拟机资源进行全面的管理。与BAT不同，华三通信的网管软件面向全行业，目前虽然没有对域名管理等特殊资源的'管理，但是能够通过API接口等方式与特有系统进行联动，进而满足定制化运维的需求，尤其是在互联网化的场景中，针对不同的业务需求，可以实现很多定制化的对接需求，例如，iMC+WSM组件与国内某大互联网公司自有Portal系统进行了对接，打通了iMC工具与用户自有运维平台，很好的实现了架构融和。另外，与阿里的逻辑分层建模相似，H3C "iMC+CAS"软件体系在上层也做了很多的逻辑抽象、分层，形成了诸多的模块，也即是大家看到的各种组件。

三、网络自动化运维体系

"哪怕是一个只有基础技术能力的陌生人，也能做专业的IT运维;哪怕是一个只有初中学历的运维人员，也能够带队完成中小型机房节点的建设，并负责数百至上千台服务器的维护管理工作"--这是一些公司对自己IT运行维护水平的一个整体评价。看似有些夸大的嫌疑，但实际上依托于强大的IT运维系统，国内已经有不少互联网公司能够达到或者接近这一标准。

这些企业都经历了运维发展过程中的各个阶段，运维部门曾经也是被动的、孤立的、分散的"救火队"式的团队，在后来的发展过程中，IT系统架构逐渐走向标准化、模型化，运维部门建立了完整的设备、系统资源管理数据库和知识库，包括所有硬件的配置情况、所有软件的参数配置，购买日期、维修记录，运维风险看板等等，通过网管软件，进行系统远程自动化监控。运维过程中系统会收集所有的问题、事件、变更、服务级别等信息并录入管理系统，不断完善进而形成一套趋向自动化的运作支撑机制。按照云计算的体系架构，在这样一套系统中，主要的IT资源包括计算、存储、网络资源，近些年随着网络设备厂商的推动，网络设备管理方面的自动化技术也得到十足的发展。

总结来看，一个企业在进行互联网化的建设初期，就需要考虑到随着用户访问量的增加，资源如何进行扩展。具体可以细化为规划、建设、管理、监控、运维五个方面。

1.规划模型化

为了确保后续业务能够平滑扩容，网管系统能够顺利跟进，互联网企业一般在早期整体系统架构设计时便充分考虑到标准化、模型化，新增业务资源就好比点快餐，随需随取。

标准化：一是采用标准协议和技术搭建，扩展性好，使用的产品较统一，便于管理;二是采用数据中心级设备，保证可靠性、灵活性，充分考虑业务系统对低时延的要求。

模型化：基于业务需求设计网络架构模型，验证后形成基线，可批量复制，统一管理，也适宜通过自动化提高部署效率、网管效率。

图5.常见互联网IDC架构

2.建设自动化

互联网IT基础设施具备批量复制能力之后，可以通过自动化技术，提高上线效率。在新节点建设过程中，3～5人的小型团队即可完成机房上线工作。例如某互联网公司某次针对海外紧急业务需求，一共派遣了2名工程师到现场进行设备安装部署和基本配置，而后通过互联网链路，设备从总部管理系统中自动获取配置和设备版本，下载业务系统，完成设备安装到机房上线不超过1周时间。

要达到自动化运维的目标，建设过程中需要重点考虑批量复制和自动化上线两个方面(如图6所示)。

批量复制：根据业务需要，梳理技术关注点，设计网络模型，进行充分测试和试点，输出软、硬件配置模板，进而可进行批量部署。

自动化上线：充分利用TR069、Autoconfig等技术，采用零配置功能批量自动化上线设备，效率能够得到成倍提升。

图6.批量配置与自动化上线

○ Autoconfig与TR069的主要有三个区别：

○ Autoconfig适用于零配置部署，后续一般需要专门的网管系统;TR069是一套完整的管理方案，不仅在初始零配置时有用，后续还可以一直对设备进行监控和配置管理、软件升级等。

○ Autoconfig使用DHCP与TFTP--简单，TR069零配置使用DHCP与HTTP--复杂，需要专门的ACS服务器。

安全性：TR069更安全，可以基于HTTPS/SSL。

而H3C iMC BIMS实现了TR-069协议中的ACS(自动配置服务器)功能，通过TR-069协议对CPE设备进行远程管理，BIMS具有零配置的能力和优势，有灵活的组网能力，可管理DHCP设备和NAT后的私网设备。BIMS的工作流程如图7所示。

图7.H3C iMC BIMS工作流程

3.管理智能化

对于网管团队而言，需要向其他团队提供便利的工具以进行信息查询、告警管理等操作。早期的网管工具，往往离不开命令行操作，且对于批量处理的操作支持性并不好，如网络设备的MIB库相比新的智能化技术Netconf，好比C和C++，显得笨拙许多。因此使用的角度考虑，图形化、智能化的管理工具，往往是比较受欢迎。

智能化：使用新技术，提升传统MIB式管理方式的处理效率，引入嵌入式自动化架构，实现智能终端APP化管理(如图8所示)。

图8.消息、事件处理智能化

● Netconf技术

目前网络管理协议主要是SNMP和Netconf。SNMP采用UDP，实现简单，技术成熟，但是在安全可靠性、管理操作效率、交互操作和复杂操作实现上还不能满足管理需求。Netconf采用XML作为配置数据和协议消息内容的数据编码方式，采用基于TCP的SSHv2进行传送，以RPC方式实现操作和控制。XML可以表达复杂、具有内在逻辑、模型化的管理对象，如端口、协议、业务以及之间的关系等，提高了操作效率和对象标准化;采用SSHv2传送方式，可靠性、安全性、交互性较好。二者主要对比差异如表1所示。

表1 网管技术的对比

● EAA嵌入式自动化架构

EAA自动化架构的执行包括如下三个步骤。

○ 定义感兴趣的事件源，事件源是系统中的软件或者硬件模块，如：特定的命令、日志、TRAP告警等。

○ 定义EAA监控策略，比如保存设备配置、主备切换、重启进程等。

○ 当监控到定义的事件源发生后，触发执行EAA监控策略。

4.监控平台化

利用基本监控工具如Show、Display、SNMP、Syslog等，制作平台化监控集成环境，实现全方位监控(如图所示)。

;

IT运维服务管理中知识管理的思考

关于IT运维服务管理中知识管理的思考

随着信息化的逐步推进，广大企事业单位越来越离不开IT，尤其是金融行业对IT是高度依赖，作为一名金融行业的IT工作人员，在日常的IT运维工作过程中，深切体会到运维服务管理的重要性，如何提高IT运维效率成为金融行业越来越关注的重点，ITIL(IT Infrastructure Library信息技术基础架构库)第三版也增加了知识管理部分。本文主要讨论在IT运维服务管理中知识的作用以及如何进行知识管理，提高IT运维效率，从而实现IT运维服务的目标。

1 IT运维服务管理中知识的主要内容及分类

IT运维服务管理中的知识主要包括IT服务相关的管理制度、流程，软件开发文档、网络拓扑图等技术资料，针对不同问题和事件的解决方案，IT运维过程中产生的测试方案、技术方案、变更申请等。

根据知识与IT运维服务流程是否相关，可以把IT运维服务管理中的知识分为流程相关类知识和非流程相关类知识。例如，测试方案、技术方案是在变更管理流程中产生的知识，解决方案是在事件管理流程和问题管理流程中产生的知识，它们都属于流程相关类知识;而IT服务相关的管理制度、网络拓扑图等则属于非流程相关类知识。

2 知识在IT运维服务管理中的价值体现

有效开展知识管理，建立知识库，实现知识的创建、储存、共享、应用，知识对IT运维服务管理的价值和作用主要体现在以下一些方面。

2.1创造知识价值

通过知识的创建、共享、积累、分析，以及知识的快速检索与获取，利用知识创造价值，从而提高IT部门的能力和运维人员的个人能力。

2.2实现知识共享，降低IT运维成本

IT运维人员常常要重复解决相同的问题。如果大多数问题及其解决方案都可以从知识库中方便、快捷的获取，就可以将IT运维人员从重复性的运维工作中解放出来，集中精力解决其他新的问题，从而达到提升工作效率，降低IT运维成本的目的。

2.3提高运维响应速度和质量

通常情况下，能够进入知识库的解决方案一般来说是最正确、标准和高效的。构建一个质量、数量及知识结构都达到一定标准的知识库，作为IT运维的强大储备库，另外，知识库都具备高效的搜索功能，这无疑是快速响应IT服务需求的最好方式。而快速、高质量的解决故障意味着客户满意度的大幅提升，这正是IT运维的最终目的`。

2.4避免知识流失

许多隐性知识集中在运维人员的脑子里，一些IT应用的操作或故障解决方法可能只有开发人员知道，知识库管理可以有效避免由人员流失造成的信息孤岛和知识流失。

2.5挖掘、分析IT应用信息

运维知识库不仅作为一种信息收集、整理工具，同时还是一种数据分析、统计工具。从知识条目、IT运维解决案例、知识的生命周期等等统计数据中，可以挖掘出许多有用的信息。便于IT服务提供者发现潜在问题、进行趋势分析，帮助拟定未来的工作重点、计划及预算等。

3 在IT运维管理过程中开展知识管理的方法

虽然开展知识管理对IT运维服务管理有这么多显著的作用，但在推行知识管理的过程中会遇到很多的阻力，如缺乏知识管理系统的强大支撑，知识共享不方便; 系统开发人员、维护人员等IT技术人员担心将自己的技术解决方案整理出来供大家共享，会降低他们在团体中的价值，而不愿意共享知识等。为了克服知识管理实施过程中的阻力，充分发挥知识在IT运维管理中的价值，可以从技术、流程、人员三个方面开展知识管理。

3.1建设IT运维服务系统，非结构化数据由内容管理平台统一管理

典型的IT运维服务管理系统采用四层架构(如图1所示)，分别为数据资源层、数据管理层、数据服务层和系统功能层(如图1所示)。为实现跨系统之间的数据交换，IT运维服务管理系统应满足面向服务(SOA)的架构要求。

IT运维服务管理系统中，结构化数据存储在本系统的数据库中，非结构化数据(如网络拓扑图、解决方案、技术方案、参考资料等知识)统一储存在内容管理平台中。IT运维服务管理系统的非结构化数据的存储、内容检索等南内容管理平台进行。

IT运维服务管理系统中的非结构化数据统一储存在内容管理平台中，可以实现“一处储存、多处引用”，减少数据冗余，节约存储空间。内容管理平台有强大的检索功能(包括属性检索、全文检索、组合检索等)，方便维护人员查询和应用。另外，IT运维服务管理相关的结构化数据和非结构化数据分别储存在IT运维系统和内容管理平台，lT运维管理系统使用Web service或JAVA API与内容管理平台进行数据交换，在IT运维服务管理系统完成审核后，非结构化数据存储到内容管理平台中。

;

ITIL图的ITIL产生的背景

随着企业之间竞争的加剧和世界范围内电子商务的兴起it运维体系架构图，IT受到了企业越来越多的重视。一方面it运维体系架构图，企业不断投资购建各种硬件、系统软件和网络it运维体系架构图，另一方面不断开发实施ERP系统、SCM系统、CRM系统、决策支持系统和知识管理系统等各种各样的系统。但是，建设这些IT基础设施只是企业信息化的一个阶段，如何运维好这些设施却是一个极为重要却又被长期忽略的问题。
因为从生命周期的观点看，系统的设计、开发（购买）和实施只占20%的时间，而系统的运维则占到整个生命周期的80%的时间。世界权威的IT研究机构Gartner的调查也发现，在导致IT基础设施经常出现故障的原因中，源自技术或产品（包括硬件、软件、网络、电力失常及天灾等）方面其实只占了 20%，而因为管理方面的原因则占到80%。
正是基于这个背景，英国商务部（OGC）从20世纪80年代开始组织开发的用于解决此类问题的IT管理标准体系－ITIL（IT基础架构库）。经过近20年的发展，现在已经风靡全球，并在包括政府、企业和非营利组织中得到了广泛的支持与应用。

关于it运维体系架构图和it系统架构图的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 it运维体系架构图的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于it系统架构图、it运维体系架构图的信息别忘了在本站进行查找喔。