Това е кратка история от реалната практика, когато малък проблем, добре прикрит от отказоустойчивостта, се превръща в главоболие.
Малко разположение:
Малък клон, има собствена PBX (звездичка + FreePBX), базирана на настолен хардуер и същия локален терминален сървър с 1C, дъмп на файлове и виртуален RO домейн контролер. Интернет разпространява Mikrotik. Клонът е малък, това им е достатъчно.
Всичко започна с мониторинг (поради липса на време и мързел не всичко се следи), който отчете прегряване на един сървър (с телефонна централа) в клона. Докато местните решаваха проблема, старецът замръзна и леко счупи базата данни MySQL.
Много неща предвещаваха беда, но не и тази...
Няма проблем, базата е ремонтирана, всичко трябва да работи. Но местните се оплакват, обажданията се прекъсват. Добре - има проблеми във FreePBX, правя резервно копие, внедрявам го, всичко е наред.
Но проблемът е там, местните все още се оплакват, обажданията не минават нормално. Преди тях обаждането изглежда нормално, но когато се обаждат сами или се обаждат, има забавяне от няколко секунди. Започвам да разглеждам обемните и неразбираеми логове на Asterisk и FreePBX, но не мога да намеря проблема в тях. Спомням си, че имаше проблем със STUN и ICE, които дадоха подобно забавяне. Изключвам всичко по дяволите, резултатът е нулев.
Унинието е пътят към вземането на лоши решения:
Изпадам в депресия, бърникането с ATS в продължение на много часове не води до нищо добро, вече е късно през нощта и проблемът не се решава.
Оставих проблема до сутринта, надявайки се на свежа глава. На сутринта беше взето друго неуспешно решение: тъй като системата беше повредена (въпреки че зависимостта не можеше да е толкова разрушителна), се опитвах да поправя системата, като преинсталирах всички пакети. Резултатът е малко повече от нула, забавянето е намаляло (не значително, но вече успех).
Вземам още едно лошо решение: ако частичният ремонт на операционната система (и базата данни от архивното копие) не е успешен и коренът на проблема все още не е ясен и вече е изразходвано много време в търсене на причината, тогава решавам да действам радикално: разрушаваме операционната система и преобръщаме всичко от нулата (за щастие, автоматизацията на процеса прави това в приемливо време). Набирам FreePBX конфигурацията от копие. Пореден провал. Резултатът е нулев!
Отчаяние - умът се замъглява, решенията стават още по-лоши
Изпадам в отчаяние. Започват да идват много лоши мисли, мисля си: може би конфът в бекъпа е крив (случвало ми се е след няколко ъпдейта да не работи след тях и не можах да намеря причината), нищо не остана : Трябва да преобръщам всичко от нулата с ръцете си. Какъв позор! Резултатът е абсолютно нулев и много загубено време!
Приемането е пътят към осъзнаването
В отчаяни опити да разбера какво се случва, започвам внимателно да изучавам дневниците. Забелязвам модел. Обаждането на вътрешен номер се извършва точно за 5 секунди, а за група от повиквания от 3 разширения за 15! Започвам да търся в гугъл за забавяне на обаждането, но вече посочвам конкретно забавяне. И срещам отговора, който вече намерих, хората казват, че проблемът е в DNS, но аз знам със сигурност, че няма проблем, всички адреси са разрешени!
Очевидно - не е вероятно
Няма какво да правя, вземам nslookup и bingo (исках да мога да направя това веднага)! Основният DNS е там (виртуална машина с контролер), но дори не забелязах! Ако имаше само един DNS, щеше да има грешка 😉
Общо
Елементарен проблем, който можеше да бъде видян чрез мониторинг (който трябва да бъде конфигуриран за всички възли), маскиран от DNS fault tolerance, доведе до загуба на почти два работни дни за разрешаване на глупава ситуация. Мързелът е болка в дупето, настройването на мониторинг отнема минута, а търсенето на проблем там, където го няма, отнема два дни.
В анкетата могат да участват само регистрирани потребители. , Моля те.
Случвало ли ви се е това?
-
Да, много рядко
-
Да, рядко
-
Често
-
Много често
-
Не, с никого, само не с мен!
-
Не, аз съм непогрешим!
2 потребители гласуваха. 1 потребител се въздържа.
Източник: www.habr.com