除了业务需求之外，还需要明确IT服务的目标，在可用性目标的制订中，应涉及可用性、可靠性、可维持性等方面。应考虑从正常状态到发生重要服务损失的所有情况。同时应该为已知的数据量、用户量的增减、预期的工作量高峰和低谷以及其它已知的将来的变更做出计划。应结合业务影响性分析结果和重要IT资源和应用优先级来进行可用性设计。

　　在制定可用性计划的过程中，我们充分考虑未来的业务需求及计划，并和业务部门进行了深入的探讨。

　　在运维队伍中，可用性经理负责对IT服务可用性计划定期维护、及时更新，保证计划维持在有效状态，以指导IT服务可用性管理和改进。

　　目前，我们利用已建立的监控系统，建立了重要应用系统的可用性报告，根据该报告和该应用系统的可用性要求（如工作日、工作时间内99.9％的可用性），制定了下一阶段的系统改进计划，全面保证应用系统的高可用性。

　　业务连续性管理是一个对IT资源的业务连续性进行有效管理的流程。它为了确保重大灾害与意外事件发生时，上海市房屋土地资源信息中心运维团队的IT运维服务能够在既定的要求时限内恢复正常运作，从而减少运营风险、降低社会影响。

　　业务影响分析：我们依据包括用户需求、社会影响、内部管理重要度、期望值与恢复策略等在内的各要素，进行业务影响分析（BIA）并制定《关键业务影响分析表》。该表反映了可能导致上海市房屋土地资源信息中心运维中断的重大影响项目、伤害属性、严重等级、中断最大可忍受时限等数据。

　　IT服务连续性规划：根据《关键业务影响分析表》协调我们制定《关键业务恢复计划表》，经过专家评审后作为当发生重大灾难时的执行依据。然后依据《关键业务恢复计划表》及《关键业务影响分析表》来规划制定《灾难恢复计划》，并将其作为系统恢复作业的依据，确保该系统执行恢复作业的有效性。各系统灾难恢复计划的规划与执行若遇有资源冲突，应交由高层决定其优先级分配次序，并在《关键业务恢复计划表》中予以说明。

　　IT服务连续性计划的实施与测试：

　　《关键业务恢复计划表》中相关系统的灾难恢复计划应同时进行测试及演练。

　　测试后依照测试结果修正《关键业务恢复计划表》和《灾难恢复计划》，并提交《测试记录表》。测试结果与修正后的《关键业务恢复计划表》送交审查。

　　测试失败或部分失效，应立即检讨并提出纠正及改善计划，或再进行测试予以确认。

　　《关键业务恢复计划表》经核准后，对所有业务相关人员进行培训了，且每年实施一次对关键业务系统的演练，以便在发生重大事件时能正确使用该计划，所有的演练均保留纪录，形成《灾难测试记录表》。

　　目前，我们已经对内外网分别制定了全套的数据级业务连接性文档，并进行了数据级的业务连续性计划演练。以后每年将演练一次，同时，我们计划逐步把规划和国土系统的灾备从数据级提高到应用级。

　　IT财务管理流程主要包括预算、核算两个子流程。

　　预算子流程主要包括在提供IT服务前对有关成本开支所做的预测和估算。

　　核算子流程主要包括针对IT运维服务中产生的费用成本进行核算、计量和报告等活动。

　　目前，我们根据财政局的相关规定，结合预算子流程，每年科学、合理的申报预算，对于预算的执行，我们根据核算子流程，对每一笔费用进行全过程跟踪，包括如项目立项、招标、评标、合同签订、分期付款、设备到货、固定资产形成等各个环节。因此在财务审计时，也得到了有关方面的好评。同时，关键节点集体决策、关键信息内部透明，对反腐倡廉也带来了积极意义。

　　4IT运维服务的支持

　　IT运维服务支持是钊对应用系统的使用者，如市局人员、区县局用户等。服务台和事故管理是主要面对用户的服务功能和流程，其次根据任务性质分解为问题管理、变更管理、发布管理和配置管理等流程。

　　服务台作为一个面对用户唯一受理的前台服务角色，不仅负责处理日常的事故、疑问和客户的咨询，同时还为其它活动和流程提供接口。这些活动和流程包括客户变更请求、维护合同、外包设备巡检、配置管理、可用性管理和持续性管理等各种内容。在运维体系中，我们制定了详细的呼叫响应时间、满意度反馈等服务台工作指标，从而能够量化的对每个服务台人员进行考核，全面提高了服务质量。

　　事故管理是对事故发生、诊断、到关闭的整个生命周期中实施管理，并定义支持运作事故管理流程相关的人员职责。

　　目前我们建立了统一的服务台，并分成多个服务小组，通过IP电话对外提供统一的服务接口，但各小组服务于不同用户群，实现了“统一服务、支持分工”,从而提高了服务响应速度，减少服务处理时间。现阶段，服务台共有14人组成，分别针对PC桌面支持、应用系统支持、网络支持、后台支持等若干小组。

　　事故的来源有用户的报障和请求、监控系统的告警。所有事故处理全部被记录在事故数据库中，并可以被建立到知识库中被重复利用。一线服务人员在接到报修电话后，只需要按照系统相关知识库的内容，按照步骤操作下去即可，因此，对于服务台的一线人员来说，不需要很高的技术水平，就可以进行维护支持。这样，对一线支持人员从业要求降低了，人员流动成本也就降低了。当一线服务人员不能解决时，就升级到二线维护人员，二线维护人员的分析过程、解决过程也全部记录在数据库中，一线人员通过学习以往事故处理记录就能提高业务支持水平。

　　同时，我们针对一线和二线支持人员建立了绩效考核的指标，如欠缺或者是不正确的信息的数量和比例（错误分类的事故/错误优先级的事故/重分派的次数/信息记录不当的事故），超时的事故数量和比例。通过绩效考核，有力地调动了一线和二线支持人员的工作能动性，从根本上提高了IT服务质量。

　　问题管理是对问题创建、故障根源诊断、到关闭的整个生命周期中实施问题管理，并定义支持运作问题管理流程相关的人员职责。

　　问题的来源有没有解决的事故，或者多次重复的事故，但也有可能是不通过事故管理流程而直接创建问题。如，当IT技术支持人员进行趋势分析、发现问题时就会出现这种情况。

　　问题的处理流程如下：问题分析员首先分析问题，发现原因，此时问题变为已知错误，然后，根据经验，采取临时解决方案或永久解决方案。

　　变更管理是用于管理和控制信息中心内IT生产服务环境中发生的变更的流程。它是一个关键流程，通过规范的变更控制和管理，来减少或者消除变更对关键生产服务带来的风险和影响。

　　变更管理流程起始于一个IT变更的请求，即RFC。变更请求可以由上海市房地资源信息中心的IT员工发起，也可以由信息中心的员工代表用户提交有关于IT系统的变更请求。RFC经过受理、分类，然后审批、评估，再经过安排日程和分发任务，接着是构建变更、实施变更/处理例外变更，最后进行关闭。关闭后的变更还会对质量定期进行后评估。

　　发布流程是将一组通过测试验证后的变更导入实际生产环境的管理控制流程。发布流程要求发布的版本必须是经过测试或验证的。发布负责处理变更任务在技术与非技术方面的问题。通过发布流程的实施确保生产环境中变更得到有效控制，对IT服务产生最小影响，客户需求得到最大满足。

　　发布流程管控的活动范围是发布管理员在收到发布通知单开始，最终到发布到生产环境成功或回退的过程。

　　发布管理流程将在多方面对IT运维服务产生积极作用，具体表现在：

　　为变更管理提供有效的过程管控：设计和实施有效的过程来发布和安装IT系统的变更，确保软件的变更是可追踪的和安全的；

　　保证配置管理数据库的准确性：能够确认所有最终软件库中的软件正本是安全可靠的，并且在配置管理数据库中得到准确的更新；

　　利用配置管理和变更管理中的流程控制，在实际运营环境中实施有效的软件的发布。

　　配置管理起始于一个初始的规划和建设步骤，包括创建配置管理数据库（CMDB）。在初始化之后，该流程主要侧重于日常基础设施的鉴别和维护配置管理数据模型，以及维护配置数据。之后，该流程还负责产生配置信息的报表、定期进行审核。

　　配置管理的数据是IT运维服务的基础数据，包括设备和服务（如小型机、数据库、网络等），以及其他关键要素（如防火墙的ACL等），它类似于我们房地产管理中的地、楼、房基础数据，它被用于其他流程，如事故、问题、变更和发布流程。

　　为了更好的开展IT服务支持工作，我们利用IBM Maxmio工具建立了所有的IT服务支持流程。在该工具中，我们记录了所有IT运维服务所涉及的要素，我们记录了所有的事故及其处理经过，记录了所有的问题及其处理经过，以及所有变更和变更任务。

　　有一句话说，管理体系的实施，是从无效到有效，工具的使用，是从有效到高效。通过使用IBM Maxmio工具，让我们更加高效的提供了IT运维服务。我们曾做过一个最终用户满意度调查，获得了98％的高分。