Back to Details

deploying-applications

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Deploying Applications

应用部署

Production deployment patterns from Kubernetes to serverless and edge functions. Bridges the gap from application assembly to production infrastructure.
从Kubernetes到无服务器及边缘函数的生产环境部署模式，打通从应用组装到生产基础设施的链路。

Purpose

用途

This skill provides clear guidance for:
  • Selecting the right deployment strategy (Kubernetes, serverless, containers, edge)
  • Implementing Infrastructure as Code with Pulumi or OpenTofu
  • Setting up GitOps automation with ArgoCD or Flux
  • Choosing serverless databases (Neon, Turso, PlanetScale)
  • Deploying edge functions (Cloudflare Workers, Deno Deploy)
本技能提供以下场景的清晰指导：
  • 选择合适的部署策略（Kubernetes、无服务器、容器、边缘计算）
  • 使用Pulumi或OpenTofu实现基础设施即代码
  • 基于ArgoCD或Flux搭建GitOps自动化流程
  • 选择无服务器数据库（Neon、Turso、PlanetScale）
  • 部署边缘函数（Cloudflare Workers、Deno Deploy）

When to Use This Skill

适用场景

Use this skill when:
  • Deploying applications to production infrastructure
  • Setting up CI/CD pipelines and GitOps workflows
  • Choosing between Kubernetes, serverless, or edge deployment
  • Implementing Infrastructure as Code (Pulumi, OpenTofu, SST)
  • Migrating from manual deployment to automated infrastructure
  • Integrating with 
    assembling-components
    for complete deployment flow
在以下场景使用本技能：
  • 将应用部署到生产环境基础设施
  • 搭建CI/CD流水线与GitOps工作流
  • 在Kubernetes、无服务器或边缘部署方案中做选择
  • 实现基础设施即代码（Pulumi、OpenTofu、SST）
  • 从手动部署迁移到自动化基础设施
  • 与
    assembling-components
    集成以实现完整部署流程

Deployment Strategy Decision Tree

部署策略决策树

WORKLOAD TYPE?

├── COMPLEX MICROSERVICES (10+ services)
│   └─ Kubernetes + ArgoCD/Flux (GitOps)
│       ├─ Helm 4.0 for packaging
│       ├─ Service mesh: Linkerd (5-10% overhead) or Istio (25-35%)
│       └─ See references/kubernetes-patterns.md

├── VARIABLE TRAFFIC / COST-SENSITIVE
│   └─ Serverless
│       ├─ Database: Neon/Turso (scale-to-zero)
│       ├─ Compute: Vercel, AWS Lambda, Cloud Functions
│       ├─ Edge: Cloudflare Workers (<5ms cold start)
│       └─ See references/serverless-dbs.md and references/edge-functions.md

├── CONSISTENT LOAD / PREDICTABLE TRAFFIC
│   └─ Containers (ECS, Cloud Run, Fly.io)
│       ├─ ECS Fargate: AWS-native, serverless containers
│       ├─ Cloud Run: GCP, scale-to-zero containers
│       └─ Fly.io: Global edge, multi-region

├── GLOBAL LOW-LATENCY (<50ms)
│   └─ Edge Functions + Edge Database
│       ├─ Cloudflare Workers + D1 (SQLite)
│       ├─ Deno Deploy + Turso (libSQL)
│       └─ See references/edge-functions.md

└── RAPID PROTOTYPING / STARTUP MVP
    └─ Managed Platform as a Service
        ├─ Vercel (Next.js, zero-config)
        ├─ Railway (any framework)
        └─ Render (auto-deploy from Git)

IaC CHOICE?

├─ TypeScript-first → Pulumi (Apache 2.0, multi-cloud)
├─ HCL-based → OpenTofu (CNCF, Terraform-compatible)
└─ Serverless TypeScript → SST v3 (built on Pulumi)
WORKLOAD TYPE?

├── COMPLEX MICROSERVICES (10+ services)
│   └─ Kubernetes + ArgoCD/Flux (GitOps)
│       ├─ Helm 4.0 for packaging
│       ├─ Service mesh: Linkerd (5-10% overhead) or Istio (25-35%)
│       └─ See references/kubernetes-patterns.md

├── VARIABLE TRAFFIC / COST-SENSITIVE
│   └─ Serverless
│       ├─ Database: Neon/Turso (scale-to-zero)
│       ├─ Compute: Vercel, AWS Lambda, Cloud Functions
│       ├─ Edge: Cloudflare Workers (<5ms cold start)
│       └─ See references/serverless-dbs.md and references/edge-functions.md

├── CONSISTENT LOAD / PREDICTABLE TRAFFIC
│   └─ Containers (ECS, Cloud Run, Fly.io)
│       ├─ ECS Fargate: AWS-native, serverless containers
│       ├─ Cloud Run: GCP, scale-to-zero containers
│       └─ Fly.io: Global edge, multi-region

├── GLOBAL LOW-LATENCY (<50ms)
│   └─ Edge Functions + Edge Database
│       ├─ Cloudflare Workers + D1 (SQLite)
│       ├─ Deno Deploy + Turso (libSQL)
│       └─ See references/edge-functions.md

└── RAPID PROTOTYPING / STARTUP MVP
    └─ Managed Platform as a Service
        ├─ Vercel (Next.js, zero-config)
        ├─ Railway (any framework)
        └─ Render (auto-deploy from Git)

IaC CHOICE?

├─ TypeScript-first → Pulumi (Apache 2.0, multi-cloud)
├─ HCL-based → OpenTofu (CNCF, Terraform-compatible)
└─ Serverless TypeScript → SST v3 (built on Pulumi)

Core Concepts

核心概念

Infrastructure as Code (IaC)

基础设施即代码（IaC）

Define infrastructure using code instead of manual configuration.
Primary: Pulumi (TypeScript)
  • Context7 ID: 
    /pulumi/docs
    (Trust: 94.6/100, 9,525 snippets)
  • TypeScript-first (same language as React/Next.js)
  • Multi-cloud support (AWS, GCP, Azure, Cloudflare)
  • See references/pulumi-guide.md for patterns and examples
Alternative: OpenTofu (HCL)
  • CNCF project, Terraform-compatible
  • MPL-2.0 license (open governance)
  • Drop-in Terraform replacement
  • See references/opentofu-guide.md for migration
Serverless: SST v3 (TypeScript)
  • Built on Pulumi
  • Optimized for AWS Lambda, API Gateway
  • Live Lambda development
使用代码定义基础设施，替代手动配置。
首选：Pulumi（TypeScript）
  • Context7 ID: 
    /pulumi/docs
    （可信度：94.6/100，9525个代码片段）
  • 优先使用TypeScript（与React/Next.js同语言）
  • 支持多云部署（AWS、GCP、Azure、Cloudflare）
  • 查看references/pulumi-guide.md获取模式与示例
替代方案：OpenTofu（HCL）
  • CNCF项目，兼容Terraform
  • MPL-2.0许可证（开放治理）
  • 可直接替换Terraform
  • 查看references/opentofu-guide.md获取迁移指南
无服务器：SST v3（TypeScript）
  • 基于Pulumi构建
  • 针对AWS Lambda、API Gateway优化
  • 支持Lambda实时开发

GitOps Deployment

GitOps部署

Declarative infrastructure with Git as source of truth.
ArgoCD (Recommended for platform teams):
  • Rich web UI
  • Built-in RBAC and multi-tenancy
  • Self-healing deployments
  • See references/gitops-argocd.md
Flux (Recommended for DevOps automation):
  • Kubernetes-native
  • CLI-focused
  • Simpler architecture
  • See references/gitops-argocd.md
以Git为唯一可信源的声明式基础设施管理。
ArgoCD（推荐给平台团队）：
  • 功能丰富的Web界面
  • 内置RBAC与多租户支持
  • 自修复部署
  • 查看references/gitops-argocd.md
Flux（推荐给DevOps自动化场景）：
  • 原生Kubernetes支持
  • 以CLI为核心
  • 架构更简洁
  • 查看references/gitops-argocd.md

Service Mesh

服务网格

Optional layer for microservices communication, security, and observability.
When to Use Service Mesh:
  • Multi-team microservices (security boundaries)
  • Zero-trust networking (mTLS required)
  • Advanced traffic management (canary, blue-green)
When NOT to Use:
  • Simple monolith or 2-3 services (overhead not justified)
  • Serverless architectures (incompatible)
Linkerd (Performance-focused):
  • 5-10% overhead
  • Rust-based
  • Simple, opinionated
