Комментарии 93
Epic Succes Toy Story 2. Спасибо за перевод.
Системные администраторы
НУ вот и источник проблем.
Их должно быть один.
НУ вот и источник проблем.
Их должно быть один.
Системные администраторы
НУ вот и источник проблем.
Их должно быть один.
Точно, точно.
А потом этот один заболел, уехал в отпуск, его сбила машина, он решил уволится или т.п.
Какая печальная история — если стали пропадать файлы отрендеренные — то кто мешал посмотреть log в unix-laikly системе, какой паразит (с какого терминала и во сколько ввел) или там был такой гадюшник что все друг другу файлы стирали? а если у них папки расшарены (ISDN? да?) и текстурщик лез к моделеру…
Про лог есть в статье, правда, сумбурно как-то
по своему опыту работы — корежу локальные копии файлов, к результатам моей работы никто не лезет («они ходили по сети, у них работа такая :-((( „) впрочем, в 98 локальные харды могли быть настолько дороги, что все копались в одной шаре, ну тогда вопрос по бекапам — 100мильенов уе не причина нанять грамотных одминов, а нагибать сутки креаторов на восстановление… ну капитализьм можт запланировано было сорвать премьеру?
Они и копались на одном диске по сети, об этом написано. Также говорится, что раздать всем грамотные права не представлялось возможным. Допустим хотя бы, что каждый из них пользовался своей собственной учёткой, а не одной на всех. И вот есть лог, они нашли виноватого в удалении. Как это помогло бы спасти работу и деньги?
Надеюсь, люди знали, за что работали, 100-часовые недели были сбалансированы высокими стоимостями акций художников, а на ура-культурой.
ага, и ещё лично Джобс подходил и делал массаж затёкших плечь сотрудникам, всё так и было)) инфа сотка
Не всё так гладко. Вот отрывки из книги «Магия Пиксар».
«Процесс открытого размещения акций пролил свет на детали предполагаемого распределения опционов акций. Для Комиссии по ценным бумагам и биржам необходимо было подготовить регистрационное заявление и другие документы, содержащие финансовые данные, а для потенциальных инвесторов — проспект эмиссии. Документы нужно было проверить и отредактировать, и вот тут-то информация и просочилась: лишь несколько сотрудников получат дешевые опционы на огромное количество акций. Кэтмелл, Леви и Лассетер должны были получить опционы на 1,6 миллиона акций каждый; Гуггенхайм и Ривз — 1 миллион и 840 тысяч соответственно. Если акции компании продадутся по планируемой цене в четырнадцать долларов, все они в одночасье станут миллионерами.
Разоблачение вызвало массовое возмущение. Если не говорить о деньгах, происходящее было глубоко символично: эти опционы будто недооценивали годы работы, которые посвятили компании все остальные. Они делали бессмысленным чувство принадлежности к пиксаровскому трудолюбивому сообществу — то чувство, которое собрало всех этих людей, делающих вместе высококлассную и интересную работу.»
«Выпуск большого числа фондовых опционов явился результатом заключенной в 1991 году сделки с Disney по поводу производства фильма. Поскольку Disney активно использовала трудовые контракты с собственными сотрудниками, она потребовала, чтобы Pixar также заключила контракты со всеми специалистами, занятыми в производстве «Истории игрушек». Руководство Pixar было против, опасаясь, что трудовые контракты испортят культуру компании; Кэтмелл всегда считал, что сотрудники должны оставаться в Pixar, только если того хотят, а не по причине обязательств, наложенных многолетними контрактами. Disney пошла на значительные уступки, однако продолжала настаивать на заключении договоров со всеми значимыми участниками производственного процесса. Таким образом, по условиям сделки Disney — Pixar от 1991 года Pixar должна была заключить договоры с так называемыми «ключевыми творческими силами компании» — в их число вошли Кэтмелл, Лассетер, Гуггенхайм и Ривз, чтобы гарантировать их работу.
Каждый из четверых теперь был в выгодном положении: не будь трудового договора, не было бы и сделки с Disney. Чтобы убедить их подписать контракт, Джобс разработал для них план участия в прибылях в феврале 1993 года. Шестнадцать процентов пиксаровской прибыли от фильма пойдет в «прибыльный фонд», а потом он будет разделен на четыре равные части. Пару лет спустя, когда Джобс планировал выводить компанию на открытый рынок, они опять оказались в сильной позиции. Советники Джобса указывали на то, что инвесторы не примут такой роскошный план участия в прибылях для горстки сотрудников, поэтому 28 апреля 1995 года Джобс и пять сотрудников из руководства компании договорились заменить этот план необычайно щедрыми фондовыми опционами. Хотя Леви не было среди участников прибыльного фонда, он также имел достаточно влияния, чтобы настаивать на щедрых опционах.»
«Процесс открытого размещения акций пролил свет на детали предполагаемого распределения опционов акций. Для Комиссии по ценным бумагам и биржам необходимо было подготовить регистрационное заявление и другие документы, содержащие финансовые данные, а для потенциальных инвесторов — проспект эмиссии. Документы нужно было проверить и отредактировать, и вот тут-то информация и просочилась: лишь несколько сотрудников получат дешевые опционы на огромное количество акций. Кэтмелл, Леви и Лассетер должны были получить опционы на 1,6 миллиона акций каждый; Гуггенхайм и Ривз — 1 миллион и 840 тысяч соответственно. Если акции компании продадутся по планируемой цене в четырнадцать долларов, все они в одночасье станут миллионерами.
Разоблачение вызвало массовое возмущение. Если не говорить о деньгах, происходящее было глубоко символично: эти опционы будто недооценивали годы работы, которые посвятили компании все остальные. Они делали бессмысленным чувство принадлежности к пиксаровскому трудолюбивому сообществу — то чувство, которое собрало всех этих людей, делающих вместе высококлассную и интересную работу.»
«Выпуск большого числа фондовых опционов явился результатом заключенной в 1991 году сделки с Disney по поводу производства фильма. Поскольку Disney активно использовала трудовые контракты с собственными сотрудниками, она потребовала, чтобы Pixar также заключила контракты со всеми специалистами, занятыми в производстве «Истории игрушек». Руководство Pixar было против, опасаясь, что трудовые контракты испортят культуру компании; Кэтмелл всегда считал, что сотрудники должны оставаться в Pixar, только если того хотят, а не по причине обязательств, наложенных многолетними контрактами. Disney пошла на значительные уступки, однако продолжала настаивать на заключении договоров со всеми значимыми участниками производственного процесса. Таким образом, по условиям сделки Disney — Pixar от 1991 года Pixar должна была заключить договоры с так называемыми «ключевыми творческими силами компании» — в их число вошли Кэтмелл, Лассетер, Гуггенхайм и Ривз, чтобы гарантировать их работу.
Каждый из четверых теперь был в выгодном положении: не будь трудового договора, не было бы и сделки с Disney. Чтобы убедить их подписать контракт, Джобс разработал для них план участия в прибылях в феврале 1993 года. Шестнадцать процентов пиксаровской прибыли от фильма пойдет в «прибыльный фонд», а потом он будет разделен на четыре равные части. Пару лет спустя, когда Джобс планировал выводить компанию на открытый рынок, они опять оказались в сильной позиции. Советники Джобса указывали на то, что инвесторы не примут такой роскошный план участия в прибылях для горстки сотрудников, поэтому 28 апреля 1995 года Джобс и пять сотрудников из руководства компании договорились заменить этот план необычайно щедрыми фондовыми опционами. Хотя Леви не было среди участников прибыльного фонда, он также имел достаточно влияния, чтобы настаивать на щедрых опционах.»
Забавно, я не знал, что в Pixar использовалась своя ОС, основанная на юниксе.
И ещё не очень понятно, почему их должна эскортировать полицейская машина, если они об этом не просили,– наверное, какие-то американские реалии.
Ещё не понятно, что за анимация "на лету" в сцене с псом Бастером – гугл выдаёт мне только фильм The Fly по запросу "animation on the fly". :/
И да, в месте под название Bugville такая история обязана была случиться! :D
И ещё не очень понятно, почему их должна эскортировать полицейская машина, если они об этом не просили
Даже в России можно попросить ДПСников сопроводить, если жена рожает — видео такие есть. А в статье написано — надеялись: «ехали… с мигающими фарами, надеясь… Но ни одна полицейская машина нас не заметила» — хз, что имелось в виду, может на аварийке, может дальним моргали. Но КМК в американских реалиях они могли в полицию позвонить и им бы не отказали.
Забавно, я не знал, что в Pixar использовалась своя ОС, основанная на юниксе.
Не совсем своя. В работе использовались станции Silicon Graphics, которые скорее всего были под IRIX, который в свою очередь Unix-based.
Во время создания «Приключений Флика» большинство муравьёв удалили и их пришлось восстанавливать, потому что, разумеется, Pixar выполняла резервное копирование данных.
Подозреваю, что в оригинале опечатка. Должно быть «arts»?
Хотелось бы посмотреть первую версию фильма.
Получается, после команды rm -r -f * в Unix всё? Нет никакой возможности вытянуть только что удалённые файлы?
Это зависит от файловой системы с большего. Конечно есть возможность получить дамп с жёсткого диска, но на нём сложно найти границы файлов, а также понять какие файлы удалены правильно, а какие нет. Не говоря уж о том, что нет их названий. Поэтому применённый ряд мер более эффективен, чем попытка пользоваться каким-нибудь undelete.
Да, намного проще было использовать бэкап. А если они этот бэкап развернули на тот же диск, то восстанавливать удалённые файлы после этого было уже совсем безнадёжно.
Ну, с высоты текущих реалий, правильнее было бы использовать какую-нибудь систему контроля версий, и давать пользователям доступ к ней, а не к файловой системе хранилища, тут тебе и разделение доступа, и аудит, и версионирование. А настоящего удаления у рядовых работников вовсе быть не должно, только права пометить файл как удаленный. Но были ли такие средства достаточно развиты и применимы в тот момент, сказать не возьмусь)
Ну, CVS тогда уже была, но она была неудобной и малораспространённой. Лишнего места под хранение файлов не было, глобальных сетей толком не было. Да что там — даже локальные сети и то были не очень развиты. Это сейчас есть и средства и инфраструктура, а тогда…
Гигабайтные бинари загрузить в CVS скорее всего было нельзя.
Наверное можно было нагородить что-то кастомное, но до тех пор очевидно не было повода этим всерьез озаботиться.
А еще «проект побился, но мы не знаем где и как» — столь же эпический фейл.
Наверное можно было нагородить что-то кастомное, но до тех пор очевидно не было повода этим всерьез озаботиться.
А еще «проект побился, но мы не знаем где и как» — столь же эпический фейл.
В CVS можно и терабайт загрузить. Только это бессмысленно. Потому что CVS хранит историю каждого файла отдельно. А когда у вас десятки тысяч файлов… я даже не знаю что из существовавшего в то время такое умело. Perforce, может быть…
Гигабайтные бинари загрузить в CVS скорее всего было нельзя.
На каждую версию бинарного файла хранится отдельный файл. В отличии от хранения диффов, место съедает очень быстро, а это был вообще 98 год, когда домашние винты, как и память, еще измерялись мегабайтами. А 10+ГБ серверного места было просто огромно. Причем надо учитывать, что на каждую модель и текстуру готовится по нескольку вариантов, часть из которых отбрасывается, но не удаляется, на всякий случай (те самые тысячи потерянных «ненужных» файлов).
Наверное можно было нагородить что-то кастомное, но до тех пор очевидно не было повода этим всерьез озаботиться.
Велосипед с квадратными колесами или бекапы на стриммер? Выбрали второе, но не учли лимиты. Всплывает такие проблемы обычно через несколько лет и в ограниченном случае, встречался с подобным на практике.
А еще «проект побился, но мы не знаем где и как» — столь же эпический фейл.
Вполне нормальное явление. И для тех годов, и даже позже.
Стори 1: 2004-2005 год, лицензия TES3 Morrowind с дополнениями. Не было упаковано целых 2 текстуры из сотен, которые отвечали за небо при снежной погоде на небольшом острове дополнения. Проект побитый, всплыло оно уже только у игроков, причем спустя NN часов игры в строго определенных условиях.
Стори 2, та же игра: Потрошил один плагин, вместо кувшинок в игре отображался огромный треугольник с восклицательным знаком, т.е. проблемы либо с моделью, либо с текстурой для модели. 1 игровой объект из тысяч статичных объектов, никаких ошибок, никаких логов, если не знаешь хотя бы локацию с проблемным объектом, найти среди тысяч статичных объектов просто невозможно.
Подозреваю что у пиксаров было что-то с аналогичной особенностью для рендера, т.е. допускающее рендер при частичной целостности проекта. Причем есть подозрение, что сделано оно было специально, т.к. выкачать 10 ГБ исходников для тестового локального рендера аниматору… да в 98 году… дорогое удовольствие.
А без логов… ну разве что файл с иерархической структурой проекта поможет, да какой параноик его предусмотрит при наличии бэкапов?
Используйте ext4magic для ext3/ext4.
Только не забудьте прихватить в 1998 год машину времени.
Вот тоже также подумал, видимо они понадеялись на бэкап и перезаписали диск с удаленными данными, а когда через неделю узнали что бэкап плохой то было уже поздно
ну блин это всего лишь мультфильм, а написано как будто тут прям драма Шекспира, чувствуется рука мастера кующего корпоративный дух, как то все раздуто и преувеличино
Ну хорошо, мультфильм вас не впечатляет. А перспектива потери 100 миллионов долларов?
Ну честно говоря, какие-то слишком тут позитивные комментарии. Обычно в темах подобного рода в мокрого места не остаётся от менеджмента, который ставит нереалистичные сроки, а потом простые исполнители убиваются на работе. Ну и про доступ под рутом кого угодно тоже самое, вспомните знаменитую историю с реддита про студента, который в первый день на рабочем месте грохнул основную БД. Но, видимо, Пиксару такое простительно :)
>> который ставит нереалистичные сроки
Так они закончили за 9 месяцев до релиза, даже несмотря на этот инцидент.
Только вот продукт получился некачественным и пришлось переделывать.
Но вообще я в шоке, конечно.
10GB проект копируется на 4GB ленту и никто об этом не знает.
Скорее всего никто даже не поинтересовался сколько он занимает.
Никто не пробовал проверить работоспособность бэкапа.
Техдир проекта «случайно» вспоминает что у неё дома есть копия фильма.
Так они закончили за 9 месяцев до релиза, даже несмотря на этот инцидент.
Только вот продукт получился некачественным и пришлось переделывать.
Но вообще я в шоке, конечно.
10GB проект копируется на 4GB ленту и никто об этом не знает.
Скорее всего никто даже не поинтересовался сколько он занимает.
Никто не пробовал проверить работоспособность бэкапа.
Техдир проекта «случайно» вспоминает что у неё дома есть копия фильма.
10GB проект копируется на 4GB ленту и никто об этом не знаетВозможно, предыдущий проект был размером в пару ГБ, и когда начали делать этот проект, он тоже влезал в 4 ГБ, он постепенно раздулся, но система бэкапа всего лишь не прислала сообщение об ошибке.
Ну закончили они всё-таки благодаря каким-то стахановским геройствам. Тогда не совсем понятно, зачем они так убивались после краша, если у них времени было в запасе. Ну и работали бы спокойненько, восстанавливали данные в рабочем режиме.
С чего вы взяли, что они закончили за 9 месяцев до релиза? За 9 месяцев до релиза они поняли, что то, что они делают сейчас, никуда не годится и всё надо переделать. Это вполне могла быть как половина работы, так и треть или 75%, нам об этом не сказали.
Но, видимо, Пиксару такое простительно
Нет. Все это простительно компании 21 год назад. Если что тогда web с гуглом еще пешком под стол ходили и не было нормальных систем контроля версий, бекапов и разделения доступа. Многое из того, что нам кажется очевидным сейчас, тогда было совсем не очевидным.
Ну, очень странные вещи вы говорите. как будто бы в это время динозавры по улицам ходили. Веб с гуглом к описываемой теме никакого отношения не имеют, а Perforce — система контроля версий, специально рассчитанная на бинарные файлы, существует с 1995 года.
Я бы сказал, что ровно наоборот — сейчас оборудование куда надёжнее, плюс есть штуки типа дропбокса, поэтому я сам сейчас менее аккуратно отношусь к бэкапам, чем в те годы. Тогда я знал, что винчестер может полететь в любой момент, и следил, чтобы мои проекты не пропадали. Но куда мне до опыта и практик многомиллионной компании, конечно.
Я бы сказал, что ровно наоборот — сейчас оборудование куда надёжнее, плюс есть штуки типа дропбокса, поэтому я сам сейчас менее аккуратно отношусь к бэкапам, чем в те годы. Тогда я знал, что винчестер может полететь в любой момент, и следил, чтобы мои проекты не пропадали. Но куда мне до опыта и практик многомиллионной компании, конечно.
Даже если что тогда и было, то далеко не все об этом знали. Это сейчас любая толковая тулза может быстро войти в обиход. А тогда была туча разных не очень совместимых между собой UNIX-ов, софт был часто самописный какой-то и вообще был зоопарк, разброд и шатания. Сейчас то легко говорить, когда есть и знания и софт и всё что хочешь. А тогда всё было в диковинку и в новинку.
Ну почему вы так думаете? Были специализированные журналы, конференции, реклама. Тот же perforce как-то надо было рекламировать и продавать. В любом случае, посмотрите на это вот как: допустим, все это сложно и ново. Но ведь у них были IT-спецы, чьей прямой работой было как раз всем этим заниматься и точно себе представлять, что они будут делать, если кто-то сдуру сделает rm — rf. Собственно, им и платят за то, чтобы они разбирались в сложных и новых технологиях, даже без Гугла.
В моей конторе в те годы тоже был случай с rm -rf, когда админ по телефону командовал действиями оператора в другом городе, пытаясь почистить место на переполненном SCO Unix сервере. (О нормальном заходе терминалом по тогдашним телефонным линиям с их качеством можно было только мечтать.) Хотел он так почистить лишние драйвера, но команда cd не прошла, а он не проконтролировал лишний раз. В итоге получился классический rm -rf * от корня. Сервер умер и админ поехал в командировку — переустанавливать сервер.
И бэкапом тоже там как-то был классический случай, когда всё регулярно бэкапилось, а когда накрылись диски и понадобился бэкап, то выяснилось, что zip архивы с бэкапом получались битые по какой-то причине с определённого момента времени и никто это, конечно же, не проверял до момента, когда этот бэкап понадобился.
Естественно, после этого в регламент бэкапов было внесено требование регулярно пробовать накатывать бэкап на резервный сервер, сколько бы это времени и сил не занимало. И резервный сервер для этого, кстати, тут же выделили, до этого его необходимость доказать не удавалось.
Естественно, после этого в регламент бэкапов было внесено требование регулярно пробовать накатывать бэкап на резервный сервер, сколько бы это времени и сил не занимало. И резервный сервер для этого, кстати, тут же выделили, до этого его необходимость доказать не удавалось.
На моей практике был похожий случай — всё бэкапилось самописным батником с использованием консольного winrar — скриптик отладили, оттестили бэкапы и забыли про них где-то на полгода-год, а когда внезапно потребовался бэкап, выяснилось, что вызываемый из батника winrar почему-то не видел лицензионный ключ, а без ключа у него ограничение на количество файлов в архиве — на этапе тестирования ограничение не достигалось, но "за время в пути" файлохранилище успело изрядно подрасти… стоимость потери была, конечно, несопоставима с пиксаровской, но всё равно неприятно.
Кто-то скажет после таких примеров, что работать в командной строке это хорошо?
Ну права надо ограничивать, есть ACL. Всё можно настроить.
Написано же в статье, что это было невозможно сделать. Вообще, у администраторов полный доступ.
А при чём здесь статья? 20 лет прошло. Сейчас есть все инструментарии для анального огораживания юзеров в командной строке.
Как администраторов ограничишь?
Сегодня есть системы контроля версий для бинарных файлов, можно не ограничивать.
Но если так совпало, что:
1. Нет системы контроля версий
2. И допустимо на проекте пользоваться rm
то:
Нужно сделать чтобы rm не удалял файлы а помещал в корзину на месяц. Например глобальным алиасом.
Но если так совпало, что:
1. Нет системы контроля версий
2. И допустимо на проекте пользоваться rm
то:
Нужно сделать чтобы rm не удалял файлы а помещал в корзину на месяц. Например глобальным алиасом.
а если места нет? контроль версий только для исходного кода же используется обычно. А я в целом про сервер.
Слишком много «а если». У меня начинает возникать ощущение, что я вам оказываю бесплатные консультации по администрированию.
Давайте в последний раз:
* Контроль версий существует для бинарных файлов: Boar или любое хранилище артефактов, куда заливаются изменения скриптами по каждому чиху.
* Место — сегодня самый дешёвый ресурс. Если какая-либо проблема решается удалением фалов, скорее всего она решается неправильно.
* В целом про сервер: аудит всех вводимых команд (например через syslog-ng), автоматизированные сценарии раскатки серверов с нуля на другом железе и помещение etc в git, с автокоммитом.
Давайте в последний раз:
* Контроль версий существует для бинарных файлов: Boar или любое хранилище артефактов, куда заливаются изменения скриптами по каждому чиху.
* Место — сегодня самый дешёвый ресурс. Если какая-либо проблема решается удалением фалов, скорее всего она решается неправильно.
* В целом про сервер: аудит всех вводимых команд (например через syslog-ng), автоматизированные сценарии раскатки серверов с нуля на другом железе и помещение etc в git, с автокоммитом.
В статье ни слова про административные права, только про доступность всех файлов проекта всем сотрудникам, которые с ним работают
Но они ведь даже не знают как именно это произошло и кто виноват, это только предположение. Файлы можно и из через GUI так же покрошить, или неудачным скриптом. При большом количестве сотрудников с полным доступом к файлам, это уже не вопрос, случится ли такое, а вопрос как скоро. И в тексте прямо написано, что это не первый случай. Потому они уже делали бэкапы. Уже делали, но ещё не тестировали.
Но да rm, особенно с ключами -r и -f мощное и тихое оружие, очень опасное.
Но да rm, особенно с ключами -r и -f мощное и тихое оружие, очень опасное.
В GUI понятнее что удаляешь
В GUI может быть легче перепутать текущую папку.
Поэтому придумали корзину (которая все равно не поможет с сетевой шарой)
Поэтому придумали корзину (которая все равно не поможет с сетевой шарой)
Я привыкал к GUI Винды, когда диски были маленькими. Поэтому «Shift+Del, Enter» для удаления я нажимаю автоматически. Сейчас вот уже почти переучился в обратную сторону.
(которая все равно не поможет с сетевой шарой)Это чего это вдруг? У меня на работе стоит NAS, который при удалении любого файла, помечает его как удаленный, и перемещает его в корзину, сколько файлы там храняться не скажу, но если случайно что то удалил, всегда можно востановить.
до момента, пока путь не перестанет влазить в отведенное место.
В который раз убеждаюсь, что поиск виноватых — это в первую очередь баг человеческой психологии, которой проще по-быстрому приклеить ярлык, чем решить основополагающую проблему. Да, иногда виноваты конкретные люди, но статистически чаще проблема оказывается решаема через изменение внешних факторов.
В основном это фича, но в крупных проектах/организациях скорее баг из-за стремления к гипержопоприкрывательству.
Накосячивший скорее всего больше такого не сделает и в среднем теперь будет работать лучше ненакосячившего.
Накосячивший скорее всего больше такого не сделает и в среднем теперь будет работать лучше ненакосячившего.
Скорее фитча со времен когда лечить проблемы общества не умели и просто ампутировали части.
После удаления и восстановления Toy Story 2 команда надеялась на ничем не омрачённый выпуск продукта, но этому не суждено было случиться.
В Рождество 1998 года, после выпуска «Приключений Флика» и завершения рекламного тура Джон Лассетер, Эндрю Стэнтон, Пит Доктер и легендарный сценарист Джо Рэнфт решили оценить Toy Story 2.
Фильм был плохим. Они посвятили зимние каникулы почти полному переписыванию проекта с нуля. Производство было остановлено 15 декабря и возобновилось после Нового года, в январе, когда команда сценаристов повторно изложило идею фильма.
Т.е. данные вначале героически спасли и восстановили, а потом они опять отправились в мусорную корзину потому что «Фильм был плохим»? Рука-лицо
Что же там было плохого (это кстати не написано)?
В Рождество 1998 года, после выпуска «Приключений Флика» и завершения рекламного тура Джон Лассетер, Эндрю Стэнтон, Пит Доктер и легендарный сценарист Джо Рэнфт решили оценить Toy Story 2.
Фильм был плохим. Они посвятили зимние каникулы почти полному переписыванию проекта с нуля. Производство было остановлено 15 декабря и возобновилось после Нового года, в январе, когда команда сценаристов повторно изложило идею фильма.
Т.е. данные вначале героически спасли и восстановили, а потом они опять отправились в мусорную корзину потому что «Фильм был плохим»? Рука-лицо
Что же там было плохого (это кстати не написано)?
Да, меня это как раз больше всего поразило — в статье подробно расписано восстановление, а потом как будто между делом упоминается что всё это было не нужно — всё равно большая часть была переделана.
Ну, всё достаточно логично. Они восстанавливали первую версию, которую в живую еще никто не видел от начала и до конца. Это всё же фильм. Потом, как собрали проект, посмотрели и поняли, что он не подходит. Могли бы понять это раньше, но удаление помешало.
Так модели спасли. Рендер готового фильма удалили, переделали сченарий, и с теми же моделями «сняли» заново.
По следам соседней статьи: что-то у меня какое-то дежа вю, уже переводили эту историю на хабре. PatientZero ожидает зачет? :)
«Быстро, в течение буквально пары часов, программисты написали скрипты, которые получали на входе список и создавали окна XF, по 20 файлов в глубину. Закрываешь их все, спускаешься ещё на 20 вглубь. Закрываешь их все, поэтому так можно двигаться очень быстро».
Все окна нужно было просматривать глазами, чтобы увидеть, какие из них короче, чем более новые.
А написать скрипты, которые определяли более короткий вариант они не осилили? Вообще непонятно, что можно такого нарассматривать вручную в 30К файлов, чего не сможет рассмотреть алгоритм.
Написать тулу даже на C, которая обойдёт рекурсивно две директории и сравнит размеры файлов в них (и содержимое) — пара пустяков. Похоже скорее на наказание всех из-за промаха одного.
Они занимались этим следующие несколько недель.
Типа xdiff вам в руки и барабан на шею.
Они занимались этим следующие несколько недель.
Типа xdiff вам в руки и барабан на шею.
Подозреваю, что не всегда последний вариант сцен или моделей был просто по размеру больше. Могли как добавлять что-то, так и удалять. Пробовать, и если не понравилось — откатить назад. А так как не было версионирования, пытались гадать что же являлось последней рабочей версией. Как-то работал в такой творческо-гуманитарной среде, классических творческий беспорядок там присутствовал всегда.
Поиск виноватых в такой ситуации очень прост — виноват руководитель, которые не выстроил в компании процессы должным образом. И за его косяк расплачивались рядовые сотрудники 100 часовыми неделями.
Всё складывается со временем так, что мы не можем до конца понять «почему не поступили по другому?».
Вот вроде бы Пиксар, да и Джобс не последний в IT человек, но почему то администрирование плохо велось.
А может, если бы это всё выстроили, потратив кучу денег, времени и сил, всё это наоборот сделало бы трудней производство? Какие-то права, какой-то доступ, лишние двери на пути людей, которые просто творят вместе. Достают всё с одного сервера и на него же кладут по необходимости, без лишних вопросов по типу «кто забрал мой молоток?», «почему мне не выдают гвозди?».
Метод решения проблемы, да и само появление проблемы говорит о довольно сплочённом коллективе, который умело справлялся и без всего этого администрирования. Да, проблема случилась, но это скорее всего стечение обстоятельств, которое так же возможно и при сегодняшнем жестком контроле, который нужно еще настроить.
Вот вроде бы Пиксар, да и Джобс не последний в IT человек, но почему то администрирование плохо велось.
А может, если бы это всё выстроили, потратив кучу денег, времени и сил, всё это наоборот сделало бы трудней производство? Какие-то права, какой-то доступ, лишние двери на пути людей, которые просто творят вместе. Достают всё с одного сервера и на него же кладут по необходимости, без лишних вопросов по типу «кто забрал мой молоток?», «почему мне не выдают гвозди?».
Метод решения проблемы, да и само появление проблемы говорит о довольно сплочённом коллективе, который умело справлялся и без всего этого администрирования. Да, проблема случилась, но это скорее всего стечение обстоятельств, которое так же возможно и при сегодняшнем жестком контроле, который нужно еще настроить.
Через каждые несколько дней или недель текущие данные заменяются резервными копиями и работа продолжается, чтобы гарантировать, что все данные на месте. Такая практика называется «live backup».Хороший метод "проверки"… звонок сисадминам: "Черт побери! Вырубайте сервер! Валидные данные фильма затираются битыми бэкапами!".
Ну да, тут как-то так написано… В оригинале имелось в виду, что они обмениваются местами. То есть текущие данные ничем не затираются, они кладутся на полку вместо бэкапа, а с бэкапом пробуют работать дальше. Если выяснится, что бэкап битый, можно вернуть текущую версию обратно в целости.
Из сттаьи понял, что rm -rf / — лучший тимбилдинг.
Поучительная история, и да, ISDN это 2 по 64 kbps )
А сегодня вообще есть *nix-овые ФС с не худшей восстанавливаемостью данных после удаления чем та же NTFS? Или как то потюнить существующие?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как «Историю игрушек 2» Pixar удалили дважды: сначала случайно, а потом из-за стремления к совершенству