Главная страница

Управление ИТ и тп. Современные технологии делопроизводства и документооборота


Скачать 1 Mb.
НазваниеСовременные технологии делопроизводства и документооборота
Дата09.07.2019
Размер1 Mb.
Формат файлаdoc
Имя файлаУправление ИТ и тп.doc
ТипРуководство
#83860
страница10 из 13
1   ...   5   6   7   8   9   10   11   12   13

IT Service Management Tools


Обычно под термином IT Service Management Tools понимают средства автоматизации ITSM-процессов. На этом рынке существует широкий спектр решений, оценка достоинств и недостатков которых — тема отдельной дискуссии.

Методология HP ITSM независима от используемых средств автоматизации. Проектирование или реинжиниринг процессов выполняется без привязки к конкретным программным продуктам. В идеале средства автоматизации выбираются уже после проектирования процессов, исходя их состава функций, требующих автоматизации. Конечно, в состав HP ITSM входит большой блок техник и шаблонов, позволяющих выполнить автоматизацию процессов ITSM с применением инструментария HP OpenView Service Desk, который сертифицирован на соответствие ITIL и позволяет решить большинство задач автоматизации процессов ITSM. При этом OpenView Service Desk сочетает жесткое следование принципам ITIL и удобный интерфейс, обеспечивая интеграцию с другими системами. Однако при использовании методологии HP ITSM перечень возможных к использованию средств автоматизации не ограничен только программными продуктами от HP. Основной акцент в ITSM-проекте делается на процессы. Выбор средств автоматизации, их функциональность, конечно же, влияют на ход проекта и его конечный результат.

Мифы и реалии ITSM-проектов


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

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


ITIL (IT Infrastructure Library) — обобщение лучшего международного опыта в области организации и управления информационными технологиями. ITIL содержит детализацию основных принципов ITSM, в частности, по следующим дисциплинам:

  • Управление конфигурациями (Configuration Management);

  • Управление изменениями (Change Management);

  • Диспетчерская служба (Help Desk, Service Desk, Incident Management);

  • Управление проблемами (Problem Management);

  • Управление уровнем обслуживания (Service Level Management);

  • Управление ресурсами (Capacity Management);

  • Управление доступностью ресурсов и услуг (Availability Management, IT Service Continuity);

  • Управление расходами (Financial Management for IT Services);

  • Управление клиентами (Customer Management).

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

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

Одной из самых неприятных, по возможным последствиям, является возможность сделать все втихаря. За рубежом все значимые ИТ-проекты реализуются открыто, в тесной кооперации с бизнес-подразделениями под пристальным контролем руководства. В России, не добившись должной поддержки у бизнес-руководителей, но осознавая необходимость ITSM, некоторые ИТ-руководители выполняют проект собственными силами внутри ИТ-службы и представляют готовый результат бизнесу по завершении проекта. К сожалению, большинство дисциплин ITIL должны быть в значительной степени увязаны с деятельностью бизнес-подразделений. Это относится даже к таким «внутренним» процессам, как Управление конфигурациями и Управление релизами. И дело даже не в том, что необходимо знать специфику бизнеса (в России часто именно ИТ-специалисты лучше знают бизнес-процессы). Дело в «причастности», в «вовлеченности» бизнеса в выполняемые работы. По окончании проекта бизнес-подразделения должны «захотеть» следовать новым принципам работы.

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

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

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

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

Выводы


Внедрение идеологии ITSM и рекомендаций ITIL является сложной задачей: реализовывать подобные проекты необходимо с применением специализированных методологий.

Методологии внедрения ITSM постоянно развиваются, причем некоторые изменения могут носить достаточно радикальный характер. Так, за последние два года существенно возросла значимость управления уровнем предоставления услуг.

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

Литература


  1. Thomas Mendel, Beyond ITIL: Despite Hype, Full Implementations are the Exception, Giga Research, October 23, 2003



Меняющийся лик соглашений об уровне сервиса

Дэн Блачарски
Журнал сетевых решений "LAN" №4, 2000

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


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

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

«С точки зрения обслуживания разница между сетью, приложениями и бизнес-процессами постепенно стирается», — говорит Джефф Каплан, директор по стратегическому маркетингу в подразделении NetCare Professional Services компании Lucent Technologies.

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

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

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

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

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

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

ПРОИЗВОДИТЕЛЬНОСТЬ ПРИЛОЖЕНИЙ


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

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

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

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

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

«Мы видим, что самое важное — то, как работа сети сказывается на конечных пользователях, — говорит Энди Бирн, менеджер по продуктам VitalAnalysis и VitalHelp в отделе NetCare компании Lucent Technologies. — В конечном итоге, продуктивность рядовых пользователей, работающих с сетевыми приложениями, сказывается на прибыльности компании».

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

ТОЧКА ЗРЕНИЯ КОНЕЧНЫХ ПОЛЬЗОВАТЕЛЕЙ


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

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

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

В целях учета точки зрения конечных пользователей такие продукты, как VitalSuite 7.0 от Lucent NetCare, осуществляют мониторинг не только работы устройств, но и работы приложений — для предоставления решения, отчеты которого мог бы понимать любой сотрудник организации (о продуктах см. врезку «Некоторые инструменты для мониторинга»).

«Среди тех, кто принимает решение относительно выбора технологий, менеджеры по маркетингу и по продажам, — говорит Бирн. — Они непосредственно заинтересованы в том, как структура продаж будет реализована в Web».

ОГОВАРИВАЕМЫЕ УСЛОВИЯ


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

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

SLA состоит из нескольких компонентов, каждый из которых вносит вклад в измерение уровней сервиса (см. более подробно об условиях SLA во врезке «Элементы SLA»). По данным исследования International Network Services (INS, теперь часть Lucent), главной характеристикой является доступность сети, а далее по важности — уровень удовлетворенности пользователей, производительность сети и доступность приложений.

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

Что касается приложений, то для конечных пользователей наиболее существенны два параметра: доступность и время отклика приложения. Вместо времени отклика между двумя устройствами эта метрика, например, сообщает, что при выполнении приложения планирования корпоративных ресурсов среднее время отклика для пользователей составляет 8—10 с.

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

КАК ЭТО РАБОТАЕТ


«Успех на рынке управления уровнем сервиса будет зависеть от способности продукта обрабатывать данные из различных источников и извлекать из собранных данных необходимую информацию, — говорит Марк Бучард, аналитик-исследователь из META Group. — Как правило, это подразумевает переход от сетецентрической статистики к статистике по ОС и серверам, а также критически важным приложениям».

Инструментарий мониторинга SLA предлагает обычно два вида анализа: в реальном времени и в перспективе. Мониторинг в реальном времени применяется для выявления проблем на ранних стадиях до того, как они приобретут серьезный характер. Он открывает возможность решить проблему, прежде чем условия соглашения будут нарушены. Анализ же тенденций позволяет проверить уровень сервиса за определенный период, а также выявить тенденции общего характера, способные привести к проблемам в будущем.

Как измеряется производительность? Какие данные записываются? Как показало исследование INS, наиболее популярной метрикой, используемой при определении доступности и производительности, является доступность всех компонентов сети, в том числе устройств и каналов; следом за ней идет доступность приложений в сети (см. Рисунок).


Метрическая система. Приведенные параметры используются для определения и измерения доступности и производительности сети.

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

В случае VitalSuite 7.0 мониторинг работы приложений осуществляется посредством размещения программных агентов на каждом клиенте. VitalSuite отказывается от опросов всех агентов (так как это привело бы к значительному снижению производительности) благодаря реализации механизмов принудительной рассылки на базе HTTP, так как при необходимости агенты могут сами передавать сообщения HTTP серверной части приложения мониторинга. Таким образом, опрашивать все настольные системы не требуется, и инструмент имеет приемлемую производительность.
1   ...   5   6   7   8   9   10   11   12   13


написать администратору сайта