用途
Operability 是一份可运维性准则，面向的是系统在生产环境中的运行，而不仅仅是构建。它的出发点很直接：系统会失败，任务会卡住，状态会漂移。真正的问题在于——当出现问题时，运维人员能否在不部署代码的情况下解决问题。该准则用于指导运维工具的设计与评审。
技术栈
准则中明确的技术栈约定如下：
- Workflows: Upstash Workflows + QStash
- Cache: Upstash Redis
- Platform: Vercel
不可妥协的要求（Non-Negotiables）
准则列出了三项必须满足的底线：
- 死信处理必须存在且可运维（可见、可重放）。
- 副作用（邮件、计费、账本）必须幂等或可安全重入。
- 漂移告警必须配有修复手册。
核心关注点
准则强调要从事故期间运维人员的体验出发进行思考：他们手头有哪些工具？存在哪些运维手册？能否安全地重试失败的任务？能否检测并修复漂移？
驱动性问题
准则给出了一组用于自检的问题：
- 当一个任务永久失败时会发生什么？
- 运维人员如何知道某个东西卡住了？
- 失败的工作流能否在不重复副作用的前提下被安全重放？
- 系统之间可能出现哪些漂移，以及我们如何检测它们？
- 如果一次部署破坏了关键功能，回滚方案是什么？
- 目前存在哪些运维手册，以及哪些本该存在却还没有？
适用场景与限制
该准则适用于运维工具及生产系统运行相关的工作，尤其是涉及工作流、缓存与部署平台的场景。其技术栈约定指向 Upstash Workflows、QStash、Upstash Redis 与 Vercel。除上述内容外，资料未提供更多关于具体实现细节、收费、价格、平台支持范围或量化效果的信息。