Pull to refresh
37
0
Дмитрий Володин @DmitryVolodin

User

Send message
Вопрос у автору: вы пробовали добавлять в анализ гипотезы, не связанные непосредственно с игровым процессом? Фактически, своим исследованием вы еще раз подтвердили, что причина оттока игроков лежит далеко не в самой игре. Собственно, для этого не надо было тратить два месяца и кучу технических ресурсов, достаточно было предложить отдельным личностям в компании почаще смотреться в зеркало.
Попробуйте посмотреть в сторону pica8, если связываться с openflow, то уж по-полной. Порты у них достаточно дешевые.
Четвертый тип (он же первый), который выпал из описания — graph based, который руководствуется заранее определенными зависимостями между сервисами. В какой-то мере NAGIOS делает похожую работу.

Вы правы относительно того, что терминология и понятия у разных вендоров отличаются. С этим все давно уже смирились :) Наш вариант трактовки терминологии точно также встречается в ряде коммерческих систем. Естественно, у нас в системе есть приоритеты аварий, которые могут изменяться оператором и системой в зависимости от тяжести последствий. Задачи придумать что-то радикально новое в fault management'е мы не ставили. Текущая задача проекта — доведение системы до уровня и функциональных возможностей нормальных промышленных FMS. Задачи отобрать хлеб у игроков, которые находятся на рынке не один десяток лет у нас тоже не стоит.

Распределенная обработка событий в той или иной мере реализована у всех, хотя слишком часто встречаются и откровенные костыли, тянущиеся из технологических решений двадцатилетней давности.
В нашем случае мы руководствовались собственным скромным опытом эксплуатации высоконагруженных систем и применили часть архитектурных решений из этой области в нашем проекте. Важный для многих момент — система работает на обычном дешевом железе и не требует монстров вроде Oracle и сановских гробов, обработку событий можно легко выносить ближе к месту их возникновения, и так далее.
Между серваками все равно стоит обычный железный свич?
Там еще хуже будет, при сбое в контроллере вся сеть задурит. Весьма сомнительное решение, на мой взгляд. Да и с железом проблемы пока. Pica8 ставили?

PS: Мне в этом плане больше нравится движение в сторону TRILL + нормальный статический provisioning сервисов.
Так в чем проблема-то? Отругается свич на то, что контроллер его игнорирует, а дальше в общем порядке. BRASы точно так же ругаются на завалившийся RADIUS.

Openflow, между нами, все-таки сильно эксперементальная вещь :)
Вы немного путаете. Мы все-таки говорим про обработку аварий в контексте сетевых технологий,
которые немного отличаются от последствий раздолбайства на серверах :)
И тут часто встречаются сложные наведенные аварии. В качестве примера — крашится процесс rpd на JUNOS, ложатся протоколы маршрутизации. Ящик при этом живой. Выглядит это как падение neighbor'ов на соседних коммутаторах. Причем всех сразу и в сторону одного ящика. В результате должен подняться alarm routing process failure. И таких примеров — масса.

Я не зря давал терминологические определения — вылет винта в рейде требует реакции (в виде замены) и винт можно считать аварийным пока не засинхронизировалась замена.

При нормальной организации процесса любая авария — штатная ситуация, так как вместо паники все работают: инженеры диагностируют, логистика везет замену, контакт-центр отбивается от клиентов, а генеральный подписан на изменение статуса аварии. Разбор полетов обычно откладывает на потом.
Я занудствую как раз на эту же тему — очень многие называют системами мониторинга именно рисовалки графика, хотя они всего лишь подмножество PM. PM как класс безусловно нужен, но его задача немного отличается от мониторинга в общем понимании. Наш PM в статье мы не рассматривали. В целом, он работает совместно с FM и умеет генерировать свои события и alarm'ы, которые обрабатываются FM в общем порядке.
В этом случае, PM выступает для FM просто еще одним источником событий.

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

Касательно Event'ов и Alarm'ов — действительно, в некоторых системах это одно и то же и отличие лишь во флажке или в приоритете. Именно так и работала первая реализация FM в NOC. У такого метода есть как свои достоинства, так и недостатки. Разделение на event'ы и alarm'ы у нас происходит по техническим и по архитектурным причинам.

Мы представляем сеть как процесс, для простоты — дискретный по времени. Фактически — это черный ящик, несмотря на то, что какие-то детали мы знаем. Процесс стохастический и прогнозировать его развитие достаточно затруднительно.

Внутри большого общего процесса деятельности сети можно выделить подпроцессы, которые как-то взаимодействуют между собой. Например, на роутерах крутятся процессы маршрутизации, на серверах — сервисы и так далее. Фактически, для задач FMS можно считать, что каждый из этих подпроцессов — это конечный автомат и в результате работы под действием внешних и внутренних факторов иногда происходит смена состояний. Для наших задач можно считать, что часть состояний процессов является нормальной и рабочей, а часть — аварийной. Все процессы регулярно генерируют логи и кидают трапы, часть из которых несет информацию о смене состояний. FMS принимает весь поток, классифицирует и дальше считает событиями. Реально из всего потока событий для нас важны только смены состояний.

