手里攥着100台Linux服务器，不想天天通宵？这份“偷懒”指南请收好

咱实话实说，从管 10 台机器到管 100 台机器，那绝对不是简单的“工作量 x10”的概念，那是维度上的打击。

10 台机器的时候，你是个手艺人，精心雕琢每一台服务器，哪台机器脾气咋样你都门儿清。到了 100 台，你必须得是个包工头，甚至是个工厂厂长。你要是还想着一台台 ssh 上去敲命令，我敢打赌，不出三个月，要么你身体垮了，要么你因为误操作把生产环境搞崩了提桶跑路。

我在这个坑里摸爬滚打好几年，从最初的“人肉运维”到后来的“喝茶运维”，总结下来，管好 100 台服务器，核心就在于把非标准化的烂摊子变成流水线作业。

下面这些内容，都是我用熬夜和发际线换来的血泪经验。

一、 别上来就干，先把家底盘清楚（资产与标准化）

刚接手 100 台机器时，最可怕的不是机器多，而是乱。

我见过最坑爹的情况，Excel 表里写着 IP 是 Web 服，连上去一看跑着 MySQL；主机名全是 localhost 或者 instance-xxxxx 这种云厂商默认名。这要是半夜报警，你都不知道挂的是哪位大爷。

1. 这里的技术细节：主机名（Hostname）规范

必须重命名。不要嫌麻烦，这事儿一本万利。
我的命名规则通常是：地区-环境-业务-角色-序号。

比如：bj-prod-shop-nginx-01

• bj：北京节点
• prod：生产环境
• shop：电商商城业务
• nginx：服务角色
• 01：第一台

怎么批量改？写个简单的 Shell 脚本，配合一个文本文件（IP和主机名对应表），循环跑一遍 hostnamectl set-hostname。

2. 这里的技术细节：系统层面的“统一度量衡”

100 台机器，操作系统版本必须锁死。别一会儿 CentOS 7.6，一会儿 7.9，一会儿又冒出个 Ubuntu。内核版本不同，有些内核参数的表现是不一样的，到时候排查问题能把你气死。

新机器到手，初始化脚本（System Init Script） 是第一道工序。这个脚本里必须包含：

• 更换 YUM/APT 源：换成阿里云或清华源，内网有条件的自建 Repo 更好，速度就是生命。
• 安装基础工具包：vim, lrzsz, wget, curl, net-tools, sysstat (iostat, mpstat, sar 全靠它)，tcpdump。哪怕现在用不上，装上总没错，省得排错时抓瞎。
• 时间同步（Chrony）：把 NTP 换成 Chrony 吧，同步速度快，精度高。配置好内网的 NTP server，别让 100 台机器都去公网对时，防火墙要是严一点就瞎了。
• 文件描述符限制：echo "* - nofile 65535" >> /etc/security/limits.conf。别等业务跑起来报 "Too many open files" 再去改，那时候通常得重启进程。

二、 还在手动敲命令？Ansible 搞起来（自动化执行）

管理 10 台机器你可以用 Xshell 的“发送键输入到所有会话”，100 台你再这么干，那就是在玩火。网络稍微抖一下，或者哪台机器卡一下，你的命令就乱套了。

你需要 Ansible。

为啥不是 SaltStack？因为 Salt 需要在客户端装 Agent（Minion），100 台机器还得维护 100 个 Agent 的死活，累不累？Ansible 走 SSH，只要 SSH 通，它就能干活，轻量、干净。

1. 这里的技术细节：SSH 优化

Ansible 既然走 SSH，那 SSH 的连接速度就决定了你的执行效率。100 台机器，每台慢 1 秒，就是慢 100 秒。

• 关闭 DNS 解析：在 /etc/ssh/sshd_config 里设置 UseDNS no。否则每次连上去它都要反查你的 IP，慢得要死。
• 复用连接（ControlPersist）：在你的管理机（Ansible控制端）的 ~/.ssh/config 或者 ansible.cfg 里配置开启 ControlMaster 和 ControlPersist。建立一次连接后，socket 文件保留一段时间，后续的命令直接复用通道，速度起飞。

2. 这里的技术细节：Ansible 调优

默认 Ansible 的并发数（forks）是 5。意思是一次只操作 5 台。100 台机器跑完得猴年马月。
在 ansible.cfg 里，把 forks 改成 20 甚至 50。取决于你控制机的 CPU 和带宽。

3. 实战场景：批量分发配置

举个例子，你要修改所有 Nginx 的 nginx.conf。
别写 Shell 循环了，用 Ansible 的 copy 模块和 service 模块：

- name: Update Nginx Config
  hosts: web_group
  tasks:
    - name: Push config file
      copy:
        src: ./nginx.conf
        dest: /etc/nginx/nginx.conf
        backup: yes  # 关键！覆盖前先备份，救命用的参数
      notify: Reload Nginx # 触发器，只有文件变了才重启

  handlers:
    - name: Reload Nginx
      service:
        name: nginx
        state: reloaded

