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

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

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

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

Ориентировочная работа с заказчиком

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

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

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

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

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

1. Доставка коммуникаций.

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

2. Размещение ЦОД.

Есть несколько значительных факторов:

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

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

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

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

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

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

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

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

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

Главные факторы, на которых стоит заточить внимание:

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

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

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

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

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

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

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

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

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

Конструирование

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

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

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

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

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

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

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

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

Введение

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

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

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

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

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

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

Сдача в работу и гарантийное обслуживание

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

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

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

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

Коваленко