Эксплуатация ЦОД. Практическое руководство
Шрифт:
Еще раз отметим, что создание рекомендуемого нами объема документации позволит вам исполнить требования как отечественных норм и правил, так и многих международных стандартов.
В процессе создания и ведения документации самое главное – понимать, что инженеры ЦОД должны не только владеть знаниями о технологиях и оборудовании, используемых в ЦОД, но и знать принципы организации процессов и базовой документации ЦОД. Они должны иметь информацию, где находится документация, как ее применять, постоянно обновляя и совершенствуя свои знания. Это достигается регулярным обучением, тренировками и проверками знаний (аттестацией). Только в этих случаях риски отключений в ЦОД, вызванных человеческим фактором, будут сведены к минимуму.
Когда будет организована
Потребители (клиенты) услуг ЦОД и уровень SLA
Это важный вопрос для определения концепции будущего ЦОД и, следовательно, принципов построения службы эксплуатации.
Если в случае коммерческого ЦОД уровень предоставляемой клиенту услуги очевиден и зафиксирован в договоре, то в случае корпоративного ЦОД зачастую бывает так, что текущие требования потребителя и его будущие потребности заранее не определены.
В рамках консультационной практики у нас был пример, когда одна финансовая организация, не рассматривающая перемещение мощностей своих ЦОД на коммерческую площадку, хотела организовать внутренние процессы по стандарту TS: OS – Tier Standard: Operational Sustainability [17] .
В ходе первичных консультаций при определении объемов задач и текущей ситуации в организации выяснилось, что внутренние требования к ЦОД своих же внутренних клиентов – ИТ-отдела – никак не зафиксированы и даже не определены, а существуют на уровне «должно работать». Более того, люди, которым поставлена задача привести эксплуатацию ЦОД в соответствие со стандартом TS: OS, слабо ориентируются в подразделениях компании, являющихся их внутренними заказчиками. Соответственно, оказалось невозможным как выстроить концепцию функционирования ЦОД и службы эксплуатации, так и определить объем и квалификацию персонала, который требовался для работы ЦОД.
17
Стандарт на эксплуатационную устойчивость ЦОД компании Uptime Institute, см. далее по тексту раздел, посвященный стандартам.
Какие из этого проистекают проблемы для проектировщиков и службы эксплуатации:
• Если мы не знаем, допускает ли ЦОД технологические перерывы в работе и какова приемлемая длительность таких перерывов, мы не можем оценить достаточность уровня резервирования инфраструктуры.
• Если мы не знаем логику работы приложений, то мы также не можем оценить достаточность уровня резервирования инфраструктуры, ведь организация, имея два ЦОД, вполне может использовать их как основной и резервный. При такой схеме в случае аварии в одном из ЦОД используется другой, обладающий репликами [18] приложений.
18
Синхронизированная и готовая к работе копия приложения.
• Мы не можем понять, какая численность службы эксплуатации требуется, так как непонятно, нужно ли держать инженеров на объектах 24 x 7.
• Не зная требований к непрерывности, мы не можем понять требования к подрядчикам по обслуживанию сложных и критических узлов инженерной инфраструктуры, установить сроки реагирования на неисправности, установить количество необходимого ЗИП [19] на складе.
Во избежание всех указанных проблем и неясностей во взаимодействии необходимо определить, сформулировать и зафиксировать уровень сервиса между
19
ЗИП – запасные части, инструменты и принадлежности. Согласно п. 75 ГОСТ 27.102–2021 «Надежность в технике»: «Совокупность запасов материальных средств, сформированная в зависимости от назначения и особенностей использования объекта и предназначенная для его функционирования, технического обслуживания и ремонта».
Соглашение об уровне обслуживания (SLA) и его важность
Теперь Вам стала понятна важность определения уровня сервиса между ЦОД и клиентом. Для этого требуется составление и проведение формальных процедур принятия обеими сторонами документов, называемых SLA или OLA.
SLA (Service Level Agreement), соглашение об уровне услуг, – это документ, характерный прежде всего для ЦОД колокейшн-провайдера, заключаемый между заказчиком и исполнителем, описывающий параметры предоставляемой услуги или сервиса.
SLA с клиентом чаще всего характеризуется требованиями к параметрам окружающей среды, указанным производителями оборудования и используемым клиентами ЦОД. Эти параметры необходимо учитывать в максимально широком диапазоне, чтобы иметь возможность эксплуатировать оборудование с более строгими параметрами по температуре и влажности.
Также существует OLA (Operational Level Agreement), соглашение об уровне операционного обслуживания, – аналогичный SLA внутренний документ компании, определяющий параметры услуги, оказываемой друг другу внутренними подразделениями компании.
• При соотнесении требований этих документов важно учитывать три аспекта:
• требования к любым SLA должны быть более жесткими по сравнению c OLA;
• требования к SLA ваших подрядчиков и поставщиков услуг должны быть более жесткими или как минимум равными с SLA, заключенными вами с клиентом;
• в договорах с подрядчиками и поставщиками услуг необходимы санкции за нарушение SLA, симметричные санкциям от клиентов ЦОД.
Если данные условия не соблюдаются, это может приводить к негативным событиям. Например, согласно SLA ваш поставщик услуг связи может допускать перерыв в предоставлении услуг на два часа в месяц без санкций, а по SLA с вашим клиентом допустим перерыв лишь в один час; это означает невозможность выполнения условий контракта с клиентом вашего ЦОД.
Отделы внутри компании также взаимозависимы и используют внутренние сервисы, параметры которых должны быть описаны. Важность наличия внутренних задокументированных взаимоотношений с разными отделами трудно переоценить. Несмотря на этот, казалось бы, формализм подхода, у вас будут четкие критерии того объема работы и уровня сервиса, который вы предоставляете другим. Информация не останется на уровне «договоренностей в почтовой переписке» между сотрудниками компании, которые могут ее покинуть и не оставить следов договоренностей. Также, опираясь на задокументированные условия OLA, можно обосновать те или иные затраты на резервирование и уровень обслуживания вашей инфраструктуры.
Например: для корпоративного ЦОД планировалась установка сетевого оборудования одного из вендоров. Выяснилось, что данному оборудованию присущи технологические особенности, а именно – подача охлаждающего воздуха к нему осуществляется от одной боковой стороны к другой, а также низкая температурная устойчивость: при 35 °C уже фиксировался перегрев. Эксплуатационной команде ЦОД пришлось не только демонтировать все боковые стенки уже установленных стоек холодных коридоров, но и понижать температуру подаваемого холодного воздуха до минимально возможной в 16 °C, чтобы сохранить температуру в пределах рабочего диапазона этого сетевого оборудования.