DevOps *

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Утром чинит 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 рублей на тест. 

Как создать мультиаккаунт-ферму для любых целей: от TikTok до Amazon

Мультиаккаунтинг — основа множества задач: от продвижения в соцсетях и тестирования антифрод-систем до арбитража трафика, отзывов, заказов и автоматизации серых схем. Эта статья — техническое руководство по созданию собственной мультиаккаунт-фермы.

1. Зачем нужна мультиаккаунт-ферма

Массовое создание и управление аккаунтами востребовано в:

• TikTok / Instagram / YouTube (SMM, продвижение, фарм, масслайкинг)

• Amazon / eBay / Etsy (отзывы, возвраты, seller support)

• Tinder / Badoo / Facebook (фарм профилей, трафик, лидогенерация)

• Финансовые сервисы (регистрация, чекапы, симуляция пользовательской активности)

2. Инфраструктура: из чего состоит ферма

Управляющий скрипт / панель

• Язык: Python + SQLite / Redis

• Задачи: управление профилями, логами, заданиями

Эмуляторы / браузеры

• Android: MEmu, LDPlayer, Anbox (Linux)

• Браузерные: Puppeteer, Playwright, Selenium, антидетект-браузеры (Dolphin{anty}, AdsPower, Incogniton)

Прокси-серверы

• Mobile / Residential — лучшее для trust-оценки

• Автоматическая ротация, логика GEO под задачу

Серверная часть

• VPS / VDS с Linux или Windows

• Docker-контейнеры под каждое окружение

• Балансировка нагрузки

3. Создание аккаунтов: подходы

Ручной полуавтомат (через Android-эмулятор)

• Эмуляция касаний (ADB, Auto.js)

• Работа через антидетект-образы

Полностью автоматический (браузер + API)

• Использование Playwright + обфускация fingerprint

• Капча-решатели: 2Captcha, CapMonster, hCaptcha API

4. Управление и автоматизация

• Отслеживание статуса аккаунта: валидация, блок, SMS

• Система задания задач (task scheduler)

• Импорт/экспорт сессий и cookies

• Telegram-бот для уведомлений

5. Масштабирование

• Запуск десятков сессий в docker-контейнерах

• Использование headless-режима с обходом защиты

• Съём логов и дебаг-интерфейсы

6. Безопасность и устойчивость

• Разделение трафика по подпроектам

• Автоматическое обновление fingerprint’ов

• Логирование и автоотключение забаненных узлов

• Мониторинг прокси и доступов

Пример архитектуры

[ Telegram Bot ] <- уведомления / команды
       |
[ Flask API ] <-> [ SQLite / Redis ]
       |
[ Управляющий скрипт ] -> [ Docker / Android VM ]
                                |
                         [ Браузер / Эмулятор ]
                                |
                            [ Прокси-сервер ]

Vulnerability management — непрерывный процесс поиска, выявления и устранения уязвимостей. И это — один из ключевых аспектов в поддержании информационной безопасности всей IT-инфраструктуры 🔃

📆 Когда: 7 августа в 11:00 мск

📍 Где: онлайн

На вебинаре разберем ключевые методы защиты от киберугроз на уровне контейнеров и Kubernetes.

Что вы узнаете:

• Как устроена безопасность в Kubernetes — архитектурные особенности и «подводные камни».

• Типовые модели атак — кто и как чаще всего атакует контейнерные среды.

• 5 самых уязвимых компонентов системы контейнеризации — какие элементы требуют особого контроля и почему.

• Лучшие практики защиты Kubernetes-контейнеров — от сканирования образов до политик безопасности.

• Стратегии митигации киберрисков — как минимизировать угрозы до их реализации.

Присоединяйтесь, чтобы послушать про реальные кейсы и получить практические рекомендации по защите вашей инфраструктуры. А еще читайте статьи по теме:

• Защищаем контейнеры от киберрисков: наш опыт и рекомендации

• Плагины безопасности спешат на помощь или как добиться тотальной доминации над уязвимостями контейнеров.

Будет особенно полезно DevOps-инженерам, техническим лидерам, директорам по разработке, специалистам по кибербезопасности, а также всем, кого интересует тема безопасности Kubernetes.

Зарегистрироваться 👈

Контейнеры для топ-менеджмента: способ увеличить прибыль или головная боль?

Многие компании уже давно используют контейнеры. Но все ли понимают, как на них переходить, а также какие последствия ждут бизнес, когда технология внедрена, но «готовить» ее никто не умеет? Как из-за отсутствия ресурсов этот бизнес может понести потери или вовсе встать? Или, наоборот, за счет правильного использования контейнеризации увеличить прибыль? 

Уже были тысячи митапов и конференций, где мы обсуждали, как хороши контейнеры. Но бизнесу-то они зачем? Им вообще это надо?

22 июля (вторник) в 18:00 мск приглашаем вас присоединиться к жаркой дискуссии, на которой мы соберем топ-менеджеров крупных компаний — генеральных, технических и исполнительных директоров. Они расскажут, как они видят (и видят ли вообще) пользу от контейнеризации и как именно они ее оценивают.

Ключевые вопросы эфира:

1.   Зачем это топам?

• Должны ли топы разбираться в технике?

• А что для них значат контейнеры?

• Драйверы для внедрения контейнеров и лидеры перемен.

• При чем тут импортозамещение.

2.   Процессы, деньги и люди

• Что меняли для внедрения контейнеров?

• Люди: раздутие штата, увольнения, обучение.

• Как бороться с сопротивлением?

• Долго ли длился переход и сколько он стоил?

3.   Итоги

• Что дало внедрение контейнеризации?

• Стоило ли оно того?

• А с точки зрения ROI и TCO?

• Метрики для оценки эффективности внедрения контейнеров.

Приглашенные эксперты:

• Максим Чудновский, исполнительный директор, «СберТех»

• Валерий Котелов, CEO, digital-интегратор KOTELOV

• Александр Буторин, CTO, «Дом.ру»

• Александр Токарев, СЕО, VoxysLab

• Дмитрий Зайцев, СТО, Flocktory

Модератор: Роман Ивлиев, CTO, программный директор TeamLead Conf.

Регистрация

🚀 Открой JupyterLab на PrimeWay и получи 4 бесплатных часа GPU каждый день

Зачем тебе пробовать:

• R&D без DevOps-рутины. JupyterLab с A100/A40 запускается из браузера за пару минут.

• Оплата только за runtime. Никаких idle-счётов или помесячных подписок.

• Стартовый грант 500 ₽ + дополнительно 4 ч / день после короткого опроса.

🙌 Помоги нам понять твою реальность

Ответь на 5 вопросов в комментариях или напиши в TG — и мы сразу активируем тебе +4 ч ежедневно:

1. Что сейчас гоняешь на GPU? (обучение, инференс, fine-tune, какие модели?)

2. Какая DevOps-задача бесит сильнее всего? (Docker, Kubernetes, autoscaling, логирование…)

3. Сколько времени или денег это у тебя отнимает в месяц?

4. Что тормозит внедрение новых инструментов для ML-инфры?

5. Если DevOps-боли исчезнут завтра, как изменится твой проект

💬 Пиши ответы здесь или сразу в Telegram:
— @PrimeWayio (чат команды)

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

Регистрация и грант → https://primeway.io/

Всем, привет!

Я основатель PrimeWay — сервиса для автоматического запуска и масштабирования ML-задач на GPU без DevOps-рутины. Сейчас мы общаемся с ml инженерами, CTO, data scientist's и другими специалистами, которые сталкиваются с проблемами в ML-инфраструктуре.

Я не хочу показывать продукт или что-то продавать — мы проводим серию коротких интервью (по 30 минут, можно и без созвона, просто текстом в telegram) с разработчиками, чтобы лучше понять их задачи и сложности.
Формат простой: 100% про ваши реальные проблемы и задачи.
Я задам 5 коротких вопросов, все ответы строго конфиденциальны.

Если готовы — напишите в тг, когда вам будет удобно

Заранее спасибо!
TG - https://t.me/WhiteRbbt
https://primeway.io/

NotCVE-2025-0003 и NotCVE-2025-0004

Продолжаю по мере сил пополнять базу проекта NotCVE информацией о проблемах безопасности, которым разработчики не желают присваивать CVE (делал заметку об этом проекте). В этот раз одна проблема в компиляторе Go привела к регистрации сразу 2-х записей:

• NotCVE-2025-0003

• NotCVE-2025-0004

Т.к. помимо самого компилятора Go, пострадал и Kubernetes:

The Go team has released a fix in Go versions 1.21.11 and 1.22.4 addressing a symlink race condition when using os.RemoveAll. The Kubernetes Security Response Committee received a report that this issue could be abused in Kubernetes to delete arbitrary directories on a Node with root permissions by a local non-root user with the same UID as the user in a Pod.

Из сообщения в гитхабе Kubernetes видно насколько заразительна тенденция вместо регистрации CVE называть фикс проблемы безопасности хардерингом:

The Go team has not issued a CVE for this, as it is considered a hardening issue, and the SRC is following that decision as well.

Собственно, в случае с Docker в этом году было то же самое, для них это тоже хардеринг (моё обращение в MITRE так и не привело к появлению CVE, поэтому я зарегистрировал NotCVE-2025-001).

Как видно, ситуации, когда проблемы безопасности не приводят к появлению CVE случаются не редко. А некоторые разработчики даже пытаются оспаривать назначение CVE.

Открыта регистрация на Kubernetes Community Day — главную сходку K8s-сообщества

31 июля в Москве состоится первая независимая конференция Kubernetes Community Day для открытого сообщества профи по куберу и тех, кто только начинает. Два пространства с техническими докладами, дискуссиями и хардкорными воркшопами, интерактивы и IT StandUp. Никаких HR-стендов и дорогих билетов — только бесплатное участие, сообщество, живое общение.

Цель мероприятия — создать площадку для объединения сообщества, обмена опытом и нетворкинга. В программе — актуальные выступления от коллег из различных компаний, которые дышат контейнерами: Yandex Cloud, ecom.tеch, VK, Luntry, МКБ, «Лаборатория Числитель», Lamoda Tech, Rebrain, Cloud ru и др.

Среди заявленных тем:

• «Legacy-кубы и как нежно увезти с них продукты»

• «Ретроспектива уязвимостей системных компонентов Kubernetes»

• «Блеск и нищета Cluster API Kubernetes»

• «Почему K8s — плохой продукт и он вам не нужен?»

• «Как мы переизобрели UI для Kubernetes: динамический фронт на основе OpenAPI и CRD».

Полная программа будет объявлена позже.

Зачем идти?

• Послушать истории коллег про реальные кейсы, факапы и «боли». 

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

• Встретиться со старыми друзьями и найти новых.

• Внести свой вклад в сообщество.

Формат: офлайн и онлайн.

Участие бесплатное. Количество мест на офлайн ограничено площадкой — успейте зарегистрироваться!

Следите за анонсами мероприятия в Telegram-канале генерального партнера конференции — платформы «Штурвал».

Информационные партнеры: Computerra, ICT Online, Cybermedia, Global Digital Space, AM Live, ict2go, Kubernetes_ru, DevOps For Love, IT STAND.

Карма vs Инженерная честность: Почему рейтинги убивают экспертизу

Есть в инженерной культуре наивная вера: если система имеет метрики и правила - она безусловно и по умолчанию объективна. Карма на Хабре тому идеальный контрпример. Формально всё честно: пост → оценка → рейтинг. На практике же это цифровой аналог пассивно-агрессивного "не зашло". Без объяснений. Без контекста.

Социальная инженерия вместо экспертной оценки

Главный парадокс: чтобы выжить, ты должен угадывать не истину, а ожидания аудитории. Тон, формат, табу. Это краш-тест на конформизм:

Написал, что 80% мониторинга в проде — это фейковый SLO? → Минус ("негатив").
Сказал, что ChatGPT пишет ТЗ лучше джуна? → Минус ("ересь").
Осмелился быть лаконичным без смайликов? → Минус ("агрессия").

Почему так? Потому что карма измеряет не глубину мысли, а комфорт восприятия. Инженерная точность = высокомерие. Прямолинейность = токсичность. Даже если за этим — годы практики и статистика.

Карма как инструмент подавления инакомыслия

Самое циничное на мой взгляд, найдутся и оппоненты, несомненно, это - непрозрачность. Минус прилетает анонимно, без мандата на критику. И неважно, что твой вклад в тему - как у топ-комментатора. Система молчит, а ты получаешь ярлык "ненадёжного".

Итог:
Действительно качественные и экспертные умы, готовые спорить и рушить догмы, — уходят.
Остаются те, кто мастерски жонглирует банальностями в дружелюбной обёртке. Звучит довольно резко, соглашусь. Но иначе не донести усть мысли.
Платформа медленно превращается в клуб взаимного одобрения.

Что делать?

1. Игнорировать карму как погрешность системы (но тогда зачем она?).

2. Требовать мандат для минусов ("Укажи причину: факт ошибка/оффтоп/токсичность"). Хотя у кого тут истребуешь - не нравится, двери на кнопке "выйти".

3. Ввести верифицированную карму - например, чисто теоретически, только от пользователей с 100+ постами в профильных хабах.

Пока же мы имеем соцсеть, где алгоритмическая справедливость проигрывает человеческой... нетерпимости.

P.S. Этот текст - эксперимент. Проверим, сколько стоит сказать: "Император голый". За инженерную честность - не жалко.
P.P.S. Карма — временна. Культура дискуссии — вечна.

Можно ли развернуть кластер Kubernetes на процессоре с открытой архитектурой RISC-V?

Короткий ответ: нет.

К сожалению, на данный момент «классический» K8s неполноценно портирован на RISC-V. Один из необходимых модулей K8s — kubelet — отказался запускаться на RISC-V-машине (в роли нее — микрокомпьютер Lichee Pi 4A).

Зато облегченная версия оркестратора K3s и Docker Swarm заработали на RISC-V, но с разными компромиссами:

→ Docker Swarm проще в развертывании.

→ K3s — более гибкий в работе, так как поддерживает Kubernetes-инструменты.

В синтетических тестах (stress-ng) K3s показал лучшую производительность на матричных вычислениях — он обошел показатели Docker Swarm примерно в 16 раз. В цифрах: 2.996 bogo ops/s (K3s) против 188 bogo ops/s (Docker Swarm). Возможно, это связано с оптимизацией Kubernetes или меньшими накладными расходами: K3s потребляет меньше ресурсов на фоновые процессы, такие как управление кластером и сетью, что важно для маломощных устройств.

Интересно узнать больше? Тогда переходите по ссылке и читайте подробности экспертимента по заапуску известных оркестраторов на RISC-V.

Добавили поддержку российских ОС в Open Source-платформе Deckhouse Kubernetes Platform

Хабр, мы кратко. В нашей Open Source-платформе Deckhouse Kubernetes Platform (DKP CE) появилась поддержка отечественных операционных систем. Изменения смержены в версии 1.69. 

Теперь в качестве ОС для узлов поддерживаются:

• Astra Linux;

• ALT Linux;

• РЕД ОС;

• РОСА Сервер.

Напомним — если у вас есть вопросы и обратная связь по DKP CE, их можно принести в наше Telegram-сообщество для инженеров. 

Сегодня 24 июня до 23.59 успейте принять участие в главном DevOps-исследовании года!

Это last call по исследованию состояния DevOps 2025 в России, проводимого компанией «Экспресс 42» при поддержке Axiom JDK. Оно закрывается сегодня ночью в 00.00 по мск.

Помогите отследить тренды и понять, как опыт разработчиков (DX) влияет на эффективность команд и успех компании. Фокус State of DevOps Russia 2025 на developer experience. 

Осталось всего несколько часов — пройдите опрос до 23.59.

Мы вместе изучим, что помогает компаниям формировать позитивный опыт для разработчиков и как на него влияют внутренние платформы, ML/AI-инструменты, облачные технологии и практики ИБ.

Опрос анонимный и займёт ~20 минут. Данные нужны, чтобы понять, какие инструменты реально работают в проде, а какие — только в красивых презентациях.

Все участники получат:

• Полный доступ к результатам исследования;

• Возможность выиграть билеты на Highload++ и DevOpsConf.

• Промокоды и мерч от партнёров (AvitoTech, VK Cloud, Positive Technologies, Selectel, ecomtech, Okko, Онтико, Т-Технологии,  Axiom JDK, Экспресс 42).

Участвуйте сегодня и голос вашей команды будет услышан. Чем больше ответов — тем лучше получится карта DevOps-практик в России.

Почитать предыдущие отчёты можно тут

PS. А у кого есть интерес заняться девопсом в команде Axiom JKD, загляните сюда.

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

Я пришёл из Яндекса
Я строил облака
Я знаю, как делать лидоген

А потом ты открываешь план, который он накатал, и читаешь:
Надо срочно повысить охваты и сделать event-маркетинг в партнёрстве с департаментом госсектора. Занавес.
Это даже не ахинея. Это скриншот из какой-то методички 2010 года.

Кто ты, воин?
Формально - новоявленный руководитель блока продаж и маркетинга.
По факту - всего навсего бывший аккаунт-директор. До этого вообще специалист по ИБ в системных интеграторах.

Он искренне считает, что понимает рынок.
Он не знает, кто покупает облака. Он не знает, зачем их покупают.
Он путает капексы с опексами. У него в голове до сих пор есть'облако' как магическое слово, которое должно продавать себя само. А если не продаёт — значит, виноват кто? Конечно, маркетинг.

