Happy Devops — сообщество адекватных инженеров
前往频道在 Telegram
Сообщество адекватных инженеров | Все про DevOps и эксплуатацию. Культура, инструменты, подходы и решения Живо общаемся (чат): https://t.me/+eNGNnbY_2mVkZTEy По всем вопросам в бота: @HDFeedBackBot Web: https://happydevops.ru
显示更多1 991
订阅者
无数据24 小时
-27 天
-930 天
正在加载数据
吸引订阅者
十月 '2610月 '26
十月 '260
在0个频道中
九月 '260
在0个频道中
Get PRO
八月 '260
在0个频道中
Get PRO
七月 '260
在0个频道中
Get PRO
六月 '260
在0个频道中
Get PRO
五月 '260
在0个频道中
Get PRO
四月 '260
在0个频道中
Get PRO
三月 '260
在1个频道中
Get PRO
二月 '260
在0个频道中
Get PRO
一月 '260
在0个频道中
Get PRO
十二月 '250
在0个频道中
Get PRO
十一月 '250
在0个频道中
Get PRO
十月 '250
在0个频道中
Get PRO
九月 '250
在0个频道中
Get PRO
八月 '25
+5
在0个频道中
Get PRO
七月 '25
+5
在0个频道中
Get PRO
六月 '25
+10
在0个频道中
Get PRO
五月 '25
+13
在2个频道中
Get PRO
四月 '25
+18
在1个频道中
Get PRO
三月 '25
+27
在1个频道中
Get PRO
二月 '25
+20
在0个频道中
Get PRO
一月 '25
+28
在0个频道中
Get PRO
十二月 '24
+98
在3个频道中
Get PRO
十一月 '24
+214
在2个频道中
Get PRO
十月 '24
+121
在6个频道中
Get PRO
九月 '24
+19
在2个频道中
Get PRO
八月 '24
+17
在0个频道中
Get PRO
七月 '24
+30
在1个频道中
Get PRO
六月 '24
+64
在3个频道中
Get PRO
五月 '24
+57
在1个频道中
Get PRO
四月 '24
+55
在1个频道中
Get PRO
三月 '24
+144
在4个频道中
Get PRO
二月 '24
+49
在2个频道中
Get PRO
一月 '24
+15
在0个频道中
Get PRO
十二月 '23
+10
在0个频道中
Get PRO
十一月 '23
+17
在2个频道中
Get PRO
十月 '23
+22
在0个频道中
Get PRO
九月 '23
+15
在0个频道中
Get PRO
八月 '23
+27
在0个频道中
Get PRO
七月 '23
+36
在0个频道中
Get PRO
六月 '23
+60
在0个频道中
Get PRO
五月 '23
+18
在0个频道中
Get PRO
四月 '23
+6
在0个频道中
Get PRO
三月 '23
+27
在0个频道中
Get PRO
二月 '23
+31
在0个频道中
Get PRO
一月 '23
+71
在0个频道中
Get PRO
十二月 '22
+754
在0个频道中
Get PRO
十一月 '22
+16
在0个频道中
Get PRO
十月 '22
+35
在0个频道中
Get PRO
九月 '22
+16
在0个频道中
Get PRO
八月 '22
+372
在0个频道中
Get PRO
七月 '22
+10
在0个频道中
Get PRO
六月 '22
+26
在0个频道中
Get PRO
五月 '22
+5
在0个频道中
Get PRO
四月 '22
+12
在0个频道中
Get PRO
三月 '22
+8
在0个频道中
Get PRO
二月 '22
+22
在0个频道中
Get PRO
一月 '22
+48
在0个频道中
Get PRO
十二月 '21
+73
在0个频道中
Get PRO
十一月 '21
+755
在0个频道中
| 日期 | 订阅者增长 | 提及 | 频道 | |
| 26 十月 | 0 | |||
| 25 十月 | 0 | |||
| 24 十月 | 0 | |||
| 23 十月 | 0 | |||
| 22 十月 | 0 | |||
| 21 十月 | 0 | |||
| 20 十月 | 0 | |||
| 19 十月 | 0 | |||
| 18 十月 | 0 | |||
| 17 十月 | 0 | |||
| 16 十月 | 0 | |||
| 15 十月 | 0 | |||
| 14 十月 | 0 | |||
| 13 十月 | 0 |
频道帖子
Repost from ProIT Fest
🔥 База знаний тимлида: как въехать в процессы быстро и безболезненно! Подкаст Виктор Корейша и Андрея Синицыны.
Секция: Hype
Кому будет полезно:
➖Тимлидам, которые недавно вошли в новую команду или готовятся к переходу
➖ Инженерам, у которых всё держится в голове и пора с этим что-то делать
➖ Всем, кто хочет структурировать знания о людях и технологиях, не теряя в темпе
✅ О чем?
Как собирать и систематизировать знания в удобных инструментах (например, Obsidian), чтобы понимать, как всё работает — от кода до коммуникаций.
⬇ Что вас ждет?
➖ Рекомендации по ведению личной базы знаний
➖ Как фиксировать не только техпроцессы, но и “социальную архитектуру” команды
➖ Инструменты и лайфхаки для заметок, которые реально работают
➖ Обсуждение Obsidian и подходов к организации данных
👀 Кто спикеры?
Виктор Корейша — Руководитель направления Managed Services в Ozon.
Андрей Синицын — адепт blameless culture, руководитель платформенного отдела в Ozon. Профи в эксплуатации, поклонник SRE и автор телеграм-канала HappyDevops.
PRO IT Fest V
5–6 июля
Санкт-Петербург, пр. Медиков, 3, корп. 5
Конгресс-центр «Ленполиграфмаш»
Билеты
Telegram-бот в котором можно получить скидку до -20%
| 2 |  Дорогие друзья, уже на следующей неделе, 23 апреля в Амфитеатре Санкт-Петербургского конгресс-центра Ленполиграфмаш состоится очередной [ Big Monitoring Meetup ] 12!
Программа посвящена мониторингу и включает доклады по тематикам разработки, связи, менеджменту. BMM - площадка, где встречаются профессионалы и энтузиасты отрасли, чтобы обсудить современные тренды, обменяться опытом и найти новые решения для актуальных задач.
Нетворкинг, дружеская атмосфера, способствующая открытому общению и обмену знаниями. Одной из главных ценностей нашей конференции является возможность установить прямой контакт между разработчиками и пользователями.
Встречайте докладчиков двенадцатой конференции:
Презентация "3D визуализация в мониторинге: модный тренд или рабочий инструмент?"
— Андрей Никифоров. Генеральный директор [ ООО «ТРИТВИН» ]
Дискаверинг и мониторинг сетевого оборудования в системе мониторинга Saymon, часть вторая.
— Дмитрий Хандыго. Начальник отдела программных решений [ Inline Technologies ]
Мониторинга много не бывает. Или бывает? А наследованного и самописного?
— Михаил Еграмин. Главный инженер [ ООО «Сети ВЕБА» ]
Мониторинг не ограничен потреблением. Как FinOps помогает не упустить контроль над инфраструктурой.
— Гуляев Андрей. Руководитель развития продукта [ Инферит Клаудмастер ]
Облачная система мониторинга радиовещания.
— Александр Орлов. Менеджер [ ООО "Тракт-Софт" ]
Мониторинг — это просто.
— Вадим Исаканов. Старший инженер [ Платформа контейнеризации «Боцман» ]
Если инциденты случаются - значит это кому-нибудь нужно?
— Вероника Шапиро. Руководитель направления инфраструктурного мониторинга [ CLOUD.ru ]
Не упустите шанс стать частью профессионального сообщества, получить новые знания и вдохновение для развития своих проектов!
✔️ Зарегистрируйтесь сейчас, количество билетов ограничено
Подпишитесь на наш ТГ канал или ВК сообщество, чтоб не пропустить важные новости
До встречи на конференции [ Big Monitoring Meetup ] 12! | 439 |
| 3 |  Даже если за плечами много лет опыта, ты не застрахован от этих ошибок 🫣
Поговорим о них 1 апреля (без шуток) на вебинаре облачного провайдера Cloud․ru. Эксперт поделится рекомендациями, которые помогут успешно мигрировать в облако, минимизируя риски и оптимизируя процессы.
А еще вы узнаете:
😶🌫️что такое традиционные приложения и чем они отличаются от cloud-native;
😶🌫️какое облако подходит вам;
😶🌫️как развивать приложение в облаке после миграции.
Зарегистрироваться на вебинар 👈 | 338 |
| 4 |  Eventual Consistency: когда доступность важнее мгновенной согласованности
Eventual consistency — модель согласованности, ставшая фундаментом современных распределённых систем. Ключевая идея проста: система гарантирует, что при отсутствии новых обновлений все реплики со временем придут к согласованному состоянию.
В отличие от strong consistency, модель работает асинхронно. Узел может подтвердить запись до синхронизации с остальными репликами. Изменения распространяются по системе постепенно, создавая окно времени, когда разные клиенты могут видеть разные версии данных.
Техническая реализация включает векторные часы, конфликт-резолверы и gossiping-протоколы для эффективного распространения изменений. Решение конфликтов обычно строится на принципе "последняя запись побеждает" или через более сложные механизмы слияния.
Яркий пример — DNS-система. Когда меняется запись, обновления распространяются по DNS-серверам не мгновенно. Кто-то может видеть новый IP, кто-то — старый, но в течение TTL все системы синхронизируются. Другие примеры — CDN, социальные сети, большинство NoSQL баз.
Преимущества очевидны: высокая доступность, низкая латентность, отличная устойчивость к сетевым разделениям. Система продолжает работать даже при потере связи между датацентрами. Кластеры легко масштабируются географически, поддерживая локальную запись с отложенной репликацией.
Обратная сторона — борьба с аномалиями согласованности. Разработчикам приходится заранее продумывать, как система будет реагировать на конфликты данных, внедрять идемпотентные операции и проектировать UI с учётом возможных несоответствий.
Выбор между eventual и strong consistency — всегда компромисс между доступностью и мгновенной согласованностью, между скоростью и надёжностью. Если ваше приложение может корректно функционировать без строгой синхронизации всех реплик — eventual consistency даст значительный прирост в производительности и отказоустойчивости.
🏴☠️ @happy_devops | 771 |
| 5 |  Гонка за новым функционалом не должна превращать систему в «хрупкого гиганта». SRE-практики помогают определить «точку невозврата» и выстроить процессы поддержки SLA. Если вы хотите научиться проектировать устойчивые системы и оберегать их от неожиданных падений, секция «Reliability Engineering» будет для вас незаменима.
Вторая часть докладов секции ⤵️, первая здесь
1) Blameless culture. Как правильно работать с инцидентами. Андрей Синицын (Ozon)
Принцип старой школы: «у любой проблемы есть имя и фамилия». Слышали? Может, сами практикуете или бывали такими именем и фамилией? Из доклада вы узнаете, почему культура без обвинений более эффективна, почему это не про всепрощение и расслабон и как запустить такой подход у себя.
2) Как жить, когда у тебя N тысяч алертов в секунду. Кирилл Борисов (VK)
Доклад про цикл жизни систем алертинга — от самого зарождения, когда только нащупываются подходы, до уже зрелой системы со своим собственным флоу.
3) Непрерывность как вид искусства. И почему доступности в 3,5 девятки вам достаточно. Глеб Тильтиков (МТС Диджитал)
Глеб расскажет о реальном применении SRE-практик, на личном примере рассмотрит оправданное добавление ещё одной девятки и когда от заботы о «pets» нужно переходить к «cattle».
🖐️ Ждём вас 7 и 8 апреля в Москве на DevOpsConf 2025.
✅ Программа конференции и билеты на сайте | 642 |
| 6 |  Приглашаем на митап для DevOps-инженеров от билайна
Главные темы — контейнеры, безопасность и миграция.
📍 Офлайн в Казани — в ИТ-парке имени Башира Рамеева
🌐 Онлайн на VK Видео
📆 26 марта, 18:30 (МСК, GMT+3)
В программе — три доклада от инженеров билайна:
• Виталий Ерофеев — «Миграция платформы данных на корпоративную инфраструктуру: DevOps-стратегия»
• Илья Васянин — «Безопасность и удобство, или Как сохранить внутренний покой
• Владимир Барков — «DevPod в помощь, или почему не просто docker run»
Начало митапа — 26 марта в 18:30 (МСК, GMT+3). Офлайн-участников ждем к 18:00.
Регистрация — на сайте.
Реклама. ПАО "Вымпелком». ИНН 7713076301 | 583 |
| 7 |  Strong Consistency: между производительностью и надежностью данных
Strong consistency — ключевой принцип в распределенных системах, гарантирующий, что все узлы видят одинаковые данные в любой момент времени. При любом обновлении изменения мгновенно становятся видимыми для всех последующих операций чтения.
Технически это достигается через линеаризуемость операций — все действия должны выполняться атомарно и по сути выстраиваться в единую временную линию. Синхронная репликация и двухфазный коммит гарантируют, что любое изменение будет применено ко всем репликам до того, как клиент получит подтверждение.
Жизненный пример — банковские транзакции. Когда система переводит деньги между счетами, критически важно, чтобы все узлы системы видели актуальное состояние баланса. Рассинхронизация даже на секунду может привести к дублированию списаний или потере транзакций.
На практике реализация strong consistency требует серьезных компромиссов. Задержки на синхронизацию увеличивают латентность, а при сетевых сбоях система может временно перестать принимать запросы на запись — цена за гарантию целостности данных.
Альтернативы вроде eventual consistency предлагают лучшую производительность и доступность, жертвуя строгими гарантиями согласованности. Выбор между ними определяется теоремой CAP: нельзя одновременно обеспечить консистентность, доступность и устойчивость к разделению сети.
К сожалению, универсального решения не существует. Критичные финансовые и медицинские системы выбирают strong consistency. Социальные сети и стриминговые сервисы предпочитают eventual consistency. Все зависит от требований конкретного проекта и цены потенциальной ошибки.
🏴☠️ @happy_devops | 811 |
| 8 |  О! Астрологи объявили март месяцем DevOps ✨
27 марта пройдёт первый DevOps митап от Островка.
Программа митапа:
🟢 «Как правильно готовиться к работам, связанным с даунтаймами» — Иван Иостман, Senior Data Infrastructure Engineer, Островок.
🟢 Stand-up «Девопс — не лошадь» — Александр Чистяков, многодетный отец девопсов.
🟢 «Автоскейлинг инференса в Kubernetes» — Антон Алексеев, Selectel.
🟢 Stand-up «Ошибки капитального строительства» — Антон Жбанков, автор канала BeerPanda.
Ведущие:
🔹Александр Крылов — организатор DevOpsForLove, CPO "Штурвала" в Лаборатории Числитель.
🔹Денис Божок — Engineering Manager, Островок.
🔹Анна Афонина — организатор ProIT Fest.
Трансляции не будет, но мы выложим запись мероприятия на нашем канале в YouTube.
👉Регистрация по ссылке
Мы приглашаем поучаствовать очно в первую очередь DevOps-специалистов. Участие будет одобрено в течение 1-2 дней. Подтверждение и подробную информацию о мероприятии направим на почту, указанную при регистрации.
До встречи! | 605 |
| 9 | Друзья, я опять с вакансией
Мне нужен руководитель команды 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 | 526 |
| 10 | Есть работа!
Друзья, я ищу в одну из своих команд крутого тимлида, который возглавит команду разработки.
Мы строим инфраструктуру для секретов (на базе 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 | 754 |
| 11 |  Приглашаем на Deckhouse Conf 2025 🔧
27 марта, Москва, Центр событий РБК
Техническая конференция для инженеров и разработчиков от команды Deckhouse — специалистов с 8-летним опытом в создании Cloud Native-решений.
В программе — хардкорные доклады, решения для автоматизации инфраструктурных задач и безопасности, а также живое общение с экспертами и коллегами.
>>> Зарегистрироваться | 306 |
| 12 | 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 | 929 |
| 13 | Коллеги, праздники прошли и мы снова на связи! Команда HappyDevops поздравляет вас с Новым годом, мы желаем вам пять девяток в аптайме, замечательных задач, новых вызовов и отщывчивых систем! Учитесь, растите и развивайтесь. Мы традиционно начинаем новую неделю и наша тема — мониторинг!
Мониторинг трансформируется? На смену старой доброй связке RRD и Nagios пришло понятие observability, и она перевернула представление о том, как отслеживать здоровье систем.
За последние пять лет инфраструктура выросла из детских штанишек. Микросервисы, контейнеры, serverless — всё это сделало классический мониторинг бесполезным. Нет смысла просто проверять CPU, память и диск. В распределённых системах баги живут на стыках сервисов, а корень проблем прячется в недрах асинхронного взаимодействия.
Observability строится на трёх китах: метрики, логи и трейсы. Метрики показывают общую картину, логи рассказывают что случилось, а трейсы объясняют почему. И если мониторинг отвечал на вопрос "что сломалось?", то observability даёт ответ на "почему это случилось?".
SLO (Service Level Objectives) стали новой валютой надёжности. Вместо бинарного "работает/не работает" появились чёткие метрики успеха. 99.9% запросов должны выполняться быстрее 200мс? Отлично, настройка алертов и отслеживание трендов решают эту задачу. Никакой магии — только точные цифры и понятные цели.
В современном мире недостаточно знать, что сервис упал. Критично предвидеть проблемы до того, как они затронут пользователей. Observability становится третьим глазом инженера, позволяя заглянуть в самое сердце системы.
На этой неделе разговор пойдет о каждом аспекте observability. От базовой настройки Prometheus до продвинутых техник трейсинга в Jaeger. Материал будет глубоким и детальным — держите свои дашборды наготове.
🏴☠️ @happy_devops | 774 |
| 14 |  没有文字... | 412 |
| 15 | IaC Week: уроки управления большой инфраструктурой
Масштабные проекты в Terraform раскрывают истинную сложность управления инфраструктурой. Недостаточно просто писать код — нужна целая система практик и процессов. Опыт реальных проектов показывает несколько критических моментов.
Первый — изоляция компонентов через отдельные state-файлы. База данных живет отдельно от сети, сеть — отдельно от вычислительных ресурсов. Это не только упрощает откат изменений, но и защищает от каскадных сбоев при обновлениях.
Второй — строгая система версионирования. Каждый модуль получает свой тег по semver, каждое изменение проходит через пайплайн с тестами. State-файлы хранятся в Object Storage с версионированием и репликацией между регионами.
Третий — автоматизация всех рутинных операций. План изменений формируется автоматически, проверяется линтером и security-сканером, а после ревью деплоится в production без ручных действий. Человеческий фактор исключен везде, где это возможно.
В итоге все сводится к базовому принципу: инфраструктурный код должен быть таким же надежным и поддерживаемым, как прикладной. Только тогда можно говорить о настоящем Infrastructure as Code.
🏴☠️ @happy_devops | 988 |
| 16 | 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 | 787 |
| 17 | Автоматизация развертывания: Пайплайны 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 | 475 |
| 18 | Управление состоянием в 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 | 447 |
| 19 | Версионирование инфраструктуры: практики безопасных изменений 📦
Современная инфраструктура требует продуманного подхода к версионированию. Неконтролируемые изменения в 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 | 506 |
| 20 | 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 | 505 |
