DevOpsConf Channel

Доброе утро! Готовы ко второму дню конференции DevOpsConf 2024? Будет также насыщенно и активно 🙌 ⠀ ☕️ А пока мы предлагаем выпить чашечку ароматного кофе (или чая) и полистать расписание https://devopsconf.io/moscow/2024/schedule

🖐 Друзья, в 17:00 ждём вас на последних докладах первого дня DevOpsConf 2024: 🔸 Зал «Конгресс-холл». Анна Атрошкина (Index) «Что ты сделал для DevOps'а в свои годы... по мнению рекрутера» В докладе будут подробно освещены методы работы рекрутеров: как происходит поиск кандидата, его «верификация» на предмет правдивости профиля. У вас сформируется картина построения своего профиля для максимального совпадения предложений со стороны рекрутеров со своими потребностями. 🔹 Зал «Кейптаун». Павел Сушин (Яндекс) «Динозавр в магазине: опыт публикации YTsaurus в YC.Marketplace» Если вы думаете, как опубликовать свое приложение в YC.Marketplace и что для этого потребуется сделать со своим непростым приложением, то этот доклад для вас. 🔸 Зал «Сингапур». Дмитрий Анисов (GS Labs) «История отказа ceph. Как была потеряна часть данных» Интересная история про то, как докладчик чинил ceph, с выводами о том, как можно было избежать аварии. 🔹 Зал «Уфа». Варвара Подольская (Независимый эксперт) «ChatGPT: декларативная автоматизация» Как генерировать не пару кусочков Terraform из ChatGPT и потом переписывать половину предложенного чатом, а сгенерировать всю инфраструктуру проекта. Про переменные и ресурсы при генерации, а также что еще нужно будет поменять в своем мышлении и подходах. Плюс best practices. 🔸 Зал «Дели+Калькутта». Владимир Романов (Райффайзен Банк) «K8s as a Self Service — как штамповать кластеры» Доклад предлагает погружение в стратегии эффективного масштабирования кластеров Kubernetes при необходимости создания множества экземпляров. Спикер расскажет про эволюцию от ручной конфигурации с помощью Kubespray к более автоматизированному подходу через Cluster API. 🔹 Зал «Пекин». Роман Володин (Ozon) «REpublic — управляй релизами в едином окне» На примере опыта Романа вы узнаете, с какими проблемами можно столкнуться при выстраивании системы автоматизации релизов, как именно можно упростить доставку изменений в продакшн, что такое сущность релиза, зачем её определять и как ими удобнее всего управлять.

В 16:50 в Зале «Шанхай» начнётся Fail-митап, приходите Конференции завалены историями успеха. Но путь к успеху всегда лежит через фейлы, о которых рассказывать не принято. Но только не на нашем fail-митапе! В своих коротких, но зажигательных выступлениях спикеры поделятся настоящими историями фейлов. Без записи, без трансляции, без комплексов.

#DevOpsConf Евгений Харченко из Райффайзен Банк. Как DevOps влияет на эффективность организации? Очень интересный доклад о реально наблюдаемой корреляции между показателями инженерной культуры и метриками эффективности. На масштабе 3000 сотрудников в 148 командах. Метрики касаются применения инженерных практик и интегральной производительности по модели DORA. А по культуре - на модель Ron Westrum, которая разделяет три вида: патологическую, бюрократическую и генеративную. Деление культур опирается на 6 факторов: обмен информацией, сотрудничество, общая ответственность, отношение к ошибкам, анализ причин, улучшения, и для определения генеративной культуры они по каждому фактору сформулировали гипотезы-вопросы, которые предлагают оценить по 5-бальной шкале Лигерта от полностью несогласен до полностью согласен. Гипотезы: * В командах происходит активный обмен информацией. * В командах происходит взаимодействие ролей. * Есть общая ответственность за продукт и платформу * В командах свободно делятся информацией об ошибках и неудачах, не опасаются осуждения * В командах Проводятся анализы причин проблем, ошибок и неудач * В командах приветствуются новые идеи по улучшению процессов Кроме оценки к каждому фактору есть дополнительный вопрос: надо проиллюстрировать вашу оценку примерами, например, в чем проявляется или не проявляется общая ответственность. Для таких вопросов есть варианты ответов со множественным выбором и можно написать свое. Что интересно, средний индекс культуры хорошо коррелирует с инженерными практиками и метриками производительности. В общем-то, так и должно быть, ведь не зря говорят, что devops - это культура. Однако, многие к этому относятся скептически. Метрики показывают ,что это - не так, и работа с культурой - важная составляющая. Результат работы с которой можно измерить. Ну, с точностью до того, что люди начнут подделывать ответы, но это - тоже часть культуры. Но корреляция - побочный результат. Опрос - не для этого, а чтобы увидеть картину в целом, выделить точки роста и аномалии. И успешно работать с ними.

