.png "Дмитрий Волков")
Не за горами время, когда корпорации будут измерять объемы доступных им данных в бронтобайтах (примерно 290 байт), однако уже сегодня непонятно, как надежно хранить и нынешние экзабайты. В стремительно меняющемся мире с его BYOD, облаками и Большими Данными старые понятия быстро теряют свою прежнюю четкость, и далеко не ясно, какую информацию надо сохранять, что понимать под резервированием, как обеспечить полное восстановление данных после сбоев и т. д. Традиционные средства поддержки непрерывности бизнеса, включающие известные и очевидные технологии резервного копирования и дедупликации, пасуют перед большими расстояниями, разделяющими ЦОД, активными злоумышленниками с их атаками типа Advanced Persistent Threat, огромными массивами данных, для копирования которых уже нет свободных окон, причем все это на фоне того, что пользователям требуется синхронизация данных на различных устройствах, включая мобильные.
Какие сегодня имеются системно-программные решения защиты инфраструктуры бизнеса? Как гарантированно сохранить критическую для компании или организации информацию? В чем особенности резервирования в облаках и какие функции требуются от современных средств мониторинга и анализа работы ИТ-систем? Все это обсуждают авторы данного выпуска журнала, посвященного вопросам сохранности информационных активов предприятия и технологиям обеспечения непрерывности бизнеса.
По данным аналитиков Forrester, 72% всех приложений компаний считаются для нее критически важными, и, учитывая, что в среднем потери от часа простоя информационной системы составляют сегодня 145 тыс. долл., предприятия готовы инвестировать в решения по обеспечению их доступности и сохранности. Однако старые парадигмы (например — чем больше копий, тем лучше) сегодня не работают: каждая новая копия усугубляет проблему стоимости и надежности. Инкрементальное или блочное копирование тоже не всегда помогает, хотя и позволяет уменьшить объем данных. Как отмечает Леонид Черняк, при организации хранения последовательно измененных версий одного и того же файла компактное размещение не будет достигнуто, если речь идет о реляционных СУБД, таблицы которых, как правило, размещаются на носителях построчно. Количество идентичных блоков в этом случае будет минимально, что приведет к низкому эффекту от дедупликации. Выходом, по мнению Владимира Гречушкина, может быть изменение хранения с построчного на поколоночное, с последующим сжатием.
Однако мало организовать быстрое и оптимальное резервное копирование, гарантирующее восстановление, — необходимо решить вопрос обеспечения конфиденциальности информации в растущем потоке корпоративных данных. Как отмечают Андрей Данкевич и Александр Насонов, для устранения утечек ценных данных требуется мониторинг всех их потоков внутри компании, применение автоматизированных средств определения тематики сообщения, а также специализированных технологий анализа и категоризации неструктурированных данных.
Про облака говорят уже давно, но, как отмечает Евгений Пухов, иногда забывают, что облака — это не только новые возможности, но и новые проблемы. Так, виртуализация породила новые требования к способу взаимодействия компонентов ИТ-инфраструктуры, для обеспечения которого нужны новые решения по хранению, защите, резервному копированию и повышению доступности. Такие решения должны позволять, например, на нескольких территориально разнесенных ЦОД организовать работу с одним массивом данных, перемещение тысяч виртуальных машин и петабайтов информации, перераспределение ресурсов по регионам с целью их увода, например, из мест, где произошло стихийное бедствие, выросло энергопотребление или вычислительная нагрузка.
Очевидно, что не существует какого-то одного «волшебного» инструмента или метода, позволяющего обеспечить надежность сложного приложения, — для его создания нужны качественные инструменты, высокая квалификация программистов и тщательно контролируемый процесс разработки. В этой связи читателям журнала будет интересна статья «Программы для посадки на Марс», раскрывающая ключевые моменты процесса создания надежных программ на примере проектов управляющего ПО для марсианских автономных аппаратов, любой сбой в системе которых может привести к потере корабля. Например, сложно следовать принципу дублирования в случае ПО — выполнение одного и того же кода на нескольких экземплярах процессора не защитит от программных сбоев. Значит, дублирующий код должен быть иным — в программах управления посадкой, которые в НАСА называют «семью минутами ужаса», резервный процессор исполняет упрощенную версию посадочного ПО, называемую «последний шанс».
Рассуждая над вопросом, как просто, стабильно, безопасно и недорого обеспечить сохранность информационных активов предприятий, авторы журнала приходят к выводу, что создание надежного хранилища для бронтобайта корпоративных данных невозможно без тесной увязки существующих и новых аппаратно-программных решений, а главное — грамотных политик работы с информацией, построенных на анализе информационных потребностей компании, однако сегодня бизнес-культура российского бизнеса, как правило, позицию аналитика не предполагает.
