Контейнеры не панацея: скрытые затраты на содержание Kubernetes, о которых молчат вендоры
Kubernetes стал де-факто стандартом оркестрации, но за кадром остаются реальные эксплуатационные расходы. Когда стоимость обслуживания кластера превышает стоимость самих сервисов — пора пересматривать архитектурные решения.
Что не учитывают при внедрении:
Эффективность нод: В среднем 35-40% ресурсов простаивают "на всякий случай"
Стоимость сетей: Service mesh + CNI добавляют 15-20% к потреблению CPU
Трудозатраты: 1 инженер на 3-5 кластеров — утопия для средних компаний
Реальные метрики из практики:
bash
# Анализ утилизации за 3 месяца
kubectl top nodes | awk '{sum += $3} END {print "Средняя загрузка:", sum/NR "%"}'
# Результат: 41% по CPU, 28% по памяти
Где теряем деньги:
Overprovisioning "На всякий случай" развертываем на 200% больше ресурсов
Сложность мониторинга Требуется отдельный стек: Prometheus + Grafana + Alertmanager
Безопасность Pod Security Policies, network policies — +20% к времени развертывания
Когда Kubernetes оправдан:
50+ микросервисов
Непредсказуемая нагрузка
Команда из 3+ DevOps инженеров
Альтернативы для средних проектов:
Nomad — проще оркестратор без привязки к контейнерам
Docker Swarm — для простых сценариев
Managed k8s — если нет своей экспертизы
Вывод: Kubernetes — мощный инструмент, но не серебряная пуля. Прежде чем прыгать в эту экосистему, посчитайте TCO и убедитесь, что сложность управления не съест всю экономию от контейнеризации.
Записки параноика: почему Zero Trust — это не мода, а новая реальность для ИТ-инфраструктуры
Современные угрозы больше не останавливаются на периметре. Атаки стали целевыми, изощренными и часто исходят изнутри. Традиционный подход «замок и ров» безнадежно устарел.
Почему Zero Trust — это не просто buzzword:
68% компаний сталкивались с инцидентами внутренних угроз
Среднее время обнаружения нарушителя в сети — 207 дней
Традиционные VPN стали главным вектором атак в 2024
Как мы внедряли Zero Trust без переписывания всей инфраструктуры:
Post-Quantum Cryptography: тихая революция в инфраструктуре, которую нельзя игнорировать
Пока большинство обсуждает ИИ, в мире криптографии происходит настоящая революция. NIST утвердил первые стандарты постквантовой криптографии, и это потребует фундаментальных изменений в ИТ-инфраструктуре уже в ближайшие 2–3 года.
Проблема:
Современные алгоритмы (RSA, ECC) могут быть взломаны квантовыми компьютерами в обозримом будущем. Миграция на PQC — не вопрос «если», а вопрос «когда».
Что меняется:
Размер ключей увеличивается в 5-10 раз
Процессоры испытывают нагрузку на 30-50% выше
TLS-хендшейки становятся значительно объемнее
Наши тесты с OpenSSH 9.8:
bash
# Стандартный ключ Ed25519: 68 байт
# PQC-ключ Dilithium3: 1842 байта
# Рост трафика при подключении: ~2700%
Практические рекомендации:
Аудит инфраструктуры:
python
# Скрипт для поиска уязвимых сервисов
import ssl
for protocol in ['TLSv1.2', 'TLSv1.3']:
ctx = ssl.create_default_context()
ctx.set_ciphers(protocol)
Откладывание перехода на PQC аналогично игнорированию проблемы Y2K в 90-х. Уже сегодня нужно начинать тестирование и планирование, чтобы избежать хаотичной миграции под давлением регуляторов.
Уже проводили тесты с постквантовыми алгоритмами? Делитесь результатами в комментариях — соберем статистику по разным конфигурациям.
Когда TLS 1.3 ломает мониторинг: тонкая настройка под новые протоколы
С переходом на TLS 1.3 многие системы мониторинга внезапно "ослепли". Старые методы перехвата трафика перестали работать, а бизнес требует полной видимости. Разбираем, как адаптировать мониторинг под современные стандарты безопасности.
Проблема:
eSNI и Encrypted Client Hello шифруют метаданные подключения
PFS (Perfect Forward Secrecy) делает историческую расшифровку трафика невозможной
70% инструментов мониторинга показывают "encrypted traffic" вместо полезных метрик
Решение через eBPF:
bash
# Вместо SSL-инспекции - анализ системных вызовов
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_connect {
printf("%s → %s:%d\n", comm, args->uservaddr, args->port);
}'
Наша реализация:
Мониторинг на уровне ядра - eBPF-программы для анализа сокетов
Анализ временных метрик - latency между SYN и ACK без расшифровки содержимого
Косвенные метрики - количество новых соединений, размер передаваемых данных
Снизили время диагностики проблем с подключением с 25 до 3 минут
Соответствуем требованиям GDPR и PCI DSS (без декриптации трафика)
Вывод: Современный мониторинг требует смещения фокуса с инспекции содержимого на анализ метаданных и поведенческих паттернов. Безопасность и наблюдательность больше не противоречат друг другу.
Grafana: когда красивые графики становятся рабочим инструментом
Все мы видели скриншоты дашбордов Grafana с красочными графиками. Но когда красивая визуализация становится реальным инструментом мониторинга, а не просто картинкой для отчёта?
Проблема типового подхода:
Собираем все метрики подряд — «на всякий случай»
Создаём дашборды с 20+ графиками, где невозможно найти нужную информацию
- HTTP-коды ответов (1xx, 2xx, 3xx, 4xx, 5xx)
- Latency: p50, p95, p99
- Rate of errors (> 5%)
- SLO: доступность за последний час
4. Интеграция логов и трейсов: Теперь не просто видим, что latency вырос, а сразу находим причину в логах конкретного микросервиса.
Реальные результаты:
Время диагностики инцидентов сократилось с 40 до 8 минут
Количество ложных алертов уменьшили в 5 раз
Единая система вместо 3 разных инструментов мониторинга
Ошибки, которых стоит избегать:
Не создавайте дашборды «для галочки»
Настройте meaningful алерты, а не «disk usage > 90%»
Используйте единый стек данных (метрики + логи + трейсы)
Вывод: Grafana — это не про красивые графики, а про единое информационное пространство для принятия решений. Когда каждый инженер видит одну и ту же картину — проблемы решаются в разы быстрее.
А какие подходы к мониторингу используете вы? Делитесь кейсами в комментариях!
Когда мониторинг слепнет: почему 90% алертов — это ложные срабатывания и как с этим жить
Системы мониторинга должны помогать, но вместо этого часто создают информационный шум. Когда на каждый чих приходит алерт, админы просто перестают на них реагировать. И тут случается реальная проблема.
Проблема ложных срабатываний
📊 15% нагрузки на Zabbix/Prometheus — сбор и обработка бесполезных метрик
⏰ До 3 часов в день senior-инженеры тратят на фильтрацию алертов
🔕 68% инженеров признаются, что пропускали важные уведомления из-за "алертной усталости"
Почему это происходит
Мониторим всё подряд — собираем метрики "на всякий случай"
Неправильные пороги — одинаковые thresholds для dev и prod
Отсутствие бизнес-логики — система не понимает контекст сбоя
Решение: умный мониторинг
# Вместо этого:
alert: CPU > 90%
# Мониторим так:
alert:
condition: CPU > 90%
and LoadAverage > 5
and duration > 5m
and business_impact = true
Что внедрили у себя
Сезонные пороги — разные thresholds в рабочее/нерабочее время
Корреляцию событий — не алертим о высокой нагрузке, если это время бэкапов
Бизнес-метрики — мониторим не "доступность сервера", а "доступность оплаты"
Результаты через 3 месяца
✅ Снизили количество алертов в 7 раз
✅ 98% срабатываний требуют реакции
✅ Время реакции на реальные инциденты сократилось с 25 до 8 минут
Вывод Мониторинг должен говорить, когда бизнес теряет деньги, а не когда у сервера чихнул процессор. Лучше 10 точных алертов, чем 1000 мусорных.
А как у вас с алертами? Тоже тонете в ложных срабатываниях?
О скрипте: быстрая и безопасная оценка экспозиции устройств Cisco IOS/IOS XE, связанная с CVE-2025-20352 (подсистема SNMP).
Сканируем подсети на SNMP через onesixtyone с дефолтными сообществами. Парсим баннеры sysDescr.0 Python-скриптом: помечаем Cisco IOS/IOS XE и проставляем статус Fixed (если в белом списке) или Potentially Vulnerable (проверить в Cisco Software Checker).
Проект не эксплуатирует уязвимость. Он лишь определяет устройства, отвечающие на дефолтные SNMP-сообщества, и извлекает версию из sysDescr.0.
Подборка обучающих материалов по Docker и Kubernetes
Привет, Хабр! Сегодня пятница, поэтому я снова со своей нерегулярной подборкой полезных материалов для начинающих специалистов. На этот раз несу статьи о Docker и Kubernetes. Как обычно: все бесплатно, без регистрации и смс. Читайте и практикуйте.
Первые шаги в Kubernetes
Здесь 12 статей примерно на два часа чтения. Будет полезно, если нужно освоить базу: что такое K8s, какие задачи помогает решить, основные понятия, с чего начать, как работать с контейнерами и настроить мониторинг.
Docker с нуля: как работают контейнеры и зачем они нужны
Эта подборка из шести статей — ваш гид в мир контейнеризации. Вы узнаете, что такое Docker, как запускать контейнеры, собирать образы и использовать Docker Compose, а еще разберетесь, чем эта технология отличается от Kubernetes. Все материалы подкреплены практическими примерами и будут понятны начинающим. На полное изучение уйдет менее двух часов.
Основы безопасности в Docker-контейнерах
Если вы прочитали предыдущую подборку и почувствовали в себе силы начать работу с контейнерами, не спешите. Изоляция, которую они обеспечивают, может вызывать ложное чувство безопасности. Чтобы вы могли погрузиться в вопросы защиты своего Docker, есть еще одна мини-подборка из трех исчерпывающих материалов. Изучение — чуть больше часа, а эффект — бесценен.
Приглашаем на Infra Meetup от Wildberries & Russ! Расскажем про внутреннее файловое хранилище собственной разработки, поговорим о методах автоматизации репозиториев в Nexus, разберём существующие сервисы и процедуры их сопровождения, обеспечивающие бесперебойную работу. И обязательно затронем важнейшую тему культуры инженерного взаимодействия в команде.
В программе:
Файловое хранилище Wildberries: бескомпромиссный HighLoad | Иван Волков, CTO CDN
Как устроено одно из важнейших файловых хранилищ Wildberries
1,2+ млн RPS на выдачу фото и видео — и это не предел
Код Оккама: органический подход к разработке и процессам
Путь автоматизации репозиториев в Nexus | Владислав Раев, DevOps & DevTools Engineer
Автоматизация без стандартизации, или путь в никуда
Что работает для 10, может сломаться на 100
Меньше состояния — меньше проблем
Явное лучше неявного
У вас завелся сервис: рекомендации лучших сервисоводов (наверное) | Александр Стовбунский, Tools Team TechLead
«Пап, можно мы его оставим?» — почему приносят одни, а чиним мы
«А выгуливать кто будет?» — что может требовать тот, у кого нет права отказаться
«Он большим не вырастет!» — как считать трудозатраты и сроки
Вредные советы: как гарантировано всё испортить
Для участия в офлайне она обязательна. После докладов — продуктивный нетворкинг и афтерпати.
Мы создали графический установщик, который превращает развёртывание Deckhouse Kubernetes Platform в несколько кликов и упрощает начало использования платформы через веб-интерфейс.
На вебинаре 25 сентября технический директор веб-интерфейсов Deckhouse покажет live-демо Installer:
Развернёт полноценный кластер Deckhouse Kubernetes Platform за 10 минут.
Включит виртуализацию ещё за 10 — и запустит Doom на виртуальной машине.
Расскажет, какие проблемы установки закрывает Installer.
Покажет планы развития графического установщика и где его взять.
Привет всем хабровцам! Мы регулярно публикуем посты о наших вакансиях, включая 1С и DevOps.
Полный и актуальный список вакансий здесь: https://spb.hh.ru/employer/5648224. Но откликаться на портале хх необязательно — внизу дадим прямые контакты с нашим HR.
Рабочие места в офисах в Москве (топ локация в ЦАО у Красной площади) и в Томске, а также у нас много сотрудников, которые работают удаленно из разных регионов России. Формат «онлайн» или «оффлайн» обсуждаем.
Вот примеры вакансий 1С и девопс — остальные 20 штук на см. на хх.ру:
Из сегодняшнего. Давно уже напрашивается MCP registry. Появился MCP реджистри. Не знаю, насколько аудитория погружена, поэтому если нет, то я подробнее распишу
Model Context Protocol (MCP) — это не классическое API, а новый слой взаимодействия между LLM и источниками данных: вместо того чтобы самому писать запросы, интеграции и «велосипеды», бизнес просто подключает MCP-серверы, которые находятся у провайдеров данных. Провайдер отвечает за подготовку промптов, функций, агрегацию источников и поддержку версий, а компания получает централизованный доступ к данным и готовым описаниям. Важно: MCP разводит зоны ответственности — финансы за работу LLM остаются у вас, а ответственность за качество данных и промптов несёт провайдер; таким образом, вы оптимизируете бюджеты, снижаете риски и можете гибко строить оркестрацию (через LangChain или свои пайплайны) без затрат на «ручные» интеграции с контролем версий отпровайдера
Раньше каждая команда или компания искала MCP-сервера вручную, через частные списки или разрозненные каталоги, что замедляло внедрение и поддержку клиентов. Теперь MCP Registry выступает единым «источником правды», где можно быстро находить, подключать и проверять сервера
Думаю, что ближайший год-два мы будем наблюдать, как наровне с публичными АПИ, будут появляться публичные MCP для интеграций. Что уж там, они есть уже у 1С даже, хотя там нюансы, конечно
LLamaSwap - гибкая альтернатива Ollama Ollama — прекрасное приложение, основанное на llama.cpp, которым я пользовался для инференса локальных моделей до недавних пор, однако у него есть несколько критических недостатков:
Отсутствие поддержки всех GPU и BLAS, доступных в llama.cpp. Для меня это стало проблемой после перехода на Radeon RX 6800: инференс через Vulkan на llama.cpp работает быстрее и стабильнее, чем ROCm, но Ollama не поддерживает Vulkan.
Отсутствие тонкой настройки. Например, на момент написания статьи в Ollama нельзя выгружать часть MoE-слоев на CPU, что позволяет сильно увеличить скорость инференса при нехватке VRAM для загрузки всех слоев на GPU.
Ollama использует собственное хранилище моделей, несмотря на то, что под капотом работает с GGUF. Если загрузить модель с Hugging Face, Ollama всё равно скопирует её в своё хранилище, а модели в наше время весят не мало и занимают лишнее место на SSD.
Функции доступные в llama.cpp появляются в ollama с задержкой , а иногда и вовсе не появляются.
Мне нужна была альтернатива, способная динамически управлять загрузкой моделей в памяти через API без моего участия, как это делает Ollama, но без вышеперечисленных недостатков. В итоге я остановил выбор на проекте llama-swap.
Llama-Swap — приложение на Go, которое запускает несколько инстансов llama-server и проксирует запросы к ним по заданным правилам.
Плюсы по сравнению с Ollama:
Полный доступ ко всем возможностям llama-server (например --override-tensor для выгрузки MoE слоев на CPU).
Поддержка большего количества GPU кскорений (таких как Vulkan или даже связки Vulkan + CUDA)
Возможность настроить отдельную версию llama-server для каждой модели (если в будущих обновлениях что то сломается).
Более гибкая настройка правил загрузки/выгрузки моделей в память: (одновременная загрузка, поочередная по запросам).
Не дублирует модели на диске (если используются форматы поддерживаемые llama.cpp).
Из коробки есть WebUI для управления загрузкой/выгрузкой моделей.
Минусы:
Из коробки не работает, требуется настройка через config.yaml и наличие рабочего llama-server.
Проект молодой, и его дальнейшая судьба пока не ясна.
Основные пункты файла конфигурации
Список моделей с указанием их расположения и параметров запуска (влючая путь к llama-server).
Группировка моделей, к группам применяются правила загруpки/выгрузки из памяти: - Все модели в группе загружены одновременно. - Модели загружаются по мере поступления запросов
Различные настройки прокси, порты, таймауты и пр.
У меня мини-ПК с интегрированной Radeon 780m, 32 ГБ ОЗУ и eGPU RX 6800. Я полностью перешел на Llama-Swap + OpenWebUI и всё больше отказываюсь от использования онлайн-сервисов вроде OpenRouter — ведь возможностей моего недорогого, по современным меркам ПК, хватает для запуска, таких моделей как Gemma3 30B и Qwen3-Coder-30B-A3B-Instruct. Думаю, в скором времени, когда ПК с объёмами памяти от 64 ГБ и выше станут ещё дешевле, интегрированная графика — мощнее и на рынке окажется множетсво БУ GPU с объемом VRAM 16ГБ и выше, часть людей, использующих LLM для своих задач, сможет полностью перейти на локальный инференс. Хотя это, возможно, это только моя фантазия. Всем спасибо за прочтение.
Успеть за пять дней: отклик — интервью — оффер за пять дней для инженеров по безопасности
Надежные продукты начинаются с безопасного кода. Команда безопасности следит за уязвимостями, укрепляет процессы и поддерживает CI/CD в форме. И мы в YADRO укрепляем команду — ищем специалистов на позиции Application Security Engineer и DevSecOps. Принимаем заявки до 28 сентября.
Это вакансия на позицию инженера по безопасности приложений, который поможет создавать устойчивые к атакам продукты и внедрять лучшие практики SSDLC на всех этапах разработки. В этой роли вы будете:
проводить триаж уязвимостей, найденных с помощью SAST, SCA, Secret Detection и других инструментов;
оценивать защищенность продуктов на основе моделей угроз и выполнять специализированные тесты (fuzzing, сканирование портов и др.);
исследовать новые векторы атак и участвовать в тестировании на проникновение;
разрабатывать PoC решений для функций безопасности;
участвовать в выборе и внедрении инструментов тестирования.
Подать заявку и узнать больше о вакансии можно по ссылке →
DevSecOps / Infrastructure Engineer
Присоединяйтесь к нам в роли инженера, который будет развивать практики DevSecOps, совершенствовать подходы к безопасности инфраструктуры разработки и CI/CD, а также помогать командам интегрировать проверки безопасности в процессы. В этой роли вы будете:
внедрять и развивать DevSecOps-практики;
выявлять и устранять угрозы в инфраструктуре продуктов и CI/CD-процессах,
проектировать и внедрять безопасную архитектуру CI/CD;
обеспечивать стабильную работу инструментов SAST/SCA/DAST и создавать Quality Gates;
автоматизировать процессы с помощью GitLab CI, Ansible, Helm;
ставить задачи командам по улучшению безопасности и контролировать их выполнение.
Изучение Python может показаться сложным, но с правильным подходом и пониманием ключевых аспектов процесс станет понятным и увлекательным. Привет, я Иван Чернов, senior system architect, кратко расскажу, как начать вкатываться в Python, с какими проблемами сталкиваются новички и как их преодолеть.
Первые шаги
Определяемся с направлением, в котором вы хотите развиваться. Это может быть веб-разработка, машинное обучение, DevOps и т. д. Каждое направление требует своих знаний и навыков. Поэтому важно понять, что конкретно вам интересно и на какой позиции не будет скучно или слишком сложно.
Начните с изучения базовых понятий, таких как переменные, типы данных, структуры данных и функции. Это заложит фундамент для дальнейшего изучения.
Когда определились с направлением и изучили теорию — проходите курсы с практическим обучением или начинайте работать с кодом сами. Всегда лучше писать, чем читать. Как только вывели “Hello, World!”, переходите к обучающим программам, где первые задачки применимы к жизни. Например, на некоторых курсах учат разрабатывать Telegram-бота под ваши нужды. Это отличная практика для понимания процессов.
Также можете прочитать базу «Питона» — книгу “Automated Boring Stuff with Python”. В ней много практических задач, которые помогут вам освоить язык. А ещё есть полезный курс “Learning How to Learn”, который учит, как правильно учиться, опираясь на достижения нейронауки.
Этап, на котором новички отваливаются
При более глубоком изучении «Питона» новичок столкнётся с первой проблемой — настройкой инфраструктуры. На этом этапе многое пугает: установка редакторов кода, интерпретаторов, пакетных менеджеров и прочее. Даже опытные программисты каждый день ищут подходящие инструменты и пытаются освоить новые.
Чтобы облегчить старт, можно для начала научиться использовать онлайн-среду разработки, например Replit. Можно просто зайти на сайт, выбрать язык Python и сразу приступать к написанию кода.
Replit — это сервис для вайб-кодинга. В нём можно быстро экспериментировать с задачами и сразу видеть результат. Так вы сконцентрируетесь именно на изучении языка, а не на технических сложностях.
Тут есть большое «но»: на вайб-кодинге далеко не уедешь. Использование онлайн-сред — это чит-код, который облегчает старт, но не учит решать реальные проблемы. Так что с комплексной инфраструктурой всё же придётся разобраться.
Концептуальные вопросы
Отдельно стоит отметить концептуальные вопросы, которые могут возникнуть на старте. Новички часто сталкиваются с трудностями в понимании таких понятий, как переменные и функции.
Например, в Python переменная может принимать разные значения, что противоречит математическим представлениям. Это может привести к путанице и неправильному пониманию основ программирования.
Важно понимать, что программирование — это не только про то, как писать код, но и о то, как мыслит как программист. Необходимо развивать критическое мышление и осознавать, что многие концепции, которые мы учили на уроках математики, могут быть неверными в программировании.
Советы начинающим питонщикам
Постоянная практика. Пишите код каждый день, хотя бы немного. Работайте над проектами, которые вас интересуют, и решайте проблемы, которые вас раздражают. Я в 2010-м хотел, чтобы дома лампочка включалась по голосу. С помощью Python удалось сделать это.
Изучайте чужой код. Чтение и понимание чужого кода поможет вам увидеть, как другие решают задачи и какие подходы используют. Однако не стоит изучать рандомный код. Лучше ищите тот, что поможет улучшить ваши проекты.
Go sport, go team. Физическая активность способствует лучшему усвоению информации. Поэтому не забывайте делать перерывы и заниматься спортом.
Заключение
Определитесь с направлением, изучите теорию, но не медлите с практикой. Не пугайтесь сложностей инфраструктуры: всегда можно нагуглить или спросить на форумах. Пользуйтесь онлайн-средами, но не делайте большую ставку на вайб-кодинг. Не бойтесь начинать и ошибаться — и у вас всё получится.
Наступает осень, а значит и высокий сезон в IT. У нас больше 20 вакансий в командах аналитиков, девопсов, QA и разработчиков. Полный и актуальный список вакансий здесь: https://spb.hh.ru/employer/5648224. Но откликаться на хх необязательно — внизу дадим прямые контакты с нашим HR.
Напомним, кто мы: компания SSP SOFT занимается заказной разработкой и IT-аутсорсингом. Наши спецы помогают внешним клиентам реализовывать задачи в e-commerce, финтехе, медтехе, управлении инфраструктурой и других отраслях.
Рабочие места в офисах в Москве (топ локация в ЦАО) и в Томске, а также у нас много сотрудников, которые работают удаленно из разных регионов России. Формат «онлайн» или «оффлайн» обсуждаем.
Резюме на вакансии 1С, Elixir, Ruby, девопс и инфобез — рассмотрим в приоритетном порядке.
Data Scientist
DevOps-инженер
Data Scientist
DevOps-инженер
Сетевой инженер
Тестировщик 1C
QA Auto Java
Automation QA Engineer (Lead)
Elixir разработчик
Middle Java Developer
Ruby Developer
Jira Developer
С++ Developer (Senior)
Ведущий разработчик 1С (ERP, УХ)
Разработчик 1С (ЗУП)
Разработчик DWH
Аналитик DWH
Ведущий аналитик 1С ERP
Аналитик 1С (Управление недвижимостью и арендой)
Аналитик 1С (регламентированный учет)
Мы ценим сотрудников — работа без лишней бюрократии — акцент на задачи, которые приносят результат и развитие профессиональных навыков. 🎁 Наши бонусы: ДМС со стоматологией, обучение за счет компании, бонусная программа.
👉 В SSP SOFT мы рассматриваем найм с прицелом на долгосрочную совместную работу. Многие сотрудники у нас работают по 5 лет и более.
Data Sapience приглашает на онлайн-конференцию «Kolmogorov Online Day» ⚙️
Эксперты Data Sapience раскроют секреты эффективного управления жизненным циклом моделей и расскажут, как увеличить отдачу от ML-инвестиций.
Дата: 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-м инженер мог достать насекомое пинцетом и продолжить работу, то сегодня одна ошибка в коде способна обрушить бизнес-систему мирового масштаба.
И это, пожалуй, самое важное напоминание: в ИТ нет «мелких багов». Любая ошибка может стать той самой «молью», остановившей работу огромной машины.
Kubernetes — стандарт де-факто для оркестрации контейнеров. Но вместе с популярностью растут и риски. Ошибка в настройке кластера может стоить компании гораздо дороже, чем баг в коде. Как избежать подобных ошибок будем разбираться на бесплатном вебинаре «Проблемы безопасности в инфраструктуре Kubernetes».
📅 Дата: 26 августа 2025
⏰ Время: 16:00–17:00 (Мск)
В программе:
✔️ Культура DevSecOps и её связь с Kubernetes
✔️ Разбор реальных проблем безопасности
✔️ Поиск уязвимостей в инфраструктуре
✔️ Живая демонстрация
Вебинар будет интересен для разработчиков, тестировщиков, сисадминов и DevOps-инженеров.
💡 Если Kubernetes — часть вашей работы, этот эфир поможет избежать критических ошибок.
Компания PVS-Studio и платформа Securitm заключили технологическое партнёрство для обеспечения интеграции статического анализатора кода PVS-Studio в экосистему DevSecOps.
Облачный сервис и программное обеспечение SGRC Securitm позволяют построить управление информационной безопасностью на базе риск-ориентированного подхода и единой информационной модели компании.
Отчёт анализатора PVS-Studio стало возможным загрузить в Securitm для дальнейшего использования с помощью пользовательского интерфейса системы.
Подробнее о том, как загрузить отчёт анализатора PVS-Studio в систему Securitm можно прочитать в посвящённом этому разделе нашей документации.
Также мы с коллегами из Securitm провели совместный вебинар, на котором обсудили, как обеспечить соблюдение требований ГОСТ в области РБПО, а также показали реальные примеры использования PVS-Studio и Securitm.
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'ом.
Критерии (как быстро поднимаем прод):
отлично: меньше часа;
хорошо: меньше дня;
средне: меньше дня;
плохо: больше дня.
Когда это нужно?
Для себя я выделил три критерия, когда эти метрики имеет смысл считать:
Когда есть конкретный продукт в активной стадии развития с постоянной командой хотя бы из 3-5 разработчиков. Т.е. это не что-то, что получает несколько фич в месяц или находится в стадии активного саппорта.
Когда компания большая, в которой появилось много команд с продуктами и нужно выстроить хоть какое-то понимание в среднем по компании. Вот тут, кстати, важно не начать погоню за метриками, т.к. все внутренние проекты живут в своём темпе. Нельзя выставить одинаковые метрики всем поголовно в качестве KPI.
Когда СТО\CIO нужны хоть какие-то метрики для отчётности. Чтобы объяснить инвесторам или нетехнической части C level'a, что в компании или команде хороший DevOps процесс (или, наоборот, плохой).
DORA метрики измеряются через GitLab или почти любую другую систему CI \ CD. GitLab умеет считать всё это из коробки. За исключением, наверное, падения прода (что тоже можно добавить вручную или вебхуками \ alert manager'ами).
---
Мой Telegram канал про разработку. Мой open source проект для бекапа PostgreSQL - GitHub.
Docker долго был самым популярным инструментом контейнеризации, но сейчас все больше сервисов переходит на Podman. Вы уже умеете работать с ним? Тогда проверьте свои знания базовых команд.
Практически каждый день я читаю и узнаю что-то новое про разработку. Решил начать вести посты в формате "Я узнал о... (какой-то факт)"
В краткой форме буду рассказывать о чем-то, что узнал за последнее время
---
Я узнал о... #1: FinOps
Задумка FinOps заключается в том, что мы начинаем считать расходы на DevOps и инфраструктуру в компании. Чтобы потом всё это счастье оптимизировать и сэкономить (в идеале, спрогнозировать расходы и риски).
Само название меня немного насмешило, потому что взяли "Ops" и добавили к нему другой префикс, чтобы выглядело солиднее
Стартапы очень любят таким же образом добавлять слово "Tech" ко всему подряд. Началось с EdTech и понеслось... AgroTech, FoodTech, PetTech, SleepTech, SexTech, HrTech.
Возвращаясь к сути: FinOps - это когда на уровне компании мы перманентно мониторим инфраструктуру, её загрузку и расходы, а затем ищем способы оптимизации.
McKinsey говорит, что от ~20% расходов на инфраструктуру в бигтехах уходят впустую. Следовательно, раз это нижняя планка, в среднем можно брать ~30%.
Например:
сервера, которые взяли с запасом, и >50% ресурсов не используются (но оплачиваются);
сервера для тестировщиков и стейджинга, которые мы купили и забыли про них;
прожорливые сервера у проектов, которые не особо-то рентабельны (и стоит подумать уже об оптимизации кода).
Контроль делается за счёт того, что:
Мы начинаем в целом считать инфраструктуру, чтобы понимать, что в компании есть;
Затем мы начинаем мониторить утилизацию инфраструктуры, чтобы находить простаивающие ресурсы;
Каждый инстанс закрепляем за конкретной командой или человеком, чтобы посчитать ROI этой команды в контексте инфраструктуры.
Дополнительный бонус: CTO проще объяснить фин. директору, куда и зачем мы платим, и сколько примерно денег потребуется на следующий период.
Есть софт, чтобы считать инфраструктуру в гетерогенных облаках. Есть Kubecost, который умеет считать расходы в k8s. Есть разные опции в Terraform, чтобы считать стоимость инфраструктуры.
Даже есть подходы, когда инстанс нельзя использовать, пока не добавишь его в директорию всех инстансов компании. Но как это всё использовать - пока не вникал. Просто теперь знаю, что такие опции есть
Когда это нужно?
Пока расходы меньше $30к/мес. - должно хватать гугл-таблицы и зоркого взгляда CTO/DevOps'а. И дружеского вопроса команде: - "А зачем нам это?".
Когда расходы >$30к/мес. и оперативной памяти ответственного лица не хватает - можно начинать думать об автоматизации сбора метрик. Иначе до этого момента автоматическое сведение метрик воедино рискует просто не окупиться
---
Мой Telegram канал про разработку. Мой open source проект для бекапа PostgreSQL - GitHub.
💡 Статический сайт в облаке Gramax. Можно опубликовать свою документацию буквально за пару кликов, для этого не нужен сервер или хостинг. Достаточно нажать «Опубликовать в облако» и войти в почтовый аккаунт.
💡 Фильтр по содержимому. В каталоге можно создавать статьи и абзацы для разных сборок. На портале для чтения они будут фильтроваться с помощью переключателя.
💡 Браузерная версия на мобильном. Браузерную версию Gramax можно использовать на мобильном телефоне. Доступны все действия, как при работе на компьютере.
А также:
📌 Новая главная страница. Улучшили внешний вид главной страницы. Добавили возможность создавать вложенные группы.
📌 Транскрипция речи с помощью ИИ. Если в пространстве включены ИИ-функции, редактор может автоматически транскрибировать аудиозаписи в текст.
📌 Просмотр изменений после синхронизации. После синхронизации автоматически открывается окно сравнения ревизий: сравнивается новая версия каталога с версией до синхронизации.
Об этих и других изменениях читайте в Release Notes 🔥
Вебинар "От кода до запуска: российский стек для Java — Axiom JDK и OpenIDE"
Приглашаем на вебинар, посвященный безопасному стеку базовых технологий для разработки и исполнения Java-приложений и безопасной среде разработке OpenIDE. Вы поймете, что такое OpenIDE, как это всё относится к Intellij IDEA, зачем OpenIDE бизнесу и какие у проекта OpenIDE планы на будущее.
Кому будет полезен вебинар: • тимлидам • разработчикам • DevOps
Вебинар проведут: • Дмитрий Сапожников, технологический консультант Axiom JDK • Илья Сазонов, директор по продуктам Axiom JDK, направления Spring и OpenIDE
Компания 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 через CSI-драйвер и Swordfish API
Дальше 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 в экосистему DevSecOps.
Hexway VamPy — это решение, агрегирующее данные о безопасности из разных источников для работы с уязвимостями.
В Hexway стало возможным загрузить результаты анализа PVS-Studio в виде отчёта и работать с конкретными ошибками так же, как это позволяют другие инструменты. Загрузка возможна двумя способами: через пользовательский интерфейс или командную строку с использованием CLI-инструментов.
Подробнее о том, как загрузить результаты анализа PVS-Studio в Hexway VamPy можно прочитать в соответствующем разделе нашей документации.
Компания 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 тоже крут:
Фен, утюг, микроволновку
Все чинить ему несут.
Антивирус, драйвер, почта,
Принтер, сканер, монитор,
"Очень важно", "суперсрочно"
"Почему пропал курсор?"
С датацентром связь наладит,
На заявки даст ответ,
И готов клиентов ради
Пропустить опять обед...
Всё как в высшем пилотаже.
Завтра - снова день такой.
Сисадмин стоит на страже.
Наш коллега. Наш герой. ❤️
* или российский, кому как по душе
** да, есть сисадмины девушки, но тут нужно было в рифму )
Ранее в Amvera Cloud, были возможны откаты только путём новой сборки из нужного коммита в Git-репозитории. Помимо этого, использовалась медленная технология сборки.
Мы ускорили сборки до 10 раз и сделали возможность быстрого отката к предыдущим версиям!
Стало легче откатывать приложение, в случае ошибок.
Подключить быстрые сборки можно в разделе проекта «Контроль версий».
Интерфейс управления версиями сборок
Новые сборки
Быстрее старых до 10 раз.
Позволяют откатываться к предыдущим версиям одной кнопкой. Это полезно, если вы случайно накатили баг и надо вернуться к прошлой версии.
Amvera Cloud – облако для простого запуска проектов со встроенным CI/CD (деплой идёт через Git или загрузку файлов в интерфейсе), бесплатными https-доменами, мониторингом работы приложений, встроенным проксированием до ведущих LLM и собственным инференсом LLaMA.
Вам не нужно думать о настройке инфраструктуры. Git push amvera master и ваш проект запущен. Зарегистрируйтесь и получите 111 рублей на тест.
Как создать мультиаккаунт-ферму для любых целей: от TikTok до Amazon
Мультиаккаунтинг — основа множества задач: от продвижения в соцсетях и тестирования антифрод-систем до арбитража трафика, отзывов, заказов и автоматизации серых схем. Эта статья — техническое руководство по созданию собственной мультиаккаунт-фермы.
1. Зачем нужна мультиаккаунт-ферма
Массовое создание и управление аккаунтами востребовано в:
Vulnerability management — непрерывный процесс поиска, выявления и устранения уязвимостей. И это — один из ключевых аспектов в поддержании информационной безопасности всей IT-инфраструктуры 🔃
📆 Когда: 7 августа в 11:00 мск
📍 Где: онлайн
На вебинаре разберем ключевые методы защиты от киберугроз на уровне контейнеров и Kubernetes.
Что вы узнаете:
Как устроена безопасность в Kubernetes — архитектурные особенности и «подводные камни».
Типовые модели атак — кто и как чаще всего атакует контейнерные среды.
5 самых уязвимых компонентов системы контейнеризации — какие элементы требуют особого контроля и почему.
Лучшие практики защиты Kubernetes-контейнеров — от сканирования образов до политик безопасности.
Стратегии митигации киберрисков — как минимизировать угрозы до их реализации.
Присоединяйтесь, чтобы послушать про реальные кейсы и получить практические рекомендации по защите вашей инфраструктуры. А еще читайте статьи по теме:
Будет особенно полезно DevOps-инженерам, техническим лидерам, директорам по разработке, специалистам по кибербезопасности, а также всем, кого интересует тема безопасности Kubernetes.
Контейнеры для топ-менеджмента: способ увеличить прибыль или головная боль?
Многие компании уже давно используют контейнеры. Но все ли понимают, как на них переходить, а также какие последствия ждут бизнес, когда технология внедрена, но «готовить» ее никто не умеет? Как из-за отсутствия ресурсов этот бизнес может понести потери или вовсе встать? Или, наоборот, за счет правильного использования контейнеризации увеличить прибыль?
Уже были тысячи митапов и конференций, где мы обсуждали, как хороши контейнеры. Но бизнесу-то они зачем? Им вообще это надо?
22 июля (вторник) в 18:00 мск приглашаем вас присоединиться к жаркой дискуссии, на которой мы соберем топ-менеджеров крупных компаний — генеральных, технических и исполнительных директоров. Они расскажут, как они видят (и видят ли вообще) пользу от контейнеризации и как именно они ее оценивают.
