Ответы на наиболее часто задаваемые вопросы о том, как внедрять управление ИТ-услугами на основе рекомендаций ITIL

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

Прежде всего определимся с часто упоминаемыми терминами, вызывающими путаницу. Управление ИТ-услугами (Information Technology Service Management, ITSM) – это сервисный процессный подход к организации работы ИТ-службы. Суть его в том, что вся деятельность ИТ-подразделения рассматривается в разрезе услуг, оказываемых им другим подразделениям в соответствии с соглашениями об уровне услуг. ITSM декларирует, что ИТ-отделом можно управлять, основываясь на тех же принципах, которые применимы к бизнес-подразделениям.

Библиотека ИТ-инфраструктуры (Information Techno-logy Infrastructure Library, ITIL) – это библиотека рекомендаций, обобщающая международный опыт по организации работы ИТ-департаментов и разъясняющая, что надо сделать для реализации подхода ITSM. ITIIL состоит из ряда книг, каждая из которых описывает тот или иной аспект деятельности в виде набора процессов. В настоящее время выпущена вторая версия ITIL, активно ведется работа над созданием третьей. В ITIL описывается, как должна быть организована деятельность ИТ-структур, но не приводятся конкретные шаги по внедрению содержащихся в ITIL рекомендаций. Конкретные методики внедрения ITSM на основе ITIL предлагают компании, которые специализируются на подобных проектах.

Этот и подобные вопросы вызвали немало дискуссий. Самый распространенный ответ такой: внедрение процессной модели в соответствии с рекомендациями ITIL позволит бизнесу исходить из собственных потребностей при оценке ИТ-услуг и уже в соответствии с ними планировать расходы на ИТ и определять ключевые показатели эффективности. Кроме того, повышается прозрачность ИТ для бизнеса, что вместо вкладывания денег в «черную дыру ИТ» приводит к прогнозируемому инвестированию в развитие ИТ как в серьезное подспорье для бизнеса и потенциал для развития новых конкурентных преимуществ компании. Такой ответ, как правило, хорошо принимается руководством компании.

Сотрудникам же бизнес-подразделений следует объяснить, что внедрение рекомендаций ITIL обеспечит им более качественное обслуживание, сокращение времени возможных простоев и перебоев, а также быстрое рассмотрение и реакцию на все без исключения обращения в ИТ-службу. У них появится уверенность в том, что каждое обращение будет отработано по принятым правилам в установленный срок.

Для получения финансирования проекта по внедрению ITSM часто необходимы убедительные обоснования. В зависимости от конкретного случая это могут быть следующие три основных аргумента.

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

Увеличение эффективности и направление фокуса ИТ-деятельности на решение задач бизнеса.

Внедрение даже ограниченного набора процессов ITIL (службы Service Desk и процессов управления инцидентами и уровнем услуг) позволит организовать работу ИТ-службы таким образом, что в центре ее внимания окажется именно бизнес. ИТ-отдел из «вещи в себе» превратится в ориентированную на потребности бизнеса внутреннюю сервисную структуру.

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

Дополнительным аргументом может служить ответ на вопрос об окупаемости проекта по внедрению ITSM. Стоимость решения заявки на этапе промышленной эксплуатации решения, состоящего из процессной части и настроенной системы автоматизации в случае, когда внедрена часть процессов ITIL, по сравнению с ситуацией, когда не внедрен ни один из процессов, в пересчете на единицу времени оказывается ниже. Таким образом, окупаемость проекта по внедрению рекомендаций ITSM может быть вычислена для каждой конкретной организации. В простейшем случае рассчитываются стоимости единицы рабочего времени специалиста каждой из линий поддержки до и после внедрения. Более сложный расчет учитывает стоимость возможного простоя сотрудников бизнес-подразделений, стоимость аренды помещений и т.д.

Следует ли затраты на ИТ распределять по бизнес-подразделениям и бизнес-пользователям?

Ответ на этот вопрос кроется в финансовой учетной политике относительно ИТ на конкретном предприятии. Если ИТ-отдел выделен как независимый центр затрат и прибыли (то есть является самоокупаемой организацией), то затраты на ИТ-услуги могут быть соотнесены с конкретным бизнес-подразделением. Подобная деятельность ведется, как правило, в рамках процесса управления финансами. В этом случае ИТ-служба и бизнес-подразделения становятся полноценными участниками внутреннего рынка ИТ-услуг.

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

С чего начать внедрение? Какие процессы внедрять?

Проект по внедрению рекомендаций ITIL, как и любой другой, связанный с управлением, следует начать с определения бизнес-требований и анализа состояния дел ИТ-департамента. Для анализа можно применять известные методики (например, Pink Elephant, HP ITSM) или самостоятельно составленные опросные листы. Как правило, дополнительно проводится анализ по бизнес-модели: делается описание того, как работает ИТ-отдел в данный момент, в виде связанной совокупности бизнес-процессов. Следует отметить, что такой анализ полезен даже в случае полной деструктурированности работы ИТ, поскольку помогает выявить внутренние зависимости и связи, опираясь на которые, можно будет спроектировать тот или иной процесс.

Одновременно с построением картины работы «как есть» проводится анализ бизнес-требований к ИТ-отделу на основе сбора и обобщения требований и ожиданий бизнеса от ИТ и возможностей ИТ-службы удовлетворить потребности бизнес-подразделений.

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

Как установить соответствие между услугами, которые бизнес желает (или ожидает) получить от ИТ-подразделения, и ИТ-услугами?

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

Какие фазы внедрения ITSM существуют? Что влияет на его успешное завершение?

