Личный блог программиста
ProgCode.Ru
PHP, Bitrix, JavaScript, D, Windows и практические заметки из ежедневной разработки.
Материалы
Статьи
Эксплуатационная инструкция: от симптома к проверенному откату
Как описать опасную операцию так, чтобы оператор видел область сбоя, условия запуска, одно обратимое действие, сигнал остановки и критерий восстановления.
Web performance budget: как читать LCP, INP и CLS вместе
Разбираем, почему один показатель не объясняет скорость интерфейса, как разделить LCP, INP и CLS и превратить наблюдение в проверяемое действие.
Security headers: CSP и HSTS без иллюзии защиты
Как CSP и HSTS ограничивают браузер, почему nonce и HTTPS не заменяют исправление XSS и как вводить политики с проверяемым откатом.
Incident runbook: как пройти от симптома к проверенному rollback
Практический маршрут инцидента: зафиксировать симптом и границу влияния, проверить одну гипотезу, выполнить обратимое действие и доказать recovery по техническому и бизнес-сигналу.
Retry без шторма: как повторять HTTP-запросы безопасно
Повтор запроса переживает временный сбой только после проверки семантики операции, общего deadline и способа узнать результат записи. Разбираем backoff, jitter и безопасный отрицательный путь.
Миграция схемы БД без простоя: совместимые фазы expand, switch, contract
Как изменить схему при работающем старом и новом коде: сначала добавить совместимую форму, затем заполнить и проверить данные, переключить чтение и только после этого удалить старую колонку.
Trace Context в HTTP: как сохранить запрос на границе proxy
Если traceparent исчезает или не проходит проверку, gateway и сервис перестают видеть один запрос. Разбираем контракт proxy, безопасный fallback и проверку через реальный HTTP-маршрут.
TLS-сертификат: почему «curl работает» не закрывает проверку
Один успешный запрос доказывает только один набор условий: маршрут, SNI, часы, trust store и политику конкретного клиента. Разбираем, как отделить эти проверки и исправить причину без отключения TLS.
HTTP-таймауты: как разложить общий deadline на измеримые фазы
Запрос может завершиться таймаутом до ответа сервера или повторить запись после неясного результата. Разбираем общий deadline, фазы HTTP и безопасную проверку retry.
API-diff в code review: как найти несовместимость и сохранить откат
Практический разбор API-изменений: классифицируем риск, ищем потребителей, проверяем частичный rollout и удаляем старый контракт только после измеримого сигнала.
JSON Schema не разрешает операцию: как разделить форму, инвариант и состояние
JSON Schema проверяет форму документа, но не знает права пользователя и текущее состояние ресурса. Разбираем границу между схемой, доменным правилом и безопасной записью.
Совместимый API-ответ: как поймать breaking change до релиза
Разбираем ответ HTTP-метода на границе сервиса: какие изменения ломают старого клиента, как отделить форму JSON от состояния системы и чем доказать совместимость.
Авторизация, которую можно доказать: от симптома до отрицательного теста
К своему профилю API возвращает 200, к чужому — тоже. Разбираем, как связать security-требование, объектную политику, HTTP-проверку и доказательство отказа.
Аутентификация не даёт доступ: строим deny-by-default для объекта
Валидная сессия не делает любой id разрешённым. Разбираем BOLA, доверенные поля, границу tenant-а и отрицательные HTTP-тесты от URL до ответа.
SSRF начинается с URL: проверяем адрес до сетевого вызова
Практическая защита server-side запроса: разбираем URL, применяем точный allowlist, запрещаем обход через credentials и редиректы, а затем ограничиваем сам сетевой вызов.
Когда retry превращается в аварию: как связать попытку, deadline и результат
Собираем контракт событий попытки: как связать operationId и requestId, отделить timeout от ответа и остановиться по deadline без слепого повтора.
Retry после timeout: как не повторить бизнес-операцию дважды
Timeout сообщает о потерянном ответе, но не о результате записи. Идемпотентный контракт связывает повторы одной операции и не даёт сетевому сбою превратиться в дубль.
Retry без двойной записи: как связать timeout, 503 и идемпотентность
Разбираем, почему повтор HTTP-запроса нельзя включать одной настройкой. Сначала проверяем семантику операции, затем ограничиваем время, попытки и последствия сбоя.
p95 не изменился: как найти настоящую причину медленной страницы
Уменьшение bundle не гарантирует быстрый ответ. Разбираем полевой симптом, разделяем сервер, сеть и браузер, а затем принимаем решение по повторяемому p95.
Waterfall без иллюзий: как доказать, что ресурс задерживает первый экран
Длинная полоса в waterfall не равна причине задержки. Разбираем зависимость ресурса, инициатора и потребителя, а затем проверяем одно изменение на учебной странице.
Медленная первая загрузка: как отделить TTFB от блокирующих ресурсов
Практический маршрут для случая, когда пользователь видит пустой экран: разделяем ожидание ответа, передачу HTML, CSS и работу JavaScript, а затем проверяем одну гипотезу повторным замером.
HTTP и TLS без догадок: как найти границу сетевой ошибки
504, ошибка сертификата и 404 выглядят похожими в браузере, но рождаются на разных этапах. Разбираем безопасную диагностику: от имени узла и TLS до HTTP-статуса, логов и критерия готовности.
Почему HTTPS ошибается в разных местах: карта границ DNS, TCP, TLS и HTTP
Ошибка сертификата, таймаут и 404 могут выглядеть одинаково для пользователя, но требуют разных проверок. Разбираем порядок запроса, доверие к серверу, роль proxy и воспроизводимую запись результата.
HTTP и TLS: как за один запрос найти границу отказа
Практический маршрут от DNS и TLS к статусу HTTP: как отличить отсутствие маршрута от ошибки сертификата, проверить гипотезу и не сделать опасный retry.
Рост frontend bundle: как найти конкретный input и не чинить симптом
Общий размер JavaScript-артефакта показывает симптом, но не причину. Разбираем сопоставимый diff metafile, связь input с output и проверку реальной доставки в браузер.
Кэш frontend-сборки: как ключ сохраняет или скрывает устаревший результат
Разбираем границы кэша dependency optimizer и сборщика, составляем ключ из проверяемых входов и доказываем свежесть артефакта через положительный и отрицательный тест.
Сборка быстрее на 20%? Сначала докажите, что вход одинаковый
Как сравнивать frontend-сборки по одному входу, не принимать cache hit за ускорение и находить причину роста bundle по данным артефакта.
D и C ABI: как поймать ошибку до FFI-вызова
Разбираем сбой на границе D и C: layout структуры, порядок байтов, ownership и код возврата. В статье — воспроизводимый протокол проверки, пример wrapper и условия, при которых вызов нужно остановить.
D и C API: как закрыть небезопасную границу буфера
Как проверить pointer, length и lifetime до вызова C, изолировать @trusted и не принять атрибут @safe за доказательство всей системы.
D для прикладной утилиты: как проверить, нужен ли новый язык
Перед переходом на D измерьте workload, найдите границу с native-кодом и сравните стоимость toolchain с реальным выигрышем. Воспроизводимый benchmark и критерий готовности помогают принять решение, включая отказ от миграции.
Миграция данных пользователя Bitrix: сохранить смысл, а не только значение
Как перенести данные пользователя из legacy-контракта Bitrix без тихой потери: различить стандартные и UF-поля, сохранить пустые состояния, сделать read-back и безопасно повторить операцию.
Bitrix API и версия: имя метода не обещает одинаковый контракт
Как проверить установленную поверхность Bitrix API, сопоставить поля legacy и D7 и остановить миграцию, если среда не подтверждает совместимость.
Bitrix legacy без догадок: как сравнить CUser и D7 перед миграцией
Практический способ решить, что делать со старым вызовом Bitrix: зафиксировать наблюдаемый контракт, проверить callers и события, а затем выбрать сохранение, адаптер или замену.
502 без догадок: как восстановить цепочку запроса по логам
Практический разбор 502 по access и application log: как установить границу отказа, проверить корреляцию по request ID и не объявить приложение причиной без подтверждения.
Trace ID связывает события, но не доказывает причину
Как читать trace, log и metric вместе, проверять разрывы контекста и не принимать совпадение идентификатора за доказательство причины.
502, пустой экран и 403: диагностика по различающим сигналам
Практический маршрут от web-симптома к проверяемой причине: как сохранить конверт запроса, связать границы и отличить исправление от удачного повтора.
Инженерный кейс от проблемы до результата: как проверить причинность
Разбираем инженерный кейс на воспроизводимом примере: как связать симптом с причиной, выбрать проверку, измерить эффект и честно описать ограничения решения.
Инженерный кейс: как проверить причинность, а не приписать результат изменению
Если после изменения стало лучше, это ещё не доказывает причинность. Разбираем, как отделить событие от наблюдения, проверить механизм и остановить вывод, когда данных недостаточно.
Инженерный кейс: как связать симптом, решение и доказательство
Практический способ разобрать задержку API: проверить гипотезу о дублирующих вызовах, ограничить кэш одной операцией и не приписать изменению эффект без сопоставимых измерений.
Как сравнивать технологии, когда цена ошибки выше цены эксперимента
Сравнение технологий начинается не с рейтинга. Сначала нужно определить симптом, стоимость ошибки, критерии, измерение и границы вывода.
Как сравнивать технологии, если данных пока мало
Практический способ отделить наблюдение от предпочтения: как зафиксировать критерии, остановить псевдоточный выбор и подготовить проверяемое решение.
Как сравнивать технологии, когда ошибка стоит дороже прототипа
Практический способ сравнить технологии по границе задачи: отделить факт от допущения, посчитать цену перехода, проверить отказ и не выдавать пустую ячейку за нулевой результат.
Code review: как не пропустить риск изменения контракта
Форматирование занимает строки в комментариях, а изменение контракта остаётся без проверки. Разбираем порядок review, который связывает симптом, evidence, отрицательный путь и решение.
Code review как механизм управления риском: evidence, stop и решение
Как отличить замечание о стиле от риска контракта, состояния или границы доверия, запросить проверяемое evidence и не выдать предположение за готовое решение.
Code review без шума: как проверить риск изменения
Практический стандарт для code review: сначала назвать границу изменения и цену ошибки, затем запросить нужное доказательство и остановиться, если сильный вывод пока не подтверждён.
Граница frontend и backend: как доказать, где расходится правило скидки
Браузер показывает скидку, сервер считает другую сумму, а повторный запрос только запутывает расследование. Разбираем воспроизводимый кейс, контракт расчёта, статусы HTTP и безопасный порядок проверки.
Состояние экрана не угадывают по статусу: разделяем query, command и ошибку
Как провести границу между UI и API: отличить чтение модели от команды, разобрать 202, 204, 409, 422, 429 и 5xx и не показать пользователю состояние, которого сервер не подтвердил.
Ответ 200 не описывает экран: как проверить модель на границе UI и API
Успешный HTTP-ответ ещё не означает, что тело подходит экрану. Разбираем четыре проверки, отрицательные пути и безопасное поведение для 200, 202, 204 и ошибок API.
Сквозная наблюдаемость без ложной связи: UI, API и worker
E2E-тест падает, API пишет лог, worker считает задачу, но причина теряется между границами. Разбираем trace context, роли trace, log и metric, проверку очереди и отрицательный путь.
End-to-end наблюдаемость: как не перепутать сигналы с доказательством
Когда e2e-тест падает, совпадение имён в логах не связывает UI, API и worker. Разбираем propagation, смысл span/log/metric, отрицательный путь и критерий, при котором сквозной вывод можно считать проверяемым.
Сквозная наблюдаемость без ложных связей: UI, API и worker
Как сохранить trace context между UI, API и worker, не превращать trace id в измерение метрики и проверять асинхронную границу по воспроизводимому контракту.
Безопасный переход между старой и новой схемой
Как перенести поле или формат данных без разрыва совместимости: разделить чтение и запись, проверить реальные границы и заранее назвать состояние отката.
Миграция без ложного rollback: четыре проверяемые границы перехода
Rollback трафика не возвращает данные автоматически. Разбираем inventory, сопоставимый control/candidate, состояние данных и именованный триггер, чтобы отличить проверяемую готовность от зелёного статуса.
Миграция без прыжка: как сохранить данные и управлять откатом
Пошаговая схема миграции с инвентарём, совместимыми версиями, контрольным срезом трафика и отдельным планом возврата данных.
PHP, JavaScript и D на одной границе: как доказать совместимость
Практический разбор расхождения между PHP, JavaScript и D: явный контракт значения, ошибки и времени, отрицательные проверки и границы вывода.
Один payload, три runtime: как сохранить смысл на границе
Похожая структура данных не делает PHP, JavaScript и D взаимозаменяемыми. Разбираем контракт type, error и time, fail-closed проверку и границы вывода.
PHP, JavaScript и D: как не потерять смысл на общей границе
Три runtime могут передавать один payload и всё равно принимать разные решения. Разбираем узкий контракт результата, ошибки, времени и диагностики с воспроизводимой fail-closed проверкой.
Низкий CPU, длинный запрос: как найти границу задержки
CPU почти свободен, а пользователь ждёт ответ десять секунд. Разбираем trace, очередь, сопоставимую нагрузку и границу, за которой нельзя объявлять причину.
Почему короткий trace не доказывает ускорение системы
Как читать длительность root span, отделять ожидание от работы и проверять сопоставимость нагрузки до заявления об улучшении.
Медленный запрос при низком CPU: практический маршрут от браузера до базы
Пошаговый способ разобрать долгий end-to-end запрос: зафиксировать одну границу, связать браузерный timing с trace, проверить базу отдельно и остановиться там, где данных недостаточно.
Почему CORS не защищает POST: как проверить границы веб-безопасности
Чужой сайт может отправить запрос с cookie даже после настройки CORS. Разбираем механизм на тестовом endpoint, проверяем отрицательный путь и фиксируем границы вывода.
Почему список security controls не доказывает защиту веб-приложения
CSP, HttpOnly, CORS и сканер отвечают на разные вопросы. Разбираем путь от угрозы к точке прерывания, связываем его с проверяемым evidence и оставляем остаточный риск там, где данных недостаточно.
Безопасность веба начинается с границы: как доказать, что контроль прерывает атаку
CSP, CSRF-токен, CORS и проверка прав останавливают разные шаги атаки. Разбираем карту пути, рабочий пример с nonce, отрицательный тест и границы того, что действительно доказано.
Контракты данных: как не принять похожее поле за совместимое
Один consumer прочитал новый JSON, но это не доказывает совместимость всей схемы. Разбираем смысл полей, политику reader и fail-closed проверку producer → consumer.
Совместимость схемы — это направление, а не номер версии
Как compatibility gate отделяет направление чтения, обязательные поля, объявленные additions и возможности consumer — и почему неопределённость должна останавливать проверку.
Изменение схемы без устных договорённостей: как проверить контракт данных
Практический маршрут для изменения JSON-контракта: зафиксировать baseline, candidate, manifest, направление чтения и конкретного consumer до передачи изменения дальше.
Retry под нагрузкой: как остановить каскад запросов
Медленная зависимость сама по себе не валит сервис: его валят неограниченные повторы, fan-out и поздний fallback. Разбираем бюджет попыток, проверку трассы и безопасную деградацию.
Механика устойчивости: сначала ограничьте каскад, потом настраивайте retry
Timeout ограничивает ожидание одного вызова, но не объём дополнительной работы. Разбираем, как связать retry, fan-out, fallback и точку остановки в одну проверяемую модель.
Как остановить каскадный отказ: один бюджет для retry и fallback
Медленная зависимость превращает несколько разумных защит в каскад лишней работы. Разбираем владельца retry, предел fan-out, безопасный fallback и проверяемую точку остановки.
Совместимость платформенного API: проверка до изменения контракта
Как проверить изменение API на паре «контракт — потребитель»: отрезать несопоставимые операции, найти скрытые ожидания и передать результат с явными причинами и ограничениями.
Платформенный API без скрытых обещаний: как проверить контракт и потребителя
Успешный HTTP-ответ ещё не означает совместимость. Разбираем, как отделить схему от случайного поведения реализации, проверить пару «контракт — потребитель» и оформить особый режим так, чтобы он не стал вторым API.
Платформенный API без скрытых обещаний: как проверить контракт до hand-off
Инженерный маршрут для ситуации, когда потребителю нужен особый флаг, порядок или внутреннее поле: зафиксировать решение, проверить названного consumer и остановиться там, где начинается неописанное обязательство.
Как собрать инженерный год в проверяемый вывод
Разрозненные технические заметки не становятся знанием от одного общего вывода. Показываю, как собрать карточки событий, найти повторяющийся механизм, отделить факт от интерпретации и превратить результат в следующий проверяемый шаг.
Синтез инженерного года: как превратить наблюдения в проверяемое решение
Годовой обзор становится инженерным инструментом, когда отделяет решение от наблюдения, показывает цену выбора и оставляет проверяемую границу причинности.
Как разобрать инженерный год: от решения к проверяемому выводу
Практический способ собрать годовой разбор: отделить решение от наблюдения, записать альтернативы и стоимость, проверить время и не выдать совпадение за доказанный эффект.
Как проверять техническое утверждение по первоисточнику
Практический метод для случаев, когда ссылка выглядит убедительно, но не отвечает на вопросы о версии, контексте и границе применимости.
Как проверить источник до того, как он повлияет на решение
Дата, версия, HTTP-валидатор и цифровая подпись отвечают на разные вопросы. Разбираем, как связать источник с наблюдаемым фактом, не расширить его смысл и остановить неподтверждённое решение.
Как превратить ссылку в проверяемое техническое утверждение
Ссылка сама по себе не доказывает решение. Разбираем журнал утверждений: как зафиксировать версию источника, область применимости, наблюдение, отрицательный путь и следующий проверяемый шаг.
Promise.all не отменяет работу: как не потерять второй запрос
Promise.all объединяет результаты, но не останавливает уже начатые операции. На коротком примере разберём first rejection, порядок значений, allSettled и явную отмену через AbortController.
Promise.all не отменяет работу: как разделить результат и управление
Разбираем на трассировке, что именно отклоняет Promise.all, почему соседние операции продолжаются и как связать отмену с AbortController, не выдавая запрос на остановку за откат побочных эффектов.
Promise.all не отменяет работу: как объяснить границу и проверить её
Promise.all объединяет исходы асинхронных операций, но не управляет их остановкой. Разбираем порядок результатов, контрпример, AbortSignal и проверку, которую можно воспроизвести локально.
Как калибровать техническое интервью по фактам, а не по впечатлению
Практический разбор калибровки технического интервью: как разделить наблюдение, неизвестное и трактовку, найти первую точку расхождения и не превратить учебную пробу в необоснованный вывод о человеке.
Техническое интервью: как отличить наблюдение от инженерного вывода
Как устроить рабочую пробу так, чтобы reviewer фиксировал наблюдаемые факты, ограниченный вывод и безопасный следующий шаг, а не впечатление о кандидате.
Инженерное интервью: рубрика и рабочая проба вместо экзамена по терминам
Практический маршрут для технического разговора: ограниченная роль, рабочая проба, наблюдаемые критерии и учебный hand-off без оценки человека.
Как исследовать UX внутреннего инструмента и не принять мнение за факт
Разбираем запрос «сделать форму удобнее» через рабочий сценарий, наблюдаемое действие и проверяемый hand-off. Внутри — контракт заметки, отрицательные ветки, команда проверки и границы вывода.
UX внутреннего инструмента: как превратить наблюдение в проверяемое решение
Разбираем, как отделить действие коллеги от интерпретации, связать наблюдение с решением и остановить работу, если согласие, сценарий или ссылка на evidence не выдерживают проверки.
UX внутреннего инструмента: как найти проблему до правки интерфейса
Нейтральный сценарий и точная запись действия помогают отличить реальную трудность в рабочем процессе от просьбы добавить ещё одну кнопку. Разбираем consent boundary, воспроизводимый decision log и отрицательные пути.
Когда рост conversion не означает улучшение продукта
Полевой разбор ситуации, в которой conversion выросла, а обращения в поддержку удвоились: как сверить cohort, качество результата и guardrail до решения о раскатке.
Рост conversion не равен улучшению продукта: проверяем denominator и guardrail
Практический способ проверить продуктовую метрику до решения: зафиксировать событие, population, cohort, attribution, окно и denominator, затем сопоставить сигнал с guardrail и остановить вывод при разрыве данных.
Метрики продукта для инженера: от изменения к проверяемому решению
Рост conversion сам по себе не доказывает пользу релиза. Разбираем контракт события, cohort, denominator, атрибуцию и guardrail на воспроизводимом примере, который останавливает расчёт при неполных данных.
Когда внутренний инструмент заставляет разработчика ждать
Разбираем учебный кейс долгого запуска проекта: как отделить очередь, неясный маршрут и реальную ошибку, измерить путь до первого успешного изменения и выбрать проверяемое улучшение.
Удобство внутреннего инструмента: как проверить путь одной задачи
Внутренний сервис может быстро завершать операции и всё равно заставлять людей искать владельца и повторять запрос. Разбираем контракт задачи, разделяем события, наблюдения и сигналы поддержки, а затем проверяем гипотезу без неподтверждённых обещаний.
DX внутреннего инструмента: найти место, где застревает задача
Практический маршрут от симптома к проверяемой гипотезе: одна задача, пять видов свидетельств, локальная проверка и безопасная остановка без доказательства эффекта.
Как ограничить batch-автоматизацию до безопасного изменения
Разбираем учебный кейс с массовым скриптом: как связать preview, точный scope, approval, проверку результата и отдельный план восстановления, чтобы не принять успешный exit code за доказательство правильных данных.
Почему preview и approval не делают автоматизацию безопасной
Preview показывает рассчитанное намерение, authority ограничивает допустимый scope, approval связывает согласие с конкретной операцией, а verification читает результат. Если эти доказательства смешать, batch-автоматизация может изменить лишние объекты.
Как безопасно автоматизировать массовые изменения: preview, approval и проверка результата
Практический маршрут для операций, которые меняют сразу много объектов: зафиксировать состав targets, связать preview с разрешением, проверить отказоустойчивость и отделить receipt исполнителя от фактического состояния системы.
Почему замаскированный лог всё ещё нельзя отправлять в AI-инструмент
Разбираем синтетический кейс: как отделить класс данных, условия сервиса, сетевой маршрут и полномочия, а затем воспроизвести безопасную остановку без внешнего запроса.
Данные и приватность в AI-инструментах: как принять инженерное решение
Передача контекста в AI — это не одно разрешение, а проверяемая цепочка из класса данных, условий обработки, маршрута и полномочий. Разбираем fail-closed контроль с воспроизводимым отрицательным примером.
Перед AI-инструментом данные должны пройти четыре независимые проверки
Практический маршрут для безопасной передачи контекста: классификация записи, условия сервиса, egress и scoped authorization с воспроизводимым fail-closed тестом.
Когда поиск по базе знаний должен остановиться
Похожий фрагмент не становится доказательством только из-за высокого score. Разбираем проверку версии, доступа и точной цитаты, а также воспроизводимый stop-ответ для неполного результата.
Почему высокий vector score не доказывает ответ
Vector search ранжирует похожие фрагменты, но не подтверждает их смысл, свежесть и право показа. Разбираем decision trace, отрицательный путь и проверку источника до ответа.
Поиск по инженерной базе: как не превратить похожий текст в доказательство
Практический маршрут для retrieval по инженерной документации: сначала проверить версию, срок, права и точную цитату, а затем решать, можно ли отвечать.
Как проверить AI-предложение кода до merge
Зелёный happy path не доказывает сохранность API и правил доступа. На примере трёх границ разбираем отрицательные тесты, команды проверки и критерий готовности изменения.
Почему зелёный тест не доказывает корректность сгенерированного кода
Разбираем, как проверять сгенерированный diff по контракту, состоянию, отрицательной ветке и пути потребителя — и когда расхождение доказательств должно остановить merge.
Зелёный тест не доказывает корректность AI-изменения
Пошаговый способ проверить сгенерированный diff: от контракта и отрицательных сценариев до потребителя, зависимостей и решения о merge.
AI-помощник в задаче: как проверить diff перед merge
Сгенерированный код может пройти happy path и всё равно выйти за границу задачи, изменить контракт или добавить непроверенную зависимость. Разбираем практический gate перед merge: scope, отрицательные ветки, evidence и ограничения человеческого решения.
Как принять код, предложенный AI-помощником
AI-помощник ускоряет черновик, но не принимает решение за инженера. Разбираем, как проверить область изменения, контракт, отрицательный путь и зависимости до merge.
AI-помощник в разработке: как проверить и принять ограниченный diff
AI-помощник ускоряет черновик, но не знает скрытый контракт репозитория. Показываю, как ограничить контекст, проверить отрицательные ветки и принять только diff с наблюдаемым evidence.
Год сопровождения: как принять решение по повторяющейся проблеме
Практическая схема для повторяющихся проблем сопровождения: отделить факт от гипотезы, проверить границу риска и выбрать между ограниченным экспериментом, остановкой и перепроверкой.
Как приоритизировать сопровождение без ложной точности
Maintenance backlog становится полезным, когда отделяет наблюдаемый факт от оценки. Разбираем evidence, повторяемость и uncertainty, чтобы выбрать следующую проверку и не принять учебный score за прогноз.
Maintenance review: как превратить повторяющуюся проблему в проверяемый план
Повторяющиеся задачи сопровождения нельзя приоритизировать по раздражению. Разбираем, как отделить симптом от причины, оценить риск, проверить гипотезу на выгрузке и оставить команде ограниченный следующий шаг.
Как удалить устаревший API и не сломать последнего клиента
Депрекация не доказывает, что endpoint больше не используют. Разбираем removal gate: как отделить активного клиента от неизвестной зоны, выбрать проверку, остановить удаление и определить готовность изменения.
Deprecation API: как доказать готовность к удалению
Пустой график вызовов не доказывает, что API никому не нужен. Разбираем границы deprecation, Sunset и removal gate на воспроизводимом примере.
Депрекация API без аварии: карта потребителей и gate удаления
Дата Sunset и пустой график вызовов не доказывают, что endpoint можно удалить. Показываю, как ограничить scope, собрать карту потребителей и остановить опасное удаление.
Ёмкость и стоимость: как выбрать следующий предел, а не самый большой инстанс
Большой инстанс может улучшить одну latency-метрику и одновременно увеличить расход и операционный риск. Разбираем причинную цепочку, проверку и безопасный критерий следующего шага.
Ёмкость и стоимость: как связать нагрузку, ресурс и счёт
Низкая загрузка и зелёный SLO не показывают цену сами по себе. Разбираем цепочку от workload до billing unit и даём воспроизводимый способ проверить следующий предел ёмкости.
Ёмкость и стоимость: почему зелёный SLO не означает дешёвую систему
Практическая схема для случая, когда задержка укладывается в SLO, а счёт растёт: разделяем нагрузку, резерв, фактическое использование и единицу тарификации.
ADR устарел: как проверить решение и не переписать его историю
Старый ADR не становится неверным только потому, что изменился код. Разбираем drift, successor-запись, confirmation и безопасный переход от Accepted к Superseded.
ADR как журнал компромисса: решение, цена и путь назад
Хороший ADR сохраняет не только выбранный вариант, но и исходное ограничение, отклонённые альтернативы, цену решения и сигнал для пересмотра. Разбираем это на сценарии долгого экспорта.
ADR без бюрократии: как сохранить причину технического решения
Практический разбор ADR на учебном BFF-кейсе: как отделить факт от гипотезы, сравнить альтернативы, записать цену выбора и понять, когда нужен новый decision record.
Feature flag после rollout: как отделить rollback от cleanup
Выключенный feature flag прекращает выдачу нового поведения, но не удаляет ветки, конфигурацию и несовместимые данные. Разбираем безопасный rollout, проверяемый rollback и отдельный cleanup gate.
Feature flags без рассинхрона: где принимать решение и что считать показом
Как разделить серверное решение, клиентское отображение и аналитическое событие, чтобы rollout оставался объяснимым, а временная ветка действительно исчезла.
Фича-флаг как контракт выпуска: включить, проверить, удалить
Release-флаг снижает риск только тогда, когда у него есть ограниченная аудитория, безопасный fallback, владелец, срок пересмотра и заранее описанное удаление.
Когда версия не доказывает релиз: проверка artifact, migration и rollback
Как связать commit, provenance, digest, migration и точку возврата до approval — с воспроизводимым gate, отрицательным тестом и честными границами rollback.
Инженерия релиза: как доказать связь артефакта, миграции и отката
Одинаковая версия в CI не доказывает, что будет доставлен нужный код. Разбираем цепочку commit → artifact → migration → rollout и ставим проверяемый stop до deploy.
Релиз без догадок: как связать commit, artifact и rollback
Одинаковый tag не доказывает, что команда собирается доставить нужный код. Разбираем проверяемую цепочку от commit до rollout, отрицательный путь и границу rollback для данных.
Kubernetes без ложных сигналов: как связать rollout, readiness и HPA
После обновления образа новые Pod могут запускаться, но не получать трафик, а HPA — не менять число реплик. Разбираем четыре разных контура, команды проверки и безопасный критерий готовности.
Контейнерная нагрузка без догадок: как связать requests, readiness и HPA
После обновления образа Pod может стать Unready, а HPA — не изменить число реплик. Разбираем, какой механизм отвечает за placement, traffic и масштабирование, как проверить гипотезу и когда изменение манифеста действительно готово.
Контейнерная нагрузка: как связать ресурсы, готовность и автомасштабирование
Почему Pod может успешно разместиться, но не выдержать трафик: разбираем requests и limits, readiness и HPA на одном учебном примере.
Платформенный шаблон без ловушки fork: как провести границу решения
Шаблон ускоряет повторяемый путь, но не заменяет архитектурное решение. Разбираем симптомы слишком широкой формы, проверяем контракт, безопасное расширение и корректный отказ до создания репозитория.
Платформенный шаблон как контракт: базовый путь, расширение и отказ
Как превратить шаблон для команд в ограниченный контракт: отделить копию репозитория от наследования, закрыть входные параметры и остановить запрос, который требует отдельного архитектурного решения.
Платформенный шаблон без ловушки универсальности: контракт, расширение и отказ
Шаблон экономит время только там, где повторяется один и тот же класс решений. Разбираем границы golden path, именованного расширения, отрицательного пути и проверяемой готовности.
Миграция данных без ловушки: совместимость, backfill и безопасный contract
Новая колонка не становится безопасной от одного deploy. Разбираем полевой кейс: старый writer ещё жив, backfill не имеет границы остановки, а удаление прежней формы нельзя объявлять rollback-операцией.
Миграция данных без разрыва контракта: expand, backfill и граница отката
Как провести изменение формы данных при смешанных версиях приложения: сохранить совместимость старых reader и writer, ограничить backfill и не принять удаление старой формы за rollback.
Миграция данных без ловушки отката: expand, migrate, contract
Как менять схему при смешанных версиях приложения: сохранить совместимость, ограничить backfill, проверить отрицательный путь и не принять удаление старого поля за обычный rollback.
Границы пакетов: как остановить утечку домена в общую utility
Общая utility начинает ломать архитектуру задолго до падения сборки: она узнаёт доменные типы, а consumers обходят public API через internal-файлы. Разбираем симптомы, проверку границы и безопасные варианты исправления.
Границы пакетов: как отделить public API от внутренностей
Публичный API пакета — это договор о маршрутах импорта, данных и владельце смысла. Разбираем, как обнаружить утечку домена, ограничить deep import и не перепутать возможности Node.js, TypeScript и ESLint.
Границы пакетов: как закрыть deep import и не смешать домен с утилитой
Общий пакет начинает дорожать в сопровождении, когда его внутренние файлы становятся API, а доменные типы проникают в нейтральную утилиту. Разбираем контракт root entry point, проверку через exports, TypeScript и ESLint и безопасную миграцию существующих импортов.
Модульный монолит под ревью: как остановить протечку границ
Три похожих импорта могут незаметно связать каталог, checkout и оплату. Разбираем границы на учебном примере, проверяем API и направление зависимостей, а затем выбираем обратимое исправление.
Модульный монолит: как удержать границы до распила на сервисы
Папки по доменам не защищают код от скрытых связей. Разбираем публичную поверхность модуля, карту разрешённых направлений, циклы и проверку, которую можно встроить в review.
Модульный монолит: как сделать границы зависимостей проверяемыми
Папки не защищают модуль от чужих импортов. Разбираем публичную поверхность, разрешённые направления, цикл зависимостей и проверку, которую можно встроить в тесты.
Модернизация legacy-системы: как ограничить rollout и не перепутать rollback с восстановлением данных
Практическая схема замены одного участка legacy-системы: узкий шов, сравнимый control, ограниченная волна и отдельная проверка обратимости данных.
Модернизация legacy без ложной совместимости: как проверять поведение
Одинаковый HTTP-ответ не доказывает совместимость старой и новой реализации. Разбираем контракт, побочные эффекты, повтор запроса и минимальную проверку перед переключением маршрута.
Модернизация legacy-системы: как выбрать безопасный шов
Полное переписывание редко начинается с доказанной границы. Разбираем, как выделить одну операцию, описать её поведение, подключить новый путь через адаптер и не спутать возврат маршрута с восстановлением данных.
Аудит веб-проекта: как превратить список рисков в безопасный порядок исправлений
Длинный отчёт аудита не говорит, что исправлять первым. Разбираем учебный кейс через scope, актив, доказательство, влияние и обратимую проверку — с таблицей приоритетов и безопасными командами.
Аудит веб-проекта: как превратить наблюдение в проверяемый вывод
Практический аудит начинается не со сканера, а с границ системы, разрешённых действий и цепочки доказательств. Разбираем, как отделить факт от гипотезы и выбрать безопасный следующий шаг.
Аудит веб-проекта: scope, разрешение и воспроизводимая проверка
Как очертить путь данных, разделить scope и разрешение и подготовить одну безопасную проверку до активного тестирования. С картой границ, локальным fail-closed примером и диагностической таблицей.
Postmortem без поиска виноватого: от неполного сигнала к проверяемому действию
Как отделить факт от поздней гипотезы, восстановить контекст решения и выбрать одну защиту с измеримым критерием. Внутри — безопасный пример и границы применимости.
Postmortem без поиска виноватого: как отделить факт от решения
Разбираем, как сохранить в postmortem границу знания: что команда видела до действия, какую гипотезу проверяет и как связать профилактику с измеримым критерием.
Postmortem, который помогает исправить систему
Практическая схема разбора сбоя: отделяем наблюдение от гипотезы, сохраняем контекст решения и превращаем профилактику в проверяемое действие.
SLI/SLO в релизном разговоре: от красного графика к проверяемому решению
Как связать SLI, SLO и error budget с пользовательским путём, окном измерения и обратимым действием — и не выдать один график за доказательство инцидента или автоматический запрет релиза.
Error budget без магии: как связать SLI, окно и решение
Error budget появляется не из красного процента, а из явных границ измерения. Разбираем SLI, SLO, знаменатель, окно и policy на воспроизводимом примере и показываем, почему арифметика не является release-gate.
SLI и SLO: договор измерения, которому можно доверять
Как связать показатель качества с пользовательским исходом: определить знаменатель, хороший результат, окно и error budget, проверить отрицательный путь и не принять HTTP-статус за готовую операцию.
Ошибка без причины: маршрут диагностики через log, metric и trace
Пошаговый маршрут, который не подменяет один correlation ID новой label-кардинальностью: как разложить симптом, гипотезу и evidence между metric, trace и log/event record.
Почему trace ID не должен становиться label метрики
Trace, metric и log отвечают на разные вопросы. Разбираем, как сохранить корреляцию одного запроса, не превратить метрику в журнал событий и проверить отрицательный путь.
Логи, метрики и трассы: как связать один сбой без взрыва cardinality
Пошаговая схема корреляции для распределённого запроса: метрика показывает класс отказа, trace — путь, а структурированный лог — причину конкретного события.
Flaky e2e-тест: как найти причину и сохранить сигнал
Если первый запуск падает, а retry проходит, тест не становится надёжным. Разбираем locator, actionability, готовность интерфейса, данные и trace, чтобы менять только доказанный слой.
Почему e2e-тест проходит на retry: четыре контракта устойчивого сценария
Timeout в e2e-тесте не объясняет причину. Разбираем locator, actionability, пользовательский результат и retry, чтобы отличать настоящий дефект от замаскированного падения.
E2E без лишних retry: ждать факт, а не тишину интерфейса
Почему retry не лечит e2e-падение: отделяем locator, условие готовности, повторный запуск и evidence, а timeout меняем только после проверки контракта.
Контракт API прошёл schema-проверку, но сломал сценарий: как найти расхождение смысла
Валидный JSON не доказывает совместимость consumer и provider. Разбираем случай с nullable-полем, отделяем форму ответа от его смысла и задаём проверяемый шлюз перед выпуском.
Почему schema match не равен совместимости API
Ответ может соответствовать OpenAPI и всё равно сломать действие на экране. Разбираем границу между формой JSON, ожиданием consumer и проверкой provider на конкретном состоянии.
Контрактные тесты API: почему зелёная схема не гарантирует совместимость
Контракт ловит не только исчезнувшее поле, но и расхождение между допустимым ответом и действием consumer. Разбираем interaction, provider state, verification и безопасный release gate.
Токен в образе: как проверить цепочку поставки до deploy
Разбираем случай, когда токен тестовой среды оказался в контейнерном образе: как найти след, заменить небезопасный способ сборки, сопоставить digest с provenance и не объявить релиз проверенным без доказательств.
Attestation не доказывает provenance: как связать секрет, сборку и артефакт
Файл attestation рядом с образом ещё не подтверждает его происхождение. Разбираем границы секрета, digest, builder identity и проверку, которая связывает provenance с тем, что действительно попадает в deploy.
Секрет в CI и digest образа: как проверить цепочку поставки
Разбираем выпуск, в котором pipeline зелёный, но непонятно, какой commit и образ попали в deploy. Показываем границу секрета, проверку provenance и отрицательный путь.
Шумное правило статического анализа: как принять обратимое решение
Один результат статического анализа не объясняет, нужно ли менять правило или ограничить только этот сигнал. Разбираем контекст, scope, срок, rollback и проверяемый критерий готовности.
Статический анализ: где заканчивается правило и начинается решение
Линтер и анализатор быстро находят совпадения в коде, но не выносят вердикт о работе приложения. Разбираем модель, воспроизводимую проверку и границы применимости.
Шумное правило статического анализа: как разобрать сигнал и выбрать действие
Статический анализ сообщает о совпадении, а не выносит готовый вердикт. Разбираем SARIF-результат, восстанавливаем путь данных и выбираем keep, tune или точечное suppress без глобального отключения правила.
Безопасность зависимостей: как проверить транзитивный пакет до релиза
Сканер нашёл пакет, которого нет в package.json. Разбираем путь через npm-дерево, lockfile, production-артефакт и runtime, затем проверяем обновление и откат без ложного PASS.
Advisory, lockfile и SBOM: как доказать состав выпуска
Имя пакета в advisory ещё не доказывает риск для конкретного выпуска. Разбираем границы manifest, lockfile, SBOM и runtime, показываем проверку npm-командами и критерий, при котором неизвестность не маскируют под «безопасно».
Advisory зависимости: как доказать, что сигнал относится к вашему выпуску
Совпадение package и версии с advisory ещё не доказывает риск в приложении. Разбираем lockfile, SBOM, путь зависимости и безопасный порядок обновления с воспроизводимыми командами.
CORS, preflight и CSRF: как найти настоящую причину ошибки cookie API
Интерфейс теряет ответ, OPTIONS получает отказ, а mutation заканчивается 403. Разбираем границы CORS и CSRF, проверяем контракт по фактам и не снимаем защиту ради быстрого зелёного теста.
CSRF и CORS: где заканчивается доступ к ответу и начинается защита действия
Разбираем на одном cookie-аутентифицированном endpoint, чем отличаются origin, CORS, preflight и CSRF-проверка, как воспроизвести запрос через curl и где заканчиваются гарантии каждого слоя.
Cookie API и виджет: как не перепутать CORS с CSRF
Разделяем три проверки для cookie-аутентифицированного API: origin, доступ JavaScript к ответу и право принять изменение данных. На одном PATCH разбираем preflight, CSRF-токен и отрицательные тесты.
Старый session ID после rotation: как проверить logout и не закрыть новую сессию
После renewal старая вкладка не всегда означает старую cookie: запрос мог уйти раньше, прийти позже или иметь другой scope. Разбираем server-side проверку, stale-события, logout и воспроизводимый fixture.
Сессия после rotation и logout: кто решает, действителен ли запрос
Cookie доставляет идентификатор, но не принимает решение о доступе. Разбираем серверную запись сессии, смену current ID, logout и отрицательные проверки со старым идентификатором.
Сессия после rotation и logout: один контракт для cookie и сервера
Как отделить cookie от серверной сессии, не принять старый ID после rotation и доказать logout повторным запросом, а не только исчезновением записи в браузере.
Модель угроз для одного потока: от симптома до проверяемого контроля
Как разобрать security-sensitive изменение, когда команда предлагает контроль, но не называет актив, границу и злоупотребление. На примере одного API-потока — схема, код, таблица диагностики и критерий готовности.
Модель угроз: от актива к проверяемому контролю
Как связать актив, злоупотребление, границу и контроль в одну проверяемую модель — с учебным контрактом, отрицательным путём и явными ограничениями.
Модель угроз перед чек-листом: поток, актив и граница
Практический способ разобрать один поток до выбора контроля: назвать актив, злоупотребление, границу доверия и наблюдаемое доказательство.
Как остановить фичу без подтверждённой пользовательской проблемы
Макет и оценка не доказывают, что интерфейс нужно менять. Разбираем путь от наблюдаемого симптома к вопросу, гипотезе и проверяемому решению.
Как проверить пользовательскую проблему до изменения интерфейса
Разбираем цепочку от наблюдения до решения: как отделить факт от объяснения, выбрать проверку под вопрос и не принять готовый UI за доказательство проблемы.
Как проверить пользовательскую проблему до изменения интерфейса
Команда часто начинает с готового UI-решения, хотя проблема ещё не описана. Разбираем цепочку от наблюдения до проверяемого следующего шага и показываем, когда изменение нужно отложить.
Когда тормозит Bitrix-страница: как найти границу проблемы и не сломать кеш
Практический разбор медленной Bitrix-страницы: отделяем запрос, компонент, кеш и шаблон, проверяем ключи результата и принимаем только обратимые решения.
Производительность Bitrix-страницы: модель, ограничения и границы
Разбираем контракт встроенного кеша Bitrix: какие части ключа названы, где заканчивается документация API и почему ветка учебной модели не равна наблюдению сервера.
Производительность Bitrix-страницы: как найти узкое место без оптимизации наугад
Разделяем маршрут, компонент, кеш и шаблон, сверяем зависимость результата и выбираем одно обратимое действие вместо отключения кеша вслепую.
UI-тест после клика: ждать состояние, а не время
Как разобрать flaky UI-тест: связать действие с наблюдаемым состоянием, отсеять устаревший ответ и проверить отказ без ложного успеха.
Механика UI-проверки: сделать состояние наблюдаемым
Как отделить transition, наблюдение и assertion, чтобы не лечить флак произвольным ожиданием.
UI-тест ждёт состояние, а не секунду
Как заменить хрупкую паузу после действия на наблюдаемый контракт, проверить отрицательный путь и понять, когда сценарий действительно готов.
Мобильный интерфейс: как вернуть скрытое действие и не сломать откат
Если на узком экране основной шаг виден только при наведении или теряется за таблицей, сначала восстановите наблюдаемое действие, затем проверьте причину и только после этого меняйте layout.
Мобильный интерфейс без скрытого действия: как разделить среду и маршрут
На узком экране действие часто исчезает не из-за одного breakpoint. Разбираем границу между возможностями ввода, состоянием компонента и обязательным маршрутом, а затем проверяем отрицательный путь.
Мобильное действие без скрытого шага: маршрут, который не зависит от hover
Если главное действие исчезает на узком экране, ищите не только breakpoint, а потерянный маршрут. Разбираем явный mobile-путь, fail-closed проверку и границу между учебной моделью и браузером.
Когда маленькая картинка тормозит страницу: как найти причину в media-слоте
Изображение может быть маленьким на экране и большим в сети. Разбираем source mapping, геометрию, priority и безопасную проверку одной обратимой правки.
Медиа без ложных метрик: как отделить контракт компонента от наблюдения браузера
Изображение может иметь правильный размер в данных и всё равно поздно попасть на экран. Разбираем слои media slot, границы LCP-наблюдения, учебный контракт и обратимую проверку.
Медиа в первом экране: разделите разметку, геометрию и измерение
Поздний hero и скачок карточки часто начинаются с одной ошибки: команда смешивает описание ресурса, резервирование места и браузерное наблюдение. Разбираем контракт media slot, отрицательный путь и проверяемый критерий готовности.
Плохая сеть: как сохранить черновик и не перепутать результат запроса
При обрыве сети интерфейс не знает, дошла ли операция до сервера. Разделяем черновик, попытку и подтверждение, чтобы не потерять текст и не создать опасный повтор.
Плохая сеть: как разделить попытку, подтверждение и черновик
Запрос может быть обработан, а ответ — потерян. Разбираем контракт, в котором версия черновика, логическая операция и попытка доставки живут отдельно, а поздний ответ не стирает новую работу.
Плохая сеть: как не объявить неизвестный результат успехом
Практический контракт для формы, которая сохраняет черновик, различает попытку и подтверждение и безопасно переживает потерю ответа.
Форма застряла между retry и старым ответом: диагностика и обратимый возврат к принятому снимку
Полевой маршрут для формы с поздним ответом, дубликатом и повторной отправкой: какие факты собрать, что остановить и где допустим локальный rollback.
Ошибка формы должна относиться к тому вводу, который человек видит
Как связать значение поля, попытку отправки и сообщение об ошибке, чтобы поздний ответ сервера не переписал исправленный ввод.
Старая ошибка формы после новой правки: как связать ответ с тем вводом, который сервер проверял
Если пользователь исправил поле, поздний ответ прежней отправки не должен менять текущую форму. Разбираем локальную проверку, версии полей, attemptId и честный retry.
Как менять токен дизайн-системы и не сломать соседний экран
Практический разбор правки токена: как зафиксировать симптом, оценить радиус изменения, проверить состояния кнопки и оставить точный путь к откату.
Контракт кнопки: как связать токены, состояния и доступную семантику
Разбор малого component contract: какие данные принадлежат токенам, состояниям, семантике и usage inventory, а какие нельзя подменять модельным visual payload.
Маленькая дизайн-система: начать с контракта кнопки, а не с каталога компонентов
Практический маршрут для одинаковых кнопок, которые разошлись по цвету, состояниям и семантике: named tokens, один минимальный contract, usage inventory и обратимая правка.
Доступный control после правки: как не потерять фокус, состояние и обратный путь
Визуально исправный control может потерять смысл для клавиатуры и screen reader. Разбираем расхождение состояний на примере панели настроек и задаём проверяемый путь исправления.
Контракт доступного control: имя, состояние и фокус должны меняться вместе
Почему role сам по себе не исправляет custom control и как связать name, state, focus route и declared status в одном контракте без заявления о реальном accessibility tree.
Доступный интерфейс начинается с маршрута фокуса
Как связать имя, роль, состояние и фокус в одном интерактивном сценарии и проверить ошибку до того, как пользователь потеряет управление формой.
Тяжёлый кадр в браузере: как найти причину и проверить обратимую правку
Если интерфейс дёргается, широкий участок Performance trace ещё не объясняет причину. Разбираем один пользовательский шаг через DOM-результат, владельца изменения, узкий диапазон записи и rollback.
Как браузер рисует изменение интерфейса: модель и границы
Разбираем путь от изменения DOM до видимого кадра: как найти forced layout в записи, отделить производительность от функционального результата и выбрать проверяемое изменение.
Медленный рендер: как связать DOM-изменение с причиной в кадре
Если интерфейс дёргается после одного действия, не называйте виновником весь браузер. Зафиксируйте DOM-изменение, отделите JavaScript от работы конвейера отрисовки и проверьте гипотезу одной записью Performance panel.
Когда total зелёный, а компонент красный: как проверять бюджет производительности
Общий score может пройти, пока отдельная часть маршрута уже превысила допуск. Разбираем контракт сравнения, named budgets, отрицательный путь и проверяемое действие без выдуманных production-выводов.
Почему общий PASS не спасает бюджет маршрута: механизм проверок
Разбираем механизм бюджета маршрута: сопоставимый контракт, именованные проверки, допуск, вторичный aggregate и ограниченная диагностика без подмены учебных чисел браузерной метрикой.
Бюджет производительности: как не спрятать регрессию за общим PASS
Как описать один пользовательский путь, разделить его бюджет на именованные части и остановить изменение, которое превышает допуск, даже если общий результат ещё выглядит зелёным.
SSR и CSR: как диагностировать повторный fetch после первого экрана
Первый экран уже пришёл с SSR, но после hydrate браузер повторяет fetch. Разбираем, как отличить отсутствие snapshot, рассинхрон версий, ошибку владельца состояния и осознанное обновление.
SSR и CSR без двойного состояния: как сохранить границу данных
Первый экран уже содержит данные, но после гидрации браузер запрашивает их снова и может заменить интерфейс. Разбираем владельцев source, HTML, snapshot и client state, а затем проверяем mismatch до любого автоматического восстановления.
SSR и CSR без рассинхронизации: как принять snapshot и не запустить второй запрос
HTML уже содержит данные, но после гидрации клиент снова обращается к API и может заменить первый экран. Разбираем контракт snapshot, контекст чтения и явный recovery path для mismatch.
Как проверить архитектурное решение, пока ошибка ещё обратима
Пошаговая диагностика случая, когда запись сохранена, но публичное чтение её не показывает. Разбираем границы решения, канонический write, intent, повторную доставку и read contract.
Архитектурное решение как проверяемый контракт: запись, повтор и откат
Схема не объясняет, что происходит после сбоя. Разбираем, как связать требования, evidence и assumption, отделить запись намерения от публичного эффекта и проверить безопасный повтор.
Граница публикации: как связать запись, событие и публичное чтение
Рабочая заметка может сохраниться, но не попасть в публичное чтение. Разбираем двойную запись, transactional outbox, повторную доставку и проверки, которые отделяют доказанный факт от предположения.
Нагрузочный тест: как отличить дрейф среды от узкого места
Рост ошибок или задержка после нагрузочного теста ещё не доказывают узкое место. Разбираем контекст запуска, профиль нагрузки и границы измерения, а затем выбираем одно проверяемое действие.
Почему «много запросов» не является нагрузочной моделью
Разбор механизма workload: arrival intent, профиль сегментов, evidence packet и synthetic bottleneck. Почему aggregate без среды и stop criterion не объясняет ни причину, ни следующее действие.
Нагрузочное тестирование: как связать профиль, измерение и решение
Нагрузочный тест даёт полезный ответ только тогда, когда команда заранее описала сценарий, среду, данные и критерий успеха. Разбираем практическую схему, пример на k6 и отрицательный путь, который не позволяет выдать учебный счётчик за capacity.
Пик latency в D-сервисе: как отделить allocation от GC, FFI и I/O
Редкий пик latency в D-сервисе не доказывает паузу GC. Разбираем один запрос: сохраняем result и error path, отделяем allocation от фактического сбора и проверяем FFI/I/O до изменения конфигурации.
Пауза в D-сервисе: как отделить GC от FFI и I/O
Один медленный request не доказывает, что виноват DRuntime. Разбираем путь decode → validation → compute → encode, отделяем allocation pressure от GC, FFI и I/O и проверяем гипотезу до изменения глобальной настройки.
D-runtime: как доказать лишнюю аллокацию в одном запросе
Если endpoint стал медленнее и рядом с ним виден GC, не меняйте настройки DRuntime вслепую. Сохраните контракт запроса, сравните вариант с копированием и вариант без копии, а затем отдельно проверьте GC, FFI и I/O.
Когда поле исчезло: как диагностировать несовместимость API
Клиент получил успешный HTTP-ответ, но не смог прочитать данные. Разбираем missing field, смену семантики и unknown request field, а затем выбираем обратимое действие.
Совместимость API: проверяйте request и response отдельно
Одинаковая JSON-схема не гарантирует совместимость: значение может сменить смысл, а новое поле — потеряться в старом сервере. Разбираем направления проверки, безопасное additive-изменение и остановку несовместимого retirement.
Версионирование API: как изменить контракт и не сломать клиентов
Пошаговая схема для изменения request и response: найти реальный разрыв, проверить старого и нового потребителя, а опасное удаление поставить на паузу.
Reader упал после записи: как проверить контракт хранилища
Практический разбор сбоя после изменения записи: как отличить неверный тип, отсутствие поля, сужение старых значений и смену смысла, не уничтожить evidence и вернуть дефект в compatibility test.
Контракт хранилища: как менять запись, не ломая старого reader
Совместимость хранилища зависит не только от JSON-синтаксиса. Разбираем presence, тип и смысл поля, безопасный порядок rollout и отрицательные проверки для writer/reader.
Контракт хранилища: как менять profile/settings без поломки старых читателей
JSON задаёт форму, но не объясняет смысл поля, различие между absent и null и границы совместимости. Разбираем контракт profile/settings, матрицу writer/reader и безопасный порядок изменения.
Документ сохранён, но не найден: как отделить задержку индекса от ошибки запроса
Карточка уже открывается, но поиск не возвращает новый документ. Разбираем путь от source до видимой выдачи, проверяем version и refresh и выбираем безопасное действие без удаления исходной записи.
Индексация и поиск: почему сохранённая запись ещё не видна
Запись уже открывается по прямой ссылке, но пропала из поиска. Разбираем путь source → ingest → index → refresh → query, проверяем устаревшую версию и выбираем безопасное действие.
Индексация и поиск: почему сохранённая запись ещё не видна
Карточка открывается по прямой ссылке, но поиск возвращает пустой результат или старую версию. Разбираем границы source, ingest, индексирования и refresh, а затем показываем проверяемый маршрут диагностики.
Replay события: как не записать второй result и не скрыть новую схему
Replay полезен только тогда, когда видно исходный event, consumer contract и уже записанный result. Разбираем evidence packet, duplicate, controlled replay, schema mismatch и маршрут без обещания exactly-once.
Как менять схему события и не сломать consumer
Валидный JSON не гарантирует совместимость события. Разбираем writer и reader contract, безопасное добавление поля, replay, версионирование результата и отказ без тихой подмены данных.
Событийный контракт: как пережить повтор и смену схемы
Повтор доставки и изменение payload выглядят как обычные ошибки очереди, пока у события нет устойчивой идентичности и версии. Разбираем envelope, контракт consumer и проверку, которая останавливает неизвестный вход до побочного эффекта.
Поздний владелец lease: как разобрать stale write без ложного диагноза
Когда старый worker пишет после expiry, сначала собираем leaseId, token и highest token ресурса. Такой пакет фактов отделяет stale write от duplicate, неверного release и предположений о времени.
Почему distributed lock не защищает позднюю запись
Lease координирует владельцев, но не останавливает проснувшийся процесс. Разбираем fencing token, атомарную проверку на ресурсе и диагностику stale write.
Распределённая блокировка: почему lease не защищает позднюю запись
Истёкший lease не останавливает старый worker и не отменяет уже отправленный запрос. Разбираем fencing token, атомарную проверку на ресурсе и отрицательный сценарий, который стоит воспроизвести до интеграции.
Когда сервисы видят разные данные: диагностика рассинхронизации по версиям и событиям
Заказ уже отменён в owner-сервисе, но downstream-система всё ещё разрешает отгрузку. Разбираем, как отличить задержку события от ошибки consumer-а и какое evidence собрать до replay, correction или компенсации.
Согласованность между сервисами: почему event id не заменяет версию и компенсацию
Повтор сообщения, пропущенная версия и неизвестный результат действия создают разные виды расхождения. Учебный пример показывает, как owner, consumer и компенсация удерживают состояние от отката и повторного эффекта.
Согласованность данных между сервисами: версия, владелец и безопасное действие
Один сервис уже отменил заказ, а другой всё ещё готовит его к отгрузке. Разбираем, как отделить owner-состояние от проекции, пережить gap и не превратить повтор события в новый бизнес-эффект.
Poison message в очереди: как остановить retry и сохранить задачу
Consumer повторяет одно сообщение, очередь шумит, а команда не знает, был ли уже создан эффект. Разбираем конечный retry, идемпотентный ключ, порядок обработки и ручной маршрут для poison message.
Очереди задач: как duplicate появляется после уже записанного эффекта
Разбираем границы delivery: подтверждение относится к доставке, а идемпотентность — к доменному эффекту. Отдельно фиксируем порядок, retry и ручной исход без обещаний exactly-once.
Очередь задач без иллюзий: повтор, порядок и право на эффект
Двойная отправка и застрявшие сообщения начинаются не с выбора брокера, а с неявного контракта. Разбираем идентификаторы, локальный порядок, ограниченный retry, защиту эффекта и ручной маршрут.
Инвалидация кеша: как доказать, что читатель получил старую проекцию
Пользователь видит старое значение после записи в source. Разбираем key, version, delayed event и visibility, чтобы выбрать точечное действие вместо очистки всего кеша.
Инвалидация кеша: почему TTL не заменяет версию
После успешной записи кеш может вернуть известную старую проекцию. Разбираем versioned invalidation: кто владеет версией, как key отделяет области выдачи, почему delayed event не заменяет проверку на read и как безопасно обработать private-данные.
Инвалидация кеша: ключ, событие и проверка чтения
Учебный контракт для одного публичного представления: владелец записи, key с областью читателя, версия, событие изменения и read с защитой от stale entry.
Граница транзакции PostgreSQL: как сохранить cross-row инвариант
Два успешных запроса могут вместе оставить ночную смену без дежурного. Разбираем scope проверки, row-level locks, deadlock и полный retry для SERIALIZABLE.
Почему транзакция не спасает сама по себе: snapshot, блокировки и retry в PostgreSQL
Два запроса могут честно выполнить SELECT и COMMIT, но нарушить общее правило данных. Разбираем, что видит snapshot, какие строки временно блокирует FOR UPDATE и почему Serializable требует повторить всю операцию.
Граница транзакции PostgreSQL: как сохранить правило между строками
Два запроса могут успешно изменить разные строки и вместе нарушить одно бизнес-правило. Разбираем write skew, область блокировки и полный retry на учебном примере PostgreSQL.
Разбор инцидента: как не принять обход за исправление
Запрос возвращает blocked, потому что обязательное поле теряется на границе mapper. Разбираем, как отделить факт от гипотезы, проверить обратимый обход и оставить защиту от повторения.
Разбор инцидента: как не перепутать симптом с причиной
После восстановления сервиса обход легко принять за окончательное решение. Разбираем цепочку от наблюдения до проверки и показываем, как сохранить отрицательный результат и превратить вывод в проверяемое действие.
Разбор инцидента: как отделить факт от поспешного исправления
Сервис отвечает ошибкой, команда меняет timeout, а причина остаётся неизвестной. Разбираем учебный случай через наблюдение, гипотезу, ограниченное действие, проверку и профилактику.
CSRF не должен быть обещанием: как проверить защиту административного POST
Старый административный POST может принять действие из чужого контекста, даже если в чеклисте написано «CSRF включён». Разбираем механизм, отрицательные проверки и критерий готовности без сканирования живого приложения.
Граница запроса: как собрать минимальный security baseline для state change
Один защищаемый POST показывает, почему сессия, CSRF-контекст, permission и response policy решают разные задачи. В статье есть учебный контракт, матрица проверки и критерий готовности без иллюзии production-аудита.
Минимальная защита старой админки: один маршрут, четыре контроля
Не начинаем с коллекции заголовков: для учебного маршрута связываем актив, угрозу, контроль и наблюдаемое доказательство.
Резервная копия не равна восстановлению: как проверить backup без риска для источника
Архив можно увидеть и скачать, но это ещё не доказательство восстановления. Разбираем manifest, checksum, область данных, изолированную цель и проверку результата на учебном PostgreSQL-сценарии.
Резервная копия PostgreSQL: как доказать, что её можно восстановить
Файл с совпавшим SHA-256 ещё не является рабочей резервной копией. Разбираем scope, manifest и безопасный restore на учебном примере PostgreSQL 12.
Резервная копия не равна восстановлению: как проверить PostgreSQL-архив
Файл backup может существовать, читаться и всё равно не содержать нужный объём данных. Разбираем scope, checksum и безопасный restore в изолированную базу.
Как читать распределённый trace: duration, parent и critical path
Практический разбор медленного запроса: как проверить связность trace, не сложить вложенные интервалы дважды и выбрать следующую проверку вместо поспешного увеличения timeout.
Trace context без иллюзий: как связать запрос и найти задержку
Если gateway и downstream видят разные trace, waterfall превращается в набор несвязанных чисел. Разбираем traceparent, parent/child span, синтетический пример и безопасный порядок проверки.
Трассировка запроса: как доказать задержку по одному trace
Разбираем учебный разрыв trace: как проверить traceparent на границах сервисов, не сложить перекрывающиеся span дважды и выбрать следующий измеримый сигнал.
Метрики приложения: как превратить график в проверяемое действие
Пользователь видит ошибку, а общий график запросов не объясняет причину. Разбираем counter, окно, labels и проверку учебного порога без выдуманных production-выводов.
Лейблы Prometheus: где заканчивается полезная размерность
На примере дежурства разбираем, почему label должен иметь ограниченный набор значений, как cardinality превращается в стоимость и каким запросом проверить counter, не превращая Prometheus в хранилище контекста.
Метрики приложения: как превратить сбой в проверяемый сигнал
Общий график запросов не отвечает, где возникла ошибка и что проверять дальше. Разбираем небольшой контракт для HTTP-операции: границу события, тип метрики, ограниченные labels, учебный запрос и действие после порога.
Разбор журнала: redaction и кардинальность до первой аварии
Выбираем поля для диагностики, удаляем чувствительные значения до сериализации и не превращаем event или route в бесконечный словарь.
Один request_id через границы: как связать журнал без ложной трассировки
Если gateway, API и worker пишут рядом, но не связывают события, диагностика превращается в догадку. Разбираем владельца request_id, передачу контекста, отрицательный путь и границы корреляции.
Структурированные логи: как связать один запрос и быстро найти ошибку
Контракт JSON-события, единый request_id и проверка отрицательного пути помогают найти запрос без поиска по случайному тексту. Разбираем форму записи, границы корреляции и redaction.
Потерянный ответ и повтор запроса: как не создать второй эффект
Timeout сообщает только о потерянном ответе. Разбираем связь requestId и Idempotency-Key, replay сохранённого результата, конфликт payload и границу, за которой автоматический retry нужно остановить.
Идемпотентный retry: как не выполнить одну команду дважды
Клиент получил timeout, но сервер мог уже создать результат. Разбираем scope ключа, fingerprint payload, конкурентный запрос, сохранённый ответ и границу внешнего эффекта.
Повтор HTTP-запроса без второго эффекта: ключ, результат и бюджет
Timeout не доказывает, что сервер ничего не сделал. Разбираем, как связать один пользовательский intent с idempotency key, ограниченным retry и повторяемым результатом.
Разбор: почему экспорт отчёта повторился и как остановить poison message
Учебный разбор двух путей: результат создан до потерянного ack и невалидная задача крутится в requeue. Собираем журнал, меняем порядок и вводим карантин.
Фоновая задача без дублей: delivery, ack и карантин
Как отделить бизнес-состояние фоновой задачи от доставки сообщения, поставить ack после результата и остановить бесконечный retry для неисправимых данных.
Фоновые задачи: как не терять намерение и переживать повторы
Как вынести долгую операцию из HTTP-запроса и сохранить проверяемое состояние между базой, брокером и worker: outbox, идемпотентность, ack и карантин.
Reverse proxy: как отделить 502, 504, неверную схему и адрес клиента
504, ссылка с http вместо https и одинаковый IP в логах — разные ветки диагностики. Разбираем один proxy-hop, безопасный access-log и порядок проверки без правок вслепую.
Reverse proxy под капотом: два соединения, заголовки и таймауты
Приложение видит не внешний запрос, а новый upstream-hop. Разбираем, как proxy меняет Host, forwarded-заголовки и время ожидания, и как проверить границу без догадок.
Reverse proxy перед приложением: как проверить границу HTTP
Приложение за proxy видит внутреннее соединение, а не клиента. Разбираем Host, forwarded-заголовки и таймауты по hop-ам, а затем проверяем контракт одним безопасным маршрутом.
CI/CD: как связать проверенный build с deploy
После зелёного build на staging оказывается другой каталог. Разбираем границу между сборкой и deploy: передаём один artifact, сверяем commit и останавливаем выпуск до сетевого действия.
Артефакт как контракт CI/CD: как не отправить непроверенную сборку
Зелёные job ещё не доказывают, что deploy отправит тот же каталог, который проверял build. Разбираем границу между checkout, cache и artifact и ставим проверку до сетевого действия.
Минимальный CI/CD pipeline: как не отправить непроверенную сборку
Практический разбор GitLab CI/CD: отделяем проверки от сборки, передаём deploy один артефакт и останавливаем выпуск, если его происхождение нельзя подтвердить.
Токен попал в лог: как провести ротацию и закрыть путь утечки
Удалить строку из кода недостаточно, если credential уже попал в лог, образ или историю Git. Разбираем учебный incident: ограничиваем распространение, меняем потребителей, отзываем старое значение и проверяем, что ошибка не вернулась.
Как конфигурация доходит до процесса и превращается в утечку
Сервис получает настройки через несколько границ: Git, сборку, образ, delivery и runtime. Разбираем, где значение должно остановиться, почему .gitignore не удаляет секрет из истории и как проверить путь без раскрытия credential.
Как доставить конфигурацию до процесса и не передать секрет в образ и лог
Сервис запускается локально, но в CI получает пустой URL, а токен может оказаться в Git, Docker-образе или логе. Разбираем границы конфигурации, добавляем проверку на старте и задаём воспроизводимый критерий готовности.
Старый PHP в Docker: как воспроизводимо поднять локальный проект
Проект требует версию PHP, которой нет на компьютере разработчика. Разбираем, как описать окружение в Docker, проверить границы между образом, контейнером и данными и не превратить чистый запуск в потерю локальной базы.
Почему локальный Docker ломается: адреса, файлы и состояние
Контейнер может быть запущен и всё равно не видеть базу, файл или переменную. Разбираем границы Compose и порядок проверки, который отделяет проблему хоста от проблемы контейнера.
Локальная разработка в Docker: как разделить код, данные и сеть
Контейнеры не делают окружение одинаковым сами по себе. Разбираем bind mount, named volume, сервисные имена и порядок проверки локального Compose-сценария.
Когда у ошибки четыре владельца: как разбирать код на стыке модулей
Неизвестный статус проходит через gateway и checkout, а команда ищет автора последней строки. Разделяем историю кода, владельца решения, маршрут review и проверку после merge.
Кому принадлежит изменение: Git, CODEOWNERS и границы ответственности
Последний автор строки не всегда знает смысл контракта, а CODEOWNERS не заменяет review. Разбираем, как разделить историю, маршрут проверки, решение и контроль после merge.
Ответственность за код: как назначать владельцев на стыке модулей
Последний коммит показывает историю строки, но не назначает владельца решения. Разбираем четыре роли, проверяем маршрут CODEOWNERS и не пропускаем неизвестный статус в success.
Два разных dist из одного commit: как найти первый разрыв сборки
Один commit даёт разные release-файлы у двух разработчиков. Разбираем, как отделить dependency drift, конфигурацию и generated data, а затем подтвердить исправление двумя чистыми прогонами.
Почему один commit даёт разные бандлы: механизм воспроизводимой сборки
Один и тот же commit не гарантирует одинаковый bundle. Разбираем границы входов сборки, канонический manifest и способ найти первый байт, который расходится между двумя чистыми прогонами.
Один commit — два dist: как доказать воспроизводимость сборки
Одинаковый commit иногда даёт разные assets. Разбираем входы webpack-сборки, чистую установку npm и manifest SHA-256, который показывает место расхождения.
Граница между legacy JavaScript и TypeScript: миграция одного API-потока
Безопасный переход начинается не с переименования файлов, а с контракта на границе API. Разбираем транспорт, проверку во время выполнения, проверку типов, отрицательный путь и откат для одного старого потока.
Миграция на TypeScript: где заканчивается тип и начинается runtime
Расширение .ts не проверяет JSON во время выполнения. Разбираем границу внешних данных, разницу между unknown и any и постепенный переход на TypeScript через один проверяемый шов.
Переход на TypeScript: одна проверяемая граница за шаг
Пошаговый способ перевести один контракт данных на TypeScript: сохранить существующую сборку, проверить внешний JSON и не прятать ошибки за массовым any.
Ошибка поля формы: текст, состояние и фокус должны быть одной системой
Красная рамка не объясняет ошибку и не возвращает пользователя к месту исправления. Разбираем контракт поля после submit: label, текст ошибки, aria-invalid, фокус и проверка в браузере.
Почему DOM не доказывает доступность: имя, роль и фокус
В разметке есть input и кнопка, но пользователь всё равно может потерять фокус или не понять ошибку. Разбираем, как браузер превращает HTML в доступное представление и что проверить на живой форме.
Базовая доступность формы: имя, фокус и понятная ошибка
Форма может работать мышью и всё равно оставлять пользователя без имени поля, видимого фокуса и объяснения ошибки. Разбираем короткий проверяемый маршрут и правки в нативном HTML.
Пустой первый экран при быстром HTML: как найти задержку в цепочке загрузки
Сервер отвечает быстро, но пользователь видит пустой каркас. Разбираем, как отделить позднее обнаружение ресурса, работу JavaScript, CSS и decode изображения и проверить исправление без выдуманных production-цифр.
Почему быстрый HTML не гарантирует быстрый экран
Первый байт, запрос ресурса и видимый экран — разные границы. Разбираем критический путь первой загрузки, находим владельца задержки и проверяем исправление без выдуманных production-результатов.
Первая загрузка: как найти владельца задержки
Пустой первый экран не объясняется словом «тяжёлая страница». Разбираем сеть, CSS, JavaScript и изображения по отдельным проверкам и выбираем одно изменение с воспроизводимым критерием.
Каталог замедлился после роста таблицы: как проверить индекс до изменения схемы
В кейсе каталога Seq Scan оказался не доказательством ошибки. Разбираем форму запроса, селективность и статистику, затем выбираем одно проверяемое изменение.
EXPLAIN ANALYZE: как понять, почему PostgreSQL выбрал этот план
Медленный SQL не всегда требует нового индекса. Разбираем дерево плана, сравниваем оценку с фактом, проверяем статистику и выбираем действие по данным, а не по названию узла.
Индекс есть, а запрос медленный: как читать план PostgreSQL
Индекс не обязан ускорять каждый запрос. Разбираем Seq Scan, селективность, статистику и форму условия через EXPLAIN ANALYZE, а затем выбираем действие по данным.
Контракт REST API: как не принять ошибку за пустые данные
Один и тот же сбой API не должен превращаться то в строку, то в пустой массив. Разбираем контракт ответа, воспроизводимую fixture и переход от локальной проверки к тестовому стенду.
REST API без угадывания: как зафиксировать контракт операции
Старый клиент получает валидный JSON, но показывает пустой экран, теряет последнюю страницу или повторяет ошибку. Разбираем контракт одной REST-операции: статусы, схемы, problem details, обязательные поля и cursor-пагинацию.
REST API без угадываний: как зафиксировать ответ операции
Список ломается не из-за URL, а из-за неявных правил: 200 скрывает ошибку, курсор исчезает на последней странице, а необязательное поле приходит то пустым, то отсутствующим. Разбираем контракт одной REST-операции и проверяем его по статусу, Content-Type и форме JSON.
Один URL, два ответа: как не склеить варианты в HTTP-кэше
После включения CDN пользователь получает не тот язык или старую версию страницы. Разбираем cache key, Vary и ETag на контролируемом примере и проверяем результат через origin и edge.
HTTP-кэш: почему правильный TTL не спасает ответ
Кэш проверяет не только срок свежести. Разбираем cache key, Vary, ETag и границы браузера, proxy и CDN на воспроизводимом сценарии.
HTTP-кэширование без устаревших ответов: контракт для HTML, assets и API
После релиза браузер показывает старый HTML, JavaScript или данные API. Разбираем, как связать cache key, свежесть, валидаторы и проверку ответа, чтобы кэш ускорял сайт, а не скрывал ошибку.
Почему поздняя проверка логина ломает состояние формы
Асинхронная проверка логина может показать ошибку для уже изменённого значения. Разбираем гонку ответов, версионирование состояния, привязку ошибки к полю и границы клиентской валидации.
Валидация формы: кто принимает решение и как не показать старую ошибку
Клиент быстро проверяет формат, сервер принимает окончательное решение, а асинхронный ответ должен относиться к текущему значению поля. Разбираем состояния формы, гонку запросов и проверяемый путь от input до submit.
Валидация формы без ложного успеха: поле, API и устаревший ответ
Браузер проверяет формат, сервер принимает бизнес-решение, а асинхронный ответ должен относиться к текущему значению. Разбираем контракт ошибки, доступную разметку и воспроизводимую защиту от гонки запросов.
Зависший фильтр: как отделить блокировку event loop от гонки ответов
Фильтр может тормозить по двум разным причинам: тяжёлая работа блокирует главный поток, а старый async-ответ перезаписывает новый. Разбираем обе ветки по трассе, коду и проверяемому критерию готовности.
Event loop без магии: где Promise ждёт, а интерфейс блокируется
Кнопка не отвечает, таймер срабатывает позже ожидания, а Promise обгоняет setTimeout. Разбираем стек, microtask и task, затем выбираем проверяемое исправление для данных и CPU-работы.
Event loop без догадок: как отличить порядок callback от блокировки UI
Promise-обработчик может прийти раньше таймера, а интерфейс — перестать отвечать. Разбираем две причины по наблюдаемым меткам, профилю и явному критерию готовности.
ES-модули в браузере: найдите второй запуск по фактическому URL
Виджет запускается дважды или импорт получает HTML вместо JavaScript. Разбираем module identity, разрешение относительных путей и проверку через Network.
ES-модули в браузере и Webpack: где разрешается import
Одинаковый синтаксис import проходит разные границы. Разбираем, как браузер строит URL графа модулей, что добавляет Webpack и как быстро найти причину 404, MIME-ошибки или «модуль не найден».
ES-модули в браузере: как найти причину 404, MIME и CORS
Страница загрузила HTML, но интерфейс не запустился: браузер не нашёл entry-модуль или его зависимость. Разбираем нативный граф ES-модулей, проверяем URL и ответ сервера, а затем фиксируем критерий готовности без сборщика.
jQuery и Webpack: как вернуть legacy-плагин после production-сборки
Старый jQuery-плагин работает в development, но пропадает после production-сборки. Разбираем порядок исполнения, глобальный window.jQuery и второй экземпляр зависимости, затем проверяем исправление в браузере и stats.json.
jQuery в Webpack: почему legacy-плагин теряет глобальный объект
В development форма работает, а production-сборка получает undefined вместо window.jQuery. Разбираем разницу между ProvidePlugin и глобальным объектом, порядок запуска legacy-плагина и проверку фактических production-ассетов.
jQuery в Webpack: как связать модульный код и legacy-плагины
После миграции на Webpack плагин видит $ только на одной странице или получает другой объект jQuery. Разбираем границы ProvidePlugin, window.jQuery и externals и заканчиваем проверяемым критерием готовности.
Bitrix: как заменить генерацию CODE в legacy-коде и не потерять исходное значение
Точечная замена обработчика Bitrix начинается с одного элемента: фиксируем исходный CODE, проверяем инфоблок, записываем только нужное поле и читаем результат обратно. Отдельно разбираем отрицательный путь и осторожный откат.
Bitrix: как отделить запись от смешанного save.php
Старый обработчик формы может изменить инфоблок, отправить уведомление и показать HTML в одном проходе. Разбираем, как отделить запись элемента, увидеть отрицательный путь и проверить локальный рефакторинг без ложного сообщения об успехе.
Bitrix: как безопасно заменить один CIBlockElement::Update
Как выделить узкий шов вокруг CIBlockElement::Update, проверить вход, не задеть чужой инфоблок и подтвердить результат повторной выборкой.
PHP: зелёный тест и нерабочая форма — как проверить БД, HTTP и конфигурацию
Модульный тест может пройти, пока форма падает на настоящем DSN, SQL или HTTP-ответе. Разбираем короткую интеграционную трассу PHP с тестовой БД, локальным callback и явным критерием готовности.
PHP-тесты: где mock заканчивается и начинается настоящая интеграция
Зелёный unit-тест не доказывает, что PHP отправил правильный SQL, открыл нужную базу и разобрал ответ драйвера. Разбираем границу между подстановкой и настоящим переходом через PDO.
PHP-интеграционный тест репозитория: проверить запись, чтение и откат
Unit-тест может быть зелёным, пока настоящий PDO не видит схему базы. Разбираем узкий интеграционный тест PHP-репозитория: отдельное подключение, запись, чтение, rollback и границы доказательства.
Bitrix: как не потерять изображение между preview и сохранением формы
Preview показывает выбранный файл, но не доказывает, что Bitrix получил его и записал в PREVIEW_PICTURE. Разделяем нативный multipart-контракт и AJAX-режим FileInput, разбираем ветки замены и удаления и проверяем результат после обновления элемента.
Bitrix API: как встроить редактор изображений и сохранить файл в элементе
FileInput показывает выбранную картинку, но не сохраняет её сам. Разбираем контракт формы, проверку загрузки и привязку файла к PREVIEW_PICTURE в Bitrix.
Bitrix: почему preview не означает сохранённую картинку
В форме уже виден новый preview, но карточка после сохранения показывает старое изображение. Разделяем браузерный файл, запись в b_file и ссылку PREVIEW_PICTURE, чтобы найти разрыв и проверить результат.
Windows: как проверить, что «работает на моей машине» связано с окружением
Одинаковая команда может запускать разные файлы и получать разный вывод. Разбираем порядок проверки PATH, приоритета PowerShell, версии инструмента и кодировки без переустановки среды.
Windows: почему команда запускает не тот бинарник
Разбираем разрешение команд в PowerShell: приоритет alias, функций, cmdlet и приложений, поиск через PATH и PATHEXT, а также отдельную диагностику кодировки консоли и файлов.
Windows-окружение без гадания: как найти настоящий бинарник и сравнить запуск
Если одна Windows-машина запускает проект, а другая не находит команду или выбирает другую версию, сначала снимите процессное окружение. Разбираем PATH, профиль PowerShell, кодовую страницу и обратимую проверку без глобальной переустановки.
PHP cURL: как заменить устаревший CA bundle без отключения TLS-проверки
Старый PHP-клиент перестал доверять HTTPS-партнёру. Разбираем, какой CA bundle использует процесс, как проверить новый файл и переключить его с понятным откатом.
TLS в PHP cURL: как отличить CA bundle, hostname и SNI
PHP cURL может отклонить HTTPS-соединение даже тогда, когда сайт открывается в браузере. Разбираем цепочку сертификатов, имя хоста и SNI, а затем проверяем каждую причину отдельно.
PHP cURL: как исправить ошибку проверки TLS без отключения защиты
PHP cURL возвращает ошибку сертификата, хотя адрес открывается в браузере. Разбираем CA bundle, цепочку, SNI и hostname, а затем проверяем исправление тем же запросом.
PHP cURL: как найти стадию HTTP-таймаута и не повторить операцию дважды
Ошибка cURL 28 не говорит, где остановился запрос. Разбираем временную шкалу PHP cURL, отличаем сбой соединения от позднего первого байта и выбираем безопасное действие для чтения и операции, которая меняет данные.
PHP cURL: как понять, на какой стадии сработал таймаут
Ошибка cURL 28 сообщает о сработавшем ограничении, но не называет стадию запроса. Разбираем connect timeout, общий предел, медленный ответ и условия безопасного повтора.
PHP cURL: как ограничить время HTTP-запроса и не повторить операцию дважды
Таймаут HTTP-запроса состоит из нескольких границ. Разбираем connect timeout, общий бюджет, медленное тело ответа, диагностику и безопасное правило повтора в PHP cURL.
Webpack 4: почему новый entry раздувает bundle и как это доказать
После добавления entry сборка может вырасти по ожидаемой причине, из-за дублирования модулей или из-за ошибочного HTML. Разбираем stats.json, граф chunks и сетевой след страницы, затем выбираем точечную настройку.
Webpack 4: почему общий модуль попадает в два entry bundle
После добавления второго entry общий модуль может оказаться в обоих стартовых bundle. Разбираем граф зависимостей, смысл массива entry, splitChunks и проверку результата через stats и HTML.
Webpack 4: две страницы, общие chunks и проверяемая сборка
Две HTML-страницы могут тянуть один и тот же код дважды. Разбираем границу entry, настройку splitChunks и проверку итоговых ассетов в Webpack 4.
jQuery-форма без двойной отправки: состояние, jqXHR и честный отказ
Как защитить legacy Ajax-форму от повторного submit, не потерять данные запроса и не оставить кнопку заблокированной после timeout или ошибки сети.
jQuery. Почему кнопка перестаёт работать после .html()
После обновления каталога через Ajax карточки видны, но кнопка больше не реагирует. Разбираем, почему .html() удаляет обработчики дочерних узлов, как выбрать живой контейнер для делегирования и как проверить решение без дублирования кликов.
Legacy jQuery: как повторно инициализировать виджет без двойной отправки
Повторный mount jQuery-виджета накапливает обработчики, если код только вызывает .on(). Разбираем namespace, делегирование, границу корня и проверку: три инициализации должны дать один вызов.
Bitrix: как доказать конфликт символьных кодов и исправить адрес товара
Карточка товара открывает соседний элемент или даёт нестабильный результат? Разбираем путь от URL до фильтра CIBlockElement, считаем совпадения и меняем CODE только после проверки маршрута.
Bitrix ЧПУ: как путь становится ELEMENT_CODE и где ломается карточка
Карточка отвечает 404, хотя CODE в инфоблоке выглядит правильно. Разбираем путь от запроса до фильтра элемента и проверяем каждый слой коротким PHP-примером.
Bitrix CODE без дублей: как проверить символьный код до публикации
Транслитерация создаёт только кандидата. Разбираем, как проверить CODE в нужном инфоблоке, сохранить его вместе с элементом и найти ошибку, если URL открывает не ту карточку.
PHP. Как отдать приватный файл владельцу и не сделать uploads публичной папкой
Разбираем контролируемую выдачу документа: путь хранится вне веб-корня, доступ проверяется по записи в базе, а браузер получает содержимое только после авторизации.
Безопасная загрузка в PHP: почему расширение и MIME из запроса не доказывают тип файла
Разделяем сведения клиента, результат приёма PHP и проверку временного файла. На примере JPEG и PNG показываем порядок проверок, отрицательный путь и границу между допуском файла и его хранением.
PHP: безопасная загрузка аватара без доверия к имени файла
Как принять JPEG или PNG от пользователя, проверить временный файл на сервере, сохранить его под своим ключом и не открыть приложению лишний путь к выполнению кода.
PHP: почему null не доказывает ошибку JSON
Пустой массив, null и false могут быть корректным JSON, а ошибка декодирования тоже часто возвращает null. Разбираем ответ API по слоям: транспорт, синтаксис и контракт данных.
PHP и cURL: как доказать, что интеграция действительно сработала
Строка от curl_exec() доказывает только получение ответа. Разбираем транспорт, HTTP-статус и контракт тела, чтобы не принять 403 или неверный JSON за успешную операцию.
PHP-интеграция вернула 500: как сохранить причину сбоя
Разбираем, почему одного set_error_handler недостаточно для диагностики PHP-интеграции, как связать ошибку с операцией и где проходит граница shutdown-обработчика.
Почему элемент Bitrix есть в админке, но пропадает из каталога
ID после CIBlockElement::Add подтверждает запись, но не публичную видимость. Разбираем фильтры инфоблока, товарный слой, права и кеш по проверяемой цепочке.
CIBlockElement::Add в Bitrix: где проходит граница между событием и сервисом
Разбираем путь создания элемента инфоблока: обработчики до и после Add, общий инвариант, диагностика LAST_ERROR и проверка результата без скрытой магии init.php.
CIBlockElement::Add: как не потерять ошибку и проверить результат
ID элемента ещё не означает готовую карточку. Разбираем контракт CIBlockElement::Add, ошибки LAST_ERROR, свойства, события и контрольную выборку, которая отделяет сохранённую запись от рабочего результата.
Tilix и D: как проверить раскладку, зависимости и границы
Tilix объединяет несколько терминальных сессий в одном окне. Разбираем тайлинг, GTK, D, сборку и проверки, которые отделяют удобную раскладку от надёжного рабочего сценария.
Bitrix API: как сгенерировать символьный код элемента и не сломать URL
CUtil::translit создаёт только кандидата для CODE. Разбираем нормализацию, проверку уникальности, ограничение длины, обновление элемента и безопасное поведение при смене публичного адреса.
Bitrix API: как создать торговое предложение, связать его с товаром и проверить каталог
ID элемента ещё не делает SKU готовым к продаже. Разбираем связь предложения с товаром, параметры каталога, цену, идемпотентный импорт и проверку через тот же путь чтения, которым пользуется витрина.
Firefox и долгий HTTP-запрос: как увеличить timeout, не скрыв неисправность
Если Firefox обрывает долгий запрос, сначала определите этап задержки. Затем временно измените response timeout в отдельном профиле и проверьте, что запрос действительно продолжает работу.
PHP: как исправить unable to get local issuer certificate без отключения TLS
Ошибка cURL 60 возникает, когда PHP не может построить доверенную цепочку сертификата. Разбираем CA bundle, SNI, различия CLI и FPM и проверяем исправление с включённой TLS-валидацией.
Сборщик мусора D под нагрузкой: от паузы к устройству пулов
Пауза в D-приложении не доказывает, что виноват только GC. Разбираем пулы малых и больших объектов, консервативную маркировку и порядок проверки перед изменением режима сборки.
Аналог preg_match_all в D: группы, порядок и смещения
Как перенести поиск всех совпадений из PHP в D, сохранить смысл групп и не принять байтовый offset за номер символа.
CTFE в D: как перенести вычисление в сборку и не сломать её
CTFE выполняет функцию там, где компилятору нужно значение на этапе сборки. Разбираем границу между compile-time и runtime, историческую проблему NewCTFE и проверку стоимости такого переноса.
Vibe.d: как не заблокировать event loop в сервере на D
Vibe.d делает асинхронный сервер похожим на последовательную программу, но fiber не создаёт второй поток. Разбираем границу между ожиданием I/O, синхронным CPU-кодом и worker-потоком, а затем проверяем её коротким воспроизводимым сценарием.
Браузер сам открывает сайты: как найти источник запуска в Windows
Браузер запускается сам через одинаковые промежутки времени, а антивирус ничего не находит. Разбираем, как отличить подозрительное задание от обычного, проверить его действие и безопасно подтвердить результат.
DMD под Windows x64: как проверить архитектуру сборки и зависимости
Сборка D-программы с флагом -m64 не заканчивается на успешном сообщении компилятора. Разберём, как проверить DMD, linker, PE-заголовок и DLL, чтобы не искать ошибку в коде, когда проблема находится в toolchain.