DevOps *

В начале 2010-х в профессиональном сообществе разработчиков и архитекторов распределенных систем широко обсуждалась идея, что мир баз данных вступает в новую эру. На фоне успехов крупных интернет-сервисов термин BASE начал использоваться как противопоставление классическому ACID. Хайп вокруг NoSQL, CAP-теоремы и масштабируемых систем породил лозунги вроде «SQL умер», «ACID — для банков, а мы делаем веб», «eventual consistency — это нормально».

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

Что же произошло? Была ли «битва ACID и BASE» реальным технологическим разломом или лишь отражала ограничения своего времени? 

В этой статье мы разберём, как возникли ACID и BASE, почему BASE быстро стал популярен и что на самом деле означает тезис «победил ACID» в 2020-е годы.

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

Мы доверили ИИ первым реагировать на критические инциденты в продакшене. Это сократило время реакции, но одна его галлюцинация едва не отправила весь кластер в ребут...

История о том, как мы получили мощного, но странного стажёра, с которым нельзя оставаться наедине.

Меня зовут Дима Синявский, я SRE-инженер в Ви.Tech — это IT-дочка ВсеИнструменты.ру. В этот раз я решил помочь вам посмотреть на свою работу в отношении надежности. Особенно полезно будет тем, у кого официально нет SR-инженеров в штате.

"У нас нет SRE" – не значит "у нас нет надёжности". Даже без SRE-инженера ваша команда уже что-то делает для надёжности.

Покажу, как увидеть уже существующие у вас практики и понять, куда двигаться дальше.

Коллеги, всем привет!

Долгое время в нашей внутренней сети для обработки DNS-трафика мы использовали только BIND, и нам с ним было хорошо. Но в какой-то момент его возможностей перестало хватать. В статье расскажу, что именно с BIND не так и почему теперь весь DNS-трафик у нас проходит через DNSdist. И что это вообще такое...

Если вы используете nofailover: true (а многие так и делают), Patroni не синхронизирует слоты логической репликации — и при переходе на реплику часть данных может исчезнуть навсегда. Рассказываем, почему и как фиксить.

Одна команда — и Claude Code сам анализирует коммиты, определяет тип релиза, генерирует changelog, обновляет версии и пушит в GitHub. Разбираем внутрянку 1000-строчного bash-скрипта.

DevOps давно перестал быть просто набором инструментов или должностью, в которой достаточно знать только Docker. DevOps стал целой культурой, интегрирующей разработку и эксплуатацию, автоматизацию, мониторинг, качество и скорость поставки изменений. К 2026 году DevOps глубже сливается с платформенной инженерией, SRE-подходами и архитектурой облаков. Соответственно, требования к инженерам растут.

Что ожидают от DevOps-специалистов в 2026 году, какие навыки становятся важными и как построить карьеру от начинающего инженера к платформенному, — объясняем в статье.

Привет, Хабр! Меня зовут Андрей Басов, я руководитель команды технической поддержки стрима корпоративных продуктов и сервисов в MWS. Вместе со своими коллегами — Тимуром Хабибулиным (data scientist) и Рафисом Ганеевым (senior devops engineer) — занимаюсь технической поддержкой и сопровождением продуктов линейки Partner Experience Platform.

Чтобы улучшить качество наших сервисов, через которые МТС взаимодействует с партнерами, мы вынуждены постоянно внедрять новые решения, растить продукты и развивать их архитектуру, при этом нам важно обеспечивать надежность и стабильность работы ИТ-систем. Это не всегда дается легко, ведь объемы данных растут, и их нужно эффективно обрабатывать. Одной из основных проблем становится анализ логов — текстовых записей. В нашем случае они фиксируют события в работе систем, которые созданы за 25+ лет работы компании, а еще у них различные стеки и архитектурные подходы. 

Объемы данных настолько велики, что проанализировать вручную (например, в OpenSearch/Kibana) даже один продукт практически невозможно, иначе нам пришлось бы просматривать миллионы строк логов каждый день. Поэтому мы решили разработать систему, которая позволила бы автоматически выявлять в логах аномалии — события, не свойственные нормальному функционированию системы. Например, это могут быть следы багов, вызванных новыми релизами, или другие непредвиденные происшествия. Что из этого вышло — расскажу дальше. 

Меня зовут Дима Синявский, я SRE-инженер в Ви.Tech — это IT-дочка ВсеИнструменты.ру. Мы в своей компании давно используем vector.dev для обработки логов, о чем я рассказывал в предыдущих статьях (раз, два). Мне попалась интересная статья на английском языке о vector.dev и как можно сломать по-тихому незаметно для себя конвейер "правильными" данными и настройками. Представляю свое виденье этого материала.

