Игра с огнем: почему нельзя хранить яйца в одной корзине

Наверняка многие видели мем о том, что никаких облаков на самом деле нет – это просто чей-то чужой компьютер. И это правда, вопрос лишь в том, насколько хорошо защищен этот компьютер, и где лежат резервные копии. Недавний пожар в южнокорейском дата-центре уничтожил серверы облачного хранилища, а вместе с ними более 800 ТБ важной информации. И это мгновенно парализовало сотни государственных и общественных служб, показав, насколько хрупкой стала наша цифровая жизнь.
Многие тогда с ужасом подумали: «А что, если бы такое случилось у нас?». И вот здесь, как технический специалист, я вижу ключевое отличие «нас» от «них». В России исторически сильна идея «плана Б». У нас не принято чинить сломавшееся на «передовой» – мы просто выбросим старый блок и поставим запасной. И эта логика «запасного блока» пронизывает практически всю нашу жизнь, в том числе, IT-инфраструктуру. Поэтому у нас нет единой точки отказа, все «яйца» распределены по разным корзинам: Госуслуги размещаются в одних дата-центрах, облако Казначейства – в других, Гостех – в третьих и так далее. И чтобы отрубить все и сразу, нужно приложить действительно титанические усилия. 

Поэтому сегодня я гораздо больше боюсь не потерять свои данные, размещенные в облаке, а обнаружить их в каком-нибудь Телеграм-канале, где по номеру телефона можно «пробить» связанные мейлы, паспорта, историю перелетов и номера счетов. Утечка – вот главная современная угроза, и именно с ней борются технологии, стоящие за ключевыми государственными реестрами. 

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

Похожий подход используется в банковской сфере – так называемая «технология четырех глаз». Любое важное решение или операция (например, подписание договора или платеж) должны быть одобрены, как минимум, двумя независимыми сотрудниками. Это помогает защититься от единоличных, некомпетентных или мошеннических действий и минимизировать риски в компании. 

Другой важный момент – это децентрализованное хранение данных, при котором информация сразу распределяется по десяткам узлов. А благодаря технологиям организации децентрализованных реестров каждая запись сохраняется не во всех ЦОДах (центры обработки данных) одновременно, а реплицируется, например, на 4 или 5 из них. Это позволяет избежать многократного увеличения объема данных и при этом обеспечить высокую надежность: даже если из строя выйдет 2-3 ЦОДа, это не приведет к окончательной потере информации, как это случилось в Южной Корее. 

Разумеется, слабое звено в лице человеческого фактора полностью исключать нельзя. Если бухгалтер вашей компании не внесет запись в электронную трудовую книжку, то доказывать опыт работы придется с помощью обычных бумажных справок. То есть, надежность системы упирается в дисциплину участников. Но, как ни крути, централизованные электронные системы вроде Госуслуг существенно облегчают жизнь рядового обывателя и в масштабах страны позволяют экономить колоссальные ресурсы. Только представьте: сколько бы пришлось перевести бумаги и задействовать помещений, чтобы хранить в печатном виде несметные архивы данных. 

Так что в этом плане я спокоен: мои данные в цифровых государственных реестрах защищены надежно. А главный урок Кореи заключается в том, что нужно все время тестировать разные сценарии действий в случае отказа системы. Даже те, которые кажутся параноидальными, потому что жизнь, как показывает практика, – это самый невероятный и непредсказуемый режиссер. 

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

Будет интересно: