鉴于稳定性原则，我们知道如果必须架设互联网比赛服务器，那就要选择十分信得过的部署方案。很显然，韩国的比赛服务器是值得考虑的选择。这是一个仅供职业比赛使用的环境，和韩国公共服务器位于同一数据中心，并常用于LCK韩国联赛。同样这也意味着这个服务器有无数小时的运行数据来验证其网络的良好连通性和架构的可信赖性。所以当至少有一支队伍需要远程参赛时，用这个节点是合理的。但接下来的问题是，是应该在所有比赛中使用它，还是只针对远程比赛使用。这便引出了策略二：最小化网络风险。
策略二：仅在必要时使用远程参赛，最小化网络风险
在之前的策略中，考虑到某些比赛需要在互联网环境中进行，那么问题就变成了：“何不统统放在这个环境下呢？”这个答案很简单：互联网的可靠性。互联网有时候风平浪静，有时候则未必。如果所有季中冠军赛比赛都在互联网服务器上进行，那么任何网络问题都可能导致比赛在进行中出现问题。如果只是远程比赛通过互联网进行，那网络出现问题的概率就会大大降低。我们相信通过我们的计划，能够将风险降到最低。由于我们相信我们有能力通过使用人工延迟来实现ping值在同等竞赛环境，所以这只是一个复杂性与可靠性的简单问题。为了实现更低的风险（减少互联网的不可靠性），我们增加了一点复杂性（两种网络架构设计）。
考虑到这两种选项，并基于我们的评估，我们决定采用策略二，它能够为赛事的可靠性和竞赛公平性带来最低的风险。
下方的图表就是我们所选择的网络架构设计，展示了在不同情况下网络是如何链接运行的。
最合理方案
考虑到以上种种因素，我们决定在使用人工延迟服务并维持竞赛公平性的情况下支持两种不同的网络架构设计。两支都在场馆的队伍比赛时，将使用架设在季中冠军赛场地内的本地服务器。而对上远程参赛队伍时，对战双方均在韩国数据中心的比赛服务器上进行比赛。拳头游戏电竞技术团队设置了系统并进行了基础架构测试，以确保一切运转正常。其中包括了各种测量和监控，如 ping值、网络抖动，以及对丢包的仔细检查。我们也让队伍在这个比赛服务器上进行训练赛，并让他们来到现场，进行技术测试。
但在第一比赛日结束后，选手告诉我们，比赛的时候感觉很卡。部分选手表示，即便游戏屏幕上显示 35ms，但实际体感却高于 35ms。当时我们所有的日志和基础架构监控显示一切正确，但我们决定继续调查，找出问题的原因。
找寻漏洞
引起这些问题的原因还是不清楚。由于架构监控工具并没有汇报错误，但我们却收到报告说比赛很卡。我们缺少特定漏洞或特定游戏内情况来定性。于是我们又回到了基础问题上。哪些数据是可用的？我们手里都有哪些日志？我们能收集到什么信息？
对此我们采取了两步走的做法。首先是向参赛的职业队伍收集问题，帮我们理解情况，到底哪里出了岔子。你们是在哪儿发现问题的？是场馆服务器还是比赛服务器？是场馆网络环境还是训练赛环境？是所有对局都这样？还是只是个别情况？与此同时，因为标准报告没有显示任何错误，所以我们开始查看其他日志和指标，寻找任何可能的差异。我们也提取了赛事客户端和服务器端的日志，并开始深入研究。
举个例子，我们曾假设问题是，也许游戏服务器没有保持稳定的帧率。于是我们提取了日志，并将数据放入一个查看工具中，把数据可视化为上面的图表（如上示意）。它显示了我们在每场比赛中都有非常稳定的帧率。所以这并不是职业选手报告的问题原因。
查阅日志是一项极其细致而艰巨的工作。数据本身看起来就像一页又一页看似随机的数字流，必须通过各种工具进行编译，将其可视化，使其有意义。每一轮的彻查，我们都没有发现异常。
