Культура Надёжности

10 open-source сканеров безопасности агентских навыков Хочу поделиться ссылкой на статью с таким заголовком и еще парой ссылок по теме: - В январском исследование SkillScan говорится, что среди 31 132 общедоступных навыков agent skills удалось выявило 26,1% потенциально опасных, и 5,2% заведомо опасных навыка. - В конце июля организовался Open Secure AI Alliance (см. пресс-релиз в блоге Nvidia) В общем, сканируйте ваши, а тем более чужие навыки. Мало ли что

Сообщество инженеров сопровождения Сбера продолжает агентизировать города 📆13 августа Сбер собирает OPS, DevOps и SRE-инженеров Самары в необычном формате и только офлайн. 🏦Сбер курсирует по Волге на двух теплоходах, где в формате барных стендапов и дискуссий инженеры обсудят, что умеют агенты в OPS, а что пока нет, как в Сбере строят надёжность, как реагируют на инциденты, куда ведёт агентизация и что с этим делать. 13 августа, 18:30 Самара, Теплоходы "Вояж" и "Спутник" ➡️Регистрация тут Количество очных мест ограничено

В психологии есть принцип принятия решений - Pre-Mortem Когда вы собираетесь что-то сделать — запустить проект, нанять сотрудника, подписать контракт, — вместо вопроса «что может пойти не так?» скажите себе: «прошло полгода, все провалилось, что случилось?». Этот прием анализа решений придумал психолог Гэри Кляйн. Он заметил: если описать провал как уже свершившийся факт, человек оценивает свои планы объективнее.   В ИТ мы чаще всего пользуемся другим принципом - Post-Mortem. Для чего он нужен, кажется, все понятно, а отказаться от него мы сможем только когда у нас не будет инцидентов… т.е. примерно никогда.   А что если перенять и переиспользовать Pre-Mortem для смещения влево оценки надежности при новых внедрениях… Берлинский разработчик Амин Боргеи создал на основе этой техники готовый скилл Premortem для Claude. Он собирает контекст из чатов и файлов, реконструирует сценарии провала, поручает сгенерированным «следователям» проанализировать каждый из них и выдает чеклист на 3–5 пунктов — что надо было проверить до запуска ссылка @Simple_Reliability

- Знаете, что такое Harness? - Нет. - Дословный перевод – сбруя. На самом деле это и есть сбруя, только не для лошади, а для ИИ-агентов. Так понятнее? - Да… но… что такое сбруя?   Harness состоит из двух компонентов: 1. Платформа – базовый инструмент для агентной разработки. Примеры: Claude Code, OpenAI Codex, OpenCode, Cursor... Он дает технические возможности для работы с кодом; 2. Правила и настройки – то, что делает платформу «умной» именно для компании: стандарты написания кода; архитектурные ограничения; автоматические проверки (требований надежности); механизмы исправления ошибок прямо в процессе генерации. Основной принцип в том, что инфраструктура выстраивает «рамки» для ИИ‑агента: - Перед работой система загружает в модель все нужные правила и контекст проекта - В процессе специальные механизмы сразу блокируют ошибки и заставляют ИИ исправлять их - После генерации код проходит автоматическую проверку: тесты, сборку, сканирование безопасности. Пока проверка не пройдена, код не попадает в проект Без такой системы контроля: - в коде накапливается больше ошибок, чем при ручной разработке; - разработчики тратят на проверку ИИ‑кода больше времени, чем на написание его с нуля; - доверие к ИИ падает, и команды возвращаются к ручному ревью: теряется весь выигрыш в скорости.   Оригинал: For Agentic SDLC, the AI Coding Harness Matters More Than the Coding Model (Gartner, March 2026) - К 2028 году компании с грамотно настроенным harness будут иметь на 60% меньше дефектов после запуска продукта - Правильная инфраструктура повышает успешность генерации кода с 53,8% до 81,8% - Разница между топовыми моделями ИИ при этом невелика - всего 1–3%. @Simple_Reliability

