Happy Devops — сообщество адекватных инженеров — посты канала в Telegram

16 декабря 2024

Happy Devops — сообщество адекватных инженеров

Фотография
нажмите — покажем

💥 Анонс! Анонс! Анонс! 💥 Каждому нужен близкий человек, которому можно кидать мемы. Это почти физиологическая потребность. У меня, к сожалению, такого человека нет и поэтому я просто решил кидать мемы всем🤷‍♂️ Я уже давно говорил, что хочу запилить канал с мемами и вот оно свершилось. Раньше в этом канале были смешные картиночки, но теперь он стал большой и серьезный, уже как-то несолидно. Да и хотелось что-нибудь сделать на базе ИИ. 🎹 ДевопсРадио v.1.0.1 Канал ведет специально обученный бот, который сам, на основе невероятного ИИ (обученного на всратом чувстве юмора, моем и группы товарищей), ищет и отбирает мемы по всему интернету. Телеграм, Реддит, ВК, Лепра и еще пачка всяких мемных помоек регулярно подвергаются его обходу. Он пока не очень умный, поэтому я все-таки аппрувлю то, что он находит. Но! Один мем в сутки он постит самостоятельно и я не знаю какой, пока он не появится в канале 😊 Свободу роботам и все дела 🤖 Итак, каждые полчаса, без праздников и выходных, железный дружочек постит для вас один прикольный мемчик, выбранный из тысяч найденных и проанализированных им картинок. Это ли не чудо чудесное?🤗 А когда он совсем хорошо научится, то я совсем устранюсь из этого процесса и разрешу ему фигачить самостоятельно Но это еще не все. "Радио" в названии не так-то просто присутствует, в следующем релизе я реально запилю радио. Я очень привык работать под всякую приятную музычку типа lounge, chiilout, ambient, nu-jazz и тому подобное. Но с замедлением ютуба у меня отобрали мои любимые 10-часовые подборки лаунжа. А еще на ютубе есть специальная фоновая музыка для СДВГ-шников и вот примерно такое и будет транслироваться на моем радио. А мой суперумный бот будет помогать скачать понравившиеся треки. Там еще куча разного интересного в бэклоге есть, но не буду рассказывать про все сразу, пусть будет небольшая интрига😏 Пока что просто отборные (и немножко проклятые) мемы❤️ 🔞 Картинки нецензурные и неполиткорректные, без уважения к личности, гендеру, религии

648 · 12:21

18 декабря 2024

Happy Devops — сообщество адекватных инженеров

Индексы в базах данных работают по тому же принципу, что и оглавление в книге. Без них приходится просматривать каждую страницу в поисках нужной информации. И если в книге это просто неудобно, то в базе данных такой полный перебор может растянуться на часы. PostgreSQL предлагает несколько типов индексов, и каждый подходит для своих сценариев. B-tree индексы — стандартный выбор для большинства случаев. Они эффективны для поиска по точному совпадению и для диапазонных запросов. GiST индексы незаменимы для геоданных и полнотекстового поиска. Hash индексы работают только с равенством, зато делают это максимально быстро. Создание индекса — это только начало пути. Планировщик запросов не всегда использует доступные индексы, особенно если статистика устарела или запрос написан неоптимально. Команда EXPLAIN ANALYZE показывает реальный план выполнения запроса. Если вместо Index Scan видите Sequential Scan — самое время разобраться, почему индекс игнорируется. При создании составных индексов порядок колонок критически важен. Индекс по (last_name, first_name) поможет найти всех однофамильцев, а вот индекс по (first_name, last_name) для такого запроса будет бесполезен. Первая колонка должна быть самой селективной — той, что лучше всего сужает результаты поиска. Не стоит индексировать все подряд — это замедляет операции вставки и обновления. Каждый индекс нужно поддерживать в актуальном состоянии, что требует дополнительных ресурсов. Особенно осторожно нужно подходить к индексам на часто изменяемых колонках. Частичные индексы — мощный инструмент оптимизации. Вместо того чтобы индексировать всю таблицу, можно создать индекс только для нужного подмножества данных. Например, для активных пользователей или для заказов за последний месяц. Это экономит место и ускоряет обновление индекса. Покрывающие индексы позволяют получить все нужные данные прямо из индекса, без обращения к таблице. Для этого в INCLUDE нужно добавить все колонки, которые встречаются в SELECT. Такие индексы з

14 · 717 · 08:12

Фотография
нажмите — покажем

EXPLAIN — основной инструмент для отладки производительности запросов в PostgreSQL. За сухими цифрами и техническими терминами в его выводе скрываются истории о том, как база данных пытается максимально быстро найти нужные данные. Планировщик PostgreSQL выбирает путь выполнения запроса на основе статистики и эвристик. Sequential Scan — самый простой способ, перебор всех строк таблицы. Index Scan использует индекс и подходит для точечных запросов. Bitmap Scan комбинирует несколько индексов, собирая битовую карту подходящих строк. Parallel Sequential Scan означает, что база распределила нагрузку между несколькими процессами. Звучит круто, но если запрос часто выполняется — лучше помочь базе правильным индексом. Nested Loop, Hash Join и Merge Join — разные стратегии объединения таблиц, каждая со своими сильными сторонами. EXPLAIN ANALYZE не просто показывает план, но и реально выполняет запрос. В выводе появляются actual time и actual rows — реальное время выполнения и количество обработанных строк. Если цифры сильно отличаются от estimated — планировщик работает с устаревшей статистикой. Высокие значения в startup time говорят о длительной подготовке операции. Большая разница между loops planned и loops actual намекает на проблемы с кардинальностью. А buffers shared hit против buffers shared read показывает, насколько эффективно работает кэш. Partial и parallel стоит внимательно изучить. Partial Mode означает, что база выбрала только часть данных. А чем больше workers запущено в parallel, тем важнее следить за нагрузкой на CPU и диск — параллельное выполнение требует ресурсов. Бывает, что индекс есть, а база его игнорирует. Причин масса: от слишком большого процента подходящих строк до неудачной формулировки WHERE. Особенно коварны неявные преобразования типов и функции в условиях — они мешают использовать индексы. И последнее: EXPLAIN ANALYZE реально выполняет запрос. На больших таблицах это может занять много времени. Если нужно только проверить план — исполь

