Pull to refresh

Comments 197

Примечание: это моё личное мнение как индивидуального разработчика. Наша компания никоим образом не спонсируется и не связана с Google

Извините, но как это не спонсируется, если вам простили счет на $72`000? Счет хоть и достаточно спорный, но в основе своей правильный — ребята взяли инструмент и, не потрудившись разобраться, врубили его на over9000 %.
Счет хоть и достаточно спорный, но в основе своей правильный — ребята взяли инструмент и, не потрудившись разобраться, врубили его на over9000 %.
Позволим себе возразить. Гугл без всякого разрешения «ребят» предоставил им кредитный лимит в 72 косаря. У автора, кстати, достаточно объемный кусок текста посвещен именно тому, что гугл накосячил в своей биллинговой системе и биллинговых правилах — загнав в такой долг в ситуации, в которой даже по своим же правилам не имел права этого делать. Будь автор упорнее, возможно ему удалось бы стрясти не только отмену счета, но и моральную компенсацию.
Может быть, но я все же считаю счет справедливым, равно как и то что они его простили )
Ребятам дали бугатти покататься, они его раскочегарили до 420км/ч и насобирали штрафов, мне такая аналогия видится. Простили и ладно, в целом всем надо быть внимательнее, и гуглу и пользователям.
Может быть, но я все же считаю счет справедливым
В россии была тема с сотовыми операторами. Человек уезжал за границу кинув на счет 1500р, из-за лагов в выставлении биллинга или автовключения опции «доверительного платежа», приезжал и получал счет на 1.5млн. Требуют бабла. Справедливо?
Сейчас имеем дело со строителями. Насчитали одну смету, согласовали ее, потом по ходу работ сделали в 2 раза больше и итоговую смету выставили в 2 раза больше поставив перед фактом после окончания работ, не согласовывая в промежутке ничего. Требуют бабла. Справедливо?
Вы открываете пластиковую карту в банке. Специально дебитовую, не кредитную. Оплачиваете ей что-то в интернете, к Вам прицепляется подписка и загоняет Вас в долг на 200 тысяч рублей. Требуют бабла. Справедливо?
Банк выдал клиенту кредит на сумму которую он заведомо не сможет вернуть под залог квартиры. Требует бабла или квартиру. Справедливо?

Можно накидать еще примеров.

И нет, это не справедливо. Нельзя просто взять и загнать клиента в долг без его согласия. Фирма может и должна приостановить оказание услуг в случае исчерпания баланса. Но любые кредитные операции, особенно если фирма не обладает банковской лицензией, должны совершаться с явного согласия клиента, написанного огромными церковнославянскими буквами:)

Ребятам дали бугатти покататься, они его раскочегарили до 420км/ч и насобирали штрафов, мне такая аналогия видится.
В контексте этой истории аналогия с бугатти нам кажется более точной в следующем изложении:
ребятам дали бугатти налив 1л бензина и предупредив об этом, а когда они вернулись, им выставили счет на 12400 тонн авиационного керосина и услуги самолета-топливозаправщика, сказав что когда их литр кончился, то они автоматом подключили опцию автодолива бензина, а поскольку машина ехала, им пришлось вызвать самолет-топливозаправщик который смог заправить их на ходу… а почему они не заметили? Да потому что у топливо-заправщика была технология стелс, из-за которой его видно только через 24 часа после того как он где-то реально пролетит:)
Я имел ввиду то, что счет справедлив потому, что ребята реально напользовали столько. Ровно также я считаю справедливым и то, что им его отменили, чисто по-человечески. В целом тут все не правы, одни фуфловый код задеплоили, другие превысили лимиты, соглашусь. Скорее всего ребята такую лажу и лупанули не проверяя, в надежде на $100 лимит. Не удивлюсь, если у гугла есть где-то мелкий шрифт про то, что билинг может отставать и лимиты могут превыситься, вот почти уверен.
Я имел ввиду то, что счет справедлив потому, что ребята реально напользовали столько.
Мы понимаем, просто не согласны.
Наш тезис состоит в том, что поскольку обязанностью гугла было не дать им столько напользовать, то все из этого проистекающее сугубо проблема гугла.
Окей. Разовьем пример с бугатти.
Ребята поехали на нем и разбили его. Счет за починку в 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 обсуждалась немного, проблема остальных судебных разбирательств не особо отличается.


Я уж молчу про дорогих адвокатов, которые выигрывают суды даже когда клиент не прав (в данном контексте это про Гугл), и про трату времени — вместо того, чтобы релизнуть продукт «завтра» потратили несколько месяцев на изучение облака, а то потратили бы это время на суд, попутно обанкротились (другие проекты же тоже остановили, а работникам надо ЗП платить).

А так-то вообще после преодоления лимитов система почему-то решила, что «шпайш машт флоу», что и нарушает договор, и вообще какое-то дикое мошенничество, и тот же Гугл рисковал получить большие проблемы в попытках доказать в суде отсутствие злого умысла.
обязанностью гугла было не дать им столько напользовать

Не было у гугла такой обязанности. Внутренние правила гугла — это не обязанность. В любом юридически значимом месте будет написано что юзер сам должен следить за тем, что бы не потратить больше чем он хочет. В противном случае герои статьи могли бы не волноваться а просто пойти в суд. Нет судебного решения — у вас нет аргументов.
Автоматическая смена тарифного плана на ходу — это не вина клиента, кстати, скорее всего, даже если это будет прописано в этом тарифе
что бы не потратить

Есть разница между потратить и влезть в долги.

… создаем статическую страницу, на которой текстом указываем, что для поисковых роботов эта страничка предоставляется в аренду (недорого — 1 цент на 1 показ из кеша поисковика в сутки), а фактом акцепта оферты считается: заход робота на сайт и помещение странички в кеш.
Публикуем, ждем недельку, смотрим в кеш гугла, выставляем счет за аренду.
Законно же, не? /s
Не знаю, как в США, но в РФ акцептом оферты являются действия лица, к которому обращена оферта (т.е. компании Google), безоговорочно (недвусмысленно) подтверждающие его согласие заключить договор.

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

Иначе вы могли бы в метро повесить подобную оферту и мгновенно разбогатеть.

Выставить счёт, конечно же, законно. Но его можно так же законно опротестовать. Если прокатит, можно заработать немного денег. Если непрокатит — можно заработать немного проблем с коллективным иском от хитрых законников. И вопросов от налоговой в стиле "не занимаются ли тут финансированием терроризма и отмыванием денег".

Справедливо?

Нет, нет, нет, да. Потому что в первых трех случаях клиент не знал о том, что ему навешают долгов, а в последнем сам на это пошел добровольно. В случае описанном в посте это больше похоже на первые случаи, раз с них должны были только $100 списать, но раз автор об этом узнал постфактум, то и он виноват тоже (иными словами если бы этого пункта про $100 не было, то это был бы уже не глюк биллинга, а что-то типа «взять кредитку с большим лимитом и потратить ее»).
Все вышеприведенные случаи в общем-то зарегулированы законом и решаются чтением договора, который вы заключаете.

Не совсем понятен только второй пункт (что у вас такое написано в договоре со строителями-то, что они требуют плату за неподписанную смету?)

Я понимаю, что симпатии читателя на стороне потребителя (он им ближе), да и компании часто пользуются дырками в законах и мелким шрифтом, чтобы вводить в заблуждение, но давайте попробуем посмотреть на те же ситуации с другой стороны (про строителей — от себя нафантазировал, уж простите):

1) Ваш клиент воспользовался задержкой обработки счетов между вами и вашим заграничным партнером. Вам приходит счет на 1.4 млн рублей от вашего заграничного партнера, а клиент говорит «у меня на счету всего 1.5 т.р. было, а платить не буду, потому что думал, что раз задержка — значит бесплатно и на буквы в договоре/тарифе можно не обращать внимания». Это справедливо?
2) Заказчик дал устное согласие на изменение сметы. Вы потратили время рабочих и материалы, а теперь заказчик говорит «платить не буду, в изначальной смете этого не было». Это справедливо?
3) Клиент открыл счет с овердрафтом, правила использования которого прописаны в договоре. Положил $100 на счет, вы оплатили его фуршет в ресторане за $1000, включился овердрафт, а теперь клиент говорит, что денег у него нет. И фуршет обратно тоже не вернуть. Это справедливо?
4) С кредитом вообще не понятно. «На сумму которую он заведомо не сможет вернуть под залог квартиры». То есть сумму-то он вернуть сможет, но если продаст квартиру. В чем спорность ситуации? «Под залог» — это когда банк практически прямым текстом говорит «ЧУВАК, ТЫ НЕ СМОЖЕШЬ ВЕРНУТЬ ДОЛГ, НО ЕСЛИ ТЫ СОБИРАЕШЬСЯ РИСКНУТЬ — МЫ ДАДИМ ДЕНЕГ, ТОЛЬКО СТАВЬ НА ЭТО СВОЮ ЖКВАРТИРУ».

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

Ну и про индусов из статьи аналогия скорее такая:
Ты дал ключ от F15 клиенту. (типа шутка)
— Цена $1000 за 100 километр полёта.
— Ну я так немношк пролечусь, — ответил клиент и дал тебе $1000.
Придя в ангар клиенту скомандовал
— Подготовьте-ка мне мой F15.
— Как?
— А как вы обычно делаете?
— Ну обычно бак на полную, двигатели в форсированный режим и шансон на максимум.
— Сойдет!
После чего клиент поднимается в воздух и делает полный круг вокруг земного шарика и приземляется.
— Слушай, ты должен нам $40 000 000
— Так я же заплатил $1000, чойта я вам должен?
— Тебе ж было сказано, что это за километр.
— Эээ, а что не предупредил, когда километр кончился?
— Так ты на сверхзвуке рванул — пока мобилу доставал ты уже полпути пролетел. Да и вообще мог техникам сказать, что тебе ограничение по скорости в километр в час поставить, а не форсированный режим — точно бы не промахнулся.
Скорее дали бугатти, сказав что там вклюен ограничитель скорости на 15кмч, а оно у них рвануло с места на максимальных 1.2 кило-лошади мощности
Настройки по умолчанию были «максимальные 1.2 кило-лошади», парни это видели, но не придали этому значения. (Часто вы меняете настройки по умолчанию в программе/сервисе, которым пользуетесь впервые?)
Ну, например, в AWS я слабо могу себе представить, что можно такого случайно сделать, чтобы получить такой счет. Даже если клиент ошибся — за 10 минут десятки тысяч килобаксов не натекают (ну или я не слышал про такие случаи). Самый большой инстанс стоит десятки долларов в час. Контейнеры и лямбды имеют по-умолчанию лимиты порядка нескольких сотен на аккаунт — тоже не особо разгонишься.
Самый большой инстанс стоит десятки долларов в час.

Вот, а они запустили 1000 инстансов на 24 часа. О том и речь.
На самые большие инстансы в AWS крайне небольшие лимиты — тк их вообще часто немного в каждом регионе есть. И это точно не 1000.
В AWS тоже автоматически, без подтверждений с моей стороны, перевели бесплатный тестовый аккаунт в коммерческий и сразу попытались снять 54 доллара с карты. Слава богу им не это не удалось. Пришлось переписываться с поддержкой и закрывать свой аккаунт, хорошо хоть не стали дальше требовать деньги.

В AWS нет бесплатных аккаунтов

aws.amazon.com/ru/free
И хоть это и действительно бесплатно, снимать деньги начинают сразу при превышении лимитов.
UFO landed and left these words here
Free tier — это другое.

Деления на «бесплатные» и «коммерческие» аккаунты, как написал автор комментария, нет.
если так думать, то гугл может любого рекламодателя со 100 баксами загнать в долговую яму, выставив ему счет на 72т со словами «мы показывали вашу рекламу на все», а у вас и сайт упал от наплыва клиентов и долг «сформировался». собственно, зачем ограничиваться 72т? даешь миллион?
Так ведь тут разница в том что «показывать вашу рекламу на всё» ребята оставили как опцию по дефолту. Они поленились подумать над алгоритмом, поленились подумать над настройками облака, поленились настроить мониторинг, «уяк-уяк и в продакшн». А лимиты они работают как уведомления, а не как останов. Я не говорю, что это хорошо и классно, и не хотел бы к себе такого отношения, потому что ошибиться может каждый, но это справедливо поскольку прописано в доках гугла. Czz ниже все расписал.
Проблема не только в лимитах, но и в задержке в 48 часов.
И лично я теперь ещё подумаю, размещаться ли у них, если они позволяют клиенту уйти в такой минус без его согласия. А уж «мы тут автоматом вас перевели на платный акк» — по хорошему это повод идти в суд, ибо мошенничество чистейшего вида.
Амазон таким не страдает, как я помню.
В Амазоне можно успеть получить уведомление о превышении ожидаемого размера счёта (если настроили такое уведомление), но сервисы от этого не остановятся — пока сами не остановите (поправка: надо посмотреть, можно ли сейчас настроить действие наподобие «отключи нахрен такие-то и такие-то сервисы», в ответ на превышение порога ожидаемого счёта).

Влететь на мегабаксы в Амазоне можно крайне легко. Особенно легко — в случае сервисов, которые сами запускают другие сервисы, та же Лямбда.

Тарификация в Амазоне, если не путаю, выдаётся в браузерной консоли с задержкой в час, так что следует быть крайне осторожным.

Регался в 2013-м на Амазоне поиграться на бесплатные кредиты. Запустил что-то, оставил на ночь, а тут оффер, релокейт, комп с собой не брал, в общем в этом году зашёл: долг баксов 600 и ничего не даёт сделать пока не погасишь.

можно написать и попросить аннулировать, амазон даже десятки килобаксов прощает. Другой момент — что это их же просчёт, почему они продолжали оказывать услугу, по которой нет оплаты, явно не 1 месяц. Если были «бесплатные кредиты» то это 1 машина t2.micro, и несколько при условии типа t2.micro и 720 часов. Я сам запускал 3 машины на 10 дней — и это было мне бесплатно.
Более того. В 2010 я акк забросил, с инвойсом на $5. В прошлом году мне акк опять понадобился, вошёл, всё удалено, и операции заблокированы. Написал в саппорт, просто попросил «забыть» долг, недели 2 восстанавливали доступность сервисов. Сейчас всё работает.
ЗЫ А инвойс так и висит.
2010-07-02
6709957
Charge
2010-07-02
Payment failed — Overdue

5.09 USD

Видимо, на кого в саппорте нарвешься. Ну или сценарий на кейс "сначала оплатил, а потом попросил разблокировать" — другой.

Если вы дали покататься на бугатти ребёнку(стартаперу), то это ваша проблемма, а не его:)
У них точно не яйцо в эмблеме? А то что-то подозрительно напоминает.

Счёт явно не правильный. У ребят был выставлен лимит в $100. Если гугл технически неспособен его проконтролировать, то пусть выставляет счета сам себе. Удивляюсь, почему, аналогично gdpr, до скотов ещё не добрались со стороны регуляторов

Лимита в $100 не было. Текст, приведенный в статье, означает лишь, что списание с карты будет произведено, когда баланс станет $100 или более, либо по истечении 30 дней.
Читайте текст внимательней, лимит там был, правда не $100, а вообще $7.
Это тоже не лимит. Я сейчас опишу, как бюджет работает в амазоне, скорее всего в гугле аналогично.

По истечении бюджета не происходит автоматическая немедленная остановка всех сервисов и прекращение биллинга. Сервисы вообще невозможно немедленно остановить, особенно если там получилось какая-то рекурсия, когда одни инстансы запускают другие, тем более если это serverless сервисы (насколько я понимаю, в статье описывается serverless архитектура).

Превышение бюджета — это уведомление, на которое можно повесить определенные действия — по умолчанию это письмо на емэйл. Далее можно опционально добавить остановку инстансов EC2 (виртуальные машины) и RDS (база данных), но не serverless сервисов. И кроме того можно отправить уведомление в SNS (notification service), где на него может отреагировать какой-то код (но этот код еще надо написать).

Разработчикам надо было ставить разумные лимиты на использование конкретных сервисов (firebase, инстансы).
UFO landed and left these words here
Вряд ли это вообще где-то написано, потому что это вполне разумное и ожидаемое поведение.

Нельзя просто так взять и махом вырубить все виртуалки, убить выполняющиеся процессы и очистить очереди от необработанных сообщений. Во многих случаях будут нарушения консистентности данных, которые потом будет сложно разрешить, и вообще есть вероятность, что сервис после этого не поднимется. Тогда уже могут быть претензии от больших компаний, где данные дороже денег, а не от стартаперов, копирующих код со stackoverflow.

Но какие-то более мягкие меры для уменьшения ущерба на стороне гугла, с моей точки зрения, должны были быть предусмотрены.

Скажем, могли бы быть установлены лимиты количества запросов для новых пользователей, которые расширялись бы по заявлению после подтверждения платежеспособности компании. По истечении такого лимита доступ в firebase мог бы быть заблокирован почти мгновенно, аналогично и возможность запуска cloud run могла бы быть заблокирована. Это безопасно с точки зрения сохранности данных, а экспоненциальный рост иссяк бы за несколько минут.

Но также я допускаю, что сервис не обязан иметь «защиту от дурака», если он рассчитан на профессионалов, а не на дураков :)
UFO landed and left these words here
Я сейчас за несколько минут посмотрел документацию по бюджетам (https://cloud.google.com/billing/docs/how-to/budgets) и по функции cap usage (https://cloud.google.com/billing/docs/how-to/notify#cap_disable_billing_to_stop_usage), там нет никаких умолчаний, а предупреждения об особенностях, с которыми стартаперы неожиданно столкнулись, там видны почти сразу в синих рамочках, а не на 365-й странице.

Похоже, что «догадываться» приходится только тем, кто не читает доки.
UFO landed and left these words here
Вы все-таки немного драматизируете. Во-первых, написано достаточно заметно. Во-вторых, в долговую яму никто никого не загнал, у стартаперов есть право на ошибку. В-третьих, рекомендуется использовать лимиты по ресурсам, там гранулярность 100 секунд.

Я согласен, что такая большая задержка в биллинге сводит почти к нулю полезность данной функции, но, видимо, сценарий использования, на который рассчитывали создатели сервиса, не предполагал рекурсии с экспоненциальным ростом. Может быть, они извлекут урок.
UFO landed and left these words here

Как тут говорят, Гугл — не корпорация добра, так что вряд ли речь идёт об их доброй воле, а вероятно, есть какая-то политика и регламенты разруливания подобных ситуаций.

Вряд ли это вообще где-то написано, потому что это вполне разумное и ожидаемое поведение.

«Ожидаемое» кем, сотрудниками гугла? Особенно в контексте получить побольше бабла?

Нельзя просто так взять и махом вырубить все виртуалки,

Виртуалки уже в 2008 умели такую штуку как pause. Также есть такая штука как cpu credits, и машина просто начинает работать медленнее, вплоть до полной остановки, оставаясь технически running. Так что было бы желание.

Корпорация «добра», что с неё взять…

У виртуалки на паузе идёт биллинг за хранилище и снапшоты. Чтобы остановить биллинг полностью, нужно грохнуть все данные, включая бэкапы. Такое поведение вы бы ожидали?


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


«Ожидаемое» кем, сотрудниками гугла?

Ожидаемое с точки зрения сохранности данных, я конкретно об этом написал. Деньги приходят и уходят, а данные не всегда можно вернуть. Это vps за 3 бакса вам могут удалить со всеми данными и сказать «а че такого?», а здесь другой подход.

Чтобы остановить биллинг полностью, нужно грохнуть все данные, включая бэкапы. Такое поведение вы бы ожидали?

Да. Но также я понимал бы, что для реально заметного счёта (а не лишние $7) нужно занять петабайты. Сколько Пб надо, чтобы за 2 дня насчитало $70k? Так почему по процу это норма?

что их удалять надо будет несколько дней

Место не равно количеству, если что. Можно забить хранилище файлами условно по 1Пб, но для всех фс умеющих в фоновое удаление — сам факт это простановка признака «удалено». Очистка — фоном, и там хоть год. А можно в цикле писать файлы меньше сектора, и будет что вся папка с накладными расходами 100гб — а там миллиарды файлов. И то, был у нас почтовик, там очередь набирала под миллион файлов (кривая настройка, да), но места там было чуть, несколько (десятков) гиг. Через find + xargs rm чистилось к слову неспешно, но без проблем. А вообще привет js с npm, у нас небольшая веб морда не упаковывалась в рпм пакет, потому что у рпм лимит был на примерно 100к файлов.

Это vps за 3 бакса вам могут удалить со всеми данными и сказать «а че такого?», а здесь другой подход.

Помнится, даже амазон данные терял, а казалось бы.
если он рассчитан на профессионалов

Судя по рекламе он так не позиционируется, а ровно наоборот: вам больше не нужны профессионалы по администрированию сервисов, мы делаем эту работу за вас

Профессионалы по администрированию сервисов может и не нужны, а профессионалы-программисты, видимо, все-таки еще нужны :)

Настройка лимитов мышкой — работа программиста?

Работа программиста — выполнить задачу, использовав разумное количество ресурсов.
'Лимит' там БЫЛ! в 7$ проблема началась когда счет автоматически проапгрейдился.

Такие техники — полностью вина на сервис-провайдерах (в данном случае гугл), система специально (понятно юридически доказать это очень сложно) выстраивается такой чтобы в тарифных планах были ценовые ловушки, просто на практике клиенты попадают на 10х от ожиданий, способны это заплатить и молча в тряпочку это делают.

Это не лимит, а “free tier”, сумма, в рамках которой клиент пользуется сервисом бесплатно, а дальше начинает платить.


Клиенту «простили» услуг на 72000, офигеть ловушка, хотел бы я почаще попадать в такие ловушки.

Корпорации на удивление довольно серьезно относится к странным и необъяснимым начислениям, на своей шкуре убедился давно в их милости: одно время по инету гулял паук, который собирал данные Amazon EC2 и создавал на этих акках миллионы виртуальных машин (говорят что для майнинга, это как раз было тогда, когда это было модно-молодежно), под раздачу попал и я, когда в открытый репозиторий выложил проект, где хранились эти данные, за три часа мне накрутило 5 000 баксов (уже по курсу 70), это две средних зп программиста, конечно же было довольно обидно, в итоге они заблочили мне акк (хотя казалось бы, им-то что до этого), и так и написали, мол, это как-то нездорОво, у вас все нормально, а-то тут у людей акки воруют, может и у вас тоже, и я такой ой, да, вы уж извините дурака, сам не знал чо творил, и они аннулировали этот счет вообще без разбирательств (Гугл-то еще в чем-то разбирался, какое-то расследование проводил), а ведь тоже имели полное право сказать мол ну да, ходит паук по интернету, но ведь даже дети знают какие опасности подстерегают в инете на каждом шагу, так что сам мол виноват, долг платежом красен.
UFO landed and left these words here
Залил в открытый по ошибке, да. Забыл закрыть когда создавал. Я же и говорю, моя безалаберность.
UFO landed and left these words here
Да понятно, молодые, горячие были, там просто конфиг попал в прод, который не должен был. А «не хранить» это в смысле папку с ними запрещать для индексирования, или что?
UFO landed and left these words here
А где они должны быть? Если в БД, дак они все-равно как-то должны в нее записываться при деплое, не на бумаге же дампы хранить. Или может на перфокартах?
UFO landed and left these words here
Оооо, ясно, правда даже не знаю, очередной запрос к очередному api, но идея интересная благодарю. Неожиданная, я бы даже сказал бы :/

Простой и относительно безопасный способ: файл типа secrets.conf или .env в .gitignore, при первом/каждом деплое там задаются пароли не из репозитория, приложение их читает при старте/релоаде, можно даже наблюдение за файлом сделать для автоматического релоада.

О, да, благодарю, тоже интересно. Правда меня немного смущает что это все ради того, чтобы не хранить явки на Гитхабе, но когда бабки на кону — то да, перестраховаться стоит. Я просто, если честно, почему этот вопрос не прорабатывал — потому-что считаю панацеей приватные репы (понятно что на них тоже не желательно полагаться, но все), на худой конец Гитлаб локальный развернуть прям на компе без инета, да и всего делов, чем запросы очередные на Vault делать только ради конфигов, я уж не говорю о том, что к проду вообще нельзя из коробки доступ получить никак. В идеале имею ввиду, а не когда сервак реально сломали.

Я не ради сохранения секретов подходы с конфигом применяю. В основном, главное, что код из репы можно было развернуть в разных окружениях, с разными кредами к той же СУБД.

1) конфиги — в .gitignore, а примеры для настройки — в .sample с <here_password_or_hash>. Можно использовать симлинки, если и закоммитится конфиг с линком на ../../../configs/prod.conf — невелика потеря, при условии что configs выше корня проекта
2) использовать vault или у амазона — SecretsManager
3) гитхаб уже штатно блочит такие вещи, и присылает письмо счастья.
В США принято, что вы не несете обязательства по действиям третьих лиц, совершенные без вашего согласия, пусть вы даже и проявили крайнюю беспечность.
Ого! Ну это прям как с какой-то другой планеты новости (хотя чему я удивляюсь?). Это я отвечал человеку, который обвиняет автора в том, что это рекламная статья, типа вам же Гугл счет списал на 72 000, а вы говорите что никакого отношения к нему не имеете. Вот я и говорю, вполне обычная практика для них.

Скорее всего не в «инструменте» проблема, а в:


« Мы действительно обнаружили новый способ использования бессерверного использования POST-запросов, который я не нашёл нигде в интернете, но задеплоили его без уточнения алгоритма»


То есть взяли кусок кода где то в интерне и без проверки (ВООБЩЕ) задеплоили.

А еще вот в этом «Я практически не тратил времени на управление облаком — потратил ровно столько, чтобы поднять систему и обеспечить базовый процесс разработки (CI/CD).»
То есть взяли кусок кода где то в интерне

Наоборот же, сами придумали монстра, который даже не гуглится.
Да все лучше, выглядит так, что они не нашли в интернете подходящий исходник для отправки POST-запросов, поэтому запилили свой, не фильтрующий дубликатов — и тут же и выкатили, так и не приходя в сознание в своей парадигме «стремительно учиться и пробовать новые вещи». Такой себе обучающий DDoS за $72k получился.

Ну то есть ребята в принципе не особо понимают, что делают, собирая свой убер-стартап по кускам кода со stackoverflow, а в случае отсутствия — запиливая что-то таинственное в меру своего затейливо-гималайского восприятия окружающего мира.

Х@@к и в production с одной стороны (тестирования нет и не предполагалось). И "непрокатило " с другой. Без этого конфликта не было бы истории.

Во-во, Гугл им прощает долги из-за безалаберности (ибо я почитал выше что там пишут про их код, и это какой-то лютый сюр), а его обвиняют за это в том, что он статьи мол заказные заказывает…

Ну Гугл конечно тоже молодцы, циничненько они так конечно ))


  1. Лимиты мы в реальном времени не обрабатываем
  2. А вот ваши расходы мы вам считаем исправно в риалтайме :)))
Они молодцы настолько, что там в принципе нельзя выставить лимиты в деньгах, например $100. Можно лишь выставить алерты при достижении определенной суммы. А вот сами лимиты в обычном понимании — типа вырубить все сервисы при достижении лимита денег — нет такого. Там можно настроить лимиты, но не в деньгах, а в неких внутренних юнитах, отдельно для каждого сервиса. И для каждого сервиса стоимость юнита в долларах разная. В общем мрак. Поправьте меня, если лимиты в деньгах там таки настроить можно.

На сколько я знаю лучше всего дела в этом направлении идут у Амазана, у них на многих сервисах реальная посекундная тарификация.
Вообще сделать даже поминутную тарификацию очень сложно и это проблема не одного гугла. Просто попробуйте спроектировать такую систему. Вот у вас есть база данных, которая может обрабатывать 9млн запросов в минуту, как в статье, для одного клиента. Для всех клиентов она наверно 10^11 запросов в минуту обрабатывает, а то и больше. И нужно каждый запрос посчитать, перевести в доллары и обновить счёт у клиента и чтобы не тормозило… Это колоссальная задача, по ресурсам сравнимая с работой самой базы данных. Поэтому они и делают лаг, обновляют биллинг только раз в какой-то интервал, например в сутки. А пользователям рекомендуют следить за метриками и ставить лимиты по метрикам, т.к. метрика не требует особой обработки, это просто число запросов, его можно быстро выкинуть в АПИ и обновлять, а уж юзер сам решит как реагировать на взлёт метрик — например установит лимит.
Опять же в большой компании наверняка есть специальный отдел биллинга, то есть сервис базы данных сам ничего не переводит в деньги, он только отправляет метрики использования в систему биллинга, она там уже внутри в соответствии с тарифами пересчитывает в деньги, выставляет счета, списывает с карт. Это всё занимает время.
Так что на любой облачной платформе легко можно уйти в минус, если моментально создать нагрузку в 1000+ раз больше, чем ваша средняя нагрузка за день, вы просто сгенерируете себе счёт как за 1000 дней типичного использования.


Что странно конечно, это автоматический апгрейд уровня обслуживания. Если у них был бесплатный тарифный план, их должны были затротлить и всё. Вот в этом реальный косяк гугла, наверно поэтому они и не стали требовать оплату, поняли, что в суде проиграют

Дак вот и беда, что нет там бесплатных тарифных планов. Я веб разработчик, делаю например сайт, и подключил на сайт гугл карту. Для разработки я для себя создал API ключ для доступа к гугл картам, на и делаю сайт потихоньку. Ранее в бесплатном тарифе у меня было какое-то количество запросов в API, для разработки мне их хватало, и всё нормально. А теперь гугл сказал что бесплатных тарифов нет, но дает бесплатных 200 баксов, и требует привязать карту к аккаунту. И теперь если на мой тестовый сайт случайно привалит толпа ботов, нагенерит кучу запросов к гугл картам, я попаду на деньги. Конечно я пытался настроил лимиты, но там даже лимиты настраиваются не в количестве запросов в АПИ, а в юнитах, на каждый юнит дается xx запросов к статическим картам или yy запросов к динамическим или zz других запросов. И где-то ошибиться в этих всех юнитах элементарно. А хочется банальную вещь — отрубить всё при превышении лимита по деньгам.

Я завёл виртуальную карту для сервисов, которые требуют привязки карты, и положил на неё минимально необходимую сумму денег

Это не спасет от истории как в статье — счет выставят все равно, и будут требовать оплату. Ну или заводить новый аккаунт потом.
Гугл мапс не принимает «предоплаченные карты».
Так он назвал мою виртуальную карту тогда еще яндекс денег.
… теперь понятно почему!
Просто попробуйте спроектировать такую систему.…
Это колоссальная задача, по ресурсам сравнимая с работой самой базы данных

Так сложилось, что буквально не так давно я проектировал подобную систему, но конечно меньших масштабов. Там все получается достаточно сложно, но не на столько, чтобы прям по ресурсам было как у самой базы данных, даже если она позволяет десятки миллиардов операций.
Ключ к скорости — аггрегации на уровне ближе к сервису и, очевидно, параллельность. У каждого сервиса есть 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 тысяч контейнеров, что более чем ок.
Другое дело, что гуглу дешевле вот так «прощать» оверчарджи, чем содержать систему, которая более-менее быстро будет считать расходы при их текущей архитектуре с тысячами SKU и дать возможность алерты выставлять.
Раз в сутки этот объем информации еще можно посчитать за более-менее внятные деньги, а вот 50 раз — уже дорого.
Это кстати некоторым образом объясняет, почему некоторые провайдеры вроде DO стараются вводить как можно меньше billing metrics и упрощать тарифы — просто потому, что считать развесистую систему метрик на каждый чих очень дорого.
Гугл мало что потерял, себестоимость их сервисов для гугла — 10х..100х крат меньше.
А вот и нет — конкуренция на рынке облаков такова, что там нет никаких 10-100 крат наценки. Иначе AWS или Azure его бы выщемили ценами.
И какие же конкуренты у амазона и гугл с таким списком услуг? майкрософт? и все? Облачные услуги именно тем и хороши, что у них отличные от классической ценовой политики 'взять в аренду машину' — оплата за действия, где много возможностей по увеличению доходов на пустом месте.

Окей, забыли про маркетинг и ценовые ловушки.

Тупой пример — вы способны поднять распределенный кластер для хранения данных в оперативной памяти повышенной отказоустойчивости (это пальцем в небо, на основе косвенных уликах)? а гугл с его ресурсами способен, а это значит вместо прямой записи на диск они могут 'включить' кеш writeback или напрямую размещать файлы баз данных в оперативной памяти.

Дальше, маленькая компания не способна разработать/переделать проект, оптимально работающий в архитектуре, где не нужно заботиться именно о ненадежности хранилища, а вот крупные типа гугл вполне способны, мало того можно сначала разрабатывать опенсорс с классическим подходом, отлаживая идею а для внутреннего использования пилить оптимальный, используя наработки из опенсорс — весь мир будет использовать не оптимальный и мерить свои расходы соответственно.

Это реально, отличный пример смены парадигмы — rest с запуском приложения на каждый запрос -> на все работает внутри единого приложения, даже простейшие тесты перехода с http rest на websocket дают повышение скорости на порядок, а если еще и базу данных убрать, оставляя данные в оперативной памяти без смены форматов и сериализации…

Еще, на рынке уже есть мастодонты, конкурировать с ними никто адекватный не будет, силенок не хватит, максимум попытаться занять маленькую нишу (и даже в этом случае тебя мастодонты купят). Вы как клиент не будете рисковать с множеством никому неизвестных компаний, которые решают только по 1% ваших задач, вместо этого вы пойдете туда где ваши задачи решаются все в одном месте.
UFO landed and left these words here

Я не спорю что можно сделать. Но вы сами согласны, что объем большой. А ещё нужно учесть, что раз в 30 минут не уберёт проблему описанную в статье. Если запустить большую параллельную задачу на pay as you go тарифе без ограничений по ресурсам даже за полчаса легко на много тысяч улететь. Я слышал, что Microsoft поставила цель сделать поминутный биллинг во всём azure, не уверен по срокам, но движение в эту сторону есть и уже есть некоторые сервисы, которые это умеют.
Также у пользователей существует фундаментальное не понимание как работает биллинг, в статье это упоминается "у меня на карте было всего 100$". В контексте, что "как же я мог потратить больше". А вот легко мог, потому что биллить карту даже раз в полчаса это мало реально, поэтому даже в деньгах лимит нужно явно устанавливать руками в сервисе. Иначе к тому времени когда система решить списать с карты, уже будет большой счёт

Недавно был блогпост — там писали, что на Prime Day магазин Амазона, куда все ломились как ненормальные, делал «всего» 80М запросов в секунду на DynamoDB. Вы же предлагаете обрабатывать на пару порядков больше запросов, чтобы посчитать деньги чуть быстрее? Что это даст пользователям? Кто оплатить банкет? Нищие стартаперы?
Осталось сделать еще один маленький шажок: считать стоимость не раз в час, а раз в сутки и вуаля, мы пришли к точно такому же решению, как и гугл.
В Амазоне — да, тарификация может быть почти в реальном времени, и при достижении бюджета можно послать команды на остановку сервисов — но все равно эта остановка может занять несколько минут на большой инфраструктуре, и за эти несколько минут может произойти все, что угодно.

Поэтому лимит по бюджету вообще в принципе невозможен, так как невозможно при достижении бюджета мгновенно отрубить сервисы и прекратить списание денег.

Значит надо рубить по достижению 80% бюджета, например

Можно тогда просто самому задать «бюджет» на 80%
А кто вам мешает? Поставьте billing alert и останавливайте.
Ну можно перестать считать биллинг после поступления команды на остановку и тогда не важно сколько по времени она займет, она уже не будет тарифицироваться.
Тогда появилась бы легальная возможность напользоваться услугами на $72k бесплатно :)

« Вообще сделать даже поминутную тарификацию очень сложно и это проблема не одного гугла. Просто попробуйте спроектировать такую систему.»


Ну никто и не спорит что это очень не просто. Но мы же с вами сейчас говорим о Гугле а не МакДональдсе (отсылка к фильму с Кевином Спейси « Двадцать одно» 2008г).

Посекундная тарификация (а реально она уже миллисекундная на лямдах) не означает, что сервис отключится по достижении лимитов. Как уже сказали — это было бы крайне опасно для больших корпораций. На всех сервисах AWS есть soft-limits, которые можно поднять обратившись в поддержку. Они как раз и призваны ограничить темпы сжигания денег при факапах.
Ну разумеется, переворачивающие мир божественные индийские стартаперы. Это должно быть в энциклопедиях, как хрестоматийный пример к статье «Даннинга-Крюгера, эффект», часть «Типичные проявления и их последствия».

Имхо это дырка. Любой получается, не имея средств может попользоваться мощной инфраструктурой Гугля. Имхо, должна быть какая то граница, с которой оплата должна осуществляться не кредитной картой, а переводами и заранее обговариваться.


В нулевых было одно время подобное. На сайт заходишь проверить свой IQ, а там мелким текстом, что пройдя тест ты тем самым осуществляешь подписку 80 евров в месяц. Мало того что тем самым завалил тест на IQ :) так ещё и счёт через пол года приходит и в придачу письмо от адвоката, мол не заплатите, айда в суд. И некоторые платили. Потом прикрыли эту лавочку.


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

Да, сценарий для DOS, зарегают несколько аккаунтов с краденными карточками и запустят по несколько миллиардов запросов. Рано или поздно, облако Гугла кончится.

Хрен с ним, с Гуглом. Зато появляется возможность получить дорогущие вычисления на халяву.

Уже было на хабре, да
Вкратце — у чувака взломали почту, угнали облако (гугл или амазон?) и запустили там крипто-майнер.

Ок, я проигнорировал, что задеплоить SQL базу данных слишком затратно, хотя мускл какой-нибудь поднимается за полчаса. Я проигнорировал, что для создания тестовой даты людям потребовался высокопроизводительный AI, я не обратил внимания на то что команде потребовалась ночь, чтобы понять за что пришёл счёт. Пропустил мимо ушей тот факт, что они вообще не разбираются в том что делают, судя по описанию процесса, что в stackoverflow нагуглили то и запустили...


Но я не выдержал когда узнал что чел работал в гугле… Да как же так-то… Судя по тому какие вопросы задают подобные компании на собеседованиях там одни гении работают.
Я с пятилетним опытом работы с linux даже на четверть не могу ответить… Как в linux initrd работает, как docker изолирует и разделяет ресурсы ядра, как управляет памятью и её переполнением… Человек знающий детальные ответы на вопросы такого уровня просто что-то там поднимает о чем в интернете прочитал?


Такое впечатление, как-будто в IT начали как в шоубизнес набирать… С каким ПМ мне надо переспать для этой работы? Или пойти сделать операцию по смене расы на индуса что ли...


Извините, после 35 собеседований за последние два месяца наболело

Вы же не знаете, кем он там работал...

в IT начали как в шоубизнес набирать

Это уже давно так. Я вот уже второй месяц бодаюсь с ТП Microsoft по достаточно простой теме, счет людей, с которыми я говорил, приближается к 10, и никто, Карл, не знает, как решить мою проблему. По ней есть три набора документации, все три говорят разные вещи, не работает реально ни один. И всем нас… ть, что характерно, потому что никому из тех ~10 саппортистов лично не прилетит по башке, если оно не заработает. Если это не шоубизнес, тогда что?

"Или пойти сделать операцию по смене расы на индуса что ли..."


Кроме расы, нужно ещё правильных родственников получить. Индийское кумовство же.

Сменить касту будет вполне достаточно.

Проблема в том из какого региона нанимают. Если вы живёте в России и хотите попасть в гугл, вас должны взять на довольно высокую позицию, чтобы имело смысл оплачивать переезд, визу и так далее. Поэтому отбор очень суровый.
Если вы уже живёте в США, есть рабочая виза или гражданство и вы ещё и студент последнего курса, то попасть на стажировку на начальную позицию не составляет особых проблем. Потребность в кадрах на порядок выше предложения, поэтому берут всех подряд

Человек знающий детальные ответы на вопросы такого уровня просто что-то там поднимает о чем в интернете прочитал?

Натыкался с год назад на статью человека, прошедшего в гугл где-то в америке, так вот он там описывал как проходило собеседование и как он с нуля(работал строителем что ли) к нему пол года готовился на курсах… по подготовке к собеседованиям в FAANG. То есть человек пол года учил то, что в этом году спрашивают на собеседованиях, профессиональный проходитель собеседований.
Был такой фильм, «Кадры», как раз про гугл.
Развод. Что я буду спрашивать сегодня на собеседовании знаю только я. И в следующий раз может быть другой вопрос — потому что с предыдущим кандидаты плохо справлялись. Или этот кандидат пишет на плюсах, а не на Java. Внутренняя подготовка собеседователей проходит один раз, и не предполагает указаний что в этом году модно спрашивать по технической части.
Ох, боже, я не одинок!
Каждый раз, читая очередной фейл, думаешь да как так то?!
Наверняка, автор зато мастерски раскладывает красно-чёрные деревья, разворачивает листы, разделяет ценности и всё это за bigO(1) и вообще без памяти.
Осталось только софт научиться писать и системы проектировать, ну это мелочи.
Возникает вопрос, чем он занимался в Гугле, что вообще не представляет как работает их собственное облако?
Другим облаком. Или кусочек фронтенда на гугловской библиотеке писал. В таких условиях сложно понять что-то кроме гугловской библиотеки.
Да ничего он не писал, дело вроде было в отсутствии контроля кол-ва/дублей URL ссылок перед тем как их (рекурсивно небось, да по модному в новый инстанс каждуюю) на обход в очередь поставить. А «виновата» у автора — плохая «архитектура»? Это странное слово которое говорят программисты из далекого подвала, полюбому она

В Канаде есть закон, который ограничивает максимальную накрутку в 100 долларов в месяц за любые цифровые услуги, за всё, мобильный, интернет и прочее. Если гугл накрутил вам 72К, то он сам себе Буратино, имеет право только на тарифный план + $100. Это конечно в случае если вы сами не попросили снять данные лимиты.


Не уверен, но по-моему в штатах тоже такое есть.

В штатах, насколько мне известно, с защитой прав потребителей всё очень плохо. Это у нас всё по предоплате, кроме, разве что, коммунальных услуг, а у них — нет. В итоге получаются такие замечательные истории, что подписаться на что-нибудь (кабельное ТВ, новостные сайты, абонемент в спортзал, доставку готовой еды, спутниковое радио в машину) можно неосторожным движением курсора на сайте, а вот отписаться… У них будут данные твоей карты, и они будут снимать с тебя деньги. Заблокируешь карту — отдадут тебя на растерзание коллекторам. Единственный способ отписаться без негативных последствий для себя и своего кредитного рейтинга — расчитывать на их милость, которой у них, конечно же, не будет. В лучшем случае в интерфейсе будет много тёмных паттернов и попыток надавить на жалость. В худшем интерфейса не будет вообще — заставят звонить в колл-центр и час припираться с индусом, пытающимся удержать клиента, потому что если удержит слишком мало, его уволят.

(источник: иногда слишком много сижу на реддите)
Поэтому в спортзал лучше с наличными.
Это же в друзьях уже обыгрывалось

с защитой, как таковой, тут (в штатах), проблем нет. но, если ты подписался в спортзал на год (и получил скидку), то да, придется платить… можно не ходить, а платить — придется. то же самое, и с любыми сервисами, что вы описали.
Басни. В США чарджбэк в таких случаях будет запущен по одному звонку в банк.
На том же реддите писали, что в этом случае могут отдать коллекторам, как и если карту перевыпустить. Не знаю, насколько правда.
Не могут, оснований нет. Подписка «неосторожным движением курсора на сайте», как и любой подобный скам, отменяется моментально. Потому там и распространены покупки в интернете (и пицца по телефону домой, классика) просто по номеру карты без всяких cvv. Это защита платежной системы, отмена фрода — в таксе.
Эти практики давно уже в России. Была у меня неосторожность подписаться на один популярный сервис, очевидно с инвесторами и менеджментом оттуда. Так чтобы отписаться мне пришлось писать заявление на бумаге и отправлять его на специальный адрес ( хотя-бы электронный ).
Вы про этот? crtc.gc.ca/eng/phone/mobile/codesimpl.htm

«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.»

К облачным сервисам это никак не относится, кмк.

А без целого букета новомодных SaaS-ов стартап это не стартап? VPS за три доллара, и взламывайтк хоть Пентагон полным перебором, цена останется та же. Не можете написать нормальный софт или поднять его на своей виртуалке, ну тогда вообще не понятен какого фига вы лезите в разработку.

Ну есть определенные так сказать нюансы. Например реклама. Обычно это как выглядит, звпустили.вы на.виртуалке стартап, на нем три юзера. Потом подключаются гениальные маркетологи и закупают рекламу или размещают пост на хабре. У вас сразу лавинообразный наплыв юзеров. Сервис лег. Как с этим быть? Можно конечно лендинг разместить статикой отдельной от продукта. Но мало кто это делает

В стартапе и сразу гениальные маркетологи? Реклама без консультаций с IT на mvp-серваки? Это должны быть такие же долбоящеры, как и разрабы из статьи. В плане рекламной кампании всегда есть цели и объём трафика, который кампания должна привлечь и если маркетологи не проконсультируются с IT, то в случае проблем будут оплачивать простой из собственного кармана.

У VPS тоже есть лимиты по трафику, и как с google cloud надо внимательно изучать что произойдет при достижении этих лимитов.

Я не спец по VPS, но кмк у тех, что дороже $3 уже нет лимитов
У большинства VPS условный безлимит, который стартап никогда не высосет. Но если даже что-то такое произойдет, то вам просто выключат сервер или снизят пропускную способность канала, а не выставят счет на 70 тысяч.
UFO landed and left these words here
Стартапу такой лимит вряд ли получится высосать. Но даже если и получится, к огромным расходам это не приведет.
UFO landed and left these words here
У меня сервера в OVH (в SoYouStart точнее). Это dedicated, но VPS у них тоже есть. Они заявляют безлимитный трафик. По факту я расходую в районе 15 TB в месяц, никаких проблем не возникало. Сколько надо потратить чтобы возникли проблемы?
UFO landed and left these words here

Ну да лимиты по трафику есть, однако если мы говорим не про aws/azure они достаточно большие, чтобы у покупателей не было шанса его истратить полностью (чаще всего). Само собой, если мы там поднимаен виделхостинг нам этих лимитов не хватит просто потому что на такое дешёвые тарифы на рассчитаны, если нужно много трафика то тут уже придется платить совершенно другие деньги, возможно совершенно другом людям

У меня создалось впечатление, что часть нынешних исполнителей даже не знает, как все развернуть на VPS или локальном тестовом сервере.
оффтопик
Пока смотрел на картинку «Фух, пронесло», заметил, что в отражении на капоте присутствует «стоп-столб». И не факт, что в отражении именно Калкин.
ну так не модно же /s
А если серьезно, мне тоже не понятны такие заморочки, свой VPS всяко лучше будет, особенно когда проект на стадии прототипа и до продакшена еще как до Китая раком. И да, судя по описаным в статье ошибкам (сугубо мое мнение на основе прочитанного, ни на кого не гоню, и могу ошибаться) они и VPS без выстрела в колено поднять бы не смогли. Хотя с другой стороны, если команда из вчерашних студентов, толком порох не нюхавшех, то в принципе неплохой опыт, в следующий раз будут хотя бы мануалы внимательно читать
Не можете написать нормальный софт или поднять его на своей виртуалке, ну тогда вообще не понятен какого фига вы лезите в разработку.

Согласен, но с другой стороны…
Вы же тоже «лезите» в русский язык. ;)
Ну вы что, там линукс кокойта, разбираться надо, а мы стартаперы, дених хотим, мы инноваторы, а не задроты.

Было нечто похожее пару лет назад с Селектелом.


Запустилась по крону задача бэкапа одного раздела в облачное хранилища. В норме там совсем немного файлов и задача отрабатывает за минуту.


Но в этот раз что-то пошло не так.


Утречком выяснилось, что "все тормозит". Почему тормозит? Да потому что задача бэкапа работает. А что он делает? Ну, смотрю в логи и ничего не понимаю — вроде работает, вроде всё в порядке, но… что-то тут не то… Тормоза закончились через несколько часов, а я так и не понял, "что это было".


Когда обломался следующий бэкап, я полез в консоль селектела и обнаружил, что должен им что-то около 10к рублей.


О.о


И что это было?


А вот что:


Незадолго до этого я игрался с Vagga (система виртуализации, аналог докера) на этом разделе и Vagga мне создала в одном из своих служебных каталогов несколько миллионов файлов. И всё это поехало бэкапиться (в 5 часов утра, как полагается, когда я сладко спал).


PUT файла стоил совсем чуть-чуть (1.4 копейки, что ли, не помню), но их были миллионы.


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


… но почему-то доступ не отрубился. И файлы заливались, и заливались, и заливались в облако.


А счет все уменьшался, уменьшался, уменьшался...


Что произошло раньше — бэкап закончился или биллинг селектела опомнился, что деньги в минусе — я не выяснил.


В общем, после долгих, очень долгих дискуссий эту проблему признали сначала багом, деньги простили (уффф), а потом фичей. И сказали, что да, теперь это фича, теперь это нормально, теперь счета могут улетать в минус.


Странное решение, как по мне, но я не работаю в селектеле. Возможно, пока не работаю.


P.S. Потом там в рамках этой задачи что-то чинили, меняли, снова чинили, снова меняли, но счета по прежнему могут уходить в минус.

Пофайловые бэкапы в облако, ммм… Амазон, к слову, на грозном красном фоне в вебморде предупреждает, что перемещение туда большого числа маленьких файлов — не самая лучшая идея. Хотя это, кмк, понятно и без Амазона, в принципе — хотя бы элементарно за-tar`ить бэкап стоит.
Скучаю по тем временам, когда за услуги надо платить вперед, предварительно закинув денег в «кошелек» сервиса (Откуда уже и идут списания).
Все больше сталкиваюсь с мыслью, что в Google Cloud самое сложное это не знать как работают различные сервисы масштабирования, а уметь не влететь в долг.

