SokolovS Опубликовано 9 ноября, 2010 (изменено) · Жалоба 2dvolodin: я периодически смотрю что вы делаете, интересный проект. Полностью свои проекты я открыть не могу к сожалению :(Вот идея с источниками топологической информации мне понравилась, применю ) У нас сейчас только FDB снимается, но карта как видите строится нормально, она кстати интерактивная, т.е. увязана с мониторингом и есть возможность переходить дальше вглубь. Если нод зеленый, то дальше что-то есть, если синий то это последний узел в цепи. Мы столкнулись с тем, что FDB хватает далеко не всегда, это скорее fallback вариант. Наши алгоритмы определяют не только связь между железками, но и физические порты или port-channel'ы, в зависимости от алгоритма. То есть информации о том, что железка A подцеплена к железке B для нас недостаточно, нужны конкретные порты, которых на наших железках бывает по несколько сотен. Нам хватает ;) Номера портов определяются нормально, причем даже для многоюнитовых коммутаторов. Обратите внимание мы указывам номера портов в виде юнит:порт. Проблема скорее в кольцах L2, L3, но у нас есть возможность и ручной привязки с запрещением внесения изменений автоматом. Работать вобщем то еще есть над чем, но аварийная служба с тех.поддержкой уже балдеют. Обрити внимание на скрине: http://forum.nag.ru/forum/index.php?act=at...ost&id=5249 Стоит соответствие на 24 порту и запрещено его отключать т.к. это аплинк. Т.е. мне кажется как раз наоборот в большинстве случаев FDB более реальную картину дает. Потом еще хочу рекомендацию дать, для устройств хранить диапазон self MAC-адресов, т.к. у L3 коммутаторов их например много и наличие любого из них на порту носит определяющий характер :) Изменено 9 ноября, 2010 пользователем SokolovS Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SokolovS Опубликовано 9 ноября, 2010 (изменено) · Жалоба Понимаете, провайдеру нужно чтобы всё было под рукой и быстро, чтобы всё было в одном интерфейсе, а не так, чтобы сначала по номеру договора смотреть есть ли деньги в биллинге, потом лезть в тех.учёт и смотреть куда он подключен, потом ползти в некий интерефейс управления железом, смотреть что там с портом, приходит ли мак и т.д.Вот тут пожалуй соглашусь :) Скрины которые я приводил это на самом деле часть интерфейса билинга, а не отдельная система. И у нас именно так как ты пишешь, т.е. оператор ТП сразу видит куда подключен абонент, может посмотреть нет ли ошибок на порту, посмотреть клиентские маки и.т.д. и это удобно. Я не представляю если бы им пришлось лезть еще куда-то. Когда я писал что билинг не должен работать с железом я имел ввиду что он не должен делать это напрямую, должен быть некий сервер реализующий функционал работы с железом и интерфейсом SOAP или XML-RPC. Вся первичная информация в том числе и по оборудованию должна храниться в билинге. Ну это мое мнение. Плюс должна быть гибкая система прав. Например доступ к веб-консоли управления железом у нас имеет только группа "Специалисты по сетевому обеспечению" ну и "Суперюзеры" :) Права у нас делятся на чтение / запись / супер-привелегии / просмотр паролей. Изменено 9 ноября, 2010 пользователем SokolovS Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dvolodin Опубликовано 9 ноября, 2010 · Жалоба Понимаете, провайдеру нужно чтобы всё было под рукой и быстро, чтобы всё было в одном интерфейсе, а не так, чтобы сначала по номеру договора смотреть есть ли деньги в биллинге, потом лезть в тех.учёт и смотреть куда он подключен, потом ползти в некий интерефейс управления железом, смотреть что там с портом, приходит ли мак и т.д.nocproject это целый самостоятельный project, который, очевидно, заточен под управление оборудованием датацентра или магистральных операторов и для учёта технологических объектов(rd,ip-адреса, домены и т.д.), хотя опять же очевидно, что все эти вещи должны быть привязаны к деньгам абонентам, а не храниться в отдельной базе. И пожалуй самое главное, база данных должна быть единой, крайне важно избегать любое дублирование данных, иначе получается бардак. Мы идем немного в другую сторону - разделяемые ресурсы должны привязываться к сервису, а вот сервис может оказываться, в том числе, и абоненту. Давайте все-таки определимся с задачами. Маленький ШПД вполне проживет и на биллинге, так как его относительно просто на него натянуть. Если оператор покрупнее, то пихать все в биллинг - идиотизм. По большей части, в качестве центрального хранилища выступает таки inventory, из которого все дергают данные. Допустим мы хотим дать возможность получения статического белого IPv4-адреса. Следуя Вашей идеалогии, пометка о том, кому принадлежит этот адрес должна быть в базе nocproject, но в самом деле ассоциация IP и логина на pppoe/pptp или id порта(option82) должна быть в базе биллинга, чтобы при авторизации bras получил радиус-атрибут, содержащий статический IP адрес абонента. Поэтому первая строчка из overview к nocproject нужна далеко не всем. Аналогично про последнюю, reporting должен быть в контексте денег, а не оборудования.Опять же - зависит от размеров и задачи. Возьмем для примера тот же Juniper E-series, чем не BRAS. SRC-PE к ним совсем не зря делают, несмотря на его монструозность. И тут еще большой вопрос, откуда SRC-PE правильнее брать адрес. NOC обычно используется как инструмент для проведения технической политики, элементами которой являются и адресный план, и политика маршрутизации и пиринговая политика. К вопросам биллинга, абонентам и деньгам эти вещи весьма ортогональны. Каким боком конфиг свича, например, относится к биллингу? А прилетевший SNMP Trap? Собственно IPAM в NOC появился под вполне конкретную задачу - разработку адресного плана для сети МгМн. Большинству операторов он конечно интересен, но не как отдельная система, а как некий libnocproject, чтобы дёргать его напрямую из биллинга/техучёта, а не использовать его как чёрный ящик в стиле бросил SOAP-запрос и получил ответ. >Во-вторых, либо этот продукт будет создан под ваш бизнес, либо ваш бизнес будет натянут на этот продукт. В третьих - продукт будет весьма сложным и малотиражным, тут уже просто бабло насосом сосать будут за поддержку и каждый чих. У провайдеров последней мили все бизнес-процессы должны быть решены в виде модулей биллинга, покупается биллинг с нормальным API, к нему прикручиваются модули, тогда никакого высасывания бабла не будет Опять же - если центр управления сетью совмещен с девочками-менеджерами на телефоне, то да, биллинг. А если сетью управляет распределенная техническая служба, то в биллинг ее вообще пускать противопоказано. Все-таки каждый инструмент - для своей задачи. Если на сети есть прокурвы, то бывает каждый день :)Это вы о чем? HP ProCurve. CLI у них чудной, для того же MSTP часть параметров можно выдернуть только через SNMP или walkMIB Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dvolodin Опубликовано 9 ноября, 2010 · Жалоба Обрити внимание на скрине: http://forum.nag.ru/forum/index.php?act=at...ost&id=5249Стоит соответствие на 24 порту и запрещено его отключать т.к. это аплинк. Т.е. мне кажется как раз наоборот в большинстве случаев FDB более реальную картину дает. Потом еще хочу рекомендацию дать, для устройств хранить диапазон self MAC-адресов, т.к. у L3 коммутаторов их например много и наличие любого из них на порту носит определяющий характер :) В этом нет необходимости. MAC'и SVI интерфейсов автоматом выскребаются из ARP-кешей. Кроме того наш алгоритм нормально определяет абонентские порты.FDB не видит заблокированные по STP порты и не видит физические порты, входящие в port-channel. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 9 ноября, 2010 (изменено) · Жалоба Каким боком конфиг свича, например, относится к биллингу? А прилетевший SNMP Trap?Навскидку: - Подписка на мультикаст-группы. Настраивается на свитче исходя из параметров, хранимых в билинге. - vpn vlan, например. Хотя у нас - достаточно нечастое явление, чтобы хранить отдельно. - Прилетел трап о срабатывании того же storm-control и блокировке абонентского порта - желательно также в билинг запихнуть, чтобы операторы, открыв инфу юзера, сразу видели причину "неработы тырнета" Можно продолжать долго =) Изменено 9 ноября, 2010 пользователем Wingman Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 9 ноября, 2010 · Жалоба >Опять же - зависит от размеров и задачи. Возьмем для примера тот же Juniper E-series, чем не BRAS. SRC-PE к ним совсем не зря делают, несмотря на его монструозность. И тут еще большой вопрос, откуда SRC-PE правильнее брать адрес. И всё же вернёмся к дублированию данных. Абонент, подключённый по PPPoE захотел статический адрес, допустим внедрён nocproject в чистом виде, вносим в него, что абонент Вася Пупкин(что именно вносим - какой-то id абонента, id сервиса или "вася пупкин" ?) получил такой-то адрес. Чтобы он выдавался Васе каждый раз при авторизации, его ведь ещё куда-то надо внести, откуда его будет брать брас? Ну чем тут не дублирование? По всему остальному дам ответ позже, если за меня не ответят. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dvolodin Опубликовано 10 ноября, 2010 · Жалоба Каким боком конфиг свича, например, относится к биллингу? А прилетевший SNMP Trap?Навскидку: - Подписка на мультикаст-группы. Настраивается на свитче исходя из параметров, хранимых в билинге. - vpn vlan, например. Хотя у нас - достаточно нечастое явление, чтобы хранить отдельно. Ну так пусть хранится. Только зачем именно биллингу самому по свичам бегать? Пнул service activation и все. По хранению данных, применительно к NOC, можно навесить триггеры на события: см. пример. И никакой двойной работы не будет - забил данные в NOC, если надо, они автоматом уедут в биллинг. Со стороны биллинга, в принципе, аналогично должно делаться. - Прилетел трап о срабатывании того же storm-control и блокировке абонентского порта - желательно также в билинг запихнуть, чтобы операторы, открыв инфу юзера, сразу видели причину "неработы тырнета"Можно продолжать долго =) Опять же - не дело биллинга парсить весь syslog/snmp. Пусть их собирает fault management, у него и производительность повыше, и мозгов побольше :)Дополнительные данные он всегда сможет дернуть из inventory/биллинга или других систем. А уже по факту, словив событие, сообщающее о приостановке сервиса, красиво пнуть биллинг и сказать, что юзера отключили по такой-то причине. И оператор сразу увидит причину в общем dashboard'е. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dvolodin Опубликовано 10 ноября, 2010 · Жалоба >Опять же - зависит от размеров и задачи. Возьмем для примера тот же Juniper E-series, чем не BRAS. SRC-PE к ним совсем не зря делают, несмотря на его монструозность. И тут еще большой вопрос, откуда SRC-PE правильнее брать адрес. И всё же вернёмся к дублированию данных. Абонент, подключённый по PPPoE захотел статический адрес, допустим внедрён nocproject в чистом виде, вносим в него, что абонент Вася Пупкин(что именно вносим - какой-то id абонента, id сервиса или "вася пупкин" ?) получил такой-то адрес. Чтобы он выдавался Васе каждый раз при авторизации, его ведь ещё куда-то надо внести, откуда его будет брать брас? Ну чем тут не дублирование? Давайте все-таки разделять дублирование данных и их повторный многократный ввод. Как вариант - NOC можно научить генерировать конфиг для DHCPd, или подсовывать нужные данные RADIUS'у, или провзаимодействовать с policy-server'ом, или тупо накормить BRAS данными о подписчике, если он софтовый. Со стороны биллинга все предельно просто должно быть - запросили и зарезервировали свободный адрес в заданном пуле, сказали NOC'у, что ему надо активировать сервис "статический IP на PPPoE", получили подтверждение, что сервис активирован. А если завтра клиент вдруг обзаведется AS'кой и решит стать downlink'ом. А биллинг про BGP'шные вещи вообще не в курсе, что делать будем? А в случае с отдельным service activation ему достаточно только пнуть его на тему активации сервиса "BGP Downlink" и забыть о том, что сессии, вообще-то, надо настраивать, а фильтры - периодически обновлять. И, по отработанному механизму, NOC, увидев, что BGP-пир завалился, честно пнет биллинг, и оператор увидит это в списке событий. А если пойдем дальше и вспомним про MPLS-сервисы? А тут опаньки, а биллинг и слов-то таких страшных не знает. Плагины к нему писать будем? Основной вопрос - в удобстве сопровождения. Если своих ресурсов немного и сетка небольшая, то биллинг может и сам заниматься такими вещами. Но, с определенного момента, лучше использовать более гибкое внешнее решение. Скрипты для активации сервиса могут быть весьма запутанными и лучше выносить из них все взаимодействие непосредственно с железом отдельно. В случае с NOC'ом - есть generic script'ы, которые не привязаны непосредственно к железу. Если, скажем, решили поменять часть DLink'ов на Zyxel'ы, то достаточно сделать небольшой набор примитивов (которые, с высокой вероятностью, уже кем-то сделаны), и сложный скрипт активации сервисов будет работать на новом железе. Как мы будем выкручиваться в случае, если этим занимается биллинг? Перепишем весь скрипт для другой железки? А при модификации сервиса потом будем вносить изменения в нескольких местах? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
terrible Опубликовано 10 ноября, 2010 · Жалоба Если своих ресурсов немного и сетка небольшая, то биллинг может и сам заниматься такими вещами. Но, с определенного момента, лучше использовать более гибкое внешнее решение.Полностью согласен. Нереал одному биллингу наблюдать и мониторить несколько тысяч железок, он их тупо не успеет опросить в заданный промежуток времени. Но я не говорю, что этим не должен заниматься биллинг, именно этим он и должен заниматься, но не прямо он сам, а его отдельная часть, не имеющая прямого отношения к абоненту. Если, скажем, решили поменять часть DLink'ов на Zyxel'ы, то достаточно сделать небольшой набор примитивов (которые, с высокой вероятностью, уже кем-то сделаны), и сложный скрипт активации сервисов будет работать на новом железе. Как мы будем выкручиваться в случае, если этим занимается биллинг? Перепишем весь скрипт для другой железки?Если система написана так, что при модификации парка оборудования требуется вмешательство в код - за это открывают руки и запихивают сами знаете куда. В случае же, если система изначально подразумевает настройку политик управления и гибкую алгоритмизацию управления и мониторинга, + к этому присобачить гибкую алгоритмизацию парсинга логов, и чтобы всё это дело выполняло определённую цель - то неважно вообще, какой у вас парк, на длинках, цисках, хукселях или ещё на чём-то. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
marikoda Опубликовано 11 ноября, 2010 · Жалоба Если система написана так, что при модификации парка оборудования требуется вмешательство в код - за это открывают руки и запихивают сами знаете куда. В случае же, если система изначально подразумевает настройку политик управления и гибкую алгоритмизацию управления и мониторинга, + к этому присобачить гибкую алгоритмизацию парсинга логов, и чтобы всё это дело выполняло определённую цель - то неважно вообще, какой у вас парк, на длинках, цисках, хукселях или ещё на чём-то. Придумать свой язык для описания парсилки лога? Проще взять готовые perl,tcl,pyhon и т.п. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
terrible Опубликовано 11 ноября, 2010 · Жалоба Придумать свой язык для описания парсилки лога?Да нет, просто описать, что сообщение, содержащее определённый текст попадает в такой-то класс, ну и дальше руление классом парсинга. Придумывать ничего не надо, нужно только грамотно это сделать изначально гибгим, чтобы под несколько классов можно было бы подвести все теоретически-возможные сообщения от оборудования любого производителя.Я думал заняться такой хнёю, но пока у нас только длинк и смысла делать нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mlevel Опубликовано 11 ноября, 2010 · Жалоба Ну у нас вот как-то так. Это фронтенд в билинге. Тоже считаю что не дело билинга с железками общаться. У нас выполнено все в виде XML-RPC сервера через Frontier::Daemon:Fork, работает как с SNMP, так и с telnet. Пингалка многопоточная отдельно написана, но все в рамках того же проекта. Как работать с железкой решает сам сервер. Софт закрытый, хотя есть идея выложить как открытый как раз сам сервер. Там структура классов на perl для snmp и telnet, т.е. можно дописывать под другие коммутаторы. Сейчас рабтает с D-Link (почти все модели включая L3), Planet WSW, SGSW, Cisco L2/L3, Telesyn L3. Кару сети можно строить как в автоматическом режиме на основе FDB, так и в ручном (через привязки). Извините за оффтоп, скажите пожалуйста чем рисуеться карта коммутаторов (рис. 1), очень ровно получилось, хотелось бы у себя такое реализовать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SokolovS Опубликовано 11 ноября, 2010 (изменено) · Жалоба Ну у нас вот как-то так. Это фронтенд в билинге. Тоже считаю что не дело билинга с железками общаться. У нас выполнено все в виде XML-RPC сервера через Frontier::Daemon:Fork, работает как с SNMP, так и с telnet. Пингалка многопоточная отдельно написана, но все в рамках того же проекта. Как работать с железкой решает сам сервер. Софт закрытый, хотя есть идея выложить как открытый как раз сам сервер. Там структура классов на perl для snmp и telnet, т.е. можно дописывать под другие коммутаторы. Сейчас рабтает с D-Link (почти все модели включая L3), Planet WSW, SGSW, Cisco L2/L3, Telesyn L3. Кару сети можно строить как в автоматическом режиме на основе FDB, так и в ручном (через привязки). Извините за оффтоп, скажите пожалуйста чем рисуеться карта коммутаторов (рис. 1), очень ровно получилось, хотелось бы у себя такое реализовать. http://pear.php.net/package/Image_GraphVizЭто кстати не вся карта, это только кусочек, один из центров. Там ноды можно ссылками делать для переходов вглубь и возвратов обратно, т.е. для навигации по уровням карты. Изменено 11 ноября, 2010 пользователем SokolovS Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mlevel Опубликовано 11 ноября, 2010 · Жалоба Огромнейшее спасибо. Оф. сайт: http://www.graphviz.org/ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dvolodin Опубликовано 11 ноября, 2010 · Жалоба Придумать свой язык для описания парсилки лога?Да нет, просто описать, что сообщение, содержащее определённый текст попадает в такой-то класс, ну и дальше руление классом парсинга. Придумывать ничего не надо, нужно только грамотно это сделать изначально гибгим, чтобы под несколько классов можно было бы подвести все теоретически-возможные сообщения от оборудования любого производителя.Я думал заняться такой хнёю, но пока у нас только длинк и смысла делать нет. В NOC примерно так и сделано. Сообщения классифицируются и, в дальнейшем, вся работа идет с классами сообщений. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jingvar Опубликовано 11 ноября, 2010 · Жалоба Позвольте незамутненным взглядом высказаться. Сейчас занимаюсь домашним написанием управлялки. Основная проблема - банально нет описания и понимания что нужно сделать. Т.е. понятно, что конфиги, прошивки лить, итд. Но главный вопрос - нет реверс инженеринга бизнеспроцессов. Вот вы говорите для операторов нужен дашборд, а что они должны там делать? Как они должны исполнять свои обязанности? Какие именно ресурсы им необходимы? Вот когда работа админов, операторов, бухгалтерии, и маркетинга будет понятна от и до, возникнет некая CRM система. И в целом как будет крутится биллинг+управление, вообще все отдельно или еще как будет не принципиально. На тему готовых систем - а я что-то не помню ни одной системы которая взяла и сразу в конторе заработал без допилки. Я к тому, что поверх любой базовой системы придется натягивать свое окружение и вариант подсесть на интегратора будет в любом случае. Для конкретики есть python - постой язык, сделать на нем framework стоит денег, есть Zope свободный крутой framework - на нем сделать CMS стоит денег, берем свободный Plone - CMS - запилить его под вас стоит денег, запилили под вас CMS - девелопер слишком много денег хочет, сколько будет стоить другой? Да одинаковую сумму относительно любого этапа. Если будет существовать идеальная система управления, вы то для чего будете нужны :) P.S. Может кто поделится инфой что должен делать оператор, как, к каким ресурсам должен быть доступ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
terrible Опубликовано 12 ноября, 2010 · Жалоба что должен делать оператор, как, к каким ресурсам должен быть доступПервое и самое главное - он должен делать деньги!Второе - заработанные даньги он должен экономить! Третье - он должен всегда стремиться к новым возможностям заработка денег и их экономии! Всё остальное - детали, если вам важны детали - то у каждого свои бизнес-процессы, и каждому бизнес-процессу требуется строго-определённый уровень получения количества данных для работы - не больше и не меньше. И не идите вперёд паравоза, для реальной работы первоначально требуется чётко описать бизнес-процесс, а уже под него допиливать СУ. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jingvar Опубликовано 12 ноября, 2010 · Жалоба И не идите вперёд паравоза, для реальной работы первоначально требуется чётко описать бизнес-процесс, а уже под него допиливать СУ. Так о чем я и говорю, без этого обсуждать СУ и их связки нет смысла. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dvolodin Опубликовано 13 ноября, 2010 · Жалоба что должен делать оператор, как, к каким ресурсам должен быть доступПервое и самое главное - он должен делать деньги!Второе - заработанные даньги он должен экономить! Третье - он должен всегда стремиться к новым возможностям заработка денег и их экономии! Вы путаете оператора и менеджера по продажам. Оператор должен работать с клиентом согласно своим инструкциям, в отдельных случаях проводить диагностику по диагностическим картам,в противном случае передавать клиента на вторую линию, если не стоит задача срочно разгрузить вторую линию. Если нет четкого разделения должностных функций и все занимаются всем, то это означает только, что в конторе творится форменный бардак. В результате автоматизации бардака может получиться только автоматизированный бардак. Всё остальное - детали, если вам важны детали - то у каждого свои бизнес-процессы, и каждому бизнес-процессу требуется строго-определённый уровень получения количества данных для работы - не больше и не меньше. И не идите вперёд паравоза, для реальной работы первоначально требуется чётко описать бизнес-процесс, а уже под него допиливать СУ. Вы не забывайте, что бизнес-процессы имеют нехорошую привычку изменяться. Иногда они меняются даже во время реинжениринга :) Разделение функционала по службам и системам позволяет, в определенной мере, устранить перекосы, возникающие при смене процессов. Обычно всякая лобуда, связанная с маркетингом, работой с клиентами, тарифными планами и прочим куда более динамична, чем работа службы эксплуатации, которая по определению весьма статична и не допускает излишней дерготни. Всякие мартетинговые ходы позволяют привлечь новых клиентов, а стабильная работа и качество сервиса - важнейшие факторы их удержания. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 13 ноября, 2010 (изменено) · Жалоба dvolodin Поделитесь Вашей точкой зрения на процесс общения первой линии с абонентом. Допустим звонит "блондинка" и говорит, что "интернет не работает", посмотреть статус линка, тем более выполнить ipconfig /all не в состоянии. (Допустим, что проблема в том, что абонент установил фаервол типа "iptables -I INPUT -j DROP") Оператору удаётся узнать ФИО и домашний адрес. Что должен делать оператор дальше? В какие системы ползти?(особенно интересует как в этом учавствует nocproject). Вариант - составить заявку и отправить на вторую линию не предлагать или же описать алгоритм работы второй линии по типовым заявкам "не работает интернет" Изменено 13 ноября, 2010 пользователем s.lobanov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 13 ноября, 2010 · Жалоба Убедится что проблема есть: проверить не ушёл ли в минуса или всякую блокировку биллингом типа юзер сам заблокировал или его отключили за вирусную активность и тп. Уже потом искать в технических плоскостях проблему. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dvolodin Опубликовано 15 ноября, 2010 · Жалоба dvolodin Поделитесь Вашей точкой зрения на процесс общения первой линии с абонентом. Допустим звонит "блондинка" и говорит, что "интернет не работает", посмотреть статус линка, тем более выполнить ipconfig /all не в состоянии. (Допустим, что проблема в том, что абонент установил фаервол типа "iptables -I INPUT -j DROP") Оператору удаётся узнать ФИО и домашний адрес. Что должен делать оператор дальше? В какие системы ползти?(особенно интересует как в этом учавствует nocproject). Вариант - составить заявку и отправить на вторую линию не предлагать или же описать алгоритм работы второй линии по типовым заявкам "не работает интернет" Да хотя бы так:* При входящем вызове у оператора в CRM'е выскакивает dashboard с состоянием счета клиента и текущим статусом сервисов, если удается определить клиента по A-номеру. Если не удается - спрашиваем номер договора и ищем руками и получаем тот же dashboard. * Дальше, в идеале, проходим по шагам по карте. Если надо, например, посмотреть маки на порту, то можно пнуть тот же сторонний service activation и получить их. Линк стоит - маков нет - идем дальше. * Ходим по карте пока не исчерпываем все варианты, которые вы предусмотрели для девочек. Не помогло - отдаем на вторую линию. * Опционально девочек спихиваем на аутсорс. Несогласных - в декрет. Как будет выглядеть процесс диагностики - зависит от вашей сети и от ваших проблем. У всех оно по-разному выглядит. Важно то, что CRM'у достаточно только уметь запрашивать нужную информацию у других систем (включая биллинг), а другим системам - отдавать информацию. Если бизнес-процессы просты, и девочку не обламывает схватить бухту кабеля и побежать перетягивать клиента, то пойдут и простые решения, где все в одном (биллинг, CRM, OSS'ы). А если задача посложней, то придется комбинировать более специализированные системы и, возможно, часть дорабатывать. В отдельных случаях NOC может быть хорошим кубиком и альтернативой написанию аналогичного функционала с нуля. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...