Привет! Меня зовут Егор Сизов, в компании «Цифра» (дивизион Непрерывные производства) я руковожу направлением «Системы управления производством».

За этот год, среди прочего, я занимался двумя крупными проектами: организации сбора библиотеки готовых конфигураций и конвертацией конфигураций PI System в Платформу ZIIoT. 

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

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

Недавно мы с командой посчитали, сколько времени уходит только на то, чтобы найти информацию о задаче. Получилось около 8 часов в неделю на человека — это целый рабочий день, который тратится на переключение между Jira, Excel, почтой, Service Desk, GIT,  Confluence и ещё парой внутренних систем. При этом половина контекста всё равно теряется где-то между инструментами. Знакомо?

Плохая новость: проблема не в конкретном таск-трекере.

Хорошая: есть системный подход, который обкатан на реальных внедрениях — он опирается не на «ещё один инструмент», а на процессы.

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

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

Привет, Хабр! Я Виктор, в Хайстекс руковожу отделом разработки. Сегодня расскажу про фичу, которая снимает ложную дилемму «API или универсальность», потому что оба сценария можно применять параллельно.

При переносе виртуальных машин между облаками и частными контурами API-интеграция обычно даёт максимум автоматизации. Но как только целевых площадок становится больше одной-двух или появляется «собранная на коленке» платформа, выясняется, что у этой автоматизации есть цена. Миграция через API превращается в отдельный проект на недели разработки и тестирования. Этот пост — для инженеров и архитекторов, которые занимаются миграциями ВМ и упираются в стоимость и сроки поддержки API-интеграций под каждую новую целевую площадку.

Под катом — как сделать целевую сторону миграции воспроизводимой без зависимости от API конкретного облака и без ожидания поддержки со стороны платформы.

Решил я тут, что будет удобно иметь S3 бакет как диск в системе для всякого. Так как я плотно работаю с Yandex Cloud, то и использовать буду их бакет.

У них довольно щедрые тарифы и достаточно большие бесплатные лимиты.

Я сижу на Федоре. Для подключения бакета буду использовать GeeseFS - - высокопроизводительная файловая система S3 ( Яндекс , Amazon ), соответствующая стандарту POSIX и написанная на языке Go.

GeeseFS позволяет монтировать S3 бакет как файловую систему. Файловые системы FUSE на основе S3 обычно имеют проблемы с производительностью, особенно при работе с небольшими файлами и операциями с метаданными. GeeseFS пытается решить эти проблемы, используя агрессивный параллелизм и асинхронность.

Будет работать кстати и на винде.

Естественно нужно иметь аккаунт в яндекс облаке. У меня он есть. Создать новый не представляет сложности. Там ещё и грант 4000 рублей дадут. Поэтому переходим к делу.

В облаке нужно будет создать бакет. А так же статические ключи доступа.

Скачиваю бинарник https://github.com/yandex-cloud/geesefs/releases/latest/download/geesefs-linux-amd64. Кстати должна быть установлена ещё fuse, в федоре она предустановлена.

В профиль aws нужно добавить созданный ранее статический ключ доступа. Если вы не пользовались aws cli, то нужно создать файл ~/.aws/credentials, если пользовались то файл уже есть. В него нужно добавить профиль

Привет, Хабр! На связи Илья Антипов, разработчик Рег.облака в группе Рунити. В этой статье расскажу, как мы поднимали наш Terraform Registry для размещения Terraform-провайдера. Какие ограничения уперлись в официальный HashiCorp Registry, почему выбрали Terralist, как настроили авторизацию через Keycloak и автоматизировали сборку релизов с помощью GoReleaser — об этом подробно расскажу в статье.

Если вы когда-нибудь пытались собрать свой провайдер или поднять альтернативный registry, этот текст сэкономит вам несколько часов или даже дней. 

Shadow Data — данные, которые существуют вне поля зрения ИБ и compliance-команд. 

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

Сегодня официально выпустили новую версию Kubernetes — 1.35. Собрали обзор со всеми изменениями. Среди главных нововведений — возможность запускать поды с hostNetwork: true и hostUsers: false, групповое планирование подов и перевод контроллера маршрутов на watch-модель.

Если оглянуться на последние три года в российской IT-индустрии, становится ясно: мы пережили полноценную трансформацию. Процесс, который в обычных условиях занял бы лет пять-семь, сжался в 2-3 раза. Для многих это был болезненный, но продуктивный стресс-тест для всей экосистемы.

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

Итак, начнём!

Как и большинство компаний мы активно используем kubernetes, а поскольку находимся в Облаке, то для удобства перешли на management k8s. После полного переезда именно куб стал основной статьей расхода в биллинге Yandex Cloud. Поэтому стало актуально найти способ снизить стоимость без потери в производительности.