我从高级软件工程师身上学到的那些经验与教训
|
这是个关于搜索与 SQLAlchemy 的故事。在 BNEF，我们需要处理大量由分析师们撰写的研究报告。每当报告发布时，我们都会收到一条消息；在收到消息之后，我们会通过 SQLAlchemy 进入数据库，获取我们需要的全部信息，进行转换，并将结果发送至 solr 实例进行索引。但这时候，我们发现了奇怪的 AF bug。 每天早上，连接数据库的操作都会失败，消息提示“MYSQL 服务器不存在”。有时候连下午都会出现这种状况。由于下午时段的使用量最大，所以我首先进行了一番检查。没问题，机器的运行状态一切正常。我们全天会向数据库发出数千次请求，都没有失败。那么，为什么负载强度这么低的情况反而会出问题呢? 哦，可能是我们在事务结束后没有关闭会话？所以失败其实来自同一段会话，只不过下一个请求出现在很长一段时间之后，这就引发了超时——因为此次服务器已经关闭了。快速查看代码，我们通过上下文管理器检查了每一次在 exit() 上调用 session.close() 的读取操作。 经过一整天的排查，没发现任何问题。在第二天早上，我又遇到了同样的情况。错误发生的一秒之后，其他三项索引请求都成功了。这明显就是会话未能正确关闭的典型表现。好了，相信大家能够脑补出接下来的完整故事。 SQLAlchemy mysql 语言中的 Session.close() 无法关闭底层数据库连接，除非使用 NullPool。是的，这就是修复方案。 引发这个 bug 的原因很简单，这是因为我们不会在夜间以及午餐时段发布研究报告。此外，我们也吸取到另一个教训——大多数堆栈溢出问题的答案（我是从谷歌上查来的），正是 bug 本身会调整会话的超时时间，或者控制每条 SQL 语句所能发送数据量的参数。这些对我来说都没有意义，因为它们与问题的根源无关。我检查了查询大小是否在限制范围之内，而且由于会话本身正在关闭，所以也不会发生超时状况。 我们当然可以把超时时间从 1 个小时增加到 8 个小时来快速“修复”这个 bug。但这显然解决不了问题，到第二天早上，又会有研究报告引发的错误出现在我们面前。 一边是调整参数与查看统计数据，另一边是修复底层问题根源。这就是我们的日常生活。 监 控我之前从来没想过监控也会归自己管。坦白讲，在接受全职编码职位之前，我从来不管系统维护这些事。我只是构建系统，用上一个礼拜，然后再换一套系统。 现在，我日常使用的是两套系统，其中一套拥有良好的监控机制，另一套的监管机制则比较差。通过实际体验，我感受到了监控的重要意义。毕竟如果意识到问题，我又怎么能解决问题呢？最差的情况，就是连客户都发现 bug 了，我自己还蒙在鼓里。“我在做什么？！我连自己的系统出了问题都不知道？” 我认为监控机制主要包含三大组件——日志记录、指标与警报。 日志记录以代码的形式存在，类似于人类记录，这是一种渐进的过程。 我们可以找到需要监控的内容，记录这些内容，同时运行系统。随着时间的推移，我们可能会发现自己缺少某些解决 bug 所需要的信息。这正是调整日志记录的好机会——我们忘了记录哪些重要的内容？ 我认为，最重要就是直观地理解哪些内容值得进行记录。作为我的观察对象，他（标题中的高级软件工程师）和我在记录服务方面的想法有着很大的不同。我认为记录请求 - 响应就足够了，但他却列出了很多指标，比如查询执行时间、代码中的一些特定内部调用以及何时轮换日志等等。很明显，如果没有日志记录作为参考，我们几乎不可能进行任何调试工作——如果我们不清楚系统的当前状态，重建系统自然也就成了痴人说梦。 指标可以从日志当中提取，也可以在代码当中单独建立。（例如将事件发送至 AWS CloudWatch 以及 Grafana）。大家可以自行设定指标，并在代码运行时发出对应的数字。 警报则是将所有内容整合在优秀监控系统中的重要粘合剂。如果某项指标代表着当前正处于生产状态的机器数量，那么这个数字下降到 50% 则代表着一种严重警报——肯定是出了什么大问题。失败计数超过栽个阈值？又会有新警报给我们发出提醒。 这样我就能安心睡觉了，因为我很清楚即使出了什么问题，系统也会马上提醒我～对吧…… 而这中间又隐藏着另一种重要的习惯。在修复 bug 时，我们不应单纯关注如何解决问题，而是为什么我们没能早点发现？警报有没有及时提醒？如何更好地设置监控以防止出现类似的问题？我到现在也没弄明白如何监控 UI。目前的组件选项还无法了解问题究竟来自哪里。而且，仍有相当一部分问题是由客户上报过来的——这里头肯定还有提升空间。 总 结过去一年以来，我学到了很多。在开始撰写这篇文章时，我很高兴自己接受了这份新的工作。动笔的过程中，我也深切体会到自己的成长。希望大家也能从这篇文章里获得一点启发！ 我非常幸运地加入了一支优秀的团队——我们完成了大量编码工作、我们每天都过得很开心、我们从零开始设计系统，我们也与很多其他团队携手协作。 今年，我身边又多了一位高级开发人员。我很期待能学到更多重要的心得。多谢啦，我的团队！ 优秀的工程师能够设计出更健壮且更易被他人理解的系统。这将带来乘积效应，帮助同事们更快更可靠地构建他们的工作成果。- *如何构建良好软件（How to Build Good Software） 【编辑推荐】
点赞 0 （编辑：厦门网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
