Культура Надёжности
175 subscribers
141 photos
5 videos
48 links
Авторский канал о надёжности

@SlavaKudryashov
Download Telegram
В начале февраля вышло очередное исследование от Harvard Business Review: AI Doesn’t Reduce Work — It Intensifies It.
 
200+ интервьюеров опровергает гипотезу о том, что генеративный ИИ разгружает команды. Напротив, добровольное использование ИИ приводит к систематической интенсификации (попросту говоря,увеличению количества) труда.

Внедрение ИИ запускает самоподдерживающийся механизм, который, в конечном итоге, приводит к перегрузкам

Ускорение задач → Рост ожиданий скорости → Зависимость от ИИ → Расширение функционала → Увеличение плотности работы → Когнитивное истощение


Сотрудники, увлеченные возможностями ИИ, активно берут на себя дополнительные задачи, воспринимая это как профессиональный вызов.
Однако, такая «добровольная» интенсификация труда имеет отложенные последствия, в том числе и для надёжности (канал же про надёжность=))): накапливается усталость, растет число ошибок, снижается качество решений.

В итоге эксперты HBR делают такие выводы/советы:
ИИ сам по себе не снижает нагрузку, а позволяет делать больше.

Чтобы это не привело к выгоранию и снижению качества, организациям нужно активно формировать такие практики:

- Проведение аудита ролей: проверить, какие новые задачи взяли на себя сотрудники благодаря ИИ, и оценить реальную нагрузку, в том числе неучтенную

- Проведение тренингов по осознанному использованию ИИ: как ставить границы, как распределять задачи между собой и ИИ, как избегать мультизадачности

- Введение намеренных пауз, регулярных остановок для сверки с целями: перед принятием ключевого решения нужно привести контраргумент и обосновать связь со стратегией компании

- Четкая последовательность. Вместо мгновенной реакции — сбор и групповая обработка результатов работы ИИ в отведенные временные слоты. Это освобождает ресурсы для глубокой фокусировки

- Человеческое общение!... Выделение времени для живого общения: в отличие от ответов ИИ, диалог с коллегами возвращает контекст и выявляет неочевидные нюансы.


@Simple_Reliability
3👍1🙏1
Что если использовать LLM по его прямому назначению: попросить предугадать. Придумать, что может пойти не так, что может стать гипотетической причиной сбоя при внедрении.

Получается не post-mortem, а pre-mortem анализ.
Чем не идея для улучшения производительности службы сопровождения и повышения надёжности?
 
Pre-mortem — это гипотетическая противоположность посмертного анализа (postmortem). В медицине вскрытие позволяет медикам и родственникам узнать, что стало причиной смерти пациента.

Выгоду получают все, кроме, разумеется, самого пациента. Pre-mortem в IT/Бизнесе проводится в начале проекта, чтобы его можно было улучшить, а не «вскрывать».

В отличие от типичных сессий критики, где членов команды/AI-агентов спрашивают, что может пойти не так, Pre-mortem исходит из предположения, что «пациент» умер, и задает вопрос: что именно пошло не так?

Задача команды/AI-агентов — придумать правдоподобные причины провала проекта/внедрения.

 
Типичный Pre-mortem начинается после того, как все готово к запуску. Команде/AI-агентам ставится задача «Проект провалился, вам необходимо сформулировать причины провала».

Что хорошо, живые люди в такой ситуации смогут сформулировать «потенциальные» проблемы, которые они обычно не стали бы упоминать, опасаясь показаться «недипломатичными».

AI-агенты смогут потратить еще n-ое количество токенов на очень важное дело=))
 
@Simple_Reliablity
5👍2🔥1
Forwarded from Avito SREда
Media is too big
VIEW IN TELEGRAM
Работает быстро, но не всегда туда. О чём мы? Об AI 😀

В новом выпуске размышляем на самые спорные темы и выясняем:
➡️ какие рутинные задачи в SRE ему уже можно отдать;
➡️ в каких случаях AI — коллега, а в каких — инструмент;
➡️ почему эта тема стала так актуальна для SRE именно сейчас;
➡️ где мы в Авито уже внедрили AI, а где соблюдаем осторожность.

А пока вы не успели перейти по ссылке на выпуск, попробуйте угадать, фейки следующие новости или нет:

1️⃣— DeepSeek обогнала OpenAI по эффективности обучения, тренируя модели за миллионы вместо миллиардов
2️⃣— Model Drift уничтожил систему обнаружения мошенничества — никто не замечал две недели


❤️, если обе новости — правда
👀, если 1 новость — фейк
👾, если 2 новость — фейк
😱, если обе новости — фейки

Правильные ответы ищите в выпуске!

📺 YouTube
🔵 VK
💻 Rutube
🛫 Любая удобная платформа

#sre
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥105👾1
Forwarded from Мишка на сервере (Mikhail Savin)
Надежность — это не продукт 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
3👍1🔥1
10-11 апреля можем встретиться на XV IT-конференции «Стачка» в Ульяновске.

Обсудить проблемы надёжности, связанные с внедрением ИИ и все остальное.

Здесь соберутся более 2000 участников (и онлайн-зрителей): разработчики, специалисты по контенту и коммуникациям, HR, а также руководители и собственники IT-компаний.

В течение двух дней – мощный IT-буст:
- 200+ докладов от лидеров индустрии из ВКонтакте, Авито, Яндекса, Сбера, Wildberries & Russ, Ozon, Газпром ИД, Альфа-Банка и т.д.
- 30+ секций по четырём направлениям: Разработка, Управление, Дизайн и Контент, Digital-маркетинг.
- мастермайнды, панельные дискуссии, мастер-классы, экспертные зоны, нетворкинг-события, афтепати в завершении первого дня.


Есть промокод и бесплатный билет, пишите

@Simple_Reliability
🔥6
Forwarded from DUMP Ekb 2026
Секция DevOps & SRE — про изменения, которые происходят прямо сейчас в индустрии.

Делимся одним из докладов ⤵️

Вячеслав Кудряшов, «От DevOps к EvalOps (или как мы трансформируем функцию OPS/SRE в связи с внедрением GenAI)»

Как меняется роль OPS и SRE с приходом генеративного ИИ? Что такое EvalOps и зачем он нужен?

В докладе разберём, как трансформируются функции сопровождения, как управлять инфраструктурой, где значительную часть процессов уже выполняют ИИ-агенты, и какие компетенции важно развивать уже сейчас.

Если хотите понять, куда движется DevOps и какие навыки будут востребованы завтра — обязательно загляните ☺️
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8👍2
Forwarded from ДевФест
От DevOps к EvalOps
или как мы трансформируем функцию OPS/SRE в связи с внедрением GenAI 🤖

При массовом внедрении GenAI в ИТ-ландшафт, крупные организации сталкиваются с новыми вызовами:
– GenAI-системы недетерминированы по своей природе. Классические метрики (uptime, latency) не отражают их реальное качество и надежность.
– Появляются новые классы инцидентов: «галлюцинации», дрейф качества, промпт-инжекты требуют новых подходов к мониторингу и реагированию.

В докладе Вячеслав Кудряшов, исполнительный директор, МСС, СБЕР, расскажет о том, как меняются функции сопровождения, что такое EvalOPS. Рассмотрим конкретные примеры, как управлять инфраструктурой, в которой большую часть бизнес-процессов обслуживают ИИ-агенты, и какие компетенции нужно растить уже сейчас 🧠

Если это для вас, ждём вас на ДевФесте 🖱
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
- Знаете, что такое 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
🔥62
В психологии есть принцип принятия решений - Pre-Mortem
Когда вы собираетесь что-то сделать — запустить проект, нанять сотрудника, подписать контракт, — вместо вопроса «что может пойти не так?» скажите себе: «прошло полгода, все провалилось, что случилось?». Этот прием анализа решений придумал психолог Гэри Кляйн. Он заметил: если описать провал как уже свершившийся факт, человек оценивает свои планы объективнее.

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


@Simple_Reliability
🔥64👏1
Forwarded from Технологии Сбера Самара
Сообщество инженеров сопровождения Сбера продолжает агентизировать города

📆13 августа Сбер собирает OPS, DevOps и SRE-инженеров Самары в необычном формате и только офлайн.

🏦Сбер курсирует по Волге на двух теплоходах, где в формате барных стендапов и дискуссий инженеры обсудят, что умеют агенты в OPS, а что пока нет, как в Сбере строят надёжность, как реагируют на инциденты, куда ведёт агентизация и что с этим делать.

13 августа, 18:30
Самара, Теплоходы "Вояж" и "Спутник"

➡️Регистрация тут
Количество очных мест ограничено
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6👍1
10 open-source сканеров безопасности агентских навыков
Хочу поделиться ссылкой на статью с таким заголовком и еще парой ссылок по теме:

- В январском исследование SkillScan говорится, что среди 31 132 общедоступных навыков agent skills удалось выявило 26,1% потенциально опасных, и 5,2% заведомо опасных навыка.

- В конце июля организовался Open Secure AI Alliance (см. пресс-релиз в блоге Nvidia)

В общем, сканируйте ваши, а тем более чужие навыки. Мало ли что