核心内容摘要
国防单位使用百度富文本编辑器导入机密WORD文档，有哪些加密方案？
快速定位哪个层次出问题当服务异常或告警时我第一步不是直接重启而是把系统“目前的样子”抓下来命令很短但信息密度高# 进程与负载uptimetop-b -n1|head-n20# 内存/交换free-hvmstat15# 磁盘空间与 inodedf-hTdf-i# I/O 与等待iostat -xz13# 需要 sysstat 包iotop -o# 需要 iotop# 网络侦测ss -tulpnipaiproute这些输出能马上告诉我CPU 被某进程吃满了内存耗尽磁盘满了导致写失败还是网络端口没有监听我会把这些命令输出复制到一个临时文件作为后续分析的证据。
进程层面精查如果 top 显示某个 PID 占用异常我会用以下步骤确认进程行为不轻易 killps-eo pid,ppid,cmd,%mem,%cpu --sort-%cpu|head-n20# 查看进程打开的网络/文件lsof-pPIDss -p|grepPID# 跟踪系统调用短时间内观察strace-pPID-s200-o /tmp/strace.PID.log# 或只抓取阻塞的 syscallstrace-pPID-etracenetwork,file -s200-o /tmp/strace.net.log我用strace并不是长期跟踪而是想知道程序卡在做 I/O、等待网络还是在无限循环。
如果strace显示 blocked on write 或 blocked on futex那我就知道这不是 CPU 算力问题而是 I/O 或锁竞争。
如果是内存问题用pmap -x PID或smem看内存分布如果是频繁创建子进程导致 load 高用pstree -p PID看父子关系。
先读不改再动手磁盘满、inode 用尽、文件系统错乱是我遇到最多的停服来源。
关键原则能读就备份。
查磁盘占用时我不直接用du /太慢而是分级定位# 大目录一览快速找到“胖目录”du-xsh /var/*|sort-rh|head-n20# 定位单个目录下的大文件find/var/log -xdev -type f -size 100M -execls-lh{}\;# 查 inode 使用df-i磁盘满了能短期救急的做法我会先用清理旧日志但保留备份压缩归档冷数据或把某个目录临时挂到另一个磁盘上mount --bind。
只有在确认没有其他办法时才删除文件并把删除清单记录下来。
若遇到 filesystem corruption我会先用fsck.ext4 -n /dev/sdX做只读检查然后做镜像dd if/dev/sdX of/backup/sdX.img bs4M statusprogress如果盘还能读再在镜像上尝试修复这样把风险降到最低。
我如何快速从日志里抓问题我经常用journalctl和tail -F联合抓取服务日志。
journalctl的时间过滤很有用# 系统 journaljournalctl -xe --no-pager# 某个服务最近 200 行并持续跟踪journalctl -u myservice -n200-f# grep 关键词注意 journalctl 自带过滤journalctl -u myservice --since
10:00--until
11:00|grep-i error我一般不会一次读全日志而是先定位时间窗口报警触发时刻前后 5 分钟然后向外扩展。
很多时候根因就在那短短几行堆栈或错误代码里。
验证链路、端口、DNS、路由网络故障常有三种表现本机无法访问、端口未监听、远程不通。
我常做的顺序是ip a看地址
ss -tulpn确认服务在监听
curl -I http://
127.
0.
1:端口验证本机服务
tcpdump -i if host peer抓包看流量。
举个我常用的抓包命令我想看与远端
10.
1.
3 的连接sudotcpdump -i eth0host
10.
1.
3 -nn -s0 -w /tmp/cap.pcap抓完我会用 Wireshark/tcpdump -r本地查看是否有三次握手是否有 RST或者是否只是应用层超时。
服务管理与快速恢复的套路我始终坚持“先恢复服务再做根因分析”。
这通常意味着快速重启 service 或切换到备实例而不是盲目调参。
常用命令systemctl status myservice systemctl restart myservice systemctl stop myservice journalctl -u myservice -n200-f如果重启后问题消失我不会当场把系统升级或改配置我会把恢复步骤记录标注为“临时恢复”并在事后低峰时段做深入排查。
备份与恢复我偏好rsync做文件/目录级备份因为它简单且可增量。
示例我常用的命令rsync-aHAX --delete --infoprogress2 /data/ /backup/data/# 说明-aHAX 保持权限/硬链接/ACL/扩展属性--delete 保证目标镜像源--info 显示进度对于更复杂的版本化备份我会用rsync --link-dest做硬链接增量或者长期使用restic/borg做去重和加密备份这里我个人偏好 restic 的简单性。
重要的是每次备份后都做恢复演练。
备份不验证 没有备份。
升级、打补丁与变更管理在我看来升级是风险管理而不是例行操作。
原则上我在三层环境跑升级本地开发机快速验证灰度或测试环境业务场景覆盖生产低峰窗口先备份如果是关键组件内核、数据库、容器 runtime我会先拍快照或备份数据并准备回滚计划。
很多故障来自“版本跳太大”所以分阶段、每次改一个维度是我不出意外的保命法则。
“救命”命令下面这些命令我把它们背在手上关键时刻能救场每个命令前后的语境我都会先确认找占空间的文件du-xsh /var/*|sort-rh|head-n20找大于 100MB 的文件find/ -xdev -type f -size 100M -execls-lh{}\;|sort-k5 -h快速查看某端口谁在占用ss -tulpn|grep:80把某个服务日志流式保存并 grep 错误journalctl -u myservice -f|tee/tmp/myservice.log|grep-i error临时增加 swap短期救内存不足sudofallocate -l 1G /swapfilesudochmod600/swapfilesudomkswap/swapfilesudoswapon/swapfile这些命令看起来简单但用了就知道在紧急情况下速度和证据比完美的步骤更重要。
我的小习惯我把这些习惯放在最后因为它们往往比一堆命令更能降低事故率每次变更写变更日志记录时间、操作人和回滚步骤。
把常用的排错步骤写成脚本或 playbookAnsible避免“手工失误”。
定期演练恢复从 1 次变更开始建立信心链。
对生产机器做最小权限配置避免运维误操作造成级联故障。
对关键盘做 SMART 定期检测并预警smartctl -H /dev/sdX。