The State of DevOps Modernization 2026 (Рубрика #Devops)Изучил недавно вышедший отчет "The State of DevOps Modernization 2026" от Harness. Отчет основан на опросе ~700 инженеров и руководителе, что был проведен в феврале 2026 года компанией Coleman Parkes. Основной вывод отчета в том, что AI резко ускорил локальный цикл кодирования, а остальная часть delivery контура во многих командах внутри корпораций не успевает его переварить.Основная аналитическая модель отчета очень простая: почти все выводы построены через cross-tab по вопросу "как часто вы используете AI инструменты для кодирования" - от нескольких раз в день до более редкого использования. То есть это не анализ телеметрии и не каузальный инференс как в DORA, а срез восприятия и самооценок респондентов.Авторы выделил следующие ключевые результаты1️⃣ Скорость действительно выросла. 45% very frequent AI пользователей говорят о ежедневных или чаще развертывания против 32% у frequent и 15% у occasional users. Но рядом с этим идет налог на стабильность: 69% very frequent users говорят, что AI-generated code приводит к проблемам с развертыванием как минимум в половине случаев; 22% deployments в этой когорте заканчиваются rollback, hotfix или customer-impacting incident; MTTR по таким инцидентам у них выше - 7.6 часа против 6.0 и 6.3 часа в соседних когортах.2️⃣ Но это напряжение распространяется далеко за пределы инцидентов. Среди very frequent AI users 50% говорят о росте vulnerabilities/security инцидентов и 50% - о росте non-compliance issues; 49% видят больше проблемы с производительностью; 51% - больше code quality/efficiency problems. При этом сами авторы специально оговаривают: явной причинно-следственной связи между AI coding и этими проблемами отчет не доказывает (такой дизайн эксперимента может показать только корреляции)3️⃣ Coding автоматизируется быстрее, чем остальной SDLC. 84% респондентов используют AI ежедневно для coding, но для QA testing этот показатель 68%, для performance/cost optimization 63%, для refactoring 62%. 47% very frequent users говорят, что ручная работа дальше по пайплайну после кода стала проблемнее (это QA, code review, remediation); 69% теряют время из-за медленных и ненадженых CI/CD; 70% считают, что их pipelines страдают от flaky тестов and неуспешных развертываний; 75% связывают давление на шиппинг с выгоранием; 73% говорят, что у них почти нет стандартных темплейтов и golden pathsВ итоге, видно, что проблема в том, что AI усиливает throughput там, где платформа, CI/CD, гейты контроля и координация остались на старой скорости. Авторы сами это почти проговаривают: у них есть гипотеза, что heavy AI users просто пытаются доставлять больше кода и поэтому острее чувствуют flaky tests и deployment failures; их pipelines не обязательно хуже, просто потребности уже выше. Это сильный инсайт, но как доказательств причинности отчет не дает:)Примерно эти же мысли я писал в статье "От классического PDLC к AI-native разработке", но в основном опирался на другие исследования типа DORA или нашего AI4SDLC, который мы проводили от "Т-Технологий" в конце прошлого года и проведем еще раз в этом году#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign
DevOps и инфраструктура
DevOps и инфраструктура — раздел темы «Технологии»: посты из публичных Telegram-каналов в единой ленте. Листай свежие записи и переходи к оригиналам в Telegram.
Лента темы
Деградировавший кластер, или 168 часов траблшутингаСегодня хочу подсветить отличный доклад с DevOpsConf 2024 как раз в тему недавно вышедшего подкаста, хотя доклад и не про Incident Management Process, а про борьбу с Kafka:Максим Ванюшкин — Kafka. Деградировавший кластер, или 168 часов траблшутинга.С одной стороны, в докладе нет рассказа про борьбу за живучесть системы, а с другой — он целиком и полностью именно про это. То, как ребята рубятся с Kafka, ну это просто красота-красотища. +) Смотреть и кайфовать.

