Инженерная инфраструктура центров обработки данных (ЦОД)

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

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

Источники ошибок, приводящие к краху проекта ЦОД

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

Используйте опыт управления проектами при создании ЦОД

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

Основные ошибки при работе над сложными проектами

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

     Основными ошибками при работе над сложными проектами являются:

• Ошибки, связанные с персоналом разработчиков проекта и получателей услуг проекта;
• Ошибки, связанные с нарушением процесса выполнения проекта;
• Ошибки, связанные с запуском новых продуктов;
• Ошибки, связанные с внедрением новых технологий.

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

Ошибки, связанные с персоналом разработчиков проекта и получателей услуг проекта

В эту группу попадают ошибки связанные с:

• Неверной кадровой политикой;
• Отсутствием мотивации;
• Отсутствием инициативности у исполнителей;
• Отсутствием коммуникационной культуры.

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

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

     Основными ошибками связанным и с персоналом при выполнении проектов являются:

• Отсутствие адекватной мотивации. Не обязательно денежной, но и моральной, а также возможности самореализации;
• Неверный выбор руководителя проекта. Обычно происходит при автоматическом назначении на эту должность лица имеющего наивысший административный статус, а не наиболее компетентного в этой области сотрудника;
• Создание нервозных отношений в виду частых проверок, мелкой опёки и не учёта всех мнений в коллективе. Постоянный прессинг в любом коллективе ведёт к оттоку из него наиболее ценных специалистов. В своей книге «Slack» («Слабина»), Том ДеМарко раскрывает классические проблемы Менеджмента и поясняет, как послабление помогает организациям быть более адаптируемыми и даже более эффективными. ДеМарко описывает, что для большей эффективности людям нужно 20% времени для бездействия во время рабочего дня. Яркий пример Google – Android, Chrome и все другие программы, не относящиеся к поиску, задумывались и на первом этапе разрабатывались во время этих 20%. Незаинтересованный исполнитель и на работе думает о домашних делах, а заинтересованный и дома думает о работе. Убив мотивацию и заинтересованность в положительном результате у исполнителей, кроме того, что руководитель получит безынициативных исполнителей, он реально лишиться не менее 50% реального времени работы исполнителей, хотя и не на рабочем месте. И вместо 20% увеличения отдачи за счёт принудительной 100% загрузки, от сотрудников нельзя будет получить и 50% от их потенциала. На конечный результат влияет и метод при помощи которого пытаются этот результат получить. Перекос в сторону использования в основном метода «Кнута» даёт всегда меньший эффект, чем использование в основном метода «Пряника». Существует даже такое понятие, как «Культура страха». Если в своих характеристиках она дошла до уровня: «Силе позволено превосходить здравый смысл…». Всё… уже не только никакой сложный проект реализован не будет, но и не будет, ни какой реальной перспективы у коллектива, т.к. наверх будет уходить только информация, которую хотят услышать, не отражающая реального положения дел, а все функционирующие и развивающиеся системы без обратной связи, (а точнее с искажённой обратной связью) не работоспособны.
• Конечно, ещё могут быть и трения между Заказчиком и Исполнителями, но в большинстве случаев они преодолимы. Просто при общении нужно постараться договориться о степени открытости ведущихся работ. Т.е. сразу заявить, что Заказчик не побежит при первых же проблемах у Исполнителей менять их и что в случае необходимости специалисты Заказчика окажут посильную помощь. Т.к. и Заказчик, и Исполнители одинаково заинтересованы в успешном окончании проекта, то очень большая вероятность, что общий язык они вероятнее всего найдут.

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

Ошибки, связанные с нарушением процесса выполнения проекта

Иногда проект изначально содержит больше требований, чем требуется. При этом на выполнение большого количества «лишних» требований тратятся силы и средства. Ещё в 1800–х гг. Вильфредо Парето открыл, что маленькая часть любого действия производит большинство результатов. Теперь это называется правилом 80/20, или же принципом Парето. Согласно этому принципу выделив важнейшие 20% из всего объёма проекта и выполнив их, вы уже получите 80% выгод от проекта, если же после выполнения проекта сосредоточиться на доработке только его важнейших частей, то это существенно увеличит результаты проекта. А лишние требования из ТЗ всё равно нужно исключать, для этого и желательна доработка окончательного ТЗ Заказчиком и Исполнителями совместно.

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

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

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

     Если цель проекта чётко не обозначена и проект требует новых методов — это скорее уже не проект, а исследование. О соблюдении графика в таком случае, можно забыть – нечёткие требования и недостаточная квалификация специалистов часто ставят такой проект под угрозу срыва. Часто такая ситуация бывает при попытке внедрить нововведения при работе над проектом. В этом случае, несмотря на то, что специалисты без этих нововведений смогли бы выполнить работу в срок, изменения в порядке отчётности и вероятные проблемы при планировании этапов могут несколько задержать окончательные сроки.

Основные правила создания успешных IT-проектов

Показав основные ошибки при реализации IT-проектов, которые чаще заканчиваются полной или частичной неудачей (согласно последним опросам компании Accenture), всего 29% ИТ-проектов считаются успешными и в среднем 56% превышают бюджет, а 84% выполняются не в срок, я постараюсь перечислить правила, выполнение которых поможет проекту оказаться в тех 29% проектов закончившихся успешно.

     Разные авторы дают различное количество этих правил. Обычно их количество варьируется от 6 до 10. Существует документ, в котором приводится целых 100 правил и из них 80% попадает под определение «Общие правила реализации успешных проектов». Но, безусловно, можно реально количество основных правил создания успешных проектов свести к меньшему количеству.

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

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

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

     Основные правила для создания успешных IT-проектов в том виде как я их определил для себя.

1. Определяй наиболее важные требования. При разработке любого сложного проекта (создание ЦОД, да и просто создание большой серверной, действительно сложный проект) требуется взаимоувязка между всеми его частями. Это проще сделать, написав как минимум раздел по основным техническим (и не только) характеристикам, а так же краткое описание всех наиболее важных в проекте технологических процессов и описав основные взаимосвязи между элементами системы. На самом деле это подразумевает выполнение Эскизного проекта, то, о чём многие просто забывают. Конечно, всё это было в ГОСТ 34.601-90, но кто же сейчас его исполняет?
2. Сомневайся во всём. Большинство документов регламентирующих построение ЦОД в действительности жёстко не регламентируют его построение. Часто они построены на основании опыта уже построенных объектов. Точные задачи и ограничения при построении этих объектов обычно не известны, поэтому было бы неразумным переносить бездумно чужие решения на свой ЦОД. Кроме того нужно давать себе отчёт, что копирование полностью чьих-то решений или следование общим рекомендациям просто будет дороже и может создать проблемы при дальнейшей модернизации. Поэтому каждое решение должно проверяться на целесообразность применения в вашем конкретном случае.
3. Ищи решения от задач стоящих перед проектом. Часто основным аргументом различных «горе»-разработчиков или поставщиков является: «так это же более мощное (современное, универсальное и т.д…) решение». На самом деле правильным аргументом должно быть – Это сбалансированное решение по техническим характеристикам и экономической целесообразности для решения задач стоящих перед проектом, с учётом возможности дальнейшего расширения и удобства в обслуживании. О необходимости сбалансированного решения я расскажу при объяснении следующего правила, а сейчас только добавлю, что ограничение круга основных задач, поможет ограничить и круг возможных решений.
4. Применяй только сбалансированные решения. Решения должны быть сбалансированы по техническим и экономическим показателям. Технические показатели обычно явно прописаны в ТЗ или Эскизном проекте. С экономическими показателями сложнее, т.к. борясь за экономическую эффективность, обычно теряешь в технических параметрах. Некоторые показатели легко задать, но сложно обеспечить (во всяком случае, рекомендованными методами). Например, показатели эффективного использования энергии в ЦОДе — Коэффициент PUE и ее обратная величина, DCiE которые определяются следующим образом: PUE = общая мощность оборудования/мощность ИТ-оборудования DCiE = 1/PUE = мощность ИТ-оборудования/общая мощность оборудования x 100%. Показатели пытаются представить их чуть ли не основными, для многих категорий ЦОД, и за их улучшение борются. Вся пикантность ситуации заключается в том, что лучшие показатели имеют только ЦОДы, у которых очень мало электроэнергии тратится на охлаждение, т.е. заведомо аппаратура перегревается (что вполне допустимо в целом ряде случаев). Сами показатели должны быть выбраны приблизительно для одного уровня, т.е. делать полное резервирование, если у вас очень ненадёжная сеть, нет второго ввода от другого поставщика энергии и нет генератора, просто нерациональный перевод средств.
5. Применяй по возможности универсальные решения. В этом случае, при дальнейшем развитии, будет больший выбор поставщиков, и решение будет более дешёвым. Вообще заранее (на этапе ТЗ) привязываться к какому-то решению, это заведомо уменьшать круг Исполнителей, а значит, такой подход приведет к удорожанию проекта. Обоснована привязка к конкретному решению, только в строго определённых случаях. И в большинстве случаев уже на этапе Эскизного проекта (ещё один аргумент в пользу этого этапа) можно обоснованно определиться с решением, но не на этапе ТЗ.
6. Проектируй как можно проще. Используй принцип бритвы Оккама «Не следует множить сущее без необходимости». В применении к нашему случаю это будет соответствовать интерпретации Оккама Альбертом Эйнштейном «Все должно быть сделано как можно проще, но не слишком просто». Масштабные технические задачи требуют сложных решений и трудно управляются. Разбиение сложного проекта на несколько различных, меньших по сложности, позволяет повысить управляемость, задание для более простого проекта можно более точно сформулировать, а в случае изменения технических требований, проще внести изменение в исполняемый и тем более в частный проект, который может по срокам начинаться даже позже.
7. Уделяй внимание мелочам. На самом деле принцип «В сложном деле мелочей не бывает» на практике нарушается очень часто. В некоторых случаях это проходит без последствий, но в большинстве это не так. Достаточно сложно представить к чему может привести небольшое отклонение в ходе проектирования, или на этапе эксплуатации. Дело ещё более осложнится, если таких мелких отклонений будет несколько. Поэтому рекомендуется в проекте не опускать некоторые несущественные моменты, исходя из того, что они очень несущественны и, скажем, на этапе эксплуатации и так будет всё ясно, либо можно будет потом при наличии свободного времени подправить, или уточнить. К сожалению «потом» обычно не наступает и какой-то из, казалось бы, несущественных вопросов оказывается не раскрыт. Последствия этого могут быть весьма не приятны. Особенно рекомендуется перед сдачей проекта посмотреть, не остались ли нераскрытыми, казалось бы, не существенные вопросы. Этот принцип, казалось бы, противоречит известному принципу Парето изложенному далее, но только на первый взгляд.
8. Старайся сконцентрироваться на наиболее важных сторонах проекта, т.к. известно маленькая часть любого действия производит большинство результатов. Теперь это называется правилом 80/20, или же принцип Парето. Осознание того, что 20% действий вызывает 80% результата, отнюдь не предполагает, что вы сконцентрируете все силы на работе с важнейшими характеристиками вашего проекта, и спустя рукава будете выполнять все остальные работы. Знание принципа Парето просто должно заставить вас предварительно провести анализ наиболее важных для успешного функционирования ЦОД задач, попытаться исключить, или ограничить круг несущественных. Но после проведения этой работы всё равно необходимо выполнять её, учитывая все мелочи. Следование этому принципу позволит существенно уменьшить объём работ, без ущерба их качеству.
9. Старайся создавать системы работоспособные при наихудшем развитии событий. На самом деле при глубоком анализе практически для всех ЦОДов можно найти ситуацию, когда при стечении нескольких обстоятельств, они станут неработоспособны. Конечно, нельзя проявлять паранойю, т.к. вероятность такого совпадения крайне мала, но мировой опыт учит, что если неблагоприятное событие может произойти, оно обязательно произойдёт. Надо ещё добавить — произойдёт в самый неблагоприятный момент. Поэтому устойчивость к воздействию нескольких неблагоприятных факторов, а так же различных их сочетаний должна обеспечиваться средствами, заложенными ещё на этапе проектирования. Для разных Уровней ЦОД эти последствия могут быть различны (или их может не быть вообще), но проверка надёжности при сочетании нескольких возможных сбойных ситуаций должна проводиться. Лучше если она проводилась практически и до сдачи проекта. Отсюда вытекает ещё одно правило.
10. До сдачи проекта проводи хотя бы 2 раза его бета-тестирование. Данное правило относится не только к разработке ПО, но и другим компьютерным проектам. Помните — что неудача это ошибка, которую вы не можете исправить. В сложном проекте необходимо всегда предусмотреть контрольные точки, при достижении которых нужно проверить, что же получилось. В этом случае ещё возможно внести корректирующие изменения в проект. По возможности при разработке сложных проектов необходимо проводить тестирование после разработки каждой его части. Конечно, это на практике трудноосуществимо, т.к. требует использования специальных методов проектирования, а одно только обсуждение плюсов и минусов такого подхода заняло бы больше места, чем настоящий документ. Поэтому обычно тестируют достаточно независимые аппаратные части или ПО. Но на тестирование всей системы обычно выходят на заключительном этапе, и не факт что система проходившая тестирование всех своих частей, при объединение в единое целое также удачно пройдёт и это тестирование. Прохождение бета-тестирования 2 раза объясняется просто. При первом тестировании выявляется обычно большое количество ошибок и не согласованностей. Процесс исправления ошибок – это не только исправление найденных ошибок, но и внесение новых. После 2-го тестирования их количество снижается до приемлемого уровня (но, к сожалению, не снижается до нуля).
11. Внимательно продумай удобство эксплуатации системы. Эксплуатация системы вносит существенный вклад в обеспечение надёжного функционирования. И если обслуживание неудобно (например, для устранения некоторых неисправностей требуется остановка ещё каких-то устройств или не дай бог строительные работы), далеко находится ЗИП, или в нём вообще отсутствуют критически важные запасные части, то говорить о надёжности функционирования ЦОД не приходится. Эксплуатационные документы должны разрабатываться с не меньшим старанием, чем Рабочий проект.
12. Разрабатывай проект, учитывая перспективу дальнейшего развития. Исследования Uptime Institute показывают, что жизненный цикл инженерной инфраструктуры ЦОД в среднем колеблется от 8 до 15 лет. Срок же службы серверов реально 2-3 года, да и активного сетевого оборудования не намного больше. Несмотря на все старания, среднее потребление одной стойки каждый год возрастает. Первое время ещё можно решить часть проблем по производительности и по охлаждению простым добавлением устройств (если ЦОД это позволяет). Затем придётся увеличивать производительность путём постепенной замены оборудования. Безусловно, это должно быть предусмотрено в проекте, в противном случае ЦОД не оправдает затраченных на себя денег. Поэтому логично оставлять около 20% запаса вычислительной мощности в резерве, даже если создаётся ЦОД для «внутреннего пользования», т.е. уровень вычислительной мощности известен. У коммерческих ЦОД всё сложнее и уровень используемой, в какой-то момент мощности определяется количеством договоров с ЦОД и требованием необходимых вычислительных ресурсов клиентам. Во всяком случае, для безболезненной модернизации ЦОД желательно изначально соответствие уровню 3.

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

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

Невозможность реально получить точные цифровые показатели надёжности ЦОД

Говоря «ЦОД» обычно приходят ассоциации с его надежностью. «Режим работы 24/7», «полное дублирование аппаратуры или целых подсистем», «пять девяток», и т.п. Вот, что приходит в голову, если основной задачей ЦОД является обеспечение надёжного хранения, обработки и передачи данных и информации. Но, как оказалось, вопрос надежности ЦОД настолько малоизученный, что невозможно количественно оценить надежность, а значит и обосновать выполнение различных требований.

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

1. Наработка на отказ (MTBF) отдельных компонентов ЦОД предоставляемая производителями существенно завышена. Она должна браться не у производителя, а у специальных независимых лабораторий по результатам испытаний.

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

2. Нет общепризнанных методик расчета надежности резервируемых структур, подходящих ко всей структуре ЦОД в целом, включая резервные ЦОД, вычислительные кластеры, СХД, телекоммуникационное оборудование. Производители аппаратуры не показывают подробного описания испытания своего оборудования. Многие операторы дата центров скрывают отказы и простои своих ЦОДов. И правда, какой уважающий себя поставщик услуг скажет об отказах, если из-за этого оно может потерять свою репутацию и клиентов?
3. Рассматривая вопросы надёжности, часто используют статистику отказов предыдущих моделей. При этом спокойно перенося нужное количество девяток на новые модели, хотя новые модели могут иметь большие отличия от предыдущих. Стоит заметить, что некоторые материалы по этой теме всё же встречаются в Интернете. Например, в 2007 году компания Google обнародовала исследование надёжности 100 000 дисков. Можно посмотреть более свежие данные, правда уже не от Google, приведённые в http://www.tomshardware.com/reviews/ssd-reliability-failure-rate,2923-3.html, хотя в этом случае говорить о надёжности, анализируя только количество возвратов, не совсем корректно.

