Нормативная документация

Организация процесса построения ЦОД: практические заметки

09 апреля 2014 г. | Категория: Проектирование ЦОД

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

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

Итак, с чего начать? С идеи. А по­­чему бы и нет? Интегратор здесь дол­жен выполнить роль психолога: приехать к клиенту и поговорить о том, что он в итоге хочет получить от ЦОДа. Здесь важны две вещи: не формализовать процесс и не зарыться в детали. Формализация процесса обычно сводится к отправке клиенту кучки опросников и таблиц. Безусловно, это нужно делать, но только не на первой или второй встрече. Поэтому лучше разбивать большой опросник на несколько небольших и передавать их профильным специалистам компании-клиента. Емкие опросные листы с множеством технических подробностей обычно просто не заполняются, и тут виной всему человеческий фактор. Увы, факты — вещь упрямая, и по собственному опыту скажу, что универсальный опросник, включающий в себя все-все-все, заполняют не более 1–3 % клиентов. Обычно это выглядит так: высылаете, неделя-две потерянного времени, приезжаете и начинаете беседовать. Живое общение позволяет значительно сэкономить время, которого обычно и так нет: почему-то решение строить ЦОД принимается «на вчера», и клиент обычно год думает, как построить ЦОД за два месяца :).

Предварительная работа с клиентом

Установочная встреча состоялась, и дальше — работа пресейл-специа­листов и ключевых специалистов клиента. Важно, чтобы пресейл умел говорить на двух языках — языке финансистов и языке технического персонала. Пресейл — это своеобразный переводчик, способный понять потребности клиента и оценить, на какую сумму потянет проект и будет ли это выгодно клиенту. Более того, такой специалист решает дилемму, помогая рабочей группе клиента защитить бюджет просчитанного решения перед финансовым директором. Расчет таких показателей, как окупаемость инвестиций (ROI), общая стоимость владения (TCO), внутренняя норма доходности (IRR), период окупаемости (PP), позволит обосновать топ-менеджерам, почемунужен именно 1 миллион и недостаточно 200 тысяч, «чтобы айтишники успокоились и наигрались», а также учесть особенности финансирования и этапность инвестирования. В идеале здесь клиенту нужно представить хотя бы укрупненный инвестиционный план для понимания конечности затрат ЦОД и выбора модели его использования: будет ли это свой ЦОД, арендуемый коммерческий или «облачный» сервис. Обычно для корпоративного клиента это будет некий гибрид, в котором будут все три типа. В этом случае топ-менеджер понимает смысл всей затеи, финансовый директор — конечность затрат, а ИТ-директор — насколько ЦОД будет соответствовать потребностям бизнеса.

Еще одна важная деталь на данном этапе — не следует слишком увлекаться резервированием и фактором надежности. Часто бывает так: строительный департамент выбирает дублирование источников электроснабжения и кондициониро­ва­ния. ИТ-департамент дублирует ли­нии свя­зи и ИТ-оборудование, специалис­ты по бизнес-приложениям делают синхронную репликацию и «горячее дублирование» работающих узлов… В итоге цена зашкаливает, хотя каждый департамент в отдельности поступил правильно и максимально проработал свою зону ответственности. Поэтому при сравнении вариантов бюджетирования и описании концепции нужно опираться именно на сравнение вариантов под ключ. К тому же не стоит забывать, что при прочих равных стоимостях две площадки Tier III всег­да бу­­дут более надежными, чем Tier IV, ведь в этом случае уменьшает­ся стои­мость внешних рисков.

Выбор площадки

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

Особое внимание стоит уделить следующим вопросам:

1. Подвод коммуникаций.

Здесь стоит особо обратить внимание не просто на возможности подвода коммуникаций, а стоимос­ти проекта под ключ. Очень часто тех­ническая возможность есть, а вот стоимостная… То слаботочные ка­нализации надо копать или арендовать, то трансформаторную подстанцию (ТП) надо свою ставить и завязываться с 10 кВ. Поэтому не стоит соблазняться на разговоры и обещания, пока нет валидных технических условий на подключение. Они хотя бы позволят гарантировать, что в рамках временного промежутка (обычно одного года) затраты не вырастут. Отдельно желательно проинспектировать независимость энерговводов. Как показывает практика, велика вероятность во время этой процедуры получить неприятный сюрприз: узнать, например, что два ввода тянутся от одной подстанции. По каналам связи: учитывайте, что их должно быть несколько и тянуть их желательно разными трассами. Темное волокно идеально, но чрезвычайно дорого. Коммутируемые линии связи, которые проходят между разными провайдерами, — дешево, но сердито: в случае аварии время даунтайма может быть непрогнозируемо. Поэтому золотая середина — канал связи от одного провайдера, который владеет всей сетью из точки А в точку Б (особенно это касается связи между основным и резервным ЦОДами).