🖐 В 15:50 встречаемся на следующих докладах: ⠀ 🔸 Зал «Конгресс-холл». Дмитрий Евдокимов (Luntry) «Безопасность Kubernetes-кластеров: вредные советы» Из доклада в стиле Григория Остера вы узнаете, как не надо настраивать кластер Kubernetes, от маэстро по безопасности K8s Дмитрия Евдокимова. ⠀ 🔹 Зал «Кейптаун». Алексей Игнатов (АО "СберТех") «Управление горизонтальным автоскейлингом в on-premise-инсталляциях K8s» Отличная возможность посмотреть, как фишку автоскейлинга, характерную для облачных провайдеров, можно реализовать в своей onprem-инфраструктуре. ⠀ 🔸 Зал «Сингапур». Максим Ванюшкин (Тинькофф) «Kafka. Деградировавший кластер, или 168 часов траблшутинга» Доклад о решении проблем в Kafka: от низкоуровневого траблшутинга до устранения серьёзных сбоев, угрожающих работе сервисов. Будут освещены сложные конфигурации, инструменты мониторинга, лайфхаки и тонкости, полезные при работе с Kafka для предотвращения неожиданностей в кластере. ⠀ 🔹 Зал «Уфа». Илья Кочнев (СберМаркет) «FinOps в Облаках» Практический опыт построения FinOps в крупной компании на нескольких облаках. Полезно для тех, кто давно хочет внедрить этот подход у себя, но всё руки не доходят. 🔸 Зал «Дели+Калькутта».  Виктор Евдокимов (Альфа-Банк) «Kubernetes vs Mesos: как мы кластер из 240 микросервисов мигрировали в кубер из mesos/marathon» Из доклада вы узнаете о том, какова стоимость миграции с одного оркестратора на другой, какие при этом были сложности и можно ли было их избежать. ⠀ 🔹 Зал «Пекин». Виталий Астраханцев (АО "СберТех") «Как мы сделали оркестратор релизного конвейера для 2500+ команд Сбера» На примере разберётесь, почему был выбран Jenkins, а не GitLab, зачем нужен отдельный оркестратор для CI/CD и какой взгляд у Сбера на дальнейшую роль DevOps-инженеров.

Приходите на стенд Синимекс, чтобы узнать о продуктах компании и пообщаться с техническими экспертами! Также ребята подготовили для вас: - активности в квест-боте; - настольные игры и баланс-борды; - квиз и лотерею! Всех гостей стенда ждут призы и хорошее настроение! Реклама ООО «СИНИМЕКС ДАТА ЛАБ» erid: LjN8KUcL4

Как «навести порядок в зоопарке» сложного ИТ-окружения? Ответы – на стенде Monq! Приходите знакомиться с командой, а также: ✔️Примите участие в исследовании о сбоях в ИТ и получите дизайнерский мерч. ✔️Получите эксклюзивный доступ к платформе. Monq – платформа ИТ-мониторинга и автоматизации для управления состоянием ИТ-окружения любой сложности. Помогает проактивно реагировать на сбои. В «коробке» – мониторинг инфраструктуры и интерфейсов, зонтичный мониторинг, аналитика, low и no-code автоматизация. Реклама ООО "Монк Диджитал Лаб" erid: LjN8JzKh6

