Информационная система комплексного менеджмента

Информационная система комплексного менеджмента

1. Анализ предметной области

1.1 Услуга colocation

1.1.1 Общие понятия услуги colocation

Colocation — размещение оборудования в центрах обработки данных (далее по тексту ЦОД) с возможностью подключения к интернет и внутренним корпоративным сетям. Почему размещение оборудования именно в ЦОДе, а не каких-либо технологических площадках? Для этого необходимо представлять, что такое ЦОД в современной сфере информационных технологий.

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

Сетевая инфраструктура. Сегодня коммуникации дата центра чаще всего базируются на сетях с использованием IP протокола. ЦОД содержит ряд роутеров и свитчей, которые управляют трафиком между серверами и внешним миром. Для надежности дата-центр иногда подключен к интернету с помощью множества разных внешних каналов от разных ISP. Некоторые серверы в ЦОДе служат для работы базовых интернет и интранет служб, которые используются внутри организации: почтовые сервера, прокси, DNS и т. п. Сетевой уровень безопасности поддерживают: межсетевые экраны, VPN шлюзы, IDS-системы и т. д. Также используются системы мониторинга трафика и некоторых приложений.

Все ЦОДы можно условно разделить на несколько типов:

Крупные ЦОДы имеют свое здание, специально сконструированное для обеспечения наилучших условий размещения. Обычно они имеют свои каналы связи, к которым подключают серверы.

Средние ЦОДы обычно арендуют площадку определенного размера и каналы определенной ширины (ширина канала измеряется его пропускной способностью в Mbps).

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

1.1.2 Услуги ЦОД (colocation)

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

VPS (он же VDS) — хостинг — Предоставление гарантированной и лимитированной части сервера (части всех ресурсов). Важная особенность данного вида хостинга — разделение сервера на несколько виртуальных независимых серверов реализуемых программным способом.

DS-хостинг — Аренда сервера (Dedicated). Дата-центр предоставляет клиенту в аренду сервер в различной конфигурации. Крупные дата-центры в основном специализируются именно на подобных типах услуг. В зависимости от страны расположения дата-центра имеются различные ограничения на трафик.

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

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

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

Почему именно, colocation, а не создание собственной серверной площадки:

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

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

*Единый уровень сервиса, включая отдаленные регионы.

*Снижение управленческой и административной нагрузки на предприятие клиента за счет уменьшения численности персонала.

*Снижение затрат на обучение и сертификацию персонала клиента.

*Высвобождение площадей, техники, оборудования рабочих мест иликвидация расходов на их содержание.

*Снижение командировочных и логистических расходов клиента.

*Повышение показателя выручки предприятия клиента на одного сотрудника.

*Решение социальной проблемы при увольнениях — часть сотрудников клиента предприятия может быть переведена в штат сервисной сети компании аутсорсера.

*Прогнозируемость и прозрачность затрат для клиента.

1.2 История развития ЦОД и услуг colocation

1.2.1 Происхождение вида

Первые ЦОДы, появились в 60-х годах прошлого века. Их сердцем были мэйнфреймы. Больше всего наследили в истории мэйнфреймы IBM 360, которые потом у нас решили клонировать, отказавшись от собственных компьютеров БЭСМ6, «Мир» и др., инженерные решения которых во многом превосходили американские разработки. Так что в эпоху тогдашних ЦОД наша страна вошла с аналогом продукции IBM под названием ЕС ЭВМ. Разные модели этой серии выпускались с 1971 по 1998 г., и ими были оснащены многие советские предприятия и НИИ.

В 60−70х годах ЦОД использовались главным образом для решения сложных вычислительных задач, под каждую из которых писалась своя программа. Затраты на дорогие мэйнфреймы (они и сейчас недешевы) и на штучную работу по созданию ПО могли позволить себе только крупные богатые компании, и это сдерживало широкое распространение ЦОД. Именно тогда возникла концепция обработки информации как централизованного сервиса, предоставляемого вычислительным центром всем остальным подразделениям компании. По нынешней терминологии это внутренний аутсорсинг. Для внешнего аутсорсинга условий тогда не было, поскольку он требует наличия стандартных приложений, пользоваться которыми могут самые разные компании.

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

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

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

1.2.2 Всеобщая ЦОДофикация

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

