十二月 21, 2025
41 分钟阅读

初级 SRE 面试题与答案

interview
career-advice
job-search
entry-level
初级 SRE 面试题与答案
Milad Bonakdar

Milad Bonakdar

作者

通过围绕 SLO、错误预算、告警、事件响应、Linux 排障、自动化和 Kubernetes 的实用问题，准备初级 SRE 面试。

初级 SRE 面试重点

初级 SRE 面试通常会考察你能否从用户影响推导到系统信号：SLO、错误预算、告警、事件响应、Linux 信号、自动化、容器和 Kubernetes 基础运维。你不需要像资深工程师一样回答，但需要表现出有条理的排查方式、事件期间的清晰沟通，以及在不掩盖风险的前提下自动化重复运维工作的能力。

用这些问题练习简洁回答，并把每个答案连接到项目、实验环境、实习或值班旁听中的真实例子。

SRE 基础

1. 什么是站点可靠性工程，它与 DevOps 有何不同？

答案： SRE 是 Google 在大规模可靠地运行生产系统的方法。

主要原则：

  • 将运维视为软件问题
  • 最多 50% 的时间用于运维工作（琐事）
  • 使用错误预算来平衡可靠性和速度
  • 无责事后分析
  • 逐步推广和自动回滚

SRE 与 DevOps：

方面SREDevOps
重点可靠性和可扩展性协作和自动化
指标SLI、SLO、错误预算部署频率、交付周期
方法指导性（具体实践）哲学（文化运动）
琐事明确限制在 50%没有明确定义

SRE 通过具体的实践和指标来实现 DevOps 原则。

稀有度： 非常常见 难度： 简单

2. 解释 SLI、SLO 和错误预算。

答案： 这些是衡量和管理可靠性的核心 SRE 概念：

SLI（服务级别指标）：

  • 服务级别的量化指标
  • 示例：延迟、可用性、错误率

SLO（服务级别目标）：

  • SLI 的目标值
  • 示例：“99.9% 的请求成功”

错误预算：

  • 允许的失败率（100% - SLO）
  • 用于平衡可靠性和功能开发速度
# 示例 SLI/SLO 计算
def calculate_error_budget(total_requests, failed_requests, slo_target=0.999):
    """
    计算错误预算消耗
    
    SLO: 99.9% 成功率
    错误预算: 允许 0.1% 失败
    """
    success_rate = (total_requests - failed_requests) / total_requests
    error_rate = failed_requests / total_requests
    
    # 错误预算: 我们使用了允许的 0.1% 中的多少
    allowed_errors = total_requests * (1 - slo_target)
    budget_consumed = (failed_requests / allowed_errors) * 100
    
    return {
        'success_rate': success_rate,
        'error_rate': error_rate,
        'slo_target': slo_target,
        'slo_met': success_rate >= slo_target,
        'error_budget_consumed': budget_consumed,
        'remaining_budget': max(0, 100 - budget_consumed)
    }

# 示例
result = calculate_error_budget(
    total_requests=1000000,
    failed_requests=500,  # 0.05% 错误率
    slo_target=0.999
)

print(f"成功率: {result['success_rate']:.4%}")
print(f"SLO 达成: {result['slo_met']}")
print(f"错误预算消耗: {result['error_budget_consumed']:.1f}%")

稀有度： 非常常见 难度： 中等

3. 什么是琐事（Toil），你如何减少它？

答案： 琐事 是重复性的、手动的运维工作，它：

  • 是手动的（需要人工操作）
  • 是重复的
  • 可以自动化
  • 没有持久的价值
  • 随着服务增长线性增长

琐事示例：

  • 手动重启服务
  • 在服务器之间复制文件
  • 手动扩展资源
  • 重复的工单回复

减少琐事的策略：

# 示例：自动化服务重启
#!/bin/bash
# auto-restart-service.sh

SERVICE_NAME="myapp"
MAX_RETRIES=3
RETRY_DELAY=5

check_service() {
    systemctl is-active --quiet $SERVICE_NAME
    return $?
}

restart_service() {
    echo "$(date): 正在重启 $SERVICE_NAME"
    systemctl restart $SERVICE_NAME
    
    # 等待服务稳定
    sleep $RETRY_DELAY
    
    if check_service; then
        echo "$(date): $SERVICE_NAME 重启成功"
        # 发送通知
        curl -X POST https://alerts.company.com/webhook \
          -d "{\"message\": \"$SERVICE_NAME 自动重启\"}"
        return 0
    else
        return 1
    fi
}

# 主逻辑
if ! check_service; then
    echo "$(date): $SERVICE_NAME 已停止"
    
    for i in $(seq 1 $MAX_RETRIES); do
        echo "尝试 $i，共 $MAX_RETRIES 次"
        if restart_service; then
            exit 0
        fi
        sleep $RETRY_DELAY
    done
    
    # 所有重试都失败了 - 升级
    echo "$(date): 尝试 $MAX_RETRIES 次后，重启 $SERVICE_NAME 失败"
    curl -X POST https://pagerduty.com/api/incidents \
      -d "{\"service\": \"$SERVICE_NAME\", \"severity\": \"critical\"}"
    exit 1
fi

SRE 目标： 将琐事保持在 50% 的时间以下，并自动化其余部分。

稀有度： 非常常见 难度： 简单-中等

监控与可观测性

4. 监控和可观测性有什么区别？

答案： 监控： 收集预定义的指标和警报

  • 已知-未知：你知道要关注什么
  • 仪表板、警报、指标
  • 示例：CPU、内存、请求率

可观测性： 从输出来理解系统状态

  • 未知-未知：调试你没有预料到的问题
  • 日志、指标、跟踪相结合
  • 可以回答任意问题
Loading diagram...

可观测性的三大支柱：

  1. 指标： 聚合数字（CPU、延迟）
  2. 日志： 离散事件
  3. 跟踪： 请求在系统中流动

示例：Prometheus + Grafana + Loki

# Prometheus 抓取配置
scrape_configs:
  - job_name: 'api-server'
    static_configs:
      - targets: ['localhost:8080']
    metrics_path: '/metrics'
    scrape_interval: 15s

稀有度： 常见 难度： 中等

5. 如何设置有效的警报？

答案： 好的警报是可操作的、有意义的，并且不会导致疲劳。

警报最佳实践：

1. 警报针对症状，而不是原因：

# 错误：警报针对高 CPU
- alert: HighCPU
  expr: cpu_usage > 80
  
# 正确：警报针对用户影响
- alert: HighLatency
  expr: http_request_duration_seconds{quantile="0.95"} > 1
  for: 5m
  annotations:
    summary: "API 延迟高"
    description: "95th 百分位延迟为 {{ $value }}s"

2. 包括运行手册链接：

- alert: DatabaseConnectionPoolExhausted
  expr: db_connection_pool_active / db_connection_pool_max > 0.9
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "数据库连接池几乎耗尽"
    runbook: "https://wiki.company.com/runbooks/db-connections"

3. 使用适当的严重级别：

# 需要呼叫 (唤醒某人)
- alert: ServiceDown
  expr: up{job="api"} == 0
  for: 1m
  labels:
    severity: critical
    
# 需要创建工单 (在工作时间内处理)
- alert: DiskSpaceWarning
  expr: disk_free_percent < 20
  for: 30m
  labels:
    severity: warning

4. 避免警报疲劳：

  • 使用 for: 持续时间以避免抖动
  • 对相关警报进行分组
  • 设置适当的阈值
  • 定期审查和调整

稀有度： 非常常见 难度： 中等

事件响应

6. 详细介绍你的事件响应过程。

答案： 结构化的事件响应可以最大限度地减少影响和恢复时间：

事件响应步骤：

Loading diagram...

1. 检测：

  • 警报触发或用户报告问题
  • 确认警报
  • 创建事件频道

2. 分类：

# 快速评估清单
- 对用户有什么影响？
- 有多少用户受到影响？
- 哪些服务受到影响？
- 情况是否正在恶化？

3. 缓解：

# 常见的缓解策略
- 回滚最近的部署
- 扩大资源规模
- 禁用有问题的特性
- 故障转移到备份系统
- 限制流量速率

4. 解决：

  • 修复根本原因
  • 验证指标恢复正常
  • 监控是否再次发生

5. 事后分析（无责）：

# 事件事后分析模板

## 摘要
对发生的事情的简要描述

## 影响
- 持续时间：2024-11-25 10:00 - 10:45 UTC（45 分钟）
- 受影响的用户：约 10,000（总数的 5%）
- 受影响的服务：API、Web 前端

## 根本原因
由于慢查询导致数据库连接池耗尽

## 时间线
- 10:00：触发 API 高延迟警报
- 10:05：值班工程师确认
- 10:10：确定数据库为瓶颈
- 10:15：增加连接池大小（缓解）
- 10:30：识别并终止慢查询
- 10:45：服务完全恢复

## 解决
- 立即：将连接池从 100 增加到 200
- 短期：添加查询超时（30 秒）
- 长期：优化慢查询，添加查询监控

## 行动项
- [ ] 添加慢查询警报（负责人：Alice，截止日期：2024-12-01）
- [ ] 在应用程序中实施查询超时（负责人：Bob，截止日期：2024-12-05）
- [ ] 审查和优化前 10 个最慢的查询（负责人：Charlie，截止日期：2024-12-10）

## 经验教训
- 连接池监控不足
- 查询性能下降未被注意到

稀有度： 非常常见 难度： 中等

7. 如何对遇到高延迟的服务进行故障排除？

答案： 系统的调试方法：

# 1. 验证问题
curl -w "@curl-format.txt" -o /dev/null -s https://api.example.com/health

# curl-format.txt:
#     time_namelookup:  %{time_namelookup}s\n
#        time_connect:  %{time_connect}s\n
#     time_appconnect:  %{time_appconnect}s\n
#    time_pretransfer:  %{time_pretransfer}s\n
#       time_redirect:  %{time_redirect}s\n
#  time_starttransfer:  %{time_starttransfer}s\n
#                     ----------\n
#          time_total:  %{time_total}s\n

# 2. 检查应用程序指标
# - 请求率（突然飙升？）
# - 错误率（错误导致重试？）
# - 资源使用率（CPU、内存）

# 3. 检查依赖项
# - 数据库查询时间
# - 外部 API 调用
# - 缓存命中率

# 4. 检查基础设施
top  # CPU 使用率
free -h  # 内存
iostat  # 磁盘 I/O
netstat -s  # 网络统计信息

# 5. 检查日志中的错误
tail -f /var/log/app/error.log | grep -i "timeout\|slow\|error"

# 6. 分析应用程序
# Python 示例
import cProfile
cProfile.run('my_function()')

# 7. 检查数据库
# 慢查询日志
SELECT * FROM mysql.slow_log ORDER BY query_time DESC LIMIT 10;

# 活动查询
SELECT pid, query, state, query_start 
FROM pg_stat_activity 
WHERE state = 'active';

常见原因：

  • 数据库慢查询
  • 外部 API 超时
  • 内存压力（GC 暂停）
  • 网络问题
  • 资源耗尽
  • 代码路径效率低下

稀有度： 非常常见 难度： 中等

自动化与脚本

8. 编写一个脚本来检查服务是否健康，如果需要则重启它。

答案： 健康检查和自动修复脚本：

#!/usr/bin/env python3
"""
具有自动重启功能的服务健康检查器
"""
import requests
import subprocess
import time
import sys
from datetime import datetime