9 · 661 · 10:32

Как EXPLAIN помогает находить проблемы в типичных запросах. Индексы и EXPLAIN — главные инструменты для отладки производительности в PostgreSQL. Планировщик выбирает путь выполнения запроса на основе статистики, а EXPLAIN показывает, насколько удачным был этот выбор. Возьмем типичный запрос поиска заказов за последний месяц с джойном на таблицу пользователей: EXPLAIN ANALYZE SELECT o.id, o.created_at, u.email FROM orders o JOIN users u ON u.id = o.user_id WHERE o.created_at >= CURRENT_DATE - INTERVAL '30 days' AND o.status = 'completed'; -> Hash Join (cost=19.15..729.45 rows=238 width=80) (actual time=0.432..5.512 rows=245) Hash Cond: (o.user_id = u.id) -> Seq Scan on orders o (cost=0.00..685.20 rows=238 width=56) Filter: (status = 'completed') AND (created_at >= (CURRENT_DATE - '30 days'::interval)) -> Hash (cost=12.40..12.40 rows=540 width=36) -> Seq Scan on users u (cost=0.00..12.40 rows=540 width=36) Sequential Scan в плане запроса — первый звоночек. База читает всю таблицу orders, чтобы найти записи за последний месяц. Создадим индекс по дате создания и статусу: CREATE INDEX idx_orders_date_status ON orders(created_at, status); EXPLAIN ANALYZE SELECT ... -> Hash Join (cost=19.15..129.45 rows=238 width=80) (actual time=0.132..0.512 rows=245) Hash Cond: (o.user_id = u.id) -> Index Scan using idx_orders_date_status on orders o (cost=0.00..85.20 rows=238 width=56) Filter: (status = 'completed') AND (created_at >= (CURRENT_DATE - '30 days'::interval)) -> Hash (cost=12.40..12.40 rows=540 width=36) -> Seq Scan on users u (cost=0.00..12.40 rows=540 width=36) Index Scan и время выполнения упало в 10 раз — именно то, что нужно. Но обратите внимание на Seq Scan для таблицы users. База все еще читает ее целиком, хотя мы достаем только email. Самое время для покрывающего индекса: CREATE INDEX idx_users_email ON users(id) INCLUDE (email); EXPLAIN не просто показыва

12 · 797 · 14:18

19 декабря 2024

Happy Devops — сообщество адекватных инженеров

Партиционирование баз данных превратилось в модную тему. О нем говорят на каждой конференции, пишут в каждой второй статье про оптимизацию. Только часто забывают сказать главное: партиционирование — сложная техника, которая может не только ускорить, но и замедлить систему. В основе партиционирования лежит простая идея — разделить большую таблицу на маленькие части по какому-то признаку. База будет работать с каждой частью как с отдельной таблицей, но для приложения всё останется единым целым. И тут важно не путать партиционирование с шардированием. При партиционировании все данные живут на одном сервере, просто база умнее работает с разными частями таблицы. А шардирование раскидывает данные по разным физическим серверам. Партиционирование спасает от проблем с большими таблицами, шардирование — от ограничений одного сервера. Часто их комбинируют: сначала делят данные на шарды по серверам, а внутри шарда — на партиции. Партиционирование по времени — самый популярный вариант. Логи, метрики, исторические данные — всё, что имеет временную метку, можно разбить по дням, неделям или месяцам. База будет быстро находить нужный диапазон и не тратить время на сканирование старых данных. А ещё появится возможность по-разному хранить старые и новые данные: свежие держать на SSD, а исторические переносить на медленные диски. Географическое партиционирование спасает распределённые системы. Данные европейских клиентов живут в европейских дата-центрах, азиатских — в азиатских. Запросы летят к ближайшему серверу, задержки минимальны. Только придётся продумать, что делать с путешествующими пользователями. Партиционирование по хешу равномерно распределяет данные между частями. Это полезно, когда нет явного признака для разделения, но нужно распределить нагрузку. База считает хеш от выбранных полей и решает, куда положить строку. Минус один — сложно понять, в какой партиции искать конкретную запись. Из реальной практики: один проект страдал от медленных запросов к логам. Таблица ра

6 · 655 · 08:12

MongoDB, PostgreSQL и Elasticsearch предлагают разные подходы к партиционированию. И дело не только в терминологии — каждая база данных реализует его по-своему, со своими преимуществами и ограничениями. В PostgreSQL после версии 10.0 появилось декларативное партиционирование. Создаём основную таблицу, указываем стратегию разделения, и база сама распределяет данные по дочерним таблицам. Партиции наследуют структуру родительской таблицы, но могут хранить данные на разных табличных пространствах. Под капотом PostgreSQL использует ограничения и триггеры для маршрутизации данных. MongoDB строит партиционирование на концепции шардинга. Каждый шард — отдельный сервер или набор реплик. Данные распределяются по шардам на основе ключа. Интересная фишка — зоны шардинга. Можно связать диапазоны ключей с конкретными шардами и тем самым контролировать, где живут данные. Балансировщик следит за равномерным распределением нагрузки. В Elasticsearch партиционирование встроено изначально. Каждый индекс разбивается на шарды, которые распределяются по узлам кластера. Количество шардов задаётся при создании индекса и не меняется, но можно использовать шаблоны индексов для автоматического создания новых индексов по времени или другим критериям. ClickHouse особенно интересно подходит к партиционированию аналитических данных. Он хранит партиции как отдельные директории на диске, что упрощает работу с ними. Можно замораживать старые партиции, перемещать их на другие диски или даже сервера. А встроенная система материализованных представлений автоматически поддерживает агрегаты по партициям. Главный подводный камень во всех базах — запросы, которые работают с несколькими партициями. PostgreSQL приходится объединять данные из разных таблиц, MongoDB собирает результаты со всех затронутых шардов, а Elasticsearch балансирует нагрузку между узлами. Чем больше партиций затрагивает запрос, тем сложнее его выполнить. И везде есть свои тонкости при работе с индексами. В PostgreSQL индексы создаю

