14 июня приглашаем на DevOps митап!

Вы узнаете, как упорядочить автоматизацию с помощью Ansible, AWX и Vault, почему IaC и GitOps — это только начало на пути к self-service порталу, и как масштабировать инфраструктуру с 5 до 300 виртуальных машин. Обсудим паттерны отказоустойчивости (ретраи, таймауты, circuit breakers) и тонкости работы баз данных в высоконагруженных системах. Присоединяйтесь, чтобы разобрать реальные кейсы и лучшие практики DevOps/SRE.

Программа:

Автоматизация Ansible, AWX, Vault — Матюков Николай, Руководитель команды SRE, iSpring

История о том, как, используя стандартные подходы к IaC, мы:

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

От IaC до self-service портала своими руками — Лищук Александр, Архитектор решений, НЛМК-ИТ

Централизованные DevOps инфраструктуры компаний с ростом числа продуктов и пользователей увеличивают нагрузку на поддерживающих их инженеров в геометрической прогрессии. Больше решений и команд — больше активов и их зависимостей, которые нужно знать и контролировать. Число рутинных задач и обращений очень быстро становится неподъемным, занимает все доступное время, и снижает скорость и качество их решения. Осознав этот снежный ком, быстро приходишь к желанию реализовать self-service решение.

Расскажу про наш опыт: как мы своими руками и простыми экспериментами дошли до портала самообслуживания. Почему IaC и GitOps не достаточно, для чего от автозаполняемой wiki перешли к БД, и как важен и непрост software catalog. Как с помощью простого workflow и интеграций мы соединили пользователей и наши внутренние автоматизации, и сняли с себя большую долю нагрузки. И в то же время, как легко стать заложником простоты при попытке тиражировать это шире, и потому лучше сразу присмотреться к какому-нибудь temporal.

Развитие инфраструктуры разработки iSpring 2018-2025 — Исайкин Алексей, SRE, iSpring

В далёком уже 2018 году вся наша разработка (5 основных проектов, 40 VM) помещалась на 3-4 серверах виртуализации, разделяя ресурсы хостов с другими офисными сервисами.

Через пару лет у разработки появилась собственная инфраструктура, 3 сервера, но на горизонте замаячила та же проблема, что двумя годами ранее — если число окружений будет и дальше расти, для развертывания нового окружения придётся выключать что-то взамен.

Решение было на поверхности — горизонтальное масштабирование среды виртуализации обещало решить многие наши проблемы и мы с радостью погрузились в процесс... Кратко расскажу с чем мы столкнулись в процессе перехода и как мы сейчас управляем хозяйством из 20 серверов и почти 300 VM.

Подстилая соломки или как выжить в нестабильности — Борисов Кирилл, SRE, VK

Сервисы, которые мы разрабатываем, не существуют в изоляции — они являются частью распределённой системы, взаимодействуют друг с другом, используют общую инфраструктуру и ресурсы. Пользователь при этом ожидает стабильной и быстрой работы, независимо от того, сколько компонентов задействовано "под капотом". Именно поэтому наша задача — проектировать сервисы с учётом отказоустойчивости и предсказуемого поведения даже в условиях частичных сбоев.

Чтобы этого достичь, мы используем проверенные архитектурные паттерны: ретраи, таймауты, рейт-лимиты, circuit breakers. Эти подходы позволяют минимизировать влияние сбоя одного сервиса на всю систему и сохранить пользовательский опыт. Однако важно понимать: каждый из этих инструментов — это палка о двух концах. Неправильно сконфигурированные ретраи могут перегрузить зависимые сервисы, чрезмерно короткие таймауты могут привести к фрагментации запроса, а плохо спроектированные рейт-лимиты — к неожиданным отказам. Всё это способно привести систему в метастабильное состояние — ситуацию, при которой нагрузка сама себя усиливает, и система всё глубже погружается в кризис.

Как спроектировать устойчивую архитектуру, не выстрелив себе в ногу? Как предвидеть и предотвратить каскадные сбои? И главное — какие паттерны действительно работают на практике, а какие только добавляют иллюзию контроля? Об этом — в моём докладе.

Базы данных в СДО iSpring Learn — Никитин Михаил, Senior SRE, iSpring

Описание устройства баз данных в СДО iSpring Learn. Каким образом автоматизированно разворачивание баз данных для новых микросервисов. Как происходит fail-over и какие из-за этого есть подводные камни для приложений.

Собираемся в холле офиса компании iSpring, ул. Вознесенская 110. Участие бесплатное, регистрация обязательна. Приглашайте друзей и до встречи на митапе!

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

Информационные партнёры:

• «Митапочная - анонсы митапов по разработке»
• «IT Meeting - митапы и конференции по разработке»
• «IT-мероприятия Йошкар-Олы»