DevOps *

Нагрузка на базы данных растет с каждым днем. Как быстро масштабировать ресурсы, расширять базы данных и следить за их состоянием в UI, не вникая в подкапотные движения Kubernetes? Приводим кейсы.

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

Год назад наша компания столкнулась с проблемой, знакомой многим крупным организациям. Разные команды, работая над похожими сервисами, каждый раз решали одни и те же задачи: настраивали CI/CD, поднимали окружения, интегрировали мониторинг и управляли зависимостями. В результате мы получили дублирование усилий, фрагментированность подходов и значительное замедление стартовой фазы проектов.

Платформа, как и правила дорожного движения, нужна для создания единого стандарта, который обеспечивает порядок, безопасность и удобство взаимодействия всех участников. Без неё возникает хаос: каждый действует по своим правилам, что приводит к конфликтам, рискам и неэффективности. Например, когда на дорогах появились ГИБДД, водители стали соблюдать правила только в присутствии инспекторов, а при их отсутствии часто позволяли себе нарушения. С внедрением автоматизации, таких как камеры контроля скорости и светофоры с датчиками, соблюдение правил стало постоянным, так как система работает всегда и везде, а не только «при виде инспектора». Это показывает, что платформа упрощает взаимодействие, делает его предсказуемым и позволяет легко адаптироваться к новым условиям, сохраняя баланс между старыми и новыми участниками системы.

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

На самом деле создать disaster recovery план — т.е. набор документов и инструкций, в которых указано, как именно восстанавливать сервис — не так сложно. Как это сделать, читайте в статье.

Я начал использовать Nginx более 20 лет назад, и как-то привык к тому что это решение по умолчанию при выборе веб сервера. В своем пути в IT я начинал с linux администрирования, потом был мелкий онлайн бизнес, работал бизнес аналитиком, продактом, временами что-то программировал для себя. Обстоятельства опять поменялись и год назад я устроился работать девопсом в маркетплейс доменов, по сути такой возврат к истокам. Первая задача которую мне выдали - перевести паркинг с 100к доменами с nginx на caddy. На тот момент я не слышал про Caddy, но был очень хорошего мнения о nginx. 

Я был удивлен, зачем?!
Что такого может быть в каком-то другом веб сервере, чего не умеет nginx? 

Я изучил нюансы, перевел паркинг на Caddy, и теперь могу уверенно заявить: да, у Caddy действительно есть очень сильные стороны. 

В этой статье я изложу кейс, нюансы, которые становятся важными когда у вас 100к клиентских доменов, на которых должен работать https. И какие тут есть преимущества у Caddy перед Nginx. На хабре есть всего несколько статей по Caddy, и это незаслужено мало для него. Поэтому я надеюсь из этого кейса вы сможете узнать что-то интересное.

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

В сообществе наделала шума свежая статья о том, каким мог бы быть Kubernetes, если бы его создавали с учётом всего, что мы знаем сейчас — почти десятилетие спустя после выхода версии 1.0. В ней DevOps-инженер Мэт Дугган предлагает заменить etcd и YAML (на HCL!), а также размышляет про новый пакетный менеджер вместо Helm и IPv6 по умолчанию. 

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

Привет, я Светлана Газизова, и, как несложно догадаться, я работаю в Positive Technologies. Занимаюсь я всяческим AppSec и всем, что к нему близко. Занимаюсь я этим серьезное количество времени — уже пятый год.

Сегодня хочу рассказать вам, насколько развитие AppSec и DevSecOps (да и вообще в целом практика безопасной разработки) похоже на то, как развивалось метро в Москве. Да‑да, именно метро!

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

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

Так что устраивайтесь поудобнее — сегодня у нас будет необычная экскурсия. С одной стороны — в мир безопасной разработки со всеми его AppSec'ами и DevSecOps'ами. С другой — в московское метро с его кольцами, диаметрами и постоянно растущей сетью станций. Готовы? Тогда поехали!

Как мы построили DevOps в локальном облаке без AWS и managed-сервисов: GitLab CI, Kubernetes, PostgreSQL, мониторинг на Prometheus и Grafana. 10 000 TPS в пике, 12 минут на деплой, 2 минуты на восстановление — и всё это в проде.

Привет, Хабр. В этом дайджесте мы собрали обучающие материалы по ИТ‑инфраструктуре — чтобы вы могли получить нужные знания точечно или системно и перенять лучшие практики от экспертов индустрии, так сказать, не отходя от станка. Без долгих предисловий, перейдём к делу.

Так ли нужно хранить 3 ТБ метрик за 180 дней? Устали от компромисса между детализацией мониторинга и размером storage?
В статье разберём, как разделить метрики на два независимых потока без Multi Retention из Enterprise-версии. Solution inside: простое, но эффективное решение с сохранением детализации для оперативного мониторинга и разумным использованием дискового пространства. Идём организовывать хранение сырых метрик на 30 дней и агрегированных — на 180!

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

Но есть способ лучше - автоматизация через Chocolatey и PowerShell. В этой статье разберём:

1. Как развернуть ПО на всех машинах за кратчайший срок;
2. Как создать собственные пакеты и управлять ими;
3. Как внедрить данное решение в вашу организацию.

Если вы системный администратор, DevOps, ИТ-инженер или специалист ТП - постараюсь помочь сэкономить вам десятки часов рутинной работы.

