北京
分享至
服务挂了，团队的第一反应出奇一致：重启、扩容、加重试。这三板斧像条件反射，按下去系统就活了，警报停了，大家松口气下班。问题是——这根本不是修复，是麻醉。
Yuvraj S在博客里写得很直白：「The first fix doesn't solve the issue」。系统看起来稳了，只是症状被压下去，病根还在代码里躺着。过两周同样的故障再来一遍，团队才意识到上次在浪费时间。
这种救火模式有个隐蔽的成本。每次临时补丁上线，技术债就厚一层，直到某天架构扛不住，需要整体重构。那时候花的功夫，够修一百次根因。
他观察到一个反直觉的现象：愿意让系统多崩几分钟、先查日志的团队，长期故障率反而更低。慢一步，是为了以后不用跑一百趟。
评论区有人补了刀：「我们组把『先重启』写进了on-call手册，结果去年同一个模块崩了11次」。手册没改，人已经换了两拨。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
