Разработка и инженерия

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

Меня больше достают интеграции. Когда разные системы должны работать вместе.

Недавняя авария AWS — это радикальный вариант с точки зрения взаимозависимости сложных систем, но вот совсем простой пример от нашего клиента.

Это успешное медиа, которое заказало спецпроект у подрядчика. Подрядчик сделал классный апп: даже авторизация в админку не просто по логину и паролю, а по OTP — одноразовыми кодами, всё как у взрослых.

Только коды эти приходят по почте. Поэтому они попросили завести в почтовой системе клиента адреса для отправки и получения. Что может пойти не так? Да всё!

Сначала происходит сломанный телефон между админом клиента и заказчиком и оказывается, что желаемые адреса уже заняты. Админ в конце-концов заводит пользователя для отправки писем и групповую рассылку для получателей.

Потом выясняется, что хостинг подрядчика режет подключения к SMTP портам. Решили временно использовать почтовый сервер подрядчика.

Жду, когда эти письма начнут попадать в спам.

Если можно обойтись без внешних зависимостей и интеграций — лучше без них!

Подъехал пост-мортем от Амазона.

С одной стороны, хочется поржать над DNS Enactor, DropletWorkflow Manager (DWFM), Network Manager и прочими — это Galactic от Krazam, только в реальном мире и на очень серьезных щщах.

Если без шуток, то цепочка такая:

1. сначала сломался доступ к dynamodb из-за рейс-кондишена системы управления DNS — два таска начали писать в DNS одновременно, первый старую версию записей, второй — более новую новую, в результате часть записей в DNS оказалась новая, часть старая, второй процесс запустил cleanup, который удалил все старые записи и из такого разломанного состояния система сама восстановиться не могла. Сломалось в полночью, за 50 минут поняли в чем дело и ещё за 40 минут починили руками.

2. из-за сломанного dynamodb, система управления железом не могла обновить статус физических серверов и начала отмечать их как «недоступные», поэтому не могла запустить новые виртуальные машины; после восстановления dynamodb, по-идее всё должно было встать само, но из-за большого объема железа, стоящего в очереди, обновление статуса занимало дольше, чем таймаут — и очередь не разгребалась, а только росла. Коллапс. Стандартной процедуры восстановления для такого случая прописано не было, через 2 часа попыток что-то разрулить, инженеры ограничили число входящих запросов и начали перезапускать тачки с системой управления; это помогло, теперь можно было создать новые виртуальные машины;

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

4. из-за этой задержки появления сети на машинах, моргали статусы серверов в лоад-балансерах, отмечая живые инстансы как мертвые и триггерились дополнительные переключения нагрузки (привет, DNS!) и перегрузилась система проверки здоровья серверов,
пришлось её на время выключить.

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

Раздел «что мы поменяем» удивительно короткий и очень технический: починят рейс кодишен в DNS, ограничат объем серверов, который может выключить лоад-балансер и т. д. Ну и заканчивают «извините, в будущем будем более лучше стараться».

Интересно, что они не делают никаких философских выводов из ситуации. Видимо, считают, что идейно всё верно. Я сам такими огромными системами (и командами) не управлял и поэтому осторожно предположу, что, наверное, технически, можно сделать систему проще, но учитывая, что над ней работают десятки независимых команд — это, наверное, минимальный доступный объем сложности и допустимый объем ошибок. Было бы интересно услышать мнение «настоящих сварщиков».

—

Коллеги советуют замечательную статью на тему безопасности сложных систем. Она не дает ответов, но предостерегает от попытки найти «root cause», «причину аварии» и предлагает посмотреть на безопасность систем по-новому, через другие линзы, чем я привык. Очень рекомендую.

Большая часть облачных сервисов AWS лежала почти 3 часа. Если у вас глючили Слек, Зум, Сигнал и прочие — это всё от этого. Уже поднимаются. Официальный статус тут.

Как обычно, система поддержки AWS тоже легла. Говорят, что из-за проблем с DNS отвалилась база данных DynamoDB на восточном побережье США, ну а дальше эффект домино. Ждем официального post mortem.

