«Не кладите все яйца в одну корзину»

ЧП в мире глобальных коммуникаций имело множество последствий, начиная от падения стоимости акций цифровых гигантов на биржах и заканчивая пошатнувшимся психологическим здоровьем некоторых пользователей. Но профессиональных оценок причин случившегося было не так много. Можно ли уберечься от подобных случаев глобальной цифровой турбулентности? Какие угрозы безопасности несут ошибки софта? Об этом «Армейский стандарт» спросил ведущего эксперта в IT-области, руководителя DZ Systems и создателя «Яндекс.Маркета» Дмитрия Завалишина.

— Компания Цукерберга назвала предварительную причину — сбой маршрутизаторов. Можно для большого количества чайников объяснить, что это такое?

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

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

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

— Можно ли сказать, что была умышленная или неумышленная ошибка в программе?

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

— Facebook пока отрицает внешнее воздействие в систему. Такому выводу можно доверять? Можно ли с гарантией в 100% определить, какое было воздействие — изнутри или извне?

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

— Почему «легли» другие сети?

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

— Какой вывод Россия должна сделать из этой ситуации?

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