olku1 июн 2014 в 10:53

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

4 мин

14K

Комментарии 30

lair 1 июн 2014 в 11:00

Вы какими-то странными путями идете. Зачем копировать БД с продуктива в UAT/интеграционное/разработческое, если маршрут развертывания строго обратный? Просто начинайте работать сразу в разработческом контуре, а потом следующие контура разворачивайте/мигрируйте скриптами. Тогда у вас не будет проблемы утечки данных.

dm9 1 июн 2014 в 11:28

Раз в полгода (ну, у кого как) на продакшене возникает невоспроизводимая локально ошибка. Вот тогда встает вопрос о копировании БД оттуда в локальное окружение.

lair 1 июн 2014 в 15:52

… после чего выясняется, что ошибка все равно не воспроизводится, потому что она вызвана (а) окружением и/или (б) теми самим данными, которые меняет алгоритм анонимизации.

olku 1 июн 2014 в 11:46

Конечно, вы правы и насчет версионирования базы данных от разработчика. Однако, мои наблюдения среди сайтостроителей (MySQL там весьма почитаем), даже с опытом, говорят ровно об обратном. Для них, собственно, статья.

sferrka 1 июн 2014 в 13:18

Если вы согласны с мыслью о версионировании, то логичнее было бы писать статьи о том, как делать правильно, а не писать утилиты для упрощения работы на костылях?

olku 1 июн 2014 в 14:07

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

lair 1 июн 2014 в 15:53

Наблюдения еще не означают, что люди делают правильно. Чем давать людям инструменты, которые поощряют делание неправильно, лучше уж сразу учить правильно.

olku 1 июн 2014 в 16:26

Уже ответил постом выше. Ваша точка зрения верна в некотором контексте. И я с ней согласен, в некоторм контексте. Однако реальность многообразнее и не столь идеальна. Ограниченные бюджеты, стартапы, где все надо было еще вчера, историческое наследие, аутсорс отдельных работ… По вашему, «скорая помощь» поощряет травмы. Ветка обсуждения себя исчерпала.

lair 1 июн 2014 в 16:38

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

svetasmirnova 4 июн 2014 в 13:22

эээ, а данные в работы базу тоже разработчики вносят?

svetasmirnova 4 июн 2014 в 13:23

рабочую базу

lair 4 июн 2014 в 13:24

Нет, но вот как раз данные-то разработчикам и не нужны (иначе бы не было анонимизации)

svetasmirnova 4 июн 2014 в 16:42

Сами данные не нужны, но если у вас MySQL работает не так как вы хотите данные могут иметь значение.

lair 4 июн 2014 в 18:42

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

svetasmirnova 4 июн 2014 в 19:13

Правда=) Только есть один нюанс: не все данные нужно анонимизировать при выводе и не всегда данные, которые анонимизируются, — это именно те данные, которые приводят к нежелательным результатам. Потом смотря как анонимизировать. Например, если есть поле varchar, в котором хранятся, например, имена, можно менять их на другие строки с одинаковым числом букв, чтобы все Светы сконверитровались в одинаковую абракадабру, например Ssfec, все Тани в Ledw и т.д. При желании подобную обфускацию, вероятно, можно сломать, но вероятность того, что разработчик шпион всё же реже, чем вероятность того, что он же — раздолбай.

lair 4 июн 2014 в 19:15

не все данные нужно анонимизировать при выводе и не всегда данные, которые анонимизируются, — это именно те данные, которые приводят к нежелательным результатам.

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

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

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

svetasmirnova 4 июн 2014 в 19:30

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

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

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

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

lair 4 июн 2014 в 19:41

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

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

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

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

svetasmirnova 4 июн 2014 в 20:37

> Каким образом? Вот у вас есть сервер в продуктиве, на нем ошибка есть. А на любом другом сервере — нет.

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

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

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

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

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

lair 4 июн 2014 в 20:42

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

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

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

Несомненно.

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

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

Хотя, конечно, с гостайной даже так нельзя.

svetasmirnova 4 июн 2014 в 20:59

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

Это хорошо, когда такое возможно.

Envek 1 июн 2014 в 11:38

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

Тут нужны fixtures, factories или ещё какие-то методы генерации БД из заранее заданных данных.

olku 1 июн 2014 в 11:54

Смешивание окружений это порочная практика. Внешние системы, как правило, также имеют sandbox или test mode. Также, анонимизация это не создание тестовых людей, а как раз наоборот, попытка сбалансировать их реальность с безопасностью. Понимаете, вам не надо заменять все атрибуты чтобы анонимизировать лицо. Оно становится анонимным если не удается его однзначно идетифицировать.

Envek 1 июн 2014 в 12:16

Что вы подразумеваете под «Смешивание окружений это порочная практика.»?

Я говорю про то, что наша тестовая среда X должна содержать в себе человека А и организацию Б, чтобы при запросе к тестовой среде системы Y, та могла нам ответить, что человек А работает в организации Б и делает там то-то и бла-бла-бла. А человек В не работает в организации Б, а человек Г вообще был уволен и вы должны так же пометить его у себя. И у нас и у них должно быть пересекающееся подмножество одинаковых данных для тестирования. Эти данные и у нас и у них можно считать неприкасаемыми. А вот всё остальное можно при желании тащить из боевой системы с анонимизацией. А уж если с вами в свою очередь интегрируются ещё десятки других систем и вайпать старые данные нежелательно — то тут становиться вообще весело.

olku 1 июн 2014 в 12:33

Актуальное подмножество безопасных данных — именно то, что достигается частичным (LIMIT X) копированием рабочей базы с анонимизацией. Само собой, утилита не умеет контролировать данные внешних систем…

svetasmirnova 4 июн 2014 в 13:21

у сгенерированных данных есть один минус. Они слишком структурированы. Это может давать неверные результаты при тестировании. Особенно если речь о производительности.