Comments 46
Ставить под угрозу разработку крупного проекта путём отдачи репозитория сторонней компании, которая может всё без предупреждения отключить только потому, что левая пятка зачесалась — бесценно, чёрт побери.
Мне кажется, главный урок, который следовало/следует усвоить из этой истории — никогда не отдавать ничего критичного неконтролируемым тобой людям.
И свой репозиторий на своём сервере уж точно обошёлся бы дешевле, чем день простоя команды.
Мне кажется, главный урок, который следовало/следует усвоить из этой истории — никогда не отдавать ничего критичного неконтролируемым тобой людям.
И свой репозиторий на своём сервере уж точно обошёлся бы дешевле, чем день простоя команды.
Максимально несовременная точка зрения в эпоху, когда «все крутится на Амазоне».
А свои репозитории на своих серверах за все эти годы точно обошлись бы сильно дороже, чем день простоя. Притом, что свои сервера совсем не гарантируют отсутствие простоев.
А свои репозитории на своих серверах за все эти годы точно обошлись бы сильно дороже, чем день простоя. Притом, что свои сервера совсем не гарантируют отсутствие простоев.
Ну да. Тогда как Ваша «максимально современная» точка зрения привела к дню простоя, причём неконтролируемого и это стало поводом для статьи на хабре.
Ну банально — разбирательства с гитхабом могли затянуться на неопределённый срок. Здесь на Хабре достаточно примеров, как гитхаб блокировал репозитории просто потому что «они так решили». А ещё у них может случиться любая авария, утечка данных или они просто могут закрыться.
При этом шансов отсудить у гитхаба фактическую стоимость простоя бизнеса, в общем-то, не существует. Это же касается и Амазона «на котором всё крутится» и много кого ещё.
При этом имеется вполне достаточно локальных инструментов — тот же Gitlab, Phabricator, Gitea и т.д., с которыми вы не будете ограничены ни смехотворными 100гб на репозиторий, сможете делать бэкапы по любой удобной вам схеме, можете держать хоть кластер dev-серверов.
А также вы сможете в любой момент проверить фактическую работоспособность этих бэкапов, а в случае сбоя — у вас будут ваши люди, которые будут чинить этот сбой, а не безликий баннер на сайте «у нас технические проблемы, но мы уже знаем и наши инженеры работают над этим».
Ну банально — разбирательства с гитхабом могли затянуться на неопределённый срок. Здесь на Хабре достаточно примеров, как гитхаб блокировал репозитории просто потому что «они так решили». А ещё у них может случиться любая авария, утечка данных или они просто могут закрыться.
При этом шансов отсудить у гитхаба фактическую стоимость простоя бизнеса, в общем-то, не существует. Это же касается и Амазона «на котором всё крутится» и много кого ещё.
При этом имеется вполне достаточно локальных инструментов — тот же Gitlab, Phabricator, Gitea и т.д., с которыми вы не будете ограничены ни смехотворными 100гб на репозиторий, сможете делать бэкапы по любой удобной вам схеме, можете держать хоть кластер dev-серверов.
А также вы сможете в любой момент проверить фактическую работоспособность этих бэкапов, а в случае сбоя — у вас будут ваши люди, которые будут чинить этот сбой, а не безликий баннер на сайте «у нас технические проблемы, но мы уже знаем и наши инженеры работают над этим».
Кто мешает сделать зеркало на свои сервера?
GitHub берет на себя инфраструктуру и обслуживание, а бекапы никто не отменял.
А смысл? git устроен так, что по сути у каждого разработчика на компьютере полный бекап. Хостингов миллион, не понравился один — переедем на другой.
Все же сейчас облака — это стандарт де факто, строить свои датацентры желающих мало.
Ну и 100Гб на репозиторий — это вообще то много, git на такое на самом деле не особо рассчитан. То есть мы объективно работали неправильно, и этот случай помог нам пересмотреть свои подходы.
Все же сейчас облака — это стандарт де факто, строить свои датацентры желающих мало.
Ну и 100Гб на репозиторий — это вообще то много, git на такое на самом деле не особо рассчитан. То есть мы объективно работали неправильно, и этот случай помог нам пересмотреть свои подходы.
В том то и дело, все полагаются на облачные технологии, на их надёжность и забывают, что они, по сути, просто большое количество серверов, которые тоже могу ломаться.
Я, например, один из рабочих продуктов, разметил в Gilab, Github, Bitbucket и локальном репозитории. Это даёт мне возможность работать с продуктом из разных мест. Я просто читаю все репозитории и пишу тоже во все. Если один из ресурсов недоступен, то на него изменения прилетят в следующий раз. Во всех местах хранятся все ветки и все коммиты. В любой момент можно залить на очередной репозиторий и в нём окажется все, что есть в остальных.
На счёт бинарных данных, хорошо заметили. В проекте они тоже есть, но обновляются крайне редко. Хотя, урок для себя из статьи я вынес по данному моменту.
Я, например, один из рабочих продуктов, разметил в Gilab, Github, Bitbucket и локальном репозитории. Это даёт мне возможность работать с продуктом из разных мест. Я просто читаю все репозитории и пишу тоже во все. Если один из ресурсов недоступен, то на него изменения прилетят в следующий раз. Во всех местах хранятся все ветки и все коммиты. В любой момент можно залить на очередной репозиторий и в нём окажется все, что есть в остальных.
На счёт бинарных данных, хорошо заметили. В проекте они тоже есть, но обновляются крайне редко. Хотя, урок для себя из статьи я вынес по данному моменту.
Не знаете, к чему придраться — назовите противную точку зрения «несовременной». Я пришёл к диаметрально противоположному выводу: всё перетаскивать «на Амазон» в конечном итоге дороже, да и возиться с кучей поставщиков услуг надоедает — везде свои заморочки. А нужно многое: файловое хранилище, репозитории, билд-машина, хранилище документации, баг-трекер, какие-то собственные инструменты в виде веб-приложений, которые нужно расшарить на команду.
Поставил простой обычный NAS от Synology, держу всё это дело там и вообще ни о каких «планах», ограничениях, подписках и прочей ерунде не думаю.
Поставил простой обычный NAS от Synology, держу всё это дело там и вообще ни о каких «планах», ограничениях, подписках и прочей ерунде не думаю.
Всю инфраструктуру для сотен разработчиков из десятков городов на NAS? И туда же еще и production с миллионами игроков давайте закинем. Нет уж, мы лучше повозимся с поставщиками.
Да, когда-то и у нас было что-то подобное. Просто для разных масштабов нужны разные решения.
Да, когда-то и у нас было что-то подобное. Просто для разных масштабов нужны разные решения.
Аргумент вида «соломенное чучело»: поздравляю, achievement unlocked. Я не предлагал вам засовывать на NAS базу данных всех игроков.
У меня NAS для разработчиков, а для пользователей, разумеется, обычная production база данных в дата-центре. А вы попробуйте покритиковать исходную идею. Да, NAS для разработчиков из десятков городов. А в чём, собственно, проблема? Назовите хотя бы две штуки.
У меня NAS для разработчиков, а для пользователей, разумеется, обычная production база данных в дата-центре. А вы попробуйте покритиковать исходную идею. Да, NAS для разработчиков из десятков городов. А в чём, собственно, проблема? Назовите хотя бы две штуки.
Я не буду ввязываться в дискуссию. Мне достаточно аргумента про «бутылочное горлышко». Отключили интернет или (надолго) электричество там, где стоит NAS — и все встало. Можно, конечно, ставить генераторы и резервные каналы связи. Только нужно ли? Мы хотим доступности всех сервисов для разработки на том же уровне, что и production для игроков. И не хотим заморачиваться с обеспечением этого уровня сами. Если вы хотите — ваше решение, каждому свое.
И при любых обстоятельствах, все наше добро на один NAS ну вот никак не поместится.
И при любых обстоятельствах, все наше добро на один NAS ну вот никак не поместится.
Я не буду ввязываться в дискуссию. Мне достаточно аргумента про «бутылочное горлышко».
Разумеется. Ведь достаточно обозвать оппонента «ретроградом», а потом ещё и приписать ему то, что он не говорил.
Можно, конечно, ставить генераторы и резервные каналы связи. Только нужно ли?
Ну, ваша статья ровно об этом: «отключили интернет или электричество» или «закрыли доступ к репозиторию» — одного уровня проблемы. А они случаются и на вашей стороне, на стороне поставщиков — это всё неизбежно, и сложно сказать, что чаще бывает.
И при любых обстоятельствах, все наше добро на один NAS ну вот никак не поместится.
Да, пожалуй, ваши объёмы превосходят мои фантазии. Ну что ж.
Что-то мне подсказывает, что при их масштабах бедствия, обычный NAS уже тянет за собой необоснованно большие риски. И хочется уже делать как-то более по уму — хотя бы пару серверов, мастер-слейв с переключением, нормальный мониторинг этого добра, и прочие элементы собственной инфраструктуры. Не очень понимаю, что помешало это поднять.
Это же «что-то» должно вам подсказывать, что при наших масштабах бедствия «пара серверов» — это самое начало истории. У нас были сервера, их было гораздо больше, чем пара. Постепенно выпиливаем. В какой-то момент роста облака становятся и проще, и дешевле, и доступнее.
Серверная конечна по определению. И есть 3 бесконечные вещи — Вселенная, человеческая глупость, Амазон (С).
Серверная конечна по определению. И есть 3 бесконечные вещи — Вселенная, человеческая глупость, Амазон (С).
На следующем витке вы считаете экономику амазона и начинаете задумываться, не пора ли строить свой дата-центр :). Пока годовой счет от амазона меньше зарплаты 10-ти инженеров — туда даже смотреть не нужно.
Ну и кстати облако облаку рознь. Вы можете там инстансы гонять и по сути это будет почти своя инфраструктура, за которую вы «всего лишь» раза в два переплачиваете, в обмен на гибкость и отсутствие головняка с физическим масштабированием. А можете платить за «сервис» — когда в расчете на гигабайт/гигабит/гигафлопс вы переплачиваете раз в 20, но еще с вас снимают головняк по логическому масштабированию, безопасности и обеспечивают какой-то уровень SLA. В конечном итоге все сводится к тому, кто заплатит инженерам за чертову магию :)
Мы делаем и так и так. Иногда «гоняем инстансы», иногда сервис под ключ.
Низконагруженное выгоднее брать под ключ. Там получится «раз в 20 дороже» — $100 вместо $5, но зато все из коробки.
Высоконагруженное обычно лучше запилить свое, получится и дешевле, и можем сделать более кастомно. Там еще очень распространенный кейс: пользователи проснулись, надо в 3 раза больше серверов. Уснули — в 3 раза меньше. Или какой-то экшен в игре, то же самое. В Амазоне мы можем так сделать, у себя пришлось бы держать запас под максимальную нагрузку.
Низконагруженное выгоднее брать под ключ. Там получится «раз в 20 дороже» — $100 вместо $5, но зато все из коробки.
Высоконагруженное обычно лучше запилить свое, получится и дешевле, и можем сделать более кастомно. Там еще очень распространенный кейс: пользователи проснулись, надо в 3 раза больше серверов. Уснули — в 3 раза меньше. Или какой-то экшен в игре, то же самое. В Амазоне мы можем так сделать, у себя пришлось бы держать запас под максимальную нагрузку.
git же. «Отдача» на чужой сервер ничего особо не меняет – это просто +1 точка, где лежат исходники. И просто восстановить работу можно было очень быстро – разослав письмо с адресом локального репозитория и инструкцией по переключению.
Так тем более непонятно, почему это стало такой проблемой. Или они настолько слепо верили в непогрешимость облаков, что даже не озаботились поддержкой локального зеркала?
А что о ней заботиться? У каждого разработчика своё локальное зеркало есть, залить на общедоступный сервер недолго.
Подождём ответа от s_shestakov, думаю, что просто решили воспользоваться моментом и привести репу в порядок.
Подождём ответа от s_shestakov, думаю, что просто решили воспользоваться моментом и привести репу в порядок.
думаю, что просто решили воспользоваться моментом и привести репу в порядок.
Возможно :)
В этом случае ещё более доставляет заголовок статьи «была чуть не сорвана разработка Gardenscapes». Скандалы, интриги, расследования :)
А по факту просто мануал «как вычистить г… но из репы».
Может просто при таком размере каждый разработчик уже не держал у себя полный клон?
Можно же фетчем забрать только нужную ветку, минуя всю историю целиком.
Я понимаю, что история про гит, но ваша реклама на ютубе задолбала.
а) Не интересно.
б) Содержит сцены насилия с криками и т.д.
в) Раздражает.
(тем спорная, так что официально: это моя личная точка зрения, а не точка зрения компании)
Мы делаем подобную рекламу не потому, что любим сцены насилия и прочие ужасы. Мы делаем ее потому, что она работает лучше, чем «обычная». То есть для среднестатистического игрока больше вероятность установить игру после «плохой» рекламы, чем после «хорошей». Почему — мы не знаем. Возможно, с человечеством что-то не так :). Вы — видимо, не среднестатистический, так что извините за доставленные неудобства.
Я вообще рассматриваю это как перевоспитание. Человек приходит в игру, думая что там треш. А там на тебе, милый Остин восстанавливает сад, и все вокруг его друзья. И человек, сам того не замечая, становится добрее.
Мы делаем подобную рекламу не потому, что любим сцены насилия и прочие ужасы. Мы делаем ее потому, что она работает лучше, чем «обычная». То есть для среднестатистического игрока больше вероятность установить игру после «плохой» рекламы, чем после «хорошей». Почему — мы не знаем. Возможно, с человечеством что-то не так :). Вы — видимо, не среднестатистический, так что извините за доставленные неудобства.
Я вообще рассматриваю это как перевоспитание. Человек приходит в игру, думая что там треш. А там на тебе, милый Остин восстанавливает сад, и все вокруг его друзья. И человек, сам того не замечая, становится добрее.
А ещё эта реклама показывается в детских видео (включая колыбельные и т.д., в том числе в середине колыбельной). Если вас когда-нибудь забанят, знайте, где-то есть человек, который тщательно помечает его как inappropriate, потому что оно inappropriate.
Не защищая автора, просто обратите внимание на баннерорезки. Читая ужасы о рекламе, я в недоумении, понимаю, что далек от этого. На телефоне кстати снесены приложения ютуба, и он прекрасно работает через браузер.
Очевидно, что дети, которые смотрят колыбельные — не наша целевая аудитория. Мы сами не хотим показывать им эту рекламу, это бессмысленно. Тут вопрос скорее к алгоритмам YouTube. Ваши inappropriate помогают им настроить алгоритмы, так что здесь мы с вами солидарны.
А поставить галку "не показывать в детских видео" не судьба?
Была бы — поставили бы. Я же говорю, это и в наших интересах тоже — показывать рекламу только тем, кому она подходит. Таргетинг мобильной рекламы устроен не так просто. А ребята из гугла считают, что им виднее, какие крутилки нужны. Мы иногда пробуем их переубедить, но, как говорится, где гугл — а где мы.
Мсье Густав, это вы?
Полностью поддерживаю. Более того, она даже не соответствует реальной игре. В сторе полно отзывов об этом обмане. Ребенок тоже повелся, установили и в итоге там оказалось совсем другое. Эта реклама повсюду, и достала многих. Вы бы постыдились в открытую писать название этой игры здесь :)
Ну игра на самом деле неплохая, но… Мне у них не нравятся две вещи — вот эта вот дурацкая реклама (раньше была лучше и давала адекватное представление об игре) и то, что они ввели премиум-пасс. Я, конечно, понимаю, что постоянный доход это хорошо, но не по цене же сравнимой с крупными MMORPG). В общем момент введения премиум-пасса стал моментом, когда я удалил эту игру, пусть и с сожалением.
Есть ещё адекватные регуляторы.
В рекламе ещё и чей-то чужой геймплей показан. За что такие игры и получают свою заслуженную звёздочку, но рекламщики, похоже, только увеличивают бюджет.
А зачем делать git gc в этом сценарии? Разве без него не зальется и так?
Я предполагаю, что это была попытка оценить итоговый размер репозитория после всех этих операций.
С другой стороны, после gc можно было вызвать git repack, упаковать все в один или несколько пакетов и потом только вызывать git push, это могло уменьшить количество передаваемых данных и возможно позволило бы запушить без разделения на несколько посылок, хотя не факт и над тем, как разбивать коммиты на эти пакеты пришлось бы отдельно думать.
Странно конечно. Помню раньше на странице самого github была статья — что если вам таки действительно надо удалить файл и чтобы на 146%, то это можно сделать только через их техподдержку
Да, удалить файл насовсем сложно.
Из репозитория можно удалить файл описанным в статье способом. Причем это будет связано с изменением истории, то есть у пользователей репозитория неизбежно возникнут проблемы. При этом у гитахаба, вероятно, есть еще и резервные копии, которых мы не видим. Из них файл, естественно, не удалится. Так что да, если вы случайно закоммитили номер вашей кредитки, то техподдержка — правильный способ.
Из репозитория можно удалить файл описанным в статье способом. Причем это будет связано с изменением истории, то есть у пользователей репозитория неизбежно возникнут проблемы. При этом у гитахаба, вероятно, есть еще и резервные копии, которых мы не видим. Из них файл, естественно, не удалится. Так что да, если вы случайно закоммитили номер вашей кредитки, то техподдержка — правильный способ.
Sign up to leave a comment.
Как однажды была чуть не сорвана разработка Gardenscapes