Да это справедливо со всеми облаками, нужно понимание того, что делаешь и умение расчитать цену полученного решения до запуска, а не по полученному счёту.

UFO landed and left these words here
привязал бы дебетовую карту, проблем бы не было.
то наберут своих кридитных…
Вряд ли у него был лимит в $72к. Дело не в карте, дело в счете: если согласился на услугу, будь добр оплатить счет. Не можешь с карты — так идем в суд.

Это не важно, для дебетной будет овердрафт, что еще дороже для платильщика

для этого есть карты без овердрафа

Я боюсь что Google Cloud не даст вам добавить такую карту в биллинг

На сколько мне известно, любую дебетовую карту можно загнать в технический овердрафт. Даже если официально его нет. Идет все это из-за особенностей обработки платежей.
технический овердрафт потом гораздо проще ИМХО разруливать с техподдержкой

Стал в принципе крайне негативно относится к всякого рода автоматическим подпискам. А уж хрень по типу "оказал услугу, а потом проверил баланс клиента" и "автоматически списал деньги после окончания бесплатного периода" должна быть запрещена и отключена по-умолчанию, а разрешатся только с двойного подтверждения клиента.

Водоснабжение и отопление в квартире уже отключили? :)
Думаю, я всё таки смог бы преодолеть свою лень и оформить двойное подтверждение на две эти услуги. :)

