«Тогда-то мы и заметили это впервые, на примере Вуди».
«Ларри Катлер зашёл в каталог и как раз говорил об установке исправления для Вуди или его шляпы. Он посмотрел в каталог, и там было около 40 файлов, потом заглянул ещё раз, а там осталось всего четыре».
«Затем мы увидели, что начали пропадать последовательности кадров, и подумали: „Боже мой!“»
«Я схватил телефонную трубку… „отключайте машину!“»
Так Орен Джейкоб, бывший главный технический директор Pixar, тогда работавший помощником технического директора Toy Story 2, вспоминает момент, когда они обнаружили, что фильм удаляется с серверов компании после выполнения ошибочной команды, уничтожая два месяца и сотни человеко-часов работы.
Эта история стала известной после публикации клипа из расширенной версии фильма на Tested. Озвучивал клип сам Джейкоб, а также руководящий технический директор Галин Сусман.
Эта история показалась мне интересной, поэтому я связался с Джейкобом, который теперь работает исполнительным директором ToyTalk. Я хотел услышать рассказ непосредственно от участника, понять, действительно ли ситуация была такой драматичной, узнать, как с этим справлялись сотрудники и выяснилось ли в итоге, кто удалил файлы. Джейкоб хорошо помнит подробности этой ситуации.
Огромная часть Toy Story 2 действительно была удалена и восстановлена только благодаря счастливому стечению обстоятельств и напряжённому труду сотрудников Pixar.
Но что осталось неизвестным, так это то, что на самом деле весь фильм снова полностью уничтожен, только уже не компьютерами, а самими создателями. После чего он был полностью переделан за считанные месяцы, когда дата релиза уже была объявлена.
История, которую поведал мне Джейкоб, содержит интересные уроки для людей, работающих с большими объёмами технических данных. Но кроме того, она многое говорит нам о том, как великолепное качество фильмов Pixar связано с работающими в компании людьми, которые стремятся делать всё идеально.
/bin/rm -r -f *
История скорее всего началась в 1998 году, хотя Джейкоб признаётся, что точной даты не помнит. Команда создателей «Истории игрушек 2» (Toy Story 2), примерно 150 человек из отделов анимации, освещения и моделирования Pixar, уже какое-то время упорно работала над фильмом. Одновременно другие 200-250 человек завершали работу над «Приключениями Флика» (Bug’s Life), который должен был выйти осенью того же года.
В один из дней Джейкоб (на фото ниже) находился в офисе с Ларри Катлером и Ларри Опперле, который тоже был помощником технического директора и работал под руководством Сусман. По удачному стечению обстоятельств они заглянули в каталог, где хранились ресурсы персонажа Вуди. После обновления каталога они заметили, что там становится всё меньше и меньше файлов.
«Компьютер выдал ошибку, уже не помню, какую точно. Что-то типа „Каталог уже недействителен“, потому что Ларри находился в месте, которое уже было удалено. Затем мы поднялись вверх по иерархии, вернулись, и увидели Хэмма, Мистера Картофельную голову и Рекса. Чуть позже мы заглянули в каталог снова, и там остался только Хэмм, а потом и он пропал».
Скорее всего, была запущена команда
rm -r -f *, которая, грубо говоря, приказывает системе начать удаление каждого файла ниже текущего каталога. Она часто используется для удаления подмножества нежелательных файлов. К сожалению, кто-то в системе запустил команду на корневом уровне проекта Toy Story 2, и система начала рекурсивно отслеживать структуру файлов и удалять их, подобно червяку, прогрызающему себе дорогу из сердцевины яблока.Именно тогда был совершён панический звонок в машинный зал, где располагался главный сервер, и отдан приказ отключить питание и сетевое соединение сервера. Это не так просто сделать в средах, где к машине подключены сотни клиентов, вам как будто нужно дёрнуть главный рубильник, чтобы выключить всё.
«Главный сервер отключился», — рассказывает Джейкоб. «Часть сотрудников анимировала кадры, и на это могло тратится от одной до пяти минут. Но затем, когда им по какой-то причине нужно было загрузить файлы с главного сервера, то их компьютеры зависали».
«В конечном итоге каждый аниматор и технический директор, все, кто работал над фильмом сказали: „Ну вот, все компьютеры выключились. Пойдём обедать, ха-ха“».
Несколько часов спустя сервер включили и приступили к оценке ущерба. Команда определения размера каталога Toy Story 2 показала, что сохранилось только 10% от его исходного объёма.
Случайная команда удалила 90% мультфильма.
«Фильм был уничтожен»
Когда об этой истории стало известно впервые, основным из главных вопросов стал «как это вообще произошло?»
Я тоже задал Джейкобу этот вопрос. Оказалось, что причина заключалась в том, как компании уровня Pixar работают над проектами.
«В нашей сети было 400 людей, и все они имели достаточно масштабный доступ к ресурсам всего проекта, поэтому сложно было ограничить степень ущерба», — рассказывает Джейкоб. «Это могло быть сделано с любого терминала».
«Pixar — это широко открытая Unix-среда, то есть она позволяет довольно многое. Можно переходить из каталога в каталог, бродить по сети и при желании входить на машины Эда Кэтмелла или Стива Джобса. Не то чтобы Стив непосредственно работал над проектом, но сделать это было можно».
Стандартный способ защиты от подобных команд — ограничение доступа пользователей только теми файлами, которые им нужны. Но из-за того, как выполнялась работа над проектом фильма Pixar, почти каждому требовался доступ на чтение и запись на главный сервер. Это была их работа.
Назначение допусков при помощи микроменеджмента съело бы все административные ресурсы, особенно во время кранчей.
Резервный план
Итак, на этом этапе бОльшая часть фильма была удалена или повреждена. Но это не было большой проблемой. Файлы удалялись и раньше, такое происходит время от времени. Во время создания «Приключений Флика» большинство муравьёв удалили и их пришлось восстанавливать, потому что, разумеется, Pixar выполняла резервное копирование данных.
В 1998 году самым распространённым способом резервного копирования большого объёма информации была лента; именно такую систему и использовала Pixar. К сожалению, эти резервные копии не проверялись регулярно, как это рекомендуется и как происходит в компании сегодня.
Обычно, чтобы убедиться в качестве резервной копии, необходимо её использовать. Через каждые несколько дней или недель текущие данные заменяются резервными копиями и работа продолжается, чтобы гарантировать, что все данные на месте. Такая практика называется «live backup».
В то время Pixar не тестировал свои резервные копии регулярно. И именно поэтому начались проблемы: резервные копии хранились на ленточном накопителе, и когда размеры файлов превышали 4 гигабайта, то упирались в ограничение на максимально возможный объём. Журнал ошибок, который бы мог сообщить системным администраторам о заполненном диске, тоже был расположен на заполненном томе, и имел размер в 0 байтов.
Это означало, что новые данные продолжали записываться на накопитель, но «выталкивали» с него старые файлы. Но никто в Pixar пока об этом не знал.
Здесь стоит упомянуть, что весь фильм занимал не более 10 гигабайт информации. Это может казаться безумием по сравнению с размером текстур современных фильмов, но нужно помнить, что лента резервных копий имела ограничение на размер файлов в 4 ГБ и в течение многих месяцев работы над проектом это не представляло проблемы. Весь объём данных для мультфильма можно было бы уместить на паре двухслойных DVD.
Итак, сотрудники взяли резервные копии, приступили к работе и восстановили фильм. В течение пары дней они думали, что у них есть полностью восстановленная версия файлов TS2.
Чтобы протестировать их, они запустили рендеринг примерно 2 000 кадров, по одному из каждой «сцены» фильма (фрагмента между переходами). По сути, для них нужны все ресурсы, участвовавшие в фильме, потому что для рендеринга этих отдельных кадров необходимы все модели, освещение и текстуры.
Всё выглядело хорошо. «Мы потеряли неделю работы», — рассказывает Джейкоб. «То есть последние 10 сцен последней недели, но всё остальное было нормальным».
Перенесёмся в конец этой недели. Команда вернулась к работе и уже несколько недель использовала эти восстановленные файлы. Но на протяжении этой недели возникали небольшие странности. Всплывали загадочные ошибки с «привязками».
«Привязка» — это когда персонаж, например Вуди, снимает шляпу. Шляпа превращается из части его головы в часть его руки, это очень хитрая и «хрупкая» процедура.
«Мы начали сравнивать кадры и поняли, что фильм неполон. Я не могу объяснить, как нам удавалось работать эту неделю и получать такие рендеры»
К концу недели выявилось достаточно ошибок, чтобы команда поняла, что есть проблема. Кроме ошибок «привязок» некоторые люди, работавшие с версией своей сцены, заметили, что текущая версия была намного меньше, чем раньше. Допустим, до удаления файлов они работали с номером 420, а теперь сцена имела версию 20. Творилось что-то не то.
Именно тогда, спустя целую неделю работы, обнаружилась проблема с резервным копированием на ленту.
«Эта работа совершенно точно была проделана впустую, потому что основывалась на ненадёжных восстановленных данных», — вспоминает Джейкоб. «Теперь у нас не было ни малейшей уверенности в любом из решений: восстановленные данные были плохими, проделанная с ними работа была плохой, удаление оказалось ужасным, а резервные копии на лентах повреждены».
«У нас не оставалось возможных путей для дальнейшего движения, а может быть, даже хуже. Мы не полностью понимали, в чём именно испортились резервные копии. Если на лентах нет только 10 процентов фильма, то каких именно 10 процентов, мы не знали».
«Мы собрали большое совещание в конференц-зале в Багвилле (корпоративном комплексе Pixar). Самые умные люди в студии говорили: „Мы не знаем, что делать. Боже мой!“»
А потом Сусман сказала: «У меня дома есть машина».
«Вольво» за 100 миллионов долларов
Сусман, бывшая тогда руководящим техническим директором Toy Story 2 (на фотографии ниже), незадолго до этого родила сына Элая, поэтому работала из дома. То есть у неё дома была рабочая станция Silicon Graphics. Это была или Indigo 2, или Octane, показанная ниже, в которую загрузили полную копию фильма.
Чтобы она могла работать за пределами офиса, машину подключили к локальной сети и скопировали в неё всё дерево файлов. После этого она получала инкрементные обновления по ISDN-подключению к Интернету. Для тех кто не знает, что это такое: это соединённые вместе два модема на 56 Кбит/с (добро пожаловать в 1998 год).
Последнее обновление, которое загружалось на её машину, устарело на пару недель, но на этом этапе, когда у сотрудников Pixar была только неполная резервная копия и повреждённое дерево файлов, требовалось хоть что-то, с чего можно было начать решать проблемы. Выбор был таким: или воссоздавать каждый потерянный файл с нуля, или выпустить фильм вовремя.
Поэтому Джейкоб и Сусман сели в её «Вольво» и понеслись по мосту из Ричмонда к ней домой, чтобы забрать компьютер. Они погрузили его в машину и аккуратно разместили на заднем сиденье, обернув одеялами и надёжно пристегнув ремнями.
«Нам больше ничего не оставалось», — рассказывает Джейкоб про описанное выше совещание. «Мы были мертвы. Совещание длилось минут 45. Там собралось 30 самых умных сотрудников Pixar, которых можно было привлечь для решения проблемы».
Именно тогда Сусман вспомнила о её домашнем компьютере.
«Мы просто встали, вышли, залезли в её „Вольво“, пересекли мост, забрали компьютер и несколько одеял, и я закрепил его ремнями безопасности на заднем сиденье. Мы ехали со скоростью около 35 миль в час с мигающими фарами, надеясь, что полиция будет нас сопровождать. Но ни одна полицейская машина нас не заметила, и это нам не помогло».
В тот момент «Вольво» везла компьютер стоимостью 100 миллионов долларов, потому что на его жёстких дисках хранился проект, вмещавший в себя труд всей команды.
Им удалось невредимыми доехать до Ричмонда. «Перед парковкой нас встретили восемь человек с листом фанеры, и как фараона на носилках внесли компьютер в машинный зал».
Все волновались, когда включался компьютер, потому что именно в этот момент чаще всего «умирают» жёсткие диски. Он загрузился. Никто не стал ничего проверять, его просто немедленно подключили к сети и сразу же скопировали весь диск, а затем стали разбирать, что же нам досталось.
Резервной копии было примерно две недели, но им удалось создать дерево «B» и сравнить его с резервной копией «A», сделанной пару месяцев назад, и третьим источником «C», собранным из всех локальных резервных копий, созданных аниматорами и моделлерами на своих личных терминалах. Эта версия состояла из жалких .old, .sav, .bak и любых других старых файлов, которые удалось найти.
Удалось подтвердить целостность примерно 70 тысяч файлов, а ещё 30 тысяч нужно было проверить вручную. «Мы в составе 10-12 человек, без остановки работали с пятницы по понедельник, непрерывными сменами, с едой и спальными мешками», — вспоминает Джейкоб.
«Когда люди пришли в пятницу мы выдали им распечатку: „Вот 500 пунктов, которые нужно проверить за следующие восемь часов. Начинайте с команд xdiff. Приступайте“».
«Быстро, в течение буквально пары часов, программисты написали скрипты, которые получали на входе список и создавали окна XF, по 20 файлов в глубину. Закрываешь их все, спускаешься ещё на 20 вглубь. Закрываешь их все, поэтому так можно двигаться очень быстро».
Все окна нужно было просматривать глазами, чтобы увидеть, какие из них короче, чем более новые. Они занимались этим следующие несколько недель. Наиболее чётко Джейкоб вспоминает ощущение сопереживания и поддержки. Не только то, что сотрудникам нужно было пожертвовать выходными с семьёй и работать по воскресеньям, оставаясь после смены и даже ночуя на работе, но и то чувство «ухода с головой» в решение проблемы.
«В то время мы закопались очень глубоко. Нам помогали люди из команды „Истории игрушек“, люди, работавшие над „Приключениями Флика“, да и вся студия в целом. Всё сообщество поддерживало нас ночной работой, печатью на клавиатурах или отправкой нам еды».
«Однажды одна из местных лавок по продаже сэндвичей в Поинт-Ричмонд спросила нас: „Вам нужна сегодня бесплатная еда? Мы знаем, что сейчас вы не спите“».
Невероятная сосредоточенность, необходимая для сравнения всех этих файлов, показала, насколько глубоко пришлось копать создателям проекта. Это уже не было работой, а перешло в плоскость истинной преданности фильму, своим цифровым друзьям и друг другу.
«Больше всего в выходных мне запомнились подносы с печеньем, лимонад, пицца и цветы, которые нам отправляли», — вспоминает Джейкоб. «Кто-то нанял на воскресенье массажиста. Кто-то ещё работал в организации, предоставляющей временное убежище, и принёс нам одеяла».
Затем они пересобрали и протестировали проект, и он вроде бы работал. Даже сегодня Джейкоб не может объяснить то, что после завершения их работы в дереве не хватало более нескольких тысяч файлов.
«Мы не знаем, куда подевались эти файлы. И совершенно необъяснимо, как проект всё равно работал без них».
Но проект работал, кадры рендерились, и «История игрушек 2» снова ожила.
Охота на ведьм
Один из самых интересных для меня вопросов заключался в том, удалось ли найти виновного во всём этом, и был ли он наказан. Обычно, когда такое происходит, люди стремятся найти ответственного. Первым пунктом в повестке дня является «Кто виноват?» Но не в Pixar.
«Мы не пытались это скрыть», — рассказывает Джейкоб. «Спустя 10 минут мы разослали всем в здании электронные письма. „Помогите. Чёрт возьми!“»
Кроме сразу же возникшего обсуждения того, кто мог совершить такой глупый поступок, обсуждение сразу же перешло к поиску решения проблемы.
«Давайте отложим охоту на ведьм. Для начала нам нужно восстановить фильм. Давайте не будем всю неделю искать, кого нужно убить. Где наш фильм?»
«Очевидно, что спустя пять минут совещания обстановка накалилась. Кто-то сказал: „Давайте найдём его и линчуем, немедленно“», — вспоминает Джейкоб. «Я поддержал идею о линчевании, но самым главным было вернуть фильм и снова начать работать над Базом и Вуди. Мы потеряли наших друзей».
После множества человеко-лет, или даже десятков человеко-лет, потраченных на проект, искушение найти виновного, обнаружить ответственного за это, было очень сильным.
Но подобные негативные мысли никому не могли помочь, и просто отвлекали от основной задачи: движения вперёд.
Системные администраторы тщательно пересмотрели планы резервного копирования и пришли на большое производственное совещание с новым планом, который обсуждался очень дотошно. Но в конечном итоге никаких увольнений или перепалок не было.
Джейкоб не может вспомнить, кто из руководства был на службе в день, когда восстанавливали резервные копии, но, по его словам, кто бы это ни был, Стив Джобс, основатель студии Эд Кэтмелл и другое руководство сильно поддерживало работу по восстановлению, а не винило сотрудников в ошибке. В те выходные они купили команде пиццы, давали ей всё необходимое и поддерживали в целом.
Во время большого совещания относительно проблемы с резервным копированием Кэтмелл, известный тем, что ведёт «невероятно спокойный и почти дзенский образ жизни», просто спросил у команды, что она будет делать с этой проблемой.
Джейкоб вспоминает этот разговор:
«Эд, сейчас мы делаем всё, что можем».
«Ребята, вы справитесь с проблемой?»
«Да, спасибо, Эд».
В случае подобной катастрофы сложность заключается в том, что технические директора и сотрудники Pixar должны доверять друг другу при устранении проблемы, даже если было совершено несколько ошибок и один из них был в этом виноват. «Если ты не можешь спокойно сидеть и участвовать в совещании, то тебе нельзя быть на совещании», — говорит Джейкоб. «Обстоятельства были чрезвычайно необычными. „Чёрные лебеди“ иногда случаются».
Вместо того, чтобы искать виновного или оплакивать потерю времени и усилий, команда занялась изменением стратегии резервного копирования, чтобы подобное больше не повторялось, и приступило к навёрстыванию упущенного времени.
Toy Story 2 снова отправляется в мусорную корзину
После удаления и восстановления Toy Story 2 команда надеялась на ничем не омрачённый выпуск продукта, но этому не суждено было случиться.
В Рождество 1998 года, после выпуска «Приключений Флика» и завершения рекламного тура Джон Лассетер, Эндрю Стэнтон, Пит Доктер и легендарный сценарист Джо Рэнфт решили оценить Toy Story 2.
Фильм был плохим. Они посвятили зимние каникулы почти полному переписыванию проекта с нуля. Производство было остановлено 15 декабря и возобновилось после Нового года, в январе, когда команда сценаристов повторно изложило идею фильма.
В конечном итоге Лассетер и Ли Анкрич стали режиссёрами фильма вместе с Эшем Брэнноном.
Что же осталось от предыдущей версии? Разумеется, главные герои: Базз, Вуди, Хэмм, Мистер Картофельная голова, Рекс. Осталась комната Энди. Осталась сцена с «Амбаром игрушек Эла». Почти всё остальное в фильме было новым.
Джейкоб рассказывает, что было добавлено, в том числе и новый персонаж — пёс Бастер с его анимацией:
По сути, мы выбросили всю анимацию. Выбросили всю раскадровку. Поэтому работу с камерой пришлось начинать с начала. Небольшая часть освещения осталась, но и его тоже выкинули. Нам нужно было создавать новых персонажей.
На этом этапе появился Бастер. И с момента его появления до выпуска фильма прошло девять месяцев.
Это была четырёхногая модель, полностью анимированная… на лету. Как большинство людей в фильме. Вся массовка в аэропорту в конце"
А затем мы собрали их. Затем были добавлены все эффекты. Первая сцена, в которой Базз играет с роботами, там где он взрывает четверть миллиона роботов одним кристаллом. Всё это было добавлено во второй версии. В январе мы начали с нуля.
По сути, и весь сюжет. И сам фильм. Это оказалось одной из самых серьёзных проверок культуры Pixar и самой компании.
Что было самое серьёзное в переделке фильма? У него был жёстко заданный срок выпуска — 22 ноября 1999 года. Эту дату нельзя было изменить. Такой высокобюджетный фильм, как Toy Story 2, имеет множество маркетинговых привязок, рекламных кампаний, и всё это должно идеально синхронизироваться с выпуском фильма.
Сдвинуть дату выпуска фильма за год безумно трудно. Сдвинуть её за шесть месяцев невозможно. Это означало, что команде придётся переделать Toy Story 2 за 9 месяцев. И всё потому, что они стремились сделать максимально качественный продукт.
Руководство Disney не верило, что они справятся, но им удалось.
«Период с января по сентябрь 1999 года был занят невообразимой геракловой попыткой создать фильм заново. Это было одним из основополагающих камней в фундаменте корпоративной культуры Pixar. И только благодаря ему мы справились».
Сточасовые рабочие недели и так достаточно тяжелы для умственного и физического здоровья. Но когда они длятся 9 месяцев подряд, то это уже становится больше, чем служебный долг.
В то время Pixar была независимой акционерной компанией. Провал такого фильма, как Toy Story 2, невыпуск его вовремя снизил бы доверие к студии и разрушил экономику финансирования фильмов Disney.
«Нужно спасти Базза и Вуди. Спасти франшизу. Спасти фильм. Спасти компанию. На карту было поставлено всё».
«Историю игрушек 2» удалось завершить и выпустить вовремя. По всему миру она заработала 500 миллионов долларов, была номинирована на награду Киноакадемии и подтвердила репутацию Pixar как студии, не идущей на компромиссы.
Полученные уроки
В заключение Джейкоб сказал мне, что самое важное, что он извлёк из этой ситуации, было чувство товарищества команды Pixar.
«Раньше я никогда не ощущал его на таком уровне, потому что это была такая потеря, что для её объяснения даже не требовалось совещаний. Люди просто знали это. Знала не только компания, но даже родственники, друзья и люди из Поинт-Ричмонд. Возможно, именно благодаря этому результат работы оказался таким. Дело не в технологиях, а в чувствах».
Из этой ситуации я понял, что спонтанность общественной поддержки говорит об общем уровне культуры Pixar. Подобные вещи просто так не происходят. Невозможно потерпеть катастрофу и мгновенно развить чувство общности и товарищества.
Джейкоб соглашается со мной, вспоминая свои ощущения при восстановлении фильма: «Невозможно работать по 60 часов, не теряя концентрации. Но неожиданно откуда-то появляется еда. Кто-то приносит одеяло, кто-то заставляет тебя пойти в душ, а потом вернуться к работе. И ты спрашиваешь себя: „Как это получилось?“»
«Всё просто работало, и над этим не нужно было думать. Незабываемым после такого опыта стала дружба, появившаяся благодаря нему. Этот совместный путь объединил наше сообщество».
«Я никогда не забуду, что стал частью „Истории игрушек 2“. Мне очень повезло», — рассказывает Джейкоб. «Мне довелось работать на том уровне руководства, которое позволило нам сохранить Вуди и Базза, „Историю игрушек“ и саму франшизу. Обо всём этом мы и говорим сегодня».
Комментарии (83)
Dioxin
25.11.2019 09:30-1Системные администраторы
НУ вот и источник проблем.
Их должно быть один.zavodp
25.11.2019 10:53+2Системные администраторы
НУ вот и источник проблем.
Их должно быть один.
Точно, точно.
А потом этот один заболел, уехал в отпуск, его сбила машина, он решил уволится или т.п.
dimitry78
25.11.2019 19:25-3Какая печальная история — если стали пропадать файлы отрендеренные — то кто мешал посмотреть log в unix-laikly системе, какой паразит (с какого терминала и во сколько ввел) или там был такой гадюшник что все друг другу файлы стирали? а если у них папки расшарены (ISDN? да?) и текстурщик лез к моделеру…
dimitry78
25.11.2019 22:25-1по своему опыту работы — корежу локальные копии файлов, к результатам моей работы никто не лезет («они ходили по сети, у них работа такая :-((( „) впрочем, в 98 локальные харды могли быть настолько дороги, что все копались в одной шаре, ну тогда вопрос по бекапам — 100мильенов уе не причина нанять грамотных одминов, а нагибать сутки креаторов на восстановление… ну капитализьм можт запланировано было сорвать премьеру?
Iv38
26.11.2019 01:48+4Они и копались на одном диске по сети, об этом написано. Также говорится, что раздать всем грамотные права не представлялось возможным. Допустим хотя бы, что каждый из них пользовался своей собственной учёткой, а не одной на всех. И вот есть лог, они нашли виноватого в удалении. Как это помогло бы спасти работу и деньги?
excoder
25.11.2019 10:49+1Надеюсь, люди знали, за что работали, 100-часовые недели были сбалансированы высокими стоимостями акций художников, а на ура-культурой.
Xobotun
25.11.2019 11:09+2Забавно, я не знал, что в Pixar использовалась своя ОС, основанная на юниксе.
И ещё не очень понятно, почему их должна эскортировать полицейская машина, если они об этом не просили,– наверное, какие-то американские реалии.
Ещё не понятно, что за анимация "на лету" в сцене с псом Бастером – гугл выдаёт мне только фильм The Fly по запросу "animation on the fly". :/
И да, в месте под название Bugville такая история обязана была случиться! :D
Vsevo10d
25.11.2019 12:02И ещё не очень понятно, почему их должна эскортировать полицейская машина, если они об этом не просили
Даже в России можно попросить ДПСников сопроводить, если жена рожает — видео такие есть. А в статье написано — надеялись: «ехали… с мигающими фарами, надеясь… Но ни одна полицейская машина нас не заметила» — хз, что имелось в виду, может на аварийке, может дальним моргали. Но КМК в американских реалиях они могли в полицию позвонить и им бы не отказали.trolley813
25.11.2019 13:02Даже в России можно попросить ДПСников сопроводить, если жена рожает — видео такие есть.
Далеко ходить не надо — вот буквально дня 2 назад точно такой сценарий во всех смыслах этого слова проскочил в казанских новостях.
onlinehead
25.11.2019 12:47+1Забавно, я не знал, что в Pixar использовалась своя ОС, основанная на юниксе.
Не совсем своя. В работе использовались станции Silicon Graphics, которые скорее всего были под IRIX, который в свою очередь Unix-based.Xobotun
25.11.2019 12:57Эм, ок. Я, по-видимому, эту фразу не так понял:
Pixar — это широко открытая Unix-среда
Эх, профессиональные рабочие станции – это было круто, чувствуется.
nick758
25.11.2019 12:20+1Во время создания «Приключений Флика» большинство муравьёв удалили и их пришлось восстанавливать, потому что, разумеется, Pixar выполняла резервное копирование данных.
Подозреваю, что в оригинале опечатка. Должно быть «arts»?
SilverHorse
25.11.2019 12:55+1Сразу видно, что Приключения Флика (A Bug's Life) вы не смотрели, иначе поняли бы сразу, что опечатки тут скорее всего нет.
Barbaresk
26.11.2019 13:17Я вот не совсем понял, о каких «Приключениях Флика» идёт речь. Оказалось, что я смотрел этот мультфильм в нормальной локализации названия — «Жизнь жуков».
kryvichh
25.11.2019 14:12Получается, после команды rm -r -f * в Unix всё? Нет никакой возможности вытянуть только что удалённые файлы?
gnomeby
25.11.2019 14:37Это зависит от файловой системы с большего. Конечно есть возможность получить дамп с жёсткого диска, но на нём сложно найти границы файлов, а также понять какие файлы удалены правильно, а какие нет. Не говоря уж о том, что нет их названий. Поэтому применённый ряд мер более эффективен, чем попытка пользоваться каким-нибудь undelete.
Iv38
25.11.2019 17:11Да, намного проще было использовать бэкап. А если они этот бэкап развернули на тот же диск, то восстанавливать удалённые файлы после этого было уже совсем безнадёжно.
Norno
25.11.2019 17:34Ну, с высоты текущих реалий, правильнее было бы использовать какую-нибудь систему контроля версий, и давать пользователям доступ к ней, а не к файловой системе хранилища, тут тебе и разделение доступа, и аудит, и версионирование. А настоящего удаления у рядовых работников вовсе быть не должно, только права пометить файл как удаленный. Но были ли такие средства достаточно развиты и применимы в тот момент, сказать не возьмусь)
CrazyElf
25.11.2019 17:49+2Ну, CVS тогда уже была, но она была неудобной и малораспространённой. Лишнего места под хранение файлов не было, глобальных сетей толком не было. Да что там — даже локальные сети и то были не очень развиты. Это сейчас есть и средства и инфраструктура, а тогда…
catharsis
25.11.2019 19:25+2Гигабайтные бинари загрузить в CVS скорее всего было нельзя.
Наверное можно было нагородить что-то кастомное, но до тех пор очевидно не было повода этим всерьез озаботиться.
А еще «проект побился, но мы не знаем где и как» — столь же эпический фейл.khim
25.11.2019 20:26+1В CVS можно и терабайт загрузить. Только это бессмысленно. Потому что CVS хранит историю каждого файла отдельно. А когда у вас десятки тысяч файлов… я даже не знаю что из существовавшего в то время такое умело. Perforce, может быть…
XAHOK
27.11.2019 04:32Гигабайтные бинари загрузить в CVS скорее всего было нельзя.
На каждую версию бинарного файла хранится отдельный файл. В отличии от хранения диффов, место съедает очень быстро, а это был вообще 98 год, когда домашние винты, как и память, еще измерялись мегабайтами. А 10+ГБ серверного места было просто огромно. Причем надо учитывать, что на каждую модель и текстуру готовится по нескольку вариантов, часть из которых отбрасывается, но не удаляется, на всякий случай (те самые тысячи потерянных «ненужных» файлов).
Наверное можно было нагородить что-то кастомное, но до тех пор очевидно не было повода этим всерьез озаботиться.
Велосипед с квадратными колесами или бекапы на стриммер? Выбрали второе, но не учли лимиты. Всплывает такие проблемы обычно через несколько лет и в ограниченном случае, встречался с подобным на практике.
А еще «проект побился, но мы не знаем где и как» — столь же эпический фейл.
Вполне нормальное явление. И для тех годов, и даже позже.
Стори 1: 2004-2005 год, лицензия TES3 Morrowind с дополнениями. Не было упаковано целых 2 текстуры из сотен, которые отвечали за небо при снежной погоде на небольшом острове дополнения. Проект побитый, всплыло оно уже только у игроков, причем спустя NN часов игры в строго определенных условиях.
Стори 2, та же игра: Потрошил один плагин, вместо кувшинок в игре отображался огромный треугольник с восклицательным знаком, т.е. проблемы либо с моделью, либо с текстурой для модели. 1 игровой объект из тысяч статичных объектов, никаких ошибок, никаких логов, если не знаешь хотя бы локацию с проблемным объектом, найти среди тысяч статичных объектов просто невозможно.
Подозреваю что у пиксаров было что-то с аналогичной особенностью для рендера, т.е. допускающее рендер при частичной целостности проекта. Причем есть подозрение, что сделано оно было специально, т.к. выкачать 10 ГБ исходников для тестового локального рендера аниматору… да в 98 году… дорогое удовольствие.
А без логов… ну разве что файл с иерархической структурой проекта поможет, да какой параноик его предусмотрит при наличии бэкапов?
gnomeby
25.11.2019 14:40Используйте ext4magic для ext3/ext4.
Gutt
25.11.2019 15:23+1Только не забудьте прихватить в 1998 год машину времени.
CrazyElf
25.11.2019 17:00Да, в то время, если я правильно помню, не было никаких средств восстановления под юниксом, если уж удалил, то удалил.
khim
25.11.2019 20:29Всё было очччено по разному на разных версия Unix'а.
Опция «Undelete files (exte2fs only)» в Midnight Commander — это как раз описываемые времена… Сегодня она, скорее всего, уже просто не работает… давно не пробовал пользоваться — но в прошлом веке оно работало…
Iv38
25.11.2019 17:03+2Ну, в 98году, кстати, тоже были средства восстановления удаленных файлов. Потому что случайно удалять файлы люди научились как только придумали первую файловую систему.
khim
25.11.2019 20:31На всяких старых системах это вообще раз плюнуть было: там файлы не могли состоять из нескольких сегментов.
А на ЗС c этого Norton Utilities в 1982м начались…
rinaty
25.11.2019 15:39Вот тоже также подумал, видимо они понадеялись на бэкап и перезаписали диск с удаленными данными, а когда через неделю узнали что бэкап плохой то было уже поздно
sol77
25.11.2019 17:06-11ну блин это всего лишь мультфильм, а написано как будто тут прям драма Шекспира, чувствуется рука мастера кующего корпоративный дух, как то все раздуто и преувеличино
CrazyElf
25.11.2019 17:13+10Ну хорошо, мультфильм вас не впечатляет. А перспектива потери 100 миллионов долларов?
rg_software
25.11.2019 20:13-1Ну честно говоря, какие-то слишком тут позитивные комментарии. Обычно в темах подобного рода в мокрого места не остаётся от менеджмента, который ставит нереалистичные сроки, а потом простые исполнители убиваются на работе. Ну и про доступ под рутом кого угодно тоже самое, вспомните знаменитую историю с реддита про студента, который в первый день на рабочем месте грохнул основную БД. Но, видимо, Пиксару такое простительно :)
beeruser
25.11.2019 23:40+4>> который ставит нереалистичные сроки
Так они закончили за 9 месяцев до релиза, даже несмотря на этот инцидент.
Только вот продукт получился некачественным и пришлось переделывать.
Но вообще я в шоке, конечно.
10GB проект копируется на 4GB ленту и никто об этом не знает.
Скорее всего никто даже не поинтересовался сколько он занимает.
Никто не пробовал проверить работоспособность бэкапа.
Техдир проекта «случайно» вспоминает что у неё дома есть копия фильма.
Goodkat
25.11.2019 23:5910GB проект копируется на 4GB ленту и никто об этом не знает
Возможно, предыдущий проект был размером в пару ГБ, и когда начали делать этот проект, он тоже влезал в 4 ГБ, он постепенно раздулся, но система бэкапа всего лишь не прислала сообщение об ошибке.
rg_software
26.11.2019 09:42Ну закончили они всё-таки благодаря каким-то стахановским геройствам. Тогда не совсем понятно, зачем они так убивались после краша, если у них времени было в запасе. Ну и работали бы спокойненько, восстанавливали данные в рабочем режиме.
sumanai
26.11.2019 12:25Тогда бы не успели переделать.
rg_software
26.11.2019 12:32Ну согласитесь, звучит странно: у нас был краш, и мы бросились на амбразуру с таким рвением, что закончили на 9 мес раньше срока. Где-то там недоговаривают.
Mingun
26.11.2019 18:13С чего вы взяли, что они закончили за 9 месяцев до релиза? За 9 месяцев до релиза они поняли, что то, что они делают сейчас, никуда не годится и всё надо переделать. Это вполне могла быть как половина работы, так и треть или 75%, нам об этом не сказали.
vedenin1980
26.11.2019 02:22+2Но, видимо, Пиксару такое простительно
Нет. Все это простительно компании 21 год назад. Если что тогда web с гуглом еще пешком под стол ходили и не было нормальных систем контроля версий, бекапов и разделения доступа. Многое из того, что нам кажется очевидным сейчас, тогда было совсем не очевидным.rg_software
26.11.2019 09:40Ну, очень странные вещи вы говорите. как будто бы в это время динозавры по улицам ходили. Веб с гуглом к описываемой теме никакого отношения не имеют, а Perforce — система контроля версий, специально рассчитанная на бинарные файлы, существует с 1995 года.
Я бы сказал, что ровно наоборот — сейчас оборудование куда надёжнее, плюс есть штуки типа дропбокса, поэтому я сам сейчас менее аккуратно отношусь к бэкапам, чем в те годы. Тогда я знал, что винчестер может полететь в любой момент, и следил, чтобы мои проекты не пропадали. Но куда мне до опыта и практик многомиллионной компании, конечно.CrazyElf
26.11.2019 09:48+1Даже если что тогда и было, то далеко не все об этом знали. Это сейчас любая толковая тулза может быстро войти в обиход. А тогда была туча разных не очень совместимых между собой UNIX-ов, софт был часто самописный какой-то и вообще был зоопарк, разброд и шатания. Сейчас то легко говорить, когда есть и знания и софт и всё что хочешь. А тогда всё было в диковинку и в новинку.
rg_software
26.11.2019 12:29Ну почему вы так думаете? Были специализированные журналы, конференции, реклама. Тот же perforce как-то надо было рекламировать и продавать. В любом случае, посмотрите на это вот как: допустим, все это сложно и ново. Но ведь у них были IT-спецы, чьей прямой работой было как раз всем этим заниматься и точно себе представлять, что они будут делать, если кто-то сдуру сделает rm — rf. Собственно, им и платят за то, чтобы они разбирались в сложных и новых технологиях, даже без Гугла.
CrazyElf
26.11.2019 12:55Зачем мне думать, если я тогда жил и работал в конторе, у которой чуть не у первой в городе на серверах стояли юниксы в ассортименте :) Я не был админом и может не всё помню, но в общих чертах я не забыл как именно всё тогда было.
CrazyElf
25.11.2019 17:07+3В моей конторе в те годы тоже был случай с rm -rf, когда админ по телефону командовал действиями оператора в другом городе, пытаясь почистить место на переполненном SCO Unix сервере. (О нормальном заходе терминалом по тогдашним телефонным линиям с их качеством можно было только мечтать.) Хотел он так почистить лишние драйвера, но команда cd не прошла, а он не проконтролировал лишний раз. В итоге получился классический rm -rf * от корня. Сервер умер и админ поехал в командировку — переустанавливать сервер.
CrazyElf
25.11.2019 17:11+2И бэкапом тоже там как-то был классический случай, когда всё регулярно бэкапилось, а когда накрылись диски и понадобился бэкап, то выяснилось, что zip архивы с бэкапом получались битые по какой-то причине с определённого момента времени и никто это, конечно же, не проверял до момента, когда этот бэкап понадобился.
Естественно, после этого в регламент бэкапов было внесено требование регулярно пробовать накатывать бэкап на резервный сервер, сколько бы это времени и сил не занимало. И резервный сервер для этого, кстати, тут же выделили, до этого его необходимость доказать не удавалось.
Carburn
25.11.2019 17:36-10Кто-то скажет после таких примеров, что работать в командной строке это хорошо?
gnomeby
25.11.2019 17:47Ну права надо ограничивать, есть ACL. Всё можно настроить.
Carburn
25.11.2019 17:48Написано же в статье, что это было невозможно сделать. Вообще, у администраторов полный доступ.
gnomeby
25.11.2019 17:49+1А при чём здесь статья? 20 лет прошло. Сейчас есть все инструментарии для анального огораживания юзеров в командной строке.
Carburn
25.11.2019 17:51-1Как администраторов ограничишь?
gnomeby
25.11.2019 18:00+2Сегодня есть системы контроля версий для бинарных файлов, можно не ограничивать.
Но если так совпало, что:
1. Нет системы контроля версий
2. И допустимо на проекте пользоваться rm
то:
Нужно сделать чтобы rm не удалял файлы а помещал в корзину на месяц. Например глобальным алиасом.Carburn
25.11.2019 18:01а если места нет? контроль версий только для исходного кода же используется обычно. А я в целом про сервер.
gnomeby
25.11.2019 18:17+2Слишком много «а если». У меня начинает возникать ощущение, что я вам оказываю бесплатные консультации по администрированию.
Давайте в последний раз:
* Контроль версий существует для бинарных файлов: Boar или любое хранилище артефактов, куда заливаются изменения скриптами по каждому чиху.
* Место — сегодня самый дешёвый ресурс. Если какая-либо проблема решается удалением фалов, скорее всего она решается неправильно.
* В целом про сервер: аудит всех вводимых команд (например через syslog-ng), автоматизированные сценарии раскатки серверов с нуля на другом железе и помещение etc в git, с автокоммитом.
maxzhurkin
25.11.2019 22:13+1В статье ни слова про административные права, только про доступность всех файлов проекта всем сотрудникам, которые с ним работают
Iv38
25.11.2019 18:41+6Но они ведь даже не знают как именно это произошло и кто виноват, это только предположение. Файлы можно и из через GUI так же покрошить, или неудачным скриптом. При большом количестве сотрудников с полным доступом к файлам, это уже не вопрос, случится ли такое, а вопрос как скоро. И в тексте прямо написано, что это не первый случай. Потому они уже делали бэкапы. Уже делали, но ещё не тестировали.
Но да rm, особенно с ключами -r и -f мощное и тихое оружие, очень опасное.Carburn
25.11.2019 19:03-5В GUI понятнее что удаляешь
catharsis
25.11.2019 19:54+1В GUI может быть легче перепутать текущую папку.
Поэтому придумали корзину (которая все равно не поможет с сетевой шарой)Iv38
26.11.2019 01:53Я привыкал к GUI Винды, когда диски были маленькими. Поэтому «Shift+Del, Enter» для удаления я нажимаю автоматически. Сейчас вот уже почти переучился в обратную сторону.
WanSpi
26.11.2019 14:22(которая все равно не поможет с сетевой шарой)
Это чего это вдруг? У меня на работе стоит NAS, который при удалении любого файла, помечает его как удаленный, и перемещает его в корзину, сколько файлы там храняться не скажу, но если случайно что то удалил, всегда можно востановить.
arkamax
25.11.2019 19:03+2В который раз убеждаюсь, что поиск виноватых — это в первую очередь баг человеческой психологии, которой проще по-быстрому приклеить ярлык, чем решить основополагающую проблему. Да, иногда виноваты конкретные люди, но статистически чаще проблема оказывается решаема через изменение внешних факторов.
catharsis
25.11.2019 19:29В основном это фича, но в крупных проектах/организациях скорее баг из-за стремления к гипержопоприкрывательству.
Накосячивший скорее всего больше такого не сделает и в среднем теперь будет работать лучше ненакосячившего.
Andronas
25.11.2019 20:26+2После удаления и восстановления Toy Story 2 команда надеялась на ничем не омрачённый выпуск продукта, но этому не суждено было случиться.
В Рождество 1998 года, после выпуска «Приключений Флика» и завершения рекламного тура Джон Лассетер, Эндрю Стэнтон, Пит Доктер и легендарный сценарист Джо Рэнфт решили оценить Toy Story 2.
Фильм был плохим. Они посвятили зимние каникулы почти полному переписыванию проекта с нуля. Производство было остановлено 15 декабря и возобновилось после Нового года, в январе, когда команда сценаристов повторно изложило идею фильма.
Т.е. данные вначале героически спасли и восстановили, а потом они опять отправились в мусорную корзину потому что «Фильм был плохим»? Рука-лицо
Что же там было плохого (это кстати не написано)?TimReset
25.11.2019 23:36Да, меня это как раз больше всего поразило — в статье подробно расписано восстановление, а потом как будто между делом упоминается что всё это было не нужно — всё равно большая часть была переделана.
Mana_Banana
26.11.2019 08:31Ну, всё достаточно логично. Они восстанавливали первую версию, которую в живую еще никто не видел от начала и до конца. Это всё же фильм. Потом, как собрали проект, посмотрели и поняли, что он не подходит. Могли бы понять это раньше, но удаление помешало.
Mingun
25.11.2019 22:39По следам соседней статьи: что-то у меня какое-то дежа вю, уже переводили эту историю на хабре. PatientZero ожидает зачет? :)
PatientZero Автор
25.11.2019 23:24Да, вы меня раскусили, все мои переводы — попытка умаслить препода ;)
PatientZero Автор
25.11.2019 23:26Перевода конкретно этой статьи я не нашёл, на Хабре был один пост про удаление Toy Story 2, но не такой подробный.
Direvius
25.11.2019 23:58+2«Быстро, в течение буквально пары часов, программисты написали скрипты, которые получали на входе список и создавали окна XF, по 20 файлов в глубину. Закрываешь их все, спускаешься ещё на 20 вглубь. Закрываешь их все, поэтому так можно двигаться очень быстро».
Все окна нужно было просматривать глазами, чтобы увидеть, какие из них короче, чем более новые.А написать скрипты, которые определяли более короткий вариант они не осилили? Вообще непонятно, что можно такого нарассматривать вручную в 30К файлов, чего не сможет рассмотреть алгоритм.
beeruser
26.11.2019 02:14Написать тулу даже на C, которая обойдёт рекурсивно две директории и сравнит размеры файлов в них (и содержимое) — пара пустяков. Похоже скорее на наказание всех из-за промаха одного.
Они занимались этим следующие несколько недель.
Типа xdiff вам в руки и барабан на шею.
Cenzo
26.11.2019 02:46+1Подозреваю, что не всегда последний вариант сцен или моделей был просто по размеру больше. Могли как добавлять что-то, так и удалять. Пробовать, и если не понравилось — откатить назад. А так как не было версионирования, пытались гадать что же являлось последней рабочей версией. Как-то работал в такой творческо-гуманитарной среде, классических творческий беспорядок там присутствовал всегда.
Stas911
26.11.2019 03:59+2Поиск виноватых в такой ситуации очень прост — виноват руководитель, которые не выстроил в компании процессы должным образом. И за его косяк расплачивались рядовые сотрудники 100 часовыми неделями.
Mana_Banana
26.11.2019 08:41Всё складывается со временем так, что мы не можем до конца понять «почему не поступили по другому?».
Вот вроде бы Пиксар, да и Джобс не последний в IT человек, но почему то администрирование плохо велось.
А может, если бы это всё выстроили, потратив кучу денег, времени и сил, всё это наоборот сделало бы трудней производство? Какие-то права, какой-то доступ, лишние двери на пути людей, которые просто творят вместе. Достают всё с одного сервера и на него же кладут по необходимости, без лишних вопросов по типу «кто забрал мой молоток?», «почему мне не выдают гвозди?».
Метод решения проблемы, да и само появление проблемы говорит о довольно сплочённом коллективе, который умело справлялся и без всего этого администрирования. Да, проблема случилась, но это скорее всего стечение обстоятельств, которое так же возможно и при сегодняшнем жестком контроле, который нужно еще настроить.Stas911
26.11.2019 16:21Как жесткий контроль над ежедневными ночными бэкапами затруднил бы работу аниматоров?
Mana_Banana
27.11.2019 08:21Конечно нет, но нужно понимать и осознавать то, что мы тоже в своё время не делали бэкапы, пока первый петух не клевал где не прикрыто было. Не было нужды или прецедентов, довольно расслабленная обстановка и много еще чего.
Nick_Shl
26.11.2019 07:48Через каждые несколько дней или недель текущие данные заменяются резервными копиями и работа продолжается, чтобы гарантировать, что все данные на месте. Такая практика называется «live backup».
Хороший метод "проверки"… звонок сисадминам: "Черт побери! Вырубайте сервер! Валидные данные фильма затираются битыми бэкапами!".CrazyElf
26.11.2019 09:51Ну да, тут как-то так написано… В оригинале имелось в виду, что они обмениваются местами. То есть текущие данные ничем не затираются, они кладутся на полку вместо бэкапа, а с бэкапом пробуют работать дальше. Если выяснится, что бэкап битый, можно вернуть текущую версию обратно в целости.
Nick_Shl
27.11.2019 02:42Простое бинарное сравнение нн катит? Вначале недели обменяли местами а "К концу недели выявилось достаточно ошибок, чтобы команда поняла, что есть проблемы" и результат недельной работы нужно выкинуть и начинать все сначала.
CrazyElf
27.11.2019 12:10Учитывая, что бэкапы были то на ленту, то ещё на что-то не очень то интерактивное и делались долго, не так то легко и быстро было их сравнить :)
drWhy
Epic Succes Toy Story 2. Спасибо за перевод.