Istio (Feature-rich):
  • 25-35% overhead
  • C++ (Envoy)
  • Advanced routing, observability
See references/kubernetes-patterns.md for service mesh patterns.
微服务通信、安全与可观测性的可选层。
何时使用服务网格：
  • 多团队协作的微服务（安全边界）
  • 零信任网络（需要mTLS）
  • 高级流量管理（金丝雀发布、蓝绿部署）
何时不使用：
  • 简单单体应用或2-3个服务（开销得不偿失）
  • 无服务器架构（不兼容）
Linkerd（性能优先）：
  • 5-10%性能开销
  • 基于Rust开发
  • 简洁、 opinonated（约定大于配置）
Istio（功能丰富）：
  • 25-35%性能开销
  • 基于C++（Envoy）
  • 高级路由、可观测性
查看references/kubernetes-patterns.md获取服务网格模式。

Quick Start Workflows

快速开始工作流

Workflow 1: Deploy Next.js to Vercel (Zero-Config)

工作流1：将Next.js部署到Vercel（零配置）

bash
undefined
bash
undefined

Install Vercel CLI

安装Vercel CLI

npm i -g vercel
npm i -g vercel

Link project

关联项目

vercel link
vercel link

Deploy to production

部署到生产环境

vercel --prod

See examples/nextjs-vercel/ for complete example.
vercel --prod

查看examples/nextjs-vercel/获取完整示例。

Workflow 2: Deploy to Kubernetes with ArgoCD

工作流2：使用ArgoCD部署到Kubernetes

  1. Create Helm chart
  2. Push chart to Git repository
  3. Create ArgoCD Application
  4. ArgoCD syncs automatically
See examples/k8s-argocd/ for complete GitOps setup.
  1. 创建Helm Chart
  2. 将Chart推送到Git仓库
  3. 创建ArgoCD应用
  4. ArgoCD自动同步
查看examples/k8s-argocd/获取完整GitOps配置。

Workflow 3: Deploy Serverless with Pulumi

工作流3：使用Pulumi部署无服务应用

typescript
import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";

// Create Lambda function
const lambda = new aws.lambda.Function("api", {
    runtime: "nodejs20.x",
    handler: "index.handler",
    role: role.arn,
    code: new pulumi.asset.FileArchive("./dist"),
});

export const apiUrl = lambda.invokeArn;
See examples/pulumi-aws/ and references/pulumi-guide.md for patterns.
typescript
import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";

// 创建Lambda函数
const lambda = new aws.lambda.Function("api", {
    runtime: "nodejs20.x",
    handler: "index.handler",
    role: role.arn,
    code: new pulumi.asset.FileArchive("./dist"),
});

export const apiUrl = lambda.invokeArn;
查看examples/pulumi-aws/与references/pulumi-guide.md获取模式。

Workflow 4: Deploy Edge Function to Cloudflare Workers

工作流4：将边缘函数部署到Cloudflare Workers

typescript
import { Hono } from 'hono'

const app = new Hono()

app.get('/api/hello', (c) => {
  return c.json({ message: 'Hello from edge!' })
})

export default app
Deploy with Wrangler:
bash
wrangler deploy
See examples/cloudflare-workers-hono/ and references/edge-functions.md.
typescript
import { Hono } from 'hono'

const app = new Hono()

app.get('/api/hello', (c) => {
  return c.json({ message: 'Hello from edge!' })
})

export default app
使用Wrangler部署：
bash
wrangler deploy
查看examples/cloudflare-workers-hono/与references/edge-functions.md。

Integration with assembling-components

与assembling-components的集成

After building an application with 
assembling-components
, this skill provides deployment patterns:
Frontend (Next.js/Vite) → Deployment:
  1. Review deployment decision tree
  2. Choose platform: Vercel (Next.js), Cloudflare Pages (static), or custom (Pulumi)
  3. Set up environment variables
  4. Deploy using chosen method
Backend (FastAPI/Axum) → Deployment:
  1. Containerize application (Dockerfile)
  2. Choose platform: ECS Fargate, Cloud Run, or Kubernetes
  3. Set up IaC (Pulumi or OpenTofu)
  4. Deploy with GitOps (ArgoCD/Flux) or CI/CD
