银行业监管机构定义了一些系列运维事件定义，用于监督银行的IT系统安全运营。
例如，一级事件：由于重要信息系统服务异常、在业务服务时段导致两个（含）以上省（自治区、直辖市）所有分支行业务无法正常开展达3个小时（含）以上，或一个省（自治区、直辖市）所有分支行业务无法正常开展达6个小时（含）以上的事件定为特别重大突发事件
所以，Ivan认为培训是必要的，但系统的稳健运行不能过分依赖执行层面的因素。
再来说“大锅的构造”
MPP数据库这口大锅能够解决隔离问题吗？Ivan觉得可能还是要商榷的。很多MPP数据库都会遵从的一个基本原则，就是将数据打散平均分配在所有数据节点上。例如一张表有10亿条记录，MPP集群有10个节点，则每个节点会平均存储1亿条记录。对这张表的查询会推送到每个节点上，而后汇总结果返回给数据库的调用方。这样，如果存在一个烂SQL，实际上会拖慢所有节点的速度，只不过当MPP集群足够大的时候，可以更快的执行完这个烂SQL。
处理不同任务间的资源竞争问题，就要谈到“工作负载管理”功能。简单来说，工作负载管理就是对不同的工作任务所需要的资源进行细化分配，来大致锁定任务间对资源的占用，不会抢占资源，导致某些任务受到影响，甚至被饿死的情况。这里的资源包括CPU、内存和磁盘I/O，其中磁盘I/O因为其由于其物理寻道方式，往往很难进行划分管理的。由于上述MPP架构的特点，数据集市合并到一个物理集群后，数据会被平均分配到每个节点，磁盘I/O的竞争可能会加剧，给“工作负载管理”制造更大的难题。所以说，MPP大锅的隔离性可能还不够。对于“小胡加冰”问题，如果无法做好工作负载管理，就只能通过增加火力的方式，是一种粗放的、资源堆积的方式，不值得提倡。即使有再大的锅，假如某天小胡发烧，加了整桶的冰块，所有食客还是没得吃，潜在的操作风险还是太大。
有更好的大锅吗？
看到这里，大家可能会有自己的答案，Ivan认为更好的方案应该是云数据库或者是可以云化的分布式数据库。分布式数据库与MPP一个很大的区别在于数据的存储规则上。前者往往不是平均分配，而是将有限的数据副本（通常是3副本）存储在集群中的几个节点上，而这些存储节点可以通过一定的管理策略来约束范围的。这样，至少在系统层面将I/O的竞争区隔开。也就是说，不管小胡加了多少冰，如果只影响到他自己服务的食客，那风险就被能控制在有限范围内。当然，除了强大的工作负载管理能力，系统的高可用性也很重要，任何系统的集中都会伴随着风险的集中，抛开系统内部设计不说，这种逻辑层面上的单点依赖往往是管理者有所顾虑的，是需要慎重对待的。
本文所论述的MPP数据库本身通常有成熟的高可用方案，并没有作为本文的讨论重点，故略过。
后记数据时代，信息化成熟的企业通常建设了很多BI报表系统，每天各级管理人员根据报表的数据调整企业整体的经营决策和各项具体措施、行动。系统除了保证数据准确，最受关注的就是查询的相应效率也就是延迟时间（Latency）。BI系统为了提供用户需要的报表要做大量的ETL工作，通过预处理加工数据并存储下来，采用空间换时间的方式，提升用户与系统的交互速度。批量处理和联机查询如果在同一个数据库的同一时间段进行，会产生大量资源的竞争，由于批量加工是长任务，从目前的技术来说，是很难进行协调的。所以也会采用批量和联机进行物理分离的方式，来规避资源冲突。即使如此处理后，也会发生联机报表查询响应缓慢的问题。
本文提炼出一个简化的场景，关注对联机查询部分存在的问题，略去了批量部分。
说回火锅，伴随着湿热和汗水的夏天就要过去了，吃火锅的季节还远吗？Ivan去过的店，真有不让客户自己放食材的，但具备“工作负载管理”能力的大锅还没碰到，没准有一天真会出现呢。