Классический проект по внедрению процессной модели в соответствии с рекомендациями ITIL действительно может проходить в несколько фаз. О первых трех из них (аудите ИТ-службы предприятия, определении бизнес-требований и ожиданий от ИТ, выявлении слабых мест в управлении ИТ-службой, определении состава процессов ITIL, подлежащих внедрению) мы уже рассказали. Следом за реализацией этих фаз необходимо определить систему для автоматизации выбранных процессов. Результаты аудита и выбора процессов ITIL, а также средства автоматизации представляют руководству предприятия и сотрудникам ИТ. Наконец, после этого осуществляется последовательное внедрение каждого из названных выше процессов. Оно идет в несколько этапов: разработка технического задания или технических требований на внедрение процесса; описание внедряемого процесса; определение требований к системе автоматизации; описание настроек системы автоматизации; настройка системы автоматизации; опытная эксплуатация.

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

Обязательно ли организовывать Service Desk?

Внедрение службы Service Desk целесообразно по нескольким причинам. Большинство современных средств автоматизации предусматривает возможность регистрации инцидентов самим пользователем (посредством Web-форм, например). Однако пользователь порой не в состоянии квалифицированно определить суть инцидента. Но даже если он может провести самостоятельную классификацию, все равно требуется уточнение (или, как минимум, подтверждение) специалиста. Автоматизированный ввод инцидентов самим пользователем не отменяет механизма ввода и диспетчеризации оператором Service Desk, поскольку в ряде случаев пользователь просто не имеет возможности завести заявку (инцидент) для автоматической обработки (например, при отсутствии технической возможности доступа к интерфейсу Service Desk).

Наличие Service Desk обеспечивает единую точку входа. Это очень важно, поскольку отпадает необходимость выстраивать персональные отношения с ИТ-специалистами, и пользователь всегда знает, куда ему обратиться с проблемами.

При отказе от Service Desk более вероятно возникновение «очередей» заявок у высококвалифицированных ИТ-специалистов, которые будут совершенно неэффективно тратить свои ресурсы. Запуск же квалифицированной службы Service Desk позволяет спустя некоторое время разрешать до 70% заявок на первой линии благодаря накоплению базы знаний и другим преимуществам правильно организованных процессов. Это экономит время высокооплачиваемых специалистов, и они могут направить его для решения более важных задач. Оставшиеся 30% заявок маршрутизируются таким образом, что гарантируется их скорейшее решение.

При отсутствии службы Service Desk ее функции выполняет вся ИТ-служба.

Как оценить численность сотрудников Service Desk?

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

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

Нельзя ли обойтись при внедрении рекомендаций ITIL без автоматизированной системы?

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

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

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

Может ли ITSM помочь при внедрении ERP (CRM и т.д.)?

Если в организации внедрен один или несколько процессов в соответствии с рекомендациями ITIL, безусловно, может. Служба Service Desk возьмет на себя ответы на запросы пользователей и регистрацию инцидентов, связанных с новой системой. Эти инциденты будут разрешаться в рамках процесса управления инцидентами, анализироваться и использоваться для выявления проблем в рамках процесса управления проблемами. Разрешение инцидентов будет происходить путем проведения изменений в рамках процесса управления изменениями, а информация о конфигурации инфраструктуры будет постоянно актуальной вследствие работы процесса управления конфигурациями. Расчет мощностей, требуемых для внедрения новой системы, будет проведен в рамках процесса управления мощностями, в рамках процесса управления доступностью будут сформированы требования, удовлетворение которых обеспечит требуемый уровень доступности. В рамках процесса управления непрерывностью будет сформирован план обеспечения непрерывности для ERP-системы, финансы на приобретение требуемых серверов и поддержку программно-аппаратного комплекса формируются в рамках процесса управления финансами, мероприятия по обеспечению безопасности конфиденциальных данных в ERP будут обеспечены в рамках процесса управления безопасностью. Далее, имея организованную в соответствии с определенными регламентами службу ИТ, легче проводить планирование внедрения, поскольку при четкой организации деятельности ИТ повышается прозрачность и управляемость ИТ.

Отдельно следует рассмотреть параллельное внедрение ERP и ITSM. В этом случае вероятность успешного завершения каждого из проектов будет ниже, чем при последовательном внедрении. Дело в том, что и тот и другой проект относятся к так называемым «стрессовым» проектам, требующим перестройки как ИТ-службы, так и бизнес-подразделений. Таким образом, на время параллельного внедрения ERP и ITSM повышается нагрузка на сотрудников, возрастает неопределенность и влияние человеческого фактора, в итоге значительно повышаются риски подобного проекта.

Чем ITSM может помочь при организации аутсорсинга?

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

Обязательно ли использовать консалтинг при внедрении ITSM?

Порой проще и выгоднее использовать компанию-консультанта, имеющую опыт внедрения проектов, связанных с ITSM, чем создавать свою команду. Тем более что после завершения проекта наверняка возникнет вопрос, что будет делать его команда. Распущена? Переведена на другие проекты? Как правило, внедрение рекомендаций ITIL — это совместный проект с внешней компанией-консультантом.

Что будет, когда закончится проект?

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

Размещено: Директор ИС, №03/2007

Распространенная задача, решать которую приходится практически во всех ИТ отделах, пытающихся применить принципы сервисного управления – построение, развитие и управление каталогом сервисов. Задача эта на первый взгляд достаточно тривиальная, однако и при ее решении существуют определенные «подводные камни».

Например, при решении задачи «в лоб», каталог сервисов часто заменяют на перечень эксплуатируемых ИТ систем и базового ПО. Подобный подход имеет ярко выраженный недостаток: при инвентаризации в средней компании (то есть, с числом АРМ порядка 500) может быть обнаружено порядка 100..300 систем и приложений, которые могут быть классифицированы как сервис. Таким образом, пользователь, обращаясь в ИТ для решения каких-либо вопросов, вынужден формулировать свой запрос «на языке ИТ», что принципиально противоречит рекомендациям ITIL. Другая крайность – чересчур широкое определение сервиса. Например, сервис «рабочее место пользователя» может включать в себя ПК, базовое ПО, специфическое ПО и периферийные устройства, что приближает количество инцидентов, связанных с данным сервисом, к 100% от общего числа зарегистрированных инцидентов.

Классическое определение понятия «сервис» гласит, что «сервис – есть процесс обслуживания объектов». Библиотека ITIL рекомендует определять сервис как информационную услугу, то есть ту услугу, которую отдел ИТ предоставляет пользователям. При этом в качестве пользователей могут выступать как сотрудники профильных для бизнеса подразделений, так и внешние заказчики (в этом случае вводится специальное понятие – аутсорсинг). По сути, такая трактовка означает, что отдел ИТ является обслуживающей организацией по отношению к пользователям.

Библиотека ITIL не содержит четкого алгоритма, при помощи которого может быть построен каталог сервисов. Единственная рекомендация – «взглянуть на мир глазами пользователя». В этом случае сервис может быть представлен в виде совокупности инструментальных средств, технологий, политик и методов. Например, информационным сервисом может выступать «доступ в Интернет», который может быть реализован для различных пользователей при помощи различного оборудования, различных инструментальных и технологических средств, но результат будет один – доступ конкретного пользователя к ресурсам Интернет. Подобный подход к сервису значительно упрощает жизнь простым пользователям, одновременно усложняя ее специалистам ИТ, поскольку в этом случае они должны иметь информацию о связях пользователя, сервиса и оборудования. (Следует отметить, что рекомендации ITIL не обходят вниманием эту проблему – процесс управления конфигурациями и конфигурационная база данных как раз направлены в том числе на решение указанной задачи).

Таким образом, примерный алгоритм построения каталога сервисов будет следующим:

• Составляется инвентарный перечень всех программных и аппаратных средств, а также политик
• Составляется список пользователей, которые работают с указанными средствами
• Пользователи объединяются в группы по определенным признакам (соответственно, выделяются признаки классификации)
• Для каждой из сформированных таким образом групп пользователей выделяются те ресурсы (программные и аппаратные средства, политики), которые ими используются
• Определяется примерный перечень сервисов для каждой из групп пользователей
• Определяется примерный перечень всех сервисов, которые предоставляются отделом ИТ
• Проводится аудит перечня сервисов

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

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

И, наконец, каталог сервисов и построенную матрицу необходимо отобразить в средстве автоматизации (для чего средство автоматизации должно поддерживать такую возможность). После чего можно переходить к следующей фазе – а именно, к управлению каталогом сервисов.

Управление каталогом сервисов включает в себя:

• Мониторинг текущего каталога сервисов
• Выявление новых сервисов
• Выявление новых территорий, требующих разворачивания тех или иных ИТ сервисов
• Выявление утративших актуальность сервисов
• Актуализация каталога сервисов

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

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

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

Рассмотрим типичную картину – среднестатистическое предприятие, у которого 300 работников, центральный офис, два филиала и пять точек продаж. В наличии имеется локальная сеть, самостоятельно разработанный комплекс ERP/CRM, реализована система мобильных продаж, интегрированная с ERP, и десяток серверов. ИТ-отдел содержит всю эту инфраструктуру и обеспечивает поддержку пользователей. Знакомая картина?

Типичные проблемы на таком предприятии – слишком "узкий" канал передачи данных до филиалов, необходимость постоянных доработок ERP, нехватка квалифицированных специалистов. Скажем, если ваш единственный системный администратор в отпуске, то все работы по подключению новой точки продаж просто встанут, и никто не сможет его заменить, как обладателя уникальных знаний о когда-то настроенной им системе. Кроме того, ИТ-подразделения и обслуживаемая им инфраструктура постоянно страдают от нехватки финансирования; обычная аргументация при этом: "Зачем тратить деньги, если и так все работает?". А если что-то не работает, от топ-менеджеров тут же следует волевое указание "разобраться, наказать, устранить и доложить в кратчайшие сроки". В результате бизнес стоит, продажи теряются, компания несет убытки: в такой ситуации уже не до финансирования ИТ. Вот и получатся, что начальник отдела ИТ либо мальчик на побегушках, либо груша для битья, а его подразделение сильно напоминает пожарную команду.

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

• Бизнес не понимает (и не хочет понимать) процессов внутри ИТ. ИТ для бизнеса – "черный ящик";
• Бизнес позиционирует ИТ как обслуживающий отдел;
• Бизнес не в состоянии адекватно оценить риски, связанные с теми или иными компонентами ИТ;
• Бизнес считает вложения в ИТ избыточными.

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

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

Однако в решении данных проблем Россия не является первопроходцем. В этом смысле показательна ситуация, сложившаяся в ИТ службе правительства Великобритании в 80-ых гг. которое дало задание агентству CCTA (ныне OGC) разработать рекомендаций по максимально эффективному использованию ИТ ресурсов. Результатом проделанной работы стала библиотека ITIL (Information Technology Infrastructure Library). Основные ее принципы остались неизменными до сих пор – это сервисная модель работы, измерение и контроль качества услуг, а также построение отношений между бизнесом и ИТ на базе договоров об уровне обслуживания (Service Level Agreement – SLA). Для реализации этих основных принципов ITIL рекомендует использование определенных процессов управления ИТ, такими, как управления инцидентами, изменениями, конфигурациями, уровнем обслуживания, мощностями, доступностью и др.

ITIL рекомендует выстраивание проверенной на опыте цепочки управления ИТ и взаимодействия ИТ и бизнеса: организация единой точки контакта с пользователями (Service Desk), отказ от обращений пользователей напрямую к специалистам ИТ, регистрация всех обращений пользователей, анализ обращений пользователей, выстраивание "линий поддержки пользователей", определение уровней обслуживания, критерии оценки сервиса и т.п.

