Мы же рассмотрим создание второй копии, необходимой для продолжения работы над проектом. Статья ориентирована на разработчиков, только вступающих на тернистый путь управления качеством. И бесполезна тем, кто уже знает, что «вторая копия» на самом деле не совсем вторая, и не совсем копия.
Разделяй и властвуй
Индустрия рекомендует 3-4 независимых окружения (environment) для информационных систем. Кроме вышеупомянутого рабочего, это окружения: разработки (development), тестирования (test) и симуляции (staging).
Так как развертывание и обслуживание каждого окружения суть прямые расходы, то их применение определяется спецификой проекта. Чем выше стоимость ошибки в рабочем окружении, тем больше окружений включается в процесс разработки. И наоборот. Последние два могут быть заменены одним окружением тестирования, если процесс не предусматривает отдельные приемочные (acceptance) тесты или демонстрацию. Аналогично, все три могут быть одним окружением разработки, если процесс не предусматривает регрессионное (regression) тестирование или непрерывную интеграцию (continuous integration). В пределе, всех трех может не существовать вовсе. Например, для статичного сайта-визитки неизвестной компании, обновляемого по ftp.
Кроме игр с функционалом и устранением ошибок, наличие независимых окружений позволяет масштабировать команду проекта. Когда программист программирует, а администратор администрирует, это хорошо. Это называется разделением обязанностей (segregation of duties). Рекомендуется замыкать разработчика на окружение разработки, а тестировщика на окружение тестирования. Считается, что такой организационно-технический подход снижает операционные риски (operational risk), поэтому сильно радует владельцев информационных систем.
Так что там со второй копией? Самый простой и очевидный способ ее получить — скопировать резервную. И из нее уже поднять любое дополнительное окружение где нужно.
Нельзя просто так взять
и скопировать базу данных из рабочего в окружение разработки или тестирования.
Дело в том, что в настоящее время ключевым риском информационных систем является утечка непубличных данных. Например, в соответствии с исследованием Verizon’s 2013 Data Breach Investigations Report, из 47 тысяч инцидентов, 69% утечек данных были обнаружены третьими лицами. То есть, утечка данных обнаруживается где-то сторонними людьми, в том числе нашими с вами клиентами. А более половины случаев инсайда приходится на бывших сотрудников, которые воспользовались своими забытыми активными учетными записями или бэкдорами.
Следовательно, прямой доступ в рабочее окружение должен быть только у тех, кто непосредственно с ним работает. Например, у администратора базы данных. Но никак не у всех программистов компании «потому что так проще дебажить». Да, Соглашение о Неразглашении (non-disclosure agreement, NDA) в контракте — эта хорошая превентивная мера. Но лишь организационная, а поэтому недостаточная. Организационные меры должны быть подкреплены техническим контролем.
Данные становятся дороже в обслуживании
К ним предъявляется все больше требований защиты. От добровольного соответствия (например, стандартам ISO27K) вплоть до сертификации местным регулятором (в ЕС это Office of the Data Protection). Да, в конечном счете, все сводится к минимизации ущерба компании от утечки непубличных данных. Причем, защита данных о людях уже затмила собой защиту коммерческой тайны. А использование облачных хранилищ неизвестно где и обслуживание их неизвестно кем, только добавляет проблеме остроты.
Стандартной практикой защиты данных вне рабочего окружения является их анонимизация (sanitization). Данные, подлежащие защите, группируются по типам. Например, номер банковского счета, дата рождения, фамилия, зашифрованный пароль. Далее к ним применяется одна из техник анонимизации — полная или частичная маскировка, очистка, перемешивание, подмена, шифрование или хэширование. Рассматривать их тут не будем, это тема отдельной статьи. В качестве бонуса, если вы однажды будете писать анонимизацию счетов, обратите внимание на Sample Account Data. Там есть как валидные, так и невалидные банковские данные по странам.
Данные становятся больше по объему
Ручной метод развертывания тестовой базы представляет собой:
- копирование дампа рабочей базы на тестовый сервер;
- восстановление базы данных из него;
- выполнение скрипта анонимизации.
Для передачи «чистой» базы данных дальше, в окружение разработки или вовне, делается ее резервная копия.
Преимущества такого подхода очевидны: высокая скорость на малых объемах и согласованность реляционных данных на выходе. Но есть и недостатки, в полный рост проявляющиеся на объемах от десятков гигабайт:
- используется промежуточный файл дампа, передающийся по сети;
- полная копия обычно избыточна для целей разработки или тестирования;
- до анонимизации данные подвержены утечке как из файла дампа, так и из базы;
- cкрипт анонимизации является отдельным элементом, в случае ошибки данные остаются прежними.
Решение
В рамках подготовки к экзамену по Java была написана утилита org.crystalcopy для MySQL, лишенная этих недостатков и достоинств.
Утилита поддерживает таблицы, записи, триггеры, хранимые процедуры, индексы и внешние ключи. Подходит для:
- частичного копирования базы данных в другую базу или файл;
- полного копирования базы данных в другую базу или файл;
- копирования только схемы базы данных в другую базу или файл;
- анонимизации средствами SQL без передачи данных по сети.
При частичном копировании реляционные связи между полями сохраняются, однако согласованность всех записей не гарантируется. Скорость полного копирования из одной базы данных в другую на моей машине составляет порядка 2Гб в час. Утилита запускается из командной строки, ее можно встроить в билд непрерывной интеграции. Доступна в Интернет по некоммерческой лицензии.
Статус — бета. Так что буду счастлив получить ваши отзывы!
This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий