Hacker News Digest

Злоумышленники заявили о краже 10,6 ТБ данных из облачной платформы TiDB Cloud компании PingCAP — это 4 901 203 файла, включая полный контрольный слой продакшена. По их словам, выгрузка шла почти два месяца и оставалась незамеченной: 88 последовательных экспортов каждые шесть часов с 8 по 30 сентября, последний — в 06:02 UTC 30 сентября. Репликацию собственной базы данных TiDB Cloud они настроили через учётные данные, найденные в репозиториях самой компании: ключи сервисного аккаунта GCP и субъект Azure.

Среди похищенного — 180 046 организаций-арендаторов, 292 276 записей пользователей, 403 262 уникальных адреса электронной почты, 115 308 пар ключей API в открытом виде (42 612 активных), 20 645 574 SQL-запроса клиентов из редактора и Chat2Query, 102 003 766 подключений к шлюзу, 5 036 738 IP-адресов серверов заказчиков, 377 446 задач Jira, 433 928 контактов CRM, 92 ГБ данных о затратах AWS с метками арендаторов и 413 приватных репозиториев с исходным кодом. Также упоминаются 1 809 внешних конечных точек баз данных с учётными записями root и admin на хостах MySQL/Aurora заказчиков и 290 идентификаторов аккаунтов AWS.

Первый этап публикации — около 200 ГБ, доступен через торрент-файл размером 128,3 ГиБ. Атакующие подчёркивают, что PingCAP, будучи облачным провайдером, не заметил массовой выгрузки из AWS, GCP, Jira и Azure, хотя компания зарабатывает на обещании безопасности мультитенантной платформы.

Обсуждение указывает на катастрофический уровень операционной безопасности PingCAP: инженеры хранили production-учетные данные клиентов и ключи сервисных аккаунтов GCP и Azure в тикетах Jira и репозиториях. Это позволило атакующим настроить автоматическую репликацию данных в течение месяца. Сообщество ставит под сомнение заявления компании об отсутствии воздействия на данные, так как у хакеров есть полные дампы контрольного слоя. В споре о природе утечки @gregwebs считает, что утекли в основном метаданные, однако другие указывают на наличие SQL-логов с реальными данными клиентов. Проведенный ранее аудит NCC Group выявил разрыв между анализом кода и реальной безопасностью процессов. @kobieps отмечает необходимость перестройки индустрии пентестов, так как даже enterprise-grade вендоры допускают подобные провалы. @ozgrakkurt полагает, что безопасность была бы выше при использовании консервативной модели разрешений (как в Deno), где всё закрыто по умолчанию. Также пользователи иронизировали по поводу Rust, но @boorbat уточнил, что TiDB на 95% написан на Go.

Автор перешёл на самохостинг после нескольких лет в Индии, где стриминговые сервисы стоили дёшево по западным меркам. Вернувшись, он не захотел платить западные цены и устал от «беговой дорожки вовлечённости» — особенно ради сына: постоянные «рекомендовано для вас» и «далее» мешали ограничивать контент. Отказ от стриминга в пользу Jellyfin за полтора года открыл дорогу к десяткам других сервисов и снизил зависимость от облачных провайдеров.

Правила просты: никакие сервисы, кроме VPN на роутере, не выставляются в публичный интернет — провайдер использует CGNAT для IPv4, а VPN доступен только по IPv6, из-за чего почти не работает в публичных сетях Wi-Fi. Предпочтение отдаётся нативному запуску, а не контейнерам: сервис из одного бинарника на Go — идеал, а требующий MySQL, Redis и ещё трёх контейнеров вызывает поиск альтернативы. Docker автор забросил в пользу Podman с его отличной интеграцией с systemd.

Итог: 17 нативных сервисов и 11 под управлением Podman, все через systemd. Мини-ПК Beelink S12 Pro на Intel N100 с 16 ГБ памяти держит около 7,5 ГБ занятой памяти и загрузку процессора 30–40%. Firefly III оказался слишком сложным, OwnTracks не смог стабильно сообщать позицию, а Music Assistant пытался «владеть» всей музыкальной конфигурацией. Самохостинг почты автор считает неоправданно трудоёмким.

