这几年做信创运维最深的感触就是这一行不再是把 Windows 换成麒麟、把 Intel 换成鲲鹏那么简单了。国产化替代走到深水区运维工程师面对的是完全异构的底层架构、不成熟的软件生态以及比传统环境更严苛的安全合规要求。这篇文章我想把实际工作中沉淀下来的系统优化思路和安全防护手段整理出来重点聊聊那些常规文档里不会写的细节希望能给正在做信创适配或者准备转信创运维的朋友一些参考。1. 信创运维的底层逻辑先搞懂国产化环境的“脾性”1.1 信创运维和传统 x86 运维到底差在哪很多人以为信创运维就是把原来跑在 Windows 上的操作习惯搬过来换几个命令而已。实际做过才知道这两者之间的差距比想象中大得多。传统 x86 环境下Intel/AMD 的指令集高度统一底层硬件抽象层做得非常成熟数据库、中间件、业务系统基本都是“装上就能跑”。操作系统层面Windows 和主流 Linux 发行版在驱动适配、内核稳定性、软件兼容性上已经打磨了十几年运维的核心工作是监控、调优、故障排查——一切建立在稳定的基础设施之上。信创环境恰恰相反。它的“不稳定”主要体现在三个层面第一CPU 指令集分叉严重。鲲鹏基于 ARM 架构飞腾也是 ARM但海光走的是 x86 路线兆芯兼容 x86龙芯是自己的 LoongArch。这意味着同一套软件在不同芯片平台上可能需要重新编译甚至部分依赖库都不存在。一个在内网跑得好好的 Java 应用迁移到鲲鹏上可能因为缺少 ARM 版 native 库直接起不来。第二操作系统版本碎片化。统信 UOS、麒麟银河麒麟、中标麒麟已经合并、openEuler 衍生版底层都是 Linux 内核但服务管理方式、默认安全策略、软件源管理各有差异。更麻烦的是很多单位内部还有 CentOS、Ubuntu 混用的情况一个运维要同时维护三四套发行版命令兼容性是个大问题。第三软件生态成熟度不足。比如某些国产数据库对标准 SQL 的支持不够完整迁移后个别存储过程要重写办公套件WPS、永中的文件兼容存在细微差异甚至一些基础的运维工具比如备份软件、监控 agent在国产平台上没有官方版本需要自己编译。所以信创运维的第一个核心能力不是会用某个命令而是理解异构——知道你的环境里有哪几种芯片、哪几套系统、哪些软件跑在什么底座上才能针对性地制定优化和防护方案。1.2 信创环境常见的硬件与软件组合接触过的信创项目里最典型的硬件组合大概是这几类鲲鹏 920/930 系列服务器配麒麟 V10 或 openEuler飞腾 FT-2000/S2500 配麒麟 V10 SP1 或 UOS 服务器版海光 7000 系列配麒麟 V10、UOS甚至还有配 CentOS很多单位还没完全切走龙芯 3A5000/6000 配 Loongnix 或麒麟。服务器之外终端环境更复杂。台式机、笔记本上跑着 UOS 家庭版/专业版、麒麟桌面版芯片涵盖兆芯、飞腾、龙芯、鲲鹏。政务单位还会出现“双网双模”的配置——一台终端同时接政务内网和互联网通过隔离卡切换。这种场景下运维不仅要管系统本身还要管双网隔离的安全性这在国内是特有的运维需求。我的建议是接手一套信创环境第一周不要急着做优化先把资产台账搞清楚每台设备的芯片型号、操作系统版本、内核版本uname -a、重要业务依赖的中间件版本、数据库版本、网络分区情况。这些信息全部记录在案后续所有优化和安全策略都基于这份台账来定。没有台账的优化就像盲人摸象。2. 系统优化实战从内核参数到磁盘 IO 的调优方案2.1 内核参数调优先看业务类型再动手很多人一上来就照着网上的“Linux 内核优化参数大全”抄把 vm.swappiness 改成 0net.core.somaxconn 改成 65535看似专业实则危险。信创环境尤其不能这么干因为国产芯片和操作系统的组合千差万别照搬 x86 的优化经验可能会带来负面效果。内核调优的正确姿势是先搞清楚业务的负载特征。如果是跑数据库达梦、人大金仓、GaussDB重点优化内存管理和磁盘 IO如果是跑 Web 服务东方通、金蝶天燕中间件重点优化网络栈和文件描述符如果是跑大数据组件Flink、Spark重点优化进程调度和内存分配。以最常见的数据库业务为例核心要调的参数有这么几个# 内存管理针对数据库类应用 vm.swappiness 10 vm.dirty_ratio 20 vm.dirty_background_ratio 5 # 文件系统 fs.aio-max-nr 1048576 fs.file-max 6815744 # 网络栈高并发连接场景 net.core.somaxconn 65535 net.ipv4.tcp_max_syn_backlog 65535 net.ipv4.ip_local_port_range 1024 65000需要注意vm.swappiness 不要照抄 0。很多文章推荐 0是为了让内存尽量不换页。但在国产 ARM 平台上内存访问延迟比 x86 高swap 设置过低可能导致内存回收不及时反而引发 OOM。实测下来数据库类应用设置 10 左右比较合适既保证内存利用率又保留一定的回收弹性。文件描述符上限也是排查“明明没宕机但应用连不上”的常见原因。修改方法有两个一个是在/etc/sysctl.conf里写死另一个是用 systemd 启动脚本的 LimitNOFILE 属性。注意优先改 systemd 侧的配置因为在 systemd 环境下/etc/security/limits.conf可能不生效——这个坑我踩过。2.2 存储与文件系统优化日志、数据库目录分开放信创服务器上存储设备参差不齐有的是 SSD有的是 SAS 机械盘还有的是传统 HDD 阵列。不同业务的数据落盘特征不同优化策略也要分开。最基础也是最有效的优化是把日志目录和数据库目录分开放。这个建议听起来土但实际效果立竿见影。数据库的随机读写和日志的顺序写入如果挤在同一块盘上会产生严重的 IO 竞争导致事务响应时间飙升。分开之后各自独占 IO 通道性能提升肉眼可见。具体操作上如果服务器有多块硬盘建议这样分区系统盘一块 SSD建议 240G 以上装操作系统、中间件、数据库程序数据盘一块或多块 SSD/HDD存放数据库数据文件、表空间日志盘一块 HDD 或小容量 SSD集中放 /var/log、应用日志、数据库归档日志没有条件分盘的至少要用 LVM 做逻辑卷隔离并用 ionice 为不同进程设置 IO 优先级。比如给数据库进程设置较高的 IO 优先级给备份任务设置较低的# 查看进程PID systemctl status mysqld # 设置IO优先级0-7数字越小优先级越高 ionice -p 1357 -c 2 -n 0文件系统层面信创平台主流用的是 ext4 和 xfs。数据库场景建议用 xfs它的并发写入能力和元数据操作性能比 ext4 好尤其在 ARM 平台上差距更明显。制作文件系统的时候记得加上ftype1参数xfs 默认开启避免后续 Docker 等容器服务运行时报 overlay 存储驱动不支持。2.3 服务与进程优化systemd 才是信创平台的主角国产操作系统全面采用 systemd 管理服务这个和 CentOS 7 以后的主流实践是一致的。但信创环境有个特殊情况很多从 Windows 迁移过来的业务组件aint 提供 systemd 服务文件只有一个可执行的 start.sh。运维人员图省事直接nohup ./start.sh 就跑了结果进程成了孤儿开机不自启崩溃不自愈。正确做法是写 systemd service 文件哪怕只是一个简单的 Java 应用也应该纳入 systemd 托管。一个标准的 service 文件长这样[Unit] DescriptionMy App Server Afternetwork.target mysql-server.service [Service] Typesimple Userappuser Groupappgroup WorkingDirectory/opt/myapp ExecStart/usr/bin/java -Xms4g -Xmx4g -jar myapp.jar Restarton-failure RestartSec5 LimitNOFILE65535 NoNewPrivilegestrue PrivateTmptrue [Install] WantedBymulti-user.target这段配置里几个要点值得注意。Restarton-failure只会在进程异常退出时自动拉起正常退出比如运维手动执行 systemctl stop不会触发重启比较安全。LimitNOFILE65535解决文件描述符不够的问题作用等同于 ulimit -n。NoNewPrivilegestrue和PrivateTmptrue是安全基线要求前者防止进程通过 setuid 提权后者隔离临时目录这些在等保测评里都会看。服务写好后要执行systemctl daemon-reload重新加载然后systemctl enable --now myapp设置开机自启。另外UOS 和麒麟自带的图形化管理工具比如 UOS 的“服务管理”实际上也是调用 systemd 的接口命令行习惯在信创环境里依然是最通用的路径。桌面运维给终端用户解释“为什么服务又挂了”用 systemctl status 截图比讲原理高效得多。2.4 终端性能优化让旧 PC 也能流畅跑国产系统终端优化是信创运维里最“接地气”的一块。很多单位的 PC 还是几年前的老配置内存 4G、机械硬盘装完 UOS 或麒麟桌面版之后卡顿明显用户的第一反应就是“国产系统不行”。实际上这一半是硬件问题另一半是优化没到位。在终端侧最有效的优化集中在三个方向释放内存压力。桌面版打开自带的软件包管理器把用不到的内置应用卸载掉比如一些游戏、非必要的办公组件。然后调整 swap 策略桌面环境可以适当提高 swappiness 到 30-60让系统在内存吃紧时敢于换页避免直接冻死。关闭无用的视觉效果。麒麟和 UOS 的桌面特效窗口动画、透明效果在 GPU 性能弱的环境下非常拖后腿。到“设置-通用-特效模式”切换为“普通模式”或“兼容模式”卡顿感会明显改善。这一步做完多数 PC 用户基本满意。启用 SSD 优化。如果终端是 SSD确认 TRIM 是否开启systemctl enable fstrim.timer systemctl start fstrim.timer这行命令让系统周期性执行 TRIM保证 SSD 长期不掉速。机械硬盘用户则要反过来关注磁盘碎片国产桌面系统的文件碎片问题比 Windows 更明显能用e4defrag对 ext4 分区做离线整理。终端优化不要过度核心目标是“让用户不吐槽”。完成基础优化后给标准化终端做一份 GHOST 或自定义镜像模板后续新终端直接批量克隆部署比一台台优化省时省力得多。3. 安全防护架构从等保合规到实战防御3.1 安全基线核查先把该做的检查项做完信创环境的安全防护起点是安全基线不是装一套杀毒软件就行。政务、金融、能源等行业的信创项目等保 2.0 三级测评基本是硬门槛测评之前自查越细后面整改越少。我按实际测评经验整理了一个核心检查项速查表可以参考着逐项核对检查项推荐配置说明账户策略密码最长有效期 90 天最少 8 位含数字大小写字母/etc/login.defs和 PAM 模块配合设置登录失败锁定连续 5 次失败锁定 15 分钟编辑/etc/pam.d/system-auth增加 tally2 或 faillock 模块远程管理限制仅允许指定 IP 段通过 SSH 登录修改/etc/ssh/sshd_config中 AllowUsers审计策略启用 auditd记录用户操作和关键文件变更systemctl enable auditd确认规则已加载服务最小化关闭不必要服务仅保留业务必须项systemctl list-unit-files --typeservice逐项过补丁管理操作系统和中间件补丁滞后不超过 3 个月麒麟/UOS 都有漏洞库对应工具日志留存本地日志留存 6 个月以上建议集中采集rsyslog 转发到日志服务器防病毒/EDR启用国产终端安全软件集中管理如深信服、奇安信、天融信的国产平台版本等保测评有个容易忽略的点所有设备的时间必须同步否则日志关联分析的时候完全对不上。在信创环境尤其重要因为国产系统的 NTP 配置各有差异。做法是搭一台内网 NTP 服务器用开源 chrony所有服务器和终端统一指向它同时把timedatectl set-ntp true确认在开。3.2 账号与权限管理默认密码必须改root 权限要收敛信创项目上线初期为了赶进度不少系统是用默认密码或简单密码比如Admin123、Kylin123跑起来的。这在互联网隔离的网络里问题不明显但信创环境通常还要对接政务网或行业专网一旦某个节点被突破横向移动很容易。账号管理的几条硬性纪律首次登录强制改密。利用chage -d 0 用户名让用户在下次登录时必须修改密码。清理万能账号。UOS 和麒麟在安装时可能创建了uos或kylin的超级用户如果业务不需要直接userdel -r uos删除。禁用 root 远程登录。在/etc/ssh/sshd_config设置PermitRootLogin no运维用普通用户登录后通过 sudo 提权。把 sudo 权限精细到命令级别比如运维只能执行systemctl restart nginx、tail -f /var/log/nginx/error.log等操作而不是无脑 ALL。最小权限原则不是口号。给应用单独建服务账号不共用 root 跑进程。这个前面 systemd 那段配置里已经演示了Userappuser 就是落实这一条。权限管理的本质是给攻击者增加横向移动的成本。即使一台机器被攻破没有 root 权限、没有全局通用密码攻击者很难在短时间内拿到内网其他机器的控制权。3.3 边界与终端防护端口管理、防火墙策略、外设管控防火墙是边界的第一道门但也是配置错误率最高的地方。信创服务器的防火墙策略我建议遵循“白名单制”——默认拒绝只放行业务端口和管理端口。不要图省事用firewall-cmd --add-port1-65535/tcp这种操作这在服务器上线时是原罪。比如一台跑东方通中间件的服务器对外只需要开放 8080 给负载均衡器管理只需要开放 22 给运维网段systemctl start firewalld systemctl enable firewalld # 添加白名单规则 firewall-cmd --permanent --add-rich-rulerule familyipv4 source address10.10.1.0/24 port port8080 protocoltcp accept firewall-cmd --permanent --add-rich-rulerule familyipv4 source address10.10.200.0/24 port port22 protocoltcp accept # 默认策略改为拒绝外部访问 firewall-cmd --permanent --set-default-zonedrop firewall-cmd --reload注意--set-default-zonedrop这一步。很多管理员保留了默认的 public 区域规则放过 8080 之后其他端口依然可以通过等于白设。设置为 drop 之后所有未放行的流量一律丢包简单粗暴但有效。终端外设管控是政务场景的高频需求。用户拿个 U 盘拷文件一插就是病毒入口。国产终端普遍有 TPM可信平台模块和统一安全管控软件建议启用“USB 存储只读”策略或者干脆禁用 USB 存储设备改为通过内网网盘传输文件。从用户反馈来看技术上没有任何障碍难的是“收回”用户的既有习惯。运维能做的是先把策略配好然后准备好“怎么申请例外”的流程文档。另外国产终端普遍预装的安全中心比如 UOS 安全中心、麒麟安全中心一定要利用起来而不要因为它“看起来简陋”就无视。这些工具调用的是系统底层的安全能力强制访问控制、应用沙箱配合统一管理平台可以做外设管控、软件安装白名单、外联探测完全是能打的。3.4 数据备份与业务连续性别等到宕机才想起备份信创环境里备份的重要性不亚于安全防护。很多单位在适配阶段根本顾不上备份觉得“先跑起来再说”结果某次配置变更把数据库搞坏了没有可恢复的备份只能从头重建业务中断长达数小时。这种教训一次就够。备份这件事我的建议是“分三层做”操作系统层服务器装好、所有调优参数定稿后用 LVM 快照或系统自带的备份工具如麒麟的“备份恢复”工具做一次全量镜像。后续每次大版本升级或内核参数大量调整之前再做一次快照。这个快照存在的意义是让你有“反悔”的资本。数据层数据库达梦、人大金仓、MySQL开启归档模式每日全量备份加每小时增量备份。备份文件必须复制到独立的备份服务器或存储上不能只存在本机——本机磁盘坏了备份一起没了等于白做。应用层配置文件、部署包、版本更新记录这类的“代码资产”统一放进 Git 仓库。国产系统上的应用迁移和回滚没有版本管理简直寸步难行。备份做完了一定要定期演练恢复。找个周末拿一台闲置机器把备份的数据库导一遍看看能不能起来、数据是不是完整。演练过一次你备份才真正有价值否则就只是一堆不知道能不能用的文件。4. 国产平台的常用运维命令与效率工具4.1 麒麟与 UOS 上最常用的命令集信创桌面和服务器底层是 Linux所以 Linux 常用命令体系完全适用但有几个细节需要特别注意查看系统版本不能用一条命令通吃。麒麟系常用cat /etc/kylin-release cat /etc/os-releaseUOS 系统cat /etc/os-version cat /etc/os-release如果混用了 openEulercat /etc/openEuler-release。养成先看 os-release 的习惯再根据版本决定后续命令这是信创运维的基本素质。软件安装命令要区分发行版系。麒麟 V10 和 UOS 基于 Debian用apt-get installopenEuler 系用yum/dnf。如果内部系统都是同一批到底还好就怕混用环境下记错命令。建议在每台机器上写个小脚本自动探测包管理器#!/bin/bash if command -v apt-get /dev/null; then echo Debian-based, use apt-get elif command -v dnf /dev/null; then echo RPM-based, use dnf fi日志查看路径有差异。系统日志一般在/var/log/messages麒麟或/var/log/syslogUOS 基于 Debian应用日志位置看中间件配置。查日志时先用ls /var/log/快速确认有哪些文件再决定 tail 哪个。国产服务器硬件信息查看比如确认芯片型号lscpu cat /proc/cpuinfo | grep model name | head -1 # 海光/兆芯可见CPU型号 cat /proc/cpuinfo | grep CPU part | head -1 # ARM芯片看这个字段 cat /proc/device-tree/model # 鲲鹏/飞腾整机型号这些命令组合一台服务器 30 秒内基本就能确认芯片和整机情况排查兼容性问题时非常高效。4.2 运维效率工具Ansible、监控、日志平台一网打尽信创环境普遍设备数量大几百台终端很常见逐台手工操作根本做不过来。自动化运维工具的选择要重点看对国产平台的兼容性。Ansible 在信创环境的表现相当不错。它基于 SSH对通信协议要求低Agentless 架构不用在被管理端装额外东西天然适合异构环境。写 playbook 做批量配置修改系统参数、推送 NTP 配置、设置安全基线、批量部署软件、批量巡检都能胜任。需要注意Ansible 控制端建议跑在 openEuler 或麒麟服务器上Python 版本选择 3.9 以上的兼容版本对 ARM 架构的机器控制端和被控制端之间的 SSH 协议参数可能需要微调比如网速不稳定的环境把 timeout 调大。另外从 Ansible 2.9 开始对 Python 3.8-3.10 支持良好在国产系统上直接用 pip 装即可不需要编译。监控方案推荐 Zabbix 或 Prometheus Grafana。Zabbix 对国产化适配做得比较早支持麒麟、UOS、openEuler开启自动发现规则后几百台设备半小时内就能完成初装。如果是新的信创项目建议直接用 Prometheus node_exporter Grafana 的组合轻量、云原生友好后续容器化演进不折腾。服务端装好之后一定把监控项覆盖这几块CPU 负载负载平均值和单核使用率、内存剩余量/OOM 次数、磁盘使用率和 IO 等待、网络流量和丢包率、关键服务状态systemd 服务是否 active。报警阈值按不同硬件配置分别设置比如 ARM 服务器 CPU 负载阈值普遍比 x86 低 20%-30%否则容易误报。日志平台国产系统处理日志的方式和传统 Linux 没有本质区别。rsyslog 转发到 Logstash/Elasticsearch或者用 Loki都是成熟路径。日志集中化除了满足等保审计要求更重要的是故障排查时能跨机器关联查询比如定位到某台终端异常外联的完整链路。4.3 终端的批量运维与远程协助技巧终端运维的日常是“人少事多”几十台 PC 同时报故障不可能挨个跑现场。把批量化做到位运维效率能提升一个量级。系统镜像与批量部署是最基础的。用 Clonezilla 或系统自带的部署工具把标准终端做完优化、装好必要软件之后做成镜像。新终端开机 PXE 网络引导十几分钟一台比逐台安装快一个数量级。注意不同芯片架构的镜像不能互刷鲲鹏的镜像刷到飞腾机器上起不来。远程协助工具如果内网部署了统一管理平台比如国产办公终端管理平台通常在管理后台直接发起远程桌面协助。没有平台的话可以用 VNC 或 RustDesk 自建。RustDesk 支持自建服务器内网环境下延迟低还支持跨平台Windows、Linux、国产系统体验比 VNC 好很多。部署时注意加密配置绑定固定 ID防止被非授权设备连入。终端常用回收技巧。用户报“电脑卡死了”远程没法操作又不能跑到现场怎么办可以提前在所有终端部署一个远程命令通道如 Ansible 的 ad-hoc或者平台 agent 的远程命令功能遇到假死状态直接远程执行ansible terminal_hosts -m shell -a systemctl restart lightdm --becomeLightDM 是 UOS/麒麟桌面默认的显示管理器重启它等于“注销但保留进程的桌面刷新”比强制重启整机温和得多用户重新登录就恢复正常。这个小技巧在 80% 的“卡死”场景里都能救急。5. 常见故障与排查思路信创环境特有的那些坑5.1 软件兼容性问题不是报错的问题是生态的问题信创环境最常见的故障类别不是什么深层玄学而是软件兼容性。老软件在 x86 Windows 上跑得好好的迁移到国产平台上要么安装不了要么运行时报缺库。排查兼容性问题的思路我建议按这个顺序来先看架构。确认目标机器的 CPU 架构和软件安装包是否匹配。ARM64 的包不能装在 x86 机器上x86_64 的包也不能装在龙芯机器上。命令uname -m查看架构file 安装包查看包格式。再看依赖库。国产平台上最常见的报错是libxxx.so: cannot open shared object file。这时候不要急着乱找库文件先确认缺失库属于哪个软件包然后从系统软件源里安装不要去第三方站点下载 .so 文件手动拷到/usr/lib——系统库路径混乱是运维的噩梦。实在找不到替代库的检查是否有旧版本可兼容或者向软件厂商索要国产化适配版本。政务行业已经过了“逼着软件厂商适配”的阶段主流办公软件WPS、数科 OFD、永中在麒麟和 UOS 上都有正式适配版本要求使用方升级到这些版本即可。还有一个容易被忽视的点Java 应用的字节码版本。很多单位老系统还在用 JDK 8 编译迁移到国产平台后如果系统自带的 OpenJDK 版本过低比如 OpenJDK 11运行高版本字节码会报UnsupportedClassVersionError。先确认 JDK 版本是否匹配再排查更深层的问题。5.2 性能“假死”问题CPU 100% 但负载不高怎么查信创服务器有一个让人头疼的现象CPU 使用率显示 100%但uptime显示的负载平均值并不高系统也没完全卡死。这种情况在鲲鹏、飞腾的 ARM 平台上尤其常见。原因的根源在于 ARM 架构的 CPU 频率调节策略和中断处理机制与 x86 有差异。x86 上 CPU 飙高通常伴随负载升高和进程切换频繁容易定位ARM 上某些内核版本对中断和软中断的处理方式会导致单核打满但整体任务数不多。排查思路先用top按 CPU 排序锁定具体进程。再用pidstat -p [PID] 1看进程 CPU 占用的用户态/内核态比例。如果是内核态sy占比高多半是驱动或内核模块的问题重点检查网卡驱动、存储驱动是不是有已知 bug。用cat /proc/interrupts看中断分布。ARM 平台中断亲和性设置不当会导致多个中断集中在一个核上运行解决办法是使用irqbalance服务或手工设置中断亲和性。还有一个相关性较高的因素新版内核的 CPU 节能策略cpufreq在服务器上默认可能启用 powersave 模式导致性能波动。确认和调整cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor # 若输出 powersave改为性能模式 echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor注意这个方法只在当前运行期生效重启失效。要持久化可以写一个 systemd unit 或使用cpupower工具麒麟商店里有。5.3 数据库连接池被打满在信创平台尤其常见的瓶颈国产数据库达梦、人大金仓、GaussDB在信创迁移初期最常遇到的性能问题就是连接池打满。原因有两层一是中间件到数据库的连接池配置没有根据实际业务调整二是国产数据库的默认连接数上限比同类商业数据库低。比如达梦数据库默认 max_connections 是 100对于几百人的业务系统完全不够。调大连接数需要同时改数据库参数和应用侧连接池。以 Java 的 HikariCP 为例核心参数是最大值maximum-pool-size和连接超时connection-timeout。数据库侧达梦修改最大连接的语句SP_SET_PARA_VALUE(1, MAX_SESSIONS, 300);人大金仓KingbaseES则在 postgresql.conf 中修改max_connections 300改动之后记得重启数据库服务然后观察应用侧报错是否消失。连接池问题的另一个排查方向是连接泄漏——应用没有正确归还连接。这个在信创环境中更难排查因为业务代码往往是老系统迁移过来的可能根本没做好连接管理。日常运维建议加上连接池监控HikariCP 自带 Metrics连接数持续爬升不回落基本可以断定有连接泄漏抓紧通知开发修复。5.4 安全隐患自查清单一次常规巡检都该看什么写到最后附上一份适合信创环境的安全巡检清单。这块内容不复杂但很多运维朋友日常忽略等到出问题才后悔。登录到每一台服务器上花五分钟跑一遍下面的操作last和lastb看有没有异常登录记录和失败登录尝试。cat /var/log/auth.logUOS或/var/log/secure麒麟重点看非运维时段是否有 SSH 登录记录。ss -tulnp检查当前监听端口对照白名单确认没有多出奇怪的监听。find /tmp -type f -mtime -1很多攻击者会在 /tmp 下扔临时文件。crontab -l以及检查/etc/cron.d/、/var/spool/cron/确认没有可疑的计划任务回连行为。systemctl list-units --typeservice --staterunning确认没有多出陌生的系统服务。ss -ntp | grep ESTAB | awk {print $4} | sort | uniq -c | sort -rn查看建连数排序异常高的目标 IP 要重点核查。安全巡检的频率建议业务高峰期后做一次深查、每月做一次例行巡检每次巡检记录形成报告存档。等保测评或单位内审的时候这些巡检记录是直接能拿出手的合规成果。写在最后给刚入行信创运维的几点建议这一两年带过不少刚从 Windows 运维转向信创的同事发现大家普遍卡在同一个心理坎上总觉得国产系统“别扭”“不顺手”遇到问题习惯性先归因于“系统不行”。实际跑过几个项目之后大多数人都会改观——国产操作系统的底层是成熟的开源内核真正需要花时间的是理解自己的业务跑在什么样的异构底座上。信创运维这行没有什么捷径就是多上手、多踩坑、多总结。我个人的体会是一定要维护好一份属于自己的“问题知识库”把每次处理过的兼容性问题、性能瓶颈和安全事件记录下来标注清楚芯片架构、系统版本、软件版本和最终解法。时间长了这套知识库比任何认证都值钱。最后再分享一个实用技巧在做任何涉及内核参数、安全策略或数据库配置的变更前先用cp -a备份原配置文件然后用diff记录变更内容再执行变更。这个习惯配合 LVM 快照基本能保证你在操作失误时 10 分钟内回滚敢折腾、能收场才算真正合格的运维。
信创运维实战：异构环境优化与安全防护指南
这几年做信创运维最深的感触就是这一行不再是把 Windows 换成麒麟、把 Intel 换成鲲鹏那么简单了。国产化替代走到深水区运维工程师面对的是完全异构的底层架构、不成熟的软件生态以及比传统环境更严苛的安全合规要求。这篇文章我想把实际工作中沉淀下来的系统优化思路和安全防护手段整理出来重点聊聊那些常规文档里不会写的细节希望能给正在做信创适配或者准备转信创运维的朋友一些参考。1. 信创运维的底层逻辑先搞懂国产化环境的“脾性”1.1 信创运维和传统 x86 运维到底差在哪很多人以为信创运维就是把原来跑在 Windows 上的操作习惯搬过来换几个命令而已。实际做过才知道这两者之间的差距比想象中大得多。传统 x86 环境下Intel/AMD 的指令集高度统一底层硬件抽象层做得非常成熟数据库、中间件、业务系统基本都是“装上就能跑”。操作系统层面Windows 和主流 Linux 发行版在驱动适配、内核稳定性、软件兼容性上已经打磨了十几年运维的核心工作是监控、调优、故障排查——一切建立在稳定的基础设施之上。信创环境恰恰相反。它的“不稳定”主要体现在三个层面第一CPU 指令集分叉严重。鲲鹏基于 ARM 架构飞腾也是 ARM但海光走的是 x86 路线兆芯兼容 x86龙芯是自己的 LoongArch。这意味着同一套软件在不同芯片平台上可能需要重新编译甚至部分依赖库都不存在。一个在内网跑得好好的 Java 应用迁移到鲲鹏上可能因为缺少 ARM 版 native 库直接起不来。第二操作系统版本碎片化。统信 UOS、麒麟银河麒麟、中标麒麟已经合并、openEuler 衍生版底层都是 Linux 内核但服务管理方式、默认安全策略、软件源管理各有差异。更麻烦的是很多单位内部还有 CentOS、Ubuntu 混用的情况一个运维要同时维护三四套发行版命令兼容性是个大问题。第三软件生态成熟度不足。比如某些国产数据库对标准 SQL 的支持不够完整迁移后个别存储过程要重写办公套件WPS、永中的文件兼容存在细微差异甚至一些基础的运维工具比如备份软件、监控 agent在国产平台上没有官方版本需要自己编译。所以信创运维的第一个核心能力不是会用某个命令而是理解异构——知道你的环境里有哪几种芯片、哪几套系统、哪些软件跑在什么底座上才能针对性地制定优化和防护方案。1.2 信创环境常见的硬件与软件组合接触过的信创项目里最典型的硬件组合大概是这几类鲲鹏 920/930 系列服务器配麒麟 V10 或 openEuler飞腾 FT-2000/S2500 配麒麟 V10 SP1 或 UOS 服务器版海光 7000 系列配麒麟 V10、UOS甚至还有配 CentOS很多单位还没完全切走龙芯 3A5000/6000 配 Loongnix 或麒麟。服务器之外终端环境更复杂。台式机、笔记本上跑着 UOS 家庭版/专业版、麒麟桌面版芯片涵盖兆芯、飞腾、龙芯、鲲鹏。政务单位还会出现“双网双模”的配置——一台终端同时接政务内网和互联网通过隔离卡切换。这种场景下运维不仅要管系统本身还要管双网隔离的安全性这在国内是特有的运维需求。我的建议是接手一套信创环境第一周不要急着做优化先把资产台账搞清楚每台设备的芯片型号、操作系统版本、内核版本uname -a、重要业务依赖的中间件版本、数据库版本、网络分区情况。这些信息全部记录在案后续所有优化和安全策略都基于这份台账来定。没有台账的优化就像盲人摸象。2. 系统优化实战从内核参数到磁盘 IO 的调优方案2.1 内核参数调优先看业务类型再动手很多人一上来就照着网上的“Linux 内核优化参数大全”抄把 vm.swappiness 改成 0net.core.somaxconn 改成 65535看似专业实则危险。信创环境尤其不能这么干因为国产芯片和操作系统的组合千差万别照搬 x86 的优化经验可能会带来负面效果。内核调优的正确姿势是先搞清楚业务的负载特征。如果是跑数据库达梦、人大金仓、GaussDB重点优化内存管理和磁盘 IO如果是跑 Web 服务东方通、金蝶天燕中间件重点优化网络栈和文件描述符如果是跑大数据组件Flink、Spark重点优化进程调度和内存分配。以最常见的数据库业务为例核心要调的参数有这么几个# 内存管理针对数据库类应用 vm.swappiness 10 vm.dirty_ratio 20 vm.dirty_background_ratio 5 # 文件系统 fs.aio-max-nr 1048576 fs.file-max 6815744 # 网络栈高并发连接场景 net.core.somaxconn 65535 net.ipv4.tcp_max_syn_backlog 65535 net.ipv4.ip_local_port_range 1024 65000需要注意vm.swappiness 不要照抄 0。很多文章推荐 0是为了让内存尽量不换页。但在国产 ARM 平台上内存访问延迟比 x86 高swap 设置过低可能导致内存回收不及时反而引发 OOM。实测下来数据库类应用设置 10 左右比较合适既保证内存利用率又保留一定的回收弹性。文件描述符上限也是排查“明明没宕机但应用连不上”的常见原因。修改方法有两个一个是在/etc/sysctl.conf里写死另一个是用 systemd 启动脚本的 LimitNOFILE 属性。注意优先改 systemd 侧的配置因为在 systemd 环境下/etc/security/limits.conf可能不生效——这个坑我踩过。2.2 存储与文件系统优化日志、数据库目录分开放信创服务器上存储设备参差不齐有的是 SSD有的是 SAS 机械盘还有的是传统 HDD 阵列。不同业务的数据落盘特征不同优化策略也要分开。最基础也是最有效的优化是把日志目录和数据库目录分开放。这个建议听起来土但实际效果立竿见影。数据库的随机读写和日志的顺序写入如果挤在同一块盘上会产生严重的 IO 竞争导致事务响应时间飙升。分开之后各自独占 IO 通道性能提升肉眼可见。具体操作上如果服务器有多块硬盘建议这样分区系统盘一块 SSD建议 240G 以上装操作系统、中间件、数据库程序数据盘一块或多块 SSD/HDD存放数据库数据文件、表空间日志盘一块 HDD 或小容量 SSD集中放 /var/log、应用日志、数据库归档日志没有条件分盘的至少要用 LVM 做逻辑卷隔离并用 ionice 为不同进程设置 IO 优先级。比如给数据库进程设置较高的 IO 优先级给备份任务设置较低的# 查看进程PID systemctl status mysqld # 设置IO优先级0-7数字越小优先级越高 ionice -p 1357 -c 2 -n 0文件系统层面信创平台主流用的是 ext4 和 xfs。数据库场景建议用 xfs它的并发写入能力和元数据操作性能比 ext4 好尤其在 ARM 平台上差距更明显。制作文件系统的时候记得加上ftype1参数xfs 默认开启避免后续 Docker 等容器服务运行时报 overlay 存储驱动不支持。2.3 服务与进程优化systemd 才是信创平台的主角国产操作系统全面采用 systemd 管理服务这个和 CentOS 7 以后的主流实践是一致的。但信创环境有个特殊情况很多从 Windows 迁移过来的业务组件aint 提供 systemd 服务文件只有一个可执行的 start.sh。运维人员图省事直接nohup ./start.sh 就跑了结果进程成了孤儿开机不自启崩溃不自愈。正确做法是写 systemd service 文件哪怕只是一个简单的 Java 应用也应该纳入 systemd 托管。一个标准的 service 文件长这样[Unit] DescriptionMy App Server Afternetwork.target mysql-server.service [Service] Typesimple Userappuser Groupappgroup WorkingDirectory/opt/myapp ExecStart/usr/bin/java -Xms4g -Xmx4g -jar myapp.jar Restarton-failure RestartSec5 LimitNOFILE65535 NoNewPrivilegestrue PrivateTmptrue [Install] WantedBymulti-user.target这段配置里几个要点值得注意。Restarton-failure只会在进程异常退出时自动拉起正常退出比如运维手动执行 systemctl stop不会触发重启比较安全。LimitNOFILE65535解决文件描述符不够的问题作用等同于 ulimit -n。NoNewPrivilegestrue和PrivateTmptrue是安全基线要求前者防止进程通过 setuid 提权后者隔离临时目录这些在等保测评里都会看。服务写好后要执行systemctl daemon-reload重新加载然后systemctl enable --now myapp设置开机自启。另外UOS 和麒麟自带的图形化管理工具比如 UOS 的“服务管理”实际上也是调用 systemd 的接口命令行习惯在信创环境里依然是最通用的路径。桌面运维给终端用户解释“为什么服务又挂了”用 systemctl status 截图比讲原理高效得多。2.4 终端性能优化让旧 PC 也能流畅跑国产系统终端优化是信创运维里最“接地气”的一块。很多单位的 PC 还是几年前的老配置内存 4G、机械硬盘装完 UOS 或麒麟桌面版之后卡顿明显用户的第一反应就是“国产系统不行”。实际上这一半是硬件问题另一半是优化没到位。在终端侧最有效的优化集中在三个方向释放内存压力。桌面版打开自带的软件包管理器把用不到的内置应用卸载掉比如一些游戏、非必要的办公组件。然后调整 swap 策略桌面环境可以适当提高 swappiness 到 30-60让系统在内存吃紧时敢于换页避免直接冻死。关闭无用的视觉效果。麒麟和 UOS 的桌面特效窗口动画、透明效果在 GPU 性能弱的环境下非常拖后腿。到“设置-通用-特效模式”切换为“普通模式”或“兼容模式”卡顿感会明显改善。这一步做完多数 PC 用户基本满意。启用 SSD 优化。如果终端是 SSD确认 TRIM 是否开启systemctl enable fstrim.timer systemctl start fstrim.timer这行命令让系统周期性执行 TRIM保证 SSD 长期不掉速。机械硬盘用户则要反过来关注磁盘碎片国产桌面系统的文件碎片问题比 Windows 更明显能用e4defrag对 ext4 分区做离线整理。终端优化不要过度核心目标是“让用户不吐槽”。完成基础优化后给标准化终端做一份 GHOST 或自定义镜像模板后续新终端直接批量克隆部署比一台台优化省时省力得多。3. 安全防护架构从等保合规到实战防御3.1 安全基线核查先把该做的检查项做完信创环境的安全防护起点是安全基线不是装一套杀毒软件就行。政务、金融、能源等行业的信创项目等保 2.0 三级测评基本是硬门槛测评之前自查越细后面整改越少。我按实际测评经验整理了一个核心检查项速查表可以参考着逐项核对检查项推荐配置说明账户策略密码最长有效期 90 天最少 8 位含数字大小写字母/etc/login.defs和 PAM 模块配合设置登录失败锁定连续 5 次失败锁定 15 分钟编辑/etc/pam.d/system-auth增加 tally2 或 faillock 模块远程管理限制仅允许指定 IP 段通过 SSH 登录修改/etc/ssh/sshd_config中 AllowUsers审计策略启用 auditd记录用户操作和关键文件变更systemctl enable auditd确认规则已加载服务最小化关闭不必要服务仅保留业务必须项systemctl list-unit-files --typeservice逐项过补丁管理操作系统和中间件补丁滞后不超过 3 个月麒麟/UOS 都有漏洞库对应工具日志留存本地日志留存 6 个月以上建议集中采集rsyslog 转发到日志服务器防病毒/EDR启用国产终端安全软件集中管理如深信服、奇安信、天融信的国产平台版本等保测评有个容易忽略的点所有设备的时间必须同步否则日志关联分析的时候完全对不上。在信创环境尤其重要因为国产系统的 NTP 配置各有差异。做法是搭一台内网 NTP 服务器用开源 chrony所有服务器和终端统一指向它同时把timedatectl set-ntp true确认在开。3.2 账号与权限管理默认密码必须改root 权限要收敛信创项目上线初期为了赶进度不少系统是用默认密码或简单密码比如Admin123、Kylin123跑起来的。这在互联网隔离的网络里问题不明显但信创环境通常还要对接政务网或行业专网一旦某个节点被突破横向移动很容易。账号管理的几条硬性纪律首次登录强制改密。利用chage -d 0 用户名让用户在下次登录时必须修改密码。清理万能账号。UOS 和麒麟在安装时可能创建了uos或kylin的超级用户如果业务不需要直接userdel -r uos删除。禁用 root 远程登录。在/etc/ssh/sshd_config设置PermitRootLogin no运维用普通用户登录后通过 sudo 提权。把 sudo 权限精细到命令级别比如运维只能执行systemctl restart nginx、tail -f /var/log/nginx/error.log等操作而不是无脑 ALL。最小权限原则不是口号。给应用单独建服务账号不共用 root 跑进程。这个前面 systemd 那段配置里已经演示了Userappuser 就是落实这一条。权限管理的本质是给攻击者增加横向移动的成本。即使一台机器被攻破没有 root 权限、没有全局通用密码攻击者很难在短时间内拿到内网其他机器的控制权。3.3 边界与终端防护端口管理、防火墙策略、外设管控防火墙是边界的第一道门但也是配置错误率最高的地方。信创服务器的防火墙策略我建议遵循“白名单制”——默认拒绝只放行业务端口和管理端口。不要图省事用firewall-cmd --add-port1-65535/tcp这种操作这在服务器上线时是原罪。比如一台跑东方通中间件的服务器对外只需要开放 8080 给负载均衡器管理只需要开放 22 给运维网段systemctl start firewalld systemctl enable firewalld # 添加白名单规则 firewall-cmd --permanent --add-rich-rulerule familyipv4 source address10.10.1.0/24 port port8080 protocoltcp accept firewall-cmd --permanent --add-rich-rulerule familyipv4 source address10.10.200.0/24 port port22 protocoltcp accept # 默认策略改为拒绝外部访问 firewall-cmd --permanent --set-default-zonedrop firewall-cmd --reload注意--set-default-zonedrop这一步。很多管理员保留了默认的 public 区域规则放过 8080 之后其他端口依然可以通过等于白设。设置为 drop 之后所有未放行的流量一律丢包简单粗暴但有效。终端外设管控是政务场景的高频需求。用户拿个 U 盘拷文件一插就是病毒入口。国产终端普遍有 TPM可信平台模块和统一安全管控软件建议启用“USB 存储只读”策略或者干脆禁用 USB 存储设备改为通过内网网盘传输文件。从用户反馈来看技术上没有任何障碍难的是“收回”用户的既有习惯。运维能做的是先把策略配好然后准备好“怎么申请例外”的流程文档。另外国产终端普遍预装的安全中心比如 UOS 安全中心、麒麟安全中心一定要利用起来而不要因为它“看起来简陋”就无视。这些工具调用的是系统底层的安全能力强制访问控制、应用沙箱配合统一管理平台可以做外设管控、软件安装白名单、外联探测完全是能打的。3.4 数据备份与业务连续性别等到宕机才想起备份信创环境里备份的重要性不亚于安全防护。很多单位在适配阶段根本顾不上备份觉得“先跑起来再说”结果某次配置变更把数据库搞坏了没有可恢复的备份只能从头重建业务中断长达数小时。这种教训一次就够。备份这件事我的建议是“分三层做”操作系统层服务器装好、所有调优参数定稿后用 LVM 快照或系统自带的备份工具如麒麟的“备份恢复”工具做一次全量镜像。后续每次大版本升级或内核参数大量调整之前再做一次快照。这个快照存在的意义是让你有“反悔”的资本。数据层数据库达梦、人大金仓、MySQL开启归档模式每日全量备份加每小时增量备份。备份文件必须复制到独立的备份服务器或存储上不能只存在本机——本机磁盘坏了备份一起没了等于白做。应用层配置文件、部署包、版本更新记录这类的“代码资产”统一放进 Git 仓库。国产系统上的应用迁移和回滚没有版本管理简直寸步难行。备份做完了一定要定期演练恢复。找个周末拿一台闲置机器把备份的数据库导一遍看看能不能起来、数据是不是完整。演练过一次你备份才真正有价值否则就只是一堆不知道能不能用的文件。4. 国产平台的常用运维命令与效率工具4.1 麒麟与 UOS 上最常用的命令集信创桌面和服务器底层是 Linux所以 Linux 常用命令体系完全适用但有几个细节需要特别注意查看系统版本不能用一条命令通吃。麒麟系常用cat /etc/kylin-release cat /etc/os-releaseUOS 系统cat /etc/os-version cat /etc/os-release如果混用了 openEulercat /etc/openEuler-release。养成先看 os-release 的习惯再根据版本决定后续命令这是信创运维的基本素质。软件安装命令要区分发行版系。麒麟 V10 和 UOS 基于 Debian用apt-get installopenEuler 系用yum/dnf。如果内部系统都是同一批到底还好就怕混用环境下记错命令。建议在每台机器上写个小脚本自动探测包管理器#!/bin/bash if command -v apt-get /dev/null; then echo Debian-based, use apt-get elif command -v dnf /dev/null; then echo RPM-based, use dnf fi日志查看路径有差异。系统日志一般在/var/log/messages麒麟或/var/log/syslogUOS 基于 Debian应用日志位置看中间件配置。查日志时先用ls /var/log/快速确认有哪些文件再决定 tail 哪个。国产服务器硬件信息查看比如确认芯片型号lscpu cat /proc/cpuinfo | grep model name | head -1 # 海光/兆芯可见CPU型号 cat /proc/cpuinfo | grep CPU part | head -1 # ARM芯片看这个字段 cat /proc/device-tree/model # 鲲鹏/飞腾整机型号这些命令组合一台服务器 30 秒内基本就能确认芯片和整机情况排查兼容性问题时非常高效。4.2 运维效率工具Ansible、监控、日志平台一网打尽信创环境普遍设备数量大几百台终端很常见逐台手工操作根本做不过来。自动化运维工具的选择要重点看对国产平台的兼容性。Ansible 在信创环境的表现相当不错。它基于 SSH对通信协议要求低Agentless 架构不用在被管理端装额外东西天然适合异构环境。写 playbook 做批量配置修改系统参数、推送 NTP 配置、设置安全基线、批量部署软件、批量巡检都能胜任。需要注意Ansible 控制端建议跑在 openEuler 或麒麟服务器上Python 版本选择 3.9 以上的兼容版本对 ARM 架构的机器控制端和被控制端之间的 SSH 协议参数可能需要微调比如网速不稳定的环境把 timeout 调大。另外从 Ansible 2.9 开始对 Python 3.8-3.10 支持良好在国产系统上直接用 pip 装即可不需要编译。监控方案推荐 Zabbix 或 Prometheus Grafana。Zabbix 对国产化适配做得比较早支持麒麟、UOS、openEuler开启自动发现规则后几百台设备半小时内就能完成初装。如果是新的信创项目建议直接用 Prometheus node_exporter Grafana 的组合轻量、云原生友好后续容器化演进不折腾。服务端装好之后一定把监控项覆盖这几块CPU 负载负载平均值和单核使用率、内存剩余量/OOM 次数、磁盘使用率和 IO 等待、网络流量和丢包率、关键服务状态systemd 服务是否 active。报警阈值按不同硬件配置分别设置比如 ARM 服务器 CPU 负载阈值普遍比 x86 低 20%-30%否则容易误报。日志平台国产系统处理日志的方式和传统 Linux 没有本质区别。rsyslog 转发到 Logstash/Elasticsearch或者用 Loki都是成熟路径。日志集中化除了满足等保审计要求更重要的是故障排查时能跨机器关联查询比如定位到某台终端异常外联的完整链路。4.3 终端的批量运维与远程协助技巧终端运维的日常是“人少事多”几十台 PC 同时报故障不可能挨个跑现场。把批量化做到位运维效率能提升一个量级。系统镜像与批量部署是最基础的。用 Clonezilla 或系统自带的部署工具把标准终端做完优化、装好必要软件之后做成镜像。新终端开机 PXE 网络引导十几分钟一台比逐台安装快一个数量级。注意不同芯片架构的镜像不能互刷鲲鹏的镜像刷到飞腾机器上起不来。远程协助工具如果内网部署了统一管理平台比如国产办公终端管理平台通常在管理后台直接发起远程桌面协助。没有平台的话可以用 VNC 或 RustDesk 自建。RustDesk 支持自建服务器内网环境下延迟低还支持跨平台Windows、Linux、国产系统体验比 VNC 好很多。部署时注意加密配置绑定固定 ID防止被非授权设备连入。终端常用回收技巧。用户报“电脑卡死了”远程没法操作又不能跑到现场怎么办可以提前在所有终端部署一个远程命令通道如 Ansible 的 ad-hoc或者平台 agent 的远程命令功能遇到假死状态直接远程执行ansible terminal_hosts -m shell -a systemctl restart lightdm --becomeLightDM 是 UOS/麒麟桌面默认的显示管理器重启它等于“注销但保留进程的桌面刷新”比强制重启整机温和得多用户重新登录就恢复正常。这个小技巧在 80% 的“卡死”场景里都能救急。5. 常见故障与排查思路信创环境特有的那些坑5.1 软件兼容性问题不是报错的问题是生态的问题信创环境最常见的故障类别不是什么深层玄学而是软件兼容性。老软件在 x86 Windows 上跑得好好的迁移到国产平台上要么安装不了要么运行时报缺库。排查兼容性问题的思路我建议按这个顺序来先看架构。确认目标机器的 CPU 架构和软件安装包是否匹配。ARM64 的包不能装在 x86 机器上x86_64 的包也不能装在龙芯机器上。命令uname -m查看架构file 安装包查看包格式。再看依赖库。国产平台上最常见的报错是libxxx.so: cannot open shared object file。这时候不要急着乱找库文件先确认缺失库属于哪个软件包然后从系统软件源里安装不要去第三方站点下载 .so 文件手动拷到/usr/lib——系统库路径混乱是运维的噩梦。实在找不到替代库的检查是否有旧版本可兼容或者向软件厂商索要国产化适配版本。政务行业已经过了“逼着软件厂商适配”的阶段主流办公软件WPS、数科 OFD、永中在麒麟和 UOS 上都有正式适配版本要求使用方升级到这些版本即可。还有一个容易被忽视的点Java 应用的字节码版本。很多单位老系统还在用 JDK 8 编译迁移到国产平台后如果系统自带的 OpenJDK 版本过低比如 OpenJDK 11运行高版本字节码会报UnsupportedClassVersionError。先确认 JDK 版本是否匹配再排查更深层的问题。5.2 性能“假死”问题CPU 100% 但负载不高怎么查信创服务器有一个让人头疼的现象CPU 使用率显示 100%但uptime显示的负载平均值并不高系统也没完全卡死。这种情况在鲲鹏、飞腾的 ARM 平台上尤其常见。原因的根源在于 ARM 架构的 CPU 频率调节策略和中断处理机制与 x86 有差异。x86 上 CPU 飙高通常伴随负载升高和进程切换频繁容易定位ARM 上某些内核版本对中断和软中断的处理方式会导致单核打满但整体任务数不多。排查思路先用top按 CPU 排序锁定具体进程。再用pidstat -p [PID] 1看进程 CPU 占用的用户态/内核态比例。如果是内核态sy占比高多半是驱动或内核模块的问题重点检查网卡驱动、存储驱动是不是有已知 bug。用cat /proc/interrupts看中断分布。ARM 平台中断亲和性设置不当会导致多个中断集中在一个核上运行解决办法是使用irqbalance服务或手工设置中断亲和性。还有一个相关性较高的因素新版内核的 CPU 节能策略cpufreq在服务器上默认可能启用 powersave 模式导致性能波动。确认和调整cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor # 若输出 powersave改为性能模式 echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor注意这个方法只在当前运行期生效重启失效。要持久化可以写一个 systemd unit 或使用cpupower工具麒麟商店里有。5.3 数据库连接池被打满在信创平台尤其常见的瓶颈国产数据库达梦、人大金仓、GaussDB在信创迁移初期最常遇到的性能问题就是连接池打满。原因有两层一是中间件到数据库的连接池配置没有根据实际业务调整二是国产数据库的默认连接数上限比同类商业数据库低。比如达梦数据库默认 max_connections 是 100对于几百人的业务系统完全不够。调大连接数需要同时改数据库参数和应用侧连接池。以 Java 的 HikariCP 为例核心参数是最大值maximum-pool-size和连接超时connection-timeout。数据库侧达梦修改最大连接的语句SP_SET_PARA_VALUE(1, MAX_SESSIONS, 300);人大金仓KingbaseES则在 postgresql.conf 中修改max_connections 300改动之后记得重启数据库服务然后观察应用侧报错是否消失。连接池问题的另一个排查方向是连接泄漏——应用没有正确归还连接。这个在信创环境中更难排查因为业务代码往往是老系统迁移过来的可能根本没做好连接管理。日常运维建议加上连接池监控HikariCP 自带 Metrics连接数持续爬升不回落基本可以断定有连接泄漏抓紧通知开发修复。5.4 安全隐患自查清单一次常规巡检都该看什么写到最后附上一份适合信创环境的安全巡检清单。这块内容不复杂但很多运维朋友日常忽略等到出问题才后悔。登录到每一台服务器上花五分钟跑一遍下面的操作last和lastb看有没有异常登录记录和失败登录尝试。cat /var/log/auth.logUOS或/var/log/secure麒麟重点看非运维时段是否有 SSH 登录记录。ss -tulnp检查当前监听端口对照白名单确认没有多出奇怪的监听。find /tmp -type f -mtime -1很多攻击者会在 /tmp 下扔临时文件。crontab -l以及检查/etc/cron.d/、/var/spool/cron/确认没有可疑的计划任务回连行为。systemctl list-units --typeservice --staterunning确认没有多出陌生的系统服务。ss -ntp | grep ESTAB | awk {print $4} | sort | uniq -c | sort -rn查看建连数排序异常高的目标 IP 要重点核查。安全巡检的频率建议业务高峰期后做一次深查、每月做一次例行巡检每次巡检记录形成报告存档。等保测评或单位内审的时候这些巡检记录是直接能拿出手的合规成果。写在最后给刚入行信创运维的几点建议这一两年带过不少刚从 Windows 运维转向信创的同事发现大家普遍卡在同一个心理坎上总觉得国产系统“别扭”“不顺手”遇到问题习惯性先归因于“系统不行”。实际跑过几个项目之后大多数人都会改观——国产操作系统的底层是成熟的开源内核真正需要花时间的是理解自己的业务跑在什么样的异构底座上。信创运维这行没有什么捷径就是多上手、多踩坑、多总结。我个人的体会是一定要维护好一份属于自己的“问题知识库”把每次处理过的兼容性问题、性能瓶颈和安全事件记录下来标注清楚芯片架构、系统版本、软件版本和最终解法。时间长了这套知识库比任何认证都值钱。最后再分享一个实用技巧在做任何涉及内核参数、安全策略或数据库配置的变更前先用cp -a备份原配置文件然后用diff记录变更内容再执行变更。这个习惯配合 LVM 快照基本能保证你在操作失误时 10 分钟内回滚敢折腾、能收场才算真正合格的运维。