前言更多运维相关知识蓝队技能学习_其实防守也摸鱼的博客-CSDN博客持续更新ing~介绍如果把前面的自动化、监控比作运维的“高速公路”和“仪表盘”那么安全和数据库就是这条高速公路的“护栏”和终点站的“核心金库”。一旦这两块出问题整个业务都可能面临停摆甚至数据丢失的灾难。咱们还是结合实战场景来看看这两大“护城河”到底该怎么建。️ 安全加固把服务器变成“铁桶”安全加固的核心目的只有一个收敛攻击面让黑客找不到下嘴的地方。除了之前提到的防火墙日常运维中还有以下几个极其重要的安全手段1. 账户与访问控制扔掉密码拥抱密钥很多新手喜欢用 root 账号加简单密码直接登录服务器这在公网上等于是在裸奔。禁用 root 登录创建一个普通用户并赋予它sudo权限日常操作都用这个普通用户。SSH 密钥登录彻底关闭 SSH 的密码登录功能改用公私钥对进行身份验证。这样即使黑客知道了你的端口没有你本地的私钥文件也绝对进不来。修改默认端口把 SSH 默认的 22 端口改成一个不常见的高位端口比如 22222能挡住 90% 以上无脑扫描的自动化脚本。2. 最小化服务与权限关掉不必要的“窗户”关闭多余端口除了业务真正需要的端口如 80、443其他端口一律关闭。数据库内网监听像 MySQL3306、Redis6379这种数据库端口绝对不能暴露在公网上。必须配置它们只监听内网 IP比如bind-address 10.0.0.2只允许同内网的应用服务器来访问。3. 补丁与备份最后的防线定期打补丁系统和软件总会有漏洞开启自动安全更新或者定期手动执行apt upgrade/yum update把已知的漏洞堵上。3-2-1 备份原则这是数据安全的黄金法则。即保留3份数据副本存放在2种不同的介质上其中1份存放在异地比如另一台服务器或云端的对象存储。️ 数据库管理守护核心资产对于运维来说数据库DBA的工作不需要你像开发人员那样去写复杂的JOIN查询你的核心任务是保证它活着、不丢数据、跑得够快。1. 备份与恢复DBA 的生命线这是数据库运维最重要、没有之一的工作。全量 增量备份通常每天凌晨做一次全量备份比如用mysqldump或xtrabackup同时开启 binlog二进制日志做增量备份。定期演练恢复备份如果不经过恢复测试就等于没有备份运维必须定期把备份文件拉到测试环境尝试恢复一次确保在真正出事时这套备份真的能用。2. 基础性能调优让数据库不卡顿当开发跑来抱怨“数据库太慢了”时运维可以从以下几个维度排查看硬件指标用top或监控面板看看 CPU、内存是不是打满了。如果是内存不够数据库频繁把数据交换到磁盘Swap速度就会断崖式下跌。查慢查询开启数据库的“慢查询日志Slow Query Log”把那些执行时间超过 1 秒的 SQL 语句抓出来扔给开发人员让他们去加索引或优化代码。看连接数有时候数据库慢是因为瞬间涌入的连接太多。检查当前的连接数是否达到了配置的上限。3. 高可用架构不让单点故障拖垮业务一台数据库服务器总有宕机的时候比如硬盘坏了。为了保证业务不中断通常需要配置主从复制Master-Slave或集群。主从架构一台主库负责写数据一台或多台从库负责读数据。当主库发生故障时可以迅速把从库提拔为主库接管业务。 它们是如何协同工作的在实际的生产环境中安全和数据库是紧密交织的开发人员提交了包含数据库变更比如加了一张新表的代码。CI/CD 流水线自动执行在部署应用前先通过自动化工具在测试环境执行 SQL 脚本。应用上线后监控系统Prometheus开始紧盯数据库的连接数和响应时间。如果此时遭遇恶意攻击安全加固防火墙、密钥登录会挡住外部的非法入侵如果发生硬件故障高可用架构会自动切换节点。最坏的情况发生比如误删了数据运维人员立刻拿出3-2-1备份迅速将数据恢复到故障前的状态。一句话总结安全加固决定了你的系统能活多久数据库管理决定了你的业务能跑多稳。这两块是运维进阶到高级架构师必须啃下的硬骨头。实战1 故障背景现在是周五晚上 8 点你正在吃晚饭突然收到一条告警“订单服务 CPU 使用率飙升至 100%接口响应时间超过 5 秒” 客服群里已经有用户投诉无法下单了。作为当值运维你需要立刻排查并解决问题。请系好安全带我们开始实战 第一阶段现场排查定位问题源头1. 登录服务器查看整体状况你 SSH 登录到订单服务器首先敲下运维最常用的命令top你看到 CPU 使用率确实高达 100%。在top命令的进程列表中你发现排在第一位的不是 Java 应用也不是 Nginx而是一个名为mysqld的进程它独占了 95% 的 CPU初步判断问题出在数据库层面很可能是有极其消耗 CPU 的查询语句在疯狂执行。2. 登录数据库抓住“元凶”你使用 root 账号登录到 MySQL 数据库mysql -u root -p进入 MySQL 命令行后你输入以下命令查看当前正在执行的 SQL 语句SHOW PROCESSLIST;屏幕上刷出了一大堆记录但你一眼就盯住了其中一条状态为Sending data且Time执行时间已经高达几十秒的 SQLSELECT * FROM orders WHERE order_status pending AND user_id IN (SELECT id FROM users WHERE city Shanghai);破案了这是一条典型的“烂 SQL”。它不仅没有走索引还在orders表可能有几百万条数据里做全表扫描并且嵌套了一个子查询直接把数据库 CPU 跑满了。️ 第二阶段紧急止血恢复业务线上业务正在受损现在的首要任务是让系统先活过来而不是慢慢去优化代码。1. 杀掉卡死的进程你在 MySQL 里找到了刚才那条烂 SQL 对应的进程 ID假设是1024果断执行KILL 1024;瞬间数据库的 CPU 占用率降了下来订单服务恢复了正常响应。客服群里传来了好消息“用户可以正常下单了”2. 临时规避方案为了防止开发人员还没改好代码这条烂 SQL 再次被触发你可以利用之前学过的防火墙知识进行紧急限制。你登录到数据库所在的服务器使用iptables临时封禁掉非应用服务器 IP 对 3306 端口的访问或者直接让开发在代码里把这个查询接口暂时下线。️ 第三阶段根治与优化防止再次发生危机解除后周末的复盘会上你需要推动彻底的修复。1. 推动代码与索引优化你把那条烂 SQL 甩给了开发负责人并给出了优化建议不要在代码里写这种复杂的嵌套子查询应该改成多表JOIN。检查orders表的order_status字段和users表的city字段必须加上数据库索引。2. 开启“慢查询日志”运维的照妖镜为了防止以后再有这种烂 SQL 偷偷上线你修改了 MySQL 的配置文件my.cnf开启了慢查询日志slow_query_log 1 long_query_time 1 # 只要执行超过 1 秒的 SQL统统给我记下来这样以后任何执行超过 1 秒的 SQL 都会被自动记录运维可以定期审查把隐患扼杀在摇篮里。3. 完善监控告警你打开Prometheus和Grafana监控面板把 MySQL 的“活跃连接数”和“慢查询数量”加到了核心告警规则里。一旦慢查询数量突然激增系统会在 CPU 被打满之前提前给你发钉钉告警。 实战复盘总结恭喜你你刚刚完美处理了一次线上 P0 级故障在这个过程中你其实用到了我们之前聊过的几乎所有核心知识监控告警第一时间发现了 CPU 异常。Linux 基础用top命令快速定位到是mysqld进程在捣鬼。数据库管理用SHOW PROCESSLIST抓住了慢 SQL并用KILL命令紧急止血。安全与网络懂得利用防火墙限制端口访问防止问题恶化。这就是高级运维的日常平时用监控和自动化防患于未然战时用扎实的基础知识快速排查、果断止血。实战2来看看运维界最让人心跳骤停的“连环案”磁盘突然被撑爆导致服务全线崩溃。 故障背景周一早上 10 点正是业务高峰期。你突然收到一连串告警轰炸订单服务返回500 Internal Server Error。数据库连接失败。监控面板上几台核心服务器的 CPU 和内存看似正常但业务就是完全瘫痪了。你立刻登录到其中一台出问题的服务器准备大干一场。 第一阶段排查“幽灵”故障1. 常规检查失效你习惯性地敲下top发现 CPU 和内存都很空闲。接着你敲下df -h查看磁盘空间df -h屏幕上的输出让你倒吸一口凉气Filesystem Size Used Avail Use% Mounted on /dev/sda1 100G 99G 1.0G 99% /破案了根目录/的使用率已经达到了 99%磁盘被撑爆了数据库因为无法写入新数据而崩溃应用服务也随之报错。2. 寻找“吃”掉磁盘的元凶磁盘满了到底是谁干的你立刻用上了之前学过的du命令从根目录开始一层层排查du -sh /* | sort -nr | head -n 10(解释查看根目录下每个文件夹的大小按从大到小排序只看前 10 个)你发现/var目录大得离谱。继续往下挖du -sh /var/* | sort -nr | head -n 10最终你在/var/log/目录下发现了一个名为app_error.log的文件它竟然高达95GB3. 分析日志发现死循环你赶紧用tail -n 100 app_error.log看了一下最新的日志发现里面密密麻麻全是同一句话Redis connection refused: Too many open files原来某个微服务在尝试连接 Redis 时遇到了网络抖动由于代码里没写好重试机制它陷入了疯狂报错的死循环每秒钟往日志里写入几万条错误信息硬生生把磁盘给塞满了。️ 第二阶段紧急止血千万别直接 rm现在的首要任务是恢复服务但你面临一个棘手的问题磁盘满了直接删文件能腾出空间吗1. 错误的做法新手常犯你直接敲下rm -f app_error.log。然后你再次执行df -h绝望地发现磁盘空间依然是 99%(解释因为在 Linux 中如果这个文件正被某个进程比如你的 Java 应用打开着即使你用rm删除了文件名进程依然持有这个文件的句柄磁盘空间并不会真正释放。)2. 正确的做法运维老鸟的基操你立刻执行了以下命令瞬间清空了文件内容但保留了文件本身 /var/log/app_error.log(解释重定向符会直接把文件内容截断清空变成 0 字节。)再次执行df -h磁盘使用率瞬间掉到了 5%数据库和应用服务自动重启业务迅速恢复正常。️ 第三阶段根治与优化危机解除后为了防止下周一再次上演“惊魂时刻”你开始着手根治1. 推动代码修复你把那段疯狂报错的日志甩给开发要求他们修复连接池的重试逻辑不能无限重试必须加上退避机制比如报错后等几秒再重试。2. 配置日志轮转Logrotate你深知“日志不能无限增长”是运维的铁律。于是你配置了 Linux 自带的logrotate工具写了一个配置文件/etc/logrotate.d/myapp/var/log/app_error.log { daily # 每天轮转一次 rotate 7 # 最多保留 7 个历史文件 compress # 历史文件自动压缩成 .gz节省空间 missingok # 文件不存在也不报错 notifempty # 如果日志为空就不轮转 size 1G # 或者当文件超过 1G 时也强制轮转 }这样系统每天半夜会自动把昨天的日志打包压缩并创建一个全新的空日志文件磁盘再也不会被撑爆了。3. 完善监控告警你打开 Prometheus添加了一条极其关键的告警规则当任意服务器的磁盘使用率超过 80% 时立刻触发钉钉告警。这样你就能在磁盘满之前提前介入处理。 实战复盘总结这场“磁盘撑爆”的连环案完美串联了你的多项技能监控告警第一时间发现服务 500 报错。Linux 基础用df -h和du -sh定位空间占用用tail分析日志内容。排错思维懂得了“删除正在被进程使用的文件无法释放空间”这个经典的 Linux 坑并用 file优雅解决。自动化与预防配置logrotate自动管理日志完善磁盘监控告警。这就是高级运维的素养不仅能救火还能通过机制和工具让同样的火永远烧不起来。
)
