DevOps *

Как превратить десятки неструктурированных описаний участников сообщества в систему поиска

«Занимаюсь бэкендом лет 7, Go и Python, немного ML» — попробуйте найти среди двухсот таких описаний нужного человека. Руками — часы. Я автоматизировал это через гибрид LLM + детерминированного кода, и отловил все возможные проблемы.

Рассказываю про архитектуру, промпты и решения.

* На обложке — Архимболдо «Библиотекарь» (1566): из разрозненных книг складывается цельный образ. Как и профиль участника в системе

Если вы сейчас вкатываетесь в Linux на фоне хайпа вокруг DevOps и инфобеза — статья для вас.

Собрал в одном месте всё, что нужно знать о правах в Linux, простым и понятным языком: символьная и восьмеричная нотация, SUID/SGID/Sticky bit, SELinux-контекст, DAC, MAC, RBAC, ABAC, команды ls/stat/chmod/chown/find — с примерами и схемами, к которым легко вернуться.

Я расскажу, как реализовать локального LLM "Agent".

«Что вы получите:
— LLM, который индексирует ваш код и отвечает по контексту
— Генерацию и автоматическую вставку кода / тестов
— Полную работу без интернета и утечек данных
Показываю на примере IntelliJ IDEA, Ollama и Continue.»

Привет, Хабр!

Когда говорят про ИТ в строительстве, многие представляют довольно скромную картину: техподдержку, корпоративный сайт и пару интеграций с ERP. На практике всё давно выглядит иначе. Современный девелопер - это десятки цифровых продуктов: BIM-модели зданий, системы управления строительством, аналитические платформы, CRM, мобильные приложения жителей и даже собственные ИИ-платформы.

Меня зовут Саша. Я занимаюсь развитием операционной модели ИТ-департамента девелопера Sminex. Кстати, пару лет назад я уже писал на Хабре статью про работу системного аналитика 1С в девелопменте. Тогда речь шла о более узком срезе - роли специалиста внутри одного класса корпоративных систем и о том, как эти системы помогают бизнесу.

С тех пор моя роль внутри ИТ изменилась, и теперь я больше фокусируюсь на работе всей цифровой экосистемы компании. Поэтому хочу поговорить не про одну систему и одну роль, а про то, как вообще устроен PropTech на уровне всей ИТ-инфраструктуры девелопера.

В инфраструктуре почти не бывает задач «на один клик»: за деплоем тянутся CI/CD, за Kubernetes — эксплуатация, за нагрузкой — Nginx, Postgres, мониторинг и безопасность. В этом выпуске собрали материалы и ближайшие открытые уроки по тем темам, в которые чаще всего приходится погружаться уже на практике. Это хороший способ быстро разобраться в конкретной теме, посмотреть на рабочие подходы и понять, что стоит изучить уже системно.

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

За 2025-2026 годы произошло достаточно публичных инцидентов с AI, чтобы написать большую статью. И призвать всех, кто работает с AI-решениями, обращать внимание на безопасность.

Если коротко: После дефейса сайта нашего знакомого из-за утекшего пароля от админки мы поняли, что управлять доступами нетехнической команды (редакторы, SEO, подрядчики) через VPN или статические IP - это боль. Существующие proxy требовали рестартов и рулились конфигами. В итоге мы написали свой forward-proxy на Go, где доступ выдается токеном через расширение браузера, а правила (TTL, лимиты трафика, доступные домены) применяются на лету без разрыва соединений.

Я устал каждый раз гуглить одно и то же в nginx — и сделал инструмент, который объясняет конфиги на русском

Очередной генератор nginx-конфигов? Нет. Ну, почти нет.

20 000 заявок, тобрали меньше 2%. Я оказался в числе участников хакатона Anthropic, где инженеры компании в живом AMA рассказывали то, что не попадает в документацию.

Skills вместо агентов. Opus 4.7, который читает ваши инструкции настолько буквально, что ломает привычные workflow. Memory-слой поверх встроенного. Verification-паттерны для продакшена. И ещё 8 конкретных приёмов, которые я проверил на своих проектах.

Без воды, без “10 промптов для продуктивности”. Только то, что реально меняет работу с Claude Code.

Вышел Kubernetes 1.36 — релиз, который наконец-то закрывает старые боли админов и разработчиков. Больше не нужно пересобирать образы ради одного сигнала остановки: его теперь можно прописать прямо в манифесте. А «зомби-томы», которые висят мёртвым грузом и жрут место, стало легко находить по дате последнего использования. Собрали в статье разбор всех 68 изменений на русском языке.

Привет, Хабр. Меня зовут Алексей Постригайло. Двадцать с лишним лет я занимаюсь системной интеграцией и управлением проектами, сейчас — старший партнер одного крупного ИТ-интегратора. Здесь я рассказываю о технических и организационных подробностях наших проектов. 

