明明測試沒問題，生產(chǎn)就翻車？老楊聊 Devops 的血淚史

作者：靜靜和小沐沐 2025-09-18 08:35:57

今天就來聊聊這個讓無數(shù)技術(shù)人員頭疼的話題：測試沒問題，為什么上生產(chǎn)就總出問題。

"測試環(huán)境跑得好好的，怎么一上生產(chǎn)就出幺蛾子？"這話老楊聽了二十年，從當(dāng)年的菜鳥工程師到現(xiàn)在的老油條，這個魔咒從來沒有被打破過。

今天就來聊聊這個讓無數(shù)技術(shù)人員頭疼的話題。測試沒問題，為什么上生產(chǎn)就總出問題。

一、環(huán)境差異這個老大難問題

1. 版本差異的深水炸彈

別看都是Linux系統(tǒng)，開發(fā)環(huán)境用的Ubuntu 22.04和生產(chǎn)環(huán)境的CentOS 7.9之間的差別，有時(shí)候比你想象的要大得多。就拿Python來說，前者自帶3.10，后者還在用3.6，這點(diǎn)小差別就能讓你的腳本死得很難看。

老楊調(diào)出一個比較經(jīng)典的錯誤.我這里有個哥們兒寫了個部署腳本，用了subprocess.run()的text參數(shù)，在開發(fā)機(jī)上跑得挺好：

#!/usr/bin/env python3
import subprocess
result = subprocess.run(['systemctl', 'status', 'nginx'], 
                       capture_output=True, text=True)
print(f"Exit code: {result.returncode}")

結(jié)果到了生產(chǎn)環(huán)境，Python 3.6根本不認(rèn)識text這個參數(shù)，直接給你來個TypeError。踩這種坑不止一次，后來學(xué)乖了，兼容性處理必須做到位：

#!/usr/bin/env python3
import subprocess
import sys

def run_command(cmd):
    if sys.version_info >= (3, 7):
        result = subprocess.run(cmd, capture_output=True, text=True)
        return result.returncode, result.stdout, result.stderr
    else:
        result = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
        return result.returncode, result.stdout.decode('utf-8'), result.stderr.decode('utf-8')

returncode, stdout, stderr = run_command(['systemctl', 'status', 'nginx'])
print(f"Exit code: {returncode}")

2. 依賴庫版本的連環(huán)坑

生產(chǎn)服務(wù)器的依賴庫版本往往比開發(fā)環(huán)境落后好幾個版本，這時(shí)候各種奇怪的兼容性問題就出來了。你在開發(fā)環(huán)境用的是requests 2.31.0，生產(chǎn)環(huán)境可能還是2.25.1，SSL證書驗(yàn)證的行為就不一樣了。

這種情況下，我一般會創(chuàng)建個虛擬環(huán)境，把依賴版本鎖死：

cat > requirements.txt << 'EOF'
requests==2.25.1
urllib3==1.26.5
certifi==2021.5.25
charset-normalizer==2.0.4
idna==3.2
EOF

# 部署腳本
#!/bin/bash
set -euo pipefail

SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
VENV_DIR="$SCRIPT_DIR/venv"

echo"=== 創(chuàng)建隔離的Python環(huán)境 ==="
if [ ! -d "$VENV_DIR" ]; then
    python3 -m venv "$VENV_DIR"
fi

source"$VENV_DIR/bin/activate"
pip install --no-deps -r requirements.txt

echo"=== 驗(yàn)證環(huán)境一致性 ==="
pip freeze | sort > deployed_versions.txt

python api_client.py

二、權(quán)限問題，這個隱形殺手

在測試環(huán)境，開發(fā)人員通常有sudo權(quán)限，想寫哪兒就寫哪兒。但生產(chǎn)環(huán)境不一樣，權(quán)限控制嚴(yán)格得很，稍不注意就撞墻了。

這里老楊舉一個權(quán)限檢查腳本，每次部署前都會跑一遍，避免踩坑：

#!/bin/bash
# permission_check.sh - 生產(chǎn)環(huán)境權(quán)限預(yù)檢

set -euo pipefail

echo"=== 系統(tǒng)權(quán)限診斷報(bào)告 ==="
echo"執(zhí)行用戶: $(whoami)"
echo"用戶組: $(groups)"
echo"當(dāng)前目錄: $(pwd)"

declare -A critical_dirs=(
    ["/var/log"]="日志目錄"
    ["/etc/systemd/system"]="系統(tǒng)服務(wù)配置"
    ["/opt/applications"]="應(yīng)用部署目錄"
    ["/tmp"]="臨時(shí)文件目錄"
)

fordirin"${!critical_dirs[@]}"; do
    echo"檢查 ${critical_dirs[$dir]} ($dir):"
    if [ -d "$dir" ]; then
        ls -ld "$dir"
        if [ -w "$dir" ]; then
            echo"  ? 可寫"
        else
            echo"  ? 不可寫"
        fi
    else
        echo"  ? 目錄不存在"
    fi
    echo
