常见的 DevOps 错误及避免方法——给初创企业的建议

2>默认情况下禁止所有S3桶的公开访问：

AWS创建的S3桶在默认状态下是私有的，但可以通过桶级别、对象级别或桶策略来更改这一设置。配置不当的S3桶往往是数据泄露的最常见原因，而且这类错误几乎总是无心造成的。

最安全的做法是在账户层面启用“禁止公开访问”设置。这样，所有其他设置都会被这个规则覆盖，从而确保没有任何桶会被设置为公开可访问状态。

aws s3api put-public-access-block \
--bucket my-app-bucket \
--public-access-block-configuration \
"BlockPublicAcls=true, IgnorePublicAcls=true, BlockPublicPolicy=true, RestrictPublicBuckets=true"

对于你创建的每一个桶，都应执行这一操作。更理想的做法是在AWS账户层面启用这一设置，这样默认情况下它就会自动应用于所有未来的桶。

3. 绝不要将SSH端口开放给互联网，而应使用AWS Systems Manager Session Manager：

目前，在成千上万的AWS实例中，都将端口22开放给0.0.0.0/0，这实际上为攻击者提供了可利用的入口。暴力破解工具会持续在互联网上扫描这些开放的SSH端口。即使使用了强密码，这种设置也是不必要的，因为AWS提供了更好的解决方案。

AWS Systems Manager Session Manager允许你在不打开安全组中任何入站端口的情况下，完全访问任何EC2实例。无需扫描任何端口，也无需攻击任何端口，而且所有会话都会被自动记录到CloudTrail中：

# 在不开放端口22的情况下，在EC2实例上启动会话
aws ssm start-session --target i-0123456789abcdef0

要使用Session Manager，EC2实例需要安装SSM Agent（Amazon Linux 2和Ubuntu 20.04及更高版本默认已安装），同时还需要一个关联了AmazonSSMManagedInstanceCore策略的IAM实例配置文件。完成这些设置后，你就可以完全关闭安全组中的端口22了。

4>为所有IAM用户启用多因素认证，并通过政策强制执行这一要求：

如果一个IAM用户的用户名和密码没有启用多因素认证，那么这个账户就会面临严重的安全风险。多因素认证是防止凭证被盗用的最有效手段，而且启用它并不会产生任何费用。

你可以通过IAM政策来强制实施这一要求：当没有启用多因素认证时，该政策应拒绝所有操作，除非这些操作是用于最初设置多因素认证所需的步骤。这样一来，即使攻击者窃取了用户的凭证，如果没有第二因素认证信息，他们也无法执行任何操作。

AWS文档提供了“不启用多因素认证时完全拒绝所有操作的政策模板”
，你可以将这个政策应用到账户中的所有IAM用户或组上。这种设置只需进行一次，就能永久提升你的账户安全等级。

5>在所有区域启用CloudTrail：

如果没有CloudTrail，你就无法了解谁在AWS账户中进行了哪些操作。如果凭证被盗用，你也无法查明攻击者访问了哪些资源；如果工程师不小心删除了某个资源，你也无法追踪到这一行为。在这种情况下，你的操作完全处于盲目状态。

CloudTrail会记录下每一次AWS API调用，包括调用者、IP地址、调用时间以及响应结果。因此，即使在你不经常使用的区域，其活动也会被记录下来：

aws cloudtrail create-trail \
  --name production-audit-trail \
  --s3-bucket-name my-cloudtrail-logs \
  --is-multi-region-trail \
  --enable-log-file-validation

选项--enable-log-file-validation会为每条日志生成一个摘要文件，这样你就可以确认这些日志没有被篡改。如果你需要在安全调查或合规性审计中使用这些日志，这一功能就非常重要了。一旦启用了这项功能，账户中的每一次AssumeRole、DeleteBucket或RunInstances操作都会被永久记录下来。

6. 从第一天起就开始使用AWS Security Hub：

大多数团队都是在发生安全漏洞或合规性审计之后，才会发现存在安全配置错误。而Security Hub则恰恰相反——它会持续扫描你的AWS环境，检查其是否符合行业标准框架（如CIS AWS Foundations Benchmark和AWS Foundational Security Best Practices），并在这些问题真正引发安全事故之前就将其暴露出来。

