Авария может начаться раньше, чем поднимутся новые инстансы

Одна зона доступности легла. Остальные приняли её нагрузку, и теперь надо срочно добавить серверов. Но что, если API управления инфраструктурой тоже работает с перебоями?

В разборе static stability AWS предлагает заранее убрать эту зависимость из пути восстановления. В примере сервис работает в трёх зонах и держит 50% запаса мощности. Тогда две оставшиеся зоны способны выдержать всю нагрузку без ожидания новых инстансов.

Запас оплачивается и в спокойный день. Переключение трафика и проверки здоровья тоже остаются нужны. Но в момент аварии системе требуется меньше новых успешных действий. Это давний принцип из Builders Library, а не новая функция AWS. И 50% здесь следуют из конкретного примера с тремя зонами, универсальной нормой их считать нельзя.

Запустить программу не всегда значит создать процесс

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

В иллюстрированной главе CPU Land показан путь от пользовательского кода в ядро: передаются путь, аргументы и окружение, ядро распознаёт формат файла и загружает программу. Картинка помогает не смешать создание процесса с заменой того, что он исполняет.

Материал разбирает Linux на x86-64 и вышел в 2023 году. Хороший повод разобраться в механизме, но не обещание, что детали загрузки и обработки скриптов одинаковы во всех ОС и версиях ядра.

Весь Git перед глазами

Самое утомительное в маленьком коммите порой не сам коммит, а переключение между status, diff и логом. В lazygit эти состояния видны в соседних панелях терминала: файлы, ветки, история и изменения выбранного объекта.

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

Кроме файлов целиком можно добавлять отдельные строки и фрагменты. Но удобный интерфейс не отменяет смысл операций Git: rebase и cherry-pick остаются теми же действиями со своими последствиями. Выигрыш здесь в видимости состояния, а не в защите от любого неудачного решения.

В ядре Linux закрыли критическую уязвимость CVE-2026-98432 (CVSS 9,8), обновите ядро на серверах и перезагрузитесь. Anthropic рассказала, что эксплойт для неё написал сам Claude: он удалённо получает выполнение команд от root без учётных данных примерно за 53 минуты попыток. Код не публиковали.

Ошибка сидит в обработке TCP-рукопожатия по IPv4 с ядра 4.4 и срабатывает до того, как подключение дойдёт до приложения. Эксплойт бьёт через порты Multipath TCP: в Linux их по умолчанию открывают программы на Go с версии 1.24. Сама ошибка от MPTCP не зависит.

Исправления уже есть у Debian, Amazon Linux, Oracle Linux и частично у SUSE, у Ubuntu и RHEL пока нет. До патча Red Hat советует правило nftables, которое отбрасывает TCP-пакеты с опциями IPv4: оно снижает риск, но полностью не защищает. Ненужный MPTCP можно выключить через sysctl net.mptcp.enabled=0 с перезапуском сервисов. Команды и статус по дистрибутивам собрали на сайте.

@neuro_channel

Свободного региона может не оказаться

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

В разборе чемпионата мира Meta пишет, что на финале исходящий трафик вырос на 46% примерно за четыре минуты в конце основного времени. Для WhatsApp привычный межрегиональный перенос не помогал: все регионы выходили на пик в один момент. Занять запас у соседа было негде.

Поэтому региональные пики прогнозировали отдельно. Более 100 внутренних сервисов заранее нагрузочно проверили и подобрали им мощности. Это данные и опыт самой команды, но инженерный вопрос отсюда вполне общий: есть ли у вашего резервного ресурса причина стать занятым ровно тогда же, когда у основного?

Лог проще читать, когда важное видно цветом

IP, UUID, время, уровень ошибки и ещё несколько чисел в одной строке. После сотой такой строки взгляд начинает пропускать всё сразу.

tailspin подсвечивает узнаваемые фрагменты, не требуя отдельного описания формата для каждого сервиса. Он идёт по строкам и ищет даты, адреса, URL, числа и уровни сообщений независимо от позиции поля. Можно передать поток через stdin, например kubectl logs -f pod | tspin. Для просмотра файла инструмент использует pager less.

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

Картинка с котом может положить сервер

В учебном примере из разбора Cloudflare картинку с котом запрашивают 10 раз в секунду. Сервер картинок выдерживает только один запрос в секунду. Пока ответ есть в кеше, нагрузка до сервера не доходит. Через сутки TTL истекает, и все запросы идут к серверу.

Начать обновление на пять минут раньше? Тогда толпа придёт на пять минут раньше. Без объединения запросов это только переносит перегрузку.

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

Карту можно достраивать, вычёркивая невозможное

На анимации из проекта WaveFunctionCollapse часть карты уже нарисована человеком. Генератор достраивает окружение. Участок с надписью Fixed он сохраняет.

В основе — ограничения на соседство. В перекрывающейся модели программа берёт маленькие узоры из образца, обычно 3×3. Затем выбирает область с наименьшей ненулевой энтропией, фиксирует вариант и вычёркивает несовместимые у соседей. Один выбор сужает следующие, и постепенно проступает картинка.

Если для одной области вычеркнуть все варианты, получится противоречие. А локально согласованные тайлы ещё не гарантируют проходимый уровень. Для проходимости нужны отдельные правила.

Название квантовое, но квантового компьютера тут нет.

Видео — исходная демонстрация автора Максима Гумина.

Защитный парсер тоже читает опасный файл

Медиафайл ещё не открыли, а защитный парсер уже разбирает его содержимое. Чтобы проверить файл до системной библиотеки, ему самому приходится читать недоверенные данные. После Stagefright в 2015 году WhatsApp добавил в библиотеку wamedia проверку структуры MP4. Исправить уязвимость в самой ОС команда не могла, зато могла отсеять опасный файл до системной библиотеки.

В январском разборе миграции на Rust WhatsApp описывает, как проверяли совместимость: новую реализацию делали параллельно C++, затем кормили обе одинаковыми входами через differential fuzzing и сравнивали поведение. Плюс обычные unit- и интеграционные тесты.

Rust здесь нужен, чтобы снизить риск ошибок памяти в самом защитном парсере. Проверка формата при этом не остановит все файловые атаки.

Redis жив, соединение есть, ответа нет

Выключить Redis в тесте полезно. Но неприятность бывает хитрее: соединение установилось и просто висит. Обработчик ошибки подключения при этом может и не сработать.

Toxiproxy от Shopify ставят между приложением и зависимостью. Это TCP-прокси, условия в котором тест меняет через HTTP API. Можно задержать ответ, ограничить полосу или перестать передавать данные. При timeout = 0 данные не передаются, а соединение остаётся открытым до снятия ограничения.

В Rails-примере проекта unit-тест проверяет, что при недоступном Redis метод tags возвращает пустой массив вместо исключения. Для проверки всей страницы авторы отдельно предлагают интеграционный тест.

Задержка направленная. По умолчанию она действует от сервера к клиенту, для обратного направления нужна отдельная настройка.

Указатель нельзя просто записать на диск

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

В разборе внешней сортировки DuckDB 2021 года показано, как это обходят. Строки переменной длины живут в отдельном блоке, string heap. Перед выгрузкой 8-байтовый указатель заменяют смещением внутри блока. Когда данные понадобятся снова, адрес восстанавливают.

Особенно удобно, что смещения строковых значений относительно начала своей строки в heap не меняются при её переносе. Можно переставлять данные во время сортировки, не чиня каждый внутренний адрес заново.

Выгрузка требует места на диске и дополнительных чтений и записей. При этом для сортировки за пределами RAM не нужно совершенно другое представление строк. Выгрузкой блоков в описанной реализации занимается buffer manager.

Чем заменить Oracle и MS SQL Server? Даже если переезда пока нет в планах, стоит иметь в виду альтернативы.

На Tproger разобрали четыре российские СУБД и сравнили их по понятным параметрам: для каких задач подходят, насколько совместимы с PL/SQL и T-SQL, чем переносить данные, что придётся дорабатывать вручную, есть ли сертификат ФСТЭК и бесплатные версии, сколько стоят.

Одна из них исполняет T-SQL и PL/SQL напрямую, а SSMS и DBeaver видят её как обычный MS SQL Server.

Обзор поможет понять, какой вариант может вам больше подойти.

Форматтер поработал, а что поменялось по делу?

Выражение осталось тем же, но вокруг появилась обёртка, а строки разъехались. Обычный diff честно показывает удалённые и добавленные строки. Читателю ещё предстоит мысленно собрать из них изменение.

Difftastic разбирает код через tree-sitter и сопоставляет синтаксис. Поэтому может показать новую обёртку, сохранив связь с прежним выражением внутри. Перенос строки тоже не обязан выглядеть как замена всего блока. Номера строк при этом настоящие: до изменения и после него.

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

В скрипте стоит учесть код завершения: по умолчанию 0 не означает «изменений нет». Чтобы синтаксические изменения давали 1, нужен флаг --exit-code.

Симулятор, который портит жизнь настоящей базе

Диск тормозит, сеть теряет пакеты, процесс падает. По отдельности такие тесты ещё можно расписать руками. Дальше начинаются сочетания: что, если всё случилось в неудобном порядке?

В TigerBeetle для этого есть симулятор VOPR. В его среде работает целый кластер с настоящим кодом базы. Симулятор подбрасывает сетевые, дисковые и процессные сбои. Так можно искать и ошибку алгоритма, и баг в его реализации. Проверяется тот самый код, которому потом предстоит работать с данными.

Авторы в том же документе отдельно проговаривают: абсолютной долговечности нет. Пострадать могут все копии. И симулятор исследует только те отказы, которые в него заложили.

Контейнеру подставили другое ядро

Приложение делает системный вызов и ожидает ответа Linux. В gVisor первым его встречает Sentry — ядро приложения в пользовательском пространстве, написанное на Go.

Оно обслуживает вызов само, а не просто пересылает каждый запрос ядру хоста. Для собственной работы Sentry всё равно нужны системные вызовы хоста, но их набор ограничен. Доступ к внешней файловой системе вынесен в отдельный процесс Gofer. В документации gVisor разобрана эта граница доверия.

В контейнерные инструменты всё это встраивается через OCI-рантайм runsc. Меняется то, какой код отвечает на запросы программы, хотя для неё интерфейс стараются сохранить похожим на Linux.

У такого слоя есть цена: поддержаны не все интерфейсы, а нагрузка с частыми системными вызовами может заметно замедлиться.

Чтобы двигать образец, микроскоп сгибает пластик

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

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

Проект заявляет шаги заметно меньше 100 нм с небольшими шаговыми моторами. Это данные авторов. Любопытен сам подход: использовать упругость материала там, где обычно борются с трением в соединении. Оптику можно поставить от веб-камеры или взять лабораторный объектив с резьбой RMS. На фото проекта показан v7.0.0-alpha1.

QOI экономит ещё и на сложности кодека

Разработчик Доминик Шаблевски разбирался с упрощением видеокодека, а в итоге придумал lossless-формат для картинок — Quite OK Image Format. Занятно свернул.

QOI проходит RGB/RGBA-пиксели по порядку за один проход. Повторился предыдущий — запишем повтор. Цвет уже есть в индексе на 64 позиции — сошлёмся на него. Изменился ненамного — сохраним разницу. Не подошло ничего — положим полное значение.

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

В статье 2021 года автор сделал ставку на скорость и простоту реализации. QOI не гарантирует файл меньше PNG на любой картинке, зато восстанавливает исходные пиксели без потерь.

Для восстановления файла не обязательно держать его копию

Backblaze в разборе Reed–Solomon 2015 года описала схему 17+3. Файл делят на 17 равных фрагментов данных и вычисляют ещё три фрагмента избыточности. Всего 20, а для восстановления достаточно любых 17.

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

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

В статье это разбирают на меньшем примере 4+2: вычёркивают строки матрицы для двух потерянных фрагментов, находят обратную матрицу и с её помощью восстанавливают исходные данные.

Изменения в бэкапе есть, нужной точки восстановления уже нет

Litestream может сохранить изменение, но со временем потерять возможность восстановить базу ровно до него.

В описании v0.5 страницы SQLite WAL собираются в файлы LTX. Один такой пакет может содержать несколько транзакций SQLite. Его TXID — идентификатор пакета, а не каждой прикладной транзакции.

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

Сам по себе нужный max_txid не подтверждает возможность восстановления: нужны snapshot и непрерывная цепочка LTX до него. И репликация асинхронная: последние изменения могут ещё не доехать.

Трассу можно расспрашивать через SQL

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

В Perfetto этим занимается Trace Processor. Он читает трассы в форматах Perfetto, ftrace и Chrome JSON, структурирует события и даёт запрашивать их через PerfettoSQL. Найденную проверку можно повторять на других трассах, не разыскивая события на временной шкале вручную.

Документация предлагает начать с интерактивного исследования, а затем автоматизировать запросы через Python или C++. Когда понятно, что искать, Trace Summarization позволяет задать стабильный структурированный результат для мониторинга производительности и поиска регрессий. Выбор проверки и вывод о причине торможения остаются за человеком.

Маленькая модель пишет черновик для большой

Маленькая модель может накидать несколько токенов, а большая — проверить весь блок одним проходом.

В разборе Hugging Face 2023 года разобран случай с greedy-декодированием. Пока варианты совпадают с выбором большой модели, префикс принимается. На первом расхождении берут токен большой модели, а оставшийся черновой хвост отбрасывают: он продолжал последовательность с другим токеном.

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

Ускорение на конкретном GPU нужно измерять. При случайном семплировании отдельно нужно разбирать распределение вероятностей: переносить эту схему без изменений нельзя.