С распространением гибридных вычислительных платформ, которые сочетают собственную физическую серверную инфраструктуру той или иной компании внутри корпоративного ЦОД с IT-ресурсами стороннего провайдера облачных сервисов, увеличивается риск успешных хакерских атак с сопутствующим финансовым и репутационным ущербом. Но физическая инфраструктура также уязвима: недостаточно внимание техобслуживанию оборудования или неожиданный природный катаклизм вполне могут обернуться еще более плачевными последствиями. Подтверждением справедливости данных утверждений выступают свежие примеры Telstra, Heart Internet и GitHub.
“Человеческий фактор” и проблемы с сетевой инфраструктурой в ЦОД Telstra
Пресловутый “человеческий фактор” стал причиной проблем с сетевой инфраструктурой в дата-центре крупнейшей австралийской телекоммуникационной компании Telstra. Как сообщает издание Sydney Morning Herald, мобильная сеть телекоммуникационной компании ушла в офлайн в минувший вторник после того, как инженер компании перевел неисправный сетевой узел в автономный режим без предварительной активации резервного узла.
В итоге миллионы клиентов компании лишились возможности совершать звонки и доступа к услугам передачи данных через мобильную сеть Telstra. Проблема затронула все основные города Австралии, включая Брисбен, Сидней, Мельбурн, Аделаида и Перт. Согласно информации, распространяемой пресс-службой Telstra, отключение длилось около четырех часов. В течение этого времени тысячи людей успели выразить свое разочарование компанией через социальные сети.
22-часовой даунтайм в “одном из наиболее эффективных и надежных ЦОД Европы”
Поставщик услуг веб-хостинга Heart Internet с головным офисом в Ноттингеме (Великобритания) оказался не в состоянии обеспечить надлежащий сервис своим клиентам из-за отключения электроэнергии в дата-центре, который специалисты компании до недавнего времени без лишней скромности называли “одним из наиболее эффективных и надежных ЦОД в Европе”.
Даунтайм ЦОД продлился около 22 часов. Представители Heart Internet подтвердили, что в среду 10 февраля произошел сбой в инфраструктуре подачи электропитания одного из дата-центров британцев, после чего на объекте началось проведение аварийных работ для исправления проблемы. Это вызвало перебои в предоставлении услугах клиентам. Интересно, что инцидент сопровождался DDoS-атакой.
Представители компании также заявили, что провайдер хотела бы оставаться предельно “открытыми и прозрачными при общении с клиентами”, обязавшись впоследствии опубликовать точную информацию о причинах неисправности. По предварительным данным, проблемы в дата-центре были обусловлены неисправностью модуля передачи нагрузки с центральной сети (первичного источника питания) на ИБП. Этот модуль не смог выполнить свою задачу после отключения подачи электричества посредством центральной сети, которое продлилось менее 9 минут.
Прекращение подачи электроэнергии в дата-центр увело GitHub в офлайн
Самый популярный интернет-репозиторий для проектов с открытым исходным кодом GitHub ушел в офлайн и был недоступен в течение двух часов из-за отключения подачи электроэнергии в дата-центре, обслуживающем этот интернет-сервис.
Как следствие, сайт GitHub.com был недоступен в течение двух часов и шести минут. Как сообщается, даунтайм произошел в дата-центре партнера GitHub, расположенном в Сан-Франциско, штат Калифорния (США) .
Вместо заключения
Пользователи проводят все больше времени интернете. Поэтому когда дата-центр выходит из строя, подобный инцидент может негативно отразиться абсолютно на всем: от личных коммуникаций до состояния транспортной системы государства. Согласно данным организации Uptime Institute, человеческие ошибки являются причиной почти трех четвертей всех даунтаймов ЦОД. Тем не менее, нельзя сбрасывать со счетов и многие другие факторы такие как киберпреступность и стихийные бедствия. Даже, казалось бы, безобидная мышь, грызущая силовой кабель, может вызвать серьезные повреждения инфраструктуры ЦОД.
Учитывая финансовые затраты и репутационный ущерб, связанный с незапланированным простоем дата-центра, операторы, проектировщики и строители ЦОД должны делать все от них зависящее для минимизации даунтайма. Следует использовать современные стандарты, актуализировать план действий на случай ЧП и не забывать про плановое техобслуживание. 100-процентной безопасности никто не гарантирует, но при желании риск даунтайма вполне может быть сведен к минимуму.