Дальше вступает в работу база знаний. Описывать целиком конечные автоматы для всех возможных видов процесса дело неблагодарное и ненужное для практических применений. Поэтому реально происходящим процессам в базе знаний сопоставляется конечный автомат, состоящий из одного нормального состояния и некоторого количества аварийных. Вот эти аварийные состояния и являются Alarm'ами. Поток Event'ов у нас переключает Alarm'ы.

Вторая мотивация для разделения Event'ов и Alarm'ов не так очевидна: В отличии от многих коммерческих систем, обработка событий у нас распределенная. Сбор событий, их укладка в базу, классификация и корреляция осуществляется разными процессами, которые могут быть географически распределены и находиться на разных серверах. При этом можно варьировать количество процессов разного типа в зависимости от нагрузки. Все данные FM у нас хранятся в mongodb, которая сама по себе содержит хорошие механизмы для репликации и шардинга, что позволяет масштабировать систему как вертикально так и горизонтально. Далее учитываем тот факт, что на 1M событий реально может приходиться 100-200 alarm'ов, события можно и нужно обрабатывать раздельно и в разных местах, а alarm'ы необходимо иметь в одном месте, мы приходим к тому, что валить все в одно место недальновидно
А на этот счет есть диагностические скрипты. Имея под собой подложку в виде развитого модуля Service Activation система может сама зайти в случае аварийной ситуации на железку, провести диагностику и подшить ее к аварии.

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

Своими глазами наблюдал, как система сходу нашла десяток битых блоков питания. Можно долго рассуждать на тему того, а вдруг реально дохлых не 10, а всего 9, или вдруг она не нашла еще два битых. Но факт остается фактом — как минимум выявлено 10 проблем, которые так или иначе будут решены. А альтернатива — долго сомневаться и не найти ни одной проблемы в итоге.
Применительно к сетке badoo.com — имеющегося набора правил хватает, чтобы уверенно распознавать до 95% аварий и сильно упрощать диагностику для оставшихся 5%.
ИИ — понятие растяжимое. Rule-based система может демонстрировать интеллект ничем не хуже, чем нейронная сеть, при условии, что она не будет статичной и будет обучаться. Если вживую нарисовалась диковинная авария, которую система не обнаружила, проводится небольшое исследование и база знаний обновляется.

В качестве примера — столкнулись с отказом линейной карты на свиче. Посыпалось множество аварий, система, на основании базы знаний свела их аккурат к трем десяткам упавших линков. Инженер, разбирающийся с аварией имеет знания, которых еще нет а базе, а конкретно — по именам портов видит, что все они приходятся на одну карту. Начинает копать детальнее и видит в менеджере событий, что карта действительно упала, но FM ничего не знает про такой тип аварий. Он добавляется в систему и прописывается, что если ушла линейная карта, то все порты на ней упадут. И все — в следующий раз в подобном случае в качестве причины будет видна именно упавшая карта. Кроме того, инженер замечательно знает, что при перезагрузке свича в стеке ситуация повторится, авария моделируется в лабе или без всякой лабы в систему загружается аварийный сценарий. Немного возни, и система будет знать и про аварии в стеке. Дальше, по возможности, остальные проверят аналогичные ситуации на железе других производителей и расширят поддержку для других типов железа.
В нашем inventory все это планируется
Коллеги, давайте все ошибки тикетами на сайте
Мануал потянет на пару тысяч листов :)

Может быть сделаю еще несколько статей по отдельным применениям
Сменным операторам удобнее читать на родном языке. Другое дело, что устоявшиеся технические требования лучше не переводить и тектст превращается в страшную русско-английскую мешанину
Почему не смотрят? Базовая i18n есть, пусть и не по всем модулям. Fault Management вообще нативно умеет выводит сообщения на том языке, который выбрал оператор.
Зависит от степени толковости. Хорошему молодому специалисту всегда можно создать условия для карьерного роста :)
Толковым студентам, ищущим тему для дипломной работы, можем подкинуть несколько интересных тем и, возможно, посодействовать с преддипломной практикой. Если кому интересно, пишите мне.
Не контора красит продукт, а люди контору.
VLAN'ы от точки к точке в L2 топологии NOC умеет прокидывать и сейчас (сторонним модулем). MPLS топологии пока не понимает, но работы ведутся. Как доделаем каталог сервисов, можно будет сделать проброс VLANов в произвольных комбинациях уже без костылей, а заодно к rule-based механизму корреляции аварий добавим graph-based по зависимостям сервисов.

Визуализация схем сети с наложенными дополнительными данными — отдельная тема, скоро и до нее дойдут руки.
1

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity