#машины_aws

Пока я работаю над длиннопостом, два занимательных и одновременно неприятных факта про DynamoDB:

1. DynamoDB TTL - бесплатный server-side способ удаления устаревших данных не предоставляет гарантий удаления в срок истечения! Хуже того то, что объекты с истекшим сроком жизни все еще отображаются в запросах, что перекладывает ответственность за фильтрацию валидных данных на клиента. Не смотря на то, что в среднем удаление занимает до 48 часов, мне известны случаи о задержке аж на 10 суток.

2. Capacity Units распределяются по шардам (Partition Key) таблиц, что может привести к ProvisionedThroughputExceededException при том, что throttle происходит только на конкретном шарде - так называемая проблема Hot Partition. По результатам общения с техподдержкой выяснилось, что:
- В режиме provisioned CUs, они равномерно распределяются по шардам; далее DDB будет распределять CU на более активные шарды. Как происходит распределение, когда количество шардов превышает количество CU, неизвестно.
- В режиме OnDemand, каждый шард получает 1000 WCU и 3000 RCU сразу же и перераспределения между шардами уже не происходит, поскольку 1000 записей и 3000 чтений в секунду - верхний порог.

Казалось бы мелочи, но эти мелочи выпили мне немало крови в Uber. И заметно сузили мой личный список подходящих бизнес задач для DynamoDB.

#анонсы

Я обещал, что на этом канале нет и не будет рекламы, но я не расчитывал, что удар в спину реклама придет от самого Телеграмма.

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

Ни от кого.

#люди

Университет Северной Каролины совместно с Microsoft провели whiteboarding собеседование 48 выпускников и студентов и пришли к выводу, что эти ваши кодинги с алгосиками проверяют не технические навыки кандидатов, а их возможность бороться со стрессом и тревожностью.

Новостей тут нет, результаты исследований закономерные. Кандидаты, которым дали задание и оставили наедине, справились вдвое лучше, чем те несчастные, кто проходил интервью в присутствии интервьюера и должен был (какой ужас!) озвучивать ход своих мыслей.

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

Сегрегировать кандидатов по признаку устойчивости к стрессу, равно как и вообще любому иному признаку, кроме профессиональных - гитлер-гитлер-гитлер, и я сейчас это абсолютно серьезно. Процесс найма в ИТ сломан. Он либо идиотский, либо поддается “взлому”. Попадись на кодинге знакомая задача - можно считать, что этот раунд в кармане.

Со стороны кандидата, чтобы получить желанный оффер из FAANG+, достаточно скрепить зубы и сесть на от 1 до 6 месяцев за LeetCode и просить более опытных товарищей побыть наставниками по архитектуре и проектированию систем.

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

Однако, мне не дает покоя пункт про толерантность к интроверсии кандидатов. Пресловутый Software Engineering отличается от Coding’а именно тем, что за последние десятки лет эта работа социализировалась, и про это хорошо рассказывается в первой главе Software Engineering at Google. Времена атомарных единиц, выполняющих свой кусок задач и ни с кем не коммуницирующих хотя бы в формате текста, канули в лету.

Это вовсе не значит, что социопату закрыт путь в профессию - заходи фрилансером на рынок да бери себе единичные и сложные задачи. Ну или напиши свой Flappy Bird или Minecraft. Но в любой крупной компании придется работать с людьми, и если человек впадает в панику на интервью, то откуда гарантия, что он не впадет в панику на работе?

#люди

Джеф Безос однажды сказал: "Хорошие намерения не работают, вам нужны хорошие механизмы чтобы что-то произошло."

Методология SRE включает в себя так называемый пост-мортем - разбор полетов после инцидента. Разные конторы делают это по-своему, но основная задача проста как мир: не допустить такого же инцидента снова.

Один из вопросов, на который мне, после одного инцидента, пришлось ответить: "Что можно было сделать, чтобы избежать этого инцидента?" Я честно ответил, что мне не хватило того и этого, да и в принципе, потрать я больше времени и проверь все раз десять, то не накосячил бы так... за что получил нагоняй от наставника.

Результатом пост-мортема являются одна или более задачи, результатами которых должны быть артефакты:
• Не смог понять, что именно упало - нужны понятные логи и метрики, дашборды и инструменты observability
• Отказ одной системы вызвал цепную реакцию и retry storm - circuit breaker
• Получил уведомление, но не знал что делать - нужны понятные runbook'и и механизмы эскалации

Я же в свою очередь уперся в личностное и посчитал, что во избежание инцидента нужно крепенько думать, что делаешь. После чего, мой старший коллега процитировал экс-главу Amazon и объяснил, что мы тут все умные и внимательные котики, но так и будем косячить без полезных инструментов. Не сегодня, так завтра. Не я, так кто-нибудь другой.

И если так подумать, то все инструменты, которые любезно делает ваша группа DevExp (если она у вас есть, конечно): кодогенерация, IDL, герметичная сборка, монорепы и т.д. - это не только ускоряет работу кожаного мешка, сидящего на неприемлемо большой зарплате, но и уменьшает вероятность аварии категории PEBCAC.

