停电是我们试图避免但却不可避免的事情：它们会发生（我们希望这种情况很少发生），我们必须知道如何处理它们（并从中吸取教训）。
那么，您经历过的重大中断是什么？您和您的团队如何处理这个问题？您对未来有什么经验教训？请分享您的想法 :)
答案1
我几乎每天都会遇到“中断”（监控 44 个站点的 WAN 链接）。“小中断”是指持续时间少于 5 分钟的中断，大多数情况下“未引起注意”（出于某种原因，NOC 仅监控超过 5 分钟的中断）。我尝试与站点沟通，查看是否是内部问题，并在问题“未知”时检查路由器日志。
我发现沟通是处理停机的关键（这是轻描淡写！）。不要在排除故障或试图找出到底发生了什么时等待被叫。一定要告诉他们你知道他们出故障了，而且你正在努力解决。给他们一个时间框架，告诉他们你何时会回复他们，向他们通报情况更新（ETR）。不要让他们等着以为你忘记了他们，一定要让他们知道有人在处理他们的问题。你给他们打电话，这样他们就不必给你打电话了。
值得庆幸的是，在我负责的监控下，网站宕机的最长时间是 7 小时（工作日上午 10 点至下午 5 点）。如果不是所有相关方之间缺乏良好的沟通，宕机时间应该会缩短几个小时。基本上，问题没有得到妥善升级，而且由于假设“有人在处理”，这个问题（相对网站而言）花了很长时间才得到解决。
答案2
我们数据中心的供暖蒸汽管道破裂了。非常热，到处都是冷凝水和石棉绝缘材料。清理期间断电数周。
好的，我的小组的内容是 BGP 配对的，在多个数据中心之间进行负载平衡。我们的部分用户在当前事务传输之前会经历 30 秒的冻结。许多其他项目的中断时间长达数天，每个人都加班加点地帮助其他人。
经验教训：首先做好连续性规划，然后建立系统来支持你的结论：
- 如果您无法忍受一周的停机时间，请规划并练习您的转移。不要使用主/故障转移站点，而是使用蓝色/金色站点并每两周轮换一次，以确保所有内容都已更新且可用。
- 如果您无法忍受半小时到一天左右的时间，请在活动站点之间进行负载平衡。与在压力下争分夺秒地进行恢复相比，您花在设置上的时间和精力会更少。
- 如果你不能容忍几分钟的停机时间，那么你需要付出很多努力才能实现真正的高可用性。最好的办法是聘请一位专家顾问。
- 只是为了完成层次结构，如果你不能容忍几秒钟的停机时间，你需要专门的硬件和专门的设计。你最好是专家
答案3
我当时正在参加一家公司的面试，这家公司有 50 多名用户，但目前正面临整个网络中断的问题。我在几分钟内就解决了这个问题，并见到了他们当前的系统管理员和他们打电话联系的 IT 支持公司，因为他无法解决这个问题 - 他们花了一上午的时间试图找出问题所在。
之前那个人安装了两个桥接模式的无线路由器，并将它们都接入有线网络。它们之间的距离很近，因此它们的网络形成了一个环路，随着接收信号的变化，环路会时断时续。
不用说，我得到了这份工作，并在开始工作后立即实施了一些变更管理日志记录。
答案4
可能最大的一次事故是由于重大网络升级导致的为期4天的总部网络中断。
我最大的建议是建立健全的事件管理流程。我看到 Velocity 2008 会议上有一个精彩的演讲，介绍了如何调整应急人员使用的通用事件指挥系统（http://en.wikipedia.org/wiki/Incident_Command_System）也适用于 IT 类事件：http://en.oreilly.com/velocity2008/public/schedule/detail/1525
在制定我们自己的内部“Sev1”事件处理流程时，我们大量借鉴了此原则。它强调沟通、统一指挥、明确责任交接等重要内容。
我还会为 Transparent Uptime 博客做个宣传：http://www.transparentuptime.com/- 它专注于在线服务，但他关于如何/什么中断沟通的一般规则也适用于内部 IT 事务。 http://www.transparentuptime.com/2010/03/guideline-for-postmortem-communication.html具体来说，我们让一位经理借鉴了这一点，并开始以这种格式发送信息，你不会相信会有如此积极的回应。