Comments 166
Клиент может залезть в долги, хостер может поднять панику и всеми доступными способами предупредить о проблемах, о возможных дополнительных тратах, но без ведома клиента ничего удалять не должен, если это не домашний проект студентов, развлекающихся оверселлингом тормозных VPS на домашнем компе, с арендной платой 1 бакс в год.
На Хабре публиковали историю о том, как у человека взломали аккаунт AWSb запустили тонну майнеров на самых мощных VPS. Amazon поднял тревогу, но ничего не удалял без ведома владельца. В итоге долг вырос был порядка 10 килобаксов и она даже простили клиенту эти деньги. Но никаких автоматических удалений иотключений всего и вся не было.
У них какая-то упоротая система расчёта за скачивание.
Верно, она долбанутая, но надо было читать перед тем, как пользоваться. 200 баксов это копейки в сравнении с тем, во что могло вылиться, если бы скачали на скорости 100Мбит или 1Гбит с сервера.
Вот есть гугл диск 1тб за 10/мес, есть похожее от дропбокса. И вот вам открывается хранилище по цене нескольких долларов за терабайты. Так что ли?
А у меня AWS списал 200 баксов за то, что я скачал с Glacier-а несколько десятков гигабайтов. Чтобы понимать масштабы, до этого я там хранил эти гигабайты несколько лет и заплатил несколько баксов. У них какая-то упоротая система расчёта за скачивание. Я им написал, нифига они мне не простили.
Почему Амазон должен быть виноват, что вы не прочитали их тарифов?
Почему они должны были простить вам осознанно полученную от них услугу?
2015-07-21: Free Tier на год
2016-09-03: Мы тут счёт выставили на 18,12$
2016-09-16: Мы не можем снять деньги с вашей карты, проверьте.
2016-10-21: Мы так и не смогли снять деньги, будем блокировать аккаунт.
2017-01-03: Мы пока ничего не заблокировали и выставили ещё один счёт.
Письма о блокировке не было.
2018-01-28: В биллинге 82,11$ неоплаченного t2.micro. Написал в саппорт пространный запрос вида «аккаунт использовался только во время бесплатного тестового периода»
2018-01-29: Спасибо что вы с нами! Аккаунт разблокирован, 5 счетов на 82,11$ отменены.
На третий раз я пропустил письмо и заблокировали весь аккаунт. При чем, с концами, продолжая списывать за виртуалки деньги. Приходили и ответы «issue resolved» и звонила какая-то русскоязычная барышня с британского номера, спрашивала, чего я перестал пользоваться, обещала все разрулить. Раз 5 за полгода звонила и писала, я отправлял все детали. Кроме обещаний, что все будет хорошо, ничем не закончилось.
В общем, хорошо что к тому моменту на Амазоне лежали только бекапы и мы оперативно могли забекапиться в другое место.
Но стало уроком — больше никаких критичных сервисов у крупных американских хостеров или регистраторов, где роботы вместо саппорта и клиентов столько, что на каждого отдельного из них более, чем плевать.
(люди из саппорта подтвердили что решение принимал робот сам, но руками отменить его решения, видимо, не могли).
Проблема не столько в этом, сколько в том, что продолжались списываться деньги (хотя все было выключено), саппорт отвечал раз в сутки и ничего не мог сделать. Равно как и та барышня, которая мне названивала уже после того, как я заблокировал карту и забил на этот Амазон.
Бумажка может защитить от бюрократа. Бумажка никогда не защитит от пули или взбесившегося робота.
Что делать, если владелец карты в отпуске и недоступен в течение трёх дней? Мы потеряли бы всё — годы работы — миллионы долларов дохода.у людей вообще нет бекапов, они не слышали что такое Disaster recovery и что в ДЦ может таки ударить молния :)
А с существующими тулами, аля terraform/chef/ansible у них просто обязан быть стек, который развернет полностью инфраструктуру за считаные минуты/часы и восстановит из бекапов. Которые просто обязаны храниться за пределами GCP.
А в результате виноват Google. Они конечно те еще редиски, но тут явно проблема в ИТ организации у данной компании, имхо
И вот когда Вы их увольняете оказывается что все это была не правда)
Разве мы переплачиваем за облака не для того, чтобы проблемы отказоустойчивости ложились на них?Нет, с таким же успехом можно перекладывать проблемы бекапов на рейды. Встречал не мало людей, которые были уверены, что raid1 спасет в любой ситуации, а бекапы для слабаков. Естественно жизнь их потом наказывала.
Аналогично и с облаками, не надо думать что в облаке все за тебя делают какие то мифические эльфы. Облако позволяет избежать большинства проблем с железом и как правило абстрагирует тебя от аппаратной части, оставляя лишь программную, но это не значит, что если ты запустил виртуалку в облаке, то она каким то чудом будет бекапится и при любых проблемах сама восстановится.
Тот же Amazon постоянно предупреждает — делайте бекапы EC2 и проверяйте возможность их восстановления, ибо машина в любой момент времени может стать недоступной, от слова совсем.
А с существующими тулами, аля terraform/chef/ansible у них просто обязан быть стек, который развернет полностью инфраструктуру за считаные минуты/часы
Без сарказма и иронии, но как пользователю тех самых terraform/chef/ansible интересно: ОК, грохнули вам GCP аккаунт. Все ваши роли/рецепты написаны под GCP. Как вы в течении минут (ну — ок, часов ещё более-менее приемлимо) развернёте всё в AWS? Ведь всё-равно придётся переписывать их.
Или речь о том, что бы выкатиться на новый аккаунт в GCP?
Или речь о том, что бы выкатиться на новый аккаунт в GCP?Как минимум стек должен быть настроен на того же провайдера. Т.е. да, создали новый аккаунт и восстановили. В нормальных фирмах у вас будет просто два разных стека — один для aws, второй для gcp. Тот же terraform/ansible намного лучше поддерживают aws, чем gcp, по понятным причинам.
Естественно, если у вас тераформ был только под GCP, а вам говорят — давай подправь немного и запустим на AWS, то это полностью бессмысленно. Ибо отличий будет просто громадное множество и в разумные сроки вы не уложитесь.
Речь идет именно о создании инфраструктуры (vpc, security groups, elb, s3, iam и т.п. вещи ), а не о провижионе. Во втором случае, как правило, нет такой жесткой привязки к провайдеру, ибо тот же chef/ansible будет одинаково отрабатывать что на EC2, что на GCE.
Им суппорт потом посоветовал сделать энтерпрайзный аккаунт, так как там это работает по другому.
Не знаю, что именно по другому, но если миллионные обороты, то наверное логично.
Когда менял банк, то от Amazon пришла просьба проверить настройки биллинга, без всяких угроз, что все немедленно выключат и все удалят. Однажды был случай с DO, когда в тестовый VPS, незащищенный и с открыто торчащим 80 портом подсадили спамбота через эксплоит и техподдержка попросила меня принять меры. Я был не у компьютера и попросил их грохнуть этот VPS, на что они мне ответили — так мы не работаем, ничего по просьбе клиента не удаляем — разберитесь сами. Пришлось логиниться в админку со смарта.
То есть ни IT-гигант, ни лоухостер — ничего сами с моими данными и виртуалками не делали. Даже прямо отказывались это делать. А Google вот так запросто все отключает на автомате? Однако…
В договоре есть пункт о том, что данные могут быть удалены, если оплата поступать не будет. Но никто их нормальных хостеров не блокирует все автоматически через секунду после того, как от банка приходит ответ, что с картой проблемы.
Недавно видел видик: один блоггер шлялся где-то по Америке, и оказался где-то очень далеко от цивилизации. Встретил полицая и попросил его довезти куда-нибудь до любого города. Тот согласился, но для «вашей же безопасности» одел ему наручники, и посадил за решётку. А то мало ли что…
Оно, конечно, да — всё может быть. Но вот так вот заботится о моей безопасности? А можно я сам?
Но так как большой и жирный монополист, возможно далеко не всегда. Пойди обойди Google Play если рынок Android интересен.
"Наш робот посмотрел вашу слёзную апелляцию и решил ничего не делать".
Вероятно они были так любезны потому, что у меня был платный аккаунт и вопрос касался денег, а не проблемы с бесплатной почтой. Хотя в статье тоже не о бесплатном гмейле речь идет.
Походу, контора из статьи — попала под какого-то нового робота, которого запустили не протестив как следует.
— как админ Google Apps for Your Domain (платного но мелкого) пишу запрос на тему почему у юзера поиск работает криво (именно google.com который, были подозрения что с Apps там конфликт) — объяснили все (по сути — ошибка пользователя).
— Жалобы на фиг-поймешь-это-баг-или-фича Google Play Books (на тот момент были купленные книги) — ну по крайней мере ответили и объяснили (в стиле 'оно работает ТАК и все тут потому что...') но все же
— Жалобы на покупки в Play Store (не приложения) и отказ автоматического возврата — вернули успешно.
Вот опять же подозреваю что важно что вопрос касается денег.
Я так недавно, внезапно, и, честно говоря, не сразу то и заметил, что у меня больше нет аккаунта на Youtube. Я не блоггер, я с другой стороны.
Когда стал разбираться, то узнал, что обвинен в нарушениях принципов сообщества. Без предупреждений и шансов на аппеляцию. Я, честно говоря, не ожидал такой "клиентоориентированности".
Забить то я забил, но вот перспективы… завтра они решат отключать андроидофоны, гугломобили, фитнес-браслеты, а послезавтра кардиостимуляторы? Однако.
На этом фоне пугает зависимость от gmail. С другой стороны, а где ещё такой удобный веб-интерфейс с кучей расширений...
В своё время меня тоже разочаровался зависимостью от Gmail и других бесплатных почтовых сервисов и зарегистрировал свой домен за небольшие деньги.
Со временем перевёл все регистрации на новую почту и поставил пересылку с Gmail на свой домен.
Конечно, попал в зависимость от регистратора, но и его можно поменять в случае чего, сохранив домен и почту.
Зависимость от почтового сервиса огорчает потому что слишком много учёток в других сервисах завязано на него и потерять всё разом не хочется из-за решения ИИ Гугла.
Честно говоря, я в этом полный ноль. Мой потолок это сделать сайт в конструкторе гугла, который и хостится на sites.google, зарегистрировать домен и настроить переадрессацию.
Всё что сложнее уже потребует уделить существенно рабочего времени на изучение. :(
удобный веб-интерфейс
IMHO, на любителя.
А zoho не пробовали?
Я часто пишу письма с формулами, и для gmail есть расширение, которое перед отправкой письма находит в нем все LaTeX вставки, рендерит их, и вставляет в текст письма формулы. Мне очень удобно. А есть что-то такое для zoho?
Не смотрели на Markdown Here? Он универсальный.
Ну и плюс — отличная иллюстрация «надежности» облаков и хваленых ИИ (Искуственный Идиот).
Проблема в том, что автор по счетам компании платит кредиткой физлица — ну, это как минимум немного странно…
Я не очень уверен, что в этом проблема. Возможно, Вы делаете предположение базируясь на российских реалиях (и принимая во внимание карточки, выпущенные российскими банками). Если очень сильно обобщить мои собственные наблюдения, то пока в компании на постоянной работе (то есть — не контрактники) не начнут работать десколько десятков (или даже сотен) сотрудников — никто не будет заниматься «бизнес» кредитными карточками.
Я не знаю реальных чисел (и правил со стороны Google), но предполагаю, что когда месячные затраты компании клиента превысят тысяч десять (на GCP), то можно думать об отдельных договорах. А до десяти тысяч в месяц — вряд ли будут проблемы со стороны кредитной организации… Ещё раз оговорюсь — моё личное мнение.
Так это работает во всем мире.
Насколько я знаю (и видел) — не совсем так. И не всегда. Только если суммы большие — десятки тысяч… (и регулярно) Всё что меньше — можно платить с кредитных карт. Потом бизнес возвращает эти деньги тому, кто заплатил. Только чек (или инвойс) нужен. Причём сгодится даже расписка написанная карандашом на клочке бумаги.
… оплачивает по безналу
Насколько я знаю — наличными никто не сможет заплатить Google… Правда я не работаю в Google, и могу сказать точно — везде ли так. Может в России свой путь…
Насколько я знаю (и видел) — не совсем так. И не всегда. Только если суммы большие — десятки тысяч… (и регулярно)Для возмещения работодателем — да. А для того, чтобы банк или платежная система не посчитали транзакцию подозрительной (что, возможно, случилось с автором поста), достаточно меньшего (по крайней мере, в некоторых странах). Я когда переехал в Лондон, попытался купить много (ну как много, на несколько сотен фунтов) мебели на сайте местой IKEA, расплатившись свежеполученной зарплатной картой — карту заблокировала платежная система, пришлось перевыпускать. Пообщался с товарищами — из трех попыток три блокировки.
При привязке карты много где могут возникнуть ограничения — например по типу/виду карты, в правилах конкретного банке, в ваших настройках платежей с карты(большинство об этих настройках не знают), в жесткости правил приема карт Амазоном, в государственности(тот-же Крым/США), не совпадения страны выпуска карты/вашей локации/введенных настроек на Амазоне и т.д. Наверное несколько проще привязать на Paypal, а потом платить с него.
Бекап и локальные\резервные ресурсы как план Б тоже не проработаны?
Данный пост — очередное доказательство того, что как хостер бы не был надежен, всегда возможны неожиданные проблемы, технические или административные.
А предположите такой вариант, что пришла информация, что этой карточкой пользуется террорист пришла разнарядка всё блочить.
И разнарядка то отчасти правильная — на этих серваках, допустим, может хоститься что-то что будет отвечать за взрыв бомбы.
Тут как бы первая реакция всё отключить и не важно какими способами…
Так что прежде чем ругаться с гуглом необходимо, как минимум, разобраться до конца в ситуации. Например, позвонить в банк и спросить почему они выдали гуглу информация, за которую вас заблочили, если я правильно понял ситуацию.
Я всего лишь привёл пример ситуации, когда блокируем всё здесь и сейчас является правильной и применяемой политикой, всё таки терроризм не экзотика в наше время. (Не надо меня приписывать к сторонникам всяких законов Яровой и прочее — лично моё мнение с текущим регламентом это куча бесполезного железа, которая не поможет ни один терракт предотвратить)
В любом случае в тексте никак не упоминается сторона банка. Как бы гугл начал почему-то блочить, возможно, банк передал ему эту информацию, может стоит поинтерисоваться в банке что же они такого выдали гуглу…
вы кредиткой оплачиваете десятки хостингов, облаков и прочего?
И компенсировать никто ничего не будет)
Здравствуйте блокировка телеграмма, здравствуйте анб в США и прочие вещи…
В большинстве случаев всем будет пофиг.
Более того — когда у меня вдруг есть свободное время — я готов даже что-то активное делать, могу присоединиться к негативным отзывам, могу позвонить и в 100500й раз поинтересоваться «ой, а я слышал вы клиентов кидаете, как вы это прокомментируете?», могу поискать на досуге конкурентов и перейти к ним, могу на митинг сходить и весело поорать «долой царя» и денег организаторам подкинуть.
трафик, историю запросов и посещений и т.д., (равно как логи СМС, звонков и даже сами звонки), у нас провайдеры /операторы обязаны хранить аж до 25 лет (на каждые данные свой срок), при чём уже более 10 лет как.
При чём, когда это вводили, то обязали не только провайдеров, но и, частично, хостеров. Хотя по провайдерам это, разумеется, ударило сильнее всего (расходы) – в следствии чего мелкие перестали существовать (в основном посредством скупки их за гроши, и даже сейчас, порой, крупные уходят с рынка (тенденция на становление общих «телекомов», предоставляющих «полный спектр коммуникационных услуг», включая телевидение)
Но в данном случае — поздно не будет?
Профилактика дешевле лечения, как правило.
Ну и классическое «когда они пришли за мной...»
Не надо меня приписывать к сторонникам всяких законов ЯровойНо, согласитесь, аргументация на 100% совпадает с аргументацией закона Яровой.
«Зачем вы нагадили мне под дверь?» — «А вы что, хотите, чтобы совершались терракты?! А может, вы ещё и педофил??!!1»
Попытка использовать терроризм или ЦП как аргумент — это плохая практика. Пока что история имеет много примеров использования чего-то что предназначено для борьбы с терроризмом не по назначению, и очень мало историй использования по назначению.
Cloud native подразумевает, что cloud — это коммодити. Если cloud — это божественный провайдер без замены, то это Lord of the pets, а ничуть не cattle.
Например, есть github.com/robertpeteuil/multi-cloud-control
Для того, чтобы получить стандартизированный интерфейс, нужно использовать наибольший общий функционал, игнорируя все value added фичи каждого конкретного провайдера.
Видимо вы не в ту страну ездите или ножками попробуйте.
Ну я попробовал. Но у меня гугл аккаунты старые, еще до привязки телефонов. Пустило без проблем, сгенерило письмо вида «тут к вам заломились, если это вы — тыкните в эту ссылку». Тыкнул. Все работает.
Привязанный телефон не работает конечно.не в защиту гугла, но про Google Authenticator «не, не слышал»?
после активации оного можно не только авторизоваться без активной симки, но и создать бэкап-коды, на случай отсутствия доступа к самому аутентификатору (правда, если несколько раз подряд их использовать из разных мест – я проверял – запросит таки авторизоваться либо через СМС, либо через звонок, либо через аутентификатор)
при этом аутентификатор, разумеется, можно поставить на несколько устройств (это классический хеш-скрипт на основе key+date)
я уже много лет пользуюсь и связь по телефону (вариант только смс/звонок) он спросил всего однажды, недавно, при попытке изменений настроек безопасности.
В Росссии до сих пор существует система диспетчерского управления энергопотоками — именно потому, что требуется надежное управление.
А тут — все отдали дяде, который может что-то вдруг нарешать. А отвечать за многомиллионные убытки будет кто — Гугл? Нет? А кто? А чем он думал? Что «всетакделают» и «авосьпрокатит»? Ну вот, не прокатило. Немного предсказуемо.
Извините за бурчание )))
Если считать, что Google Cloud Platform — это аппаратно-программный комплекс, решающий определенную жизневажную задачу в продукте, и подходить с точки зрения разработки критически важных систем, то получается, что облачная инфраструктура с одной стороны снижает вероятность отказа по причинам неисправности оборудования (диски, хранилища, серверы и пр.) но с другой стороны увеличивает вероятность отказа по административным причинам — блокировок сервисов, биллингов, провайдеров, да и вообще интернета.
В итоге заветные 5 девяток доступности(5 минут даунтайма в год) все равно не получить, как ни крути, кроме, ессно, либо получения ентерпрайзного эккаунта с соответствующими гарантиями, либо, как принято в ответственном железе — полного дублирования функциональности, причем на полностью другой платформе, чтобы вероятность одновременного выхода из строя обеих систем была минимальной.
И это надо было планировать с самого начала разработки при выборе платформы.
Удалили сервер (без моего подтверждения). Но самое смешное, что бэкапов у них нет, поскольку они не хранят личные данные клиентов.
Куда жаловаться на таких хостеров и их неадекватную техподдержку?)
Юрий Дейгин: Вы упомянули богатых русских, а также людей, которые думают, что могут и сами попробовать победить старение. Можно ли отнести, например, основателя Google Сергея Брина к таким людям, которые решили, что все сами могут, и даже основали компанию Calico именно с этой целью?www.colta.ru/articles/specials/18586
Обри де Грей: У меня было смутное предчувствие, что вы спросите меня об этом, Юрий. Что ж — отвечаю. Я очень низкого мнения о Calico. Основная причина — это Ларри и Сергей. Справедливости ради отмечу, что, как я понимаю, Calico — это в основном Ларри Пейдж. Но так как в совет директоров входят оба, то и оба несут ответственность. Calico — это катастрофа, и это целиком и полностью их вина. При этом Сергей и Ларри прекрасно меня знают и в любой момент могли сказать: Обри, слушай, мы не любим благотворительность, но хотим создать компанию и просим тебя ее возглавить. Я бы сказал: нет проблем. Но они этого не сделали. Не знаю — почему. Возможно, им не нравятся люди с бородой. Начали они более-менее разумно — наняли Артура Левинсона, лучшего в мире биотехнологического гендиректора. Но вот чего они не сделали, так это не сказали ему, что делать дальше. Поставили задачу — вылечить старение, но у Артура не было ни малейшего представления о том, как делается. Поэтому он нанял директором по науке Дэвида Ботштейна, фундаменталиста, фантастического ученого и исследователя, который вообще не разбирается в технологиях. Он сам публично заявлял, что у него нет ни одной прикладной косточки в организме. Неправильно нанимать такого человека для решения технологической проблемы. Сейчас они занимаются исследованиями, которые со временем помогут лучше понять механизмы старения, но никак не смогут повлиять на то, чтобы люди могли оставаться здоровыми и, следовательно, живыми как можно дольше.
Юрий Дейгин: Почему так мало людей понимает срочность проблемы? Что нужно сделать, чтобы борьба со старением уже сейчас стала во главу угла?
Обри де Грей: Тут два ответа. Первый — Дэвид Ботштейн и Calico. Люди генерируют вопросы, ответы на которые порождают новые вопросы. Цель фундаментальной науки заключается в том, чтобы создавать новые вопросы, а не использовать ответы для гуманитарной пользы. Фундаментальные ученые не возражают против гуманитарной пользы, но они не считают ее своей задачей. Ботштейн — фантастический ученый, но находится не на своем месте и не на своей должности. Другой ответ порожден вопросом: почему люди вообще не чувствуют срочности в отношении к проблеме старения? Не забывайте, что все мы выросли с мыслью: старение неизбежно. Остановить старение — это как попытка создать вечный двигатель! А если вероятность изменить что-то нежелательное равна нулю, тогда и желательность больше не имеет значения. Исходя из такой логики, действительно лучше выкинуть из головы всю эту чепуху и продолжить проживать свою ужасно короткую жизнь.
Юрий Дейгин: То есть это, по сути, выученная беспомощность?
Обри де Грей: Да, выученная беспомощность, и вполне разумно так рассуждать, пока нет плана решения проблемы. Плана, который бы демонстрировал, что мы не так уж далеки от триумфа. И такой план появился! Конечно, предстоит еще гора работы, чтобы убедить людей, что борьба со старением уже перешла из области чисто исследовательской в область прикладную и технологическую. Но мы уже поднялись чертовски высоко! Изменился сам характер дискуссии, изменился тип людей, готовых нас слушать. Ученые с регалиями, имеющие репутацию, которую они щепетильно оберегают, готовы принять наш подход. Пятнадцать или даже десять лет назад мы не могли и мечтать о таком научном консультативном совете, который есть у нас сегодня. Тридцать человек, мировые лидеры в своих областях — и все они абсолютно четко согласились с тем, что «исчерпывающий ремонт повреждений» — разумный подход и у него есть действительно хорошие шансы победить старение.
Ладно хорошо пишу в поддержку — золотые мои — ну, что там не так? Стандартная отписка сходите и сами поищите, типо бот занят ему не до Вас.
В общем в этой истории меня возмутил сам подход сначала удалить апп, а потом клиент типо сам расчухается, что к чему.
Но по существу, сам виноват. Возможно тут тоже у клиента рыльце в пушку, а он всю правду не рассказывает.
В целом gcp работает лучше и отзывчивее чем aws. Но с поддержкой у них беда. И будет еще хуже с внедрением ai ;((
Странно держать многомиллионный бизнес на клауд платформе.
Даже если клауд провайдеры "мамой клянутся" что у них там все перезащищено, бэкап держать надо, да и при наличии it штата, возможно проще хостить все у себя. Всегда думал, что клиенты клауд провайдеров, это либо мелкие it компании ( на начальном этапе выгоднее заказать, чем пилить свое), либо компании бизнес которых, не особо завязан на it.
Странно держать многомиллионный бизнес на клауд платформе.
Ничего странного.
Но вот на одной единственной платформе — это да.
Опять таки при определенном размере IT компании дешевле держать инфраструктуру у себя, нежели постоянно кому-то платить.
Это к утверждению «при определенном размере IT компании дешевле держать инфраструктуру у себя». Правда в облаках другие риски появляются в том числе не сильно афишируемые навроде буржуйских санкций. Чпок и вся твоя инфраструктура превратилась в тыкву. :) Классика жанра: богатые тоже плачут.
Опять таки при определенном размере IT компании дешевле держать инфраструктуру у себя, нежели постоянно кому-то платить.
А при определенном — дешевле платить за аутсорсинг.
Тем более, что если фирма не ИТ-шная, занимается другим направлением.
P.S.:
Полноценно развернуть и поддерживать платформу состояния постоянной готовности, с репликациями, серверами заменяемыми на горячую — это ой как не дешевый аналог получится.
Почему не следует пользоваться Google Cloud