6.2. Управление приложениями

6.2.1. ERP-системы

6.2.2. Системы техобслуживания и ремонта (MRO)

6.2.3. Системы поддержки жизненного цикла продукта (PLM)

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

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

·         сокращение сроков проектно-конструкторских работ и технической подготовки производства;

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

Решение этих задач невозможно на сегодняшний день без современных информационных систем, основанных на системах ERP и PLM.

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

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

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

В состав PLM решений входит ряд подсистем, таких как

1.      Управление данными CAD/CAM/CAE

2.      Системы технического документооборота и электронный архив (TDM)

3.      Управление составом изделия (BOM)

4.      Управление инженерными данными

5.      Управление процессами и потоками работ

6.      Управление процессом разработки изделия

7.      Управление контентом и документацией

8.      Управление конфигурациями

9.      Управление соответствия нормативным требованиям

10.  Система обеспечения совместной работы

11.  Визуализация жизненного цикла изделия

внедрение и сопровождение каждой из подсистем представляет собой сложный процесс.

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

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

PLM-системы распространяют понятие цифрового макета на все производство.

Обычно внедрение систем PLM начинается с систем CAD (двумерное проектирование на Autocad) или электронного архива. Это связано с громадным количеством бумажных чертежей, находящихся на предприятиях. Чертежи сканируют и посредством специальных программ, переводят их в формат Autocad. После этого данные необходимо поместить в электронный архив.

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

Крупные предприятия предъявляют ряд требований к электронным архивам:

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

После или одновременно с внедрением систем электронного архива происходит развёртывание подсистемы управления составом изделия (PDM)

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

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

Также обеспечивается:

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

Использование PLM систем позволяет начать проектирование технологической оснастки ещё до окончательного утверждения конструкторской документации. Это связано с тем, что элементная модель для инженерных расчётов, 3D модель (чертёж), программа для обработки ЧПУ хранится в единой базе данных. При изменении исходной модели появляется возможность проследить зависящие от неё объекты и провести необходимые корректировки.

Система PLM должна обеспечить:

1.      Сбор и хранение всех данных о продукте на одном защищенном сервере.

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

3.      Данные о продукте доступны только зарегистрированным пользователям в соответствии с назначенным профилем. Автоматическая система резервного копирования гарантирует сохранение информации при возможных проблемах с оборудованием.

4.      Использование специального класса стандартных деталей, шаблонов стандартных деталей и методологии работы с ними.

5.      Копирование типового проекта и использование его как прототипа для быстрого начала работ над новым проектом.

6.      Проверки на наличие в базе данных стандартных компонентов и обязательное их использование.

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

 Прежде всего, давайте определимся с понятиями. Что относится к ИТ-инфраструктуре и есть ли изменения в этом понятии в связи с новыми тенденциями? Начнем с определений:[1]

Инфраструктура  — это комплекс взаимосвязанных обслуживающих структур или объектов, составляющих и/или обеспечивающих основу функционирования системы.

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

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

·    сервера и системы хранения;

·    клиентские ПК;

·    ноутбуки, мобильные устройства, смартфоны, PDA и т.д.;

·    принтеры, копировальная техника, сканеры и т.д.;

·    локальные и глобальные сети, оборудование и ПО для передачи голоса и данных;

·    операционные системы;

·    инфраструктурное ПО: СУБД, интеграционное ПО и интеграционные платформы, приложения для коллективной работы (почта, календари и т.д.);

·    ПО для разработки приложений;

·    ПО для мониторинга и управления сетями и приложениями;

·    оборудование и ПО для обеспечения информационной безопасности.

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

6.2.1 Тенденции в области ИТ-инфраструктуры

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

1.                  Рост мощности и падение стоимости ИТ-инфраструктуры, но рост ее TCO.

2.                  Возвращение идеологии терминального доступа.

3.                  Переход на парралелизацию вычислений и горизонтальную масштабируемость.

4.                  Конвергенция и «персонализация» элементов ИТ-инфраструктуры.

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

6.                  Повышение важности архитектуры и усложнение выбора платформы.

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

Рост мощности и падение стоимости ИТ-инфраструктуры, но рост ее ТСО

Эта тенденция базируется на трех более мелких.

1. Увеличение вычислительной мощности оборудования. Возможности более простых и стандартных серверов x86 постоянно растут. Более того, за последние годы этот процесс еще более ускорился. В самой популярной линейке серверов на базе процессоров x86 год назад произошли поистине революционные изменения: многопроцессорные x86-сервера – это уже машины принципиально нового уровня, чем более ранние x86-сервера. В результате, этой тенденции сервера высшего класса постепенно вытесняются серверами среднего уровня. Происходят заметные процессы миграции приложений с серверов высшего класса на машины классом ниже. Причем, вследствие очень серьезной разности в цене, стоимость такой миграции окупается в течение первого года. Причины, по которым приложения остаются на серверах высшего класса, как правило, связаны с исторической архитектурой приложения, а не с недостатком вычислительной мощности у серверов среднего уровня. Это позволяет говорить, что в перспективе 5-7 лет (среднее время жизни приложения) большинство корпоративных приложений перейдет на сервера среднего уровня.

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

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

3. Снижение стоимости элементов ИТ-инфраструктуры не приводит к общему снижению общих затрат на ИТ-инфраструктуру. Связано это с несколькими факторами. Во-первых, очень часто компания развивается очень быстро и  объемы и сложность обрабатываемой информации растут еще быстрее. Кроме того, стоимость обеспечивающих систем растет вследствие роста стоимости электричества, площадей, затрат на охлаждение и т.д. Уменьшается объем технических средств, но увеличивается стоимость аренды помещения. В результате ТСО такого ключевого элемента ИТ-инфраструктуры как ЦОД растет и общая TCO ИТ-инфраструктуры также постоянно растет[2].

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

Возвращение идеологии терминального доступа

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

1.                  Оконечные устройства будут «отупляться», становиться все проще и слабее. Для получения одинакового «окна в мир» корпоративных данных с разных устройств проще минимально использовать их вычислительные особенности. Хотя, все-таки, речь идет не об абсолютном «отуплении», технология и вычислительные мощности стремительно дешевеют и это будет стимулировать рост абсолютной вычислительной мощности оконечных устройств. Но в то же время, их относительная мощность по сравнению с центральными корпоративными ресурсами будет падать.  

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

Парралелизация и горизонтальная масштабируемость

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

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

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

Конвергенция и «персонализация» элементов ИТ-инфраструктуры

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

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

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

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

·    серьезное улучшение характеристик производительности;

·    достижение очень высокого уровня горизонтального масштабирования.

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

Виртуализация центральных корпоративных вычислений

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

И при этом количество «простаивающих» ресурсов было и остается огромным: средняя загрузка серверного оборудования архитектуры x86 составляет менее 10% от общего ресурса этого оборудования, сервера класса RISC позволяют загружать сервер на 30-40%. Поскольку эта проблема была общей и крайне острой, компании-производители серверного оборудования (и систем хранения данных) стали разрабатывать механизмы борьбы с этой проблемой. Выход был найдет в виртуализации ресурсов. Собственно, ничего нового найдено и не было, ведь не случайно мейнфрейм позволяет загружать систему «под завязку», при этом сохраняя высокую надежность работы. Механизмы виртуализации были разработаны и внедрены в мейнфреймы с самого начала, но теперь речь уже шла о других серверных архитектурах. Технологии виртуализации позволяют разделить оборудование на части, которые соответствуют текущим потребностям, тем самым увеличивая утилизацию имеющихся мощностей.

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

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

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

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

Преимущества. Сегодня виртуализация рассматривается в первую очередь как эффективный способ оптимизации затрат на развитие и поддержку инфраструктуры. Расчеты TCO и ROI позволяют говорить о возврате инвестиций в течение 3-5 лет. При этом достигаются следующие дополнительные преимущества:

·                     сокращаются издержки на ввод в эксплуатацию новых систем и серверов, а также на обслуживание задействованного оборудования;

·                     появляется возможность изменить логику приобретения ИТ-активов перейти от приобретения и управления единицами оборудования (серверами, СХД) к выделению серверного времени, дискового пространства и сетевой пропускной способности, необходимой для выполнения вашего приложения.

