生产就绪度元技能：确保服务稳定性 - Openclaw Skills

什么是 生产就绪度？

生产就绪度元技能作为一个综合编排层，旨在确保服务在进入生产流量之前已全面运行。该技能不是手动检查每个配置，而是利用 Openclaw Skills 生态系统将技术问题（如结构化日志、熔断和密钥管理）路由到专业的子代理。它将这些细颗粒度的输入综合为最终的发布/不发布评估，为开发人员提供关于服务健康和可靠性的统一报告。

通过协调日志、错误处理、性能和安全方面的领域专家，该技能消除了服务移交过程中对部落知识的需求。它确保每个服务都能自我观察，从瞬时故障中自动恢复，并有效地向编排器传达其健康状况，使其成为维护高可用性环境的重要工具。

下载入口:https://github.com/openclaw/skills/tree/main/skills/wpank/production-readiness

安装与下载

1. ClawHub CLI

从源直接安装技能的最快方式。

npx clawhub@latest install production-readiness

2. 手动安装

将技能文件夹复制到以下位置之一

全局模式 ~/.openclaw/skills/ 工作区 /skills/

优先级：工作区 > 本地 > 内置

3. 提示词安装

将此提示词复制到 OpenClaw 即可自动安装。

请帮我使用 Clawhub 安装 production-readiness。如果尚未安装 Clawhub，请先安装（npm i -g clawhub）。

生产就绪度 应用场景

• 新微服务的初始生产部署，以确保基准稳定性。
• 主要架构更改或重大功能发布前的预发布审核。
• 对现有服务进行季度可靠性审查，以维持运营标准。
• 事故后的加固，以防止特定故障模式再次发生。
• 在主要依赖项、框架或基础设施升级后验证服务稳定性。

生产就绪度 工作原理

1. 该技能根据项目上下文启动日志、性能和安全的专业子技能。
2. 验证健康检查端点的实现，包括存活、就绪和启动探针。
3. 代理审核弹性模式，如熔断器、带抖动的重试策略和出站超时。
4. 执行安全扫描以确保密钥外部化，且配置更改不需要重新部署。
5. 通过检查操作手册、SLO 定义和黄金信号仪表板的存在来验证运营就绪情况。
6. 该技能将所有发现综合到结构化报告中，并分配从 L1 (MVP) 到 L4 (优化) 的成熟度级别。

生产就绪度 配置指南

要将此元技能添加到您的环境中，请使用 Openclaw Skills 中心 CLI：

npx clawhub@latest install production-readiness

生产就绪度 数据架构与分类体系

该技能将其评估数据组织到基于成熟度的分类法中，将专业技能输出映射到运营要求：

数据类别	描述
健康与生命周期	探针检查结果和优雅停机排空验证
弹性矩阵	熔断、限流和背压机制的审计
密钥审计	Vault 集成和外部化配置状态的验证
数据安全	备份策略、RPO/RTO 和迁移可逆性的文档
运营文档	操作手册、SLO 和升级矩阵的链接
成熟度评级	基于累积审计结果的最终 L1-L4 分类

name: production-readiness
model: reasoning
description: Meta-skill that orchestrates logging, monitoring, error handling, performance, security, deployment, and testing skills to ensure a service is fully production-ready before launch. Use before first deploy, major releases, quarterly reviews, or after incidents.

Production Readiness (Meta-Skill)

Coordinates all operational concerns into a single readiness review. Instead of duplicating domain expertise, this skill routes to specialized skills and agents for each area, then synthesizes results into a unified go/no-go assessment.

Installation

OpenClaw / Moltbot / Clawbot

npx clawhub@latest install production-readiness

---

Purpose

Ensure a service is production-ready by systematically checking every operational concern — logging, error handling, performance, security, deployment, testing, and documentation — before traffic hits it.

A production-ready service:

• Fails gracefully under load and partial outages
• Observes itself with structured logs, metrics, and traces
• Recovers automatically from transient failures
• Communicates health to orchestrators and operators
• Documents operations so on-call engineers can respond without tribal knowledge

---

When to Use

---

Orchestration Flow

Run each area sequentially or in parallel. Each step delegates to a specialized skill or agent — this skill does not re-implement their logic.

┌─────────────────────────────────────────────────┐
│              Production Readiness Review         │
├─────────────────────────────────────────────────┤
│                                                  │
│  1. Logging & Observability ──? logging-observability skill
│  2. Error Handling ───────────? error-handling-patterns skill
│  3. Performance ──────────────? performance-agent
│  4. Security ─────────────────? security-review meta-skill
│  5. Deployment ───────────────? deployment-agent + docker-expert skill
│  6. Testing ──────────────────? testing-workflow meta-skill
│  7. Documentation ────────────? /generate-docs command
│                                                  │
│  ──? Synthesize results into go/no-go report     │
└─────────────────────────────────────────────────┘

Step Details

1. Logging & Observability — Structured logging, log levels, correlation IDs, metrics endpoints, distributed tracing, alerting rules
2. Error Handling — Global error boundaries, retry policies, dead-letter queues, error classification, user-facing error messages
3. Performance — Load testing results, P95/P99 latency baselines, memory/CPU profiling, database query analysis, caching strategy
4. Security — Auth/authz verification, input validation, dependency audit, secrets management, OWASP top-10 review
5. Deployment — Container hardening, rollback strategy, blue-green/canary configuration, infrastructure-as-code review
6. Testing — Unit/integration/e2e coverage, contract tests, chaos/failure injection, smoke tests in staging
7. Documentation — API docs, runbooks, architecture diagrams, on-call playbooks, ADRs for key decisions

---

Skill Routing Table

Routing rule: Read the target skill first, follow its instructions, then return results here for synthesis.

---

Production Readiness Checklist

Health & Lifecycle

• Health check endpoint (/healthz or /health) returns dependency status
• Readiness probe distinguishes "starting" from "ready to serve"
• Liveness probe detects deadlocks and unrecoverable states
• Graceful shutdown drains in-flight requests before exit
• Startup probe allows for slow initialization without false restarts

Resilience

• Circuit breakers on all external service calls
• Retry with exponential backoff and jitter on transient failures
• Rate limiting configured per endpoint and per client
• Backpressure mechanisms prevent cascade failures under load
• Timeouts set on every outbound call (HTTP, DB, queue)
• Bulkhead isolation separates critical from non-critical paths

Configuration & Secrets

• All configuration externalized (env vars, config service, or feature flags)
• No secrets in code, images, or environment variable defaults
• Secrets loaded from a vault (e.g., AWS Secrets Manager, HashiCorp Vault)
• Configuration changes do not require redeployment
• Feature flags in place for high-risk changes

Data Safety

• Backup strategy defined and tested (RPO/RTO documented)
• Restore procedure verified in a non-production environment
• Database migrations are backward-compatible and reversible
• Data retention policies implemented and enforced

Operational Readiness

• Runbooks exist for top 5 most likely failure scenarios
• SLOs defined (availability, latency, error rate) with error budgets
• SLAs communicated to dependent teams or customers
• On-call rotation staffed and escalation path documented
• Dashboards show golden signals (latency, traffic, errors, saturation)
• Alerting rules configured with appropriate thresholds and severity

---

Maturity Levels

Progression Guidance

• L1 → L2: Add structured logging, metrics endpoint, and a CI/CD pipeline. Write runbooks for known failure modes.
• L2 → L3: Instrument distributed tracing. Add circuit breakers to external calls. Define SLOs and set up on-call.
• L3 → L4: Implement canary deployments. Adopt error budgets. Run regular game days. Build predictive alerting.

---

Incident Response

On-Call Rotation

• Minimum two engineers per rotation (primary + secondary)
• Handoff includes review of recent deploys, open issues, and known risks
• Escalation targets defined: primary → secondary → engineering lead → VP Eng

Escalation Matrix

Postmortem Template

## Incident: [Title]
**Date:** YYYY-MM-DD | **Duration:** X hours | **Severity:** SEV-N

### Summary
One-paragraph description of what happened and impact.

### Timeline
- HH:MM — First alert fired
- HH:MM — Engineer paged, investigation started
- HH:MM — Root cause identified
- HH:MM — Mitigation applied
- HH:MM — Full resolution confirmed

### Root Cause
What broke and why. Link to code/config change if applicable.

### Impact
- Users affected: N
- Revenue impact: $X (if applicable)
- SLO budget consumed: X%

### Action Items
| Action | Owner | Due Date | Status |
|--------|-------|----------|--------|
| Fix X  | @eng  | YYYY-MM-DD | Open |

### Lessons Learned
- What went well
- What went poorly
- Where we got lucky

---

NEVER Do

1. NEVER skip health checks — every service must expose health endpoints; no exceptions for "simple" services
2. NEVER store secrets in code or container images — use a secrets manager; never default env vars with real values
3. NEVER deploy without a rollback plan — if you cannot roll back in under 5 minutes, you are not ready to deploy
4. NEVER ignore error budget violations — when the error budget is exhausted, freeze feature work and fix reliability
5. NEVER treat logging as optional — a service without structured logging is a service you cannot debug at 3 AM
6. NEVER go to production without runbooks — if on-call cannot resolve the top 5 failure modes without the original author, the service is not production-ready