Глупейшие ошибки персонала дата-центров

Разумеется, технологические ошибки заставляют нас понервничать, однако на человеческий фактор приходится около 70% проблем дата-центров.
Кара Гарретсон

Университетская сеть упала, когда кто-то нечаянно воткнул два сетевых кабеля не в тот хаб. Работник получил травму, несвоевременно войдя в дата-центр. Перегревшиеся системы отключились после того, как сотрудник изменил шкалу термостата дата-центра с Фаренгейта на Цельсия.

Это всего лишь несколько примеров проблем в дата-центрах, вызванных не технологическими нарушениями или природными катастрофами, а человеческими ошибками.

Согласно данным Uptime Institute, исследовательской и консалтинговой компании из Нью-Йорка, специализирующейся на производительности дата-центров, человеческие ошибки являются причиной около 70% сбоев дата-центров. По словам вице-президента Uptime Institute Джулиана Кудрицки (Julian Kudritzki), компания проанализировала 4500 инцидентов, включая 400 полных отключений. Джулиан недавно опубликовал набор рекомендаций по операционной устойчивости дата-центров.

«Я не удивлен», — говорит Кудрицки о своих исследованиях, — «Управление операциями таит в себе как наиболее серьезную уязвимость, так и основную возможность избежать сбоев. Плюс в том, что людей можно обучить».

О чем бы ни шла речь – небрежность, недостаточная подготовка, вмешательство конечных пользователей, жесткие финансовые ограничения или простые ошибки – человеческие ошибки неизбежны. А в наши дни, с постоянно возрастающей сложностью IT-систем и, соответственно, увеличением нагрузки на работников дата-центров, зачастую не получается избежать даже предупреждаемых поломок – это слова Чарльза Кинга, аналитика Pund-IT Inc.

«Сочетание высокой сложности и переработок приводит к ужасным результатам», говорит Кинг. А по мере того как компании будут все больше полагаться на технологии для достижения бизнес-задач, ошибки будут становиться все более серьезными и дорогостоящими.

Не тот работник, не тот кабель

В качестве примера рассмотрим концентратор университетского дата-центра, оказавшийся перегруженным из-за того, что сотрудник службы IT по ошибке подключил два сетевых кабеля к нисходящим портам хаба. По словам Джереми Джея Бауэрса, аналитика по безопасности этого учреждения, это случилось около четырех лет назад в Медицинском университете Индианы (Indiana University School of Medicine) в Индианаполисе.

По словам Бауэрса, который в то время работал там системным инженером, проблема возникла из-за неоптимальной архитектуры сети. IT-отдел был разделен на два помещения – одна комната в здании университета, и вторая — в университетской больнице рядом. Не самое удачное расположение.
В отделе использовалось оптоволокно – пурпурный кабель, если говорить совсем конкретно. Кабель шел от концентратора в первом здании ко второму, проходя через потолок, множество дверей, и затем к административному крылу больницы. Кабель подсоединялся к 12-портовому концентратору, установленному в IT-комнате больницы – таким образом, персонал мог с легкостью отключиться от сети университета и подсоединиться к сети больницы через разъем в стене.
Однажды Бауэрс вышел прогуляться в перерыве, как зазвонил его iPhone – концентратор в серверной университета оказался перегруженным, выдавая отказы по каждому запросу.

«Зеленые лампочки так и мигали по мере прохождения пакетов. Количество пакетов все увеличивалось».

Бауэрс начал оперативно решать проблему по телефону. Он определил, что в сети университета ничего не изменилось. Потом он вспомнил про пурпурный кабель. По телефону он попросил коллегу отключить этот кабель, и загрузка концентратора вернулась к норме. Затем он сказал сотруднику включить кабель обратно – перегрузки повторились. Таким образом, проблема была на другом конце – в здании больницы.

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

«Таким образом, данные продолжали передаваться по кругу, снова и снова», — говорит Бауэрс. Из-за этого концентратор в здании университета оказался перегруженным.
По словам Бауэрса, на момент его начала работы в университете вся сеть была запутана подобным образом, и ему предстояло решить, какой подход к проектированию и построению сети окажется наименее проблематичным. По крайней мере, теперь IT-отдел точно знает – сочетание запутанных кабелей и блуждающих техников не приведет к добру.

«После этого мы не сделали никаких официальных выводов, это просто был еще один пример «того, как делать не надо». Однако это происшествие наряду с еще одним инцидентом, когда пользователь непреднамеренно установил несанкционированную точку беспроводного доступа в сети университета и перегрузил концентратор, убедили Бауэрса в одном: «Я считаю, что по вине человека происходит больше ошибок, чем из-за техники».

Сэкономьте 35 долларов и потеряйте все данные

Сбои дата-центров, напрямую или косвенно вызванные желанием руководства сэкономить деньги, случаются чаще, чем этого хотелось бы. В рассматриваемом случае речь идет о экономии в $35 на ленте резервного копирования.

В 1999 году Чарльз Барбер (Charles Barber) работал менеджером технической поддержки в компании медицинского страхования (ныне не существующей), в которой независимые сервера были подключены к беговым дорожкам, считывая данные электрокардиограмм пациентов. Одним из клиентов компании было небольшое медицинское учреждение из Сент-Льюиса, где IT-работой занималась помощник по административным вопросам.

«Она была довольно компетентной, но все-таки не профессионалом в IT», — вспоминает Барбер.

Одним пятничным вечером она услышала странный шум, исходящий от сервера, и поняла, что произошел сбой в одном из жестких дисков. В субботу она приобрела новый жесткий диск и, имея диски и документацию, переустановила на него Microsoft Windows Server и Microsoft SQL Server. Барбер давал ей письменные инструкции по настройке сервера на случай подобной ситуации, и она успешно выполнила по ним настройку. («Бывало, работающие с этим инженеры обращались ко мне за помощью, а эта женщина справилась сама», — рассказал Барбер).

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

Однако во вторник она позвонила Барберу и сказала, что вся информация, восстановленная на сервер с ленты резервного копирования, утеряна.
«Она занимается полным резервным копированием системы каждый день», — объясняет Барбер, — «Но, когда она установила резервную копию, единственной информацией были результаты теста пациента в понедельник».

Так как у нее была только одна лента, она записала на нее результаты теста в понедельник. При этом она забыла, что на ленте были все данные сервера, которые оказались удалены.
«Лента стоит $35. Если бы только начальник разрешил ей купить еще одну… Вместо этого они потеряли данные за три месяца. Я не мог говорить секунд тридцать, когда понял, что произошло – абсолютно компетентному сотруднику боссы не выделили $35 на дополнительную ленту».
Физическое «падение»

Иногда инциденты буквально ждут подходящего момента, чтобы произойти, однако работающие на объекте люди не замечают угрозы, тогда как свежий глаз распознает их с первого взгляда.
Эд Галд, IT-профессионал в отставке, работал системным программистом в охранной фирме (имя которой он предпочел не называть) в Чикаго в середине 1980-х. Он работал там один месяц, когда обнаружил опасность, открытую для всех.

В этой компании программисты просто передавали свои ленты операторам дата-центра, которые устанавливали их в серверной. Однажды операторы были слишком заняты, чтобы установить ленты Галда, и он решил сделать это сам. Он прошел по дата-центру буквально несколько шагов и провалился в дыру в полу глубиной около 75 сантиметров и диаметром с пиццу. Дата-центр, расположенный на седьмом этаже здания, был установлен на фальшполах.
«Моя стопа просто провалилась», — вспоминает Галд, — «Я почувствовал боль и начал ругаться. Кто-то подошел и помог мне выбраться».

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

