olku Jun 1 2014 at 14:53

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

4 min

14K

Comments 30

lair Jun 1 2014 at 15:00

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

dm9 Jun 1 2014 at 15:28

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

lair Jun 1 2014 at 19:52

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

olku Jun 1 2014 at 15:46

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

sferrka Jun 1 2014 at 17:18

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

olku Jun 1 2014 at 18:07

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

lair Jun 1 2014 at 19:53

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

olku Jun 1 2014 at 20:26

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

lair Jun 1 2014 at 20:38

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

svetasmirnova Jun 4 2014 at 17:22

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

svetasmirnova Jun 4 2014 at 17:23

рабочую базу

lair Jun 4 2014 at 17:24

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

svetasmirnova Jun 4 2014 at 20:42

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

lair Jun 4 2014 at 22:42

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

svetasmirnova Jun 4 2014 at 23:13

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

lair Jun 4 2014 at 23:15

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

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

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

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

svetasmirnova Jun 4 2014 at 23:30

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

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

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

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

lair Jun 4 2014 at 23:41

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

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

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

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

svetasmirnova Jun 5 2014 at 00:37

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

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

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

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

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

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

lair Jun 5 2014 at 00:42

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

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

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

Несомненно.

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

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

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

svetasmirnova Jun 5 2014 at 00:59

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

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

Envek Jun 1 2014 at 15:38

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

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

olku Jun 1 2014 at 15:54

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

Envek Jun 1 2014 at 16:16

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

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

olku Jun 1 2014 at 16:33

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

svetasmirnova Jun 4 2014 at 17:21

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