А больше я вообще никакими подписками не пользуюсь. Есть ещё, конечно, плата за интернет на мобильнике и компьютере, но: а) там отдельный счёт; б) при нехватке средств просто прекращается оказание услуги до пополнения счёта.
Там или фиксированная плата, или счетчик работающий в режиме реального времени. И деньги списываются не автоматически.

Все метрики использования ресурсов тоже идут в реальном времени (см. в статье совет «используйте мониторинг»).


А биллинг не реалтаймовый — за воду раз в месяц, за клауд — раз в сутки.


Если вы шланг от водопровода кинете в окно, и за день сольёте годовой объём воды, вам счёт так просто не простят, как гугл, а возможно и спишут «автоматически» через судебных приставов.

На счетчике видно сколько использовано воды. Как я понял из статьи в GCP это не очень очевидно.
Я не использовал GCP, но в Amazon AWS все достаточно очевидно — дэшборд с графиками по всем возможным ресурсам. Думаю, в GCP так же.

Но конечно, нужно осознавать, что такая проблема может возникнуть, чтобы вообще смотреть в этот мониторинг и настроить в нем какие-то алерты.
А, кстати, реальный случай произошёл со мной 1.5 года назад.
Я жил в другом городе. Жена собралась ко мне приехать. За день перед вылетом обошла дом (просто на всякий случай). Обнаружила нехилую такую утечку воды из водогрейного бака. Бак находился в самом дальнем конце, то есть, нужно было обойти три стороны дома, и мы там не появляемся почти никогда.

