1. 为什么需要一个系统初始化脚本做运维或者自己折腾服务器的人应该都经历过这种场景刚买了一台云主机或者公司新分配了一台物理机系统装好了SSH能登进去了但接下来才是真正的开始。改主机名、配时区、创建用户、设置SSH安全选项、更换软件源、装基础工具、调内核参数……这一套流程你每来一台新机器就得手动来一遍。我见过不少同行干这活儿全靠复制粘贴之前某台服务器的配置命令改改IP和主机名就完事。运气好一次过运气不好漏了某个步骤后面排查问题的时候才发现系统时间不对、文件描述符上限不够、swap没关干净再回头补配置。浪费时间不说关键是每台机器配置不一致后面统一管理的时候非常痛苦。这个标题里的核心就是写一个能够“一键执行”的shell脚本把新装Linux系统的基础配置工作自动化。它能做的事情包括但不限于设置主机名和时区、创建运维用户并配置sudo权限、优化SSH服务配置、更换软件源、安装常用的基础工具包、调整内核参数、设置文件描述符限制、同步系统时间等。跑完这个脚本一台服务器基本就是“可交付”状态了直接可以扔给业务部门或者用于部署应用。这篇文章适合谁看一是刚接触Linux运维、想了解服务器上线前要做哪些基础配置的新手二是已经有一些经验、但每次配置新机器都在重复劳动、想提升效率的同行三是自己搭实验室环境、希望有一套标准化初始化流程的朋友。我会把脚本的设计思路、每个模块的实现细节、踩过的坑都拆开来讲清楚你照着做就能得到一套可以长期使用的初始化脚本。整个脚本的定位是“基础配置自动化”不是运维平台也不是配置管理工具比如Ansible那一套它的价值在于轻量、直接、可移植。一台机器只要系统装好了把脚本传上去跑一遍十几分钟就能搞定原本需要一两小时甚至半天的基础配置工作。2. 整体设计与思路拆解2.1 模块化设计把脚本拆成零件而不是一坨写初始化脚本最容易犯的错误就是把所有步骤顺序堆在一个文件里从上到下几百行所有逻辑混在一起。这样的脚本不是不能用但后期维护特别难受。比如你想单独改一下软件源的处理逻辑得在一大段代码里找半天想复用某个功能也没法直接拎出来。我自己的做法是模块化设计。把脚本拆成几个功能独立的函数或者区域每个区域只负责一个明确的任务。一个典型的初始化脚本结构是这样的环境检查确认系统类型CentOS系还是Debian系、当前用户权限、网络连通性基础配置主机名、时区、DNS用户管理创建运维用户、配置sudo、设置SSH登录方式安全加固SSH配置优化、防火墙基础策略软件源配置根据系统版本替换为合适的镜像源工具安装批量安装常用软件包系统参数调优内核参数、资源限制、swap策略这样拆开之后每个部分可以单独测试出了问题能快速定位。而且脚本的可读性提升很多别人拿到脚本也能看明白每一段在干什么。设计的时候还要考虑运行方式。我习惯把脚本设计成“可重复执行”的也就是说同一台机器上跑第二遍或者第三遍不会产生冲突或者破坏已有配置。这就要用到幂等性的思想后面我会专门讲。2.2 幂等性设计同一台机器能跑两遍而不出错这个思路我觉得很重要单独拿出来说说。所谓幂等就是你执行一次和执行十次的效果是一样的。初始化脚本最容易出现的问题就是第一次跑成功了第二次跑的时候某个步骤报错了因为第一次已经创建过用户了第二次再去创建就提示“已存在”脚本直接中断。要达到幂等效果最常用的办法就是在每个关键操作前做判断。比如创建用户之前先检查这个用户是否已经存在if id $NEW_USER /dev/null; then echo 用户 $NEW_USER 已存在跳过创建 else useradd -m -s /bin/bash $NEW_USER fi这样的判断逻辑写起来并不复杂但能避免很多重复执行时的麻烦。同类处理还包括修改SSH配置前先备份原文件追加环境变量前先检查是否已经追加过安装软件包时使用幂等的包管理命令比如apt install本身是幂等的。有人会觉得这样写脚本啰嗦但实际线上操作时脚本运行到一半因为网络原因中断了你修完问题重新跑一遍如果没有幂等性设计就要先手动清理半成品状态非常麻烦。有了幂等性重新执行脚本就行了省心很多。2.3 变量抽取把“环境相关”和“通用逻辑”分开初始化脚本在不同机器上跑总有一些参数是每台机器不一样的比如主机名、要创建的用户名、SSH端口等。如果把这些直接写死在脚本里每次用到新机器上都得改脚本容易改错也不方便多人协作。我的建议是把这类参数统一抽到脚本顶部集中管理。要么定义一批变量要么支持从命令行参数传入。例如# 可配置参数区域 HOSTNAMEweb-server-01 NEW_USERops SSH_PORT22 TIMEZONEAsia/Shanghai # # 后续代码中引用变量 hostnamectl set-hostname $HOSTNAME更进一步如果你有多台机器需要批量初始化还可以配合循环和参数传递使用。我实际项目中接触到的做法是脚本支持传入自定义配置文件或者环境变量文件把变量定义放在独立的conf文件里脚本负责source这个文件。这样脚本本身的通用性更强变量配置和逻辑代码完全分离。2.4 工具选型到底是纯shell还是用Python/Ansible这个问题可能在设计之初就会遇到。既然要实现系统初始化可用的工具很多纯Shell脚本、Python脚本、Ansible playbook、SaltStack等。我的结论是基础初始化场景下Shell脚本仍然是性价比最高的选择。原因有几个。第一Shell脚本不依赖额外环境。新装系统好不好系统自带的bash和核心命令一定在直接用就行。Python要确认是否安装了Ansible更麻烦要么在控制端安装要么在目标机上配置Python环境。第二系统初始化的本质就是执行一条条系统命令Shell本来就是干这个的。用Python无非是把system命令包一层没有本质提升。第三Shell脚本排障直观哪一步出错直接看到的是bash的报错配合echo输出问题定位很直接。当然如果你的环境已经引入了Ansible这类配置管理工具而且你在管理几十上百台机器那用Ansible做初始化是合理的Ansible的幂等性天生做得很好有playbook的可读性有变量和模板机制。但如果你只有几台机器或者你只是想快速搞定一台新服务器Shell脚本完全够用。3. 核心细节解析与实操要点3.1 set -euo pipefail脚本的“安全气囊”我见过不少初学者的脚本开头就是#!/bin/bash然后一堆命令往下写。这样有个问题如果中间某条命令失败了返回非0退出码脚本默认会继续往下执行。这在初始化场景下可能造成严重的连锁反应——比如用户没创建成功后面却继续执行了设置密码和配置sudo的步骤最终得到一个“看起来成功了但实际残缺”的配置状态。要解决这个问题脚本开头要加上严格的shell选项。这是我每写一个脚本都会默认加上的四行#!/bin/bash set -euo pipefail IFS$\n\t逐个解释一下。set -e 表示“任何一条命令返回非0状态码立即退出脚本”避免错误被忽略导致后续步骤在错误状态下执行。set -u 表示“引用未定义的变量直接报错”这能抓到很多拼写错误和逻辑疏漏。set -o pipefail 表示“管道命令中只要有任一步骤失败整个管道的退出状态就是失败”防止前面命令出错但被后面命令的返回码掩盖。IFS$\n\t 则是把默认的分隔符改成只有换行和制表符避免文件名或变量值里带空格时被意外拆分。这四行组合在一起相当于给脚本加了个“安全气囊”。不是说加了就万无一失但确实能拦截掉极其常见的一类错误。唯一的代价是脚本“变脆弱了”有一点小问题就中断退出。但初始化脚本本来就该谨慎宁可中断不可凑合往下跑。3.2 日志与错误处理跑挂了要知道挂在哪里脚本中断不可怕可怕的是中断之后你不知道刚才执行到哪一步了。排查进度全靠猜这在初始化场景下特别要命因为脚本步骤多、耗时长不可能每次都盯着屏幕。我习惯的做法是给每个模块加明确的分隔日志可读性很重要。比如echo [1/8] 设置主机名 hostnamectl set-hostname $HOSTNAME echo [2/8] 配置时区 timedatectl set-timezone $TIMEZONE每跑完一个模块输出一行带编号和名称的进度提示跑挂的时候一眼就能知道卡在哪一个模块。更进一步可以把整个脚本的输出重定向到日志文件同时保留一份在终端exec (tee -a $LOG_FILE) 21这一行的作用是脚本的所有标准输出和错误输出都同时打到终端和日志文件里。这样既能实时看到进度又保留了完整的执行记录排障时可以直接看日志文件。3.3 系统环境探测Ubuntu还是CentOS决定后面怎么做初始化脚本要面对的机器系统版本不可能完全一致。有的公司内部主用CentOS有的用Ubuntu还有些是用国产化系统比如基于CentOS或Debian二次开发的发行版。脚本要有能力自动识别系统类型然后走对应的分支逻辑。最常用的探测方法是看/etc/os-release文件。这个文件在现代主流Linux发行版中基本都存在里面有条目记录系统ID和版本号if [ -f /etc/os-release ]; then . /etc/os-release OS_ID$ID # 比如 ubuntu / centos / debian OS_VERSION$VERSION_ID else echo 无法识别系统类型脚本终止 exit 1 fi拿到OS_ID之后后面的软件源配置、包管理器选择、服务管理命令等都可以根据系统类型走不同分支。比如包管理器Ubuntu/Debian系用aptCentOS/RHEL系老版本用yum新版用dnf。服务管理在systemd时代统一用systemctl但如果碰到比较老的系统比如CentOS 6虽然已经很老了但还是有存量环境需要走service和chkconfig。写这个探测的时候有一点值得提醒不要假设所有“像CentOS”的系统都真的是CentOS。比如Rocky Linux、AlmaLinux、Oracle Linux它们的ID字段都写着自己的名字不能只判断ID等于centos就完事用通配匹配的方式比如case语句里统一处理才能覆盖更多的兼容系统。4. 实操过程与关键环节实现4.1 主机名与时区先把“身份”定下来一台新服务器到手主机名大概率是默认的localhost或者云厂商随机生成的字符串时区大多是UTC。这两个不调整后面排查日志时会很痛苦——日志里时间戳跟你的本地时间对不上主机名也不知道哪台是哪台。主机名设置现代系统用hostnamectl就行它同时管理静态主机名、临时主机名和pretty主机名hostnamectl set-hostname $HOSTNAME echo 127.0.0.1 $HOSTNAME /etc/hosts第二行是追加到/etc/hosts确保本机解析自己的主机名时不会走到DNS。有些应用比如某些数据库和消息队列对主机名解析非常敏感解析不回来会报错。时区设置用timedatectltimedatectl set-timezone $TIMEZONE设置完之后验证一下timedatectl要注意的是如果你后面安装了NTP时间同步服务最好同时确认时间同步状态正常。在中国大陆的服务器上公网NTP服务器建议用国内可访问的比如阿里云NTP、腾讯云NTP否则默认的pool.ntp.org可能因为网络原因同步不上时间一直偏着。这个坑我踩过系统装好之后没做时间同步结果业务日志时间和监控曲线对不齐排查了很久。4.2 用户与SSH配置安全的底线系统初始化的安全配置里创建日常运维用户和加固SSH是比较核心的部分。不建议直接拿root做所有操作也不建议把root的密码暴露给多人。合理的做法是创建一个运维用户给它sudo权限日常用这个用户登录需要提权的时候sudo。创建用户的部分加了幂等判断的写法如下if id $NEW_USER /dev/null; then echo 用户 $NEW_USER 已存在跳过创建 else useradd -m -s /bin/bash $NEW_USER echo $NEW_USER:$INIT_PASSWORD | chpasswd echo 用户 $NEW_USER 创建完成 fi这里有一个细节设置初始密码之后最好加上密码过期策略强制用户首次登录修改密码chage -d 0 $NEW_USER这样做的理由是初始化脚本里配置的初始密码是写在脚本里的不管脚本传到哪儿密码都有泄露面。强制首次登录改密码即使初始密码泄露了只要用户及时改了风险就缓解了。sudo配置推荐用独立的sudoers文件不要直接改/etc/sudoers主文件系统升级时可能被覆盖而且语法错误可能影响到系统所有用户echo $NEW_USER ALL(ALL) NOPASSWD:ALL /etc/sudoers.d/$NEW_USER chmod 440 /etc/sudoers.d/$NEW_USERNOPASSWD的意思是sudo时不需要再输一次密码。有的团队觉得这样不安全会去掉NOPASSWD改成每次都输密码。这个看各自的安全策略没有绝对的对错。我个人的建议是服务器上的日常运维用NOPASSWD提升效率但前提是SSH必须用密钥登录且要做好操作审计比如配置sudo日志记录。SSH配置加固主要做三件事禁止root直接SSH登录PermitRootLogin no启用公钥认证设置AuthorizedKeysFile路径根据实际需求修改SSH端口这个见仁见智我倾向默认22端口靠防火墙限制来源IP改端口的意义其实没有想象中大修改之前一定先备份原配置cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date %Y%m%d%H%M%S)这个习惯很重要。我见过不止一次有人手改SSH配置把语法写错了服务起不来然后远程连接直接断了只能去机房或者用云平台的VNC控制台救回来。所以改SSH之前先备份改完之后先执行sshd -t检查语法再重启服务。4.3 软件源替换把“默认仓库”换成体验更好的镜像源新装的系统默认软件源在国内网络环境下速度经常不理想特别是一些海外发行版比如Ubuntu默认指向archive.ubuntu.comCentOS默认指向mirror.centos.org。初始化脚本里顺手把软件源换成国内镜像后续装软件会快很多。以Ubuntu系统为例我习惯用sed匹配替换的方式把默认源地址替换成镜像站地址sed -i s/archive.ubuntu.com/mirrors.aliyun.com/g /etc/apt/sources.list sed -i s/security.ubuntu.com/mirrors.aliyun.com/g /etc/apt/sources.list如果是Ubuntu 22.04及以后的版本软件源配置改成了/etc/apt/sources.list.d/ubuntu.sourcesdeb822格式需要注意区分。判断方法很简单先看看目录里有什么文件再决定改哪里。CentOS/RHEL系的软件源老的7版本还比较简单修改/etc/yum.repos.d/CentOS-Base.repo8及以后的版本把BaseOS、AppStream、Extras等分在了不同仓库文件中替换时要处理多个文件。而且CentOS 8官方停止维护后你如果还在用CentOS 8必须切换源到vault仓库才能继续使用yum。替换完源之后跑一遍系统更新同时验证源配置是否正常apt update apt upgrade -y有两点提醒。第一软件源替换涉及网络请求如果脚本要在内网环境跑有些公司的服务器只能通过内网镜像源访问镜像地址要换成内网地址。这时候我发现的最好做法是把源地址也做成变量脚本跑起来再按需传入。第二大规模批量跑这个操作时不建议所有机器同一时刻执行update可以加个随机延迟减轻镜像站压力。4.4 内核参数调优让系统在基础层面更适合跑业务内核参数调优是初始化脚本里“含金量”比较高的部分虽然不至于让系统性能有质的飞跃但一些基础参数确实能减少后续业务部署时的坑。我常用的内核参数调整方案大致包含以下几类文件描述符上限这是最常见的瓶颈。高并发服务动不动就要打开成千上万个连接默认的1024上限根本不够。需要同时调整系统级和用户级# 系统级 echo fs.file-max 65535 /etc/sysctl.conf # 用户级 echo * soft nofile 65535 /etc/security/limits.conf echo * hard nofile 65535 /etc/security/limits.confTCP连接参数TIME_WAIT复用和快速回收net.ipv4.tcp_tw_reuse 1 net.ipv4.tcp_fin_timeout 30这里注意net.ipv4.tcp_tw_recycle这个参数在nat环境下有坑会导致连接异常我个人的建议是不要开它。tcp_tw_reuse倒是安全的它只对出站连接生效不会影响入站。具体生效方式修改/etc/sysctl.conf后执行sysctl -p加载然后sysctl -a验证sysctl -p还有swap的调整策略。默认的swappiness值60对服务器来说可能偏高会导致系统在内存还有一些余量时就开始用swap影响性能。一般倾向调低sysctl -w vm.swappiness10不过这个值到底调多少要看业务类型。内存型应用我通常调成10甚至直接0完全不使用swap普通的混合负载调10到30之间比较稳妥。建议根据自己的业务特性测试后决定不要盲目照抄。4.5 基础工具安装把“调试检修”的必要零件补齐新装的系统非常精简很多在排障、监控、诊断时会用到的工具默认都没装。初始化脚本里顺手批量安装一批基础工具省得后面用到的时候临时找包。Ubuntu/Debian系我一般会装这些apt install -y vim curl wget lsof net-tools tcpdump tree zip unzip \ telnet traceroute sysstat iotop htop dstat \ git make gcc build-essential psmiscCentOS/RHEL系对应的是yum install -y vim wget curl lsof net-tools tcpdump tree zip unzip \ telnet traceroute sysstat iotop htop dstat \ git make gcc gcc-c psmisc可能有人会说net-tools里有ifconfig这些已经过时了现在推荐用ip命令。这话没错ip命令确实更强大但如果团队里有些同事还不习惯装一个net-tools保留ifconfig也无伤大雅。毕竟兼容性并不仅仅是指“技术上正确”也包括“团队的使用习惯”。这些工具里面sysstat比较值得单独说一下。它提供sar、iostat、mpstat等命令是Linux性能分析的利器。不管是日常巡检还是出事后的排查都离不开它。而且sysstat可以通过cron采集历史性能数据事后回溯时直接看sar的历史文件就行我建议装完之后确认一下sysstat的cron任务存在有些版本安装后默认就带有些需要手动启用。5. 常见问题与排查技巧实录5.1 脚本一执行就报错set -e把脚本“卡死”了很多人第一次用set -e写脚本会碰上一个头号问题某条命令偶尔返回非0脚本直接退出但这条命令的退出码其实“不影响大局”。比如grep查不到匹配项会返回1if判断里用到没问题但放在普通语句里就会触发退出。这个问题的核心是set -e的粒度是整个脚本它不会区分“你介意不介意”某条命令的失败。解决办法有两个方向。第一如果这条命令的失败确实无所谓可以在命令末尾加上|| true告诉bash“这条命令失败也行不用退出”。第二如果这条命令的失败需要特殊处理就用if grep ...; then的写法把它放在条件判断语境中set -e就不会拦了。实际编写过程中我会坚持“该严格的地方严格该放行的地方明确放行”的原则。每写一条可能返回非0的命令都先想一想这条命令失败我要不要继续然后选择对应的写法。5.2 脚本中途失败修复后重跑却报“已存在”这个问题我在没有做幂等性设计之前经常遇到。比如脚本执行到创建用户那一步因为密码策略设置失败退出了你修复问题后重新执行整个脚本结果用户创建那步提示用户已存在。如果没有对应的跳过逻辑脚本就卡在那里。后来我把所有“可能被重复执行”的操作都加上了存在性判断。不仅是用户还包括目录、文件、软链接、cron任务等。实践中比较省事的写法是写一个公共函数比如ensure_user_exists、ensure_line_in_file然后在多个需要重复执行的场景中复用同一个逻辑既减少了重复代码也降低了漏加判断的概率。5.3 时区配置生效了但日志时间还是不对这个问题比较隐蔽。有可能你设置了时区应用的日志时间也对了但cron计划任务的时间还显示UTC或者某些服务比如通过docker运行的应用的时间不对。排查cron的时间要先确认rsyslog或者cron服务是否重启过。一些系统组件在时区变更后需要重启相关服务或者至少重启cron否则它们缓存的时区信息不会刷新。另外如果你用容器部署应用宿主机的时区变更不会自动同步到正在运行的容器里需要重建容器或者挂载/etc/localtime。我在实际执行初始化脚本时设置完时区后会顺手重启一下rsyslog和相关服务并在脚本末尾验证date命令输出date date -u两个输出对比一下就能直观确认时区是否正确生效。5.4 内核参数调整后sysctl -p没有报错但实际没生效sysctl -p加载完配置没有报错看起来一切正常但用sysctl -a查看某一个具体参数时发现还是旧值。这种情况大概率是配置写在了/etc/sysctl.conf里但同时还有/etc/sysctl.d/目录下的其他配置文件后加载的配置覆盖了你新写的值。系统加载sysctl配置文件的顺序是先/etc/sysctl.d/下的文件再/etc/sysctl.conf。如果在/etc/sysctl.d/里已经有别人或者发行版默认设置过同样的参数你的值就会被覆盖。解决方法是不要只改/etc/sysctl.conf直接在/etc/sysctl.d/下新建一个独立配置文件比如/etc/sysctl.d/99-custom.conf这个数字前缀决定了加载顺序数字大的后加载优先级更高echo fs.file-max 65535 /etc/sysctl.d/99-custom.conf sysctl --systemsysctl --system是systemd系统下推荐的加载方式会按顺序处理所有配置文件。老一点的初始化脚本喜欢用sysctl -p它默认只读取/etc/sysctl.conf在新系统上容易漏掉sysctl.d目录下的配置这也是排障时需要注意的坑。5.5 软件源替换后执行update报错提示“仓库没有有效的发布文件”这个报错常见于替换源之后没有清理原仓库的元数据缓存或者源文件里残留了不存在的仓库路径。处理方式apt clean apt update如果还不行检查sources.list或者sources.list.d里的内容确认没有多余的、指向已失效仓库的配置。CentOS系要注意有些第三方仓库比如EPEL需要额外安装epel-release包才能使用。替换源时如果直接把EPEL源里的地址也改掉很容易因为版本不匹配导致元数据拉取失败。5.6 SSH配置改坏了远程连接可能直接断开这个问题我前面提过但值得再强调一次因为它真的很容易出事。修改SSH配置之前一定要先备份。修改完之后先执行sshd -t这条命令只做语法检查不会影响现有连接。检查通过再重启sshd服务。还有一个更稳妥的“防踢”技巧重启sshd之前先开一个临时的第二个SSH连接保持不断开然后在另一个会话里执行重启。如果配置真的有问题第二个连接还在你还能通过它救回来。6. 初始化脚本的扩展思路与维护建议到这里一套系统初始化脚本的核心内容已经完整了。但这还不是终点。实际运行一段时间后你会发现初始化脚本不可能只用一次就不管了它需要持续维护和扩展。比如你的脚本跑完后后续运维中可能会遇到新需求某台机器需要额外装显卡驱动某台机器要配置RDMA网卡某台机器要加入公司统一的监控体系安装agent、配置上报地址。这些需求本质上也是“系统初始化”的一部分只是它们不是所有机器都适用。我的处理办法是把这些做成“可选模块”放在主脚本里通过参数控制./init_system.sh --standard --with-monitor-agent --with-gpu主脚本跑完标准初始化之后再调用对应的可选模块脚本。这样既保持通用流程的一致性又能适应不同机器的个性化需求。本质上是把“全量初始化”和“按需初始化”结合到一起。维护方面我的一条心得是脚本必须纳入版本管理不要靠服务器上保存的“最终版”来维护。Git仓库里放一份主分支任何修改先在测试机跑一遍确认没问题再更新到仓库。换了一台新机器从仓库拉最新版再跑就不会出现“这台机器的脚本是旧版、那台是新版”这种混乱情况。另外脚本的注释和文档也很重要。不管是自己还是同事几个月后再看这个脚本如果每段代码前面都有一两行注释说明“这段在做什么、为什么这么写”维护成本会低很多。我习惯在脚本头部写一段完整的说明包括脚本用途、使用方式、支持的系统版本、注意事项等。这不是形式主义是给未来的自己留的方便。7. 写在最后的几条个人经验这套初始化脚本的思路和实现我前后打磨了很长时间在不同发行版CentOS、Ubuntu、Debian以及一些国产系统上都跑过。过程中踩过的坑远比文章里列出来的多。有几条经验我一直记在笔记里也分享出来。第一初始化脚本不要追求“一步到位”。重要系统做变更前先在测试机或者低风险机器上跑一遍观察有没有异常报错确认无误后再推到生产环境。初始化脚本也一样它虽然只是基础配置但配置错了同样会造成大麻烦。第二每跑完一台机器的初始化建议留存一份完整的日志和配置摘要。日志里有执行过程中所有的输出配置摘要是这台机器最终的主机名、时区、用户、关键路径等。后面排查问题时这些记录能帮你快速定位“这台机器当时是这么配的”。第三尽量保持脚本的通用性把跟具体环境相关的内容都通过变量或者配置文件注入而不是直接写死在脚本正文里。团队大了、机器多了之后你不可能每次都记得“这台机器需要特殊一点”标准化的通用脚本配合按需的扩展模块才是可持续的方案。最后想说的是系统初始化脚本只是基础它解决的是“从系统装好到可以交付”这一段的问题。真正提升运维效率的下一个阶段是配置管理工具和自动化运维平台。但即使你之后会上Ansible、上CMDB一个逻辑清晰、经验沉淀完整的初始化脚本仍然是你理解系统细节和积累运维经验的重要起点。别小看它也别觉得它过时。把这一步做扎实了后面怎么自动化都不会吃亏。