Горе от высоких технологий

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

Как известно, организационные и финансовые проблемы способны «убить» любой проект в области высоких технологий. Однако верно и другое: для таких проектов «гибельной» может оказаться, как это ни парадоксально звучит, сама технология. По моим оценкам, каждый третий проект, запущенный в 2000 г., имел по крайней мере один серьезный технологический изъян.

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

БОЛЬШАЯ ТРОЙКА

В основе технологических просчетов лежат три основные причины: некорретная или неполная информация о требованиях к сети, несоответствие характеристик продукта заявленным производителем и проблемы совместимости.

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

Что касается продуктов, то нет ничего удивительного в том, что многие производители «перехваливают» свои детища, чтобы их продать. Чаще всего это касается способности обработки специфических видов трафика (например, когда приложению необходимо предоставить определенный уровень производительности). В такой ситуации сеть оказывается не в состоянии адекватно функционировать.

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

Завышение поставщиками возможностей своей продукции пользователи считают основной причиной неадекватной производительности. Руководство большинства компаний не прочь иметь возможность контроля над относительной приоритезацией трафика. Поэтому часто поддержка приоритезации становится решающим аргументом в пользу того или иного поставщика. Почти столь же часто ожидания пользователя не оправдываются. Либо от него требуются дополнительные усилия («Как, вы не установили общекорпоративную систему на базе правил? Что же вы хотите?»), либо заявленные возможности не реализуются вообще.

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

ГДЕ ЖЕ ВЫХОД?

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

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

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

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

Первое — не поддаваться на разного рода рекламные трюки. Рыночные тенденции обычно порождает и поддерживает потенциальность, а не реальность. Легко сказать — не обращайте внимания на новые поветрия, ведь реклама действует обычно на сознание пользователя сильнее, чем он готов признать. Это вызвано тем, что пользователи редко обращаются к альтернативным источникам информации, когда хотят узнать о тех или иных тенденциях развития технологий.

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

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

Чаще всего компании подавляющее большинство проектов расширения сети финансируют в конечном счете по остаточному принципу, «когда прижмет», а не из бюджета развития сети. Попытка втиснуть эти проекты и требования в прокрустово ложе существующей сети подрывает силы обслуживающей сеть группы — и в итоге саму сеть.