6.3 可靠性与生存性：单点失效与星座降级

6.3 可靠性与生存性：单点失效与星座降级

前两节假设防御还有机会起作用，本节做最坏的打算：攻击得手、器件寿终、空间碎片撞击、太阳风暴扰动电离层——失效必然发生，问题只剩一个：失效之后，网络按什么剧本降级。星座系统的可靠性哲学与单星系统完全不同：单星系统追求"每颗都不坏"，星座系统追求"坏了不致命"。本节先把失效分类定量，再给出降级三原则，最后把 5.2 节的孪生演练接进来，让降级剧本从纸面变成肌肉记忆。

图：星座系统的失效分类与降级剧本

先定量：单星失效到底多疼

星座的统计冗余值得算一笔账。以数千颗规模（2.3 节：Starlink 一代约 4408 颗）计，任一时刻头顶可见数十颗，单星失效抽走的只是其中一个"接应者"，邻星波束重指向即可补位，用户侧感知接近零——2.3 节的可见星数与 3.1 节的网格多路径在这里变成冗余度的度量。失效概率的另一面是频次：数千颗星、5 到 7 年寿命（2.1 节），意味着每天都有星失效是常态，星座运维的根本设计就是把"星会死"当成输入而不是意外。这与 GEO 时代的可靠性观是两个世界：GEO 一颗星故障就是区域断网事故，所以 GEO 卫星按"十五年零故障"标准设计、双星热备；星座按"会有星持续死亡"设计，冗余长在架构里而不是单星里。

真正的风险集中在汇聚点：信关站（馈电汇聚）、测控中心（指挥汇聚）、核心网节点（业务汇聚）。3.1 节的星间链路在这里显现第二重价值——它不仅是省毫秒的加速器，更是信关站失效时的绕行通道；2.2 节的站点分集在这里显现第二重身份——平时防雨衰，灾时防打防断。一份机制兼任两职，是星座架构设计里"一鱼两吃"的典型。测控中心失效是最深的一刀：失去指挥链的卫星无法机动避碰、无法软件升级、无法更换预案，只能按预存的最后指令自治运行——这就是为什么大型星座都建多地互备测控中心，且自治等级随星座规模上升。

降级三原则与业务等级表

失效后的资源再分配，按三条原则执行。功能可降：先关闭增值能力（高速率档、边缘缓存、实时视频回传），保基本连接与短信类服务——功能清单要事先分好级，降级是执行清单而不是现场发明。覆盖可弃：资源不足时按区域价值弃卒保车，人口密集区与应急优先区域最后退场——"区域价值"评级同样是事先议定的事。容量可让：带宽按业务等级梯度回收，语音与应急通信最后断，普通视频最先让。三原则合成一张业务等级表，这张表的生命周期在平时：计费策略、SLA 承诺、应急合作都按它写。战时或灾时执行它，才不会出现"临时决定谁先断"的管理灾难。

演练：把剧本变成肌肉记忆

降级剧本最怕的是"只在文档里演练过"。5.2 节的数字孪生在这里补上第四个用法：周期性失效注入——在孪生体上模拟拔掉一颗星、切断一个信关站、掐断一条测控链路，观察降级剧本是否按预期触发、业务等级表是否按序执行、恢复流程需要多久。演练发现的剧本缺陷回到文档修订，修订后的剧本再次演练——与消防演习同构，只是"着火"发生在轨道上。行业级证据已经出现：近年多次大规模断网事件（地震断缆、飓风毁站）中，卫星互联网的应急表现直接检验了这套机制，反过来又推动星座方把应急接口写进产品需求。可靠性不是测出来的指标，是演练出来的能力。

两个失效案例的推演对照

用两个假想失效走一遍剧本，检验三原则怎么落地。案例一：太阳风暴导致某轨道面相邻三颗星的放大器同时降级，区域容量骤降四成。按"容量可让"原则，调度器先把该区域视频类业务的码率整体降档，语音与窄带数据不动；按"覆盖可弃"，极端时段把应急优先区域之外的波束功率下调，让邻区星接管高价值网格；整个过程对用户的呈现是"网速变慢"而不是"无服务"。案例二：某信关站因光缆施工被挖断，其承载的馈电流量按站点分集预案切换到邻站，邻站余量不足触发第二档降级——非实时业务排队，实时业务保障。两个案例的共同点是：降级动作全部来自预案清单，现场没有发明任何新策略。生存性的成色不体现在事故当场的机智，而体现在预案清单平时的完备与演练的频次。

反过来，这两个案例也暴露了预案设计的常见疏漏：案例一的容量让渡若没有事先的业务分级协议（哪些客户的视频可以降码率），执行时就会陷入商务纠纷；案例二的邻站接管若没有预留功率与频谱余量的常态化配置，预案就是纸面可行、物理不可行。写预案的功夫，一半在失效场景本身，一半在平时的商务与资源配置里。

与地面网可靠性体系的对照收尾

本章的方法在地面网里其实都有亲戚：降级三原则对应核心网的过载控制、失效注入演练对应混沌工程、业务等级表对应 SLA 分级。差别在尺度与代价：卫星网的"重启"要按轨道周期等待、"扩容"要按发射计划排队、"更换"要按寿命年限规划——地面工程师习以为常的"快速迭代"在天上全部失效，这正是卫星可靠性必须前置设计、地面可靠性可以事后打补丁的根本原因。理解了这个不对称，也就理解了为什么卫星行业的老工程师对"先上线再优化"的互联网方法论保持警惕：不是保守，而是他们的世界里没有"回滚到上一个版本"这种奢侈——星上软件可以升级，但升级失败的风险敞口与地面完全不同量级。

把这个对照送给从地面互联网进入卫星领域的读者：你在地面学的可靠性方法论全部有用，但每一个都要按"不可现场维修"的前提重新标定参数。这不是技术差距，是物理位置决定的工程文化差异。

验收问题：你的星座降级能力及格了吗

把本节浓缩成一份五问验收单，任何星座运营方案都可以现场过一遍。一问：单星失效的用户感知指标是什么、由哪个机制保证（邻星接管还是容量兜底）？二问：信关站单站全断，多少比例的流量能自动绕行、恢复时间多长？三问：测控中心全失联后，星上自治运行能维持多久、自治期间哪些功能降级？四问：业务等级表是否经过商务与法务确认，极端时"谁先断"有没有争议预案？五问：以上场景最近一次在孪生体上演练是什么时候、暴露了哪些问题？五问全有干净答案的运营方，生存性设计才算及格——这套问题的用途不限于采购评审，也适合投资尽调与行业研究。

本节要点回顾

• 星座可靠性与单星可靠性是两个学科：前者把"星会死"当设计输入，冗余长在架构里。
• 风险集中在汇聚点：信关站、测控中心、核心网节点；星间链路与站点分集兼任绕行与抗毁两职。
• 降级三原则：功能可降、覆盖可弃、容量可让，全部依赖事先议定的清单与等级表。
• 孪生演练第四用法：周期性失效注入，让降级剧本从文档变成能力。

安全与生存的账算完了，回头看：定义这张网"该长什么样"的标准由谁写、产业版图由谁分割？下一章换到牌桌边。