#машины_разное

Есть много разных причин, по которым та или иная компания разрабатывает свое решение с нуля вместо адаптации того, что есть на рынке. Для кого-то это конкурентоспособность, для кого-то будущие оптимизации, для кого-то стоимость разработки с нуля меньше стоимости адаптации или форка.

Отдельным особняком от the Big Tech, славящимся собственными инженерными решениями, стоят не менее большие Деньги. Про инвестиционные банки и (не-)традиционный финтех немногое известно. Они не пользуются популярностью на рынке, их рекрутеру не носятся с названием конторы по всему LinkedIn'у, их репутация вызывает вопросы, и чаще всего платят они гораздо больше FAANG+.

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

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

Так, например, Cal Paterson в своем блоге приоткрывает завесу тайны, стоящей за большими деньгами на примере вымышленного инвест-банка Минерва и его денежных технологий, построенных на языке Python, но далеко не таком, каким мы привыкли его видеть.

Прекрасное понедельничное чтиво для эрудиции, а так же новых потенциальных мест работы. Вот, например (и как после такого не любить деньги?): "Dagger tracks the edges in the graph of underlying instruments and automatically reprices derivatives in Barbara when the value of the underlying instruments changes. If some bad news about a company is published and a credit agency downgrades their credit rating then someone in bonds will update the relevant Bond object via Dagger and Dagger will automatically revalue everything that is affected. That might mean hundreds of other derivative instruments. Credit downgrades can be rather exciting."

#пятничное #машины_разное

С третьего захода пытаюсь одолеть Designing Data-Intensive Applications, и чем дальше в лес, тем депрессивнее становится чтиво.

Компьютеры ненадежные, процессы ненадежные, runtime'ы ненадежные, сети ненадежные. Даже часы, и те ненадежные!

Особенно часы! Часы настолько ненадежны, что Google в своем сервисе суперточного времени TrueTime возвращает не суперточное время, а диапазон времен, минимально возможное и максимально возможное.

В этой вашей итшечке ни в чем на 100% уверенным быть нельзя, а вы каких-то гарантий от вакцин ждете.

#машины_разное

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

Мне не давала покоя история Spanner/TrueTime и его гарантии ACID в контексте СУБД планетарного масштаба. Я влез в нее, делая записки своих изысканий, надеясь сделать из этого полноценный блог, но блога тут хорошего не выйдет. Почему? Долгая история, но вы на меня подписаны не ради того, чтобы читать мои конспекты книг или, прости Господи, репосты.

Ниже, собранный из осколков пост, кратко описывающий, как оно работает.

Про TrueTime вы уже знаете. Он возвращает не время, но дельту вероятных времен. Spanner использует эту дельту, чтобы построить четкий порядок очередности транзакций, для обеспечения Consistency as in ACID.

Тут надо сделать небольшую ремарку: C в ACID и C в CAP это… разные consistency! Точнее слово-то одно, но оно так изнасиловано академиками кудахтер саенс, что консистентность тут имеет разные определения.

Консистентность по ACID означает то, что каждый запрос на чтение в базу вернет корректное состояние на момент исполнения запроса. По CAP - что каждый запрос на чтение вернет все завершенные записи.

Согласитесь, это несколько разные вещи? В ACID консистентность обеспечивается за счет атомарности и изоляции транзакций. В случае со Spanner, используется классический подход snapshot isolation что в купе с хитростями TrueTime дает нам нужные гарантии. Как хранилище Spanner’а обеспечивает скорую репликацию данных между регионами вопрос уже десятый, и не такой уж и интересный. В конце концов все упирается в физику, двухфазные коммиты и вот это вот все.

Что Cloud Spanner, что Aurora Global Database - прикольные решения, но в голове нужно держать цитату Мартина Клепманна: A node in the network cannot *know* anything for sure—it can only make guesses based on the messages it receives (or doesn’t receive) via the network.

#машины_aws

Модель биллинга Pay Per Request, по которой тарифицируется львиная доля serverless-сервисов AWS, крайне кусачая по стоимости на гигантских масштабах (о чем я неоднократно говорил), но позволяет однозначно понимать, в какую сумму обходится каждый кусочек бизнес логики.

И неудивительно, что AWS продолжает толкать эту затею вперед. Вы только взгляните:
- безсерверная Kafka
- безсерверный Hadoop
- безсерверный DWH

В следующем re:Invent ожидаем Savings Plans для аналитики и хранилищ.

​​#пятничное

Это я, выспавшийся и отдохнувший, показываю нашему on-call'у очередные мемы про падение us-east-1.

#машины_разное

Разные птички шепчут мне, что дела надо доводить до конца, не смотря на отсутствие дофаминового всплеска.

Оно и правильно - раз обещал рассказать про внешнюю консистентность, будь добр сдержать обещание!

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

Understanding External Consistency

Ставим лайки, делимся материалом, подписываемся, жалуемся в комментариях “а почему не на русском?!”!

Для врагов CloudFlare: https://blog.tovmasyan.io/understanding-external-consistency-8947f6469985?sk=e5bfc6b69797ede23a1c0a958231eb59