class ServiceMonitor:
    def __init__(self, service_name, health_url, max_retries=3):
        self.service_name = service_name
        self.health_url = health_url
        self.max_retries = max_retries
    
    def check_health(self):
        """检查服务是否健康"""
        try:
            response = requests.get(
                self.health_url,
                timeout=5
            )
            return response.status_code == 200
        except requests.exceptions.RequestException as e:
            print(f"{datetime.now()}: 健康检查失败: {e}")
            return False
    
    def restart_service(self):
        """使用 systemctl 重启服务"""
        try:
            print(f"{datetime.now()}: 正在重启 {self.service_name}")
            subprocess.run(
                ['systemctl', 'restart', self.service_name],
                check=True,
                capture_output=True
            )
            time.sleep(10)  # 等待服务启动
            return True
        except subprocess.CalledProcessError as e:
            print(f"{datetime.now()}: 重启失败: {e.stderr}")
            return False
    
    def send_alert(self, message, severity='warning'):
        """向监控系统发送警报"""
        try:
            requests.post(
                'https://alerts.company.com/webhook',
                json={
                    'service': self.service_name,
                    'message': message,
                    'severity': severity,
                    'timestamp': datetime.now().isoformat()
                },
                timeout=5
            )
        except Exception as e:
            print(f"发送警报失败: {e}")
    
    def monitor(self):
        """主监控循环"""
        if self.check_health():
            print(f"{datetime.now()}: {self.service_name} 是健康的")
            return 0
        
        print(f"{datetime.now()}: {self.service_name} 不健康")
        self.send_alert(f"{self.service_name} 已停止", severity='warning')
        
        # 尝试重启
        for attempt in range(1, self.max_retries + 1):
            print(f"重启尝试 {attempt}/{self.max_retries}")
            
            if self.restart_service() and self.check_health():
                print(f"{datetime.now()}: 服务已恢复")
                self.send_alert(
                    f"{self.service_name} 在重启后自动恢复",
                    severity='info'
                )
                return 0
            
            time.sleep(5)
        
        # 所有重试都失败了
        print(f"{datetime.now()}: 无法恢复服务")
        self.send_alert(
            f"{self.service_name} 在 {self.max_retries} 次尝试后未能恢复",
            severity='critical'
        )
        return 1

if __name__ == '__main__':
    monitor = ServiceMonitor(
        service_name='myapp',
        health_url='http://localhost:8080/health'
    )
    sys.exit(monitor.monitor())

稀有度： 常见 难度： 中等

可靠性实践

9. 什么是运行手册，为什么它很重要？

答案： 运行手册 是用于处理运维任务和事件的文档化程序。

运行手册结构：

# 运行手册：API 高延迟

## 症状
- API 95th 百分位延迟 > 1 秒
- 用户抱怨页面加载缓慢
- 警报：“HighAPILatency”触发

## 严重程度
**警告** - 降低用户体验，但服务正常运行

## 调查步骤

### 1. 检查当前指标
```bash
# 检查延迟分布
curl -s http://prometheus:9090/api/v1/query?query='histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))'

# 检查请求率
curl -s http://prometheus:9090/api/v1/query?query='rate(http_requests_total[5m])'

2. 确定瓶颈

  • 检查数据库查询时间
  • 检查外部 API 调用
  • 检查缓存命中率
  • 审查最近的部署

3. 检查依赖项

# 数据库连接
mysql -e "SHOW PROCESSLIST;"

# Redis 延迟
redis-cli --latency

# 外部 API
curl -w "%{time_total}\n" -o /dev/null -s https://external-api.com/health

缓解步骤

快速修复（< 5 分钟）

  1. 扩展应用程序实例
kubectl scale deployment api --replicas=10
  1. 暂时增加缓存 TTL
redis-cli CONFIG SET maxmemory-policy allkeys-lru

如果问题仍然存在

  1. 回滚最近的部署
kubectl rollout undo deployment/api
  1. 启用速率限制
kubectl apply -f rate-limit-config.yaml

解决

  • 修复根本原因（慢查询，低效代码）
  • 部署修复
  • 监控 30 分钟
  • 缩放回正常容量

升级

如果无法在 30 分钟内解决：

  • 升级到：@backend-team
  • Slack 频道：#incidents
  • 值班：使用 PagerDuty 升级策略

相关


**为什么运行手册很重要：**
- 更快的事件响应
- 一致的程序
- 知识共享
- 减少事件期间的压力
- 新团队成员的培训工具

**稀有度：** 常见
**难度：** 简单

---

### 10. 解释优雅降级的概念。

**答案：**
**优雅降级** 意味着当组件发生故障时，系统继续以降低的容量运行，而不是完全失败。

**策略：**

**1. 特性标志：**
```python
# 在高负载期间禁用非关键特性
class FeatureFlags:
    def __init__(self):
        self.flags = {
            'recommendations': True,
            'analytics': True,
            'search_autocomplete': True
        }
    
    def is_enabled(self, feature):
        # 如果错误预算低，则禁用非关键特性
        if self.error_budget_low():
            non_critical = ['analytics', 'search_autocomplete']
            if feature in non_critical:
                return False
        return self.flags.get(feature, False)
    
    def error_budget_low(self):
        # 检查错误预算是否 < 20%
        return get_error_budget() < 0.2

