Comments 197
Примечание: это моё личное мнение как индивидуального разработчика. Наша компания никоим образом не спонсируется и не связана с Google
Извините, но как это не спонсируется, если вам простили счет на $72`000? Счет хоть и достаточно спорный, но в основе своей правильный — ребята взяли инструмент и, не потрудившись разобраться, врубили его на over9000 %.
Счет хоть и достаточно спорный, но в основе своей правильный — ребята взяли инструмент и, не потрудившись разобраться, врубили его на over9000 %.Позволим себе возразить. Гугл без всякого разрешения «ребят» предоставил им кредитный лимит в 72 косаря. У автора, кстати, достаточно объемный кусок текста посвещен именно тому, что гугл накосячил в своей биллинговой системе и биллинговых правилах — загнав в такой долг в ситуации, в которой даже по своим же правилам не имел права этого делать. Будь автор упорнее, возможно ему удалось бы стрясти не только отмену счета, но и моральную компенсацию.
Ребятам дали бугатти покататься, они его раскочегарили до 420км/ч и насобирали штрафов, мне такая аналогия видится. Простили и ладно, в целом всем надо быть внимательнее, и гуглу и пользователям.
Может быть, но я все же считаю счет справедливымВ россии была тема с сотовыми операторами. Человек уезжал за границу кинув на счет 1500р, из-за лагов в выставлении биллинга или автовключения опции «доверительного платежа», приезжал и получал счет на 1.5млн. Требуют бабла. Справедливо?
Сейчас имеем дело со строителями. Насчитали одну смету, согласовали ее, потом по ходу работ сделали в 2 раза больше и итоговую смету выставили в 2 раза больше поставив перед фактом после окончания работ, не согласовывая в промежутке ничего. Требуют бабла. Справедливо?
Вы открываете пластиковую карту в банке. Специально дебитовую, не кредитную. Оплачиваете ей что-то в интернете, к Вам прицепляется подписка и загоняет Вас в долг на 200 тысяч рублей. Требуют бабла. Справедливо?
Банк выдал клиенту кредит на сумму которую он заведомо не сможет вернуть под залог квартиры. Требует бабла или квартиру. Справедливо?
Можно накидать еще примеров.
И нет, это не справедливо. Нельзя просто взять и загнать клиента в долг без его согласия. Фирма может и должна приостановить оказание услуг в случае исчерпания баланса. Но любые кредитные операции, особенно если фирма не обладает банковской лицензией, должны совершаться с явного согласия клиента, написанного огромными церковнославянскими буквами:)
Ребятам дали бугатти покататься, они его раскочегарили до 420км/ч и насобирали штрафов, мне такая аналогия видится.В контексте этой истории аналогия с бугатти нам кажется более точной в следующем изложении:
ребятам дали бугатти налив 1л бензина и предупредив об этом, а когда они вернулись, им выставили счет на 12400 тонн авиационного керосина и услуги самолета-топливозаправщика, сказав что когда их литр кончился, то они автоматом подключили опцию автодолива бензина, а поскольку машина ехала, им пришлось вызвать самолет-топливозаправщик который смог заправить их на ходу… а почему они не заметили? Да потому что у топливо-заправщика была технология стелс, из-за которой его видно только через 24 часа после того как он где-то реально пролетит:)
Я имел ввиду то, что счет справедлив потому, что ребята реально напользовали столько.Мы понимаем, просто не согласны.
Наш тезис состоит в том, что поскольку обязанностью гугла было не дать им столько напользовать, то все из этого проистекающее сугубо проблема гугла.
Окей. Разовьем пример с бугатти.
Ребята поехали на нем и разбили его. Счет за починку в 500 тысяч справедлив выставленным им? Стоп, не отвечайте. Учтите два момента:
а) Машина должна была быть полностью застрахована по договору с франшизой в 100 баксов, но арендная контора этог не сделала.
б) Машина была разбита влетев в стройку эстакады, потому что рабочие не выставили ограниченительное ограждение.
Ребята разбили машину? Несомненно. Ущерб есть? Несомненно.
Справедлив ли счет к ним? Нет, тысяча чертей. Кто-то профакапил страховку и ограждения, а теперь пытается включить в счет графу «прокатило».
Судя по тому как, ребята были рады, что им простили счет, мне кажется, что в юридических доках гугла прописаны такие моменты, ну про то, что лимиты могут отработать с задержкой.Не хочется показаться противоречащими буквально всему, но опять же не согласимся:)
В сша судебные разбирательства дорогие и расходы на них не всегда компенсируются даже в случае выигрыша, проблема патентных троллей и на хабре habr.com/en/post/381709 и habr.com/en/post/284640 обсуждалась немного, проблема остальных судебных разбирательств не особо отличается.
Затраты на суд против гугла скорее всего составили бы сумму существенно больше чем эти 72 тысячи, поэтому да, маленькому человеку приходится радоваться когда его прощает большой дядя, даже если этот большой дядя только что отдавил ему мизинчик…
скорее всего все достаточно законноНе обязательно.
Закон для больших корпораций это не свод нерушимых правил, а соотношение выгода/потери. Выставят они 10 счетов по 72 косаря… 7 счетов клиенты оплатят, 2 счета придется простить, один дойдет до суда и отсудит 144 тысячи. Выгода налицо. Имхо — все такие вот «выставления задним числом» это сугубо «прокатило» в ресторанном счете.
Спрашивает у мастера:
— А что это за пункт «Прокатило» — 10000 руб????
Мастер:
— Не прокатило. Вычеркиваем.
Закон для больших корпораций это не свод нерушимых правил, а соотношение выгода/потери
наверное в больших корпорация просто физически невозможно соблюсти все законы, проще какие-то «мелочи» покрыть финансово
Затраты на суд против гугла скорее всего составили бы сумму существенно больше чем эти 72 тысячи
Но выиграв суд, они отбили бы и 72 тысячи по счёту, и компенсацию издержек.
В сша судебные разбирательства дорогие и расходы на них не всегда компенсируются даже в случае выигрыша, проблема патентных троллей и на хабре habr.com/en/post/381709 и habr.com/en/post/284640 обсуждалась немного, проблема остальных судебных разбирательств не особо отличается.
Я уж молчу про дорогих адвокатов, которые выигрывают суды даже когда клиент не прав (в данном контексте это про Гугл), и про трату времени — вместо того, чтобы релизнуть продукт «завтра» потратили несколько месяцев на изучение облака, а то потратили бы это время на суд, попутно обанкротились (другие проекты же тоже остановили, а работникам надо ЗП платить).
А так-то вообще после преодоления лимитов система почему-то решила, что «шпайш машт флоу», что и нарушает договор, и вообще какое-то дикое мошенничество, и тот же Гугл рисковал получить большие проблемы в попытках доказать в суде отсутствие злого умысла.
обязанностью гугла было не дать им столько напользовать
Не было у гугла такой обязанности. Внутренние правила гугла — это не обязанность. В любом юридически значимом месте будет написано что юзер сам должен следить за тем, что бы не потратить больше чем он хочет. В противном случае герои статьи могли бы не волноваться а просто пойти в суд. Нет судебного решения — у вас нет аргументов.
Публикуем, ждем недельку, смотрим в кеш гугла, выставляем счет за аренду.
Законно же, не? /s
То есть:
а) Оферту должно прочитать и принять лицо, уполномоченное заключить такой договор от лица компании, а не робот.
б) Действия, которые не выражают явного намерения заключить договор (посещение страницы не является таким действием), не могут быть акцептом оферты.
Выставить счёт, конечно же, законно. Но его можно так же законно опротестовать. Если прокатит, можно заработать немного денег. Если непрокатит — можно заработать немного проблем с коллективным иском от хитрых законников. И вопросов от налоговой в стиле "не занимаются ли тут финансированием терроризма и отмыванием денег".
Справедливо?
Нет, нет, нет, да. Потому что в первых трех случаях клиент не знал о том, что ему навешают долгов, а в последнем сам на это пошел добровольно. В случае описанном в посте это больше похоже на первые случаи, раз с них должны были только $100 списать, но раз автор об этом узнал постфактум, то и он виноват тоже (иными словами если бы этого пункта про $100 не было, то это был бы уже не глюк биллинга, а что-то типа «взять кредитку с большим лимитом и потратить ее»).
Не совсем понятен только второй пункт (что у вас такое написано в договоре со строителями-то, что они требуют плату за неподписанную смету?)
Я понимаю, что симпатии читателя на стороне потребителя (он им ближе), да и компании часто пользуются дырками в законах и мелким шрифтом, чтобы вводить в заблуждение, но давайте попробуем посмотреть на те же ситуации с другой стороны (про строителей — от себя нафантазировал, уж простите):
1) Ваш клиент воспользовался задержкой обработки счетов между вами и вашим заграничным партнером. Вам приходит счет на 1.4 млн рублей от вашего заграничного партнера, а клиент говорит «у меня на счету всего 1.5 т.р. было, а платить не буду, потому что думал, что раз задержка — значит бесплатно и на буквы в договоре/тарифе можно не обращать внимания». Это справедливо?
2) Заказчик дал устное согласие на изменение сметы. Вы потратили время рабочих и материалы, а теперь заказчик говорит «платить не буду, в изначальной смете этого не было». Это справедливо?
3) Клиент открыл счет с овердрафтом, правила использования которого прописаны в договоре. Положил $100 на счет, вы оплатили его фуршет в ресторане за $1000, включился овердрафт, а теперь клиент говорит, что денег у него нет. И фуршет обратно тоже не вернуть. Это справедливо?
4) С кредитом вообще не понятно. «На сумму которую он заведомо не сможет вернуть под залог квартиры». То есть сумму-то он вернуть сможет, но если продаст квартиру. В чем спорность ситуации? «Под залог» — это когда банк практически прямым текстом говорит «ЧУВАК, ТЫ НЕ СМОЖЕШЬ ВЕРНУТЬ ДОЛГ, НО ЕСЛИ ТЫ СОБИРАЕШЬСЯ РИСКНУТЬ — МЫ ДАДИМ ДЕНЕГ, ТОЛЬКО СТАВЬ НА ЭТО СВОЮ
Повторюсь: да, многие законы не известны или не понятны рядовому потребителю. Да, большие корпорации и банки пользуются малограмотностью, юридической неосведомленностью, мелким шрифтом в договорах и т.д. и я считаю, что это не очень хорошо, неэтично и в целом несправедливо, да.
Однако во всех вышеперечисленных случаях спасает банальное прочтение договора.
Ну и про индусов из статьи аналогия скорее такая:
Ты дал ключ от F15 клиенту. (типа шутка)
— Цена $1000 за 100 километр полёта.
— Ну я так немношк пролечусь, — ответил клиент и дал тебе $1000.
Придя в ангар клиенту скомандовал
— Подготовьте-ка мне мой F15.
— Как?
— А как вы обычно делаете?
— Ну обычно бак на полную, двигатели в форсированный режим и шансон на максимум.
— Сойдет!
После чего клиент поднимается в воздух и делает полный круг вокруг земного шарика и приземляется.
— Слушай, ты должен нам $40 000 000
— Так я же заплатил $1000, чойта я вам должен?
— Тебе ж было сказано, что это за километр.
— Эээ, а что не предупредил, когда километр кончился?
— Так ты на сверхзвуке рванул — пока мобилу доставал ты уже полпути пролетел. Да и вообще мог техникам сказать, что тебе ограничение по скорости в километр в час поставить, а не форсированный режим — точно бы не промахнулся.
Самый большой инстанс стоит десятки долларов в час.
Вот, а они запустили 1000 инстансов на 24 часа. О том и речь.
В AWS нет бесплатных аккаунтов
И хоть это и действительно бесплатно, снимать деньги начинают сразу при превышении лимитов.
И лично я теперь ещё подумаю, размещаться ли у них, если они позволяют клиенту уйти в такой минус без его согласия. А уж «мы тут автоматом вас перевели на платный акк» — по хорошему это повод идти в суд, ибо мошенничество чистейшего вида.
Амазон таким не страдает, как я помню.
Влететь на мегабаксы в Амазоне можно крайне легко. Особенно легко — в случае сервисов, которые сами запускают другие сервисы, та же Лямбда.
Тарификация в Амазоне, если не путаю, выдаётся в браузерной консоли с задержкой в час, так что следует быть крайне осторожным.
Регался в 2013-м на Амазоне поиграться на бесплатные кредиты. Запустил что-то, оставил на ночь, а тут оффер, релокейт, комп с собой не брал, в общем в этом году зашёл: долг баксов 600 и ничего не даёт сделать пока не погасишь.
Более того. В 2010 я акк забросил, с инвойсом на $5. В прошлом году мне акк опять понадобился, вошёл, всё удалено, и операции заблокированы. Написал в саппорт, просто попросил «забыть» долг, недели 2 восстанавливали доступность сервисов. Сейчас всё работает.
ЗЫ А инвойс так и висит.
2010-07-02
6709957
Charge
2010-07-02
Payment failed — Overdue
5.09 USD
Счёт явно не правильный. У ребят был выставлен лимит в $100. Если гугл технически неспособен его проконтролировать, то пусть выставляет счета сам себе. Удивляюсь, почему, аналогично gdpr, до скотов ещё не добрались со стороны регуляторов
По истечении бюджета не происходит автоматическая немедленная остановка всех сервисов и прекращение биллинга. Сервисы вообще невозможно немедленно остановить, особенно если там получилось какая-то рекурсия, когда одни инстансы запускают другие, тем более если это serverless сервисы (насколько я понимаю, в статье описывается serverless архитектура).
Превышение бюджета — это уведомление, на которое можно повесить определенные действия — по умолчанию это письмо на емэйл. Далее можно опционально добавить остановку инстансов EC2 (виртуальные машины) и RDS (база данных), но не serverless сервисов. И кроме того можно отправить уведомление в SNS (notification service), где на него может отреагировать какой-то код (но этот код еще надо написать).
Разработчикам надо было ставить разумные лимиты на использование конкретных сервисов (firebase, инстансы).
.
Нельзя просто так взять и махом вырубить все виртуалки, убить выполняющиеся процессы и очистить очереди от необработанных сообщений. Во многих случаях будут нарушения консистентности данных, которые потом будет сложно разрешить, и вообще есть вероятность, что сервис после этого не поднимется. Тогда уже могут быть претензии от больших компаний, где данные дороже денег, а не от стартаперов, копирующих код со stackoverflow.
Но какие-то более мягкие меры для уменьшения ущерба на стороне гугла, с моей точки зрения, должны были быть предусмотрены.
Скажем, могли бы быть установлены лимиты количества запросов для новых пользователей, которые расширялись бы по заявлению после подтверждения платежеспособности компании. По истечении такого лимита доступ в firebase мог бы быть заблокирован почти мгновенно, аналогично и возможность запуска cloud run могла бы быть заблокирована. Это безопасно с точки зрения сохранности данных, а экспоненциальный рост иссяк бы за несколько минут.
Но также я допускаю, что сервис не обязан иметь «защиту от дурака», если он рассчитан на профессионалов, а не на дураков :)
Похоже, что «догадываться» приходится только тем, кто не читает доки.
Я согласен, что такая большая задержка в биллинге сводит почти к нулю полезность данной функции, но, видимо, сценарий использования, на который рассчитывали создатели сервиса, не предполагал рекурсии с экспоненциальным ростом. Может быть, они извлекут урок.
Вряд ли это вообще где-то написано, потому что это вполне разумное и ожидаемое поведение.
«Ожидаемое» кем, сотрудниками гугла? Особенно в контексте получить побольше бабла?
Нельзя просто так взять и махом вырубить все виртуалки,
Виртуалки уже в 2008 умели такую штуку как pause. Также есть такая штука как cpu credits, и машина просто начинает работать медленнее, вплоть до полной остановки, оставаясь технически running. Так что было бы желание.
Корпорация «добра», что с неё взять…
У виртуалки на паузе идёт биллинг за хранилище и снапшоты. Чтобы остановить биллинг полностью, нужно грохнуть все данные, включая бэкапы. Такое поведение вы бы ожидали?
Это во многих случаях даже технически невозможно, у вас могут быть такие объемы данных, что их удалять надо будет несколько дней, а потом вы их будете несколько недель заливать обратно.
«Ожидаемое» кем, сотрудниками гугла?
Ожидаемое с точки зрения сохранности данных, я конкретно об этом написал. Деньги приходят и уходят, а данные не всегда можно вернуть. Это vps за 3 бакса вам могут удалить со всеми данными и сказать «а че такого?», а здесь другой подход.
Чтобы остановить биллинг полностью, нужно грохнуть все данные, включая бэкапы. Такое поведение вы бы ожидали?
Да. Но также я понимал бы, что для реально заметного счёта (а не лишние $7) нужно занять петабайты. Сколько Пб надо, чтобы за 2 дня насчитало $70k? Так почему по процу это норма?
что их удалять надо будет несколько дней
Место не равно количеству, если что. Можно забить хранилище файлами условно по 1Пб, но для всех фс умеющих в фоновое удаление — сам факт это простановка признака «удалено». Очистка — фоном, и там хоть год. А можно в цикле писать файлы меньше сектора, и будет что вся папка с накладными расходами 100гб — а там миллиарды файлов. И то, был у нас почтовик, там очередь набирала под миллион файлов (кривая настройка, да), но места там было чуть, несколько (десятков) гиг. Через find + xargs rm чистилось к слову неспешно, но без проблем. А вообще привет js с npm, у нас небольшая веб морда не упаковывалась в рпм пакет, потому что у рпм лимит был на примерно 100к файлов.
Это vps за 3 бакса вам могут удалить со всеми данными и сказать «а че такого?», а здесь другой подход.
Помнится, даже амазон данные терял, а казалось бы.
если он рассчитан на профессионалов
Судя по рекламе он так не позиционируется, а ровно наоборот: вам больше не нужны профессионалы по администрированию сервисов, мы делаем эту работу за вас
Такие техники — полностью вина на сервис-провайдерах (в данном случае гугл), система специально (понятно юридически доказать это очень сложно) выстраивается такой чтобы в тарифных планах были ценовые ловушки, просто на практике клиенты попадают на 10х от ожиданий, способны это заплатить и молча в тряпочку это делают.
Простой и относительно безопасный способ: файл типа secrets.conf или .env в .gitignore, при первом/каждом деплое там задаются пароли не из репозитория, приложение их читает при старте/релоаде, можно даже наблюдение за файлом сделать для автоматического релоада.
2) использовать vault или у амазона — SecretsManager
3) гитхаб уже штатно блочит такие вещи, и присылает письмо счастья.
Скорее всего не в «инструменте» проблема, а в:
« Мы действительно обнаружили новый способ использования бессерверного использования POST-запросов, который я не нашёл нигде в интернете, но задеплоили его без уточнения алгоритма»
То есть взяли кусок кода где то в интерне и без проверки (ВООБЩЕ) задеплоили.
То есть взяли кусок кода где то в интерне
Наоборот же, сами придумали монстра, который даже не гуглится.
Ну то есть ребята в принципе не особо понимают, что делают, собирая свой убер-стартап по кускам кода со stackoverflow, а в случае отсутствия — запиливая что-то таинственное в меру своего затейливо-гималайского восприятия окружающего мира.
Х@@к и в production с одной стороны (тестирования нет и не предполагалось). И "непрокатило " с другой. Без этого конфликта не было бы истории.
Ну Гугл конечно тоже молодцы, циничненько они так конечно ))
- Лимиты мы в реальном времени не обрабатываем
- А вот ваши расходы мы вам считаем исправно в риалтайме :)))
На сколько я знаю лучше всего дела в этом направлении идут у Амазана, у них на многих сервисах реальная посекундная тарификация.
Вообще сделать даже поминутную тарификацию очень сложно и это проблема не одного гугла. Просто попробуйте спроектировать такую систему. Вот у вас есть база данных, которая может обрабатывать 9млн запросов в минуту, как в статье, для одного клиента. Для всех клиентов она наверно 10^11 запросов в минуту обрабатывает, а то и больше. И нужно каждый запрос посчитать, перевести в доллары и обновить счёт у клиента и чтобы не тормозило… Это колоссальная задача, по ресурсам сравнимая с работой самой базы данных. Поэтому они и делают лаг, обновляют биллинг только раз в какой-то интервал, например в сутки. А пользователям рекомендуют следить за метриками и ставить лимиты по метрикам, т.к. метрика не требует особой обработки, это просто число запросов, его можно быстро выкинуть в АПИ и обновлять, а уж юзер сам решит как реагировать на взлёт метрик — например установит лимит.
Опять же в большой компании наверняка есть специальный отдел биллинга, то есть сервис базы данных сам ничего не переводит в деньги, он только отправляет метрики использования в систему биллинга, она там уже внутри в соответствии с тарифами пересчитывает в деньги, выставляет счета, списывает с карт. Это всё занимает время.
Так что на любой облачной платформе легко можно уйти в минус, если моментально создать нагрузку в 1000+ раз больше, чем ваша средняя нагрузка за день, вы просто сгенерируете себе счёт как за 1000 дней типичного использования.
Что странно конечно, это автоматический апгрейд уровня обслуживания. Если у них был бесплатный тарифный план, их должны были затротлить и всё. Вот в этом реальный косяк гугла, наверно поэтому они и не стали требовать оплату, поняли, что в суде проиграют
Просто попробуйте спроектировать такую систему.…
Это колоссальная задача, по ресурсам сравнимая с работой самой базы данных
Так сложилось, что буквально не так давно я проектировал подобную систему, но конечно меньших масштабов. Там все получается достаточно сложно, но не на столько, чтобы прям по ресурсам было как у самой базы данных, даже если она позволяет десятки миллиардов операций.
Ключ к скорости — аггрегации на уровне ближе к сервису и, очевидно, параллельность. У каждого сервиса есть usage метрики, из которых собственно потом считаются финансы. Если попытаться их кормить напрямую в биллинг систему, то считать быстро будет сложно, потому что количество операций будет фантастическим и фактически будет равно количеству операций во всех сервисах. Прогонять подобное безусловно крайне сложно.
Если же мы добавим всего один слой аггрегации (per account per billing item per minute) на уровне сервиса, где его будет достаточно просто создать и обслуживать (для большинства сервисов, не для гугла, но об этом ниже, но там тоже можно, хоть и сложнее), т.к. все данные вот они, под ногами и уже все равно отправляются в биллинговую систему, то мы уже получим количество операций равное колличеству юзеров * колличество billing items, в терминологии гугл-клауда это SKU. Представим, что мы будем считать все это централизовано в одной системе.
Попробуем порассуждать вслух.
Представим, что есть 50 миллионов активных пользователей гугл-клауда, общее колличество SKU «на сейчас» — 23390 (посмотрел специально в консольке). Представим что каждый пользователь пользуется как минимум четвертью сервисов (что сильно с запасом, реально будет сильно меньше), то есть у нас будет 5900 метрик на 50 миллионо пользователей в минуту, или 295,000,000,000 событий в минуту, или 4,916,666,666 событий в секунду, которые надо посчитать. Все еще много.
Теперь начнем делать расчеты per-service, что было бы логично, так как очевидно лимиты хочется выставлять per-service, а не per-sku, а значит и аггрегировать имеет смысл per-service. Наверняка у гугла внутренняя структура «сервисов» сложнее чем мы видим ее снаружи, но представим, что как мы видим, так оно и есть, это не сильно изменит картину. Биллинговая система гугла дает коммулятивные скидки per-service, что для нас еще один аргумент того, что можно все считать именно per-service, а выше просто аггрегировать финальный расчет per-user.
У гугл-клауда порядка 100 сервисов. Допустим, количество SKU в них одинаково (на самом деле где-то больше, где-то меньше, но допустим). Значит SKU per-service = 23390/100 = 2339.
Пусть те же 50 миллионов пользователей пользуются этим одним сервисом (худший вариант), а значит при биллинге раз в минуту количество событий будет 50000000 пользователей *2339 SKU = 116950000000 событий в минуту или 1,949,166,667 в секунду. Все еще много, но в целом подъемно для системы масштаба гугла, т.к. эта работа хорошо параллелится и у них есть базы, способные выдержать подобную нагрузку на чтение-запись.
А если биллить 1 раз в 5 минут по аггрегированным за 5 минут данным?
Тогда 116950000000 событий в 5 минут или 389,833,333 событий в секунду. Уже лучше, но все еще многовато. Но уже уверенно можно сказать что этот объем данных можно процессить.
А если 1 раз в 10 минут?
116950000000 событий в 10 минут или 194,916,666 событий в секунду. Вполне норм.
А если 1 раз в 30 минут?
Получится 64,972,222 событий в секунду. Или 812 тысяч cloud run контейнеров, каждый из которых процессит по 80 запросов параллельно. Многовато.
А если 1 раз в час?
Получится 32,486,111 событий в секунду и 406 тысяч контейнеров cloud run.
И это все при условии, что мы считаем коммулятивно весь сервис в одном месте и все 50 миллионов пользователей пользуются этим сервисом с большим количеством SKU. Если разделить расчеты, то количество операций получится то же, но они будут размазаны по большему количеству баз и сервисов.
Тем более мы точно знаем, что у гугла есть или аггрегация, или настолько быстрая база, что позволяет писать все метрики для всех пользователей. Как то же они биллинг считают, а значит и метрики пишут.
Да, это все сильно не бесплатно, но именно технических ограничений тут особых нет. Да и активных клиентов у них не 50 миллионов, а 4, судя по тому, что ищется.
Исходя из этих данных, нам понадобится около 65 тысяч контейнеров, чтобы процессить данные раз в полчаса для этого жирного сервиса, которым пользуется 100% юзеров. Уже более чем вменяемая цифра. Если допустить, что биллинг можно считать раз в час и это решит большинство проблем, то получится вообще около 33 тысяч контейнеров, что более чем ок.
Раз в сутки этот объем информации еще можно посчитать за более-менее внятные деньги, а вот 50 раз — уже дорого.
Это кстати некоторым образом объясняет, почему некоторые провайдеры вроде DO стараются вводить как можно меньше billing metrics и упрощать тарифы — просто потому, что считать развесистую систему метрик на каждый чих очень дорого.
Окей, забыли про маркетинг и ценовые ловушки.
Тупой пример — вы способны поднять распределенный кластер для хранения данных в оперативной памяти повышенной отказоустойчивости (это пальцем в небо, на основе косвенных уликах)? а гугл с его ресурсами способен, а это значит вместо прямой записи на диск они могут 'включить' кеш writeback или напрямую размещать файлы баз данных в оперативной памяти.
Дальше, маленькая компания не способна разработать/переделать проект, оптимально работающий в архитектуре, где не нужно заботиться именно о ненадежности хранилища, а вот крупные типа гугл вполне способны, мало того можно сначала разрабатывать опенсорс с классическим подходом, отлаживая идею а для внутреннего использования пилить оптимальный, используя наработки из опенсорс — весь мир будет использовать не оптимальный и мерить свои расходы соответственно.
Это реально, отличный пример смены парадигмы — rest с запуском приложения на каждый запрос -> на все работает внутри единого приложения, даже простейшие тесты перехода с http rest на websocket дают повышение скорости на порядок, а если еще и базу данных убрать, оставляя данные в оперативной памяти без смены форматов и сериализации…
Еще, на рынке уже есть мастодонты, конкурировать с ними никто адекватный не будет, силенок не хватит, максимум попытаться занять маленькую нишу (и даже в этом случае тебя мастодонты купят). Вы как клиент не будете рисковать с множеством никому неизвестных компаний, которые решают только по 1% ваших задач, вместо этого вы пойдете туда где ваши задачи решаются все в одном месте.
Я не спорю что можно сделать. Но вы сами согласны, что объем большой. А ещё нужно учесть, что раз в 30 минут не уберёт проблему описанную в статье. Если запустить большую параллельную задачу на pay as you go тарифе без ограничений по ресурсам даже за полчаса легко на много тысяч улететь. Я слышал, что Microsoft поставила цель сделать поминутный биллинг во всём azure, не уверен по срокам, но движение в эту сторону есть и уже есть некоторые сервисы, которые это умеют.
Также у пользователей существует фундаментальное не понимание как работает биллинг, в статье это упоминается "у меня на карте было всего 100$". В контексте, что "как же я мог потратить больше". А вот легко мог, потому что биллить карту даже раз в полчаса это мало реально, поэтому даже в деньгах лимит нужно явно устанавливать руками в сервисе. Иначе к тому времени когда система решить списать с карты, уже будет большой счёт
Поэтому лимит по бюджету вообще в принципе невозможен, так как невозможно при достижении бюджета мгновенно отрубить сервисы и прекратить списание денег.
« Вообще сделать даже поминутную тарификацию очень сложно и это проблема не одного гугла. Просто попробуйте спроектировать такую систему.»
Ну никто и не спорит что это очень не просто. Но мы же с вами сейчас говорим о Гугле а не МакДональдсе (отсылка к фильму с Кевином Спейси « Двадцать одно» 2008г).
Имхо это дырка. Любой получается, не имея средств может попользоваться мощной инфраструктурой Гугля. Имхо, должна быть какая то граница, с которой оплата должна осуществляться не кредитной картой, а переводами и заранее обговариваться.
В нулевых было одно время подобное. На сайт заходишь проверить свой IQ, а там мелким текстом, что пройдя тест ты тем самым осуществляешь подписку 80 евров в месяц. Мало того что тем самым завалил тест на IQ :) так ещё и счёт через пол года приходит и в придачу письмо от адвоката, мол не заплатите, айда в суд. И некоторые платили. Потом прикрыли эту лавочку.
Я к тому, что кто-то может попользоваться инфраструктурой и отнекаться в суде и у Гугле останется на бобах. А могут и криминальные типы попользоваться и ищи потом свищи. Ещё и крайними гуглы останутся.
Ок, я проигнорировал, что задеплоить SQL базу данных слишком затратно, хотя мускл какой-нибудь поднимается за полчаса. Я проигнорировал, что для создания тестовой даты людям потребовался высокопроизводительный AI, я не обратил внимания на то что команде потребовалась ночь, чтобы понять за что пришёл счёт. Пропустил мимо ушей тот факт, что они вообще не разбираются в том что делают, судя по описанию процесса, что в stackoverflow нагуглили то и запустили...
Но я не выдержал когда узнал что чел работал в гугле… Да как же так-то… Судя по тому какие вопросы задают подобные компании на собеседованиях там одни гении работают.
Я с пятилетним опытом работы с linux даже на четверть не могу ответить… Как в linux initrd работает, как docker изолирует и разделяет ресурсы ядра, как управляет памятью и её переполнением… Человек знающий детальные ответы на вопросы такого уровня просто что-то там поднимает о чем в интернете прочитал?
Такое впечатление, как-будто в IT начали как в шоубизнес набирать… С каким ПМ мне надо переспать для этой работы? Или пойти сделать операцию по смене расы на индуса что ли...
Извините, после 35 собеседований за последние два месяца наболело
Вы же не знаете, кем он там работал...
в IT начали как в шоубизнес набирать
Это уже давно так. Я вот уже второй месяц бодаюсь с ТП Microsoft по достаточно простой теме, счет людей, с которыми я говорил, приближается к 10, и никто, Карл, не знает, как решить мою проблему. По ней есть три набора документации, все три говорят разные вещи, не работает реально ни один. И всем нас… ть, что характерно, потому что никому из тех ~10 саппортистов лично не прилетит по башке, если оно не заработает. Если это не шоубизнес, тогда что?
"Или пойти сделать операцию по смене расы на индуса что ли..."
Кроме расы, нужно ещё правильных родственников получить. Индийское кумовство же.
Проблема в том из какого региона нанимают. Если вы живёте в России и хотите попасть в гугл, вас должны взять на довольно высокую позицию, чтобы имело смысл оплачивать переезд, визу и так далее. Поэтому отбор очень суровый.
Если вы уже живёте в США, есть рабочая виза или гражданство и вы ещё и студент последнего курса, то попасть на стажировку на начальную позицию не составляет особых проблем. Потребность в кадрах на порядок выше предложения, поэтому берут всех подряд
Человек знающий детальные ответы на вопросы такого уровня просто что-то там поднимает о чем в интернете прочитал?
Натыкался с год назад на статью человека, прошедшего в гугл где-то в америке, так вот он там описывал как проходило собеседование и как он с нуля(работал строителем что ли) к нему пол года готовился на курсах… по подготовке к собеседованиям в FAANG. То есть человек пол года учил то, что в этом году спрашивают на собеседованиях, профессиональный проходитель собеседований.
Каждый раз, читая очередной фейл, думаешь да как так то?!
Наверняка, автор зато мастерски раскладывает красно-чёрные деревья, разворачивает листы, разделяет ценности и всё это за bigO(1) и вообще без памяти.
Осталось только софт научиться писать и системы проектировать, ну это мелочи.
В Канаде есть закон, который ограничивает максимальную накрутку в 100 долларов в месяц за любые цифровые услуги, за всё, мобильный, интернет и прочее. Если гугл накрутил вам 72К, то он сам себе Буратино, имеет право только на тарифный план + $100. Это конечно в случае если вы сами не попросили снять данные лимиты.
Не уверен, но по-моему в штатах тоже такое есть.
(источник: иногда слишком много сижу на реддите)
«A service provider must suspend national and international data roaming charges once they reach $100 within a single monthly billing cycle, unless the account holder or authorized user expressly consents to pay additional charges.»
К облачным сервисам это никак не относится, кмк.
Ну есть определенные так сказать нюансы. Например реклама. Обычно это как выглядит, звпустили.вы на.виртуалке стартап, на нем три юзера. Потом подключаются гениальные маркетологи и закупают рекламу или размещают пост на хабре. У вас сразу лавинообразный наплыв юзеров. Сервис лег. Как с этим быть? Можно конечно лендинг разместить статикой отдельной от продукта. Но мало кто это делает
У VPS тоже есть лимиты по трафику, и как с google cloud надо внимательно изучать что произойдет при достижении этих лимитов.
А если серьезно, мне тоже не понятны такие заморочки, свой VPS всяко лучше будет, особенно когда проект на стадии прототипа и до продакшена еще как до Китая раком. И да, судя по описаным в статье ошибкам (сугубо мое мнение на основе прочитанного, ни на кого не гоню, и могу ошибаться) они и VPS без выстрела в колено поднять бы не смогли. Хотя с другой стороны, если команда из вчерашних студентов, толком порох не нюхавшех, то в принципе неплохой опыт, в следующий раз будут хотя бы мануалы внимательно читать
Было нечто похожее пару лет назад с Селектелом.
Запустилась по крону задача бэкапа одного раздела в облачное хранилища. В норме там совсем немного файлов и задача отрабатывает за минуту.
Но в этот раз что-то пошло не так.
Утречком выяснилось, что "все тормозит". Почему тормозит? Да потому что задача бэкапа работает. А что он делает? Ну, смотрю в логи и ничего не понимаю — вроде работает, вроде всё в порядке, но… что-то тут не то… Тормоза закончились через несколько часов, а я так и не понял, "что это было".
Когда обломался следующий бэкап, я полез в консоль селектела и обнаружил, что должен им что-то около 10к рублей.
О.о
И что это было?
А вот что:
Незадолго до этого я игрался с Vagga (система виртуализации, аналог докера) на этом разделе и Vagga мне создала в одном из своих служебных каталогов несколько миллионов файлов. И всё это поехало бэкапиться (в 5 часов утра, как полагается, когда я сладко спал).
PUT файла стоил совсем чуть-чуть (1.4 копейки, что ли, не помню), но их были миллионы.
Деньги на счету кончились довольно быстро, через полчаса. И по хорошему, доступ к контейнеру должен был бы отрубиться, а задача бэкапа вылететь с ошибкой, но...
… но почему-то доступ не отрубился. И файлы заливались, и заливались, и заливались в облако.
А счет все уменьшался, уменьшался, уменьшался...
Что произошло раньше — бэкап закончился или биллинг селектела опомнился, что деньги в минусе — я не выяснил.
В общем, после долгих, очень долгих дискуссий эту проблему признали сначала багом, деньги простили (уффф), а потом фичей. И сказали, что да, теперь это фича, теперь это нормально, теперь счета могут улетать в минус.
Странное решение, как по мне, но я не работаю в селектеле. Возможно, пока не работаю.
P.S. Потом там в рамках этой задачи что-то чинили, меняли, снова чинили, снова меняли, но счета по прежнему могут уходить в минус.
то наберут своих кридитных…
Это не важно, для дебетной будет овердрафт, что еще дороже для платильщика
Стал в принципе крайне негативно относится к всякого рода автоматическим подпискам. А уж хрень по типу "оказал услугу, а потом проверил баланс клиента" и "автоматически списал деньги после окончания бесплатного периода" должна быть запрещена и отключена по-умолчанию, а разрешатся только с двойного подтверждения клиента.
А больше я вообще никакими подписками не пользуюсь. Есть ещё, конечно, плата за интернет на мобильнике и компьютере, но: а) там отдельный счёт; б) при нехватке средств просто прекращается оказание услуги до пополнения счёта.
Все метрики использования ресурсов тоже идут в реальном времени (см. в статье совет «используйте мониторинг»).
А биллинг не реалтаймовый — за воду раз в месяц, за клауд — раз в сутки.
Если вы шланг от водопровода кинете в окно, и за день сольёте годовой объём воды, вам счёт так просто не простят, как гугл, а возможно и спишут «автоматически» через судебных приставов.
Как-то не по себе сейчас стало за тестовый GCP аккаунт, который я был вынужден создать, чтобы протестить работу Speech To Text API от гугла.
- Во-первых, какого-то хрена всё, что можно было урлой с апи-ключом потестировать 10 лет назад, теперь требует аккаунта в облаке-%companyname% с подключением кредитки, созданием каких-то сервисов. То есть компании (конкретно, GCP и Azure у меня так появились) нарочно навязывают свои облачные аккаунты там, где они нафиг не нужны.
- На экране ввода кредитки там огромным шрифтом написано "МЫ НЕ БУДЕМ СНИМАТЬ С ВАС ДЕНЬГИ ПОКА ВЫ САМИ ВРУЧНУЮ НЕ ПРОАПГРЕЙДИТЕ ТАРИФ". А тут вот, оказывается, что-то что-то Firebase и хобана, автоматические попытки списания. Гугл ведёт себя как обычные жулики.
- Что если аккаунт банально взломают? Я понимаю, надо не допускать такого, но тут получается я уже рискую даже не своими деньгами, а каким-то гигантским кредитным плечом от гугла, которое никто не просил.
Супер прохладная история. Доки гугла отличные? Так почему вам потребовалась ночь чтобы разобраться в них? Или почему вы изначально не поняли, что и как работает. Да потому что нет у гугла никаких замечательных доков, сплошной маркетинговый булшит в скудной админке, где они оперируют в большинстве своем какими-то собственными понятиями, документации по которым просто нет. Ну и вот это желание постоянно пользоваться мифическими рубильниками, не разбираясь в них — это вот просто верх безответственности в IT. Да лучшеб вы сами все написали, чем пропагандировать такой идусский подход к разработке..
багованый недософт с красивой +- оболочкой запустили где-то на облаках. если б оно работало на вашем серваке, и все начало тупить, ибо ссд/нагружен на 99+%. то на этом история текущей альфа-бета версии благополучно закончилась.
Именно по-этому у меня сильная предвзятость к post-paid сервисам с "сложным биллингом". Если бы там был честный prepaid, их бы рубанули через 5 минут и они спокойно разбирались бы куда 7 баксов делось. Ну, или 100. Но не 60+ бесконечностей.
1) Сервисам нужно ограничивать объем ресурсов. А то можно завести аккаунт на бомжа с которого нечего взять, и выполнить расчёты хэшей криптовалюты. А если у этого бомжа 100 аккаунтов и 100 карточек, то можно обеспечить ему жилье в рамках благотворительной программы от Google, о которой сама компания не знает.
2) Надо быть внимательнее при работе с ткаими ресурсами.
3) Такая опасность делает сервисы менее полезными для разработчика. Одно дело, когда неправильная программа вдруг зависнет или посчитает не то — ну и ладно, поправлю. А при таких рисках надо всё более внимательно отслеживать заранее, то есть падает скорость разработки.
4) По-хорошему за найденную возможность использовать ресурсов больше, чем лимит на 4 порядка надо не счета выставлять, а давать премию по Bug Bounty, пока такие вещи делаются случайно, а не преднамеренно.
Ну всё логично, индус написал индусский код.
>>9 000 000 запросов в минуту
Хороший ddos.
И сколько стоит проскрапить весь интернет? Самое интересное не написали.
Сменил его на билайна, написал во все места кабинету, что отключаюсь от них и прошу расторгнуть договор, но идти в офис расторгать договор мне было в лом.
Кабинет еще два месяца начислял мне плату, потом таки отключил услугу(хотя по факту провод висел в воздухе). Писал и звонил мне полгода — на что я отвечал что услуга не оказывалась. В итоге перестали мне о себе напоминать.
Потом был МТС с интересным подарком в -500 рублей, Акадо и Ростелеком с точной копией истории кабинета и все сами рассосались, так как начисляли я считаю несправедливо и пойди они в суд с иском за не оказанную услугу скорее всего песперспективно.
Рассказываю, как я сжёг на $500 на GCP. При заказе VM можно выбрать тип диска. Если выбрать extreme iops, то включается режим бешенного принтера, причём какой именно нигде не видно.
При этом, если зайти в диски (не в создание VM) и попытаться создать там extreme iops, то там будет видно, что размер диска минимум 500Гб и 100000 pre-provisioned IOPS. В интерфейсе заказа VM такого нет, оно рядом между standard и balanced iops.
Как мы случайно сожгли $72 000 за два часа в Google Cloud Platform и чуть не обанкротились