有惊无险的一次问题排除经历

来自凌晨领导的问候

- 问题在问候到达之后的一个小时之内得到了解决。

领导凌晨的问候

• 如果不是睡觉比较浅，可能真的要错过了，错过了可能就是个事故了。还好我并不是那样的人

• 开口第一句话就直奔主题，

  领导： “A表在上个版本是否存在？”
  我：“嗯，存在。”
  领导：“这个版本是否执行了删除语句？”
  我：“没有”。
  我：“是出什么问题了吗？”
  领导：“嗯，a系统发布失败了。脚本执行不通过。”
  我：“具体什么问题呢？”
  领导：“我拉个群，让运维描述下。”

  是的，这就是经典的职场对话。基本没有寒暄客套的过程，这样的沟通方式很适合我。KaTeX parse error: Expected group after '^' at position 1: ^̲ !

事情先不要急着复杂化

两分之种之后，内部群发来一张图片：
 运维：“A表执行不存在。”
 领导：“@我，尽快定位一下问题，给出解决方案。”
 我：“好的。”
 我想了两分钟之后。领导的电话再次过来。
 领导：“有解决方案了吗？”
 我：“要先确认表是否真的已经不存在了。”
 领导：“我确认过了，表是不存在了。现在是否能从以前的版本恢复表结构。再从其他地方恢复数据呢。”
 我：“嗯，表真的没有了的话，可以从之前的版本恢复表结构，数据通过消费中间件，在6点时会自动填充进去。”
 领导：“中间可能会定时任务的调度，是否会有影响。”
 我：“可能会有”
 领导：“那你教运维怎么弄”
 我：“这可能涉及到两个系统，还需要从另外的系统导出脚本。运维应该不知道怎么弄。”
 领导：“你现在过去公司需要多少时间？”
 我：“打车，大概需要40分钟。”
 领导：“实在没有其他方案，你过去一趟”
 我：“好的”

 挂掉了电话。
 此时，我心中最大的疑惑是，我并没有提交过删除语句。表怎么会不存在呢。
 我拿起了电话，拨给了运维同事。

 我：“现在是什么情况”
 运维：“脚本执行报表不存在异常。”
 我：“现在有试过版本能回退成功吗？”
 运维：“没有，回退版本就是发布事故了。你们确定要回退吗？”
 我：“先忙我确认下表是否存在。在mycat上执行下，这张表的查询语句。如果不存在的话，可能需要从以前版本恢复数据了。”
 运维： "以前那个版本"
 我：“7.5到8.0之间，需要找一下。”
 运维: “这有点。。。”
 我：“先确认下表是否存在吧”
 运维：“好的”
 
 挂断了电话。。。
 
 一分钟之后，运维过来了电话。
 运维：“表在mycat上能查询到”
 我：“能看看在那个分库上面吗？”
 运维：“怎么看？”
 我：“查询语句前面加 explain，就可以了”
 运维：“在node8上”
 我：“你之前是在node1上执行的吧”
 运维：“是的”
 我：“把脚本放到node8上执行，把刚刚的查询结果发送到群里。”
 
 我给领导打了电话过去。
 我：“找到问题了，表是存在的。在node8上。之前一直约定的在node1上。因此，我提交到了node1上。导致运维执行找不到表。”
 领导：“那怎么解决？”
 我：“把语句移到node8上执行就可以了”
 领导：“好的”
 
 挂断了电话。。。
 
 领导在群里面回复运维。
 领导：“脚本在node8上执行，版本继续发。发好了，给下消息。”
 运维：“好的，脚本已经执行了。启动应用就好了”
 
 两分钟之后，
 运维：“启动没有异常，页面可以正常登录”
 领导：“那就是没有问题了，谢谢”
 运维：“感谢大家~”
 我：“辛苦大家了~”       
 
 这件事情就此解决了。但并没有结束。
 领导私信我，明天针对这个问题，写一份报告给我。

前世今生

• 前世
  • 应用采用mycat做分库操作，约定所有配置表放在node1上面
  • 该配置表之前由另外的同事建的（已离职），应用交接给了我
• 今生
  • 不明原因的我将配置表提交到了node1上
  • 导致脚本在node1上执行失败
    现在的问题是，这样的逻辑推断真能导致现在的今生吗？答案是不能。
    从开发到测试，再到运维。事实上已经通过了两次测试，为什么都没能发现这个问题。问题的关键在于开发和测试是否到了位。

因此，我看了自己的自测环境。只添加了mycat的地址。分库地址没有提交。可就是说我是在mycat上自测完成的。
咨询了测试人员之后，发现他和我犯了同样的错误。检查配置时，默认认为配置表在node1上，测试时在mycat上执行的。

真正的问题是：开发没有真正按照文件提交流程测试，测试亦是如此。

还有一个问题是：默认配置表都是在node1上的，这个是团队级别的共识。为什么这张表在node8上了呢？
带着这个疑问，我咨询了之前的同事。反馈说，当时领导说node1上的配置表太多了，让他放在了node8上。
但是这个改动并没有在周例会上，得到体现。导致大家信息失真。
有点搞笑的是，领导到最后自己也忘记了有这档子事儿。可见一个长时间的共识的威力有多大。

能凌晨关闭手机吗,显然不能

• 问题已经得到了解决，原因已经分析清楚了。可是凌晨收到领导的问候，从梦中拉回现实的感觉。再也不想有了。
• 那么该怎么规避呢？很简单，从根本的原因入手。将噩梦掐灭在摇篮里。
• 规范开发，测试的工作流程。明确提交脚本的规范。
• 对于配置表DDL操作统一在mycat上执行，也就是提交到mycat目录下。
• 开发和测试必须要找脚本提交的规范，来进行自测和测试预演。

就是这么复杂怎么办

• 这次的问题可算是有惊无险。可是，如果我们确实遇到了很复杂的事情该怎么办呢？
• 事情的复杂度对于每个人来说都不一样。我们首先要关注的是事情根本问题所在。在此过程中，不要一味相信别人的判断和意见。
  要根据自己的经验和问题现象，大胆的猜想和验证。最终确定问题的根本。
• 确定方案之后，要善于运用资源。但不要畏手畏脚，害怕困难。同时也不要把问题复杂化。以最快的速度解决问题。
• 事后一定要复盘，总结到底是哪个环节出了问题。并指定方案规避。

感悟

• 混沌确实可能带来很多捷径，同时也隐藏着很多未知的风险。为了测试简单，开发和测试都选择了在mycat执行。却同时也带来了更大风险。花费了更多时间解决问题，和复盘问题。得不偿失。
• 秩序在具体事情的价值很大，它是效率的保证。
• 人生也是如此吧，需要发现需要自己的规则和秩序。