·                      кардинально уменьшается количество физических серверов и серверных стоек, упрощается ИТ-инфраструктура компании (средний коэффициент «упаковки» серверов при их виртуализации составляет примерно 10:1);

·                     повышается эффективность использования серверного оборудования в рабочие часы до 60–80%; 

·                     сокращается энергопотребление и тепловыделение серверов, достигается десятикратная экономия на энергопотреблении серверов и примерно девятикратная на кондиционировании; 

·                     количество сетевых портов уменьшается в 4-6 раз и в 6-10 раз – сетевых коммутаторов; 

·                     экономия серверных площадей достигает 5–6 раз;

·                     устраняется зависимость операционной системы и предоставляемых сервисов от аппаратного обеспечения; 

·                     упрощаются процедуры резервного копирования, управления и мониторинга.

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

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

Отметим, что распространенное мнение, что применение средств виртуализации приводит к потери производительности лишено серьезных оснований. Конечно нельзя отрицать, что добавление новой прослойки между аппаратной частью и операционной системой повысит скорость ее работы. Потери неизбежны, но насколько они существенны? По различным оценкам снижение производительности при переходе в виртуальную среду на том же оборудовании в большинстве случаев не превышает 10% в базовой конфигурации и может быть доведена до 2-6% путем оптимизации настроек. Это важно для систем, загрузка которых приближается к 100%, но много ли их? Для 99% серверов при снижении эффективности операций на 2-6% качество предоставляемого сервиса для пользователя существенно не измениться.

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

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

Повышение важности архитектуры и усложнение выбора платформы

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

Масла в огонь подливает и постепенное изменение схемы приобретения ИТ-активов, перевод затрат на ИТ-активы из CAPEX в OPEX. Это, по сути, происходит в последние несколько лет путем роста использования механизмов аренды и аутсорсинга ИТ-ресурсов. А если по-другому происходят закупки ИТ-активов и усложняется планирование и выбор платформы, то усложняется и управление ИТ в целом.

Актуальные задачи в области ИТ-инфраструктуры

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

1.                  Оптимизация ИТ-инфраструктуры с целью снижения затрат.

2.                  Снижение затрат на приобретаемое оборудование и ПО.

3.                  Преодоление ограничений инженерной инфраструктуры ИВЦ.

4.                  Повышение надёжности ИТ.

5.                  Улучшение качества предоставляемых ИТ-сервисов.

6.                  Формирование стратегии эффективного энергопотребления.

7.                  Увеличение гибкости ИТ, ускорение реакции на изменения ситуации на рынке

8.                  Измерение ценности ИТ для бизнеса.

9.                  Обеспечение соответствия требованиям и нормативам.

10.              Внедрение новых сервисов и услуг.

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

6.2.2 Принципы построения ИТ-инфраструктуры

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

1.                  Баланс консолидации и распределения ресурсов.

2.                  Обеспечение гибкости и адаптивность ИТ-инфраструктуры.

Рассмотрим их подробнее.

Баланс консолидации и распределения ресурсов

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

С точки зрения консолидации и разделения доступа к ресурсам ИТ-инфраструктуры предприятия могут находится на одном из пяти уровней (этапов) развития (рис. 1).

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

Второй уровень — «группа» — несколько пользователей, например сотрудники одного департамента, объединяются в группу, которая подключена по сети к принтеру. Каждый может распечатать свой документ на одном и том же принтере. Это удобнее и экономнее. Правда, возникает ситуация, когда кто-то распечатывает много документов — и «тормозит» работу остальных.

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

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

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

Рис. 1. Пять уровней развития ИТ-инфраструктуры с точки зрения распределения ресурсов.

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

Консолидация вычислительных ресурсов → Консолидация информационных ресурсов → Создание системы управления ИТ-ресурсами→ Создание процессов и системы автоматизации работы с ресурсами.

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

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

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

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

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

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

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

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