See references/pulumi-guide.md for integration examples.
使用
assembling-components
构建应用后，本技能提供以下部署模式：
前端（Next.js/Vite）→ 部署：
  1. 参考部署决策树
  2. 选择平台：Vercel（Next.js）、Cloudflare Pages（静态资源）或自定义方案（Pulumi）
  3. 设置环境变量
  4. 使用选定方法部署
后端（FastAPI/Axum）→ 部署：
  1. 容器化应用（编写Dockerfile）
  2. 选择平台：ECS Fargate、Cloud Run或Kubernetes
  3. 搭建IaC（Pulumi或OpenTofu）
  4. 使用GitOps（ArgoCD/Flux）或CI/CD部署
查看references/pulumi-guide.md获取集成示例。

Reference Files

参考文档

Kubernetes Deployment

Kubernetes部署

  • references/kubernetes-patterns.md - Helm 4.0, service mesh, autoscaling
  • references/gitops-argocd.md - ArgoCD/Flux GitOps workflows
  • references/kubernetes-patterns.md - Helm 4.0、服务网格、自动扩缩容
  • references/gitops-argocd.md - ArgoCD/Flux GitOps工作流

Serverless & Edge

无服务器与边缘计算

  • references/serverless-dbs.md - Neon, Turso, PlanetScale (scale-to-zero)
  • references/edge-functions.md - Cloudflare Workers, Deno Deploy (<5ms cold starts)
  • references/serverless-dbs.md - Neon、Turso、PlanetScale（按需缩容至零）
  • references/edge-functions.md - Cloudflare Workers、Deno Deploy（冷启动<5ms）

Infrastructure as Code

基础设施即代码

  • references/pulumi-guide.md - Pulumi TypeScript patterns, component model
  • references/opentofu-guide.md - OpenTofu/Terraform migration
  • references/pulumi-guide.md - Pulumi TypeScript模式、组件模型
  • references/opentofu-guide.md - OpenTofu/Terraform迁移

Utility Scripts

实用脚本

Scripts in 
scripts/
are executed without loading into context (token-free).
Generate Kubernetes Manifests:
bash
python scripts/generate_k8s_manifests.py --app-name my-app --replicas 3
Validate Deployment Configuration:
bash
python scripts/validate_deployment.py --config deployment.yaml
See script files for full usage documentation.
scripts/
目录下的脚本无需加载上下文即可执行（无token消耗）。
生成Kubernetes清单：
bash
python scripts/generate_k8s_manifests.py --app-name my-app --replicas 3
验证部署配置：
bash
python scripts/validate_deployment.py --config deployment.yaml
查看脚本文件获取完整使用文档。

Examples

示例

Complete, runnable examples in 
examples/
:
  • pulumi-aws/ - ECS Fargate deployment with Pulumi
  • k8s-argocd/ - Kubernetes + ArgoCD GitOps
  • sst-serverless/ - SST v3 serverless TypeScript
Each example includes:
  • README.md with setup instructions
  • Complete source code
  • Environment variable configuration
  • Deployment commands
examples/
目录下包含完整可运行的示例：
  • pulumi-aws/ - 使用Pulumi部署ECS Fargate
  • k8s-argocd/ - Kubernetes + ArgoCD GitOps
  • sst-serverless/ - SST v3无服务TypeScript应用
每个示例包含：
  • 带设置说明的README.md
  • 完整源代码
  • 环境变量配置
  • 部署命令

Library Recommendations

库推荐

Infrastructure as Code (2025)

基础设施即代码（2025）

Primary: Pulumi
  • Context7: 
    /pulumi/docs
    (Trust: 94.6, 9,525 snippets)
  • TypeScript-first, multi-cloud
  • Apache 2.0 license
Alternative: OpenTofu
  • CNCF project, MPL-2.0
  • Terraform-compatible
  • HCL syntax
Serverless: SST v3
  • Built on Pulumi
  • AWS Lambda optimized
  • TypeScript-native
首选：Pulumi
  • Context7: 
    /pulumi/docs
    （可信度：94.6，9525个代码片段）
  • 优先使用TypeScript，支持多云
  • Apache 2.0许可证
替代方案：OpenTofu
  • CNCF项目，MPL-2.0许可证
  • 兼容Terraform
  • HCL语法
无服务器：SST v3
  • 基于Pulumi构建
  • 针对AWS Lambda优化
  • 原生TypeScript支持

Serverless Databases

无服务器数据库