Как видно, в теории все просто. Практическое же внедрение рекомендаций ITIL приводит к необходимости ломать привычные методы работы как отдела ИТ, так и пользователей – представителей бизнеса. Удача или провал проекта внедрению ITIL зависит от уровня зрелости каждого конкретного предприятия, и готовности его менеджеров "ломать копья", а также от профессионализма и опыта приглашенного консультанта.

Стоит отметить, что в полной мере рекомендации ITIL оправдывают себя при их внедрении на средних и крупных предприятиях (хотя возможности их применения на малых предприятиях никто не отменял). Поскольку именно на них, обладающих хорошо развитой инфраструктурой, грамотно организованное и хорошо управляемое ИТ-подразделение способно "подставить свое плечо" бизнесу, то есть создать максимально благоприятные условия для его дальнейшего развития.

Другая область предпочтительного внедрения рекомендаций ITIL – там, где запланировано внедрение крупных ERP-систем. Дело в том, что внедрение на предприятии таких систем, будь то SAP, Oracle или Axapta, особенно если до этого там работала доморощенная управленческая система, подразумевает определенную перестройку сознания и требует другого уровня подготовки пользователей. С первых же шагов перехода на новую систему возникает лавина вопросов к группе внедрения. Именно в этот момент единая служба поддержки может значительно сэкономить нервы и время как пользователям, так и внедренцам.

Без применение рекомендаций ITIL нельзя обойтись при подготовке предприятия к ИТ-аутсорсингу. Действительно, после внедрения процессов ITIL нет разницы, кто поставляет услуги ИТ – внутренний отдел или внешняя компания. Другое дело, что при передаче того или иного сервиса ИТ на аутсорсинг нужно иметь четкое представление – что выигрывает бизнес от такого шага? Возможно, внешняя компания предлагает на более выгодных условиях или лучшего качества, предоставляет уникального и "дорогого" специалиста (которого иначе пришлось бы содержать самим) или реализует услугу, которая не по силам внутреннему отделу ИТ. Естественно, что в любом случае уровень сервиса должен отслеживаться в соответствии с рекомендациями ITIL.

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

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

Опубликовано: Сети и системы связи (газета на выстаку Inerop2007)

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

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

Ни для кого не секрет, что в современном мире бизнес в той или иной степени зависим от информационных технологий. Преимущества от применения ИТ для бизнеса очевидны: скорость и простота порождения, распространения, манипуляций и поиска разнородной информации, упорядочивание ее по различным критериям, простота хранения, возможность доступа практически из любой точки мира… Все эти преимущества требуют хорошо отлаженной поддержки и сопровождения, которая, в свою очередь, предъявляет определенные требования к базовой ИТ инфраструктуре. С другой стороны, в информационных системах, часто находится информация, разглашение которой является крайне нежелательным (например, конфиденциальная информация, либо информация, составляющая коммерческую тайну). Нарушение режима нормального функционирования инфраструктуры либо получение доступа к информации, которая расположена в ИС, являются угрозами информационной безопасности.

Таким образом, угрозы информационной безопасности предприятия можно условно разделить на несколько классов:

• Угрозы нарушения доступности
• Угрозы нарушения целостности
• Угрозы нарушения конфиденциальности

Угрозы нарушения доступности – это угрозы, связанные с увеличением времени получения той или иной информации или информационной услуги. Нарушение доступности представляет собой создание таких условий, при которых доступ к услуге или информации будет либо заблокирован, либо возможен за время, которое не обеспечит выполнение тех или иных бизнес-целей. Рассмотрим пример: в случае выхода из строя сервера, на котором расположена требуемая для принятия стратегического решения информация, нарушается свойство доступности информации. Аналогичный пример: в случае изоляции по какой-либо причине (выход из строя сервера, отказ каналов связи и т.д.) почтового сервера можно говорить о нарушении доступности ИТ услуги «электронная почта». Особо следует отметить тот факт, что причина нарушения доступности информации или информационной услуги не обязательно должна находиться в зоне ответственности владельца услуги или информации. Например, в рассмотренном выше примере с нарушением доступности почтового сервера причина (отказ каналов связи) может лежать вне зоны ответственности администраторов сервера (например, отказ магистральных каналов связи). Также следует отметить, что понятие «доступность» субъективно в каждый момент времени для каждого из субъектов, потребляющих услугу или информацию в данный момент времени. В частности, нарушение доступности почтового сервера для одного сотрудника может означать срыв индивидуальных планов и потерю контракта, а для другого сотрудника той же организации – невозможность получить выпуск свежих новостей.

Угрозы нарушения целостности – это угрозы, связанные с вероятностью модификации той или иной информации, хранящейся в ИС. Нарушение целостности может быть вызвано различными факторами – от умышленных действий персонала до выхода из строя оборудования. Нарушение целостности может быть как умышленным, так и неумышленным (причиной неумышленного нарушения целостности может выступать, например, неисправно работающее оборудование).

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

Реализация каждой из указанных угроз в отдельности или их совокупности приводит к нарушению информационной безопасности предприятия.

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

Все мероприятия по обеспечению ИБ условно можно рассматривать на двух основных уровнях: на уровне физического доступа к данным и на уровне логического доступа к данным, которые являются следствием административных решений (политик).

