公司上了堡垒机，头半年一切正常。运维七八个人，每天登几十次机器，界面打开就是快的，录像回放点一下就能看。后来业务扩张，运维、开发、外包加起来三十来号人，某天早上九点半，所有人同时点登录，转圈、超时、有的干脆连不上。查了一圈，不是网络问题，不是账号问题，是那台跑堡垒机的虚拟机磁盘写满了，数据库因为没法落日志，登录流程卡死在写库那一步。
这个场景的可怕之处在于：堡垒机是全公司运维流量的唯一入口，它自己一旦撑不住，所有人就都进不去了。业务系统挂一个，影响的可能是某个模块；堡垒机挂掉，影响的是"修复业务系统的能力本身"。出了线上故障偏偏进不去机器，这种事只要发生一次，就足够让人记一辈子。
但它在绝大多数公司的资源清单里，被归类成"轻量小应用"：不就是个 web 界面加一个 SSH 代理吗，两核四G随便跑跑。这个判断在设计阶段看起来无害，在运行半年之后就会变成一场事故。给 JumpServer 这类开源堡垒机定服务器规格，要算清三笔账：会话录像、并发会话、审计库。这三笔账的消耗方式完全不同，吃的是不同的硬件资源，增长曲线也不一样，混在一起按"有多少人用"来估，是几乎所有踩坑的共同起点。
这篇文章就把这三笔账一笔一笔摊开算：每笔账到底吃什么资源、随什么增长、涨到什么程度会出症状、以及规划阶段该怎么处理。中间会反复强调一个结论——堡垒机不能部署在"业务机器的边角料"上，它是一台写入密集 + 长连接密集 + 数据只增不减的机器，磁盘规划与备份策略比 CPU 更重要。
先纠正一个直觉。普通业务系统的流量模型是"请求—响应—断开"：一个 HTTP 请求进来，几十毫秒处理完，连接释放，资源归还。堡垒机的模型完全相反，它是"连接建立—长时间保持—全程记录"：一个 SSH 会话可能开两个小时，这期间连接一直占着，内存一直占着，录像文件一直在追加写，命令日志一条一条往数据库里落。
换句话说，堡垒机同时具备三种截然不同的负载特征：持续的小文件写入、大量的长期连接、高频的数据库小事务。这三种负载对硬件的要求是互相打架的。持续写入要的是磁盘吞吐和稳定延迟；长连接要的是内存和文件描述符；高频小事务要的是数据库的 IOPS 和连接数。任何一项单独拿出来都不算重，但它们叠加在一台机器上，而且是 7×24 不间断地叠加，性质就变了。
还有一点容易被忽略：堡垒机的数据是只增不减的。业务数据有删除、有更新、有归档出冷存；堡垒机的录像和审计日志，按设计就是要留着，而且留多久往往由审计要求决定，不由运维决定。这意味着它的磁盘水位是一条单调递增的曲线，直到你主动做清理为止。一台数据只增不减的机器，磁盘规划错了，不是"以后扩容"的问题，是"某天早上九点半突然不可用"的问题。
下面这张表把六类资源一次性摊开。这张表是全文的骨架，后面每一节都是把其中某一行讲透。
| 资源项 | 什么行为在消耗它 | 随什么增长 | 典型症状 | 规划时怎么处理 | 是否要独立盘 |
|---|---|---|---|---|---|
| 会话录像容量 | 每个会话实时追加写录像文件，回放时再读取 | 运维人数 × 操作频次 × 保留期，人越多增长越快 | 磁盘剩余空间持续下降，突然写满后无法新建会话 | 先定保留期，再按日均增长速率反推容量 | 必须独立数据盘 |
| 磁盘写入吞吐 | 录像持续写、小文件创建与元数据更新 | 并发会话数、图形协议占比 | 录像丢帧、会话建立慢、写入延迟飙升 | 选持续写稳定的盘，盯写延迟而非只看标称容量 | 建议独立 |
| 内存 | 每条会话的连接缓冲、协议编解码缓冲、组件常驻 | 并发会话数，图形协议比字符协议重得多 | OOM 杀进程、在线会话被集体踢掉 | 按峰值并发估算并预留冗余，不要按平均人数算 | 否 |
| CPU | 协议代理转发、录像转码与压缩、回放解码 | 转码任务堆积数、并发图形会话数 | 转码队列积压、回放卡顿、登录响应变慢 | 转码错峰到低峰期，给转码单独留核数预算 | 否 |
| 数据库连接数 | 登录日志、命令记录、操作事件持续落库 | 并发会话数 × 单会话写频率 | 连接池耗尽、登录排队超时、界面转圈 | 设连接池上限、批量写入、定期清理历史表 | 数据盘要独立 |
| 数据库磁盘 IOPS | 高频小写入、索引维护、审计查询扫描 | 运维人数、命令审计的粒度粗细 | 写入排队、审计页面打开极慢、日志落库延迟 | 用 SSD，控制单条记录粒度，避免全表扫描式查询 | 必须独立盘 |
| 网络长连接 | 会话长期保持，不是短请求，断线还要重连 | 并发会话数 | 连接数打满、新建会话直接失败 | 调高文件描述符与连接上限，纳入监控 | 否 |
| 备份与归档空间 | 定期备份数据库、归档过期录像 | 数据总量 × 保留份数 | 备份任务失败、真要恢复时发现备份也是旧的 | 备份单独存放并与生产盘分离，定期做恢复演练 | 必须独立存放 |
把上面这张表压缩成三句话，就是全文的骨架：会话录像吃的是磁盘吞吐和容量；并发会话吃的是内存和 CPU；审计库吃的是 IOPS 和连接数。这三句话看起来平平无奇，但它们的实际含义是——你不能用一个统一的"规模"指标去套它们。人数翻倍，录像量的增长和内存占用的增长，走的是两条完全不同的曲线。
举个最直观的例子。一家公司从 10 个运维扩到 20 个运维，人数翻了一倍。内存这边的变化相对线性：并发会话数大致翻倍，内存预算跟着翻倍就够了。但录像这边不是线性的——人多了，每个人被审计的操作也变多了，跨部门协作带来的登录频次上升，新业务上线带来的排障操作增加，录像量的增长往往比人数增长更陡，经验上接近平方级的关系（这是经验区间，具体倍数取决于你们的运维强度，可按"人均日均会话数 × 平均会话时长"粗估）。按线性思维买的磁盘，往往在人数翻倍后不到半年就见底。
审计库这边又是第三种曲线。它的增长不是由"人"决定的，而是由"操作密度"决定的：一个人一天敲 20 条命令和一个人一天敲 2000 条命令，落库的记录数差着两个数量级。跑批任务、自动化脚本通过堡垒机执行、有人开着会话挂着不动但持续输出日志——这些都会让审计库的写入量远超按人数估算的结果。
所以三笔账要分开算，算完取最大值，而不是取平均值。这也是"堡垒机选型"和"普通业务系统选型"最本质的区别：业务系统通常有一个主导瓶颈（要么 CPU，要么 IO，要么带宽），堡垒机是三个瓶颈同时存在、互相独立、且都会随时间单调恶化。
先说清楚录像到底往磁盘上写了什么。一个 SSH 会话建立后，堡垒机在转发数据的同时，会把双方交互的原始字节流按时间顺序记录下来；RDP/VNC 这类图形会话记录的则是画面帧序列。这些数据不是等会话结束才一次性落盘的，而是边传边写、持续追加——也就是说，只要有人在操作，磁盘就一直在写。
这就带来两个特征。第一是"小文件洪流"。每个会话至少产生一个录像文件，运维一天登几十次机器，就是几十个新文件；三十个人一年下来，文件数量是几十万量级的。文件系统处理海量小文件时，瓶颈往往不在"写多少字节"，而在元数据操作：创建 inode、更新目录项、分配块。这些操作对磁盘来说都是随机写，而随机写正是机械盘最不擅长的场景。第二是"不可压缩"。录像内容是终端字节流和画面帧，本身已经是编码后的数据，指望文件系统层的压缩帮你省空间是不现实的，别被忽悠。
再说"持续"这两个字的杀伤力。业务系统的写入通常是突发的：早上九点一波，中午一波，晚上低峰基本空着。堡垒机的写入是跟着人走的，工作时间段内一直有，而且越是业务出问题的时候写入越猛——因为出故障时所有人都在登机器排查。也就是说，堡垒机的写入峰值，恰恰出现在你最需要它稳定的时刻。这个反身性是它区别于普通业务系统最要命的一点。
还有一个容易被漏掉的细节：录像的写入路径上还挂着"索引"和"元数据"的落库。会话结束时要记录谁、什么时间、连了哪台机器、时长多久，这些信息要写进审计库。如果审计库写不进去，会话的正常结束流程会被拖住，进而影响新会话的建立。磁盘写满为什么会直接导致登录失败？链路就是这么串起来的：盘满了 → 录像写不下 → 会话无法结束/建立 → 数据库要记录但空间不足 → 登录流程卡死。
这是整篇文章里最该在买机器之前就想清楚的问题，也是最常被跳过的问题。录像保留期一旦定下来，磁盘容量就基本定了；反过来，先买机器再想保留期，几乎必然是容量不够或者严重浪费。
保留期该定多久，没有一个放之四海皆准的数字。它取决于企业自身的审计要求和所在行业的惯例做法：有的公司内控规定操作记录要留存半年，有的行业惯例是一年，涉及特定监管场景的可能要求更久。具体条多少天，请以你们法务、内审或行业主管部门给出的口径为准，本文不替你定这个数字，也不引用任何具体法规条款——因为不同行业、不同地区、不同业务性质的要求差异很大，抄一个数字过来反而是风险。
能讲的是定这个数字的方法。第一步，把"必须留"和"方便查"分开。登录记录、命令记录这类结构化数据体积小、查询价值高，可以留很久；完整录像体积大、查询频次低，保留期可以相对短一些。两者不必用同一个期限。第二步，问清楚"最坏情况下要回溯多久"：一次安全事件从发生到被发现，中间可能隔了很久，如果你们的检测能力只能保证一个月内发现异常，那留三个月录像就够了，留三年意义不大还白花钱。第三步，把保留期写进制度，而不是写进某个管理员的习惯——因为清理动作必须有依据，否则没人敢删。
算容量的时候这么估：先估出人均日均会话数和平均会话时长，算出日均新增录像量，再乘以保留期天数，最后乘一个安全系数。字符协议（SSH）的录像体积小，图形协议（RDP/VNC）大得多，如果你们有图形协议的运维场景，要单独算一份，不要混在一起平均。算出来的数字再留三到五成余量，因为运维强度是会涨的，而扩容是有窗口期的。
最后一个提醒：保留期不是定了就完事，它需要一个执行机制。定期清理脚本、归档任务、磁盘水位告警，三样都要有。很多公司不是没定保留期，是定了之后没人执行，或者脚本挂了三个月没人发现，最后还是走到"磁盘写满"那一步。
这条是本篇里最不容商量的一条。录像文件必须放在独立的数据盘上，不能和系统盘共用，也不能和数据库盘共用。理由有三个，一个比一个硬。
第一个理由是故障隔离。录像盘写满是可预期的、会必然发生的事情——只要保留期到了而清理没跟上，盘就会满。如果这块盘同时是系统盘，那么盘满的后果是：操作系统无法写临时文件、日志写不下、服务无法启动、sshd 可能都连不上。一台因为"录像写满了"而连系统都进不去的机器，恢复起来非常痛苦，因为你连上去删文件的手段本身都依赖系统可用。把录像放到独立盘上，盘满的后果就被限制在"新会话无法录像"这个范围内，系统还在、数据库还在、你还能登录进去处理。这就是设计上的容错。
第二个理由是IO 竞争。录像写入是持续的顺序追加写，数据库写入是高频随机小写入，这两种 IO 模式放在同一块盘上会互相伤害：数据库在等随机写的低延迟，而录像正在用大块连续写占着带宽和队列。表现就是审计页面打开很慢、命令记录落库延迟、录像偶尔丢帧。分开之后，各自的性能特征是可预测的；混在一起，性能变成玄学。系统盘的日志、临时文件、swap 也需要 IO，同样不该被录像洪流冲掉。
第三个理由是扩容和运维的便利性。录像盘独立，意味着它满了可以单独扩、可以单独换、可以单独挂载到别的机器上做归档，不用动系统和数据库。也意味着你可以给它选不同的盘型：录像盘看重持续写稳定和容量，数据库盘看重随机写 IOPS 和延迟，两者用同一块盘必然是妥协的结果。一万网络深耕 IDC 19 年（成立于 2007 年），独立服务器租用支持按自己的规划去配磁盘数量和盘型，具体规格以官网实时显示为准；对堡垒机这种场景，"能不能给录像单独挂一块盘"比"CPU 是几核"重要得多。
实操上还有个小建议：录像目录单独挂载、单独设置配额意识、单独监控水位。不要图省事放在某个大目录底下，那样过半年你自己都找不到是哪个目录在吃空间。
这一节讲量级差异，不给具体数字——因为不同版本、不同编码参数、不同画面复杂度下差别很大，给一个精确数字反而是误导。但量级上的结论是明确的：图形协议（RDP/VNC）的单会话开销，比字符协议（SSH）重得多，通常差一个数量级以上。
为什么会差这么多？先看字符协议。SSH 会话里流动的是文本：键盘输入几十字节，屏幕回显几 KB，一分钟不操作几乎没有流量。堡垒机在这条链路上做的事是转发字节流 + 记录字节流，编解码开销几乎可以忽略，缓冲区可以开得很小。一条空闲的 SSH 会话，长期占用的是一条 TCP 连接、一个进程/协程、以及少量缓冲区，资源占用极低。
图形协议完全是另一回事。RDP/VNC 传的是画面：屏幕分辨率多大、每帧多少像素、帧率多少，直接决定了数据量。字符协议是"你敲什么传什么"，图形协议是"屏幕上变了什么就传什么"——看一段视频、拖一个窗口、滚一个日志，画面的变化量都是字符协议的上千倍。堡垒机在这条链路上要做的事情也更重：维护图形会话的状态、做画面编码/转码、按帧序列写入录像、回放时还要解码。一条图形会话的 CPU 和内存开销，大致相当于几十条字符会话。（经验区间，具体倍数取决于画面复杂度和编码方式，可按"是否开启图形协议运维"作为一个独立变量来估配置。）
这个差异对配置决策的影响是：如果你们的运维场景里有 Windows 服务器、有需要通过图形界面操作的设备，那么并发会话数的估算必须把图形会话单独拎出来算，不能和 SSH 会话混在一起数"多少条"。一个 30 人团队如果全部用 SSH，配置压力主要在连接数和数据库；同样 30 人如果有 10 个同时在用 RDP，配置压力就转移到内存和 CPU 上，机器规格要往上走一个档次。
还有一点：图形会话对网络延迟更敏感。字符协议下延迟 100ms 你几乎无感；图形协议下同样的延迟会让鼠标操作明显发黏。所以如果堡垒机和被管机器不在同一个网络环境里，图形协议的体验问题会先于资源问题暴露出来，排查时别只盯着 CPU 看。
这是堡垒机 CPU 消耗里最容易被漏算的一项。买机器时大家想的是"代理转发要多少 CPU"，没人想"转码要多少 CPU"。但转码和回放，往往是堡垒机 CPU 曲线上最高的那个尖峰。
为什么需要转码？原始录像的格式是为"忠实记录"优化的，不一定适合"直接播放"和"长期存储"。为了能在浏览器里直接回放、为了减小存储占用，系统通常会把原始录像再处理一遍，转成通用可播放的格式。这个处理过程是纯粹的计算：读一遍原始数据，做编码转换，再写一遍。注意这一步同时产生读 IO 和写 IO——它既吃 CPU，又吃磁盘，而且是突发的大块读写。
回放同样吃 CPU。用户在浏览器里点开一段录像，服务端要按时间轴解码、按倍速处理、再推给播放器。一个人看没什么，赶上安全事件复盘、事故review的时候，一个团队十几个人同时翻录像，CPU 就能被打满。而这个尖峰出现的时机，恰好又是"系统出事了大家都在查"的时刻——和录像写入的峰值特征一样，反身性。
规划上怎么处理？第一，给转码单独留 CPU 预算，不要和在线会话共用全部核数。如果机器只有两核，转码一跑，在线会话的转发就跟着卡，用户感知是"登录变慢了"。第二，转码错峰。把批处理性质的转码任务放到夜间或低峰，避开工作时间。第三，控制回放的并发和倍速能力预期——如果你们的场景经常需要多人同时回放，CPU 核数要相应往上走，这笔钱省不得。
一个实用的判断方法：观察 CPU 使用率的曲线形状。如果它是平稳的低占用，说明瓶颈不在 CPU；如果它呈现周期性的尖峰（比如每天固定时间、或者每次有人查录像时），那尖峰就是转码/回放，按尖峰配，不要按平均值配。按平均值配 CPU 是堡垒机选型里最常见的隐性失误。
内存的算法相对直观，但很多人算错了基数。他们按"公司有多少运维"算，而正确的基数是"业务高峰时同时在线的会话数"。这两者差得很远：一个人可能同时开着五六个会话（一台应用、一台数据库、一台跳板），一个会话断了还会自动重连，还有自动化任务通过堡垒机跑批。实际并发数经常是"人数"的两三倍甚至更多，按人头算内存必然不够。
一条会话在内存里留了什么？拆开看有这么几块：一是连接相关的缓冲区，发送缓冲和接收缓冲，字符协议可以很小，图形协议要大得多；二是协议处理的状态，加密上下文、会话密钥、编解码器的中间状态，这部分是每条会话独立的，不能共享；三是录像写入的缓冲，为了不让磁盘 IO 拖慢会话，写入通常是先攒在内存里再批量落盘，攒的这部分就常驻着；四是应用层面的会话对象和审计上下文，记录这个会话属于谁、连到哪、当前在执行什么命令。
把这些加总，一条字符会话的常驻内存开销不大，但一条图形会话因为要维护画面缓冲和编码状态，开销明显更高。所以内存规划的正确姿势是：分别估算字符会话数和图形会话数，各自乘一个单会话开销，再加起来，最后除以一个合理的内存使用率上限（不要指望用到 100%）。另外别忘了系统本身、数据库、web 组件、缓存这些常驻部分，它们是不管有没有会话都要占的。
内存不够时会发生什么？不是"变慢"，是直接的、粗暴的失败：系统 OOM killer 挑一个占内存最大的进程杀掉，很可能是数据库或者某个核心组件；或者所有在线会话被集体断开。前面说的"某天早上所有人同时登录不进去"，内存耗尽是仅次于磁盘写满的第二常见原因。而且内存的失败模式比磁盘更突然——磁盘满之前有水位告警给你缓冲期，内存耗尽往往在几秒内发生。
审计库存储的是什么？登录日志（谁什么时候从哪登进来、成功还是失败）、命令记录（在目标机器上执行了什么）、操作事件（上传下载文件、会话开始结束、权限变更）。这些数据的共同特征是：单条记录小、写入频率高、而且不可丢失。
"高频小写入"意味着瓶颈是 IOPS 而不是吞吐。一块盘标称顺序写几百 MB/s 很漂亮，但随机小写入的能力可能只有顺序写的零头。数据库落一条日志，涉及写数据页、写索引、写事务日志（WAL/redo），为了保证不丢还要 fsync（强制把操作系统缓存里的数据刷到物理盘上，这一步是真正决定写入延迟的地方）。fsync 的次数由事务提交频率决定，而审计日志是每条都要落库的，所以 fsync 压力是持续的。
如果这块盘是机械盘，或者和录像盘共用，症状会很典型：审计页面打开要转好几秒、命令记录有延迟才显示、严重时会话结束卡住、甚至登录排队。这类问题排查起来很烦，因为 CPU 和内存看起来都很闲，只有 IO 等待高——很多人第一反应是"数据库不行，加内存吧"，加了内存没用，因为瓶颈在盘的随机写能力上。
处理办法很直接：审计库单独用 SSD，最好独立数据盘；控制单条记录的粒度（不要把整段输出塞进一条记录里）；给审计表建合适的索引但别建太多（索引越多写入越慢）；定期清理历史数据。如果规模上来了，把数据库单独拆到另一台机器上也是合理的演进路径——堡垒机的应用层和数据库层分离部署，是很常见且推荐的架构。
顺便说一个经常被忽略的点：审计查询本身也会制造 IO 压力。安全管理要查"某个人在过去三个月里对某台机器执行过哪些命令"，这类查询如果没有合适索引，就是一次大范围扫描，能把 IO 打满。所以审计库既要照顾"写"，也要照顾"查"，索引策略要两边权衡，偏向写入还是偏向查询，取决于你们查的频率。
堡垒机的数据只增不减，但"只增不减"不等于"什么都要永远留着"。清理策略的核心是把数据分三类：必须长期留的、可以归档的、可以到期删的。分清楚之后，磁盘规划才有依据，否则就是无限增长。
必须长期留的：登录审计记录（谁在什么时候访问了什么资产）、权限变更记录、与安全事件相关的操作证据。这类数据结构化、体积小、查询价值高、而且往往是审计要求的重点，保留期通常比录像长得多。它们的总体积增长相对温和，但因为是"必须留"，清理时要格外小心，宁可多留也别误删。
可以归档的：超过高频查询窗口的历史录像和历史命令记录。这些数据还要留，但没人会天天查，可以从生产盘挪到归档存储（另一块大盘、对象存储、或者离线介质）。归档的意义是把"在线数据总量"压住，让生产盘的水位不再单调上涨。归档方案要提前设计好：怎么挪、挪完生产库里留不留索引、需要时怎么取回来。很多团队只设计了"归档出去"，没设计"取回来"，等到真要取证时才发现找不到。
可以到期删的：超出保留期且无涉事件标记的录像、临时的会话中间文件、系统运行日志（注意这指的是堡垒机自身的应用日志，不是审计日志）、转码产生的中间产物。这一类是最该被自动清理、也最常被遗忘的。转码中间产物尤其阴险：转码失败时留下的半成品、重试多次产生的临时文件，如果清理逻辑没覆盖到，它们会悄悄占满你的盘。
执行层面三条建议：一是清理动作必须做成定时任务并配告警，脚本失败要能被人知道；二是清理前先做备份或先归档，别直接 rm；三是每次清理记日志，清理了多少、保留了哪个时间窗口，便于日后证明"清理是按规定做的"。审计这个场景里，"删了什么、为什么删"本身也需要能被说明。
有些团队为了省钱，把堡垒机装在某一台业务服务器上，或者装在跑着其他内部系统的那台机器上。这个决定在短期内看不出问题，长期看是三个层面的隐患。
第一是可用性上的自锁。堡垒机的价值在于"当业务出问题时，它是你进去修的门"。如果这道门和业务跑在同一台机器上，那么业务机器挂掉的时候，门也一起挂了。更糟的是，业务机器出问题往往伴随着资源耗尽（CPU 打满、内存吃光、磁盘写满），恰好是堡垒机最需要资源的时刻，但资源已经被业务抢走了。把唯一的维修通道和业务系统绑在一起，等于把钥匙锁在了车里。
第二是安全隔离。堡垒机是全公司权限最集中的地方，它保存着通往所有机器的凭据、保存着所有人的操作录像、保存着完整的资产拓扑。它应该是一个被严格保护的小岛，而不是混在业务机器上、和业务共用一套账号体系、共用一套网络策略、共用一套补丁节奏。共用意味着攻击面叠加：业务机器上任何一个薄弱环节，都可能成为通向堡垒机的跳板。反过来说，堡垒机被攻破的后果也会因为共用而放大到业务数据。
第三是故障半径和资源竞争。业务系统做活动、跑批处理、做数据导出，会瞬间吃掉大量 CPU、内存和 IO，这些突发的资源占用会直接影响堡垒机的响应。反过来，堡垒机的录像写入洪流和转码尖峰，也会拖慢同机业务。两边的负载特征完全不同，放在一台机器上就是互相干扰，而且干扰发生在最难排查的时候——两边都慢，你说不清是谁拖的谁。
结论很干脆：堡垒机要独立部署，哪怕只是一台不大的独立机器。这个成本相比它承担的角色，是极其划算的。真要省钱，可以在规格上省（前提是把三笔账算对），不要省在"独立性"上。
很多人选磁盘的第一反应是看容量：要多大的盘？这个问题问错了顺序。对堡垒机来说，容量是算出来的结果（保留期 × 日均增长），而选型要看的是写入特征能不能扛住。
堡垒机需要的写入能力分两种，要分开看。录像盘要的是"持续写稳定"：不是峰值能写多快，而是在长时间连续写入下，速度不会掉、延迟不会飙升。有些盘刚用时很快，写一段时间因为缓存写满或者垃圾回收压力上来，速度断崖式下跌——这种盘跑业务可能没事，跑录像就会在连续写几个小时后出问题。数据库盘要的是"随机小写低延迟"：关键是 fsync 延迟稳定，不是顺序带宽大。一块顺序写很强的盘，fsync 延迟可能并不好看。
这就是为什么前面强调要分盘：一块盘的调优方向是单一的，你很难让同一块盘同时把"持续大块追加写"和"高频小随机写"都做到最优。分开之后，录像盘选大容量、持续写稳定的；数据库盘选随机 IOPS 好、延迟低的。两边的钱都花在刀刃上，而不是买一块"什么都能干但什么都不顶尖"的盘。
介质上的判断相对简单：数据库盘用 SSD，基本没有讨论余地——机械盘的随机写 IOPS 撑不住高频落库。录像盘取决于规模：规模小、并发低的场景，大容量机械盘也能跑；并发高、图形协议多、或者要求写入延迟稳定，就该上 SSD。另外要考虑 RAID 或冗余策略：录像数据丢了影响的是审计完整性，数据库丢了影响的是系统可用性，两者都要有保护，但保护方式可以不同。
还有一点实操经验：买盘时留出的余量，不只要覆盖"数据会涨"，还要覆盖"运维操作需要空间"。做备份、做归档、做数据迁移、做一次紧急的数据导出，都需要临时空间。一块刚好够用的盘，在你需要抢救数据的时候会让你非常难受。经验上留三成以上的余量，并且给磁盘水位设两级告警（比如八成提醒、九成紧急），是性价比较高的做法。
先想清楚一个问题：堡垒机彻底挂掉、数据丢失，最要紧的是恢复什么？
答案不是录像，是资产和授权关系。也就是：公司有哪些机器、每台机器用什么方式连、谁能连哪些、用什么账号连、密钥和凭据在哪。丢了录像，损失的是"过去发生了什么查不到"；丢了资产和授权关系，后果是"所有人的运维工作立刻停摆"——你得重新清点资产、重新分发权限，这个过程按天计。所以备份的优先级要分清：配置和授权数据第一，审计日志第二，录像第三。
具体要备份的东西拆开看有这么几类：一是数据库全量（资产、用户、授权策略、审计日志）；二是配置文件和密钥材料（堡垒机自身的配置、加密密钥、证书）——这一项特别容易漏，而它恰恰是"恢复时能不能用"的关键，没有密钥，恢复出来的加密数据可能读不出来；三是录像数据（体量大，通常靠归档策略而不是靠备份来保）。
备份策略上三个要点。第一，备份必须放在独立的物理位置，不能放在同一台机器、同一块盘上。盘满了导致系统挂掉的场景里，同盘备份会一起完蛋。第二，备份要定期做恢复演练。这是老生常谈但真正做到的人很少——备份文件的存在不等于可恢复，数据库版本不匹配、备份文件损坏、恢复步骤缺了一环，都是到了真出事才发现。第三，明确 RPO 和 RTO：能容忍丢多久的数据（这决定了备份频率），以及多久之内必须恢复起来（这决定了恢复方案的复杂度和是否需要预备机）。堡垒机的 RTO 通常要求很短，因为它停一分钟，全公司的运维就停一分钟。
这里给一个务实的建议：为堡垒机准备一份"快速重建手册"。内容是一台干净机器上从零装起、恢复配置、恢复数据、验证可用的完整步骤。平时演练一次，真出事时照着做就行。有没有这份手册，在事故当晚的差别是几个小时和几十分钟的差别。一万网络深耕 IDC 19 年（成立于 2007 年），独立服务器租用可以按业务规划配置多盘与备份空间，具体规格以官网实时显示为准；对堡垒机这种"不能倒"的角色，把预算花在独立性和备份上，比花在更高的 CPU 主频上划算得多。
堡垒机不需要特别复杂的监控体系，但下面五个指标必须有，而且要设阈值告警。这五个数合起来，能回答"这台机器什么时候会出问题"。
第一，磁盘剩余空间与增长速率。只看剩余空间是不够的，重点是增长速率：从速率能反推出"还有多少天写满"，这才是可决策的信息。建议同时监控录像盘、数据库盘、系统盘三块，各自的增长曲线不一样。告警要按"剩余天数"设（比如预计 15 天内写满就告警），而不是按"剩余百分比"设——百分比告警在大盘上往往已经来不及了。
第二，并发会话数。这是内存和 CPU 压力的直接来源，也是容量的先行指标。要看当前值，更要看历史峰值和峰值出现的时段。当并发会话数的峰值逼近你当初的规划值时，就是该扩容的信号，而不是等到 OOM 才反应。
第三，数据库连接数与连接使用率。连接池耗尽会导致登录直接失败，而且症状和"系统很慢"很像，容易被误判。这个指标要在高峰时段重点看，因为连接池问题只在高峰暴露。顺带盯一下慢查询数量，审计页面的大范围扫描会在这里现形。
第四，录像写入延迟。这是磁盘健康的早期信号，比"磁盘满了"早得多。写入延迟升高说明盘快扛不住了、或者有 IO 竞争、或者文件系统元数据操作变慢（小文件太多时常见）。这个指标一旦持续恶化，通常意味着盘型选错了或者该分盘了，而不是简单扩容能解决的。
第五，CPU 在转码时的占用。单独看整体 CPU 使用率会掩盖问题，要看转码任务运行时的尖峰值，以及转码队列的积压长度。队列积压说明转码能力跟不上产生速度，时间长了会形成堆积，进而占用更多磁盘（未转码的原始录像通常更大）和更多 CPU。这个指标是"隐藏大户"的显形镜。
五个指标之外，补一个业务侧的检查：定期做一次"全员同时登录"的压力确认，或者至少在人员规模有明显变化时重新估算一次容量。堡垒机的容量规划是动态的，一次算完不管，是几乎所有事故的共同背景。
把常见失误归成三类，每一类都对应前面某一节的结论。这三类占了堡垒机部署问题的绝大多数。
第一类：只按人数买配置。典型说法是"我们公司二十个运维，买个四核八G够了"。这个算法漏掉了三件事：一是并发会话数通常是人数的数倍，不是等于人数；二是图形协议和字符协议的开销差一个数量级，混在一起数条数没意义；三是录像量随人数增长接近平方级，不是线性的。正确算法是分别算并发会话、录像增长、审计写入三条曲线，各自取峰值，再取并集。另外别忘了"自动化任务通过堡垒机执行"这种隐形用户，它们不占人头，但占连接和写入。
第二类：把录像放在系统盘上。这是最省钱、最省事、也最危险的做法。系统盘往往是整机最小的那块盘，而录像是增长最快的数据。后果是双重的：盘很快满，而且满了之后系统一起瘫，连远程登录进去删文件都做不到。恢复方式通常只剩控制台或者重装，代价远超当初省下的那块盘的钱。这条没有折中方案，就是必须独立盘。
第三类：忘记给审计库定清理策略。指的是只规划了"数据库放哪、多大"，没规划"数据怎么瘦身"。表现是上线时一切正常，半年后审计页面越来越慢，一年后数据库盘开始报警，而此时清理已经变成一个需要停机窗口的大工程。清理策略必须和部署同时上线：保留多久、多久清理一次、清理前是否归档、清理失败怎么告警。等到数据涨起来了再补，难度和停机成本都会高一个量级。
这三类有个共同点：它们都不是技术难题，都是规划阶段的疏忽，而且都是在系统"看起来很正常"的时候埋下的。堡垒机这种"平时没人注意、出事时所有人都在等它"的系统，规划期的严谨程度直接决定了它在事故当天的表现。
把整篇文章收成一句可执行的话：配置顺序是"先定保留期、再算磁盘、最后定 CPU 和内存"，不能反过来。
为什么是这个顺序？因为保留期是唯一一个由业务和外部要求决定、而不是由技术决定的变量。它定下来之后，录像容量就是算术题；录像容量定下来，才知道要几块盘、每块多大、用什么介质；盘定了，数据库盘和 IOPS 才有参照；剩下才是并发会话数决定内存、转码需求决定 CPU。反过来的顺序——先挑一台"看起来够用"的机器，再往里塞数据——几乎必然在某个环节妥协，而妥协的那个环节，往往就是半年后出事故的地方。
具体落地的检查清单可以这么列：一、和审计、法务、内审确认录像与审计日志的保留期，写进制度；二、按人均日均会话数和会话时长估算日均录像增量，乘保留期，留三成以上余量；三、确认有没有图形协议运维场景，有就单独算内存和 CPU；四、录像盘、数据库盘、系统盘三盘分离，数据库盘用 SSD；五、上线同时配置定时清理、归档、备份三个任务，并且都配告警；六、把磁盘剩余天数、并发会话数、数据库连接数、录像写入延迟、转码 CPU 占用这五个指标纳入监控。六条做完，这台机器基本不会在某天早上九点半给你惊喜。
最后再强调一次那个判断：堡垒机不是轻量应用，它是一台写入密集、长连接密集、数据只增不减的机器。它的规划重点在磁盘和备份，不在 CPU 核数。把它当成"业务机器的边角料"来部署，省下的是一点钱，押上的是全公司在事故时刻的修复能力。这笔账怎么算都不划算。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
