DevOps *

Data Sapience приглашает на онлайн-конференцию «Kolmogorov Online Day» ⚙️

Дата: 18 сентября 📆
Время: 16:00 ⏰
Формат: онлайн 🌐

Что будет представлено:
▪️Достижения Kolmogorov AI: этапы развития, ключевые результаты;
▪️«Тессеракт» — обзор нового ПАКа для создания доверенных моделей ИИ;
▪️Срез практик MLOps — объективный взгляд на тренды и подводные камни, а также подходы к работе с AI от независимых экспертов;
▪️Демонстрация возможностей Kolmogorov AI для построения фабрики ИИ-агентов.

Вебинар будет полезен тем, кто хочет:
▪️Автоматизировать и ускорить вывод моделей в production;
▪️Наладить эффективный MLOps и перейти от экспериментов к промышленной эксплуатации;
▪️Найти подходящие инструменты и узнать об опыте создания надежной, масштабируемой и высокопроизводительной инфраструктуры для ML-моделей.

🔗 Зарегистрироваться на конференцию

Сегодня, 9 сентября, в мире ИТ вспоминают первый компьютерный баг

В 1947 инженеры Гарвардского Mark II под руководством Грейс Хоппер разбирались с поломкой реле. В какой-то момент они нашли причину — внутри застряла настоящая моль. Её аккуратно извлекли, приклеили в журнал отладки и подписали: «Первый реальный случай бага».

До этого слово “bug” использовали в инженерной среде, но именно этот случай сделал его легендой ИТ.

Забавно, что сама моль сохранилась — её до сих пор можно увидеть в Смитсоновском институте.

С тех пор баги перестали быть буквальными насекомыми, но последствия стали куда серьёзнее.

Вспомнить хотя бы Heartbleed — уязвимость в OpenSSL, обнаруженную в 2014-м. Одна ошибка в библиотеке, которая отвечает за шифрование, открыла доступ к памяти миллионов серверов по всему миру. Пароли, ключи, данные — всё оказалось под угрозой. В СМИ её называли «самым громким багом десятилетия».

Через несколько лет весь мир обсуждал уже Log4j. Казалось бы, скромная библиотека для логирования на Java, использующаяся в тысячах приложений. В декабре 2021 обнаружили, что через неё можно удалённо выполнить произвольный код. За считаные часы уязвимость стала глобальной катастрофой: под угрозой оказались банки, облачные сервисы и даже игровые платформы вроде Minecraft.

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

И это, пожалуй, самое важное напоминание: в ИТ нет «мелких багов». Любая ошибка может стать той самой «молью», остановившей работу огромной машины.

А какой баг стал самым запоминающимся для вас?

Продакшен, производственная среда или...

Подскажите, пожалуйста, какой термин вам понятнее:

• продакшен,

• "боевой" сервер,

• производственная среда,

• производственное окружение,

• промышленная среда,

• промышленное окружение,

• live сервер,

• prod,

• production,

• PROD.

Нужно для будущей книги. Хочу написать так, чтобы читатели потом поняли, что я имею в виду.

❓Сколько ошибок вы уже допустили в ClickHouse? Мы — много! На бесплатном вебинаре «ClickHouse Fail Fest: Собрали все грабли, чтобы вам не пришлось» покажем, какие проблемы чаще всего встречаются и как их обойти.

🗓 Дата: 5 сентября

🕓 Время: 16:00–17:00 (Мск)

Что разберём:

🔧 нормализацию данных и её подводные камни;

🔧 апдейты, долёты и малые вставки данных;

🔧 влияние структуры таблиц на производительность;

🔧 ошибки в оценке масштаба данных;

🔧 реальные кейсы и альтернативные подходы.

После эфира вы получите набор антипаттернов и проверенных решений, которые помогут:

✔️ повысить надёжность,

✔️ сократить издержки,

✔️ использовать ClickHouse максимально эффективно.

👨‍💻 Для кого: разработчики, тестировщики, аналитики и архитекторы ПО.

