Эгегей! Радость, kui снова подрос! Добавлена команда 'SSL update' для обновления сертификатов и ключей в секретах типа 'kubernetes.io/tls'. Как это работает?
Кладете в какую-нибудь папку новый сертификай, файл должен называться tls.crt и ключ с именем tls.key
Запускаете kui в этой папке, находите секрет с сертификатом который необходимо обновить
Обновляете через 'SSL update'
SSL update
Под капотом, обновление выполняется вот такой командой:
🎯 Что будет: ⚔️ Практический мастер‑класс по автоматизации безопасности 🐳 Развертываем уязвимую инфраструктуру в Docker 🛡 Пишем Ansible playbook для защиты 🏆 CTF‑соревнование — ищем флаги и закрываем уязвимости!
⏰ Формат: 2 часа интенсивной практики
💻 Что взять с собой: ноутбук и желание ломать/защищать системы
🚀 Программа: ✅ 5 реальных сервисов с уязвимостями ✅ Практика с nmap, hydra, curl ✅ Написание продвинутых Ansible playbooks ✅ Система очков и подсказок ✅ Живое общение и нетворкинг
👨💻 Ведущий я: Андрей Чуян DevOps-инженер, автор канала «IT‑волна»
SSP SOFT продолжает найм — ищем крутых ребят в команду 🔥
Кто мы такие и что делаем? SSP SOFT — это компания среднего бизнеса, наши направления: разработка заказного софта, IT-аутсорсинг выделенных команд и еще мы немного аутстафферы. Кандидатов ждут реальные, интересные проекты, прокачка скиллов и приятные бенефиты. Стараемся делом показывать, что для нас сотрудник — главная ценность. Минимум бюрократии, только рабочие процессы.
✅ Что мы предлагаем нашим будущим коллегам: — Интересные задачи, — Персонального наставника — мы позаботимся о твоем онбординге, — Центр компетенций — прокачивай свои скиллы без ограничений, — Свободу передвижения — работай откуда душа желает в РФ,(ино-локации обсуждаются), — Офисы для общительных — добро пожаловать в наши уютные пространства в Москве (офис в ЦАО) и в Томске. — Разумный Work-Life Balance — чтобы хватало сил и на работу, и на жизнь.
🎁 А еще: — Бонусная программа с «плюшками в рынке», — Обучение за наш счет — вкладываем в будущее, — ДМС с заботой о твоей улыбке (стоматология включена).
👉Если ты открыт для классной работы, топовых бонусов и профессионального роста — присылай резюме в ЛС нашему HR Lead Алине (https://t.me/AONikitina). Не забудь в сопроводительном или в начале переписки указать секретную фразу «Нашел(ла) вас на Хабре».
Управлять облачными расходами часто сложнее, чем кажется
FinOps Community Bot
Счета растут, бюджеты сложно прогнозировать, а прозрачности мало. Особенно это ощущают компании, где несколько команд используют разные облачные сервисы и никто не видит полной картины.
Чтобы помочь компаниям системнее подойти к FinOps, мы собрали FinOps Community Bot. Это Telegram-бот, который объединяет несколько инструментов:
Тест по FinOps. 9 вопросов за 5–7 минут. Бот рассчитает уровень зрелости вашей компании в управлении облачными затратами и подскажет следующие шаги.
База знаний. Подборка статей, инструкций и практических материалов по FinOps.
Календарь событий. Митапы, вебинары и конференции для специалистов и руководителей.
Закрытый чат. Возможность обсудить опыт с коллегами и задать вопросы сообществу.
Бот полезен для любых ролей: CEO увидит картину в целом, CFO получит идеи по оптимизации расходов, DevOps-инженеры и CTO — практические шаги для улучшения процессов.
Начать просто: пройдите тест, получите рекомендации и используйте остальные функции бота для глубокого погружения и обмена опытом.
Бессерверные вычисления: почему ваш код может стать заложником провайдера
Бессерверная архитектура обещает не думать об инфраструктуре, но скрывает риски vendor lock-in, которые проявятся слишком поздно. Пока вы наслаждаетесь отсутствием серверов, ваша бизнес-логика медленно превращается в заложника облачного провайдера.
Проблема:
Cold start в критичных приложениях достигает 10-15 секунд
Стоимость непредсказуема при скачках нагрузки
Локальная разработка и отладка превращаются в квест
Реальные кейсы:
python
# Проблема: разрыв между продакшеном и локальной средой
def lambda_handler(event, context):
# На локальной машине работает
# В AWS Lambda падает с таймаутом
return expensive_operation() # 25+ секунд
Что мониторим в бессерверной среде:
Performance
Холодные/горячие старты
Потребление памяти
Execution duration
Безопасность
Права IAM-ролей
Доступ к секретам
Цепочки вызовов функций
Экономика
Стоимость вызова
Количество параллельных исполнений
Использование сторонних сервисов
Когда бессервер оправдан:
Обработка событий с неравномерной нагрузкой
Фоновые задачи (генерация отчетов, ночные джобы)
API с низким RPS
Альтернативы:
Kubernetes + Knative — гибридный подход
Cloudflare Workers — edge-вычисления
Self-hosted FaaS — полный контроль
Вывод: Бессерверные технологии — мощный инструмент, но требуют тщательного проектирования и постоянного мониторинга затрат. Прежде чем погружаться в serverless, оцените, готовы ли вы к зависимости от вендора и непредсказуемым расходам.
Контейнеры не панацея: скрытые затраты на содержание 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-х. Уже сегодня нужно начинать тестирование и планирование, чтобы избежать хаотичной миграции под давлением регуляторов.
Уже проводили тесты с постквантовыми алгоритмами? Делитесь результатами в комментариях — соберем статистику по разным конфигурациям.
Привет, потенциал kui еще немного увеличился! Случилось то что случилось, в продской cronjoпеb'е что-то застряло. Добавил в kui ручной запуск кронжоб и kui'ем протолкнул застрявшее в кронжобе ...
Когда 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 для своих задач, сможет полностью перейти на локальный инференс. Хотя это, возможно, это только моя фантазия. Всем спасибо за прочтение.