# 用法
flags = FeatureFlags()
if flags.is_enabled('recommendations'):
    show_recommendations()
else:
    # 优雅降级 - 显示静态内容
    show_popular_items()

2. 断路器：

from enum import Enum
import time

class CircuitState(Enum):
    CLOSED = "closed"  # 正常运行
    OPEN = "open"      # 失败，拒绝请求
    HALF_OPEN = "half_open"  # 测试恢复

class CircuitBreaker:
    def __init__(self, failure_threshold=5, timeout=60):
        self.failure_threshold = failure_threshold
        self.timeout = timeout
        self.failures = 0
        self.last_failure_time = None
        self.state = CircuitState.CLOSED
    
    def call(self, func, *args, **kwargs):
        if self.state == CircuitState.OPEN:
            if time.time() - self.last_failure_time > self.timeout:
                self.state = CircuitState.HALF_OPEN
            else:
                # 返回回退而不是调用失败的服务
                return self.fallback()
        
        try:
            result = func(*args, **kwargs)
            self.on_success()
            return result
        except Exception as e:
            self.on_failure()
            return self.fallback()
    
    def on_success(self):
        self.failures = 0
        self.state = CircuitState.CLOSED
    
    def on_failure(self):
        self.failures += 1
        self.last_failure_time = time.time()
        if self.failures >= self.failure_threshold:
            self.state = CircuitState.OPEN
    
    def fallback(self):
        # 返回缓存的数据或默认响应
        return {"status": "degraded", "data": []}

# 用法
breaker = CircuitBreaker()
result = breaker.call(external_api_call, user_id=123)

3. 超时和重试：

import requests
from requests.adapters import HTTPAdapter
from requests.packages.urllib3.util.retry import Retry

def create_resilient_session():
    session = requests.Session()
    
    # 重试策略
    retry = Retry(
        total=3,
        backoff_factor=0.3,
        status_forcelist=[500, 502, 503, 504]
    )
    
    adapter = HTTPAdapter(max_retries=retry)
    session.mount('http://', adapter)
    session.mount('https://', adapter)
    
    return session

# 用法与超时
session = create_resilient_session()
try:
    response = session.get('https://api.example.com/data', timeout=5)
except requests.exceptions.Timeout:
    # 优雅降级 - 使用缓存的数据
    response = get_cached_data()

稀有度： 常见 难度： 中等

容器化基础

11. 什么是 Docker，它与虚拟机有何不同？

答案： Docker 是一个容器化平台，它将应用程序与其依赖项打包在一起。

容器 vs 虚拟机：

Loading diagram...

主要区别：

特性容器虚拟机
启动时间秒分钟
大小MBsGBs
资源使用轻量级重型
隔离进程级别硬件级别
操作系统共享主机操作系统每个 VM 一个单独的操作系统

Docker 基础：

# 拉取镜像
docker pull nginx:latest

# 运行容器
docker run -d \
  --name my-nginx \
  -p 8080:80 \
  nginx:latest

# 列出正在运行的容器
docker ps

# 查看日志
docker logs my-nginx

# 在容器中执行命令
docker exec -it my-nginx bash

# 停止容器
docker stop my-nginx

# 删除容器
docker rm my-nginx

Dockerfile 示例：

# 基础镜像
FROM python:3.12-slim