👉 Зарегистрируйтесь и приходите — час эфира избавит вас от десятков часов экспериментов и отладки.

Запись вебинара «От кода до запуска: российский стек для Java — Axiom JDK и OpenIDE» доступна для просмотра

Вебинар прошёл, а воспоминания запись осталась.

Если вы не успели на вебинар, но очень хотели, то не переживайте! Мы всё записали, чтобы вы могли посмотреть в любое удобное время.

Что обсуждали на вебинаре:

• Вызовы отечественной ИТ индустрии.

• Портфолио Axiom JDK.

• Регуляторика и соответствие стандартам.

• РБПО: процесс создания доверенных Java продуктов.

• Зачем OpenIDE разработчику и бизнесу.

• В чём проблема собрать Intellij IDEA самостоятельно

• Как будет развиваться OpenIDE.

Запись уже доступна на площадках.

• Смотреть на YouTube

• Смотреть в VK Видео

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

📅 Дата: 26 августа 2025

⏰ Время: 16:00–17:00 (Мск)

В программе:

✔️ Культура DevSecOps и её связь с Kubernetes

✔️ Разбор реальных проблем безопасности

✔️ Поиск уязвимостей в инфраструктуре

✔️ Живая демонстрация

Вебинар будет интересен для разработчиков, тестировщиков, сисадминов и DevOps-инженеров.

💡 Если Kubernetes — часть вашей работы, этот эфир поможет избежать критических ошибок.

👉 Регистрируйтесь и приходите👈

Интеграция PVS-Studio c SGRC SECURITM

Компания PVS-Studio и платформа Securitm заключили технологическое партнёрство для обеспечения интеграции статического анализатора кода PVS-Studio в экосистему DevSecOps.

Облачный сервис и программное обеспечение SGRC Securitm позволяют построить управление информационной безопасностью на базе риск-ориентированного подхода и единой информационной модели компании.

Отчёт анализатора PVS-Studio стало возможным загрузить в Securitm для дальнейшего использования с помощью пользовательского интерфейса системы.

Подробнее о том, как загрузить отчёт анализатора PVS-Studio в систему Securitm можно прочитать в посвящённом этому разделе нашей документации.

Также мы с коллегами из Securitm провели совместный вебинар, на котором обсудили, как обеспечить соблюдение требований ГОСТ в области РБПО, а также показали реальные примеры использования PVS-Studio и Securitm.

Я узнал о... #3: DevOps фреймворк DORA

DORA - это DevOps фреймворк из 4-х метрик, которые помогают оценить эффективность и качество релизного процесса.

Фреймворк придумала компания с таким же названием (DevOps Research and Assessment). Скорее всего, чтобы проще продавать свой консалтинг. В 2018-м году эту компанию купил Google Cloud и сделал своей... командой.

Вообще, про эти метрики в том или ином виде я знал. Но не знал, как они систематизированы и по-умному называются.

Собственно, сами метрики:

1) Частота деплоя (deployment frequency)

Показывает, насколько адекватный уровень автоматизированного тестирования. И умеет ли команда релизить точечно, а не сразу всё.

Критерии:

• отлично: несколько раз в день;

• хорошо: раз в 1-7 дней;

• средне: несколько раз в месяц;

• плохо: реже, чем раз в месяц.

2) Время от коммита до деплоя (Lead Time)

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

Критерии:

• отлично: меньше дня;

• хорошо: от 1-го до 7 дней;

• средне: 7-30 дней (*по оценке компании DORA, я бы сказал, что это плохой результат);

• плохо: дольше месяца.

3) % сбоев после релиза (Change Failure Rate)

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

Критерии (% релизов, которые привели к сбою):

• отлично: <5%;

• хорошо: <10%;

• средне: <15%;

• плохо: >15%.

4) Скорость восстановления (Mean Time To Recovery)

Показывает, как быстро мы поднимаем прод, если он сломался (упал, пришёл DDOS, выключились сервера). А ещё, умеем ли мы определять и измерять сбои. Упавшим продомом считается или факт того, что существенная часть системы недоступна, или коммит с hotfix'ом.

