Возможные проблемы при реализации
При подготовке ЦОДов к сертификации по Uptime возможны неожиданные проблемы, связанные со спецификой требований.
Например, при сертификации по Tier III дата-центра может потребоваться довольно специфически организовать управление синхронизацией дизель-генераторов (задача, пракически, не решенная на территории Украины и России).
При проектировании систем бесперебойного питания обычно смотрят на тип батареи, ёмкость, герметичность, обслуживаемость и так далее — то есть рассматриваются только основные параметры батарей. На самом деле при проектировании ЦОД следует принимать во внимание и более «тонкие» характеристики. Например у батарей еще и разные кривые разряда (грубо говоря, разная ёмкость при разной скорости разряда) — при частичной нагрузке всё хорошо, но при полной нагрузке система не сможет держать положенное время и произойдет отказ.
А вот пример из практики одного из заказчиков: на бумаге никто не докапывается до состояния дизельного топлива. Грубо говоря, есть генераторы, есть резервные линии доставки топлива, а соляр он и есть соляр, главное, чтобы доливали вовремя. ЦОД может быть оценен как соответствующий требованиям TIA. Но на практике ДТ в нашей стране обладает парой волшебных свойств, и дизели вполне могут захлебнуться. Это несоответствие проверке на уровне эксплуатации. Грубо говоря,
В TIA никогда не возникнет вопрос «а что если в баке вместо ДТ окажется вода?» и «когда вы в последний раз меняли топливо?» (ведь при использовании дизель-генераторов бывают разные проблемы с топливом). У Uptime Institute есть дебаг-команда, которая призвана проверять такие вещи на практике. Парни учли этот факт и теперь знают не только про то, что топливо может внезапно подвести (по методологии это так), но и учитывают, как конкретно.
Понятно, всё проверить нельзя. Всегда есть человеческий фактор, который создаёт крайне непредсказуемые ситуации. В среде инженеров ходит байка, что ещё в двухтысячных годах в Израиле один из ЦОДов крупной IT-компании остановился благодаря нашему соотечественнику в новый год. Он отмечал праздник, выпил прямо на смене, потом продолжил. После полуночи питание из города пропало, и врубились дизели (участие человека не требовалось, сработала автоматика). Но герою чем-то очень помешал шум, и он вручную аварийно повырубал все генераторы, чтобы продолжить отдых в комфортной обстановке. Официальных подтверждений истории нет, но все-таки дыма без огня не бывает.
Автоматика
Также в стандартах нет рекомендаций по организации автоматики, срабатывающей в аварийных ситуациях и рекомендаций по организации персонала типа аварийных служб. Как вариант, можно применять старый добрый «советский» подход, когда всё сделано предельно просто и надёжно, чуть ли не на реле: никаких сложных микроконтроллеров с собственной логикой и никакого «восстания машин». Выводят автоматику туда, где ситуация однозначна и нужна скорость, превышающая скорость человеческой реакции. При этом всё то, где требуется взвешенное решение, оставляем на ручное управление. Как частный пример – с города на дизель переключает автоматика. Перевод же с дизеля обратно на город (с отключением дизеля) делается строго руками на установке, а не щелчком в интерфейсе. Задача – чтобы важные действия не выполнялись на «автопилоте»: много аварий происходит именно из-за того, что люди сначала делают, а потом думают. Собственно, если в ЦОДе есть профессионал, который хорошо делает свою работу, это куда важнее и, главное, надёжнее самых умных инженерных решений.
Выводы
Итак, почему сертфицированный ЦОД может встать? Ответ — потому что при одинаковом названии уровней (например, Tier II) есть огромная разница между сертификацией проекта без проверки на месте и сертификацией работающей площадки с конкретной проверкой на месте.