Rambler's Top100
Статьи ИКС № 12 2013
Павел КОСТЮРИН  10 декабря 2013

Минимизация рисков в сервисных контрактах

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

Павел КОСТЮРИН, директор департамента сервиса и аутсорсинга, «АМДтехнологии»Что нужно учесть при планировании сервисных мероприятий и выборе сервисной организации для заключения договора на обслуживание инженерной инфраструктуры дата-центра?

Какой уровень сервиса выбрать?

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

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

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

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

Написание ТЗ

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

Несмотря на то что есть нормативные документы, регламентирующие содержание ТЗ, например ГОСТ 34.602, советую руководствоваться принципом: чем подробнее описание обслуживаемой системы, спецификации оборудования, чем четче сформулированы требования к услугам, тем лучше.

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

Разделы технического задания:

  • Общие сведения.

  • Цели предоставления услуг.

  • Требования к исполнителю.

  • Спецификация и характеристика оборудования (обязательно укажите адрес его размещения).

  • Требования к сервисному обслуживанию:

    •  требования к обслуживанию в целом;

    •  SLA (о том, что необходимо включать в соглашение об уровне сервиса см. в «ИКС» № 05’2013, с. 91);

    •  требования к квалификации персонала исполнителя.

  • Состав и подробное содержание работ (список регламентных работ по системам, их периодичность и т.д.).

  • Порядок контроля и приемки выполненных работ.

  • Регламент взаимодействия исполнителя с заказчиком (с таблицами эскалации).

  • Требования к документированию и отчетности.

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

Выбор исполнителя

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

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

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

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

Построение взаимоотношений с исполнителем в работе по контракту

Не забывайте о важности согласования подробного плана работ как для регламентного обслуживания, так и для восстановительных работ после нештатной ситуации. Представьте, что в вашем ЦОДе запланированы регламентные работы на дизель-генераторной установке, которые помимо всего остального включают в себя замену охлаждающей жидкости и сезонную смену топлива в баке. В случае пропадания внешнего электропитания ИБП смогут поддерживать работу ЦОДа не более 15 мин. А при слитой охлаждающей жидкости и пустом баке на то, чтобы запустить ДГУ, потребуется более получаса. Не имея плана проведения этих регламентных работ с соответствующими временными интервалами, вы не сможете оценить риск, который грозит вашему дата-центру в случае пропадания питания от городской электросети. Вы дадите согласие на такие работы? А если минута простоя ЦОДа стоит миллион долларов?

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

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

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



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

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

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

  • список авторизованных контактных лиц со стороны заказчика и исполнителя. Описание функционала всех линий поддержки исполнителя;

  • информация о том, каким образом размещается новая заявка: какие данные необходимо указывать при ее размещении, каким образом присваивается приоритет и т.д.;

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

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

  • таблица функциональной эскалации;

  • таблица иерархической эскалации.

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

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

Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!