Время шутки, что один сервак в hetzner может дать больший аптайм, чем вся современная облачная инфраструктура.

Доброе утро! А вот у южнокорейских государственных айтишников — не очень доброе, потому что они не делали бэкапы до сих пор восстанавливают инфраструктуру после пожара в серверной.

У большинства систем были бэкапы, но удаленное хранилище файлов, которым пользовались 17% всех госслужащих страны — не имело бэкапов. Безвозвратно потеряны терабайты документов. Делайте бэкапы!

Кстати, у этой истории есть ещё и шпионское измерение: в июне 2025го двое хакеров взломали северокорейского (китайского?) хакера, который взломал LG и кучу южнокорейских государственных систем. Дали об этом знать южнокорейским правоохранителям, которые в августе перестали выходить на связь. А дальше уже совсем мистика: кто-то пишет им с одноразового номера в сигнале «Proton небезопасен», после чего Proton блокирует почтовый ящик, с которого они вели коммуникацию только с южнокорейскими властями, но разблокирует после публикации.

24 сентября южнокорейский парламент начинает расследование взлома, 25го анонсирует физический аудит дата-центра, 26го — пожар. Подробности и ссылки на дампы с компьютера хакера — в легендарном журнале phrack.

Новая macOS 26 Tahoe, вышедшая на прошлой неделе, наконец-то получила индикатор громкости, который не перекрывает лицо собеседника в зуме. Раньше индикатор был большой по центру экрана, а теперь смотрите какой маленький аккуратный в углу. Если решите обновиться — учтите: есть есть два бага, которые серьезно мешают работать.

Безбожно тормозит ввод с клавиатуры в некоторых программах в некоторых ситуациях (и грузит CPU) и программы на базе электрона (и грузят GPU), всё это быстро съедает аккумулятор.

Первое чинится командой defaults write -g NSAutoFillHeuristicControllerEnabled -bool false (для эффекта необходимо перезапуститься), второе — командой launchctl setenv CHROME_HEADLESS 1 (эту, наоборот, выполнять каждый раз после перезапуска или настроить агента).

Тот же CTO, что посоветовал PostHog (спасибо, Никита!), рассказал ещё про dagster, платформу для оркестрации дата-пайплайнов.

Всё хранится в питон коде с аннотациями, на основе которых потом собираются супер красивые интерактивные графы зависимостей со статусами, историей запусков, временем исполнения и т. д.; хорошая поддержка тестов, бранчевания.

Видео-туториал на 30 минут, сравнение с Airflow и с dbt cloud и неплохая документация.

Нормальные цены, есть бесплатная self-hosted версия.

Говорят, все модные дата-инженеры по нему угорают.

Хорошая заметка про сервис уборки за вайбкодерами.

Совпадает с моими наблюдениями в том, что ИИ помогает быстро сделать прототип и писать тесты, а вот полноценная продакшен версия требует нормальной архитектуры и внимания сеньора.

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

В такой ситуации профессия vibe code cleanup specialist («привожу в вайбкод в порядок») перестаёт быть шуткой. В статье есть ссылки на примеры и даже исследования.

Интересно, как меняются инструменты, но не меняется суть. Мы уже много лет зарабатываем на том, что приводим в порядок проекты, запущенные другими людьми. Это называют «технический перезапуск», «глобальный рефакторинг», суть та же. Только если раньше это был код, написанный другими людьми, то теперь он сгенерирован нейросетями.

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

Технически, приводить в порядок сложнее, чем писать с нуля, потому что не достаточно реализовать продуктовую идею, нужно дополнительно разобраться в том, как устроена прошлая версия и не сломать то, что уже работает.

Похоже на то, как дешевле построить дом с нуля, чем сделать ремонт в историческом здании.

Теперь эти «исторические здания» собирают с помощью роботов. :)

Интересная и очень хорошо написанная статья про гомоморфное шифрование.

Это когда сервер выполняет вычисления поверх зашифрованной информации, не расшифровывая её.

Немного похоже на мессенджер с end-to-end шифрованием (типа Вацапа), который пересылает сообщения между пользователями, не имея возможности прочитать содержимое сообщений.

В отличие от мессенджера, здесь сервер не просто пересылает сообщения, но и производит над ними полезные действия. Например: вы отправляете в сервис зашифрованную фотографию, тот применяет фильтр на бессмысленный с его точки зрения набор цифр и возвращает вам результат операции, не видя вашей фотографии ни секунды, не имея к ней доступа к её содержимому даже теоретически. Вы расшифровываете ответ (сделать это можете только вы) и получаете фотографию с применённым фильтром.

То есть сервис производит полезные действия с вашими данными, не имея возможности их прочитать, сохранить, продать, потерять.

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

Теоретически — потому что на практике алгоритмы, работающие с такими данными, в тысячи раз медленнее, чем обычные алгоритмы, а сами данные получаются в сотни раз больше по объёму.

Под капотом там довольно сложная математика, с красивой интуитивной частью, рекомендую почитать оригинал. Придумали её ещё в 1970-х, но первый рабочий алгоритм смогли запрограммировать только в 2011.

Первая версия алгоритма обрабатывала один бит информации за 30 минут. За последние 5 лет алгоритмы и железо ускорились в триллион (1012) раз, и теперь операции с этим видом шифрования всего в 1000 раз более ресурсоёмкие, чем обычные.

Есть гипотеза, что гомоморфное шифрование продолжит ускоряться и дальше, и в какой-то момент мы сможем пользоваться онлайн-сервисами без необходимости делиться с ними личными данными. Например: отправили медицинскому сервису свои анализы или ДНК, и он поставил диагноз, не то что не сохраняя наши персональные данные, но даже не получив возможности их прочитать. Магия!

Виталик Бутерин, гениальный создатель Эфира, считает, что если 2010-е годы были эпохой криптографии эллиптических кривых, то 2020-е — эпоха гомоморфного шифрования.

Удивительное открытие для меня — это то, что уже сейчас есть продакшен-системы, которые применяют гомоморфное шифрование в реальных задачах — например, Live Caller ID Lookup айфонов, который помогает бороться со спам-звонками, сохраняя приватность.

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

Ну и классное рассуждение по мотивам исследования: автор цитирует классика Питера Науэра (того самого, который N в BNF), который говорил, что программирование — это создание ментальной модели задачи, предметной области, в которой мы работаем.

Опытные программисты, годами работающие над проектом, конечно же, имеют эту модель в подкорке, и их софт ей соответствует. У нейросети этой модели нет, поэтому она скорее мешает, чем помогает.

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

—

Удивительно, как теория переплетается с практикой.

Совсем недавно сделали проект, в котором нас позвали «привести в порядок успешный стартап». Чуваки собрали MVP, но страдают от низкой скорости добавления фичей. Раньше я говорил, что это из-за «высокой внутренней сложности кода».

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

Красиво!

Наш любимый DHH (Дэвид Хейнемейер Хэнсон, создатель популярного фреймворка Ruby on Rails, со-владелец системы управления проектами Basecamp, отличный программист и автогонщик) сделал свои сборки Linux для программистов, omakub и omarchy.

Обычно таким грешат подростки, но DHH создал два практичных и интересных сетапа для программистов, которые любят macOS и не прочь познакомиться с Linux, но не хотят сами разбираться с вопросами вроде рендеринга шрифтов и настраивать десятки стандартных программ.

Системы ориентирована на управление с клавиатуры, без мыши. Если omakub построен год назад на основе мейнстримового Ubuntu + Gnome, то свеженький omarchy, уже на основе Arch и Hyprland, современного tiling manager. Стоит хотя бы раз попробовать, это немного другой способ управлять компьютером, совсем без мышки.

В любом случае, ставите свежий linux, запускаете одну команду и через пару десятков минут можно пробовать. Пока устанавливается — смотрите видео, где DHH за 25 минут делает обзор системы и как ею стоит пользоваться.

Многие мои друзья-технари в полном восторге от omarchy. Отличное развлечение на выходные!

Oma* — от японского omakase, когда оставляешь выбор блюд в ресторане на усмотрение шефа.