Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
Если перестанут работать дата-центры (ДЦ), вы не сможете заказать такси, отправить другу мем или оплатить коммунальные услуги через банковское приложение. За любыми, казалось бы, простыми действиями в интернете стоит «невидимая армия», или служба эксплуатации. Эти люди обеспечивают работу серверов и заботятся о том, чтобы информационный поток в наших девайсах никогда не прекращался. Деятельности дата-центров и посвящена книга Алексея Жумыкина, руководителя эксплуатации ДЦ «Яндекса». Автор, опираясь на собственный опыт, подробно объясняет процессы эксплуатации, рассказывает, как создать хорошую команду, и дает практические рекомендации по безопасности и техническому обслуживанию. Жумыкин простым языком говорит о сложных вещах: организации дата-центров, управлении мощностями, составлении документации, работе с подрядчиками, бюджетировании. В книге также приведены примеры того, как справляться с аварийными ситуациями. Для наглядности автор использует схемы, графики и таблицы, которые позволяют понять устройство оборудования и процессы внутри стандартных ДЦ.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 225
Veröffentlichungsjahr: 2023
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Все права защищены. Данная электронная книга предназначена исключительно для частного использования в личных (некоммерческих) целях. Электронная книга, ее части, фрагменты и элементы, включая текст, изображения и иное, не подлежат копированию и любому другому использованию без разрешения правообладателя. В частности, запрещено такое использование, в результате которого электронная книга, ее часть, фрагмент или элемент станут доступными ограниченному или неопределенному кругу лиц, в том числе посредством сети интернет, независимо от того, будет предоставляться доступ за плату или безвозмездно.
Копирование, воспроизведение и иное использование электронной книги, ее частей, фрагментов и элементов, выходящее за пределы частного использования в личных (некоммерческих) целях, без согласия правообладателя является незаконным и влечет уголовную, административную и гражданскую ответственность.
Заставьте данные говорить: Как сделать бизнес-дашборд в Excel. Руководство по визуализации данных
Алексей Колоколов
Ценность ваших данных
Сергей Кузнецов, Александр Константинов, Николай Скворцов
Мама, я тимлид! Практические советы по руководству IT-командой
Марина Перескокова
Книга издана при поддержке АНО «Координационный совет по ЦОДам и облачным технологиям» (АНО КС ЦОД)
Вам выпала невероятная удача – прочитать самое блестящее описание непростой кухни эксплуатации датацентра[1] из всех, что были написаны на русском языке. Мне очень импонирует почти разговорный стиль изложения автора – далекий от псевдоакадемических умствований, призванных, как правило, замаскировать отсутствие живой и ясной мысли. Датацентры и без того достаточно сложны, чтобы дополнительно затуманивать понимание их устройства сложностью изложения.
Я был приятно удивлен, что идеи автора весьма созвучны стандарту эксплуатации датацентров Tier Standard: Operational Sustainability от Uptime Institute. Эта книга является его расширенным дополнением. В отличие от более чем лаконичного текста стандарта, здесь все изложено в деталях и подробностях с массой практических рекомендаций.
Автор скромно умолчал об уникальном опыте работы в крупнейших организациях, владеющих датацентрами. В этой связи я призываю читателя к вдумчивому чтению: не все, что хорошо для спортивного суперкара, подходит один в один для семейного минивэна или джипа-вездехода. При общей схожести подходов, есть существенная разница в деталях.
Книга является ясным свидетельством того, что российские датацентры вышли на мировой уровень качества. На сегодняшний день у нас есть и опыт эксплуатации, ничем не уступающий лучшим мировым практикам, и люди, способные его описать, обобщить и поделиться, за что я крайне признателен автору.
Алексей Солодовников, управляющий директор Uptime Institute
в России и странах СНГ
Не было гвоздя — подкова пропала.
Не было подковы — лошадь захромала.
Лошадь захромала — командир убит.
Конница разбита — армия бежит.
Враг вступает в город, пленных не щадя,
Оттого, что в кузнице не было гвоздя.
Стихотворение, приписываемое
Бенджамину Франклину, 1758 г.
Перевод Самуила Маршака
Компания 3data1 решила издать эту книгу, потому что мы не понаслышке знаем, насколько важна роль эксплуататоров в функционировании ЦОДов. Наша сеть насчитывает десятки центров обработки данных по всей России. Опыт Алексея Жумыкина, которым он делится в книге, позволит нашим специалистам и всем инженерам ЦОДов свежим взглядом посмотреть на собственные рабочие процессы, оценить и улучшить их. Мы рассчитываем, что книга станет настольной для профессионалов отрасли.
За каждым заказанным такси, доставленной пиццей и мемом с котиком стоит сервер. Сотни миллионов серверов делают интернет самой большой машиной на планете Земля. Серверы вместе со всеми сайтами и сервисами мира живут в центрах обработки данных, и их обслуживают настоящие профессионалы своего дела.
Оборудование датацентров работает 24/7 365 дней в году. И люди тоже. Инженерные системы ЦОДов способны противостоять инцидентам и непредвиденным ситуациям. И люди тоже. Чем надежнее техника, тем незаметнее для пользователей ее труд. И вклад людей тоже.
В качестве популяризации технологий мы будем рады предложить эту книгу и широкой аудитории. Она поможет читателям лучше узнать людей, которые трудятся за кулисами современных технологических процессов.
Илья Хала,
генеральный директор сети датацентров 3data
Идея этой книги родилась жарким летом, когда в офисных помещениях закрывают окна поплотнее и включают кондиционеры. Для тех, кто отвечает за жизнедеятельность центров обработки данных, в это время настает действительно жаркая пора. Приходится, не отрывая глаз от мониторов, следить за температурой в серверных. В такие моменты как никогда чувствуешь, насколько современный, насквозь пропитанный информационными потоками мир может зависеть от капризов погоды и какие-то плюс два-три градуса в серверной могут привести к сбою оборудования и последствиям, если и не критичным, то заметным даже для рядовых офисных сотрудников в помещениях с кондиционерами.
Про работу службы эксплуатации уже появилось несколько не очень приятных стереотипов. На первых полосах бумажных газет о ней не прочитаешь и в TikTok ее не увидишь. Существует даже мнение, что в дежурные идут для того, чтобы спокойно спать в ночную смену. Но все это совсем не так. От этих нескольких человек, находящихся в ночь с субботы на воскресенье на площадке, полностью зависит работа крупного банка, заказ еды или такси, сообщения мессенджеров, прогноз погоды — да трудно представить, какая часть информационного потока не идет сейчас через датацентры.
Эта невидимая армия заслуживает своего описания — именно службе эксплуатации будут посвящены страницы данной книги.
Эта книга не претендует на полное описание всех возможных аспектов работы датацентров, так же как и не содержит решений на все случаи жизни. Я уверен, что любой из действующих или бывших эксплуатационщиков может в какой-то момент не согласиться с моим мнением, добавить какие-то свои истории, методологии и ситуации. И это здорово.
Когда, спустя несколько лет, я вновь сел за свой старый, но все еще быстрый Lenovo Х220, то вдруг по-настоящему понял признак истинного профессионала эксплуатации. Выбирать надежное оборудование, следить за его исправностью и использовать так долго, пока окружающие не начнут спрашивать: «Где ты откопал такой раритет?» За более чем десяток лет я продолжаю ежедневно сталкиваться с проблемами, решений для которых еще нет, и придумать их необходимо здесь, сейчас и конкретно для этого случая. И теперь мне больше всего хочется не научить, а рассказать. Однако работа единомышленников в больших компаниях помогла сформировать некие общие принципы, подходы к процессу эксплуатации, придерживаясь которых справляться с проблемами стало значительно проще. Именно этими принципами я и хочу поделиться.
Так получилось, что большую часть времени я провел в командах, где были приняты неформальное общение, нестрогое отношение к одежде и внешнему виду. Это не могло не сказаться на живом общении и переписке. Надеюсь, мой стиль не покоробит никого из специалистов отрасли, кроме яростных поборников чистоты русского языка. С другой стороны, некоторая небрежность в одежде никак не коррелирует с жесткой, почти военной требовательностью и скрупулезностью в отношении оборудования.
Управление датацентрами отчасти напоминает промышленные предприятия, где существует большое количество соприкосновений с другими отделами и, несмотря на то что все работают в одной компании, интересы соседних подразделений могут быть противоположны. И как поступать в спорных ситуациях, в общем случае предсказать невозможно. Я постараюсь придерживаться мнения, что команда эксплуатации права, когда ее позиция основана на ее ключевых интересах. Например, если при закупке оборудования выбор стоит между «быстро», «дешево» и «надежно», очевидно, что первое и второе эксплуатацию должно волновать гораздо меньше, чем третье. Другими словами, финансистам, проектному отделу или даже юристам какие-то решения эксплуатации могут не нравиться, но я буду говорить только за своих.
Немного о терминологии. В российской тусовке принято сокращать центры обработки данных как ЦОД. Это, конечно, правильно, но звучание такой аббревиатуры лично меня коробит. Сразу представляются ряды электронно-вычислительных машин (ЭВМ), заполняющие эти ЦОДы, и среднего возраста научные работники в очках и белых халатах с пачкой перфокарт в руках. Лично мне, как и всей команде, с которой я работал, больше по душе сокращение ДЦ — датацентр.
Остальные разъяснения будут появляться по мере необходимости непосредственно в тексте. Итак, приступаем…
Глава
1
Глава
2
Всего несколько лет назад пусконаладка считалась кратковременным, проходным этапом в процессе строительства, а зачастую и вовсе игнорировалась. А как же иначе, если монтаж оборудования задерживается, стойки заказчика уже ждут, контракт горит? Давайте пока запустим как есть, потом доустановим недостающее и будем надеяться, что проектировщики нигде не ошиблись и все будет работать как надо.
У такого подхода есть огромное преимущество: кроме минимальных сроков ввода объекта, мы обеспечиваем службу эксплуатации интересной и захватывающей работой по поиску неисправностей и их срочному устранению в работающем датацентре на несколько лет вперед. Для тех же заказчиков, которые могли себе позволить потратить какое-то время на проверку смонтированных систем, сторонние организации, как правило, тестировали взаимодействие систем вентиляции и пожаротушения, а также все или самые основные переключения с города на ДГУ (дизель-генераторную установку)6 и т.п.
Между тем зарубежный опыт привел к пониманию, что грамотно проведенная пусконаладка позволяет обнаружить и устранить подавляющее большинство неисправностей еще до подключения полезной нагрузки и следующие годы жить намного спокойнее. В мире существует несколько компаний, которые специализируются только на услугах пусконаладки (такой участник процесса называется Commissioning Agent7 — агент ПНР) и делают их на самом высоком уровне. Правда, услуги их совсем недешевы, и это еще одна из причин, почему многие заказчики стремятся сэкономить не только время, но и деньги, стараясь избежать полноценных пусконаладочных работ.
В то же время теоретические принципы проведения ПНР уже достаточно хорошо документированы и распространены, по крайней мере на Западе, и при осознании важности этого этапа и выделении ресурсов пусконаладку вполне возможно провести самостоятельно.
Есть несколько аргументов за то, чтобы ПНР проводилась собственной службой эксплуатации. Самыми главными я бы назвал два.
За время подготовки и проведения пусконаладки будущие специалисты эксплуатации на своем опыте знакомятся со всеми единицами оборудования, их особенностями и ограничениями. Этот опыт в последующие годы будет просто бесценен, даже при наличии самой лучшей документации от поставщика. Кроме того, такие моменты, как постановка оборудования на учет и заполнение всех его данных в системе CMMS8, также будут производиться вдумчиво и последовательно для каждой единицы оборудования.Все остальные претенденты на роль агента пусконаладки имеют свои собственные интересы, которые будут противоречить задачам дальнейшей многолетней эксплуатации. Так проектировщики, осо-знанно или нет, при обнаружении проектных ошибок не будут заинтересованы в их признании, говоря, что датацентр должен быть построен точно по их проекту. Подрядчики сделают все возможное, чтобы скрыть огрехи стройки, переложив ответственность либо на проектировщиков, либо на поставщиков, либо даже на заказчиков, которые чересчур строго давят на сроки и экономят бюджет. Формальный технадзор приносит много пользы, но, как правило, не до конца понимает сущность работы всего датацентра как единого целого, поэтому легко допускает ситуацию, когда «к пуговицам претензий нет, но костюм носить невозможно». Даже специально приглашенный агент ПНР чаще всего работает за деньги, поэтому воспринимает свою работу как продажу человеко-часов. Их вовлеченность, как правило, оформлена в виде консультационных услуг, поэтому вряд ли они станут защищать интересы клиентов сверх оговоренных рамок.Другими словами, если не собственная команда эксплуатации — кто тогда?
Итак, никто не сможет провести пусконаладочные работы лучше специально подготовленного агента ПНР, которым эффективнее всего назначить команду эксплуатации этого датацентра, проведя специализированное обучение.
Наличие в проекте выделенного координатора для ПНР может привести к неожиданным отрицательным эффектам. Например, генеральный проектировщик может «обидеться» и начать слишком рьяно защищать идеи, заложенные им в проект, даже если это будет противоречить реальным интересам заказчика. Поставщики отдельных систем, наоборот, постараются самоустраниться из всех активностей по тестированию. В каждом конкретном случае рецепты решения таких ситуаций будут свои. Однако с самого начала имеет смысл не забывать упоминать на встречах и в контрактах об этапе пусконаладки, чтобы подрядчики сразу поняли важность и неизбежность этого этапа строительства.
Отличную службу здесь может сослужить… PMBOK9 — библия проектного управления, в свежих изданиях которой инструменты управления проектами доведены практически до совершенства. Если проектом строительства датацентра занимается прожженный профи, то он в самом начале составит действующий, а не формальный устав проекта, в котором подробно расскажет о назначении, этапах, сроках и участниках ПНР. Например, скопировав все из этой книги. Но даже начинающий руководитель проекта может сделать необходимый минимум — создать матрицу ответственности специально для этапа пусконаладки.
В идеальном случае эта матрица должна попасть приложением в контракты участников проекта.
Ниже я приведу пример такой матрицы в немного упрощенном виде, насколько позволяет формат книги. На практике лучше распечатать ее на большом листе. Такая матрица должна содержать:
перечисление всех этапов ПНР в текущем проекте;перечисление всех участников ПНР;контакты реальных представителей каждого из участников с учетом этапа ПНР. Например, для проведения FAT10 (factory acceptance test) и SAT11 (site acceptance test) это могут быть разные люди;перечисление ролей внутри каждого из этапов и соответствие ролей и участников.Сама таблица может иметь несколько вариантов. Мы выберем аналог известной RACI12 — модели, в которой для каждого из участников проставляется роль, которую он играет на данном этапе. Важно отметить, что таблица имеет примерный вид и в каждом конкретном проекте следует внимательно изучать каждую строку матрицы, чтобы избежать конфликтных ситуаций.
Для того чтобы содержание матрицы легче воспринималось, я разобью ее на несколько частей и каждую часть помещу в описание соответствующего этапа.
Классическая модель ПНР строится на пяти шагах (milestones — вехах). Мне довелось несколько раз участвовать в полноценных проектах пусконаладки, и опытным путем мы с коллегами пришли к выводу, что в реальной жизни нужно добавлять еще два: один в начале классической модели и один в конце. Ниже перечислим все эти вехи, при этом я приведу также и их английские наименования. Это может быть полезно при дальнейшем изучении вопроса на англоязычных сайтах.
Этот этап очень часто опускается, а иногда даже умышленно исключается, чтобы команда эксплуатации со своими умными мыслями не мешала строить новый, «еще более лучший» датацентр. Тут многое зависит от коллектива и от того, как задачи эксплуатации воспринимаются в компании. Но важно понять, что мнение команды эксплуатации очень ценно на начальных этапах, поскольку либо им самим придется потом работать с этим оборудованием многие годы, либо эти люди уже успели накопить практический опыт и знают, на что обращать внимание при проектировании и выборе оборудования, чтобы не ошибиться.
На этом этапе важно убедиться в том, что проектные решения пригодны к эксплуатации. Например, что дверцы всех шкафов открываются в нужном направлении, во всех помещениях предусмотрены места для временного хранения инструментов, все помещения имеют розетки для уборочной техники, порожки на всем пути движения стоек отсутствуют, дежурному для проверки запуска дизеля не нужно спускаться.
Как таковой программы тестирования на этой стадии нет — достаточно, чтобы команда эксплуатации участвовала в общих обсуждениях проекта и в окончательном выборе конкретных типов оборудования.
В то же время этот этап в проекте используется для настройки взаимодействия между участниками, оформления документов и подготовки скриптов (программ) тестов, как показано в таблице далее.
Основная задача на этой стадии — убедиться в том, что оборудование обладает заявленными характеристиками и покинуло завод пригодным для дальнейших монтажа и эксплуатации.
Обычно компании-производители используют свои собственные программы для заводских тестов, которые в случае визитов представителей заказчика могут быть даже существенно упрощены. Для команды эксплуатации особенный интерес могут представлять так называемые type tests — расширенные испытания, которые проходят не все собранные единицы, а только несколько из партии, или самые первые образцы, если речь идет о новой модели. Ведь именно на таких тестах выбранные единицы оборудования проверяются в по-настоящему пограничных условиях, а остальная партия таким тестам не подвергается. Поэтому имеет смысл напроситься к производителю именно на подобное тестирование, даже если это и не те экземпляры, которые поедут именно к вам. Часто производитель не возражает против участия заказчика в таких тестах, если ему обоснованно разъяснить, зачем это нужно.
Программу FAT стоит запросить у производителя сразу после покупки оборудования (а иногда даже еще во время тендера), также следует разобраться в каждой строчке: зачем этот тест делается, что именно проверяется? После этого нужно принять решение, стоит ли ехать на завод. Чаще всего — да, ведь это не только первое знакомство с новым оборудованием, но и прекрасная возможность лучше понять культуру производства, разобраться в его особенностях, а также познакомиться не только с продавцами и маркетологами, но и с настоящими инженерами производства. Последним можно напрямую задать интересующие вас вопросы, ответы на которые иногда содержат такую информацию, которую маркетологи могут не знать или даже специально скрывать. Это отличный и при этом сравнительно недорогой способ профессионального обучения. Между нами скажу, что иногда получалось упросить инженеров на производстве провести тестирование, которое не входило в стандартную программу испытаний и вряд ли было бы одобрено отделом продаж производителя, но было важно с точки зрения заказчика, а с профессиональной точки зрения интересно и самим инженерам на производстве.
Еще одной важной причиной посетить завод и посмотреть свое новое оборудование является заблаговременная проверка качества маркировки, компоновочных решений и монтажа, особенно если речь идет об уникальных продуктах, таких как ГРЩ (главный распределительный щит), собранный под конкретного заказчика. Когда инженер эксплуатации, зная, что ему предстоит ежегодная протяжка болтовых соединений шин, прямо на заводе берет гаечный ключ и пытается их подтянуть, он сразу может оценить, и какой ему понадобится инструмент, и можно ли вообще дотянуться до нужного болта. Кстати, совершенно не исключаются варианты, когда представитель заказчика еще на заводе наткнется на недостаточный момент затяжки.
Другой повод для визита находится где-то посередине между упомянутыми DCC и FAT. Когда оборудование изготавливается впервые, например по ТЗ заказчика, то имеет смысл приехать на так называемый pre-FAT, чтобы убедиться, что мелочи, которые невозможно было сразу разглядеть в документации на новое изделие, не помешают качественно эксплуатировать оборудование. Для примера приведу случай, когда изготовитель установил контрольный прибор на высоте около 2,5 м, и для снятия показаний была нужна лесенка. Или рама вент-установки, на которой крепились фильтры, имела недостаточную жесткость и при работе вентиляторов прогибалась бы под напором воздуха. Такие мелочи рано или поздно были бы обнаружены, но устранить их, пока оборудование еще на заводе, — гораздо быстрее, дешевле, да и правильнее.
Подводя итог, если есть возможность съездить на производство — нужно ехать. В любом случае такой визит приведет к появлению новых идей, что в нашем инженерном мире, наверное, самое главное. Если же такой возможности нет — ее надо организовать…
После того как оборудование доехало на площадку и было установлено в помещении, включать его еще рано. Сначала нужно убедиться, что оно смонтировано именно в проектном месте и такая установка соответствует отраслевым нормативам (тут неоценимую помощь окажет специалист по техническому надзору, лучше всех разбирающийся в тонкостях СНиПов и подобной документации) и требованиям производителя. Внимательный осмотр позволит найти даже мелкие повреждения, убедиться в полной комплектности поставки и уже на своей территории еще раз удостовериться, что нет никаких проблем с дальнейшей эксплуатацией, например что все органы управления, контроля и регулировок легко доступны.
В одной из команд, с которыми мне приходилось работать, был специалист-слаботочник, до того дотошно контролировавший шкафы управления, что вручную проверял каждый, да-да, каждый проводок – хорошо ли он зажат в разъеме. Зато именно такой подход дает бóльшую уверенность, что в ближайшее время в этих местах соединений не проявится дребезг контактов.
Подробной программы таких испытаний обычно нет ни у производителя, ни у монтажников. Исключением, наверное, являются большие производители дизель-генераторных установок, скрупулезности проверочных документов которых можно только поражаться. Для другого оборудования программу придется составлять агенту пусконаладки. Важно не забыть заблаговременно согласовать ее с монтажниками, чтобы они знали, к чему готовиться, и заранее устраняли досадные мелкие недочеты, чтобы сберечь время в проекте.
Приемка монтажа — самый «дружелюбный» тест в том смысле, что на этом этапе очень многое может быть временно прощено поставщику (некомплектность, отсутствие маркировки и т.п.) и оборудование может быть допущено к следующим шагам тестирования. Однако тщательный подход к проведению ПНР обязывает зафиксировать все найденные неисправности и по каждой из них проставить время исправления.
После успешной приемки монтажа на оборудование можно подавать напряжение и приступать к поочередной проверке всех его составляющих. Это достаточно долгий и утомительный тест, но с точки зрения конечного результата его ценность трудно преувеличить. Так, например, приходилось видеть стену из двух десятков вентиляторов, вполне себе работоспособную, в которой из-за неисправности модуля управления один вентилятор всегда вращался с постоянной скоростью, остальные свою скорость меняли. Найти такой недочет можно или случайно, или путем последовательной проверки каждого вентилятора одного за другим. Понятно, что рано или поздно подобный неисправный компонент все равно бы нашелся, но предположу, что времени на его поиски было бы потрачено намного больше.
Программу таких испытаний написать трудно. Иногда для стандартных продуктов производитель готовит соответствующие чек-листы, но для специально спроектированного оборудования это, скорее всего, будет задачей агента пусконаладки. И тут будет необходимо привлечь весь опыт и всю экспертизу эксплуатации, чтобы не только учесть все уже известные типы неисправностей, но и предположить, что еще может произойти с конкретным компонентом в конкретном типе оборудования.
В идеальном случае на этом же этапе необходимо убедиться в сопряжении оборудования с системой мониторинга датацентра, чтобы уже на следующем тесте наблюдать изменение режимов работы, находясь не только непосредственно перед пультом управления, но и удаленно, с места дежурного.
Я бы не рекомендовал переходить к следующему этапу тестирования, если на CT остаются недочеты. Практически невозможно провести полное функциональное тестирование всей системы, если какой-то ее компонент все еще не готов или неисправен. Тем не менее могут быть объективные причины, по которым проект задерживать нельзя, поэтому особое внимание здесь стоит обратить на тщательное заполнение листа доработок и последующий регулярный, вплоть до ежедневного, контроль за их устранением.
Часто для стандартного оборудования компонентное тестирование производится сразу же после проверки монтажа, в тот же день. Это значит, что обе программы лучше подготовить одновременно. Однако здравый смысл должен преобладать. Слишком долгие испытания приводят к повышенной утомляемости, большему количеству ошибок и стремлению поскорее закончить весь процесс. А это противоречит самой главной цели пусконаладки.
В большинстве контрактов именно этим шагом отмечается окончание всех работ — когда подрядчик сдает, а заказчик принимает собранную и проверенную систему. Для этого подрядчик может заранее подготовить форму соответствующего акта и даже сделать ее приложением к контракту. Большие и уважаемые компании-поставщики вообще разрабатывают стандартную международную форму актов и программы испытаний, оспорить которую совсем не легко. Тут нужно хорошо понимать, устраивает ли вас стандартная форма, или вы хотите каких-то дополнительных проверок, и если да, то как именно договориться с подрядчиком об изменении процедуры проверки.
Для локальных или более мелких поставщиков разработку программы тестирования можно поручить агенту ПНР. Принципиальная разница в том, что при создании проекта часть оборудования берется с рынка и проект как бы подстраивается под спецификацию конкретных моделей. Тогда очевидно, что и процедура проверки решения должна определяться производителем. Другая же часть, наоборот, изготавливается под конкретное техническое задание, а значит, и тестирование должно исходить из задачи получения проектных значений.
Собственно, рассказать про это тестирование что-то новое трудно, потому что на некоторых объектах вообще нет никакого другого тестирования, кроме этого, но зато в нем разбираются, наверное, все. Но после того как акт о приемке подписан, вы, скорее всего, не сможете требовать от поставщика никаких дополнительных услуг или работ. Поэтому подписывать акт и прощаться нужно только при условии, что вы удовлетворены результатом и дальше справитесь самостоятельно. Какое бы давление на вас ни оказывали руководители проекта с обеих сторон.
И вот теперь наш датацентр собран из отдельных частей, каждая из них протестирована и теоретически, если включить все оборудование, датацентр должен заработать. Как говорится, должен, да не обязан.
Важно понимать, что по окончании SAT заказчик фактически вступил в права на датацентр и все оставшиеся проблемы являются его персональной головной болью. Если в этот момент будет найдена какая-то существенная неисправность, и неважно, кто в ней виноват — проектировщик, поставщик или подрядчик, — заказчику придется решать проблему самостоятельно. Поэтому именно ему нужно проверить работу всего датацентра перед открытием.
Давайте взглянем на процесс с инженерной точки зрения. В теории отказов оборудования наиболее часто используется U-образная кривая, отражающая зависимость количества отказов системы от срока ее эксплуатации. Видно, что в начальный период оборудование демонстрирует свои «детские болезни» и проявляются неисправности, не выявленные в заводских условиях производителем, а также те, которые связаны с ошибками проектирования и монтажа. После устранения таких неисправностей количество ошибок системы стабилизируется и остается на каком-то одном уровне. Существенный рост наблюдается ближе к окончанию срока полезного использования оборудования.