8 · 768 · 10:32

Переход на партиционированные таблицы в боевой системе похож на замену колес на едущей машине. Один неверный шаг — и вся система встанет. Разберем, как провести миграцию безопасно и что делать с гигантскими объемами данных. Вот реальный кейс из практики. Таблица с данными о транзакциях весила 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 на таких объемах заблокирует таблицу на часы. Правильный путь — батчинг с параллельной обработкой: -- Функция для переноса данных за один день CREATE OR REPLACE FUNCTION migrate_day(day_start date) RETURNS integer AS $$ BEGIN RETURN WITH moved AS ( DELETE FROM transactions WHERE created_at >= day_start AND created_at < day_start + interval '1 day' RETURNING * ) INSERT INTO transactions_new SELECT * FROM moved; END; $$ LANGUAGE plpgsql; -- Запускаем параллельно для разных дней SELECT migrate_day(day) FROM generate_series('2023-01-01'::date, '2024-01-01', '1 day') day; Во время миграции критично следить за нагрузкой на диски и CPU. Утилита pg_stat_progress_copy показывает прогресс операций. А автовакуум будет очищать старые версии строк, не давая таблице разрастаться. Отдельная история — обслуживание партиций. Старые данные можно архивировать, перенося целые партиции на медленные диски: -- Перемещаем старую партицию на другое табличное пространство ALTER TABLE transactions_2023_01 SET TABLESPACE cold_storage; -- Отключаем автовакуум для стар

8 · 804 · 14:18

20 декабря 2024

Happy Devops — сообщество адекватных инженеров

Репликация данных — основа отказоустойчивости в современных системах. База данных без реплик похожа на сервер без бэкапов: всё работает отлично, пока не случится катастрофа. А потом становится поздно. Primary-Secondary архитектура — самый распространённый подход. Primary принимает все изменения и пересылает их на реплики. Secondary работают на чтение и готовы подхватить нагрузку при отказе мастера. Звучит просто, но дьявол в деталях. Синхронная репликация гарантирует, что данные попали на реплику до подтверждения записи. Транзакция не завершится, пока secondary не ответит "данные у меня". Надёжно, но медленно — каждая запись ждёт ответа от реплики. В PostgreSQL это выглядит так: ALTER SYSTEM SET synchronous_commit TO 'on'; ALTER SYSTEM SET synchronous_standby_names TO 'replica1'; Асинхронная репликация работает в фоне. Primary подтверждает транзакцию сразу, а secondary догоняют когда смогут. Быстро, но есть риск потери данных при падении мастера. MongoDB по умолчанию использует асинхронную репликацию: {w: 1, j: true} // Ждём запись только на primary {w: 'majority', j: true} // Ждём запись на большинство нод Multi-master репликация позволяет писать в любую ноду кластера. Звучит заманчиво, но порождает проблему конфликтов. Две ноды могут одновременно изменить одни и те же данные. Галера-кластер для MySQL решает это через сертификацию транзакций — узлы договариваются о порядке изменений. Отставание реплик — главная метрика здоровья репликации. В PostgreSQL следим за lag в pg_stat_replication, в MongoDB — за replication lag в rs.status(). Если реплика отстает больше определенного порога — пора разбираться в причинах. Мониторинг критичен. Нужно следить не только за отставанием, но и за статусом WAL (Write Ahead Log) архивов, свободным местом на дисках реплик и состоянием сетевого соединения между узлами. Один пропущенный WAL сегмент — и придется переинициализировать реплику с нуля. А еще репликация требует внимательной работы с транзакциями. Длинные транзакции н

6 · 769 · 10:32

Отказоустойчивость базы данных проверяется не в момент настройки репликации, а в момент аварии. И часто в самый неподходящий момент — посреди ночи или во время пиковой нагрузки. Поделюсь реальными историями и разбором полетов. Типичный сценарий: праздничная распродажа, нагрузка на пике, и тут primary-база падает. Автоматический failover звучит заманчиво, но реальность сложнее. В одном проекте автофейловер сработал при кратковременном сетевом сбое, поднял новый primary, а когда связь восстановилась — в системе оказалось два мастера. Итог: split-brain и потерянные транзакции. Теперь в критичных системах используем ручной failover с Patroni. Конфигурация выглядит так: scope: postgres-cluster namespace: /db/ name: postgres1 restapi: listen: 0.0.0.0:8008 connect_address: 10.0.0.1:8008 postgresql: listen: 0.0.0.0:5432 connect_address: 10.0.0.1:5432 data_dir: /data/postgres bin_dir: /usr/lib/postgresql/14/bin parameters: max_connections: 100 shared_buffers: 4GB wal_level: replica hot_standby: "on" Каскадная репликация помогает снизить нагрузку на primary. Вместо десяти реплик, висящих на мастере, строим дерево: пара реплик первого уровня раздает WAL остальным. В PostgreSQL это настраивается через primary_conninfo: -- На реплике первого уровня primary_conninfo = 'host=10.0.0.1 port=5432' -- На реплике второго уровня primary_conninfo = 'host=10.0.0.2 port=5432' Географически распределенные системы добавляют веселья. Латенция между дата-центрами может достигать сотен миллисекунд. Синхронная репликация в таких условиях убивает производительность. На практике работает схема с локальным кластером в каждом регионе и асинхронной репликацией между регионами. Мониторинг репликации — отдельное искусство. Следим за метриками через Prometheus: - job_name: 'postgres_exporter' static_configs: - targets: ['10.0.0.1:9187'] metrics_path: /metrics params: query: - 'pg_replication_lag' - 'pg_wal_activity' И обязательно тести

9 · 869 · 14:17

23 декабря 2024

Happy Devops — сообщество адекватных инженеров

IaC Week: Управляем инфраструктурным кодом как профессионалы Эта неделя посвящена полной перезагрузке подходов к Infrastructure as Code (IaC). Мы разберём, как эффективно версионировать инфраструктуру, управлять состоянием, автоматизировать развертывание и внедрять лучшие практики для масштабных проектов. А начнём с главного вызова — как держать Terraform под контролем, когда проект разрастается до гигантских масштабов. Когда инфраструктурный код выходит из-под контроля Крупные проекты неизбежно сталкиваются с проблемой масштабирования инфраструктурного кода. В одном из наших кейсов код вырос до 50 тысяч строк. Это быстро привело к проблемам: потере структуры, сложностям в управлении и росту риска ошибок. Решение пришло через переосмысление подходов к управлению инфраструктурой. Workspace'ы: отказ от копирования конфигураций Первым шагом стало использование workspace'ов для изоляции окружений. Вместо устаревшего копирования terraform.tfvars мы перенесли все переменные в код. Такой подход упрощает управление и снижает вероятность ошибок: workspace_config = { production = { instance_type = "t3.large" min_size = 3 max_size = 10 environment = "prod" backup_retention = 30 } staging = { instance_type = "t3.small" min_size = 1 max_size = 3 environment = "stage" backup_retention = 7 } } locals { config = workspace_config[terraform.workspace] } Теперь изменения для каждого окружения четко определены, а переключение между ними стало безопасным и простым. Надёжное хранение состояния Для хранения state-файлов мы выбрали S3 с включённым версионированием и блокировками через DynamoDB. Это предотвращает одновременное изменение state и защищает данные от случайных повреждений. Более того, мы добавили репликацию бакета в другой регион, чтобы обезопасить инфраструктуру даже в случае полного сбоя одного из регионов AWS: terraform { backend "s3" { bucket = "terraf

9 · 819 · 08:12

25 декабря 2024

Happy Devops — сообщество адекватных инженеров

Версионирование инфраструктуры: практики безопасных изменений 📦 Современная инфраструктура требует продуманного подхода к версионированию. Неконтролируемые изменения в 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 сохраняет только последнюю версию, поэтому версионирование включается на уровне бакета с правилами очистки старых версий: resource "aws_s3_bucket" "terraform_state" { bucket = "company-terraform-state" versioning { enabled = true } lifecycle_rule { enabled = true noncurrent_version_expiration { days = 90 } abort_incomplete_multipart_upload_days = 7 } } Отдельные ветки для каждого окружения с изолированными pipeline'ами позволяют тестировать изменения безопасно. Новые версии модулей проходят проверку в staging перед деплоем в production. При обнаружении проблем revert коммита автоматически возвращает предыдущую версию через CI/CD. Критичные изменения требуют blue-green deployment. Новая инфраструктура разворачивается параллельно с действующей, трафик переключается постепенно. В случае проблем быстрый откат происходит через DNS: resource "aws_route53_record" "www" { zone_id = aws_route53_zone.primary.zone_id name = "www.example.com" type = "A" alias { name = var.environment == "blue" ? aws_lb.blue.dns_name : aws_lb.green.dns_name zone_id = var.environment == "blue" ? aws_lb.blue.zone_id : aws_lb

8 · 903 · 08:12

Управление состоянием в 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" endpoint = "storage.yandexcloud.net" } } Для обмена данными между состояниями используется data source terraform_remote_state. Сетевые настройки из одного state становятся доступны другим компонентам. Это позволяет избежать жесткой связанности между модулями и упрощает поддержку кода: data "terraform_remote_state" "network" { backend = "s3" config = { bucket = "terraform-states" key = "network/terraform.tfstate" endpoint = "storage.yandexcloud.net" } } resource "yandex_mdb_postgresql_cluster" "postgres" { name = "prod-postgres" environment = "PRODUCTION" network_id = data.terraform_remote_state.network.outputs.network_id config { version = "15" resources { resource_preset_id = "s3-c2-m8" disk_size = 100 } } } При работе с секретами state-файл шифруется на уровне Object Storage через KMS. Ключ доступа выдается только членам инфраструктурной команды. Дополнительный уровень защиты обеспечивает audit log всех операций с state-файлом: terraform { backend "s3" { bucket = "terraform-states"

13 · 781 · 10:32

26 декабря 2024

Happy Devops — сообщество адекватных инженеров

Автоматизация развертывания: Пайплайны Terraform без компромиссов Когда инфраструктурой занимается команда, ручной запуск terraform apply превращается в потенциальную катастрофу. Даже небольшая ошибка может привести к непредсказуемым последствиям, особенно в масштабных проектах. Полноценный CI/CD для инфраструктурного кода становится не просто удобством, а необходимостью. Автоматизация пайплайнов снижает риск человеческого фактора, ускоряет развертывание и обеспечивает прозрачность процессов. Структура базового пайплайна Типичный пайплайн для Terraform включает четыре ключевых этапа: 1. Линтинг — проверка стиля и выявление ошибок в коде. 2. Валидация — гарантирует, что конфигурация корректна и соответствует стандартам безопасности. 3. Планирование изменений — создаёт план, который можно проверить перед применением. 4. Применение — финальный этап, на котором изменения внедряются в инфраструктуру. Пример базового пайплайна на GitLab CI: variables: TF_ROOT: ${CI_PROJECT_DIR}/terraform TF_ADDRESS: ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state stages: - validate - plan - apply fmt: stage: validate script: - cd ${TF_ROOT} - terraform fmt -check -recursive - tflint --config=.tflint.hcl validate: stage: validate script: - cd ${TF_ROOT} - terraform init - terraform validate - checkov -d . --framework terraform Двухступенчатый процесс для безопасности Для минимизации рисков используется двухступенчатый процесс: 1. Планирование: план изменений публикуется в Merge Request для ревью. 2. Применение: изменения внедряются только после проверки и подтверждения. plan: stage: plan script: - cd ${TF_ROOT} - terraform plan -out=plan.tfplan artifacts: paths: - ${TF_ROOT}/plan.tfplan expire_in: 1 week apply: stage: apply script: - cd ${TF_ROOT} - terraform apply plan.tfplan dependencies: - plan rules: - if: $CI_COMMIT_BRANCH == "main" when: manual Защита секр

14 · 852 · 10:32

27 декабря 2024

Happy Devops — сообщество адекватных инженеров

Best practices для масштабных проектов: принципы здоровой инфраструктуры Успешные инфраструктурные проекты строятся не на конкретных технологиях, а на фундаментальных принципах. Масштабные системы требуют особого внимания к деталям и проверенных практик, которые помогают держать сложность под контролем. Стабильность таких систем обеспечивается сочетанием архитектурных решений, процессов и инструментов. Структура проекта начинается с четкой организации кода. Монорепозиторий с модулями разделяется на слои по уровню абстракции, что упрощает навигацию и поддержку: infrastructure/ ├── modules/ # Переиспользуемые модули │ ├── network/ # Базовая сетевая инфраструктура │ ├── compute/ # Compute ресурсы │ └── storage/ # Хранилища данных ├── environments/ # Окружения │ ├── prod/ # Production │ └── stage/ # Staging └── platform/ # Платформенные сервисы ├── monitoring/ # Мониторинг └── security/ # Безопасность Каждый модуль проходит через строгий процесс тестирования. Unit-тесты проверяют корректность отдельных компонентов, интеграционные — взаимодействие между ними. Автоматизированные тесты запускаются при каждом изменении: module "test_network" { source = "../../modules/network" providers = { yandex = yandex.testing } environment = "test" subnets = { "a" = ["10.0.1.0/24"] "b" = ["10.0.2.0/24"] "c" = ["10.0.3.0/24"] } } resource "test_assertions" "network" { component = "network" check "subnets_created" { description = "Проверка создания подсетей" condition = length(module.test_network.subnet_ids) == 3 } check "network_connectivity" { description = "Проверка связности подсетей" condition = can(module.test_network.test_connectivity) } } Для крупных проектов критична система ограничений и политик. Terraform Sentinel защищает от нарушения корпоративных стандартов и автоматически блокирует небезопасные изменения: policy "enforce_mandato

16 · 1.2K · 10:32

28 декабря 2024

Happy Devops — сообщество адекватных инженеров

IaC Week: уроки управления большой инфраструктурой Масштабные проекты в Terraform раскрывают истинную сложность управления инфраструктурой. Недостаточно просто писать код — нужна целая система практик и процессов. Опыт реальных проектов показывает несколько критических моментов. Первый — изоляция компонентов через отдельные state-файлы. База данных живет отдельно от сети, сеть — отдельно от вычислительных ресурсов. Это не только упрощает откат изменений, но и защищает от каскадных сбоев при обновлениях. Второй — строгая система версионирования. Каждый модуль получает свой тег по semver, каждое изменение проходит через пайплайн с тестами. State-файлы хранятся в Object Storage с версионированием и репликацией между регионами. Третий — автоматизация всех рутинных операций. План изменений формируется автоматически, проверяется линтером и security-сканером, а после ревью деплоится в production без ручных действий. Человеческий фактор исключен везде, где это возможно. В итоге все сводится к базовому принципу: инфраструктурный код должен быть таким же надежным и поддерживаемым, как прикладной. Только тогда можно говорить о настоящем Infrastructure as Code. 🏴‍☠️ @happy_devops

11 · 1.4K · 10:32

13 января 2025

Happy Devops — сообщество адекватных инженеров

Коллеги, праздники прошли и мы снова на связи! Команда HappyDevops поздравляет вас с Новым годом, мы желаем вам пять девяток в аптайме, замечательных задач, новых вызовов и отщывчивых систем! Учитесь, растите и развивайтесь. Мы традиционно начинаем новую неделю и наша тема — мониторинг! Мониторинг трансформируется? На смену старой доброй связке RRD и Nagios пришло понятие observability, и она перевернула представление о том, как отслеживать здоровье систем. За последние пять лет инфраструктура выросла из детских штанишек. Микросервисы, контейнеры, serverless — всё это сделало классический мониторинг бесполезным. Нет смысла просто проверять CPU, память и диск. В распределённых системах баги живут на стыках сервисов, а корень проблем прячется в недрах асинхронного взаимодействия. Observability строится на трёх китах: метрики, логи и трейсы. Метрики показывают общую картину, логи рассказывают что случилось, а трейсы объясняют почему. И если мониторинг отвечал на вопрос "что сломалось?", то observability даёт ответ на "почему это случилось?". SLO (Service Level Objectives) стали новой валютой надёжности. Вместо бинарного "работает/не работает" появились чёткие метрики успеха. 99.9% запросов должны выполняться быстрее 200мс? Отлично, настройка алертов и отслеживание трендов решают эту задачу. Никакой магии — только точные цифры и понятные цели. В современном мире недостаточно знать, что сервис упал. Критично предвидеть проблемы до того, как они затронут пользователей. Observability становится третьим глазом инженера, позволяя заглянуть в самое сердце системы. На этой неделе разговор пойдет о каждом аспекте observability. От базовой настройки Prometheus до продвинутых техник трейсинга в Jaeger. Материал будет глубоким и детальным — держите свои дашборды наготове. 🏴‍☠️ @happy_devops

5 · 1.2K · 08:14

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"} |= "error" | json | user_id=123456 — и вот она, причина сбоя. А теперь про SLO — тут начинается самое интересное. Типичная ошибка — взять с потолка цифры типа "99.9% успешных запросов". Звучит красиво, но это путь в никуда. SLO должны отражать реальный пользовательский опыт. Если юзер не заметит падения успешности до 95% — зачем держать планку на 99.9%? Ещё один подводный камень — измерение не тех метрик. Классика жанра: латенси базы данных 99.999%, а пользователи жалуются на тормоза. Оказывается, замеряли только время выполнения запроса, забыв про очередь коннектов к БД. История из жизни: один сервис гордился своими SLO по доступности, пока не выяснилось, что health-check проверял только живость процесса, а не работоспособность бизнес-логики. Правильные SLO рождаются из боли. Сначала инциденты, потом анализ их влияния на бизнес, и только потом — осмысленные цифры. Метрики, логи и трейсы помогают превратить этот опыт в конкретные показатели. И да, их придется регулярно пересматривать — бизнес не стоит на месте. 🏴‍☠️ @happy_devops

18 · 1.4K · 10:34

20 января 2025

Happy Devops — сообщество адекватных инженеров

Ссылка
нажмите — покажем

Есть работа! Друзья, я ищу в одну из своих команд крутого тимлида, который возглавит команду разработки. Мы строим инфраструктуру для секретов (на базе Hashicorp Vault) и конфигураций (на базе etcd). Очень высоконагруженную инфраструктуру, все решения, про которые вы слышали, на наших нагрузках уже не работают и надо придумывать что-то новое. Сразу скажу, что работы очень много и это не продуктовая разработка. Наши заказчики — мы сами и это дополнительный челлендж: мы должны придумать и внедрить решения раньше, чем сервисам Озона станет плохо под нагрузками, это на 100% проактивная история, где нужно инженерное видение и готовность делать то, что раньше никто и никогда не делал. Рутина? Ну камон, ее нет как факта, каждый день — это новый вызов. Маркетплейс, инфраструктура ПВЗ, банк, тревел, фреш и еще куча всего — они все живут на нашей платформе Это high-severity сервисы, наш etcd предоставляет конфигурации для более чем 5000 микросервисов и failure is not an option, мы не можем позволить себе валяться, будет очень больно Мы форкнули Vault, потому что ванильный уже не подходит. Мы форкнули один из кусочков etcd и готовимся форкнуть его весь, потому что на наших нагрузках и требованиях ванильный не справляется. Мы разрабатываем свой etcd-operator для k8s, который позволит крутить etcd на огромном федеративном кластере Kubernetes, в нескольких ЦОДах и с сотнями тысяч деплойментов. Мы пишем низкоуровневые плагины для k8s на уровне common interfaces, чтобы обеспечить отказоустойчивость наших решений. Мы растем кратно год от года и то, что сработало в high-season в прошлом году, в следующем уже будет дремучим легаси Я гарантирую максимально интересные задачи, работу плечом к плечу с лучшими из индустрии и гордость за результат своего труда. Мы делаем очень много и про результаты мы рассказываем на конференциях, пишем статьи и контрибьютим в опенсорс. Если вы хотите принимать участие в публичной активности, то мы поможем подготовить доклады и выступить. Ребята

7 · 1.3K · 08:17

11 февраля 2025

Happy Devops — сообщество адекватных инженеров

Ссылка
нажмите — покажем

Друзья, я опять с вакансией Мне нужен руководитель команды Operations. Не, даже не так. Мне нужен охереть какой крутой лид в команду опсов. Я отдаю себе отчет, что человека, которого я ищу, на свободном рынке просто нет, такие люди не выходят в поиск, они меняют работу за полчаса, просто списавшись со знакомыми руководителями Но вдруг, вдруг... Вдруг кто-то из них читает мой канал и ищет работу, я верю в удачу, мазафака! Я — ваш знакомый руководитель, спишитесь со мной, а? 🥹 Итак, нужно возглавить команду очень крутых сеньоров-админов. Это не девопсы, это, скорее, ближе к SRE, прям очень ближе. Парни — огонь! Правда очень и очень крутые Тому, кто таки захочет за это взяться, обязательно нужна хорошая экспертиза в linux, сетях, высоконагруженных системах, хороший технический кругозор. В идеале, нужна хорошая экспертиза по kafka, etcd и vault. Но это в идеале. Если у вас такой нет, но вы понимаете, что такое bigtech, реальный хайлоад и сложные процессы, то приходите Я ищу в большей степени техлида. Мне нужен человек с экспертизой и со своим мнением, который сможет его обосновать и защитить, если понадобится. Менеджерских задач также будет некоторое количество, бэклогом, стратегией и командой все-таки тоже надо управлять. Для понимания немного сухих фактов: 🔘 У нас самый большой и нагруженный сетап кафки в РФ и один из самых больших в мире 🔘В пиках в высокий сезон мы видели цифры в 17М (семнадцать миллионов) сообщений в кафке в секунду. Кафка выдержала. Надо научить ее держать в два раза больше. 🟡Несколько раз в год мы отключаем один из ЦОДов на живом трафике и все должно работать как и работало. Мы настолько верим в себя, что можем позволить себе такие учения. 🔘Мы — платформенная команда и наши клиенты — это продуктовые разработчики и другие платформенные команды, это очень дотошные и требовательные заказчики 🔘Мы сами придумываем себе задачи и строим стратегию развития и делаем это хорошо 🟢У нас форкнутые версии волта, кафки и etcd, мы дописываем их сами. Вани

18 · 1.4K · 08:26

19 марта 2025

Happy Devops — сообщество адекватных инженеров

Фотография
нажмите — покажем

Strong Consistency: между производительностью и надежностью данных Strong consistency — ключевой принцип в распределенных системах, гарантирующий, что все узлы видят одинаковые данные в любой момент времени. При любом обновлении изменения мгновенно становятся видимыми для всех последующих операций чтения. Технически это достигается через линеаризуемость операций — все действия должны выполняться атомарно и по сути выстраиваться в единую временную линию. Синхронная репликация и двухфазный коммит гарантируют, что любое изменение будет применено ко всем репликам до того, как клиент получит подтверждение. Жизненный пример — банковские транзакции. Когда система переводит деньги между счетами, критически важно, чтобы все узлы системы видели актуальное состояние баланса. Рассинхронизация даже на секунду может привести к дублированию списаний или потере транзакций. На практике реализация strong consistency требует серьезных компромиссов. Задержки на синхронизацию увеличивают латентность, а при сетевых сбоях система может временно перестать принимать запросы на запись — цена за гарантию целостности данных. Альтернативы вроде eventual consistency предлагают лучшую производительность и доступность, жертвуя строгими гарантиями согласованности. Выбор между ними определяется теоремой CAP: нельзя одновременно обеспечить консистентность, доступность и устойчивость к разделению сети. К сожалению, универсального решения не существует. Критичные финансовые и медицинские системы выбирают strong consistency. Социальные сети и стриминговые сервисы предпочитают eventual consistency. Все зависит от требований конкретного проекта и цены потенциальной ошибки. 🏴‍☠️ @happy_devops

11 · 1.2K · 10:33

26 марта 2025

Happy Devops — сообщество адекватных инженеров

Фотография
нажмите — покажем

Гонка за новым функционалом не должна превращать систему в «хрупкого гиганта». SRE-практики помогают определить «точку невозврата» и выстроить процессы поддержки SLA. Если вы хотите научиться проектировать устойчивые системы и оберегать их от неожиданных падений, секция «Reliability Engineering» будет для вас незаменима. Вторая часть докладов секции ⤵️, первая здесь 1) Blameless culture. Как правильно работать с инцидентами. Андрей Синицын (Ozon) Принцип старой школы: «у любой проблемы есть имя и фамилия». Слышали? Может, сами практикуете или бывали такими именем и фамилией? Из доклада вы узнаете, почему культура без обвинений более эффективна, почему это не про всепрощение и расслабон и как запустить такой подход у себя. 2) Как жить, когда у тебя N тысяч алертов в секунду. Кирилл Борисов (VK) Доклад про цикл жизни систем алертинга — от самого зарождения, когда только нащупываются подходы, до уже зрелой системы со своим собственным флоу. 3) Непрерывность как вид искусства. И почему доступности в 3,5 девятки вам достаточно. Глеб Тильтиков (МТС Диджитал) Глеб расскажет о реальном применении SRE-практик, на личном примере рассмотрит оправданное добавление ещё одной девятки и когда от заботы о «pets» нужно переходить к «cattle». 🖐️ Ждём вас 7 и 8 апреля в Москве на DevOpsConf 2025. ✅ Программа конференции и билеты на сайте