# 设置工作目录
WORKDIR /app

# 复制 requirements
COPY requirements.txt .

# 安装依赖项
RUN pip install --no-cache-dir -r requirements.txt

# 复制应用程序代码
COPY . .

# 暴露端口
EXPOSE 8000

# 健康检查
HEALTHCHECK --interval=30s --timeout=3s \
  CMD curl -f http://localhost:8000/health || exit 1

# 运行应用程序
CMD ["python", "app.py"]

构建和运行：

# 构建镜像
docker build -t myapp:1.0 .

# 使用环境变量运行
docker run -d \
  --name myapp \
  -p 8000:8000 \
  -e DATABASE_URL=postgres://db:5432/mydb \
  -e LOG_LEVEL=info \
  myapp:1.0

# 查看资源使用情况
docker stats myapp

Docker Compose（多容器）：

services:
  web:
    build: .
    ports:
      - "8000:8000"
    environment:
      - DATABASE_URL=postgresql://db:5432/mydb
    depends_on:
      - db
      - redis
    restart: unless-stopped
  
  db:
    image: postgres:14
    environment:
      - POSTGRES_DB=mydb
      - POSTGRES_PASSWORD=secret
    volumes:
      - postgres_data:/var/lib/postgresql/data
  
  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"

volumes:
  postgres_data:

使用 Docker Compose 运行：

# 启动所有服务
docker compose up -d

# 查看日志
docker compose logs -f web

# 扩展服务
docker compose up -d --scale web=3

# 停止所有服务
docker compose down

最佳实践：

  • 使用官方基础镜像
  • 最小化层数
  • 不要以 root 身份运行
  • 使用 .dockerignore
  • 正确标记镜像
  • 扫描漏洞

稀有度： 非常常见 难度： 简单-中等

版本控制与部署

12. 解释 Git 工作流程以及你如何处理部署。

答案： Git 对于版本控制和部署自动化至关重要。

常见的 Git 工作流程：

Loading diagram...

基本的 Git 命令：

# 克隆存储库
git clone https://github.com/company/repo.git
cd repo

# 创建特性分支
git checkout -b feature/add-monitoring

# 进行更改并提交
git add .
git commit -m "添加 Prometheus 监控"

# 推送到远程
git push origin feature/add-monitoring

# 从 main 更新
git checkout main
git pull origin main
git checkout feature/add-monitoring
git rebase main

# 合并特性（PR 批准后）
git checkout main
git merge feature/add-monitoring
git push origin main

分支策略：