Давайте рассмотрим простой пример. Как поступить при расширении ИТ-инфраструктуры: купить три недорогих сервера или blade-систему с объединенным электропитанием, управлением и интегрированными сетевыми компонентами, в которую можно установить 14 серверов и в которой изначально заложены принципы унификации оборудования и снижения затрат на обслуживание и поддержку и три blade-сервера в ней? Ответ неочевиден, и прежде всего потому, что первый вариант – это просто инвестиции в расширение ИТ-инфраструктуры, а второй вариант – это инвестиции в расширение ИТ-инфраструктуры но с перспективой ее дальнейшей консолидации и оптимизации и он требует дополнительных затрат. Если текущую потребность можно удовлетворить тремя серверами и активное развитие инфраструктуры в ближайшие годы не планируется, какой смысл покупать blade-систему, возможности которой не будут использоваться? И, наоборот, если системы активно развиваются, и существует большая вероятность того, что в течение года понадобится еще несколько аналогичных серверов, более эффективно инвестировать в blade-систему.

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

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

Гибкость и адаптивность ИТ-инфраструктуры

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

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

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

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

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

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

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

6.2.3 Построение системы управления ИТ-инфраструктурой

В сложной и разветвленной системе с сотнями и тысячами элементов начинают работать законы статистики, поэтому у CIO возникает бесчисленное количество мелких проблем:

ñ    регулярно что-то выходит из строя или неправильно работает;

ñ    постоянно заканчиваются ресурсы в одних местах, возникают бутылочные горлышки и заторы в других — приходится где-то что-то перемещать и т.д.;

ñ    все время нужно делать какие-то действия по общей поддержке системы;

ñ    надо не только вести и внедрять текущие проекты, но планировать закупки, будущие внедрения;

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

По сути, решение всех этих (и аналогичных) проблем сводится к небольшому числу советов:

ñ    построить систему мониторинга вычислительных ресурсов: всегда знать, где какие ресурсы и как загружены, собирать статистику для планирования;

ñ    построить систему мониторинга работы вычислительных ресурсов: четко знать, где и когда произошел отказ, иметь выработанную схему их устранения и обеспечения работоспособности систем в зависимости от необходимого уровня их работы;

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

ñ    на основе мониторинга ресурсов и системы их перераспределения и выделения под различные задачи построить систему учета вычислительных ресурсов и управления конфигурациями.

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

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

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

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

1.                  Построение модели компонентов ИТ-инфраструктуры;

2.                  Сопоставление и анализ моделей ИТ-инфраструктуры и деятельности компании;

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

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

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

·                     какие задачи и функции организации не поддерживаются средствами ИТ или эта поддержка недостаточна и в какой степени;

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

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

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

1.                              Перечень важных и ключевых ИС и элементов ИТ-инфраструктуры.

2.                              Перечень ИС и элементов ИТ-инфраструктуры, эксплуатация которых нецелесообразна.

3.                              Оценка дефицита мощностей компьютерного и телекоммуникационного оборудования.

4.                              Перечень недостающих общесистемных средств.

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

На основании этих данных планируется дальнейшее развитие ИТ-инфраструктуры.

Этот план должен отражаться в модели, то к модели as is (как есть), по результатам анализа, добавляется модель to be (как должно быть).

6.2.4 Сервера и системы хранения данных

Сначала дадим определение:

Серверное оборудование – это вычислительная мощность, на которой решаются бизнес-задачи. … Обязательной частью сервера является встроенная система хранения данных, с которыми он работает.

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

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

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

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

Какие же параметры важны для сервера?

·                производительность или быстродействие (вычислительная мощность);

·                операционная система/системы, которые могут работать на сервере;

·                возможность расширения (масштабирования) его ресурсов в определенных диапазонах (процессоры, память, каналы связи);

·                перспективы развития линейки данных серверов;

·                совместимость с другим оборудованием (серверами, системами хранения данных, коммутаторами и т.д.);

·                средние сроки службы;

·                средние сроки наработки на отказ (надежность, доступность, ремонтопригодность[1]).

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

·    серверы нижнего класса (low end) обычно самые дешевые, простые, в них немного (единицы) процессоров, отсутствуют многие механизмы обеспечения надежности (дублирование элементов и т. д.);

·    серверы среднего класса (middle range) уже обладают хорошими параметрами надежности, в них существенно больше ресурсов, их можно гораздо лучше «расширять», то есть добавлять ресурсы по мере необходимости;

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

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

6.2.5 Системное программное обеспечение

Программное обеспечение (ПО) — это совокупность программ системы обработки информации и программных документов, необходимых для эксплуатации этих программ[2].

Также — совокупность программ, процедур и правил, а также документации, относящихся к функционированию системы обработки данных[3].

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

ПО может быть разделено на категории по множеству признаков:

Ø   по назначению программное обеспечение принято подразделять на системное, прикладное и инструментальное;

Ø   по способу распространения и использования на несвободное/закрытое, открытое и свободное[4];

Ø   по способу создания ПО может быть закуплено у сторонних фирм, а может быть создано самим отделом ИТ;

Ø   по функциональному назначению;

Ø   по архитектурно-техническому построению.

По функциональному назначению ПО делится на три большие категории: операционные системы, офисные пакеты и серверное ПО.

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

Операционные системы выполняют следующий круг задач:

Ø   загрузка программ в оперативную память и их выполнение, остановка программ и т.д.;

Ø   управление оперативной памятью (распределение между процессами, организация виртуальной памяти),

Ø   параллельное или псевдопараллельное выполнение задач (многозадачность), взаимодействие между процессами (обмен данными, взаимная синхронизация);

Ø   разграничение доступа различных процессов к ресурсам;

Ø   управление доступом к данным на различных носителях, организованным в той или иной файловой системе;

Ø   ввод/вывод данных, доступ к периферийным устройствам (устройствам ввода-вывода);

Ø   сетевые операции, поддержка стека сетевых протоколов;

Ø   защита самой системы, а также пользовательских данных и программ от действий пользователей (злонамеренных или по незнанию) или приложений;

Ø   и др.

На текущий момент есть множество операционных систем, самые распространённые из которых это семейство Windows и Unix-образных операционных систем, к последним относится и Linux.

2. Офисные пакеты. Офисный пакет – это набор программ, предназначенный для обработки текстов, табличных данных, почтовой корреспонденции, небольших баз данных, фотографий и т.д. Офисные пакеты, как правило, имеют, хорошую интегрируемость между своими приложениями, схожий интерфейс и логику работы в них. Существует множество разновидностей офисных пакетов. Например, Gnome Office и Open Office являются свободно распространяемыми офисными пакетами, Microsoft Office 2007/2010, LotusNotes – проприетарными, а Google Docs предоставляется как сервис. В настоящее время наблюдается тенденция к отходу от классического направления в трактовке офисного пакета как набора программ в пользу превращения его в средство совместной работы, включающего не только клиентскую, но серверную и сервисную часть (или SaaS-часть).

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

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

Серверы работы с электронной почтой – это инфраструктурное программное обеспечение, обеспечивающее работу с электронными сообщениями, а также предоставляющее функциональность групповых/персональных календарей. Сервер предоставляет механизмы хранения, направления и транспортировки сообщений, а также службы календарей. Следует отметить тенденцию ухода от простой электронной почты к комплексным  средствам корпоративного управления, таким как Microsoft Exchange Server 2010.

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

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

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

Приведем исторически первое определение компании Merrill Lynch, данное в 1998 году: «корпоративные информационные порталы -- это приложения, которые позволяют компаниям раскрывать информацию, хранящуюся внутри и вне организации, и предоставлять пользователям единый шлюз доступа к персонализированной информации, необходимой для принятия бизнес-решений». Задачи, для решения которых использовались корпоративные порталы, эволюционировали со временем. На рис 2. показана схема эволюции корпоративных порталов.

На рис 2. показана схема эволюции корпоративных порталов.

Сегодняшние задачи, которые выполняет корпоративный портал можно разделить на 2 группы:

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

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

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

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

·                       инструменты для публикации контента (блоги, файлохранилище, wiki, галереи, видео сервисы);

·                       инструменты для обсуждения (форумы, блоги, комментарии, отзывы);

·                       инструменты для организации контента (тэги, закладки, рейтинги);

·                       инструменты для контроля и мониторинга (персональные RSS-потоки).

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

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

