• Новости
• Блоги
• Аналитика
• Новости компаний
• В СНГ и в мире
• Анонсы

Можно ли управлять эксплуатацией ЦОДа как ИТ-услугами

Насколько модель управления эксплуатацией ИТ-сервисов и заложенные в ней идеи применимы и полезны для управления эксплуатацией инженерной инфраструктуры ЦОДа?

На отраслевых конференциях, где дискутируется необходимость стандартизации управления экс­плуатацией, часто высказывается мнение, что для этих целей стоит использовать стандарты серии ГОСТ Р ИСО/МЭК 20000, основанные на библиотеке ITIL. Однако прежде всего нужно понять, в чем состоят принципиальные отличия операционной модели эксплуатации ЦОДа от набора процессов, рекомендованных стандартами серии ГОСТ Р ИСО/МЭК 20000.

Полное наименование русскоязычной версии части первой стандарта ISO 20000 звучит как «ГОСТ Р ИСО/МЭК 20000 Информационные технологии. Управ­ле­ние услугами. Спецификация». Как сказано во введении, «ГОСТ Р ИСО/МЭК 20000-1 способствует принятию в повседневной практике поставщика комплексного процессного подхода к эффективному предоставлению управляемых услуг, соответствующих требованиям бизнеса и заказчика». В главе 1 стандарта говорится: «ГОСТ Р ИСО/МЭК 20000-1 определяет требования к поставщику услуг с целью предоставления заказчикам поставщика управляемых услуг приемлемого качества».

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

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

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

Обработка ИТ-инцидента, связанного с отказом в инженерной инфраструктуре

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

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

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

Через полчаса ДГУ удалось запустить, еще примерно через час все прикладные системы функционировали в полном объеме. Служба поддержки проинформировала пользователей и закрыла инцидент. Подача электроэнергии на объект в полном объеме была восстановлена через 14 часов.

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

Отказ в инженерной инфраструктуре, который не привел к инциденту на пользовательском уровне

Если несколько модифицировать ситуацию, отношение к ней и выводы будут совсем другими. Допустим, все было так же, как в предыдущем примере, однако ДГУ удалось запустить в течение 15 мин (c энной попытки, выполненной вручную), и ИТ-системы выключать не пришлось. С точки зрения конечного пользователи и службы поддержки ИТ-услуг ничего не произошло, никакие инциденты зарегистрированы не были.

Но с точки зрения службы эксплуатации ИИ ЦОДа отказ все-таки был. Причем не один, а сразу два: во-первых, отсутствие поставки энергии от внешних сетей, во-вторых, трудности с запуском ДГУ. Оба эти события должны быть зафиксированы как отказы, и по ним должна быть проведена работа по устранению. Но поскольку инцидента с точки зрения ИТ-услуг вроде бы и нет, применимость процесса управления инцидентами, рекомендуемого для ИТ-услуг, ставится под вопрос. Конечно, можно расширить понятие «инцидент», дополнить процесс отдельной ветвью для именно такого типа событий… Но насколько это оправдано? Более простым видится путь формирования в рамках службы эксплуатации ИИ ЦОДа отдельного процесса, ответственного за обработку таких отказов. Конечно, он должен быть каким-то образом связан с управлением инцидентами, но именно связан, а не заменять его.

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

Роль процессов технического обслуживания в деятельности службы эксплуатации ИИ ЦОДа

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

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

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

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

Место вспомогательных процессов в деятельности служб эксплуатации ИИ ЦОДа

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

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

Особенности взаимодействия с потребителями услуг на разных уровнях

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

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

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

Предварительные итоги

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

Модель управления эксплуатацией ИТ-систем, изложенная в стандарте ISO 20000, ориентирована на управление предоставлением ИТ-услуг.

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

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

Существенно больший приоритет в ОМЭ ИИ ЦОДа отдан процессам обслуживания ввиду их критичности для надежного функционирования ИИ ЦОДа, а также существенной трудоемкости и ресурсоемкости.

ОМЭ ИИ ЦОДа включает в себя ряд вспомогательных по характеру, но при этом весьма значимых процессов, без которых карта процессов операционной деятельности будет неполной. К ним в первую очередь относятся процессы ресурсного обеспечения, в том числе обеспечения эксплуатации достаточными по численности и квалификации человеческими ресурсами, ЗИП и др.

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

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

*  *  *

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

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

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

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

Место инженерной инфраструктуры в предоставлении ИТ-услуг