Нелепые случаи в IT: стихия, глупость и героизм
Современные ЦОД ориентированы на бесперебойную работу годами — 99,9% инцидентов можно предусмотреть и предотвратить. Но иногда даунтаймы случаются по воле стихии или человеческой глупости.
1. Ошибка секунды координации
Секунда координации — временной отрезок, добавляемый ко всемирному координированному времени для компенсации разницы со средним солнечным временем. Именно эта секунда в 2012 году вызвала сбои у крупных IT-систем, в результате чего оказались недоступны такие сайты, как Reddit, LinkedIn, Mozilla и другие. Были задержаны около 400 рейсов авиакомпании Quantas — ей пришлось проводить ручную проверку модулей. Многие Linux-серверы застряли в бесконечном цикле проверки даты и времени, а энергопотребление в крупных ЦОДах выросло на мегаватты.
2. Старый дедовский метод
Нет ничего более непредсказуемого, чем ураган. В октябре 2012 ураган Сэнди вызвал масштабное отключение электричества на Западном побережье США. Дата-центр Peer 1 был этому почти готов — аварийные генераторы заработали сразу после затопления подвалов и лобби. Но вода добралась до топливного насоса, который подавал горючее к генераторам. Вместо остановки систем команда дата-центра принялась вручную носить топливо на 17 этаж, где располагался бак. Так продолжалось несколько дней, пока не была запущена основная система питания.
3. Слишком буквальная миграция
В том самом 2007, который уже не вернуть, компания NaviSite купила провайдера Alabanza. Вскоре после этого появилась задача перевести клиентов из дата-центра в Балтиморе в Массачусетс. Каким образом ее решили? В точке А сервера отсоединили, загрузили в транспорт и физически отправили оборудование в точку Б. Расстояние между точками, между прочим, составляло около 675 километров. Естественно, сайты лежали до тех пор, пока все оборудование не было подключено.
Причинами аварий в IT и телекоме также становились корабли, белки и грузовики, перечислять все — не хватит даже электронной бумаги. Конечно же, можно сетовать на отсутствие у «ответственных лиц» провидческого дара, но от этого третий глаз у них, разумеется, не вырастет. Тем не менее, если ты работаешь с IT и от твоих действий зависят благополучие, спокойствие, надёжность виртуальной инфраструктуры, а иногда и жизни тысяч человек, необходимо оставаться профессионалом: находчивым, целеустремленным и ответственным. Тогда удастся если и не предотвратить аварию, то, как минимум, снизить влияние её последствий.
Современные ЦОД ориентированы на бесперебойную работу годами — 99,9% инцидентов можно предусмотреть и предотвратить. Но иногда даунтаймы случаются по воле стихии или человеческой глупости.
1. Ошибка секунды координации
Секунда координации — временной отрезок, добавляемый ко всемирному координированному времени для компенсации разницы со средним солнечным временем. Именно эта секунда в 2012 году вызвала сбои у крупных IT-систем, в результате чего оказались недоступны такие сайты, как Reddit, LinkedIn, Mozilla и другие. Были задержаны около 400 рейсов авиакомпании Quantas — ей пришлось проводить ручную проверку модулей. Многие Linux-серверы застряли в бесконечном цикле проверки даты и времени, а энергопотребление в крупных ЦОДах выросло на мегаватты.
2. Старый дедовский метод
Нет ничего более непредсказуемого, чем ураган. В октябре 2012 ураган Сэнди вызвал масштабное отключение электричества на Западном побережье США. Дата-центр Peer 1 был этому почти готов — аварийные генераторы заработали сразу после затопления подвалов и лобби. Но вода добралась до топливного насоса, который подавал горючее к генераторам. Вместо остановки систем команда дата-центра принялась вручную носить топливо на 17 этаж, где располагался бак. Так продолжалось несколько дней, пока не была запущена основная система питания.
3. Слишком буквальная миграция
В том самом 2007, который уже не вернуть, компания NaviSite купила провайдера Alabanza. Вскоре после этого появилась задача перевести клиентов из дата-центра в Балтиморе в Массачусетс. Каким образом ее решили? В точке А сервера отсоединили, загрузили в транспорт и физически отправили оборудование в точку Б. Расстояние между точками, между прочим, составляло около 675 километров. Естественно, сайты лежали до тех пор, пока все оборудование не было подключено.
Причинами аварий в IT и телекоме также становились корабли, белки и грузовики, перечислять все — не хватит даже электронной бумаги. Конечно же, можно сетовать на отсутствие у «ответственных лиц» провидческого дара, но от этого третий глаз у них, разумеется, не вырастет. Тем не менее, если ты работаешь с IT и от твоих действий зависят благополучие, спокойствие, надёжность виртуальной инфраструктуры, а иногда и жизни тысяч человек, необходимо оставаться профессионалом: находчивым, целеустремленным и ответственным. Тогда удастся если и не предотвратить аварию, то, как минимум, снизить влияние её последствий.