Ob-iVan

Почему надо мальчика посылать? Неужели это дешевле, чем объяснить все клиенту по телефону. Мы в обычном режиме предпочитаем телефон, если конечно нет авральной нагрузки на линии. Для базовой настройки роутера в телефонном режиме общения нужно менее 5 минут, при условии что пользователь на том конце более-менее адекватен и телефон у него не в 10 метрах от компьютера. Если на эту операцию приходится тратить полчаса - то да, будет правильнее после первых 5-10 минут разговора сказать, что лучше сейчас подойдет мальчик, так как с большой вероятностью данный клиент в конечном итоге сделает что-то такое, после чего мальчику все равно придется туда идти. Так зачем тратить время на разговор? Правильная оценка уровня квалификации пользователя в процессе общения (и выработка стратегии дальнейших действий в зависимости от этого уровня) - важный компонент работы сотрудника телефонной техподдержки. Если человек звонит с мобильного телефона в полицию и говорит, что-он очкарик-ботаник за которым гонятся гопники с бейсбольными битами, то нужно не технике самообороны его по телефону учить, а наряд скорее высылать ;)

А ничего больше говорить и не надо. Продолжайте использовать готовые унифицированные решения и никогда даже не думайте о том, что можно написать что-нибудь более адаптированное под конкретную структуру сети. Ведь если Вы не можете написать систему, которая в заданной конфигурации сети работает лучше, чем *STP, то и никто другой не может. Это же очевидно. Ага, точно. Видно, квалификации не хватило :) Разве может человек, написавший распределенную систему управления сетью, освоить настройку *STP? Это ж придется стать настоящим Одмином, а не оставаться каким-то ничтожным системным программистом. Куда уж нам, сирым ;) Ну а если серьезно, то различные версии STP проработали у нас более 5 лет. Поэтому сравнивать есть с чем. И после этого сравнения возвращаться на STP в ближайшее время я точно не собираюсь :) Не хочется разрушать Ваш уютный мирок рассказами о том, за какое минимальное время RSTP успевает гарантированно обнаружить возникновение петли и разрулить ее, и сколько пакетов до этого момента успевает по такой петле пройти на скорости 10G. А то вдруг и Вам станет страшно. Уж лучше оставайтесь в среде пользователей готовых *STP-систем и спокойно спите по ночам, потому что в мире разработчиков таких систем Вам могут ненароком рассказать столько ужасных фактов о недостатках существующих вариаций STP-протокола, что после этого Вы уже никогда не сможете смотреть на мир так, как раньше. А так, меньше знаешь - лучше спишь. P.S.: Может кто-нибудь еще хочет что-то рассказать о недостатках системы, с характеристиками которой он совершенно не знаком? Обязательно попробуйте! У вас получится не хуже, чем у предыдущих ораторов ;)

А вот это - зря. Дело совсем не в том, что сотрудников техподдержки нужно подозревать в недобросовестности. Скорее речь о "добросовестных заблуждениях". Примеров можно привести массу. Например, сотрудник на телефоне в течение получаса объяснял совершенно неподготовленному клиенту, как настроить роутер. И они таки его настроили. Сотрудник очень доволен собой и гордо смотрит по сторонам. И если ему не объяснить, что в таких случаях нужно не линию полчаса занимать, а "мальчика" к клиенту посылать, то он и в следующий раз так сделает. Инструкции, конечно, помогают, но всех случаев все равно заранее не предусмотришь. Поэтому постоянный контроль и оптимизация работы службы техподдержки - IMHO, вещь очень полезная.

Вы попросили привести практический пример, при котором тормознутость web-smart свитчей может стать проблемой. Я такой пример привел. Вы назвали систему, после внедрения которой практическая надежность работы нашей сети значительно возросла, "костылем" - ну что ж, это Ваше право давать любым вещам любые удобные Вам определения. И никто у Вас это право не отнимет ;) Я бы мог придумать достаточное количество вполне жизненных примеров, когда нужна быстрая и надежная работа тех функций, программная реализация которых у web-smart свитчей откровенно тормозит - но зачем? Автор темы мой совет, надеюсь, услышал. А переубеждать в чем-то лично Вас я не собираюсь. Продолжайте ставить web-smart свитчи в критических точках и убеждайте себя, что они ничем не хуже полноценных управлялок, гоняйте на малолитражках и утверждайте, что они ничем не хуже спорткаров и т.д. Удачи Вам во всех Ваших начинаниях! Я даже представить себе боюсь что будет, если на такую задачу я поставлю D-Link DGS-12XX. Прятно осознавать, что все-таки есть люди, понимающие разницу между свитчами разных классов.

Собственно на такой класс задач этот свитч и ориентирован. IMHO, вполне можно.

Если уважаемые собеседники не возражают, я сгруппирую похожие вопросы вместе и прокомментирую их не в том порядке, в котором они задавались. Про это многократно говорила техподдержка D-Link'a. Если так, навскидку, то например здесь: или здесь: или здесь: или еще в куче мест на форуме D-Link'a. Поиск в помощь. Когда я в личной переписке спрашивал у D-Link'овцев, есть ли шансы, что в новых прошивках появится возможность увеличить приоритет обработки пингов, мне ответили, что шансов нет, так как ограничения там аппаратные и "он играет так, как может" (с) Можно, конечно, усомниться в компетенции сотрудников представительства D-Link, но косвенно их слова подтверждаются тем фактом, что подобные задержки пингов у этих моделей есть даже тогда, когда на них отключено все, что только можно отключить, и нет никакой сетевой нагрузки. Что там может быть более приоритетным, когда свитч ничего не делает? Idle-циклы процессора? ------------------------- Например у нас в сети по ряду причин не используется протокол STP. Вместо этого свитчи управляются по snmp с центрального узла. Как только где-то обрывается линк, включаются порты на резерв, как только линк восстанавливается - резервные порты отключается. Нужно ли объяснять, насколько важна скорость реакции свитча при восстановлении основного линка (т.е. фактически - при возникновении петли, стандартные средства разрешения которой отключены)? Это лишь один из примеров, важных конкретно для меня.

Ок, хуавеи и циски - паршивые свичи. Тплинк, по вашему критерию - просто замечательный свич.... Когда человек при цитировании собеседника сознательно приводит из нескольких взаимодополняющих фраз только одну, и на основании этой фразы пытается сделать от имени собеседника заведомо неверные выводы, это говорит о слабости его позиции и отсутствии корректных аргументов в ее пользу. Вы "забыли" первую фразу из моего постинга. Вот как это звучало в оригинале ("забытая Вами фраза выделена красным"): Это к вопросу о том, замечательный ли свитч TP-Link. Теперь о том, паршивый ли свитч Huawei. Вам кажется, что приведенные Вами результаты пингов Huawei S2326TP-EI так ужасны? Тогда Вы не видели настоящего ужаса. Итак, привожу обещанные результаты тестирования двух свитчей разных классов от одного и того же производителя. Оба свитча сброшены в дефолтные настройки и подключена напрямую к Gigabit Ethernet порту ноутбука с Windows 7. Нагрузки на свитчи (кроме самих пингов) в момент тесрирования нет. Первый свитч - стандартная "рабочая лошадка" D-Link DES-3200-10: C:\Users\Ivan>ping -n 20 10.90.90.90 Обмен пакетами с 10.90.90.90 по с 32 байтами данных: Ответ от 10.90.90.90: число байт=32 время=3мс TTL=30 Ответ от 10.90.90.90: число байт=32 время=3мс TTL=30 Ответ от 10.90.90.90: число байт=32 время=3мс TTL=30 Ответ от 10.90.90.90: число байт=32 время=3мс TTL=30 Ответ от 10.90.90.90: число байт=32 время=3мс TTL=30 Ответ от 10.90.90.90: число байт=32 время=4мс TTL=30 Ответ от 10.90.90.90: число байт=32 время=3мс TTL=30 Ответ от 10.90.90.90: число байт=32 время=3мс TTL=30 Ответ от 10.90.90.90: число байт=32 время=4мс TTL=30 Ответ от 10.90.90.90: число байт=32 время=4мс TTL=30 Ответ от 10.90.90.90: число байт=32 время=3мс TTL=30 Ответ от 10.90.90.90: число байт=32 время=3мс TTL=30 Ответ от 10.90.90.90: число байт=32 время=4мс TTL=30 Ответ от 10.90.90.90: число байт=32 время=4мс TTL=30 Ответ от 10.90.90.90: число байт=32 время=4мс TTL=30 Ответ от 10.90.90.90: число байт=32 время=3мс TTL=30 Ответ от 10.90.90.90: число байт=32 время=4мс TTL=30 Ответ от 10.90.90.90: число байт=32 время=3мс TTL=30 Ответ от 10.90.90.90: число байт=32 время=4мс TTL=30 Ответ от 10.90.90.90: число байт=32 время=3мс TTL=30 Статистика Ping для 10.90.90.90: Пакетов: отправлено = 20, получено = 20, потеряно = 0 (0% потерь) Приблизительное время приема-передачи в мс: Минимальное = 3мсек, Максимальное = 4 мсек, Среднее = 3 мсек Ничего заслуживающего комментариев. Пинги - как пинги. А теперь - гвоздь программы! Web-Smart свитч D-Link DES-1210-28. Вот его полные данные: Device Type DES-1210-28 Boot Version 1.00.002 Firmware Version 2.10.000 Protocol Version 2.001.004 Hardware Version B1 Serial Number QBL21C6000707 А теперь - пинги: C:\Users\Ivan>ping -n 20 10.90.90.90 Обмен пакетами с 10.90.90.90 по с 32 байтами данных: Ответ от 10.90.90.90: число байт=32 время=586мс TTL=64 Ответ от 10.90.90.90: число байт=32 время=16мс TTL=64 Ответ от 10.90.90.90: число байт=32 время=196мс TTL=64 Ответ от 10.90.90.90: число байт=32 время=7мс TTL=64 Ответ от 10.90.90.90: число байт=32 время=6мс TTL=64 Ответ от 10.90.90.90: число байт=32 время=416мс TTL=64 Ответ от 10.90.90.90: число байт=32 время=7мс TTL=64 Ответ от 10.90.90.90: число байт=32 время=32мс TTL=64 Ответ от 10.90.90.90: число байт=32 время=19мс TTL=64 Ответ от 10.90.90.90: число байт=32 время=10мс TTL=64 Ответ от 10.90.90.90: число байт=32 время=274мс TTL=64 Ответ от 10.90.90.90: число байт=32 время=5мс TTL=64 Ответ от 10.90.90.90: число байт=32 время=8мс TTL=64 Ответ от 10.90.90.90: число байт=32 время=533мс TTL=64 Ответ от 10.90.90.90: число байт=32 время=6мс TTL=64 Ответ от 10.90.90.90: число байт=32 время=161мс TTL=64 Ответ от 10.90.90.90: число байт=32 время=20мс TTL=64 Ответ от 10.90.90.90: число байт=32 время=5мс TTL=64 Ответ от 10.90.90.90: число байт=32 время=415мс TTL=64 Ответ от 10.90.90.90: число байт=32 время=5мс TTL=64 Статистика Ping для 10.90.90.90: Пакетов: отправлено = 20, получено = 20, потеряно = 0 (0% потерь) Приблизительное время приема-передачи в мс: Минимальное = 5мсек, Максимальное = 586 мсек, Среднее = 136 мсек Вот, что я называю ПЛОХИМИ ПИНГАМИ! И вот что такое Web-Smart серии 1210 "во всей своей красе". В момент тестирования он не делал вообще ничего: только отвечал на пинги. И при этом умудрялся думать более чем пол секунды над самым простым действием - возвратом ICMP пакета (а если запустить серию из 1000 пингов, то и секундные задержки можно встретить) И Вы всерьез утверждаете, что такой дохлый CPU способен полноценно динамически управлять системой коммутации пакетов?

