[p=30,2,center]学习资料：IT运维管理社区专家讲堂直播300期视频回放

[p=30,2,center]

[p=30,2,center]

各位朋友，先锋小编为你们选了一篇很好的文章，欢迎讨论！

1、IT人生若只如初见

终于开始动笔了。

写下这个题目眼前闪回15年前的那个才走出大学校门的我很迷茫

曾经的理想是做电脑动画与艺术沾边

却从没有想过IT这个工作（那时叫计算机专业）会让我坚持走了15年

从不喜欢这个专业到今天的无法离开很难说没有日久生情的成分在其中

（呵呵，不是苦笑哦）革命乐观主义的一种精神支撑着我走下去。。。

从最初工作接触专线MODEM到今天的ITIL信息技术在不断的飞速发展之间竟然跨越了21世纪中国的企业也真正从单纯重技术到今天服务成为导向逐渐转向关注IT服务管理的阶段。而IT服务管理，是英国国家电脑局(CCTA)于上世纪80年代开始开发的一套IT业界的服务管理标准库，在中国也是近几年才逐渐被认识、接受、并推广实施的。

真正接触IT服务管理的时间，是在2004年，之前曾经从事过通讯网络、软件开发，技术支持等工作。而在这一年，我们有一个主营业务的大项目，需要在全国范围内推广实施，业务人员和技术人员都会面临全新的海量知识更新，那时似乎已经预见到项目测试、上线、运行维护这三个阶段将会遇到的重重困难。

于是我的脑海中经常会浮现出怎么办？这三个字

2、知识管理
知识管理（1）
佛家禅语

一碗浑浊的水，老摇它，水便总是浑浊，把它放到器皿里不动，沙尘便能沉底，可见清心是沉五欲之沙、驱烦恼的初步功夫。
今天记录下这句佛家禅语，用来体味当年建设知识库时面对千头万绪，如何从浮躁、焦虑的心情中逐步解脱出来，去静心梳理繁多的知识库建设与知识管理工作的。

背景介绍

做为全省范围内推广的大项目在测试和上线初期，对于企业的广大员工来说，新系统带来的知识冲击力是巨大的，而当时的技术运行中心作为提供应用系统运维管理的支持部门，支持着全省成千上万个营业单位，每天热线值班人员仅有几名，如何在最短的时间内消化海量的业务和技术知识，快速解决新的业务和技术难题，是所有人员面临的一个挑战。

设计思路:

尽管我对IT服务管理的理解尚处于启蒙的初级阶段，但还是围绕企业IT基础设施的技术运维工作设计了一个ITSM框架，知识库还成为当时的重彩。作为设计者，我至今认为ITSM的建设应该从知识库开始，因为他是一线支持人员的精神食粮，因为有了它，知识才有了载体，为有效转移提供了途径，人员的频繁流动不再成为增加企业培训成本的难题。

架构设计

经过短时间的调研分析后,企业组织搭建了基于WEB的信息知识交流平台，该平台使营业单位的业务人员在工作环境中可以方便地使用问题库、阅读下发的公文类文档资料，实时进行查询阅读各种电子学习文档资料；同时该平台还为管理人员将各种规章制度、业务知识以及操作流程向一线网点下发提供了一条方便快捷的发布与学习渠道，对于及时解决工作中遇到的问题起到了良好的效果。

推广实施

2004年的知识库最初叫问题库，其实用户或客户对于知识的理解就是解决问题的有效方法。而我们对知识的理解也有一曲同工之处，即知识就是解决方案的积累和共享。这有些像ITIL中的事件案例库，有一种故障发生了，或许是在测试阶段、或许发生在正式运行阶段，后台的维护支持人员（技术支持人员和业务管理人员）进行分析解答。我们还尝试同时开放答案的权限，即提问题的人也可以根据自己的经验回答别人提的问题，效果非常好，参与的人越来越多，附在后面的解答也多，有些像个问题IT运维管理社区了。不过这种答案的状态属于“参考答案”，只有技术或业务专家审核通过后，解答方能转正，而成为"正式答案"。

计划改进

当然，最终问题库是否用的好，还是在于管理。于是我们在一期的基础上，开发了二期的培训系统，建立完整的知识库系统和知识管理流程。从此，知识从颗颗散落的珠粒，被有序的筛选、清洗、保养、分类组装成熠熠生辉的知识珠宝了。

知识管理（2）设计方案
总体架构(略)

功能需求

• 知识分类，设计为按照3个纬度形成立体知识图：第一个纬度区分性质，按管理类、操作类等；第二个纬度按不同的专题分；第三个纬度区分行业，按业务与技术两部分。由此形成立方体结构
• 建立企业统一的知识库，统一分类，权限由企业总部控制
• 按照知识查看的次数建立知识条目的查看排名榜，显示前二十条的热门知识条目
• 可以按关键字进行全文检索，内容显示前100个字
• 企业内的用户都有权利提交知识条目、给知识打分、检索知识库内容
• 对每条知识系统应记录对它的访问量，在本条知识应可以附加评论信息。
• 对知识库和主题讨论进行统计。按周、月、季度等不同时间段进行统计、按不同知识类别进行统计、知识的访问量统计及排序、热点主题统计等。
• 系统提供知识地图功能，使检索人员可以全面、直观的检索知识库信息。
• 提供完善的查询功能，例如：知识列表、关键字查询、全文检索等。
  
  