На уровне физического доступа к данным рассматриваются механизмы защиты данных от несанкционированного доступа и механизмы защиты от повреждения физических носителей данных. Защита от несанкционированного доступа предполагает размещения серверного оборудования с данными в отдельном помещении, доступ к которому имеет лишь персонал с соответствующими полномочиями. На этом же уровне в качестве средств защиты возможно создание географически распределенной системы серверов. Уровень защиты от физического повреждения предполагает организацию различного рода специализированных систем, предотвращающих подобные процессы. К их числу относят: серверные кластера и back-up (резервного копирования) сервера. При работе в кластере (например, двух серверов) в случае физического отказа одного из них второй будет продолжать работу, таким образом работоспособность вычислительной системы и данных не будет нарушена. При дополнительной организации резервного копирования (back-up сервера) возможно быстрое восстановление вычислительной системы и данных даже в случае выхода из строя второго сервера в кластере.

Уровень защиты от логического доступа к данным предполагает защиту от несанкционированного доступа в систему (здесь и далее по тексту под системой понимается ИТ система, предназначенная для порождения, хранения и обработки данных любого класса – от простых учетных систем до решений класса ERP) как на уровне баз данных, так и на уровне ядра системы и пользовательских форм. Защита на этом уровне предполагает принятие мер по предотвращению доступа к базе данных как из Интернет, так и из локальной сети организации (на последний аспект обеспечения безопасности традиционно обращается мало внимания, хотя этот аспект напрямую связан с таким явлением, как промышленный шпионаж). Защита ядра системы предполагает, наряду с обозначенными выше мерами, вычисление контрольных сумм критических частей исполнимого кода и периодический аудит этих контрольных сумм. Подобный подход позволяет повысить общую степень защищенности системы. (Следует отметить, что указанное мероприятие не является единственным; оно приводится как удачный пример). Обеспечение безопасности на уровне пользовательских форм декларирует обязательное шифрование трафика, передающегося по локальной сети (или через Интернет) между клиентом (пользовательской формой) и приложением (ядром системы). Также безопасность на этом уровне может обеспечиваться вычислением контрольных сумм этих форм, с последующей их проверкой, принятием идеологии «разделения данных и кода». Например, система, построенная по технологии «тонкого клиента» с позиций обеспечения безопасности на данном уровне имеет преимущество перед системой, построенной по технологии «толстого клиента», поскольку на уровне пользовательских форм не предоставляет доступа к коду бизнес-логики (например, путем дизассемблирования исполняемого файла). К этому же уровню защиты относится механизм сертификации, когда в обмене между пользовательской формой и сервером, а также подлинность самой пользовательской формы подтверждается третьим участником обмена – центром сертификации.

Аналогично, на уровне защиты от логического доступа на уровне баз данных доступа целесообразно вычислять контрольные суммы критически важных таблиц, и вести журнал учета доступа объектов к базе данных. В идеальном случае («тонкий клиент») доступ к базе данных имеет лишь серверное приложение (сервер бизнес-логики), а все остальные (сторонние) запросы к БД блокируются. Подобный подход позволит исключить несколько типов атак и сконцентрировать политику защиты БД на обеспечении безопасности «по критическим точкам».

К защите на уровне административных решений относят административные меры, направленные на создание четкой и понятной политики в отношении ИТ, ИС, информационной безопасности и т.д. Можно сказать, что данный уровень является по отношению к пользователю первичным – поскольку именно защита на уровне административных решений способна предотвратить большинство критических ситуаций, связанных с информационной безопасностью.

Следует рассмотреть еще два важных вопроса, связанных с безопасностью – методы и средства аутентификации пользователей и протоколирование событий, происходящих в ИС.

Аутентификация пользователей относится к логическому уровню обеспечения информационной безопасности. Цель этой процедуры состоит в том, чтобы во-первых, сообщить ИС, какой именно пользователь работает с ним, для предоставления ему соответствующих прав и интерфейсов; во-вторых, подтвердить права данного конкретного пользователя по отношению к ИС. Традиционно процедура аутентификации сводится к вводу пользователем имени пользователя (логина) и пароля.

Довольно часто, в критически важных приложениях, форма ввода имени пользователя/пароля представляет собой работающее в защищенном программном (реже – аппаратном) тоннеле приложение, безусловно шифрующее всю передающуюся по сети информацию. К сожалению, наиболее частой является ситуация, когда имя пользователя и пароль передаются по сети в открытом виде (например, по этому принципу работают большинство известных бесплатных почтовых систем в сети Интернет). Кроме программных (ввод комбинации имя пользователя/пароль) существуют и программно-аппаратные и аппаратные решения для аутентификации пользователей. К ним относятся дискеты и USB-носители с ключевым файлом (довольно часто – в комбинации с вводом обычного имени/пароля, для подтверждения полномочий на критичные действия), защищенным от копирования; однократно записываемые USB-носители с ключевым файлом; сканеры радужной оболочки глаза; сканеры отпечатков пальцев; системы антропологии. Одним из вариантов повышения степени защиты ИС является ограничение времени действия пароля и ограничение времени бездействия пользователя в ИС. Ограничение времени действия пароля представляет собой выдачу пароля, который действует лишь определенное число дней – 30, 60 и т.д. Соответственно, с периодической сменой паролей повышается степень защищенности ИС в целом. Ограничение времени бездействия пользователя предполагает автоматическое закрытия сеанса пользователя в случае, если в этом сеансе не была зафиксирована пользовательская активность в течении определенного периода времени.

Протоколирование всех событий, происходящих в ИС, необходимо для получения четкой картины о попытках несанкционированного доступа, либо по неквалифицированным действиям персонала по отношению к ИС. Частой ситуацией является введение в ИС специализированных модулей, анализирующих системные события, и предотвращающих деструктивные действия по отношению к ИС. Подобные модули могут работать, исходя из двух предпосылок: обнаружения вторжений и предотвращение превышения доступности. В первом случае модули статистически анализируют типичное поведение пользователя, и выдают «тревогу» в случае заметных отклонений (например, работа оператора в 22-30 первый раз за два года является безусловно подозрительной); во втором случае на основе анализа текущего сеанса работы пользователя пытаются предотвратить потенциально деструктивные действия (например, попытку удаления какой-либо информации).

