什么是你已经成为主要的中断？

几乎每一天，我都是“中断”的一部分（监视44个站点的广域网链接）。 “小家伙”是那些不到5分钟，大部分时间“不被注意”（NOC只监视超过5分钟的中断，由于某种原因）。 我尝试与网站沟通，看看是否是内部问题，并在问题“未知”时检查路由器日志。

我发现沟通是关键（这是一个轻描淡写！）在处理中断。 在排除故障或试图找出究竟发生的情况时，请不要等待。 确保你沟通，你知道他们失败了，你正在努力。 给他们一个时间，当你回到他们给他们的最新情况（ETR）。 不要让他们认为你已经忘记了他们，确保他们知道有人正在看他们的问题。 你给他们打电话，所以他们不必打电话给你。

值得庆幸的是，最长的一个网站已经下了我的手表已经7个小时（这是在一个工作日上午10时至下午5时）。 如果不是因为所有有关各方之间缺乏良好的沟通，它应该缩短几个小时。 相当多的问题没有得到妥善的解决，而且由于“有人在做这个事情”这个问题，这个问题（相对于这个网站）永远得不到解决。

我们有一个加热蒸汽pipe道，通过我们的数据中心破裂。 非常热，冷凝和石棉绝缘到处都是。 清理过程中停电数周。

好的， 我的小组的东西是BGP配对，在多个数据中心之间进行负载平衡。 我们有一小部分用户在他们当前的交易被转移之前看到了30秒的冻结。 许多其他项目中断了几天，每个人都加class加点帮助其他人。

经验教训：首先进行连续性计划，然后构build系统以支持您的结论：

• 如果你不能容忍一个星期的停机时间，计划和练习你的转移。 我不是主要/故障转移站点，有蓝色/黄金，并且每隔两周轮换一次，以确保所有内容都得到更新和可用。
• 如果你不能容忍半个小时到一天左右，在活动的网站之间的负载平衡。 你会花费更less的时间和精力来设置它，而不是在压力下花时间去完成恢复。
• 如果你不能容忍几分钟的停机时间，那么你需要付出很大的努力才能做到真正的高可用性。 最好的办法是聘请专家顾问。
• 只是为了完成层次结构，如果您不能忍受停机时间，则需要专门的硬件以及专门的devise。 你最好是专家

当时我正在一家正在面对50多个用户办公室的整个networking中断的公司进行面试。 我在几分钟之内解决了这个问题，并且遇到了他们现在的系统pipe理员和他们所需要的IT支持公司，因为他解决不了这个问题 – 他们整个上午都在努力研究出了什么问题。

以前的家伙已经安装了两个桥接模式的无线路由器，并将它们插入有线networking。 他们几乎没有彼此的范围，所以他们在他们的networking中有一个循环，随着接待的变化而来来去去。

不用说，我得到了这份工作，然后一开始就实施了一些变更pipe理日志logging。

我经历了整个服务器networking的一周的中断。 我们通过创build一个冗余networking来处理这个问题，以防止将来出现同样的问题，但是当中断发生时，我们使用了一个我们在远程地点build立的旧服务器。 我们学会了总是有一个备份计划。

可能是最大的一次是由于重大networking升级而造成的4天全部总部networking中断。

我最大的一个提示是build立健全的事件pipe理stream程。 在2008年的Velocity 2008大会上，我看到关于将应急人员使用的通用事件指挥系统（ http://en.wikipedia.org/wiki/Incident_Command_System ）改编为IT型事件的精彩演讲： http：// en .oreilly.com / velocity2008 /公/日程表/细节/ 1525

在开发我们自己的内部“Sev1”事件过程中，我们从此广泛地进行了分裂。 它强调沟通，统一指挥，明确交接责任等重大事项。

我还会为透明正常运行时间博客插入一个插件： http ： //www.transparentuptime.com/ – 这是在线服务的重点，但是关于如何/为什么要中断通信的一般规则适用于内部IT-ey内容好。 特别是 – 我们有一个经理婴儿床，并开始发送这种格式的通信，你不会相信积极的回应。

如何计时。 我刚刚从紧急之旅回到我们支持的其中一个网站。

至于用户的影响，这不是一个重大的影响，但它有潜力。 作为一个正在进行的项目的一部分，将一些网站迁移到我们的支持之外，我们创build了一个新的信任域 经过广泛的testing，我们准备好第一个网站迁移到我们仍然可以pipe理的新域名。 因此，迁移的晚上出现，我们开始将两个DC中的一个迁移到新的域。 这很好。 我们迁移安全组和用户帐户。 这也很好，组成员身份正确更新。 我们迁移文件服务器并运行安全性转换来更新ACL。 一切顺利。 迁移应用程序服务器并更新IAS for VPN，没有问题。 然后，我们迁移testing用户PC，用户保留其configuration文件设置，并可以完美访问所有networking资源。 然后我们迁移另一个DC。 然后我们去迁移其余的电脑，一半失败。 我们发现本地XP防火墙已打开。 我立即将GPO推送到网站closures，但不得不等待电脑刷新。 这不会很快发生，用户开始到达。 他们无法login到原来的域名，因为两个DC都在新的域名上。

而是尝试将一个DC重新添加回原始域，我们更新防火墙规则以允许访问其他原始域的远程数据中心，并使用3小时的时间到达站点。

继续睡眠：禁用本地防火墙的GPO现在已经推出。 不要以为我抓住所有的计算机对象，并推动迁移。 我忘了这个RESETs电脑对象。 所以现在所有成功迁移的PC都被从域中删除。

更糟糕的是，我们推出的本地pipe理员权限通过我们的映像不起作用，因为很久以前，现场技术就重置了他们。

我使用启动磁盘清除本地pipe理员通道后，手动将所有PC添加到新域中。

得到教训：

• 期待意外，并尝试预测所有潜在的问题。
• 集中pipe理本地pipe理员密码和防火墙设置等
  • GPO和组策略首选项
• 再点击一下，以确保你正在做的事情正确点击之前。

对不起，这是很长的啰嗦。