1851
Авторский блог Карена Товмасяна. Идеи, слова поддержки и критики отправляйте мне - @ThomasStorm. С предложениями рекламы не обращайтесь. I do not speak on behalf of my employer.
#машины_aws
Крайне неприятным и премерзейшим образом открыл для себя, что подключиться к Aurora Serverless DataAPI из другого AWS аккаунта нельзя. Даже если есть IAM роль с cross-account доступом и этим самым.
Спекулирую, что причиной тому вероятно отсутствие доступа к KMS ключам для дешифровки в Secrets Manager, опять же, другого аккаунта, и решается это путем создания того же секрета у себя, но такой возможности у меня нет.
Отвратительное открытие стоило мне несколько дней по проекту, дедлайны которого неумолимо надвигаются. Хорошо, что в запасе был план Б в виде прямого подключения из интернета к самой базе.
Причем хотелось переключиться на RDS Proxy, чтобы безопасно, так эта зараза тоже хочет в Secrets Manager логины пароли держать.
Как проект будет завершен и отправлен на золото, раскрою подробности. А пока разрешить позлиться.
#машины_разное
Дизайн документ нередко предшествует абстракт - пару-страничник, задача которого ответить на вопрос “Зачем?” и “Почему то, что есть сейчас, не работает?”. Ответить на “Что?” тоже можно, буквально одним абзацем. Но “Зачем/Почему” куда важнее.
“Зачем” в первую очередь помогает посмотреть на проблему с нетехнической точки зрения. Технарей же хлебом не корми, дай пописать или поделать что-то прикольное, а вот нетехнарский анализ направит энергию в правильное коммерческое русло. В эту секцию складывают либо бизнес проблему, либо расчеты полученной прибыли / сокращенных расходов, либо оба два. Математика дубовая - если на проект тратим 10 баксов, а зарабатываем 100, то это хорошо и проект надо пускать вперед.
“Почему то, что есть сейчас, не работает?” вопрос наименее важный, но куда более интересный с философской и прагматичной точки зрения. Подробное описание существующих систем и компонентов, окружений и ограничений даст хорошую перспективу на историю. А история объяснит и обоснует условия, которые привели к недостаткам.
И вот эта самая история нужна, чтобы ее не повторить в новом дизайне.
#пятничное #воскресное
"Он понял из этого отрывочного бормотания, что Сомс - отвергнутый, нелюбимый муж - восстановил свои права на жену путем величайшего, наивысшего акта собственности."
Какой интересный способ выбрал Джон Голсуорси чтобы в "Саге о Форсайтах" описать обыкновенное домашнее насилие!
#машины_разное #люди
Попался на глаза прикольный блог про “10 законов в технологиях от Амира”. Кто такой этот Амир, не так уж и важно, в чем он сам и признается, ибо это его наблюдения за карьеру.
Хочу подчеркнуть 3 основных закона, которые мне аукнулись.
“A technology that was built for good will eventually be also used for bad.”
Я бы сократил это до “A technology will eventually be also used for bad.”, причем так можно говорить не только про новые блестяшки, как (де-)генеративный ИИ, но и про внутренние системы, которыми неизбежно будут злоупотреблять или использовать не по назначению. Соответственно, я, как разработчик-владелец, должен не допустить такого поведения.
“The most painful, and least useful projects are migration projects, yet companies will replace technologies every 4 years.”
Вот это прям в самое сердечко, как говорится. За миграциями часто стоит рациональное зерно, мол старую технологию так тяжело стало обслуживать, что мы напишем новую, а потом на нее всех и переведем. В результате новый API абсолютно не совместим со старым, что приводит к долгим, болезненными проектам. Из хорошего: тот, кто это начал, получил долгожданное и заслуженное повышение.
“A highly communicative and collaborative team of average engineers, is going to outperform an uncommunicative and non-collaborative team of great engineers.”, и за ним же: “Left alone, a product team will optimize to the closest and easiest goal.”
Зачем в команде и нужны всякие активные техлиды, которые ходят на ковер к бизнесу за пониманием зачем вообще это все. Иначе команда занимается бурной деятельностью ради бурной деятельности, влияя на показатели, которые никому кроме них самих не интересны.
Прекрасно понимаю коллег, которые в индустрии ради того, чтобы приносить пользу, занимаясь любимым делом и постоянно развиваясь. Неприятная реальность такова, что такие мотивы должны соответствовать миссии коммерческой организации, которая в 9 из 10 случаев звучит: “Зарабатывать деньги.”
#пятничное
Уморительно, оказывается есть игра, где участнику надо угадать, кто по ту сторону чата - человек или машина.
https://www.humanornot.ai/
Один сеанс игры занимает всего 2 минуты, долго переписываться не получиться. Для себя нашел выигрышную стратегию, задавать вопросы о политике.
Не чтобы позлить лишний раз, а потому что о политоте у каждого человека мнение есть. 🙂
#жиза
В Амстердаме стоит Королевский музей, габаритами и наполнением словно Пушкинский в Москве. Внутри он разделен на несколько эпох нидерландской культуры и искусства, от деревянных церковных статуэток святых до легендарного автопортрета, тогда еще “двуухого”, Ван Гога и знаменитого “Ночного дозора” Рембрандта, вокруг которого построили стеклянный саркофаг.
Организация музея, честно скажу, сделана добротно. Вооружившись аудиогидом за деньги или бесплатно на собственном мобильнике, можно пройти тур как общего плана, т.е. от и до, так и тематический с глубоким уклоном в конкретную эпоху или работы.
Моя любимая картина там - "Испуганный лебедь" Яна Асселина, про работу которого я узнал из нидерландского мистического триллера “Арес”. Лебедь олицетворяет Яна де Витта, защищающего тогда еще Голландию от “сущего зла”, которое изобразили в виде собаки сутулой.
Но что вызвало больший интерес, так это средневековые картины религиозного толка. Прикладываю фотографию, сделанную моей любимой супругой, к этому посту и прошу обратить внимание именно на нее. Сюжет, как это было популярно в те времена, повествует о распятии Христа, которое, как мы знаем, произошло в эпоху римлян. Что это за странные одежды и, простите, графы и герцогини, я ума не приложу, да и на кой ляд фоном рисовать замок, которого в те времена точно не было, мне совсем непонятно.
Была мысль, что автор тогда испытывал те же трудности, что и художники, которые рисовали зверей по рассказам и на слух, из-за чего вы часто можете посмеяться над максимально всратыми львами, тиграми и птицами, но я не рискну взять ее как основную гипотезу.
В комментарии приглашаются - ха-ха! - искусствоведы или знатоки, кто желает мне помочь пролить свет на эту тайну. Уже неделю с этим живу и не могу понять, что к чему.
#люди
Питер Друкер, известный экономист и автор множества произведений в области управления, в своем труде The Effective Executive дает следующий карьерный совет: “Build on strengths, not weaknesses.”
На первый взгляд такая рекомендация кажется чем-то странным, да и конфликтует с идеей T-shape, но это далеко не так. Тот же T-shape подразумевает наличие основного навыка, в которую специалист постоянно инвестирует. Помимо этого навыка у специалиста есть общее понимание смежных областей - достаточное, чтобы сделать простейшую оценку или поддержать диалог.
Что же касается самого совета, то он полезен не дебютантам индустрии, но опытным кадрам, которые спустя Х лет решили сменить свой карьерный курс. Рекомендую не выбрасывать за борт накопленный багаж знаний и опыта.
К моменту моего трудоустройства в Убер, я поставил себе задачу перестать опираться на AWS, потому что чувствовал, что некий порог уже достигнут. В какой-то мере это удалось - теперь я занимаюсь бекендом, но сказать, что теперь бекенд стал моим основным навыком будет как минимум наивно. Мозгом я все еще сисадмин инфраструктурщик, который проектирует системы из расчета, где и как могут отстрелить компоненты или как тяжело их обслуживать. Опыт работы с AWS дал мне этот и много других поднавыков, которые и стали столпом моей экспертизы: анализ откупов и выбор наименее худшего сценария; умение договариваться; коммуникативные навыки и навыки презентаций; техническое письмо, и так далее. На этих качествах я и строю свою карьеру дальше, потому что в них я силен и могу конкурировать.
При этом я прекрасно осведомлен, что не владею теми же языками программирования на том же уровне, что и мои коллеги. Я осознанно принимаю решение не инвестировать в свои слабости слишком много, ведь эффективнее делегировать задачу тому, кто с ней справится куда лучше чем я.
Если же вами движет жажда знаний, и вы хотите покрыть все больше и больше предметных областей - это похвально и ничего плохого в этом нет. Раз у вас есть силы искать себя, то это может говорить только о том, что вы просто еще не заебались. 🙂
#люди
Я привык разделять карьерный трек инженера на "до" и "после", где "после" наступает после обретения так называемой "сеньорской мудрости". Дальше рост идет только в вертикальном направлении (лидерские и управленческие качества), либо горизонтальном (охват областей и технологий). И то чаще всего идет вертикальный рост.
Пресловутая “мудрость” появляется, как ни странно, вместе с “сеньорской заебанностью”, когда молодой энергичный заряд постепенно ослабевает, и инженер становится… медленнее. Меньше отправляет pull request’ов в день по сравнению с коллегами, меньше производит дизайн документов, тише ведет себя на встречах и так далее. Это вовсе не значит, что инженер потерял в производительности! Скорее инженер понимает, что здоровье у него одно, опыта у него о-го-го, а 25-летних людей по скорости переплюнуть просто невозможно.
Но причинять пользу предприятию надо, и инженер начинает работать эффективно. Находит дешевые и быстрые имплементации или вообще избегает их - ведь лучше всего работает тот код, который не написали! Делегирует задачи, опираясь на сильные стороны своих коллег (про это расскажу отдельно), доверяет им принятие решений в определенных областях и этапах; выбивает у своего руководителя человеческие ресурсы, чтобы не тянуть проект в одиночку; и начинает все чаще задавать нелюбимый всеми вопрос “А зачем?”. Инженер уже не следит за бесконечным потоком новых фронтенд фремворков и очередных витков эволюции в индустрии, потому что он уже опоздал их изучать, да и они все равно каждую неделю новые.
Вместо этого инженер прекрасно понимает, что его польза проявляется не в оперативных, а стратегических задачах. Какие проекты принесут большую пользу, какие же, наоборот, будут пустой тратой времени. Какую работу взять самому, чтобы не ржаветь, а что поручить перспективным коллегам с потенциалом.
Если вы поймали себя на мысли, что работаете и думаете не так - не беда. Вероятнее всего вы просто еще не заебались.
#жиза
Я увлекаюсь письмом и, заветами умных людей, работаю над качеством своих трудов. Чтобы становиться лучше как, простите за пошлость, контент-мейкер, я читаю много литературы - профессиональной и художественной - и изучаю тонкости писательского дела.
Раньше мне казалось, что письмо требует обязательного аттрибута "муза", но этот миф был быстро развеян. К моему удивлению, письмо это самая настоящая работа, и относиться к письму надо как к работе.
Первое подтверждение этому я это увидел в книге Карлоса Руиза Сафона "Игра Ангела", где главный герой, неудачливый писатель, поймавший большой куш и приобретя патрона, говорит своей ассистентке: "Утром садишься и не встаешь, пока не напишешь."
Несколько лет спустя, я читаю похожие правила от Стивена Кинга в его автобиографическом мануале о писательстве On writing. В самом труде много полезных советов и упражнений, очевидных и внезапных, но правило то же - не ждешь музу, просто садишься и пишешь. Будешь писать редко - стухнешь и просрешь идею.
К техническому тексту такой совет слабо применим, но я немало интересных тем для канала бездарно просрал, потому что поленился и не написал. Надо исправляться. :)
#машины_разное #машины_aws
История о том, как Amazon Prime, стриминговый сервис, мигрировал часть своего кода с AWS Lambda на монолиты в виртуальных машинах, вызвала пусть и дебильную, но предсказуемую реакцию.
Почему дебильную? Потому что любой, кто работал с AWS, знает, что рантайм Lambda поминутно дороже ЕС2, а serverless сильно дороже на больших мощностях. Serverless стек подходит для маленьких контор с минимальной нагрузкой (считай, не больше 100 запросов в секунду) и инженерным штатом из 3-5 человек, компетенции которых хватает на то, чтобы быстро написать код и запустить.
Все, что тяжелее, решается усилиями очень дорогих SRE/DevOps/PlatformEng, зарплаты которых дешевле расходов на инфраструктуру. Но сейчас не об этом.
Некоторое время назад я писал о том, что системные администраторы вернулись. В защиту монолита теперь высказывается доктор Фогельс, утверждая очевидную истину: прагматичность в принимаемых решениях.
Выходит, колесо Сансары таки сделало огромный оборот. Такими темпами еще и к частным ЦОДам на собственном оборудовании вернемся и будем правы.
#пятничное #люди
Открыл блог про то, "как создавать высокопроизводительные инженерные команды".
"Шаг 1: Наймите топовых инженеров"
Закрыл блог.
#люди
На Хабре вышла статья Практикума о том, как живется наставникам и ревьюерам.
Если вы учитесь и хотите видать картину "по ту сторону" или рассматриваете работу в ЯП - милости прошу. Мое видение там тоже есть.
#машины_aws #машины_разное
Моя лента в Твиттере - пачка академиков и технологов, от которых я узнаю всякие оккультные вещи навроде CRDT.
И вот в мою ленту занесло волной превосходный срач дискурс между Риком Хулиханом и Алексом ДеБри, темой которого были транзакции DynamoDB.
Из него я узнал, что:
1. Транзакции не предоставляют настоящий ACID. Item'ы, записанные в транзакции, доступны к чтению до того, как транзакция завершена (Read Commited). Это создает проблемы при конкурентном доступе.
2. Транзакции - дорогая в разработке фича, которой мало кто в итоге пользуется.
По схожей логике я не стал включать транзакции в серию DynamoDB Deep Dive. Неканонично.
Этот спор был особенно интересен тем, что Рик - бывший амазонец, эксперт NoSQL и изобретатель Single Table Design, а Алекс - автор DynamoDB Book.
Как если бы Алексей Миловидов и Брендан Грегг схлестнулись на тему производительности.
#машины_aws
У меня есть программа, которая выполняет следующее действие:
def pin_lt_version_to_asg(asg, asg_name, lt_name, lt_version):
return asg.update_auto_scaling_group(
AutoScalingGroupName=asg_name,
LaunchTemplate={
'LaunchTemplateName': lt_name,
'Version': lt_version,
},
)
autoscaling:UpdateAutoScalingGroup, и разрешаю это действие в IAM.
botocore.exceptions.ClientError: An error occurred (AccessDenied) when calling the UpdateAutoScalingGroup operation: You are not authorized to use launch template: myTemplate
#пятничное #новогоднее
Своих дорогих читателей, соратников и друзей, я хочу поздравить с наступающим, а для кого-то наступившим Новым Годом!
Оставайтесь здоровыми и находитесь в кругу близких вам людей и союзников. Пусть 2023 будет к вам благосклонен!
Мирного неба над головой!!
Искренне ваш,
Чел и Маш. :)
#анонсы #машины_разное
Согласованный кеш на базе Redis Cluster, Highload Serbia.
https://youtu.be/Sqxsm2oQDsw
Приятного просмотра!
#машины_разное
Усилия по ускорения Python продолжаются! Теперь Гвидо при поддержке инженеров из Меты намерен выкинуть из него GIL.
Нелюбовь к GIL сама по себе не новость. Из-за него для эффективной параллелизации приходится использовать multiprocessing, что неэффективно по памяти, хотя multithreading vs multiprocessing - отдельная дискуссия в сообществе.
Толчком к движению PEP-a вперед стало желание фейсбушников помочь, выделив на этот проект 3 человеко-года.
#машины_aws
Разработчикам CloudFormation Extensions, да и в целом команде CFN - мое почтение, такого удобства как человек, который хочет писать бизнес-логику и только, я с сервисами AWS не испытывал примерно никогда.
Собственно, в чем цимес. Разработчики CFN придумали расширения, в которые входят Modules (по аналогии с Terraform), Hooks (валидация изменений, но теперь на лету) и Resource Types - та самая мякотка, которая позволяет выкинуть в окно и сжечь Custom Resource со всеми его Lambda’ми.
От разработчикам расширения требуется строгое следование спецификации. Оно и понятно, ведь ресурс управляется бекендом CFN, а значит входящий тип должен спокойно перевариваться. В помощь разработчику дается cloudformation-cli с набором плагинов, в который оборачивается логика жизненного цикла ресурса.
Чтобы сгенерировать стартовый скелет, нужно просто напечатать cfn init и пройти интерактивный опрос. Обертка подготовит структуру проекта, сгенерирует модель, хендлеры, скелеты тестов, и даже набросает схему.
Посмотрев на результат работы init-скрипта, я поймал сильный вайб от SAM. Предположив, что мне нужно будет руками поправить сначала схему, потом переписать приблизительно все. Однако, открыв models.py, я увидел подозрительную строчку: # DO NOT modify this file by hand, changes will be overwritten
Пройдясь бегло по мануалу, я обнаружил волшебную команду cfn generate, которая на основе схемы генерирует весь шаблонный код, с (де-)сериализацией, валидаторами и прочим. От меня нужно только CRUDL нашлепать, да в сгенерированные тесты какие-то данные сложить.
Весь остальной опыт +- такой же как у SAM CLI, но вот генерация и регенерация кода - мое увожение, я был приятно удивлен.
#машины_aws
А если без шуток, то c us-east-1 часто творится какая-то хрень, потому что это старейший и крупнейший регион, причем не только у AWS, но и в целом в Северной Виргинии очень много ЦОД. Автор помнит мемы, когда какой-то реднек хотел "сломать интернет" взорвав серверные интернет провайдеров в этом штате.
С USE1 ситуация усложняется еще тем, что раньше этот регион ставился по умолчанию всем, кто заходил в облако впервые. Молодым же стартаперам невдомек были особенности регионального развертывания, да и запустить свежий продукт поскорее хотелось больше, чем думать о том, где именно его запускать. Чего уж добавлять, что AWS тестирует новые сервисы в Вирджинии и Ирландии (eu-west-1).
В итоге USE1 перегрузился, AWS сделал регионом по умолчанию Орегон (us-west-2), но дело это не сильно спасло, ибо вчерашние стартапы уже стали единорогами.
Собственно хозяйке на заметку: держитесь от USE1 подальше. А про мульти-региональные приложения вы и без меня знаете.
#машины_aws
Для CloudFormation был разработан линтер cfn-lint, который на базе разных правил проверял шаблон на вшивость. Одной из моих любимых фишек этого линтера была возможность написать свое правило на том же языке, что и сам линтер, т.е. на Python.
А раз для написания правила используется верхнеуровневый язык программирования, то положить в это правило можно буквально все что угодно. Автор помнит времена, когда он злоупотреблял Boto3, чтобы в рамках правила делать вызовы на AWS API и делать более точечные проверки, например, если hardcoded ARN ссылается на существующий ресурс.
У таких свистоплясок есть очевидный недостаток. Например, если линт проходит в рамках CI, то у сборочного агента должен быть доступ в AWS, не говоря уже о том, что мы нагружаем линтер функциональностью, для которой он никогда не предназначался.
И вот я в очередном туре по кишкам CFN, изучая расширения, нашел расширение Hooks. Hooks проверяют разные типы ресурсов на соответствие определенным правилам, но в этот раз правила проверяются на стороне самого CloudFormation. Может показаться, что это бесполезное дело, ресурс дешевле проверить до развертывания, а не во время развертывания.
С другой стороны можно застраховаться от тех, кто катит CFN вручную и не применяет линтер, или если приходящие изменения в вашу инфраструктуру не под вашим контролем. Hooks это такой способ защититься от неприемлемых изменений, поскольку они не допускают абьюза со стороны ленивых девопсов.
Но для этого нужно побороть сначала свою лень и написать много правил на все случаи жизни. 🙂
#машины_разное
В пользу, извините за тавтологию, противников всего нового и современного говорит необходимость обслуживания старой системы на период миграции, а иногда и на более долгий срок, если миграция затянулась или вовсе отменилась.
Один из законов Лемана гласит, что ПО либо эволюционирует, либо становится несопровождаемым и бесполезным. Это может привести к тому, что экономия человеческих ресурсов от новой красивой системы нивелируется при условии, что старая система все еще существует, но в нее уже не инвестируют.
Это не отменяет того факта, что рефакторинг существующей системы, особенно при большой текучке кадров, становится непосильной задачей, из-за чего команда принимает решение бросить все и написать новую с нуля. Это является не ликвидацией технического долга, а скорее объявлением дефолта, что, честно скажу, рабочий вариант при условии, что технический долг уходит на свалку вместе с legacy. Иначе остаемся в долговой яме надолго.
Поэтому я с пониманием и уважением отношусь к тем, кто продолжительно инвестирует и обслуживает старую скучную тусклую систему, за доработки которой не светит никакого повышения.
#анонсы
4-ого июля буду выступать на HighLoad в Сербии, рассказывая о том, как можно сделать Redis строго-консистентным в кластерном режиме.
Буду рад встретиться очно с коллегами, кто окажется там же в те же дни. 🙂
#машины_aws
К слову о интересных темах - смахнем пыль со старого срача о системах управления облаками, т.е. Infrastructure-as-Code. Так получилось, что я снова изучаю возможности CloudFormation и нарвался на нововведение под названием Language Extensions.
Language Extensions это Template Macros, разработанные AWS. Сами макросы представляют собой блоки шаблона, которые “трансформируются” на лету, делая шаблон динамическим и позволяя с ним химичить, как душе угодно.
Например, AWS SAM это самый, что ни на есть, макрос-сахарок, который абстрагирует под собой неудобства описания serverless ресурсов.
На момент этой записи Language Extensions умеет конвертировать YAML ключи-значения в JSON-строки, включает поддержку Intrinsic Functions в - наконец-то - Update/DeletionPolicy, и с какой-то целью добавляет новую функцию Fn::Length.
Что привлекло мое внимание, так это обсуждение новых фишек этой разработки, а именно вот эта ветка. Да, вам не показалось, мои дорогие ненавистники многострочных шаблонов. В CFN собираются внедрить циклы. Возможно, затем и придумали Fn::Length.
При чем здесь срач, скажете вы? При том, что львиная доля холиваров CloudFormation vs Terraform vs CDK vs Pulumi нередко сводились к тому, что последние 3 инструмента могут использовать цикличность для описания ресурса один раз, а создания многажды, а мой любимый целофан - нет. Поэтому, создавая VPC с 6 подсетями, 3 публичными и 3 приватными, вы 6 раз описывали подсеть, 6 раз описывали ассоциацию таблицу маршрузитации с подсетью, и неизвестно сколько еще дубликаций вам пришлось бы сделать позднее. Шаблон становился огромным набором копированного дублированного кода, который не хочется ни читать, ни тем более обслуживать.
Наконец-то за эту проблему взялись сами владельцы сервиса. Это создает надежду, что сервис живет и не станет полумертвым backend’ом для CDK. А может и станет, кто ж его знает.
#машины_разное
Насчет смены стратегий, архитектуры и направления, читай "начали за serverless, закончили за монолит", есть важный нюанс под названием "контекст". Можно было бы пройтись по Amazon Prime, но эту историю только ленивый не мусолил. Давайте из моего опыта.
🟢Ситуация 1: CRUD хранилище
Спроектировали систему-хранилище. Модель данных простая до безобразия:{
UserId: UUID,
ItemId: UUID,
SchemaName: str,
Payload: binary
}
Поле Payload представляет собой закодированный в Apache Avro набор данных, схема которого описана в отдельном реестре. Пользователь может декодировать на стороне сервера - тогда сервер вернет JSON, или на стороне клиента - тогда сервер вернет base64 строку, а там уже пусть клиент сам схему разбирает.
Целесообразность: эффективно хранить данные, максимальная гибкость клиенту. Сервис, предполагается, будет иметь строгую структуру данных и выполнять функции CRUD.
🟡Ситуация 2: CRUD хранилище с внешними интеграциями.
Проходит некоторое время, и появляется потребность помимо записи в базу делать вызовы туда-сюда, дополнять поле Payload новыми данными и класть в базу. Чем городить костыли на текущем сервисе, принимается решение сделать Отдельный Слой Абстракции™, который будет эти вызовы делать.
Целесообразность: иметь отдельный “интеграционный” слой, не выходить за рамки текущего сервиса.
🟠Ситуация 3: CRUD хранилище с внешними интеграциями, динамическими полями и строгой типизацией десериализованных данных.
Как вы догадались, давая клиентам самим десериализовать данные, ловим поток вопросов в поддержку о том, как правильно их десериализовывать. Принимается решение сделать еще один слой абстракции, который десериализацию делает со строгими типами и выдает клиенту. Вдобавок к нашей модели добавляются новые поля, которые рассчитываются динамически через RPC. Делаем новый слой абстракции.
Целесообразность: иметь отдельный уровень абстракции, который берет на себя сложность десерализации и расчета динамических полей.
🔴Ситуация 4: А какого хрена мы ходим через 3 сервиса, чтобы вернуть одну сущность?! Почему у нас 80 мс на проксирование запросов?! Давайте переделывать в угоду эффективности.
Между Ситуацией 1 и Ситуацией 4 прошло без малого 6 лет. Если бы вы, как и я, устроились в контору недавно, вы бы, как и я, решили, что систему проектировали и проектировали наркоманы и смузихлебы.
Тут надо сделать ремарку и вновь упомянуть моего приятеля Серегу П., словами которого я руководствуюсь: "Мне очень экономит время задавание вопроса самому себе, когда я вижу какую-то дичь: "При каких условиях я сделал бы вот эту ебалу?"
Ситуации с 1 по 3 я описал, опираясь на дизайн документы, предшествовавшие каждому слою. В каждом, повторюсь, каждом дизайне все было логично, потому что контекст был именно такой. Предполагали ли инженеры-архитекторы тогда, во что вырастет система сегодня? Сомневаюсь. Представляют ли они сейчас? Вполне себе да. Для опыта не существует алгоритма компрессии.
#машины_разное
Обещанный пост про блокировки!
Если совсем просто, то механизм блокировок (lock) реализуется с помощью обычной хеш-таблицы/словаря/чего-бы-то-ни-было. Ключом к этому словарю обычно является сам объект блокировки, а значение - некий идентификатор/токен замочка.
Объектом блокировки в данном контексте может быть что угодно. Довольно древний, по современным меркам, storage engine MySQL под названием MyISAM блокирует целые таблицы, а более новый InnoDB - строки. Продвинутый механизм блокировок в PostgreSQL, который задействует snapshot isolation - блокировка назначается на строку, но в определенный момент времени! Записи, в том числе обновления и удаления данных, в таблицах Postgres, работают в режиме append only, заправляя это все крепеньким vacuum’ом, ну или как там это называется, знатоки пусть меня поправят.
Локальная система блокировок существует в памяти СУБД.
1. Подключился к СУБД
2. Запрашиваешь “замочек” на строку Х в таблице У (acquire lock)
3. Получаешь некий токен “замочка” - механизм тебя “запоминает”
4. Производишь запись, “освобождаешь” замок (release lock)
Другие транзакции, точно так же приходят за замком и смиренно ждут, пока ты его освободишь. При этом блокировки могут быть на чтение и на запись, простые и двуфазные (тут уже идите читать кабанчика от Клепманна). В целом работа с механизмами блокировок в пределах одноузловой система простая и понятная.
Но если вы работаете в смузихлебном стартапе, то скорее всего вы живете в условиях распределенных систем, а значит у вас распределенные хранилища, а возможно и распределенные системы блокировок!
И если вам сейчас показалось, что я несу откровенную чушь - то зря. В SRE книге Гугла в 4-ой главе рассказывается про распределенную систему блокировок Chubby. Другим примером распределенного замочка может быть ситуация, когда вы хотите заблокировать некую сущность в пределах нескольких независимых систем. Распределенный замок может быть реализован и в рамках самой системы, например Redlock в Redis. Мы к этому еще вернемся, но тут важно уточнить, что Redlock это фича для потребителя, а не внутренний механизм для работы с запросами.
Как любая распределенная система создает неприятный головняк, так и распределенные блокировки тоже. Представьте себе следующее: процесс взял замок, начал обрабатывать транзакцию, а потом умер. Мы можем решить это с помощью срока жизни (TTL) замка, но что если процесс не умер, но задержался на срок дольше TTL?
Решается это еще интереснее, и вот тут я хочу поделиться наинтереснейшей статьей от автора того самого Кабанчика. Там вам и про блокировки, и почему Redlock говно. Не потому что Redlock, а потому что в распределенных системах все говно, если хорошенько докопаться.
#жиза
Как похорошела Москва бюрократия при Собянине Мишустине!
В январе 2023 я приобрел нидерландское гражданство и, согласно миграционному законодательству, должен отказаться от русского паспорта.
С Россией меня преимущественно связывают личные отношения, так что я со спокойной душой приступил к выполнению своих обязательств. Запускать процедуру выхода из гражданства в России мне не хотелось, а значит нужно прогуляться до консульства в Гааге 3 раза, чтобы:
1. Выписаться из отчего дома
2. Забрать справку, что я выписался из отчего дома
3. Подать заявление на выход из гражданства
Задача тривиальная, но запись в консульство еще во времена COVID-19 было тем еще приключением, а с 22-ого года стала практически невозможной. Дровишек в костер подкидывает и местное правительство, проводя сокращение штата русских консулов в Нидерландах... Словом, на момент написания этого поста запись в консульство в Нидерландах невозможна.
Нидерланды дали мне полгода, чтобы подать заявление на выход из гражданства, в противном случае новое гражданство у меня аннулируют. А значит мне надо уложиться, хотя миграционные инспекторы очень терпеливые создания, и раздают отсрочки без лишней волокиты.
Здесь надо сделать одну ремарку о бюрократии. В Нидерландах я практически любое действие я совершаю онлайн, авторизуясь с помощью ЭЦП, а визиты в офис миграционной службы нужны только чтобы сдать биометрию или забрать бумаги. С Россией же у меня была стойка ассоциация “собери 10 бумажек из 12 разных мест, приходи в определенный день недели”. Впрочем, с русской бюрократией я дел практически не имел мало с как переехал.
Так вот, в чем казус: почти все бумаги для выхода из гражданства РФ, кроме справки о выписке, я могу сделать онлайн и в электронной форме с ЭЦП! А вот чтобы уведомить миграционную службу Нидерландов о том, что я вышел из гражданства, мне нужно отправить бумажное письмо с переведенной справкой от консульства! Более того, чтобы запросить отсрочку (!!!) дедлайна, я тоже должен отправить бумажное письмо!
Чья бюрократическая машина теперь эффективнее - вопрос открытый.
#машины_разное
Поддерживать академический интерес к ИТ чем дальше, тем сложнее. Один из работающих для меня методов - прослеживание интересных разработок на ранних этапах их развития.
Такого рода поиск познакомил меня с CRDT и проектом Automerge. Но для того, чтобы объяснить сначала рассказать, как работают конкурентные записи, и при чем тут Google Docs.
Буду считать, что механизмы блокировок, зарекомендовавшие себя в реляционных базах, мы знаем и понимаем - кстати, дайте знать, если нет, раскрою мысль в другом посте. В других случаях, особенно с использованием алгоритмов консенсуса, действует правило Last Writer Wins.
В так называемом "коллаборативном" ПО (доски Miro, Google Docs), важно обеспечивать конкурентный доступ без перезатирания данных. В Google Docs используется механизм Operational Transform, который обслуживает транзакции на уровне операций. CRDT же опирается на состояние - то есть вы набили текст в документ, состояние документа зафиксировалось и улетело на сервер. Далее сервер уже сверяет разные состояния от разных авторов.
Чем же это интересно? Тем, что CRDT направлен на децентрализацию и local-first коллаборацию. Его идея - я должен иметь свои изменения в том виде, в котором указал, а дальнейшая резолюция должна быть под моим контролем. Технические реализации CRDT обеспечивают работу не только с центральным сервером, но и децентрализованно.
Что и делает эту разработку, на мой взгляд, перспективной. Особенно учитывая современные экономические и политические тенденции.
#машины_разное
Утечки утечками, а в этом коде еще разобраться надо будет!
Из очевидного вижу статический анализ кода на какие-нибудь CVE + захардкоженные секреты.
Сам код у себя поднимать смысла нет, намучаетесь с зависимостями и внутренними инструментами сборки.
Безопасникам Яндекса сил и терпения. Разгребать это придется долго, знаю по печальному опыту.
#машины_разное
Я посмотрел на The state of open source software и заметил пару очень интересных моментов, которыми хочу с вами поделиться.
Python выбился на второе место среди популярных языков.
Обещания Гвидо ускорить Python не прошли даром, да и высокий тренд на машинное обучение подпитывает популярность языка. Прибавьте к этому растущее количество bootcamp’ов, воспитывающих новое поколение инженеров с нуля и использующих этот язык с его низким порогом вхождения, и получите закономерный результат.
Конторы продолжают инвестировать в open source.
Что не новость, да и хитрость. Такие проекты повышают имидж и привлекают большое количество бесплатной рабочей силы. 🙂
HCL - самый быстрорастущий язык на GitHub.
Вот это очень интересно при условии, что HCL не язык программирования, а DSL. 🙂 Что однако не мешает писать на нем скрипты, судя по его README.
#машины_разное
Тонкое искусство наблюдаемости (оно же observability), прошло не один десяток лет, прежде чем заматереть.
Поначалу был дубовый мониторинг - смотрели данные датчиков, состояние железа и процессов ОС, затем научили приложение рапортовать о своем состоянии теми же метриками.
После SRE научил не просто мерять сигналы, а выработать некий стандарт из 4 золотых сигналов , тот же Брендан Грегг использует метод USE (Utilisation/Saturation/Errors) для выявления проблем с производительностью.
Потом пришли трассировки и структурированные широкие события, и наблюдаемость стала сама по себе отдельной сложной дисциплиной, как, впрочем, бывает с любым витком эволюции любой практики в ИТ.
Если отвлечься от технической части, то наблюдаемость нам нужна, чтобы ответить на вопрос “Оно работает?”, и этот вопрос куда сложнее, чем многие думают.
Автор этих строк помнит активные дискуссии на том же Хабре и тематических чатах времен 2014-2018, когда сильные умы мира сего задавали эти титанически сложные вопросы “А что значит не работает?”, “А что мы понимаем под работой?” или мое любимое “А когда оно у вас в последний раз работало?”.
Очевидно, что работающая система это та, которая выполняет свои задачи. Система может работать в нормальном или деградированном режиме, может совсем не работать, тут уже как мы контракты написали. Для того, чтобы определять “рабочесть” у нас есть огромный пласт методов и инструментов. Все они направлены на то, чтобы научить приложение говорить от своего лица о своем самочувствии, так что в целом все логично.
Но я не зря написал про толкования “рабочести” и изменчивость нашей индустрии. Видите ли, система может быть по всем фронтам “здоровой”, значения метрик приемлемыми, пейджер тихим, дежурство спокойным… А система все равно не будет работать! 😱
Вернемся к предыдущему толкованию “работает” - т.е. система выполняет свои функции. Функции, как мы понимаем, получаются из запросов бизнеса в виде ТЗ, историй и чего бы то ни было, но задача системы - выполнять задачу бизнеса. И вот тут может быть функциональный казус, когда система вроде бы и работает, но задач своих не выполняет.
Определить это немногим сложнее, чем набросать метрик и логов в нужных местах нашего кода. Достаточно взять бизнес-метрики на определенные процессы, строить по ним графики, выявлять аномалии и несовпадения. Лукавить не стану, на практике это не так тривиально, как на словах.
Например, если у нас есть определенный SLA на техподдержку, то рабочая система такая: 10 человек завели по жалобе, 10 жалоб создалось, 10 жалоб получили по назначенному специалисту ТП, 10 жалоб разрешилось в рамках SLA. Любое отклонение - вне зависимости от причин - является симптомом нерабочей системы. 🎉
---
Вижу новую главу наблюдаемости, которая так и просится стать очередным трендом. Я, можно сказать, только только ступаю на эту новую землю и надеюсь, поделиться своими результатами и наблюдениями в корпоративном блоге, но моей аудитории предлагаю почитать, ну или послушать, как это делают в одной экстремистской, согласно некоторым законам, организации.
С наступающим!