Позвонила мне. Я так прикинул, что у нас обычно течёт литров до 9 в минуту, а цена тонны воды $3.5. Если оно продолжается хотя бы неделю, то…

Короче, повезло ОЧЕНЬ. Судя по счёту, протечка началась за несколько дней до осмотра. Признаться, я с большим удовольствием оплатил счёт в несколько лишних сотен. Ну и с не меньшим удовольствием купил новый нормальный проточный нагреватель на газу, гораздо более экономичный, чем это электрическое накопительное убожество.

НО: в моём случае, всё же, я имею возможность и счётчик наблюдать в любой момент времени без задержки, и визуально протечку обнаружить, и кран перекрыть. СМ другой стороны, автоматизировать мониторинг малой кровью не получится. Это «сделай сам» надо какой-то.
У меня они к примеру безлимитные ))
Тогда вы можете построить небольшую ГЭС и майнить крипту на бесплатном электричестве :)
Неплохо-бы для компаний, предоставляющих услуги, дать возможность поставить лимиты и «жесткие лимиты». И если в первом случае получать сообщения при превышении счета, то во втором услуга отключается принудительно, если для клиента важнее сохранить деньги, чем бесперебойность сервиса.

Как-то не по себе сейчас стало за тестовый GCP аккаунт, который я был вынужден создать, чтобы протестить работу Speech To Text API от гугла.


  • Во-первых, какого-то хрена всё, что можно было урлой с апи-ключом потестировать 10 лет назад, теперь требует аккаунта в облаке-%companyname% с подключением кредитки, созданием каких-то сервисов. То есть компании (конкретно, GCP и Azure у меня так появились) нарочно навязывают свои облачные аккаунты там, где они нафиг не нужны.
  • На экране ввода кредитки там огромным шрифтом написано "МЫ НЕ БУДЕМ СНИМАТЬ С ВАС ДЕНЬГИ ПОКА ВЫ САМИ ВРУЧНУЮ НЕ ПРОАПГРЕЙДИТЕ ТАРИФ". А тут вот, оказывается, что-то что-то Firebase и хобана, автоматические попытки списания. Гугл ведёт себя как обычные жулики.
  • Что если аккаунт банально взломают? Я понимаю, надо не допускать такого, но тут получается я уже рискую даже не своими деньгами, а каким-то гигантским кредитным плечом от гугла, которое никто не просил.