Neon PostgreSQL:
  • Database branching (like Git)
  • Scale-to-zero compute
  • Full PostgreSQL compatibility
Turso SQLite:
  • Edge deployment (200+ locations)
  • Sub-millisecond reads
  • libSQL (SQLite fork)
PlanetScale MySQL:
  • Non-blocking schema changes
  • Vitess-powered
  • Per-row pricing
See references/serverless-dbs.md for comparison and integration.
Neon PostgreSQL：
  • 数据库分支（类似Git）
  • 计算资源按需缩容至零
  • 完全兼容PostgreSQL
Turso SQLite：
  • 边缘部署（200+ locations）
  • 亚毫秒级读取
  • libSQL（SQLite分支）
PlanetScale MySQL：
  • 无阻塞模式变更
  • 基于Vitess构建
  • 按行计费
查看references/serverless-dbs.md获取对比与集成指南。

Edge Functions

边缘函数

Cloudflare Workers:
  • <5ms cold starts (V8 isolates)
  • 200+ edge locations
  • 128MB memory per request
Deno Deploy:
  • TypeScript-native
  • Web Standard APIs
  • Global edge (<50ms)
Hono Framework:
  • Runs on all edge runtimes
  • 14KB bundle size
  • TypeScript-first
See references/edge-functions.md for patterns.
Cloudflare Workers：
  • <5ms冷启动（V8 isolates）
  • 200+边缘节点
  • 每个请求128MB内存
Deno Deploy：
  • 原生TypeScript支持
  • 遵循Web标准API
  • 全球边缘节点（延迟<50ms）
Hono框架：
  • 支持所有边缘运行时
  • 14KB包体积
  • 优先使用TypeScript
查看references/edge-functions.md获取模式。

Best Practices

最佳实践

Security

安全

  • Use secrets management (AWS Secrets Manager, Vault)
  • Enable mTLS for service-to-service communication
  • Implement least-privilege IAM roles
  • Scan container images for vulnerabilities
  • 使用密钥管理服务（AWS Secrets Manager、Vault）
  • 启用服务间通信的mTLS
  • 实现最小权限IAM角色
  • 扫描容器镜像漏洞

Cost Optimization

成本优化

  • Use serverless databases for variable traffic (scale-to-zero)
  • Enable horizontal pod autoscaling (HPA) in Kubernetes
  • Right-size compute resources (CPU/memory)
  • Use spot instances for non-critical workloads
  • 针对可变流量使用无服务器数据库（按需缩容至零）
  • 在Kubernetes中启用水平Pod自动扩缩容（HPA）
  • 合理配置计算资源（CPU/内存）
  • 非关键工作负载使用竞价实例

Performance

性能

  • Deploy close to users (edge functions for global apps)
  • Use CDN for static assets (CloudFront, Cloudflare)
  • Implement caching strategies (Redis, CloudFront)
  • Monitor cold start times for serverless
  • 靠近用户部署（全球应用使用边缘函数）
  • 静态资源使用CDN（CloudFront、Cloudflare）
  • 实现缓存策略（Redis、CloudFront）
  • 监控无服务应用的冷启动时间

Reliability

可靠性

  • Implement health checks (Kubernetes liveness/readiness probes)
  • Set up auto-scaling (HPA, Lambda concurrency)
  • Use multi-region deployments for critical services
  • Implement circuit breakers and retries
  • 实现健康检查（Kubernetes存活/就绪探针）
  • 配置自动扩缩容（HPA、Lambda并发数）
  • 关键服务使用多区域部署
  • 实现断路器与重试机制

Troubleshooting

故障排查

Deployment Failures

部署失败

Kubernetes pod fails to start:
  1. Check pod logs: 
    kubectl logs <pod-name>
  2. Describe pod: 
    kubectl describe pod <pod-name>
  3. Verify resource limits and requests
  4. Check image pull errors (imagePullSecrets)
Serverless cold starts too slow:
  1. Reduce bundle size (tree-shaking, code splitting)
  2. Use provisioned concurrency (AWS Lambda)
  3. Consider edge functions (Cloudflare Workers)
  4. Optimize initialization code
GitOps sync errors (ArgoCD/Flux):
  1. Verify Git repository access
  2. Check manifest validity (
    kubectl apply --dry-run
    )
  3. Review sync policies (prune, selfHeal)
  4. Check ArgoCD/Flux logs