В последние годы информатизация бизнеса и многих услуг идет особенно активно. Автоматизированные системы управления предприятием есть уже не только у всех крупных, но и у многих средних компаний. Документооборот переводится в электронную форму. Повсеместно устанавливаются платежные терминалы для оплаты услуг сотовой связи, доступа в Интернет, ЖКХ. Биллинговые системы крупнейших мобильных операторов обслуживают десятки миллионов абонентов. Информационные системы ритейловых сетей, охватывающих целые регионы страны, должны обрабатывать данные всех кассовых аппаратов, информацию о складских запасах и доставке товаров во все магазины сети. Растет спрос на тяжелый мультимедийный контент. Все это требует централизованной обработки гигантских объемов данных. Причем процесс этой обработки часто должен быть непрерывным, так как, например, даже небольшой простой биллинговой системы грозит оператору серьезными убытками. Компьютерные системы, способные обрабатывать с нужной скоростью такие объемы информации, потребляют столько электроэнергии, что для их нормальной работы уже недостаточно серверной комнаты в офисе. Компаниям приходится либо строить свой ЦОД с соответствующими системами бесперебойного электропитания и охлаждения, что требует колоссальных затрат, либо обращаться к услугам коммерческих дата-центров.

1.2.3 Аутсорсинг

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

Московские цены уже выше среднеевропейских и американских. И ситуация, судя по всему, улучшится не скоро. Хотя оборудование для ЦОДа обходится недешево, немалый вклад в конечную цену проекта вносит стоимость электричества, причем не самих потребленных киловатт, а фактически только разрешения на подключение к энергосети. Плата за подключение составляет сейчас 100 тыс. руб. за 1 кВт в центре Москвы, до 70 тыс. руб. — на окраине столицы и до 50 тыс. руб. — в коттеджных поселках в ближнем Подмосковье. Но и за такие деньги электричества в Москве практически нет.

1.2.4 В регионы за электричеством

В некоторых районах Московской области, а также в других регионах ситуация с электричеством не столь остра, но любой дата-центр требует толстых каналов связи, а с ними на большей части территории страны большие проблемы. Да и там, где они есть, цены на трафик, как правило, в разы превосходят московские. Правда, есть некоторая надежда на российских магистральных операторов, которые в последние годы активно двинулись в регионы, что способствовало некоторому снижению цен на интернетдоступ. Причем операторы не только потянули туда оптоволокно, но и сами стали строить ЦОДы. Например, недавно «Ростелеком» запустил дата-центры в Новосибирске, Екатеринбурге и Хабаровске, подключив их к своей магистральной сети. Причем в Хабаровске ЦОД располагается на одной площадке с точкой обмена интернеттрафиком РосНИИРОС. Занялись строительством дата-центров в своих регионах и МРК. В сентябре прошлого года «Синтерра» анонсировала программу строительства сети из 40 дата-центров в крупнейших городах России. Двинулись в регионы и корпоративные заказчики. Так, все операторы «большой сотовой тройки» уже имеют там ЦОДы и продолжают их строить: до конца 2008 г. МТС планирует построить пять дата-центров в пяти федеральных округах, а «МегаФон» намерен открыть семь ЦОДов.

Перспективным представляется и планируемое строительство дата-центров в открывающихся технопарках. К примеру, анонсированы планы строительства в технопарке подмосковной Дубны двух самых крупных в России дата-центров площадью 10 и 20 тыс. м2. Правда, скорой реализации этих планов ожидать не приходится (завершение проекта намечено на 2013 г.) и, следовательно, ликвидации дефицита услуг ЦОДов тоже.

1.2.5 Мировая мода

Несмотря на столь бурную деятельность, Россия, как водится, заметно отстает в деле ЦОДостроения от развитых стран. Там вокруг дата-центров давно сложилась мощная индустрия, созданы ассоциации владельцев ЦОДов, производителей различного оборудования для них, консалтинговых и специализированных строительных компаний, например Институт профессионалов в области дата-центров (IDCP), Ассоциация менеджеров информационных центров (AFCOM), Американское общество инженеров по отоплению, охлаждению и кондиционированию воздуха (ASHRAE).