Серверы интеграции данных – это обобщенная категория инфраструктурного ПО, включающая в себя инструменты извлечения, трансформации и загрузки данных (Extraction, Transformation and Loading, ETL), используемые для извлечения данных из различных источников данных (обычно операционных приложений) для их дальнейшей загрузки в хранилища данных или предоставления BI-инструментам. Инструменты интеграции данных образуют первый уровень архитектуры управления корпоративными данными.

Сервисная шина предприятия (Enterprise Service Bus, ESB) – это программное обеспечение, обеспечивающая интеграцию различных приложений. Один из наиболее популярных современных стандартов ESB связан с сервисной архитектурой приложений (SOA).  К основным принципам ESB можно отнести следующие:

·                    поддержка синхронного и асинхронного способа вызова сервисов;

·                    использование гарантированной доставки сообщений;

·                    поддержка модели транзакций;

·                    доступ к данным из интегрируемых информационных систем с помощью готовых или специально разработанных адаптеров;

·                    обработка и преобразование сообщений;

·                    оркестровка и хореография сервисов.

По архитектурно-техническому построению можно отметить четыре основные архитектурные системы построения ПО.

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

·                    терминальный сервер - мощный компьютер, предоставляющий свои вычислительные мощности клиентам;

·                    тонкий клиент - терминал, передающий управляющие команды серверу.

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

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

Преимущества:

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

·    улучшает защиту данных -- все данные хранятся на сервере, который, как правило, защищён гораздо лучше большинства клиентов, на сервере проще обеспечить контроль полномочий, чтобы разрешать доступ к данным только клиентам с соответствующими правами доступа;

·    позволяет использовать различные программы-клиенты, часто клиенты с разными аппаратными платформами, операционными системами и т. п.

Недостатки:

·    неработоспособность сервера может сделать неработоспособной всю систему;

·    поддержка работы данной архитектуры требует отдельного специалиста — системного администратора;

·    высокая стоимость оборудования.

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

Преимущества:

·       повышенная масштабируемость;

·       повышенная конфигурируемость — изолированность уровней друг от друга позволяет быстро и простыми средствами переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из уровней;

·       повышенная безопасность;

·       повышенная надёжность;

·       низкие требования к скорости канала между клиентским приложением и сервером приложений;

·       низкие требования к производительности и техническим характеристикам клиентского приложения, как следствие снижение их стоимости.

Недостатки:

·       более высокая сложность создания приложений;

·       сложнее в разворачивании и администрировании;

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

·       высокие требования к скорости канала (сети) между сервером базы данных и серверами приложений.

4.      Распределённая вычислительная архитектура. Это техническая архитектура с использованием нескольких компьютеров, чаще всего объединённых в параллельную вычислительную систему, применяемая для решения трудоёмких вычислительных задач. Выполнение последовательных вычислений в распределенных системах имеет смысл в рамках решения многих задач одновременно, например, в распределенных системах управления. Особенностью распределенных вычислительных систем, в отличие от локальных суперкомпьютеров, является возможность неограниченного наращивания производительности за счет масштабирования. Слабосвязанные, гетерогенные вычислительные системы с высокой степенью распределения выделяют в отдельный класс распределенных систем — Grid.

Лицензирование программного обеспечения. Программное обеспечение являются объектом авторских прав и регулируются отдельной, 4 частью Гражданского Кодекса РФ. Для использования этого объекта авторского права требуется лицензия. Важнейшей особенностью закона является то, что отсутствие запрета не считается согласием (разрешением), поэтому для использования любого ПО необходимо получить в явном виде разрешение на его использование у правообладателя, как правило – в виде лицензии.

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

Не  следует думать, что свободное ПО отличается тем, что у него нет лицензий. Например, Linux предоставляется по лицензии проекта GNU[5], которая так же накладывает ряд ограничений на использование этого ПО. Например, если Вы использовали даже небольшую часть кода Linux в своей программе, или задействовали для написания своих программ компилятор с лицензией GNU, то далее Вы обязаны предоставлять вместе со своими программами их исходный код.

6.3.5. Системное программное обеспечение

6.3.6. Сети и телекоммуникации

6.4. Управление персоналом