Zoeken naar een probleem op de verkeerde plaats

Dit is een kort verhaal uit de praktijk, waarin een klein probleem, goed vermomd door fouttolerantie, in hoofdpijn verandert.

Kleine instelling:

Het is een kleine vestiging en heeft een eigen PBX (asterisk + FreePBX) op basis van desktophardware en dezelfde lokale terminalserver met 1C, een bestandsdump en een virtuele RO-domeincontroller. Het internet distribueert Mikrotik. De tak is klein, dat is genoeg voor hen.
Het begon allemaal met monitoring (door tijdgebrek en luiheid wordt niet alles gemonitord), waarbij de oververhitting van één server (met PBX) in het filiaal werd gemeld. Terwijl de lokale bevolking het probleem aan het oplossen was, verstijfde de oude man en brak de MySQL-database enigszins.

Veel dingen waren een voorafschaduwing van problemen, maar deze niet...

Geen probleem, de basis is gerepareerd, alles zou moeten werken. Maar de lokale bevolking klaagt, oproepen worden afgebroken. Oké - er zijn problemen in FreePBX, ik maak een back-up, implementeer deze, alles is in orde.
Maar het probleem is er, de lokale bevolking klaagt nog steeds, oproepen komen niet normaal door. Voor hen lijkt het gesprek normaal door te komen, maar als ze zichzelf bellen, of elkaar bellen, is er een vertraging van enkele seconden. Ik begin te kijken naar de omvangrijke en onbegrijpelijke logboeken van Asterisk en FreePBX, maar ik kan het probleem daarin niet ontdekken. Ik herinner me dat er een probleem was met STUN en ICE, wat een soortgelijke vertraging opleverde. Ik zet alles naar de hel, het resultaat is nul.

Neerslachtigheid is de weg naar het nemen van slechte beslissingen:

Ik word depressief, urenlang aan de ATS sleutelen leidt tot niets goeds, het is al laat op de avond en het probleem wordt niet opgelost.
Ik liet het probleem tot de ochtend liggen, in de hoop op een frisse kop. In de ochtend werd opnieuw een mislukte beslissing genomen: omdat het systeem kapot was (hoewel de afhankelijkheid niet zo destructief kon zijn), probeerde ik het systeem te repareren door alle pakketten opnieuw te installeren. Het resultaat is iets meer dan nul, de vertraging is afgenomen (niet significant, maar nu al een succes).
Ik neem nog een slechte beslissing: als gedeeltelijke reparatie van het besturingssysteem (en de database vanaf de back-up) weinig succes had, en de oorzaak van het probleem nog steeds niet duidelijk is, en er al veel tijd is besteed aan het zoeken naar de oorzaak, dan besluit ik radicaal te handelen: we slopen het besturingssysteem en we rollen alles vanaf nul over (gelukkig doet de automatisering van het proces dit binnen een acceptabele tijd). Ik ben de FreePBX-configuratie aan het oprollen vanaf een kopie. Nog een mislukking. Het resultaat is nul!

Wanhoop - de geest raakt vertroebeld, beslissingen worden nog erger

Ik verval in wanhoop. Er beginnen erg slechte gedachten te komen, denk ik: misschien is de conf in de back-up scheef (het overkwam mij na een aantal updates dat het daarna niet meer werkte, en ik kon de reden niet vinden), er is niets meer over : Ik moet alles opnieuw met mijn handen omrollen. Wat een schande! Het resultaat is strikt nul en er wordt veel tijd verspild!

Acceptatie is de weg naar bewustzijn

In wanhopige pogingen om te begrijpen wat er gebeurt, begin ik de logboeken zorgvuldig te bestuderen. Ik merk een patroon. Een toesteloproep vindt plaats in precies 5 seconden, en voor een groep oproepen van 3 toestellen in 15! Ik begin te googlen naar oproepvertraging, maar geef al een specifieke vertraging aan. En ik kom het antwoord tegen dat ik al heb gevonden, mensen zeggen dat het probleem in de DNS zit, maar ik weet zeker dat er geen probleem is, alle adressen zijn opgelost!

Duidelijk - niet waarschijnlijk

Er is niets te doen, ik pak nslookup en bingo op (ik wou dat ik dit meteen kon doen)! De primaire DNS is aanwezig (virtuele machine met een controller), maar dat heb ik niet eens gemerkt! Als er maar één DNS was, zou er een fout zijn 😉

Totaal

Een elementair probleem dat had kunnen worden opgemerkt door monitoring (die voor alle knooppunten zou moeten worden geconfigureerd), gemaskeerd door DNS-fouttolerantie, leidde tot het verlies van bijna twee werkdagen bij het oplossen van een stomme situatie. Luiheid is vervelend, het opzetten van monitoring duurt een minuut en het zoeken naar een probleem waar er geen is, duurt twee dagen.

Alleen geregistreerde gebruikers kunnen deelnemen aan het onderzoek. Inloggen, Alsjeblieft.

Is jou dit ooit overkomen?

• Ja, zeer zelden

• Ja, zelden

• Vaak

• Heel vaak

• Nee, met wie dan ook, alleen niet met mij!

• Nee, ik ben onfeilbaar!

2 gebruikers hebben gestemd. 1 gebruiker onthield zich van stemming.

Bron: www.habr.com