Latest posts
Happy Devops — сообщество адекватных инженеров
28 Nov 2025, 07:26
⚡ Совместный карьерный митап от Звук и self, сообщества для поддержки айтишников. Как строить карьеру в турбулентные времена и экономический кризис📌 Время и место 🔴30 ноября, с 15:00 до 21:00 🔴Poklonka Place, корпус Е1 Поклонная ул. 3📌 Можно подробнее? Можно! Митап состоит из четырех частей:1️⃣Серафима Чекулаева, Руководитель продуктов, ex-VK Музыка, Тинькофф, Яндекс; CEO self и карьерный ментор, расскажет, как выжить на рынке труда, который не беспокоит ваше выживание 💰2️⃣Дальше – Карьерный форум с 12 экспертами из разных IT-направлений: teamlead, frontend, backend, ML&analytics, productПри покупке билета в боте
Happy Devops — сообщество адекватных инженеров
29 May 2025, 08:13
forwarded from @proitfest
🔥 База знаний тимлида: как въехать в процессы быстро и безболезненно! Подкаст Виктор Корейша и Андрея Синицыны.Секция: Hype Кому будет полезно: ➖Тимлидам, которые недавно вошли в новую команду или готовятся к переходу ➖ Инженерам, у которых всё держится в голове и пора с этим что-то делать ➖ Всем, кто хочет структурировать знания о людях и технологиях, не теряя в темпе✅ О чем? Как собирать и систематизировать знания в удобных инструментах (например, Obsidian), чтобы понимать, как всё работает — от кода до коммуникаций.⬇ Что вас ждет? ➖ Рекомендации по ведению личной базы знаний ➖ Как фиксировать не только техпроцессы, но и “социальную архитектуру” команды ➖ Инструменты и лайфхаки для заметок, которые реально работают ➖ Обсуждение Obsidian и подходов к организации данных👀 Кто спике
Happy Devops — сообщество адекватных инженеров
16 Apr 2025, 11:24
forwarded from @monhousetech
Дорогие друзья, уже на следующей неделе, 23 апреля в Амфитеатре Санкт-Петербургского конгресс-центра Ленполиграфмаш состоится очередной [ Big Monitoring Meetup ] 12!Программа посвящена мониторингу и включает доклады по тематикам разработки, связи, менеджменту. BMM - площадка, где встречаются профессионалы и энтузиасты отрасли, чтобы обсудить современные тренды, обменяться опытом и найти новые решения для актуальных задач.Нетворкинг, дружеская атмосфера, способствующая открытому общению и обмену знаниями. Одной из главных ценностей нашей конференции является возможность установить прямой контакт между разработчиками и пользователями.Встречайте докладчиков двенадцатой конференции:Презентация "3D визуализация в мониторинге: модный тренд или рабочий инструмент?" — Андрей Никифоров. Генеральный директор [ ООО «ТРИТВИН» ]Дискаверинг и мониторинг сетевого оборудования в системе
Happy Devops — сообщество адекватных инженеров
28 Mar 2025, 07:19
Eventual Consistency: когда доступность важнее мгновенной согласованностиEventual consistency — модель согласованности, ставшая фундаментом современных распределённых систем. Ключевая идея проста: система гарантирует, что при отсутствии новых обновлений все реплики со временем придут к согласованному состоянию.В отличие от strong consistency, модель работает асинхронно. Узел может подтвердить запись до синхронизации с остальными репликами. Изменения распространяются по системе постепенно, создавая окно времени, когда разные клиенты могут видеть разные версии данных.Техническая реализация включает векторные часы, конфликт-резолверы и gossiping-протоколы для эффективного распространения изменений. Решение конфликтов обычно строится на принципе "последняя запись побеждает" или через более сложные механизмы слияния.Яркий пример — DNS-система. Когда меняется запись, обновления
Happy Devops — сообщество адекватных инженеров
26 Mar 2025, 11:52
forwarded from @devopsconfchannel
Гонка за новым функционалом не должна превращать систему в «хрупкого гиганта». SRE-практики помогают определить «точку невозврата» и выстроить процессы поддержки SLA. Если вы хотите научиться проектировать устойчивые системы и оберегать их от неожиданных падений, секция «Reliability Engineering» будет для вас незаменима.Вторая часть докладов секции ⤵️, первая здесь1) Blameless culture. Как правильно работать с инцидентами. Андрей Синицын (Ozon)Принцип старой школы: «у любой проблемы есть имя и фамилия». Слышали? Может, сами практикуете или бывали такими именем и фамилией? Из доклада вы узнаете, почему культура без обвинений более эффективна, почему это не про всепрощение и расслабон и как запустить такой подход у себя.2) Как жить, когда у тебя N тысяч алертов в секунду. Кирилл Борисов (VK)Доклад про цикл жизни систем алертинга — от самого зарождения, когда только нащупываются
Happy Devops — сообщество адекватных инженеров
19 Mar 2025, 10:33edited
Strong Consistency: между производительностью и надежностью данныхStrong consistency — ключевой принцип в распределенных системах, гарантирующий, что все узлы видят одинаковые данные в любой момент времени. При любом обновлении изменения мгновенно становятся видимыми для всех последующих операций чтения.Технически это достигается через линеаризуемость операций — все действия должны выполняться атомарно и по сути выстраиваться в единую временную линию. Синхронная репликация и двухфазный коммит гарантируют, что любое изменение будет применено ко всем репликам до того, как клиент получит подтверждение.Жизненный пример — банковские транзакции. Когда система переводит деньги между счетами, критически важно, чтобы все узлы системы видели актуальное состояние баланса. Рассинхронизация даже на секунду может привести к дублированию списаний или потере транзакций.На практике реализация
Happy Devops — сообщество адекватных инженеров
11 Feb 2025, 08:26
forwarded from @boombah_in_da_house
Друзья, я опять с вакансиейМне нужен руководитель команды Operations. Не, даже не так. Мне нужен охереть какой крутой лид в команду опсов.Я отдаю себе отчет, что человека, которого я ищу, на свободном рынке просто нет, такие люди не выходят в поиск, они меняют работу за полчаса, просто списавшись со знакомыми руководителямиНо вдруг, вдруг... Вдруг кто-то из них читает мой канал и ищет работу, я верю в удачу, мазафака! Я — ваш знакомый руководитель, спишитесь со мной, а? 🥹Итак, нужно возглавить команду очень крутых сеньоров-админов. Это не девопсы, это, скорее, ближе к SRE, прям очень ближе. Парни — огонь! Правда очень и очень крутыеТому, кто таки захочет за это взяться, обязательно нужна хорошая экспертиза в linux, сетях, высоконагруженных системах, хороший технический кругозор. В идеале, нужна хорошая экспертиза по kafka, etcd и vault. Но это в идеале. Если у вас такой нет,Happy Devops — сообщество адекватных инженеров
20 Jan 2025, 08:17
forwarded from @boombah_in_da_house
Есть работа!Друзья, я ищу в одну из своих команд крутого тимлида, который возглавит команду разработки.Мы строим инфраструктуру для секретов (на базе Hashicorp Vault) и конфигураций (на базе etcd). Очень высоконагруженную инфраструктуру, все решения, про которые вы слышали, на наших нагрузках уже не работают и надо придумывать что-то новое.Сразу скажу, что работы очень много и это не продуктовая разработка. Наши заказчики — мы сами и это дополнительный челлендж: мы должны придумать и внедрить решения раньше, чем сервисам Озона станет плохо под нагрузками, это на 100% проактивная история, где нужно инженерное видение и готовность делать то, что раньше никто и никогда не делал.Рутина? Ну камон, ее нет как факта, каждый день — это новый вызов. Маркетплейс, инфраструктура ПВЗ, банк, тревел, фреш и еще куча всего — они все живут на нашей платформеЭто high-severity сервисы, наш etcdjob.ozon.ruВакансия: Руководитель группы Go, Message Bus, PaaS – Москва – работа в OzonПлатформа в Ozon — это разработка для разработки, мы снабжаем инженеров библиотеками, фреймворками и подходами, которые решают их повседневные проблемы — быстрый старт нового сервиса, работа с очередями и базами данных, балансировка нагрузки, рейт лимитинг…Happy Devops — сообщество адекватных инженеров
13 Jan 2025, 10:34
Observability — это не просто модное слово. Вот реальный пример: платежный сервис внезапно стал отдавать 500-ки. Без правильно настроенной системы наблюдения придется потратить часы на поиск причины.RED метрики (Rate, Errors, Duration) в Prometheus сразу покажут масштаб бедствия: какой процент запросов падает, как растет латенси, сколько пользователей под ударом. Базовый дашборд в Grafana для каждого сервиса — три панели с RED метриками и алерты при отклонении от нормы.Distributed tracing через Jaeger раскроет полную картину. Один платёжный запрос проходит через auth-сервис (50мс), потом биллинг (200мс), и где-то между ними теряется. Раньше такой дебаг занимал часы, с трейсами — минуты.Structured logging решает проблему поиска. JSON-логи с метаданными в Loki позволяют мгновенно найти все события по конкретному requestId или userId. Один запрос в LogQL: {job="payment-service"} |=Happy Devops — сообщество адекватных инженеров
13 Jan 2025, 08:14
Коллеги, праздники прошли и мы снова на связи! Команда HappyDevops поздравляет вас с Новым годом, мы желаем вам пять девяток в аптайме, замечательных задач, новых вызовов и отщывчивых систем! Учитесь, растите и развивайтесь. Мы традиционно начинаем новую неделю и наша тема — мониторинг!Мониторинг трансформируется? На смену старой доброй связке RRD и Nagios пришло понятие observability, и она перевернула представление о том, как отслеживать здоровье систем.За последние пять лет инфраструктура выросла из детских штанишек. Микросервисы, контейнеры, serverless — всё это сделало классический мониторинг бесполезным. Нет смысла просто проверять CPU, память и диск. В распределённых системах баги живут на стыках сервисов, а корень проблем прячется в недрах асинхронного взаимодействия.Observability строится на трёх китах: метрики, логи и трейсы. Метрики показывают общую картину, логиHappy Devops — сообщество адекватных инженеров
28 Dec 2024, 10:32
IaC Week: уроки управления большой инфраструктуройМасштабные проекты в Terraform раскрывают истинную сложность управления инфраструктурой. Недостаточно просто писать код — нужна целая система практик и процессов. Опыт реальных проектов показывает несколько критических моментов.Первый — изоляция компонентов через отдельные state-файлы. База данных живет отдельно от сети, сеть — отдельно от вычислительных ресурсов. Это не только упрощает откат изменений, но и защищает от каскадных сбоев при обновлениях.Второй — строгая система версионирования. Каждый модуль получает свой тег по semver, каждое изменение проходит через пайплайн с тестами. State-файлы хранятся в Object Storage с версионированием и репликацией между регионами.Третий — автоматизация всех рутинных операций. План изменений формируется автоматически, проверяется линтером и security-сканером, а после ревью деплоится вHappy Devops — сообщество адекватных инженеров
27 Dec 2024, 10:32
Best practices для масштабных проектов: принципы здоровой инфраструктурыУспешные инфраструктурные проекты строятся не на конкретных технологиях, а на фундаментальных принципах. Масштабные системы требуют особого внимания к деталям и проверенных практик, которые помогают держать сложность под контролем. Стабильность таких систем обеспечивается сочетанием архитектурных решений, процессов и инструментов.Структура проекта начинается с четкой организации кода. Монорепозиторий с модулями разделяется на слои по уровню абстракции, что упрощает навигацию и поддержку:infrastructure/ ├── modules/ # Переиспользуемые модули │ ├── network/ # Базовая сетевая инфраструктура │ ├── compute/ # Compute ресурсы │ └── storage/ # Хранилища данных ├── environments/ # Окружения │ ├── prod/ # Production │ └── stage/ # Staging └── platform/ # Платформенные сервисы ├── monitoring/ # Мониторинг └── security/Happy Devops — сообщество адекватных инженеров
26 Dec 2024, 10:32
Автоматизация развертывания: Пайплайны Terraform без компромиссовКогда инфраструктурой занимается команда, ручной запуск terraform apply превращается в потенциальную катастрофу. Даже небольшая ошибка может привести к непредсказуемым последствиям, особенно в масштабных проектах. Полноценный CI/CD для инфраструктурного кода становится не просто удобством, а необходимостью. Автоматизация пайплайнов снижает риск человеческого фактора, ускоряет развертывание и обеспечивает прозрачность процессов.Структура базового пайплайнаТипичный пайплайн для Terraform включает четыре ключевых этапа: 1. Линтинг — проверка стиля и выявление ошибок в коде. 2. Валидация — гарантирует, что конфигурация корректна и соответствует стандартам безопасности. 3. Планирование изменений — создаёт план, который можно проверить перед применением. 4. Применение — финальный этап, на котором изменения внедряются вHappy Devops — сообщество адекватных инженеров
25 Dec 2024, 10:32
Управление состоянием в Terraform: разделяй и властвуй ⚡️Состояние инфраструктуры в больших проектах становится узким местом при масштабировании команд и сервисов. Remote state решает проблемы с блокировками и конкурентным доступом, но требует продуманной структуры. Главный принцип — разделение state-файлов по четким границам ответственности.В основе грамотного управления состоянием лежит принцип разделения state-файлов по логическим границам. Каждый state-файл описывает независимый компонент инфраструктуры. Такой подход уменьшает риск конфликтов при параллельной работе нескольких команд:# network/main.tf terraform { backend "s3" { bucket = "terraform-states" key = "network/terraform.tfstate" endpoint = "storage.yandexcloud.net" } }# databases/main.tf terraform { backend "s3" { bucket = "terraform-states" key = "databases/terraform.tfstate"Happy Devops — сообщество адекватных инженеров
25 Dec 2024, 08:12
Версионирование инфраструктуры: практики безопасных изменений 📦Современная инфраструктура требует продуманного подхода к версионированию. Неконтролируемые изменения в Terraform приводят к простоям сервисов и потере данных. Правильно выстроенное версионирование позволяет избежать этих проблем.Базовый уровень версионирования — git-тэги для каждого модуля с семантическим версионированием. Мажорная версия растет при несовместимых изменениях, минорная — при добавлении фич, патч — при исправлении ошибок:module "web_cluster" { source = "git::https://github.com/company/tf-modules.git//web-cluster?ref=v2.3.1"cluster_name = "prod-web" instance_count = 5 zone_id = "Z2FDTNDATAQYW2" }История изменений state-файла хранится с помощью версионирования S3. По умолчанию Terraform сохраняет только последнюю версию, поэтому версионирование включается на уровне бакета с правилами очистки старыхHappy Devops — сообщество адекватных инженеров
23 Dec 2024, 08:12
IaC Week: Управляем инфраструктурным кодом как профессионалыЭта неделя посвящена полной перезагрузке подходов к Infrastructure as Code (IaC). Мы разберём, как эффективно версионировать инфраструктуру, управлять состоянием, автоматизировать развертывание и внедрять лучшие практики для масштабных проектов. А начнём с главного вызова — как держать Terraform под контролем, когда проект разрастается до гигантских масштабов.Когда инфраструктурный код выходит из-под контроляКрупные проекты неизбежно сталкиваются с проблемой масштабирования инфраструктурного кода. В одном из наших кейсов код вырос до 50 тысяч строк. Это быстро привело к проблемам: потере структуры, сложностям в управлении и росту риска ошибок. Решение пришло через переосмысление подходов к управлению инфраструктурой.Workspace'ы: отказ от копирования конфигурацийПервым шагом стало использование workspace'ов дляHappy Devops — сообщество адекватных инженеров
20 Dec 2024, 14:17
Отказоустойчивость базы данных проверяется не в момент настройки репликации, а в момент аварии. И часто в самый неподходящий момент — посреди ночи или во время пиковой нагрузки. Поделюсь реальными историями и разбором полетов.Типичный сценарий: праздничная распродажа, нагрузка на пике, и тут primary-база падает. Автоматический failover звучит заманчиво, но реальность сложнее. В одном проекте автофейловер сработал при кратковременном сетевом сбое, поднял новый primary, а когда связь восстановилась — в системе оказалось два мастера. Итог: split-brain и потерянные транзакции.Теперь в критичных системах используем ручной failover с Patroni. Конфигурация выглядит так:scope: postgres-cluster namespace: /db/ name: postgres1restapi: listen: 0.0.0.0:8008 connect_address: 10.0.0.1:8008postgresql: listen: 0.0.0.0:5432 connect_address: 10.0.0.1:5432 data_dir: /data/postgres bin_dir:Happy Devops — сообщество адекватных инженеров
20 Dec 2024, 10:32
Репликация данных — основа отказоустойчивости в современных системах. База данных без реплик похожа на сервер без бэкапов: всё работает отлично, пока не случится катастрофа. А потом становится поздно.Primary-Secondary архитектура — самый распространённый подход. Primary принимает все изменения и пересылает их на реплики. Secondary работают на чтение и готовы подхватить нагрузку при отказе мастера. Звучит просто, но дьявол в деталях.Синхронная репликация гарантирует, что данные попали на реплику до подтверждения записи. Транзакция не завершится, пока secondary не ответит "данные у меня". Надёжно, но медленно — каждая запись ждёт ответа от реплики. В PostgreSQL это выглядит так:ALTER SYSTEM SET synchronous_commit TO 'on'; ALTER SYSTEM SET synchronous_standby_names TO 'replica1';Асинхронная репликация работает в фоне. Primary подтверждает транзакцию сразу, а secondary догоняютHappy Devops — сообщество адекватных инженеров
19 Dec 2024, 14:18
Переход на партиционированные таблицы в боевой системе похож на замену колес на едущей машине. Один неверный шаг — и вся система встанет. Разберем, как провести миграцию безопасно и что делать с гигантскими объемами данных.Вот реальный кейс из практики. Таблица с данными о транзакциях весила 4 ТБ и росла на 50 ГБ в день. Запросы за последний месяц работали быстро благодаря индексам, но исторические отчеты могли считаться часами. Решение — партиционирование по месяцам.Первый шаг — создание структуры:CREATE TABLE transactions_new ( id bigint, created_at timestamp, amount decimal, -- другие поля ) PARTITION BY RANGE (created_at);-- Создаем партиции для каждого месяца CREATE TABLE transactions_2024_01 PARTITION OF transactions_new FOR VALUES FROM ('2024-01-01') TO ('2024-02-01');Дальше начинается самое сложное — перенос данных. Прямой INSERT SELECT на таких объемах заблокируетHappy Devops — сообщество адекватных инженеров
19 Dec 2024, 10:32
MongoDB, PostgreSQL и Elasticsearch предлагают разные подходы к партиционированию. И дело не только в терминологии — каждая база данных реализует его по-своему, со своими преимуществами и ограничениями.В PostgreSQL после версии 10.0 появилось декларативное партиционирование. Создаём основную таблицу, указываем стратегию разделения, и база сама распределяет данные по дочерним таблицам. Партиции наследуют структуру родительской таблицы, но могут хранить данные на разных табличных пространствах. Под капотом PostgreSQL использует ограничения и триггеры для маршрутизации данных.MongoDB строит партиционирование на концепции шардинга. Каждый шард — отдельный сервер или набор реплик. Данные распределяются по шардам на основе ключа. Интересная фишка — зоны шардинга. Можно связать диапазоны ключей с конкретными шардами и тем самым контролировать, где живут данные. Балансировщик следит за
Related Channels
Other channels in the same section of the catalogue.
