Dies ist eine kleine Geschichte aus der Praxis, in der ein kleines Problem, gut getarnt durch Redundanz, zu einer echten Herausforderung wird.
Ein kurzer Überblick:
Eine kleine Filiale, die ein eigenes PBX-System (Asterisk + FreePBX) auf Desktop-Hardware sowie einen lokalen Terminalserver mit 1C, einem Fileserver und einem virtuellen Domain-Controller betreibt. Das Internet wird über Mikrotik bereitgestellt. Die Filiale ist klein, das reicht aus.
Alles begann mit einer Überwachung (wegen Zeitmangels und Faulheit wird nicht alles überwacht), die über eine Überhitzung eines Server (PBX) in der Filiale informierte. Während die Mitarbeiter vor Ort das Problem lösten, stürzte der alte Server ab und beschädigte die MySQL-Datenbank ein wenig.
Vieles deutete auf Probleme hin, aber nicht auf dieses…
Keine Sorge, die Datenbank wurde repariert, alles sollte funktionieren. Aber die Mitarbeiter beklagten sich, Anrufe brechen ab. Na gut – Probleme in FreePBX gibt es manchmal, ich mache ein Backup, stelle es wieder her, alles in Ordnung.
Es gibt Probleme vor Ort, die Anrufer klagen immer noch, dass die Anrufe nicht richtig durchkommen. Der Anruf bei ihnen scheint in Ordnung zu sein, aber wenn sie selbst anrufen oder sich gegenseitig anrufen, gibt es eine Verzögerung von mehreren Sekunden. Ich beginne, die umfangreichen und unklaren Protokolle von Asterisk und FreePBX zu durchsuchen, aber ich kann das Problem nicht finden. Ich erinnere mich, dass es ein Problem mit STUN und ICE gab, das eine ähnliche Verzögerung verursachte. Ich schalte alles ab und das Ergebnis bleibt gleich null.
Trübsal ist der Weg zu schlechten Entscheidungen:
Ich verfalle in Trübsal; stundenlanges Herumprobieren mit der Telefonanlage führt zu nichts Gutem. Es ist bereits spät in der Nacht, und das Problem bleibt ungelöst.
Ich lasse das Problem bis zum Morgen ruhen in der Hoffnung auf einen klaren Kopf. Am Morgen wurde eine weitere missratene Entscheidung getroffen: Nachdem das System abgestürzt ist (obwohl der Absturz nicht katastrophal sein konnte), versuche ich, das System durch Neuinstallation aller Pakete zu reparieren. Das Ergebnis ist etwas besser als null, die Verzögerung hat sich verringert (nicht wesentlich, aber dennoch ein Erfolg).
Ich treffe eine weitere schlechte Entscheidung: Wenn die Teilreparatur des Betriebssystems (und der Datenbank aus dem Backup) nur begrenzt erfolgreich war und die Hauptursache weiterhin unklar bleibt, sowie bereits viel Zeit auf die Fehlersuche verwendet wurde, entscheide ich mich radikal zu handeln: Wir löschen das Betriebssystem und installieren alles von Grund auf neu (zum Glück erledigt die Automatisierung diesen Prozess in einer akzeptablen Zeit). Ich spiele die Konfiguration von FreePBX aus dem Backup ein. Ein weiterer Misserfolg. Das Ergebnis ist null!
Verzweiflung – der Verstand wird getrübt, die Lösungen werden noch schlechter.
Ich verfalle in Verzweiflung. Es kommen mir völlig wirre Gedanken: Vielleicht ist die Konfiguration im Backup fehlerhaft (ich hatte das nach einer Reihe von Updates, nach denen es nicht funktionierte, und ich konnte die Ursache nie finden). Mir bleibt nichts anderes übrig, als alles manuell von Grund auf neu zu machen. Welche Schande! Das Ergebnis ist absolut null, und ich habe viel Zeit verloren!
Akzeptanz – der Weg zum Bewusstsein.
In einem verzweifelten Versuch, das Geschehen zu ergründen, beginne ich, die Protokolle genau zu analysieren. Mir fällt eine Regelmäßigkeit auf. Der Aufruf der Extension erfolgt genau nach 5 Sekunden, während der Gruppenaufruf von 3 Extensions nach 15 Sekunden erfolgt! Ich fange an, nach der Verzögerung des Aufrufs zu googeln, wobei ich bereits die spezifische Verzögerung angebe. Und ich stoße auf die Antwort, die ich bereits gefunden hatte: Menschen sagen, das Problem liege an DNS, aber ich bin mir sicher, dass es kein Problem gibt, alle Adressen werden aufgelöst!
Das Offensichtliche ist nicht das Wahrscheinliche
Es bleibt nichts anderes übrig, als nslookup zu nutzen, und bingo (hätte ich das gleich machen sollen)! Der primäre DNS ist down (VM mit dem Controller), und ich habe es nicht einmal bemerkt! Hätte es nur einen DNS gegeben, gäbe es sofort einen Fehler 😉
Zusammenfassung
Ein elementares Problem, das das Monitoring hätte erkennen können (das für alle Knoten konfiguriert werden muss), maskiert durch die Ausfallsicherheit von DNS, hat dazu geführt, dass ich fast zwei Arbeitstage mit der Lösung einer dummen Situation verloren habe. Faulheit verursacht Kopfschmerzen; ein Monitoring einzustellen dauert eine Minute, das Problem dort zu suchen, wo es keines gibt – zwei Tage.
Nur registrierte Benutzer können an der Umfrage teilnehmen. Sind Sie an Contour interessiert?
Hatte jemand von Ihnen eine ähnliche Erfahrung?
Ja, sehr selten
Ja, selten
Ja, oft
Ja, sehr oft
Nein, mit jedem, nur nicht mit mir!
Nein, ich bin unfehlbar!
2 Benutzer haben abgestimmt. 1 Benutzer hat sich enthalten.
Quelle: habr.com