Те, кто за два дня до демы велосипедят костыль, в пятницу вечером без тестирования ставят его сразу на прод и идут спать, должны страдать.

Супер прохладная история. Доки гугла отличные? Так почему вам потребовалась ночь чтобы разобраться в них? Или почему вы изначально не поняли, что и как работает. Да потому что нет у гугла никаких замечательных доков, сплошной маркетинговый булшит в скудной админке, где они оперируют в большинстве своем какими-то собственными понятиями, документации по которым просто нет. Ну и вот это желание постоянно пользоваться мифическими рубильниками, не разбираясь в них — это вот просто верх безответственности в IT. Да лучшеб вы сами все написали, чем пропагандировать такой идусский подход к разработке..

По идее гугл бы эти деньги все равно не получил, т.к. стартап бы просто объявил о банкротстве и все… А так еще им и спасибо сказали за в общем-то их собственный фейл…

Я с подругой как-то решили накатить прототип виртуальной платёжной системы, однако из-за кривой настройки SQL-сервера "намотались" на >400$ долга (ушли в летний отпуск и за биллингом никто не присматривал, но часть всё же простили) и платёжный аккаунт оказался заблокирован после нескольких неудачных попыток снять что-либо с карты, а потом и саму карту в сервисах Гугл заблокировали из-за подозрении в "мошенничестве".