4. Всё это приводит к тому, что Исполнитель из ТЗ с заявленными заказчиком требованиями к надежности проектируемой системы берёт необходимые цифры, а затем приводятся «удобные» модели исходя из формул расчета последовательно-параллельных структур добиваясь получения нужного результата.

   Поэтому, в большом количестве случаев, все цифры по надежности ЦОД и его компонентов получаются по следующему принципу: «Если вас не удовлетворяет результат, то мы пересчитаем по-другому, даже не меняя оборудование, и всё с надёжностью будет в порядке». Такой расчёт, а правильнее сказать получение «среднепотолочных» цифр, совершенно не совпадает, с тем, что будет на этапе эксплуатации. Тем более все результаты обычно рассчитываются без учёта влияния «человеческого» фактора, вызывающего до 70% сбоев. Также не учитывается реальное время восстановления работоспособности элементов ЦОД. Поэтому при расчёте показателей надёжности, исходя только из технических характеристик оборудования, мы в любом случае получим завышенное значение коэффициента готовности, т.к. на этапе эксплуатации ошибки будет вносить «человеческий» фактор.

Замечания по оценке катастрофоустойчивости

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

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

Требования к основным элементам ЦОД

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

     Если рассматривать ЦОД как совокупность комплексов, подсистем и других организационных единиц, то современный ЦОД включает в свой состав:

1. Серверный комплекс ЦОД;
2. Хранилище данных ЦОД;
3. Сеть передачи данных ЦОД;
4. Инфраструктуру ЦОД;
5. Систему управления ЦОД;
6. Организационную структуру ЦОД.

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

     В инфраструктуру ЦОД входит:

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

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

     В этом случае в ЦОД условно выделяют несколько базовых уровней:

• инженерный;
• сетевой;
• серверный;
• уровень хранения данных.

     Кроме этого, немаловажную роль играют вспомогательные уровни обеспечения климата, мониторинга и прочие сервисы.

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

Резервирование

