Skip to Content

An-Accident-Triggered-by-a-String

Posted on

今天下午健身回来想着注册线上的search server到zk,让prometheus去拉metrics,然后由于申请机器权限的系统经常性的抽风,申请登录机器一直不成功(老牛鼻子问题了,他们就是不修),然后就想直接更新zk的数据,反正脚本也是这样,然后就到了consule的UI上(我也不知道为啥consul的UI跟ZK的数据是连着的),直接创建对应的key。

创建完成之后发现并没有卵用,过了一会儿就被打岔喊道了楼上去(现在想起来,如果不上去的话会不会自己就把key给删了?但大概率会忘掉!),说了一会儿之后正巧他们出故障了,隐隐约约听到了我们组的名字,妈的瞬间就精神了,这不是我刚才建的key吗,卧槽我是不是闯祸了?

仔细听下去,果真。日。


事情的起因是我想注册我们的search server到ZK,让prometheus去拉数据。

经过是没有登录到注册zk的机器上,然后就手工写错了注册的path和value。

结果导致平台组负责服务发现的程序崩溃?

程序期待一个JSON,我写了一个string,然后程序就崩溃了。贰叁叁。

最终导致订单系统停止服务五十分钟。(讲道理五十分钟才解决这种故障也是……)


然后群里领导们就在讨论如何避免以后类似问题的发生,说如何限制zk的写入,如何提交ticket,如何更新服务发现等等等等。

我就想,这难道没有work flow和programer的责任吗,每个人都能写线上的ZK不太好吧?这么简单的异常,程序没有正确处理而是直接崩溃不好吧?花费五十分钟还顺带回滚服务(当然没卵用了也)才解决问题也不好吧?最终我(导火索)如果没有恰好站在旁边背锅,也发现不了是怎么引起的bug也不太对吧?

洋洋洒洒都在讨论auth的问题,真是,醉了。

服务发现用ZK本来就值得吐槽了,而且各种服务都写ZK,不区分国家和服务类型,把ZK当银弹用,还是一颗,这么明显的问题都没人提出来,也没人说程序写的有问题,(这么关键的程序,感觉像是随便写写的),深深的觉着领导层有点本末倒置。

普林西普的刺杀引发了一战,但讲道理,让普林西普背一战的锅就说不过去。当然也没人让我背锅,我只是觉着导火索就不应该存在,把潜在的问题扼杀在摇篮中是最好的。因为这次可能是我写string,下次可能就是程序写int,在下次可能就是黑客直接递归删key了,暴露出这么多问题,一个auth能解决?一个disable能解决?

服务发现本来就很复杂,etcd都能被打挂,zk也不是万能钥匙啊,况且还不分区。这么关键的核心服务连这种异常都hold不住,也难怪天天修bug。

我肯定是要被批评的,因为我写的key嘛,就像上次99时候DNS挂了,一个更改防火墙的DBA背锅一样。


几点经验教训:

  1. 对核心数据的权限控制:什么样的人能干什么样的事儿,该干什么样的事儿要有明确的划分。
  2. 对数据的隔离和分区:不要把鸡蛋放在一个篮子里,老生常谈了。
  3. 核心程序的code review和至少80%的单元测试:不要让这么低级的异常把整个系统搞挂。
  4. 关键数据的备份要做好:实在解决不了问题咱回滚数据行不行?
  5. 还是告警,还是日志,错误处理不是说说那么简单的。
  6. 服务发现是个大事儿:别用zk,用etcd。
  7. 哪怕是内部服务,也不能完全可信,尤其是带有网络调用的,数据验证是基本操作。
  8. 出问题是好事儿,跌倒也是好事儿,但出了问题不总结就不是好事儿,总结不到位也不是好事儿,就像明明是脚上扎了钉子,却一直想办法如何修路。早点暴露问题就能早点修复,以免在更严重的时期触发问题;早点跌倒就会早点反思,而不是拖着一只被扎穿的脚彳亍。
  9. 最重要的一点也是针对我的一点,没事儿别瞎搞,对于不了解的东西要如履薄冰,如坐针毡,没准你就是最后一块被抽掉的积木。
comments powered by Disqus