4 · 1.1K · 11:52

28 марта 2025

Happy Devops — сообщество адекватных инженеров

Фотография
нажмите — покажем

Eventual Consistency: когда доступность важнее мгновенной согласованности Eventual consistency — модель согласованности, ставшая фундаментом современных распределённых систем. Ключевая идея проста: система гарантирует, что при отсутствии новых обновлений все реплики со временем придут к согласованному состоянию. В отличие от strong consistency, модель работает асинхронно. Узел может подтвердить запись до синхронизации с остальными репликами. Изменения распространяются по системе постепенно, создавая окно времени, когда разные клиенты могут видеть разные версии данных. Техническая реализация включает векторные часы, конфликт-резолверы и gossiping-протоколы для эффективного распространения изменений. Решение конфликтов обычно строится на принципе "последняя запись побеждает" или через более сложные механизмы слияния. Яркий пример — DNS-система. Когда меняется запись, обновления распространяются по DNS-серверам не мгновенно. Кто-то может видеть новый IP, кто-то — старый, но в течение TTL все системы синхронизируются. Другие примеры — CDN, социальные сети, большинство NoSQL баз. Преимущества очевидны: высокая доступность, низкая латентность, отличная устойчивость к сетевым разделениям. Система продолжает работать даже при потере связи между датацентрами. Кластеры легко масштабируются географически, поддерживая локальную запись с отложенной репликацией. Обратная сторона — борьба с аномалиями согласованности. Разработчикам приходится заранее продумывать, как система будет реагировать на конфликты данных, внедрять идемпотентные операции и проектировать UI с учётом возможных несоответствий. Выбор между eventual и strong consistency — всегда компромисс между доступностью и мгновенной согласованностью, между скоростью и надёжностью. Если ваше приложение может корректно функционировать без строгой синхронизации всех реплик — eventual consistency даст значительный прирост в производительности и отказоустойчивости. 🏴‍☠️ @happy_devops