这比你手动搞稳得多，因为它是幂等的。你跑一次和跑十次，结果都是一样的，不会因为重复执行而出错。

三、 监控不是越多越好，是越准越好（可观测性）

没有监控，运维就是瞎子。但 100 台机器，如果监控策略没搞好，你会被“告警风暴”轰炸成神经衰弱。

1. 这里的技术细节：Prometheus + Grafana 是标配

放弃 Zabbix 吧（虽然它是经典），Prometheus 在自动发现和容器化支持上更现代化。
每台机器装个 node_exporter，这就把 CPU、内存、磁盘 IO、网络流量全收上来了。

2. 核心：关于 Load Average 的误区

很多新手喜欢监控 CPU 使用率，设定超过 80% 就报警。其实在 Linux 下，Load Average（负载） 往往比 CPU 使用率更能反映问题。
CPU 高可能是单纯计算密集型任务，机器还能响应。但如果 Load 高（超过 CPU 核数），说明有进程在排队等待 CPU 或者等待磁盘 IO（D状态进程）。

所以我建议的报警策略：

• Load Average > CPU 核数 * 1.5（持续 5 分钟）：严重报警。
• 磁盘剩余空间 < 15%：预警（给人处理的时间）。
• 磁盘 Inodes 使用率：别忘了这个！有时候磁盘没满，但小文件太多把 Inode 耗尽了，一样写不进数据。

3. 这里的技术细节：告警收敛

这是个大坑。100 台机器，如果交换机抖了一下，100 台机器同时报“网络不可达”，你的手机短信能瞬间炸了。
你要配置 Alertmanager 的 group_wait 和 group_interval，把同一时间段、同一类别的报警合并成一条发出来。比如：“[严重] 100台机器 SSH 连接超时”，而不是 100 条短信。

四、 日志不集中，排查就是火葬场

以前机器少，出问题了 ssh 上去 tail -f /var/log/messages。
现在 100 台，用户反馈“访问报错”，请求是随机分发到某台机器的，你怎么找？难道开 100 个终端窗口去 grep？

1. 这里的技术细节：ELK 还是太重？试试 PLG

传统的 ELK (Elasticsearch, Logstash, Kibana) 确实强大，但是吃内存大户。Elasticsearch 维护起来也得要点水平。
对于 100 台这个规模，如果资源有限，我强烈推荐 Loki + Promtail + Grafana (PLG)。

• Promtail：部署在每台服务器上，极轻量，只负责采集日志文件，打上标签（Label），推送到 Loki。
• Loki：日志存储。它不像 ES 那样做全文索引（费内存），它只索引标签。查日志的时候类似 grep，但是是分布式的 grep。
• Grafana：展示界面。

这样，开发跑过来问：“帮我查下这个订单号为什么失败”，你直接在 Grafana 里输入 {app="shop"} |= "ORDER123456"，一秒钟出结果。

五、 安全这根弦，断了就是职业生涯终结

100 台机器，意味着有 100 个入口可能被攻破。

1. 这里的技术细节：Jumpserver 堡垒机

千万别把服务器的真实 IP 和 root 密码直接给开发人员，甚至运维内部也别互相传私钥。
搭建一个开源的 Jumpserver。

• 统一入口：所有人都得先登堡垒机，再跳转。
• 权限回收：某人离职了，你只需要在堡垒机上禁用他的账号，而不用去 100 台机器上删他的公钥。
• 录像审计：这是甩锅神器。万一数据库被删了，回放录像，谁敲的 rm -rf，几点几分敲的，一清二楚。

2. 这里的技术细节：Sudo 权限控制

别给所有人 root。用 Ansible 批量分发 /etc/sudoers 配置。
利用 Linux 的 Group 功能，比如 dev 组只能 sudo systemctl restart nginx，而不能 sudo su -。精确控制权限范围。

六、 总结：做个“偷懒”的运维

写了这么多，其实就一个理儿：机器多了，必须要把“人”的因素降到最低。

人的记性是不可靠的，人的手是会抖的，人的情绪是会波动的。但脚本不会，Ansible 不会，监控系统不会。

• 凡是需要操作超过两次的，写成脚本。
• 凡是需要在两台机器以上执行的，用 Ansible。
• 凡是需要人肉盯着看的，交给 Prometheus。

当你把这套体系搭起来之后，你会发现，虽然手里有 100 台机器，但你反而比管 10 台的时候更闲了。这才是运维的高级境界。

希望这些干货能帮大家少踩几个坑，多睡几个安稳觉。

最后，运维这条路，坑深路远。如果你觉得今天这篇文章对你有那么一点点启发，别忘了点个赞。

关注 @运维躬行录，咱们下期聊聊怎么用最省钱的方案搞定异地灾备，保证老板看了直呼内行。转发给你的运维兄弟，大家一起拒绝 996，科学摸鱼！