启用Security Hub只需要执行一条命令即可：

aws securityhub enable-security-hub

几分钟内，Security Hub就会为你生成一个合规性评估报告，并列出需要处理的优先级问题。例如，某个安全组可能将端口22开放给了外部网络；某个S3存储桶可能关闭了日志记录功能；或者有人最近使用了root账户进行操作。每个问题都会指出受影响的具体资源以及相应的修复方法。

对待Security Hub报告的每一个问题，都应该像处理生产环境中的故障一样：为这些问题分配优先级，指定负责人，并确保它们得到及时解决。如果某个问题在30天内仍未得到处理，那就意味着你选择让这个已知的安全漏洞继续存在。

错误7：在生产环境中进行手动部署

场景描述

某家初创公司的部署流程被记录在一份已经过时四个月的Notion文档中。该流程包括通过SSH登录服务器、执行`git pull`命令、运行`npm install`，然后重启PM2进程。不同的工程师在执行这些步骤时可能会有一些细微的差异。有一次，在深夜进行紧急发布时，有位工程师跳过了`npm install`这一步，结果导致应用程序因为缺少某个新依赖项而出现故障。

对企业造成的影响

手动部署流程本质上是不可靠的。在压力之下，人们往往会忽略某些步骤、以错误的顺序执行操作，或者对操作流程的记忆出现偏差。因此，在生产环境中进行的任何手动部署步骤，都相当于是在等待某个“关键时刻”才会发生的潜在问题。

解决方案

如果某个部署步骤被多次手动执行，那么就应该将其自动化。以下是一个针对ECS Fargate服务的简单但完整的GitHub Actions部署工作流程示例：

# .github/workflows/deploy.yml
name: 部署到生产环境

on:
  push:
    branches:
      - main

permissions:
  id-token: write   # AWS的OIDC认证所需权限
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production

steps:
  - name: 检出代码
    uses: actions/checkout@v4

  - name: 通过OIDC配置AWS凭证
    uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: ${{ secrets.AWS_DEPLOY_ROLE_ARN }}
      aws-region: us-east-1

  - name: 登录Amazon ECR
    id: login-ecr
    uses: aws-actions/amazon-ecr-login@v2

  - name: 构建并推送Docker镜像
    id: build
    env:
      ECR_REGISTRY: ${{ steps.login-ecr.outputsregistry }}
      IMAGE_TAG: ${{ github.sha }}
    run: |
      docker build -t \(ECRRegistry/my-app:\)IMAGE_TAG .
      docker push \(ECR Registry/my-app:\)IMAGE_tag
      echo "image=\(ECRRegistry/my-app:\)IMAGE_TAG" >>> $GITHUB_OUTPUT

  - name: 部署到Amazon ECS
    uses: aws-actions/amazon-ecs-deploy-task-definition@v1
    with:
      task-definition: task-definition.json
      service: my-app-service
      cluster: production
      wait-for-service-stability: true

请注意 `wait-for-service-stability: true` 这一设置。如果没有这个选项，当 ECS 接收到新的任务定义后，即使容器实际上还没有恢复正常状态，工作流程也会报告成功结果；而设置了这一选项之后，如果新创建的容器发生故障，工作流程就会失败。你肯定希望能够立即了解到这种情况的发生，而不是在三十分钟后通过用户的反馈才得知。

错误8：没有灾难恢复计划

情景描述

某家初创企业的生产数据库运行在单个 RDS 实例上，且未配置多可用区功能。虽然启用了自动备份功能，但从未进行过测试。当支撑该数据库的 EBS 卷发生故障时，AWS 会从最新的快照中创建一个新的实例，然而这个新实例所包含的数据仅是18小时前的数据，因此客户18小时以来的数据将会永久丢失。

这家初创企业既没有灾难恢复计划，也没有经过测试的恢复流程，更没有为客户准备好的沟通方案。

业务影响

问题不在于你的基础设施是否会出故障——它肯定会出故障。所有的数据库、所有的服务器、所有的可用区都可能发生故障。关键在于你是否有一套经过测试的应对方案，以便在故障发生时能够迅速采取行动。

