我在一个大型公司工作，我们使用许多遗留系统。 要注意一些系统：HP-UX 10.20，Windows 2000，VMEBus系统，30多年前devise的不通过TCP / IP协议进行通信的系统等等。
整个工作周，我们一直在困扰着这些遗留系统，失去了沟通。 通常重新启动系统以尝试恢复通信是最后一种方法。 人们普遍认为重新启动一个系统对于一个无知的同事来说只是一个“固定的全部”。 我想知道，如果重新启动一个系统（传统与否）以恢复一个失败的通信线路是否有效？
我认识到在Windows中更新IP地址应该有效地恢复networking通信; 但在底层操作系统中是否存在可能导致更严重问题的可能性，并且需要重新启动？ 失败的套接字超时，不closures，或者不尝试重新连接？
在我看来，如果拥有如此复杂的不匹配系统networking，重新启动将是一个可行的解决scheme。 但是（至less在我的工作场所），当一个系统重新启动时，神奇的一切再次开始工作，这总是一个“巧合”。 从来没有解决scheme 思考？
答案是“这取决于”。
重新启动可以解决问题，或通过提供更好的日志logging或容易观察到的问题来更容易地检测问题。 （嗯…重新启动不应该花10分钟）
然而，采用标准的故障排除技术重新启动是一种不好的做法。 有人需要了解如何断开连接，以便您可以进行分类，找出发生故障的组件，并开始排除故障。
我讨厌这样说，但是看看ITIL这样的东西，尤其是事件和问题pipe理，可能会有帮助。 它可以帮助你或你的pipe理层重新组织你的支持系统，以实际的方式运作。
是的，如果系统pipe理员或服务台的工作人员出于想法，往往是排除故障的第一步，重新启动并打电话给我。 我会警惕使用这个，但告诉某人重启服务器是一个完全不同的做法，而不是让用户重启他们的工作站，当然这取决于服务器的用途。
我不愿意提供这个build议，但是务实地讲，有时对于那些你无权replace的真正的遗留系统来说，如果重新启动解决问题，那么最好只是根据需要去做，而不是为了certificate升级不必要地延长停机时间。
我试图教育人们的想法是先采取最less的侵入path。
正如你所说的重新启动应该是最后一个选项。
因此，最小的干扰就更像是 – 重新启动通信服务 – 重新启动应用程序服务 – 重新启动应用程序的通信层（如果存在的话） – 等等
这适用于更多旧的系统，适用于任何故障排除。 有一天，其中一个系统不会回来。
通过循环系统的不同部分，这也可以让你find实际上导致失败的原因，并且由于整个重新启动还没有完成，所以还有更快的修复。
有了故障转移群集（我使用RedHat群集）重新启动是一件好事，原因如下：
它是高可用性协议的一部分，如“STONITH”（在头部拍摄其他节点），由此无响应的主机被强制断开/重新启动。 你最好确保它已经正确设置，并且会按照正常的顺序重新启动。 出现问题时，除非问题明显，否则可以重新启动机器几次。
该系统是围绕有一个节点停止优化，但它不是很好 – 事实上它很糟糕 – 在计算一个节点只是行为不端。 将服务重定位到另一个节点需要几秒钟的时间。 如果当前节点行为exception，那么拔出它的插件是最可靠和最快速的方法，否则集群可能会尝试做太多的事情，并等待一个永远不会到来的ACK。
因为你的问题跨越了多个操作系统，所以不可能有一个正确的答案。
我可以对Windows 2000系统说这个：我运行了数以千计的系统，只能回想一些通信失败的情况，而且系统没有完全挂起。 通常一个简单的禁用/重新启用单独的NIC将解决这个问题，然后驱动程序更新和/或用不那么俗气的replaceNIC。
（IOW，我只看到它与旧的驱动程序和/或非品牌的网卡。）