BigQuery预览故障转移历史视图：硬切换的STARTED不等于尚未生效
2026年9月29日，Google Cloud将BigQuery的INFORMATION_SCHEMA.FAILOVER_HISTORY视图开放为预览。它提供使用托管灾难恢复的reservation故障转移事件近实时记录，每行对应一个reservation的一次事件。对需要复盘切换过程的团队，新视图补充了可查询的运行证据，但其状态字段必须结合切换模式解释。
配图为AI生成的概念插图，表现跨区域切换与事件归档，不是真实产品界面。
记录属于新的主区域
官方文档列出的字段包括管理项目、reservation名称、开始时间、原始主位置、切换前后位置、结束时间、模式和状态。查询必须指定区域，执行位置也要与视图区域一致。它记录的是reservation事件，不包含每个数据集自身的故障转移事件。
值得特别注意的是，事件保存在切换后成为主位置的区域，也就是to_location。例如从US切到EU，记录位于region-eu；如果要看双向切换历史，应分别查询两边。只查看旧主区域后得出“这次没有切换记录”，就可能遗漏真正发生的事件。
运维系统因此需要先定义观测范围。一个跨区域恢复方案通常同时涉及资源、数据和应用流量；这张视图可以证明其中一部分动作发生过，却不是整套服务恢复的统一状态表。建议在报告中写清管理项目、reservation和目的区域，避免用一条记录代表所有数据与工作负载。
硬切换不会出现普通的完成信号
最重要的语义差异在SOFT与HARD之间。软切换进行时，end_time为空，state为STARTED；完成之后状态可变为COMPLETED。硬切换不等待次要位置确认操作，因此没有完成信号：即便切换已经生效，state仍保留STARTED，end_time仍为空。
如果把“超过几分钟还未COMPLETED”当作通用告警条件，硬切换就会持续触发假异常。更糟的是，外围自动化可能把它误判为未执行，又发起额外操作。新视图的采用应先建立模式相关的解释规则，再讨论是否自动告警。
对硬切换，本文建议把事件记录作为操作发生的证据，并结合当前资源状态和业务探测确认可用性。对软切换，也不要只等字段变化，还应验证关键查询能在预期位置执行。这是恢复验收设计建议，视图本身不提供对应用可用性的完整保证。
180天历史需要与自己的审计周期对齐
文档说明事件在视图中保留180天，之后会移除。对半年内日常排障，这一窗口提供了便利；如果团队需要年度演练对比或更长审计周期，应另行规划合规的结果保存方式，不能假定视图会永久保留历史。
保存时，建议保留事件时间、查询时间和来源区域，防止把后续查询的时间误当成切换时间。还应明确怎样识别同一事件、怎样处理后来补齐的状态，避免每次轮询都把同一行累计为一次新切换。近实时同样不代表零延迟，监控界面应允许短暂的状态传播差异。
查询权限要求包含bigquery.reservations.list，官方提供的典型角色是项目级BigQuery Resource Viewer。仅需读取历史的观测任务可以围绕所需权限设计，不应为方便调试直接赋予执行故障转移的管理权限。
先用演练验证报表，再让它参与值班
可把已有演练记录与新视图对照：一条软切换是否有合理的开始和结束时间，目的区域是否正确，硬切换是否按其特殊语义显示，以及反向切换是否出现在另一地区。没有事件的查询也要检查权限和区域，不能立即解释为系统从未切换。
长期查询应显式列出需要的字段。官方同样建议避免SELECT *，降低底层架构扩展对下游输出的影响。把视图接入值班流程之前，最好让报表同时展示模式与状态，而不是只显示一个醒目的绿色或红色标签。
此次预览让灾难恢复动作更便于追溯。真正改善响应质量的关键，是保留它准确的资源粒度与状态语义，让读者知道哪些事情已经被记录，哪些业务恢复结论还需要其他证据。
