企业官网建设流程全解析

前言

更多运维相关知识：蓝队技能学习_其实防守也摸鱼的博客-CSDN博客

持续更新ing~

介绍

如果把前面的自动化、监控比作运维的“高速公路”和“仪表盘”，那么安全和数据库就是这条高速公路的“护栏”和终点站的“核心金库”。一旦这两块出问题，整个业务都可能面临停摆甚至数据丢失的灾难。

咱们还是结合实战场景，来看看这两大“护城河”到底该怎么建。

🛡️ 安全加固：把服务器变成“铁桶”

安全加固的核心目的只有一个：收敛攻击面，让黑客找不到下嘴的地方。除了之前提到的防火墙，日常运维中还有以下几个极其重要的安全手段：

1. 账户与访问控制（扔掉密码，拥抱密钥）
很多新手喜欢用 root 账号加简单密码直接登录服务器，这在公网上等于是在裸奔。

• 禁用 root 登录：创建一个普通用户，并赋予它sudo权限，日常操作都用这个普通用户。
• SSH 密钥登录：彻底关闭 SSH 的密码登录功能，改用公私钥对进行身份验证。这样即使黑客知道了你的端口，没有你本地的私钥文件也绝对进不来。
• 修改默认端口：把 SSH 默认的 22 端口改成一个不常见的高位端口（比如 22222），能挡住 90% 以上无脑扫描的自动化脚本。

2. 最小化服务与权限（关掉不必要的“窗户”）

• 关闭多余端口：除了业务真正需要的端口（如 80、443），其他端口一律关闭。
• 数据库内网监听：像 MySQL（3306）、Redis（6379）这种数据库端口，绝对不能暴露在公网上。必须配置它们只监听内网 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）或集群。

• 主从架构：一台主库负责写数据，一台或多台从库负责读数据。当主库发生故障时，可以迅速把从库提拔为主库，接管业务。

🤝 它们是如何协同工作的？

在实际的生产环境中，安全和数据库是紧密交织的：

1. 开发人员提交了包含数据库变更（比如加了一张新表）的代码。
2. CI/CD 流水线自动执行，在部署应用前，先通过自动化工具在测试环境执行 SQL 脚本。
3. 应用上线后，监控系统（Prometheus）开始紧盯数据库的连接数和响应时间。
4. 如果此时遭遇恶意攻击，安全加固（防火墙、密钥登录）会挡住外部的非法入侵；如果发生硬件故障，高可用架构会自动切换节点。
5. 最坏的情况发生（比如误删了数据），运维人员立刻拿出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（执行时间）已经高达几十秒的 SQL：

SELECT * 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 级故障！在这个过程中，你其实用到了我们之前聊过的几乎所有核心知识：

1. 监控告警：第一时间发现了 CPU 异常。
2. Linux 基础：用top命令快速定位到是mysqld进程在捣鬼。
3. 数据库管理：用SHOW PROCESSLIST抓住了慢 SQL，并用KILL命令紧急止血。
4. 安全与网络：懂得利用防火墙限制端口访问，防止问题恶化。

这就是高级运维的日常：平时用监控和自动化防患于未然，战时用扎实的基础知识快速排查、果断止血。

实战2

来看看运维界最让人心跳骤停的“连环案”：磁盘突然被撑爆，导致服务全线崩溃。

🚨 故障背景

周一早上 10 点，正是业务高峰期。你突然收到一连串告警轰炸：

1. 订单服务返回500 Internal Server Error。
2. 数据库连接失败。
3. 监控面板上，几台核心服务器的 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的文件，它竟然高达95GB！

3. 分析日志，发现死循环
你赶紧用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% 时，立刻触发钉钉告警。这样你就能在磁盘满之前，提前介入处理。

💡 实战复盘总结

这场“磁盘撑爆”的连环案，完美串联了你的多项技能：

1. 监控告警：第一时间发现服务 500 报错。
2. Linux 基础：用df -h和du -sh定位空间占用，用tail分析日志内容。
3. 排错思维：懂得了“删除正在被进程使用的文件无法释放空间”这个经典的 Linux 坑，并用> file优雅解决。
4. 自动化与预防：配置logrotate自动管理日志，完善磁盘监控告警。

这就是高级运维的素养：不仅能救火，还能通过机制和工具，让同样的火永远烧不起来。