Команда Райффайзен Банка приглашает не только побороться на стенде за фирменный мерч, но и посетить их доклады, чтобы было о чем спорить на афтерпати:
Как DevOps влияет на эффективность организации? — о внутреннем исследовании инженерной культуры и ее влиянии на производительность компании
K8s as a Self Service — как «штамповать» кластеры Kubernetes при такой необходимости
Почему я виню «No blame culture» — как понять, когда эта культурная практика становится неэффективной и скрывает реальные проблемы
Мониторим надежность бизнес-процессов с помощью Opentelemetry и Jsonnet — что именно и как они измеряют, чтобы наблюдать за доступностью бизнес-функций
Реклама АО «Райффайзенбанк» erid: LjN8KWF5D
Как DevOps влияет на эффективность организации? — о внутреннем исследовании инженерной культуры и ее влиянии на производительность компании
K8s as a Self Service — как «штамповать» кластеры Kubernetes при такой необходимости
Почему я виню «No blame culture» — как понять, когда эта культурная практика становится неэффективной и скрывает реальные проблемы
Мониторим надежность бизнес-процессов с помощью Opentelemetry и Jsonnet — что именно и как они измеряют, чтобы наблюдать за доступностью бизнес-функций
Реклама АО «Райффайзенбанк» erid: LjN8KWF5D
🔥2
В 13:10 приходите в Зал «Шанхай» на воркшоп от Насими Мамед-заде «Helm: эволюция от стартера до суперчарта»
Helm как инструмент не накладывает ограничений на то, как его использовать, каким образом писать helm-чарты. Это приводит к тому, что нет четких гайдов, как это делать. Эта проблема решается в данном мастер-классе. Вместе со спикером вы подробно рассмотрите лучшие практики организации и написания чартов.
Helm как инструмент не накладывает ограничений на то, как его использовать, каким образом писать helm-чарты. Это приводит к тому, что нет четких гайдов, как это делать. Эта проблема решается в данном мастер-классе. Вместе со спикером вы подробно рассмотрите лучшие практики организации и написания чартов.
🔥2
Forwarded from mtsepkov (Maxim Tsepkov)
#DevOpsConf Игорь Курочкин. NextOps — что будет после DevOps. Открывающий доклад о направлениях развития DevOps. Вау-фишка Way of Ways - обобщенный путь нового движения, которое на начальной стадии порождает новые успешные практики, а потом начинает использоваться как бренд для различных паразитных практик и симулякров, которые эксплуатируют проблемы, а не решают их. И на этом этапе попытки нанести нечто полезное разбиваются о засилье этих паразитных практик. В общем, мы все знаем, что так и происходит, и это частное проявление бюрократизации, как ее исследовал Крозье, но в докладе был конкретный обобщенный путь, и это интересно. Дальше обобщенный путь наложен на DevOps и получается тоже понятная картина, DevOps уже 15 лет и как модный бренд уже прошел фазу полезного развития. Так что стоит задуматься о следующем тренде, которые Игорь назвал NextOps и который позволит сделать следующий шаг. И в докладе была попытка, на основе анализа работы отцов-основоположников DevOps и других трендах это нащупать. Это было интересно, но, на мой взгляд, не слишком перспективно, потому что опыт показывает, что гуру успешного направления очень редко становятся драйверами следующего. Хотя исключения бывают. Конспекта этой части не будет, смотрите доклад.
И тут интересно определение DevOps, которое дал Игорь. Потому что никакого нормативного определения не существует, и это - один из путей, которыми воспользовались паразитные субъекты для приватизации новой территории. Определение Игоря широкое: DevOps призван решать проблемы комомуникации, не только между разработкой и эксплуатацией, но и в других областях, и делает это общественное профессиональное движение. Проблемы решают понятным способом: через выделением паттерном и антипаттернов, и работой с ними. Что касается профессионального движения, то Игорь привел пример консорциума CNCF - Cloud Native Computing Foundation, как открытого сообщества. Наверное, было бы интересно сопоставить практики организации этого сообщества с сообществами прошлой эпохи - OMG или The Open Group.
Конкретно про DevOps надо сказать, что он проходит этап дифференциации, что естественно для каждой развивающейся практики. Появляются новые направления инженерных практик, применяемых на разных этапах конвейера поставки. По инженерным практикам у Игоря тоже широкое определение: это все, что позволяет обеспечить эффективную работы команд на большом масштабе. Тут выделяется много специализаций и направлений, в докладе были слайды. По инженерным практикам Игорь немного остановился на Relibility Engineering (SRE), который успешно развивается, и молодому Platform Engineering. Интересно, что SRE старше DevOps, ему 25 лет, но он по пути Way Of Ways находится еще на продуктивной фазе. Может быть, потому что он решал сложные инженерные задачи, в которых требовался результат - и в этих случаях не получается создавать простые симулякры.
И тут интересно определение DevOps, которое дал Игорь. Потому что никакого нормативного определения не существует, и это - один из путей, которыми воспользовались паразитные субъекты для приватизации новой территории. Определение Игоря широкое: DevOps призван решать проблемы комомуникации, не только между разработкой и эксплуатацией, но и в других областях, и делает это общественное профессиональное движение. Проблемы решают понятным способом: через выделением паттерном и антипаттернов, и работой с ними. Что касается профессионального движения, то Игорь привел пример консорциума CNCF - Cloud Native Computing Foundation, как открытого сообщества. Наверное, было бы интересно сопоставить практики организации этого сообщества с сообществами прошлой эпохи - OMG или The Open Group.
Конкретно про DevOps надо сказать, что он проходит этап дифференциации, что естественно для каждой развивающейся практики. Появляются новые направления инженерных практик, применяемых на разных этапах конвейера поставки. По инженерным практикам у Игоря тоже широкое определение: это все, что позволяет обеспечить эффективную работы команд на большом масштабе. Тут выделяется много специализаций и направлений, в докладе были слайды. По инженерным практикам Игорь немного остановился на Relibility Engineering (SRE), который успешно развивается, и молодому Platform Engineering. Интересно, что SRE старше DevOps, ему 25 лет, но он по пути Way Of Ways находится еще на продуктивной фазе. Может быть, потому что он решал сложные инженерные задачи, в которых требовался результат - и в этих случаях не получается создавать простые симулякры.
👍4
🖐 Программа докладов, которые стартуют в 13:30
⠀
🔸 Зал «Конгресс-холл». Евгений Харченко (Райффайзен Банк) «Как DevOps влияет на эффективность организации?»
Уникальный доклад от спикера из Райффайзен Банка о том, как они строили исследование инженерной культуры у себя в компании и к каким выводам пришли. Скорее всего, повторить такое дома не удастся, но послушать крайне рекомендуем.
⠀
🔹 Зал «Кейптаун». Михаил Морев (Райффайзен Банк) «Мониторим надежность бизнес-процессов с помощью Opentelemetry и Jsonnet»
Доклад предлагает углубленный взгляд на мониторинг надежности и устойчивости в контексте Райффайзен Банка. Михаил поделится практическим опытом, ориентированным на наблюдение за доступностью бизнес-функций, а не только микросервисов и монолитов.
⠀
🔸 Зал «Сингапур». Кирилл Борисов (VK, VK Реклама) «SLO: одно уравнение, множество ответов»
В докладе затрагиваются вопросы «бюрократизации» целевых показателей: как в погоне за цифрами не упустить качество продукта. Будет полезно SRE для структурирования знаний и понимания вектора движения.
⠀
🔹 Зал «Уфа». Александр Качкуркин (oxydmins) «K8s-операторы для СУБД: быстро готовим сотни стейджей»
Как штамповать базы данных (и не только) для каждого изолированного окружения в тестинге и, как следствие, ускорить time-to-market в разы.
🔸 Зал «Дели+Калькутта». Дмитрий Самохвалов (CROC Cloud Services) «Envoy Proxy — один за всех Load Balancer»
Доклад о переходе с NGINX, HAProxy на Envoy из-за ограничений старых систем для динамической конфигурации. Освещается, как Envoy улучшает быстрые обновления, его интеграция через envoy-control-plane, успешное внедрение, рекомендации и лайфхаки для эффективного перехода.
⠀
🔹 Зал «Пекин». Дмитрий Самиров (Airs.AI) «Храним секреты для прода в 1password»
Если вам нужен сторадж для секретов, но вам не нравится Vault, а облачный провайдер даёт неудобное решение, то посмотрите на этот доклад. Оказывается, что можно использовать пользовательские сервисы с секретами и будет даже удобно. На примере 1password посмотрите, как это делается.
⠀
🔸 Зал «Конгресс-холл». Евгений Харченко (Райффайзен Банк) «Как DevOps влияет на эффективность организации?»
Уникальный доклад от спикера из Райффайзен Банка о том, как они строили исследование инженерной культуры у себя в компании и к каким выводам пришли. Скорее всего, повторить такое дома не удастся, но послушать крайне рекомендуем.
⠀
🔹 Зал «Кейптаун». Михаил Морев (Райффайзен Банк) «Мониторим надежность бизнес-процессов с помощью Opentelemetry и Jsonnet»
Доклад предлагает углубленный взгляд на мониторинг надежности и устойчивости в контексте Райффайзен Банка. Михаил поделится практическим опытом, ориентированным на наблюдение за доступностью бизнес-функций, а не только микросервисов и монолитов.
⠀
🔸 Зал «Сингапур». Кирилл Борисов (VK, VK Реклама) «SLO: одно уравнение, множество ответов»
В докладе затрагиваются вопросы «бюрократизации» целевых показателей: как в погоне за цифрами не упустить качество продукта. Будет полезно SRE для структурирования знаний и понимания вектора движения.
⠀
🔹 Зал «Уфа». Александр Качкуркин (oxydmins) «K8s-операторы для СУБД: быстро готовим сотни стейджей»
Как штамповать базы данных (и не только) для каждого изолированного окружения в тестинге и, как следствие, ускорить time-to-market в разы.
🔸 Зал «Дели+Калькутта». Дмитрий Самохвалов (CROC Cloud Services) «Envoy Proxy — один за всех Load Balancer»
Доклад о переходе с NGINX, HAProxy на Envoy из-за ограничений старых систем для динамической конфигурации. Освещается, как Envoy улучшает быстрые обновления, его интеграция через envoy-control-plane, успешное внедрение, рекомендации и лайфхаки для эффективного перехода.
⠀
🔹 Зал «Пекин». Дмитрий Самиров (Airs.AI) «Храним секреты для прода в 1password»
Если вам нужен сторадж для секретов, но вам не нравится Vault, а облачный провайдер даёт неудобное решение, то посмотрите на этот доклад. Оказывается, что можно использовать пользовательские сервисы с секретами и будет даже удобно. На примере 1password посмотрите, как это делается.
Deckhouse — лидер российского рынка Kubernetes, уже более 6 лет в production в банковском секторе, нефтегазовой отрасли и ретейле.
В составе: флагманская Kubernetes-платформа Deckhouse и линейка продуктов по контейнеризации, мониторингу и виртуализации.
Приходите к ним на стенд — ребята поделятся мощной экспертизой в построении инфраструктуры, обменяются с вами опытом в Kubernetes под кружку ароматного кофе, расскажут, как узнать раньше всех, что происходит с DevOps в 2024 году!
Реклама АО «Флант» erid: LjN8KNUdz
В составе: флагманская Kubernetes-платформа Deckhouse и линейка продуктов по контейнеризации, мониторингу и виртуализации.
Приходите к ним на стенд — ребята поделятся мощной экспертизой в построении инфраструктуры, обменяются с вами опытом в Kubernetes под кружку ароматного кофе, расскажут, как узнать раньше всех, что происходит с DevOps в 2024 году!
Реклама АО «Флант» erid: LjN8KNUdz
🔥1
Эксперты CROC Cloud Services приглашают на свой стенд: задать вопрос про первое в России публичное Облако, посоревноваться в знании DevOps-практик, протестить свою ловкость и пощупать облако руками ⛅️
И конечно, подготовили мерч, стикерпаки и розыгрыш суперпризов. Приходите обсудить облачные технологии и современные инженерные практики: эксперты ответят на любые вопросы про индустрию и CROC Cloud
Больше о КРОК: t.iss.one/crocteam
Реклама ЗАО "КРОК инкорпорейтед" erid: LjN8K835n
И конечно, подготовили мерч, стикерпаки и розыгрыш суперпризов. Приходите обсудить облачные технологии и современные инженерные практики: эксперты ответят на любые вопросы про индустрию и CROC Cloud
Больше о КРОК: t.iss.one/crocteam
Реклама ЗАО "КРОК инкорпорейтед" erid: LjN8K835n
🔥2
🖐 Друзья, в 14:40 приходите на следующие доклады:
⠀
🔸 Зал «Конгресс-холл». Петр Артамонов (Evocargo) «Рассказ о том, как мы внедряли IAC для электрических автономных грузовиков»
Лёгкий доклад с байками и шутками — и немного про беспилотники. ПК всячески рекомендует.
⠀
🔹 Зал «Кейптаун». Станислав Левин и Андрей Сухоруков (Лаборатория Касперского) «Secret as a code и случайно заDevSecOps'или?»
Менеджмент ресурсов — тема неновая, а вот как правильно подойти к вопросу менеджмента секретов и работы с ними так, чтобы и безопасно, и удобно для всех участников — уже другое дело.
⠀
🔸 Зал «Сингапур». Олег Сапрыкин и Андрей Радыгин (Флант) «Stateful в Kubernetes. Казнить нельзя помиловать!»
Kubernetes прошел большой путь, чтобы облегчить запуск stateful-приложений. Из доклада можно будет узнать, что изменилось за последние годы и почему запускать stateful-приложения больше нестрашно.
⠀
🔹 Зал «Уфа». Тамаш Фазли (Evocargo) «"Conan-варвар": как мы масштабировали разработку автономных машин и зафакапились»
Доклад раскрывает опыт внедрения системы сборки C++-проектов - Conan - в компании Эвокарго. Рассказывается о затратах ресурсов, проблемах и выводах из этого опыта. Обсуждаются проблемы при внедрении новых технологий сборки и дается обзор полученных результатов преодоления сложностей.
🔸 Зал «Дели+Калькутта». Максим Чудновский (АО "СберТех") «Istio Ambient Mesh — эволюция или революция?»
Если вы задаетесь вопросом, настало ли уже время sidecar-less в теме Service Mesh или нет, то этот доклад все расставит на свои места.
⠀
🔹 Зал «Пекин». Рашид Галиев (Сбер) «DevOps в Сбере — ретроспектива 2017 – 2024»
Докладчик расскажет про путь, пройденный внутренним сообществом с 2017 года. Раскроет подходы, практики и метрики, покажет, как они повлияли на топологии, процессы и инструменты. Поделится проблемами, решениями и новыми вызовами.
⠀
🔸 Зал «Конгресс-холл». Петр Артамонов (Evocargo) «Рассказ о том, как мы внедряли IAC для электрических автономных грузовиков»
Лёгкий доклад с байками и шутками — и немного про беспилотники. ПК всячески рекомендует.
⠀
🔹 Зал «Кейптаун». Станислав Левин и Андрей Сухоруков (Лаборатория Касперского) «Secret as a code и случайно заDevSecOps'или?»
Менеджмент ресурсов — тема неновая, а вот как правильно подойти к вопросу менеджмента секретов и работы с ними так, чтобы и безопасно, и удобно для всех участников — уже другое дело.
⠀
🔸 Зал «Сингапур». Олег Сапрыкин и Андрей Радыгин (Флант) «Stateful в Kubernetes. Казнить нельзя помиловать!»
Kubernetes прошел большой путь, чтобы облегчить запуск stateful-приложений. Из доклада можно будет узнать, что изменилось за последние годы и почему запускать stateful-приложения больше нестрашно.
⠀
🔹 Зал «Уфа». Тамаш Фазли (Evocargo) «"Conan-варвар": как мы масштабировали разработку автономных машин и зафакапились»
Доклад раскрывает опыт внедрения системы сборки C++-проектов - Conan - в компании Эвокарго. Рассказывается о затратах ресурсов, проблемах и выводах из этого опыта. Обсуждаются проблемы при внедрении новых технологий сборки и дается обзор полученных результатов преодоления сложностей.
🔸 Зал «Дели+Калькутта». Максим Чудновский (АО "СберТех") «Istio Ambient Mesh — эволюция или революция?»
Если вы задаетесь вопросом, настало ли уже время sidecar-less в теме Service Mesh или нет, то этот доклад все расставит на свои места.
⠀
🔹 Зал «Пекин». Рашид Галиев (Сбер) «DevOps в Сбере — ретроспектива 2017 – 2024»
Докладчик расскажет про путь, пройденный внутренним сообществом с 2017 года. Раскроет подходы, практики и метрики, покажет, как они повлияли на топологии, процессы и инструменты. Поделится проблемами, решениями и новыми вызовами.
В 15:00 приходите в Зал «Шанхай» на мастер-класс от Алексея Обровца «Введение в нетворкинг: базовые навыки кулуарного общения»
Крайне важный мастер-класс про то, как разговаривать с незнакомыми людьми на афтепати, если вы вдруг не очень умеете, но хотите научиться. ПК рекомендует, ведь эти знакомства — важная часть конференции!
Крайне важный мастер-класс про то, как разговаривать с незнакомыми людьми на афтепати, если вы вдруг не очень умеете, но хотите научиться. ПК рекомендует, ведь эти знакомства — важная часть конференции!
🔥2
Forwarded from mtsepkov (Maxim Tsepkov)
#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, отбирать и это не дешево.
Принципиальная разница - в другом взаимодействии с разработкой. Разработка обычно относится к DevOps следующим образом: мы выдаем код, и задача DevOps - дотащить это до прода, как хотите. А платформа предполагает сервисное взаимодействие: команда платформы обеспечивает сервис конвейера доставки, а команды разработки используют этот сервис под свою ответственность. Профит разработки - в том, что команда платформы может обеспечить больший уровень сервиса своим конвейером доставки, чем команда разработки собственными силами. За счет того, что многие команды решают одинаковые задачи и при выносе их в команду платформы срабатывает эффект масштаба.
Это изменение границы - наиболее сложный вопрос, оно требует постоянной поддержки, инвестиций - через сообщества и просвещение. Через сообщества также идет обратное движение, обратная связь и сбор потребностей команд. При этом есть политика компании, побуждающая использовать платформу, но нет жесткого требования, так что решение в значительной мере принимает сама команда. Работа с командами, повышение доверие - одно из направлений. И этот подход побуждает команду платформы реально придумывать полезные фичи и учитывать специфику отдельных продуктов там, где это уместно.
Структура команды платформы: change team, которая помогает командам трансформироваться, собирает запросы и обеспечивает поддержку; feature team доработки платформы и core platform, отвечающая за технологические стандарты и единые политики. Всего в ней 26 человек, еще 8 devops-инженеров в конкретных продуктовых командах, что связано со спецификой отдельных продуктов. Задачи от продуктовых команд поступают тремя способами: таск-трекер, демо-встречи платформы и заявки. Дальше идет анализ, как решить поставленную проблему, что стоит делать в платформе, а что команда может сделать, используя существующие возможности.
Про технологический стек: нет единого требования, если бизнес выбрал некоторое решение и считает его полезным, то они должны уметь включить его в конвейер поставки от платформы. Конвейер поставки - один типовой, дальше команды докручивают. Для платформы опираются на open source решения, но когда вы забираете такие решения внутрь, то вы становитесь владельцем, надо поддерживать и дорабатывать. Часто встречающаяся проблема - развернуть несколько экземлzпров решения в рамках группы, но при этом обеспечить общую авторизацию. Приходится дорабатывать, и это непросто.
Что достигли: единая точка правды инженерных практик - в платформе; от 50+ devops инженеров сократилось до 26; разработчикам стало видно что происходит на проде, эту границу сняли; платформа обеспечивает публикацию по требованию и выделение ресурсов для тестирования. И видно, что с ростом разработки линейного роста команды платформы не происходит, а по devops - было. Инженеров платформы надо обучать внутри, готовой такой специализации на рынке нет, если искать - то в вакансиях надо писать devops, отбирать и это не дешево.
🔥2👍1