运维面试 高频10题 · 第六组

• 弹性伸缩：按需分配资源，流量高峰自动扩容，低谷自动缩容，不需要为峰值预购硬件
• 按量付费：用多少付多少，将 CapEx（资本支出）转为 OpEx（运营支出）
• 高可用：多可用区（AZ）部署，SLA 99.95%+，云厂商负责底层硬件故障转移
• 全球化部署：各地 Region 快速上线，传统 IDC 要几个月，云上几分钟

• HTTP：明文传输，端口 80，无身份验证，数据可被中间人窃听和篡改
• HTTPS：HTTP + TLS 加密，端口 443，有证书验证身份，传输内容加密

# 1. Client Hello
#    客户端发送：支持的TLS版本、加密套件列表、随机数(Random_C)

# 2. Server Hello + Certificate
#    服务端返回：选定的加密套件、随机数(Random_S)、服务器证书(含公钥)

# 3. 客户端验证证书
#    - 验证证书是否由受信CA签发（证书链）
#    - 验证域名是否匹配、是否过期
#    - 生成 Pre-Master Secret，用服务端公钥加密后发给服务端

# 4. 双方各自计算 Master Secret
#    Master Secret = PRF(Pre-Master, Random_C, Random_S)
#    从 Master Secret 派生出：对称加密密钥 + MAC密钥

# 后续通信：用对称密钥（如 AES-256）加密数据，速度快

• 握手从 2-RTT 缩短到 1-RTT，甚至 0-RTT 恢复连接
• 废弃了 RSA 密钥交换，强制使用 ECDHE（前向安全）
• 移除了 MD5/SHA-1 等弱加密算法

# 查看证书详情（过期时间、域名、签发机构）
openssl s_client -connect example.com:443 /dev/null \
  | openssl x509 -noout -dates -subject -issuer

# 检查证书链是否完整
curl -vI https://example.com 2>&1 | grep -E "SSL|subject|issuer|expire"

# 测试 TLS 版本支持
nmap --script ssl-enum-ciphers -p 443 example.com

• Bucket（桶）：存储空间，全局唯一名，绑定 Region
• Object（对象）：文件 + 元数据，Key 即路径（如 images/avatar/user1.jpg）
• 存储类型：标准（高频访问）→ 低频（IA，月最少存30天）→ 归档（冷备，恢复需解冻）
• 访问控制：私有 / 公共读 / 公共读写；细粒度用 RAM Policy + Bucket Policy

# ossutil 工具操作
ossutil cp /local/file.tar.gz oss://my-bucket/backup/     # 上传
ossutil cp oss://my-bucket/backup/file.tar.gz /local/     # 下载
ossutil ls oss://my-bucket/backup/                        # 列出对象
ossutil rm oss://my-bucket/backup/old.tar.gz              # 删除
ossutil sync /local/dir/ oss://my-bucket/dir/ --delete    # 同步

# 生命周期：自动转存储类型或删除（控制台/API配置）
# 例：30天后转低频，90天后转归档，365天后删除

# 用户 → SLB(公网IP) → ECS集群(私网)
#
# 七层监听 443 → HTTPS卸载 → 后端 HTTP 8080
# 四层监听 6379 → 直转 Redis（不解析内容，延迟低）
#
# HTTPS 卸载好处：
# - 证书只在SLB上配置，后端无需维护证书
# - 后端走HTTP，减少加解密开销
# - 统一在SLB上做 HTTP→HTTPS 强制跳转

• Cookie植入（七层）：SLB 在响应中插入 cookie，后续请求根据 cookie 路由到同一后端
• 源IP哈希（四层）：同一源IP固定打到同一后端（NAT环境有局限，多人共享同一公网IP）
• 最佳方案：Session 存 Redis，后端完全无状态，彻底不依赖会话保持，可随意扩缩容

1. 用户请求 cdn.example.com/logo.png
2. DNS 解析到离用户最近的 CDN 边缘节点（根据 IP 就近调度）
3. 边缘节点有缓存 → 直接返回（Cache Hit）
4. 没有缓存（Cache Miss）→ 回源到源站拉取 → 缓存到边缘 → 返回用户

• 回源：CDN 节点向源站请求内容，源站可以是 ECS/OSS/SLB
• 缓存TTL：资源在边缘节点缓存的有效时间，由 Cache-Control 或 CDN 控制台配置
• 命中率：越高越好，低了说明频繁回源，没发挥CDN价值
• 刷新 vs 预热：刷新=强制删除边缘缓存；预热=提前将资源推送到边缘节点

