(Прим. перев. Переводчик не считает уместным использовать традиционное название «информационно-телекоммуникационная сеть Интернет» не то что в разговорной речи, а даже в деловой переписке и официальных документах. Переводчик счел возможным использовать слово «интернет» как склоняемое существительное мужского рода, отойдя от спорной традиции считать это именем собственным, идущей от отписки Правительства одному известному российскому блогеру почти 20 лет назад)
Сейчас, когда наши платформы работают в обычном режиме после вчерашнего сбоя, я подумал, что стоит рассказать немного подробнее о том, что произошло и почему. И, что наиболее важно, какие уроки мы извлекли из этого.
Этот сбой был вызван системой, которая управляет пропускной способностью нашей глобальной магистральной сети. Магистральная сеть — это сеть Facebook, соединяющая все вычислительные мощности Facebook вместе. Она состоит из десятков тысяч километров оптических кабелей, пронизывающих земной шар, и соединяющих все наши датацентры.
Эти датацентры бывают совершенно разными. Некоторые из них представляют собой массивные здания, в которых размещаются миллионы машин, которые хранят данные и выполняют тяжелые вычислительные задачи, поддерживающие работу наших платформ. Другие, менее мощные датацентры, соединяют нашу магистральную сеть с интернетом и пользователями наших платформ.
Когда вы запускаете одно из наших приложений, и открываете вашу ленту, или сообщения, запрос данных приложения отправляется на ближайший узел, откуда передаётся напрямую по магистральной сети в один из крупных датацентров. Здесь информация, необходимая вашему приложению, извлекается, обрабатывается и отправляется обратно по сети на ваш телефон.
Поток данных между всеми этими вычислительными устройствами управляется маршрутизаторами, которые определяют, куда отправятся те или иные данные. В ходе повседневной эксплуатации нашим инженерам регулярно требуется отключать части магистральной сети для обслуживания — например, для ремонта оптического кабеля, увеличения пропускной способности или обновления программного обеспечения маршрутизатора.
Это и стало причиной вчерашнего сбоя. Во время плановых работ по обслуживанию в целях оценки пропускной способности магистральной сети была дана команда, которая непреднамеренно отключила все соединения в магистральной сети. Таким образом были отключены все наши датацентры по всему миру. Наши системы имеют специальную защиту от таких ошибок, но ошибка в системе защиты помешала остановить выполнение команды.
Итак, наши датацентры были полностью отключены от интернета и друг друга. И эта полная потеря связи вызвала вторую проблему, которая усугубила ситуацию.
Одной из задач наших небольших датацентров является обрабатывать запросы DNS. DNS - это адресная книга в интернете, позволяющая преобразовывать простые имена сайтов, которые мы вводим в браузеры, в определенные IP-адреса серверов. (Прим.перев. Далее автор вдался в сложные технические детали, которые он упростил спорным образом. Переводчик взял на себя смелость исказить оригинальный текст автора, дополнив его своими объяснениями). Превращением простых, касающихся наших платформ, имен в IP-адреса занимаются наши собственные, так называемые авторитативные, DNS-сервера. Крупные DNS-сервера, обслуживающие миллиарды запросов по всему миру, каковыми являются конечно же и DNS-сервера Facebook, обычно раскиданы по всему миру, но имеют одно и тоже множество IP-адресов, где бы они не находились. Провайдеры отправляют запросы к ближайшему серверу. Распространение информации о нахождении IP-адресов осуществляется между провайдерами, а иногда и внутри одного провайдера, по специальному протоколу — BGP.
Чтобы избежать задержек при попытках запросов к неработающим DNS-серверам, наши серверы проверяют свою доступность и отключают анонсирование своих IP-адресов по BGP, если обнаруживают, что доступность плохая. Критерием доступности для нашего DNS-сервера является доступность наших датацентров с DNS-сервера (прим. перев. скорее всего это связано с невероятным вовлечением DNS во внутренние инструменты компании, о чем говорится чуть ниже по тексту). В результате недавнего сбоя, вся наша магистральная сеть оказалась недоступной. Наши DNS-серверы предсказуемо посчитали это причиной прекратить анонсы BGP и «пропасть с радаров» (Прим.перев. Здесь я заканчиваю вносить Божью Искру в текст автора). В итоге, DNS-сервера функционировали, но не были доступны. Это сделало невозможным поиск наших серверов в интернете.
Это всё произошло очень быстро. И пока наши инженеры работали над выяснением того, что происходит и почему, они столкнулись с двумя большими препятствиями. Во-первых, невозможно было получить доступ к нашим датацентрам, потому что магистральная сеть вышла из строя. Во-вторых, произошла полная потеря DNS. Многие наши инструменты, в том числе и инструменты по исследованию аварийных ситуаций, полностью зависели от DNS.
Наш основной и запасной доступы во внутреннюю сеть не работали, поэтому мы отправили инженеров физически в датацентры, чтобы они выяснили проблему и перезапустили систему. На это потребовалось время, потому что наши объекты спроектированы с учетом высокого уровня физической и системной безопасности. В них сложно попасть физически, а как только вы окажетесь внутри, будет сложно получить доступ внутрь систем, даже если у вас есть физический доступ к оборудованию. Потребовалось дополнительное время для активации протоколов безопасности. И только после этого мы смогли подтвердить проблему и подключить нашу магистральную сеть.
К счастью, мы были хорошо подготовлены к подобным ситуациям, благодаря «штормовым» учениям, которые мы проводим уже долгое время. Во время учений мы имитируем серьёзный сбой, отключая сервис, датацентр или даже целый регион, и проводим стресс-тестирование задействованной инфраструктуры и программного обеспечения. Учения дали нам навыки, чтобы вернуть работоспособность наших платформ и осторожно управлять нарастающей нагрузкой. В итоге, наши сервисы восстановились достаточно быстро без каких-либо глобальных сбоев. И хотя мы раньше не проводили учений, имитирующих отключение всей магистральной сети, мы будем искать способы имитировать эту ситуацию в дальнейшем.
Каждый крупный сбой, подобный этому — это возможность учиться и стать лучше. И нам есть чему поучиться здесь. После каждого сбоя, большого или маленького, мы проводим исследование, чтобы понять, как сделать наши системы более устойчивыми. Этот процесс уже идет.
Мы проделали огромную работу для предотвращения несанкционированного доступа к нашим системам. Было интересно наблюдать, как это замедлило нас во время восстановления после сбоя, вызванного не злонамеренными действиями, а нашей собственной ошибкой. Я считаю, что подобный компромисс того стоит — повышенная повседневная безопасность, приведшая к медленному восстановлению после, надеюсь, редкого сбоя, подобного этому. С этого момента наша задача — усилить тестирование, учения и общую устойчивость, чтобы подобные события происходили как можно реже.
