DevOps *

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

В Иви мы решили проверить это, подключив ИИ к процессу траблшутинга приложений, запущенных в Kubernetes кластере. В статье я расскажу про наши ожидания и достигнутый результат, подробно про саму реализацию и различные нюансы, с которыми столкнулись при внедрении.

В предыдущей статье я встроил команды для работы с веб-камерой в код сервиса робота, а также заменил Wi-Fi антенну на более крупную, чтобы повысить стабильность сигнала. Кроме того, я добавил поддержку управления с клавиатуры, чтобы сделать управление роботом более отзывчивым. В результате мне удалось успешно пройти полосу препятствий, управляя роботом и ориентируясь на изображение с веб-камеры.

В этом материале я создам Docker-контейнер для веб-приложения web-robot-control, который упростит и ускорит его запуск. Также я настрою GitHub Actions для сборки артефакта и его последующей автоматической отправки в Docker Hub.

Статья будет полезна веб-разработчикам, девопсам, которые интересуются созданием Docker-контейнеров и работой с Docker Hub.

Контейнер — не виртуальная машина. Между контейнером и хостом тонкая стена: общее ядро, общие ресурсы, минимальная изоляция по умолчанию. Стандартный docker run запускает процесс с root правами внутри контейнера и доступом к большинству системных вызовов.

Большинство команд оставляют дефолтные настройки, потому что «и так работает». Пока не приходят пентестеры или не случается инцидент. Разберём конкретные настройки, которые реально повышают безопасность, с примерами и объяснением зачем это нужно.

Всем привет! Меня зовут Рома, я DevOps в команде «Платформа» в Банки.ру.

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

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

Разработка AI-агентов сегодня — одна из самых «горячих» тем в IT. Кодинг-агенты уже оформились в отдельный класс продуктов с понятными лидерами: терминальные (Claude Code, Opencode) и IDE-ориентированные решения (Cursor, плагины для VS Code и т.д.).

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

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

Автоматизируем создание виртуальных машин в Proxmox с помощью Terraform: от подготовки единого образа и настройки провайдера до управления инфраструктурой как кодом и хранения state в GitLab.

Несколько месяцев назад я опубликовал статью про использование Outline для корпоративной базы знаний. Теперь хочу описать некоторые процессы подробнее.

Сегодня речь пойдет про основы создания такой базы знаний. Опишу кратко применение метода Event Storming, ревью структуры, регламент по ведению БЗ.

Тесты — это хорошо. Медленные тесты — это CI на 40 минут и разработчики, которые забывают их запускать локально. Разберём, как ускорить pytest от простого -n auto до распределённого запуска в Kubernetes.

Персистентные Tasks, субагенты на общем списке, зависимости между задачами — разбираем обновление и подводные камни.

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

Если в предыдущем эксперименте слои выглядели так:

В каждом офисе есть кладбище техники. У нас это были старые Mac mini — аккуратно сложенные, тихие, бесполезные. Когда-то на них работали, потом они перестали тянуть современные задачи, а дальше стандартный сценарий: «Давайте не выкидывать, вдруг пригодятся».

Как оказалось, пригодились.

Привет, Хабр! Меня зовут Николай, я занимаюсь выстраиванием инфраструктуры в web-продакшне RocketDev. В этой статье я расскажу, как дал вторую жизнь офисному железу и приспособил его для рабочих задач.

1. Что сделал?
Переехал с GitLab на свой сервер, написал свой python-скрипт, который мигрирует не просто все репозитории, но и настройки, описания, картинки(done) и мердж/пулл-реквесты(in-progress). Бонусом настроил простой git fetch/push одновременно на все GitLab, GitHub, ... remotes.

2. Зачем?
Локальный сервис независим от РКН, КВН, "чебурнета" и гео-блокировки аккаунта, бэкап под контролем, без опасения утечек из облаков по независящим причинам.

3. Как?
Когда у тебя несколько десятков pet-проектов на Gitlab/Github, для каждого копи-пастить git clone/push --mirror со многими параметрами и вручную копаться в web интерфейсах откровенно "скучно и лениво".

В статье: поиск решения по полной миграции, комментарии по коду и настройки скрипта. Вторую часть по мульти git fetch/push оформляю

Гуглил похожие решения, не нашел. В итоге написал свое.

