В начале февраля вышло очередное исследование от Harvard Business Review: AI Doesn’t Reduce Work — It Intensifies It.
200+ интервьюеров опровергает гипотезу о том, что генеративный ИИ разгружает команды. Напротив, добровольное использование ИИ приводит к систематической интенсификации (попросту говоря,увеличению количества) труда.
Внедрение ИИ запускает самоподдерживающийся механизм, который, в конечном итоге, приводит к перегрузкам:
Сотрудники, увлеченные возможностями ИИ, активно берут на себя дополнительные задачи, воспринимая это как профессиональный вызов.
Однако, такая «добровольная» интенсификация труда имеет отложенные последствия, в том числе и для надёжности (канал же про надёжность=))): накапливается усталость, растет число ошибок, снижается качество решений.
В итоге эксперты HBR делают такие выводы/советы:
@Simple_Reliability
200+ интервьюеров опровергает гипотезу о том, что генеративный ИИ разгружает команды. Напротив, добровольное использование ИИ приводит к систематической интенсификации (попросту говоря,увеличению количества) труда.
Внедрение ИИ запускает самоподдерживающийся механизм, который, в конечном итоге, приводит к перегрузкам:
Ускорение задач → Рост ожиданий скорости → Зависимость от ИИ → Расширение функционала → Увеличение плотности работы → Когнитивное истощение
Сотрудники, увлеченные возможностями ИИ, активно берут на себя дополнительные задачи, воспринимая это как профессиональный вызов.
Однако, такая «добровольная» интенсификация труда имеет отложенные последствия, в том числе и для надёжности (канал же про надёжность=))): накапливается усталость, растет число ошибок, снижается качество решений.
В итоге эксперты HBR делают такие выводы/советы:
ИИ сам по себе не снижает нагрузку, а позволяет делать больше.
Чтобы это не привело к выгоранию и снижению качества, организациям нужно активно формировать такие практики:
- Проведение аудита ролей: проверить, какие новые задачи взяли на себя сотрудники благодаря ИИ, и оценить реальную нагрузку, в том числе неучтенную
- Проведение тренингов по осознанному использованию ИИ: как ставить границы, как распределять задачи между собой и ИИ, как избегать мультизадачности
- Введение намеренных пауз, регулярных остановок для сверки с целями: перед принятием ключевого решения нужно привести контраргумент и обосновать связь со стратегией компании
- Четкая последовательность. Вместо мгновенной реакции — сбор и групповая обработка результатов работы ИИ в отведенные временные слоты. Это освобождает ресурсы для глубокой фокусировки
- Человеческое общение!... Выделение времени для живого общения: в отличие от ответов ИИ, диалог с коллегами возвращает контекст и выявляет неочевидные нюансы.
@Simple_Reliability
❤3👍1🙏1
Что если использовать LLM по его прямому назначению: попросить предугадать. Придумать, что может пойти не так, что может стать гипотетической причиной сбоя при внедрении.
Получается не post-mortem, а pre-mortem анализ.
Чем не идея для улучшения производительности службы сопровождения и повышения надёжности?
Типичный Pre-mortem начинается после того, как все готово к запуску. Команде/AI-агентам ставится задача «Проект провалился, вам необходимо сформулировать причины провала».
Что хорошо, живые люди в такой ситуации смогут сформулировать «потенциальные» проблемы, которые они обычно не стали бы упоминать, опасаясь показаться «недипломатичными».
AI-агенты смогут потратить еще n-ое количество токенов на очень важное дело=))
@Simple_Reliablity
Получается не 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 новость — фейк
👾, если 2 новость — фейк
😱, если обе новости — фейки
Правильные ответы ищите в выпуске!
📺 YouTube
🔵 VK
💻 Rutube
🛫 Любая удобная платформа
#sre
В новом выпуске размышляем на самые спорные темы и выясняем:
А пока вы не успели перейти по ссылке на выпуск, попробуйте угадать, фейки следующие новости или нет:1️⃣ — DeepSeek обогнала OpenAI по эффективности обучения, тренируя модели за миллионы вместо миллиардов2️⃣ — Model Drift уничтожил систему обнаружения мошенничества — никто не замечал две недели
❤️, если обе новости — правда
👀, если 1 новость — фейк
👾, если 2 новость — фейк
😱, если обе новости — фейки
Правильные ответы ищите в выпуске!
#sre
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10❤5👾1
Forwarded from Мишка на сервере (Mikhail Savin)
Надежность — это не продукт SRE, или почему мы всё понимали не так?
Привет,
На самом деле, надежность — это не "продукт", который 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
Привет,
%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-конференции «Стачка» в Ульяновске.
Обсудить проблемы надёжности, связанные с внедрением ИИ и все остальное.
Есть промокод и бесплатный билет, пишите
@Simple_Reliability
Обсудить проблемы надёжности, связанные с внедрением ИИ и все остальное.
Здесь соберутся более 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 и какие навыки будут востребованы завтра — обязательно загляните ☺️
Делимся одним из докладов
Вячеслав Кудряшов, «От 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. Рассмотрим конкретные примеры, как управлять инфраструктурой, в которой большую часть бизнес-процессов обслуживают ИИ-агенты, и какие компетенции нужно растить уже сейчас🧠
Если это для вас, ждём вас на ДевФесте🖱
или как мы трансформируем функцию 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)
@Simple_Reliability
- Нет.
- Дословный перевод – сбруя. На самом деле это и есть сбруя, только не для лошади, а для ИИ-агентов. Так понятнее?
- Да… но… что такое сбруя?
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
🔥6⚡2
В психологии есть принцип принятия решений - Pre-Mortem
В ИТ мы чаще всего пользуемся другим принципом - Post-Mortem. Для чего он нужен, кажется, все понятно, а отказаться от него мы сможем только когда у нас не будет инцидентов…т.е. примерно никогда.
А что если перенять и переиспользовать Pre-Mortem для смещения влево оценки надежности при новых внедрениях…
@Simple_Reliability
Когда вы собираетесь что-то сделать — запустить проект, нанять сотрудника, подписать контракт, — вместо вопроса «что может пойти не так?» скажите себе: «прошло полгода, все провалилось, что случилось?». Этот прием анализа решений придумал психолог Гэри Кляйн. Он заметил: если описать провал как уже свершившийся факт, человек оценивает свои планы объективнее.
В ИТ мы чаще всего пользуемся другим принципом - Post-Mortem. Для чего он нужен, кажется, все понятно, а отказаться от него мы сможем только когда у нас не будет инцидентов…
А что если перенять и переиспользовать Pre-Mortem для смещения влево оценки надежности при новых внедрениях…
Берлинский разработчик Амин Боргеи создал на основе этой техники готовый скилл Premortem для Claude. Он собирает контекст из чатов и файлов, реконструирует сценарии провала, поручает сгенерированным «следователям» проанализировать каждый из них и выдает чеклист на 3–5 пунктов — что
надо было проверить до запуска
ссылка
@Simple_Reliability
🔥6❤4👏1
Forwarded from Технологии Сбера Самара
Сообщество инженеров сопровождения Сбера продолжает агентизировать города
📆 13 августа Сбер собирает OPS, DevOps и SRE-инженеров Самары в необычном формате и только офлайн.
🏦 Сбер курсирует по Волге на двух теплоходах, где в формате барных стендапов и дискуссий инженеры обсудят, что умеют агенты в OPS, а что пока нет, как в Сбере строят надёжность, как реагируют на инциденты, куда ведёт агентизация и что с этим делать.
13 августа, 18:30
Самара, Теплоходы "Вояж" и "Спутник"
➡️ Регистрация тут
Количество очных мест ограничено
13 августа, 18:30
Самара, Теплоходы "Вояж" и "Спутник"
Количество очных мест ограничено
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6👍1
Forwarded from Архитектура ИТ-решений
10 open-source сканеров безопасности агентских навыков
Хочу поделиться ссылкой на статью с таким заголовком и еще парой ссылок по теме:
- В январском исследование SkillScan говорится, что среди 31 132 общедоступных навыков agent skills удалось выявило 26,1% потенциально опасных, и 5,2% заведомо опасных навыка.
- В конце июля организовался Open Secure AI Alliance (см. пресс-релиз в блоге Nvidia)
В общем, сканируйте ваши, а тем более чужие навыки. Мало ли что
Хочу поделиться ссылкой на статью с таким заголовком и еще парой ссылок по теме:
- В январском исследование SkillScan говорится, что среди 31 132 общедоступных навыков agent skills удалось выявило 26,1% потенциально опасных, и 5,2% заведомо опасных навыка.
- В конце июля организовался Open Secure AI Alliance (см. пресс-релиз в блоге Nvidia)
В общем, сканируйте ваши, а тем более чужие навыки. Мало ли что
Generativeprogrammer
10 Open-Source Projects Securing AI Agent Skills
A practical map of scanners, supply-chain controls, sandboxes, and runtime governance.