HGAME 2026 运维秘话
前情提要
又一年的 HGAME 结束了！HGAME 是一个历史悠久的比赛了，有幸作为 HGAME 的运维还是很高兴的。
今年我们继续使用了 rx 佬的 ret2shell 平台。在我负责 Vidar Team 相关赛事的运营后，我一直希望平台能够维持稳定的长期的运营。HGAME 系列赛事几乎贯穿全年，从 MINI 的 8 月一路到 Final 的 4 月，每次都用新的平台也不利于数据的继承。
在非赛时，我们的平台会运行在协会的 PVE 上的一个 VM 中，并通过种种奇技淫巧反代到我们的公共外网服务器上。
意外和选型
美好的原计划
今年的比赛赛制继承了去年，由于已经没有提早开放平台或者关闭平台的概念，主要的问题就是如何维持赛时两周的负载。
同样继承自去年的还有来自杭电网络与计算协会（ICU）的支持，不过 ICU 的支持是要走流程联络的。今年是我和 NaCl 负责，这方面的进程在当时的我看来出乎意料的慢，现在来看应该是催的不够紧，还是不够理解学校的办事方法。
基于去年的成熟经验和杭电网络的现实情况，一开始的想法是这样的。从协会 PVE 迁移上云，前期完全上云，择机从云上迁移到协会 PVE 和 ICU 机器构成的多节点集群。
这里的困难其实是如何无痛迁移，数据库和队列尚且好说，ret2shell 会需要一个本地目录存取题目信息等数据。正常来说，一个 local-path 的 PV 想要迁移到另一个 node 是不可能不停机的，除非我们引入分布式文件系统。但是我相信，引入分布式文件系统带来的不稳定性很有可能大于短暂的停机。
但我们的比赛两周间有一段休息，尽管本意不是给运维天窗，但是实践上是再好不过的天窗了。
意外
在寒假离校前一两天我观测到了 PVE 重启会有概率性问题，包括但不限于随机的显示输出，无法使用 PVE 中的 shell 等。为了确保在赛时 PVE 的相对稳定性，我随手挂了个 memtest。然后它就爆炸了。
事后在协会的人说这个东西已经发出焦味了，祝它安好。土豆哥语重心长的告诉我 memtest 是高危操作，也算是经验吧。
总之在经过紧张的数据救援后（感谢 mantle 以及有过帮助的人），我们成功的捞出了承载 HGAME 的虚拟磁盘，并利用其在 ICU 新开了一个 VM。
现在要从头考虑选型了。
新的选型
既然情况已经是这样，上云的进程就被大大提前了。问题是我们不再有协会的 PVE 作为后期下云的节点，这将会浪费一个我们在 ICU 的虚拟机。
但是也可以考虑保留一个云上节点作为集群的 master，这样就可以避免迁移带来的较高代价。
为了保证开赛的稳定性，我还做了几次大批量开关靶机的压测。
现实
CDN
在前人来看，CDN 是一个艰难的抉择，毕竟要钱。
但是感谢腾讯云 EdgeOne，今年直接免费版嫖穿，中间零零散散的来自世界各地的不友善流量都被挡住了。
加上我写了超级激进的缓存规则，基本上除了 API 全部拉进缓存了，这使得对源站的压力出乎意料的低。
下云
正如前人所说，赛时运维是不可不评的一环。尽管在云上的时光非常顺利，终于在我手上，HGAME 平稳开赛了一次。
但是问题是真的太贵了，全云预计要 1500cny 才能打住。所以下云的计划提前了。
在准备下云的时候，我们云上有三个机子，一个 master 两个 node。理论上将 k3s 高可用然后就可以添加新的 master 并逐步 cordon 掉云上服务器了。
但是实践上没有这么简单。我在做完这一套操作后惊奇的发现在 pod 里可以任意包大小 ping 通每一个 node，但是唯独连不通 k3s api。
这听起来很奇怪，在没有引入其他控制平面的情况下，理论上 pod 的流量总是要过 CNI 的，怎么会 node 间互通但是 api 不通呢。
大调查的结果是，k3s 对于自己的 api 是通过 iptables 转发到某个 node 的 external IP 的，并不会过本机的 nat，这意味着对于 CNI interface 的路由措施会无法生效。特化调整即可。
另一个值得一提的是，k3s 的高可用集群要求必须有奇数个 master 以投票出集群中心，迁移的时候要注意维持节点个数。
机器的局限性
下云后发现学校的网络还是会有意料外的 RST，最终还是选择保留一个云上节点作为转发机。在此之后一切平常，直到 Week2。
Week2 开始前我就收到一些出题人指出，原本在云上测好的 Week2 的题目现在跑不通了。一开始自然怀疑是资源没给够，放大资源占用也确实好了 – 但是要放的很大。随着测试的进一步进行，又跑不通了。上服务器一看只有大量的 hang。
一个自然的怀疑是硬件问题，但是在 ICU 迁了个机器还是有类似的问题，我意识到 ICU 的机器性能还是有局限性的。不得已只能把留在协会的自用机器拉入集群，才算缓解了这个问题。
学校的奇妙网络
学校的网络奇妙之处不仅在于意料外的 RST，还在于学校分配的 IP 在学校内无法连接。这意味在协会的机器和在 ICU 的机器间联络很困难，特别是在还有一台外部转发机的时候。
如果选择将公网 IP 作为 external IP，那么校内就会有连通性问题，反之亦然。最后只能手动添加隧道来统一这个问题。
结算
比赛可以说是平稳的结束了，两周的运维工作也终于迎来尾声。虽然对 ICU 的机器和学校的网络有这么多的吐槽，但是还是很感谢 ICU 和学校能给予这么多支持。希望之后的运维能够着手解决这些问题吧。
虽然比赛大部分时间都以云下机器为主，但是由于 PVE 损坏导致的上云时间提前还是消耗了不少资金，总体来说和去年是持平的，可喜可贺。
感谢各位选手和出题人的努力以及对比赛平台波动的包容。
附录
Agent 的相关讨论
和 HGAME 同一时间的比赛还有 HPCGAME，后者显然被 agent 梭穿了，而 HGAME 也没好到哪去，榜上前几和大部分 writeup 都有明显的 AI 痕迹。
我对在此类比赛中使用 AI 的态度很微妙。首先没有道理禁止，因为比赛是现实场景的预演，你现实能用 AI 凭什么比赛不能用。
但是也更没有道理支持，比赛本身是给人增长环境的地方，在 AGI 的牛逼吹到之前，人终究还是要增长自己的水平以完成复杂的工作。以往正常的途径是：学习 -› 打比赛 -› 查漏补缺 -› 打比赛 -› 排名上升，这构成了一个正反馈循环，如果一个人愿意去尝试这种循环并坚持几轮，选择不断精进自己的技术是必然的。但是现在打比赛变成了把题目丢给 Agent 甚至不管，这个反馈就被打破了。这对新人来说无疑是艰难的，学习的反馈消失了，但是学习的必要性姑且还存在。
我也没有什么好的办法处理比赛中 Agent 的使用，说句难听话，其实如果选手有意要藏，也看不出来用了 Agent。只能说希望大家能够接着在各式各样的经历中精进自己，不被拍死在沙滩上吧。