Если у нас будет паттерн поведения сотрудников и признак, что они ненавидят друг друга, научим систему это понимать. Тут же не система даёт указания, как правильно формировать команду, а менеджмент может спросить совета у системы и доубучить ее, если она где-то ошибается

1. «То, что люди хорошо общаются или курят вместе, далеко не показатель того, что они сработаются над проектом.
Как и их заинтересованность в теме проекта не показатель того, что они могут что-то сделать.»
Отвечаю: Да, не показатель. Но один из факторов, которым пренебрегать не стоит

2. «Тянет проект по лайкам в «соцсети», или я что-то упустил? Я бы не хотел работать там, где от лайков зависит моя ценность.»
Отвечаю: Алгоритм строится не на лайках и автостроении, а пляшет от имеющейся базы проектов и отзывов на имеющиеся проектные команды. Кроме того, мы видим статистику активности по проектам. Все это вместе (включая курилку) может дать очень репрезентативную картинку

Искать девушку, которая ещё ни с кем из инженеров не встречается. А если серьёзно — ниже ответил

Автопостороение хороших проектных команд. Выявление тех, кто реально тянет проект, а не номинально руководит. По промшпионажу — ну ясно же, что мы под NDA, но все предпосылки выше есть.

Конечно, но далеко не все элементы. А вообще один из первых инструментов этой системы наши сотрудники сами запилили в нерабочее время для фана, то была карта коммуникации, которая отображала в виде карты звездного неба связи сотрудников между собой :)

Могу лишь сказать, что внедрение окупилось менее чем за полгода. Если вас интересует более конкретная информация, напишите мне в личку, детально вас проконсультируем.

Кроме всего прочего, в базе хранятся не только данные, но и логика их обработки. И логика логики обработки тоже.

В частном случае ваш вариант может работать. Попробуйте сделать baseline для разных команд разработки с различных приложений и баз данных с продовых систем. А потом храните версии изменений приложения, БД на несколько проектных команд и еще предоставляйте по требованию данные на требуемый момент времени с внедрёнными в пром изменениями для новых команд разработки. Без автоматизации сложно будет.
С помощью Delphix можно одновременно управлять формированием и распространением (маскированных) данных. Из-за сочетания методов маскировки данных с технологией их виртуальной доставки снимаются ограничения традиционных решений.

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

Как раз для тестирования изменений (в вашем случае в структуре БД) софт Delphix и нужен. Создаешь отдельную виртуальную БД и тестируешь.

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

Давайте определимся с термином «клон». Под клоном понимается полная копия на отдельной СХД. Полагаю, что клон на современной СХД (в вашем толковании) не подошёл для заказчика. Думаю, по этой же причине на рынке есть и другие схожие решения. Не всё «родное» от вендора (в том числе и СХД) является оптимальным. И дело тут не только и не столько в экономии СХД. Например, здесь экономия достигается за счет того, что при создании очередной виртуальной БД Delphix хранит не всю БД, а только изменения, которые в неё вносит разработчик или тестировщик. Более того, по отношению к каждой виртуальной БД разработчик/тестировщик может моментально получить состояние БД к любому моменту времени на временной шкале. Сколько нужно технологий, чтобы сделать снепшот для тестовой БД не нагружая продакшен БД? Ответ — более трех. Репликация данных с продакшена с последующим инкрементом, в вашем случае, снимки на уровне СХД, time-recovery на уровне БД, маскирование, скрипты и т.п. Множим это на количество тестовых БД и на десятки тестовых сред разработки. И на время стораджистов.

Еще раз повторю: заказчик умеет считать и очень хорошо.

У них была развертка приложений и до Delphix — долгая, дорогая, с «разборками» кто, когда и что должен делать. И покупкой доп. СХД, зачастую.
А теперь 1 человеко-час в день (админ Delphix) справляется с пожеланиями разрабов. Возросшими пожеланиями, конечно, ибо с приходом Delphix стало понятно, что разрабы смогут больше в единицу времени. Может, даже точат зуб на инфраструктурщиков.

Если клоны — это копия БД, как же нет экономии?
Вдумайтесь: в прежние времена компании для разработки 7 продуктов потребовалось бы 7 новых физических тестовых баз данных, которые заняли бы порядка 210тБ. Сегодня же для этого нужно всего лишь 25тБ.
Заказчик хорошо умеет считать. Очень.

И еще, Delphix не пытается заменить сложившийся порядок вещей. Там, где снэпшоты — норма жизни, ок, это их дело. Но, думаю, что в формулировке «почти эквивалент» ключевым является слово «почти».

И да, еще один важный момент: Delphix не только для СУБД, но и для слоя приложений, причем не только пакетных. Он легко синхронизирует папки приложений из прода в тестовые среды.

Писать скрипты непросто, нужны знания.
GUI Delphix – прост и понятен разработчикам на интуитивном уровне. Он выглядит как Apple GUI для ребёнка. А если баз данных/сред разработки много и много проектных команд? Писать скрипты становится еще дороже и сопровождать их тоже. Всё ведь не упомнишь, верно?
GUI повышает производительность труда, однозначно. И вообще текстовый редактор Фотон «умер», в Ворд процветает.

Кроме упомянутого выше, Delphix убирает лишнюю нагрузку с инфраструктурщиков и других админов. Сами разработчики и тестировщики делают, что им надо. Либо просят отдельного одного админа Delphix, но это всего один человек (точнее, кто-то из админов, ведущий это ПО, даже не отдельная должность), а не целый отдел инфраструктурщиков только для нужд тестирования.

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

Здесь все в одном флаконе. Delphix может использовать любую СХД. Кроме того, это софтверное решение (вирт образ) и может легко быть развернут в облаке или в ЦОДе.
NetApp — сложнее в установке и администрировании, а Delphix устанавливается за 1 день.
У Delphix простой и понятный UI, доступный разработчикам, NetApp – это сложные скрипты.

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

Да-да, вы правы, простите, ввел в заблуждение, я имел ввиду не вагон, а весь поезд. Его населенность определялась путем корреляции между расписанием движения транспорта, продажами билетов и данными с турникетов о входах или выходах. А в ее прогнозировании учитывали также погодные факторы, ввод в строй новостроек, проведение мероприятий, праздники и пр.