Что гуглят девопсы
Забавный запрос получился)
Краткий перевод: Ок, гугл, как по-быстрому к куберу подключить диск?
Забавный запрос получился)
Краткий перевод: Ок, гугл, как по-быстрому к куберу подключить диск?
Прошу помощи, не могу оплатить Amazon, карты РФ не принимает, других к сожалению нет, может у кого нибудь есть возможность оплатить со своей карты? Или вдруг знаете как быстро оформить забугорную карту для оплаты? С меня пицца😃
В 2018 году Amazon развернула кампанию, которая должна была спасти её репутацию в глазах потенциальных сотрудников и общественных деятелей из-за критики безопасности и условий работы на её складах, пишет FT со ссылкой на источники, знакомые с ситуацией.
Работники складов Amazon прошли специальный курс о том, как реагировать на критику компании в соцсетях. Они должны отвечать «прямо, но вежливо» на публикации, которые компания считает неправдой, писал в 2019 году The Intercept со ссылкой на внутренний документ.
Скриншот одного из сообщений на Twitter: «Условия труда на моём JAX2 (складе) отличные. Есть контроль температуры, безопасность в приоритете, и мы просто хотим доставить ваши посылки вовремя».
Неизвестно, сколько всего существовало таких учётных записей. В августе 2019 года Bellingcat зафиксировал около 50 похожих аккаунтов в США и Европе.
Amazon отказалась от кампании в конце 2021 года и удалила все сообщения сотрудников в соцсетях. По словам источников FT, компания оказалась недовольна эффективностью такой схемы по привлечению новых сотрудников. Кроме того, некоторые заводили сразу несколько поддельных аккаунтов, чтобы написать больше положительных отзывов и получить больше денег.
В прошлом посте (Отказы ИС 1. Amazon (DynamoDB)) был описан отказ БД DynamoDB из-за ошибки службы управления метаданными. Однако отказ сбоем только в DynamoDB не ограничивается. Ниже описаны проблемы смежных сервисов Amazon.
Simple Queue Service (SQS). На ранних этапах сбоя DynamoDB, SQS работал с повышенным фоном ошибок и с немного большей задержкой. Amazon SQS использует в своей работе DynamoDB для хранения очередей. Когда информация об очереди закэширована в SQS и не доступна напрямую для API непосредственной отправки/приема сообщений, кэш часто обновляется, чтобы корректно отразить операции создания, удаления и изменения, выполняющиеся в инфраструктуре Amazon. Когда DynamoDB перестал блокировать трафик в 05:45 PDT (с тем, чтобы дать возможность сервису метаданных восстановиться), SQS не мог считывать данные из БД, что привело к значительному повышению фона ошибок. Когда в 07:10 PDT трафик стал восстанавливаться, сервис очередей восстановился, данные в очередях в результате инцидента потеряны не были.
После инцидента сервийс SQS был доработан с тем, чтобы он не создавал ошибок даже в случае, когда сервис метаданных неоступен.
EC2 Auto Scaling. Между 02:15 и 07:10 API сервиса отдавала большое число ошибок. С 07:10 до 10:52 в EC2 наблюдались существенные задержки при выполнении нового подключения, либо отключении старого. Уже имевшиеся подключения продолжали работать корректно в течение всего инцидента.
Сервис хранит в DynamoDB информацию о группах и конфигурацих запуска. С момнета начала инцидента EC2 не мог обновлять внутреннюю таблицу данных при вызове его API. Когда DynamoDB было восстановлено, началось восстановление работы сервиса, которое не было закончено из-за накопившихся за время инцидента не обработанных активностей. Запуск и остановка сервиса осуществляется в фоновых процессах. В течение инцидента накопилось большое количество активностей, связанных с вышеупомянутым фоновым планировщиком. Эти процессы обрабатывались до 10:52.
Помимо мероприятий, сделанных командой DynamoDB, заключавшихся в обеспечении быстрого восстановления при образовании большого лога необработанных запросов, Amazon также изменил подход к разделению работ над серверами EC2 (чтобы большее их число можно было выполнять в параллельном режиме), внедрил механизмы удаления старых активностей и увеличил мощность серверов для обработки запоросов.
CloudWatch. Начиная с 02:35 сервис метрик Amazon - CloudWatch, - начал регистрировать задержки, отсутствие метрик EC2, а также возросшее число ошибок. CloudWatch использует внутреннее хранилище для добавления информации о членстве в группе автомасштабирования во все входящие запросы сервиса EC2. С 02:35 до 05:45 ошибки в DynamoDB обуславливали нестабильный доступу к метрикам EC2. CloudWatch также заметил ненормально низкую активность метрик других сервисов, использующих DynamoDB, усугбляя проблему доступа к метрикам.
Далее примерно с 05:51 до 07:10 CloudWatch сообщил о значительно возросшем фоне ошибок вызовов API сервиса PutMetricData, что влияло на все метрики Amazon, а также метрики, созданные пользователями. Ошибки были связаны с доступом к данным о членстве, упомянутым выше. Сервисы CloudWatch восстановились к 07:29.
Для уменьшения влияния DynamoDB на CloudWatch Amazon уменьшил размер пакета до минимально возможного. Также в разработке сервисы быстрой доставки метрик за счет сквозной записи кэшей. Этот кэш должен предоставить возможность получать метрики без их ее сохранения. Кроме того он обеспечит большую защиту данных.
Console. AWS console также работала не стабильно у некоторых пользователей между 05:45 и 07:10. Пользователи, уже зашедшие в консоль оставались подключенными к ней. Те же, кто пытался войти в систему сталкивались с высокими задержками при входе. Это связано было с высокими задержками API, полагавшегося на DynamoDB. Для успешного входа вызов к этому API не обязательно должен пройти без ошибок, но из-за большог таймаута, этот запрос, блокировал процесс входа на десятки секунд.
Таймаут запроса уже был уменьшен и отправлен на тестирование. К сожалению, до начала инцидента новая версия консоли еще не была обновлена на релизе.
P.S. Сбой в системе хранения затронул большое число сервисов, однако, выше приведены основные - т.е. те, которые Amazon сам посчитал таковыми.
Общие сведения о DynamoDB. DynamoDB хранит информацию в таблицах, разделенных на части (разделы), в каждой из которых содержится часть всей информации в БД. Эти разделы распределены по множеству серверов для обеспечения быстрого (с малой задержкой) и постоянного доступа к хранящейся информации, а также для целей репликации данных.
Принадлежность разделов к конкретному серверу называется "членством" (membership). Членство некоторого множества таблиц/разделов в рамках одного сервера управляется внутренней службой управления метаданными DynamoDB. Служба имеет внутреннюю репликацию и запускается в нескольких центра обработки данных (ЦОД). Сервера хранения данных содержат актуальные данные таблицы внутри раздела, а также периодически выполняют проверку того, что разделам определено корректное членство. Они осуществляют такую проверку, связываясь со службой управления метаданными. В ответ на запрос служба получает список разделов и всю связанную информацию из своего локального хранилища, объединяет эти данные в сообщении, передаваемом в последствии на сервер. Сервер хранения также получает сведения о собственном членстве при старте, либо после неполадок сети. После того, как сервер хранения данных закончил обработку собственных сведений о членстве, он проверяет наличие таблиц/разделов в локальном хранилище, создает новые связанные таблицы/разделы и получает данные от других серверов хранения для репликации существующих связанных разделов.
Первоначальная причина отказа. В 2:19 ночи ( PDT - тихоокеанское летнее время, -10 часов от МСК) наблюдалось кратковременное падение сети, затронувшее несколько серверов DynamoDB. Обычно аналогичные падения сети обрабатываются не заметно и без изменения производительности DynamoDB, так как затронутые сервера хранения запрашивают службу управления метаданными сведения о своем членстве, применяют все необходимые обновления и сообщают, что они вновь могут обрабатывать запросы. Если сервера хранения не могут получить информацию назад в течение определенного периода времени, они отправляют повторный запрос о членстве и временно отписываются от обработки запросов.
Основная проблема. Но воскресным утром несколько ответов службы управления метаданными превысили предел времени получения и передачи данных. В следствие чего некоторые из серверов не смогли получить сведения о членстве и отписались от обработки запросов. Увеличение времени ответа было связано с недавней доработкой DynamoDB: в последние несколько месяцев пользователи часто применяли GSI (Globl Secondary Indexes). GSI позволяет обращаться к данным по альтернативным ключам (а не по первичным). Так как GSI является глобальным, он имеет свой собственный набор разделов на серверах хранения, тем самым увеличивая общий размер членских данных. Пользователи могут добавить несколько GSI для одной таблицы, поэтому таблица с большим числом разделов может быстро удвоить или утроить размер таких данных. За счет быстрого применения технологии пользователями для больших таблиц индекс "разделов-на-таблицы" значительно вырос. Из-за больших размеров членских данных время обработки некоторых запросов начало приближаться к пороговым значениям. Amazon не вел мониторинга размера данных о членстве и не имел достаточных мощностей для обработки таких тяжеловесных запросов.
Таким образом, когда в воскресенье после проблем с сетью несколько серверов одновременно запросили свои членские данные, служба управления метаданными обрабатывала тяжелые запросы. Несколько одновременных запросов для таких больших объемов данных привело к еще большему увеличению времени обработки, что привело к отказу серверов хранения от обработки входящих запросов. Из за высокой нагрузки на службу управления метаданными, она также перестала отвечать на запросы серверов, не вовлеченных в изначальную проблему деградации сети, которые запросили обновление своих членских данных. Многие из этих серверов хранения также стали недоступны. Недоступные серверы продолжали отправку запросов на обновление сведений, сохраняя тем самым высокую нагрузку на службу управления метаданными. Не смотря на то, что многие запросы обрабатывались корректно, работающие сервера, получившие успешный ответ от службы один раз, получали ошибочный ответ в следующий, становясь вновь недоступными. К 2:37 ночи количество ошибок достигло максимума за последние три года, остановившись примерно на 55%.
Предпринятые шаги. Из-за высокой нагрузки Amazon не мог добавить ресурсов к службе. После нескольких неудачных попыток увеличить мощности в 5:06 утра было решено остановить запросы к службе. Это действие уменьшило активность повторных запросов, составлявших существенную часть нагрузки на службу. После того, как служба смогла отвечать на запросы администраторов, Amazon смог значительно увеличить вычислительные ресурсы и возобновить запросы серверов хранения к службе. В 7:10 утра работа DynamoDB была восстановлена.
Количество ошибок значительно снизилось и составляло теперь 0.15%-0.25%, что считалось приемлемым показателем, хотя и более высоким, чем обычно. В понедельник Amazon начал получать сообщения от пользователей о проблемах с таблицами, застрявшими в режиме обновления или удаления. Проблема заключалась в том, что не смотря на низкий уровень ошибок, отказы был и распределены не равномерно между пользователями и у некоторых из них отказы случались существенно чаще, чем у других. Оказалось, что проблема была вызвана тем, что некоторые из разделов все еще не обрабатывали требуемое количество трафика. Команда администраторов работала осторожно и старательно чтобы восстановить собственные разделы службы управления метаданными и закрыла эту проблему в понедельник.
В результате проблемы Amazon значительно увеличил вычислительные мощности службы управления метаданными, реализовал более строгий мониторинг производительности служб, уменьшил частоту и увеличил предельное время получения членских данных. Кроме того служба управления метаданными разделяется на сегменты для того, чтобы каждый экземпляр службы обслуживал только свою часть серверов хранения.
Несмотря на то, что главной причиной случившегося, конечно же, является отключение Parler от сети, всплыло немало интересных подробностей о самой социальной сети и ее разработчиках.
Например, оказалось, что главную соцсеть для консервативных активистов Америки и сторонников Трампа разрабатывали по аутсосрсу на Украине. Причем разрабатывали, желая по максимуму сэкономить.
В итоге выяснилось, что команда украинских IT-гениев построила Parler на уязвимом Вордпрессе, а для двухфакторной аутентификации пользователей применяли демонстрационную (!) бесплатную версию софта от Okta. После штурма Капитолия владельцы софта отключили Parler доступ к нему, а сеть не стала по этому поводу ничего предпринимать.
Узнав об отключении из пресс-релиза производителей Okta, неизвестные провели ночью хакерскую атаку, в ходе которой похитили у Parler 70 терабайтов данных — все посты, включая приватные и удаленные; профайлы; геолокации; сканы водительских удостоверений премиум-юзеров. Сейчас массив свободно распространяется по десяткам ссылок.
Это конец. Американская социальная сеть для правых и консерваторов убита незалежными криворукими разработчиками.
Зато инвесторы сэкономили на зарплатах.
Справились? Тогда попробуйте пройти нашу новую игру на внимательность. Приз — награда в профиль на Пикабу: https://pikabu.ru/link/-oD8sjtmAi
В то время как большинство стран-членов ЕС все еще обсуждают цифровой налог, Франция, Италия, Австрия, Великобритания и Турция пошли дальше и ввели или запланировали свой собственный налог. Технологические компании перекладывают цену на своих клиентов.
Великобритания облагает налогом прибыль, получаемую поисковыми системами, социальными сетями и онлайн-рынками, в размере двух процентов. Франция и Италия планируют ввести трехпроцентный налог. Apple перекладывает эти налоги на разработчиков в соответствующих странах. Однако в Германии Apple временно платит больше. Выплаты увеличиваются, потому что снижается НДС с 19 до 16 процентов. Цены для конечных потребителей не меняются.
Интернет-магазины в Великобритании также столкнутся с цифровым налогом, если они будут продавать свои товары на Amazon. С 1 сентября им придется платить налоги на два процента выше, как объявила Amazon .
Google конвертирует цифровой налог в цены на рекламу в Google Ads и Youtube. «Цифровые налоги увеличивают стоимость цифровой рекламы», - сказала The Guardian представитель Google . С ноября повышенная плата будет видна на счетах за рекламу. Это касается Великобритании (2 процента) и Турции (5 процентов).
По всей видимости, на Италию и Францию правила Google не распространяются. Там налог еще не действует.
«Мы продолжим призывать правительства всего мира сосредоточить внимание на международных налоговых реформах вместо введения новых односторонних налогов», - продолжила представитель Google.
Соответствующее предложение внесла и ОЭСР. Однако международные переговоры по этому поводу зашли в тупик. Такие страны, как Франция, больше не хотят ждать соглашения и полагаются на свои собственные правила.
P.s Если тебе IT тематика, юмор и различные новости из мира технологий, то можешь подписаться на Telegram канал: t.me/AlphaCodeJS