Настоящий CTO: думай как технический директор - Алан Уильямсон

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

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

8.4.5. Облако и аварийное восстановление

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

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

8.5. Работа с данными

Данные – это кровь нашей отрасли. Они поступают в организацию и выходят из нее, генерируют данные о движении данных, перерабатываются в другие данные, и все это необходимо сортировать, преобразовывать, хранить и обрабатывать. Данные – это больше чем файлы на жестком диске или строки в таблице. У них есть значение, контекст и ценность. И наоборот, в то же самое время они могут быть избыточными, отвлекающими и бесполезными. Необходимо уметь отличать полезные данные от информационного шума.

Раньше хранение данных стоило очень дорого. Сейчас, в облачной парадигме бесконечного хранилища, хранить данные стало дешево и просто как никогда (и стоимость продолжает снижаться с каждым годом). Из этого вытекают два вопроса: (а) стоит ли хранить вообще все и (б) как организовать хранение, чтобы данные оставались доступными?

Эффективная работа с данными и их защита – непростая задача. Безопасности в этой книге посвящена отдельная глава, поэтому сейчас мы лишь слегка коснемся некоторых ее вопросов. За данные компании отвечает CTO, и, по моему опыту, технические директора организуют работу с данными не так хорошо, как могли бы, в основном потому, что не понимают истинной ценности этого актива или не знают обо всех доступных инструментах и методах.

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

8.5.1. Хранение

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

Как мы уже сказали, хранение данных никогда не стоило так дешево, как сейчас, и больше нет оправданий для того, чтобы не сохранять их. Но что это на самом деле означает? И действительно ли нужно хранить всё? Чтобы ответить на эти вопросы, для начала рассмотрим основные типы хранилищ, в которые можно загружать данные:

• Файлы/папки. На сегодняшний день файл – автономный именованный набор данных, находящийся на физическом носителе, – по-прежнему является наиболее универсальным способом хранения данных. Существует множество популярных форматов файлов, таких как JSON, XML, CSV и TXT, и этот способ хранения данных универсален, потому что почти каждый инструмент способен открывать файлы и работать с ними. Файлы легко копировать, шифровать и перемещать, и ими легко делиться. Не существует ограничений на виды данных, которые можно хранить в файле.

• Реляционные хранилища (базы данных SQL). Данные, которые имеют общие атрибуты (столбцы) и связаны друг с другом (строки), прекрасно вписываются в структуру, которую мы называем таблицами. Таблицы могут быть связаны с другими таблицами, а наборы таблиц известны как базы данных. К таблицам можно выполнять запросы, используя специальный псевдоязык (SQL), который описывает команды для получения данных, их изменения или записи в таблицу новых данных. Это очень популярный механизм для хранения больших объемов одинаково структурированной информации.

• Хранилища NoSQL. В хранилищах NoSQL, или документных, отсутствуют структурные ограничения, свойственные реляционным хранилищам. В них сохраняется только то, что вы передадите, и не остается пустот на месте отсутствующих данных, как в реляционных СУБД. Группы документов образуют коллекции, в которых каждый документ может значительно отличаться от другого.

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

• Корпоративное хранилище данных (Data warehouse). Хранилище – это специально разработанная база данных, которая в основном используется для анализа и бизнес-аналитики (business intelligence, BI). В нем хранятся большие наборы данных, организованных таким образом, чтобы упростить составление отчетов и годовой анализ.

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

Файлы и базы данных распространены повсеместно. В каждой организации есть своя база данных – SQL Server, Postgres, MySQL или Oracle. Тем не менее зачастую БД плохо организованы, например, одна БД может использоваться одновременно для нескольких областей (скажем, для клиентского веб-сайта и для предоставления отчетов о состоянии бизнеса). Вместо этого у каждой области бизнеса должна быть своя БД, и данные должны реплицироваться между ними. Таким образом, когда финансовый директор задумает сформировать масштабный отчет о квартальных продажах, он не положит весь сайт.

Базы данных NoSQL (такие как MongoDB, CouchDB, DynamoDB и Elasticsearch) становятся все более популярными, особенно на ранних этапах разработки проектов, когда еще нет полного представления об итоговой структуре. Их производительность с годами увеличилась настолько, что при правильно выбранной организации данных они способны работать так же эффективно, как и их реляционные аналоги. Будьте осторожны и не увлекайтесь: некоторые команды строят всю систему на архитектуре NoSQL. В этом случае возрастает риск нарушения единообразия данных (то есть в разных документах одни и те же данные будут храниться в разных форматах, например, число 2 может быть представлено в строковом и целочисленном форматах, потому что где-то при обработке данных они не были приведены к одному виду). NoSQL не обеспечит вам ни целостность, ни единую структуру данных.

Озеро данных (Apache Hadoop, Amazon S3) – это одно большое пространство для хранения файлов. Однако это не просто крупное файловое хранилище. В озере данных есть инструменты и механизмы для просмотра файлов, чтобы вы могли выбрать то, что вам нужно. Например, оно отлично подходит для размещения журналов продакшена. Вам не нужно беспокоиться о формате файлов, он может меняться со временем. При необходимости озеро данных предоставит удобный механизм для перебора файлов журналов, чтобы найти заданное ключевое слово или строку (этот подход называется map/reduce).

Наконец, корпоративное хранилище данных (Amazon Redshift, SQL Server) – это место, куда поступают данные, необходимые для отчетности.