С 1993 г. в США действует авторитетная организация Uptime Institute, названная в честь основного критерия качества работы дата-центра — времени доступности сервера (uptime). На основе анализа имеющихся дата-центров, всех их систем и оборудования она вырабатывает рекомендации по обеспечению максимально надежной работы ЦОДов. Именно Uptime Institute предложил классификацию дата-центров по уровням надежности Tier I, II, III и IV (см. таблицу), определяющую среднее время простоя серверов ЦОДа в зависимости от структуры инженерных систем и уровня их избыточности. Есть также принятый в 2005 г. отраслевой стандарт TIA/EIA942 Telecommunications Infrastructure Standard for Data Center (Стандарт на телекоммуникационную инфраструктуру центров обработки данных), разработанный Ассоциацией телекоммуникационной промышленности США (TIA) и охватывающий многие аспекты создания ЦОДов разных уровней надежности, в том числе принципы построения систем электропитания и кондиционирования, кабельных систем, требования к резервированию отдельных элементов ЦОДа, характеристики помещения, особенности размещения оборудования и многое другое, вплоть до расположения гостевой парковки.

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

1.2.6 Проблемы «озеленения»

Мировая индустрия ЦОДостроения сейчас озабочена «озеленением» дата-центров. Недавно Uptime Institute и консалтинговая компания McKinsey & Co представили доклад, в котором утверждается, что к 2020 г. объемы парниковых газов, выбрасываемых дата-центрами в атмосферу, увеличатся в 4 раза и превзойдут объемы выхлопов всех самолетов мира. Там же говорится, что цены на энергоносители растут со скоростью 16% в год, а основной проблемой для дата-центров является резкий рост энергопотребления, который обгоняет рост вычислительной мощности. Компании, строящие и эксплуатирующие дата-центры, обеспокоены тем, что их затраты на электроэнергию сильно выросли за последние годы и продолжают расти. По данным IDC, в 1996 г. на электроэнергию приходилось примерно 15% затрат на эксплуатацию дата-центров, а к 2010 г. ее доля возрастет до 70%. Поэтому около половины опрошенных Uptime компаний собираются в течение ближайшего года модернизировать свои ЦОДы, чтобы снизить энергопотребление их инженерных систем и ИТ-оборудования. Причем заинтересованы в этом прежде всего ИТ-директора, так как электроэнергия для дата-центров на Западе уже давно оплачивается из ИТ-бюджета компании.

Наших владельцев ЦОДов до недавнего времени больше волновал вопрос, где вообще взять электричество, а не его цена. Но теперь мы стараниями наших энергетиков, и в первую очередь почившего в бозе РАО ЕЭС, по стоимости 1 кВт. ч догнали США, а счет энергопотребления нынешних дата-центров идет на мегаватты. К тому же западная практика внесения платы за электричество, потребляемое ЦОДом, в ИТ-бюджет пришла уже и в Россию. Судя по всему, скоро она станет обычной для всех корпоративных дата-центров. И тогда ИТ-директора наших компаний вслед за владельцами коммерческих ЦОДов и всем прогрессивным человечеством должны будут озаботиться проблемами экономии электроэнергии всеми доступными способами.

1.3 Основные задачи, решаемые системой комплексного менеджмента colocation-проектов

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

То есть, система представляет собой конфигуратор услуг (сервисный калькулятор), который позволяет сократить время формирования и повысить эффективность расчета специалистом спецификации для конкретного заказчика.

Спецификация представляет собой электронный документ, позволяющий оценить:

1. Трудозатраты, требующиеся на реализацию конкретного проекта.

2. Общую стоимость предоставляемого комплекса услуг.

3. Персонал и время, требуемое для реализации проекта.

4. Анализ рациональности реализации конкретного проекта.

5. Описание модели SLA проекта конкретного заказчика.

SLA — это основной документ, регламентирующий взаимоотношения ИТ и клиентов.

Цель документа — дать качественное и количественное описание сервисов, как с точки зрения провайдера, так и сточки зрения клиента.

Существенной частью SLA является каталог сервисов.

Соглашение об уровне сервиса (Service Level Agreement — SLA) определяет взаимные ответственности провайдера ИТ-сервиса и пользователей этого сервиса.

Типовая модель SLA должно включать следующие разделы:

1. Определение предоставляемого сервиса, стороны, вовлеченные в соглашение, и сроки действия соглашения.

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

3. Число и размещение пользователей и / или оборудования, использующих данный сервис.

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

5. Описание процедуры запросов на изменение. Может включаться ожидаемое время выполнения этой процедуры.

