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

Что случилось с сеткой Facebook без диванных экспертов, конспирологии и спекуляций.

#машины_aws

Из поста выше: “But this took time, because these facilities are designed with high levels of physical and system security in mind. They’re hard to get into, and once you’re inside, the hardware and routers are designed to be difficult to modify even when you have physical access to them.”

Это напомнило мне ситуацию, когда я “зашил” управление инфраструктурой в AWS так, что только CloudFormation может вызывать изменения и только TeamCity может “дергать” CloudFormation.

Когда я кое-что сломал по ошибке (в т.ч. и в самом CloudFormation), мне пришлось бегать от лида до безопасника и от безопасника до СТО, чтобы получить конверт с MFA устройством от root’ового пользователя.

#машины_aws

Дубовый евангелизм хуже чем его отсутствие. Вот @count0_digest зачем-то просит объясниться (или оправдаться?) за каких-то чуваков, которые глупейшим образом решили набрать себе трафика и продать свой продукт.

Беглый гугл говорит о том, что Ottertune автотюнит облачные базы. Балдеж, зумеры придумали Oracle AWR/ADDM с красивым UI.

Оставлю продукт в покое, но проедусь по сантименту поста. Во-первых, ультимативные посты в духе You are doing XXX - низкий ход и чистой воды кликбейт. Во-вторых, считать чужие деньги и уж тем более расписывать, на что они тратятся, еще ниже. Не похер ли, на что тратит свое состояние Безос? Вы еще расследуйте, что это за дворец в Гелленджике.

Теперь к посту. Если убрать весь скучный флер, то можно обнаружить следующие советы:
1. Не использовать слишком большие машины
2. Не использовать настройки по-умолчанию
3. Не использовать слишком много PIOPS

То есть те же базовые вещи, которые рассказывают на курсе подготовки к AWS Certified Solutions Architect. Потрясающе! Хорошее повтори и еще раз повтори.

Я позволю себе сделать одну математическую проверку, так как не в первый раз читаю потрясающие разборы экономической эффективности облаков, и чаще всего цифры там взяты из потолка.

Я не хочу ковырять цифры по всему калькулятору, так что посчитаю только один экземпляр m5.8xlarge. По оценке ребят, такая дура c 32 (!!!) ядрами стоит 25к в год. Много, согласен. Только если купить резервацию на год с полной оплатой вперед, цена сразу срезается до 15к. Сумма 25 000 - цена по модели OnDemand которую используют либо по незнанию, либо недолго.

Не говоря уже о том, что правильно выбирать сервер СУБД по разным характеристикам, а ребята-тюнеры взяли сервер “общего назначения” и издеваются над ним как могут.

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

От себя замечу, что лучшая ACID СУБД в AWS это Aurora, и я искренне не понимаю людей, которые заходят в облако и покупают там OpenSource. А потом еще несут деньги всяким хулиганам, чтобы их базы “оптимизировали”.

#пятничное

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

#машины_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/

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