QuXiao's Blog

Life && Tech && Thoughts

技术债总是要还的

Written on

事故频发的一周

这一周工作上个人感觉十分糟糕,并不是因为在技术上遇到了难题(要是这样倒好了),而是因为整整一周基本上都是在处理各种线上事故。

事故一

同事发现线上的HDFS挂了,怎么也无法重启成功,经过各种尝试服务终于恢复正常,不过有一天的数据丢失了……于是,紧急任务插入——恢复日志。由于涉及到的机器较多,数据量又较大(数量级100G+),同时又涉及到后续的各种统计。因为废了不少时间和气力才把日志都传到HDFS上面,前前后后耽误了将近3天。

事故二

发现线上一个数据上报的模块接收到了平时大约10倍的请求,怀疑是频率控制模块没有设置正确的采样率。排查频率控制模块,发现连接不上所需的ECTD服务,仔细一看,原来这个ECTD服务的机器,前两天由于机器原因迁移到了其它机器。我忘记了还有模块连接到这个ECTD上面,结果频率控制模块已经失效有2天多了……

赶紧连到新的服务器上面,但是仍然有问题。排查半天发现,是昨天其它同事上线更新这个模块的配置文件时,格式错误,导致一些逻辑没能生效,赶紧修复,最终问题才得到解决。

事故三

本着『服务化』『平台化』的理念,一些基础服务,例如存储、分布式计算、缓存,各个业务方都是共用一套。so far so good! 不过,缺点也是很明显的:就是当你的能力无法控制住某个基础服务时,如果这个基础服务出了问题,那么各个业务放就都会受到影响,或者是其中一个业务方误用了某项服务,那么其它使用该服务的业务也就受影响。

本周有同事『怀疑』我的一个使用公用MySQL的模块影响到了其它业务,表现的现象是:MySQL的 show processlist 只有30个左右,其中10个左右是我的模块创建的长链接,但是其它模块读写数据库就会变得很慢。虽然没有明确证据能证明这点,但是怕影响了线上服务,还是决定先紧急单独弄一套MySQL给我的模块使用,于是又开始找机器搭建MySQL,数据导入新库业务,最后各个模块进行数据库迁移上线。迁移之后,情况并没有本质的改变。

事故四

考虑到容灾,服务部署在了不同机房里面。每个服务在每个机房里面做到了基本同构,另外各个机房之间也拉了专线,因此可以等同于在一个大的内网里面,我们一直用得也比较爽。

不过好景不长,这周我们就发现跨机房的数据传输有问题,两个机房之前传输数据直能在100KB/s左右。这样,就导致了一些分机房进行了主从的MySQL以及HDFS,不同机房之间的节点同步就出现了问题,影响到了很多业务。最后网络组的同学查出来,就是机房之前的专线出了问题,更换了之后就恢复正常了。(事故三的问题也得到的解决……)

原因究竟是什么?

究其原因,我想至少有以下几点吧:

  1. 监控/报警不到位
  2. 文档不全面
  3. 对于基础核心服务掌握不够深入

监控和告警是保证线上业务得以平稳扩展的基础。是人写的代码,总会出错,对于一个创业团队来说,写完备的单元测试和集成测试看起来有些奢侈。前期可能只能靠人去排查,但是随着模块、业务的扩展,让人不断的『轮询』的看着线上的服务,太消耗精力了,而应该是进行『事件触发』,当没有问题的时候,大家可以专心的编码。出现了问题,可以第一时间知道,转而全力排查问题,将线上服务的损失降到最小。最近在微博上面看到这么一句话:

人管代码,代码管机器

可能场景不一样,但道理还是相通的。

文档这东西,估计只有在设计一个较大的模块或者业务时,才会想到写文档记录起来。其实,自从团队在内部使用了Wiki之后,大家还是能够留下一些文档的,但是内容都偏于零碎,大部分都是用于记录API接口字段,以及线上模块的部署,没有太多整体业务的梳理,以及类似博客一样的表达想法或者思考的过程。

对于一些技术掌握不够,别无它法,直能抽时间去学习、去实验、去总结。现阶段的节奏,其实要比项目刚刚开始的那段时间好不少,所以也并不是不能作为没时间去学习的理由。

总之,技术债迟早一天是要还的,出了线上问题,大家在极大的压力之后去现学、现修,也是一种提高的方式。但这种就像是游戏中的『大招』,虽然能解决问题,但是自己也是要『掉血』的,还是得平常多积累,这样才能比较持续发展。

-- EOF --

This entry is posted in essay.

comments powered by Disqus