хочешь пример

была у нас в би проблема с кондеями на узлах

техдир попросил получать уведомления о перегревах

чтобы контролировать

ну и хули делать в этой вашей эскалационной поебени

На свежую голову лучше

@E_zombie блин по общему правилу Qtech | QSW sysObjectID засосались QSW-2900, а к правилу прикреплен профиль QSW-2800. Модели кардинально разные и нихера не работает :(

да,я злой сегодня

Ого

Что за срач

@E_zombie блин по общему правилу Qtech | QSW sysObjectID засосались QSW-2900, а к правилу прикреплен профиль QSW-2800. Модели кардинально разные и нихера не работает :(

ну ёбта надо было проверить сперва какой профиль рабочий.

там ещё есть профиль qsw8200

LOL

ну ёбта надо было проверить сперва какой профиль рабочий.

дык это не тот профиль что я тестил. этот тот что из коробки

теперь делай реверт

что это? )

это я писал что задискаверились не те свичи, это еще до того как я профили к недостающим моделям начал подбирать

отмену коммита

Ты не понял. Есть в библиотеке общее правило для qtech, к нему прикреплен шаблон qsw2800. И т.к. правило общее, то под него засосались говняжки QSW-2900 (dlink like)

это общее правило я не трогал. оно уже было

сложна. нихуянепонял.jpg

короче, не тем моделям прихерачился шаблон QSW2800. с ними этот шаблон не работает. как быть? нужно делать отдельный шаблон под QSW2900?

короче ладно, что-то я разошелся. жить можно

fantmas opened merge request at / noc: Change alarm format view in object card Change alarm format view in object card

stubborn opened merge request at / collections: Add new model

aversant opened merge request at / noc: Fix fail check refer when delete NotificationGroup Fix fail check refer when delete NotificationGroup

stubborn opened merge request at / collections: Add new model

stubborn opened merge request at / collections: Add Unknown Qtech QSW-2850

@somovis если в одной эскалации две нотификации с пересекающимися доменами

что будет?

что будет?

сообщение о закрытии придет только в 1

блять!!!

но ты можешь проверить )

ivzakharov opened merge request at / collections: Update Bundle_SYSLOG_.json Fix для матчинга сообщений с префиксом %EC-STBY-5-BUNDLE. Сообщения от резервного супервизора, дублируют те же от активного

ivzakharov opened merge request at / collections: Update Unbundle_SYSLOG_.json Fix для матчинга сообщений с префиксом %EC-STBY-5-BUNDLE. Сообщения от резервного супервизора, дублируют те же от активного

сообщение о закрытии придет только в 1

я тебя правильно понимаю что если у меня есть два перекрывающихся админ домена, один покрывает все железки, а второй только их часть, то если настроить уведомление по подгруппе, то по большой группе уже ничего уведомить нельзя и надо перечислять железки по всем поддоменам что там есть??? А если железки разбиты так что часть из них находитсяв поддомене, а часть в самом домене, то вообще пизда будет?

я не понимаю

ща

Я пока про одну эскалацию

если я третьей строкой добавлю админ домен который является кусочком от спд и напишу там еще одну группу для уведомлений

что будет?

просто чтобы было наглядно

Я во всей этой схеме увидел только одну проблему. Нельзя в разные группы отправить разные сообщения (потому что в одной эскалации 2 группы уведомлений не работают). Приходится использовать расширенную группу уведомлений. И показывать больше деталей об аварии, хотя хотел бы их скрыть

странно, но помоему все же работает.

или я уже чего-то не помню )

совсем память отшибло

я тут уже описывал. Но там логика такая. их вот этих правил эскалации формируется цепочка. т.е. они выстраиваются друг а другом. Дальше берётся авария и начинает по этой цепочке идти сверху вниз. На каждой строчке происходит проверка условий (вначале Adm. domain, затем Severity, затем Selector) если они совпали - выполняется действие (н-р отправка уведомления) после выполнения идём дальше. И так проходим все строчки для Alarm Class