Kubernetes Pod启动失败：
  1. 查看Pod日志：
    kubectl logs <pod-name>
  2. 描述Pod：
    kubectl describe pod <pod-name>
  3. 验证资源限制与请求
  4. 检查镜像拉取错误（imagePullSecrets）
无服务应用冷启动过慢：
  1. 减小包体积（Tree Shaking、代码分割）
  2. 使用预置并发（AWS Lambda）
  3. 考虑边缘函数（Cloudflare Workers）
  4. 优化初始化代码
GitOps同步错误（ArgoCD/Flux）：
  1. 验证Git仓库访问权限
  2. 检查清单有效性（
    kubectl apply --dry-run
    ）
  3. 查看同步策略（prune、selfHeal）
  4. 检查ArgoCD/Flux日志

Performance Issues

性能问题

High service mesh overhead:
  1. Consider switching to Linkerd (5-10% vs Istio 25-35%)
  2. Disable unnecessary features
  3. Evaluate if service mesh is needed
Database connection pool exhaustion:
  1. Increase connection pool size
  2. Use serverless databases (Neon scale-to-zero)
  3. Implement connection pooling (PgBouncer)
See references/ files for detailed troubleshooting guides.
服务网格开销过高：
  1. 考虑切换到Linkerd（5-10%开销 vs Istio 25-35%）
  2. 禁用不必要的功能
  3. 评估是否需要服务网格
数据库连接池耗尽：
  1. 增加连接池大小
  2. 使用无服务器数据库（Neon按需缩容至零）
  3. 实现连接池（PgBouncer）
查看references/目录下的文档获取详细故障排查指南。

Migration Patterns

迁移模式

From Manual to IaC

从手动部署到IaC

  1. Inventory existing infrastructure
  2. Start with non-critical environments (dev, staging)
  3. Use Pulumi/OpenTofu to codify infrastructure
  4. Test in staging before production
  5. Gradual migration (one service at a time)
  1. 盘点现有基础设施
  2. 从非关键环境开始（开发、预发布）
  3. 使用Pulumi/OpenTofu将基础设施代码化
  4. 在预发布环境测试后再推广到生产环境
  5. 逐步迁移（一次一个服务）

From Terraform to OpenTofu

从Terraform到OpenTofu

bash
undefined
bash
undefined

Install OpenTofu

安装OpenTofu

brew install opentofu
brew install opentofu

Migrate state

迁移状态

terraform state pull > terraform.tfstate.backup tofu init -migrate-state tofu plan tofu apply

See references/opentofu-guide.md for complete migration.
terraform state pull > terraform.tfstate.backup tofu init -migrate-state tofu plan tofu apply

查看references/opentofu-guide.md获取完整迁移指南。

From EC2 to Containers

从EC2到容器

  1. Containerize application (create Dockerfile)
  2. Test locally (Docker Compose)
  3. Deploy to staging (ECS/Cloud Run/Kubernetes)
  4. Monitor performance and costs
  5. Cutover production traffic (blue-green deployment)
  1. 容器化应用（编写Dockerfile）
  2. 本地测试（Docker Compose）
  3. 部署到预发布环境（ECS/Cloud Run/Kubernetes）
  4. 监控性能与成本
  5. 切换生产流量（蓝绿部署）

From Containers to Serverless

从容器到无服务器

  1. Identify stateless services
  2. Refactor to serverless-friendly patterns
  3. Use serverless databases (Neon/Turso)
  4. Deploy to Lambda/Cloud Functions
  5. Monitor cold starts and costs
  1. 识别无状态服务
  2. 重构为无服务友好的模式
  3. 使用无服务器数据库（Neon/Turso）
  4. 部署到Lambda/Cloud Functions
  5. 监控冷启动与成本

Next Steps

后续步骤

After deploying applications:
  • Set up observability (metrics, logs, traces)
  • Implement CI/CD pipelines (GitHub Actions, GitLab CI)
  • Configure auto-scaling and resource limits
  • Set up disaster recovery and backups
  • Document runbooks for incident response
应用部署完成后：
  • 搭建可观测性（指标、日志、链路追踪）
  • 实现CI/CD流水线（GitHub Actions、GitLab CI）
  • 配置自动扩缩容与资源限制
  • 搭建灾备与备份方案
  • 编写事件响应手册

Additional Resources

额外资源