# 判断是否命中缓存（看响应头）
curl -I https://cdn.example.com/logo.png

# 关键响应头：
# X-Cache: HIT     ← 命中CDN缓存
# X-Cache: MISS    ← 未命中，回源了
# Age: 3600        ← 资源已缓存3600秒

# 问题1：更新了文件但CDN还是旧版本
# → 主动刷新 URL（CDN控制台 或 API）

# 问题2：动态请求被CDN缓存（返回旧数据）
# → API接口设置 Cache-Control: no-cache, no-store
# → CDN控制台对 /api/* 路径设置不缓存

# 问题3：部分地区访问慢
# → 查CDN节点健康状态，检查回源带宽是否打满

# 服务控制
systemctl start   myapp       # 启动
systemctl stop    myapp       # 停止
systemctl restart myapp       # 重启
systemctl reload  myapp       # 重载配置（不中断进程，如 nginx -s reload）
systemctl enable  myapp       # 开机自启
systemctl disable myapp       # 取消开机自启
systemctl status  myapp       # 查看运行状态

# 查看日志（journald 接管了所有 systemd 服务的日志）
journalctl -u myapp                    # 查看服务全部日志
journalctl -u myapp -f                 # 实时跟踪（等同 tail -f）
journalctl -u myapp --since "1 hour ago"
journalctl -u myapp -n 100 --no-pager  # 最后100行

# 重载 unit 文件（修改了 .service 文件后必须执行）
systemctl daemon-reload

# /etc/systemd/system/myapp.service
[Unit]
Description=My Application Service
After=network.target        # 网络就绪后再启动
Wants=redis.service         # 建议依赖 redis（非强制）

[Service]
Type=simple                 # 前台运行（不fork）
User=deploy                 # 以 deploy 用户身份运行（非root）
WorkingDirectory=/opt/myapp
ExecStart=/opt/myapp/bin/start.sh
ExecStop=/opt/myapp/bin/stop.sh
Restart=always              # 进程退出后自动重启
RestartSec=5                # 重启前等待5秒
StandardOutput=journal      # stdout → journald
StandardError=journal       # stderr → journald

# 资源限制
LimitNOFILE=65536           # 最大文件描述符数
MemoryLimit=512M            # 内存上限（可选）

[Install]
WantedBy=multi-user.target  # 多用户模式下启用

• simple：ExecStart 就是主进程，最常用
• forking：进程会 fork 并退出父进程（传统 daemon 模式，如老版 nginx）
• oneshot：执行一次就退出（适合初始化脚本）
• notify：进程启动完成后主动通知 systemd（如 PostgreSQL）

# === 第一层：网络层（最常见原因在这） ===
# 1. 控制台确认 ECS 实例状态是否「运行中」
# 2. 安全组入方向是否放行 22 端口
#    来源IP是否正确（注意办公室出口IP是否变了）
# 3. 检查是否误配了网络ACL拦截

# === 第二层：系统层（通过控制台VNC操作，不走SSH）===
# 控制台 → 实例 → 远程连接（VNC方式）

# 检查 sshd 进程是否存活
systemctl status sshd
systemctl start sshd   # 没运行则启动

# 检查 sshd 是否监听 22 端口
ss -tlnp | grep 22

# 查看 sshd 日志，找报错原因
journalctl -u sshd --since "30 min ago"
tail -100 /var/log/secure

# 检查是否被 fail2ban / hosts.deny 封禁
cat /etc/hosts.deny | grep sshd
fail2ban-client status sshd

• 安全组未放行22：最常见，控制台添加入方向规则 TCP 22，来源 your_IP/32
• sshd 服务挂了：VNC 进去 systemctl restart sshd
• 磁盘满导致 sshd 无法写日志：VNC 进去清理磁盘空间
• SSH密钥不匹配：控制台重置实例密码（需重启）
• iptables 规则封了22：iptables -F 清空规则（谨慎操作）
• CPU/内存耗尽系统无响应：强制重启实例，再查根因

• 使用多阶段构建（最有效）：编译阶段用完整镜像，运行阶段只复制产物到 alpine/distroless
• 选择最小基础镜像：alpine（~5MB）或 distroless，比 ubuntu（~70MB）小10倍以上
• 合并 RUN 指令：每条 RUN 都会创建一个层，用 && 合并，最后 rm -rf 清理缓存
• 合理利用缓存：变化少的指令（安装依赖）放前面，变化频繁的（COPY 代码）放后面