ЦОД уровня 1 не имеет резервирования (избыточности). В его топологии один путь для распределения электропитания и охлаждения.

     ЦОД уровня 2 имеет резервированные (избыточные) компоненты, но только один путь. Он имеет один путь для распределения электропитания и охлаждения, но имеет резервированные (избыточные) компоненты на этом пути распределения. Проектные возможности ИБП (UPS) и генераторов имеют оценку N +1 (Need plus One), что означает однопоточный путь распределения по всей площади. Техническое обслуживание и ремонт критического пути электроснабжения и других частей инфраструктуры объекта потребует остановки процесса обработки данных.

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

     Конкретно уровень резервирования в Стандарте не оговаривается, но основным является требование к проведению всех плановых работ без остановки ЦОД. Дополнительным требованием для 3-го и 4-го уровня является то, что Объект должен находиться под управлением человека 24 часа в сутки.

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

     В большинстве случаев необходимо полное дублирование систем, и каждая из дублированных систем, должна иметь еще и резервирование N+1.

     И ещё замечание. Создание резервных, территориально удалённых ЦОД увеличивает уровень надёжности вашей информационной системы, но не основного ЦОД.

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

Требования к телекоммуникационной инфраструктуре

Уровни телекоммуникаций

Для уровня надёжности 2 уже вводится требование, что Магистральные кабели внутренних ЛВС и СХД ЦОДа, идущие от коммутаторов в горизонтальных распределительных зонах к магистральным коммутаторам в главной распределительной зоне должны иметь резервированные оптоволоконные или медные пары.

     Для уровня надёжности 3 должны быть резервированы службы провайдеров доступа – несколько провайдеров, трасс.

     Для уровня надёжности 4 рекомендуется резервирование горизонтальной кабельной разводки. Необходимо заметить, что резервная горизонтальная, да и магистральная кабельная разводка не помешали бы и для других уровней в случае появления новых провайдеров, расширения ЦОД. Хотя в этом случае дешевле просто прокладывать кабели с «запасом». В недавно одобренном новом стандарте для телекоммуникационной инфраструктуры центров обработки данных TIA-942-A прямо написано, что минимальное требование в горизонтальных кабельных системах это использование кабелей Category 6, а рекомендуется использовать кабели Category 6A или выше. Основной причиной является не только то, что Category 6 поддерживает больший диапазон частот, но и то, что она имеет лучшую помехоустойчивость. Ещё для тех, кто вдруг захочет создать ЦОД уровня 4 — не забудьте, что резервную разводку так же нужно проложить с запасом.

Архитектура

Для уровня надёжности 3 и 4 имеются требования к расположению ЦОД. ЦОД не должен располагаться в зоне с риском затопления раз в 100 лет или менее 91 м от зоны с риском затопления раз в 50 лет. Для уровня 4 требование располагаться не менее 91 м от зоны с риском затопления раз в 100 лет. Так же регламентируется для этих уровней близость расположения от транспортных магистралей, водных путей и аэропортов.

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

Электрооборудование

Для уровня надёжности 3 и 4 необходимо 2 ввода от электросети общего пользования, а для уровня 4 ещё и от разных подстанций. Для российских реалий желательно всем дата центрам, кроме ЦОД 1-го уровня, иметь 2 ввода от разных подстанций.

     В РФ в дополнение к ANSI/TIA-942 есть еще и «Правила устройства электроустановок (ПУЭ)». Этот документ выделяет категории надежности электроснабжения (объекты I, II категории и объекты особой группы первой категории) и дает общие рекомендации по обеспечению каждого из уровней. Для I категории ПУЭ регламентирует: «Электроприемники первой категории в нормальных режимах должны обеспечиваться электроэнергией от двух независимых взаимно резервирующих источников питания, и перерыв их электроснабжения при нарушении электроснабжения от одного из источников питания может быть допущен лишь на время автоматического восстановления питания». Обычно, для ЦОД уровней 3 и 4 перерыв при переключении питания недопустим, но даже для особой группы в ПУЭ такого требования нет. А обеспечение надёжного питания наиболее важная задача разработчиков ЦОД.

     Посмотрим на результаты опроса американских ЦОД (подробных российских аналитических данных по сбоям в прессе не было). В ходе исследования Ponemon Institute было опрошено более 450 работников американских центров обработки данных. Предметом исследования стали причины и частота возникновения простоев в работе ЦОД. Что касается частоты простоев, респонденты заявили, что за последние два года произошло 2,5 полных выхода ЦОД из работы. За это же время перебои в работе ЦОД нескольких стоек имели место 6,8 раз. Чаще всего наблюдались перебои в работе отдельных устройств или серверов — за два года 11,3 инцидентов.

     Участники опроса в качестве причин незапланированных простоев ЦОД чаще всего называли неисправности в работе аккумулятора источника бесперебойного питания (65 процентов), превышение мощности ИБП (53 процента), случайное аварийное отключение питания/человеческую ошибку (51 процент) и отказ оборудования ИБП (49 процентов).

     Методом обеспечения надёжного электроснабжения аппаратуры ЦОД будет использование резервных источников электроснабжения и источников бесперебойного питания (ИБП). В TIA-942 прямо говорится: «…Резервная система выработки электроэнергии является самым жизненно важным одиночным фактором устойчивости системы к внешним воздействиям и должна быть способна предоставить электроснабжение умеренного качества и устойчивости непосредственно вычислительному и телекоммуникационному оборудованию в случае отказа общей электрической сети».

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