Проблема даже не в нём
Люди не обязаны быть идеальными. Бывают разные.
Проблема в механике: его сюда спустили.
Он не вырос, не понял, не прошёл путь. Его просто назначили.

Сходу в кресло, сразу - с правом финального слова.
А ты теперь объясняй, почему твой roadmap не просто слайд. Почему у тебя нет 'горизонтальных альянсов'. Почему ты не пишешь статьи от имени продована по цифровой трансформации.

Идеи от него сыпятся каждый день
Давайте срочно делать холодные звонки
Нам нужно охватить весь SMB. Конечно, инфраструктуру же как пирожки на базаре продают.
Где у нас продажи через Telegram?'

Ты сначала смеёшься. Потом объясняешь. Потом просто перестаёшь говорить. Потому что бесполезно.

Он не слышит - он управляет. Или думает, что управляет.

Чем всё закончится?
Ты либо уйдёшь.
Либо адаптируешься.
Либо станешь таким же.

А он? Он - останется. Потому что его назвали Начальником начальника. Потому что кто-то где-то решил, что у него 'видение'. Потому что резюме с Яндекс.Облаком, казалось бы, всё ещё производит впечатление на тех, кто никогда туда не заглядывал.

Вывод?
Парашюты должны раскрываться до касания земли.
Иначе потом мы просто собираем обломки и делаем вид, что это было управляемое приземление.

Вы знаете этих людей. Вроде умные, вроде опытные. Говорят правильные слова про 'стратегию', 'масштабируемость', 'долгосрочную перспективу'.
Но почему-то через полгода таких разговоров оказывается, что:

баг, который 'уже почти пофиксили' никуда из прода не девался
фича, которую 'вот-вот запустим' — всё ещё в черновиках
команда уже тихо ненавидит слово 'архитектура'

А техлид? Техлид как будто ничего не замечает.
Как это работает (точнее, не работает)
Слова вместо кода

вместо пулл-реквестов - диаграммы.
демо нет - зато вот вам слайды.
вместо решений 'опять' 'давайте обсудим' (читай: 'я не хочу отвечать').

Бесконечный 'анализ'

'Надо подумать над архитектурой' = 'Я не уверен, но боюсь признаться'
'Это нетривиальная задача' = 'Мне лень разбираться'

Ответственность - это не про нас
Любимый приём - щедро размазать вину:

'Это комплексная проблема' (на самом деле: 'виноваты все, а значит — никто').

Реальный кейс (чтобы было не абстрактно)

В одном проекте (Node.js, если важно) техлид 2 месяца 'прорабатывал подход' к рефакторингу.
Провёл 8 митингов, написал 50 страниц документации.

А потом... уволился.

Оставив после себя:
красивые схемы в Confluence
ни одной строчки кода
команду, которая теперь на рефакторинг смотреть не может

Как понять, что ваш техлид центральная часть системы самообмана?

главный результат его работы - не код, а презентации
коронный вопрос - 'А как мы это будем масштабировать?' (но не сам масштабирует)
после разговора с ним хочется или закодить, или закопать

Что прикажете с этим делать?

тупо запретить 'стратегировать' без кода*
нет пулл-реквеста - нет права говорить про архитектуру.

ввести 'день испанского стыда'
раз в месяц техлид показывает руками, что сделал. Не слайды - код.

Задавать всего один вопрос

'Что конкретно изменится после твоего решения?'
Если ответ начинается со слов 'теоретически....' - это тревога.

Вывод
Хороший техлид — не тот, кто красиво говорит о проблемах.
А тот, кто их решает.

Если ваш 'архитектор' только генерирует документы, но не генерирует код - возможно, он уже ИИ.

P.S. Если после этого текста кто-то узнал своего техлида - это не совпадение

Подключайтесь к трансляции митапа для инженеров и сисадминов

Сегодня на SelectOS OpenFix Day обсуждаем лучшие практики работы с Open Source, вспоминаем свои инженерные факапы и разбираемся с нестандартными инфраструктурными задачами. Начало трансляции в 18:30 (мск).

Программа

• Rust в ядре — прогресс или костыль в бронзе? Живая дискуссия про разный опыт работы с этим языком программирования.

• Как справиться с инфраструктурным хаосом: вредные советы.

• Честные истории о том, как падал и поднимался прод.

Ждем всех, кто не просто использует Linux, а вникает в код, фиксирует баги и патчит уязвимости. 

Смотреть трансляцию:

📱на YouTube

📱в VK

Как DevOps-инженеру сэкономить часы работы и избежать ошибок с помощью AI-инструментов 