任何形式的数据丢失都会带来严重的后果。对于那些处理金融数据、医疗健康数据或受 GDPR 规范约束的数据的初创企业来说，即使是部分数据丢失，也可能引发监管方面的问题。

解决方法

在开始进行任何设计之前，首先明确你的 RTO 和 RPO：

• RTO（恢复时间目标）： 在没有这个系统的情况下，你的业务还能持续运行多久？例如，一个支付 API 的 RTO 可能为15分钟，而一个内部分析仪表盘的 RTO 则可能为4小时。

• RPO（恢复点目标）： 多大的数据丢失是可以接受的？如果设置为0，意味着需要实时复制数据；如果设置为1小时，那么每小时生成一次快照就足够了。这个参数直接决定了你的备份频率和备份架构。

为所有生产数据库启用 RDS 多可用区功能：

# Terraform
resource "aws_db_instance" "production" {
  identifier        = "prod-postgres"
  engine            = "postgres"
  engine_version    = "15.4"
  instance_class    = "db.t3.medium"
  allocated_storage = 100
 
  # 多可用区配置：系统会自动切换到另一个可用区的备用实例，从而避免数据丢失。切换时间约为60至120秒。
  multi_az = true
 
  # 数据存储加密是必须的
  storage_encrypted = true
 
  # 自动备份功能，数据保留7天
  backup_retention_period = 7
  backup_window           = "03:00-04:00"
 
  # 在生产环境中启用数据删除保护机制
  deletion_protection = true
 
  tags = {
    Environment = "production"
  }
}

定期测试你的备份系统。例如，可以设置每月进行一次“将生产环境的数据备份恢复到测试环境并验证数据完整性”的操作。未经测试的备份根本算不上真正的备份，它只是一种希望罢了。

# 将快照恢复到测试实例并进行验证
aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier recovery-test \
  --db-snapshot-identifier rds:prod-postgres-2025-01-15 \
  --db-instance-class db.t3.medium \
  --no-multi-az
 
# 连接数据库并验证记录数
psql -h recovery-test.xxxx.rds.amazonaws.com -U admin -d mydb \
  -c "SELECT COUNT(*) FROM users; SELECT COUNT(*) FROM orders;"

有关RDS备份和恢复的官方指南，请参阅AWS RDS备份和恢复文档。

错误9：没有文档或操作手册

场景描述

这家初创企业的经验最丰富的DevOps工程师请了两周的假。在假期第三天，他们的测试环境出现了故障。由于没有人知道这个环境是如何构建的——这位工程师是在六个月内手动配置它的，而且完全没有留下任何文档、使用过Terraform工具，也没有任何记录——团队花了四天的时间试图根据记忆和推测来重建这个环境。在工程师休假期间，团队每天都会收到相关消息。当工程师回来后，他们仅用了四个小时就重新构建好了整个环境。

对业务的影响

缺乏文档记录的基础设施会带来“单点故障”的问题——这些故障并不发生在系统本身上，而是出现在团队中。这使得新成员加入团队后需要花费数周时间才能熟悉工作流程；同时，事故响应也依赖于某些特定人员的存在；而当这些人离开公司时，这些知识也会随之消失。

解决方法

对于一个工程团队来说，文档应该包含以下三方面的内容：

1. “基础设施即代码”才是最高形式的文档。用于定义基础设施的Terraform代码本身，就是关于现有系统架构及其配置方式的文档。如果某些配置没有以代码形式记录下来，那么它们就不应该在生产环境中被使用。

2. 每项操作任务都应配有相应的操作手册。操作手册应该是编写得非常详细的步骤指南，这样新员工在入职第一周遇到问题时就可以按照这些指南来解决问题。

# 操作手册：生产环境数据库连接数过多问题的处理方案

## 症状
- 应用程序日志中出现“连接数过多”的错误
- 依赖数据库的接口端点的500错误率急剧上升
- pg_stat_activity报告显示最大连接数已被达到

# 在对基础设施进行任何修改之前，先检查PostgreSQL中的慢查询问题
psql -h \(DB_HOST -U \)DB_USER -d $DB_NAME -c "
SELECT
  query,
  calls,
  total_exec_time / calls AS avg_ms,
  rows / calls AS avg_rows
FROM pg_stat_statements
ORDER BY avg_ms DESC
LIMIT 10;
"