6. Спецификации целевых уровней качества сервиса, включая:

· Средняя доступность, выраженная как среднее число сбоев на период предоставления сервиса

· Минимальная доступность для каждого пользователя

· Среднее время отклика сервиса

· Максимальное время отклика для каждого пользователя

· Средняя пропускная способность

· Описания расчета приведенных выше метрик и частоты отчетов

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

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

9. Процедура разрешения рассогласований, связанных с предоставлением сервиса.

10. Процесс улучшения SLA. В идеале, SLA определяется как особый сервис. Это позволяет сконфигурировать аппаратное и программное для максимизации способности удовлетворять SLA.

1.3.1 Пример методик ценообразования услуг

Стоимость операции

1. Стоимость операции = T/60 ?N_oper? К_parall? K_n? K_sla? Wage? N_obj

Где:

— T — длительность операции — время, затрачиваемое на одну операцию на один объект обслуживания (мин);

— N — кол-во операций в месяц на один объект (шт.). Статистический параметр, который показывает, что данная операция будет произведена не ко всем объектам, а к какому-то проценту объектов

— K_parall — коэффициент параллельности. Коэффициент определяет возможность дозагрузки специалиста в момент исполнения данной операции.

Например: 1 — не может ничего больше делать; 0,3 — занят на 30%

— K_scale — коэффициент масштаба — степень изменения трудозатрат в зависимости от кол-ва объектов обслуживания

— K_sla — коэффициент уровня обслуживания SLA — степень изменения трудозатрат в зависимости от уровня обслуживания.

— Wage — ставка специалиста, выполняющего операцию ($/час).

— N_obj — кол-во объектов обслуживания — под объектом обслуживания понимается обслуживаемое устройство, система, пользователь и т. п.

Стоимость услуги

2. Стоимость услуги = сумма операций * маржа На уровне услуг к операциям применяются:

1. Коэффициент уровня обслуживания SLA.

Для услуг управления рабочими станциями:

— Bronze = 1;

— Silver = 1,33 (2 для услуг Единой Службы Техподдержки);

— Gold = 2 (4 для услуг Единой Службы Техподдержки);

2. Коэффициент масштаба.

Для услуг управления рабочими станциями:

— от 50 до 100 РС = 1,5;

— от 101 до 200 РС = 1,32;

— от 201 до 500 РС = 1,3;

— 500 и больше РС = 1.

Маржа составляет:

— 10% - стандартные услуги;

— 15% - дополнительные услуги.

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

1.4 Обзор конфигураторов услуг и сервисных калькуляторов в сфере услуг colocation и аутсорсинга, представленных в Росии

1.4.1 Что же такое сервисный калькулятор или конфигуратор услуг?

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

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

Ниже произведен краткий обзор крупных консалтинговых и IT-компаний России и стран СНГ, реализующих услуги по colocation и аутсорсингу, включающий обзор сервисных калькуляторов компаний.

1.4.2 Компания EUROPROJECTS

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

«EUROPROJECTS» предлагает разработку и управление проектов финансированных фондами Европейского Союза (ЕС), консультации экспертов, подготовку бизнес планов. 14 февраля 2008 года в министерстве образования и науки был зарегистрирован Учебный Центр компании «EUROPROJECTS», который предлагает программы профессионального усовершенствования, практические семинары и курсы обучения. Группа консультантов по управлению и бизнесу объединяет в себе специалистов высокого уровня квалификации с опытом работы в Латвии и других Европейских странах. У консультантов имеются знания и практические навыки в присвоении ЕС фондов и частных инвестиций частному и общественному секторам. В процессе развития, подготовки и введения проекта, а так же в организации обучения, EUROPROJECTS сотрудничает с опытными представителями высших учебных заведений, банков, негосударственных организаций, самоуправлений и государством управляемых институций, а так же с местными и зарубежными компаниями, предлагающими консультации и с институциями, поддерживающими развитие бизнеса. Разрабатывая, вводя и составляя окончательные отчеты проектов присвоения ЕС финансирования, компания постоянно сталкивается с несовершенством разработанных в Латвии систем введения ЕС фондов. Для того чтобы сделать положительный вклад в развитие экономики Латвии, EUROPROJECTS предлагает каждому высказать свое мнение и конструктивные предложения, чтобы улучшить сложившуюся в Латвии систему ЕС фондов.