Воркшоп с Виктором Чаплыгиным, Senior Engineer в международном GameDev холдинге.

Что будет на воркшопе:

Теория: кратко о том, как работают LLM в контексте разработки и эксплуатации. Обзор инструментов:

• Cursor IDE — AI-интегрированная IDE с поддержкой кода и терминала;

• PSP/PSS Baseline — стандарты безопасности Kubernetes.

Практика:

• Настройка Cursor IDE — подготовка среды для продуктивной работы с AI;

• Создание и отладка IaC (Kubernetes YAML, Terraform) с помощью AI-ассистентов: выявление и исправление ошибок;

• Генерация понятной и структурированной документации к проектам с помощью AI;

• Разбор реальных кейсов и работа с командной строкой: исправление, пояснение, улучшение команд и манифестов.

А ещё — личный опыт и лучшие практики применения GPT-ассистентов для повседневных DevOps-задач, от написания инфраструктуры до исправления ошибок и генерации документации.

Когда: 5 июля 2025 года

Узнать подробности и занять место на воркшопе — через бота.

Батл мнений: «Ванильный» K8s VS коммерческие решения: когда стоит платить?

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

В прямом эфире вместе с AM Live собрали представителей топовых компаний: «Авито», Почта Банк, beeline cloud, АЛРОСА ИТ, RWB Media.

Они рассказали, какой подход используют внутри и почему именно его, с какими сложностями сталкиваются и какая команда эксплуатирует и поддерживает контейнерную платформу.

Смотрите запись эфира на удобной для вас платформе:

VK | YouTube | RUTUBE

🚨 У кого в РФ проекты на CloudFlare перестали работать. РКН заблокировал ECH [SNI].

Чтобы исправить:

Зайдите в настройки SSL/TLS на панели Cloudflare.

На платном тарифе:

• В разделе "Edge Certificates" найдите "Encrypted ClientHello (ECH)" и выберите "Disabled", если хотите отключить шифрование.

На бесплатном тарифе:

• Поставить Minimum TLS Version = 1.2

• Отключить TLS 1.3

OpenRedirect в IBM Instana (NotCVE-2025-0002)

Instana - платформа для мониторинга приложений и инфраструктуры. Эту особенность я нашёл пару месяцев назад совершенно случайно. Забавно, что год назад на собеседовании я не смог ответить на вопрос: что такое OpenRedirect (описан в CWE-601) - растерялся. А сейчас вот сам нашёл. Проблема довольно тривиальна: с помощью специально сформированной ссылки можно заставить браузер жертвы выполнить произвольный GET-запрос. Жертва должна быть авторизована в Instana. Пример ссылки:

https://instana.com/auth/signIn?returlUrl=https%3A%2F%2Fsite.com%2Fchangepassword%3Fuser%3Dadmin%26newpassword%3Dtest

На рисунке ниже виден результат перехода по подобной ссылке: сервер отвечает кодом 302 и через location перенаправляет пользователя на нужный ресурс.

Изначально я пытался зарегистрировать CVE. Продукт Instana принадлежит IBM. А IBM является CNA партнёром MITRE (подробнее про CNA). Т.е. для регистрации CVE нужно обращаться не к MITRE, а к IBM напрямую. Что я и сделал. Ответ от IBM был таков:

We need to see more impact beyond phishing. If you are able to chain this issue with further exploitation (ex: token theft, xss bypass, SSRF, etc…) then please let us know. You will see that other vulnerability programs (example: google) take a similar stance on open redirects.

We recommend taking a look at the following external resources for further information on open redirect issues we would be interested in addressing:

• https://www.youtube.com/watch?v=84nYxHwbCpU

• https://blog.detectify.com/industry-insights/the-real-impact-of-an-open-redirect/

We thank you for your efforts in helping keep IBM products secure. Please reference any further communication related to this issue via your original HackeOne ticket so we can better track this finding.

Нежелание признавать уязвимость со стороны разработчиков - не такая уж и редкость. В моей практике бывало, что разработчики даже пытались оспаривать CVE. Я решил вместо дальнейших исследований по повышению импакта обратиться в NotCVE - сервис как раз для подобных случаев (делал об этом сервисе заметку). Тем более уже был опыт взаимодействия с ними. И буквально через пару дней получил ответ, что уязвимости назначен идентификатор NotCVE-2025-0002.

Проблема замечена в версии User interface v1.293.809 + Backend Tag v3.293.425-0. В этой версии проблемы нет: User interface Tag 1.267.675 + Backend Tag 3.267.347-0