Осенью запускаем новый формат обучения — SE Labs — онлайн-лабы по 4 часаЗачем это нужноДля проектирования ИТ-решений нужен кругозор в технологиях. Технологий очень много, каждый день появляются новые. Сесть и за один присест изучить их все невозможно, нужно грызть гранит понемногу. В одиночку это делать сложно и муторно. Можно потратить 5 часов на поиск дистрибутива, установку, настройку, конфликты зависимостей и т.д.Что предлагаем мыВы приходите на 4 часа в онлайн и под руководством лаборанта знакомитесь с технологией на кончиках пальцев.Мы даём готовые скрипты по подготовке инфраструктуры, помогаем её настроить или даже даём готовую среду для тренировки.Мы даём заготовленный учебный проект со структурами данных, API и т.д.Мы ведём вас по учебно-тренировочному сценарию лабы, который даёт возможность быстро и наглядно познакомиться с технологией разумным путём, без «метода случайного тыка».Мы заготовили до 50 потенциальных тем, сейчас готовим пилотный трек. Помогите нам выбрать лабы, с которых вам хотелось бы начать.Какие темы лаб вам наиболее интересны (см следующий пост)?
QazTech — национальная платформа, на которой государственные органы будутразрабатывать свои информационные системы. Об этом писали выше. В ней собраны все необходимыеинструменты: для разработки, тестирования, деплоя, мониторинга и т.д. По сути, госорганысмогут собирать свои ИС как конструктор.На платформу уже мигрировали Smart Bridge и сайт Nitec, уже разрабатывается в рамках этойплатформы Egov 3.0.Ранее ЦПЦП сэкономил более 50 млрд тенге благодаряэкспертизе ИТ-проектов госорганов.Эта огромная сумма как раз и показывала, насколько легко раньше было ГО завышатьбюджеты и стоимости всяких непонятных проектов. Вопрос, сократит ли QazTech гос расходы на раздутые проекты? Ну и станет ли это еще одним шагом к тому, чтобы государственная цифровизация стала эффективной,прозрачной и действительно ориентированной на результат, а наши деньги не уходилинепонятно куда?
Пхахаха. Утром были важные новости на работе, кто-то удалил продакшн базу данных на одном из проектов и без возможности восстановить. Теперь мы должны на всех проектах у всех пользователей удалить права доступа.
Закончена очередная большая переписка онлайн-курса "Системная инженерия", теперь это версия 2025 года, согласованная по идеям и терминологии со всеми курсами-пререквизитами.Основная цель текущей переписки -- это подробней дать идеи эволюционной инженерии, гибкой (agile) инженерной разработки. Существенно обновлены основные понятия: вместо "жизненный цикл", отсылающий к идеям однократного его прохождения и представлениям "водопада" идёт отсылка к "инженерному процессу" (engineering process, иногда в конкретизации software process или с отсылкой именно к разработке development process). В этой версии уточнено разделение труда: введена явно роль прикладного методолога (функционального проектировщика, функционального архитектора), уточнена роль визионера, уточнена роль инженера внутрненней платформы разработки (идеи DevOps дополнены идеями platform engineering). Инженерные обоснования, как главный технический тренд (после тренда автоматизации инженерии, в том числе с использованием AI) выведены в отдельный раздел. Объём текста (включая задания) -- 1Мзнак с пробелами (для сравнения: "Рациональная работа" -- 1.2Мзнака, "Системное мышление" -- 2.5Мзнаков, "Методология" -- 1.4Мзнака), текст был существенно дополнен разъяснениями и примерами (объём предыдущей версии курса -- 0.7Мзнаков, так что 30% материала в курсе -- новые). Разделы:Введение1. Безсмасштабная эволюционная системная инженерия2. Архироль создателя/инженера и разделение инженерного труда3. Инженерный процесс4. Прикладная методология предметной области5. Эволюционная архитектура6. Эволюционное проектирование7. DevOps8. Инженерные обоснованияОсновной материал курса изложен с использованием не столько стандартов системной и программной инженерии (они отражают идеи, которые были передовыми больше десяти лет назад, поэтому не отражают произошедшего с тех пор сдвига в эволюционную инженерию, но продолжают использоваться в сильно зарегулированных госорганами больших инженерных проектах создания кибер-физических систем типа атомной электростанции и авианосца, изменений инженерии там можно ожидать очень нескоро), сколько по современной литературе 2017-2025 годов. При этом в курсе нет фрагментов, сгенерированных AI-системами. В курсе приведено 392 ссылки на первоисточники и 21 обложка рекомендованных книг (картинка в посте в ЖЖ — как раз эти обложки, над каждой книгой — год её издания). https://ailev.livejournal.com/1759527.html
ПереездКогда я работала в Skyeng и он был крошечным, но гордым стартапом, а отдел обучения только формировался, мы постоянно переезжали. И нет, не из офиса в офис, ведь мы все работали удаленно. Хорошие времена были! Переезжали мы с одной платформы дистанционного обучения на другую. Причем каждый раз по очень удивительным причинам: то контракт с компанией решили не продлевать, то компания обанкротилась или просто перестала выходить на связь. Помню, что за 2 года нам пришлось переехать 3 раза и это было ад безудержное веселье. Несколько выводов:◾️ Всегда делайте БЭКАП! Сохраняйте исходники. Даже если лень, даже если кажется, что лучше потом. «Потом» не наступит. ◾️ Храните все ваши исходники в полном порядке, организуйте процесс так, чтобы все, кто работает над созданием продукта, знали, куда, как и когда сохранять все документы. Сделайте так, чтобы любой человек (новичок, например) смог быстро все найти. ◾️ Ну, и выбирайте подрядчиков с умом. Составьте список критериев, выделите наиболее приоритетные, сделайте ресерч, составьте шорт-лист, запросите демо-версии и протестируйте. И вот опять.Прошло 5 лет. Я на встрече и руководитель внезапно: «Кстати! Тут такая новость! Возможно в конце года нас ждет переезд!»Пара-пара-пам! 🫠#work
С 1 сентября 2026 года все участники перевозок вне зависимости от сферы деятельности обязаны оформлять в электронном виде транспортные накладные, заказы или заявки на перевозку, экспедиторские документы, железнодорожную накладную и грузовую накладную при авиаперевозках. . В отдельных случаях, список которых определит Минтранс России, будет допускаться оформление бумажных документов. 🖋
Чтобы перейти на электронные перевозочные документы, необходимо получить сертификат квалифицированной электронной подписи (КЭП) на руководителя (индивидуального предпринимателя) или сертификат КЭП и оформить машиночитаемую доверенность (МЧД) для сотрудников.
Затем подключиться к одному из аккредитованных операторов ИС ЭПД — организации, которая предоставляет услуги по передаче электронных перевозочных документов между участниками перевозки и в ГИС ЭПД. Перечень аккредитованных операторов размещен на сайте Минтранса России.
Третий шаг — предоставить доступ к сервису для сотрудников компании и назначить администратора, при необходимости подключить водителей.Сказать спасибо — 🔥
Федеральный закон от 07.06.2025 № 140-ФЗ👩🏼💻 Обращаю внимание: 
В Kubernetes-продакшене пользователи жалуются, что при резком росте нагрузки часть запросов теряется или обрабатывается с большим лагом. Как вы будете искать и решать проблему?Проверю метрики Pod’ов и нод (CPU/memory), события в кластере и логи ingress-контроллера. Удостоверюсь, что настроены requests/limits, HPA для автоматического масштабирования и readinessProbe, чтобы трафик шёл только на готовые Pod’ы. Для решения — оптимизировать ресурсы, включить горизонтальное или кластерное авто-масштабирование, при необходимости добавить очередь (Kafka/RabbitMQ) для сглаживания пиков.Библиотека собеса по Python
Каналы по теме
Bash Days | Linux | DevOps@bashdays · 24.0K подписчиков
k8s (in)security@k8security · 12.5K подписчиков
Технологический Болт Генона@tech_b0lt_Genona · 8.7K подписчиков
Useful Tools | Linux | GitOps | DevOps@gitgate · 6.6K подписчиков
📚Системный Администратор (RTFM)@IT_obrazovach · 6.5K подписчиков
Админим с Буквой@bykvaadm · 6.1K подписчиков
DevopsTrain@devopstrain · 1.2K подписчиков
Кубернетичек@k8sjust · 1.1K подписчиков
realmanual.ru@realmanual · 595 подписчиков
DevOps от первого лица@byurrer_ru · 507 подписчиков
Кубертатный период@kubertat · 488 подписчиков
Что мы делаем в IT@everydayanykey · 419 подписчиков