DevOps *

В начале лета я опубликовал статью Маленькая утилита для контроля квот в Yandex Cloud и планировал добавить помимо контроля за квотами еще и подсчет стоимости добавляемых ресурсов.

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

runo — ассистент для репозиториев, который позволяет забыть о проблемах с настройкой локальной среды разработки и переключаться между репозиториями быстро и безболезненно. Больше не надо запоминать что, где и как можно/нужно запускать и что перед этим требуется сделать — обо всём позаботится ассистент.

Как защитить Kubernetes, если злоумышленник попытается выбраться из контейнера на хост? Рафаэль Натали предлагает многоуровневый подход: настройка Security Context, отказ от лишних прав, запуск контейнеров без root-доступа, а также усиление защиты с помощью AppArmor и seccomp.

Собираю собственный NAS сервер для хранения данных, обретения независимости от западных сервисов, а также ведения своих документов. В последние годы зависимость от облачных сервисов стала проблемой: компании в любой момент могут изменить условия использования или вовсе закрыть сервис (как это произошло с Notion например). Кроме того, платные подписки на хранилища и сервисы накапливаются, а контроль над своими данными теряется.

Подробный разбор сборки и настройки домашнего NAS: выбор SAS-дисков и контроллера, настройка ZFS-пула, установка TrueNAS SCALE, организация резервного копирования в S3 и запуск Docker-сервисов (Immich, Affine, Keycloak, Actual Budget). Небольшой гайд для тех, кто хочет построить своё хранилище и цифровую инфраструктуру под полным контролем.

Всем привет!

Недавно мы с приятелем обсуждали, как устроены рабочие процессы в бигтех-компаниях и какую роль в них уже играет ИИ. Речь в основном шла о зарубежных компаниях — у него там есть знакомые, которые делились опытом изнутри. Один из самых любопытных моментов — использование искусственного интеллекта для предварительного код-ревью в Pull Request: прежде чем коллеги возьмутся проверять изменения, PR уже анализирует ИИ и указывает на потенциальные проблемы.

Эта идея меня зацепила, и я решил изучить, какие готовые решения уже существуют (кроме встроенного в GitHub Copilot). Из более-менее крупных нашёл только PR Agent. Я протестировал его, но по ряду причин он мне не подошёл: хотелось больше гибкости, настройки под свои нужды и возможности запускать всё самостоятельно, без передачи кода сторонним сервисам.

Так родился проект ReVu — self-hosted инструмент для автоматического код-ревью в Pull Request с помощью ИИ. Он универсален, легко кастомизируется и не требует доверять исходный код внешним платформам.

Если вам интересны подобные материалы и проекты, подписывайтесь на Telegram-канал «Код на салфетке» — там я делюсь гайдами для новичков, историями разработки и полезными инструментами.

Чувствую себя комиком на стендап-концерте, но позвольте начать именно так, как это делают они. У всех же такое бывало, что в конце месяца приходит счет от облачного провайдера, а там сумма, от которой хочется сделать вид, что ты ее не видел? Причем чем меньше ваш бизнес, тем страшнее все это переживать. Это корпорации с миллионными ИТ-бюджетами могут позволить себе нанять целую свору финопсеров. А нужна ли вся эта канитель владельцам малого и среднего бизнеса?

Если вы работаете с мониторингом в Prometheus или VictoriaMetrics, то наверняка знаете, как алерты из Alertmanager могут быстро накапливаться, требуя ручного трекинга в Jira. А что если автоматизировать это полностью — с назначением исполнителей, метками, компонентами и даже шаблонами для описаний? Знакомьтесь с alertmanager-jira — классным инструментом для обеспечения интеграции Alertmanager (с Prometheus или VictoriaMetrics). Это Alertmanager (webhook) плагин, который создаёт и управляет задачами в Jira на основе алертов, с акцентом на гибкость. Написан на Quarkus, лёгкий и готов к деплою в docker (podman).

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

Привет, Хабр! 2 октября прошёл первый митап WIldberries & Russ по инфраструктуре. Обсудили всё самое интересное: от файловых хранилищ на экстремальных нагрузках до автоматизации репозиториев и философии DevOps. Делимся записями докладов.

Привет, друзья! Я Олег Васильев, владелец продукта Dream DE. В этой статье расскажу, как мы научились быстро и эффективно выводить витрины на Hadoop в эксплуатацию, или как мы за один квартал вывели 26 инициатив в рабочую среду силами четырёх инженеров по данным.

С каждым годом роль DevSecOps в обеспечении безопасной разработки ПО становится всё больше и больше. Масло в огонь подливает стремительное развитие ИИ. Больше не в моде письма от «нигерийских принцев» и многомиллионных выигрышах. На смену им пришли дипфейки, имитирующие голос, внешность и поведение звёзд, директоров
и других ЛПР. В этой и следующих своих статьях я расскажу, какие подходы для обеспечения безопасности мы, как DevSecOps, используем в CUSTIS.

С момента публикации предыдущей статистики прошел год и пора опять обновить данные, провести анализ по предложениям работы в сфере системного администрирования для планирования индексаций на 2026 год.

У нас уже есть статистика за 2022, 2023 и 2024 года, будем смотреть динамику изменений с ними, пока позволяет ширина таблиц на Habr.

Цели, условия, методика и формат анализа остались без изменений, их можно прочитать в предыдущих статьях или спойлером ниже. Данные по каждой должности сравним с предыдущими периодами по количеству вакансий и по заработным платам.

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

Де-факто стандартом мониторинга стал Prometheus. В статье мы разберёмся, всегда ли можно доверять информации, которую он предоставляет. Посмотрим, в каких случаях его данные не соответствуют реальности, и погрузимся в тонкости работы Lookback-delta, оконных функций и Federation API. В итоге вы глубже поймёте внутреннее устройство Prometheus и других систем мониторинга на базе TSDB и сможете корректно интерпретировать данные с учётом их особенностей.

