来自凌晨领导的问候
- 问题在问候到达之后的一个小时之内得到了解决。
领导凌晨的问候
-
如果不是睡觉比较浅,可能真的要错过了,错过了可能就是个事故了。还好我并不是那样的人
-
开口第一句话就直奔主题,
领导: “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执行。却同时也带来了更大风险。花费了更多时间解决问题,和复盘问题。得不偿失。
- 秩序在具体事情的价值很大,它是效率的保证。
- 人生也是如此吧,需要发现需要自己的规则和秩序。