Fehlgeschlagene Kommunikationslinie… Neustart für Idioten?


7

Ich arbeite in einem großen Unternehmen, in dem wir viele Legacy-Systeme verwenden. Um einige der Systeme zu beachten: HP-UX 10.20, Windows 2000, VMEBus-Systeme, Systeme, die vor mehr als 30 Jahren entwickelt wurden und nicht über TCP / IP-Protokolle kommunizieren, und mehr.

Während der gesamten Arbeitswoche sind wir ständig mit diesen Legacy-Systemen konfrontiert, die die Kommunikation untereinander verlieren. Normalerweise ist ein Neustart eines Systems, um zu versuchen, die Kommunikation wiederherzustellen, der letzte Ansatz. Es ist allgemein bekannt, dass ein Neustart eines Systems nur ein „Allheilmittel“ für ignorante Mitarbeiter ist. Ich habe mich gefragt, ob der Neustart eines Systems (Legacy oder nicht) zur Wiederherstellung einer fehlgeschlagenen Kommunikationslinie jemals Gültigkeit hat.

Mir ist klar, dass das Erneuern von IP-Adressen in Windows die Netzwerkkommunikation effektiv wiederherstellen sollte. Aber besteht die Möglichkeit eines tieferen Problems im zugrunde liegenden Betriebssystem, das beschädigt werden und einen Neustart erfordern könnte? Ein ausgefallener Socket, der eine Zeitüberschreitung aufweist, nicht geschlossen wird oder möglicherweise nicht versucht, die Verbindung wiederherzustellen?

Ein Neustart scheint mir eine praktikable Lösung zu sein, wenn ein so komplexes Netzwerk von Fehlanpassungssystemen vorhanden ist. Aber (zumindest an meinem Arbeitsplatz) wenn ein System neu gestartet wird und alles auf magische Weise wieder funktioniert, ist es immer ein „Zufall“. niemals eine Lösung. Gedanken?

Antworten:


2

Die Antwort lautet "es kommt darauf an".

Ein Neustart kann Probleme beheben oder das Erkennen von Problemen erleichtern, indem eine bessere Protokollierung oder leicht zu beobachtende Probleme bereitgestellt werden. (Hmmm ... ein Neustart sollte nicht 10 Minuten dauern)

Es ist jedoch eine schlechte Praxis, als Standardmethode zur Fehlerbehebung auf Neustarts zurückzugreifen. Jemand muss verstehen, wie die Dinge getrennt werden, damit Sie Triage durchführen, die ausgefallenen Komponenten isolieren und mit der Fehlerbehebung beginnen können.

Ich hasse es, es zu sagen, aber es kann nützlich sein, sich etwas wie ITIL anzuschauen, insbesondere das Incident- und Problem-Management. Dies kann Ihnen oder Ihrem Management dabei helfen, Ihr Support-System so zu reorganisieren, dass es tatsächlich rational funktioniert.


6

Ja, "Neustart und rufen Sie mich an, wenn es immer noch nicht funktioniert" ist oft die erste Fehlerbehebung für Systemadministratoren oder Helpdesk-Mitarbeiter, die keine Ideen mehr haben. Ich werde mich auch damit beschäftigen, aber jemandem zu sagen, er solle einen Server neu starten, ist eine völlig andere Übung, als wenn ein Benutzer seine Workstation neu startet, je nachdem, wofür der Server verwendet wird.

Ich hasse es, diesen Rat zu geben, aber ich spreche pragmatisch, manchmal für echte Legacy-Systeme, die Sie nicht ersetzen können. Wenn ein Neustart zur Behebung des Problems funktioniert, ist es besser, dies nur nach Bedarf zu tun und auf die Rechtfertigung eines Upgrades hinzuarbeiten Ausfallzeiten unnötig verlängern.


4

Meine Gedanken beim Versuch, Menschen zu erziehen, sind, zuerst den am wenigsten aufdringlichen Weg zu gehen.

Wie Sie sagten, sollte ein Neustart die letzte Option sein.

Am wenigsten aufdringlich wäre also eher: - Neustarten des Kommunikationsdienstes - Neustarten des Anwendungsdienstes - Neustarten der Kommunikationsschicht der Anwendung (falls vorhanden) - usw.

Dies gilt nicht nur für alte Systeme, sondern auch für die Fehlerbehebung. Eines Tages wird eines dieser Systeme nicht mehr hochgefahren.

Wenn Sie die verschiedenen Teile eines Systems durchlaufen, können Sie möglicherweise auch herausfinden, was den Fehler tatsächlich verursacht, und eine schnellere Lösung finden, da kein vollständiger Neustart durchgeführt wird.


Ich stimme dem zu, was Sie gesagt haben, und logischerweise werden diese Methoden in der von Ihnen beschriebenen Reihenfolge übertragen, um einzugrenzen, wo die Kommunikationsverbindung ausgefallen ist. Was mich mehr interessiert, ist, ob es jemals einen Zustand gibt, in dem sich ein System befinden kann, in dem ein Neustart die eindeutige Lösung für eine fehlgeschlagene Kommunikation darstellt. Wenn ja, warum oder warum nicht?
Cimplicity

3

Bei Failover-Clustern (ich verwende RedHat Cluster) ist ein Neustart aus mehreren Gründen eine gute Sache:

  • Es ist Teil des Hochverfügbarkeitsprotokolls "STONITH" (Shoot The Other Node in The Head), bei dem ein nicht reagierender Host zwangsweise getrennt / neu gestartet wird. Stellen Sie besser sicher, dass es ordnungsgemäß eingerichtet ist und ordnungsgemäß funktioniert. Wenn etwas schief geht, können Sie Computer mehrmals neu starten, es sei denn, das Problem ist offensichtlich.

  • Das System ist so optimiert, dass ein Knoten ausfällt, aber es ist nicht sehr gut - tatsächlich ist es scheiße -, wenn man herausfindet, dass sich ein Knoten nur schlecht verhält. Das Verschieben eines Dienstes auf einen anderen Knoten dauert einige Sekunden. Wenn sich der aktuelle Knoten schlecht verhält, ist das Ziehen des Steckers der sicherste und schnellste Weg, dies zu tun. Andernfalls könnte der Cluster versuchen, die Dinge zu gut zu machen, und auf eine Bestätigung warten, die niemals kommen wird.


2

Da sich Ihre Frage über mehrere Betriebssysteme erstreckt, kann es keine einzige richtige Antwort geben.

Ich kann dies für Windows 2000-Systeme sagen: Ich habe Tausende von ihnen ausgeführt und kann mich nur an eine Handvoll Fälle erinnern, in denen die Kommunikation fehlgeschlagen war UND das System nicht vollständig blockiert war. Oft wird dies durch einfaches Deaktivieren / erneutes Aktivieren der NIC ohne Kontakt zur Außenwelt behoben, gefolgt von einem Treiberupdate und / oder dem Ersetzen der Netzwerkkarte durch etwas weniger kitschiges.

(IOW, ich habe es nur mit alten Buggy-Treibern und / oder NICs von Markenherstellern gesehen.)

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.