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️⃣А финальный диджей-сет от Звука поможет выдохнуть после насыщенного инсайтами дня под расслабляющий бит🎵 Честное слово, ивент будет эпохальный, сильно расстроитесь, если пропустите! И ребята тоже расстроятся, если вас не увидят, так что скорее залетайте и регайтесь!

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

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

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

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

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

Друзья, я опять с вакансией Мне нужен руководитель команды Operations. Не, даже не так. Мне нужен охереть какой крутой лид в команду опсов. Я отдаю себе отчет, что человека, которого я ищу, на свободном рынке просто нет, такие люди не выходят в поиск, они меняют работу за полчаса, просто списавшись со знакомыми руководителями Но вдруг, вдруг... Вдруг кто-то из них читает мой канал и ищет работу, я верю в удачу, мазафака! Я — ваш знакомый руководитель, спишитесь со мной, а? 🥹 Итак, нужно возглавить команду очень крутых сеньоров-админов. Это не девопсы, это, скорее, ближе к SRE, прям очень ближе. Парни — огонь! Правда очень и очень крутые Тому, кто таки захочет за это взяться, обязательно нужна хорошая экспертиза в linux, сетях, высоконагруженных системах, хороший технический кругозор. В идеале, нужна хорошая экспертиза по kafka, etcd и vault. Но это в идеале. Если у вас такой нет, но вы понимаете, что такое bigtech, реальный хайлоад и сложные процессы, то приходите Я ищу в большей степени техлида. Мне нужен человек с экспертизой и со своим мнением, который сможет его обосновать и защитить, если понадобится. Менеджерских задач также будет некоторое количество, бэклогом, стратегией и командой все-таки тоже надо управлять. Для понимания немного сухих фактов: 🔘 У нас самый большой и нагруженный сетап кафки в РФ и один из самых больших в мире 🔘В пиках в высокий сезон мы видели цифры в 17М (семнадцать миллионов) сообщений в кафке в секунду. Кафка выдержала. Надо научить ее держать в два раза больше. 🟡Несколько раз в год мы отключаем один из ЦОДов на живом трафике и все должно работать как и работало. Мы настолько верим в себя, что можем позволить себе такие учения. 🔘Мы — платформенная команда и наши клиенты — это продуктовые разработчики и другие платформенные команды, это очень дотошные и требовательные заказчики 🔘Мы сами придумываем себе задачи и строим стратегию развития и делаем это хорошо 🟢У нас форкнутые версии волта, кафки и etcd, мы дописываем их сами. Ванильные уже не выживают на наших нагрузках 🟣В нашем проде более 5 000 микросервисов и больше 200 технических команд. Они все очень много используют наши сервисы Немного про нашу команду я писал вот в этом посте. Лида команды разработки я успешно нашел, спасибо, что спросили😊 Вакансия на Ozon.Job: https://job.ozon.ru/vacancy/rukovoditel-gruppi-operations-message-bus-paas-112995867/ Еще раз повторюсь: это прям челлендж-челлендж. Работы много, работа сложная, работа ответственная. Мне не подойдут вонаби-менеджеры, которые умеют хорошо говорить, но которые не делали ничего руками и не в состоянии пройти интервью по system design. Мне не подойдут люди, которые годик управляли маленькой командой в маленьком стартапе, у нас реально "большая вода", они просто не вывезут. Мне не подойдут люди, которые про хайлоад слышали только на "Хайлоаде". Только ветераны войн за аптайм, с горячим сердцем и холодной головой. Если чувствуете в себе силы пособеседоваться, то пишите мне на asinitsyns@ozon.ru Ну или перешлите вакансию знакомому лиду 〰️〰️〰️〰️〰️〰️〰️ 🗞 @boombah_in_da_house