Группа ИТ era — специализированный отдел EUROPROJECTS, который предлагает своим клиентам широкий спектр услуг в области web программирования и дизайна, например, разработка домашних страниц и порталов, программирование и аудит, услуги SEO, размещение и хостинг серверов, е-маркетинг web проектов, разработка дизайна и Интернет рекламы. Непрекращающийся и уверенный рост IT группы era, удача наших разработанных решений по программированию и оригинальность идей дизайнеров стали возможными благодаря нашей команде. Все это дает возможность нашему предприятию занимать одну из ведущих позиций в Латвии в области web решений, более чем с 500 реализованными проектами. Теплая и дружеская атмосфера в предприятии и высокие требования к тем, кто хочет присоединиться к нашему коллективу, гарантируют нашим клиентам компетентные, выгодные и новые решения, а талантливым и амбициозным работникам — возможности карьерного роста, социальные гарантии и работу с предприятиями и организациями, занимающими лидирующие позиции в области разработки новых технологий. В 2007 году был разработан и предложен клиентам новый продукт — система управления складом ZION. Программа ZION более всего подходит складам с большой базой номенклатуры и с большим оборотом товаров. Специалисты все еще продолжают работу над усовершенствованием ZION, чтобы можно было предложить клиентам еще более удобный и лучший сервис.

Открываем конфигуратор услуг компании и видим следующий интерфейс (Рисунок 1.1):

1. Слева от нас находится список, предлагаемых компанией, услуг (поле A).

2. Выбираем интересующую нас услугу (поле B).

3. Просматриваем список сервисов, предлагаемых в рамках данной услуги (поле C).

4. Задаем параметры по каждому из сервисов (поле D).

5. Так же предоставлена информация по бесплатным, услугам (поле E).

6. Услуги за дополнительную плату (поле F).

7. Сформировали список услуг и жмем «Оформить заказ» (поле G).

Рисунок 1.1

Переходим к странице заказа услуги (рисунок 1.2):

1. Здесь мы видим общую сумму заказанной услуги (поле H).

2. Представляется возможность выбрать систему оплаты заказа (поле F).

3. Нажимаем «Заказать»

Далее пользователь переходит непосредственно к системе оплаты заказа.

Рисунок 1.2

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

Плюсы: Возможность оплаты услуги без непосресдвенной встречи с представителем компании, предлагающей услугу. Существует каталожное описание услуг, отраженных в конфигураторе (рисунок 1.1 поле A).

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

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

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

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

Основные минусы современных систем конфигурирования и расчета стоимости услуг и сервисов:

1. Конфигуратор или сервисный калькулятор не отражает порой и 50%, предлагаемых компанией, услуг.

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

3. Многие сервисные калькуляторы IT-компании не имеют web-публикаций.

4. Не существует ни одного конфигуратора, способного рассчитать трудозатраты и ресурсы компании для реализации проектов.

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

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

2. Интерфейс программы и ее web-публикация позволяют работать с программой, как клиенту, так и специалистам компаний. Данный функционал реализован с помощью разграничения доступа к информационной системе и авторизации внутри нее (существуют группы пользователей: Администраторы, Специалисты).

3. Реализован функционал расчета трудозатрат компании для реализации проектов.

4. Система имеет гибкий интерфейс пополнения каталогов продукции.

2. Выбор и обоснование средств разработки и технологий реализации

2.1 Выбор программной платформы разработки системы

2.1.1 Выбор технологии

По способу доступа к данным была выбрана технология трехуровневой архитектуры «клиент-сервер» Технология «клиент-сервер» позволяет наиболее полно реализовать функциональные возможности разрабатываемой ИПС.

Технология «клиент-сервер» была выбрана исходя из следующих достоинств:

1. Снижается нагрузка на сеть за счет уменьшения объема данных в пакетах, посылаемых по сети;

2. Снижаются требования к аппаратному обеспечению пользователя;

3. Повышается степень безопасности данных за счет жесткого контроля целостности.

Технология «клиент-сервер» сводится к разделению системы на две части — приложение-клиент (front-end) и сервер базы данных (back-end).