Обсуждение дополняет статью практическими советами по железу, организации сети и спорами о выборе между легковесными бинарниками, Docker и Kubernetes. Спор: Пользователи спорят о ресурсоемкости *arr-стека: @eleventen и @eventuallyok утверждают, что Sonarr и Radarr потребляют минимум CPU и около 160 МБ RAM в простое; другие считают их сложными и хрупкими. Спор: Разногласия по базам данных: @mikeocool рекомендует SQLite для простоты селф-хостинга; @diebillionaires и @scottydelta предпочитают Postgres за его преимущества. Совет: Для бюджетного сервера @hypfer рекомендует б/у Intel NUC 8-го поколения (~110€); @bahmboo советует MacBook Air M1 с разбитым экраном как энергоэффективный headless-узел. Совет: Для доступа к сервисам без открытия портов в интернет @turtlebits рекомендует Pangolin; @jwrallie предлагает Tailscale + Samba. Совет: Вместо полного хостинга почты @ebrahimh советует использовать mbsync для зеркалирования входящих из Gmail/Proton в локальный фронтенд вроде Roundcube. Совет: Для управления музыкой @disposition2 рекомендует Lyrion как более современную и удобную альтернативу MPD для множества клиентов. Декларативное развертывание (Docker Compose, k3s/k8s) считается стандартом для минимизации ручной настройки и упрощения миграции между железом. Совет: По опыту @bengalister, Kubernetes для домашних сервисов может быть избыточным, но помогает поддерживать профессиональные навыки. Совет: Для синхронизации паролей @seplox рекомендует KeePass + Syncthing.

Yandex Cloud столкнулся с масштабным сбоем, начавшимся 11 октября в 1:00 по GMT и продолжавшимся до момента публикации обновления 12 октября в 16:16 GMT. Платформа работала в ограниченном режиме, а затем перешла в режим чрезвычайной ситуации, что повлияло на доступность практически всех ключевых сервисов: Compute Cloud, VPC, Object Storage, IAM, Managed Service for Kubernetes, Monitoring, базы данных (PostgreSQL, ClickHouse, MySQL, Valkey, YDB), сетевые сервисы (Network и Application Load Balancer, Cloud Interconnect, Cloud DNS), инструменты разработки (Cloud Functions, API Gateway, Cloud Desktop, Managed Service for GitLab, SourceCraft), ИИ и аналитика (YandexGPT API, Yandex Query, Yandex AI Studio, Yandex MPP Analytics Engine), а также вспомогательные системы (Cloud Logging, Audit Trails, SmartCaptcha, Cloud Backup, Yandex Cloud Console, Yandex Cloud Billing, Yandex Cloud Router, Yandex Cloud Quota Manager и многие другие). Техническая поддержка работала в усиленном режиме, но время ответа увеличивалось из-за высокой нагрузки.

Компания рекомендовала пользователям использовать альтернативные площадки для хостинга и резервирования ресурсов, а также рассматривать другие платформы для быстрого развертывания и обеспечения избыточности. Квоты на дополнительные ресурсы оставались приостановленными. Обновления публиковались несколько раз в день: сначала планировались на 11 октября в 18:00 и 19:00 МСК, затем на 12 октября в 11:00 и 19:00 МСК, а следующее — на 13 октября в 11:00 МСК. Восстановление шло круглосуточно, но полное возвращение к нормальной работе заняло значительное время из-за масштаба инцидента.

Атака на дата‐центр Yandex Cloud вызвала масштабные перебои в российских сервисах: пользователи не могли вызвать такси, заказать еду, а POS‐системы в розничных сетях перестали работать. Yandex получил положительные отзывы за прозрачную коммуникацию через статус‐страницу и своевременные обновления. Атаки на дата‐центры становятся частью военных действий: в сентябре Россия подверглась более чем 10 ударам по украинским телеком‐центрам, теперь Украина отвечает ударами по российским дата‐центрам. Это подчёркивает рост дата‐центров как целей в современных конфликтах и глобальную уязвимость крупных облачных провайдеров — аналогичные инциденты отмечались с AWS на Ближнем Востоке. Потеря инфраструктуры и талантов в России ускоряется: ИТ‐отрасль теряет как специалистов, так и физические объекты, что может ослабить её конкурентоспособность и отразиться на экономике на месяцы при выводе из строя трёх стратегических дата‐центров. В ответ на уязвимость крупных объектов обсуждается переход к децентрализации: рост сетей небольших дата‐центров и распределённых систем, а также вопросы о размещении инфраструктуры под землёй или в защищённых местах. Технический интерес к мониторингу демонстрирует ссылка на график соединения AS200350 (YandexCloud), показывающий деградацию сети в реальном времени.

Маленькие знания часто дают большой эффект в повседневной работе инженера. Например, ctrl + r в терминале можно улучшить с помощью fzf для нечёткого поиска истории или atuin, который хранит историю в SQLite и позволяет искать по директориям. В SQL можно выполнять SELECT без FROM — удобно для тестирования функций или проверки выражений вроде SELECT TRUE <> NULL. Для оптимизации запросов в PostgreSQL и MySQL полезно EXPLAIN ANALYZE, которое выполняет запрос и показывает детальную производительность. В регулярных выражениях \b помогает находить границы слов, а логарифмы удобны для bucketing метрик — например, Math.floor(Math.log10(count)) группирует значения по порядкам величины. В современном JavaScript полезны Array.flatMap, Object.entries и Promise.withResolvers, а в Node.js — повторное использование HTTPS-соединений через https.Agent, что снижает латентность. В Git: git log -S pattern ищет коммиты, где строка была добавлена или удалена («git pickaxe»), git checkout - переключается на предыдущий HEAD, а вместо find часто достаточно **/*.md при включённом globstar в Bash. Для поиска по содержимому файлов лучше использовать rg (ripgrep), а в Zsh стоит включить автодополнение через compinit и настроить FPATH для функций от Homebrew. Эти приёмы не требуют глубоких знаний, но экономят время и снижают когнитивную нагрузку. Аналогично в компаниях ценны небольшие внутренние лайфхаки: какой источник данных смотреть при проблеме, кто эксперт в определённой области, где лежит документация по сложной теме, когда нужно вручную масштабировать систему, какая команда делает rolling restart, какой утилитой удобно скриптировать рутинную задачу. Один такой совет в день — достаточно, чтобы не перегружать команду, но полезно для тех, кто ещё не знал этого трюка. Даже если вы знаете 9 из 10, десятый может сэкономить час работы и спровоцировать полезное обсуждение. Старшим инженерам стоит делиться такими знаниями — они формируют культуру эффективной работы.

Эффективность мелких трюков зависит от привычки и системного закрепления, а не от их наличия. Инженеры годами используют неоптимальные методы из-за привычки и лени, несмотря на знание более быстрых альтернатив. Записывайте полезные трюки в легко доступный документ — это помогает вспомнить их при необходимости, не полагаясь на память или поиск в интернете. Размещайте чит-листы на стене или в рабочем пространстве — физическое присутствие подсказок повышает вероятность их применения. Создавайте bash-алиасы или скрипты, которые 'порицают' за использование устаревших команд — это формирует новую привычку (как @lelandbatey с git switch). Храните редко используемые, но важные команды в файле типа ~/scratch.txt с grep-доступом — это надежнее, чем история shell. Используйте zoxide вместо cd — он запоминает частые директории и позволяет прыгать между ними без цепочек ../.. (как @disinterred). Используйте zhist для улучшенного поиска истории Zsh с контекстом — он лучше стандартного fzf (как @overflowy). Сохраняйте полезные команды в Makefile или инструментарии приложения — это делает их воспроизводимыми и устраняет необходимость вводить их вручную (как @cachvico). Пишите полезные трюки на собственном сайте — это делает их долговечными и удобными для обмена (как @AJRF). Изучайте трюки, наблюдая за тем, как AI выполняет задачи — часто AI использует неизвестные вам команды (например, в perf, как @kccqzy и @SebasDev). Спор: Некоторые считают, что трюки вроде SELECT без FROM зависят от СУБД — например, IBM-продукты могут не поддерживать это (как @rf15). Спор: Некоторые считают, что эти трюки — не программирование, а администрирование или CLI-навыки (как @ozim и @1vuio0pswjnm7). Спор: Некоторые считают, что трюки устаревают из-за AI — например, @bufordtwain и @monideas считают, что AI делает их менее полезными. Используйте git ls-files вместо find для поиска файлов в репозитории — это быстрее и точнее (как @lucasoshiro). Используйте rg --hidden -g '!*.lock' для фильтрации шума в поиске — это эффективно для повседневной работы (как @ahmedhossamdev). Используйте pbcopy на macOS для копирования вывода команды в буфер обмена — это ускоряет работу с API-ответами (как @okinternets).

DuckDB v2.0, codenamed «Cyanoptera», выходит этим осенью и представляет набор кардинальных изменений: серверный режим через расширение quack и оператор CONNECT, новый SQL‑парсер, переработанную СУБД‑структуру, асинхронный ввод‑вывод и тип VARIANT. Серверный режим позволяет любой процессу DuckDB обслуживать базы данных по сети, а клиентские запросы можно отправлять напрямую на удалённый PostgreSQL или MySQL без копирования данных. Кроме того, в v2.0 введены триггеры, более строгая типизация и поддержка транзакций в многопользовательском режиме, что делает DuckDB конкурентоспособным для аналитических и даже транзакционных нагрузок.

Ключевые нововведения: серверный режим (quack + CONNECT), новый тип VARIANT для гибкого хранения схем, асинхронный I/O ускоряющий запросы, новая хранилище‑формат с улучшенной компрессией, а также новый C‑API и небольшие, но важные ломающие изменения (переход на lambda‑синтаксис). В статье также упоминается создание DuckDB Foundation Advisory Board, который будет влиять на дальнейшее развитие проекта. Эти изменения формируют фундамент для «года DuckDB как сервера» и открывают путь к масштабным распределённым решениям.

DuckDB v2.0 трансформируется из локального аналитического процессора в основу облачной аналитической инфраструктуры, что подтверждено использованием в продакшене: многотенантные системы с данными 5–150 ГБ на тенанта, обработка миллионов Parquet-файлов, замена серверных решений. Он превосходит PostgreSQL и MariaDB в OLAP-задачах благодаря колоночному хранению и встроенному процессу, но уступает в многопользовательской конкурентности без Quack. Поддерживает обработку данных, превышающих ОЗУ, на потребительском оборудовании, снижая требования к инфраструктуре. Асинхронный ввод-вывод в v2.0 критически важен для масштабной работы с Parquet и обеспечивает значительный прирост производительности. WASM-сборка весит ~10 МБ, пригодна для браузера; расширения не увеличивают размер бинарников существенно. Заменяет сложные ETL-пайплайны, позволяя объединять запросы к CSV, Parquet и базам данных в одном SQL-интерфейсе. Стандартная практика — анализ лог-файлов (например, Nginx access.log) на диске. Рекомендации: - Использовать Arc для ускорения сканирования через pruning при работе с Parquet. - Для расширений применять официальный шаблон extension-template. - Ручная настройка memory_limit необходима для предотвращения убийства OOM-killerом. - При аналитике в браузере кастомизировать Emscripten-сборку — она оптимизирована, но требует настройки. - Документировать новый PEG-парсер — его детали критичны для совместимости. Quack (серверный режим) и CONNECT к PostgreSQL делают DuckDB гибридным инструментом, интегрируемым с OLTP-системами. Споры: - Некоторые считают DuckDB неподходящим для распределённой обработки против AWS Athena с Trino, но Quack и DuckLake меняют эту динамику. - Одни выражают разочарование, что DuckDB не переписан на Zig, другие не видят в этом проблемы.

Борьба с «инновационными токенами» — ключ к устойчивому росту. Каждый проект получает всего три шанса на радикальные технологические эксперименты; их расходование на эксперименты вроде NodeJS, MongoDB или новейших сервисов обнаружения приводит к риску провала. Вместо этого выбирайте «скучные», но проверенные решения — MySQL, Postgres, PHP, Python, Memcached. Их известные слабые места позволяют заранее спланировать отказоустойчивость, в отличие от новых технологий, где неизвестные неизвестные часто оказываются катастрофическими.

Оптимизация должна быть глобальной: фокус на долгосрочной стабильности, а не на блеске. В Etsy, используя «скучный стек», команда масштабировала активности в 20 раз без вмешательства, пока не отвлеклась на новые решения. Это подтверждает, что сознательный отказ от избыточной инновации ускоряет успех, а не замедляет его.

Тред критикует концепцию «инновационных токенов» как излишне упрощённую, подчёркивая, что выбор технологий должен основываться на конкретных потребностях проекта, а не на новизне. @NickNaraghi считает её полезной для принятия решений, но @insanitybit, @threethirtytwo и @euthymiclabs возражают: новизна не заменяет надёжность и стабильность. @gaigalas предлагает компромисс — 80% «скучных», 20% инновационных технологий, чтобы избежать конфликтов.

Мы заменили Redis‑хранилище резервов на MySQL и смогли выдержать нагрузку в $5,1 млн продаж в минуту в 2025 году.
Ключевая идея — по одной строке на каждый товарный остаток, а не на одну строку на товар с колонкой количества. Это позволило использовать SKIP LOCKED, получая конкурентный доступ к отдельным единицам и избегая конфликтов при одновременных покупках.

Получилось два важных вывода. Во‑первых, старые ограничения (одна строка‑количество) устарели: современные версии MySQL уже поддерживают нужный уровень изоляции, и их стоит перепроверить при росте нагрузки. Во‑вторых, простая прототипная проверка (небольшой скрипт, мониторинг блокировок) раскрыла реальный узел — избыточное использование соединений, а не «медленные» запросы. В итоге система стала надёжнее: больше нет перепродаж и больше завершённых покупок, а база остаётся здоровой для всех остальных процессов.

Тред критикует подход Shopify к резервированию товаров, предлагая альтернативы: отдельная строка на заказ-товар или фоновый возврат товаров в запас. Участники согласны, что денормализация повышает производительность, но может вызывать проблемы с согласованностью и блокировками. Рекомендуется шардирование таблицы запасов по ID магазина для снижения нагрузки. Некоторые считают Shopify шагом назад — вместо Redis используется диск-ориентированная БД, не справляющаяся с десятками тысяч одновременных соединений. Хотя готовые решения проще, в данном случае они могут быть неоптимальны.

Выпуск Litestream v0.5.0 знаменует переход от простого резервного копирования к эффективному восстановлению на определённый момент времени (PITR). Ключевое нововведение — формат LTX, позаимствованный из проекта LiteFS. Вместо потоковой передачи отдельных страниц базы данных Litestream теперь группирует изменения в рамках транзакций, что значительно ускоряет восстановление после сбоя.

Формат LTX решает проблему "горячих страниц" — например, при частых вставках в таблицу с автоинкрементным ключом, когда изменения концентрируются на ограниченном числе страниц. Раньше Litestream обрабатывал каждую страницу отдельно, что замедляло процесс. Теперь транзакции записываются целиком, сокращая количество операций ввода-вывода и ускоряя восстановление. Это делает SQLite ещё более надёжным решением для полноценных приложений.

• Пользователи обсуждают сложности развертывания SQLite-приложений на Fly.io, включая проблемы с инициализацией и миграцией баз данных.
• Litestream получает положительные отзывы за простоту использования, низкую стоимость репликации в S3 и надежность как инструмента для резервного копирования и репликации.
• Обсуждаются технические детали Litestream: поддержка S3-совместимых хранилищ, условные записи для реализации временных lease и планы по реализации read-replicas через VFS.
• Участники сравнивают Litestream с другими решениями (LiteFS, rsync, управляемые БД), отмечая его операционную простоту и отсутствие необходимости в отдельном сервере.
• Поднимаются вопросы о практическом применении SQLite и Litestream: восстановление после сбоев, работа с нестабильным интернетом, целесообразность использования против PostgreSQL/MySQL для разных сценариев.