История о том, как мы оказались на грани банкротства, не успев даже запустить первый продукт, как нам удалось выжить и какие уроки мы извлекли.
В марте 2020 года, когда COVID поразил весь мир, наш стартап Milkie Way тоже сильно пострадал и почти закрылся. Мы сожгли 72 000 долларов во время изучения и внутреннего тестирования Cloud Run с Firebase в течение нескольких часов.
Я начал разработку сервиса Announce в ноябре 2019 года. Главная цель состояла в выпуске минимально функциональной первой версии продукта, поэтому код работал на простом стеке. Мы использовали JS, Python и развернули наш продукт на Google App Engine.
С очень маленькой командой мы сосредоточились на написании кода, разработке пользовательского интерфейса и подготовке продукта. Я практически не тратил времени на управление облаком — потратил ровно столько, чтобы поднять систему и обеспечить базовый процесс разработки (CI/CD).
Десктопный Announce
Первая версия была не очень удобной, но мы просто хотели выпустить версию для экспериментов, а потом уже работать над нормальной. В связи с COVID мы подумали, что сейчас хорошее время для запуска, поскольку государственные службы по всему миру могут использовать Announce для публикации оповещений.
Разве не здорово сгенерировать на платформе немного данных, когда пользователи ещё не закачали свою информацию? Эта мысль привела к появлению другого проекта Announce-AI для генерации контента. Богатые данные — это различные события, такие как оповещения о землетрясениях и, возможно, релевантные местные новости.
Некоторые технические детали
Для начала разработки Announce-AI мы использовали Cloud Functions. Поскольку наш бот для скрапинга был ещё на начальной стадии, мы решили взять эти легковесные функции. Но при масштабировании возникли проблемы, потому что у облачных функций тайм-аут около 9 минут.
И вдруг мы узнали о системе Cloud Run, у которой тогда был большой лимит бесплатного использования! Не разобравшись полностью, я попросил команду развернуть «тестовую» функцию Announce-AI в Cloud Run и оценить её производительность. Цель состояла в том, чтобы поиграться с Cloud Run для накопления опыта.
Google Cloud Run
Поскольку у нас очень маленький сайт, то для простоты мы использовали БД Firebase, так как у Cloud Run нет никакого хранилища, а деплой SQL Server или другую БД слишком чрезмерен для теста.
Я создал новый проект GCP ANC-AI Dev, настроил бюджет облачного биллинга на 7 долларов, сохранил проект Firebase по бесплатному плану (Spark). Худший вариант, который мы представляли, — это превышение ежедневного лимита Firebase.
После некоторых модификаций мы подготовили код, сделали несколько запросов вручную, а затем оставили его работать.
Кошмар начинается
В день тестирования всё прошло нормально, и мы вернулись к разработке Announce. На следующий день после работы ближе к вечеру я пошёл слегка вздремнуть. Проснувшись, я увидел несколько писем из Google Cloud, все с интервалом в несколько минут.
Первое письмо: автоматический апгрейд нашего проекта Firebase
Второе письмо: бюджет превышен
К счастью, на моей карте был установлен лимит в $100. Из-за этого платежи не прошли, а Google приостановил обслуживание наших аккаунтов.
Третье письмо: карта отклонена
Я вскочил с кровати, вошёл в биллинг Google Cloud и увидел счёт примерно на $5000. В панике начал щёлкать по клавишам, не понимая, что происходит. В фоновом режиме начал размышлять, как такое могло произойти и как оплатить счёт на $5000, в случае чего.
Проблема была в том, что с каждой минутой счёт продолжал расти.
Через пять минут он показывал $15 000 долларов, через 20 минут — $25 000. Я не понимал, когда цифры перестанут увеличиваться. Может, они будут расти до бесконечности?
Через два часа цифра остановилась на отметке чуть меньше $72 000.
К этому времени мы с командой были на телеконференции, я был в полном шоке и не имел абсолютно никакого понятия, что делать дальше. Мы отключили биллинг, закрыли все сервисы.
Поскольку во всех проектах GCP мы рассчитывались одной картой, все наши учётные записи и проекты были приостановлены.
Кошмар продолжается
Это произошло в пятницу вечером, 27 марта — за три дня до того, как мы планировали запустить первую версию. Теперь разработка остановилась, потому что Google приостановила все наши проекты, привязанные к одной карте. Мой боевой дух ниже плинтуса, а будущее компании казалось неопределённым.
Все наши облачные проекты приостановлены, разработка остановлена
Как только разум смирился с новой реальностью, в полночь я решил нормально разобраться, что же произошло. Я начал составлять документ с подробным расследованием инцидента… и назвал его «Глава 11» [это глава из закона о банкротстве — прим. пер.].
Двое коллег, участвовавших в эксперименте, тоже не спали всю ночь, исследуя и пытаясь понять, что произошло.
На следующее утро, в субботу 28 марта, я позвонил и написал письма десятку юридических фирм, чтобы записаться на приём или поговорить с адвокатом. Все они были в отъезде, но я смог получить ответ от одного из них по электронной почте. Поскольку детали инцидента настолько сложны даже для инженеров, объяснить это адвокату на простом английском языке было само по себе непросто.
Для нас как начинающего стартапа не было никакой возможности возместить $72 000.
К этому времени я уже хорошо изучил 7-ю и 11-ю главы закона о банкротстве и мысленно готовился к тому, что может произойти дальше.
Некоторая передышка: лазейки GCP
В субботу после рассылки электронных писем юристам я начал дальше читать и просматривать каждую страницу документации GCP. Мы действительно совершали ошибки, но не было никакого смысла в том, что Google позволил нам резко потратить $72 000, если раньше мы вообще не делали никаких платежей!
GCP и Firebase
1. Автоматический апгрейд аккаунта Firebase на платный аккаунт
Мы такого не ожидали, и об этом нигде не предупреждалось при регистрации на Firebase. Наш биллинг GCP был подключён к исполнению Cloud Run, но Firebase шла под бесплатным планом (Spark). GCP просто ни с того ни с сего провела апгрейд на платный тариф и взяла с нас необходимую сумму.
Оказывается, этот процесс у них называется «глубокая интеграция Firebase и GCP».
2. Биллинговых «лимитов» не существует. Бюджеты запаздывают минимум на сутки
Выставление счетов GCP фактически задерживается как минимум на сутки. В большинстве документов Google предлагает использовать бюджеты и функцию автоматического отключения облака. Но к тому времени, когда сработает функция отключения или пользователю пришлют уведомление, ущерб уже будет нанесён.
Синхронизация биллинга занимает около суток, именно поэтому мы заметили счёт на следующий день.
3. Google должен был взять 100 долларов, а не 72 тысячи!
Поскольку с нашего аккаунта до сих пор не проходило никаких платежей, GCP должен был сначала взять плату в размере 100 долларов в соответствии с платёжной информацией, а при неуплате — прекратить услуги. Но этого не произошло. Я понял причину позже, но это тоже не по вине пользователя!
Первый счёт для нас составил около $5000. Следующий на $72 тыс.
Порог выставления счетов для нашего аккаунта составляет $100
4. Не полагайтесь на панель управления Firebase!
Не только биллинг, но и обновление панели управления Firebase заняло более 24-х часов.
Согласно документации Firebase Console, цифры в панели управления могут «незначительно» отличаться от отчётов биллинга.
В нашем случае они отличались на 86 585 365,85%, или 86 миллионов процентных пунктов. Даже когда пришёл счёт, панель управления Firebase Console ещё показывала 42 000 операций чтения и записи в месяц (ниже дневного лимита).
Новый день, новый вызов
Отработав шесть с половиной лет в Google и написав десятки проектных документов, отчётов с расследованиями событий и много другого, я начал составлять документ для Google, описывая инцидент и добавляя лазейки со стороны Google в отчёт. Команда Google вернётся на работу через два дня.
Поправка: некоторые читатели предположили, что я использовал свои внутренние контакты в Google. На самом деле я ни с кем не общался и выбрал путь, по которому пошёл бы любой нормальный разработчик или компания. Как и любой другой мелкий разработчик, я проводил бесчисленные часы в чате, за консультациями, составлением длинных электронных писем и сообщений об ошибках. В одной из следующих статей, посвящённой составлению отчётов об инцидентах, я покажу документы, которые отправил в Google.
Последний день в Google
Кроме того, нужно было понять наши ошибки и разработать стратегию развития продукта. Не все в команде знали об инциденте, но было совершенно ясно, что у нас большие неприятности.
В Google я сталкивался с человеческими ошибками ценой в миллионы долларов, но культура Google спасает сотрудников (за исключением того, что инженерам приходится потом сочинять длинные отчёты). На этот раз Гугла не было. На карту поставлен наш собственный маленький капитал и наша тяжёлая работа.
Стойкие Гималаи нам говорят…
Такой удар я получил первый раз. Это могло изменить будущее нашей компании и мою жизнь. Этот инцидент преподал мне несколько уроков бизнеса, в том числе самый важный — держать удар.
В то время у меня работала команда из семи инженеров и стажёров, и Google требовалось около десяти дней, чтобы ответить нам по поводу этого инцидента. Тем временем мы должны были возобновить разработку, найти способ обойти приостановку счетов. Несмотря на всё, мы должны были сосредоточиться на функциях и нашем продукте.
Стихотворение «Стойкие Гималаи нам говорят»
Почему-то у меня в голове постоянно крутилось одно стихотворение из детства. Это была моя любимая книга, и я помнил её слово в слово, хотя в последний раз читал более 15 лет назад.
Что мы на самом деле сделали?
Будучи очень маленькой командой, мы хотели как можно дольше воздержаться от расходов на аппаратное обеспечение. Проблема Cloud Functions и Cloud Run заключалась в тайм-ауте.
Один инстанс будет постоянно скрапить URL-адреса со страницы. Но через 9 минут наступит тайм-аут.
Тогда вскользь обсудив проблему, я за пару минут набросал на доске сырой код. Теперь понял, что у того кода была масса архитектурных недостатков, но тогда мы стремились к быстрым циклам исправления ошибок, чтобы стремительно учиться и пробовать новые вещи.
Концепт Announce-AI на Cloud Run
Чтобы преодолеть ограничение тайм-аута, я предложил использовать POST-запросы (с URL в качестве данных) для отправки заданий в инстанс и — запускать параллельно несколько инстансов, а не составлять очередь для одного. Поскольку каждый инстанс в Cloud Run скрапит только одну страницу, тайм-аут никогда не наступит, все страницы будут обрабатываться параллельно (хорошее масштабирование), а процесс высоко оптимизирован, поскольку использование Cloud Run происходит с точностью до миллисекунд.
Скрапер на Cloud Run
Если присмотреться, в процессе не хватает нескольких важных деталей.
- Происходит непрерывная экспоненциальная рекурсия: инстансы не знают, когда остановить работу, потому что оператора break не предусмотрено.
- У POST-запросов могут быть одни и те же URL. Если есть обратная ссылка на предыдущую страницу, то сервис Cloud Run застрянет в бесконечной рекурсии, но хуже всего то, что эта рекурсия умножается экспоненциально (максимальное количество инстансов было установлено на 1000!)
Как вы можете себе представить, это привело к ситуации, в которой 1000 инстансов делают запросы и записи в Firebase DB каждые несколько миллисекунд. Мы увидели, что по операциям чтения Firebase в какой-то момент проходило около 1 миллиарда запросов в минуту!
Сводка транзакций на конец месяца для GCP
116 миллиардов операций чтения и 33 миллиона записей
Экспериментальная версия нашего приложения на Cloud Run сделала 116 миллиардов операций чтения и 33 миллиона записей в Firestore. Ох!
Стоимость операций чтения на Firebase:
$ (0.06 / 100,000) * 116,000,000,000 = $ 69,600
16 000 часов работы Cloud Run
После тестирования из остановки логов мы сделали вывод, что запрос умер, но на самом деле он ушёл в фоновый процесс. Поскольку мы не удалили сервисы (мы первый раз использовали Cloud Run, и тогда действительно не понимали этого), то несколько сервисов продолжали медленно работать.
За 24 часа все эти службы на 1000 инстансах отработали в общей сложности 16 022 часа.
Все наши ошибки
Деплой ошибочного алгоритма в облаке
Уже обсуждалось выше. Мы действительно обнаружили новый способ бессерверного использования POST-запросов, который я не нашёл нигде в интернете, но задеплоили его без уточнения алгоритма.
Деплой Cloud Run с параметрами по умолчанию
При создании службы Cloud Run мы выбрали в ней значения по умолчанию. Максимальное число инстансов 1000, а параллелизм — 80 запросов. Мы не знали, что эти значения на самом деле наихудший сценарий для тестовой программы.
Если бы мы выбрали max-instances=2, затраты были бы в 500 раз меньше.
Если бы установили concurrency=1, то даже не заметили бы счёт.
Использование Firebase без полного понимания
Кое-что понимаешь только на опыте. Firebase — это не язык, который можно выучить, это контейнерная платформа. Её правила определены конкретной компанией Google.
Кроме того, при написании кода на Node.js нужно подумать о фоновых процессах. Если код уходит в фоновые процессы, разработчику нелегко узнать, что служба работает. Как мы позже узнали, это ещё и стало причиной большинства таймаутов наших Cloud Functions.
Быстрые ошибки и быстрые исправления — плохая идея в облаке
Облако в целом похоже на обоюдоострый меч. При правильном использовании он может быть очень полезен, но при неправильном — пеняй на себя.
Если посчитать количество страниц в документации GCP, то можно издать несколько толстенных томов. Чтобы всё понять, в том числе тарификацию и использование функций, требуется много времени и глубокое понимание, как работают облачные сервисы. Неудивительно, что для этого нанимают отдельных сотрудников на полный рабочий день!
Firebase и Cloud Run действительно мощны
На пике Firebase обрабатывает около миллиарда считываний в минуту. Это исключительно мощный инструмент. Мы играли с Firebase уже два-три месяца — и всё ещё открывали новые аспекты, но до того момента я понятия не имел, насколько мощная это система.
То же самое относится и к Cloud Run! Если установить количество параллельных процессов 60, max_containers == 1000, то при запросах по 400 мс Cloud Run может обрабатывать 9 миллионов запросов в минуту!
60 * 1000 * 2.5 * 60 = 9 000 000 запросов в минуту
Для сравнения, поиск Google обрабатывает 3,8 миллиона запросов в минуту.
Используйте мониторинг
Хотя Google Cloud Monitoring не остановит биллинг, он отправляет своевременные оповещения (задержка 3-4 минуты). Поначалу не так просто освоить терминологию Google Cloud, но если вы потратите время, то панель мониторинга, оповещения и метрики немного облегчат вашу жизнь.
Эти метрики доступны только в течение 90 дней, у нас они уже не сохранились.
Мы выжили
Фух, пронесло
Изучив наш длинный отчёт об инциденте, описывающий ситуацию с нашей стороны, после различных консультаций, бесед и внутренних обсуждений, Google простила нам счёт!
Спасибо тебе, Google!
Мы схватили спасательный круг и использовали эту возможность, чтобы завершить разработку продукта. На этот раз — с гораздо лучшим планированием, архитектурой и намного более безопасной реализацией.
Google, моя любимая технологическая компания, — это не просто отличная компания для работы. Это также отличная компания для сотрудничества. Инструменты Google очень удобны для разработчиков, имеют отличную документацию (по большей части) и постоянно расширяются.
(Примечание: это моё личное мнение как индивидуального разработчика. Наша компания никоим образом не спонсируется и не связана с Google).
Что дальше?
После этого случая мы потратили несколько месяцев на изучение облака и нашей архитектуры. За несколько недель моё понимание улучшилось настолько, что я мог прикинуть стоимость скрапинга «всего интернета» с помощью Cloud Run с улучшенным алгоритмом.
Инцидент заставил меня глубоко проанализировать архитектуру нашего продукта, и мы отказались от той, что была в первой версии, чтобы построить масштабируемую инфраструктуру.
Во второй версии Announce мы не просто создали MVP, мы создали платформу, на которой могли быстрыми итерациями разрабатывать новые продукты и тщательно тестировать их в безопасной среде.
Это путешествие заняло немало времени… Announce запущен в конце ноября, примерно через семь месяцев после первой версии, но он очень масштабируемый, берёт лучшее из облачных сервисов и высоко оптимизирован.
Мы также запустились на всех платформах, а не только в интернете.
Более того, мы повторно использовали платформу для создания нашего второго продукта — Point Address. Он тоже отличается масштабируемостью и хорошей архитектурой.
Zavtramen
Извините, но как это не спонсируется, если вам простили счет на $72`000? Счет хоть и достаточно спорный, но в основе своей правильный — ребята взяли инструмент и, не потрудившись разобраться, врубили его на over9000 %.
edogs
Zavtramen
Может быть, но я все же считаю счет справедливым, равно как и то что они его простили )
Ребятам дали бугатти покататься, они его раскочегарили до 420км/ч и насобирали штрафов, мне такая аналогия видится. Простили и ладно, в целом всем надо быть внимательнее, и гуглу и пользователям.
edogs
Сейчас имеем дело со строителями. Насчитали одну смету, согласовали ее, потом по ходу работ сделали в 2 раза больше и итоговую смету выставили в 2 раза больше поставив перед фактом после окончания работ, не согласовывая в промежутке ничего. Требуют бабла. Справедливо?
Вы открываете пластиковую карту в банке. Специально дебитовую, не кредитную. Оплачиваете ей что-то в интернете, к Вам прицепляется подписка и загоняет Вас в долг на 200 тысяч рублей. Требуют бабла. Справедливо?
Банк выдал клиенту кредит на сумму которую он заведомо не сможет вернуть под залог квартиры. Требует бабла или квартиру. Справедливо?
Можно накидать еще примеров.
И нет, это не справедливо. Нельзя просто взять и загнать клиента в долг без его согласия. Фирма может и должна приостановить оказание услуг в случае исчерпания баланса. Но любые кредитные операции, особенно если фирма не обладает банковской лицензией, должны совершаться с явного согласия клиента, написанного огромными церковнославянскими буквами:)
В контексте этой истории аналогия с бугатти нам кажется более точной в следующем изложении:
Zavtramen
Я имел ввиду то, что счет справедлив потому, что ребята реально напользовали столько. Ровно также я считаю справедливым и то, что им его отменили, чисто по-человечески. В целом тут все не правы, одни фуфловый код задеплоили, другие превысили лимиты, соглашусь. Скорее всего ребята такую лажу и лупанули не проверяя, в надежде на $100 лимит. Не удивлюсь, если у гугла есть где-то мелкий шрифт про то, что билинг может отставать и лимиты могут превыситься, вот почти уверен.
edogs
Наш тезис состоит в том, что поскольку обязанностью гугла было не дать им столько напользовать, то все из этого проистекающее сугубо проблема гугла.
Окей. Разовьем пример с бугатти.
Ребята поехали на нем и разбили его. Счет за починку в 500 тысяч справедлив выставленным им? Стоп, не отвечайте. Учтите два момента:
а) Машина должна была быть полностью застрахована по договору с франшизой в 100 баксов, но арендная контора этог не сделала.
б) Машина была разбита влетев в стройку эстакады, потому что рабочие не выставили ограниченительное ограждение.
Ребята разбили машину? Несомненно. Ущерб есть? Несомненно.
Справедлив ли счет к ним? Нет, тысяча чертей. Кто-то профакапил страховку и ограждения, а теперь пытается включить в счет графу «прокатило».
Zavtramen
Судя по тому как, ребята были рады, что им простили счет, мне кажется, что в юридических доках гугла прописаны такие моменты, ну про то, что лимиты могут отработать с задержкой. У такой мега корпорации все учтено в их пользу. Так что скорее всего все достаточно законно, а вот то что «некрасиво», это другой вопрос. Подождем продолжения где будут выложены доки.
edogs
В сша судебные разбирательства дорогие и расходы на них не всегда компенсируются даже в случае выигрыша, проблема патентных троллей и на хабре habr.com/en/post/381709 и habr.com/en/post/284640 обсуждалась немного, проблема остальных судебных разбирательств не особо отличается.
Затраты на суд против гугла скорее всего составили бы сумму существенно больше чем эти 72 тысячи, поэтому да, маленькому человеку приходится радоваться когда его прощает большой дядя, даже если этот большой дядя только что отдавил ему мизинчик…
Не обязательно.
Закон для больших корпораций это не свод нерушимых правил, а соотношение выгода/потери. Выставят они 10 счетов по 72 косаря… 7 счетов клиенты оплатят, 2 счета придется простить, один дойдет до суда и отсудит 144 тысячи. Выгода налицо. Имхо — все такие вот «выставления задним числом» это сугубо «прокатило» в ресторанном счете.
Спрашивает у мастера:
— А что это за пункт «Прокатило» — 10000 руб????
Мастер:
— Не прокатило. Вычеркиваем.
Zavtramen
Может и так, ситуация неприятная, хорошо, что счет отменили. Никому не желаю оказаться в таком положении ;)
наверное в больших корпорация просто физически невозможно соблюсти все законы, проще какие-то «мелочи» покрыть финансово
tyomitch
Но выиграв суд, они отбили бы и 72 тысячи по счёту, и компенсацию издержек.
vinny496
Отвечаете на комментарий, не читая?
Я уж молчу про дорогих адвокатов, которые выигрывают суды даже когда клиент не прав (в данном контексте это про Гугл), и про трату времени — вместо того, чтобы релизнуть продукт «завтра» потратили несколько месяцев на изучение облака, а то потратили бы это время на суд, попутно обанкротились (другие проекты же тоже остановили, а работникам надо ЗП платить).
А так-то вообще после преодоления лимитов система почему-то решила, что «шпайш машт флоу», что и нарушает договор, и вообще какое-то дикое мошенничество, и тот же Гугл рисковал получить большие проблемы в попытках доказать в суде отсутствие злого умысла.
AC130
Не было у гугла такой обязанности. Внутренние правила гугла — это не обязанность. В любом юридически значимом месте будет написано что юзер сам должен следить за тем, что бы не потратить больше чем он хочет. В противном случае герои статьи могли бы не волноваться а просто пойти в суд. Нет судебного решения — у вас нет аргументов.
rPman
Автоматическая смена тарифного плана на ходу — это не вина клиента, кстати, скорее всего, даже если это будет прописано в этом тарифе
VolCh
Есть разница между потратить и влезть в долги.
vassabi
… создаем статическую страницу, на которой текстом указываем, что для поисковых роботов эта страничка предоставляется в аренду (недорого — 1 цент на 1 показ из кеша поисковика в сутки), а фактом акцепта оферты считается: заход робота на сайт и помещение странички в кеш.
Публикуем, ждем недельку, смотрим в кеш гугла, выставляем счет за аренду.
Законно же, не? /s
czz
Не знаю, как в США, но в РФ акцептом оферты являются действия лица, к которому обращена оферта (т.е. компании Google), безоговорочно (недвусмысленно) подтверждающие его согласие заключить договор.
То есть:
а) Оферту должно прочитать и принять лицо, уполномоченное заключить такой договор от лица компании, а не робот.
б) Действия, которые не выражают явного намерения заключить договор (посещение страницы не является таким действием), не могут быть акцептом оферты.
vassabi
извините, был неточен, действительно, не робот принимает оферту — а компания-владелец поискового робота. Например гугл.
Все остальное — остается такое же :«фактом акцепта оферты считается: заход робота на сайт и помещение странички в кеш». Т.е. не просто посещение.
czz
Должно быть действие, выражающее осознанное намерение принять эту оферту.
Иначе вы могли бы в метро повесить подобную оферту и мгновенно разбогатеть.
unsignedchar
Выставить счёт, конечно же, законно. Но его можно так же законно опротестовать. Если прокатит, можно заработать немного денег. Если непрокатит — можно заработать немного проблем с коллективным иском от хитрых законников. И вопросов от налоговой в стиле "не занимаются ли тут финансированием терроризма и отмыванием денег".
Vilgelm
Нет, нет, нет, да. Потому что в первых трех случаях клиент не знал о том, что ему навешают долгов, а в последнем сам на это пошел добровольно. В случае описанном в посте это больше похоже на первые случаи, раз с них должны были только $100 списать, но раз автор об этом узнал постфактум, то и он виноват тоже (иными словами если бы этого пункта про $100 не было, то это был бы уже не глюк биллинга, а что-то типа «взять кредитку с большим лимитом и потратить ее»).
haldagan
Все вышеприведенные случаи в общем-то зарегулированы законом и решаются чтением договора, который вы заключаете.
Не совсем понятен только второй пункт (что у вас такое написано в договоре со строителями-то, что они требуют плату за неподписанную смету?)
Я понимаю, что симпатии читателя на стороне потребителя (он им ближе), да и компании часто пользуются дырками в законах и мелким шрифтом, чтобы вводить в заблуждение, но давайте попробуем посмотреть на те же ситуации с другой стороны (про строителей — от себя нафантазировал, уж простите):
1) Ваш клиент воспользовался задержкой обработки счетов между вами и вашим заграничным партнером. Вам приходит счет на 1.4 млн рублей от вашего заграничного партнера, а клиент говорит «у меня на счету всего 1.5 т.р. было, а платить не буду, потому что думал, что раз задержка — значит бесплатно и на буквы в договоре/тарифе можно не обращать внимания». Это справедливо?
2) Заказчик дал устное согласие на изменение сметы. Вы потратили время рабочих и материалы, а теперь заказчик говорит «платить не буду, в изначальной смете этого не было». Это справедливо?
3) Клиент открыл счет с овердрафтом, правила использования которого прописаны в договоре. Положил $100 на счет, вы оплатили его фуршет в ресторане за $1000, включился овердрафт, а теперь клиент говорит, что денег у него нет. И фуршет обратно тоже не вернуть. Это справедливо?
4) С кредитом вообще не понятно. «На сумму которую он заведомо не сможет вернуть под залог квартиры». То есть сумму-то он вернуть сможет, но если продаст квартиру. В чем спорность ситуации? «Под залог» — это когда банк практически прямым текстом говорит «ЧУВАК, ТЫ НЕ СМОЖЕШЬ ВЕРНУТЬ ДОЛГ, НО ЕСЛИ ТЫ СОБИРАЕШЬСЯ РИСКНУТЬ — МЫ ДАДИМ ДЕНЕГ, ТОЛЬКО СТАВЬ НА ЭТО СВОЮ
ЖКВАРТИРУ».Повторюсь: да, многие законы не известны или не понятны рядовому потребителю. Да, большие корпорации и банки пользуются малограмотностью, юридической неосведомленностью, мелким шрифтом в договорах и т.д. и я считаю, что это не очень хорошо, неэтично и в целом несправедливо, да.
Однако во всех вышеперечисленных случаях спасает банальное прочтение договора.
Ну и про индусов из статьи аналогия скорее такая:
Ты дал ключ от F15 клиенту. (типа шутка)
— Цена $1000 за 100 километр полёта.
— Ну я так немношк пролечусь, — ответил клиент и дал тебе $1000.
Придя в ангар клиенту скомандовал
— Подготовьте-ка мне мой F15.
— Как?
— А как вы обычно делаете?
— Ну обычно бак на полную, двигатели в форсированный режим и шансон на максимум.
— Сойдет!
После чего клиент поднимается в воздух и делает полный круг вокруг земного шарика и приземляется.
— Слушай, ты должен нам $40 000 000
— Так я же заплатил $1000, чойта я вам должен?
— Тебе ж было сказано, что это за километр.
— Эээ, а что не предупредил, когда километр кончился?
— Так ты на сверхзвуке рванул — пока мобилу доставал ты уже полпути пролетел. Да и вообще мог техникам сказать, что тебе ограничение по скорости в километр в час поставить, а не форсированный режим — точно бы не промахнулся.
fuermann
Скорее дали бугатти, сказав что там вклюен ограничитель скорости на 15кмч, а оно у них рвануло с места на максимальных 1.2 кило-лошади мощности
tyomitch
Настройки по умолчанию были «максимальные 1.2 кило-лошади», парни это видели, но не придали этому значения. (Часто вы меняете настройки по умолчанию в программе/сервисе, которым пользуетесь впервые?)
Stas911
Ну, например, в AWS я слабо могу себе представить, что можно такого случайно сделать, чтобы получить такой счет. Даже если клиент ошибся — за 10 минут десятки тысяч килобаксов не натекают (ну или я не слышал про такие случаи). Самый большой инстанс стоит десятки долларов в час. Контейнеры и лямбды имеют по-умолчанию лимиты порядка нескольких сотен на аккаунт — тоже не особо разгонишься.
tyomitch
Вот, а они запустили 1000 инстансов на 24 часа. О том и речь.
Stas911
На самые большие инстансы в AWS крайне небольшие лимиты — тк их вообще часто немного в каждом регионе есть. И это точно не 1000.
daitepiva
В AWS тоже автоматически, без подтверждений с моей стороны, перевели бесплатный тестовый аккаунт в коммерческий и сразу попытались снять 54 доллара с карты. Слава богу им не это не удалось. Пришлось переписываться с поддержкой и закрывать свой аккаунт, хорошо хоть не стали дальше требовать деньги.
czz
В AWS нет бесплатных аккаунтов
rPman
aws.amazon.com/ru/free
И хоть это и действительно бесплатно, снимать деньги начинают сразу при превышении лимитов.
dominigato
Мой вроде засуспендили сразу. Может сейчас уже не переводят автоматически на платный?
czz
Free tier — это другое.
Деления на «бесплатные» и «коммерческие» аккаунты, как написал автор комментария, нет.
Brodilla
если так думать, то гугл может любого рекламодателя со 100 баксами загнать в долговую яму, выставив ему счет на 72т со словами «мы показывали вашу рекламу на все», а у вас и сайт упал от наплыва клиентов и долг «сформировался». собственно, зачем ограничиваться 72т? даешь миллион?
Zavtramen
Так ведь тут разница в том что «показывать вашу рекламу на всё» ребята оставили как опцию по дефолту. Они поленились подумать над алгоритмом, поленились подумать над настройками облака, поленились настроить мониторинг, «уяк-уяк и в продакшн». А лимиты они работают как уведомления, а не как останов. Я не говорю, что это хорошо и классно, и не хотел бы к себе такого отношения, потому что ошибиться может каждый, но это справедливо поскольку прописано в доках гугла. Czz ниже все расписал.
playnet
Проблема не только в лимитах, но и в задержке в 48 часов.
И лично я теперь ещё подумаю, размещаться ли у них, если они позволяют клиенту уйти в такой минус без его согласия. А уж «мы тут автоматом вас перевели на платный акк» — по хорошему это повод идти в суд, ибо мошенничество чистейшего вида.
Амазон таким не страдает, как я помню.
Temmokan
В Амазоне можно успеть получить уведомление о превышении ожидаемого размера счёта (если настроили такое уведомление), но сервисы от этого не остановятся — пока сами не остановите (поправка: надо посмотреть, можно ли сейчас настроить действие наподобие «отключи нахрен такие-то и такие-то сервисы», в ответ на превышение порога ожидаемого счёта).
Влететь на мегабаксы в Амазоне можно крайне легко. Особенно легко — в случае сервисов, которые сами запускают другие сервисы, та же Лямбда.
Тарификация в Амазоне, если не путаю, выдаётся в браузерной консоли с задержкой в час, так что следует быть крайне осторожным.
Zavtramen
Пишут что все было немного не так: habr.com/ru/post/532624/#comment_22417604
VolCh
Регался в 2013-м на Амазоне поиграться на бесплатные кредиты. Запустил что-то, оставил на ночь, а тут оффер, релокейт, комп с собой не брал, в общем в этом году зашёл: долг баксов 600 и ничего не даёт сделать пока не погасишь.
arctic-fox
У них точно не яйцо в эмблеме? А то что-то подозрительно напоминает.
algotrader2013
Счёт явно не правильный. У ребят был выставлен лимит в $100. Если гугл технически неспособен его проконтролировать, то пусть выставляет счета сам себе. Удивляюсь, почему, аналогично gdpr, до скотов ещё не добрались со стороны регуляторов
czz
Лимита в $100 не было. Текст, приведенный в статье, означает лишь, что списание с карты будет произведено, когда баланс станет $100 или более, либо по истечении 30 дней.
mithdradates
Читайте текст внимательней, лимит там был, правда не $100, а вообще $7.
czz
Это тоже не лимит. Я сейчас опишу, как бюджет работает в амазоне, скорее всего в гугле аналогично.
По истечении бюджета не происходит автоматическая немедленная остановка всех сервисов и прекращение биллинга. Сервисы вообще невозможно немедленно остановить, особенно если там получилось какая-то рекурсия, когда одни инстансы запускают другие, тем более если это serverless сервисы (насколько я понимаю, в статье описывается serverless архитектура).
Превышение бюджета — это уведомление, на которое можно повесить определенные действия — по умолчанию это письмо на емэйл. Далее можно опционально добавить остановку инстансов EC2 (виртуальные машины) и RDS (база данных), но не serverless сервисов. И кроме того можно отправить уведомление в SNS (notification service), где на него может отреагировать какой-то код (но этот код еще надо написать).
Разработчикам надо было ставить разумные лимиты на использование конкретных сервисов (firebase, инстансы).
czz
.
dominigato
Так это и есть проблема. Видимо это где-то написано маленькими буковками на 356-ой странице? Потому что ну совсем не очевидно.
czz
Вряд ли это вообще где-то написано, потому что это вполне разумное и ожидаемое поведение.
Нельзя просто так взять и махом вырубить все виртуалки, убить выполняющиеся процессы и очистить очереди от необработанных сообщений. Во многих случаях будут нарушения консистентности данных, которые потом будет сложно разрешить, и вообще есть вероятность, что сервис после этого не поднимется. Тогда уже могут быть претензии от больших компаний, где данные дороже денег, а не от стартаперов, копирующих код со stackoverflow.
Но какие-то более мягкие меры для уменьшения ущерба на стороне гугла, с моей точки зрения, должны были быть предусмотрены.
Скажем, могли бы быть установлены лимиты количества запросов для новых пользователей, которые расширялись бы по заявлению после подтверждения платежеспособности компании. По истечении такого лимита доступ в firebase мог бы быть заблокирован почти мгновенно, аналогично и возможность запуска cloud run могла бы быть заблокирована. Это безопасно с точки зрения сохранности данных, а экспоненциальный рост иссяк бы за несколько минут.
Но также я допускаю, что сервис не обязан иметь «защиту от дурака», если он рассчитан на профессионалов, а не на дураков :)
dominigato
Это совершенно неразумное, неочевидное и неожидаемое поведение. И я надеюсь за гугл что они это где-то прописали. Иначе трудно было бы вообще что-то доказывать в судах.
Можно
Надо делать это не через ж..
Это не защита от дурака, а скорее умалчивание и неочевидность терминов, что вообще граничит с мошенничеством. Никто не должен догадываться что в гугле подводят баланс раз в сутки, это даже позорно.
czz
Я сейчас за несколько минут посмотрел документацию по бюджетам (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-й странице.
Похоже, что «догадываться» приходится только тем, кто не читает доки.
dominigato
Ну вообще-то там обещают:
То есть точно то что стартаперы хотели и любой юзер был бы не против иметь.
Однако маленькими буквами все же:
То есть пробовать конечно можете все, но никто нам не мешает загнать вас в долговую яму на всю жизнь только потому что вы не ту кнопочку нажали.
Это просто прекрасно.
czz
Вы все-таки немного драматизируете. Во-первых, написано достаточно заметно. Во-вторых, в долговую яму никто никого не загнал, у стартаперов есть право на ошибку. В-третьих, рекомендуется использовать лимиты по ресурсам, там гранулярность 100 секунд.
Я согласен, что такая большая задержка в биллинге сводит почти к нулю полезность данной функции, но, видимо, сценарий использования, на который рассчитывали создатели сервиса, не предполагал рекурсии с экспоненциальным ростом. Может быть, они извлекут урок.
dominigato
Ну мы только одну историю слышали, сколько их там было никто не знает. Вряд ли конечно кто-то так разгонялся, но "с миру по нитке — голому рубаха".
czz
Как тут говорят, Гугл — не корпорация добра, так что вряд ли речь идёт об их доброй воле, а вероятно, есть какая-то политика и регламенты разруливания подобных ситуаций.
playnet
«Ожидаемое» кем, сотрудниками гугла? Особенно в контексте получить побольше бабла?
Виртуалки уже в 2008 умели такую штуку как pause. Также есть такая штука как cpu credits, и машина просто начинает работать медленнее, вплоть до полной остановки, оставаясь технически running. Так что было бы желание.
Корпорация «добра», что с неё взять…
czz
У виртуалки на паузе идёт биллинг за хранилище и снапшоты. Чтобы остановить биллинг полностью, нужно грохнуть все данные, включая бэкапы. Такое поведение вы бы ожидали?
Это во многих случаях даже технически невозможно, у вас могут быть такие объемы данных, что их удалять надо будет несколько дней, а потом вы их будете несколько недель заливать обратно.
Ожидаемое с точки зрения сохранности данных, я конкретно об этом написал. Деньги приходят и уходят, а данные не всегда можно вернуть. Это vps за 3 бакса вам могут удалить со всеми данными и сказать «а че такого?», а здесь другой подход.
VolCh
Судя по рекламе он так не позиционируется, а ровно наоборот: вам больше не нужны профессионалы по администрированию сервисов, мы делаем эту работу за вас
czz
Профессионалы по администрированию сервисов может и не нужны, а профессионалы-программисты, видимо, все-таки еще нужны :)
VolCh
Настройка лимитов мышкой — работа программиста?
czz
Работа программиста — выполнить задачу, использовав разумное количество ресурсов.
rPman
'Лимит' там БЫЛ! в 7$ проблема началась когда счет автоматически проапгрейдился.
Такие техники — полностью вина на сервис-провайдерах (в данном случае гугл), система специально (понятно юридически доказать это очень сложно) выстраивается такой чтобы в тарифных планах были ценовые ловушки, просто на практике клиенты попадают на 10х от ожиданий, способны это заплатить и молча в тряпочку это делают.
czz
Это не лимит, а “free tier”, сумма, в рамках которой клиент пользуется сервисом бесплатно, а дальше начинает платить.
Клиенту «простили» услуг на 72000, офигеть ловушка, хотел бы я почаще попадать в такие ловушки.
Acuna
Корпорации на удивление довольно серьезно относится к странным и необъяснимым начислениям, на своей шкуре убедился давно в их милости: одно время по инету гулял паук, который собирал данные Amazon EC2 и создавал на этих акках миллионы виртуальных машин (говорят что для майнинга, это как раз было тогда, когда это было модно-молодежно), под раздачу попал и я, когда в открытый репозиторий выложил проект, где хранились эти данные, за три часа мне накрутило 5 000 баксов (уже по курсу 70), это две средних зп программиста, конечно же было довольно обидно, в итоге они заблочили мне акк (хотя казалось бы, им-то что до этого), и так и написали, мол, это как-то нездорОво, у вас все нормально, а-то тут у людей акки воруют, может и у вас тоже, и я такой ой, да, вы уж извините дурака, сам не знал чо творил, и они аннулировали этот счет вообще без разбирательств (Гугл-то еще в чем-то разбирался, какое-то расследование проводил), а ведь тоже имели полное право сказать мол ну да, ходит паук по интернету, но ведь даже дети знают какие опасности подстерегают в инете на каждом шагу, так что сам мол виноват, долг платежом красен.
dominigato
Вы в открытый репозиторий на гитхабе выложили данные для авторизации на амазон?
Acuna
Залил в открытый по ошибке, да. Забыл закрыть когда создавал. Я же и говорю, моя безалаберность.
dominigato
Да это вообще неважно какой, закрытый или открытый, их вообще нельзя хранить в репозиториях.
Да и паук особо не нужен, можно просто поискать
Acuna
Да понятно, молодые, горячие были, там просто конфиг попал в прод, который не должен был. А «не хранить» это в смысле папку с ними запрещать для индексирования, или что?
dominigato
Ну наверное да… но я не понимаю почему папка с ними вообще должна быть в репозитории.
Acuna
А где они должны быть? Если в БД, дак они все-равно как-то должны в нее записываться при деплое, не на бумаге же дампы хранить. Или может на перфокартах?
dominigato
Если в репо, то только с Vault. В любых других случаях — хоть на перфокартах, да.
Acuna
Оооо, ясно, правда даже не знаю, очередной запрос к очередному api, но идея интересная благодарю. Неожиданная, я бы даже сказал бы :/
VolCh
Простой и относительно безопасный способ: файл типа secrets.conf или .env в .gitignore, при первом/каждом деплое там задаются пароли не из репозитория, приложение их читает при старте/релоаде, можно даже наблюдение за файлом сделать для автоматического релоада.
Acuna
О, да, благодарю, тоже интересно. Правда меня немного смущает что это все ради того, чтобы не хранить явки на Гитхабе, но когда бабки на кону — то да, перестраховаться стоит. Я просто, если честно, почему этот вопрос не прорабатывал — потому-что считаю панацеей приватные репы (понятно что на них тоже не желательно полагаться, но все), на худой конец Гитлаб локальный развернуть прям на компе без инета, да и всего делов, чем запросы очередные на Vault делать только ради конфигов, я уж не говорю о том, что к проду вообще нельзя из коробки доступ получить никак. В идеале имею ввиду, а не когда сервак реально сломали.
VolCh
Я не ради сохранения секретов подходы с конфигом применяю. В основном, главное, что код из репы можно было развернуть в разных окружениях, с разными кредами к той же СУБД.
playnet
1) конфиги — в .gitignore, а примеры для настройки — в .sample с <here_password_or_hash>. Можно использовать симлинки, если и закоммитится конфиг с линком на ../../../configs/prod.conf — невелика потеря, при условии что configs выше корня проекта
2) использовать vault или у амазона — SecretsManager
3) гитхаб уже штатно блочит такие вещи, и присылает письмо счастья.
czz
В США принято, что вы не несете обязательства по действиям третьих лиц, совершенные без вашего согласия, пусть вы даже и проявили крайнюю беспечность.
Acuna
Ого! Ну это прям как с какой-то другой планеты новости (хотя чему я удивляюсь?). Это я отвечал человеку, который обвиняет автора в том, что это рекламная статья, типа вам же Гугл счет списал на 72 000, а вы говорите что никакого отношения к нему не имеете. Вот я и говорю, вполне обычная практика для них.
Valsha
Скорее всего не в «инструменте» проблема, а в:
« Мы действительно обнаружили новый способ использования бессерверного использования POST-запросов, который я не нашёл нигде в интернете, но задеплоили его без уточнения алгоритма»
То есть взяли кусок кода где то в интерне и без проверки (ВООБЩЕ) задеплоили.
Zavtramen
А еще вот в этом «Я практически не тратил времени на управление облаком — потратил ровно столько, чтобы поднять систему и обеспечить базовый процесс разработки (CI/CD).»
Theodor
Наоборот же, сами придумали монстра, который даже не гуглится.
soymiguel
Да все лучше, выглядит так, что они не нашли в интернете подходящий исходник для отправки POST-запросов, поэтому запилили свой, не фильтрующий дубликатов — и тут же и выкатили, так и не приходя в сознание в своей парадигме «стремительно учиться и пробовать новые вещи». Такой себе обучающий DDoS за $72k получился.
Ну то есть ребята в принципе не особо понимают, что делают, собирая свой убер-стартап по кускам кода со stackoverflow, а в случае отсутствия — запиливая что-то таинственное в меру своего затейливо-гималайского восприятия окружающего мира.
unsignedchar
Х@@к и в production с одной стороны (тестирования нет и не предполагалось). И "непрокатило " с другой. Без этого конфликта не было бы истории.
Acuna
Во-во, Гугл им прощает долги из-за безалаберности (ибо я почитал выше что там пишут про их код, и это какой-то лютый сюр), а его обвиняют за это в том, что он статьи мол заказные заказывает…
Valsha
Ну Гугл конечно тоже молодцы, циничненько они так конечно ))
Squash
Они молодцы настолько, что там в принципе нельзя выставить лимиты в деньгах, например $100. Можно лишь выставить алерты при достижении определенной суммы. А вот сами лимиты в обычном понимании — типа вырубить все сервисы при достижении лимита денег — нет такого. Там можно настроить лимиты, но не в деньгах, а в неких внутренних юнитах, отдельно для каждого сервиса. И для каждого сервиса стоимость юнита в долларах разная. В общем мрак. Поправьте меня, если лимиты в деньгах там таки настроить можно.
maxbl4
На сколько я знаю лучше всего дела в этом направлении идут у Амазана, у них на многих сервисах реальная посекундная тарификация.
Вообще сделать даже поминутную тарификацию очень сложно и это проблема не одного гугла. Просто попробуйте спроектировать такую систему. Вот у вас есть база данных, которая может обрабатывать 9млн запросов в минуту, как в статье, для одного клиента. Для всех клиентов она наверно 10^11 запросов в минуту обрабатывает, а то и больше. И нужно каждый запрос посчитать, перевести в доллары и обновить счёт у клиента и чтобы не тормозило… Это колоссальная задача, по ресурсам сравнимая с работой самой базы данных. Поэтому они и делают лаг, обновляют биллинг только раз в какой-то интервал, например в сутки. А пользователям рекомендуют следить за метриками и ставить лимиты по метрикам, т.к. метрика не требует особой обработки, это просто число запросов, его можно быстро выкинуть в АПИ и обновлять, а уж юзер сам решит как реагировать на взлёт метрик — например установит лимит.
Опять же в большой компании наверняка есть специальный отдел биллинга, то есть сервис базы данных сам ничего не переводит в деньги, он только отправляет метрики использования в систему биллинга, она там уже внутри в соответствии с тарифами пересчитывает в деньги, выставляет счета, списывает с карт. Это всё занимает время.
Так что на любой облачной платформе легко можно уйти в минус, если моментально создать нагрузку в 1000+ раз больше, чем ваша средняя нагрузка за день, вы просто сгенерируете себе счёт как за 1000 дней типичного использования.
Что странно конечно, это автоматический апгрейд уровня обслуживания. Если у них был бесплатный тарифный план, их должны были затротлить и всё. Вот в этом реальный косяк гугла, наверно поэтому они и не стали требовать оплату, поняли, что в суде проиграют
Squash
Дак вот и беда, что нет там бесплатных тарифных планов. Я веб разработчик, делаю например сайт, и подключил на сайт гугл карту. Для разработки я для себя создал API ключ для доступа к гугл картам, на и делаю сайт потихоньку. Ранее в бесплатном тарифе у меня было какое-то количество запросов в API, для разработки мне их хватало, и всё нормально. А теперь гугл сказал что бесплатных тарифов нет, но дает бесплатных 200 баксов, и требует привязать карту к аккаунту. И теперь если на мой тестовый сайт случайно привалит толпа ботов, нагенерит кучу запросов к гугл картам, я попаду на деньги. Конечно я пытался настроил лимиты, но там даже лимиты настраиваются не в количестве запросов в АПИ, а в юнитах, на каждый юнит дается xx запросов к статическим картам или yy запросов к динамическим или zz других запросов. И где-то ошибиться в этих всех юнитах элементарно. А хочется банальную вещь — отрубить всё при превышении лимита по деньгам.
Finesse
Я завёл виртуальную карту для сервисов, которые требуют привязки карты, и положил на неё минимально необходимую сумму денег
oz0ne
Это не спасет от истории как в статье — счет выставят все равно, и будут требовать оплату. Ну или заводить новый аккаунт потом.
reborm2
Гугл мапс не принимает «предоплаченные карты».
Так он назвал мою виртуальную карту тогда еще яндекс денег.
vassabi
… теперь понятно почему!
onlinehead
Так сложилось, что буквально не так давно я проектировал подобную систему, но конечно меньших масштабов. Там все получается достаточно сложно, но не на столько, чтобы прям по ресурсам было как у самой базы данных, даже если она позволяет десятки миллиардов операций.
Ключ к скорости — аггрегации на уровне ближе к сервису и, очевидно, параллельность. У каждого сервиса есть 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 тысяч контейнеров, что более чем ок.
onlinehead
Другое дело, что гуглу дешевле вот так «прощать» оверчарджи, чем содержать систему, которая более-менее быстро будет считать расходы при их текущей архитектуре с тысячами SKU и дать возможность алерты выставлять.
Раз в сутки этот объем информации еще можно посчитать за более-менее внятные деньги, а вот 50 раз — уже дорого.
Это кстати некоторым образом объясняет, почему некоторые провайдеры вроде DO стараются вводить как можно меньше billing metrics и упрощать тарифы — просто потому, что считать развесистую систему метрик на каждый чих очень дорого.
rPman
Гугл мало что потерял, себестоимость их сервисов для гугла — 10х..100х крат меньше.
Stas911
А вот и нет — конкуренция на рынке облаков такова, что там нет никаких 10-100 крат наценки. Иначе AWS или Azure его бы выщемили ценами.
rPman
И какие же конкуренты у амазона и гугл с таким списком услуг? майкрософт? и все? Облачные услуги именно тем и хороши, что у них отличные от классической ценовой политики 'взять в аренду машину' — оплата за действия, где много возможностей по увеличению доходов на пустом месте.
Окей, забыли про маркетинг и ценовые ловушки.
Тупой пример — вы способны поднять распределенный кластер для хранения данных в оперативной памяти повышенной отказоустойчивости (это пальцем в небо, на основе косвенных уликах)? а гугл с его ресурсами способен, а это значит вместо прямой записи на диск они могут 'включить' кеш writeback или напрямую размещать файлы баз данных в оперативной памяти.
Дальше, маленькая компания не способна разработать/переделать проект, оптимально работающий в архитектуре, где не нужно заботиться именно о ненадежности хранилища, а вот крупные типа гугл вполне способны, мало того можно сначала разрабатывать опенсорс с классическим подходом, отлаживая идею а для внутреннего использования пилить оптимальный, используя наработки из опенсорс — весь мир будет использовать не оптимальный и мерить свои расходы соответственно.
Это реально, отличный пример смены парадигмы — rest с запуском приложения на каждый запрос -> на все работает внутри единого приложения, даже простейшие тесты перехода с http rest на websocket дают повышение скорости на порядок, а если еще и базу данных убрать, оставляя данные в оперативной памяти без смены форматов и сериализации…
Еще, на рынке уже есть мастодонты, конкурировать с ними никто адекватный не будет, силенок не хватит, максимум попытаться занять маленькую нишу (и даже в этом случае тебя мастодонты купят). Вы как клиент не будете рисковать с множеством никому неизвестных компаний, которые решают только по 1% ваших задач, вместо этого вы пойдете туда где ваши задачи решаются все в одном месте.
dominigato
"картельный сговор" же
Гуглoвский клауд и так "выщемлен", хоть и не из-за цен.
maxbl4
Я не спорю что можно сделать. Но вы сами согласны, что объем большой. А ещё нужно учесть, что раз в 30 минут не уберёт проблему описанную в статье. Если запустить большую параллельную задачу на pay as you go тарифе без ограничений по ресурсам даже за полчаса легко на много тысяч улететь. Я слышал, что Microsoft поставила цель сделать поминутный биллинг во всём azure, не уверен по срокам, но движение в эту сторону есть и уже есть некоторые сервисы, которые это умеют.
Также у пользователей существует фундаментальное не понимание как работает биллинг, в статье это упоминается "у меня на карте было всего 100$". В контексте, что "как же я мог потратить больше". А вот легко мог, потому что биллить карту даже раз в полчаса это мало реально, поэтому даже в деньгах лимит нужно явно устанавливать руками в сервисе. Иначе к тому времени когда система решить списать с карты, уже будет большой счёт
Stas911
Недавно был блогпост — там писали, что на Prime Day магазин Амазона, куда все ломились как ненормальные, делал «всего» 80М запросов в секунду на DynamoDB. Вы же предлагаете обрабатывать на пару порядков больше запросов, чтобы посчитать деньги чуть быстрее? Что это даст пользователям? Кто оплатить банкет? Нищие стартаперы?
czz
В Амазоне — да, тарификация может быть почти в реальном времени, и при достижении бюджета можно послать команды на остановку сервисов — но все равно эта остановка может занять несколько минут на большой инфраструктуре, и за эти несколько минут может произойти все, что угодно.
Поэтому лимит по бюджету вообще в принципе невозможен, так как невозможно при достижении бюджета мгновенно отрубить сервисы и прекратить списание денег.
Terranz
Значит надо рубить по достижению 80% бюджета, например
dimabelousov1
Можно тогда просто самому задать «бюджет» на 80%
Stas911
А кто вам мешает? Поставьте billing alert и останавливайте.
Gizmich
Ну можно перестать считать биллинг после поступления команды на остановку и тогда не важно сколько по времени она займет, она уже не будет тарифицироваться.
czz
Тогда появилась бы легальная возможность напользоваться услугами на $72k бесплатно :)
Valsha
« Вообще сделать даже поминутную тарификацию очень сложно и это проблема не одного гугла. Просто попробуйте спроектировать такую систему.»
Ну никто и не спорит что это очень не просто. Но мы же с вами сейчас говорим о Гугле а не МакДональдсе (отсылка к фильму с Кевином Спейси « Двадцать одно» 2008г).
Stas911
Посекундная тарификация (а реально она уже миллисекундная на лямдах) не означает, что сервис отключится по достижении лимитов. Как уже сказали — это было бы крайне опасно для больших корпораций. На всех сервисах AWS есть soft-limits, которые можно поднять обратившись в поддержку. Они как раз и призваны ограничить темпы сжигания денег при факапах.
soymiguel
Ну разумеется, переворачивающие мир божественные индийские стартаперы. Это должно быть в энциклопедиях, как хрестоматийный пример к статье «Даннинга-Крюгера, эффект», часть «Типичные проявления и их последствия».
gsaw
Имхо это дырка. Любой получается, не имея средств может попользоваться мощной инфраструктурой Гугля. Имхо, должна быть какая то граница, с которой оплата должна осуществляться не кредитной картой, а переводами и заранее обговариваться.
В нулевых было одно время подобное. На сайт заходишь проверить свой IQ, а там мелким текстом, что пройдя тест ты тем самым осуществляешь подписку 80 евров в месяц. Мало того что тем самым завалил тест на IQ :) так ещё и счёт через пол года приходит и в придачу письмо от адвоката, мол не заплатите, айда в суд. И некоторые платили. Потом прикрыли эту лавочку.
Я к тому, что кто-то может попользоваться инфраструктурой и отнекаться в суде и у Гугле останется на бобах. А могут и криминальные типы попользоваться и ищи потом свищи. Ещё и крайними гуглы останутся.
kmmbvnr
Да, сценарий для DOS, зарегают несколько аккаунтов с краденными карточками и запустят по несколько миллиардов запросов. Рано или поздно, облако Гугла кончится.
screwer
Хрен с ним, с Гуглом. Зато появляется возможность получить дорогущие вычисления на халяву.
DonAgosto
Уже было на хабре, да
Вкратце — у чувака взломали почту, угнали облако (гугл или амазон?) и запустили там крипто-майнер.
razielvamp
Ок, я проигнорировал, что задеплоить SQL базу данных слишком затратно, хотя мускл какой-нибудь поднимается за полчаса. Я проигнорировал, что для создания тестовой даты людям потребовался высокопроизводительный AI, я не обратил внимания на то что команде потребовалась ночь, чтобы понять за что пришёл счёт. Пропустил мимо ушей тот факт, что они вообще не разбираются в том что делают, судя по описанию процесса, что в stackoverflow нагуглили то и запустили...
Но я не выдержал когда узнал что чел работал в гугле… Да как же так-то… Судя по тому какие вопросы задают подобные компании на собеседованиях там одни гении работают.
Я с пятилетним опытом работы с linux даже на четверть не могу ответить… Как в linux initrd работает, как docker изолирует и разделяет ресурсы ядра, как управляет памятью и её переполнением… Человек знающий детальные ответы на вопросы такого уровня просто что-то там поднимает о чем в интернете прочитал?
Такое впечатление, как-будто в IT начали как в шоубизнес набирать… С каким ПМ мне надо переспать для этой работы? Или пойти сделать операцию по смене расы на индуса что ли...
Извините, после 35 собеседований за последние два месяца наболело
PleaseKING
Вы же не знаете, кем он там работал...
arkamax
Это уже давно так. Я вот уже второй месяц бодаюсь с ТП Microsoft по достаточно простой теме, счет людей, с которыми я говорил, приближается к 10, и никто, Карл, не знает, как решить мою проблему. По ней есть три набора документации, все три говорят разные вещи, не работает реально ни один. И всем нас… ть, что характерно, потому что никому из тех ~10 саппортистов лично не прилетит по башке, если оно не заработает. Если это не шоубизнес, тогда что?
unsignedchar
"Или пойти сделать операцию по смене расы на индуса что ли..."
Кроме расы, нужно ещё правильных родственников получить. Индийское кумовство же.
stokker
Сменить касту будет вполне достаточно.
unsignedchar
«Мышки, станьте ёжиками».
maxbl4
Проблема в том из какого региона нанимают. Если вы живёте в России и хотите попасть в гугл, вас должны взять на довольно высокую позицию, чтобы имело смысл оплачивать переезд, визу и так далее. Поэтому отбор очень суровый.
Если вы уже живёте в США, есть рабочая виза или гражданство и вы ещё и студент последнего курса, то попасть на стажировку на начальную позицию не составляет особых проблем. Потребность в кадрах на порядок выше предложения, поэтому берут всех подряд
Firz
Натыкался с год назад на статью человека, прошедшего в гугл где-то в америке, так вот он там описывал как проходило собеседование и как он с нуля(работал строителем что ли) к нему пол года готовился на курсах… по подготовке к собеседованиям в FAANG. То есть человек пол года учил то, что в этом году спрашивают на собеседованиях, профессиональный проходитель собеседований.
denisshabr
Был такой фильм, «Кадры», как раз про гугл.
dj1m
Ох, боже, я не одинок!
Каждый раз, читая очередной фейл, думаешь да как так то?!
Наверняка, автор зато мастерски раскладывает красно-чёрные деревья, разворачивает листы, разделяет ценности и всё это за bigO(1) и вообще без памяти.
Осталось только софт научиться писать и системы проектировать, ну это мелочи.
Stas911
Возникает вопрос, чем он занимался в Гугле, что вообще не представляет как работает их собственное облако?
vvzvlad
Другим облаком. Или кусочек фронтенда на гугловской библиотеке писал. В таких условиях сложно понять что-то кроме гугловской библиотеки.
OloloUndefined
Да ничего он не писал, дело вроде было в отсутствии контроля кол-ва/дублей URL ссылок перед тем как их (рекурсивно небось, да по модному в новый инстанс каждуюю) на обход в очередь поставить. А «виновата» у автора — плохая «архитектура»? Это странное слово которое говорят программисты из далекого подвала, полюбому она
alex6999
В Канаде есть закон, который ограничивает максимальную накрутку в 100 долларов в месяц за любые цифровые услуги, за всё, мобильный, интернет и прочее. Если гугл накрутил вам 72К, то он сам себе Буратино, имеет право только на тарифный план + $100. Это конечно в случае если вы сами не попросили снять данные лимиты.
Не уверен, но по-моему в штатах тоже такое есть.
grishkaa
В штатах, насколько мне известно, с защитой прав потребителей всё очень плохо. Это у нас всё по предоплате, кроме, разве что, коммунальных услуг, а у них — нет. В итоге получаются такие замечательные истории, что подписаться на что-нибудь (кабельное ТВ, новостные сайты, абонемент в спортзал, доставку готовой еды, спутниковое радио в машину) можно неосторожным движением курсора на сайте, а вот отписаться… У них будут данные твоей карты, и они будут снимать с тебя деньги. Заблокируешь карту — отдадут тебя на растерзание коллекторам. Единственный способ отписаться без негативных последствий для себя и своего кредитного рейтинга — расчитывать на их милость, которой у них, конечно же, не будет. В лучшем случае в интерфейсе будет много тёмных паттернов и попыток надавить на жалость. В худшем интерфейса не будет вообще — заставят звонить в колл-центр и час припираться с индусом, пытающимся удержать клиента, потому что если удержит слишком мало, его уволят.
(источник: иногда слишком много сижу на реддите)
iproger
Поэтому в спортзал лучше с наличными.
urvanov
Это же в друзьях уже обыгрывалось
Ostapus
с защитой, как таковой, тут (в штатах), проблем нет. но, если ты подписался в спортзал на год (и получил скидку), то да, придется платить… можно не ходить, а платить — придется. то же самое, и с любыми сервисами, что вы описали.
wadeg
Басни. В США чарджбэк в таких случаях будет запущен по одному звонку в банк.
grishkaa
На том же реддите писали, что в этом случае могут отдать коллекторам, как и если карту перевыпустить. Не знаю, насколько правда.
wadeg
Не могут, оснований нет. Подписка «неосторожным движением курсора на сайте», как и любой подобный скам, отменяется моментально. Потому там и распространены покупки в интернете (и пицца по телефону домой, классика) просто по номеру карты без всяких cvv. Это защита платежной системы, отмена фрода — в таксе.
acklamterrace
Вы про этот? 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.»
К облачным сервисам это никак не относится, кмк.
centralhardware
А без целого букета новомодных SaaS-ов стартап это не стартап? VPS за три доллара, и взламывайтк хоть Пентагон полным перебором, цена останется та же. Не можете написать нормальный софт или поднять его на своей виртуалке, ну тогда вообще не понятен какого фига вы лезите в разработку.
zim32
Ну есть определенные так сказать нюансы. Например реклама. Обычно это как выглядит, звпустили.вы на.виртуалке стартап, на нем три юзера. Потом подключаются гениальные маркетологи и закупают рекламу или размещают пост на хабре. У вас сразу лавинообразный наплыв юзеров. Сервис лег. Как с этим быть? Можно конечно лендинг разместить статикой отдельной от продукта. Но мало кто это делает
dezconnect
Эх, мечты мечты :)))
Fafhrd
В стартапе и сразу гениальные маркетологи? Реклама без консультаций с IT на mvp-серваки? Это должны быть такие же долбоящеры, как и разрабы из статьи. В плане рекламной кампании всегда есть цели и объём трафика, который кампания должна привлечь и если маркетологи не проконсультируются с IT, то в случае проблем будут оплачивать простой из собственного кармана.
axifive
У VPS тоже есть лимиты по трафику, и как с google cloud надо внимательно изучать что произойдет при достижении этих лимитов.
HiroX
Я не спец по VPS, но кмк у тех, что дороже $3 уже нет лимитов
Vilgelm
У большинства VPS условный безлимит, который стартап никогда не высосет. Но если даже что-то такое произойдет, то вам просто выключат сервер или снизят пропускную способность канала, а не выставят счет на 70 тысяч.
dominigato
Это лимит. Он есть всегда, просто вы иногда о нем не знаете.
Обычно в нормальных местах его указывают.
Vilgelm
Стартапу такой лимит вряд ли получится высосать. Но даже если и получится, к огромным расходам это не приведет.
dominigato
При чем тут стартап или не стартап? Как мы видим выше, это никак не зависит.
Попробуйте гнать видео стриминг с вашего впса и вы очень скоро узнаете свой лимит :)
Vilgelm
У меня сервера в OVH (в SoYouStart точнее). Это dedicated, но VPS у них тоже есть. Они заявляют безлимитный трафик. По факту я расходую в районе 15 TB в месяц, никаких проблем не возникало. Сколько надо потратить чтобы возникли проблемы?
dominigato
centralhardware
Ну да лимиты по трафику есть, однако если мы говорим не про aws/azure они достаточно большие, чтобы у покупателей не было шанса его истратить полностью (чаще всего). Само собой, если мы там поднимаен виделхостинг нам этих лимитов не хватит просто потому что на такое дешёвые тарифы на рассчитаны, если нужно много трафика то тут уже придется платить совершенно другие деньги, возможно совершенно другом людям
borisxm
У меня создалось впечатление, что часть нынешних исполнителей даже не знает, как все развернуть на VPS или локальном тестовом сервере.
BioHazzardt
ну так не модно же /s
А если серьезно, мне тоже не понятны такие заморочки, свой VPS всяко лучше будет, особенно когда проект на стадии прототипа и до продакшена еще как до Китая раком. И да, судя по описаным в статье ошибкам (сугубо мое мнение на основе прочитанного, ни на кого не гоню, и могу ошибаться) они и VPS без выстрела в колено поднять бы не смогли. Хотя с другой стороны, если команда из вчерашних студентов, толком порох не нюхавшех, то в принципе неплохой опыт, в следующий раз будут хотя бы мануалы внимательно читать
HEKOT
Согласен, но с другой стороны…
Вы же тоже «лезите» в русский язык. ;)
namikiri
Ну вы что, там линукс кокойта, разбираться надо, а мы стартаперы, дених хотим, мы инноваторы, а не задроты.
Arris
Было нечто похожее пару лет назад с Селектелом.
Запустилась по крону задача бэкапа одного раздела в облачное хранилища. В норме там совсем немного файлов и задача отрабатывает за минуту.
Но в этот раз что-то пошло не так.
Утречком выяснилось, что "все тормозит". Почему тормозит? Да потому что задача бэкапа работает. А что он делает? Ну, смотрю в логи и ничего не понимаю — вроде работает, вроде всё в порядке, но… что-то тут не то… Тормоза закончились через несколько часов, а я так и не понял, "что это было".
Когда обломался следующий бэкап, я полез в консоль селектела и обнаружил, что должен им что-то около 10к рублей.
О.о
И что это было?
А вот что:
Незадолго до этого я игрался с Vagga (система виртуализации, аналог докера) на этом разделе и Vagga мне создала в одном из своих служебных каталогов несколько миллионов файлов. И всё это поехало бэкапиться (в 5 часов утра, как полагается, когда я сладко спал).
PUT файла стоил совсем чуть-чуть (1.4 копейки, что ли, не помню), но их были миллионы.
Деньги на счету кончились довольно быстро, через полчаса. И по хорошему, доступ к контейнеру должен был бы отрубиться, а задача бэкапа вылететь с ошибкой, но...
… но почему-то доступ не отрубился. И файлы заливались, и заливались, и заливались в облако.
А счет все уменьшался, уменьшался, уменьшался...
Что произошло раньше — бэкап закончился или биллинг селектела опомнился, что деньги в минусе — я не выяснил.
В общем, после долгих, очень долгих дискуссий эту проблему признали сначала багом, деньги простили (уффф), а потом фичей. И сказали, что да, теперь это фича, теперь это нормально, теперь счета могут улетать в минус.
Странное решение, как по мне, но я не работаю в селектеле. Возможно, пока не работаю.
P.S. Потом там в рамках этой задачи что-то чинили, меняли, снова чинили, снова меняли, но счета по прежнему могут уходить в минус.
ky0
Пофайловые бэкапы в облако, ммм… Амазон, к слову, на грозном красном фоне в вебморде предупреждает, что перемещение туда большого числа маленьких файлов — не самая лучшая идея. Хотя это, кмк, понятно и без Амазона, в принципе — хотя бы элементарно за-tar`ить бэкап стоит.
Fox_exe
Скучаю по тем временам, когда за услуги надо платить вперед, предварительно закинув денег в «кошелек» сервиса (Откуда уже и идут списания).
saboteur_kiev
Все больше сталкиваюсь с мыслью, что в Google Cloud самое сложное это не знать как работают различные сервисы масштабирования, а уметь не влететь в долг.
tmin10
Да это справедливо со всеми облаками, нужно понимание того, что делаешь и умение расчитать цену полученного решения до запуска, а не по полученному счёту.
le1ic
Искренний совет: не пользуйтесь GCP. Да технологии там классные, но есть фатально сырые вещи, а поддержка абсолютно бесполезна. У нас например не работал и по прошествии пяти лет и бесчисленного количества багрепортов и личного общения с сотрудниками гугла не работает панель активности запросов к DataStore. В биллинге все есть, а активности операций нет.
Ну и когда у них большая авария, они сознаются в этом часа через два, и не преуменьшают скоуп. Я считаю это настоящим обманом. Так было в прошлом или позапрошлом году. У нас внезапно лег все тот же DataStore. У них все статусы были зелеными еще два часа. А на следующий день после расследования инцидента, они написали, что были затронуты некоторые пользователи compute & network. Про то. что целые сервисы не работали — ни слова.
devopg
привязал бы дебетовую карту, проблем бы не было.
то наберут своих кридитных…
vvzvlad
Вряд ли у него был лимит в $72к. Дело не в карте, дело в счете: если согласился на услугу, будь добр оплатить счет. Не можешь с карты — так идем в суд.
splix
Это не важно, для дебетной будет овердрафт, что еще дороже для платильщика
vassabi
для этого есть карты без овердрафа
splix
Я боюсь что Google Cloud не даст вам добавить такую карту в биллинг
urvanov
На сколько мне известно, любую дебетовую карту можно загнать в технический овердрафт. Даже если официально его нет. Идет все это из-за особенностей обработки платежей.
MaslovRG
Стал в принципе крайне негативно относится к всякого рода автоматическим подпискам. А уж хрень по типу "оказал услугу, а потом проверил баланс клиента" и "автоматически списал деньги после окончания бесплатного периода" должна быть запрещена и отключена по-умолчанию, а разрешатся только с двойного подтверждения клиента.
czz
Водоснабжение и отопление в квартире уже отключили? :)
MaslovRG
Думаю, я всё таки смог бы преодолеть свою лень и оформить двойное подтверждение на две эти услуги. :)
А больше я вообще никакими подписками не пользуюсь. Есть ещё, конечно, плата за интернет на мобильнике и компьютере, но: а) там отдельный счёт; б) при нехватке средств просто прекращается оказание услуги до пополнения счёта.
Vilgelm
Там или фиксированная плата, или счетчик работающий в режиме реального времени. И деньги списываются не автоматически.
czz
Все метрики использования ресурсов тоже идут в реальном времени (см. в статье совет «используйте мониторинг»).
А биллинг не реалтаймовый — за воду раз в месяц, за клауд — раз в сутки.
Если вы шланг от водопровода кинете в окно, и за день сольёте годовой объём воды, вам счёт так просто не простят, как гугл, а возможно и спишут «автоматически» через судебных приставов.
Vilgelm
На счетчике видно сколько использовано воды. Как я понял из статьи в GCP это не очень очевидно.
czz
Я не использовал GCP, но в Amazon AWS все достаточно очевидно — дэшборд с графиками по всем возможным ресурсам. Думаю, в GCP так же.
Но конечно, нужно осознавать, что такая проблема может возникнуть, чтобы вообще смотреть в этот мониторинг и настроить в нем какие-то алерты.
HEKOT
А, кстати, реальный случай произошёл со мной 1.5 года назад.
Я жил в другом городе. Жена собралась ко мне приехать. За день перед вылетом обошла дом (просто на всякий случай). Обнаружила нехилую такую утечку воды из водогрейного бака. Бак находился в самом дальнем конце, то есть, нужно было обойти три стороны дома, и мы там не появляемся почти никогда.
Позвонила мне. Я так прикинул, что у нас обычно течёт литров до 9 в минуту, а цена тонны воды $3.5. Если оно продолжается хотя бы неделю, то…
Короче, повезло ОЧЕНЬ. Судя по счёту, протечка началась за несколько дней до осмотра. Признаться, я с большим удовольствием оплатил счёт в несколько лишних сотен. Ну и с не меньшим удовольствием купил новый нормальный проточный нагреватель на газу, гораздо более экономичный, чем это электрическое накопительное убожество.
НО: в моём случае, всё же, я имею возможность и счётчик наблюдать в любой момент времени без задержки, и визуально протечку обнаружить, и кран перекрыть. СМ другой стороны, автоматизировать мониторинг малой кровью не получится. Это «сделай сам» надо какой-то.
sumanai
У меня они к примеру безлимитные ))
czz
Тогда вы можете построить небольшую ГЭС и майнить крипту на бесплатном электричестве :)
v1000
Неплохо-бы для компаний, предоставляющих услуги, дать возможность поставить лимиты и «жесткие лимиты». И если в первом случае получать сообщения при превышении счета, то во втором услуга отключается принудительно, если для клиента важнее сохранить деньги, чем бесперебойность сервиса.
EviGL
Как-то не по себе сейчас стало за тестовый GCP аккаунт, который я был вынужден создать, чтобы протестить работу Speech To Text API от гугла.
pae174
Те, кто за два дня до демы велосипедят костыль, в пятницу вечером без тестирования ставят его сразу на прод и идут спать, должны страдать.
mrguardian
Супер прохладная история. Доки гугла отличные? Так почему вам потребовалась ночь чтобы разобраться в них? Или почему вы изначально не поняли, что и как работает. Да потому что нет у гугла никаких замечательных доков, сплошной маркетинговый булшит в скудной админке, где они оперируют в большинстве своем какими-то собственными понятиями, документации по которым просто нет. Ну и вот это желание постоянно пользоваться мифическими рубильниками, не разбираясь в них — это вот просто верх безответственности в IT. Да лучшеб вы сами все написали, чем пропагандировать такой идусский подход к разработке..
olekl
По идее гугл бы эти деньги все равно не получил, т.к. стартап бы просто объявил о банкротстве и все… А так еще им и спасибо сказали за в общем-то их собственный фейл…
Saiv46
Я с подругой как-то решили накатить прототип виртуальной платёжной системы, однако из-за кривой настройки SQL-сервера "намотались" на >400$ долга (ушли в летний отпуск и за биллингом никто не присматривал, но часть всё же простили) и платёжный аккаунт оказался заблокирован после нескольких неудачных попыток снять что-либо с карты, а потом и саму карту в сервисах Гугл заблокировали из-за подозрении в "мошенничестве".
Всё бы ничего, но с той же карты оплачивался App Engine для других проектов, а также продлялись домены в Google Domains — всё это пошло коту под хвост. Не ложите все яйца в одну корзину, даже если таким образом дешевле.
Dimaaasik
Рад что всё закончилось хорошо, но блин иначе и быть не могло т.к. если бы GOOGLE не простил этот счёт то автор пошёл бы в суд и без проблем выиграл дело может быть ещё и моральную компенсацию мог получить)
glendanzig
В РФ такое бы не проканало. С тем же Яндексом (знаю по своему горькому опыту)…
seraz
багованый недософт с красивой +- оболочкой запустили где-то на облаках. если б оно работало на вашем серваке, и все начало тупить, ибо ссд/нагружен на 99+%. то на этом история текущей альфа-бета версии благополучно закончилась.
atri1
локально на одной видеокарте можно обрабатывать по 100+ миллионов запросов в секунду(если БД разместить в GPU)
ничего личного, впечатления от статьи что "команда ламеров ковыряет эти ваши компустеры"… через слово "я ни понимаю что происходит ааа"… +байт на "большие цифры денег"(для читателя)
kanvas
ZIP-бомбу тоже можно открывать в облаках Гугла?
amarao
Именно по-этому у меня сильная предвзятость к post-paid сервисам с "сложным биллингом". Если бы там был честный prepaid, их бы рубанули через 5 минут и они спокойно разбирались бы куда 7 баксов делось. Ну, или 100. Но не 60+ бесконечностей.
anonymous
От этой статьи возникает 3 мысли:
1) Сервисам нужно ограничивать объем ресурсов. А то можно завести аккаунт на бомжа с которого нечего взять, и выполнить расчёты хэшей криптовалюты. А если у этого бомжа 100 аккаунтов и 100 карточек, то можно обеспечить ему жилье в рамках благотворительной программы от Google, о которой сама компания не знает.
2) Надо быть внимательнее при работе с ткаими ресурсами.
3) Такая опасность делает сервисы менее полезными для разработчика. Одно дело, когда неправильная программа вдруг зависнет или посчитает не то — ну и ладно, поправлю. А при таких рисках надо всё более внимательно отслеживать заранее, то есть падает скорость разработки.
4) По-хорошему за найденную возможность использовать ресурсов больше, чем лимит на 4 порядка надо не счета выставлять, а давать премию по Bug Bounty, пока такие вещи делаются случайно, а не преднамеренно.
denisshabr
>>У POST-запросов могут быть одни и те же URL. Если есть обратная ссылка на предыдущую страницу, то сервис Cloud Run застрянет в бесконечной рекурсии
Ну всё логично, индус написал индусский код.
>>9 000 000 запросов в минуту
Хороший ddos.
rustamaha
И сколько стоит проскрапить весь интернет? Самое интересное не написали.
zartarn
У амазона «micro», раньше, не знаю как сейчас, через год переводится автоматом на платный тариф, и прилетает уже счёт сразу.
VolCh
И довольно долго время не отключается
alexhott
Был у меня провайдер кабинет — работал через раз, но начислял исправно.
Сменил его на билайна, написал во все места кабинету, что отключаюсь от них и прошу расторгнуть договор, но идти в офис расторгать договор мне было в лом.
Кабинет еще два месяца начислял мне плату, потом таки отключил услугу(хотя по факту провод висел в воздухе). Писал и звонил мне полгода — на что я отвечал что услуга не оказывалась. В итоге перестали мне о себе напоминать.
Потом был МТС с интересным подарком в -500 рублей, Акадо и Ростелеком с точной копией истории кабинета и все сами рассосались, так как начисляли я считаю несправедливо и пойди они в суд с иском за не оказанную услугу скорее всего песперспективно.