Есть работа! Друзья, я ищу в одну из своих команд крутого тимлида, который возглавит команду разработки. Мы строим инфраструктуру для секретов (на базе 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 в прошлом году, в следующем уже будет дремучим легаси Я гарантирую максимально интересные задачи, работу плечом к плечу с лучшими из индустрии и гордость за результат своего труда. Мы делаем очень много и про результаты мы рассказываем на конференциях, пишем статьи и контрибьютим в опенсорс. Если вы хотите принимать участие в публичной активности, то мы поможем подготовить доклады и выступить. Ребята из наших команд входят в программные комитеты многих конференций. Каждый месяц мы дарим топовый ноутбук за лучшую статью, у некоторых из ребят он уже не один Если вы давно хотели поработать со мной, то вот отличный шанс. Приходите сами или перешлите вакансию знакомому лиду😊 Почитать подробное описание и откликнуться можно на сайте Озона или через меня. Готов ответить на любые ваши вопросы (кроме тех, которые под NDA🙃) 〰️〰️〰️〰️〰️〰️〰️ 🗞 @boombah_in_da_house

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

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

IaC Week: уроки управления большой инфраструктурой Масштабные проекты в Terraform раскрывают истинную сложность управления инфраструктурой. Недостаточно просто писать код — нужна целая система практик и процессов. Опыт реальных проектов показывает несколько критических моментов. Первый — изоляция компонентов через отдельные state-файлы. База данных живет отдельно от сети, сеть — отдельно от вычислительных ресурсов. Это не только упрощает откат изменений, но и защищает от каскадных сбоев при обновлениях. Второй — строгая система версионирования. Каждый модуль получает свой тег по semver, каждое изменение проходит через пайплайн с тестами. State-файлы хранятся в Object Storage с версионированием и репликацией между регионами. Третий — автоматизация всех рутинных операций. План изменений формируется автоматически, проверяется линтером и security-сканером, а после ревью деплоится в production без ручных действий. Человеческий фактор исключен везде, где это возможно. В итоге все сводится к базовому принципу: инфраструктурный код должен быть таким же надежным и поддерживаемым, как прикладной. Только тогда можно говорить о настоящем Infrastructure as Code. 🏴‍☠️ @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_mandatory_tags" { enforcement_level = "hard-mandatory" rule "check_tags" { source = "./rules/tags.sentinel" } } import "tfplan/v2" as tfplan mandatory_tags = ["project", "environment", "owner", "cost-center"] check_resource_tags = func(resource) { tags = resource.change.after.labels return all mandatory_tags as tag { tags contains tag } } Отдельный акцент делается на мониторинг и наблюдаемость. Каждое изменение инфраструктуры должно оставлять след в системе. Метрики, логи и алерты формируют полную картину состояния инфраструктуры: resource "yandex_monitoring_dashboard" "terraform" { name = "terraform-changes" chart { title = "Infrastructure Changes" metrics { name = "terraform.apply.success" aggregation = "COUNT" } metrics { name = "terraform.apply.failure" aggregation = "COUNT" } } alert { name = "High Rate of Failed Changes" condition = "rate(terraform.apply.failure[1h]) > 3" severity = "critical" } } 🏴‍☠️ @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 Защита секретов и управление доступом Безопасность — ключевой аспект. Секреты передаются через защищённые переменные CI/CD, а временные credentials с ограниченным сроком действия предотвращают компрометацию: before_script: - vault kv get -field=YC_TOKEN secret/terraform > token.json - export YC_TOKEN=$(cat token.json) - vault token revoke -self after_script: - rm -f token.json - unset YC_TOKEN Расширение пайплайна: от документации до тестирования Чтобы обеспечить максимальную надёжность, пайплайн можно дополнить: 🔘 Автоматической генерацией документации с помощью terraform-docs, чтобы новые разработчики быстрее понимали структуру. 🔘Проверкой security best practices через tfsec, что помогает выявить уязвимости ещё на этапе разработки. 🔘Постдеплойными тестами, например проверкой доступности сервисов или соответствия стандартам: tests: stage: test script: - cd ${TF_ROOT}/tests - go test -v ./... - inspec exec compliance -t yc:// dependencies: - apply rules: - if: $CI_COMMIT_BRANCH == "main" Идемпотентность как основа надёжности Одной из главных задач в автоматизации развертывания является идемпотентность: повторный запуск пайплайна на одном и том же коммите должен приводить к идентичному результату. Для этого важно правильно работать с артефактами и кэшировать необходимые данные. Автоматизация развертывания с помощью CI/CD для Terraform — это инвестиция в стабильность, безопасность и эффективность вашей инфраструктуры. Пайплайны, построенные по принципу идемпотентности и безопасности, помогают не только сократить время на рутинные задачи, но и минимизировать риски. 🏴‍☠️ @happy_devops

Управление состоянием в 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" key = "secrets/terraform.tfstate" endpoint = "storage.yandexcloud.net" kms_key_id = "abjhq8c9gct5pd5klm7p" access_key = var.storage_access_key secret_key = var.storage_secret_key } } Отдельное внимание стоит уделить резервному копированию state-файлов. Настройка репликации бакетов между регионами защищает от потери данных при отказе основного региона. А регулярные бэкапы позволяют восстановить состояние на любой момент времени. 🏴‍☠️ @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.green.zone_id evaluate_target_health = true } } 🏴‍☠️ @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 = "terraform-state-company" key = "infrastructure/terraform.tfstate" region = "eu-west-1" dynamodb_table = "terraform-locks" encrypt = true versioning = true replication_configuration { role = "arn:aws:iam::123456789012:role/service-role/s3-bucket-replication" rules { status = "Enabled" destination { bucket = "arn:aws:s3:::terraform-state-backup" region = "eu-central-1" } } } } } Этот подход обеспечил безопасность и восстановление инфраструктуры в любых непредвиденных обстоятельствах. Модули и автоматизация: простота в управлении Чтобы упорядочить код, мы приняли стратегию: "один сервис — один модуль". Все повторяющиеся компоненты вынесли в переиспользуемые модули. Это значительно упростило поддержку и добавление новых фич. Для автоматизации развертывания мы внедрили CI/CD pipeline: 🔘 Форматирование и линтинг: проверка стиля кода. 🔘 Проверка плана изменений: гарантируем, что никакие изменения не попадают в production случайно. 🔘 Документация: с помощью terraform-docs мы автоматически генерируем документацию, что помогает новым разработчикам быстро вникнуть в проект. Infrastructure as Code — это не просто способ автоматизации, это мощный инструмент управления инфраструктурой. Использование workspace'ов, надёжного хранения состояния, продуманной модульности и автоматизации делает инфраструктурный код масштабируемым, понятным и устойчивым. Эти практики не только упрощают текущую работу, но и создают прочный фундамент для будущего роста проектов. 🏴‍☠️ @happy_devops

Отказоустойчивость базы данных проверяется не в момент настройки репликации, а в момент аварии. И часто в самый неподходящий момент — посреди ночи или во время пиковой нагрузки. Поделюсь реальными историями и разбором полетов. Типичный сценарий: праздничная распродажа, нагрузка на пике, и тут 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' И обязательно тестируем failover. Регулярно. По графику. С записью времени переключения и подробным разбором каждого случая. Только так можно быть готовым к реальной аварии. Из последних кейсов: база на 12TB с репликацией между континентами. Переключение на другой континент занимало 40 минут. Ускорили до 5 минут через комбинацию логической и физической репликации: основные таблицы реплицировали физически, а небольшие справочники — логически. 🏴‍☠️ @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 сегмент — и придется переинициализировать реплику с нуля. А еще репликация требует внимательной работы с транзакциями. Длинные транзакции на primary мешают очистке WAL, а значит, растет нагрузка на диск и сеть. И секционированные таблицы тоже могут преподнести сюрприз — операции с партициями должны реплицироваться атомарно. 🏴‍☠️ @happy_devops

Переход на партиционированные таблицы в боевой системе похож на замену колес на едущей машине. Один неверный шаг — и вся система встанет. Разберем, как провести миграцию безопасно и что делать с гигантскими объемами данных. Вот реальный кейс из практики. Таблица с данными о транзакциях весила 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; -- Отключаем автовакуум для старых партиций ALTER TABLE transactions_2023_01 SET (autovacuum_enabled = false); Для автоматизации рутины помогает расширение pg_partman. Оно создает новые партиции заранее и может автоматически архивировать старые: SELECT partman.create_parent( 'public.transactions', 'created_at', 'range', 'month', p_premake := 3 ); И последнее: партиционирование требует изменений в приложении. Запросы без указания партиционного ключа будут сканировать все партиции. А значит, нужно научить ORM всегда добавлять created_at в условия поиска. 🏴‍☠️ @happy_devops

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