name: server-management description: 服务器管理原则和决策制定。过程管理、监控策略和扩展决策。教思维，而非命令。 allowed-tools: 读, 写, 编辑, 全局, 搜索, Bash
服务器管理
生产操作的服务器管理原则。 学会思考，而不是记忆命令。
1. 过程管理原则
工具选择
| 场景 | 工具 |
|---|---|
| Node.js应用 | PM2 (集群, 重新加载) |
| 任何应用 | systemd (Linux原生) |
| 容器 | Docker/Podman |
| 编排 | Kubernetes, Docker Swarm |
过程管理目标
| 目标 | 含义 |
|---|---|
| 崩溃时重启 | 自动恢复 |
| 零停机重新加载 | 无服务中断 |
| 集群 | 使用所有CPU核心 |
| 持久性 | 服务器重启后存活 |
2. 监控原则
监控什么
| 类别 | 关键指标 |
|---|---|
| 可用性 | 运行时间, 健康检查 |
| 性能 | 响应时间, 吞吐量 |
| 错误 | 错误率, 类型 |
| 资源 | CPU, 内存, 磁盘 |
警报严重性策略
| 级别 | 响应 |
|---|---|
| 关键 | 立即行动 |
| 警告 | 尽快调查 |
| 信息 | 每日回顾 |
监控工具选择
| 需求 | 选项 |
|---|---|
| 简单/免费 | PM2指标, htop |
| 完整可观察性 | Grafana, Datadog |
| 错误跟踪 | Sentry |
| 运行时间 | UptimeRobot, Pingdom |
3. 日志管理原则
日志策略
| 日志类型 | 目的 |
|---|---|
| 应用日志 | 调试, 审计 |
| 访问日志 | 流量分析 |
| 错误日志 | 问题检测 |
日志原则
- 轮换日志 以防止磁盘填满
- 结构化日志 (JSON) 用于解析
- 适当级别 (错误/警告/信息/调试)
- 日志中无敏感数据
4. 扩展决策
何时扩展
| 症状 | 解决方案 |
|---|---|
| 高CPU | 添加实例 (水平) |
| 高内存 | 增加RAM或修复泄漏 |
| 慢响应 | 先分析, 然后扩展 |
| 流量峰值 | 自动扩展 |
扩展策略
| 类型 | 何时使用 |
|---|---|
| 垂直 | 快速修复, 单实例 |
| 水平 | 可持续, 分布式 |
| 自动 | 可变流量 |
5. 健康检查原则
构成健康的因素
| 检查 | 含义 |
|---|---|
| HTTP 200 | 服务响应 |
| 数据库连接 | 数据可访问 |
| 依赖项正常 | 外部服务可达 |
| 资源正常 | CPU/内存未耗尽 |
健康检查实现
- 简单: 只返回200
- 深入: 检查所有依赖项
- 根据负载均衡器需求选择
6. 安全原则
| 区域 | 原则 |
|---|---|
| 访问 | 仅SSH密钥, 无密码 |
| 防火墙 | 仅开放所需端口 |
| 更新 | 定期安全补丁 |
| 密钥 | 环境变量, 而非文件 |
| 审计 | 记录访问和更改 |
7. 故障排除优先级
当出现问题时:
- 检查是否运行 (过程状态)
- 检查日志 (错误消息)
- 检查资源 (磁盘, 内存, CPU)
- 检查网络 (端口, DNS)
- 检查依赖项 (数据库, APIs)
8. 反模式
| ❌ 不要 | ✅ 做 |
|---|---|
| 以root运行 | 使用非root用户 |
| 忽略日志 | 设置日志轮换 |
| 跳过监控 | 从一开始监控 |
| 手动重启 | 自动重启配置 |
| 无备份 | 定期备份计划 |
记住: 一个良好管理的服务器是无聊的。这就是目标。