done

還有個更狠的，SELinux。這家伙在RHEL/CentOS系統(tǒng)里默默守護(hù)，很多時(shí)候你的腳本運(yùn)行失敗，根本想不到是它在作怪。檢查SELinux狀態(tài)，配置正確的文件上下文，這些都得考慮進(jìn)去。

三、網(wǎng)絡(luò)環(huán)境，看不見的攔路虎

企業(yè)內(nèi)網(wǎng)環(huán)境復(fù)雜，防火墻規(guī)則、代理設(shè)置、DNS解析，任何一個環(huán)節(jié)出問題都能讓你的腳本跑不起來。

這里老楊舉例一個網(wǎng)絡(luò)連通性檢查腳本：

#!/bin/bash
# network_connectivity_check.sh

set -euo pipefail

declare -A endpoints=(
    ["registry.cn-hangzhou.aliyuncs.com:443"]="阿里云容器鏡像服務(wù)"
    ["mirrors.aliyun.com:80"]="阿里云軟件源"
    ["api.dingtalk.com:443"]="釘釘API"
    ["127.0.0.1:3306"]="本地MySQL"
    ["redis.internal.company.com:6379"]="內(nèi)網(wǎng)Redis"
)

check_connectivity() {
    local endpoint=$1
    local description=$2
    local host port
    
    IFS=':'read -r host port <<< "$endpoint"
    
    echo"檢查 $description ($endpoint):"
    
    # DNS解析檢查
    if ! nslookup "$host" >/dev/null 2>&1; then
        echo"  ? DNS解析失敗"
        return 1
    fi
    echo"  ? DNS解析正常"
    
    # 端口連通性檢查
    iftimeout 5 bash -c "echo >/dev/tcp/$host/$port" 2>/dev/null; then
        echo"  ? 端口 $port 可達(dá)"
    else
        echo"  ? 端口 $port 不可達(dá)"
        echo"  ?? 建議檢查防火墻規(guī)則:"
        echo"     sudo iptables -L | grep $port"
    fi
    echo
}

for endpoint in"${!endpoints[@]}"; do
    check_connectivity "$endpoint""${endpoints[$endpoint]}"
done

特別是企業(yè)代理環(huán)境，這個更是個大坑。所有外網(wǎng)訪問都得走代理，腳本里不配置代理參數(shù)，連個包都下載不了。我一般會做個代理感知的處理：

setup_proxy() {
    echo"=== 代理環(huán)境配置 ==="
    
    local proxy_sources=(
        "$http_proxy"
        "$HTTP_PROXY"
        "http://proxy.company.com:8080"# 企業(yè)默認(rèn)代理
    )
    
    local detected_proxy=""
    for proxy in"${proxy_sources[@]}"; do
        if [[ -n "$proxy" ]] && curl -s --proxy "$proxy" --connect-timeout 5 \
           "http://www.baidu.com" >/dev/null 2>&1; then
            detected_proxy="$proxy"
            break
        fi
    done
    
    if [[ -n "$detected_proxy" ]]; then
        echo"? 檢測到可用代理: $detected_proxy"
        export http_proxy="$detected_proxy"
        export https_proxy="$detected_proxy"
    else
        echo"? 未檢測到可用代理，使用直連模式"
    fi
}

四、配置管理的精細(xì)化工程

配置文件的管理更是門學(xué)問。不同環(huán)境用不同的配置，這個看起來簡單，實(shí)際操作起來坑不少。配置文件的版本控制、語法驗(yàn)證、權(quán)限設(shè)置，每一步都不能馬虎。

我習(xí)慣用Git管理配置，按環(huán)境分目錄存放，部署的時(shí)候根據(jù)環(huán)境選擇對應(yīng)的配置：

#!/bin/bash
manage_configs() {
    localenv=$1# dev, test, prod
    
    echo"=== 環(huán)境配置管理 [$env] ==="
    
    # 克隆配置倉庫
    if [ ! -d "/tmp/myapp-configs" ]; then
        git clone"$GIT_REPO" /tmp/myapp-configs
    fi
    
    cd /tmp/myapp-configs
    git pull origin main
    
    local config_source="configs/$env"
    if [ ! -d "$config_source" ]; then
        echo"? 環(huán)境配置目錄不存在: $config_source"
        return 1
    fi
    
    # 備份現(xiàn)有配置
    if [ -d "$CONFIG_DIR" ] && [ "$(ls -A "$CONFIG_DIR" 2>/dev/null)" ]; then
        local backup_timestamp=$(date +"%Y%m%d_%H%M%S")
        local backup_path="$BACKUP_DIR/backup_$backup_timestamp"
        
        echo"?? 備份現(xiàn)有配置到: $backup_path"
        sudocp -r "$CONFIG_DIR""$backup_path"
    fi
    
    # 部署新配置
    sudocp -r "$config_source"/* "$CONFIG_DIR/"
    sudochown -R myapp:myapp "$CONFIG_DIR"
    
    echo"? 配置管理完成"
}

密鑰管理這塊兒更得小心，生產(chǎn)環(huán)境的密碼、API密鑰這些敏感信息，絕對不能明文存儲。我一般用HashiCorp Vault或者至少做個加密存儲：

encrypt_secrets() {
    local secrets_file=$1
    local encrypted_file="${secrets_file}.enc"
    
    echo"?? 加密密鑰文件: $secrets_file"
    
    # 使用GPG加密
    ifcommand -v gpg >/dev/null 2>&1; then
        gpg --symmetric --cipher-algo AES256 --output "$encrypted_file""$secrets_file"
        # 安全刪除原文件
        shred -vfz -n 3 "$secrets_file" 2>/dev/null || rm -f "$secrets_file"
        echo"? 文件已加密: $encrypted_file"
    fi
}

五、資源限制的現(xiàn)實(shí)約束

生產(chǎn)環(huán)境的資源控制比開發(fā)環(huán)境嚴(yán)格多了，CPU、內(nèi)存、磁盤I/O都有限制。你的腳本在開發(fā)機(jī)上跑得飛快，到了生產(chǎn)環(huán)境可能因?yàn)橘Y源不夠用而跑得慢如蝸牛，甚至直接被kill掉。

我經(jīng)常用cgroup來做資源限制，確保應(yīng)用不會因?yàn)橘Y源搶占而影響其他服務(wù)：

setup_cgroup_limits() {
    local app_name=$1
    local memory_limit=$2    # 例如: 512m, 1g
    local cpu_limit=$3       # 例如: 1.0, 0.5
    
    echo"??  配置cgroup資源限制: $app_name"
    
    # 創(chuàng)建cgroup
    local cgroup_path="/sys/fs/cgroup/myapps/$app_name"
    sudomkdir -p "$cgroup_path"
    
    # 內(nèi)存限制
    echo"$memory_limit" | sudotee"$cgroup_path/memory.limit_in_bytes" > /dev/null
    echo"? 內(nèi)存限制: $memory_limit"
    
    # CPU限制
    local cpu_period=100000
    local cpu_quota=$(echo"$cpu_limit * $cpu_period" | bc | cut -d. -f1)
    echo"$cpu_period" | sudotee"$cgroup_path/cpu.cfs_period_us" > /dev/null
    echo"$cpu_quota" | sudotee"$cgroup_path/cpu.cfs_quota_us" > /dev/null
    echo"? CPU限制: ${cpu_limit}核"
}

磁盤I/O也是個大頭，特別是日志文件寫入頻繁的應(yīng)用。我會做好日志輪轉(zhuǎn)配置，避免磁盤被撐爆：

# logrotate配置示例
$log_dir/*.log {
    daily
    missingok
    rotate 7
    compress
    delaycompress
    notifempty
    create 644 $app_name$app_name
    
    postrotate
        if [ -f /var/run/${app_name}.pid ]; then
            kill -HUP $(cat /var/run/${app_name}.pid) 2>/dev/null || true
        fi
    endscript
}

六、服務(wù)依賴關(guān)系的復(fù)雜網(wǎng)絡(luò)

現(xiàn)在的應(yīng)用架構(gòu)越來越復(fù)雜，微服務(wù)之間的依賴關(guān)系像蜘蛛網(wǎng)一樣，任何一個服務(wù)掛了都可能引發(fā)連鎖反應(yīng)。數(shù)據(jù)庫掛了，后端服務(wù)起不來；緩存服務(wù)異常，整個應(yīng)用性能下降；消息隊(duì)列堵塞，數(shù)據(jù)處理停滯。

我一般會建立服務(wù)依賴拓?fù)?，按照依賴關(guān)系順序啟動服務(wù)：

# 服務(wù)依賴配置
{
"services": {
    "mysql": {
      "type": "database", 
      "dependencies": [],
      "health_check": "mysqladmin ping -h localhost",
      "start_timeout": 60
    },
    "redis": {
      "type": "cache",
      "dependencies": [],
      "health_check": "redis-cli ping",
      "start_timeout": 15
    },
    "app-backend": {
      "type": "application",
      "dependencies": ["mysql", "redis"],
      "health_check": "curl -f http://localhost:8080/api/health",
      "start_timeout": 45
    }
  }
}

健康檢查也很重要，不能只看進(jìn)程是否存在，還要確保服務(wù)真的可用。HTTP接口要能正常響應(yīng)，數(shù)據(jù)庫連接要正常，緩存要能讀寫，這些都得檢查到位。

責(zé)任編輯：趙寧寧來源： IT運(yùn)維技術(shù)圈