1. 一个具体问题
一份流程在平常运转得很快，却只有一个人知道如何恢复数据；一次请假就让业务停摆。平时效率与遭遇冲击后的持续服务能力不是同一个指标。系统是否可靠，还要看失去部分条件后能保留什么、多久恢复以及是否能调整。
2. 一句话解释
系统韧性是系统在冲击和变化中吸收扰动、维持关键功能，并在必要时适应或重组的能力。
3. 出处与原意
Holling 在一九七三年的生态学论文中区分了韧性与某些稳定性概念，后续研究扩展到社会生态系统。工程中常关注恢复速度，生态韧性还关注是否跨越阈值进入另一种状态；使用时需要说明采用哪种含义。
4. 原理与机制
冗余、模块隔离、多样化和可恢复能力都可能增加韧性，但也有成本。两套系统如果依赖同一个电源或账号，表面冗余并没有分散共同原因风险。恢复也不一定是回到原样：环境永久改变时，调整服务方式可能比恢复旧流程更符合目标。
韧性还包含发现问题的能力。没有监测，备用方案可能等到损害扩大后才启动；没有明确权限，知道故障也未必有人敢切换。因而演练应覆盖发现、判断、授权、执行和恢复，而不仅测试备份设备能否开机。
5. 一个完整案例
假设案例：一个活动组织的报名与通知依赖单一平台。团队先确定关键功能是保留已报名名单、联系参与者和确认活动安排，再定期导出可读取的名单，安排两人掌握通知流程，并准备平台不可用时的公开公告渠道。演练发现，备用名单能打开，但联系方式缺失，于是修改导出字段。最后记录从发现故障到完成通知需要多久。韧性来自经过验证的可执行替代方案，而不是在计划里写一句“启用应急预案”。
活动组织在演练后删去一条已经失效的联系人信息，并让另一位成员独立执行通知。只有原设计者能完成的步骤，需要补充说明或简化。下次平台字段变化时再复测，避免把一次成功演练当成永久有效的保证。
6. 适用条件与反例
提高韧性不等于无上限增加备份，也不代表系统永远不会失败。要明确“对什么冲击、保护谁的什么功能、持续多长时间”。某些旧制度很顽固也可以称为有韧性，但这未必是社会上值得追求的结果，价值目标需要独立讨论。
7. 今天可以尝试的行动
列出当前系统最重要的三个功能，为每个功能规定可接受中断时间和最低服务水平。挑一个现实故障做桌面演练，检查人员、信息和权限是否真的可用。优先修复共同依赖和恢复断点，再评估增加更多备份是否值得。
8. 参考资料与关联条目
Holling（1973），《Resilience and Stability of Ecological Systems》。
Resilience Alliance，Glossary。