TP官方网络故障处理指南 延迟问题及应急流程

TP网络最近这次故障，我们得好好聊聊。

别光是瞅着热闹瞧，得去瞧瞧其中的门道——身为经历了十几年网络工程师职业生涯的人，这次故障所显现出来的问题，实则是蛮具典型性的。

今天不谈那些高深的协议，就说几个最基础的要点。

故障恢复后别急着松口气，延迟故障才是隐形杀手。

很多朋友告诉我，故障那会儿网络通了，但打开网页特别慢。

这极有可能是在路由收敛进程当中出现了环路，又或者是链路带宽由于突发流量而被占满。

那时，我碰到过相仿状况，最终发觉乃是某一台核心设备的生成树协议未配置妥当，致使数据包于设备之间反复地来回兜圈子。

这对我们起到了提醒的作用，在恢复之后，需要马上专注地盯着流量监控方面，查看延迟情况以及丢包率是否存在异常之处。

运维人员的应急流程比技术更重要。

初期时，我观察到，这次出现故障那儿，许多用户反馈，都被径直个别处理，从而耽搁了整体的那种诊断判断。

具备良好表现的运维团队，当遭遇大规模故障状况时，首要采取的事情不是进行设备维修操作，而是发布相关公告。

将故障所产生的影响范围，以及初步形成的原因，还有预计能够恢复的时间，一同同步给用户，如此这般便能够避免百分之九十的投诉。

当故障出现的时候，首先要将用户的情绪稳定住，接着再全神贯注地去排查问题，这样效率反倒会更高。

我们自己的应急方案，也该更新了。

TP是骨干网，咱们公司内部网络有没有类似的单点故障风险？

建议各位同行，趁这个机会检查一下自己的网络架构。

出口带宽有没有冗余？

核心交换机有没有双机热备？

如果最坏的情况发生，你的网络能撑多久？

不妨在评论区聊聊你的网络冗余方案。