1851
Авторский блог Карена Товмасяна. Идеи, слова поддержки и критики отправляйте мне - @ThomasStorm. С предложениями рекламы не обращайтесь. I do not speak on behalf of my employer.
#новогоднее
Когда бывшая руководительница спросила, получаю ли я до сих пор удовольствие от работы, я честно ответил, что получаю, но уже иного рода.
Раньше это удовольствие было от неизведанного, а теперь от того… насколько все плохо. Этакая мазохистическая радость от очередной жесточайшей аварии или секретного проекта с неадекватно сжатыми сроками.
Лукавить не стану, работать в таком режиме вредно, но каждый кризис делает кожу толстой, а разум холодным.
Мои дорогие читатели, я желаю, чтобы ваша профессиональная жизнь наделяла вас всеми атрибутами прохождения кризисов, но эти свойства нужны были только для решения профессиональных задач. Вне конторских стен пусть вас окружают близкие люди заряжающие вас положительной энергией и вдохновляющие жить жизнь.
С наступающим Новым годом!
Анонс № 8. Управление инцидентами в большой компании
Большая компания – это компания, над которой не заходит солнце. Например, мировой агрегатор такси и доставки Uber.
Кто?
Карен Товмасян – Senior Engineer – Payments @ Uber и бессменный автор канала Человек и Машина.
О чём?
• Планируем выяснить, как всё-таки писать слово «инцидент»;
• Чем отличается инцидент от аварии, алёрта или бага;
• Что происходит в процессе починки, чем postmortem отличается от обычного отчёта от аварии;
• Всё это приправим небольшим количеством офигительных историй.
Когда: 29.11.2024 в 17:00 по МСК
Обязательно задаём свои вопросы в чате подкаста с тегом #вопрос8.
Анонимные вопросы можно задавать там: тыц.
Трансляция будет здесь и тут
@ITRadiosu
#машины_разное #люди
Прочитал пост у Димы про то, как автор любит обсуждать follow up’ы. Я же на той баррикаде, где обсуждать надо не обновления ранбуков и тестов, но архитектурные и организационные решения, которые повлияли на этот инцидент.
Немножко деталей: за последние 3 года я провел 44 разбора инцидентов, презентовал лично 5, 2 из которых запустили масштабную программу. Надеюсь когда-нибудь рассказать об этом опыте.
Автор поддерживаемого мною поста захотел отнестись к инцидентам, как к анти-дизайн ревью. Такой способ помогает командам и индивидам узнать больше о структуре и взаимодействии систем и команд, и о последствиях принятых решений. После такого разбора полетов, команда с набором свежих знаний может пересмотреть свои решения пока не стало слишком поздно для них самих.
Здесь кроется краеугольный камень: если мы обсуждаем обстоятельства, повлекшие к произошедшему инциденту, мы психологически ставим людей, принимавших решения тогда, в неудобное положение. Это наименее предпочтительно, чем ставить в неудобное положение презентующих инцидент, настаивая на важности тестирования, и мол будь у них интеграционный тест, инцидент был бы предотвращен.
Почему менее предпочтительно? Потому такие обсуждения бросают тень на работу этих самых принимающих решения. Впрочем, blameless он на то и blameless.
А вот что касается этих вот follow up’ов, то 99.999% инцидентов могут быть предотвращены:
- тестами;
- метриками и алертами;
- выплатой техдолга;
- ранбуками и тренингами.
Учитывая, что разбор полетов занимает минимум 30-40 минут, не вижу смысла собираться в комнате и обсуждать мониторинг и TDD. Взять к примеру из текста: «Do we think people should be following that runbook without a clear understanding of what each step means?»
Что этот вопрос предлагает? Что человек, проснувшийся в 4 утра от писка мониторинга, и задача которого быстро вернуть систему в рабочее состояние, должен «зачелленджить» ранбук? Если ранбуку нельзя доверять это плохой ранбук, и уж тем более не стоит взваливать на дежурного инженера дополнительный груз ответственности и когнитивной нагрузки поверх инцидента. Протокол есть протокол, и тут нечего обсуждать.
P.S. Прочитав пост и посмотрев профиль автора, который является CPO конторы, продающей инструмент для управления инцидентами, его мотивация становится понятной. Функциональность надо продавать!
#машины_разное
Ликуйте, страждущие, в Python версии 3.13 можно выключить GIL!
Осталось ещё статическую типизацию добавить и у питонохейтеров кончатся аргументы.
#машины_aws
Этой ночью, AWS Kinesis снова отстрелил многим чресла в us-east-1. Практически так же, как 4 года назад. По этому поводу сделаю пару замечаний.
Во-первых - не используйте us-east-1. Это регион-страдалец, там всегда что-то взрывается раз в год. Пощупать экспериментальные сервисы первым того не стоит... Впрочем вы и без меня это знаете.
Во-вторых, давать леща за инциденты нельзя. А вот давать леща за неисполнение incident follow up'ов - вполне себе можно и нужно. Следите за руками.
В 2020, когда случился инцидент, AWS поставил себе задачу разделить Kinesis на две изолированных группых сервисов, иными словами, сделать "внутренний" Kinesis.
We will also move a few large AWS services, like CloudWatch, to a separate, partitioned front-end fleet. (с) из пост-мортема
Делается это для того, чтобы внутренние проблемы сервисов не били по внешним потребителям напрямую, потому что потребители работают с абстракциями - ну давайте честно, кто еще знает, что Cognito использует Kinesis под капотом? - и знать внутренности не должны.
Однако спустя почти 4 года, мы имеем отказ клиентских сервисов по подозрительно схожей причине, более того, "клиентский" Kinesis тоже пятисотил. Это говорит о том, что:
- либо в общей структуре есть большой архитектурный огрех, который не решается дублированием сервиса для внутренних нужд
- либо, что еще хуже, AWS не исполнил обещание после инцидента.
За второе надо бить палками, а так же отдавать айтишников на массовые расстрелы, потому что задача каждого разбора полетов не допустить такой же инцидент в будущем.
#люди
Этот блог на сайте Мартина Фаулера провисел у меня в списке чтения месяцев, наверное, 7 или 8, и наконец-то у меня добрались руки. Настоятельно рекомендую не только кубоводам и сисадминам, но и разработчикам так называемых бизнес платформ.
Из важного внутри поста:
1. Фазы взаимодействия платформенных команд с продуктовыми;
2. Модели взаимодействия в каждой фазе;
3. Рекомендации по построению масштабируемых платформеннных команд.
Пункт 3 особенно важен, потому что в отличие от комплюктеров, люди и часы в сутках не масштабируются.
#машины_aws
Роскошный пример синтеза белошапочников и черношапочников.
https://buckets.grayhatwarfare.com/
По ссылке - список из всех публичных, т.е. открытых наружу бакетов во всех крупных поставщиках облачных услуг. За дополнительную плату можно получить доступ к поисковому API, регулярные выражения и даже сортировку по размеру.
За находку спасибо Юре @pyToshka
#люди
Если жестокий капитализм не пощадил вас или ваших друзей и заставил искать новую работу, испытывая стресс от автоматических отказов или игнора - я написал пост про то, как в 2024-ом стоит оформлять резюме для итшников, чтобы увеличить шансы на первую встречу с работодателем.
Пост доступен на Медиум. Если по какой-то причине Медиум не работает, пост продублирован на Телега.пх.
Внутри поста:
- как изменилось поведение работодателей
- что писать в резюме, а что не писать
- кто такой этот ваш импакт
- что делать, если рекрутер все никак не позовет
В работе я ориентировался на западный рынок, но некоторые пункты применимы и для России/СНГ.
Уточняющие вопросы можно задать в Медиуме или тут в треде. Я также не против перевода статьи на русский, если у кого-то есть время и ресурс, и буду признателен, если переводчик сошлется на оригинал.
#машины_разное
Рик Хулихан, известный политтехнолог NoSQL в свое время разработал стандарт Single Table Design, который подразумевает хранить все поля сущностей в одной, как следует из названия, таблице.
Про STD есть превосходная презентация, которая раскрывает суть, детали и имплементацию. Честно скажу, что это моя самая любимая презентация.
Однако, индустрия делает очередной виток, и снова начинаются гонения на, вроде бы, принятые подходы. Создателя паттерна это, можно сказать, задело, и он разразился большой ответкой в Твитере.
Настоятельно советую прочитать ответ. Без апелляции к авторитету, можно снова сказать, что был потерян контекст. STD никогда не подразумевал складывать вообще все в одной таблице. Паттерн подразумевает, что атрибуты одной сущности должны храниться в одном месте, а не в разных. Но определение этих атрибутов идет в первую очередь с помощью определения паттернов доступа - какие данные мы читаем и для каких целей.
От себя замечу, что пока мы, как индустрия, продолжаем терять контекст, мы обречены использовать инструменты и подходы не по назначению, а потом героически их переизобретать.
#машины_разное
Если вам вдруг надоело флексить CAP теоремой, значит пришло самое время расчехлять "новый" "тренд" под названием PACELCA
И если вы сейчас подумали о зумерах, которые переизобрели распределенные системы, спешу вас расстроить - с критикой теоремы зашли пресловутые деды.
В первую очередь, CAP теорема обманывает тем, что мы можем выбрать 2 из трех, в то время как выбрать мы можем одно из двух - А или С. Выкинуть из системы Р нереалистично, да и более того - кто такой этот ваш партишн толеранс? В каком-то случае, пропавший интернет в туннеле уже себе Network Partition, попробуйте предусмотреть это в своей системе.
Вернемся к PACELCA (кто-нибудь, отберите у итшников нейминг, пожалуйста).
Сама по себе эта, даже не теорема, а скорее алгоритм анализа компромисов звучит так: Если нам нужна терпимость к сетевым партициям (P), то мы выбираем между доступностью (А) и согласованностью (С). В противном случае (Else - E), компромис между задержкой (Latency - L) и выбором в сторону согласованности (С) или доступности (А).
Сложно? Сложно. Сначала академики придумали нам устойчивую договоренность, а потом пришли деды из индустрии и из этой договоренности сделала пес знает что. Потому что edge cases. 🤷♂️
P.S. В индустрии в принципе есть тренд то на усложнение, то на упрощение. См. прыжки из монолита в микросервисы, из микросервисов в макросервисы, из макросервисов обратно в монолит. В гибкости - сила!
#пятничное #новогоднее
Многим из вас знаком закон Конвея, который гласит, что организационная структура и коммуникация между командами отражается на итоговой архитектуре систем.
Существует и обратный закон Конвея, предлагающий растить и развивать структуру предприятия в соответствии с архитектурой системы.
К чему я это все? К тому, что и в первом, и во втором случае наблюдается натягивание одного на другое. Это не хорошо и не плохо, это данность за которой придется следовать. В конце концов мы субъекты вечно меняющихся обстоятельств, в которых нам надо существовать и оперировать.
В 2024 году я хочу пожелать вам, дорогие друзья, крепости и силы для внешних обстоятельств и гармонии и покоя для внутренних.
С наступающим Новым годом! 🎉
#машины_aws
AWS будет строить "суверенные" регионы в Еврозоне.
Ставлю, что это нужно для:
1. GDPR/PSD2/других европейских стандартов
2. GovCloud для ЕС
#анонсы #машины_aws
Лучшая книга по AWS CloudFormation получила второе издание!
В новой версии:
1. Переработаны почти все главы в соответствии с изменениями у самого AWS'а, обновлен весь код, и мне за него даже почти не стыдно
2. В главе Advanced Template Development добавлена секция по работе с Language Extensions
3. Глава про Macros была переписана полностью и теперь включает в себя Nested Stacks и Modules
4. Новая глава, посвященная работе с CloudFormation Registry
5. В главе по CDK используется CDK v2
Отдельная благодарность @VasilyPantyukhin и @patrick239 за то, что заставили меня вылизывать все почти до мельчайшего знака препинания!
#машины_разное #люди
В индустрии есть распространённое предубеждение против найма так называемых олимпиадников, и оно, должен признать, небеспочвенно.
Как-то раз мне дали одну задачу на собеседование. Задача про пиццу, она же Lazy caterer's sequence, была крутая. Так и не смог понять, как к ней подойти, но я и математику не знаю, что с меня взять. А коллега, давший мне задачу, намекнул, что решение задачи не должно превышать 40 символов, чем вызвал желание написать этот пост.
Зная формулу, решить эту задачу можно в одну строку, а олимпиадники их так наверняка и решают. Однако такое решение имеет мало шансов обеспечить кандидату найм, ведь интервьюер смотрит не только на такие характеристики как эрудицию, отладку и прочее, но и читаемость кода. А все потому что в индустрии код пишется не для машин - компилируемый код машина и так пожрет - но для людей. Если кандидат не в состоянии внятно объяснить свой ход мыслей словами через рот и невербально через код, то о командной работе и сопровождаемости и речи быть не может.
Поэтому читаемый код, пусть и превышающий мнимый лимит в количество символов, гораздо важнее быстрого наброска, который не поймет даже сам автор, не говоря уже о его коллегах.
Хорошо про читаемость кода написал один из адвокатов оного в Google. Да, вы работаете не в Google и не решаете задач Google, но изучать опыт других никто не запрещает, верно?
#машины_aws
Славная традиция снова повторяется. Раньше, стоило мне написать второе издание лучшей книги по AWS CloudFormation, как AWS делал ее устаревшей на стадии печати.
А теперь стоит мне запланировать переезд из DynamoDB из-за ее проблем с кросс-региональной согласованностью, как… DynamoDB выпускает это в Preview (читай - открытое бета тестирование).
Понятное дело, что пройдет минимум полгода, пока оно уйдет в продуктив, но и миграция баз данных проект не на неделю. 😌
Кто пропустил живьем, приглашаю послушать запись.
Читать полностью…
#машины_разное #люди #анонсы
За полтора года в роли ведущего разбора полетов я принял тот факт, что любой инцидент в определенной мере это анти-дизайн ревью.
Если в дизайн ревью, команда рассказывает: "Вот что мы хотим сделать", то в инцидент ревью, команда рассказывает: "Вот что мы сделали, и вот к чему это привело."
Приглашаю вас послушать о том, как проходит управление инцидентами, от каких инцидентов у меня до сих пор идет дрожь по коже, а так же чем полезен и опасен blameless.
Буду рад ответить на ваши вопросы!
#машины_разное #люди
Small changes in context (people/places/features you want to support) often radically change how well a program fits its context. Our dominant milieu of short-termism doesn't prepare us for this fact. (с) Kartik Agaram
Очень хорошее дополнение к закону Конвея и дежурное напоминание о том, что приоритеты и обстоятельства могут наглухо перечеркнуть прогресс проекта или радикально поменять его направление. Закладывайте любой риск в работу и не старайтесь решить все проблемы сразу - все равно не получится.
#машины_разное
Моя давняя аудитория знает, что я волею судеб держусь в стороне от Кубернетеса и всего с ним связанного, периодически делая смелые вылазки в эти непонятные и, честно скажу, ненужные мне дебри.
Я оказался не одинок в этом! Некто davidv, автор блога Mumbling about computers прикоснулся к «де факто стандарту индустрии» и высказал свое мнение. Рекомендую к прочтению, эссе читается легко и с юмором.
Меня зацепила следующая фраза:
«What do you mean that the *type* for value depends on the *value* of mode?? And what do you mean mode is a string when it should be an enum??»
Да, меня зацепило использование строк вместо enum.
Видите ли, когда мы передаем строку, мы можем передать в нее все что угодно, от откровенно хулиганского мусора и невалидных данных до закодированного в base64 бинаря. Это накладывает дополнительную нагрузку на принимающую сторону - нужно добавлять валидацию, правильно обрабатывать вход, а то и ставить security прослойку, чтобы злоумышленник чего бы лишнего не пропихнул.
Это не значит, что строки надо запретить, но вот минимизировать их использование можно. В данном - из поста - случае, речь идет о режимах сбора метрик с RabbitMQ. Сколько там может быть вариантов? Как часто добавляют новые? Как часто убирают старые? Простым enum’ом это реализовать гораздо проще, чем принимать и парсить строку.
#люди #машины_разное
Как это обычно с крупными инцидентами, отвал башки от CrowdStrike произвел фиаско. С нетерпением жду post mortem, потому что это значительно круче, чем отстрелы интернетов от неработающего S3.
И как это обычно бывает с инцидентами такого масштаба, у людей есть мнение, и это мнение выходит в публику. Из того, что я увидел, у нас есть предложение казнить программистов, и есть доводы защиты, что казнить надо СЕО и… политиков. С мнениями такое бывает.
Сам я считаю, что индустрия заматерела достаточно, чтобы попасть под жесткое давление стандартов, писаных кровью, но моим мнением на этот счет можно пренебречь.
Однако в попытках найти кого-то, в кого бы можно было тыкать пальцем, мы часто забываем о практике управлениям инцидентами, а именно о разборе полетов. И нелюбимый всеми дедами blameless существует не для того, чтобы оградить нежную натуру программиста от гула толпы, но чтобы убрать все отвлекающие факторы, пока мы докапываемся до сути проблемы. Да, я говорю о 5 Whys.
Системы, в отличие от человека, могут и должны быть защищены от человеческого фактора. Поэтому, я бы спросил:
1. “Почему не был выловлен баг на стадии тестирования?” Чего не хватало разработке? Времени? Инструментов тестирования?
2. “Почему такой большой blast radius?” Почему обновление вышло сразу на такое большое количество устройств? Был ли канал обратной связи?
3. “Почему код shyamsundarb/technical-details-of-the-windows-bsod-disaster-due-to-crowdstrike-58de2371c19c">не смог выделить память?” или даже лучше “Почему код вообще работает с памятью напрямую?”
Ответы на эти вопросы помогут предотвращать инциденты. Массовые расстрелы айтишников и стартаперов - вряд ли.
#машины_aws
У CloudFormation два классных нововведения. Про первое уже написал Рома, обязательно пройдите и прочитайте, если вас задолбала последовательность: создал стек с бакетом - набил бакет объектами - удалил стек - стек не удалился - матерясь, чистишь бакет - удаляешь стек снова - раздраженно снимаешь галочку с “игнорировать удаление”.
Но мне, честно говоря, больше понравилась новость про дебаг с помощью CloudTrail.
Когда я работаю с новым или мало изученными сервисом, у меня часто происходят итерации trial and error. Где-то опечатался, где-то перепутал параметр, где-то добавил несовместимые свойства, где-то забыл построить зависимость с помощью DependsOn.
До того, как появилась возможно управлять стеками с disable rollback, обычный цикл разработки выглядел похожим на цикл удаления стека с непустыми бакетом:
1. Создаем стек
2. Стек валится, откатывается назад. Пока он откатывается, смотрим ошибку API
3. Ждем пока стек откатится. Поскольку это новый стек, мы его удаляем, потому что перенакатить изменения на новый стек, который сломался и откатился в пустоту ПОЧЕМУ-ТО ДО СИХ ПОР НЕЛЬЗЯ
4. Находим ошибку в шаблоне, исправляем. Повторяем итерацию с пункта 1.
Чем же тут хорош CloudTrail? Тем, что раньше у нас была скучная консоль с логом стека, где мы по куску ошибки должны были сделать вывод. Теперь же можно пройти в CloudTrail, посмотреть подробно не только ошибку, но и какие параметры были у запроса в API, со всеми полями. Это так же упрощает разбор ситуаций, когда создание валится не из-за опечаток в шаблоне, а например если у роли, с которой CloudFormation создает ресурс, недостаточно прав.
#машины_разное
Мой прошлогодний доклад про строго-согласованный кластер Redis получил TechInternals/feet-of-clay-achieving-strong-consistency-over-eventual-a42102c928c6">расшифровку. Если вы предпочитаете текст вместо видео - милости прошу.
#пятничное
AWS CodeDeploy научился цеплять несколько балансировщиков к EC2 машинам. Это вызвало у меня радость, поскольку я мог вычистить кодовую базу от нескольких хаков, которые пришлось применить, чтобы подружить машину с двумя балансировщиками.
Зайдя в доку, я обнаружил что нововведение не появилось в провайдере (хотя 3 месяца прошло, могли бы и завести). Беглый поиск показал открытый запрос на поддержку, висящий в очереди, потому что HashiCorp расставляет приоритеты на основе... лайков!
Удивительно, что Хаши раньше добавляли новые фичи и сервисы быстрее команды CloudFormation.
#машины_aws
При настройке доступа через IAM велик соблазн использовать сгенерированные самим AWS'ом политики, в которых нужная часть доступа уже предоставлена.
Так, например, в AmazonEC2ReadOnlyAccess добавили ec2:Get*. Все бы хорошо, но действие ec2:GetPasswordData дает администраторский пароль от Windows машины, что, скажем так, уже не совсем read-only 🙂
Изменение довольно шустро откатили. Лишний раз напомню, что лучше дополнительные пару часов потратить на дизайн доступа по Least Privilege Principle, чем потом быть на первой полосе новостей из-за взлома.
#машины_aws
У нас с командой AWS CloudFormation есть славная традиция: как только я отправляю новое издание по Mastering AWS CloudFormation в печать, команда тут же выпускает новые фичи, про которые мне обязательно хотелось бы рассказать в книге.
Сначала это был Fn::ForEach, который добавляет поддержку циклов (долгожданный конкурент Terraform'овского count и for_each), вышедший в релиз как только вторая глава со словами "Вот AWS уже делает нам циклы в клавдформейшоне" была сдана, сверстана и проиндексирована, ну а теперь, как вы наверное догадались - IaC generator.
Генератор - это AWS-managed аналог Terraformer. Сканируем весь аккаунт (если надо, с фильтрами) и добавляем ресурсы для будущего стека.
На выходе получаем сгенерированный код с импортированным состоянием. Этакий OneClick переезд с ClickOps на Infrastructure-as-Code. А любители высокоуровневых языков программирования могут сходу занести стек в CDK и забыть про ужасы правки длиннющих YAML'ов.
Из очевидных недостатков: поддерживаются только "родные" ресурсы из CloudFormation Registry, что логично - оно не побежит в DataDog сканировать дашборды. Второй недостаток вытекает из первого - если вы накликали себе ресурсов из свежего мегасервиса, который не поддерживается CloudFormation, то никакой генерации не будет.
P.S. Мне такими темпами скоро придется третье издание писать, пощадите.
P.P.S. В комментарии приглашаются YAML-фобы, потому что я так и не понял разницу между поддержкой кодовой базы на тысячу строк и аналогичным шаблоном CloudFormation.
#машины_разное
Null Pointer Exception одна из самых ублюдских проблем, с которой мне приходится сталкиваться с тех пор, как я перешел в бекенд. Особенно противно работать с вложенными структурами, когда приходится делать такие проверки:
s := someStruct{}
if s.Nested != nil || s.Nested.MoreNested != nil || s.Nested.MoreNested.EvenMoreNested != nil {
// ...
}
#машины_разное
Мое пятничное чтиво - история load average (LA), которое, как выяснилось, существует аж с 70х годов прошлого века, и претерпело значительные изменения в 93-ем.
Для тех, кому LA в новинку, рекомендую мой источник. Там и пояснения, и увлекательное детективное расследование.
Но что интересно, так это то, что LA сначала мерило ожидания только CPU. По мере добавления других компонентов в компьютеры, как сетевые и дисковые устройства, причин задержек стало больше, поэтому их тоже понадобилось включать в формулу.
Иными словами, если раньше LA показывало количество процессов "ждущих" процессор, то сейчас оно показывает количество процессов ожидающих любой ресурс.
P.S. Вы наверняка столкнетесь с кадрами, которые считаю LA какой-то бесполезной фигней, например, разработчики Linux.
#машины_разное #люди
Вне зависимости от срока жизни предприятия или организации, специалист всегда можно подчерпнуть вдохновение из, возможно устаревшей, архивной документации и рабочих предложений.
Во-первых, история циклична, и то, что использовалось 30 лет или 3 года назад, вполне может быть переиспользовано сейчас под давлением новых обстоятельств.
Во-вторых, архивные рабочие предложения могли быть закрыты из-за нехватки ресурсов или более приоритетного проекта. Что не значит, что проект нельзя реанимировать - не зря же его пытались запустить.
В-третьих, полезные знакомства в лице локальных дедов помогут усилить рабочее предложение, убрав из него очевидные недостатки и сгладив углы. Вы получите мудрого и влиятельного советника, а дед получит возможность тряхнуть стариной.
Вооружившись историей и дедами, как начинающий карьерист, так и опытный специалист, можно найти хорошую отправную точку для причинения пользы предприятию.
#машины_aws
А давайте еще неприятное про AWS. На этот раз про непредсказуемое и блокируещее поведение DynamoDB Global Tables, Billing Mode и лимитов.
Представим, что у нас есть глобальная таблица с двумя репликами в регионах А и Б. Таблица работает в режиме provisioned с включенным автоскейлингом.
Теперь представим, что реплики работают в режиме primary/secondary, т.е. мы сначала обращаемся к реплике в регионе А, а если что-то идет не так, то в регионе Б.
Поскольку таблица А получает львиную долю запросов, которых очень много, лимиты на употребление W/RCU превышают значение по умолчанию в 40 тысяч. Лимит увеличивается до 100 тысяч, и является верхним значением автоскейлинга. В регионе Б в это время лимит по-прежнему стоит 40 тысяч.
Далее, мы совершим небольшую шалость, и переведем таблицу из режима provisioned в режим pay-per-request, а затем обратно. Вопрос: как поведет себя DynamoDB?
Она, конечно же, не сможет вернуться в режим provisioned!
Следите за руками:
1. Если режим provisioned был с включенным автоскейлингом, при переводе из pay-per-request в provisioned автоскейлинг включен по умолчанию с предустановленными параметрами. "Не включать" его нельзя.
2. DynamoDB принимает решение поставить максимальное значение для глобальной таблицы, а значит и реплик в обоих регионах - в нашем случае 100 тысяч запросов в секунду, как настроено в регионе А.
3. При попытке настроить схожим образом реплику в регионе Б, DynamoDB упадет с ошибкой в связи превышением регионального лимита.
4. Изменения откатятся, обе реплики будут работать в режиме pay-per-request.
Единственный способ побороть эту проблему - запросить увеличение лимита в регионе Б до нужного значения. Поскольку это делается техподдержкой и руками, настоятельно рекомендую иметь под рукой контакты аккаунт менеджера для эскалации.
Lessons learned, мать его, the hard way.