Всем привет, меня зовут Кирилл и я Android-разработчик в Scanny.

В прошлой статье, мы описали то, как будет выглядеть наш CI/CD, научились запускать статический анализатор кода, выполнять Unit-тестирование, собирать различные Build Flavors и отправлять их в нашу Telegram-группу.

В этой статье я покажу, как можно подключить и запустить Android-тесты в рамках CI/CD на примере Marathon Labs и Firebase Test Lab.

У нас были две сотни брокеров, шесть тысяч топиков, клиенты на четырех языках программирования, миллионы сообщений в секунду и целое море различных паттернов использования Kafka. А также жесткие требования по latency, тонна SLA и желание сделать гибкую систему аутентификации и авторизации для сервисов. Не то, чтобы все это было категорически необходимо для начала этой истории, но если уж начал рассказывать про асинхронные взаимодействия, то иди в этом до конца.

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

Если вам интересно распутать клубок асинхронного взаимодействия тысяч продюссеров и консьюмеров, узнать, где документация Kafka нас обманывает, а librdkafka и Confluent.Kafka не могут договориться, и как один потерянный пакет может привести к Permission denied, добро пожаловать под хабракат. Эта история для тех, кто догадался, что недостаточно было «просто включить флажок в конфиге».

Привет, Хабр! Меня зовут Виктор Корейша и я — руководитель направления Managed Services в Ozon. Я и моя команда, в том числе, отвечаем за всю инфраструктуру асинхронного взаимодействия между сервисами, которую строим на базе Kafka. А ещё я ведущий подкастов «Кода кода» и «Три тимлида заходят в бар».

Эта статья написана по мотивам моего доклада для DevOps Conf 2025. Расскажу нашу историю про внедрение авторизации и аутентификации в Kafka. Инженеры по эксплуатации найдут в ней обзор решений реализации SASL-сервера, разработчики — историю о конфликтах в production-ready клиентах, архитекторы — любопытные кейсы взаимодействия высоконагруженных систем, ну а менеджеры — эпос о внедрении технически сложных изменений в больших компаниях.

Хабр, привет! В этой статье расскажем, как команда банка ВТБ построила собственную аналитическую систему на базе открытых технологий и с использованием решений Arenadata. Мы рассмотрим архитектуру платформы, разберём её сильные и слабые стороны, а также заглянем «под капот» — покажем, как устроены процессы внутри банка и почему ВТБ решил идти своим путём, а не использовать готовые вендорские системы.

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

В этой статье мы рассмотрим, как расширение функционала K8s с помощью пользовательских ресурсов помогает решать инфраструктурные задачи, позволяя разработчикам быстро запускать и масштабировать сервисы без лишних хлопот. Однако с этим подходом приходят и свои проблемы, такие как ограничения в хранении больших объёмов данных. Разберемся, что стоит за этими вызовами, и почему HariKube — перспективное решение для эффективного распределения данных в Kubernetes.

Контейнеры падают, а вы узнаёте об этом постфактум? Ошибки в логах проходят мимо?

Собрал Rattle за три дня — простой self-hosted инструмент, который отправляет события из Docker в Telegram. Без лишних панелей, без сложной настройки — просто работает и сообщает о самом важном.

В статье рассказываю, зачем он мне понадобился, как устроен внутри и как можно быстро развернуть его у себя. Покажу Telegram Mini App, через которую удобно управлять уведомлениями.

📎 Ссылка на репозиторий: github.com/rattle-bot/rattle

Переход к SRE — это не просто внедрение новых инструментов, а целая культурная трансформация, которая ставит надежность в центр всех процессов. В этой статье мы разберемся, почему подход Site Reliability Engineering стал неотъемлемой частью современного IT, чем он отличается от DevOps и как его внедрение меняет подход к разработке и эксплуатации систем. Мы также коснемся ключевых вызовов, с которыми сталкиваются компании, пытаясь интегрировать SRE в свою работу, и объясним, почему без отказов и сбоев в реальном мире обойтись все равно не удастся.

Проектирование и поддержка высоконагруженной платформы для букмекерской конторы almsports.net потребовало особого подхода к обеспечению стабильности, отказоустойчивости и производительности. Мы, как команда разработчиков, ставили перед собой цель обеспечить не только стабильную работу, но и гибкость для масштабирования, отвечая на растущий трафик. В этом посте я поделюсь опытом того, как с использованием DevOps практик и CI/CD процессов мы смогли достичь 99.99% аптайма и эффективно обслуживать миллионы запросов в день на платформе almsports.

Когда микросервисов становится столько, что в них легко запутаться, а Prometheus уже не справляется с единой картиной мира, пора переходить на новый уровень observability.

Расскажу как именно я внедрял OpenTelemetry в своей инфраструктуре, с какими сложностями столкнулся и какие возможности открывает такой подход.

Спойлер: вышло хорошо

Привет, Хабр! Меня зовут Евгений Никулин, я – тимлид инженеров эксплуатации в К2 Cloud.

Пару месяцев назад меня позвали на онлайн-митап «Карьера в Линукс» – обсудить, как сейчас всё устроено: какие подходы используют компании, каких специалистов ценят и что помогает соискателям находить общий язык с работодателями.

Решил с вами поделиться самым важным оттуда. Полная запись, если что, есть на канале K2 Cloud Team – там же можно узнать, как мы с 2009 года строим облачную платформу собственной разработки.