# ===== 构建阶段 =====
FROM maven:3.9-eclipse-temurin-17 AS builder
WORKDIR /app
COPY pom.xml .
RUN mvn dependency:go-offline          # 先下依赖（缓存层）
COPY src ./src
RUN mvn package -DskipTests            # 再编译（代码变化不影响依赖缓存）

# ===== 运行阶段（只有JRE，没有Maven/JDK）=====
FROM eclipse-temurin:17-jre-alpine
WORKDIR /app
# 只复制 jar 包，构建工具链一律不带入
COPY --from=builder /app/target/app.jar .

# 安全：不以 root 运行
RUN adduser -D -u 1000 appuser
USER appuser

EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

# 清理包管理器缓存（合并到同一 RUN 层）
RUN apt-get update && apt-get install -y curl \
    && rm -rf /var/lib/apt/lists/*

# .dockerignore 排除不必要文件（类似 .gitignore）
# .dockerignore 内容：
# .git
# node_modules
# *.log
# target/

# 明确指定基础镜像版本（不用 latest，保证可重复构建）
FROM nginx:1.25.3-alpine   # ✅
FROM nginx:latest           # ❌ 不确定版本

Helm 是 Kubernetes 的包管理器，类比 Linux 的 yum/apt。把一组相关的 K8s 资源（Deployment/Service/ConfigMap/Ingress 等）打包成一个 Chart，通过模板变量实现多环境复用，解决"K8s yaml 文件太多、环境差异难管理"的问题。

• Chart：Helm 的打包格式，包含 templates/ 目录和 values.yaml 默认配置
• Release：Chart 在集群中的一次部署实例，同一 Chart 可部署多个 Release（如 dev/staging/prod）
• values.yaml：模板的默认参数，部署时可用 -f 或 --set 覆盖
• Repository：存放 Chart 的仓库，类似 Docker Hub

# 添加仓库
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

# 搜索 Chart
helm search repo nginx

# 查看 Chart 的默认 values
helm show values bitnami/nginx

# 安装（使用默认值）
helm install my-nginx bitnami/nginx -n production

# 安装（覆盖参数）
helm install my-nginx bitnami/nginx \
  --set replicaCount=3 \
  --set service.type=ClusterIP \
  -f custom-values.yaml \
  -n production

# 升级
helm upgrade my-nginx bitnami/nginx -f custom-values.yaml -n production

# 回滚
helm rollback my-nginx 1 -n production   # 回到第1个版本

# 查看已安装的 Release
helm list -n production

# 卸载
helm uninstall my-nginx -n production

myapp/
├── Chart.yaml          # Chart 元信息（名称、版本、描述）
├── values.yaml         # 默认参数
└── templates/
    ├── deployment.yaml # 用 {{ .Values.xxx }} 引用参数
    ├── service.yaml
    └── ingress.yaml

1. 发现告警：监控触发 or 用户反馈，记录发现时间
2. 止损优先：先恢复服务（回滚/重启/切流量），再查根因。不要边查边等
3. 保留现场：在止损前尽量 dump 日志、快照、heap，事后分析用
4. 根因定位：服务恢复后，系统性排查根本原因
5. 复盘总结：写复盘报告，24-48小时内完成

# 故障复盘报告模板

## 基本信息
- 故障时间：2025-01-15 14:32 ~ 15:10（持续38分钟）
- 影响范围：订单服务不可用，影响约5000用户下单
- 故障等级：P1（核心业务中断）

## 故障时间线
- 14:32  监控告警：订单服务错误率超过5%
- 14:35  On-call收到告警，开始排查
- 14:42  定位到是Redis连接池耗尽，开始处理
- 14:58  重启订单服务，错误率下降
- 15:10  服务完全恢复，关闭告警

## 根本原因（Root Cause）
# 一句话描述根本原因，不要只描述表象
# ❌ 表象："Redis连接超时导致服务不可用"
# ✅ 根因："大促活动上线前未评估Redis连接池配置，
#           并发量增加3倍导致连接池耗尽（max=100, 实际需求300+）"

## 为什么没有及时发现
- 告警阈值设置过高（5%才告警，应该设1%）
- 没有连接池使用率的监控指标

## 改进措施（Actions）
| 措施 | 负责人 | 完成时间 |
|------|--------|----------|
| 调整Redis连接池 max=500 | 张三 | 2025-01-16 |
| 增加连接池使用率监控 | 李四 | 2025-01-17 |
| 大促前增加压测环节 | 王五 | 长期执行 |