12 · 1.5K · 07:19

16 апреля 2025

Happy Devops — сообщество адекватных инженеров

Фотография
нажмите — покажем

Дорогие друзья, уже на следующей неделе, 23 апреля в Амфитеатре Санкт-Петербургского конгресс-центра Ленполиграфмаш состоится очередной [ Big Monitoring Meetup ] 12! Программа посвящена мониторингу и включает доклады по тематикам разработки, связи, менеджменту. BMM - площадка, где встречаются профессионалы и энтузиасты отрасли, чтобы обсудить современные тренды, обменяться опытом и найти новые решения для актуальных задач. Нетворкинг, дружеская атмосфера, способствующая открытому общению и обмену знаниями. Одной из главных ценностей нашей конференции является возможность установить прямой контакт между разработчиками и пользователями. Встречайте докладчиков двенадцатой конференции: Презентация "3D визуализация в мониторинге: модный тренд или рабочий инструмент?" — Андрей Никифоров. Генеральный директор [ ООО «ТРИТВИН» ] Дискаверинг и мониторинг сетевого оборудования в системе мониторинга Saymon, часть вторая. — Дмитрий Хандыго. Начальник отдела программных решений [ Inline Technologies ] Мониторинга много не бывает. Или бывает? А наследованного и самописного? — Михаил Еграмин. Главный инженер [ ООО «Сети ВЕБА» ] Мониторинг не ограничен потреблением. Как FinOps помогает не упустить контроль над инфраструктурой. — Гуляев Андрей. Руководитель развития продукта [ Инферит Клаудмастер ] Облачная система мониторинга радиовещания. — Александр Орлов. Менеджер [ ООО "Тракт-Софт" ] Мониторинг — это просто. — Вадим Исаканов. Старший инженер [ Платформа контейнеризации «Боцман» ] Если инциденты случаются - значит это кому-нибудь нужно? — Вероника Шапиро. Руководитель направления инфраструктурного мониторинга [ CLOUD.ru ] Не упустите шанс стать частью профессионального сообщества, получить новые знания и вдохновение для развития своих проектов! ✔️ Зарегистрируйтесь сейчас, количество билетов ограничено Подпишитесь на наш ТГ канал или ВК сообщество, чтоб не пропустить важные новости До встречи на конференции [ Big Monitoring Meetup ] 12!

