• Пьеса «Технический долг»
    +86

    Притча "Менеджер и программист"


    Человек, летящий на воздушном шаре, обнаружил, что потерялся. Он спустился немного ниже и заметил на земле женщину. Спустившись ещё чуть ниже, он обратился к ней:
    — Простите, не могли бы вы помочь? Я договорился с другом встретиться час назад, но не знаю, где сейчас нахожусь.
    — Вы находитесь на воздушном шаре в 30 футах от поверхности Земли, между 40 и 41 градусом северной широты и между 59 и 60 градусом западной долготы ответила женщина.
    — Вы, должно быть, программист?
    — Да, а как вы догадались?
    — Вы мне дали абсолютно точный ответ, но я совершено не представляю, что делать с этой информацией, и я всё ещё потерян. Откровенно
    говоря, вы мне совершенно ничем не помогли.
    — А вы, наверное, менеджер?
    — Да. А вы как догадались?
    — Вы не знаете, где находитесь и куда направляетесь. Поднялись вы туда, благодаря воздуху. Вы дали обещание, которое не представляете, как выполнять, и ожидаете, что люди, которые находятся ниже вас, решат ваши проблемы. И, наконец, сейчас вы в том же самом положении, в котором находились до встречи со мной, но почему-то теперь в этом оказалась виновата я.


    Просто почему-то вспомнилось...

  • Panasonic KX-NSX: новые АТС для корпоративного рынка
    0
    Может быть скажу банальную вещь, но не всё можно сравнить лоб в лоб. Как всегда есть масса нюансов. Я попробую выразить свои мысли на эту тему, но не судите строго, так как сам я над этим много не думал. По роду своей деятельности я занимаюсь коммутаторами для ёмкостей на порядок выше и сетями другими. Поэтому трудностей решений уровня УПАТС я просто не знаю заранее.

    В общем все же понимают, что компании бывают разного размера и сферы деятельности, с разными задачами и способами их решения. От имиджа и внешнего вида до того, какой порядок реализации проекта и политика расхода бюджета на поставленные задачи. Поэтому вопрос по выбору решения далеко не только технический. Удобство администрирования, защищённость и отказоустойчивость — это части того аспекта, на основание которого принимают решения по пункту — эксплуатация. Сертификация — тоже довольно важный пункт для тех, кто хочет выполнить свою часть работы в компании. Речь идёт о выборе продукта, который защищён документом, подтверждающим способности этого программно-аппаратного комплекса. Ведь в случае провала внедрения, будет как в том монологе — «К пуговицам претензии есть? — Нет. Пришиты намертво, не оторвёшь» :)

    Для кого то астериск хорошее решение. Кому то больше подойдёт станция сама в себе. Кто то собирает инфраструктуру из разных решений. В любом случае при выборе того или иного решения, всегда будет список из пунктов, по которым надо принять решение. Например по персоналу:
    • кто спроектирует план нумерации и маршрутизации?
    • кто задаст правила пользования телефонной сетью с применением ДВО?
    • кто следит и отвечает за безопасностью голосовой сети и трафика?
    • кто следит и отвечает за безопасность программной платформы?
    • кто следит и отвечает за состоянием аппаратной платформы?

    Но это бытовуха. А что касательно стратегических решений:
    • кто рассчитает требуемые ресурсы на обеспечение связью офисов и филиалов (количество одновременных invite/setup/iam, организация СЛ в ЧНН)?
    • централизованная или распределённая архитектура?
    • как повысить отказоустойчивость?
    • нужна ли возможность производить модернизацию и обновления ПО на ходу, без остановки коммутации?
    • как быстро можно получить ЗИП, услуги ремонта, хелпдеска?
    • а сколько стоит этот ЗИП для разных решений (интерфейсные платы, расширение функционала/ресурса, абонентские устройства, базовые станции и пр)?
    • как сделать инфраструктуру не уникальным творением отдельно взятого человека, который там и будет сидеть на ней, и которого не выгонишь? (а у меня полно таких историй из жизни)


    В конце концов из всего этого и, наверное, ещё кучи других аспектов, выясняется:
    • сколько денег потребуется на содержание персонала (аусорс или штатного сотрудника)
    • риски в эксплуатации по части безопасности (взлом и до ближайшего ежемесячного счёта вы не узнаете сколько через ваш узел прошло вызовов на платные сервисы в страны Южной Америки)
    • риски из-за простоя или не удовлетворительного качества инфраструктуры (отсутсвие слышимости или помехи в голосовом канале, отвалившиеся удалённые локации или другие технические проблемы)


    И после этого:
    • кому-то подойдёт астериск, со своим постоянным квалифицированным админом, или скорее группы администраторов, для поддержания всей разносторонней инфраструктуры (nix, *, ethernet и уровни выше, эникей для расстановки телефонов и решения проблем на рабочем месте) + человеческий резерв ко всей этот компании славных парней или девушек.
    • кто-то выберет продукт в железном монолитном исполнение, к которому нужен один человек на все 2000 учёток на станции + эникей + резерв.
    • ещё кто-то решит, что ему нужны простые и быстрые способы развернуть филиал с достаточной степенью надёжности, что бы не привнести туда человеческий фактор, вариации монтажа, подключений и танцев с музыкальными инструментами древних при, вроде как стандартных протоколах, но реализованных чуть по другому, немного не охватывающих всех вариаций и проблем на сетях пакетной связи. И уже эти будут выбирать между решения на рынке, а не тем, что можно собрать самому из всякого разного.


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

    Ещё я считаю бессмысленным вдаваться в вопросы функционала при поверхностном сравнение, без необходимости взвесить ВСЁ под конкретный проект. Так или иначе, можно реализовать, наверное, любые функции как на открытом ПО, так и на проприетарном решение, вроде сабжа данной статьи. Только в случае с открытым ПО (астериск к примеру) вы получаете всё, что только смогли придумать и реализовать (причём не с гарантией качества), а в случае с проприетарным изделием вы получаете то, что реализовал вендор. И реализация вендора вас может устроить или нет. В остальном же, в какую сторону смотрите вы, или другой человек, — решается исключительно из опыта и принципов каждого. При запросе финансирования на реализацию того или иного способа телефонизации, вопрос будет решаться в большинстве случаев исходя из принципов расхода бюджета — вложиться или тратить постепенно… Или вообще «пусть как хотят, так и собирают эти ваши интернеты из говна и палок за 50% от запроса». Техническая же дирекция будет стремиться рассмотреть вопрос на ряду с более высокой эксплуатационной характеристикой. Начальнику IT сектора (или его аналогу) интересно большими частями разделить бюджет отдела, без найма дополнительных сотрудников. А значит с задачей должны справляться существующие + спец (или вырастить спеца из существующего, если у него есть время и желание). У самих же исполнителей варианта два: либо они хотят иметь меньше проблем, либо им нужно стабильное место и они там городят чёрт чего (когда речь об этом заходит, вспоминается картинка «я сплёл сеть жопой! А чего добился ты?»)

    Вот вам пример, когда компания решила потратить деньги на отказоустойчивость и проверенную десятилетиями надёжную технологию, дабы минимизировать человеческий фактор и разграничить зоны ответственности между отделами.
    Я лично предпочитаю иметь как можно меньше проблем с тем сектором сервисов, за которые я отвечаю. В связи с этим я стараюсь мои сервисы как можно больше выделить в отдельные сети и аппаратные решения, что бы за них нёс ответственность только т.с. мой отдел. Например для голосового трафика я предпочитаю сеть SDH, нежели IP. Ведь IP занимаются другие люди, там что то постоянно происходит при выстраивание архитектуры и сервисов согласно поступающим им задачам. Шанс того, что сервис, за который отвечаю я, пострадает, заметно увеличивается. И компании, где я работаю, пришлось в общем случае потратить лишний, наверное, 1-1,5млн в общей сложности на мультиплексоры, STM-¼ модули и тёмные волокна для выстраивания колец для большей части голосового трафика и каналов G.703. Но как говорилось в том пранке — «ни единого разрыва», даже когда магистральные кабели резали и переваривали в нескольких местах (SDH сеть обеспечивает мгновенную сходимость, которую, даже при полной загрузке STM контейнера в 63 потока Е1 в ЧНН, пользователь скорее всего не заметит). Не говорю уже о синхронизации сети TDM станций и сигнальных шлюзов. Положиться на сетевиков я не могу, потому как инциденты бывают, а мои принципы расходятся с их принципами. Ну и ещё так сложилось, что у меня есть приборы для паспортизации моей сети, а у них нет. Соответственно и ловить косяки на низких уровнях могу все, но я могу их найти или доказать, что проблема не в моей зоне ответственности, поставив на ГОСТовский тест G.703 потока через любой набор узлов моей сети.
    Сейчас мы разворачиваем узел на базе пакетной коммутации голосового трафика (это сертифицированный до уровня АМТС программно-аппаратный комплекс на серверах с декларациями серии ССС). Скоро сдавать пакет документации в роскомнадзор, а сеть между элементами нового узла не до конца выстроена и всё это будет делаться уже тогда, когда хотелось бы забыть о вопросах такого низкого уровня и заниматься только планами маршрутизации.

    Надеюсь, что я дал вам какую то пищу для размышлений.