ITIL 4官方核心著作
02 ITIL应急管理评估
由 superadmin 于 2024/06/05, 11:06 最后修改
复制
导出
注释
打印预览
查看源代码
子项
评论
附件 (1)
历史记录
信息
ITIL应急管理评估
一、应急管理评估项
| 序号 | 应急管理评估项 | HP评估 | 评分 | 权重 |
| 1 | 请您介绍一下你所主管的部门主要职责、人员规模以及日常工作情况。 | |||
| 2 | 在您的印象中，有没有发生过因为IT服务中断对业务产生较大影响的事件？您如何看待服务的可用性和持续性？ | 之前曾发生过tuxdo积压事件，属于重大故障，重启完毕后恢复。启动了应急预案。实际上常规的处理基本上都包含在应急预案中，主要事件的处理都会参考应急预案的场景。发生新的重大故障并解决之后，会将其更新到应急预案的场景中去。 数据中心统一对事件分为6级，主要告警，都作为应急事件对待。次要告警按照常规事件处理。 | ||
| 3 | 在应急管理体系方面，网络中心或者信息中心是否有相关的应急策略，以保障重大紧急事件发生时，IT服务的影响降至最低？ | 数据中心有指导性的总体应急预案（北京数据中心总体应急预案），要求各部门参照此进行细化。中心的总体预案更新频度较高，但各部门细化的应急预案没有随之更新。 相对于应急流程而言，技术应急场景的更新比较及时。 系统管理二部运维工作基本要求中，对应急事件处置有原则性要求文档。 | ||
| 应急组织与保障（People & Resource） | ||||
| 4 | 有一位应急管理的全权负责人或组织机构，他被授权总体负责定义、管理和改进应急管理流程。 | 数据中心风险管理部负责全中心的应急管理，定期要求各部门更新应急预案、进行演练并出具演练报告。 | 好 | 高 |
| 5 | 有专人或组织部门负责执行应急管理活动，并且他（们）有足够的技能来完成该项工作。 | 应急事件发生时，由值班经理或者系统经理负责组织和协调，值班人员负责应急活动执行。参与应急的人员技能基本能满足要求。 | 好 | 高 |
| 6 | 实施应急管理所需的资源、技能和工具被清晰定义并能及时到位。 | 资源上，值班要求比较严格，人员24小时有保障，包括第三方的运维团队管理遵循建行的要求。厂商的资源，由技术部统一签订合同，基本能满足处里的使用需求。 技能上，至少基本的处理操作没有问题，比如服务启停。在需要时，不同技能的人可被调度，重点系统的维护有保障。 工具上，操作系统方面文档化比较欠缺，依赖于管理员对系统的了解，如果管理员不在，则可能需要联系管理员。一般的通用东西，由中心统一部署。但个性化的东西，可能没有文档化管理。尤其是厂商交接时的清单，没有对工具和资源进行明确的规定。 | 可接受 | 高 |
风险管理（Risk Management） | ||||
| 7 | 是否有正式的风险管理过程，通过对趋势、脆弱性与影响度进行识别，评估并选择控制方法或其他缓解手段？ | 有风险评估过程，但属于不定期的。一些重大的保障期之前（比如奥运）都会做风险评估，或者在出现重大事件后进行系统风险清理。 风险评估的过程一般由中心主导，风险和生产办来牵头。各系统管理员依照统一的风险梳理模板参照梳理，在技术层面，采用检查列表进行风险识别。另外，采用风险跟踪表用于跟踪风险控制的进展。 不足之处在于，虽然有统一的模板和方法，但各系统的风险评估计算标准并不统一。 | 可接受 | 高 |
| 8 | 当引入新的服务或对已存在的服务增加新的服务实例和实施重要变更前，是否都会执行风险评估？由谁来执行？有何参考依据？ | 在执行变更时进行详细的风险评估，大部分的变更都设置了关注列表（比如针对数据库变更中的数据导出，有详细的文档指导，说明此项操作需要关注多少个点）。另外，所有的变更，都需要中心审批。重大变更，需要CAB当面评审，以严格管控变更的风险。 | 可接受 | 高 |
| 9 | 风险评估结果是否有正式的文档化记录？如果有，请提供打印或信息拷贝。 | 有文档化记录的风险评估结果。 | 好 | 中 |
| 10 | 风险评估文档是否指出了可以用于减轻已被识别的风险的控制措施。 | 在风险跟踪表中指出了可用于减轻已被识别的风险的控制措施。 | 好 | 高 |
| 11 | 针对风险评估的结果，进行了恰当的风险跟踪，并定期回顾并更新风险管理文档。 | 缺少对风险整改的跟踪过程。 | 不完全 | 低 |
| 12 | 是否定期进行例行的风险评估和审计？如果可能的话，应由外部机构承担。发现的问题能够被报告出来，并据此采取改进行动。 | 风险部和生产办负责进行例行的风险评估和审计，但依赖于保障期梳理活动，不是常态化、定期的、持续的工作。一般只是政治性活动才触发。 各部门，除了完成技术中心的要求，没有单独的风险评估活动，只是在重大节日进行基本的巡检。 审计部仅从管理和安全的角度，定期对日常管理和系统风险进行审计，较少关注IT系统运营的风险。 | 不完全 | 低 |
应急预案和流程（Emergency Program & Processes） | ||||
应急准备 | ||||
| 13 | 应急预案中是否说明了恢复和运行IT服务所需的设备，基础设施，IT支持服务的安排，并确保他们在需要的时间和地点可以投入使用？您认为这些准备工作是否完善？请举例描述相关的准备情况。 | IT系统本身的配置信息在预案中都有明确阐述，对于IT支持服务的安排预案中没有涉及。（检查中心的文档是否有此内容） 配置项基本上都能及时更新。系统经理不定期进行检查，确保在需要的时候可用。 | 不完全 | 高 |
| 14 | 应急预案中是否明确了对人员和技术准备的要求，以保证应急预案可以在任何时候实施，并能满足服务的要求。 | 实际运营过程中，运行部作为数据中心各系统统一的服务台，负责应急事件的配合，但应急预案中没有明确其职责。 | 不完全 | 高 |
| 15 | 应急预案中是否定义了在服务恢复期间提供使用的合适的机房设施？ | 目前在应急预案中没有对机房设施提出要求，但备用设施的建设已经在数据中心的规划中体现。（准备在B座建立应急机房） | 完善的计划 | 中 |
| 16 | 应急预案中是否定义了在服务恢复期间各部门的配合要求？ | 在数据中心的整体应急预案中，明确了服务恢复期间各部门之间的协调配合要求。 | 可接受 | 高 |
| 17 | 应急预案中是否定义了在服务恢复期间提供使用的合适后勤保障？ | 中心的预案以及各部门细化的应急预案中，没有涉及到后勤保障的说明。在必要的时候，由中心统一考虑。 | 不完全 | 低 |
预案启动条件 | ||||
| 18 | 应急预案中是否定义了启用的具体条件？如果有，请详细描述预案的启动条件。包括启动的权限（例如，谁可以做？每个人都必须了解。）、启动的标准（应该考虑到损害的程度、可能的中断时长）。 | 应急预案中指出，当系统发生事件，并直接或间接影响到生产的情况下，就启动应急处理，力争在最短时间内恢复重要系统生产运行。 某个场景的启动条件。在故障描述中，有大致说明。但现象描述中，还有待具体量化以达到精确判断应急启动的条件。 启动标准，并不是所有人员都清楚（比如值班人员）。事件上报后，由系统经理来决定是否需要启动应急预案。 由于数据中心对A+系统的重视和投入程度较高，为了达到快速恢复服务的目的，将大部分事件都作为紧急事件对待，导致一般事件和应急事件的区别未显现出来。 | 不完全 | 高 |
| 应急组织架构 | ||||
| 19 | 预案中是否明确了每个组织成员的职责？如果有，请详细描述这种应急组织架构。 | 在现有组织架构基础上定义了应急组织架构，职责定义明确。但与数据中心的整体应急预案存在一定的差异。 | 可接受 | 高 |
应急时长/应急恢复目标 | ||||
| 20 | 应急预案中是否对恢复点目标（RPO）和恢复时间目标（RTO）有明确说明？对于XX系统的应急处理，应急时长是如何定义的？ | 预案中没有清晰的RTO、RPO定义，应急场景中所定义恢复时间，是技术操作的处置耗时，作为领导的参考。 | 不完全 | 高 |
| 21 | 应急预案中是否包含功能、性能、安全、运维管理和服务级别要达到的要求？请举例说明。 | 预案中没有清晰的RTO、RPO定义，应急场景中所定义恢复时间，是技术操作的处置耗时，作为领导的参考。 | 不完全 | 高 |
应急管理流程（包括应急管理流程图和流程描述）（建议展示典型的流程图给客户） | ||||
| 22 | 在紧急事件发生期间，如何识别危机并决策？请详细说明系统当前采用的危机识别流程。 | 故障应急等级定义作为危机决策和处理的参考，但缺少流程化的决策指导。 | 不完全 | 高 |
| 23 | 预案是否定义了在紧急事件发生期间的公关流程？ 系统的故障，是否会造成较大的社会和公众影响？如果需要公关流程，哪些人或组织负责公关行动？ | 如果影响到网银，或者受众有体验的时候，由生产办上报的技术部，具体如何处理不祥。（公关流程在外部） | 不适用 | 低 |
| 24 | 预案是否定义了在紧急事件发生期间和业务部门的沟通流程？依据您的经验，如果需要与业务部门沟通，哪些人或组织负责沟通？通常的沟通途径和方法是怎样的？ | 电子银行部作为主管业务部门，日常与系统II部直接沟通不多。系统II部主要采取垂直沟通机制，当发生紧急事件时，由运行部与业务部门进行沟通协调。 | 不完全 | 高 |
| 25 | 预案是否定义了在紧急事件发生期间，如何将紧急情况上报（至高层或上级领导部门）？系统的故障，是否必须报告至上级领导部门？是否上报由谁来决策？上报的标准是什么？上报的途径是怎样的？ | 技术管理部负责跨部门的沟通上报、通报等。紧急事件发生时，直接发到7楼运行维护部，由运行维护部负责决定发到什么层级的领导，其操作遵循数据中心的故障定级标准以及上报原则。 | 可接受 | 高 |
| 26 | 预案是否定义了在紧急事件处理之后的善后处理流程？由哪些人或组织负责善后处理？就系统而言，善后处理包括哪些环节？ | 有少量的场景涉及到技术层面的善后，包括一些总结报告。应急预案中缺乏明确的善后流程定义。数据中心的重大事件应急管理规范中有对善后处理操作的说明，但落实到系统II部的应急预案中，没有相应的体现。 | 不完全 | 高 |
应急处置步骤（含具体指令、执行人） | ||||
| 26 | 预案是否定义了在紧急事件发生期间的检查点和升级过程？请提供系统故障点的检查清单，相关操作手册，以及升级处理过程说明。 | 应急预案中通过大量的应急场景说明，对具体的技术故障现象进行了详细描述，并列举了每一类故障场景的验证方法，作为故障诊断的参考。但缺少针对综合故障的系统化的故障诊断步骤。 | 不完全 | 高 |
| 27 | 预案是否详述了每个IT服务如何进行恢复？如果有，请提供系统的恢复操作指南。 | 定义了具体的技术故障场景的救治步骤，但针对IT服务如何恢复的操作指南还有所缺失。 | 不完全 | 中 |
| 28 | 预案是否定义了服务切换回到正常环境的条件和详细的做法？（回退还原）请说明服务切换的条件，以及服务切换的操作说明文档。 | 定义了服务切换到正常环境的详细操作方法。而且服务的回切是受到变更流程的控制，并同意在变更窗口做。 | 可接受 | 高 |
| 29 | 应急预案恢复策略部分是否包括冗余方法（架构上的冗余）？请提供冗余方案以及相关说明文档。 | 目前只有一套应急库可用于应急切换，但应急库本身是单点的，而且与生产数据存在一定的差异，切换应急库会暂时损失一部分关键功能的可用性。。 | 不完全 | 高 |
应急演练 | ||||
| 30 | 应急预案是定期测试的，至少一年一次，按照约定的日程进行。 | 每季度都有一次应急演练，每次的应急场景可能不一样。应急演练的场景包括了业务角度和技术角度，平时演练的最多技术场景：双机切换和应急库的演练。 （实际操作，不带载，并选择在维护日进行，即行里规定可以不对外提供业务的时段。） | 好 | 高 |
| 31 | 在重大的变更发生后，应急预案是否被要求重新测试。 | 每季度都有一次应急演练，每次的应急场景可能不一样。应急演练的场景包括了业务角度和技术角度，平时演练的最多技术场景：双机切换和应急库的演练。 （实际操作，不带载，并选择在维护日进行，即行里规定可以不对外提供业务的时段。） | 好 | 高 |
| 32 | 应急演练是否符合实际情况并能全面进行，以保证在实际灾难发生时应急预案能够执行，并达到恢复时间和恢复目标的要求。 | 应急演练偏重于系统本身的技术故障演练，基本上符合实际情况。但综合的应急演练，比如针对重大灾难和环境变化的应急演练相对欠缺。 | 可接受 | 中 |
| 33 | 应急演练中是否包括了第三方（供应商）参与、外部流程或职能部门一起测试。 | 演练过程中，第三方厂商或维护商会参与。但演练范围基本上局限于系统内部，一般不会与其他部门一起测试。 | 可接受 | 高 |
| 34 | 对演练过程中暴露的问题，立即采取行动解决，并将演练结果文档化。 | 在演练结束后采取相关的行动对发现的问题进行分析和解决。演练过程有明确的文档，包括演练计划和演练报告等。 | 好 | 高 |
应急管理持续改进 | ||||
| 35 | 定期评审应急管理策略。 | 风险管理部负责定期回顾和改进应急管理策略。 | 好 | 低 |
| 36 | 制定了应急管理流程，并定期评审，该流程定义包括和其它流程的接口及相关关系，应急管理流程详细的过程及相关的工作指南。 | 由于系统调整频率较高，应急预案不能保证一直都是最新的，对应急管理策略的定期回顾存在不确定性。 | 不完全 | 高 |
| 37 | 对于如何实施和运行应急管理有一个文档化的计划。 | 风险管理部负责应急体系的建设，对应急管理的整体工作有较好的规划。 | 可接受 | 低 |
| 38 | 应急管理流程能与风险管理体系相一致，并被及时的更新和维护。 | 应急管理流程中一些关键定义与中心层面的应急指导不统一，更新和维护还有待加强。 | 不完全 | 高 |
| 39 | 应急管理流程能与公司整体的服务管理体系相一致，并被及时的更新和维护。 | 应急管理流程与服务管理流程较为一致。主要体现在： 1. 应急事件的记录在服务管理平台中有较为完整的体现。 2. 与变更管理的结合较为紧密，体现在详细的风险评估策略和过程。 | 可接受 | 高 |
| 40 | 所有相关记录被保存以证实该应急管理流程和过程能正确和有效运作。 | 所有事件相关记录被保存在服务管理流程平台中。由于未将普通事件和应急事件区分对待，应急管理过程的相关记录还有待完善。 | 不完全 | 中 |
| 41 | 执行应急管理的数据被很好的获取、分析、评审与报告，以对比预定义的KPI和CSF，并用作趋势和异常分析。 | 事件管理预先定义了一部分的事件KPI，有初步的决策分析过程，可从DCM中获取客观数据进行趋势分析，进而生成相关的报告。 | 可接受 | 中 |
| 42 | 分析数据的结果被用于明确差距和改进机会，并根据需要进行改进提高。 | 根据趋势分析报告，识别出明显的差距并进行改进提高。 | 可接受 | 低 |
技术领域 | ||||
日常操作与监控 | ||||
| 43 | 有专人、小组或职能负责执行日常的IT运营管理活动，并具备所需的技能和资源来开展工作。 | 有足够的人员和技能执行每天的日常运营活动，包括监控所有的事件。（运行部有专人负责中心内各系统的日常监控，各系统有系统经理负责安排本系统值班人员进行常规日常运维活动。 神码值班人员负责执行日常的备份，恢复，维护作业计划，健康检查等活动，并且能够按照任务规程使用合适的工具完成；宇信值班人员负责执行日常的备份，恢复，维护作业计划，健康检查等活动，并且能够按照任务规程使用合适的工具完成） | 好 | 高 |
| 44 | IT日常运营小组是否参与到新服务的交维过程中？是否有文档化的交接检查清单？ | 在DCM系统上发布流程，对于发布上线需要检查的项目及文档，都有提交的要求和电子功能支持。 | 可接受 | 高 |
| 45 | 拥有事件监控的整体设计和实施工具，并采用了单一控制点进行监控。 | 数据中心进行统一的集中监控。拥有事件监控的整体设计和实施工具，监控范围广泛并能根据需要进行调整。 | 可接受 | 高 |
| 46 | 通过合适的事件管理能够快速发现和识别IT服务和基础架构的故障或性能的降低。 | 所有基础架构和服务故障都能够产生告警，并且通过不断优化阈值设置合理，主要告警都会经由短信送达需关注人员，次要告警通过邮件发送。运维人员普遍认可当前监控系统的Event设置，符合工作需要。告警进行了关联和过滤，但是没有合并和干预机制。中心对于非告警事件要求事后都要查明原因，这一机制的确立有效保障了告警平台在日常工作发挥关键作用的能力，并且可以不断获得优化提升 | 好 | 高 |
| 47 | 告警事件被分类并设定优先级，能够在所需的时间范围内采取适当的行动。 | 通过监控平台，各系统管理人员和值班人员可以第一时间获得需要其关注的告警信息。 | 可接受 | 高 |
| 48 | 日程安排表的变更被授权、测试和沟通，遵循变更管理流程。 | 任务安排由系统经理确定，没有通过变更流程进行管控 | 不完全 | 中 |
| 49 | 日常计划活动尽量自动执行,比如使用自动备份或数据迁移脚本。 | 检查有日常维护作业计划模板，有固定脚本和启动策略进行检查类操作 | 可接受 | 低 |
| 50 | 有流程或机制来辨别是否一个计划内活动没有在正确的时间内启动或结束。 | 自动执行活动主要依靠值班人员检查执行返回，人工执行活动如记录某时段CPU利用率，会要求在日报中进行记录，但没有校验机制 | 可接受 | 低 |
| 51 | 任何需要进一步诊断或影响到服务交付的事件都会由一个故障工单进行记录。 | 目前不是自动产生工单，也不是所有需要进一步诊断的Event都会创建工单，而是运行部值班人员根据事件的重要程度决定是否字DCM系统创建工单 | 不完全 | 高 |
| 52 | 任何需要进一步诊断或影响到服务交付的事件都会由一个故障工单进行记录。 | 目前不是自动产生工单，也不是所有需要进一步诊断的Event都会创建工单，而是运行部值班人员根据事件的重要程度决定是否字DCM系统创建工单 | 不完全 | 高 |
| 53 | 制定了统一的维护标准，并被用于所有的服务和工作方案，在引入新服务的项目计划中也应充分考虑此标准 | 各岗位有固定的日常维护任务计划，但缺乏文档化的维护标准。 | 不完全 | 中 |
| 54 | 具备有效实施日常运营管理所需的资源、技能、工具和资金 | 基于对日常运营与监控的重视，数据中心为此配备了拥有足够技能的内外部人员，并为必备工具提供必要的资金支持和投入 | 好 | 中 |
应用与中间件 | ||||
| 55 | 应用与中间件专家是否了解关于系统的应急预案？ | 相关技术专家参与应用部分预案编制，预案一般原则上要求半年培训一次。主要人员对预案了解程度较高。预案的培训还有待加强。 | 可接受 | 高 |
| 56 | 应用与中间件的处置过程是否遵循应急管理流程？ | 执行过程基本遵循应急管理规范，但需要在系统II部的应急预案中有所体现并细化落地。 （监控平台或自有的监控工具发现故障，首先值班人员赶赴现场进行分析，通知系统经理，根据事件影响，决定是否往上报（处长，中心主任）。出现客户投诉和实时交易性能下降，在DCM创建事件单，事件级别为4级报总行，过30分钟就要报银监会。） | 可接受 | 高 |
| 57 | 应急预案中是否有完善的应急场景设置？ | 目前已准备了一些针对应用与中间件的应急场景，但主要来源于历史故障分析，没有将主动风险分析结果应用到应急场景库中，应急场景库有待梳理、归纳和完善。 （切换到应急库后，准备了关闭与资金类相关交易的脚本，代表如果切换到应急库，会丧失对部分功能的支撑。已经计划年底作informix改造，可以实时同步到应急库。 对于环境的应急预案，如掉电重起后，最小单元应急，按什么顺序启动最核心服务; Weblogic自动重连等演练，数据库重新启动；） | 不完全 | 高 |
| 58 | 除了应急预案中的技术处置步骤作为参考，是否还有其他的经过测试的修复和恢复步骤的文档？是否被统一管理和更新？ | 除了应急预案文档，还有故障验证手册，由主管负责更新管理。但存在因关键人物不在而导致技术手册不能及时获取的可能性。 | 不完全 | 中 |
| 59 | 应用架构的设计是否充分考虑到了冗余和可扩展性，以满足快速恢复应用或中间件故障的需求？ | 比较核心的应用，较多的考虑了冗余与可扩展性，有一部分业务，在原来的规划较少考虑冗余，但是已经有更换设备和扩容的计划。在极端情况下，业务不能全承载，存在单点风险。 （目前AP架构：一个AP上最少是2个实例，网银这种比较重要的业务会有更多实例分布在多台物理AP上。部分前端压力比较大，如支付宝，正在考虑扩容和更换设备。如果遇到极端情况，即两台同时坏，应急预案关闭部分查询交易，重定向F5端口等方式来解决。 运维配置：应用运维8个人，同时会有5个应用的人在。10点前2个，后1个。 当出现应用或中间件故障时，负载均衡会自动把请求发送到另外的server上。） | 可接受 | 高 |
| 60 | 运维环境需要安装和升级的介质，是否良好地保存、更新和集中管理，在需要的时候可以方便获取。 | 运维团队自己有配置管理，但存在不常用配置没有被及时更新的情况，没有集中管理。 | 可接受 | 中 |
| 61 | 应急处置过程中，是否用到了专业的故障诊断工具？ | 日常运维中采用了系统自带或者原厂提供的工具，但是缺少预先设置的故障排查脚本。 | 可接受 | 低 |
| 62 | 服务合同或维保合同是否能够满足服务级别的需求？ | 与应用与中间件在服务合同或维保合同方面，基本能保证服务恢复的需要，但没有进行明确的服务级别说明。 | 不完全 | 中 |
| 63 | 是否定期与供应商开会审查性能，并采取行动解决任何发现的问题。 | 不完全 | 中 | |
| 64 | 是否定义并实施了日常维护的活动和计划表，记录并测试过相应的工作手册。 | 依据健康检查模板，按项目检查。由系统经理进行核对。统计结果将作为作月报和周报的输入。 | 可接受 | 高 |
| 65 | 应用与中间件变更后，是否会进行预案的更新，并进行演练以测试预案仍旧有效并能应对可能出现的新风险 | 大版本或新的模块上线，开发部门或开发商会提供运维方面的应急措施、维护手册等。但不会进行预案的更新和演练。 | 不完全 | 中 |
| 66 | 应用与中间件维护方面，是否明确意识到已知的风险，并在此基础上采取了相应的改进计划和措施。 | 能明确识别出应用与中间件的已知风险，并结合实际情况制定风险整改计划。 （1. 值班人员故障定位水平有待提高。 2. 切应急库之前，先把交易功能关闭，只提供查询。切了之后，恢复故障数据，恢复完成之后，再更新应急库。 切应急库，将只提供查询功能，不提供更新，业务是受影响的。数据库回滚大概需要3-4小时。 3. 域网关如果出问题，会影响部分交易。 4. Tuxdo的版本，现在还是8，设备可研已通过，即将升级。） | 可接受 | 高 |
数据库 | ||||
| 67 | 数据库专家是否了解关于系统的应急预案？ | 数据库技术专家对预案了解程度较高。 | 可接受 | 高 |
| 68 | 数据库的处置过程是否遵循应急管理流程？ | 执行过程基本遵循应急管理规范，但需要在系统II部的应急预案中有所体现并细化落地。 （2年内，还未发生大的事件。只要不是明显的，频繁发生的问题，通常都能通过分析来进行提前预防和解决。 如果出现应急故障，优先迁到应急HA，如果还不行，手工切应急。 软件有bug，才可能导致。看现场是否还有，看是否还能起来，如果不能，切应急库。但是，应急库有单点风险。如果切了应急，可能与生产库有7天的差异，要保持数据的一致性，只能由应用人员手动进行调整。） | 可接受 | 高 |
| 69 | 是否有针对数据库的应急场景设置？ | 目前已准备了一些针对应用与中间件的应急场景，但主要来源于历史故障分析，没有将主动风险分析结果应用到应急场景库中，应急场景库有待梳理、归纳和完善。（预案中的故障场景，会尽量避免其出现，提前预防。） | 不完全 | 高 |
| 70 | 除了应急预案中的技术处置步骤作为参考，是否还有其他的经过测试的修复和恢复步骤的文档？是否被统一管理和更新？ | 如果符合应急场景的现象描述，则参照故障场景中的处置步骤执行，除此之外，还有详细的数据库文档手册作为参考。 | 不完全 | 中 |
| 71 | 数据库架构的设计是否充分考虑到了冗余和可扩展性，以满足快速恢复数据库故障的需求？ | 数据库架构的设计考虑到了冗余，但存在一定的单点风险。 （数据库服务器两台，HA互备。有一块业务室单点的，生产互备，应急和历史是单点的。应急和消息不会影响到生产，所以没有互备。每天一个全备，放在带库上。） 指导开发人员进行数据设计的配置。偶尔主动沟通，通常开发中心设计的方案数据库部分，会由DBA来审。 高伟达，负责数据库的运维，包括调优。 | 不完全 | 高 |
| 72 | 运维环境需要安装和升级的介质，是否良好地保存、更新和集中管理，在需要的时候可以方便获取。 | 常用的存放在一个固定的地方，用于日常使用和交接。 | 可接受 | 中 |
| 73 | 应急处置过程中，是否用到了专业的故障诊断工具？ | 较多采用informix自带的故障诊断工具。 | 可接受 | 低 |
| 74 | 服务合同或维保合同是否能够满足服务级别的需求？ | 数据库签署了IBM原厂服务，基本能保证服务恢复的需要，但没有进行明确的服务级别说明。 | 不完全 | 中 |
| 75 | 是否定期与供应商开会审查性能，并采取行动解决任何发现的问题。 | 不完全 | 中 | |
| 76 | 是否定义并实施了日常维护的活动和计划表，记录并测试过相应的工作手册。 | 不完全 | 高 | |
| 77 | 数据库变更后，是否会进行预案的更新，并进行演练以测试预案仍旧有效并能应对可能出现的新风险 | 日常的演练，主要做HA和切应急这两种演练，由应用来切，DBA作指导。但是数据库的变更并不会触发演练活动。 | 不完全 | 低 |
| 78 | 数据库维护方面，是否明确意识到已知的风险，并在此基础上采取了相应的改进计划和措施。 | 能明确识别出一定的已知风险，但数据库专家对风险的控制和改进需要更多第三方部门的配合。 （1.索引层次比较高。 2.索引是否合理，由应用来判断，然后做一定的调整。由于不了解业务，能做的工作主要在判断索引导致的异常现象。） | 可接受 | 高 |
服务器和操作系统 | ||||
| 79 | 服务器和操作系统专家是否了解关于系统的应急预案？ | 对应急预案比较熟悉，曾参与本系统预案编制。按要求应每年进行预案的培训。 | 可接受 | 高 |
| 80 | 服务器和操作系统的处置过程是否遵循应急管理流程？ | 执行过程基本遵循应急管理规范，但需要在系统II部的应急预案中有所体现并细化落地。（近两年暂时没有出现过由于主机和OS问题造成的重大事件。平时对于一般事件的处理，会第一时间通知系统经理，提起操作变更来处理。） | 可接受 | 高 |
| 81 | 是否有针对服务器和操作系统的应急场景设置？ | 已经发生过的故障场景会进入应急场景。但应急场景来源主要来源于历史故障分析，没有将主动风险分析结果应用到应急场景库中，应急场景库有待梳理、归纳和完善。 | 不完全 | 高 |
| 82 | 除了应急预案中的技术处置步骤作为参考，是否还有其他的经过测试的修复和恢复步骤的文档？是否被统一管理和更新？ | 除了预案之外，还有一些其他技术处置步骤作为参考。（主要凭借经验和对系统的熟悉程度即可解决大部分问题，对本系统运维一段时间的资深人员基本不需要四处寻找解决方案。会提前制作操作控制表来对应每次准备实施的变更操作过程。是否提前测试未经证实） | 可接受 | 中 |
| 83 | 服务器和操作系统架构的设计是否充分考虑到了冗余和可扩展性，以满足快速恢复服务器和操作系统故障的需求？ | 架构上采用了冗余的机制，硬件故障坏一般不会影响到业务。 （目前设备情况：DB2台,应用16台左右. 两两负载均衡，没有应急系统。有2个管理员负责。日常工作：主机和系统作巡检，处理故障和变更，性能优化，以及新需求上线支持。硬件故障坏一般都会按照故障第一时间处理。硬件问题转到环境部。） | 可接受 | 高 |
| 84 | 运维环境需要安装和升级的介质，是否良好地保存、更新和集中管理，在需要的时候可以方便获取。 | 工具和资源和文档都在固定服务器上进行集中管理。 | 可接受 | 中 |
| 85 | 应急处置过程中，是否用到了专业的故障诊断工具？ | 低 | ||
| 86 | 服务合同或维保合同是否能够满足服务级别的需求？ | 中 | ||
| 87 | 是否定期与供应商开会审查性能，并采取行动解决任何发现的问题。 | HP在现场有驻场人员，会进行定期的主机健康检查。 | 好 | 中 |
| 88 | 是否定义并实施了日常维护的活动和计划表，记录并测试过相应的工作手册。 | 有固定的检查计划和活动任务表，通过Excel来填写每日检查项目。提交的日报由系统经理进行核对。统计结果将作为作月报和周报的输入。 | 可接受 | 高 |
| 89 | 服务器与操作系统变更后，是否会进行预案的更新，并进行演练以测试预案仍旧有效并能应对可能出现的新风险 | 服务器和操作系统小的功能调整和优化不会更新应急预案，重大变更和新版本上线会作演练，并出具演练报告。 | 不完全 | 低 |
| 90 | 服务器和操作系统维护方面，是否明确意识到已知的风险，并在此基础上采取了相应的改进计划和措施。 | 能明确识别出一定的已知风险，但技术专家对风险的控制和改进需要进一步明确计划。 （目前主机和系统方面存在的风险：从方便运维和降低系统起停较多所带来的风险，希望更换设备的过程中进行OS升级，PA->安腾，目前重起25-30分钟,更换为安腾后很多配置维护工作可以不Restart。 曾经出现的其他真实应急事件：其他系统：机房空调坏了，温度高down机09年。 技术专家会参与主机和系统的风险评估过程，由于系统架构变化不大，风险点变化亦不大。运维人员具备风险发现意识,在日常工作中随时发现发现风险点会汇报给系统经理。已识别的风险中,部分风险会尽快采取控制措施消除，比如系统设置形成的风险。另一部分风险因客观条件和运营要求短期内很难消除，如根文件系统比较小，需重新安装耗时很长时间。） | 可接受 | 高 |
| 91 | 是否有进行服务器和操作系统层面的应急演练 | 经常会演练DB双机切换，手工模拟主机故障，看是否能够自动切换到备机。（备机切换回主机需要手工切。这个过程中存在5分钟左右的系统down机，即中断时间。） | 好 | 高 |
二、应急管理评估结果
