|
|
知识路径： > 大型网站运维 > 政府门户网站运维案例分析 >
|
被考次数：1次
被考频率：低频率
总体答错率：63%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
相关知识点：37个
|
|
|
|
|
|
|
（1）门户网站及内容管理平台应用的安全性。确保网站能够正常访问；确保网站群动态应用正常，并能够提供正常的服务。
|
|
|
|
（2）门户网站及内容管理平台数据的安全性。确保数据库中的信息跟网站发布的信息一致；确保数据库数据正确，不被非法破坏，并且及时做数据库和网站数据的备份，当意外发生时，网站能够及时、完全恢复；未经许可，不得将网站数据泄漏给其他个人或组织；由专人负责，保证数据的安全。
|
|
|
|
|
|
运维要求系统不间断服务，即提供7×24不间断服务，专人值守，监控网站；意外情况下，及时通知信息中心相关负责人，并做好各项应急准备。定期向信息中心相关负责人汇报网站运营情况。另外，对于响应时间也有要求，所以要监控网站群访问速度，如访问响应时间过长，及时查找原因，并向信息中心相关负责人汇报；监控网站群动态应用，对影响应用性能方面因素及时预警，并提出相应解决方案，及时汇报给信息中心相关负责人。
|
|
|
|
|
|
只有高效、稳定、个性化的本地化服务模式才能满足用户随时随地的服务需求；也只有迅速的维护响应才能真正保证用户的利益不受损害。因此在自身服务体系的基础上，针对政府门户网站内容管理平台运维项目，特定IT服务体系，由响应体系、维护体系和质量监督体系构成。
|
|
|
|
（1）客户需求。在服务协议规定范围内的任何服务请求，包括咨询、问题申报、投诉等。
|
|
|
|
（2）响应体系。第一时间受理客户的需求，以最快的速度解决问题，保障客户系统尽快恢复正常。
|
|
|
|
（3）维护体系。对客户系统进行主动式服务，发现并解决系统隐患，优化系统性能，并提出合理的改进和升级建议。
|
|
|
|
（4）质量监督体系。为保障服务的质量制定相关的服务协议，通过满意度调查等方式评估服务的提供是否正常。
|
|
|
|
IT服务体系最终都可以通过本次项目建设的ITIL运维体系落实，响应体系对应ITIL运维体系的“事件管理”，维护体系对应ITIL运维体系的“问题管理”，质量监督体系则通过“运维管理”来实现。
|
|
|
|
|
|
响应体系包含服务台和突发事件管理，主要任务是受理客户的服务需求，尽快恢复客户系统的正常运行。
|
|
|
|
客户有问题可以通过热线电话、Email与服务台联系，服务台负责接听技术服务电话、受理客户问题，进行记录，分类并转给相应的工程师处理。二线工程师负责处理服务台分配的事件或问题，当二线工程师需要技术支持时，可以从公司总部或第三方获得到技术支持和实验室环境支持。
|
|
|
|
|
|
ITIL提供了一个概念化、模块化的优秀框架，与其说是解决方案，不如说它更像理论。它提出了建立IT服务管理体系时要考虑哪些流程，提到了应该做哪些，好处在哪儿，但并不详细介绍怎样去做，因此它本身不具备实际操作可能性。
|
|
|
|
在长期的运维项目中积累的丰富的经验，根据政府门户网站的实际情况，对ITIL进行适当选取、适应和扩展。
|
|
|
|
（1）导入ITIL是一个长期过程，运维初期，以“系统日常运行和支持”为主，重点解决服务支持（Service Support）流程，对发生的问题进行维护和处理。在运维后期，运维的服务支持流程步入正轨后，再关注运维服务的长期计划和改进，考虑服务提供（Service Delivery）。
|
|
|
|
（2）针对政府门户网站，运维的主要任务是解决发生的问题，对IT基础架构进行基本的配置管理，因此主要实现“服务台”“事件管理”“问题管理”和“配置管理”，至于变更管理在实际运维中，暂时没有系统工具支持。
|
|
|
|
（3）由于初期运维工作内容多，系统繁杂，人员少，为提高运维人员解决问题的能力和效率，运维体系扩展加设“知识库”，以提高运维技术的积累、传承、利用。
|
|
|
|
经过对ITIL体系进行适当选取、适应和扩展，从适合政府门户网站，适合运维团队完成任务目标为主，制定了个性化的运维体系。
|
|
|
|
个性化的政府门户网站运维体系设置“服务台”统一接受各种故障受理，包括最终用户直接电话或邮件传来的求助信息和运维监控软件传过来的自动报警信息，然后对服务台问题分析并归类，力求初步解决用户或系统的故障；不能在线解决的需求问题，启动“事件管理”和“问题管理”流程，运维人员按照既定的流程，在“知识库”和“配置管理”的支持下，解决故障，并把积累的经验知识归入知识库。问题解决后，运维体系反馈到IT系统，促使其更好更稳定运行，并促进其优化和完善。
|
|
|
|
其中，“知识库”和“配置管理”可以依托运维监控工具实现信息化作业，而“服务台”“事件管理”和“问题管理”则仍然依照对应的制度人工操作，暂时没有信息化系统辅助运行，可以考虑在后期建设运维平台时优先实现。
|
|
|
|
所有的事件都应该基于影响度、紧急度和优先级进行分类分级，并提供相应的解决方案和临时方案，如下表所示。
|
|
|
|
|
|
|
|
一级故障是指系统发生严重故障，业务发生中断，或虽然业务未中断但已经无法保证及时、正确的情况，对用户业务的运行有严重影响。
|
|
|
|
二级故障是指对于系统发生的非严重故障，业务并未中断，业务仍然及时、正确的情况，但性能有所下降。
|
|
|
|
三级故障是指系统发生轻微的故障，系统有警告信息等，对系统没有较大影响的故障。
|
|
|
|
|
|
在信息化运维中，制度建设是一道必要的保障。信息化不能一蹴而就，在信息化发展到一定阶段，建设重点应该要从系统实施转向以应用运维提升为主，运维质量保障、安全机制变得重要起来，这时除了技术的保障以外，制度保障越显得重要。
|
|
|
|
对于IT运维团队来说，可从以下几个方面来进行IT运维制度化。
|
|
|
|
（1）转变运维观念，树立规范化意识。只有建立制度化的IT运维意识，才能在日常繁杂琐碎的工作中有效的区分任务的优先级，将有限的资源投入到最能满足“客户”需要的工作中。
|
|
|
|
为保证运维工作，把运维工作和制度化紧紧地捆绑到一起。运维工作很琐碎，关键在于规范而不是创新。只有各级运维技术人员一丝不苟、老老实实按规范做，才能够把事情做好。
|
|
|
|
（2）建立事件处理流程，强化规范执行力度。首先需要建立故障和事件处理流程，利用表格工具等记录故障及其处理情况，以建立运维日志，并定期回顾从中辨识和发现问题的线索和根源。建立每种事件的规范化处理指南，减少运维操作的随意性，在很大程度上降低故障发生的概率。
|
|
|
|
同时，建立IT运维制度非常重要，但是有了制度还要有人去执行，要强化执行制度比建立制度更重要的观念和意识。
|
|
|