Термин «сервер баз данных» обычно используют для обозначения всей СУБД, основанной на архитектуре «клиент-сервер», включая и серверную, и клиентскую части. Такие системы предназначены для хранения и обеспечения доступа к базам данных. Хотя обычно одна база данных целиком хранится в одном узле сети и поддерживается одним сервером, серверы баз данных представляют собой простое и дешевое приближение к распределенным базам данных, поскольку общая база данных доступна для всех пользователей локальной сети.

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

Это язык по сути дела представляет собой текущий стандарт интерфейса СУБД в открытых системах. Собирательное название SQL-сервер относится ко всем серверам баз данных, основанных на SQL.

Серверы баз данных, интерфейс которых основан исключительно на языке SQL, обладают своими преимуществами и своими недостатками. Очевидное преимущество — стандартность интерфейса. В пределе, хотя пока это не совсем так, клиентские части любой SQL-ориентированной СУБД могли бы работать с любым SQL-сервером вне зависимости от того, кто его произвел.

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

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

В типичном на сегодняшний день случае на стороне клиента СУБД работает только такое программное обеспечение, которое не имеет непосредственного доступа к базам данных, а обращается для этого к серверу с использованием языка SQL.

Основная часть любой системы «клиент-сервер» — это сервер БД. Основное требование к серверу БД — обеспечение минимального времени выполнения запросов при максимально возможном числе пользователей. Существуют две основные архитектуры для построения процессора БД: архитектура с несколькими процессами и многопоточная архитектура.

2.1.2 Трехуровневая архитектура «клиент-сервер»

Трёхуровневая архитектура «клиент-серверной» модели довольно своеобразна и интересна по своей структуре. На верхнем уровне абстрагирования взаимодействия клиента и сервера достаточно четко можно выделить следующие компоненты:

*презентационная логика (Presentation Layer — PL), предназначенная для работы с данными пользователя;

*бизнес-логика (Business Layer — BL), предназначенная для проверки правильности данных, поддержки ссылочной целостности.;

*логика доступа к ресурсам (Access Layer — AL), предназначенная для хранения данных

1. «Толстый» клиент. (fat client) (Рисунок 2.1).

Рисунок 2.1

colocation менеджмент программный пирсон Наиболее часто встречающийся вариант реализации архитектуры клиент-сервер в уже внедренных и активно используемых системах. Такая модель подразумевает объединение в клиентском приложении как PL, так и BL, таким образом обеспечивается полная децентрализация управления бизнес-логикой. Однако в случае необходимости выполнения каких-либо изменений в клиентском приложении придется менять исходный код. Серверная часть, при описанном подходе, представляет собой сервер баз данных, реализующий AL. К описанной модели часто применяют аббревиатуру RDA — Remote Data Access.

2. «Тонкий» клиент. (thin client) (Рисунок 2.2).

Рисунок 2.2

Модель, начинающая активно использоваться в корпоративной среде в связи с распространением Internet-технологий и, в первую очередь, Web-браузеров. В этом случае клиентское приложение обеспечивает реализацию PL, поэтому клиент может довольствоваться довольно скромной аппаратной платформой, а сервер объединяет BL и AL. Максимальная загрузка сервера предусматривает выполнение бизнес-логики только с помощью хранимых процедур сервера (Хранимые процедуры — откомпилированные SQL-инструкции, хранящиеся на сервере). Это позволяет максимально централизовать контроль над данными и легко изменять правила работы сразу для целого предприятия. С другой стороны, незначительная корректировка правил, касающаяся только части пользователей, потребует длительной процедуры согласования. В этом случае невозможно реализовать какие-то исключения из общих правил для некоторых пользователей или приложений. В принципе, это хорошо и является залогом безопасности и целостности данных.

3. Сервер бизнес-логики. (трехуровневая архитектура) (Рисунок 2.3).

Рисунок 2.3

Модель с физически выделенным в отдельное приложение блоком BL, таким образом получаем трехуровневую архитектуру «клиент-сервер». На сервере БД может функционировать «универсальная» часть бизнес-логики (правила на уровне предприятия или группы связанных приложений). Такая схема позволяет поддерживать тонких клиентов на пользовательских компьютерах и в то же время разгрузить сервер БД от чрезмерной загрузки при сохранении гибкой системы работы с бизнес-правилами. В качестве промежуточного сервера может использоваться второй SQL-сервер, но чаще рациональней задействовать персональную СУБД, которая менее требовательна к аппаратным ресурсам и может обеспечить удобные средства построения и поддержки бизнес-логики.