Вот как раз прием заявок (и решение заявленных проблем) и является главной (а в идеале - единственной) функцией службы техподдержки. И конечно же такие заявки должны принимать и обрабатывать живые люди. Не знаю, у кого как, а у нас человек может зайти на свою страничку биллинга из любой точки мира, в том числе с работы и с мобильного телефона. Вообще говоря, на мой взгляд, биллинг, на который можно зайти только изнутри сети и/или только с положительным балансом, это что-то противоестественное. Кроме того, рабочий день провайдера, обслуживающего не только юридических, но и физических лиц, не должен заканчиваться раньше восьми вечера, чтобы большинство пользователей имело возможность обратиться в техподдержку после работы. IMHO, если стабильность работы сети находится на достаточном уровне, то пользователь, у которого пропал Интернет, в первую очередь думает что причина в отрицательном балансе или зависании роутера. Если при пропадании Интернета пользователь сразу же начинает звонить в техподдержку, значит над надежностью сети надо еще очень серьезно работать. А вот с этим тезисом соглашусь на 100% :)

andryas, если на свитч хороший пинг, то само по себе это еще но означает, что это хороший свитч ;) Впрочем, лично я ничего против Микротиков не имею, хотя сам ими и не пользуюсь. А вот если пинг на свитч паршивый, то это серьезный повод задуматься о многом. Например о том, можно ли использовать пингование этого свитча для мониторинга сети, удастся ли скачать с него до конца таблицу MAC'ов на портах по snmp до ухода в глубокий таймаут, можно ли будет зайти на него во время жесткого флуда и отключить нужный порт и т.д. P.S.: Поверьте, если вы раньше не пробовали пинговать DES-1210-28, его пинги вас впечатлят ;) Это не просто плохо. Это запредельно.

Свободного DES-1228 у меня в зоне досягаемости нет. Завтра возьму на складе его одноклассника DES-1210-28 и, для сравнения, DES-3200-10, сброшу их в дефолтные насройки (чтобы никто не сказал, что я их криво настроил) и подключу напрямую к ноутбуку без нагрузки (чтобы никто не сказал, что я взвалил на них непосильную ношу), после чего выложу на форум результаты серии пингов интерфейсов этих свитчей. Потом прокомментирую, почему такой результат.

Почти он: http://forum.nag.ru/forum/index.php?showtopic=88942

Так у вас узкое место - количество линий, а не сотрудников? Богато живёте :) Узкое место у нас - количество линий, на конце которых расположены сотрудники :) А живем мы скромно ;)

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

Ну вообще то так и есть. Малолитражка подразумевает высокооборотистый движек (иначе она просто не поедет). Как прямое следствие гораздо более низкий мото-ресурс и более высокий износ. myst, Вы вставили фрагмент моего сообщения в виде цитаты так, что это выглядит, как будто именно я сомневаюсь в том, что малолитражка менее надежна, чем гоночный автомобиль ;)

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