Бесперебойность ЦОД и SLA

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

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

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

Бизнес, выходя на определенный уровень зрелости, должен задать вопрос о гарантиях бесперебойности. Многие отраслевые стандарты прямо требуют наличия программы BCM , которая должна учитывать риски аварий инфраструктуры, в том числе и при аутсорсинге. Ключевые показатели способности к бесперебойному оказанию услуг должны быть зафиксированы в SLA оператора ДЦ, а программа непрерывности клиента должна содержать мероприятия, основанные на оценках остающихся рисков.

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

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

Базовое требование

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

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

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

Для начала изучим "противника".

Аварийные отключения

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

Плановые отключения

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

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

Для плановых отключений как раз вполне адекватным представляется обычный метод компенсации «за сверхплановый простой», только не нужно на плановый простой отводить «8 минут в месяц» вместо «96 минут в год» (96/12=8). За 8 минут провести обслуживание не получится, да и ежемесячные плановые отключения в ДЦ Tier 3 по TIA-942 – нонсенс.

Возможна ли «СТРАХОВКА ОТ АВАРИЙ»

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

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

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

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

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

Именно поэтому не сработает вариант «очень большой компенсации». Казалось бы, если оператор ДЦ назначил за аварийное отключение компенсацию порядка годовой платы, то для клиента это стало бы гарантией, что они «в одной лодке» и оператор приложит все усилия для бесперебойной эксплуатации. Но что это означало бы на практике? 

Даже в лучшем ДЦ аварии случаются. Предположим, что системы ДЦ имеют уровень надежности примерно в одну аварию за три года. Эта авария может случиться и в первый год, и во второй и в третий. Вероятность того, что в первый год произойдут две аварии, а потом пять лет не будет ни одной тоже не нулевая – около 1,5%. Назначив «разорительную» компенсацию мы получим следующее:

  1. Оператору нужно существенно поднять расценки. Ведь раньше или позже компенсацию придется платить.
  2. Возникает значительный риск полного разорения оператора ДЦ. Пара аварий подряд и всем клиентам надо искать новый ДЦ, т.к. этот идет с молотка.
  3. Если случилась авария, то нужно найти ее причины и принять меры, чтобы не допустить повторения. Но меры, как правило, требуют расходов, а бюджет оператора ДЦ как раз получит сильнейший удар в виде «большой компенсации». После такого удара оператор наоборот начнет экономить на техническом обслуживании.
Таким образом, вместо повышения уверенности в стабильности, мы получили «казино». Причем не очень понятно, что клиенту делать с такой компенсацией? Может ли солидная компания заложить в свой бюджет строку «компенсация за аварию в ДЦ, вероятность 1/3»?

Опыт современной индустрии

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

Стабильность процессов

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

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

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

Бесперебойность в ДЦ

Попробуем взглянуть на ДЦ как на смежника, который «поставляет» свои услуги на «конвейер» основного бизнеса клиента, а бесперебойность – основной показатель бездефектности. На чисто практическом уровне, не пытаясь строго соответствовать канону процессного управления, выделим следующие процессы, непосредственно влияющие на бесперебойность:

  • проектирование инженерных систем,
  • поставка, монтаж и испытания инженерных систем,
  • текущая эксплуатация оборудования инженерных систем,
  • модернизация и ремонт инженерных систем.

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

Проектирование инженерных систем

Клиент, как правило, не стоит за плечом у проектировщиков, но он может положиться на следующее:

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

Поставка, монтаж и испытания инженерных систем

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

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

Текущая эксплуатация оборудования инженерных систем

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

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

Модернизация и ремонт инженерных систем

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

Представляется, что на эту тему оператор может продемонстрировать клиенту следующее:

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

Пункты для SLA

Что из приведенного выше можно внести в текст договорных документов (SLA)? Пожалуй, нет смысла фиксировать в SLA прошлое. Если ДЦ уже спроектирован и построен, то часть документации проекта может быть предоставлена потенциальному клиенту до подписания контракта, и в договоре достаточно указать площадку (может быть с указанием зала, очереди строительства и т.п.) с проектными особенностями которой клиент был ознакомлен и согласился.

В договоре стоит указывать те особенности, которые будут реализованы или могут изменяться в период его действия:

  • Политика раскрытия информации. Например, клиент может иметь право в любой момент заглянуть в журналы обслуживания оборудования и сверить выполненные мероприятия с планом. Клиенту можно сделать доступным ключевые результаты испытаний по принятому в эксплуатацию оборудованию.
  • Доступность для анализа статистически значимых массивов данных технологического мониторинга.
  • Право клиента провести аудит деятельности по обеспечению надежности, с указанием объема, порядка назначения сроков, ограничениями по частоте и времени.
  • Обязательства оператора ДЦ провести независимый аудит и предоставить его материалы.
  • Ключевые характеристики инженерных систем, применяемого оборудования, соблюдение которых клиент может проверить («источники бесперебойного питания в конфигурации n+1», «утилизация мощности инженерных систем не более 80%», «запас топлива на площадке на 48 часов непрерывной работы на 100% мощности» и т.п.)
  • Обязанность оператора продемонстрировать по запросу наличие определенного оборудования для испытаний.
  • Ключевые моменты по обеспеченности персоналом, которые могут быть продемонстрированы по требованию («круглосуточное дежурство инженера с соответствующей квалификацией» и т.п.)
  • Право клиента запросить у сервисных организаций подтверждение того, что соответствующий контракт заключен и выполняется. Право клиента запросить у поставщика оборудования подтверждение того, что оборудования было должным образом введено в эксплуатацию.
  • Ключевые параметры процедуры уведомления о работах, плановых отключениях, действий в аварийных и неотложных ситуациях.

В SLA, конечно же, войдут ограничения на плановые отключения, нормативы по скорости ответа технической поддержки и другие параметры. Это тот слой, который превращает надежный сервис в отличный. Но эта тема, как общая для всех ИТ-услуг, хорошо раскрыта в отраслевых стандартах ISO 20000 (ITSM).

Автор: Михаил Золоторев, менеджер проекта 

Публикация по материалам статьи: ИКС 08-09.2013
Получить консультацию специалиста
Персональный ассистент
Cloud.Xelent