端午Incident了

前言

现在，我们作为Ops 维护这一个新加坡的项目，项目还是比较复杂的。端午前一天00：00 上线了很多hotfix, 而这里面就隐藏了2个bug。

回顾

技术层面，有两个bug，一个Job运行时，数据库CPU 拉满，一个少了Redis 初始化，导致从Event Hub 发送过来的数据无法处理。

业务层面, 数据库CPU 拉满，导致业务数据无法处理；另一个Redis 初始化失败，影响到所有用户数据同步及奖励转换的问题。

数据库CPU 拉满

1

select * from "table" where columnName='value'

新的代码修改是根据数据库某一列去查找对应的数据，然而Dev 对于这一列并没有添加索引，导致在Job 运行，Job 运行时间过长，通过数据库指标的dashboard 查看，数据库CPU 爆满,进而对该Job 的代码重新review， 发现时数据库查询没有加索引的问题。

发现有问题后，我们开始分析是否可以回滚该服务；但是发现该服务还涉及到其他hotfix, 如果这个service rollback，那么还有其他2个service 也需要回滚，影响面比较大。最终，我们的解决方案是，hotfix 依旧上线，但是涉及的Daily Job 从任务中删除，通知客户该incident 的影响面，并且在第二天晚上定时任务执行的时候再次确认是否又执行了; 对于在新的fix 上线之前的报告，我们使用手动生成的方式,以使业务持续。

是不是感觉不应该出现这样的问题？

是的, 但为什么还是出现了这样的事故呢？个人认为原因很简单:

• 在low env 没有足够的数据对新的代码更改做充分的压力测试，只是完成的对应的功能
• Review 时没有发现该问题，不可否认，这完全是Reveiwer 的经验问题

Redis 没有初始化

关于这个问题，我们的应用程序在代码层面有两方面的设计，1，启动server, 向外部提供RESTful 服务；2，启动Agendash, 运行一些业务方面的定时任务。

而我们的更新就是去优化这个服务，在应用层面分为2个服务，并且保持运行Agendash 的pod 数量与Event Hub partition 的数量一致，以解决一个消息被重复消费的问题（虽然很tricky）。

团队使用的方式是，参考之前某一个服务的拆分策略，业务代码，Ops 部署代码都进行双份设计，在启动服务时，启动不同的脚本即可。方式很简单，只是抄代码，抄逻辑。

然而，团队在做code fix 时，没有将代码抄全，导致少了 initRedis() 这样的代码；又因为团队对对应的业务了解的不多，没有进行充分的上线前的测试，只是凭Senior dev 的感觉就上线了。

为什么呢？

• Dev 对抄过来的代码在思想上很有信心，但是没有经过验证
• 没有在本地测试
• 没有充分的业务测试，甚至没有测试
• Senior dev 可能粗心没发现

这个过程中，因为负责这个code fix 的是个Junior Dev, 而在那段时间，我们有新的Senior Dev 要上项目，所以两人Pair 一起修bug。

Standby

为什么需要Standby 呢？

增强信心

如果你是第一次遇到Incident，是不是会害怕?

• 这个问题到底是怎么发生的？
• 这么多人问我这么多问题，我忙不过来，会不会被客户投诉？
• 标准的处理流程是什么？
• 这个业务我不了解，我该不该叫其他小伙伴一起看？
• 出了线上事故了，项目组或者公司会不会处理我？
• ……

想到这些，你是不是已经很恐慌了？相反，如果有人和你一起追踪这个问题，你又是什么样的心态呢？

及时响应

正如上面所说，在出现Incident 的时候会有很多事要做，比如查询根因、处理各种leader 发过来的问题，是不是感觉一个人根本忙不过来？

所以，如果有其他小伙伴和你一起standby, 那么是不是可以将工作分配一下，对客户、leader 的问题及时做出响应；起码给别人你很靠谱的印象, 提升自己、团队甚至公司在这方面的声誉。

收获

在数据库中查询，基本都需要考虑加索引

凡事查询，在没有加索引，且数据量上去之后，查询一定会变慢，这种情况下需要根据biz/tech 的策略加索引。

在出现Incident 时，全员应该随时支持，所谓Standby

在这次的Incident中，团队并没有及时的Standby，需要提升这方面的实践和认知。所以后续需要在团队内进行Incident 培训，让大家知道如何处理Incident。同时Standby 是一种负责人的态度。

没有所谓的简单的工作

不要在不了解事情的情况下，随便说"这不是很简单么"这样的话；说的越轻松，打脸往往来的越快。

不要责备

就像Thoughtworks 所倡导的，出了问题, 不要针对个人，不要问"9：00～10：00, 你在干嘛" 这样"地震级"的问题；而应该去分析为什么会出现这个Incident, 以后怎么避免。

总结

在Ops 项目中遇到Incident 应该是在平常不过的了，那么处理Incident 的过程中，流程和人才是最重要的。将流程标准化（SOP）,鼓励团队积极响应，认真分析，产出修复方案，做好事后事故报告(Incident Report)这些才是最重要的。

Refs

• 博客:https://guzhongren.github.io/

Disclaimer

本文仅代表个人观点，与 Thoughtworks 公司无任何关系。

SHA256 checksum: f2fe1394e4ab9297ed69ff73ac32e9ac1375f01c2102183b509bf9379a5995d6

赞助

SHA256 checksum: 964978ecd2059064abe542e51dc02e204d3ee2e6c320ca68e2b1399ce0c6953c

使用此文件进行校验： gpg --verify PayForGuzhongren.svg.sig