2. Расположение ЦОД.

Есть несколько важных моментов:

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

б) Наличие достаточной нагрузки на перекрытие и конструкции стен. Стоит ли говорить, что оборудование на­до не просто занести и пос­та­­вить — его еще нужно и довезти. Поэтому обращаем внимание на то, какая наг­рузочная способность перекрытий по путям транспортировки (прова­лен­ный фальшпол, раздробленная плит­ка и т. д. совсем не добавят удобства при эксплуатации, когда ЦОД уже будет построен). Наконец, тре­буется архитектурная экспертиза зда­ния «на сегодня». Часто она есть, но 15-летней давности. Конечно, мож­но экстраполировать и гадать на ко­фейной гуще, но стои­мость рисков зна­чительно выше, чем стоимость такой экспертизы. Что касается стен — здесь важно, сколько на них можно наг­рузить, ведь кабельные эстака­ды, на­весные щиты при проектировании для экономии площади проще повесить на стену.

в) Высота помещения. Не стоит забывать, что в ЦОД надо не просто поставить шкафы, а сделать еще и многоэтажные кабельные трассы элект­рики и слаботочки, поэтому высота лишней не бывает. Особенно если планируются шкафные кондиционеры с выдувом под фальшпол — решение простое, недорогое и при правильном расчете позволяющее отвести до 15 кВт со шкафа (в теории можно и больше, но жалко объема помещения). Так на какую же величину стоит ориентироваться? Эмпирика показала: 4,5 метра. Но уж точно не меньше трех метров.

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

д) Организация подъезда к ЦОДу. Есть ли возможность прямого подъезда автопоезда к воротам ЦОД? Возможно ли организовать выгрузку напрямую из прицепа в здание?

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

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

Взаимодействие команд интегратора и клиента

Не будем дублировать PMBook — остановимся на основных моментах. Назначение людей, выделенных со стороны интегратора и клиента, должно быть закреплено приказами с соответствующей четкой документацией, в которой будут прописаны их зоны влияния и ответственности. Руководителю проекта со стороны интегратора крайне полезно создать устав проекта и на первой же встрече зафиксировать матрицу ответственности (часто ведь как бывает: принимают решения одни люди, а отвечают за эти решения другие). В этой матрице должны быть перечислены и контактные данные каждого участника, чтобы с ними было просто связаться. С одной стороны, аргумент, что «нам надо спешить, некогда тратить время на ерунду». Но устав проекта — достаточно полезная штука. В нем фиксируется формат документов, которыми будут обмениваться участники, периодичность встреч, порядок со­г­ласования принятых решений. Хороший устав проекта — это документ, который можно дать новому члену команды, и после его прочтения он сможет полноценно включиться в работу, зная свою роль в данном процессе.

Основные моменты, на которых стоит заострить внимание:

1. Найти нужных людей, определить реальные роли в проекте. Как найти нужного человека? Ответ прост. Попробуйте его мысленно убрать — что-то изменится? Если нет — этот человек не нужен. Проект ЦОД не требует большой постоянной команды, поэтому лучше не включать в основной состав более 5–7 человек с каждой стороны.

2. Человек противится переменам, пока не почувствует себя в безопасности. Поэтому не стоит удивляться, что, как правило, команда людей со стороны клиента более консервативно настроена. Это нормально, ибо их задача — не просто построить ЦОД, но еще и жить с ним, потому любые революционные решения встречаются настороженно: продукт сырой, статистики отказов нет, каков он в эксплуатации — непонятно... Это не значит, что новые продукты не стоит внедрять — просто их внедрение потребует более детальной проработки, в том числе с клиентом.

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

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

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

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

7. Спецификацию, в которой нет спис­ка входящей и исходящей информации, даже не следует принимать во внимание. Поэтому работать по чьей-то спецификации или спе­цификации, посчитанной «одной известной компанией», не стоит, если нет понимания, какое техническое задание ставилось. Общий совет для руководителя проекта со стороны клиента: прежде чем заказывать проект у сторонней компании и после этого проводить тендер на внедрение, задайте вопрос, кто выступит аудитором качества такого проекта? Не будут ли это зря потраченные время и деньги? Общий совет для руководителя проекта со стороны интегратора: не утешайте себя тем, что вы просто поставите цены в специ­фикации чьего-то проекта, и весь риск ляжет на плечи клиента. Это не так, ведь, скорее всего, в договоре клиент захочет получить не расчет монтажа материалов, а работающую сис­тему, которая обладала бы рядом параметров. А значит, отвечать все равно будет интегратор, выполняющий внедрение.