Климатическое оборудование

Согласно первой редакции TIA-942 климатическое оборудование обязано обеспечивать следующие параметры в помещениях ЦОД.

• Температура: от 20°С до 25°С
• Точки нормальной настройки: 22°С
• Контрольный диапазон отклонений ± 1°С
• Относительная влажность: от 40℅ до 55℅

     Необходимо заметить, что начиная с ЦОД уровня 2 системы кондиционирования воздуха должны быть рассчитаны на непрерывную работу 7 дней в неделю/24 часа в сутки/365 дней в год и должны иметь резервирование не менее (N+1) для кондиционеров машинного зала (CRAC – Computer Room Air Conditioning).

     Несмотря на то, что зависимость отказов от температуры носит экспоненциальный характер, но обычно увеличение отказов при повышении температуры до 30 градусов очень мало. Страшно не само повышение температуры, а локальный перегрев вычислительного оборудования в серверной стойке, где температура локально может достигать существенно больших величин. При правильно спроектированном оборудовании и учитывая то, что срок службы до его замены обычно не превышает 3-х лет, часто повышают температуру в машинных залах и серверных помещениях. Есть смысл прочитать стандарт TIA-568-C, основанный на новых рекомендациях ASHRAE TC 9.9. Хотя сам стандарт найти не очень просто, но в Интернете достаточно широко были описаны сами рекомендации ASHRAE TC 9.9.

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

     Более подробно требования к инженерным подсистемам ЦОД можно посмотреть всё в том же стандарте TIA-942. Помимо упомянутых выше требований при проектировании ЦОД также следует учитывать и ряд других требований, обеспечивающих его отказоустойчивость (в основном для ЦОД уровней 3 и 4), в частности, от:

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

Требования к ЦОД определяются исходя из бизнес-требований

В полной мере требования к ЦОД по уровням надежности и доступности определяются исходя из бизнес-требований, в частности, например, исходя из показателей RPO/RTO.

     RTO (recovery time objective, время восстановления) — допустимое время простоя сервиса в случае сбоя. Обычно диктуется временем восстановления информации при сбое и теоретически может стремиться к 0.

     RPO (recovery point objective, точка возврата) — допустимый объем возможных потерь данных в случае сбоя. Обычно определяется временем между процедурами резервного копирования, включением резервного оборудования или передачей запроса на работоспособное устройство.

     Необходимо понимать, что уменьшение значений RTO и RPO (а значит и увеличение затрат) определяется только одной величиной — возможными потерями (финансовыми или репутационными) в случае простоя ЦОД.

Начальный этап эксплуатации ЦОД

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

     Необходимо подготовить документы по:

• мониторингу сети и оборудования;
• комплексу мер по защите информации;
• обеспечению необходимого уровня эксплуатации.

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

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