#DevOpsConf Карапет Манасян из MOEX Group. Сколько стоит платформа? Вопреки названию, доклад - не про деньги, он про процессы, обеспечивающие платформенный подход, которые надо наладить. Конечно, процессы стоят денег, но это не главное. Рассказ был о построении платформенной конструкции в рамках MOEX Group. При этом типовой платформенный подход с полной однородностью процессов и единым технологическим стеком у них не подходит, так как бизнес - существенно гетерогенный, есть торговые решения с длинным релизным циклом, есть финтех с коротким тестированием гипотез и есть критическая инфраструктура со своими требованиям регулятором. Тем не менее, они рассматривают сделанное именно как платформу, а не как работу DevOps инженеров. Принципиальная разница - в другом взаимодействии с разработкой. Разработка обычно относится к DevOps следующим образом: мы выдаем код, и задача DevOps - дотащить это до прода, как хотите. А платформа предполагает сервисное взаимодействие: команда платформы обеспечивает сервис конвейера доставки, а команды разработки используют этот сервис под свою ответственность. Профит разработки - в том, что команда платформы может обеспечить больший уровень сервиса своим конвейером доставки, чем команда разработки собственными силами. За счет того, что многие команды решают одинаковые задачи и при выносе их в команду платформы срабатывает эффект масштаба. Это изменение границы - наиболее сложный вопрос, оно требует постоянной поддержки, инвестиций - через сообщества и просвещение. Через сообщества также идет обратное движение, обратная связь и сбор потребностей команд. При этом есть политика компании, побуждающая использовать платформу, но нет жесткого требования, так что решение в значительной мере принимает сама команда. Работа с командами, повышение доверие - одно из направлений. И этот подход побуждает команду платформы реально придумывать полезные фичи и учитывать специфику отдельных продуктов там, где это уместно. Структура команды платформы: change team, которая помогает командам трансформироваться, собирает запросы и обеспечивает поддержку; feature team доработки платформы и core platform, отвечающая за технологические стандарты и единые политики. Всего в ней 26 человек, еще 8 devops-инженеров в конкретных продуктовых командах, что связано со спецификой отдельных продуктов. Задачи от продуктовых команд поступают тремя способами: таск-трекер, демо-встречи платформы и заявки. Дальше идет анализ, как решить поставленную проблему, что стоит делать в платформе, а что команда может сделать, используя существующие возможности. Про технологический стек: нет единого требования, если бизнес выбрал некоторое решение и считает его полезным, то они должны уметь включить его в конвейер поставки от платформы. Конвейер поставки - один типовой, дальше команды докручивают. Для платформы опираются на open source решения, но когда вы забираете такие решения внутрь, то вы становитесь владельцем, надо поддерживать и дорабатывать. Часто встречающаяся проблема - развернуть несколько экземлzпров решения в рамках группы, но при этом обеспечить общую авторизацию. Приходится дорабатывать, и это непросто. Что достигли: единая точка правды инженерных практик - в платформе; от 50+ devops инженеров сократилось до 26; разработчикам стало видно что происходит на проде, эту границу сняли; платформа обеспечивает публикацию по требованию и выделение ресурсов для тестирования. И видно, что с ростом разработки линейного роста команды платформы не происходит, а по devops - было. Инженеров платформы надо обучать внутри, готовой такой специализации на рынке нет, если искать - то в вакансиях надо писать devops, отбирать и это не дешево.

В 15:00 приходите в Зал «Шанхай» на мастер-класс от Алексея Обровца «Введение в нетворкинг: базовые навыки кулуарного общения» Крайне важный мастер-класс про то, как разговаривать с незнакомыми людьми на афтепати, если вы вдруг не очень умеете, но хотите научиться. ПК рекомендует, ведь эти знакомства — важная часть конференции!