综合运维管理平台技术白皮书.docx

综合运维管理平台 技术白皮书综合运维管理平台技术白皮书2018年3月目录1概述32平台架构42.1平台整体架构42.2平台技术架构43平台特点53.1稳定性53.2易用性53.3扩展性63.4开放性63.5标准性63.6组件化74第四章 平台特色功能74.1自助服务台74.2工作区84.3事件管理94.4问题管理114.5变更管理164.6发布管理174.7配置管理194.8值班管理244.9知识库管理264.10自定义流程304.11移动运维364.12运维报表375第五章 平台技术参数415.1服务器端配置要求411 概述OSSWorks综合运维管理系统，是结合国内外ITSM的方法论以及最佳实践，并分析了中国IT管理现状和需求后，基于ITIL理念自主研发而成。秉承以客户为中心、流程为导向的理念，实现对IT资源的全面管理，完美整合了人员、技术和流程三大要素，帮助用户以较低的成本提供稳定、优质的服务，共同实现IT服务的目标。2 平台架构2.1 平台整体架构2.2 平台技术架构3 平台特点3.1 稳定性系统基于稳定且优化的jdk1.6版本开发和编译，采用JBOSS中间件作为web服务器， 标配Mysql数据库。安装包在出厂前均对各个组件经过优化，对安装环境依赖度度不高，系统自身运行稳定。3.2 易用性系统采用B/S架构，界面友好，交互性好，易于使用。另外，系统内置多种标准对接接口，出厂时就已经具备了与多种第三方接口对接的能力，如短信、邮件系统、 呼叫中心、AD域、 第三方监控系统等。方便用户的使用，降低实施成本。3.3 扩展性系统基于可扩展的多层MVC模型，面向接口进行开发，各个组件均具有很强的扩展性。3.4 开放性为了方便与第三方系统的对接，系统提供了基于HTTP的Restful对外接口，目前已经开发的接口有工单接口和权限接口。将来还会陆续开放资产，CMDB等其他接口。3.5 标准性1）从开发角度：我们基于CMMI3， ISO90001的标准来进行产品的研发和管理。2）从功能角度：作为运维工具厂商，我们的系统提供了标准的ITILv2+v3的标准功能。3.6 组件化系统各模块之间耦合性低，各模块可以自由组合，面向不同的用户可提供不同的组件功能菜单。并通过license控制各个模块的可用性。4 第四章 平台特色功能4.1 自助服务台自助服务台提供主动管理的有效工具，它既可以提供给用户的报障、各类咨询和服务请求的统一入口，让用户对事件的处理过程进行查看，提高事件的处理效率和客户的满意度。用户可登录到自助服务台，可提交问题咨询或者提交IT服务请求，是提供给用户的报障、各类咨询和服务请求的统一入口。用户在填写IT服务请求或者提交问题咨询时，系统采用主动链技术，自动将电话、姓名等关键项目显示到界面上，用户不用每个信息依次填写。用户可通过自助服务台查看自己提交的事件请求的处理过程，包括处理的流程、每一步的处理人、每一步的处理情况、当前所在的流程节点位置等信息。提供查询功能，可按照待处理、处理中、已处理等状态对提交的工单进行过滤。提交IT服务请求当提交的服务请求处理结束时，用户可对IT部门提供的服务进行评价。用户评价服务情况4.2 工作区Apex OssWorks为了能够在一个界面上呈现来自不同系统的数据，将个人用户最常用的功能、最关注的业务数据进行统一集成，能够一目了然的看到各个子系统的运行状态，作为用户日常工作的快捷方式汇集。通过个人工作台，用户可快速定位到所需要进行的工作，提高系统应用的效率，方便日常维护支持工作。个人工作台组件化的服务台个人工作台采用组件式管理，系统默认定义了多种组件，各个组件的刷新时间等可自定义。组件自定义4.3 事件管理Apex OssWorks事件管理流程是负责解决IT服务的突发事件、客户投诉和请求的运维流程。设计目的是尽快恢复被中断或受到影响的IT服务，它的特点是以快速解决故障为目的，而对反复出现或者重大故障可升级到问题管理来分析根本原因，防止以后再次出现。流程说明基于ITIL标准的事件流程图如下：图11：事件流程图对流程的描述如下：n 服务台工作人员根据客户的请求创建事件工单流程，此时流程进入“待处理”状态；如果在创建的同时选择了处理人，则流程直接进入“处理中”状态，同时处理人将得到邮件通知n 运维人员在事件工单池中看到有待处理的工单，即执行接单操作，此时流程进入“处理中”状态，此时接单人也即流程的当前处理人将得到邮件通知n 运维人员可以拒绝分配给他的工单，此时流程进入“被拒绝”状态，同时工单的创建人将得到邮件通知n 运维人员如果解决了故障，则流程进入“已解决”状态，此时工单的创建人将得到邮件通知n 流程处于“被拒绝”状态可以重新提交，流程进入“重新打开”状态，此时工单的当前处理人将得到邮件通知n 流程处于“重新打开“状态时可以再次拒绝，流程进入“被拒绝”状态，此时工单的创建人将得到邮件通知n 流程处于“重新打开”状态时如果处理人解决了故障，则流程进入“已解决”状态，此时工单的创建人将得到邮件通知n 只要工单被关闭，则流程进入“已关闭”状态，工单的处理人将得到邮件通知。直接解决对于事件工单，由于是以快速解决为目的，而且实际中，服务台在接到IT服务请求时，往往能够在接听电话的同时就解决了故障，比如很多咨询类的IT服务请求或一些简单的事件故障，对于这些简单的IT请求，服务台工作人员通过自身经验判断以及搜索知识库，是可以现场解决的，在创建事件工单的时候，提供“直接解决”按钮，可以直接解决工单，而不用提交后在工单详情界面中再次点击“解决工单”按钮，加快操作者的速度。升级工单当发现表现现象相同的故障经常发生或者事件管理无法解决某个故障时，可以由事件经理将事件升级为问题，交由问题管理流程来解决故障背后的深层次问题以防止事件再次发生。状态跟踪系统还提供用户对已开始执行的流程状态查询和跟踪功能。用户通过流程跟踪功能将对每个开始执行的流程实例进行跟踪和记录，保存流程的活动记录，包括各个环节信息传递发送和到达的时间、部门环节处理的历时、处理该环节的运维人员等。与知识库的联动事件管理可实现与知识库的互动，当输入事件的简要信息后，系统可根据输入的信息检索出知识库中的相同事件的处理办法。供工作人员参考。4.4 问题管理问题管理的目标在于尽量减少由于IT基础设施的故障导致的业务故障，并防止与这些错误相关的问题再次出现。重点就是在于发现问题产生的根本原因，并随后采取措施改善或者纠正这种情况。问题是导致一些或者多起事故的潜在原因，Apex OssWorks问题管理就是尽量减少服务基础架构、人为错误和外部事件等缺陷或过失对客户造成的影响，并防止它们重复发生的过程。问题管理与事件管理有明显的不同，后者是尽可能快的恢复服务，而前者的主要目的是找出事故产生的根本原因。为此，它甚至可能要求中断服务。问题管理流程将会带来以下好处：1. 将突发事件减到最小2. 找出突发事件的根本原因3. 避免相关事件或问题再次发生流程说明基于ITIL标准的问题流程图如下：创建工单问题工单创建的方式，可以是直接提交问题工单或者是由事件工单升级为问题工单。评估工单提交的问题工单需要进行评估，评估的结果有两种，一种是问题确实存在需要解决，运维人员接受该工单，点击“开始调查”超链接，相应的工单状态变为“调查中”；另一种是认为不需要解决或者提交的工单描述不清楚，拒绝调查，点击“拒绝调查”，相应的工单状态变为“被拒绝”。开始调查“开始调查”是一个动作，执行后工单状态相应的变为“调查中”，表示目前正在调查和诊断该问题产生的原因，调查和诊断可能是一个反复的过程，需要重复进行多次，而重复一次均更加接近我们想要的解决方案。执行开始调查不需要输入备注，只是一个动作，用来将工单状态从“评估中”转换到“调查中”，以表明当前运维人员已经着手处理该问题了。在这里系统会和配置管理以及基础架构组件联动。可关联配置信息、产品的供应商信息、产品的技术说明及错误信息等，关联产生问题的节点运行情况信息，例如可用性报告、性能报告等。为工作人员分析问题原因提供依据。拒绝调查“拒绝调查”是一个动作，发生在工单经评估后不认为是一个问题或者问题描述不清，则可拒绝调查该问题，拒绝时需要输入拒绝的理由，工单状态变为“被拒绝”。处于“被拒绝”状态的工单可以重新提交，重新提交后工单状况再次变为“评估中”。结束调查“结束调查”是一个动作，当问题分析人员找到问题原因并找到解决该问题的临时或永久解决方案时可结束调查，在ITIL规范中，问题此时被转换为“已知错误”状态，结束调查时必须输入调查出来的问题原因，执行动作后工单状态变为“已知错误”。制定方案“制定方案”是一个动作，表明该问题背后的故障已经找到了，目前正在制定解决方案，工单状态进入“方案制定中”。提交方案方案制定结束，需要提交给问题经理审批，提交方案有两种方式，一种是直接输入具体方案；另外一种也可以将一份解决方案文档作为附件上传（分析人员也是很有可能在制定方案时写了几份文档），提交后工单状态进入“方案审批中”。审批方案对于提交的问题解决方案，需要经过问题经理的评审，问题经理会从方案所需要的时间、对业务的影响程度、人力成本，财务成本等多方面做出综合考量后来做出审批决定，审批结果有2中：方案不通过被退回，要求改进解决方案；审批通过，工单状态进入“解决中”。提出变更一旦工单状态进入“解决中”，则表明运维人员正在根据解决方案解决问题，此时有2种情况，一种是不需要对IT基础设施做出变更即可解决问题，比如规章制度上的修改、客户IT知识的培训等等；另外一种是必须对IT基础实施做出变更才能彻底解决问题的，这个时候可以发起变更请求。在单个问题工单的生命周期里面，可以发起多次变更请求，要发起变更请求，问题工单必须进入“解决中”状态，否则不能发起变更请求，也就是说处于“解决中”状态的问题工单页面上必须出现“提交RFC”超链接，当然如果问题无需变更即可解决的话，运维人员是不需要点击该链接而直接可以选择解决工单。解决工单在解决问题的过程中，如果问题导致了严重的事件，如果一时半会找不到永久解决问题的方案而又需要紧急解决的话，那么制定的方案可能是一个临时方案；或者说问题综合考虑下来不需要修复，比如公司自己的信息中心开发了一套业务系统出现了逻辑上的bug，需要修改源代码，但由于之前开发的人员已经走了，修改的难度、时间、成本都很大，而公司已经决定在年底购买商业软件公司的产品了，那么此时该问题很可能做出的决定就是不修复。解决问题后，点击“解决问题”按钮，此时提供3个选项来表明解决是临时修复或永久修复或不修复，用下拉列表框选择，保存后工单状态变为“已解决”，这3个属性只是额外附加用来说明解决的性质的，不管选择的是哪一种，工单的状态均为“已解决”。如果在问题管理流程中提交了RFC，则意味着该工单有一个到多个与之相关联的RFC，只有在所有这些相关联的RFC全部解决并关闭后，才能够将该问题工单标记为已解决，这个问题管理工单才算是真正解决。重新打开如果问题没有真正解决却被置为“已解决”，那么可以重新打开，执行重新打开操作后工单状态变为“重新打开”。关闭工单问题经过核实确实得到解决后被具备“关闭问题工单”权限的人员关闭，可输入备注，工单被关闭后状态变为“已关闭”，表明该工单生命流程结束。4.5 变更管理基于ITIL标准的变更管理流程如下图：变更的发起变更的发起一般是由变更申请人提出，主要收集变更的目的、类别、变更风险、变更的执行计划，计划开始时间、计划结束时间等相关信息，此处的关键在于变更的相关信息要完整、准确地记录下来，以便变更经理和CAB委员会有足够的信息对变更的可行性、风险进行准确评估。尤其需要注意的是每次变更均应该尽可能地记录下来，以便企业能够按照季度、年度对变更的数量和质量做出评估，提高IT服务的质量。与CMDB的关联CMDB中保存着各种各种的信息资源配置项，变更实际上是对这些资源配置项进行修改的过程，在对业务进行变更时，落实到CMDB中会有增加新的配置项、修改已有的配置项或者删除不再存在的配置项，所以在提交变更请求时，有必要将本次变更会涉及到的配置项一并关联起来，在进行变更风险评估的时候，变更经理或CAB可以很清晰的看到本次变更会影响到哪些配置项。变更风险的评估这一步是变更计划是否能够通过的关键所在，一般较小的对业务影响范围不大的变更由变更经理直接决定，影响较大的或者是变更经理无法直接决策的变更，可以由变更委员会来审判，变更委员会一般由企业内部的CIO、CTO、项目经理、总经理等组成，负责对重大的变更请求作出评估、决策，只有通过变更经理或CAB审核通过的变更才能够由发布流程去实施。变更完成后的评审关闭变更工单之前必须对变更进行实施后评审，如果变更成功实施，那么相关联的问题工单和变更工单才可以关闭，评审时填写一个单子，针对本次实施，给出评审意见，支持电子格式的评审意见文档作为附件上传。更新CMDB变更完成以后，本次变更涉及到的配置项需要由配置管理员更新到CMDB中，否则会造成CMDB中的配置项数据与生产环境下的数据不一致。4.6 发布管理发布管理，指将一组新增的或经过改动的配置项成功导入实际运营环境，发布管理负责计划与实施IT服务的变更，主要应用于大型的或关键软硬件的上线、割接，简单来说，变更管理流程负责审核变更对业务所带来的影响，评估风险以做出是否要实行变更的决定，发布管理流程负责落实审批通过的变更，根据变更计划安排人员，分解任务并监督任务的执行，最终成功的实施变更，默认的发布流程如下图所示（可以根据实际情况作出调整）：确定发布政策和规划变更审核通过后，需要启动发布流程来实施变更，一个发布流程的结束对应的是一次变更的完成，启动发布时首先需要制定好完整的发布计划，包括发布类型、发布时间、参与人员、任务分工，计划完成时间、发布失败时的回滚计划，然后提交一份发布计划工单，发布计划需要由相应的发布经理进行审核后才能执行。注意发布计划不能单独提交，只能由变更管理流程触发，只有变更的风险评估通过后才能启动发布流程，创建发布工单。审核发布计划发布计划制定好以后，需要进行审核以确保发布计划的正确性和合理性，只有审批通过的发布计划才允许执行，审判通过后发布经理根据计划安排分配具体的任务，一项发布可以分解为若干具体的子任务，交给不同的人去协同完成。测试、试运行及验收发布完成后需要进行全面的测试，发布应该由用户代表对其进行功能测试并由IT管理人员进行操作测试，只有测试通过以后才可以进入试运行的阶段，测试还应该涉及到安装配置手册、用户操作指导书等文档的验证，只有发布成功后，与该发布相关联的变更才允许关闭。与变更流程的关系一般而言，发布流程均是因为企业要对当前环境内的软件系统、硬件配置、网络基础设施等进行变更而导致的，所以是从变更管理流程中启动发布流程，如下图所示，在一个变更流程的详情界面中，当变更审批通过后，可以点击“启动发布流程”按钮来提交发布计划。变更管理还需要确保对发布进行了充分的测试，只有当整个发布流程完整结束后，才能够关闭该发布流程所关联的变更流程。4.7 配置管理配置管理负责提供这样一个虚拟数据库，来记录大量的这些基础信息和它们之间的关系，并提供科学化的流程来负责核实IT基础设施中实施的变更、配置项之间的关系是否被正确地记录下来、监控IT组件的运行状态，以确保配置管理数据库能够准确地反映现存配置项的实际版本情况，一般来讲，对配置项的修改不应直接进行，必须由变更管理流程发起，因此配置管理与变更管理是紧密结合的，变更管理流程引发和控制对配置项的修改，相反，配置管理向变更管理提供详细的信息，以帮助变更经理分析评估比变更带来的影响。实施配置管理的好处：l 所有配置项被正确识别；l 确保配置项信息的完整性，并保留配置项历史变更记录；l 必须准确描述配置项之间的各种关联关系，并随时监控这些配置项的状态；l 协助处理变更、识别和解决问题并为用户提供支持，能够提供高质量的IT服务；l 帮助确定受影响的配置项的位置，并负责对配置项的修改和替换进行管理，能够有效地解决问题；l 提供有关维护成本和维护合同、许可证和许可证有效日期等方面的信息，以便帮助IT运维部门制定更精确的支出计划；l 问题发生时，配置管理可以帮助进行快速而准确的影响度分析，从而可以更快速而有效地处理变更。CMDB的分类配置项分类实际上是在实施CMDB之前要做的一项工作，根据企业的实际情况进行配置项分层，过少的层次和过深的层次都有不利影响，系统出厂时自带的配置项类别如下所示，真正实施时，可以根据实际情况做调整。配置管理数据库包括的资源数据如下：1） 网络系统：核心交换机、接入交换机、核心路由器、接入路由器2） 计算机系统：小型机、Pc服务器、刀片服务器、负载均衡设备、操作系统、数据库、中间件、存储备份设备3） 安全系统：补丁分发系统、病毒监控预警系统、防病毒软件升级系统、入侵监测系统、防火墙、PKI/PMI系统、漏洞扫描系统4） 辅助设施：动力、空调、消防、防雷、门禁5） 动态资源：IP地址、域名、邮件6） 业务应用系统：重要应用系统、门户网站7） IT组织：组织、人员、供应商、工作组、角色、其他CI属性针对CMDB分类中的各CI的属性，可根据CI属性定制功能自定义科学合理的软硬件资源基础数据模型。CMDB建立配置管理数据库的建立是一个逐步完善的过程，由于各种各样的信息数据均可以加入到CMDB，这出现一个颗粒度的问题，究竟什么样的数据才应该放到CMDB中，什么样的数据不应该放到CMDB中，提供了手工和自动相结合的方式来录入资源数据，包括：1. 从监控系统中自动导入，依托监控管理模块强大的自动发现能力，-可以轻易的自动发现网络环境内的各种网络设备（交换机、路由器、防火墙等），服务器（支持Windows、Linux、Solaris、IBM-AIX等多种操作系统）、数据库（Oracle、MS-SQL、MYSQL、DB2等）、中间件（JBoss、Tomcat、Weblogic、WebSphere等）等发现的资源可以自动进入CMDB。2. 从Excel中导入，对于用户手工维护的信息资源，提供了Excel模板，用户仅需要按照模板规定的格式，将信息资源数据写入Excel，即可使用系统提供的Excel导入功能导入到CMDB中3. 手工添加，根据选择的配置项类型，逐项填入配置项实例的各种属性保存到CMDB配置项关联管理的设置各种配置项之间并不是孤立的，而是存在着多种物理或逻辑上的关系，-配置管理模块提供可视化的关联关系映射功能，可以在拓扑图上通过拖拉的方式定义各个配置项之间的关系，包括：n 构成：这个指配置项之间的父子关系，比如某块硬盘构成了某个服务器的一部分n 安装于：这个指配置项之间的物理位置关系，比如某台路由器被安装在了某个机柜上n 连接：如某台服务器连接到了某台交换机的某个端口上n 需要：如某套应用系统需要服务器的支持n 关联：如某台应用服务器与某个数据库实例之间的关联关系n 其它用户自定义的关系，用户可以根据实际需要对系统出厂自带的配置项关系进行扩充以满足CMDB可视化展示的实际业务需要。配置项的变更CMDB一旦建立好以后，为了确保配置项属性和当前生产环境的匹配，杜绝随意变更对数据完整性、准确性带来的负面影响，有必要规范配置项的变更流程，配置项的变更包括以下几种类型： 配置项类型的改变：这涉及到配置项数据结构的变动，包括增加新的配置项类型，修改现有配置项类型的属性种类，通常是由于管理上的需要而需要对数据结构做出改变 配置项实例的改变：这包括增加新的CI或删除现有的CI，通常是因为新的IT基础设施被引入到现有环境：设备报废引起的从现有环境移除等操作 修改配置项的属性：这个指对现有配置项的属性进行改变，比如某台服务器的口令发生了变化、服务器的CPU个数发生了变化、网络内配置的VLAN发生了变化等，此时就需要对配置管理数据库中相应的CI进行变更，否则会造成生产环节下的数据与CMDB中的数据不匹配，造成不必要的负面影响，一般情况下，应该对CI的修改应该首先发起变更申请，由变更流程来评估修改配置项对业务造成的影响，在可控的范围内由人工或系统自动的方式对配置项进行修改。CMDB关系可视化CMDB中的配置项数量庞大，如何将这些硬件网络设备、服务器、数据库、中间件、网站、邮件服务、FTP服务以及客户积累下来的各种业务系统之间的物理和逻辑关系映射可视化，使得IT运维人员能够从业务的角度可视化的理解这些配置项之间的依赖关系，并分析各个配置项对业务整体带来的影响？如果能够提供配置项可视化的视图，IT运维人员看图就可以了解其对业务的影响，无疑可以大大提高IT服务的水平，-配置管理模块提供CMDB的可视化功能，通过拖、拉的方式绘制业务拓扑图，并可以在拓扑图上直接划线连接各个配置项，实现对配置项之间各种关联、依赖关系的定义与维护。CMDB灵活定制支持类别的自定义功能，类别的定义采用树状结构，父节点下可定义多个子节点。父节点和子节点的CI属性之间有依赖关系，子节点自动继承父节点的所有属性，子节点可在父节点属性的基础上增加自身的特色属性。不同分类的配置项，其属性并不相同，支持根据CI分类自定义其属性，可以添加新属性、删除旧属性，一旦添加新属性，则所有该分类的CI实例则自动同步增加该属性，比如为分类二层交换机增加一个交换能力属性，则当前系统中的所有二层交换机实例都必须自动新增一个称之为“交换能力”的属性，至于属性值则可以为空，但添加属性值时可以设置默认值，如有默认值，则所有CI实例也必须同步添加该默认值。删除属性时，系统必须判断当前有没有对应该分类的CI实例，如果有的话则需要提醒用户。4.8 值班管理为了确保IT业务系统724正常运转，响应客户的IT服务请求，IT部门安排人员值班是非常有必要的，值班表模块用来对IT运维部门人员的值班工作进行管理，确保值班人员安排有计划、有步骤的执行，不乱套，有案可查。产品默认提供了值班管理模块，Apex OssWorks值班表管理模块支持自由创建值班类型，可以根据创建的值班类型创建值班模板，并可将值班模板应用到月，并支持打印功能，IT运维中心人员可以在服务台上方便的看到任意月份与某天的各种值班类型的人员安排情况。班次设置班次设置是排班的基础，用户可以自定义班次，定义班次的名称，指定时间段，已经颜色标识(颜色标识用来在不同的视图上展示)。排班管理产品默认提供两种排班方式，按天为周期进行排班，按周为周期进行排班。也可以根据用户的特定规则，进行自动排班。调班管理对于已经排好的班次，可以进行调班。已经调班的人员，在值班视图上会用不同的颜色标记加以区分。值班表视图排班周视图以周为单位，显示本周的各个班次的排班情况。调过班的人员通过特定标记与其他人员区分开来。排班月视图4.9 知识库管理运维管理系统建设的目的不仅仅是规范、记录、督促等管理工作，而且还要帮助各级运维人员提高技能水平，简化IT服务任务。知识管理负责搜集、分析、存储和共享知识和信息，其主要目的是通过确保提供可靠和安全的知识和信息以提高管理决策的质量。同时也是降低对具体某个个人依赖的手段。这些需要通过知识经验的积累和共享来完成。对于IT运维来说，管理经验的积累与传播是非常重要的一个手段，新的IT运维人员可以通过老员工累积下来的知识记录迅速提升运维经验，老员工忘记后也可以随时查阅知识库记录。因此知识库系统包括了知识提交、知识审核、知识检索等功能。知识库管理员通常由具备丰富IT运维经验的资深专家来担任，只有他们才知道方案的正确、完善与否，否则知识库中一旦出现错误的信息，会导致不可预料的后果。统一知识库贯穿于系统的各个层次，包括采集、分析、运维知识库等不同层次，包括信息内容、专家技能、标准规范、考核指标等不同内容，通过知识建设降低对个人依赖，实现运行知识的有效共享。知识库模型面向运行维护的知识库，作为IT服务管理的知识核心，提供了各个层面的知识管理，协同解决知识共享和再利用的问题。将IT运行管理提高过程建立在知识积累和共享的过程之上，将知识管理作为IT监控和管理的指导核心，并针对行业性知识和规范提供支持。知识库流程1、创建知识由知识创建者创建新知识，并提交到知识库。也可以通过事件管理、问题管理等其他外部流程提交知识到知识库中。2审核知识知识库管理员将对提交的新知识进行审核，包括知识的规范性、完整性、可用性等，对于不符合知识规范的，将其废弃。知识审核将保证知识的来源可靠及理论可行性。3知识验证在测试平台实地验证知识的真确性和有效性，并确认知识使用场景。4知识废弃当知识没有通过评审或验证时，表明提交的知识不可用或知识有误，所以知识将从知识库中移出作废。5知识发布知识库管理员将已经通过验证的知识进行发布，以便于用户的查询和使用。知识的来源APEX OSSWorks运维管理平台提供基于WEB的交互式知识库，运维人员以及普通用户均可在此进行关键字的深度检索。服务台人员也可直接通过故障报修的故障类型或故障描述关联到知识库。知识的来源包括直接录入的知识和事件单、问题单为基础的知识。知识库管理提供知识的输入系统，输入系统支持字体大小、颜色、排版等编辑功能、支持图片、文档、视频等不超过40M的附件上传。事件单、问题单在处理完成后可直接提交为知识，提交的知识由知识库管理员审批通过后可显示到知识库中。知识发布系统系统具有面向用户和面向IT工程师的两个知识库发布系统。面向用户的知识发布系统采用百度知道式的设计，界面友好、分类清晰。提供积分榜功能，促使用户提高回答问题的积极性。用户可对问题的回答质量进行评价，可显示知识被阅读和引用的次数，促使用户不断提升问题回答的质量。面向用户的知识发布系统面向IT工程师的知识发布系统界面简洁明了，以列表的方式显示所有问题简介。面向工程师的知识发布系统知识的检索系统提供关键字的检索功能，每增加一条新的知识，系统会自动对知识的标题和内容进行分词，用户输入关键字及可准确的查找到自己需要知识，支持模糊匹配。知识库权限知识库具有完善的权限控制功能，可分为提交、只读、修改、删除和审批。不同的角色和用户具有不同的权限。知识库管理员具有上述所有权限、普通用户只能对自己回答的问题进行修改和删除。4.10 自定义流程APEX OSSWorks提供业内成熟、功能强大、性能稳定的流程引擎产品，通过使用流程引擎，可以使得技术支持或者高级用户通过使用流程建模工具即可完成流程设计，规避了运维人员不懂软件开发技术、软件开发人员不懂业务所带来的困扰；通过对流程的建模（结果以XML格式呈现），方便我们根据企业多变的业务情况灵活修改，流程引擎帮助我们管理各个流程实例的状态，运维人员只需要在此基础上加入业务特定要求的表单数据即可，大大简化了流程设计的复杂度、降低了开发时间和财务成本，提高了软件交付的时间，也提高了软件的稳定性。自定义流程流程设计提供对流程的图形化自定义设计，便于用户根据需要和实际情况设计流程模板。流程的配置和运行情况都有图形化的界面，易于配置、便于检查、简化管理。APEX OSSWorks基于JBPM流程引擎开发，该流程引擎提供图形化的流程设计器，客户可以根据需要使用拖拉的方式设计符合企业需要的流程，流程支持任务节点、状态节点、判断节点、并行节点、合并节点，并设定该流程涉及到的业务字段（即自定义表单技术，不同的业务流程涉及到的业务模型数据均不一样，这需要为不同的流程设定不同的表单字段，同时在用户界面上能够动态生成）,流程节点的任务分配类型、任务分配方式，流程节点的访问权限（支持设定具体的人、具体角色、具体工作组），流程节点超时处理方式（自动流转到指定节点、发送短信和邮件通知）。图形化的流程设计器一图形化的流程设计器二流程业务表单设计流程节点任务分配方式设定流程执行流程执行时，能够指定到具体的处理人、具体的工作组、具体的角色，当流程停留在某个节点超过一定时间时，系统会根据预先设定的超时策略自动流传到指定节点并发送邮件或短信通知。在流程工单的详细界面上，提供了该流程的执行步骤和详细的数据情况，方便事后一目了然的了解流程的历史执行步骤。流程节点角色权限设置流程自动流转流程审计流程在执行的过程中，每一步处理了多少时间，由谁进行处理，处理的结果如何都会形成详细的流程记录，并保存在数据库，当需要查看某个流程的历史记录时，系统将以图形化的方式展示某个流程的具体历史执行步骤，是有谁在什么时候处理的，处理的结果如何，处理的意见如何，非常直观方便。4.11 移动运维OSSWorks移动运维客户端软件支持的手机硬件型号如下：1.Android 2.3+、Android4.0、Android4.1版本，分辨率支持800*480，1280