1. Gitflow：

  • main：可用于生产的代码
  • develop：集成分支
  • feature/*：新特性
  • release/*：发布准备
  • hotfix/*：紧急修复

2. 基于主干的开发：

# 短暂的特性分支
git checkout -b feature/quick-fix
# 工作时间 < 1 天
git push origin feature/quick-fix
# 审查后立即合并到 main

部署工作流程：

1. CI/CD 管道（GitHub Actions）：

name: 部署到生产环境

on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: 运行测试
        run: |
          npm install
          npm test
      
      - name: 运行 linting
        run: npm run lint
  
  build:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: 构建 Docker 镜像
        run: |
          docker build -t myapp:${{ github.sha }} .
          docker tag myapp:${{ github.sha }} myapp:latest
      
      - name: 推送到注册表
        run: |
          echo ${{ secrets.DOCKER_PASSWORD }} | docker login -u ${{ secrets.DOCKER_USERNAME }} --password-stdin
          docker push myapp:${{ github.sha }}
          docker push myapp:latest
  
  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: 部署到生产环境
        run: |
          kubectl set image deployment/myapp \
            myapp=myapp:${{ github.sha }}
          kubectl rollout status deployment/myapp

2. 部署脚本：

#!/bin/bash
# deploy.sh - 简单部署脚本

set -e  # 发生错误时退出

# 配置
APP_NAME="myapp"
VERSION=$(git rev-parse --short HEAD)
ENVIRONMENT=${1:-staging}

echo "正在将 $APP_NAME 版本 $VERSION 部署到 $ENVIRONMENT"

# 运行测试
echo "正在运行测试..."
npm test

# 构建应用程序
echo "正在构建应用程序..."
npm run build

# 构建 Docker 镜像
echo "正在构建 Docker 镜像..."
docker build -t $APP_NAME:$VERSION .

# 推送到注册表
echo "正在推送到注册表..."
docker tag $APP_NAME:$VERSION registry.company.com/$APP_NAME:$VERSION
docker push registry.company.com/$APP_NAME:$VERSION

# 部署到 Kubernetes
echo "正在部署到 Kubernetes..."
kubectl set image deployment/$APP_NAME \
  $APP_NAME=registry.company.com/$APP_NAME:$VERSION \
  --namespace=$ENVIRONMENT

# 等待上线
kubectl rollout status deployment/$APP_NAME \
  --namespace=$ENVIRONMENT \
  --timeout=5m

echo "部署完成！"

# 运行冒烟测试
echo "正在运行冒烟测试..."
curl -f https://$ENVIRONMENT.company.com/health || {
  echo "健康检查失败！正在回滚..."
  kubectl rollout undo deployment/$APP_NAME --namespace=$ENVIRONMENT
  exit 1
}

echo "部署成功！"

3. 回滚程序：

# 查看部署历史记录
kubectl rollout history deployment/myapp

# 回滚到上一个版本
kubectl rollout undo deployment/myapp

# 回滚到特定修订版本
kubectl rollout undo deployment/myapp --to-revision=3

# 检查回滚状态
kubectl rollout status deployment/myapp

部署最佳实践：

  • 部署前始终进行测试
  • 使用特性标志进行有风险的更改
  • 在低流量时段部署
  • 准备好回滚计划
  • 部署后进行监控
  • 使用蓝绿或金丝雀部署

稀有度： 非常常见 难度： 中等

Linux 基础

13. 如何对运行缓慢的 Linux 服务器进行故障排除？

答案： 诊断性能问题的系统方法：

故障排除清单：

1. 检查系统负载：

# 查看当前负载平均值
uptime
# 输出：15:30:45 up 10 days, 3:25, 2 users, load average: 2.5, 2.0, 1.8
# 负载平均值：1 分钟、5 分钟、15 分钟

# 查看详细的系统统计信息
top
# 按“1”查看每个 CPU 的统计信息
# 按“M”按内存排序
# 按“P”按 CPU

总结

准备初级 SRE 面试时，要能用实际例子说明 SLO、告警、事件响应、Linux 排障和安全自动化。好的回答不是背命令，而是先确认用户影响，再查看可靠信号，用低风险方式缓解问题，并把经验记录下来。

Newsletter subscription

真正有效的每周职业建议

将最新见解直接发送到您的收件箱

相关文章

初级前端开发面试题：HTML、CSS 和 JavaScript
12月 21, 2025
36 分钟阅读

初级前端开发面试题：HTML、CSS 和 JavaScript

用32个问题复习语义化HTML、响应式CSS、JavaScript作用域、异步代码、DOM事件和数组方法等前端基础。

Milad BonakdarMilad Bonakdar
初级前端面试题：React 和工具
12月 21, 2025
31 分钟阅读

初级前端面试题：React 和工具

通过 21 个问题准备初级前端面试，覆盖 React、Git、构建工具、Web 性能、调试、可访问性和测试基础。

Milad BonakdarMilad Bonakdar
初级 Node.js 后端开发面试题
12月 21, 2025
41 分钟阅读

初级 Node.js 后端开发面试题

用 35 个初级 Node.js 后端面试题练习 JavaScript 基础、异步代码、事件循环、Express、REST API、数据库、安全、测试和调试。

Milad BonakdarMilad Bonakdar

您的下一次面试只差一份简历

在几分钟内创建一份专业、优化的简历。无需设计技能——只有经过验证的结果。

创建我的简历

分享这篇文章

让面试回访翻倍

根据职位描述定制简历的候选人获得的面试机会是其他人的2.5倍。使用我们的AI为每一份申请即时自动定制您的简历。

提升我的机会