Критерии (как быстро поднимаем прод):

• отлично: меньше часа;

• хорошо: меньше дня;

• средне: меньше дня;

• плохо: больше дня.

Когда это нужно?

Для себя я выделил три критерия, когда эти метрики имеет смысл считать:

1. Когда есть конкретный продукт в активной стадии развития с постоянной командой хотя бы из 3-5 разработчиков. Т.е. это не что-то, что получает несколько фич в месяц или находится в стадии активного саппорта.

2. Когда компания большая, в которой появилось много команд с продуктами и нужно выстроить хоть какое-то понимание в среднем по компании. Вот тут, кстати, важно не начать погоню за метриками, т.к. все внутренние проекты живут в своём темпе. Нельзя выставить одинаковые метрики всем поголовно в качестве KPI.

3. Когда СТО\CIO нужны хоть какие-то метрики для отчётности. Чтобы объяснить инвесторам или нетехнической части C level'a, что в компании или команде хороший DevOps процесс (или, наоборот, плохой).

DORA метрики измеряются через GitLab или почти любую другую систему CI \ CD. GitLab умеет считать всё это из коробки. За исключением, наверное, падения прода (что тоже можно добавить вручную или вебхуками \ alert manager'ами).

---

Мой Telegram канал про разработку.
Мой open source проект для бекапа PostgreSQL - GitHub.

Квиз: насколько хорошо вы владеете Podman

Docker долго был самым популярным инструментом контейнеризации, но сейчас все больше сервисов переходит на Podman. Вы уже умеете работать с ним? Тогда проверьте свои знания базовых команд.

Пройти квиз

Не забудьте поделиться результатами в комментариях!

Практически каждый день я читаю и узнаю что-то новое про разработку. Решил начать вести посты в формате "Я узнал о... (какой-то факт)"

В краткой форме буду рассказывать о чем-то, что узнал за последнее время

---

Я узнал о... #1: FinOps

Задумка FinOps заключается в том, что мы начинаем считать расходы на DevOps и инфраструктуру в компании. Чтобы потом всё это счастье оптимизировать и сэкономить (в идеале, спрогнозировать расходы и риски).

Само название меня немного насмешило, потому что взяли "Ops" и добавили к нему другой префикс, чтобы выглядело солиднее

Стартапы очень любят таким же образом добавлять слово "Tech" ко всему подряд. Началось с EdTech и понеслось... AgroTech, FoodTech, PetTech, SleepTech, SexTech, HrTech.

Возвращаясь к сути: FinOps - это когда на уровне компании мы перманентно мониторим инфраструктуру, её загрузку и расходы, а затем ищем способы оптимизации.

McKinsey говорит, что от ~20% расходов на инфраструктуру в бигтехах уходят впустую. Следовательно, раз это нижняя планка, в среднем можно брать ~30%.

Например:

• сервера, которые взяли с запасом, и >50% ресурсов не используются (но оплачиваются);

• сервера для тестировщиков и стейджинга, которые мы купили и забыли про них;

• прожорливые сервера у проектов, которые не особо-то рентабельны (и стоит подумать уже об оптимизации кода).

Контроль делается за счёт того, что:

1. Мы начинаем в целом считать инфраструктуру, чтобы понимать, что в компании есть;

2. Затем мы начинаем мониторить утилизацию инфраструктуры, чтобы находить простаивающие ресурсы;

3. Каждый инстанс закрепляем за конкретной командой или человеком, чтобы посчитать ROI этой команды в контексте инфраструктуры.

Дополнительный бонус: CTO проще объяснить фин. директору, куда и зачем мы платим, и сколько примерно денег потребуется на следующий период.

Есть софт, чтобы считать инфраструктуру в гетерогенных облаках. Есть Kubecost, который умеет считать расходы в k8s. Есть разные опции в Terraform, чтобы считать стоимость инфраструктуры.

Даже есть подходы, когда инстанс нельзя использовать, пока не добавишь его в директорию всех инстансов компании. Но как это всё использовать - пока не вникал. Просто теперь знаю, что такие опции есть

Когда это нужно?

Пока расходы меньше $30к/мес. - должно хватать гугл-таблицы и зоркого взгляда CTO/DevOps'а. И дружеского вопроса команде: - "А зачем нам это?".

Когда расходы >$30к/мес. и оперативной памяти ответственного лица не хватает - можно начинать думать об автоматизации сбора метрик. Иначе до этого момента автоматическое сведение метрик воедино рискует просто не окупиться

---

Мой Telegram канал про разработку.
Мой open source проект для бекапа PostgreSQL - GitHub.

Новая версия Gramax!

Приглашаем вас протестировать экспериментальные функции:

• 💡  Статический сайт в облаке Gramax. Можно опубликовать свою документацию буквально за пару кликов, для этого не нужен сервер или хостинг. Достаточно нажать «Опубликовать в облако» и войти в почтовый аккаунт.

• 💡  Фильтр по содержимому. В каталоге можно создавать статьи и абзацы для разных сборок. На портале для чтения они будут фильтроваться с помощью переключателя. 

• 💡  Браузерная версия на мобильном. Браузерную версию Gramax можно использовать на мобильном телефоне. Доступны все действия, как при работе на компьютере.

А также:

• 📌  Новая главная страница. Улучшили внешний вид главной страницы. Добавили возможность создавать вложенные группы.

• 📌 Транскрипция речи с помощью ИИ. Если в пространстве включены ИИ-функции, редактор может автоматически транскрибировать аудиозаписи в текст.

• 📌 Просмотр изменений после синхронизации. После синхронизации автоматически открывается окно сравнения ревизий: сравнивается новая версия каталога с версией до синхронизации.
  

Об этих и других изменениях читайте в Release Notes 🔥

Вебинар "От кода до запуска: российский стек для Java — Axiom JDK и OpenIDE"

Приглашаем на вебинар, посвященный безопасному стеку базовых технологий для разработки и исполнения Java-приложений и безопасной среде разработке OpenIDE. Вы поймете, что такое OpenIDE, как это всё относится к Intellij IDEA, зачем OpenIDE бизнесу и какие у проекта OpenIDE планы на будущее.

Кому будет полезен вебинар:
• тимлидам
• разработчикам
• DevOps

Вебинар проведут:
• Дмитрий Сапожников, технологический консультант Axiom JDK
• Илья Сазонов, директор по продуктам Axiom JDK, направления Spring и OpenIDE

Когда: 21 августа 2025 г.

Во сколько: 11:00–12:30 по мск

Формат: Онлайн

Участие: Бесплатное (нужно предварительно зарегистрироваться)

Интеграция PVS-Studio в Inseq RBPO

Компания PVS-Studio и Inseq заключили технологическое партнёрство для обеспечения интеграции статического анализатора кода PVS-Studio в экосистему DevSecOps.

Программное обеспечение Inseq RBPO предназначено для создания и управления конфигурациями, необходимыми для автоматического развёртывания и настройки компонентов инфраструктуры безопасной разработки ПО — систем контроля версий, анализаторов кода, инструментов автоматизации сборки, тестирования и развёртывания. Управление конфигурациями и политиками безопасности осуществляется централизованно.

"ИНСЕК.РБПО" представляет собой клиент-серверную систему, работающую на локальном оборудовании. Она включает серверную часть, генерирующую конфигурационные файлы, и веб-приложение с графическим интерфейсом для взаимодействия с пользователями.

Внутри этой платформы стало возможным использовать статический анализатор PVS-Studio для поиска критических ошибок в исходном коде.

Также мы провели вебинар с коллегами из Inseq, в котором поговорили о необходимости регулярного статического анализа, а также в целом об автоматизации в РБПО.

DUC meetup #2: узлы кластера, платформа на DKP CE, контроль архитектуры

Если вы работаете с Kubernetes или планируете начать, приходите 21 августа на второй митап Deckhouse User Community в Москве. Будут доклады спикеров из «Фланта», «КРОК» и «ДОМ.РФ», а ещё пицца и пиво. Регистрация — по ссылке. 

Темы докладов и спикеры:

• От рассвета до заката, или Как Deckhouse Kubernetes Platform управляет жизненным циклом узлов кластера — Николай Митрофанов, «Флант»

• Разработка платформы для обучения K8s на основе DKP CE — Кирилл Харитонов, «КРОК»

• Архитектура под контролем: фиксируем изменения с помощью AaC и фитнес-функций — Антон Сафронов, «ДОМ.РФ Технологии»

Встречаемся 21 августа в «Событие Лофт» по адресу: Николоямская улица, 28. Ближайшая станция метро — «Таганская» Кольцевой линии. Программа стартует в 19:00, приходите чуть пораньше. Больше подробностей о докладах и регистрация — на страничке митапа. 

CSI-драйвер и Swordfish API: как заставить Kubernetes дружить с любым хранилищем

В современных enterprise-средах важно обеспечить стандартизированный доступ к системам хранения данных (СХД) от разных производителей, избегая жесткой привязки к конкретному вендору. Одним из решений этой задачи является использование CSI-драйвера, который взаимодействует с Swordfish API. Такая интеграция позволяет Kubernetes автоматически создавать, подключать и удалять тома, избавляя команды от множества ручных операций.

Процесс выглядит так: когда приложение в Kubernetes запрашивает постоянное хранилище, оркестратор формирует PersistentVolumeClaim (PVC) с нужными параметрами — размером, типом и характеристиками. Kubernetes определяет, что создание тома должно выполняться через CSI-драйвер, и передает запрос в эмулятор Swordfish API. Тот создает том, а в случае работы с файловыми системами (например, NFS) дополнительно настраивает подключение к серверу и возвращает CSI-драйверу сведения о готовом ресурсе.

Дальше Kubernetes связывает созданный том с заявкой PVC, после чего CSI-драйвер монтирует его на рабочий узел к нужному контейнеру или поду. Эмулятор Swordfish API при этом добавляет путь к каталогу в конфигурацию NFS (/etc/exports), что позволяет клиентам подключаться к сетевому хранилищу.

Когда хранилище больше не нужно:

• DevOps удаляет PVC.

• Kubernetes вызывает NodeUnpublishVolume для размонтирования тома с узла.

• CSI-драйвер передает команду Swordfish API.

• API удаляет том и освобождает ресурсы (в случае NFS — удаляет запись из /etc/exports и каталог).

• Kubernetes удаляет объект PV, завершая процесс.

Главное преимущество этого подхода в том, что он автоматизирует полный цикл работы с томами — от создания до удаления — и при этом одинаково хорошо работает с разными типами СХД, обеспечивая гибкость и снижение операционных затрат.

Если интересно, как самостоятельно разработать CSI-драйвер с поддержкой Swordfish API и запустить его даже без реального оборудования, то об этом — в статье, где пошагово показано, как реализовать и протестировать решение.

Интеграция PVS-Studio с Hexway

Компания PVS-Studio и платформа Hexway заключили технологическое партнёрство для обеспечения интеграции статического анализатора кода PVS-Studio в экосистему DevSecOps.

Hexway VamPy — это решение, агрегирующее данные о безопасности из разных источников для работы с уязвимостями.

В Hexway стало возможным загрузить результаты анализа PVS-Studio в виде отчёта и работать с конкретными ошибками так же, как это позволяют другие инструменты. Загрузка возможна двумя способами: через пользовательский интерфейс или командную строку с использованием CLI-инструментов.

Подробнее о том, как загрузить результаты анализа PVS-Studio в Hexway VamPy можно прочитать в соответствующем разделе нашей документации.

Привет, малюсенькое увеличение потенциала kui'я, добавил pv и pvc в список просмотра.

Творите, выдумывайте, пробуйте!)

Интеграция PVS-Studio c AppSecHub

Компания PVS-Studio и платформа AppSec.Hub заключили технологическое партнёрство для обеспечения интеграции статического анализатора кода PVS-Studio в экосистему DevSecOps.

AppSec.Hub — это платформа для автоматизации процессов Application Security, которая позволяет объединять различные инструменты анализа, тестирования и мониторинга безопасности приложений.

Отчёт анализатора PVS-Studio теперь можно загрузить для просмотра в платформу AppSecHub вручную с помощью пользовательского интерфейса инструмента либо с помощью специальной утилиты командной строки.

Подробнее о работе PVS-Studio в AppSec.Hub можно прочитать в посвящённом этому разделе документации.

Также мы провели вебинар с коллегами из AppSec Solutions, чтобы на практике показать, как инструменты работают вместе, а также поделиться полезным опытом в интеграции статического анализа в DevSecOps.

В последнюю пятницу июля в России, как и во всём мире, отмечается День системного администратора. Несколько лет назад на эту тему сложились стихи, которые до сих пор в открытых источниках не публиковались.

В эту пятницу привычно

Стул придвинет он к компу

Пусть всё кажется обычным,

Присмотритесь же к нему:

В джинсах, свитере неброском,

(Невзирая на июль)

Стильный, без излишков лоска,