Кроме того, он обнаружил, что дыра была сделана для прокладки кабеля для лентопротяжного механизма, который уже был перемещен к моменту ситуации с Галдом.
Что больше всего удивило Галда, так это реакция персонала на помеху буквально в центре коридора: «Думаю, больше всего меня поразили операторы, просто обходящие ее».

Ошибки по всему миру

Если вам нужны еще свидетельства бедствий, которые люди могут создать в дата-центрах, предлагаем вам ознакомиться с собственной колонкой Shark Tank Computerworld, в которой уже много лет IT-менеджеры рассказывают истории из своей карьеры.

В середине 1980-х на базе ВВС в Аризоне надо было проложить новые кабели по всему объекту – вспоминает Джон Эйр (John Eyre), тогда инженер ВВС. Новые кабели были нужны для установки миникомпьютеров Wang – каждый компьютер подключался к терминалу коаксиальными кабелями, и производитель порекомендовал использовать двухдюймовые кабель-каналы.

По мнению Эйра, кабель-канал был слишком узок для кабеля, но, поскольку они были рекомендованы Wang и проект шел с отставанием от графика, начальники велели ему использовать эти кабель-каналы.
Когда весь кабель был проложен, начальство обнаружило, что везде, где использовался кабель-канал, кабель оказался пережат и неработоспособен. Пришлось переделывать все заново с новым кабель-каналом, что отсрочило запуск на девять месяцев.

Усвоили урок? «Торопясь успеть в срок и получить похвалу, вы только получите еще больше проблем»,

— говорит Эйр.
Вот еще небольшая подборка историй об ошибках:

• Струя фреона ударила из отсоединенного воздуховода прямо в середине дата-центра, забрызгивая ряды серверных стоек («а безумный техник пытался остановить поток голыми руками», по словам рассказчика). В итоге пришлось эвакуировать все здание.


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


• В серверной стояла температура выше 100 градусов по Фаренгейту, хотя термостат был установлен на 64 градуса. Проблема – кто-то поменял шкалу с Фаренгейта на Цельсия. Результат – расплавленные диски..

Минимизация ошибок в дата-центрах

Так что же опаснее для дата-центров – системы или обслуживающие их люди?

«Полагаю, что и то и то», — говорит вице-президент Uptime Institute Кудрицки, — «В хорошо оборудованном и грамотно обслуживаемом дата-центре техника будет работать на высочайшем уровне. На плохо сопровождаемом объекте вы неизбежно столкнетесь с проблемами».

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

Руководство не должно применять скоропалительные решения в части человеческого фактора, обуславливающего проблемы в дата-центрах, считает президент Pund-IT Чарльз Кинг. Эффективное управление персоналом требует тщательно продуманных стратегий.

«Решение любой из этих [человеческих проблем] требует системных стратегий и решений, однако программы обучения зачастую слишком узки и ориентированы на конкретные задачи», — считает Кинг.

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

Рецепт снижения количества ошибок персонала

1 июля 2010 года Uptime Institute выпустил новый набор руководств, предназначенных для помощи дата-центрам в повышении надежности за счет устранения операционных проблем, включая человеческий фактор.

Руководство Стандарт уровней дата-центра: Операционная устойчивость описывает, помимо прочего, как поведение и риски руководства дата-центра могут повлиять на долгосрочную производительность.
При неправильном управлении даже самый совершенный дата-центр будет испытывать сбои, считает вице-президент Uptime Institute Джулиан Кудрицки.

В руководстве описаны четыре аспекта, которые должны быть рассмотрены руководством для максимизации надежности дата-центра. Это работа с персоналом – не просто персонал, но квалифицированный персонал, способный выполнять задачи производительности дата-центра. Например, Uptime Institute рекомендует наличие в наиболее сложных дата-центрах (4 уровень) как минимум двух сотрудников в режиме 24/7.

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

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

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

Предлагаю добавлять сюда свои истории о проблемах в Дата-Центре из-за человеческого фактора!

Источник: computerworld