52/48
Такое распределение у нас получилось по итогу дебатов «Заменит ли ИИ службу сопровождения»
С небольшим перевесом победил ответ: «нет, не заменят».
Вот что интересно, среди голосовавших большинство - администраторы АС, т.е. как раз те, кого заменит ИИ.
Всего год назад, подобный вопрос в адрес любого специалиста в ИТ вызвал бы искреннюю улыбку… из всех приемников страны звучало «у нас дефицит ИТшников»…
И вот, неожиданно быстро, наступила стадия «принятия»
@Simple_Reliability
Такое распределение у нас получилось по итогу дебатов «Заменит ли ИИ службу сопровождения»
С небольшим перевесом победил ответ: «нет, не заменят».
Вот что интересно, среди голосовавших большинство - администраторы АС, т.е. как раз те, кого заменит ИИ.
Всего год назад, подобный вопрос в адрес любого специалиста в ИТ вызвал бы искреннюю улыбку… из всех приемников страны звучало «у нас дефицит ИТшников»…
И вот, неожиданно быстро, наступила стадия «принятия»
@Simple_Reliability
😱2
Популяризация ИИ делает свое дело. Никто не хочет «отстать от поезда», все, так или иначе, начинают использовать ИИ для рабочих задач, а иначе окажешься не эффективным и тебя заменят эффективные…
Но вот вопрос: готовы ли организации к тому, что их сотрудники станут более «эффективными» за счет ИИ (неподконтрольного им ИИ)
Точно не все.
1. Судя по опросу Gartner, 2025, 49% сотрудников используют сторонние сервисы, которые
отправляют всю внутреннюю информацию в «неподконтрольные облака»
2. 32% сотрудников скрывают факт такого использования, чтобы избежать процессов внутренних согласований с ИБ, тем самым усугубляя ситуацию
3. 15% сотрудников вообще используют личные BYOD (bring your own device) для решения рабочих задач. Как контролировать использование таких устройств пока вообще не очень понятно…
Что с этим делать?
Видимо подстраиваться под реалии:
1. Создавать внутренние службы за контролем использования ИИ, должен же кто-то централизованно нести за все это ответственность…
2. В идеале, доводить внутренние ИИ решение до состояния, когда у сотрудников не будет даже мыслей пользоваться чем-то другим
3. Внедрять новые механизмы и методики, например:
- AI Usage Control для обнаружения и блокировки нежелательного ИИ.
- AI TRiSM (Trust, Risk, Security) решения для тотального контроля над всеми моделями ИИ в сети.
4. И, самое главное, обучайте сотрудников новым рискамреалиям
#Надёжность_ИИ
@Simple_Reliability
Но вот вопрос: готовы ли организации к тому, что их сотрудники станут более «эффективными» за счет ИИ (неподконтрольного им ИИ)
Точно не все.
1. Судя по опросу Gartner, 2025, 49% сотрудников используют сторонние сервисы, которые
отправляют всю внутреннюю информацию в «неподконтрольные облака»
2. 32% сотрудников скрывают факт такого использования, чтобы избежать процессов внутренних согласований с ИБ, тем самым усугубляя ситуацию
3. 15% сотрудников вообще используют личные BYOD (bring your own device) для решения рабочих задач. Как контролировать использование таких устройств пока вообще не очень понятно…
Что с этим делать?
Видимо подстраиваться под реалии:
1. Создавать внутренние службы за контролем использования ИИ, должен же кто-то централизованно нести за все это ответственность…
2. В идеале, доводить внутренние ИИ решение до состояния, когда у сотрудников не будет даже мыслей пользоваться чем-то другим
3. Внедрять новые механизмы и методики, например:
- AI Usage Control для обнаружения и блокировки нежелательного ИИ.
- AI TRiSM (Trust, Risk, Security) решения для тотального контроля над всеми моделями ИИ в сети.
4. И, самое главное, обучайте сотрудников новым рискам
#Надёжность_ИИ
@Simple_Reliability
👍5
Психология на службе надёжности…
В 1962 году французский исследователь Мишель Сифр проводил эксперимент по субъективной оценки времени, который случайно открыл механизм контроля над паникой.
Механизм, среди прочего, можно использовать для экономии времени при решении инцидентов.
Называется он «Вербальное заземление»
Тоже самое предлагается использовать и при решении критических инцидентов, необходимо лишь внедрить соответствующие практики:
1. Исполнители должны проговаривать все свои действия вслух
2. Координаторы и руководители изменить формат своих вопросов
(Вместо «Какой статус?» – «Что ты видишь прямо сейчас?»)
3. Заменить интерпретации на факты
(Вместо «Это катастрофа…» - «До хоста X не доходит трафик…»)
@romanestt, что скажешь, должно работать?
@Simple_Reliablity
В 1962 году французский исследователь Мишель Сифр проводил эксперимент по субъективной оценки времени, который случайно открыл механизм контроля над паникой.
Механизм, среди прочего, можно использовать для экономии времени при решении инцидентов.
Называется он «Вербальное заземление»
В пещере, на грани психологического срыва, Сифр случайно обнаружил механизм стабилизации. Он не медитировал и не применял дыхательные техники. Он начал говорить вслух простые утверждения:
"Я сижу."
"Я дышу."
"Моя рука двигается."
Эффект был немедленным. Паника отступила. Когнитивный контроль вернулся.
Тоже самое предлагается использовать и при решении критических инцидентов, необходимо лишь внедрить соответствующие практики:
1. Исполнители должны проговаривать все свои действия вслух
2. Координаторы и руководители изменить формат своих вопросов
(Вместо «Какой статус?» – «Что ты видишь прямо сейчас?»)
3. Заменить интерпретации на факты
(Вместо «Это катастрофа…» - «До хоста X не доходит трафик…»)
@romanestt, что скажешь, должно работать?
@Simple_Reliablity
👍7❤1
В сентябре 2022 года, Gartner опубликовал прогноз, согласно которому организации инвестирующие в DIS
к 2025 году увеличат удовлетворенность своих пользователей за счет снижения времени простоя своих сервисов на 80%.
2025 год подходит к концу. Gartner ничего не говорит о том сбылся их прогноз или нет… (нет такой задачи). Зато продолжает прогнозировать, что данный тренд продолжит развиваться и эволюционирует в ACIS
Сработает или нет, покажет время. Но концепция точно поможет обосновать «эволюцию» службы сопровождения/SRE/экспертов надежности в эпоху GenAI 😉
@Simple_Reliability
Digital Immune System (DIS) — это целостный подход к созданию программных систем, которые обладают врожденной устойчивостью и способностью к самовосстановлению. Объединяя практики наблюдаемости, автотестирования, инженерии хаоса и автоматического исправления сбоев, DIS минимизирует downtime и обеспечивает бесперебойный пользовательский опыт, проактивно нейтрализуя угрозы и оперативно восстанавливаясь после инцидентов, подобно биологическому иммунитету.
к 2025 году увеличат удовлетворенность своих пользователей за счет снижения времени простоя своих сервисов на 80%.
2025 год подходит к концу. Gartner ничего не говорит о том сбылся их прогноз или нет… (нет такой задачи). Зато продолжает прогнозировать, что данный тренд продолжит развиваться и эволюционирует в ACIS
Autonomous Cyber Immune System
- автономная, самообучающаяся система превентивной безопасности и надежности (эволюция DIS)
Сработает или нет, покажет время. Но концепция точно поможет обосновать «эволюцию» службы сопровождения/SRE/экспертов надежности в эпоху GenAI 😉
@Simple_Reliability
❤2👍1
This media is not supported in your browser
VIEW IN TELEGRAM
Похоже формируется новая традиция: конец ноября = IT Talks by SBER в Самаре.
Если будете в Самаре 20.11, приходите, обсудим насущное.
Мероприятие отличное.
@Simple_Reliability
Если будете в Самаре 20.11, приходите, обсудим насущное.
Мероприятие отличное.
@Simple_Reliability
🔥8❤2
Запоминаем новые слова: EvalOps (это то чем нам предстоит заниматься в ближайшем будущем)
Раньше мы (многие, к счастью, до сих пор) имели дело с детерминированным кодом: есть входные данные, есть код, который их обрабатывает по строгим правилам, есть предсказуемый выход.
Было все понятно: работа заключалась в обеспечении доступности, производительности и отказоустойчивости инфраструктуры и приложений.
Ключевой же особенностью AI-агентов и LLM является недетерминированность их поведения (нельзя полностью предсказать стандартными юнит-тестами результат их работы).
Новые особенности = новыепроблемы вызовы (или новая область внимания SRE/OPS инженеров)
Галлюцинации: Система выдает убедительно звучащую, но абсолютно ложную информацию
НеИндепотентность (мое любимое): Ответы модели могут деградировать со временем, при одинаковых вводных, без каких-либо изменений
Нестабильность контекста: Небольшие изменения в промпте могут кардинально менять результат работы AI-агента
…
Практики EvalOps (на них посмотрим в следующий раз), как раз направлены на решение этих проблем. Это своего рода SRE для AI.
#НадёжностьИИ #EvalOps
@Simple_Reliability
EvalOps = Еvaluation (оценка) + Operations - это философия и набор практик, которые расширяют принципы DevOps и SRE, добавляя непрерывную, автоматизированную оценку "интеллектуального" поведения AI-систем в производственной среде.
Раньше мы (многие, к счастью, до сих пор) имели дело с детерминированным кодом: есть входные данные, есть код, который их обрабатывает по строгим правилам, есть предсказуемый выход.
Было все понятно: работа заключалась в обеспечении доступности, производительности и отказоустойчивости инфраструктуры и приложений.
Ключевой же особенностью AI-агентов и LLM является недетерминированность их поведения (нельзя полностью предсказать стандартными юнит-тестами результат их работы).
Новые особенности = новые
Галлюцинации: Система выдает убедительно звучащую, но абсолютно ложную информацию
НеИндепотентность (мое любимое): Ответы модели могут деградировать со временем, при одинаковых вводных, без каких-либо изменений
Нестабильность контекста: Небольшие изменения в промпте могут кардинально менять результат работы AI-агента
…
Практики EvalOps (на них посмотрим в следующий раз), как раз направлены на решение этих проблем. Это своего рода SRE для AI.
#НадёжностьИИ #EvalOps
@Simple_Reliability
👍6
Новый термин узнали (EvalOps), а что конкретно делать?
Есть три ключевые области на которых стоит сосредоточиться:
1. Наблюдаемость (Observability) для AI
Привычных технологических метрик, логов и трейсов не достаточно.
Для «наблюдаемости» AI нужно в онлайне контролировать бизнес-метрики качества (factual_accuracy, hallucination_rate, toxicity_score, relevancy_score,…)
Логировать не только HTTP-запросы, но и промпты, ответы модели, цепочки размышлений (reasoning chains) агентов
«Трассировать» выполнение не только микросервисов, но и шаги AI-агентов
2. Автоматизированное тестирование и Canary-релизы для AI
Не нужно ждать пока пользователь наткнется на галлюцинация, нужно проактивно их искать… например с помощью
canary-релизов с автоматическими quality-gate’ами (небольшая часть трафика направляется на новую версию модели, автоматически насчитываются метрики качества и если они отклоняются от нормы, то трафик автоматом возвращается на работоспособную версию модели)
3. Пост-продакшен мониторинг и инцидент-менеджмент
Все то что описано в п.1 должно стать рабочими инструментами службы сопровождения, без использования этих инструментов расследование инцидентов станет слабо реализуемым
Кончено это не все, но основы кажется понятны и логичны.
#НадёжностьИИ #EvalOps
@Simple_Reliability
Есть три ключевые области на которых стоит сосредоточиться:
1. Наблюдаемость (Observability) для AI
Привычных технологических метрик, логов и трейсов не достаточно.
Для «наблюдаемости» AI нужно в онлайне контролировать бизнес-метрики качества (factual_accuracy, hallucination_rate, toxicity_score, relevancy_score,…)
Логировать не только HTTP-запросы, но и промпты, ответы модели, цепочки размышлений (reasoning chains) агентов
«Трассировать» выполнение не только микросервисов, но и шаги AI-агентов
2. Автоматизированное тестирование и Canary-релизы для AI
Не нужно ждать пока пользователь наткнется на галлюцинация, нужно проактивно их искать… например с помощью
canary-релизов с автоматическими quality-gate’ами (небольшая часть трафика направляется на новую версию модели, автоматически насчитываются метрики качества и если они отклоняются от нормы, то трафик автоматом возвращается на работоспособную версию модели)
3. Пост-продакшен мониторинг и инцидент-менеджмент
Все то что описано в п.1 должно стать рабочими инструментами службы сопровождения, без использования этих инструментов расследование инцидентов станет слабо реализуемым
Кончено это не все, но основы кажется понятны и логичны.
#НадёжностьИИ #EvalOps
@Simple_Reliability
❤2
LLM-as-a-judge популярный метод повышения качества AI-решений, так говорят, но есть вопросы…
Точнее результаты исследования Gartner, которые говорят о другом.
Вся суть на картинке: LLM принимает решение на основе знаний, а человек, помимо знаний, обладает знанием контекста и уникальным экспертным опытом.
Безусловно, часть контекста передается и знаний у LLM больше… но исследования говорят о том, что «Использование ИИ для проверки ИИ» - это миф, который работает для ограниченного числа задач создании контента, например, проверки орфографии и общеизвестных фактов.
Еще два мифа: «Для ИИ чем больше контента, тем лучше» и «Для ИИ нет необходимости структурировать контент» развинчиваются в этом же исследовании.
Оригинал: Misconceptions when using AI for knowledge management (Gartner, 27.10.2025)
@Simple_Reliability
Точнее результаты исследования Gartner, которые говорят о другом.
Вся суть на картинке: LLM принимает решение на основе знаний, а человек, помимо знаний, обладает знанием контекста и уникальным экспертным опытом.
Безусловно, часть контекста передается и знаний у LLM больше… но исследования говорят о том, что «Использование ИИ для проверки ИИ» - это миф, который работает для ограниченного числа задач создании контента, например, проверки орфографии и общеизвестных фактов.
Еще два мифа: «Для ИИ чем больше контента, тем лучше» и «Для ИИ нет необходимости структурировать контент» развинчиваются в этом же исследовании.
Оригинал: Misconceptions when using AI for knowledge management (Gartner, 27.10.2025)
@Simple_Reliability
🤔1
GigaChat определенно льстит нашему псу(обратите внимание на сгенерированное видео)
Шутки шутками, но цензор явно не дорабатывает в кейсах со щенками… или обучающая выборка состояла преимущественно из коней🙈
@Simple_Reliability
Шутки шутками, но цензор явно не дорабатывает в кейсах со щенками… или обучающая выборка состояла преимущественно из коней🙈
@Simple_Reliability
😁12🙈2🤣1
На примере дилеммы «кого сбить насмерть? Бабушку или ребенка» удобно иллюстрировать различие больших языковых моделей (LLM):
Западные LLM «сбивают» бабушку, мотивируя это тем, что у ребенка вся жизнь впереди.
Китайские - ребенка, руководствуясь логикой, что бабушка идеологически правильно подкована и может воспитать сотни полезных членов общества…
Что же выберет AGI, когда действительно станет General?
@Simple_Reliability
Западные LLM «сбивают» бабушку, мотивируя это тем, что у ребенка вся жизнь впереди.
Китайские - ребенка, руководствуясь логикой, что бабушка идеологически правильно подкована и может воспитать сотни полезных членов общества…
Что же выберет AGI, когда действительно станет General?
@Simple_Reliability
Шутка родилась, в связи с повсеместным обсуждением того, что AI заменит ИТшников:
В аббревиатуре SRE, S значит Senior
@Simple_Reliability
В аббревиатуре SRE, S значит Senior
@Simple_Reliability
🤣2
Forwarded from Технохаб Сбера | Екатеринбург
This media is not supported in your browser
VIEW IN TELEGRAM
Пока гирлянды мигают, а код компилируется — самое время задуматься о главном тренде 2025: AI во всем.
Приглашаем на нашу большую конференцию IT Community Day.
Ключевые темы:
🤖 AI-агенты и GenAI — как встроить в продукты и не сломать архитектуру.
🛡️ Надёжность инфраструктуры — когда за монитором следит еще один (искусственный) интеллект.
🧠 Soft skills — что прокачивать, чтобы остаться нужным человеком в эпоху ИИ.
Живые кейсы от Сбера, Т-Банка, 2ГИС и Яндекса в докладах и панельных дискуссиях, а также движ на afterparty гарантируем!
Участие — бесплатное. Прокачка — бесценна.
Встречаемся 6 декабря в 11:30.
➡️ Забронировать место
Приглашаем на нашу большую конференцию IT Community Day.
Ключевые темы:
🤖 AI-агенты и GenAI — как встроить в продукты и не сломать архитектуру.
🛡️ Надёжность инфраструктуры — когда за монитором следит еще один (искусственный) интеллект.
🧠 Soft skills — что прокачивать, чтобы остаться нужным человеком в эпоху ИИ.
Живые кейсы от Сбера, Т-Банка, 2ГИС и Яндекса в докладах и панельных дискуссиях, а также движ на afterparty гарантируем!
Участие — бесплатное. Прокачка — бесценна.
Встречаемся 6 декабря в 11:30.
➡️ Забронировать место
👍2
Gartner выпустил очередной прогноз по рискам внедрения AI в разработку (Predicts 2026: AI Potential and Risks Emerge in Software Engineering Technologies (Gartner; 3 December 2025))
Ключевые цифры следующие:
К 2027 году 40% организаций использующих AI для разработки столкнуться с перерасходом средств на оплату токенов, в случае если модель оплаты останется «по факту потребления»
К 2028 году приложения созданные с помощью vibe-кодинга увеличат количество дефектов в 2500%... на этом можно было бы поставить точку.
Но, как водится, есть ответы:
1. Контроль расходов за использование токенов нужно выстраивать уже сейчас. В идеале менять модель оплаты
2. Если от vibe-кодинга уже не отказаться, всех программистов уже оптимизировали, то надо возраждать/развивать/усиливать функцию архконтроля!
Забыл еще про одну цифру:к 2028 году появятся первые квантовые решения в enterprise среде… (повод для размышления)
@Simple_Reliability
Ключевые цифры следующие:
К 2027 году 40% организаций использующих AI для разработки столкнуться с перерасходом средств на оплату токенов, в случае если модель оплаты останется «по факту потребления»
К 2028 году приложения созданные с помощью vibe-кодинга увеличат количество дефектов в 2500%... на этом можно было бы поставить точку.
Но, как водится, есть ответы:
1. Контроль расходов за использование токенов нужно выстраивать уже сейчас. В идеале менять модель оплаты
2. Если от vibe-кодинга уже не отказаться, всех программистов уже оптимизировали, то надо возраждать/развивать/усиливать функцию архконтроля!
Забыл еще про одну цифру:
@Simple_Reliability
❤1👍1🔥1🤔1💯1
Есть такая легенда про римский бетон, якобы он прочнее современного, но рецепт его изготовления потерян…
Недавно ученые разрыли Помпеи и выяснили, что римляне просто… плохо мешали! И в этом был гениальный умысел.
Они добавляли в смесь куски негашёной извести (белые комочки). При замесе они не полностью растворялись и оставались внутри. Потом, когда в бетоне появлялась трещина и в неё попадала вода, она добиралась до такого «комочка». Он активировался и запечатывал повреждение. Вечный бетон с автопочинкой!
Это идеальная архитектурная метафора. Римляне не пытались сделать систему без изъянов. Они встроили в неё «горячие» резервные узлы (комочки извести), которые активируются только при сбое (трещине). Не стремитесь к идеальной первой версии — проектируйте системы, которые умеют залечивать себя сами.
@Simple_Reliability
Недавно ученые разрыли Помпеи и выяснили, что римляне просто… плохо мешали! И в этом был гениальный умысел.
Они добавляли в смесь куски негашёной извести (белые комочки). При замесе они не полностью растворялись и оставались внутри. Потом, когда в бетоне появлялась трещина и в неё попадала вода, она добиралась до такого «комочка». Он активировался и запечатывал повреждение. Вечный бетон с автопочинкой!
Это идеальная архитектурная метафора. Римляне не пытались сделать систему без изъянов. Они встроили в неё «горячие» резервные узлы (комочки извести), которые активируются только при сбое (трещине). Не стремитесь к идеальной первой версии — проектируйте системы, которые умеют залечивать себя сами.
@Simple_Reliability
🔥6👍3🤔1
Архитекторы ИИ — люди года по версии журнала Time
Впервые с 1982 года, подобное признание получила технология, тогда героем обложки стал персональный компьютер.
Time обосновал свой выбор тем, что в этом году ИИ стал полноценной частью жизни обычных людей и перестал быть игрушкой.
По сути, это признание всех, кто стоит за созданием и развитием технологий искусственного интеллекта.
P.S. Если хотите пообщаться с архитекторами ИТ СБЕРа (и не только) про ИИ и все остальное, приходите завтра на Arch.Conf
@Simple_Reliability
Впервые с 1982 года, подобное признание получила технология, тогда героем обложки стал персональный компьютер.
Time обосновал свой выбор тем, что в этом году ИИ стал полноценной частью жизни обычных людей и перестал быть игрушкой.
По сути, это признание всех, кто стоит за созданием и развитием технологий искусственного интеллекта.
P.S. Если хотите пообщаться с архитекторами ИТ СБЕРа (и не только) про ИИ и все остальное, приходите завтра на Arch.Conf
@Simple_Reliability
🔥1
Forwarded from Мишка на сервере (Mikhail Savin)
Крупнейший сбой Cloudflare с 2019 года: разбор корневой причины и уроки для SRE
Привет,
Корневая причина: неожиданное поведение 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
Привет,
%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
Блог Cloudflare
Сбой Cloudflare, 18 ноября 2025 г.
18 ноября 2025 г. в работе сервисов Cloudflare произошел сбой. Сбой был вызван ошибкой в логике генерации файла функции управление ботами, что привело к сбою многих Сервис Cloudflare.
👍2
Ребята из DevCrowd опросили 273 инженера, которые занимаются вопросами надёжности в своих компаниях и составили портрет инженера по надёжности
SRE - молодая роль, даже для опытных специалистов. Почти 70% тех, кто перешли в SRE сделали это за последние 1–5 лет.
Каждый пятый респондент работает в финтехе
Размер SRE-команды растёт вместе с размером компании
1 - 2 специалиста по надёжности на 150 инженеров.
Каждому второму сложно отстаивать свои инженерные решения
В основном из-за проблем с коммуникациями, нагрузки и отсутствия базовых процессов
Две трети респондентов
пользуются мессенджерами для алертинга
В половине компаний за инциденты отвечает дежурный инженер, а не отдельная роль
Только 50% команд формализовали процесс реагирования на инциденты
При этом у 59% команд
постмортемы стали стандартной практикой
Профессия эволюционирует: фокус смещается в сторону стратегической ответственности за устойчивость.
@Simple_Reliability
SRE - молодая роль, даже для опытных специалистов. Почти 70% тех, кто перешли в SRE сделали это за последние 1–5 лет.
Каждый пятый респондент работает в финтехе
Размер SRE-команды растёт вместе с размером компании
1 - 2 специалиста по надёжности на 150 инженеров.
Каждому второму сложно отстаивать свои инженерные решения
В основном из-за проблем с коммуникациями, нагрузки и отсутствия базовых процессов
Две трети респондентов
пользуются мессенджерами для алертинга
В половине компаний за инциденты отвечает дежурный инженер, а не отдельная роль
Только 50% команд формализовали процесс реагирования на инциденты
При этом у 59% команд
постмортемы стали стандартной практикой
Профессия эволюционирует: фокус смещается в сторону стратегической ответственности за устойчивость.
@Simple_Reliability
👍4
В ночь на 20 декабря масштабное отключение электроэнергии в Сан-Франциско парализовало весь флот роботакси Waymo. Более 130 000 потребителей остались без света, а беспилотники, потеряв связь с центром управления, просто застыли на дорогах, создав гигантские пробки.
Удалённые операторы не смогли помочь — в офисах тоже не было электричества.
Блэкаут начался в субботу днём из-за пожара на подстанции Pacific Gas & Electric.
Восстанавливали эту феерию полтора дня!
Уроки для адептов «надежности»:
1. Самые продвинутые автономные системы в очередной раз оказались уязвимы к сбою в коммунальных сетях (никогда такого не было и вот опять). Всегда помните и учитывайте риски нижележащих слоёв.
2. Waymo заявила, что её ПО рассматривает не работающие светофоры как нерегулируемые перекрёстки, но в условиях блэкаута это не сработало. Нужны алгоритмы и сценарии,позволяющие действовать в полностью деградировавшей среде (хотя бы съехать на обочину и не мешать)
3. Ну и самое простое и очевидное: центр управления и связь с автомобилями должны иметь автономное питание и альтернативные каналы связи. (Было?... не было…)
@Simple_Reliability
Удалённые операторы не смогли помочь — в офисах тоже не было электричества.
Блэкаут начался в субботу днём из-за пожара на подстанции Pacific Gas & Electric.
Восстанавливали эту феерию полтора дня!
Уроки для адептов «надежности»:
1. Самые продвинутые автономные системы в очередной раз оказались уязвимы к сбою в коммунальных сетях (никогда такого не было и вот опять). Всегда помните и учитывайте риски нижележащих слоёв.
2. Waymo заявила, что её ПО рассматривает не работающие светофоры как нерегулируемые перекрёстки, но в условиях блэкаута это не сработало. Нужны алгоритмы и сценарии,позволяющие действовать в полностью деградировавшей среде (хотя бы съехать на обочину и не мешать)
3. Ну и самое простое и очевидное: центр управления и связь с автомобилями должны иметь автономное питание и альтернативные каналы связи. (Было?... не было…)
@Simple_Reliability
😱3👍2
У многих, зачастую, создается ощущение, что их имеющиеся знания и опыт очевидны всем. На самом деле, это не так.
Люди не связанные с ИТ, в большинстве случаев, имеют очень поверхностные знания по тому как устроена надежности в ИТ.
Если вам нужно их быстро погрузить в тему надежности, а главное, дать понять, что они играют не последнюю роль в ее обеспечении, можете для начала дать им почитать эту памятку.
Памятка для руководителя: как управлять надёжностью IT-систем
@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
❤5👍4