#машины_aws

1. У Facebook инцидент с сетью
2. Facebook заводит партнерство с AWS
3. https://aws.amazon.com/message/12721/

#машины_aws

Чем дилетанты отличаются от неудачников:
- Дилетанты осознают свои возможности и учатся
- Неудачники улюлюкают и устраивают клоунаду в Твиттере

Очевидно, дилетантам надо помогать и наставлять, а неудачников гнать и насмехаться.

Понедельничное чтиво для моих любимых дилетантов : мой набор трюков, как не тратить лишних денег на AWS.

#машины_разное #люди

Многим знакома такая практика как Code Freeze - блокировка изменений на период рождественских/новогодних праздников, чтобы не усложнять жизнь дежурным. Окно обычно занимает около двух недель или более, в зависимости от страны, а его строгость зависит от домена, в котором оперирует бизнес.

И не смотря на общепринятость практики, находятся те, кто с ней не согласен.
Роберт Росс, СЕО FireHydrant и выходец из Digital Ocean, призывает перестать это делать.

Я не разделяю мнение автора, но в его словах есть рациональное зерно: заморозка не предотвращает, а отодвигает неизбежный инцидент.

#машины_разное

https://arstechnica.com/information-technology/2021/12/patch-fixing-critical-log4j-0-day-has-its-own-vulnerability-thats-under-exploit/

Счастливого дежурства!

#машины_разное

Site Reliability Engineering я прочитал несколько раз с перерывом в год с лишним. Подобное “перепрочтение” позволяет еще раз по мере роста опыта взглянуть на ту или иную задачу.

По схожей причине сейчас перечитываю SRE Workbook, а конкретно главу Alerting on SLOs. От того интереснее еще раз пройтись по термину burn rate.

Полностью все описывать нет смысла, прочитайте по ссылке, там очень интересно, даже если вы далеки от SRE практик.

Подход SLO и error budget привносит в работу операций нотку экономики. И именно таким образом авторы из Google предлагают реагировать на нездоровость системы.

Возьмем SLO по успешным ответам (2ХХ) 99.9%. Иными словами, только 0.1% запросов или 1 из 1000 не будут корректно обработаны системой. SLO растягивается на часы, дни, кварталы, месяцы и так до года. Каким образом выбрать временнОе окно для замеров и логику уведомлений?

В Google решили применить способ расчета под названием Burn Rate - в каком темпе “съедается” наш заделанный на год бюджет ошибок, в искомой главе есть небходимые значения. Расчет самого burn rate я не понял, если кто понял, напишите в комментариях, обучите уму разуму, мне под конец года уже лень.

А поскольку “гореть” можно слабо, но продолжительно, а можно ярко, но недолго, умные ребята предложили интересную математику: возьмем несколько окон, несколько burn rate’ов, Булеву Алгебру и получим удобные и своевременные уведомления, на которые можно реагировать.

Наглая копия из книги:

expr: (
        job:slo_errors_per_request:ratio_rate1h{job=“myjob”} > (14.4*0.001)
      and
        job:slo_errors_per_request:ratio_rate5m{job=“myjob”} > (14.4*0.001)
      )
    or
      (
        job:slo_errors_per_request:ratio_rate6h{job=“myjob”} > (6*0.001)
      and
        job:slo_errors_per_request:ratio_rate30m{job=“myjob”} > (6*0.001)
      )
severity: page

Итого ловим судорожные звонки от робота, когда система сбоит жестко в течение пяти минут И часа ИЛИ чуть помягче в течение получаса И 6 часов.

Сложно, да. А вы как хотели?

#машины_aws

Распространённый миф о безопасных клавдиях больно ударил, что по Capital One в 2019 что по Twitch в 2021.

Непопулярное мнение: все эти инциденты - вина владельцев и инженеров сервисов и инфраструктуры и только их.

Особая близость с платежами и деньгами в целом сделала из меня параноика в хорошем смысле этого слова. Если это доступно где-то в интернете - это можно спиз… скачать.

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

Читаем, применяем, не даем злодеям и своим наделать глупостей.

Всех с наступающим! Увидимся в 2022.

Старая добрая традиция!

Спасибо, что вы со мной, что читаете меня, делитесь своими мыслями в комментариях и ЛС.

Я беру небольшой перерыв до 15 января, после чего продолжу производство контента в комфортном для себя и вас режиме.

Планы, как всегда, грандиозные. Исполнены, как всегда, будут не все. :)))

С наступающим!

#машины_aws

(голосом радиоведущего) Мы прерываем наш отпуск, чтобы поделиться важной информацией!

Multi-tenant архитектура очень сложная в реализации, но единственно верная при масштабировании на миллионы и милиарды клиентов. Однако риски поджидают не только при построении системы, но и при ее эксплуатации.

Исследователи из Orca Security нашли брешь в AWS CloudFormation, позволящую выполнять вызовы на стороне сервера, получая доступ к любому аккаунту AWS. Ранее уязвимость с похожими возможностями была найдена в сервисе Glue (ETL процессинг), на данный момент уязвимости в обоих сервисах устранены.

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