Как проверить postmortem, подготовленный LLM. Разбираем инцидент Cloudflare
«Все сервисы восстановили в 14:30» выглядит как обычная строка хронологии. Но для инцидента Cloudflare, который мы разберём ниже, она неверна: к этому времени в значительной степени восстановился основной трафик, а полное восстановление наступило позже.Такое сокращение меняет оценку последствий сбоя. Команда рискует пропустить часть проблем и меры, которые помогли бы их устранить.Если вы поручаете большой языковой модели, LLM, подготовить postmortem, письменный разбор причин и последствий сбоя, результату нужна содержательная проверка. Разберём её на материале
Промпт‑инжиниринг для моделей надежности отказоустойчивого кластера
Ранее в «Базовые модели надежности отказоустойчивого кластера» были показаны теоретические подходы к построению моделей (непрерывная цепь Маркова, CTMC, Continuous‑Time Markov Chain) отказоустойчивого кластера (fault‑tolerant cluster).
Бэкап, из которого ни разу не восстанавливались — это не бэкап
Привет, Хабр! У резервного копирования есть свойство, которое отличает его от почти всего остального в инфраструктуре. Проверить, работает ли оно, можно ровно одним способом — восстановиться. Всё остальное проверяет что‑то другое.Ситуация тем неприятнее, что узнаёте вы об этом в единственный день, когда копия понадобилась. Поэтому в статье рассмотрим пять мест, где схема резервного копирования разваливается. Ноль в конце формулыНачну с главного, потому что остальные пять — его частные случаи.Правило 3-2-1 знают все:
Топ-5 проблем, с которыми я столкнулся при разработке AI-агентов
Когда я начал делать агентов под разные задачи внутри компании, я довольно быстро понял что задача не сводится просто к хорошему промпту.Промпт важен, но он закрывает только верхний слой, а дальше начинается обычная инженерная работа - контекст, память, доступы, инструменты, состояние, git, фоновые задачи и т.д. и т.п. И если это не проектировать отдельно, агент может нормально справиться с короткой задачей, но начать сыпаться на длинной работе.
Под с GPU не лечится рестартом: устраиваем отказ устройства в кубере и чиним без вечного Pending
В 2024 году была опубликована интересная статья
От «пяти девяток» до антихрупкости. Как менялось представление о надежности ИТ-инфраструктуры за 25 лет
Надежная ИТ-инфраструктура как здоровье – пока она есть, ее никто не замечает. Но за четверть века подходы к реализации ее надежности сильно поменялись: сначала компании пытались не допустить сбой вообще, потом научились быстро восстанавливаться после него, а теперь — проектируют системы так, чтобы они продолжали работать и становились сильнее даже в условиях хаоса.
Модель не виновата: разбираем 3 громких ИИ-инцидента, которые случились из-за отсутствия архитектуры
Когда ИИ-агент ошибается молча: 6 отказов, которые не видно по ответу
ИИ-агент — не чат-бот. Чат-бот генерирует текст. Агент совершает действия: читает документ, решает, какие инструменты вызвать, выполняет многошаговый рабочий процесс и выдает результат, на основании которого без дополнительной проверки действуют системы-потребители — а иногда и люди.Когда агент составляет ответ, цена ошибки — неудачный абзац. Когда он одобряет кредит, подает регуляторную отчетность или запускает эскалацию, ошибка может обернуться операционными, финансовыми или репутационными потерями.
DDoS: от алерта до выбора модели: диагностика DDoS и Always-On vs On-Demand
Когда на графиках мониторинга появляется аномальный всплеск трафика, ваш первый порыв — сразу врубить фильтры и блокировать всё подозрительное, но на практике именно подобное чаще всего приводит к ошибкам.На самом деле DDoS-защита начинается не с выбора сервиса и не с настройки правил — она начинается с диагностики. В этой статье мы разберём полный цикл: от момента появления алерта до выбора между Always-On и On-Demand моделями защиты.Часть 1. Диагностика и реагированиеА точно ли это DDoS?
Что происходит с LLM‑пайплайном, если провайдер падает посреди выполнения
В 2025 году каждый крупный провайдер LLM пережил минимум один значимый сбой. Большинство решений этой проблемы — gateway‑слой снаружи приложения: LiteLLM, Bifrost, Kong AI Gateway. Они перехватывают упавший HTTP‑запрос и повторяют его на другом провайдере.Это работает для одного вызова, но не работает для многошагового пайплайна — gateway не знает, что упавший запрос был вторым шагом из трёх. Он видит запрос, которому нужен retry, а не позицию в конечном автомате.В этой статье — как реализовать fallback провайдера как явный переход FSM на реальном стеке llm‑nano‑vm 0.8.6