Всё бы ничего, но с той же карты оплачивался App Engine для других проектов, а также продлялись домены в Google Domains — всё это пошло коту под хвост. Не ложите все яйца в одну корзину, даже если таким образом дешевле.

Рад что всё закончилось хорошо, но блин иначе и быть не могло т.к. если бы GOOGLE не простил этот счёт то автор пошёл бы в суд и без проблем выиграл дело может быть ещё и моральную компенсацию мог получить)
UFO landed and left these words here

багованый недософт с красивой +- оболочкой запустили где-то на облаках. если б оно работало на вашем серваке, и все начало тупить, ибо ссд/нагружен на 99+%. то на этом история текущей альфа-бета версии благополучно закончилась.

UFO landed and left these words here
ZIP-бомбу тоже можно открывать в облаках Гугла?

Именно по-этому у меня сильная предвзятость к post-paid сервисам с "сложным биллингом". Если бы там был честный prepaid, их бы рубанули через 5 минут и они спокойно разбирались бы куда 7 баксов делось. Ну, или 100. Но не 60+ бесконечностей.

От этой статьи возникает 3 мысли:
1) Сервисам нужно ограничивать объем ресурсов. А то можно завести аккаунт на бомжа с которого нечего взять, и выполнить расчёты хэшей криптовалюты. А если у этого бомжа 100 аккаунтов и 100 карточек, то можно обеспечить ему жилье в рамках благотворительной программы от Google, о которой сама компания не знает.
2) Надо быть внимательнее при работе с ткаими ресурсами.
3) Такая опасность делает сервисы менее полезными для разработчика. Одно дело, когда неправильная программа вдруг зависнет или посчитает не то — ну и ладно, поправлю. А при таких рисках надо всё более внимательно отслеживать заранее, то есть падает скорость разработки.
4) По-хорошему за найденную возможность использовать ресурсов больше, чем лимит на 4 порядка надо не счета выставлять, а давать премию по Bug Bounty, пока такие вещи делаются случайно, а не преднамеренно.
>>У POST-запросов могут быть одни и те же URL. Если есть обратная ссылка на предыдущую страницу, то сервис Cloud Run застрянет в бесконечной рекурсии
Ну всё логично, индус написал индусский код.

