
2. 部署前的整体规划与版本特性1.1 RHEL 9.7 不只是一个“小版本”不少团队在选服务器操作系统时会在RHEL9.7和它的各种免费衍生发行版之间反复横跳。先说结论RHEL 9.7在Red Hat 9系里属于维护成熟的里程碑版本内核稳定、工具链齐全对数据库、虚拟化、容器这类常见生产负载的支持都比较到位。虽然Red Hat的版本节奏是每年出一个minor版本9.7不会像8.0到9.0那样推倒重来但它持续合入了对新硬件平台的支持尤其是新一代至强处理器、DDR5内存以及部分网卡和NVMe控制器老内核跑在这些设备上容易出现识别不全或者性能无法发挥的问题。这代系统在安全加密策略上也更严格OpenSSL和加密默认策略都做了收紧很多老环境的弱加密算法在默认配置下会被直接拒绝。对做合规和等保的人来说这种默认安全策略反而是省心的事不用自己再额外加固一层。容器工具链方面podman、buildah、skopeo这些Red Hat主推的容器工具链版本也整体上移了对于准备从Docker向系统原生容器方案迁移的环境来说9.7是个合适的起点。但这篇文章不准备讲官方文档里已经写明白的概览介绍我只讲实际部署一台RHEL9.7服务器时怎么规划分区、怎么最小化安装、怎么调内核参数以及我在生产环境和测试环境里踩过的那些坑。无论是刚接触RHEL的新手还是已经运维过CentOS 7要往9系迁移的老手照着这个流程走一遍基本能把系统装得干净、跑得稳。1.2 硬件选型与分区规划需要想清楚什么部署之前最花时间的不是下载镜像而是想清楚这台机器要跑什么业务。如果是一台通用业务服务器我建议硬件选型按“未来三年不焦虑”的思路来CPU核心数宁可多配几个内存比当前峰值需求多出50%到100%系统盘用两块SSD做RAID1数据盘按业务量评估后再决定。因为RHEL 9.7对硬件的要求其实不高但一旦上线后再扩硬件往往比最开始多花几倍时间。分区规划是部署前的重头戏。RHEL9.7默认采用LVM管理磁盘这几乎是必须的选择因为LVM可以在线扩容逻辑卷不用卸载分区。我通常在一台物理机上这么分挂载点容量文件系统说明/boot1GBxfs引导分区不需要太大/60GBxfs系统根分区给系统和日志留足空间/var40GBxfs软件包缓存、临时文件和容器数据/var/log20GBxfs单独分出来防止日志写满根分区/home30GBxfs如果用户目录用得少可以更小swap8GBswap视内存大小调整下文会细说/data剩余空间xfs业务数据单独挂载方便做快照和备份很多习惯CentOS 6时代“swap分内存1.5倍”的老运维到了RHEL9.7还在分出96GB swap这完全没有必要。现代物理服务器内存动辄64GB起步kswapd在绝大多数时间都不会触发。swap的作用是兜底和休眠内存转储不是用来替代物理内存的。我一般按这个原则计算内存小于16GBswap分8GB内存16GB到64GBswap分8GB到16GB内存超过64GBswap分16GB就够甚至某些数据库专用机可以只留4GB前提是服务器有可靠的监控和告警。分区时还有一个容易被忽略的点/boot分区在UEFI引导模式下会自动创建EFI分区这部分大小建议给够512MB到1GB。以前遇到过/boot分区只有200MB结果更新了几次内核后旧内核没来得及清理直接导致无法升级非常尴尬。1.3 安装方式单台用U盘批量用PXE单台机器的安装选择U盘启动最直接。制作RHEL9.7启动盘在Linux环境里用dd写入速度最快Windows环境下用Rufus或balenaEtcher都行。dd命令也很简单dd if/rhel-9.7-x86_64-dvd.iso of/dev/sdb bs4M statusprogress注意这里of指定的是磁盘设备不是分区比如/dev/sdb不能写成/dev/sdb1否则做出来的U盘无法引导。如果是机房上架多台机器手工安装的效率就太低了。采用PXE加Kickstart批量部署是生产环境的标准做法这也是我在有几十台机器需要初始化时的首选方案。Kickstart文件核心是定义一个无人值守的安装流程下面给一个简化但实际的ks.cfg片段lang en_US.UTF-8 keyboard us timezone Asia/Shanghai --utc url --urlhttp://pxe-server/rhel9.7/ clearpart --all --initlabel part /boot --fstypexfs --size1024 part pv.01 --size1 --grow volgroup vg_system pv.01 logvol / --fstypexfs --size61440 --nameroot logvol /var --fstypexfs --size40960 --namevar logvol swap --fstypeswap --size8192 --nameswap %packages core %end这个文件中值得注意的几个字段一个是url指向安装源的地址这里是用HTTP方式提供安装源另一个是logvol swap --size8192把swap固定成了8GB。Kickstart的好处是批量部署时所有机器的分区、软件包、网络配置完全一致减少手工操作带来的随机性后续再用Ansible补差异配置就行。3. 最小化安装与基础配置2.1 安装过程中的关键选项决定后续维护成本RHEL9.7安装界面里的软件选择我会毫不犹豫地选“最小化安装”Minimal Install。很多新手习惯在安装时勾选图形界面和一堆开发工具装完系统占了十几个GB磁盘里面至少一半的服务根本没用到。最小化安装完成后系统只占2GB左右磁盘干净、启动快、被攻击面也小。后面缺什么工具再用dnf按需安装这是最符合服务器运维习惯的做法。磁盘分区的“自定义”选项里安装器会自动创建一个LVM卷组默认把根分区和swap都建好。我通常会在这一步把根分区大小改到60GB把/var/log单独拆出来把swap调整到自己预期的大小。安装界面里操作过一次之后整个分区结构就固定下来了所以这一步千万不要偷懒点“自动配置”。网络和主机名的设置在安装界面就要写对。服务器不像笔记本装完系统后再用NetworkManager图形工具改IP虽然不难但在纯命令行环境下没有网的人容易陷入死循环。主机名、静态IP、网关、DNS这些信息在安装阶段一并填好装完重启后直接就能远程登录。这一步省下的时间至少是半小时起步。root密码设置完成后我强烈建议立刻创建第一个普通运维账号。因为运维过程中的绝大多数操作都应该用普通账号加sudo完成而不是直接登录root。在安装界面可以顺手把这个账号建好省得装完系统后再去useradd。2.2 网络与软件源的配置细节安装完成后的第一件事是确认网络能通。RHEL9.x的网口命名默认走systemd的规则可能是ens3、ens192这类名字而不是老的eth0。配置静态IP最推荐的方式是用nmcli这个工具是命令行环境下一等公民写成脚本也不用担心图形界面依赖nmcli con mod ens3 ipv4.addresses 192.168.10.20/24 nmcli con mod ens3 ipv4.gateway 192.168.10.1 nmcli con mod ens3 ipv4.dns 192.168.10.1 192.168.10.2 nmcli con mod ens3 ipv4.method manual nmcli con up ens3这里把IP地址、网关、DNS一次配置到位最后up一下连接生效。如果你习惯传统方式也可以直接改/etc/sysconfig/network-scripts/ifcfg-ens3但RHEL9已经默认不推荐这种方式改完还要用nmcli重新加载远不如nmcli直接。软件源的配置是很多新手最容易卡住的地方。如果你用的是RHEL官方订阅第一步需要注册并启用订阅subscription-manager register --username 你的账号 --auto-attach这会把官方源自动配置好。如果公司暂时没有订阅而是使用CentOS Stream、Rocky Linux、AlmaLinux这些与RHEL兼容的发行版需要对应配置各自的镜像源。实际操作中很多团队核心诉求是“能安装软件包”这时候我一般建议在系统安装前就确认好可用的软件源类型避免装完系统后到处找源。dnf命令在RHEL9.7里是包管理的核心几个高频操作需要熟练掌握dnf history # 查看历史操作回滚时非常有用 dnf install vim tmux htop sysstat lsof # 安装常用工具 dnf upgrade # 升级系统包 dnf clean all # 清理缓存启用EPEL源也是必不可少的一步Red Hat软件源里不包含很多常用软件包EPEL作为Fedora社区维护的扩展源会把大量额外的工具包补全。安装命令dnf install epel-release2.3 安装完成后立刻要做的基础优化清单系统刚装完一小时内应该把这些基础优化做完。先看两行基本信息cat /etc/redhat-release uname -r确认系统版本和内核版本然后把时间同步服务拉起来。RHEL9.x默认使用chronyd启动后确认状态systemctl enable --now chronyd timedatectl如果发现时区不对用timedatectl set-timezone Asia/Shanghai修正。这一步不及时做后面日志时间对不上排查问题会非常痛苦。创建运维账号和配置SSH安全是接下来最值得做的两件事。先创建具备sudo权限的账号RHEL里直接把用户加入wheel组即可useradd -G wheel ops passwd ops然后检查/etc/ssh/sshd_config确保最关键的两项配置PermitRootLogin no PasswordAuthentication no但这里有个顺序问题如果你之前没有把公钥写入到新账号的authorized_keys文件里直接关掉密码登录会让你自己都进不去。所以正确步骤是先给ops账号配置好密钥登录确认能通过ops登录后再修改SSH配置。密钥配置的具体操作我在安全部分详细展开。4. 系统性能优化与内核调优3.1 内核参数优化的思路与核心参数计算RHEL9.7默认的内核参数不是“错的”而是为了兼容各种场景做了折中。真实业务跑起来之后默认值在并发连接数、文件句柄数、内存回收策略等方面不一定匹配当前工作负载这时候需要手动调整。内核参数配置文件有两种习惯直接改/etc/sysctl.conf或者在/etc/sysctl.d/下建独立文件。我推荐后者因为可以按用途拆分成不同文件比如99-sysctl.conf用来放自己调整的参数和系统自带参数隔离升级系统时也方便管理。我常用的调优配置放在/etc/sysctl.d/99-sysctl.conf中下面是一份经过多轮生产验证的base配置适用于普通业务服务器和Web应用服务器vm.swappiness10 vm.dirty_ratio30 vm.dirty_background_ratio5 fs.file-max2097152 net.core.somaxconn1024 net.core.netdev_max_backlog65536 net.ipv4.tcp_max_syn_backlog65536逐个解释这些参数的含义和依据。vm.swappiness10控制系统在内存压力下使用swap的积极程度默认值是30。设成10意味着系统只有在内存接近耗尽时才会换页减少不必要的磁盘写入但不建议设成0因为某些边缘情况下内核需要一点swap空间来做内存回收的缓冲。vm.dirty_ratio30和vm.dirty_background_ratio5是配对使用的。当内存中脏页待写回磁盘的数据达到总内存30%时内核会强制同步写回当脏页达到5%时后台开始异步写回。这两个值组合起来的效果是允许更多内存暂时存放写缓存批量写入场景下性能提升明显。但是要注意如果这台机器没有配备带电池保护的RAID缓存断电丢失数据的风险窗口会变大。对普通SSD来说这两个值相对偏大可以按dirty_ratio15配dirty_background_ratio5来折中。文件句柄数的配置计算有一个简单逻辑假设一台Web服务器同时处理5000个并发连接每个连接至少占用一个fd系统本身还要消耗几百个fd加上日志、监控等保守估计峰值在10000左右。fs.file-max2097152设置成200万冗余度非常大基本不会因为系统级fd限制出问题。但光改系统级参数还不够还需要配合进程级的ulimit -n设置。在/etc/security/limits.conf中加两行* soft nofile 1048576 * hard nofile 1048576这样普通用户进程的单进程fd上限就到了100万如果某个应用确实需要更高可以单独对其调整。网络栈参数里net.core.somaxconn1024提高系统级accept队列长度net.ipv4.tcp_max_syn_backlog65536提高半连接队列长度这两个值在短连接高并发场景下作用明显比如Nginx或Spring Boot应用前面有大量瞬时请求时不会因为默认队列太短直接丢弃连接。参数修改后执行sysctl -p /etc/sysctl.d/99-sysctl.conf使其生效。实际操作中不要一次性把几十个参数全改掉应该先改几个关键的观察几天再决定下一步否则出了问题也不知道是哪个参数导致的。3.2 文件系统与存储配置优化RHEL9.7默认文件系统是XFS这是Red Hat的默认选择XFS在超大文件、高并发写入和大分区支持上比ext4更有优势。我的建议是数据盘也统一采用XFS除非你有非常老的遗留数据盘还是ext4格式那另说。挂载参数的重点是noatime。Linux默认在每次文件被读取时都会更新atime访问时间这会导致产生大量无意义的写操作。对于大多数业务场景我们根本不需要关注文件最后访问时间加上noatime可以显著减少磁盘写放大。在/etc/fstab中这样配/dev/mapper/vg_system-root / xfs defaults,noatime 0 0 /dev/vg_system/data /data xfs defaults,noatime 0 0通过临时挂载检查当前生效参数可以用mount | grep noatime确认。存储部分的另一个重点是NVMe设备的IO调度器。传统机械硬盘需要电梯算法来优化寻道所以用mq-deadline比较合适而NVMe固态盘寻址时间极短根本不需要调度算法。在RHEL9中NVMe默认已经是none这在较新内核里就是noop的意思。但如果你接入的是老旧型号的NVMe控制器内核版本没有正确识别也可以通过udev规则统一指定在/etc/udev/rules.d/60-io-scheduler.rules中写入ACTIONadd|change, KERNELnvme*, ATTR{queue/scheduler}none ACTIONadd|change, KERNELsd*, ATTR{queue/rotational}1, ATTR{queue/scheduler}mq-deadline第二条规则把机械硬盘rotational为1的块设备设为mq-deadlineSSDrotational为0默认就是none这样配置完所有磁盘的调度器就都符合各自介质的特性了。swap的优化在RHEL9.7中还需要考虑是否启用swapfile。安装器默认创建的是LVM swap逻辑卷需要调整大小时得用lvreduce和lvresize用起来有点绕。如果是在云服务器上我推荐直接在数据盘上创建一个swapfile比如8GB的swap文件fallocate -l 8G /data/swapfile chmod 600 /data/swapfile mkswap /data/swapfile swapon /data/swapfile然后写入/etc/fstab/data/swapfile swap swap defaults 0 0采用swapfile的好处是大小调整灵活不需要动分区结构。物理机上如果你已经建好了LVM swap就不用再折腾了。3.3 服务管理优化与进程资源控制系统装完最小化安装后其实已经没有太多多余服务但有一些默认启动的服务仍然可以按业务情况禁用。比如如果不用打印服务cups.service可以关掉systemctl disable --now cups.service systemctl disable --now avahi-daemon.serviceavahi-daemon是mDNS/DNS-SD协议实现对大多数服务器没有意义关掉还能减少一些不必要的局域网广播。启动耗时的检查是一个被很多人忽略的优化。systemd-analyze blame可以列出每个单元的启动耗时按顺序排查耗时最长的服务。有一次我发现某台新机器启动时间到了90多秒追查发现是某个服务在等一块长期掉线的网络磁盘。把无关的服务禁用后启动时间直接降到20秒以内这种优化虽然不影响运行性能但每次重启能省一分钟在批量发布场景下也是实打实的时间成本。针对CPU密集型服务systemd的CPUAffinity可以用来绑定CPU核心。比如一台32核服务器业务进程只需要用到6到7核这时可以创建覆盖文件限定进程的CPU亲和性在/etc/systemd/system/business.service.d/override.conf中写[Service] CPUAffinity2-7 IOWeight0IOWeight0表示这个服务在系统IO调度中的权重最低意思是就算它在疯狂读写磁盘也不会拿去抢数据库等核心服务的IO带宽。这个技巧在处理业务进程与数据库共存一台物理机的场景下非常实用。RHEL9自带tuned-adm工具性能调优时建议直接启用它。这个工具会根据服务器负载类型自动调整一组参数覆盖CPU governor、磁盘调度器、透明大页等。选择profile的方法tuned-adm profile throughput-performancethroughput-performance偏吞吐量会把CPU governor设为performance减少节能状态latency-performance则侧重降低延迟适合需要极短响应时间的业务。在这两个profile之间切换后可以用tuned-adm active确认当前生效的配置用tuned-adm recommend查看根据系统识别推荐选择的配置。5. 安全加固与日常运维4.1 SELinux与防火墙不要一上来就关闭很多从CentOS 6时代过来的运维看到SELinux的第一反应是setenforce 0然后改配置永久关闭。这个习惯在RHEL9.7上非常危险一方面系统默认的很多服务已经依赖SELinux策略特别是容器、Apache、数据库等另一方面等保合规检查中对SELinux的状态也会有要求。SELinux的正确用法是理解它的核心逻辑进程只能访问被标签标记为允许的内容。很多时候我们遇到“权限拒绝”的问题并不是Linux文件权限的问题而是文件的安全上下文标签不对。比如把一个网站根目录放在了/data/web下发现Apache始终无法读取文件这时候就检查标签ls -Z /data/web如果是default_t类型执行semanage fcontext -a -t httpd_sys_content_t /data/web(/.*)? restorecon -Rv /data/webrestorecon的作用是把实际的文件标签调整到策略规定的标签上semanage负责把这个规则保存进持久化配置重启后依然有效。处理完后再访问权限问题就消失了。防火墙方面RHEL9.7依旧用firewalld。常见操作是放行端口firewall-cmd --permanent --add-servicehttp firewall-cmd --permanent --add-port8080/tcp firewall-cmd --reload但更精细的需求是限制来源IP比如数据库端口3306只对内网网段开放可以用rich rulefirewall-cmd --permanent --add-rich-rulerule familyipv4 source address192.168.0.0/16 port port3306 protocoltcp accept firewall-cmd --reload如果不加source地址等于任何机器都能尝试连MySQL这是一件非常危险的事情。SSH的安全加固是重中之重。在修改sshd_config之前首先确保已经配置好了密钥登录。用ed25519算法生成密钥对是现代默认选择它比RSA更短、更快安全性也不弱ssh-keygen -t ed25519然后把公钥安装到目标服务器的ops账号下ssh-copy-id ops192.168.10.20或者手动追加公钥到~/.ssh/authorized_keys最后设置目录权限chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys完成之后修改/etc/ssh/sshd_config把PermitRootLogin no和PasswordAuthentication no设置为yes后注释取消这里其实是改为no即禁止root密码登录、禁止密码登录然后重启sshd服务systemctl restart sshd重启之前一定不要关掉当前SSH窗口万一配置出错还能回去。建议先把配置写入后用sshd -t做一次语法检查没问题再重启。4.2 账户与密码策略的落地账户安全在RHEL9.7上的配置点多但核心是密码策略、过期策略和登录限制。密码复杂度配置在/etc/security/pwquality.conf中去掉注释后修改minlen 14 dcredit -1 ucredit -1 lcredit -1 ocredit -1这里minlen14表示密码最短14位那四个credit-1分别要求至少包含一个数字、一个大写字母、一个小写字母和一个特殊字符。这些策略对运维人员的密码习惯是有约束力的但对爆破攻击的抵抗力提升非常明显。密码过期策略通过chage控制。比如要求每90天改一次密码提前7天提醒chage -M 90 -W 7 ops查看某用户当前的密码策略使用chage -l ops。这个策略虽然简单但在公司内部如果有多个人共管一台机器定期改密码的需求是真实存在的。登录失败限制我建议用sshd的额外防护来弥补最简单的做法是设置MaxAuthTries 4在sshd_config文件中限制单次连接尝试登录次数。如果公司有集中的堡垒机或跳板机建议把RHEL的SSH访问限制到只有堡垒机来源IP可以连这一步能大幅降低被爆破的暴露面。4.3 日志、监控与日常巡检journald日志如果不加限制长时间运行的服务器日志会一直增长。配置一个最大上限非常必要。创建/etc/systemd/journald.conf.d/10-size.conf[Journal] SystemMaxUse2G然后重启journald服务systemctl restart systemd-journald如果公司没有集中的日志收集这台服务器的日志就存在本地2G通常能覆盖数周到数月具体取决于日志量。有条件的建议配置rsyslog远程转发把日志汇总到日志服务器统一分析但这就涉及更复杂的方案部署不在这里展开。监控方面RHEL9自带cockpit这是个轻量级的Web管理界面。安装和启用dnf install cockpit cockpit-storaged systemctl enable --now cockpit.socket firewall-cmd --add-servicecockpit firewall-cmd --permanent --add-servicecockpit firewall-cmd --reload然后浏览器打开https://服务器IP:9090登录可以看到系统资源、磁盘、日志、更新提醒也能管理服务单元。cockpit比较适合小规模环境和日常巡检但在生产环境需要更细致的指标告警时还是建议上Prometheus加node_exporter这套组合采集到指标数据后接入告警实现秒级发现问题。日常巡检的命令习惯我认为可以固化成一套命令uptime free -h df -h iostat -x 1 3 ss -lntup journalctl -p err -b前四个命令看负载、内存、磁盘、IO后面两个看端口和系统错误日志。这套组合每天早上扫一眼基本能在用户发现故障之前提前定位问题。6. 常见问题与踩坑记录5.1 安装与启动问题用U盘安装RHEL9.7遇到的第一个坑是启动界面进不去安装程序。制作好启动盘后机器启动黑屏或者卡在引导界面通常有两个原因。第一是U盘没有被正确识别为启动设备直接在BIOS里把启动项调整后重试即可第二个常见原因是显卡驱动问题。在启动菜单按e编辑内核参数在linux那一行末尾追加nomodeset可以绕过KMS驱动加载避免黑屏。装完系统后有时候会出现GRUB引导丢失的情况比如服务器重启后卡在grub提示符。这种情况通常需要用安装镜像的救援模式修复。进入救援模式后执行chroot /mnt/sysimage grub2-mkconfig -o /boot/grub2/grub.cfg grub2-install /dev/sda/dev/sda换成实际系统盘这里需要注意的是UEFI模式的服务器还要确认EFI分区已经挂载到/boot/efi下。这个坑多发生在新机器迁移或磁盘控制器调整之后。5.2 性能调优中的经典失误调优时最容易犯的错误是从网上复制一大段sysctl参数直接全上然后系统变得不稳定。我自己就见过有人把net.ipv4.tcp_tw_reuse1直接套到RHEL9.7上结果连接池出现大量复用后的错乱日志里全是异常连接。这类奇技淫巧在旧内核上有一定道理但在新环境中反而会引入新问题。调优的正确顺序是先明确业务指标再看监控数据最后修改参数每个参数改动后至少观察24小时。另一个我踩过几次的坑是修改/etc/fstab后重启进入emergency mode。比如新增了一个挂载点但分区的UUID写错了系统无法挂载该分区直接拒绝启动。遇到这种情况不要慌输入root密码后在救援环境里用vim /etc/fstab检查错误行把它注释掉然后systemctl daemon-reload重启即可。现代Linux对fstab中的挂载异常容忍度很低宁可多花一分钟检查也不要凭记忆随便写磁盘路径。tuned-adm的性能profile选择也是一个容易出问题的地方。比如一台业务数据库服务器如果误选了latency-performanceCPU governor会被锁定到performance模式整机功耗上升却不见得业务延迟下降多少。应该先用tuned-adm recommend看看系统推荐的profile再根据业务场景做切换测试找到最适合的组合。5.3 版本升级与回滚策略RHEL9.7发布后不急于当天升级对于生产系统我建议至少等一到两周。升级前的检查命令dnf check-update然后看一下本次更新涉及哪些包特别关注内核、glibc、openssl这些关键组件。升级操作执行dnf upgrade升级完成后系统会提示需要重启。如果升级后出现异常dnf的history功能可以回滚dnf history dnf history undo transaction-id不过回滚也不是万能药尤其是跨小版本升级后配置文件和数据文件可能已经变化这时最可靠的恢复手段还是升级前的快照和备份。内核更新后旧内核会保留在/boot目录下重启时可以从GRUB菜单选择旧版内核进入这是天然的回退机制。建议在生产环境保留最近1到2个旧内核别因为/boot空间不足就把旧内核全删了。备份工具方面Red Hat官方推荐用rearRelax-and-Recover做裸机恢复。RHEL9.7安装reardnf install rear rear -v mkbackup它会生成一个可引导的恢复镜像保存系统布局和文件在机器损坏后可以快速恢复到新的硬件上。这一套备份策略建议在一台新机器上线前就配置好而不是等出问题再补。7. 最后再说两句我自己在实际操作中的体验是RHEL9.7这个版本已经足够成熟最怕的不是系统本身的问题而是部署前没想清楚分区规划、软件源和备份策略。只要这三个方向想明白后面基本是水到渠成的事情。从CentOS 7迁过来的人最需要适应的是不再有一个能免费无限期使用的发布版而是应该把注意力放在自动化和配置管理上。最后再分享一个小技巧第一次把系统调优到满意状态后把你执行过的所有配置、sysctl参数、fstab修改、SELinux标签规则整理成一份可执行的Shell脚本或Ansible playbook。这样不只是为了以后批量复制更重要的是半年后接手的人不用靠猜就能知道你在这台机器上改了什么。把这套脚本放进Git仓库每次变更都提交一次等需要复盘时你会感谢当时的自己。