Текст в ленте: Много лет индустрия информационной безопасности старается улучшить стандарты шифрования в сети двумя способами:

массовое распространение HTTPS как общего стандарта шифрования для всех сайтов — даже для тех, которым защита формально не требуется. Очень много времени было потрачено на то, чтобы убедить пользователей в важности тотального шифрования абсолютно всех коммуникаций;

сокращение сроков выдачи сертификатов SSL/TLS, чтобы стимулировать пользователей внедрять автоматические процедуры/скрипты для автопродления сертификатов, чтобы исключить «человеческий фактор» и забывчивость сисадминов, которые забывают менять сертификаты.

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

Я решил проверить следующий уровень — может ли ИИ не советовать, а выполнять действия сам.

В этом эксперименте ИИ:

управлял Yandex Cloud через yc

сам создавал ВМ и Managed PostgreSQL

сам подключался по SSH к ВМ

администрировал сервер

поднимал WordPress в Docker

и подключал его к базе, созданной в облаке

Без Terraform.
Без Ansible.
Без ручного выполнения команд человеком.

Это не туториал и не реклама.
Это практическое исследование второго уровня автономности ИИ, где агент реально работает в инфраструктуре, а человек остаётся в контуре управления.

Автоматизируете настройку Linux для embedded-разработки? Я собрал Ansible-коллекцию, которая за пару минут установит arm-none-eabi-gcc, J-Link, can-utils и драйверы PEAK CAN на любую машину. Больше никаких ручных команд и забытых зависимостей — всё одной кнопкой, с поддержкой CI/CD.

Всем привет, меня зовут Алексей Леонтьев, я техлид и архитектор на проекте Smartbot в компании KTS. Smartbot — это nocode-платформа для настройки сценариев чат-ботов, которые могут работать в нескольких соцсетях и мессенджерах одновременно.

Мы храним много данных о событиях, которые обрабатывает наша платформа. Раньше для этого мы использовали Postgres. Но возникла задача сократить потребляемые кластером ресурсы.

В этой статье я расскажу о том, как мы бесшовно перенесли данные из Postgres в ClickHouse. И при этом сократили оперативную память в 4 раза, а размер потребляемого дискового пространства — на порядок.

Представьте: вы работаете в крупной компании с федеральной сетью. У вас более 300 баз данных Microsoft SQL Server, сотни тысяч объектов — таблиц, процедур, функций, триггеров. Значительная часть бизнес-логики реализована с использованием cross-database references и распределённых запросов через linked servers, что создаёт сложные зависимости между объектами на разных базах и даже серверах.

А теперь представьте, что все изменения в схему вносятся напрямую в production — через SSMS, без версионирования, без ревью, без возможности отката.

Звучит как кошмар? Но именно так работала наша команда более 10 лет.
«Так исторически сложилось» — и это было нормой. Такой подход неизбежно порождал инциденты: от локальных нарушений целостности данных до масштабных простоев, напрямую влияющих на выручку и репутацию компании.

Мы поняли: нужно внедрять CI/CD. Но главная проблема оказалась не в технологиях — а в людях.

Для меня tmux - это не просто терминальный мультиплексор, это центр моей консоли: чтобы я не намеревался сделать - открытие новой панели будет моей стартовой точкой, особенно когда дело касается Kubernetes.

И вот однажды, в момент очередного использования kubectl config current-context появилась идея - "а не научить ли tmux показывать мой контекст?"

Так появился небольшой tmux-плагинчик, а так же сама эта статья, в которой я покажу и расскажу как это просто - написать плагин для tmux, надеюсь будет увлекательно.

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

Если верить вакансиям, DevOps — это человек-оркестр: он пишет пайплайны, чинит Kubernetes, настраивает облака, знает Linux на уровне ядра, умеет в безопасность, автоматизацию, мониторинг и, на всякий случай, может заменить бэкендера, когда тот ушёл в отпуск. Желательно за зарплату джуна и с готовностью выходить на алерты в три часа ночи. Реальность, к счастью, чуть менее драматична. Но и чуть более сложна, чем рассказывают на вводных курсах (привет тем, кто решился вкатится по быстрому). В этой статье разберёмся, кто такой DevOps на самом деле, почему от него действительно ждут «всего и сразу» и где заканчивается адекватное ожидание, и начинается фантазия работодателя.