一次线上事故的 24 小时

这篇我按时间线写。事故发生在两年前一个周四晚上，我做的是主要排查人。时间是我从聊天记录和监控截图里对出来的，误差不超过两分钟。 21:47 报警群里第一条消息：接口平均响应时间从 80ms 涨到 1.2s。我当时在洗碗，手机响的时候手是湿的。 21:53 打开监控。错误率还不高，只有 0.3%，但
作者：早睡失败者
分类： 技术笔记

一次接口性能从 3s 优化到 200ms

这是一次完整的排查记录，我尽量把每一步的数字都保留下来，因为我觉得这个过程比结论有意思——没有任何一步是决定性的，是六个小改动堆出来的结果。 起点 一个列表查询接口，平均耗时 2.9 秒，最慢的能到 6 秒。前端加了骨架屏也救不回来，用户投诉说点一下要等好久。 我做的第一件事不是看代码，是在方法里埋
作者：键盘上的猫
分类： 技术笔记

一个小工具，帮我省下每天半小时

我做过很多没用的轮子，但有一个例外。它一共 130 行，从写完到现在跑了两年多，我几乎每天都用。 它解决的是一个很蠢的问题 那阵子我负责的服务分布在四套环境，日志分散在若干台机器上。每次排查问题的流程是这样的：打开跳板机、想一下这个环境的机器地址是哪几台、逐台登录、切到日志目录、按日期找文件、用关键
作者：晚风信箱
分类： 技术笔记

定时任务的那些隐藏陷阱

有天早上我被电话叫醒，说昨晚的对账结果全是错的。原因是：凌晨 2 点的对账任务那天跑了两次。 为什么跑两次？因为那天是夏令时切换日，某个时区的凌晨 2 点出现了两遍。 这是我职业生涯里最哭笑不得的一个 bug，也是我开始认真对待定时任务的起点。在那之前我一直觉得定时任务最简单——不就是到点执行一段代
作者：键盘上的猫
分类： 技术笔记

关于「技术债」，我的理解变了

刚工作那几年，我把技术债理解成一个道德问题。看到烂代码就来气，觉得写的人不负责任，觉得项目就是被这些人拖垮的。我甚至私下列过一个清单，记录哪些模块该重构、谁写的。现在回头看，那个清单挺幼稚的。 让我改主意的一段代码 有一年我接手一个模块，里面有个硬编码的映射表，把十几个业务代码映射成显示名称，直接写
作者：阿柴不加班
分类： 技术笔记

一次线上内存泄漏的排查记录

这是我今年排查时间最长的一个问题，前后大概花了四天，其中有两天完全走在错误的方向上。按时间顺序记一下，主要是给未来的自己看。 第一天：现象 运维在群里说，有个 Python 服务最近每隔一天半就要被 kill 一次。我拉了监控图看，进程 RSS 从启动时的 380MB 一路匀速爬升，大概 40 小时
作者：一只猫饼
分类： 技术笔记

分布式锁：看起来简单，其实不简单

那天早上运营找过来，说有个用户的额度被扣了两次。我看了一眼日志，两条扣减记录时间戳差 40 毫秒，来自两个不同的实例。加锁的代码明明就在那儿。 后面几个月我把这个东西从头到尾踩了一遍，记录一下每一层是怎么塌的。 第一层：只加锁，不设过期 最朴素的版本：用一个原子的「不存在才写入」操作占位，成功就是拿
作者：树懒先生
分类： 技术笔记

单元测试写不下去，通常是设计有问题

我先把结论放这儿：当你觉得一个函数「没法写单元测试」的时候，问题几乎从来不在测试上，而在这个函数本身。 这个观点我以前是不信的。我信的是「这段代码逻辑太复杂了，测试成本太高，先上线再说」。直到有一次，我为了给一个函数写测试，写了 140 行的 mock，测试代码是被测代码的三倍，而且每次改一点实现，
作者：键盘上的猫
分类： 技术笔记

正则表达式：又爱又恨

我电脑上有个文件叫 regex.txt，从 2016 年记到现在，一共 73 条。每条上面都有一行注释写着这玩意儿是干什么的。这个文件的存在本身就说明了一切——正则是我唯一需要给自己写备忘录的语言。 先说爱 爱它的时刻通常长这样：某天下午，产品拿来一个 40 万行的日志文件，说想知道有多少个用户在支
作者：晚风信箱
分类： 技术笔记

从面试题里学到的东西

我这些年面过大概两百个人，也被面过三十几次。有意思的是，我从面试题里学到的东西，大部分不是在准备面试的时候学的，而是在出题和听答案的时候学的。 下面挑四道题讲，每道题背后都有一个我认知被更新的瞬间。 题一：写一个函数判断字符串是否为回文 这题烂大街，我曾经觉得它毫无区分度。直到有一次，一个候选人写完
作者：树懒先生
分类： 技术笔记
共 44 篇文章
页