Причины и цена простоя систем дата-центра: Вопросы и ответы Консультативного Совета

27 октября 2014 г. | Механиков Олег | Категория: Обсуждаем статью

Иногда невозможно избежать простоя системы, но планирование и обучение в большинстве случаев помогут быстрее возобновить операции и снизить негативные последствия.

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

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

Роберт МакФарлейн, руководитель и эксперт про проектированию дата-центров, Shen Milsom Wilke Inc.

Авторитетные исследования показали, что порядка 75% простоев происходят по вине той или иной ошибки персонала. Но что стоит за этими ошибками? Всегда легко сказать – «недостаток обучения», но даже наилучшим образом обученные работники все равно допускают ошибки, если они спешат, устали, не думали, что делали, или просто решили, что сойдет и так.  Я бы назвал причину скорее в недостатке планирования. Я был всегда убежден в том, что многие вещи (дата-центры в частности) порождают человеческие ошибки просто потому, что они нелогично спроектированы, плохо (или вообще никак) маркированы, и им просто суждено поймать в ловушку грешную душу и довести до ошибки, которой могло бы и не быть, если бы изначально приложили ума к логике операции.

Например, сегодня почти все устройства имеют дублированное подключение к электросети, то есть соединяются с двумя различными розетками, которые должны вести к двум разным электрическим щиткам. Предоставленные сами себе, электрики могут соединить розетку с предохранителем 7 на панели А, а другую розетку – с предохранителем 16 на панели В. Дальше – больше: они могут надписать розетки внутри шкафов и это будет невозможно прочесть, или пометить разъемы на панели предохранителей номерами, которые не будут совпадать с номерами шкафов. Вследствие этого можно нечаянно отключить розетки в несовпадающих с нумерацией шкафах или наоборот не выключить нужный шкаф.

В результате простоев моральное состояние персонала подвергается серьезным испытаниям, потому что ИТ живет в постоянном страхе аварий. Даже маленькой проблемы уже достаточно для стресса, а уж большие просто приводят персонал в состояние отчаяния. ИТ стали новым видом «коммунальной услуги». Системы просто обязаны работать всегда, как всегда есть газ, свет и вода,  -  если их отключили, то быстро восстанавливают.   Сотрудники IT очень хорошо знают, что такой сбой, который  наносит бизнесу реальный ущерб, и даже ставит в опасность жизнь людей, будет тщательно расследован и даже может быть предан широкой огласке, что приведет к потере работы. Ежедневно они живут в стрессе, стараясь не допустить сбоя, но еще в большем стрессе они оказываются в процессе восстановления. Я видел только один дата-центр, где регулярно публиковали информацию о продолжительности бесперебойной работы.

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

Риск простоя трудно уменьшить. ИТ – это бизнес стрессовый. Все время надо подключать новый сервер, или устанавливать программу, и редко есть достаточно времени, чтобы сделать это не торопясь, аккуратно и полностью задокументировать. Иногда необходимо твердо сказать руководителю: «этот график нереалистичен, это прямая дорога к аварии в будущем». Нужна дисциплина и настойчивость в правильном планировании и соблюдении процедур, которые включают все вышеперечисленное. Человеку свойственно ошибаться. Если мы толкаем ИТ-сотрудника к заведомой ошибке, то не стоит потом удивляться тому, что произошла авария.

Мэтт Стансберри, директор контента и публикаций, UptimeInstitute

Я обратился к Рику Шукнехту, вице-президенту Uptime Institute, с просьбой ответить на некоторые вопросы. Шукнехт работает с элитными сетями дата-центров конечных пользователей, и он утверждает, что 73% аварий вызваны человеческим фактором.  Человеческий фактор включает плохую подготовку персонала, плохие процедуры обслуживания и плохое управление эксплуатацией. Рик считает, что простой системы может быть очень болезненным и даже сломить моральный дух, потому что работа и зарплата часто зависят от выполнения организацией запланированных целей.

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

Упускают еще несколько неприятных косвенных последствий остановки. Например, на финансовых рынках регулирующие органы применяют систему штрафов. Остановка системы может также подорвать конкурентоспособность компании, ухудшить ее деловую репутацию в отрасли и/или среди клиентов. Куда вы скорее вложите деньги: в тот банк, который не допускает остановок системы, или в другой, система которого постоянно зависает? Большинство финансовых организаций внедрили процессы, позволяющие сохранить или восстановить данные, но именно неспособность обеспечить непрерывность операций вызывает наибольшие проблемы.

