|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
信息技术服务，因信息技术（Information Technology, IT）的特指性，信息技术服务广泛被业界人士称为IT服务。IT服务是服务的一种，因此继承了服务独有的特性。
|
|
|
|
通常而言，IT服务是指IT服务提供商为其客户提供信息咨询、软件升级、硬件维修等全方位的服务，具体包括产品维护服务、IT专业服务、集成和开发服务、IT管理外包服务等。
|
|
|
|
在《信息技术服务分类与代码》（GB/T 29264-2012）中，对信息技术服务（Information Technology Service，即IT服务）的定义是“供方为需方提供开发、应用信息技术的服务，以及供方以信息技术为手段提供支持需方业务活动的服务”。常见服务内容包括软件服务、硬件服务及其他相关的服务。常见IT服务形态有信息技术咨询服务、设计与开发服务、信息系统集成实施服务、运行维护服务、数据处理和存储服务、运营服务、数据内容服务、呼叫中心服务和其他信息技术服务。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
运维是运行维护的简称，是一种IT服务形态。在《信息技术服务分类与代码》（GB/T 29264-2012）中，对运行维护服务（operation maintenance service）给出的定义是“采用信息技术手段及方法，依据需方提出的服务级别要求，对其信息系统的基础环境、硬件、软件及安全等提供的各种技术支持和管理服务”。
|
|
|
|
运维是信息系统全生命周期中的重要阶段，也是内容最多、最繁杂的部分，是对信息系统提供维护和技术支持以及其他相关的支持和服务。运维服务的主要对象包括基础设施、硬件平台、基础软件、应用软件以及依赖于IT基础设施的数据中心、业务应用等信息系统，其范围可以是单个IT基础设施的运维，也可以是整体IT基础设施和业务应用的总体运维。运维服务交付内容主要包括咨询评估、例行操作、响应支持和优化改善。
|
|
|
|
在《信息技术服务分类与代码》（GB/T 29264-2012）中，将运行维护服务分成基础环境运维、硬件运维服务、软件运维服务、安全运维服务、运维管理服务和其他运行维护服务六类，每类运维服务及其说明见下表。
|
|
|
|
|
|
|
|
|
|
任何组织和个人提供运维服务需要依据需方提出的服务级别要求，并确保提供的运行维护服务符合与需方约定的质量要求。因此，具备相应运维服务能力是服务组织提供服务的必要条件，比如规范和明确运维人员的岗位职责和工作安排、提供绩效考核量化依据、提供解决事故和问题经验、提供知识的积累和共享手段、实现完善的IT运维管理、提高组织经营水平和服务水平等等。在《信息技术服务运行维护第1部分：通用要求》（GB/T 28827.1-2012）中给出了供方运维服务的能力模型，该模型定义了运行维护服务能力的四个关键要素：人员、资源、技术和过程，每个要素通过关键指标反映应具备的条件和能力。模型也给出了供方为持续提升运维能力的管理方法。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
服务级别协议（SLA）设定了IT服务的数量、质量、费用等相关标准，实现了IT部门和业务部门之间的全面协作，努力获得高质量的服务以及最大限度地提高服务效率。SLA不仅用于企业内部IT部门和业务部门之间，而且也将用于企业和第三方服务提供商之间（比如外包、应用开发服务、系统集成服务等）。
|
|
|
|
|
|
|
|
.定义每项服务的测量标准：例如数量、质量、可用性、可靠性、安全性、问题解答、支持、备份、恢复时间、偶然性、增长能力、开发请求。
|
|
|
|
.此外还应包括服务时间框架；服务成本及计费；对不履行职责所实施的惩罚。
|
|
|
|
|
|
.另外服务级别协议中也应包括企业和第三方服务提供商之间的明确职责。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
维护阶段是软件生存期中时间最长的阶段。软件一旦交付正式投入运行后便进入软件维护阶段。该阶段的关键任务是通过各种必要的维护活动使系统持久地满足用户的需要。每一项维护活动都应该准确地记录下来，作为正式的文档资料加以保存。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
数据库应用系统经过测试、试运行后即可正式投入运行。运行维护是系统投入使用后，必须不断地对其进行评价、调整与修改，直至系统消亡。
|
|
|
|
在任一设计阶段，一旦发现不能满足用户数据需求时，均需返回到前面的适当阶段进行必要的修正。经过如此的迭代求精过程，直到能满足用户需求为止。在进行数据库结构设计时，应考虑满足数据库中数据处理的要求，将数据和功能两方面的需求分析、设计和实现在各个阶段同时进行，相互参照和补充。
|
|
|
|
事实上，在数据库设计中，对每一个阶段设计成果都应该通过评审。评审的目的是确认某一阶段的任务是否全部完成，从而避免出现重大的错误或疏漏，保证设计质量。评审后还需要根据评审意见修改所提交的设计成果，有时甚至要回溯到前面的某一阶段，进行部分重新设计乃至全部重新设计，然后再进行评审，直至达到系统的预期目标为止。
|
|
|
|
|
|
|
|
|
|
|
|
|
