大多数监控面板显示的是平均响应时间，但平均值会平滑掉大量小数值，把真正影响用户体验的慢请求盖住。在大规模系统里， 尾部延迟 （tail latency，最慢的那一小部分请求的响应时间）比平均值更能反映真实状况。作者学到的第一课，平均延迟好看不顶用，用户实际感受到的是尾部的慢请求。

响应偶尔很快但不稳定，比稳定但稍慢更糟糕。因为你的下游服务和调用方依赖的是可预期的行为，如果系统有时 10ms 有时 5s，调用方只能按最坏情况做超时和重试，整体效率反而更低。稳定的慢不算大事，规划和容忍都没问题。不稳定的快才真要命。

故障发生时每一秒都珍贵。如果架构足够简洁，你扫一眼就能判断问题出在哪个环节，不用在多层抽象和间接引用里绕来绕去。教科书不会告诉你的那些设计取舍，像应用和环境的交互、服务之间的深层依赖，只有在线上故障的压力下才真正暴露出来。真到那时候，你有时间慢慢查吗？简洁架构的价值就是让你在最没时间思考的时候，能最快想清楚。

作者列了四个方面，全都是在设计阶段就得想好的事，不是上线前两周能补的，

• 可观测性 ，日志、指标、链路追踪的接入点要在代码结构里预留好，而不是出事后才到处加埋点
• 一致性配置 ，所有环境的配置走同一套模板和管理流程，而不是每个环境手改
• 自动化就绪 ，部署、扩容、回滚这些操作从一开始就设计成可脚本化的，不留只有某个老员工知道怎么操作的手工步骤
• 合理的默认值 ，连接池大小、超时时间、重试策略这些参数，默认值就应该适合生产环境，而不是拿开发环境的配置上线

这些在出事之前看起来都是可有可无的事，但等故障来了，你就会发现没有它们什么都干不了。作者的工程品味始终带着运维的视角，即使不再 oncall 了，这种眼光也一直没丢。

Twitter 早期把时间线存在 Memcached 里，这些对象长度不固定，随时间不断增长。定期重启 Memcached 释放内存是必要的维护操作，但重启本身也可能触发全站故障。有一次他的失误导致别人花了几小时救火。他没有找理由也没遮掩，直接承认是自己的问题。结果出乎他意料，没有指责、没有追责，同事反而更信任他了。他后来才明白，出了事大家都想知道发生了什么。坦诚认错等于告诉别人，「我知道了，不会再犯」，反而是重建信任最快的方式。

有些故障的根因落在自己不懂的领域，内核、BMC 这些，靠自己一辈子也搞不定。只能不断追踪、缩小范围，然后靠各基础设施团队帮忙。作者说关键时候培养的情谊是最牢固的。那些在故障中一起想办法的队友，帮他补盲点的同事、教他操作技巧的运维、主动分流流量的上游负责人、把他的模糊问题翻译成明明白白解释的内核工程师，大家忙完一起庆祝。这种战友情，日常工作中培养不出来。

作者的第一个经理在他还是菜鸟的时候就肯定他，鼓励他往前走。这不是什么复杂的领导技巧，但就是那句「你做得不错，继续成长」让他在后来的团队管理中也学会了这样对待新人。