От DevOps к EvalOps или как мы трансформируем функцию OPS/SRE в связи с внедрением GenAI 🤖 При массовом внедрении GenAI в ИТ-ландшафт, крупные организации сталкиваются с новыми вызовами: – GenAI-системы недетерминированы по своей природе. Классические метрики (uptime, latency) не отражают их реальное качество и надежность. – Появляются новые классы инцидентов: «галлюцинации», дрейф качества, промпт-инжекты требуют новых подходов к мониторингу и реагированию. В докладе Вячеслав Кудряшов, исполнительный директор, МСС, СБЕР, расскажет о том, как меняются функции сопровождения, что такое EvalOPS. Рассмотрим конкретные примеры, как управлять инфраструктурой, в которой большую часть бизнес-процессов обслуживают ИИ-агенты, и какие компетенции нужно растить уже сейчас 🧠 Если это для вас, ждём вас на ДевФесте 🖱

Секция DevOps & SRE — про изменения, которые происходят прямо сейчас в индустрии. Делимся одним из докладов ⤵️ Вячеслав Кудряшов, «От DevOps к EvalOps (или как мы трансформируем функцию OPS/SRE в связи с внедрением GenAI)» Как меняется роль OPS и SRE с приходом генеративного ИИ? Что такое EvalOps и зачем он нужен? В докладе разберём, как трансформируются функции сопровождения, как управлять инфраструктурой, где значительную часть процессов уже выполняют ИИ-агенты, и какие компетенции важно развивать уже сейчас. Если хотите понять, куда движется DevOps и какие навыки будут востребованы завтра — обязательно загляните ☺️

10-11 апреля можем встретиться на XV IT-конференции «Стачка» в Ульяновске. Обсудить проблемы надёжности, связанные с внедрением ИИ и все остальное. Здесь соберутся более 2000 участников (и онлайн-зрителей): разработчики, специалисты по контенту и коммуникациям, HR, а также руководители и собственники IT-компаний. В течение двух дней – мощный IT-буст: - 200+ докладов от лидеров индустрии из ВКонтакте, Авито, Яндекса, Сбера, Wildberries & Russ, Ozon, Газпром ИД, Альфа-Банка и т.д. - 30+ секций по четырём направлениям: Разработка, Управление, Дизайн и Контент, Digital-маркетинг. - мастермайнды, панельные дискуссии, мастер-классы, экспертные зоны, нетворкинг-события, афтепати в завершении первого дня. Есть промокод и бесплатный билет, пишите @Simple_Reliability

Надежность — это не продукт SRE, или почему мы всё понимали не так? Привет, %username%! Недавно мы обсуждали, что является главным продуктом SRE. Кажется логичным сказать, что это надежность или внутренние инструменты для разработчиков. Но если опираться на свежее исследование, базирующееся на опыте Google и отчетах DORA, открывается совсем другая картина. На самом деле, надежность — это не "продукт", который SRE-команда может произвести в вакууме и отдать бизнесу. Это совместная ответственность всей организации. А вот SRE выступает как архитектор и катализатор целой экосистемы обеспечения надежности. Давай разберем, из чего состоит эта экосистема: - Инженерные практики: SLI/SLO, Error Budgets и автоматизация. Важно понимать, что 100% аптайма — это почти всегда неправильная цель. Требуемый уровень надежности — это продуктовый вопрос, а не технический. - Культура и процессы: Blameless postmortems и устранение "стен" между командами. SRE не может единолично "внедрить" правильную культуру, но выступает ее драйвером. Исследования DORA подтверждают: культура доверия без поиска виноватых напрямую повышает эффективность всего бизнеса. - Инструменты надежности: Системы мониторинга, алертинга и автоматизации реакций на инциденты. И тут кроется важное отличие от смежных ролей: создание удобной внутренней платформы разработки (IDP) — это задача Platform Engineering. SRE же фокусируется именно на инструментах стабильности, а упрощение жизни разработчиков — это скорее приятный побочный эффект. Если SRE начинает восприниматься как единственный владелец надежности, это ломает концепцию shared responsibility и приводит к антипаттерну "перебрасывания ответственности через стену". Разработчики должны сами владеть своим сервисом и отвечать за его доступность, а SRE лишь помогает им достигать нужных показателей. Краткие выводы: - Надежность — это фича самого продукта, а не изолированный результат работы SRE-команды. - SRE является архитектором экосистемы надежности, но отвечает за стабильность весь бизнес сообща. - Фокус SRE — инструменты стабильности (Reliability Tooling), тогда как удобство разработчиков (Developer Experience) — это профильный домен Platform Engineering. Делись опытом в комментариях! Как у тебя в компании разделена ответственность за надежность между SRE, разработчиками и продуктологами? Сталкивался ли с ситуацией, когда стабильность полностью перевешивали на SRE? И где, по-твоему, проходит грань между SRE и Platform Engineering в реальной работе? #SRE #DevOps #Observability #incidents #ErrorBudget #Postmortem #OnCall #SiteReliabilityEngineering #Monitoring

Работает быстро, но не всегда туда. О чём мы? Об AI 😀 В новом выпуске размышляем на самые спорные темы и выясняем: ➡️ какие рутинные задачи в SRE ему уже можно отдать; ➡️ в каких случаях AI — коллега, а в каких — инструмент; ➡️ почему эта тема стала так актуальна для SRE именно сейчас; ➡️ где мы в Авито уже внедрили AI, а где соблюдаем осторожность. А пока вы не успели перейти по ссылке на выпуск, попробуйте угадать, фейки следующие новости или нет: 1️⃣— DeepSeek обогнала OpenAI по эффективности обучения, тренируя модели за миллионы вместо миллиардов 2️⃣— Model Drift уничтожил систему обнаружения мошенничества — никто не замечал две недели ❤️, если обе новости — правда 👀, если 1 новость — фейк 👾, если 2 новость — фейк 😱, если обе новости — фейки Правильные ответы ищите в выпуске! 📺 YouTube 🔵 VK 💻 Rutube 🛫 Любая удобная платформа #sre

Что если использовать LLM по его прямому назначению: попросить предугадать. Придумать, что может пойти не так, что может стать гипотетической причиной сбоя при внедрении. Получается не post-mortem, а pre-mortem анализ. Чем не идея для улучшения производительности службы сопровождения и повышения надёжности?   Pre-mortem — это гипотетическая противоположность посмертного анализа (postmortem). В медицине вскрытие позволяет медикам и родственникам узнать, что стало причиной смерти пациента. Выгоду получают все, кроме, разумеется, самого пациента. Pre-mortem в IT/Бизнесе проводится в начале проекта, чтобы его можно было улучшить, а не «вскрывать». В отличие от типичных сессий критики, где членов команды/AI-агентов спрашивают, что может пойти не так, Pre-mortem исходит из предположения, что «пациент» умер, и задает вопрос: что именно пошло не так? Задача команды/AI-агентов — придумать правдоподобные причины провала проекта/внедрения.   Типичный Pre-mortem начинается после того, как все готово к запуску. Команде/AI-агентам ставится задача «Проект провалился, вам необходимо сформулировать причины провала». Что хорошо, живые люди в такой ситуации смогут сформулировать «потенциальные» проблемы, которые они обычно не стали бы упоминать, опасаясь показаться «недипломатичными». AI-агенты смогут потратить еще n-ое количество токенов на очень важное дело=))   @Simple_Reliablity

В начале февраля вышло очередное исследование от Harvard Business Review: AI Doesn’t Reduce Work — It Intensifies It.   200+ интервьюеров опровергает гипотезу о том, что генеративный ИИ разгружает команды. Напротив, добровольное использование ИИ приводит к систематической интенсификации (попросту говоря,увеличению количества) труда. Внедрение ИИ запускает самоподдерживающийся механизм, который, в конечном итоге, приводит к перегрузкам:  Ускорение задач → Рост ожиданий скорости → Зависимость от ИИ → Расширение функционала → Увеличение плотности работы → Когнитивное истощение Сотрудники, увлеченные возможностями ИИ, активно берут на себя дополнительные задачи, воспринимая это как профессиональный вызов. Однако, такая «добровольная» интенсификация труда имеет отложенные последствия, в том числе и для надёжности (канал же про надёжность=))): накапливается усталость, растет число ошибок, снижается качество решений. В итоге эксперты HBR делают такие выводы/советы: ИИ сам по себе не снижает нагрузку, а позволяет делать больше. Чтобы это не привело к выгоранию и снижению качества, организациям нужно активно формировать такие практики: - Проведение аудита ролей: проверить, какие новые задачи взяли на себя сотрудники благодаря ИИ, и оценить реальную нагрузку, в том числе неучтенную - Проведение тренингов по осознанному использованию ИИ: как ставить границы, как распределять задачи между собой и ИИ, как избегать мультизадачности - Введение намеренных пауз, регулярных остановок для сверки с целями: перед принятием ключевого решения нужно привести контраргумент и обосновать связь со стратегией компании - Четкая последовательность. Вместо мгновенной реакции — сбор и групповая обработка результатов работы ИИ в отведенные временные слоты. Это освобождает ресурсы для глубокой фокусировки - Человеческое общение!... Выделение времени для живого общения: в отличие от ответов ИИ, диалог с коллегами возвращает контекст и выявляет неочевидные нюансы. @Simple_Reliability

Экономика надёжности, в мировом масштабе CAST Intelligence Unit представил результаты масштабного исследования технического долга, основанного на анализе 10 миллиардов строк кода из 47 000 приложений в 17 странах, совокупно представляющих 51 % мирового ВВП. Исследование переводит понятие технического долга в измеримый показатель - человеко-дни Общий объем работ по исправлению накопившегося технического долга оценивается в 611 миллиардов человеко‑дней — консервативная оценка, учитывающая лишь выявленные дефекты. Если бы все 25 миллионов разработчиков мира сосредоточились исключительно на рефакторинге, работа была бы завершена лишь к 2034 году. Это подчеркивает масштаб зависимости бизнеса от систем, находящихся в состоянии критического износа. Страны, ранее лидировавшие в цифровизации, сегодня несут наибольшую нагрузку по техническому долгу. Топ‑3 страны по затратам на исправление 1 000 строк кода: - США — 2,07 дня; - Италия — 1,99 дня; - Франция — 1,98 дня; Развивающиеся экономики (например, Перу — 1,40 дня, Эквадор — 1,45 дня) демонстрируют существенно меньший уровень технического долга. Это создает потенциал для «технологического рывка»: внедряя ИИ и современные платформы на относительно чистом коде, компании из развивающихся стран могут обойти страны, вынужденные поддерживать устаревшие системы. Отчет опровергает предположение, что генеративные ИИ (LLM) могут автоматически устранять технический долг. Вероятностная природа нейросетей эффективна для создания нового кода, но малоприменима для исправления сложных, устаревших систем. При этом менее 10 % технического долга носит критический характер, однако именно он причиняет основной ущерб. Для снижения рисков предлагается (да по сути ничего нового и не предлагается, но перечислим): 1. Интегрировать метрики технического долга в KPI IT‑подразделений. 2. Сегментировать портфель систем, выделив критически важные с низкой устойчивостью. 3. Внедрить автоматический контроль состава ПО для управления рисками 4. Проводить глубокий анализ кода перед миграциями или внедрением ИИ‑решений. Источник: The State of Global Technical Debt 2025 (CAST Intelligence Unit, 2025) @Simple_Reliability

SLA, SLO, SLI — основа договоров о надежности (я тоже так часто говорю). Но их ценность нулевая, если метрики выбраны бездумно. Если посмотреть вокруг, то, в обычной жизни (не в ИТ) также полно примеров их бездумного использования … Например, в парке, рядом с домом очень хорошо чистят дорожки от снега, действительно чисто, но есть одно НО… если чисто, то снегоуборочная техника все равно ездит по маршруту «в холостую», потому что в ней стоят gps трекеры и простоев быть не должно… (вот такой SLI - отсутствие простоев). Казалось бы SLА - выполнены, мэрия довольна, SLO тоже - чистят оперативно, даже через чур… а вот индикатор (SLI) не верный… в итоге дополнительные расходы… а могли бы чистить в другом месте, там где это действительно нужно. Развивайте насмотренность. В других бизнесах могут найтись очень интересные решения и приемы для вашего… @Simple_Reliability

В одном из сценариев будущего, самый большой риск связанный с ИТ - не кибермошенничество, а дискриминация алгоритмов (в большинстве случаев конечно же недетерминированных=)).   Получается, что для минимизации такого рода рисков нам необходим независимый механизм валидации любых решений принятых ИИ (еще одна модель, которая перепроверяет работу первой модели).   На языке бизнеса это означает, что надо заплатить х2 только для минимизации одного риска.   Других внятных идей как минимизировать этот риск пока нет.   @Simple_Reliability

Метафор про принципы надёжности в обычной жизни очень много. Если присмотреться. Накануне оставил машину с «жёлтой лампочкой» - стрелка топлива упёрлась в ноль. «Система мониторинга», явно показывала: «Заправь меня!». Но я подумал: «Да ладно. Заправка рядом с домом, сделаю это утром». Ночью ударил мороз. Утром включил автозапуск, чтобы прогреть салон. Система отработала штатно: грела салон, тратя последние остатки топлива. Итог понятен: утром пришлось идти на заправку, покупать канистру и бензин, нервничать…опаздывать… А теперь проводим параллель (для интересующихся и/или заказчиков 😉) 1. Жёлтая лампочка/стрелка на 0 — это WARNING в вашем Grafana/Zabbix: «Свободной памяти < 10%», «Диск заполнен на 85%». 2. Мысль «Заправлюсь утром» — это «Пофиксим в понедельник», «Это же не Critical, подождёт». 3. Ночной мороз и автозапуск — это внезапный всплеск трафика, фоновое задание, обновление — любая рядовая нагрузка, которая добивает иссякающий ресурс. 4. Незаведённая утром машина — это полноценный критический инцидент в рабочее время. Простои, паника, звонки руководству, авральное разбирательство. 5. Поход за канистрой — это hot-fix и инцидент менеджмент, хотя всё можно было решить вечером планово и за 5 минут. Мораль простая 😉 ⚠️ Сигналы мониторинга существуют не для галочки. Они — прямой аналог датчиков в автомобиле. Игнорируя «жёлтые» алерты, вы гарантированно получаете «красный» инцидент в самый неподходящий момент. Лень, надежда «на авось» и «и так сойдёт» в эксплуатации систем стоят дорого. Всегда. @Simple_Reliability

У многих, зачастую, создается ощущение, что их имеющиеся знания и опыт очевидны всем. На самом деле, это не так. Люди не связанные с ИТ, в большинстве случаев, имеют очень поверхностные знания по тому как устроена надежности в ИТ. Если вам нужно их быстро погрузить в тему надежности, а главное, дать понять, что они играют не последнюю роль в ее обеспечении, можете для начала дать им почитать эту памятку. Памятка для руководителя: как управлять надёжностью IT-систем Главный принцип: надёжность — ваша общая с IT ответственность, а не только их проблема. 1. Заложите надёжность в разработку — 40–60% инцидентов случаются после выпуска новой фичи. — Внедряйте CI/CD, постепенный rollout и адекватные тестовые среды. — Выделяйте 20–30% бэклога на техдолг и задачи надёжности — это страховка от будущих аварий. 2. Переходите на end-to-end команды — Команда, которая разрабатывает и сопровождает сервис, выводит продукты на рынок быстрее и создаёт более устойчивые решения. 3. Требуйте настоящей наблюдаемости (Observability) — Панель мониторинга должна за 30 сек. давать ответ: что сломалось, на кого влияет, какая бизнес-метрика падает. — Фиксируйте целевые показатели доступности (SLO) ещё на этапе проектирования сервиса. 4. Управляйте технологическими рисками: — Риск = Вероятность сбоя × Стоимость минуты простоя. — Для критичных систем считайте классы критичности. Пример: «4 девятки» (99,99%) = десятки минут простоя в год. — Регулярно проводите учения по аварийному восстановлению (DRP). — Выстройте процесс управления мощностями 5. Ваша роль — расставлять приоритеты и давать команде время на улучшение фундамента. — Защищайте команду от перегрузки. В спринте держите баланс: фичи, задачи на надёжность (20–30%), буфер на срочные правки (15–20%). 6. Задавайте правильные вопросы при выборе решений 1. Оценили ли риски? 2. Сколько стоит минута простоя? 3. Какое время восстановления (RTO) и потери данных (RPO)? 4. Что будет, если эта новая технология (например, AI-агент) перестанет работать? 5. Какие метрики выводятся на панель дежурным? 6. Когда пройдут первые аварийные учения? 7. Кто в команде отвечает за надёжность? Итог: Управляйте надёжностью проактивно, говорите с IT на одном языке. Это не технические детали, а управленческие решения, которые напрямую влияют на лояльность клиентов и доход. @Simple_Reliability

В ночь на 20 декабря масштабное отключение электроэнергии в Сан-Франциско парализовало весь флот роботакси Waymo. Более 130 000 потребителей остались без света, а беспилотники, потеряв связь с центром управления, просто застыли на дорогах, создав гигантские пробки. Удалённые операторы не смогли помочь — в офисах тоже не было электричества. Блэкаут начался в субботу днём из-за пожара на подстанции Pacific Gas & Electric. Восстанавливали эту феерию полтора дня! Уроки для адептов «надежности»: 1. Самые продвинутые автономные системы в очередной раз оказались уязвимы к сбою в коммунальных сетях (никогда такого не было и вот опять). Всегда помните и учитывайте риски нижележащих слоёв. 2. Waymo заявила, что её ПО рассматривает не работающие светофоры как нерегулируемые перекрёстки, но в условиях блэкаута это не сработало. Нужны алгоритмы и сценарии,позволяющие действовать в полностью деградировавшей среде (хотя бы съехать на обочину и не мешать) 3. Ну и самое простое и очевидное: центр управления и связь с автомобилями должны иметь автономное питание и альтернативные каналы связи. (Было?... не было…)   @Simple_Reliability

Ребята из DevCrowd опросили 273 инженера, которые занимаются вопросами надёжности в своих компаниях и составили портрет инженера по надёжности SRE - молодая роль, даже для опытных специалистов. Почти 70% тех, кто перешли в SRE сделали это за последние 1–5 лет. Каждый пятый респондент работает в финтехе Размер SRE-команды растёт вместе с размером компании 1 - 2 специалиста по надёжности на 150 инженеров. Каждому второму сложно отстаивать свои инженерные решения В основном из-за проблем с коммуникациями, нагрузки и отсутствия базовых процессов Две трети респондентов пользуются мессенджерами для алертинга В половине компаний за инциденты отвечает дежурный инженер, а не отдельная роль Только 50% команд формализовали процесс реагирования на инциденты При этом у 59% команд постмортемы стали стандартной практикой Профессия эволюционирует: фокус смещается в сторону стратегической ответственности за устойчивость. @Simple_Reliability

Крупнейший сбой Cloudflare с 2019 года: разбор корневой причины и уроки для SRE Привет, %username%! Думаю ты слышал, что 18 ноября 2025 года в 11:20 UTC Cloudflare полностью потеряла способность маршрутизировать трафик на протяжении 6 часов​. Сбой вызвал каскадные ошибки 5xx по всей сети, затронув CDN, WAF, Zero Trust и внутренние системы. По масштабу это самый серьезный инцидент за последние 6 лет. Корневая причина: неожиданное поведение ClickHouse Инцидент начался не с DDoS-атаки или сбоя hardware, а с изменения разрешений в ClickHouse: - В 11:05 команда внесла изменение, разрешив пользователям видеть метаданные таблиц в базе данных r0 - Это изменение привело к тому, что распределенные запросы ClickHouse стали возвращать дублирующиеся строки с метаданными - Файл конфигурации системы управления ботами, генерируемый каждые 5 минут, внезапно удвоился в размере (превысил лимит в 200 функций ML) - Некорректный файл был автоматически распространен на все прокси-сервера сети Техническая цепочка сбоя - 11:05 — Изменение доступа к ClickHouse. - 11:20 — Некорректный файл конфигурации ботов достиг прокси-серверов. - 11:28 — FL2 (новая версия прокси) начала возвращать HTTP 5xx. - 11:30-13:05 — Инженеры искали проблему, изначально подозревая DDoS и Workers KV. - 13:05-13:37 — Временный откат Workers KV и Access, частичное улучшение. - 14:24 — Прекращена генерация новых файлов конфигурации. - 14:30 — Ручная установка правильного файла, перезапуск FL2. - 17:06 — Полное восстановление всех систем. Затронутые сервисы - Основной трафик: HTTP 5xx ошибки на 80% запросов. - Turnstile: Полная недоступность (аутентификация CAPTCHA). - Workers KV: Повышенная задержка и ошибки. - Cloudflare Access: Невозможность входа в панель управления. - Информационная панель: Прерывистая доступность. - Email: Задержки в обработке и снижение точности антиспам-фильтрации. Уроки для инфраструктуры любого масштаба - Защита от "хороших" изменений: Даже полезные изменения в доступности могут иметь непредсказуемые эффекты. - Observability must be deeper: Метрики должны показывать не только "что", но и "почему" на каждом этапе конвейера. - Configuration as a threat: Файлы конфигурации - это потенциальный вектор катастрофического сбоя, требующий защиты на уровне кода. - Graceful degradation: Система должна работать с устаревшей, но валидной конфигурацией, а не падать от некорректной. Какая из найденных причин сбоя Cloudflare кажется вам самой неожиданной или недооценённой в крупных инфраструктурах? Что у тебя делается для защиты от подобных каскадных отказов конфигурации в ваших системах? Какие подходы к изоляции и обработке ошибок конфигураций наиболее эффективны по твоему мнению? Какую роль должны играть метрики и observability в быстром выявлении root cause подобных инцидентов? Были ли у тебя в практике инциденты, вызванные изменениями доступа или разрешений в хранимых данных? Какие практики проверки и roll-back конфигурации уже применяются у вас, а какие собираетесь внедрить после анализа кейса Cloudflare? Как реализуется graceful degradation у вас в платформе, и сталкивался ли ты с нарушением этого принципа? #Cloudflare #SRE #DevOps #Outage #IncidentManagement #Observability #HighAvailability #FaultTolerance #RootCauseAnalysis #Postmortem #BestPractices #ConfigurationManagement #Microservices

Архитекторы ИИ — люди года по версии журнала Time Впервые с 1982 года, подобное признание получила технология, тогда героем обложки стал персональный компьютер. Time обосновал свой выбор тем, что в этом году ИИ стал полноценной частью жизни обычных людей и перестал быть игрушкой. По сути, это признание всех, кто стоит за созданием и развитием технологий искусственного интеллекта. P.S. Если хотите пообщаться с архитекторами ИТ СБЕРа (и не только) про ИИ и все остальное, приходите завтра на Arch.Conf @Simple_Reliability