3 · 1.7K · 11:24

29 мая 2025

Happy Devops — сообщество адекватных инженеров

Фотография
нажмите — покажем

🔥 База знаний тимлида: как въехать в процессы быстро и безболезненно! Подкаст Виктор Корейша и Андрея Синицыны. Секция: Hype Кому будет полезно: ➖Тимлидам, которые недавно вошли в новую команду или готовятся к переходу ➖ Инженерам, у которых всё держится в голове и пора с этим что-то делать ➖ Всем, кто хочет структурировать знания о людях и технологиях, не теряя в темпе ✅ О чем? Как собирать и систематизировать знания в удобных инструментах (например, Obsidian), чтобы понимать, как всё работает — от кода до коммуникаций. ⬇ Что вас ждет? ➖ Рекомендации по ведению личной базы знаний ➖ Как фиксировать не только техпроцессы, но и “социальную архитектуру” команды ➖ Инструменты и лайфхаки для заметок, которые реально работают ➖ Обсуждение Obsidian и подходов к организации данных 👀 Кто спикеры? Виктор Корейша — Руководитель направления Managed Services в Ozon. Андрей Синицын — адепт blameless culture, руководитель платформенного отдела в Ozon. Профи в эксплуатации, поклонник SRE и автор телеграм-канала HappyDevops. PRO IT Fest V 5–6 июля Санкт-Петербург, пр. Медиков, 3, корп. 5 Конгресс-центр «Ленполиграфмаш» Билеты Telegram-бот в котором можно получить скидку до -20%

