Помимо измерений готовности управление качеством ИТ нуждается в более развернутой системе оценки.

На растущую зависимость от платформ ИТ руководители предприятий реагируют ужесточением требований к функционированию ИТ. Отдел ИТ должен гарантировать не только готовность платформ, но и получение от различных приложений «правильных» результатов в «правильный» момент времени, для чего необходимо наличие новых соглашений об уровне сервиса (Service Level Agreement, SLA), отвечающих высоким требованиям к технической прозрачности. Целью же является внедрение системного мониторинга в измерение процессов и услуг.

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

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

НОВЫЕ SLA, НОВЫЕ МЕТОДЫ

Безусловно, подобные SLA не подходят для современного SLM в соответствии с рекомендациями библиотеки инфраструктуры ИТ (IT Infrastructure Library, ITIL). SLA должны описывать услугу ИТ таким образом, чтобы она как можно лучше поддерживала деловой процесс. Отказываясь от общепринятого указания системной готовности в процентах, договаривающиеся стороны охотнее согласуют сегодня сквозные SLA (End-to-End), что, однако, не вписывается в SLA на основе готовности — в конечном итоге они могут описать лишь функционирование инфраструктуры.

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

МОДЕЛЬ БАЛЛОВ

Этот новый тип измерения готовности выражается посредством модели баллов (Scoring Model) лучше, чем при помощи определения готовности в процентах. Комбинация отдельных технических компонентов, их готовность, производительность и желаемые результаты, а также качество могут при невыполнении быть вычтены из целевой оценки. Таким образом SLM в состоянии измерять даже «тонкие срезы» в результатах процесса (см. врезку «Сравнение подходов к измерению SLA»).

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

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

ПРОЗРАЧНОСТЬ И ИНТЕГРАЦИЯ

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

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

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

Еще один способ — сравнение своей платформы с другими (с такими же и иными приложениями, собственного производства или внешними). Платформа поставщика услуг по аренде приложений (Application Service Provider, ASP) позволит сделать это анонимно.

ОЦЕНКА КАК ЦЕННАЯ АЛЬТЕРНАТИВА МОНИТОРИНГУ

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

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

Ганс-Кристиан Боос — председатель компании Arago, Оливер Хайнц - руководитель направления системного управления и безопасности. С ними можно связаться по адресам: boos@arago.net; heinz@arago.net.

Сравнение подходов по измерению SLA

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

а) SLA: готовность на уровне 99% в год (24 ч в сутки, 7 суток в неделю), время реакции — 30 мин.

Готовность на уровне 99% означает максимальную продолжительность отказа приблизительно 7 ч в месяц или четверть часа в сутки. На первый взгляд такой отказ не составляет проблем, тем более что учитываются и ночное время, и выходные. Однако в пересчете на год длительность простоя равна 88 ч — без нарушения SLA. С точки зрения бизнес-подразделений это неприемлемо, поскольку в контракт постоянно придется вносить сложные добавления для согласования максимальной длительности отдельного отказа или никогда стопроцентно не гарантируемое время восстановления при практической эксплуатации ИТ. Мало того, один отказ центральной корпоративной базы данных длительностью в 2 ч в разгар рабочего дня влечет за собой более тяжкие последствия, чем отказ ночью или в выходные, — фактор, который игнорируется в SLA на базе готовности.

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

б) SLA: придерживаться первого класса оценки.

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

? AWi Verlag