基础设施现代化的目标，不只是把旧服务器迁移到云端，或替换一套技术栈。更重要的是，让组织能够确认：当系统遭遇故障、流量突增、区域中断或其他意外事件时，关键业务仍然可以持续运行。
现代化与韧性必须一起规划。没有韧性目标的现代化，可能只是把原有的单点故障搬到了新的平台；没有现代化支撑的韧性建设，则往往依赖昂贵、缓慢且难以验证的人工流程。
现代化为什么会影响韧性
传统基础设施通常存在几类共同问题：资源配置依赖人工操作，系统之间耦合紧密，故障恢复步骤缺少标准化，运行状态也难以持续观测。这些问题会让组织很难回答几个关键问题：
- 哪些服务属于关键业务？
- 某个组件失效后，业务还能维持多久？
- 恢复流程是否真正经过演练？
- 配置变更能否快速回滚？
- 系统在压力和中断条件下的行为是否可预测？
现代化可以通过自动化交付、基础设施即代码、弹性资源、集中式监控和标准化恢复流程，把这些问题转化为可以验证的工程能力。重点不在于使用多少新技术，而在于系统是否更容易观察、扩展、恢复和持续改进。
从“部署成功”转向“持续运行”
基础设施项目过去常常以部署完成作为终点。对于关键业务，更合理的衡量方式是：系统在异常条件下能否保持可接受的服务水平。
可以从以下几个方面建立现代化目标：
- 减少单点故障：识别关键组件，并为它们设计冗余或替代路径。
- 缩短恢复时间：把恢复操作自动化，降低对少数专家和手工步骤的依赖。
- 控制数据损失：根据业务重要性设计备份、复制和恢复点策略。
- 提高变更可逆性：让配置和基础设施变更可审计、可测试、可回滚。
- 强化可观测性：同时关注指标、日志、追踪和业务层面的服务状态。
这些能力应该进入架构评审、发布流程和日常运维，而不是等到事故发生后才补充。
一个可落地的实践：把恢复目标写进配置
下面是一个简化的 Kubernetes Deployment 示例。它不是完整的生产高可用方案，但可以作为现代化改造的起点：通过多个副本、就绪探针、存活探针和资源约束，让平台更容易判断服务是否可接收流量，以及是否需要重启异常实例。
运行前请把镜像地址 ghcr.io/example/orders-api:1.4.0 替换为你自己的镜像，并确认集群已安装 Kubernetes。
apiVersion: apps/v1
kind: Deployment
metadata:
name: orders-api
labels:
app: orders-api
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 0
maxSurge: 1
selector:
matchLabels:
app: orders-api
template:
metadata:
labels:
app: orders-api
spec:
containers:
- name: orders-api
image: ghcr.io/example/orders-api:1.4.0
ports:
- name: http
containerPort: 8080
readinessProbe:
httpGet:
path: /ready
port: http
initialDelaySeconds: 5
periodSeconds: 5
livenessProbe:
httpGet:
path: /health
port: http
initialDelaySeconds: 15
periodSeconds: 10
resources:
requests:
cpu: "250m"
memory: "256Mi"
limits:
cpu: "1"
memory: "512Mi"
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: orders-api
spec:
minAvailable: 2
selector:
matchLabels:
app: orders-api
可以使用下面的命令部署并检查滚动更新状态：
kubectl apply -f orders-api.yaml
kubectl rollout status deployment/orders-api
kubectl get pods -l app=orders-api -o wide
kubectl describe pdb orders-api
这个示例体现了几个重要原则：发布期间保持可用实例数量，实例不健康时避免接收流量，节点维护时保留最低服务能力，并通过声明式配置让变更可以被审查和重复执行。生产环境还需要结合 Service、Ingress、跨可用区调度、数据层恢复策略、密钥管理和实际的故障演练进行完善。
韧性不是某个团队的单独职责
基础设施韧性涉及开发、平台、运维、安全和业务团队。业务团队需要定义关键流程和可接受的中断范围；工程团队需要把这些要求转化为架构和测试；平台团队需要提供标准化的交付、监控和恢复能力；安全团队则需要确保恢复路径不会绕过访问控制和审计要求。
还要注意现代化本身带来的风险。迁移期间可能出现配置漂移、依赖关系遗漏、权限扩大、监控缺失或回滚失败。因此，分阶段迁移通常比一次性重构更容易控制：先建立可观测性和基线，再拆分关键依赖，随后逐步切换流量，并在每个阶段保留明确的回滚条件。
采用前的检查清单
在启动基础设施现代化项目之前，可以检查：
- 是否已经列出关键服务、依赖关系和业务优先级？
- 每项关键服务是否定义了恢复时间目标和数据恢复目标？
- 故障恢复步骤是否可以由自动化工具执行？
- 变更是否经过测试，并且能够快速回滚？
- 监控是否能同时反映基础设施状态和用户影响？
- 团队是否定期进行备份恢复和故障演练？
- 现代化过程中的迁移风险是否有分阶段控制方案？
现代化的价值，最终要通过持续运行能力来证明。组织越早把恢复、观测和验证纳入基础设施设计，就越有可能在真正的中断发生时保持关键业务稳定。