production-readiness

Production Readiness 是一个高阶元技能（Meta-Skill），旨在通过系统化的编排流程，确保服务在上线前满足生产环境的全部运维要求。该技能不直接执行具体检查，而是作为中央协调器，将日志监控、错误处理、性能优化、安全审查、部署配置、测试验证和文档生成等七大领域的专业子技能串联起来，最终输出统一的"go/no-go"上线决策报告。

核心用法围绕六个关键触发场景展开：首次生产部署、重大版本发布、季度运维审计、事故后加固、依赖项升级和团队交接。执行时，技能会按照既定编排流程，依次或并行调用 specialized skills：首先检查日志可观测性（结构化日志、链路追踪、告警规则），接着验证错误处理机制（熔断、重试、死信队列），然后评估性能基线（P95/P99 延迟、资源消耗），再进行安全审查（AuthN/AuthZ、OWASP Top 10），随后确认部署策略（容器加固、回滚方案、金丝雀配置），最后核查测试覆盖（契约测试、混沌工程）和运维文档（Runbook、架构决策记录）。整个过程遵循 L1（MVP）到 L4（优化）的成熟度模型，团队可根据当前阶段选择对应的检查深度。

显著优点在于其体系化的风险控制能力。通过标准化检查清单，它消除了"经验主义"导致的遗漏风险，确保健康检查、优雅关闭、Secrets 管理等关键项不被忽略。作为 Meta-Skill，它实现了专业分工与全局视野的平衡：各子领域由专家技能处理，而该技能负责结果整合与风险评估。此外，成熟度分级（L1-L4）为团队提供了清晰的演进路径，避免一次性投入过大，也防止了"假就绪"现象。

潜在缺点不容忽视。首先，该技能为纯文档型资产，所有检查需人工执行或依赖其他技能的自动化能力，本身不提供脚本执行功能。其次，其有效性高度依赖子技能的可用性和版本兼容性，若某专项技能未安装或过时，可能导致评估盲点。作为 T3 来源（个人开发者维护）的社区项目，内容的持续更新和专业性验证存在不确定性，企业用户可能需要自行 fork 维护。此外，通用化模板可能无法完全适配特定行业（如金融、医疗）的合规要求，需要大量定制化调整。

适合的目标群体包括：负责服务可靠性的 DevOps 工程师和 SRE（Site Reliability Engineer）、准备发布新产品的技术团队负责人、需要进行架构审查的资深架构师，以及建立运维规范的中大型技术团队。对于处于快速迭代期的初创公司，该技能可帮助建立基础运维纪律；对于成熟企业，则适合作为季度审计和事故后复盘的标准框架。

使用风险主要涉及执行层面：由于检查项繁多（涵盖七大领域数十个检查点），人工执行时容易出现"走过场"或选择性忽略；过度依赖文档检查可能导致"纸上就绪"但实际环境配置漂移；子技能路由依赖路径配置，若环境路径错误可能导致调用失败；最后，虽然技能本身无代码执行风险，但文档中包含 npx 等安装命令示例，执行前需严格审查来源，避免供应链攻击。建议结合 Infrastructure as Code 和自动化测试平台，将检查清单转化为可执行的策略即代码（Policy as Code），以降低人为失误。