数据库表结构

r字段名称	r名称	r说明
rNAME	r题目	r
rRESOLUTION	r解答/方案	r
rNOTES	r注释	r
rRECORDER_ID	r提交人	r提交人的用户ID
rAUTHOR_NAME	r作者名称	r真实的作者姓名
rCLASS_ID	r分类	r关联权限
rFLAG	r状态标志	r“草案”、”审核中”、”正式答案”、”作废”
rSCORE	r评价分数	4-高3-较好2-中1-一般
rACCESS	r访问次数	为知识排名
rINCIDENT_ID	r来源的事件单号	关联的事件
rPROBLEM_ID	r来源的问题单号	关联的问题
rCHANGE_ID	r来源的变更单号	关联的变更

表1-1.知识库表结构

知识管理流程设计

企业内部建立统一的知识库系统，但各级机构的知识审核、发布应由本地的知识管理员组完成。按照不同的一级分类，指派不
同类别的知识库管理员，一个人也可以同时担任多个分类的知识类别的管理员角色（一个人带多个帽子），负责所属类别的知识审核。

• 知识的提交
  
  企业内所有人员均可以向知识库提交知识，也可以通过事件管理、问题管理和变更管理流程的关联项向知识库系统提交知识条目，提交人默认为用户ID。
• 知识的审核
  
  知识管理员对提交的知识进行审核，检查知识的分类和内容正确后，才可以用于对外发布。
• 知识的发布
  
  知识管理员对验证审核通过的知识条目进行对外发布，所有用户可以根据不同权限检索到相应权限范围内的知识，事件流程、问题流程和变更流程也可以与知识库进行关联。
  
  当新的知识内容增加或者有严重性较高的事件发生后，可以自动通过邮件、短信方式向用户和员工自动发布故障现象的描述和解决方案。
• 知识的维护
  
  知识管理员应定期检查、维护管辖范围内的知识条目，将已经过期的知识记录标志设置状态为“作废”。
• 角色
  

  角色	主要职责
  知识提交人	所有用户都有权利提交知识条目
  知识管理员	负责审核提交的知识，发布知识和对知识库进行定期维护

  
  表1-1.知识管理的角色
  
  

知识管理流程图(略)（转）

[p=30,2,center]学习资料：IT运维管理社区专家讲堂直播300期视频回放

[p=30,2,center]

[p=30,2,center]

各位朋友，先锋小编为你们选了一篇很好的文章，欢迎讨论！

1、IT人生若只如初见

终于开始动笔了。

写下这个题目眼前闪回15年前的那个才走出大学校门的我很迷茫

曾经的理想是做电脑动画与艺术沾边

却从没有想过IT这个工作（那时叫计算机专业）会让我坚持走了15年

从不喜欢这个专业到今天的无法离开很难说没有日久生情的成分在其中

（呵呵，不是苦笑哦）革命乐观主义的一种精神支撑着我走下去。。。

从最初工作接触专线MODEM到今天的ITIL信息技术在不断的飞速发展之间竟然跨越了21世纪中国的企业也真正从单纯重技术到今天服务成为导向逐渐转向关注IT服务管理的阶段。而IT服务管理，是英国国家电脑局(CCTA)于上世纪80年代开始开发的一套IT业界的服务管理标准库，在中国也是近几年才逐渐被认识、接受、并推广实施的。

真正接触IT服务管理的时间，是在2004年，之前曾经从事过通讯网络、软件开发，技术支持等工作。而在这一年，我们有一个主营业务的大项目，需要在全国范围内推广实施，业务人员和技术人员都会面临全新的海量知识更新，那时似乎已经预见到项目测试、上线、运行维护这三个阶段将会遇到的重重困难。

于是我的脑海中经常会浮现出怎么办？这三个字

2、知识管理
知识管理（1）
佛家禅语

一碗浑浊的水，老摇它，水便总是浑浊，把它放到器皿里不动，沙尘便能沉底，可见清心是沉五欲之沙、驱烦恼的初步功夫。
今天记录下这句佛家禅语，用来体味当年建设知识库时面对千头万绪，如何从浮躁、焦虑的心情中逐步解脱出来，去静心梳理繁多的知识库建设与知识管理工作的。

背景介绍

做为全省范围内推广的大项目在测试和上线初期，对于企业的广大员工来说，新系统带来的知识冲击力是巨大的，而当时的技术运行中心作为提供应用系统运维管理的支持部门，支持着全省成千上万个营业单位，每天热线值班人员仅有几名，如何在最短的时间内消化海量的业务和技术知识，快速解决新的业务和技术难题，是所有人员面临的一个挑战。

设计思路:

尽管我对IT服务管理的理解尚处于启蒙的初级阶段，但还是围绕企业IT基础设施的技术运维工作设计了一个ITSM框架，知识库还成为当时的重彩。作为设计者，我至今认为ITSM的建设应该从知识库开始，因为他是一线支持人员的精神食粮，因为有了它，知识才有了载体，为有效转移提供了途径，人员的频繁流动不再成为增加企业培训成本的难题。

架构设计

经过短时间的调研分析后,企业组织搭建了基于WEB的信息知识交流平台，该平台使营业单位的业务人员在工作环境中可以方便地使用问题库、阅读下发的公文类文档资料，实时进行查询阅读各种电子学习文档资料；同时该平台还为管理人员将各种规章制度、业务知识以及操作流程向一线网点下发提供了一条方便快捷的发布与学习渠道，对于及时解决工作中遇到的问题起到了良好的效果。

推广实施

2004年的知识库最初叫问题库，其实用户或客户对于知识的理解就是解决问题的有效方法。而我们对知识的理解也有一曲同工之处，即知识就是解决方案的积累和共享。这有些像ITIL中的事件案例库，有一种故障发生了，或许是在测试阶段、或许发生在正式运行阶段，后台的维护支持人员（技术支持人员和业务管理人员）进行分析解答。我们还尝试同时开放答案的权限，即提问题的人也可以根据自己的经验回答别人提的问题，效果非常好，参与的人越来越多，附在后面的解答也多，有些像个问题IT运维管理社区了。不过这种答案的状态属于“参考答案”，只有技术或业务专家审核通过后，解答方能转正，而成为"正式答案"。

计划改进

当然，最终问题库是否用的好，还是在于管理。于是我们在一期的基础上，开发了二期的培训系统，建立完整的知识库系统和知识管理流程。从此，知识从颗颗散落的珠粒，被有序的筛选、清洗、保养、分类组装成熠熠生辉的知识珠宝了。

知识管理（2）设计方案
总体架构(略)

功能需求

• 知识分类，设计为按照3个纬度形成立体知识图：第一个纬度区分性质，按管理类、操作类等；第二个纬度按不同的专题分；第三个纬度区分行业，按业务与技术两部分。由此形成立方体结构
• 建立企业统一的知识库，统一分类，权限由企业总部控制
• 按照知识查看的次数建立知识条目的查看排名榜，显示前二十条的热门知识条目
• 可以按关键字进行全文检索，内容显示前100个字
• 企业内的用户都有权利提交知识条目、给知识打分、检索知识库内容
• 对每条知识系统应记录对它的访问量，在本条知识应可以附加评论信息。
• 对知识库和主题讨论进行统计。按周、月、季度等不同时间段进行统计、按不同知识类别进行统计、知识的访问量统计及排序、热点主题统计等。
• 系统提供知识地图功能，使检索人员可以全面、直观的检索知识库信息。
• 提供完善的查询功能，例如：知识列表、关键字查询、全文检索等。
  
  

数据库表结构

r字段名称	r名称	r说明
rNAME	r题目	r
rRESOLUTION	r解答/方案	r
rNOTES	r注释	r
rRECORDER_ID	r提交人	r提交人的用户ID
rAUTHOR_NAME	r作者名称	r真实的作者姓名
rCLASS_ID	r分类	r关联权限
rFLAG	r状态标志	r“草案”、”审核中”、”正式答案”、”作废”
rSCORE	r评价分数	4-高3-较好2-中1-一般
rACCESS	r访问次数	为知识排名
rINCIDENT_ID	r来源的事件单号	关联的事件
rPROBLEM_ID	r来源的问题单号	关联的问题
rCHANGE_ID	r来源的变更单号	关联的变更

表1-1.知识库表结构

知识管理流程设计

企业内部建立统一的知识库系统，但各级机构的知识审核、发布应由本地的知识管理员组完成。按照不同的一级分类，指派不
同类别的知识库管理员，一个人也可以同时担任多个分类的知识类别的管理员角色（一个人带多个帽子），负责所属类别的知识审核。

• 知识的提交
  
  企业内所有人员均可以向知识库提交知识，也可以通过事件管理、问题管理和变更管理流程的关联项向知识库系统提交知识条目，提交人默认为用户ID。
• 知识的审核
  
  知识管理员对提交的知识进行审核，检查知识的分类和内容正确后，才可以用于对外发布。
• 知识的发布
  
  知识管理员对验证审核通过的知识条目进行对外发布，所有用户可以根据不同权限检索到相应权限范围内的知识，事件流程、问题流程和变更流程也可以与知识库进行关联。
  
  当新的知识内容增加或者有严重性较高的事件发生后，可以自动通过邮件、短信方式向用户和员工自动发布故障现象的描述和解决方案。
• 知识的维护
  
  知识管理员应定期检查、维护管辖范围内的知识条目，将已经过期的知识记录标志设置状态为“作废”。
• 角色
  

  角色	主要职责
  知识提交人	所有用户都有权利提交知识条目
  知识管理员	负责审核提交的知识，发布知识和对知识库进行定期维护

  
  表1-1.知识管理的角色
  
  

知识管理流程图(略)（转）