1851
Авторский блог Карена Товмасяна. Идеи, слова поддержки и критики отправляйте мне - @ThomasStorm. С предложениями рекламы не обращайтесь. I do not speak on behalf of my employer.
#прощальное
Вы могли заметить, что из канала исчезли комменты, а чат был удален. Подробнее о том, что происходит здесь.
#машины_aws
Пожалуй, лучший инцидент, что я когда либо видел.
Если вкратце:
1. Управление DNS записями для DynamoDB отвалилось, в итоге:
2. Эндпоинты DynamoDB (в том числе для внутреннего пользования) отвалились, в итоге:
3. Storage backend, которым выступала DynamoDB, одного из компонентов control plane EC2 отвалился, в итоге:
4. Отвалился NLB, который не мог следить за событиями EC2.
Очень радует, что AWS решил минимальными усилиями решить конкретную проблему, а не сделать отдельный внутренний Kinesis как тогда с инцидентом CloudWatch и Cognito.
Да и не пользуйтесь us-east-1, сколько еще повторять. Новые фичи раньше всех того не стоят.
#пятничное
Инженер-программист Шивам Баларани рассеянно смотрел в монитор. Через блеклый интерфейс JIRA ему в ответ смотрела скупо описанная задача в спринте. Шивам Баларани немного сщурился, наклонил голову набок, скопировал текст задачи и открыл корпоративный ChatGPT в новой вкладке. Включив режим «Deep Research», он начал промпт со словами: «Тебе нужно решить следующую задачу». Вставив текст из JIRA, Шивам добавил уточнящих деталей касательно языка, версии, платформы, зависимостей, и, немного подумав, разрешил ChatGPT придумать собственное решение или предложить уже существующее с открытым исходным кодом на GitHub.
Ответив на уточняющие вопросы, Шивам Баларани оставил нейросеть заниматься своей работой и пошел налить себе кофе. Вернувшись, закончив просматривать мотивирущее видео про образ жизни на Youtube и допив кофе, он вернулся к вкладке с ChatGPT. Компьютер подготовил для него большой и красивый отчет. Шивам бегло пробежался по рекомендациям, с облегчением увидел подходящее, на взгляд нейросети, решение, и скачал все в Markdown файл. Затем он открыл терминал, прошел в директорию с кодовой базой, запустил в ней Claude Code и впечатал следующую инструкцию: “Ты работаешь над фичей и твоя задача написать функцию в директории transformers. Подход к решению описан в документе /home/shiwam/gpt_research.md.”
Нажав Enter, Шивам отправился за второй чашкой кофе. Вернувшись и отвлекшись на социальную сеть X (ранее Twitter) на полчаса, инженер с неудовольствием увидел, что Claude Code набросал черновой вариант кода и ждал отмашки на продолжение. Дав компьютеру добро на проведение дальнейших операций без отмашки в будущем, Шивам вернулся в социальную сеть Х (ранее Twitter). Уже через 15 минут у Шивама был готово рабочее решение. Только он приготовился подключиться к ответственной миссии финальным “git checkout -b jira-123 ; git add . ; git commit -m ‘JIRA-123 Add transformer feature’ ; git push”, как ему в голову пришла идея. Он добавил еще одну инструкцию: “Ты старший инженер-программист и должен провести код ревью изменениям. Обрати особое внимание на согласованность стиля в кодовой базе, организацию кода, читаемость и лучшие практики языка”. Через пару минут, Claude Code переквалифицировавшийся из автора кода в ревьюера, сделал самому себе несколько замечаний. Шивам, заметно уставший к концу дня от дешевого дофамина, ответил ему коротким “apply these recommendations”. Подождав немного времени, он еще раз прошелся по коду и отправил pull request на проверку коллегам.
На следующий день, pull request представлял собой смесь LGTM и различных комментариев тут и там. Шивам Баларани решил делегировать задачу своему нейроассистенту и скопировал каждый комментарий, добавляя к какой строке и файлу этот комментарий относился. Дав машине целевые указания, инженер-программист решил скоротать время в Instagram. Подняв голову через 10 минут, он закатил глаза от того, что Claude Code закончил черновой вариант и снова ждал отмашки пользователя. “Надо настроить авто-да,” - подумал Шивам, ожидая окончания генерации кода. Повторив Git-ритуал, он отписался в Slack канале “addressed” и снова залип в телефон. Через полчаса, когда pull request перешел в состояние Approved, он нажал кнопку Merge, перенес задачу в состояние QA, нанес курсор на кнопку закрытия терминала и нажал на нее. Его насторожило то, что на долю секунды что-то промерцало в диалоговом окне Claude Code. Инженер-программист Шивам Баларани был готов поклясться, что Claude Code попрощался с ним со словами: “А ты-то нахуя нужен?”
Если вы большое предприятие, которое хочет масштабировать управление изменениями надежно и безопасно, то… то пишите это сами, потому что все продукты предлагают наитупейшие компромисы там, где их можно избежать. Команда из 6 человек напишет такое решение за квартал. Если не знаете как приступиться, пишите, договоримся о консультации (сомореклама это или нет - решайте сами).
Читать полностью…
#машины_разное
Само понятие «флаг» может произвести впечатление, что это какой-то тумблер «вкл/выкл», который захотел включил, захотел выключил.
Самый простой флажок будет выглядеть именно так, но ✨настоящая магия ✨ прячется за условиями выполнения, которые могут быть статическими и динамическими! Давайте на примере расскажу про Configuration Driven Development (далее CDD).
Итак, у нас есть флаг и есть часть кода, где мы спрашиваем значение флага. Флаг всегда возвращает «да» или «нет» или строку с числом, но логика внутри флага может быть умнее.
Самый простой флаг, который определяет какой адрес базы дать на базе энва будет таким псевдокодом на YAML:default: prod-db
flags:
- test:
if:
- env = testing
then: test-db
- prod:
if:
- env = production
then: prod-db
Опытный инженер увидит подозрительное default, которое может нагнать страх, и этот страх вполне оправдан. Выбирая между «передаем по умолчанию прод, и возможно не тот енв получит доступ» и «передаем null, и приложение упадет», я бы выбрал второ- исходя из ситуации.
А что если нам нужно обслуживать тестовый трафик в промышленной среде? Тогда можно опираться на заголовки запроса и обогатить нашу логику.default: prod-db
flags:
- test:
if-one-of:
- env = testing
- req-tenancy = test
then: test-db
- prod:
if-one-of:
- env = production
- req-tenancy = prod
then: prod-db
А что, если нам нужно обеспечить теневой трафик, который живет в рамках теста, но нуждается в "живых" данных? Тогда можно использовать использовать логическое умножение: default: prod-db
flags:
- shadow:
if-all-of:
- env = testing
- req-tenancy = shadow
then: prod-db
Тут вы наверняка скажите: «Карен, ты упоролся, connection string к базе инициализируется на старте приложения, а ты предлагаешь это делать на каждый запрос?!», а я вам отвечу: «Не душните, взял самый наглядный пример, чтоб всем было понятно!»
У CDD очевидно есть и бизнес применение, например решать в какой PSP передать платеж на базе параметров платежного поручения. Представьте себе такое:flags:
- dest1:
if-all-of:
- country-code = BR
- payment-method = payment_card
- card-type = debit
then: psp1
Количество таких параметров ограничивается вашей фантазией, а вы на базе десятков таких конфигураций сделали самый что ни на есть платежный маршрутизатор! Причем новые маршруты можно добавлять не трогая приложение вообще.
Я не зря оговорился о разношерстных параметрах, ведь диверсификация параметров это необходимая составляющая экспериментов!
У вас бывало такое, что вы запускаете любое мобильное приложение, а оно ПОЧЕМУ-ТО ведет себя иначе? А потом точно так же ПОЧЕМУ-ТО ведет себя как раньше?
Это означает, что вы попали под эксперимент. Эксперименты это целые наборы флагов, которые принимают в качестве параметров… да вообще что угодно, от страны и устройства до пола, возраста, и последних 10 пролайканных фоток. Эксперименты проверяют жизнеспособность фич и их полезность, поэтому ставятся на длительный период и измеряют бизнес метрики навроде конверсии. Если цифры идут вверх, расширяем поле экспериментов дальше, пока не уйдем на 100%.
Платформа экспериментации - красивая обертка над системой конфигураций, feature flag’ов, мониторинга и механизмов раскатки, и стоит на вооружении у всех больших дядечек и тетечек.
В следующем посте постараюсь собрать для вас подходящие инструменты, с которыми вы можете использовать feature flag’и с минимальным ущербом для здоровья.
#машины_разное
Рассказал на Tech Internals Conf, он же англоязычная вариация Highload++, про миграции API.
Рекомендуется к просмотру аудитории любой степени подготовки.
#машины_разное #пятничное
Хотите знать почему у нас скоро уберут удаленку? Потому что иначе Северная Корея украдет деньги наших работодателей!
Мне в ящик упал умопомрачительный отчет DTEX, в рамках которого специальная группа северо-корейских айтишников устраивается на удаленную работу и ворует корпоративные секреты и даже деньги! Результат их деятельности используется для финансирования ядерной программы.
Уверен, они даже свою зарплату Ким Чен Ину отправляют.
#машины_разное
С небольшой ноткой усталого садизма наблюдаю за негодованием одно-зональников, когда у Яндекса отстреливает яйцо зона. Принимаю аргументы, что межзональный трафик денег стоит всегда, а Яндекс ломается только раз в год.
Хотя другой инцидент меня зацепил посильнее, а именно «Не было такого!» инцидент у Оракла с кражей учетных данных для входа в их облако. Ухх!
Тут надо сделать несколько заметок, от которых у меня идет холодок по коже.
Во-первых, взлом произошел по двухлетней уязвимости, которую совсем не ждешь на SSO или другом публичном эндпоинте. С точки зрения безопасности облачных систем это треш и неприемлемо, а Оракл можно еще по PCI-DSS за такое отругать.
Во-вторых, черношапочник получил доступ к зашифрованным паролям, что вообще странно, учитывая что пароли принято хешировать (тут пусть знатоки SSO и всяких oAuth меня поправят)
Ну и напоследок, переход в режим отказа, который прозвучал от представителей Оракла, понятен, но некрасив. Вендоры не любят признавать инциденты публично, вспомнить хотя бы городскую легенду о «одобрении VP, чтобы объявить инцидент в AWS», потому что за публичным признанием потом собирается пачка коллективных исков. Но Оракл хоть и признался своим клиентам о взломе, публично должен был объявить о внутреннем расследовании и отказаться от дальнейших комментариев. По опыту вынужден сказать, что это единственное правильное кризисное управление в таких ситуациях.
#новогоднее
Когда бывшая руководительница спросила, получаю ли я до сих пор удовольствие от работы, я честно ответил, что получаю, но уже иного рода.
Раньше это удовольствие было от неизведанного, а теперь от того… насколько все плохо. Этакая мазохистическая радость от очередной жесточайшей аварии или секретного проекта с неадекватно сжатыми сроками.
Лукавить не стану, работать в таком режиме вредно, но каждый кризис делает кожу толстой, а разум холодным.
Мои дорогие читатели, я желаю, чтобы ваша профессиональная жизнь наделяла вас всеми атрибутами прохождения кризисов, но эти свойства нужны были только для решения профессиональных задач. Вне конторских стен пусть вас окружают близкие люди заряжающие вас положительной энергией и вдохновляющие жить жизнь.
С наступающим Новым годом!
Анонс № 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 особенно важен, потому что в отличие от комплюктеров, люди и часы в сутках не масштабируются.
#новогоднее
Если бы мне пришлось охарактеризовать 2025-ый год одним единственным словом, я бы назвал слово «принятие».
Принять пришлось многое, что-то обратимое, что-то неизбежное, что-то из профессиональной среды, что-то из личной жизни, что-то в других, а что-то в себе.
Принятию на удивление помогает открытость. Открытость не навязанная повесткой, но открытость искренняя, сродни доброжелательному любопытству. Открытость дает нам новые контакты и связи и открывает доступ к новым знаниям и опыту. Принятие же помогает держать котелок в стабильном состоянии, особенно на фоне вечно меняющегося всего.
Мои дорогие друзья, я поздравляю вас с наступающими, а кого-то и с наступившим новым годом и хочу пожелать вам открытости: открытости к другим, особенно тем, кто придерживается диаметрально другой точки зрения, открытости к себе, особенно к своим потаенным талантам и желаниям, принятию жизни, какая она есть, и сил на то, чтобы сделать 2026-ой год незабываемым в самом лучшем смысле этого слова.
#машины_разное
Моя любимая рубрика «Разработчики СУБД знают лучше».
Вы наверняка помните, сколько шума вызвало в свое время использование O_DIRECT. Теперь разработчики пошли еще дальше - решили что io_uring для плебеев и сделали свой асинхронный ввод-вывод внутри Postgres.
Обожаю 🤤
Вот это я конечно не попал в лимиты телеграма. 🤦♂️
Читать полностью…
#машины_разное
Итак, я хочу управление конфигурацией отдельно от кода, желательно с поддержкой код ревью, работающее на любой платформе. Я сразу отбрасываю GO Feature Flag (хотя задумка прикольная), и останавливаю свое внимание на Unleash, Flagsmith, Flagr и Flipt. И тут начинаются дурацкие компромисы.
Код ревью есть только у Flipt. При этом все они предлагают инкрементальную выкатку с ограничениями (“Включи эту фичу для владельцев айфонов с новым прикольным стекляным иосом.”), но Unleash предлагает еще и концепцию strategy. Глядя в доку, это все еще выглядит как набор ограничений, где мы передаем параметры навроде клиента, пользовательского идентификатора и так далее. Зачем тут было выпендриваться - непонятно.
Все варианты интегрируются с мониторингом по-своему, а точнее никак. Например прикрутить график из Графаны к интерфейсу feature-flag’а чтобы наблюдать за метриками во время релиза нельзя. Но зачем-то можно экспортировать метрики самих управлялок, например активацию/деактивацию флагов - но я бы это делал через само приложение.
Отдельно стоял вопрос доставки конфигурацией на клиент, это важный аспект с точки зрения производительности. Следите за руками:
1. Нам прилетает запрос, приложение должно решить, включать флаг или нет.
2. Если для этого нам нужно обратиться к серверу - прибавляем еще один запрос на сервер.
3. Пусть каждый запрос на сервер стоит 10 мс - потому что сетевые запросы не бесплатные
4. Если на пути нашего запроса в бизнес логике есть 5 проверок флагов, то мы просто так накидывем себе 5 * 10 мс задержки.
И это не говоря о надежности, потому что SLO нашего эндпоинта будет зависеть от SLO API feature flag’а.
Очевидным решением является кеширование флага на клиенте с проактивным eviction policy - то есть клиент раз в минуту, например, опрашивает сервер и смотрит не обновились ли значения или условия флага, а при выкатке клиент получает нотификацию и обновляет все флаги. Вот тут уже… прям плохо. Все поддерживают polling, Unleash из коробки поддерживает нотификации, которые обновят значение флагов; Flagsmith это делает через webhook’и, но не во всех клиентах это поддерживается; Flagr и Flipt это не умеют вовсе.
А что по платным облачным решениям? Ну тут не то, чтобы прям лучше. Каноничный откат есть только у Kameleoon, он выключает фичу если какие-то метрики выходят за допустимые рамки. LaunchDarkly за каким-то хреном сделали kill switch, который требует ручной активации от оператора. Чем это лучше отката фичи на 0% - непонятно - но разработчики божатся, что это быстрее. Охотно верю.
У публичных клавдиев все еще хуже. Более-менее рабочее решение дает AWS AppConfig - тут тебе и кеширование, и поддержка автоматических роллбеков на базе алертов из CloudWatch. У GCP нет такого сервиса вообще, Azure App Configuration не умеет откатывать флаги.
С локальным кешированием у большой тройки двойки все еще тупее. AWS AppConfig предлагает ставить агента, который будет кешировать флаги, при этом этот клиент может ставиться в качестве sidecar’а для контейнеров и даже Lambda функций. Учитывая, что Lambda должна быстро отработать и умереть, польза от этого sidecar’а только в том, чтобы переиспользовать теплый контейнер с закешированной конфигурацией флагов. Стоит ли в свежем контейнере функции оставлять возможно протухший набор флагов вопрос дискуссионный.
А вот cache eviction на базе обновлений не поддерживает никто, извольте подождать пока таймер истечет. То есть AWS смог в автоматический роллбек, но в server-side events не смог даже при условии, что у них для флагов аж целый агент есть. Пиздец.
Что по итогам?
Если вы только открываете для себя увлекательный мир разработки через конфигурации, используйте Unleash или Flipt, если у вас сильно развита культура код ревью.
#машины_разное
Я думаю, все и так достаточно рассосали падение Гугла, поэтому давайте расскажу в нескольких постах подробнее про feature flag’и, и какие у них есть полезности.
Из очевидного - безопасность сервиса. Представьте себе мечту Андрея Синицы DevOps и SRE любителей, где в секунду выкатываются десятки изменений.
Если в релизный цикл попадет баг, и нужно будет откатиться, то вы откатите не только свое изменение, но и другие (а там могли быть критические фиксы!), и будете делать это долго: плохие экземпляры потуши, старые релизные подними, трафик перенаправь, а если это делается глобально, то и сам релиз откатываться начнет не сразу (смотря как быстро алерт сработает), да и возвращаться будет долго.
В целом запуск бинаря в контейнере даже в самых современных оркестрациях занимает десятки секунд, что непростительно много, а даже самый чуткий алерт выстрелит в лучшем случае через минуту.
С флагами вы можете спокойно донести баговое решение до прода и спать крепко - до тех пор, пока флаг неактивен, плохой код исполняться не будет.
Более того, выкатку флага тоже можно и нужно контролировать с таким же усердием, как и сам релиз. Например, повесить на флаг те же алерты, что и на сервис, включить флаг для 1% запросов в canary, и смотреть как та пищит. Если у нас выстрелил алерт по SLO доступности, то дело скорее всего в фиче, и система выкатки так же умно его откатит назад.
Инженеру остается проанализировать логи, написать фикс и повторить итерацию.
Позже расскажу про как флаги позволяют контролировать выполнение кода, но пока поспекулирую, что флаги пропускают либо когда очень спешат (а в нынешней экономике все очень спешат), либо когда риск изменения низкий. А ваш покорный прилично инцидентов просмотрел, триггерами которых являлись «низкорисковые» изменения. :)
#машины_разное
Позавчера закончилась Tech Internals Conf Berlin, и я был рад пообщаться с ветеранами индустрии.
Под конец конфы у нас был форум, посвященный извечному дискурсу «Скорость против Качества», где два лагеря обсуждали, стоит ли делать быстро, или же правильно.
Вне всяких сомнений, ответ на этот вопрос будет «it depends», но к нему есть важное дополнение.
Время - ограниченный ресурс, и тратить его надо на то, что важно и нужно сейчас, а значит, на некоторые недостатки (даже на страницу, которая грузится 15 секунд, да-да, я тебя запомнил!), можно и нужно закрывать глаза.
Интересная и одновременно с этим приятная мудрость придет тогда, когда вы начнете отпускать те маленькие и крупные недостатки, которые уж очень раздражают, но практическая польза от их устранения стремится к нулю.
Если же вы и только вы знаете, насколько это важно и нужно и надо прямо сейчас, я приглашаю вас прочитать хороший пост на тему избавления от острой потребности чинить все, до чего дотянутся руки.
Отвечать за весь мир нет необходимости. :)
#машины_разное
Компания Redis в том году эффектно, но не эффективно, прикрыв свою OpenSource модель, предсказуемо вернулась обратно - и это правильный, в нынешних условиях, поступок.
В чем, собственно, цимес - охреневшие поставщики облачных услуг продают управляемые сервисы на базе редисов и эластиков, никаким образом не "возвращают" ничего назад - ни частью прибыли (а с чего вдруг?), ни контрибьюцией от своих инженеров (а с чего вдруг?).
Однако стоило конторам-авторам уйти в модель закрытого исходного кода, как ультраглобалисты индустрии в момент сделали форк и пустили свои инженерные силы на разработку клона со скоростью разработки, чуть ли не превосходящей команду первоисточника.
Хорошим примером является тот же OpenSearch - по возможностям он почти такой же как платный Elastic.
С высокой долей вероятностью ValKey сделал бы тоже самое с Redis. Так что Redic Inc. дала заднюю, и поступила правильно.
По-хорошему, интересы вендоров должны защищаться каким-нибудь госорганом, но государство в последнюю очередь беспокоят локальные терки айтишников за долю прибыли от труда.
#машины_разное
Проснувшись однажды утром после беспокойного сна, Грегор Замза обнаружил, что у него в продакшоне огромнейшее количество техдолга.
Шутки в сторону, но не все старое и дурно пахнущее стоит считать техдолгом. Вот пример из моего опыта.
Работая над одной миграцией, мне довелось переписать внутренний процессинг. Система, разработанная лет 6 или 8 назад, придерживалась довольно хитрой логики. Система запрашивает данные платежного метода, после чего передает их дальше по цепочке, заранее сериализуя через Thrift Json Serializer, десериализуя их в точке приема, при необходимости обогащая. У системы были свои недостатки: например она очевидно не поддерживала gRPC, а значит блокировала процессинг на использовании устаревших IDL. Потратив с пару недель, мы обнаружили что сериализованные данные в общем-то и не используются и являются аппендиксом, который можно было удалить.
Отключив его, мы обнаружили, что данные все еще используются, как есть, в процессинге, и это не техдолг, но осознанное дизайнерское решение. Систему так спроектировали, создали и она работала (пока не перестала - но это тема другого поста).
Так вот, техдолг от просто «Старой Системы, Которую Неприятно Поддерживать» отличается наличием… процентной ставки.
Поясню. Если для того, чтобы добавить изменение вам нужно дописать некрасивый старый код, заправив его неудобными тестами, которые не генерируются с помощью Copilot/Cursor - это просто старый некрасивый код.
А если к каждому изменению добавляется поток багов и инцидентов, количество которых со временем только увеличивается - то это техдолг.
Хороший блог на эту тему.
#машины_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 создает ресурс, недостаточно прав.