Меня, признаться, удивило, что наш предыдущий рассказ — тот самый «больнючий» опыт про СТО — так неожиданно стал лидером по дочитыванию среди наших статей. Мы решили, что стоит продолжить кейсы с разными «граблями» и успехами, которые помогли нам научиться кодить лучше и строить процессы грамотно. Берите на вооружение полезное и не повторяйте наших ошибок. Поехали.

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

Я не популяризирую средства обхода блокировок, а рассказываю о техническом решении по настройки ОС в образовательных целях.

Эта статья — практическое руководство, основанное на реальном опыте настройки AmneziaWG на Debian 11, а именно такую версию ОС предлагает провайдер из "белого" списка.

Развитие цифровых сервисов, облачных платформ, распределённых корпоративных систем и API-инфраструктуры приводит к существенному усложнению задач обеспечения информационной безопасности. В современных условиях защита информации уже не может ограничиваться только периметровыми средствами, такими как межсетевые экраны и системы фильтрации трафика. Существенное значение приобретают механизмы идентификации субъектов доступа, централизованного управления правами, а также мониторинга и аудита действий пользователей и сервисов.

Одним из перспективных подходов к решению указанных задач является внедрение систем класса Identity and Access Management (IAM), обеспечивающих централизованную аутентификацию, авторизацию и управление учётными данными. Среди свободно распространяемых решений данного класса важное место занимает Keycloak - платформа с открытым исходным кодом, предназначенная для организации единого входа, федерации пользователей и управления доступом на основе стандартных протоколов безопасности.

Актуальность применения Keycloak обусловлена тем, что данная система позволяет унифицировать процессы аутентификации в гетерогенной ИТ-среде, обеспечить поддержку многофакторной аутентификации, интеграцию с LDAP/Active Directory, а также централизованное управление ролями и политиками доступа. При этом архитектурные особенности внедрения Keycloak требуют отдельного анализа, поскольку речь идёт о критически важном компоненте сетевой системы защиты информации.

Место Keycloak в архитектуре сетевой защиты информации

Утро: 3,8 ТБ памяти на кластеры Prometheus. Вечер: 0,6 ТБ. Между ними — переход на Deckhouse Prom++.

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

Вы слышали о Kafka, MQTT, S3, Iceberg, Trino, PostgreSQL, Redis и Flink? А насколько хорошо вы знаете эти технологии? По каждой из них написаны огромные книги («Kafka: The Definitive Guide», около 800 страниц), и каждый день выходят новые публикации про тонкости.

Эта статья про другое.

Вместо внутренностей движков и законов распределённых систем посмотрим на эти технологии как на кубики LEGO: какую роль каждая из них играет в архитектуре и как они стыкуются друг с другом. Это будет практический туториал: начнём с минимальной конфигурации и постепенно соберём сложную систему. Статью можно просто читать как обзор архитектуры, а можно запускать каждую конфигурацию и изучать её в деталях. Для этого достаточно Git, Git LFS и Docker Compose. Всё запускается в контейнерах. Даже примеры на Java собираются через Docker multi-stage build.

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

В FinOps эта ситуация — не метафора, а суровая реальность. Данные от облачных провайдеров доступны лишь в ограниченном окне (30–90 дней), а иногда и меньше. Если вы сначала обработали их, а потом поняли, что ошиблись, может так случиться, что перезапросить исходники уже не получится. 

В этой статье мы разберем два подхода к построению процессов обработки и преобразования данных — ETL и ELT — и докажем, почему для FinOps выбор ELT — это не просто вопрос производительности, а вопрос выживания исторических данных.

Привет, коллега! 👋 Если ты только начинаешь свой путь в мире контейнеров и оркестрации, эта статья — для тебя. Я постараюсь объяснить всё максимально просто, без заумных фраз и воды. Представь, что мы сидим на кухне с чашкой кофе, и я рассказываю тебе, как самому запустить Kubernetes и не запутаться в терминах.

Поехали!

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

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

Некоторое время назад я был участником команды, реализующей решение, на базе которого можно развернуть internal development platform. В первую очередь мы ориентировались на крупный enterprise с командами разработки от 150 человек, которым важны унификация, контроль, снижение когнитивной нагрузки на команды, безопасная разработка и т.д. Сегодня же хотел бы поделиться своими рассуждениями о платформах разработки немного под другим углом — не с учётом команд и процессов разработки (IDP всё-таки заточены в первую очередь решать проблемы в этой области), а с точки зрения зрелости самого разрабатываемого решения. 

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

Я технический лидер. Обычно моя работа не в том, чтобы писать код руками, а в том, чтобы запускать сложные hardware/software-проекты с нуля, собирать архитектуру, принимать ключевые технические решения, выстраивать команду и доводить систему до MVP в условиях неопределённости.

Я работаю на стыке механики, электроники, разработки и AI, связывая это в единый контур.

При этом я не владею языками программирования как разработчик.

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

Короткий ответ: да, можно.

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