8. Если в проекте участвует большая команда, это снижает эффективность самой ответственной части работы — определения концепции ЦОД (ведь всем надо побыстрее дать работу), что приводит к потере независимос­ти внутри команды, увеличению числа собраний и совещаний. Поэтому придерживайтесь следующего принципа: сначала маленькая команда, после концепции — подключение новых игроков. Очень часто доводилось наблюдать, когда на первое же совещание приезжает 30–40 человек, которые пытаются обсудить все и сразу, разбиваются на группы, что-то обсуждают и… уезжают. После этого во время формирования общего протокола возникает конфронтация — и все опять собираются. И так до бесконечности. Определите ключевых сотрудников (со стороны клиента это обычно ИТ-ди­ректор, со стороны интегратора — Руководитель проекта), а остальных подключайте по мере необходимости. Эмпирически оптимальная группа, с которой еще можно решать вопросы, — это группа до 10 человек.

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

Проектирование

Прежде чем начать проектирование, нужно определиться с техническим заданием (ТЗ) и согласовать его с клиентом. Хоть это и должен делать клиент, выскажу свое скромное мнение: это все-таки должен делать интегратор совместно с клиентом. Почему? Да потому что именно интегратор более компетентен: у него больший опыт и подчас больше понимания, что нужно клиенту. В ТЗ обязательно фиксировать не общие фразы (наподобие «система кондиционирования долж­на поддерживать температуру в сервер­ной в пределах рекомендованной произ­водителем ИТ-оборудования»), а конкретику, нап­ример: обеспечить температуру воздуха на воздухозаборниках ИТ-оборудования в шкафу в пределах +20...24 °С круглосуточ­но в любое время года.

Далее вкратце затронем последо­вательность процесса проектирования и основные вопросы, на которые стоит обратить внимание.

Важна фиксация в ТЗ двух ключе­вых величин: количество этапов и мощность ИТ-оборудования на пер­вом этапе. Неоднократно доводи­лось наблюдать, как при расчетном PUE в 1,4–1,7 на первом этапе оно равнялось двум-трем именно по той причине, что первая стадия ИТ-оборудования составляла 1/10 от той, что была указана в ТЗ. Если есть спецификация ИТ-оборудования и понимание этапности его закупки, которое планирует­ся устанавливать, не поленитесь и расставьте его в стойки. Тогда будет понимание и того, какая мощность на стойку требуется реально, сколько портов структурированной кабельной системы (СКС) и каких именно понадобится, какие разъемы питания потребуются на блоках распределения питания в шкафах.

Далее прорабатывается общая кон­цепция: компоновка помещений, размещение крупноузлового оборудования, проходы, зоны обслуживания оборудования. Часто встает та­кая за­дача: есть мощность 1000 кВт от транс­форматорной подстанции (ТП) — как ее разделить? Делим просто: обычно PUE составляет 1,6–1,8. Соответственно, задаем PUE 1,6 на начальном этапе для ИТ-оборудования, оставляем мощность 625 кВт, для остального оборудования (а это в основ­ном кондиционирование) — 375 кВт. Далее рассчитываем зоны ИТ-шкафов. Не за­бываем, что крайне желательно физически разделить помещение ввода, зоны серверов, стоечных Hi-End (так как часто им нужна специфическая организация охлаждения, которая может отличаться от типового в серверной) и коммутационной зоны (мощность которой обычно значительно ниже, чем серверной зоны).

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

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

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

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

Внедрение

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

1. Работа под реконструкции помещений, перенос/возведение стен, выполнение проемов для прохода коммуникаций, расширение дверных проемов, выполнение наружных работ по прокладке кабельных каналов, заливка фундамента для дизель-генераторов и баков топливохранилищ, прокладка топливопроводов, прокладка наружных коммуникаций к зданию ЦОД, выполнения заземления и молниезащиты. При необходимости — выполнение электромагнитного экранирования сер­верного помещения.

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

3. Установка плит фальшпола, установка внутренних блоков кондиционирования, установка шкафов, установка щитов и ИБП в щитовой, установка ДГУ.

4. Монтаж СКС, монтаж АГП, СКД, видеонаблюдения, освещения, оборудования мониторинга и автоматики.

5. Проведение измерений, испытаний, стартап оборудования инженерных сис­тем, пусконаладка.

Сдача в эксплуатацию и сервисное обслуживание

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

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

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

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

Константин Коваленко

Источник: журнал ЦОДы.РФ, февраль 2013, № 02

Теги: построение ЦОД, проектирование ЦОД