Примечание:

ИБ – информационная безопасность

ИТ – информационные технологии

ИС – информационные системы или информационная система (по контексту)

Представленный ниже небольшой доклад-презентация по IP телефонии я делал на выставке SkiSalon2002, проходившей зимой 2002 года в Санкт-Петербурге. Публикуя его на сайте, я преследовал две основных цели:

• Большинство тезисов доклада не утратило своей актуальности и по сей день(2006 год)
• В послесловии кратко проанализировать — а что, собственно говоря, изменилось за 4 года на рынке в целом и в сфере IP телефонии в частности.Поэтому просьба — перед тем, как говорить: «Фу, устарело! Таких цен уже нет!» — дочитайте до конца;)

Кроме того, следует отметить, что SkiSalon — узкоспециализированная туристическая выставка, на которой, как правило, кроме представителей турфирм (и небольшого количества «случайных» посетителей никого и не бывает;)

В настоящее время все более серьезное и пристальное внимание представителей самых разных сфер туристической индустрии привлекают проблемы телекоммуникаций, в частности — проблемы качественной и дешевой телефонной связи и беспрепятственного быстрого доступа в Интернет. Традиционно работа даже небольшой туристической фирмы — будь то оператор или агент — строится таким образом, что неизбежно проведение большого количества междугородних/международных переговоров, обмен факсимильными посланиями, e-mail сообщениями. Это накладывает жесткие требования по качеству и бесперебойности услуг связи. Но в то же время необходимо учитывать и фактор стоимости услуг связи. Начнем с последнего. В настоящее время довольно большой сегмент рынка связи Петербурга оказался охваченным телефонными карточками. Стоимость звонка по карточке привлекательно низка. Но насколько это выгодно? Рассмотрим технологию звонка по карточке: клиент звонит (через оператора или напрямую) на телефонный ip-сервер, который направляет (маршрутезирует) голосовой трафик клиента в ip-сеть, или, проще говоря, в Интернет. «На том конце» голосовой трафик при помощи специализированного оборудования направляется в телефонную сеть. Для того, чтобы направить в сеть Интернет и извлечь его оттуда, необходимо провести его через ряд преобразований. Эти преобразования негативно сказываются на качестве передаваемого голосового трафика. Кроме того, протокол передачи связи в сети Интернет допускает потери и последующее восстановление части информации; в случае с компьютерными данными это менее актуально, но в случае с голосовыми данными это означает эхо, потерю части слов, плохую слышимость, непрохождение или искажение факсимильных посланий. С «карточными» компаниями есть еще одна неприятность: довольно часто клиент производит оплату с момента соединения с телефонным сервером, а не с момента фактического соединения абонентов; часто случается, что клиента рассчитывают по курсу у.е., установленного внутри карточной компании на день звонка. (Надо отметить, что порой этот курс превышает курс ЦБ на 5 — 10%!). Таким образом, экономия при звонках по системе «карточек» довольно часто оказывается мнимой.

Давайте рассмотрим пример: например, звонок в Москву у «карточных» компаний стоит порядка 8 центов в минуту. Вы отправляете факс, время его передачи составляет 2 мин. Планируемый Вами расход — 16 центов. Что получается реально? Вам прибавляют время, прошедшее с момента соединения с телефонным сервером (порядка 30 секунд), что сразу увеличивает Ваш баланс на 1 минуту (стандартное время округления). Если рассмотреть возможность дозвона до абонента со второго раза (предположив, что в первый раз линия абонента была занята), или непрохождения факса с первого раза, то Ваш расход составит вместо планируемых 16 центов минимум 24, максимум — 40 центов. То есть реально звонок в Москву по «карточке» обходится едва ли не дороже, чем при звонке через ПТС.

Рассмотрим еще один способ снижения стоимости телефонных переговоров, а именно звонок через собственный узел междугородной/международной связи операторов. Что это подразумевает? Аналогично «карточкам», клиент звонит на телефонный узел, но его трафик направляется не через Интернет, а через традиционные телефонные сети, что гарантирует качество передаваемой речи и факсимильных сообщений. В рассмотренном ранее примере за передачу факса в Москву клиент заплатит ровно 18 центов, вместо 40, поскольку за соединение с узлом плата не взимается; в случае занятости линии абонента клиент не оплачивает вообще ничего, обмен факсимильными сообщениями происходит гораздо более уверенно, нежели в случае с ip-телефонной карточкой.

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

• Программирование мини-АТС абонента
• Установка устройства перенаправления вызова — роутера

Как уже было сказано, роутер представляет собой устройство перенаправления вызова. Он может быть установлен на одну телефонную линию. При этом все междугородние/международные звонки, совершаемые по этой линии, перенаправляются на узел оператора. Преимущества роутера очевидны: это постоянное соединение с оператором и невозможность вскрыть код доступа к сети оператора. В случае, если у клиента установлена мини-АТС, роутер может быть установлен как до нее, на конкретную линию (в этом случае целесообразно закрыть доступ к «межгороду» на остальные линии), так и после нее (в этом случае целесообразно станцией маршрутеризировать все междугородние звонки на линии с роутером).

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

Хотелось бы еще уделить немного внимания такому явлению современного туристического бизнеса, как Интернет. Прошло то время, когда представительство компании в Интернет был больше имиджевой рекламой; в настоящее время многие туристические фирмы активно используют ресурсы всемирной сети для продажи своих услуг как напрямую, со своего сайта, так и через туристические мультипорталы, такие, как «travel.ru», «100 дорог» и т.д. Это подразумевает наличие свободного выделенного либо коммутрируемого доступа в Интернет. Организация такого доступа возможна с использованием нескольких технических решений; о приемуществах и недостатках каждого конкретного решения можно говорить достаточно долго, поэтому, если такие вопросы будут, мы рады будем ответить на них в дискуссионной части семинара.