ИИ перестраивает саму ткань разработки: ускоряет релизы, но множит баги, заставляет пересматривать тестирование и принципы командной работы. В 2025-м инженеры и лиды живут в двойственности — между стремительным ростом продуктивности и растущей ценой наблюдаемости, между автоматизацией и риском утраты человеческого взаимодействия. Новый отчёт InfoQ о культуре и методах разработки показывает: индустрия вступила в фазу, где платформенная инженерия становится наследником DevOps, а психологическая безопасность и умение работать малыми итерациями — вопросом выживания команд, а не модного тренда.

Привет, Хабр! В этой статье хочу рассказать об основных модулях нашего приложения для развертывания больших инфраструктур и киберполигонов на основе Ansible. Эти модули мы называем A-services (сокращенно от Ansible services). Они содержат все сценарии подготовки, развертывания и настройки ИТ-инфраструктуры.

Общая архитектура приложения на основе Ansible описана в предыдущей статье. Здесь хочу поделиться особенностями архитектуры модулей А-services.

Сегодня расскажу историю о том, как мы еще в 2017 году решили поменять инфраструктурную платформу. Мы расшифровали мой доклад с DevOpsConf21, много всего уточнили, переписали и дополнили с учетом опыта следующих четырех лет, прошедших после того выступления. 

8 лет назад у нас было 40 сред, 15 разработчиков, 2 монолита, 10 сервисов и свое железо в трех серверных стойках. С такими исходными данными мы решили перейти с Puppet на Ansible. Окружений много, потому что с 2010-го мы поставляли разработчикам и тестировщикам маленькие копии нашего приложения — это делало задачу еще интереснее.

Путь был непростой. О нем расскажу в хронологическом порядке, не забывая о косяках и ошибках. По ходу повествования я выделил инсайты, которые могли бы сильно помочь мне в прошлом. В конце оформил их в виде письма для себя образца 2017-го 🙂.  А если вы решитесь проделать нечто столь же безумное (ну там, не знаю, переехать с микросервисов на монолит, с linux на windows и так далее), надеюсь, мои заметки уберегут вас от сложностей, с которыми мы столкнулись.

Всем привет, с вами снова Смирнов Илья. Напомню, что я архитектор решений из Cloud.ru. На этот раз предлагаю погрузиться в тему мультикластеров. Сначала разберем, зачем они нужны и когда целесообразны — для тех, кто только начинает изучать вопрос. Ну и, конечно, детально разберем «что там по технике» — посмотрим, как создать рабочую мультикластерную инфраструктуру для одновременного и унифицированного управления приложениями, на какие подводные камни можно наткнуться и как расчистить себе этот путь.

Хватит спорить — пора запускать и сравнивать.

Тестируем реальные сценарии, измеряем RPS, смотрим на потребление памяти и разбираемся, когда самая разумная стратегия — это просто подождать и обновить Python на free-threading версию. 

Привет, Хабр! Меня зовут Игорь Анохин, я — руководитель платформенной разработки в K2 Cloud и более 8 лет программирую на Python. 

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

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

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

Мы с тобой, коллега — Системные Администраторы.
Не “инфраструктурные инженеры”, не “DevOps-практики”, не “cloud-специалисты”.

Просто — сисадмины.
Это звание не выдают по результатам онлайн-курсов и не прикрепляют в LinkedIn. Его зарабатывают в душных, перегретых серверных, где запах пыли вперемешку с озоном от ИБП становится запахом профессии. Где вместо open-space — кладовка с розеткой на три киловатта и проводами, похожими на гнездо безумного питона.

Наш путь — это не просто карьера. Это живая эволюция техники, прошедшая через наши руки и нервы: от скрежета SCSI-дисков и светящегося экрана CRT-монитора до кластеров Kubernetes, которые даже потрогать нельзя — всё спрятано в облаке.

Мы — свидетели и участники самой стремительной технологической трансформации последних двадцати пяти лет. Когда-то мы тянули первые «витухи» по потолкам советских зданий, пробивая стены перфоратором, потому что «завтра сдавать сеть в бухгалтерии».
Теперь мы нажимаем пару клавиш в Terraform и поднимаем целые дата-центры. А ведь тогда облаком мы называли сигаретный дым в серверной после ночного релиза.

Мы знаем, что такое физическая боль — тащить 4U сервер без тележки, спотыкаясь о кабель-канал, потому что «сейчас, только вот этот один, и домой». И что такое ментальная боль — когда забыл поставить setlocal enabledelayedexpansion, и кривой .bat-файл превратил NT-домен в цифровой ад.

Наш возраст измеряется не годами, а версиями операционных систем.
Мы взрослели вместе с Windows NT 4.0, Windows 2000, XP, Server 2003… потом 2008, 2012, 2016… А где-то между ними — Slackware, Debian Potato и FreeBSD 4.10, которые учили нас терпению, вниманию и вере в консоль.

Попробуйте как-нибудь чисто из спортивного интереса объяснить жене, почему в прошлом месяце ваш интернет стоил не 900 рублей, как обычно, а 90 000. Аттракцион, прямо скажем, диковатый, но примерно в таком же положении оказывается ваш ИТ-дир, когда видит счета от всех облачных сервисов одновременно. Что не так? Да примерно все. Каждый провайдер считает по своим правилам, выставляет счет в собственном формате, из-за чего объяснить, за что именно платим, оказывается просто супер-сложно. Но ведь не будешь складывать все яйца в одну корзину. Значит, нужно решать этот вопрос как-то по-другому.