8 · 2K · 08:13

28 ноября 2025

Happy Devops — сообщество адекватных инженеров

Фотография
нажмите — покажем

⚡ Совместный карьерный митап от Звук и self, сообщества для поддержки айтишников. Как строить карьеру в турбулентные времена и экономический кризис 📌 Время и место 🔴30 ноября, с 15:00 до 21:00 🔴Poklonka Place, корпус Е1 Поклонная ул. 3 📌 Можно подробнее? Можно! Митап состоит из четырех частей: 1️⃣Серафима Чекулаева, Руководитель продуктов, ex-VK Музыка, Тинькофф, Яндекс; CEO self и карьерный ментор, расскажет, как выжить на рынке труда, который не беспокоит ваше выживание 💰 2️⃣Дальше – Карьерный форум с 12 экспертами из разных IT-направлений: teamlead, frontend, backend, ML&analytics, product При покупке билета в боте задай свой вопрос, выбери ментора среди экспертов и получи совет о том, что сейчас реально работает✨ 3️⃣ Будет организованный нетворкинг с другими участниками, можно будет обсудить текущую карьерную ситуацию и поделиться лайфхаками. Знакомства получатся без неловкости – ребята уже придумали за вас, как начать диалог💛 4️⃣А финальный диджей-сет от Звука поможет выдохнуть после насыщенного инсайтами дня под расслабляющий бит🎵 Честное слово, ивент будет эпохальный, сильно расстроитесь, если пропустите! И ребята тоже расстроятся, если вас не увидят, так что скорее залетайте и регайтесь!

2 · 1.6K · 07:26