2.2 Выбор СУБД

Выбор системы управления баз данных (СУБД) представляет собой сложную многопараметрическую задачу и является одним из важных этапов при проектировании информационных систем и разработке приложений баз данных.

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

Выбор СУБД производился по следующим критериям:

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

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

· Реализация языка запросов. Все современные системы совместимы со стандартным языком доступа к данным SQL-92, однако многие из них реализуют те или иные расширения данного стандарта;

· Масштабируемость. При выборе СУБД необходимо учитывать, сможет ли данная система соответствовать росту информационной системы, причем рост может проявляться в увеличении числа пользователей, объема хранимых данных и объеме обрабатываемой информации;

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

· Резервное копирование. В результате аппаратного сбоя может быть частично поврежден или выведен из строя носитель информации и тогда восстановление данных невозможно, если не было предусмотрено резервное копирование базы данных, или ее части. Резервное копирование спасает и в ситуациях, когда происходит логический сбой системы, например при ошибочном удалении таблиц. Существует множество механизмов резервирования данных (хранение одной или более копий всей базы данных, хранение копии ее части, копирование логической структуры и т. д.). Зачастую в систему закладывается возможность использования нескольких таких механизмов;

· Распространённость и популярность продукта. Редкая и неизвестная СУБД может быть просто забыта в будущем своим производителем. Поддержка и развитие созданной ИС напрямую зависит от этого фактора;

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

· Надёжность и устойчивость. Снижает затраты на поддержание работоспособности ИС;

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

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

· Поддержка кластеризации. Использование технологии кластеризации повышает производительность СУБД и обеспечивает ее отказоустойчивость, позволяя избежать

· Возможность реализации 3-х уровневой модели «клиент-сервер». То есть перемещение части бизнес-логики системы на функционал СУБД.

На основании проведенного аналитического обзора в качестве СУБД для ИПС нормативно-правовых документов была выбрана СУБД MSSQL. MSSQL представляет собой очень быстрый, многопоточный, многопользовательский и надежный SQL-сервер баз данных (SQL — язык структурированных запросов) с возможностью кластеризации процессов и реализации 3-х уровневой модели «клиент-сервер». Он в полной мере обладает средствами для организации логики на уровне построения запросов к СУБД, что значительно понижает нагрузку на сервер приложений (Промежуточный сервер в представленной архитектуре).

2.3 Выбор языка программирования

Для разработки ИПС нормативно-правовых документов был выбран скриптовый язык программирования с открытым исходным кодом PHP, предназначенный для генерации HTML-страниц на web-сервере и работы с базами данных. Выбор на этот язык программирований пал исходя из описанных ниже соображений.

Главным фактором языка PHP является практичность. РНР предоставляет программисту средства для быстрого и эффективного решения поставленных задач. Практический характер РНР обусловлен шестью важными характеристиками:

· Традиционностью;

Язык РНР будет казаться знакомым программистам, работающим в разных областях. Многие конструкции языка позаимствованы из С, Perl. Код РНР очень похож на тот, который встречается в типичных программах на С или Pascal. Это заметно снижает начальные усилия при изучении РНР. PHP — язык, сочетающий достоинства Perl и С и специально нацеленный на работу в Интернете, язык с универсальным (правда, за некоторыми оговорками) и ясным синтаксисом. И хотя PHP является довольно молодым языком, он обрел такую популярность среди web-программистов, что на данный момент является чуть ли не самым популярным языком для создания web-приложений (скриптов).

· Простотой;

Сценарий РНР может состоять из 10 000 строк или из одной строки — все зависит от специфики поставленной задачи. Вам не придется подгружать библиотеки, указывать специальные параметры компиляции или что-нибудь в этом роде. Механизм РНР просто начинает выполнять код после первой экранирующей последовательности ( ). Если код имеет правильный синтаксис, он исполняется в точности так, как указал программист.

PHP — язык, который может быть встроен непосредственно в html-код страниц, которые, в свою очередь будут корректно обрабатываться PHP-интерпретатором. Мы можем использовать PHP для написания CGI-сценариев и избавиться от множества неудобных операторов вывода текста. Мы можем привлекать PHP для формирования HTML-документов, избавившись от множества вызовов внешних сценариев.

Большое разнообразие функций PHP избавят от написания многострочных пользовательских функций на C или Pascal.

