降级顺序预先定义，不在运行时临时决定
别名: 优雅降级顺序 · degradation tiers · 功能分级
概念解释
优雅降级指系统在无法维持全部功能时，主动放弃一部分次要功能以保住核心功能可用，而不是让整个系统一起崩溃。这条讲的是降级顺序该在什么时候定：应该在设计阶段就把"先放弃什么、再放弃什么、最后保住什么"的完整顺序确定下来，写成明确的分级清单，而不是等到故障真的发生、系统或值班人员在事故现场临时判断该牺牲哪个功能。
机制
故障发生时的现场判断天然是在时间压力、信息不全、后果未知这三重约束下做出的，这和从容状态下的决策在质量上不是同一回事——处于压力下的人倾向于依赖当下最容易想到的信息做判断，而不是系统性比较各个功能的重要性，这就导致同一类故障在不同时间、由不同人处理时，被牺牲掉的功能可能完全不一样，用户体验因此变得不可预测。把降级顺序提前定好，等于把这个判断从事故发生的高压时刻挪到了没有时间压力、可以从容权衡的设计阶段，事故发生时系统只需要执行一份已经想清楚的清单，而不是重新做一次判断。
怎么研究
评估降级顺序是否真正做到了"预先定义"，通常的方法是故意在测试环境里触发资源不足或部分功能失效的场景（断网、服务端超时、内存耗尽），记录实际被放弃的功能顺序，再和设计文档里写明的分级顺序做比对——如果两者一致，说明预案真的在起作用；如果实际顺序因为触发者或触发时间不同而变化，说明所谓的"预先定义"只是文档层面的，运行时依然在临场决定。这类比对同时验证了一个更普遍的现象：处于时间压力下的即时判断和经过深思熟虑的判断在结果上系统性不同，这也是为什么把降级顺序留到事故现场决定风险更高的原因。
边界
预先定义的降级顺序假设可能出现的失效模式是可以被提前枚举的，对于真正意料之外、组合方式极其罕见的复合故障，预案可能没有覆盖到对应的分支，此时仍然需要现场判断兜底，但这不推翻"能枚举的部分应该预先定义"这个原则——预案覆盖不到的部分越少，留给临场决策的风险敞口就越小。
怎么落地
在系统设计阶段，列出所有可能因资源不足或部分故障而需要牺牏的功能，按重要性排出明确的分级（例如核心读取功能优先保留，写入功能其次，实时同步与非必要动效最先放弃），把这份清单写成可执行的配置或代码逻辑，而不是仅存在于文档里。验证办法：定期在预发布或测试环境执行故障演练，人为制造资源不足或服务中断，检查系统实际放弃功能的顺序是否与预先定义的分级完全一致——任何偏差都说明分级清单没有真正被系统执行，只是写在纸面上。