Упавшие сервера: самые необыкновенные истории

Читайте также

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

Самые частые причины падения серверов и отказа сервисов

Для начала мы решили выяснить основные причины падения сервера и какие из них встречаются чаще остальных. Занимают лидирующие позиции: человеческий фактор, вредоносные атаки, внешнее воздействие на оборудование. Представляем вам ТОП-5 самых частых причин падения сервера.

1. Проблемы “внешнего мира”. 

К этой категории относится все, что связано с внешними факторами, которые могут отрицательно повлиять на техническое оборудование: ураган, землетрясение, апокалипсис и более обыденные проблемы, которые приведут к повреждению оптоволоконного кабеля. Все, что происходит вокруг, может сказаться на работе сервера и вывести его из строя. С этим бороться бесполезно, предсказать подобное не сможет никто. В такой ситуации вы вправе потребовать от “системного партнера” только оперативности решения вопроса, но поверьте, он уже бегает, словно ошпаренный и ваши претензии только добавят масла в огонь. 

“Однажды мы бухали в одной большой телекоммуникационной компании. Зимой. На втором этаже. А прямо под нами, на первом, находился узел связи одного большущего банка. Так вот. Побухали, и ушли. Только форточку забыли закрыть. Была зима и минус 40 градусов. Все это было перед праздником 23 февраля. Три дня форточка открыта была, напомню, минус 40. Ну и разморозились батареи к чертям. И залило узел связи этого большущего банка. Так пенсионеры трех регионов получили пенсию на день позже. Бывает”.

2. Начальная школа хакеров.  

Порой начинающие хакеры решают развлечься и проверить свои навыки, а заодно и ваши нервы, устраивая DDoS-атаки на сервера. Многие из них ликвидируются автоматически, технический прогресс не стоит на месте, но случается так, что за работу берутся адепты хакерского дела и с помощью “темной магии” проводят DDoS-атаку исполинского размера. Для решения этой проблемы всегда требуется время специалистов, остается только ждать завершения баталий и приведения работы сервисов в нормальный режим. Негативные реакции и испорченное настроение - норма, но не выливайте их на спеца, только отвлечете, а он и так вовсю занят “фехтованием на световых мечах” за ваше счастье и благополучие.

“Году примерно в 2011 в один из наших серверов хостинга прилетела крупномасштабная по тем временам DDoS-атака. Атакующие, вероятно, были крайне заинтересованы в неработоспособности информационного ресурса одного из наших клиентов, но какого конкретного сайта, выяснить было крайне сложно. Задача атаки сводилась к тому, чтобы полностью забить все наши каналы паразитным трафиком. Да настолько, чтобы полностью парализовать вообще всё, что у нас размещалось. Мы довольно быстро изолировали атакованный сервер и вынесли его внешнюю связность в отдельный канал, чтобы все остальные серверы работали без проблем. На сервере размещалось более тысячи клиентов и почти две тысячи сайтов, и какой именно из них был атакован сетевым флудом неясно. Перебои в работе продолжались больше суток. В 2017 году я смотрю на такие атаки совершенно иначе. Нападений подобного уровня у нас иногда случается по несколько штук в неделю и большинство из них фильтруется автоматикой без вмешательства наших администраторов. Но путь от первой такой атаки и до сегодняшнего состояния занял 6 лет, и до сих пор мы периодически что-то совершенствуем”.

3. Человеческий фактор. 

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

“Давным давно одна компания давала приходящим сотрудникам в свободный доступ компьютеры, поскольку с такой техникой тогда было напряженно. Можно было зайти в интернет ненадолго, договоры поправить, распечатать чего по работе. И стоял у них, как обычный комп - “главный”, это был сервер, с договорами и т.п. А чего пропадать рабочему месту? Кто что сделает без прав админа? Так вот, одной девочке по учебе надо было научиться Linux ставить, ну и пришла она в эту компанию, попросила помочь, говорит: “Можно я у вас потренируюсь?”. Админ ей рукой на компы махнул и сказал: “Ставь, что хочешь, у нас все равно все тачки с сервера зеркалятся, потом оно “бутнется” оттуда и все”. И девочка поставила свой Linux. На сервер! Научилась, что тут скажешь. Сказала, что он самый большой и красивый был”.

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

4. Не железное железо. 

Сколько раз вы могли слышать фразу: “Техника подвела”? Как бы банально это не звучало, но это одна из самых распространенных причин отказа сервисов. Техническое оборудование имеет свойство изнашиваться или изначально может быть бракованным. Опять же, можно следить за каждой пылинкой, которая приземляется на оборудование, моментально убирать ее, надеясь, что все будет хорошо, но никто не гарантирует, что в один момент оборудование не вспыхнет синим пламенем по неизвестными никому причинам, разве что только производителю техники.

В одном банке был сервер с материнской платой “Intel SE7520BD2”, и в один прекрасный летний день в этом сервере вдруг сдохло 8 гигабайт памяти из 32. Инженеры банка, конечно, быстро поменяли память, которая снова сдохла через 3 минуты после запуска сервера. Инженеры снова поменяли память и дохнуть начало уже по 16 гигабайт. Так инженеры спалили 192 гига памяти, после чего решили-таки почитать эти ваши “интернеты” и обратились к поставщику. А все произошло потому, что не прочитали про отзывную кампанию на эти материнские платы, в которых попадались бракованные конденсаторы в контроллере питания памяти”.

5. Температура. 

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

“Купил один заказчик себе дорогущие серверы “IBM Power” под SAP, но куда же их девать? Шумят да греются. Нужен ЦОД! Нашли комнатку 4 квадратных метра, под одну стойку, поставили два кондиционера. Помолились и запустили. Тут на вторые сутки посыпались “алярмы”! Смотрят, железки работают кондиционеры дуют холодом, а “алярмы”, словно по расписанию, раз в 45 минут. В общем - магия! Искали причину - ничего не нашли,  так как хозяйство на гарантии. Позвали спецов - та же история! Через месяц стало ясно, что все из-за малой площади помещения. “Power” регулярно скидывал кучу тепла по сработке автоматики, от чего случался перегрев по датчику температуры внешнего воздуха в помещении, в результате чего кондиционеры начинали все неистово  охлаждать. Пока охлаждали - “алярмы” сыпались”.

Читайте также

Как с этим бороться?

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

“Основной метод борьбы с этим явлением - грамотный выбор инженерных решений при создании ЦОД и квалифицированная эксплуатация оборудования, в т.ч. внедрение систем проактивной диспетчеризации”.

“Нужно читать руководящие документы и стандарты. И следовать им. Понимаю, это трудно, но индустрии "дата-центров" (ранее - мейнфреймов и т.п.) более 50 лет. И очень умные люди уже подумали о том, что и как нужно делать. Наступили на грабли и описали все случаи, которые с ними случались. Главный руководящий документ называется TIA-942. И этот документ, кажется, даже переведен на русский. Если вы никогда не слыхали об этом документе, то никогда, ни при каких обстоятельствах даже не думайте заводить "собственный сервер". Просто отдайте эту функцию профессионалам. Проверить профпригодность можно вопросом: "а что такое TIA-942?".

“Думаю, что пока эту проблему не побороть никак. Современный тренд такой, что от падения серверов защищаются тем, что строят распределённые системы, которые не обращают на это внимания, потому что работают сразу на большом количестве оборудования”.