明明測試沒問題，生產就翻車？老楊聊 Devops 的血淚史
作者：靜靜和小沐沐
今天就來聊聊這個讓無數技術人員頭疼的話題：測試沒問題，為什么上生產就總出問題。
"測試環境跑得好好的，怎么一上生產就出幺蛾子？"這話老楊聽了二十年，從當年的菜鳥工程師到現在的老油條，這個魔咒從來沒有被打破過。
今天就來聊聊這個讓無數技術人員頭疼的話題。測試沒問題，為什么上生產就總出問題。
一、環境差異這個老大難問題
1. 版本差異的深水炸彈
別看都是Linux系統，開發環境用的Ubuntu 22.04和生產環境的CentOS 7.9之間的差別，有時候比你想象的要大得多。就拿Python來說，前者自帶3.10，后者還在用3.6，這點小差別就能讓你的腳本死得很難看。
老楊調出一個比較經典的錯誤.我這里有個哥們兒寫了個部署腳本，用了subprocess.run()的text參數，在開發機上跑得挺好：
#!/usr/bin/env python3
import subprocess
result = subprocess.run(['systemctl', 'status', 'nginx'],
capture_output=True, text=True)
print(f"Exit code: {result.returncode}")結果到了生產環境，Python 3.6根本不認識text這個參數，直接給你來個TypeError。踩這種坑不止一次，后來學乖了，兼容性處理必須做到位：
#!/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. 依賴庫版本的連環坑
生產服務器的依賴庫版本往往比開發環境落后好幾個版本，這時候各種奇怪的兼容性問題就出來了。你在開發環境用的是requests 2.31.0，生產環境可能還是2.25.1，SSL證書驗證的行為就不一樣了。
這種情況下，我一般會創建個虛擬環境，把依賴版本鎖死：
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"=== 創建隔離的Python環境 ==="
if [ ! -d "$VENV_DIR" ]; then
python3 -m venv "$VENV_DIR"
fi
source"$VENV_DIR/bin/activate"
pip install --no-deps -r requirements.txt
echo"=== 驗證環境一致性 ==="
pip freeze | sort > deployed_versions.txt
python api_client.py二、權限問題，這個隱形殺手
在測試環境，開發人員通常有sudo權限，想寫哪兒就寫哪兒。但生產環境不一樣，權限控制嚴格得很，稍不注意就撞墻了。
這里老楊舉一個權限檢查腳本，每次部署前都會跑一遍，避免踩坑：
#!/bin/bash
# permission_check.sh - 生產環境權限預檢
set -euo pipefail
echo"=== 系統權限診斷報告 ==="
echo"執行用戶: $(whoami)"
echo"用戶組: $(groups)"
echo"當前目錄: $(pwd)"
declare -A critical_dirs=(
["/var/log"]="日志目錄"
["/etc/systemd/system"]="系統服務配置"
["/opt/applications"]="應用部署目錄"
["/tmp"]="臨時文件目錄"
)
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系統里默默守護，很多時候你的腳本運行失敗，根本想不到是它在作怪。檢查SELinux狀態，配置正確的文件上下文，這些都得考慮進去。
三、網絡環境，看不見的攔路虎
企業內網環境復雜，防火墻規則、代理設置、DNS解析，任何一個環節出問題都能讓你的腳本跑不起來。
這里老楊舉例一個網絡連通性檢查腳本：
#!/bin/bash
# network_connectivity_check.sh
set -euo pipefail
declare -A endpoints=(
["registry.cn-hangzhou.aliyuncs.com:443"]="阿里云容器鏡像服務"
["mirrors.aliyun.com:80"]="阿里云軟件源"
["api.dingtalk.com:443"]="釘釘API"
["127.0.0.1:3306"]="本地MySQL"
["redis.internal.company.com:6379"]="內網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 可達"
else
echo" ? 端口 $port 不可達"
echo" ?? 建議檢查防火墻規則:"
echo" sudo iptables -L | grep $port"
fi
echo
}
for endpoint in"${!endpoints[@]}"; do
check_connectivity "$endpoint""${endpoints[$endpoint]}"
done特別是企業代理環境，這個更是個大坑。所有外網訪問都得走代理，腳本里不配置代理參數，連個包都下載不了。我一般會做個代理感知的處理：
setup_proxy() {
echo"=== 代理環境配置 ==="
local proxy_sources=(
"$http_proxy"
"$HTTP_PROXY"
"http://proxy.company.com:8080"# 企業默認代理
)
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
}四、配置管理的精細化工程
配置文件的管理更是門學問。不同環境用不同的配置，這個看起來簡單，實際操作起來坑不少。配置文件的版本控制、語法驗證、權限設置，每一步都不能馬虎。
我習慣用Git管理配置，按環境分目錄存放，部署的時候根據環境選擇對應的配置：
#!/bin/bash
manage_configs() {
localenv=$1# dev, test, prod
echo"=== 環境配置管理 [$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"? 環境配置目錄不存在: $config_source"
return 1
fi
# 備份現有配置
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"?? 備份現有配置到: $backup_path"
sudocp -r "$CONFIG_DIR""$backup_path"
fi
# 部署新配置
sudocp -r "$config_source"/* "$CONFIG_DIR/"
sudochown -R myapp:myapp "$CONFIG_DIR"
echo"? 配置管理完成"
}密鑰管理這塊兒更得小心，生產環境的密碼、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
}五、資源限制的現實約束
生產環境的資源控制比開發環境嚴格多了，CPU、內存、磁盤I/O都有限制。你的腳本在開發機上跑得飛快，到了生產環境可能因為資源不夠用而跑得慢如蝸牛，甚至直接被kill掉。
我經常用cgroup來做資源限制，確保應用不會因為資源搶占而影響其他服務：
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"
# 創建cgroup
local cgroup_path="/sys/fs/cgroup/myapps/$app_name"
sudomkdir -p "$cgroup_path"
# 內存限制
echo"$memory_limit" | sudotee"$cgroup_path/memory.limit_in_bytes" > /dev/null
echo"? 內存限制: $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也是個大頭，特別是日志文件寫入頻繁的應用。我會做好日志輪轉配置，避免磁盤被撐爆：
# 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
}六、服務依賴關系的復雜網絡
現在的應用架構越來越復雜，微服務之間的依賴關系像蜘蛛網一樣，任何一個服務掛了都可能引發連鎖反應。數據庫掛了，后端服務起不來；緩存服務異常，整個應用性能下降；消息隊列堵塞，數據處理停滯。
我一般會建立服務依賴拓撲，按照依賴關系順序啟動服務：
# 服務依賴配置
{
"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
}
}
}健康檢查也很重要，不能只看進程是否存在，還要確保服務真的可用。HTTP接口要能正常響應，數據庫連接要正常，緩存要能讀寫，這些都得檢查到位。
責任編輯：趙寧寧
來源：
IT運維技術圈