…

К тезису о низком качестве «карточной» IP телефонии. Следует отметить, что в последнее время наблюдается устойчивая тенденция к росту качества связи по карточкам. Дело в том, что потребитель, кроме прямой экономии, стал предъявлять требования к качеству сервиса (качество передачи голоса, возможность нормальной передачи факсов), обеспечение которого для оператора является залогом получения лояльного абонента.

Развивая указанный тезис, следует отметить возрастающие требования и к доступности сервиса. Карточку практически любого IP оператора можно купить буквально на каждом углу. Другой вопрос, что если на том углу, мимо которого проходит ежедневный маршрут Потребителя, не окажется карточки Самого Любимого Оператора, то весьма маловероятно, что он отправится за ней куда-либо еще. Просто купит другую карточку, конкурента, с похожими ценами. Таким образом, потребитель поощряет деятельность оператора по активному разворачиванию инфраструктуры сбыта.

К тезису о способах тарификации и курсу у.е. Действительно, в 2000 — 2002 годах в ряде карточных компаний существовала подобная проблема. Парадокс состоит в том, что подобное отношение к потребителю спровоцировало его уход к другим, более «интересным» операторам. И, как следствие — либо переориентацию и уход оператора с рынка, либо кардинальный пересмотр принципов тарификации.

Также следует отметить, что в настоящее время хорошей альтернативой IP телефонии стали внутресетевые звонки сотовых операторов — это удобно, и, как правило, в кредит:) Да и сама стоимость IP вызова в Москву снизилась до «демократичных» 2..5 центов за минуту

К тезису о звонках через телефонный коммутатор оператора. Этот вид телефонных соединений, безусловно, более перспективен. Правда, есть одно «большое но», которое состоит в том, что в настоящий момент практически не осталось нецифровой передачи трафика. И порой провести грань между «чистой IP телефонией» и «традиционной телефонией», имея в виду междугородние соединения, довольно проблематично . Хотя бы потому, что в целях экономии некоторые операторы пропускают междугородний трафик через IP сети (а почему бы и нет, если при этом не страдает качество)? Кроме того, развитие IP телефонии не стоит на месте: появляются новые протоколы, направленные на обеспечение качества связи, появляются и успешно занимают свою нишу на рынке «чистые» IP провайдеры (например, питерский Телфин или сеть Skype, где вообще возможно звонить с компьютера на компьютер, без использования телефона как такового).

К тезису о способах передачи трафика (удобства пользователя).Очевидно, что кроме указанных двух способов (программирования мини-АТС или установки роутера), существует еще как минимум два способа:

• Программирование телефонного аппарата абонента
• Использования специальных сервисов, типа Skype, которые не требуют телефона в принципе
• Использование IP телефона, то есть аппарата, который подключается не к телефонной сети, а к сети передачи данных

Следует отметить, что использование Skype клиента требует предварительной регистрации и настройки самого клиента, а использование IP телефона — его предварительного программирования и программирования оборудования, с которым он работает (в том числе — каналообразующего, для пропуска трафика от конкретного устройства с заданным уровнем качества).

Внимание! Данная статья скорее всего устарела и описываемое ниже имеет больше академичсекий интерес.Одной из основных задач, которые призвана решить современная локальная вычислительная сеть, состоит в организации одновременного доступа в Интернет некоторого числа ее пользователей. Как правило, в каждой организации имеется одно подключение к Интернет, и одна (или несколько) локальных сетей, использующих это подключение. Рассмотрим, каким именно способом пользователи локальной сети могут получить доступ в Интернет через одно соединение.

Первый способ, наиболее простой, состоит в установке на одной клиентской машине специализированного программного обеспечения, организующего доступ в Интернет для всей сети. Второй способ состоит в выделении специальной машины – сервера для решения той же задачи. При этом следует учесть, что при любом варианте абсолютно не важно, каким способом (dial-up, ADSL, выделенная линия) организуется доступ в Интернет – каждый из рассмотренных ниже способов будет работать при любом способе подключения. Правда, если скорость модемного соединения составляет 4 Кб/сек, а в сети 10 пользователей работающих в Интернет, то для каждого из них скорость соединения с Интернет будет составлять порядка 400 байт/сек... Но это, как говорится, совсем другая история...

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

В любом случае, для организации одновременного доступа в Интернет для пользователей локальной сети на машине, через которую организуется доступ в Интернет (или следующий сегмент сети), должно быть установлено либо две сетевые карты, либо сетевая карта и модем. То есть, одна сетевая карта служит для "общения" с внутренней сетью, а вторая (роль которой может выполнять модем) – для общения с внешними сетями (в том числе – Интернет).

Рассмотрим более подробно каждый из способов организации одновременного доступа в Интернет для пользователей ЛВС.