Подведение итогов по этапу «Реализация проекта построения ЦОД»

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

     Для того, чтобы добиться это необходимо:

1. Руководствоваться правилами создания успешных проектов. И хотя следование правилам не гарантирует успешную реализацию проекта, но позволяет избежать многих ошибок.
2. Не забывать, что большинство ошибок, приводящих к краху проектов, лежат в области менеджмента. И, несмотря на кажущуюся лёгкость устранения этих ошибок, отсутствие должной мотивации исполнителей, неверный выбор руководителя, частые проверки, мелкая опёка и отсутствие принятие во внимание всех мнений в коллективе создаёт все предпосылки для возникновения проблем при разработке проекта.
3. Помнить, что ещё хуже ситуация, когда от исполнителей наверх уходит информация не соответствующая реальному положению дел. В этом случае об оперативном и адекватном управлении при возникновении проблем при разработке речь уже не идёт, а значить и реализация проекта находится под реальной угрозой.
4. Понимать, что надёжность ЦОД не ограничивается надёжностью его оборудования, а требует комплексного подхода и специальных мер по её повышению на этапе эксплуатации и комплексного (без перекоса в сторону дорогих аппаратных решений) подхода по обеспечению защиты информации. Например, если основное требование к важной информации, хранящейся на каком-то из серверов, является её сохранность и получение за некоторое конечное (но не очень короткое) время, то архивирование на 3-х независимых, территориально разнесённых устройствах будет надёжнее и главное существенно дешевле использования кластера.
5. Критически подходить к цифровым показателям надёжности создаваемого ЦОД, но в тоже время всеми силами стараться обеспечить надёжность вашего ЦОД не только аппаратными и программными решениями, а и мерами на этапе эксплуатации. Об обязательности обучения обслуживающего персонала, о необходимости использования средств контроля работоспособности аппаратуры, средств регистрации и анализа инцидентов я подробно напишу в 3-й части посвящённой эксплуатации. Так же необходимо серьёзно подходить к написанию всех эксплуатационных документов, к которым у некоторых Исполнителей достаточно легкомысленное отношение.
6. Во время работы над эскизным проектом (а его написание рекомендуется во всех случаях разработки действительно крупных проектов, либо в случаях, когда осталась некоторая неясность с методами, технологиями или вообще целесообразности выполнения каких либо требований приведенных в ТЗ) необходимо обратить пристальное внимание на обоснованный выбор решений по:
   • электрооборудованию (т.к. неверное решение в этой области может грозить очень тяжёлыми последствиями). Наиболее тяжёлый случай это авария на Фокусиме, которой могло и не быть, предвидя разработчик одновременную потерю основного питания и резервного, не сумевшего продержаться из-за разрушений более длительное, чем предполагалось время до момента подвода питания по резервной схеме. Конечно, в нашем случае такие тяжёлые последствия исключены, но для многих из-за проблем с электропитанием возможны свои маленькие персональные Фокусимы.
   • резервированию достаточного количества кабелей магистральной и кабельной разводки. Т.к. в противном случае возможны большие проблемы (потери времени) при прокладке кабелей в уже работающем ЦОД.
   • внедрению новых и ещё не опробованных до конца новых технологий и запуску новых продуктов. Вы всегда должны в вопросах их использования пользоваться принципом «любая новая технология или продукт внедряется в том случае если старых недостаточно, либо старые существенно более затратны, чем новые».
7. При реализации ЦОД желательно сразу производить проверку устанавливаемого оборудования и создаваемых подсистем, а так же тестирование ПО. Начало проверки, перенесённое на этап сдачи объекта, приводит к очень большой загрузке специалистов, особенно если всплывают какие-то проблемы, да и обслуживающий персонал должен привыкать к технике и ПО которое он будет обслуживать.

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

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

Об авторе

Главный специалист ГУП ВЦКП «ЖХ» Александр Кругляк, a_krug@rambler.ru

     Приглашаем специалистов обсудить данную статью.