Твёрдо держится за руль.

Он почти всегда в ударе,

В поле - воин, хоть один,

Он простой советский* парень**,

По профессии - админ

Ночь не спит в дежурной смене,

Утром чинит 1С,

Днём сетей рисует схемы,

Вечер - время сервис деск

"Файрвол", "маршрутизатор" -

Знает много умных слов,

Он прогрессор и новатор,

Накатить всегда готов

"Накатить" - релиз, конечно,

Здесь ci/cd, DevOps,

Пинги, tracert бесконечный,

Стойка в сотню терафлопс

Кубер, докер, AstraLinux

Windows, база SQL -

Все сомнения отринув,

В бубен бьёт, и точно в цель.

Вот бигдаты полный кластер,

Шарды, топики, бэкап -

Он над всем - незримый мастер,

Всё ИТ - в его руках.

Вам настроит сервер ловко,

И в hardware тоже крут:

Фен, утюг, микроволновку

Все чинить ему несут.

Антивирус, драйвер, почта,

Принтер, сканер, монитор,

"Очень важно", "суперсрочно"

"Почему пропал курсор?"

С датацентром связь наладит,

На заявки даст ответ,

И готов клиентов ради

Пропустить опять обед...

Всё как в высшем пилотаже.

Завтра - снова день такой.

Сисадмин стоит на страже.

Наш коллега. Наш герой. ❤️

* или российский, кому как по душе

** да, есть сисадмины девушки, но тут нужно было в рифму )

Быстрые сборки с функцией Rollback в Amvera Cloud

Ранее в Amvera Cloud, были возможны откаты только путём новой сборки из нужного коммита в Git-репозитории. Помимо этого, использовалась медленная технология сборки.

Мы ускорили сборки до 10 раз и сделали возможность быстрого отката к предыдущим версиям!

Стало легче откатывать приложение, в случае ошибок.

Подключить быстрые сборки можно в разделе проекта «Контроль версий».

Новые сборки

1. Быстрее старых до 10 раз.

2. Позволяют откатываться к предыдущим версиям одной кнопкой. Это полезно, если вы случайно накатили баг и надо вернуться к прошлой версии.

Amvera Cloud – облако для простого запуска проектов со встроенным CI/CD (деплой идёт через Git или загрузку файлов в интерфейсе), бесплатными https-доменами, мониторингом работы приложений, встроенным проксированием до ведущих LLM и собственным инференсом LLaMA.

Вам не нужно думать о настройке инфраструктуры. Git push amvera master и ваш проект запущен. Зарегистрируйтесь и получите 111 рублей на тест.