Что же делает персонал дата-центра для того, чтобы избежать остановок системы или уменьшить их последствия?  Шукнехт рекомедует принять хорошую программу обслуживания оборудования и информационных систем для каждого устройства, создать систему обучения персонала с подробным объяснением, как и когда реагировать на сбои, выделить необходимое финансирование для операционных расходов, чтобы обеспечить надлежащее функционирование объекта, а также внедрить качественную систему управления, позволяющую эксплуатировать площадку в соответствии с ожиданиями производителя.

Чак Гулсби, управляющий дата-центром и блоггер SearchDataCenter.com

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

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

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

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

Билл Клейман, директор технологий, WorldWideFittingsInc.

Остановка и простой – это такие вещи, о которых ИТ-администратор (даже в большой глобальной организации) не часто задумывается, но когда они случаются, они сразу получают статус чрезвычайного происшествия. Первый шаг к уменьшению простоев – это планирование. Если случается сбой, а плана по его ликвидации нет, то можно ожидать негативные последствия затяжного характера. Хорошо обученный и подготовленный к аварийной ситуации персонал лучше справится с проблемой, когда понадобится искать решения для послеаварийного восстановления данных (DR). Планирование, тестирование и фактическое воплощение DR-плана поможет любой организации подготовиться к чрезвычайной ситуации. Не существует ноу-хау, как выжить в случае выхода из строя. Чем выше степень резервирования и подготовки инфраструктуры, тем легче она сможет пережить аварийный сбой.

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

Нам, как одному из глобальных производителей, единственный день простоя обходится примерно в $200.000 -$350.000, в зависимости от того, какая именно подсистема упала. Если система не готова или не способна дублировать функции неработоспособного элемента, то в долгосрочной перспективе издержки вашей организации будут немалыми.

Что это значит? На этапе первичной покупки ИТ-менеджеры имеют возможность сэкономить и приобрести оборудование без резервных вентиляторов, энергоблоков, ИБП и тд. На этом первом этапе можно совершить ошибку, которая вернется к вам в будущем и больно ударит по всему предприятию. К примеру, скажем, скачок напряжения может вырубить сервер с одним источником питания и повредить его внутренние узлы. И вот выходит из строя вся система, и устройство необходимо менять на новое. С другой стороны, возьмем того же ИТ-менеджера, который потратил дополнительные деньги и купил более качественный блок питания и распределительную панель для защиты оборудования. В этом случае, простое переключение с одного источника питания на другой решит проблему с минимальным простоем или вообще без такового. Нематериальные факторы тоже играют роль, когда случаются простои или сбои. Никто не хочет раньше времени поседеть из-за того, что система «легла», и единственное решение занимает долгие дни. Такого рода стресса можно избежать с помощью хоть какого-то мало-мальского планирования. Кроме того, вы вряд ли хотите, чтобы ваш ИТ-департамент потерял доверие своего Правления.

Если вам надо, чтобы система находилась в рабочем состоянии 99% времени, то планируйте это. Чем больше планирования, тем лучше инфраструктура справляется со сбоями. Будьте готовы к сбою, до самого простого элемента. Это означает, что дата-центр должен иметь запасные генераторы, временно неиспользуемые виртуальные машины, готовые к запуску, или готовую площадку, которая подключится сразу же, как только возникнет необходимость. Нужно иметь несколько мест для хранения данных (это может быть облако, локальная система хранения, выделенная сеть хранения,  удаленный носитель) и регулярно тестировать эти решения.  Каждая система должна иметь нечто вроде DR-плана. Чем выше резервные возможности, предусматриваемые программой, тем лучше система справится с аварией. Задайте себе простой вопрос. Есть ли у меня резервные интернет-провайдеры? Сидят ли они на разных магистральных сетях? Есть ли у меня план по резервному энергоснабжению? Все ли аккумуляторы в порядке? Может ли моя виртуальная система справиться со сбоем физического устройства? Поскольку каждая система уникальна, план по аварийному восстановлению должен разрабатываться конкретно для нужд данной инфраструктуры. Сотрудников необходимо обучить, чтобы они идеально знали и основную, и резервную систему. Чем более подготовлен даже самый младший инженер, тем лучше вся сетевая инфраструктура справится со сбоем или отключением оборудования.

Стефан Биглоу,
редактор отдела технологий портала  www.searchdatacenter.techtarget.com

Теги: простой систем