Итак, первый, условно "безсерверный" вариант состоит в установке на клиентской машине специализированного программного обеспечения, называемого прокси-сервером. Например, для Windows самыми распространенными вариантами такого программного обеспечения стали программы EasyProxy, WinProxy, WinGate, WinRoute. Все эти программы выполняют роль маршрутеризатора – то есть не пропускают во внешнюю сеть пакеты данных, предназначенные для локальной сети, и перенаправляют по необходимости пакеты данных конкретной локальной машины во внешнюю сеть. В терминах сетей на базе Windows машина с установленным прокси-сервером называется шлюзом (Gateway). (IP-адрес этой машины указывается на вкладке "Шлюз" диалога настройки TCP/IP). Самая простая программа (со всех точек зрения) из рассмотренных выше – EasyProxy. Она распространяется бесплатно, найти ее можно, например, через www.filesearch.ru. Эта программа предназначена для обслуживания небольших сетей, рассчитанных на 3-4 пользователя. В этом случае она обеспечивает нормальную комфортную работу. Формально ее можно настроить и на работу с большим числом пользователей, однако в этом случае возможны сбои. Все остальные программы (кстати, распространяемые либо условно бесплатно, либо на коммерческой основе), могут работать с большим числом пользователей. Кроме того, каждая из них может выступать в качестве так называемого mail-сервера, то есть, подобно почтовым серверам Интернет, принимать и отправлять почту локальных пользователей, что довольно удобно. Правда, сразу же стоит оговориться – EasyProxy не работает как прокси-сервер ни для какого протокола, кроме HTTP. Это значит, что, например, при попытке обращения к FTP-серверу локальный пользователь получит сообщение об ошибке. Что же, за простоту приходится платить... Все остальные из перечисленных выше программы поддерживают все популярные протоколы Интернет, включая FTP. Кроме того, все указанные выше программы, кроме EasyProxy, поддерживают автодозвон.

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

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

Также, как и в случае псевдо-сервера, для обеспечения одновременного доступа в Интернет пользователей ЛВС используется специализированное программное обеспечение. Например, в сетях Windows (сервер на базе WinNT или Win2K), используется то же ПО, что и в случае псевдо-сервера, правда надежность и стабильность работы этого ПО будет гораздо выше. Кроме того, довольно часто на сервер устанавливается отдельная программа для работы с почтой, то есть mail-сервер. В операционных системах на базе Unix простейший (хотя как сказать) вариант такого сервера поставляется в комплекте – утилита sendmail. В системах Windows такой сервер необходимо устанавливать дополнительно – если нужна большая мощность (например, Microsoft Exchange или MDeamon), либо пользоваться встроенными в WinRoute и WinGate средствами.

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

Опубликовано в:Computer Market N35(116)

- Конечно. Vasia@mail.ru...

Говорят, что все компьютерщики - народ немного больной. На голову. Хотя при ближайшем рассмотрении оказывается, что все несколько не так: компьютерщики как правило болеют редким видом нервного заболевания, именуемого "компьютерная лихорадка". Что же это такое?

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

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

По возможности, желательно выделить все "стадии" - пропустить строку (как в этом файле), или еще как-нибудь отделить их друг от друга

Легкая стадия заболевания

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

Заболевание средней тяжести первой степени

Больной задерживается на работе на 10-15 минут, или приходит на 10-15 минут пораньше - посмотреть электронную почту в недавно заведенном почтовом ящике, и почитать последние новости на Газета.РУ. В сознании время от времени возникают вопросы о смысле жизни, роли человека и компьютера в мироздании. В качестве лечения рекомендуется отключение от Интернета, сытная и обильная пища, для неженатых - почти всегда помогает женитьба. (Если только потенциальная супруга сама не жертва "компьютерной лихорадки").

Заболевание средней тяжести второй степени

Больной начинает раздавать свой электронный e-mail адрес направо и налево, и умоляет знакомых писать ему как можно больше. Подписывается на все известные почтовые рассылки, иногда (очень редко) мелькают мысли о том, чтобы самому стать автором рассылки. С Интернетом пока на "вы", но уже с презрительной интонацией. Основной вопрос - что было раньше: компьютер или программист? Возможное лечение - шокотерапия, когда внезапно (и без предупреждения) отключают компьютер, а пострадавшего выносят на улицу и показывают живых людей.

Заболевание средней тяжести третьей степени

Больной становится автором рассылки, проводит за компьютером большую часть своего времени, спит мало, в речи наблюдаются явные нарушения - она начинает походить на бесконечный монолог с вкраплениями жаргонных слов. С Интернетом на "ты", постоянно скачивает оттуда массу самых нужных программ, смеется невпопад, знакомится с девушками только на досках объявлений, и только с теми, у которых есть свой сайт и e-mail адрес. Вопросов больше нет, кроме одного: как добыть деньги для поддержания существования (то есть покупки времени в Сети, так как все остальное время он уже не считает за полноценную жизнь)... Возможное лечение - полная изоляция от компьютеров, желательно в помещение, обитое войлоком (может начать биться головой о стену), кормление только мягкой пищей несколько раз в день. Желательно попытаться поговорить с ним на некомпьютерные темы, приветствуются прогулки на воздухе под надзором врача и санитаров.

Тяжелая стадия заболевания

Больной создает свой собственный сайт, проводит за компьютером все время, не отрываясь на сон, пищу принимает попутно, ест все, без разбору, даже предметы, принципиально не предназначенные для этого. Речь нарушена, на 100% состоит из жаргона. Все вещи, не относящееся к компьютеру, теряют в его глазах всякий смысл. На просьбу оставить адрес бурчит что-то типа vasia.boom.ru и отворачивается в сотый раз посмотреть статистику посещений сайта. Заводит себе виртуальную любов, с которой познакомился в чате. Лечение назначается в индивидуальном порядке, но почти наверняка не помогает. Попытки использования санитаров для обуздания его энергии, как правило заканчиваются ничем - ему удается заинтриговать их компьютером. Со всеми вытекающими отсюда последствиями. (См. пункт "Легкая стадия заболевания").

Сверхтяжелая стадия заболевания

Больной становится системным администратором, хакером и не может прожить ни минуты без ноутбука. Сон нарушен (в 99 случаях из 100 отсутствует вообще), речь отсутствует, на вопросы не реагирует, время от времени издает мычащие звуки, пытается подключить себя к компьютеру через порт USB, полагает себя частью сложной вычислительной системы... К сожалению, в этом случае медицина бессильна, и самые лучшие медики говорят в один голос о таком: "лечению не подлежит".

Опубликовано в:Computer Review N15(110)