справ есть галочка Stop, если её поставить, то на этом шаге (если сойдутся условия) выполнение цепочки прервётся

проблема с отправкой закрытия в следущем. Куда отправлять сообщение о закрытии сохраняется в аларме. И, соотв. сохранится там группа сработавшая последней

?‍♂️

то есть какие бы манипуляции с доменами, селекторами, эскалациями я ни делал, закрытие пойдет только в одну группу

я правильно понял?

да

думаю, можно баг завести

извините меня конечно, но вы сделали полную ебанину

предлагаю зойбанеть. нахуй.

она работает

если понимать, что делаешь

при хреновых процессах может доставлять неудобства

но лучшей схемы никто не предложил

она работает

как тебе сказать, оно работает когда есть вертикаль власти и все идет сверху вниз и снизу вверх, когда же есть параллельные пути, то начинаются проблемы о которых мы сейчас говорим. я сейчас от тебя слышу что все бизнес процессы должны быть подстроены под то как вы задумали. нормальные проекты обычно делаются наоборот

вот я и говорю -- проблемы с процессами

вот я, например, абсолютно уверен, что у конктретного сервиса (или железки), должен быть строго один хозяин

иначе начинает работать принцип коллективной безответсвенности

но лучшей схемы никто не предложил

ну и вообще, раньше было лучше, не было такой проблемы в принципе, это ваша очередная схема получилась неадекватной. раньше было неудобно что нельзя алармклассы разбить по группам нотфикации, да и только

иначе начинает работать принцип коллективной безответсвенности

Так не бывает

вот я, например, абсолютно уверен, что у конктретного сервиса (или железки), должен быть строго один хозяин

всегда появляются начальники которые тоже хотят видеть уведомления

вот я и говорю -- проблемы с процессами

и еще ты говоришь что любой кто захочет поставить нок, должен подстроить процессы под него, а точнее как их видишь ты. Ты серьезно считаешь что так будет?

Мне почему-то увиделось, что нок это в принципе фреймворк, и у тебя с ним два пути. Либо подстроиться под него, либо переписать под свои процессы и продвинуть в массы.

но лучшей схемы никто не предложил

Вот тут например.

и еще ты говоришь что любой кто захочет поставить нок, должен подстроить процессы под него, а точнее как их видишь ты. Ты серьезно считаешь что так будет?

у меня есть один инженер который думает что нок должен подстраиваться под то что ему удобно и как он хочет. и да. он ..... очень хороший и ценный специалист.

который все проблемы скидывает на сисадмина в плане актоматизации решения его проблем

@ewwwwcha коллективной безотвественности не бывает?

сплошь и рядом бывает

есть разные подходы -- построить процесс под нужды компании, чтобы в рамках отведенного бюджета решать задачи

или подстроить процесс под себя, любимого

чтобы не уволили при очередном сокращении штатов

кому чего нравится

мне изрядно пришлось поразбирать процессов, настроенных под одного человека

вплоть до махровых культов личности

в общем, советую помимо своего личного мнения относительно каких-либо вещей в NOC, попробовать посмотреть на процессы компании в целом

а дальше?

порой, объединяя усилия вполне хороших людей и срезая постепенно острые углы, можно добиться большего, чем пытаясь прогнуться под хотелки очередной рок-звезды

?‍♂️

ага

если считаешь, что можно сделать лучше -- описывай детально и давай обсуждать

но держи в голове, что текущая схема не на ровном месте придумана

знаю, она придумана на сети ртк и заточена на его бп

тут ты не прав

допустим, что я скажу, что часть процессов РТ затачивались под эту схему

и не нами она придумана была

и ты решил что и остальные сделают так же

просто была схема, которая неплохо отработала в двух компаниях

все провайдеры одинаковые и должны следовать одному

№1 и №2 в Москве по ШПД, если что

то есть провайдеров номер 10 и 11 в списке ты не рассматриваешь

более того, она неплохо бы работала еще в двух из первой десятки

там движуха в правильную сторону шла

№11 должен, как минимум, понять, что первые 10 перед ним не идиоты