Skip to content

2019 10 12 道友登陆验证服连接数解析 AAR

1618 字
   

步骤一:当初行动的意图是什么(What was the intent) 当初行动的意图或目的为何?当初行动时尝试要达成什么?是怎样达成的?

我们希望通过一系列,各自发现的信息和推测,不断地同步,来解决问题。

当初的行动意图是,通过运维方面的分析和配置调整,解决潜在的宕机风险。

实际结果是,通过分析和推演,确认了现象产生的原因,并解决了潜在的单节点隐患。

步骤二:发生了什么(What happened) 实际上发生了什么事?为什么?怎么发生的?真实地重现过去所发生的事,并不是容易的,人类的知觉与推论历程是有很多偏误的,而且不同人所看到的常是不同的。

19:50分 国锋同学来电,说明发现了登陆服两台服务器的连接数存在问题,需要协助排查。并在MM里发了相关截图。

关键点在于一号服务器和二号服务器的连接数比例异常,为5:1900。国锋怀疑是一服正常,二服异常,而且二服的连接数还在不断上升,可能存在宕机的风险。

19:55 德文同学当时正在泳池准备训练,收到消息后中止了训练,开始返家,路上在持续和国锋同学交流具体情况。

20:30 左右,德文回到家里,计划利用VPN远程连接到公司进行问题排查,结果因为笔记本的MacOS升级到10.15之后,深信服的VPN软件无法正常使用,又消耗了不少时间在解决远程连接的问题,最终在深信服论坛找到了临时的解决方案,连接到公司。结果又遇到Windows10升级后没有重启,导致办公电脑无法正常远程连接。

21:00左右,德文开始设法用阿里云的后台直接进行分析操作。发现了登陆验证服一号服务器并没有被加入负载均衡的后端服务器中(原因是因为早期的黑客攻击,迫使当时将一号服移除业务,黑客伏法后,也没有再将其重新加入),将一号服务器重新加入负载均衡。

观察监控数据,没有发现特别异常的负载波动,未发现被攻击的迹象,未收到用户登陆异常的反馈。

根据过往的经验,在目前稳定运行的情况下,出现突然意外宕机的风险概率相对较低,由于国锋同学以及回家,暂时就没有在跟进。

2019-10-12 9:00 开始持续排查问题,发现一服的连接数上升到50,而二服的连接数为400,这依旧不符合负载均衡的1:1预期

排查问题,梳理架构,最终符合预期的架构因为:

需要调整的配置为:

  1. DDos高防的19235端口,增加1号服IP,
  2. 负载均衡器的后端服务器,增加1号服

后续的跟进:

连接数比例趋近1:1,达到合理预期。

国锋发现服务器日志里存在大量报错,已经累计超过5G,德文推断可能是负载均衡器的健康检测,在自动嗅探游戏端口是否开放,产生的大量记录。然后进行了验证:

  1. tailf sals.log ## 持续观察输出日志,发现日志刷新非常之快
  2. 阿里云后台调整健康检查的监听端口,将其指向22端口,持续观察输出日志,日志的记录恢复正常
  3. 重新将健康检查监听端口恢复,日志刷新恢复到第一阶段的状态。

步骤三:从中学到什么(What have we learned) 我们从过程中学到了什么新东西?如果有人要进行同样的行动,我会给他什么建议?

看到的现象不一定是问题,现象后面的运作规律,才是问题的本质。这次事件的本质问题,是连接数的比例不符合预期的1:1

操作系统升级后可能会遇到一些软件兼容性的问题,升级之前要提前准备,升级之后要及时检查,避免尴尬。

行动建议:不要急着该配置调参数,先找出自己预期的结果,然后根据结果去倒推,找出现象背后的运作规律。

步骤四:可如何将学习转化为行动 (What do we do now) 接下来我们该做些什么?哪些是我们可直接行动的?哪些是其它层级才能处理的?是否要向上呈报?另外,可采三种时间长度来辅助思考:

  • 短期行动-设法恢复Mac系统下的VPN软件使用
  • 中期行动-暂时没有
  • 长期行动-暂时没有

步骤五:采取行动(Take action) 知识是存在于行动中的,知识必须透过应用才会发挥效用,必须产生某些改变才是所谓的学习。

采用的套路和核心逻辑:

  1. 逆向工作法
  2. 洞穴寓言

步骤六:分享给别人(Tell someone else) 谁需要知道我们生产的这些知识?他们需要知道什么?杠杆性地把“有用知识”有效地传递给组织其它“有用的人”。

分享给运维、IT团队和P22团队,记录企业文化案例。