· Эффективностью;

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

Очень важное преимущество PHP заключается в его «движке». «Движок» PHP не является ни компилятором, ни интерпретатором. Он является транслирующим интерпретатором. Такое устройство «движка» PHP позволяет обрабатывать сценарии с достаточно высокой скоростью.

По некоторым оценкам, большинство PHP-сценариев (особенно не очень больших размеров) обрабатываются быстрее аналогичных им программ, написанных на Perl. Однако, чтобы не делали разработчики PHP, откомпилированные исполняемые файлы будут работать значительно быстрее — в десятки, а иногда и в сотни раз. Но производительность PHP вполне достаточна для создания вполне серьезных web-приложений.

· Безопасностью;

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

1. Средства безопасности системного уровня В РНР реализованы механизмы безопасности, находящиеся под управлением администраторов; при правильной настройке РНР это обеспечивает максимальную свободу действий и безопасность. РНР может работать в так называемом безопасном режиме (safe mode), который ограничивает возможности применения РНР пользователями по ряду важных показателей. Например, можно ограничить максимальное время выполнения и использование памяти (неконтролируемый расход памяти отрицательно влияет на быстродействие сервера). По аналогии с cgi-bin администратор также может устанавливать ограничения на каталоги, в которых пользователь может просматривать и исполнять сценарии РНР, а также использовать сценарии РНР для просмотра конфиденциальной информации на сервере.

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

· Гибкостью;

Поскольку РНР является встраиваемым (embedded) языком, он отличается исключительной гибкостью по отношению к потребностям разработчика. Хотя РНР обычно рекомендуется использовать в сочетании с HTML, он с таким же успехом интегрируется и в JavaScript, WML, XML и другие языки. Кроме того, хорошо структурированные приложения РНР легко расширяются по мере необходимости (впрочем, это относится ко всем основным языкам программирования).

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

Поскольку РНР не содержит кода, ориентированного на конкретный web-сервер, пользователи не ограничиваются определенными серверами (возможно, незнакомыми для них). Apache, Microsoft IIS, Netscape Enterprise Server, Stronghold и Zeus — РНР работает на всех перечисленных серверах. Поскольку эти серверы работают на разных платформах, РНР в целом является платформенно-независимым языком и существует на таких платформах, как UNIX, Solaris, FreeBSD и Windows 95/98/NT/2000/XP/2003.

Наконец, средства РНР позволяют программисту работать с внешними компонентами, такими как Enterprise Java Beans или СОМ-объекты Win32. Благодаря этим новым возможностям РНР занимает достойное место среди современных технологий и обеспечивает масштабирование проектов до необходимых пределов.

Бесплатное распространение.

Существует еще одна «характеристика», которая делает РНР особенно привлекательным: он распространяется бесплатно! Причем, с открытыми исходными кодами (Open Source).

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

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

2.4 Выбор web-сервера

В качестве web-сервера (программного обеспечения, осуществляющего взаимодействие по HTTP протоколу с браузерами) был выбран Apache HTTP-сервер. Apache, на данный момент, является самым распространенным, мощным и удобным web-сервером с открытым исходным кодом, совместимым со стандартом HTTP/1.1.

Apache — это web-сервер с открытым исходным кодом, популярный во всём мире. Причин популярности несколько. Первая и основная — кроссплатформенность. Apache может быть установлен практически на любую ОС и практически не зависит от аппаратного обеспечения. На данный момент существуют версии для Windows, Unix и Mac. Apache с легкостью устанавливается как на обычных ПК, так и на крупных серверах. Вторая причина популярности — простая расширяемость. Apache состоит из ядра, которое обеспечивает самые основные функции, всегда присутствующие в стандартной поставке, и модулей, расширяющих его возможности. Некоторые модули по умолчанию входят в дистрибутив. Другие необходимые модули можно впоследствии подключить к Apache. Таким образом, например, реализуется поддержка SSL, или языков программирования. Для Apache уже создано огромное число стандартных библиотек, позволяющих решать практически любые задачи. Третья причина — простота начальной установки и настройки. Все параметры конфигурации хранятся в соответствующих конфигурационных файлах. Пользователь может по своему усмотрению менять даже самые тонкие настройки сервера. Правда, есть в таком подходе существенный недостаток — после сохранения изменений в файле, нужно перезапустить службу сервера.