>>9 000 000 запросов в минуту
Хороший ddos.

И сколько стоит проскрапить весь интернет? Самое интересное не написали.

У амазона «micro», раньше, не знаю как сейчас, через год переводится автоматом на платный тариф, и прилетает уже счёт сразу.

И довольно долго время не отключается

Был у меня провайдер кабинет — работал через раз, но начислял исправно.
Сменил его на билайна, написал во все места кабинету, что отключаюсь от них и прошу расторгнуть договор, но идти в офис расторгать договор мне было в лом.
Кабинет еще два месяца начислял мне плату, потом таки отключил услугу(хотя по факту провод висел в воздухе). Писал и звонил мне полгода — на что я отвечал что услуга не оказывалась. В итоге перестали мне о себе напоминать.
Потом был МТС с интересным подарком в -500 рублей, Акадо и Ростелеком с точной копией истории кабинета и все сами рассосались, так как начисляли я считаю несправедливо и пойди они в суд с иском за не оказанную услугу скорее всего песперспективно.

Рассказываю, как я сжёг на $500 на GCP. При заказе VM можно выбрать тип диска. Если выбрать extreme iops, то включается режим бешенного принтера, причём какой именно нигде не видно.

При этом, если зайти в диски (не в создание VM) и попытаться создать там extreme iops, то там будет видно, что размер диска минимум 500Гб и 100000 pre-provisioned IOPS. В интерфейсе заказа VM такого нет, оно рядом между standard и balanced iops.

Only those users with full accounts are able to leave comments. Log in, please.