Выводим MySQL из окружения

    Как только ваша информационная система становится рабочей (prоduction), появляется необходимость иметь как минимум две копии ее базы данных. Первая, резервная, с некоторой частотой создается при помощи штатных утилит и представляет собой согласованный дамп (consistent dump). Цель его создания — восстановление системы после сбоя (disaster recovery).

    Мы же рассмотрим создание второй копии, необходимой для продолжения работы над проектом. Статья ориентирована на разработчиков, только вступающих на тернистый путь управления качеством. И бесполезна тем, кто уже знает, что «вторая копия» на самом деле не совсем вторая, и не совсем копия.

    Разделяй и властвуй


    Индустрия рекомендует 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Гб в час. Утилита запускается из командной строки, ее можно встроить в билд непрерывной интеграции. Доступна в Интернет по некоммерческой лицензии.

    Статус — бета. Так что буду счастлив получить ваши отзывы!
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 30

      +1
      Вы какими-то странными путями идете. Зачем копировать БД с продуктива в UAT/интеграционное/разработческое, если маршрут развертывания строго обратный? Просто начинайте работать сразу в разработческом контуре, а потом следующие контура разворачивайте/мигрируйте скриптами. Тогда у вас не будет проблемы утечки данных.
        0
        Раз в полгода (ну, у кого как) на продакшене возникает невоспроизводимая локально ошибка. Вот тогда встает вопрос о копировании БД оттуда в локальное окружение.
          0
          … после чего выясняется, что ошибка все равно не воспроизводится, потому что она вызвана (а) окружением и/или (б) теми самим данными, которые меняет алгоритм анонимизации.
          0
          Конечно, вы правы и насчет версионирования базы данных от разработчика. Однако, мои наблюдения среди сайтостроителей (MySQL там весьма почитаем), даже с опытом, говорят ровно об обратном. Для них, собственно, статья.
            0
            Если вы согласны с мыслью о версионировании, то логичнее было бы писать статьи о том, как делать правильно, а не писать утилиты для упрощения работы на костылях?
              0
              Спасибо за замечание. Версионирование базы «от разработчика» — не единственный способ это делать. «Правильность» — есть ответ на вопрос «Достигам ли мы цели?». Проекты разные, компании разные, нет универсальных таблеток. А проблема утечки данных есть.
              Но отвечая на Ваш вопрос… Возможно, когда-нибудь и напишу.
              0
              Наблюдения еще не означают, что люди делают правильно. Чем давать людям инструменты, которые поощряют делание неправильно, лучше уж сразу учить правильно.
                0
                Уже ответил постом выше. Ваша точка зрения верна в некотором контексте. И я с ней согласен, в некоторм контексте. Однако реальность многообразнее и не столь идеальна. Ограниченные бюджеты, стартапы, где все надо было еще вчера, историческое наследие, аутсорс отдельных работ… По вашему, «скорая помощь» поощряет травмы. Ветка обсуждения себя исчерпала.
                  0
                  Аналогия неверна. Не скорая помощь поощряет травмы, а самостоятельно оказание себе первой помощи без соответствующих навыков поощряет дополнительные травмы.
              0
              эээ, а данные в работы базу тоже разработчики вносят?
                0
                рабочую базу
                  0
                  Нет, но вот как раз данные-то разработчикам и не нужны (иначе бы не было анонимизации)
                    0
                    Сами данные не нужны, но если у вас MySQL работает не так как вы хотите данные могут иметь значение.
                      0
                      Правда же, занимательный парадокс? Данные имеют значение, но выносить их с продуктивного контура без анонимизации нельзя, а анонимизация меняет те самые данные, которые имеют значение…
                        0
                        Правда=) Только есть один нюанс: не все данные нужно анонимизировать при выводе и не всегда данные, которые анонимизируются, — это именно те данные, которые приводят к нежелательным результатам. Потом смотря как анонимизировать. Например, если есть поле varchar, в котором хранятся, например, имена, можно менять их на другие строки с одинаковым числом букв, чтобы все Светы сконверитровались в одинаковую абракадабру, например Ssfec, все Тани в Ledw и т.д. При желании подобную обфускацию, вероятно, можно сломать, но вероятность того, что разработчик шпион всё же реже, чем вероятность того, что он же — раздолбай.
                          0
                          не все данные нужно анонимизировать при выводе и не всегда данные, которые анонимизируются, — это именно те данные, которые приводят к нежелательным результатам.

                          А это неизвестно. Может и вообще не в данных дело, а может в этих конкретных данных.

                          Например, если есть поле varchar, в котором хранятся, например, имена, можно менять их на другие строки с одинаковым числом букв, чтобы все Светы сконверитровались в одинаковую абракадабру, например Ssfec, все Тани в Ledw и т.д.

                          Распределение/статистика все равно поломаются.
                            0
                            > А это неизвестно. Может и вообще не в данных дело, а может в этих конкретных данных.

                            Ну проверить-то можно перед тем как к секретным данным лезть?

                            > Распределение/статистика все равно поломаются.

                            Есть некоторая надежда, что похоже поломается.
                              0
                              Ну проверить-то можно перед тем как к секретным данным лезть?

                              Каким образом? Вот у вас есть сервер в продуктиве, на нем ошибка есть. А на любом другом сервере — нет. Как понять, что ошибка в данных, и в каких именно данных, а не в сервере/окружении/фазе луны? А уж если у вас есть инструмент это понять, то вам не надо копировать себе все данные, вам надо воспроизвести ошибочную ситуацию.

                              Есть некоторая надежда, что похоже поломается.

                              На том уровне выяснения проблем, когда нас волнует статическое распределение записей в БД, «некоторая надежда» — это уже слишком мало. В таких ситуациях обычно просто имеют идентичный сервер в боевом контуре для выяснения проблем.
                                0
                                > Каким образом? Вот у вас есть сервер в продуктиве, на нем ошибка есть. А на любом другом сервере — нет.

                                Взять эти данные из бэкапа и проверить.

                                > Как понять, что ошибка в данных, и в каких именно данных, а не в сервере/окружении/фазе луны?

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

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

                                Если вы можете позволить себе иметь идентичный сервер и самим тестировать — прекрасно. К сожалению, не все могут сами тестировать плюс в некоторых компаниях о сокрытии данных заботятся очень сильно. Я в своей практике встречалась вот именно с такими случаями. Клиент приносит запрос, который либо медленно выполняется, либо неверно. Я пробую повторить со сгенерированным набором данных: безуспешно, прошу дамп. Дамп мне этот дать не могут, потому что в нём секретные данные. Приходится объяснять и как обфускацию делать, и как частичный бэкап без секретных полей.
                                  0
                                  Взять эти данные из бэкапа и проверить.

                                  В момент, когда этот бэкап покинул территорию заказчика, и начались проблемы.

                                  Вообще на тестовой машине желательно иметь такое же окружение как и на рабочей.

                                  Несомненно.

                                  Если вы можете позволить себе иметь идентичный сервер и самим тестировать — прекрасно.

                                  Не «мы», а заказчик, это важное отличие. Я же не зря написал «идентичный сервер в боевом контуре». И, соответственно, в случае тотальной невоспроизводимости, выяснения идут на этой реплике на территории заказчика под его контролем.

                                  Хотя, конечно, с гостайной даже так нельзя.
                                    0
                                    > Не «мы», а заказчик, это важное отличие. Я же не зря написал «идентичный сервер в боевом контуре». И, соответственно, в случае тотальной невоспроизводимости, выяснения идут на этой реплике на территории заказчика под его контролем.

                                    Это хорошо, когда такое возможно.
                0
                Мне кажется, что ваш подход «взять боевую базу и анонимизировать» неверен в корне. Он, конечно, подойдёт, если ваша система одна-одинёшенька в бушующем океане денных. Но когда вы интегрируетесь с пятком-десятком других систем и ваши тестовые среды должны быть согласованы по данным, хотя бы для того, чтобы проверять работу интеграций, то нет, ваш подход не пойдёт. Потому что у вас и у других в тестовых базах должны быть одинаковые тестовые люди, тестовые организации, тестовые товары и т.д. и т.п.

                Тут нужны fixtures, factories или ещё какие-то методы генерации БД из заранее заданных данных.
                  0
                  Смешивание окружений это порочная практика. Внешние системы, как правило, также имеют sandbox или test mode. Также, анонимизация это не создание тестовых людей, а как раз наоборот, попытка сбалансировать их реальность с безопасностью. Понимаете, вам не надо заменять все атрибуты чтобы анонимизировать лицо. Оно становится анонимным если не удается его однзначно идетифицировать.
                    0
                    Что вы подразумеваете под «Смешивание окружений это порочная практика.»?

                    Я говорю про то, что наша тестовая среда X должна содержать в себе человека А и организацию Б, чтобы при запросе к тестовой среде системы Y, та могла нам ответить, что человек А работает в организации Б и делает там то-то и бла-бла-бла. А человек В не работает в организации Б, а человек Г вообще был уволен и вы должны так же пометить его у себя. И у нас и у них должно быть пересекающееся подмножество одинаковых данных для тестирования. Эти данные и у нас и у них можно считать неприкасаемыми. А вот всё остальное можно при желании тащить из боевой системы с анонимизацией. А уж если с вами в свою очередь интегрируются ещё десятки других систем и вайпать старые данные нежелательно — то тут становиться вообще весело.
                      0
                      Актуальное подмножество безопасных данных — именно то, что достигается частичным (LIMIT X) копированием рабочей базы с анонимизацией. Само собой, утилита не умеет контролировать данные внешних систем…
                    0
                    у сгенерированных данных есть один минус. Они слишком структурированы. Это может давать неверные результаты при тестировании. Особенно если речь о производительности.
                    +1
                    Мне кажется (methinks), что в тексте излишек пояснений/переводов на английском языке (English).
                      0
                      Да (yes)
                      0
                      Доступна в Интернет по некоммерческой лицензии.

                      Статус — бета. Так что буду счастлив получить ваши отзывы!


                      А где URL?
                        0
                        По названию пакета находится гуглом. Пожалуйста, www.crystalcopy.org

                      Only users with full accounts can post comments. Log in, please.