Добавили потоков, а программа стала медленнее? Причина может скрываться в ложном разделении кеш‑линий: потоки работают с разными переменными, но процессор всё равно заставляет ядра конкурировать за один участок памяти.
Разберём, как воспроизвести такую просадку, найти её через perf c2c и исправить без лишнего раздувания структур.
Гигабитный канал может быть загружен лишь наполовину, а пинг под нагрузкой всё равно взлетает до сотен миллисекунд.
Разбираемся, где копятся очереди, как распознать bufferbloat и какие механизмы действительно удерживают задержку под контролем.
CPU и диск свободны, а сервис уже задыхается: транзакции ждут блокировок, соединения заканчиваются, база перестаёт отвечать.
Разберём, как найти корневой процесс в PostgreSQL, отличить длинную транзакцию от конкуренции за строки и остановить каскадный сбой.
Порог 0,8 часто воспринимают как 80% уверенности — и на этом строят автоматизацию.
Разберём, почему predict_proba может врать, как измерить калибровку модели и вернуть её вероятностям практический смысл.
На демо корутины выглядят почти безошибочно, но под нагрузкой один неверный выбор области, диспетчера или способа обработки исключений быстро превращается в зависшие задачи и падение чужих запросов.
Разбираем типичные ошибки Kotlin‑бэкенда и показываем, как сохранить предсказуемое поведение сервиса.
Привет, Хабр! Go специально сделали маленьким языком. Ключевых слов немного, конструкций мало, за неделю осваиваешь синтаксис и начинаешь писать. Именно из-за этой простоты возникает ложное ощущение, что тут негде ошибиться — код компилируется, значит всё правильно.
А потом оказывается, что компилятор пропускает целый класс вещей, которые в других языках он бы отловил или которые просто устроены не так, как ты привык. Цикл, который выдаёт не те значения. Слайс, который меняется сам собой. Горутина, которая молча теряет ошибку. Всё это компилируется и запускается, а ведёт себя не так, как ожидаешь.
Собрал восемь ошибок, через которые проходит примерно каждый, кто приходит в Go из другого языка. Все — реальные, все встречаются в чужом (и своём) коде постоянно.
Неограниченный канал спокойно работает до первого замедления потребителя, после чего очередь начинает расти, память — заканчиваться, а фоновый воркер может зависнуть при остановке сервиса.
В статье разберём, как строить конвейеры на System.Threading.Channels: настраивать обратное давление, корректно завершать обработку, не терять исключения и безопасно использовать каналы в ASP.NET Core.
Django ORM умеет долго скрывать проблемы: лишние запросы, гонки при save(), затянувшиеся транзакции и выборки, которые незаметно съедают память.
В статье разберём шесть типичных ошибок, которые редко проявляются на тестовых данных, зато быстро становятся заметны под нагрузкой.
Отмена задачи кажется простой, пока сервис не зависает при остановке, таймаут не оставляет запрос работать в фоне, а CancelledError исчезает внутри обработчика исключений. Разберём, как устроена кооперативная отмена в asyncio, где ставить точки ожидания и как использовать TaskGroup, timeout и shield, чтобы задачи завершались предсказуемо.
Локально тесты проходят стабильно, а в CI начинают падать в случайных местах — знакомая картина даже для проектов на Playwright.
В статье разберём, где заканчивается встроенное автоожидание, какие привычные конструкции возвращают гонки и как выстроить тесты так, чтобы результат меньше зависел от скорости окружения и состояния данных.
Promise, setTimeout и async/await часто работают совсем не в том порядке, которого ждёшь по коду, а тяжёлая синхронная функция способна заморозить весь интерфейс. Разберём модель цикла событий, которая объясняет эти эффекты и помогает понимать, где возникают блокировки, гонки запросов и лишние задержки.
Обычные тесты находят только ожидаемые ошибки. В статье разберём, как Hypothesis сам ищет контрпримеры и сокращает их до минимального сбоя.
Цифры за закрытый месяц внезапно меняются, а поиск причины превращается в разбор всего пайплайна — от загрузки событий до логики витрин.
В статье разбираем пять типовых сценариев, из‑за которых прошлое в отчётах продолжает «двигаться», и показываем, как сделать пересчёт данных предсказуемым.
Strict‑режим включён, схема валидна, ответ успешно парсится — а в проде всё равно всплывают None, пропавшие ограничения и аргументы инструментов не тех типов.
В статье разберём пять ситуаций, где Structured Outputs создают ложное ощущение надёжности, и посмотрим, какие проверки действительно стоит добавить в LLM‑пайплайн.
Локально Testcontainers запускается за секунды, тесты стабильно зелёные, а в CI тот же набор начинает падать в трёх запусках из ста и каждый раз по новой причине.
В статье разберём пять типовых источников такого поведения — от плавающих версий образов и неправильного ожидания готовности до конфликтов портов и нехватки памяти — и покажем, как сделать интеграционные тесты воспроизводимыми на пайплайне.
Сплиттер работает корректно, метрика посчитана, а p‑value уверенно опустился ниже 0,05 — результат кажется готовым к раскатке. Однако ошибка в оценке дисперсии способна превратить случайное различие в статистически значимое.
В этой статье разберём четыре типовых сценария, в которых тест подтверждает эффект, которого в данных нет, и посмотрим, как исправить расчёты.
Вызов LLM легко принять за обычную функцию — пока код не сталкивается с квотами, тайм‑аутами, повторными списаниями и плавающими результатами.
В статье разбираем пять типичных ошибок в Python‑коде вокруг языковых моделей и показываем, какие инженерные привычки помогают пережить реальную нагрузку без сюрпризов в продакшене.
Модуль ядра может собраться без предупреждений, успешно загрузиться и несколько минут выглядеть полностью исправным. А потом под нагрузкой поймать гонку, зависнуть на блокировке или уронить всю систему. Разберём пять типичных ошибок, которые не видит компилятор, но хорошо видит продакшен.
В статье разберём, как Pact закрывает этот разрыв между модульными и E2E‑тестами, как устроены consumer‑driven контракты, Pact Broker и can-i-deploy, и что нужно учесть, чтобы contract testing действительно останавливал несовместимые релизы, а не создавал новую точку боли.
Первая AI-фича часто ломается задолго до релиза — ещё на этапе, когда команда пытается описать, что именно она собирается делать. Привычного PRD с user stories и acceptance criteria уже недостаточно: поведение LLM зависит от промпта, модели, данных для оценки и множества граничных случаев.
В статье разбираем, какие разделы стоит добавить в спецификацию AI-продукта, чтобы команда понимала, как измерять качество, контролировать риски и принимать решения после запуска.
