Конференция для инженеров и всех, кто должен понимать инженеров

Доклады

Platform Engineering (15)

Сколько стоит платформа?

Представим, что вы лидер инженерной команды или амбициозный инженер, который понял ценность platform engineering'а для своей компании. У вас возникла идея начать работу над внутренней платформой разработки, но вы осознаете необходимость инвестиций в эту активность со стороны руководства.

В моем докладе вы узнаете:
* технологические составляющие платформы;
* экономические составляющие платформы;
* как выбрать базовую стратегию обоснования необходимости PE для своей компании;
* модели развития платформы в зависимости от инвестиций;
* проблемы при масштабировании платформы и пути их решения;
* внутренняя платформенная команда: части, состав, проблемы в работе;
* платформа, обязательная к использованию или по желанию команд: как лучше?
* как сравнить жизнь с платформой и без нее;
* как сделать внутренних клиентов вашей опорой перед руководством;
* кейсы из опыта MOEX Group: как мы строим единую отказоустойчивую платформу для всех компаний Группы.

В конце доклада у вас будет четкое понимание, как защитить необходимость платформы не лозунгами, а конкретными цифрами именно для своей компании. Кроме этого, еще одна цель доклада состоит в формировании нового в индустрии инженерного мышления, которое направлено на основные аспекты бизнеса, клиентоориентированности, организационно-культурного состояния и технологической зрелости компании.

Доклад принят в программу конференции

REpublic — управляй релизами в едином окне

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

Доклад принят в программу конференции

K8s as a Self Service — как штамповать кластеры

Технологии виртуализации и контейнеризации
Управление конфигурацией
DevOps / Кубер
DevOps / SRE
Железо
Инфраструктура
Владимир Романов

Райффайзен Банк

В современных реалиях, когда кубер стал практически стандартом, одной из типовых задач становится непосредственно развёртывание и дальнейшее сопровождение K8s-кластеров. И если их немного, то это не представляет особой сложности, проблемы начинаются, когда их нужны десятки, сотни, и они нужны on-premise, вчера, ну или через 5 минут.

В этом докладе я расскажу о нашем опыте решения как раз такой задачи.

Доклад принят в программу конференции

Как мы платформу на существующие процессы натягивали

* Как наверняка понять, что платформа вам нужна?
* Как (не) выстрелить себе в ногу, внедряя платформу?
* Что придется сломать в процессах, системах и головах людей?
* Где придется признать, что ломать дороже (даже в долгой перспективе), чем оставить все как было?
* Какую ценность должна нести платформа, чтобы "продать" ее разработчикам?

Расскажу про то, как мы за 4 года жизни платформы искали ответы на эти вопросы, через какие тернии прошли, и где нас укусила реальность.

Доклад принят в программу конференции

Платформа — это продукт. А что, вообще, такое — продукт?

Все давно решили, что внутренние IT-сервисы — это продукты, но никто толком не понимает, что это значит. Просто техлиду говорят, что теперь он еще и владелец продукта.

Рассмотрим, что такое продуктовая методология применительно к внутренним айти-сервисам и какие практики и инструменты применимы в этом случае.

Доклад принят в программу конференции

Kubernetes и сеть: история одного TelcoCloud

Технологии виртуализации и контейнеризации
Сетевое администрирование
DevOps / Кубер
Железо
Инфраструктура
Степан Чернов

Инфосистемы Джет

В докладе расскажу про TelcoCloud в части контейнеров, а именно: как мы тестировали производительность сети на одном из наших проектов для телеком-заказчика. Расскажу, кому и зачем это нужно. Покажу методику и результаты тестирования, где сравню пропускную способность оверлейной сети OVN-Kubernetes и SRIOV+DPDK.

А на сладенькое — расскажу немного боли про переход с OpenShift на OKD.

Доклад принят в программу конференции

Что делать с requests/limits, или Утилизируй Kubernetes правильно

Последние годы контейнеры и Kubernetes захватывают все больше и больше компаний, позволяя быстро запускать тысячи приложений. Однако в какой-то момент можно столкнуться с проблемой утилизации железа: какие-то сервера оказываются сверхнагруженными, а какие-то — совсем нет.

В своем докладе я расскажу про:
* опыт эксплуатации большого кластера K8s;
* что такое requests/limits и как они работают на низком уровне;
* как мы помогали разработчикам правильно рассчитывать эти значения, а затем начали выставлять их автоматически;
* зачем нужен descheduler;
* а также покажу демо, чтобы развеять несколько мифов.

Доклад принят в программу конференции

Alerts-Registry. Одно место управления алертами

Доклад представит, как эволюционировала наша система создания алертов. Раскрою, с какими сложностями сталкивались на каждом из этапов. Поговорим про типы алертов в Озоне. Расскажу, как мы создаем единый сервис написания и деплоя алертов.

Доклад принят в программу конференции

Istio Ambient Mesh — эволюция или революция?

Новый режим Ambient Mesh в Istio стремится решить основные проблемы Service Mesh и обещает нам мир, где больше нет sidecar-контейнеров с сетевыми прокси, а значит нет никаких дополнительных затрат ресурсов, проблем с L4-трафиком или повышенных привилегий для редиректа сетевого потока. При этом Ambient-режим обещает отсутствие каких-либо компромиссов в функциональности или безопасности.

Давайте все это проверим?

В докладе я предлагаю глубоко погрузиться в архитектуру Ambient Mesh, сравнить ее с прошлой реализацией, оценить на практике все преимущества и недостатки и, конечно, главное — ответить на вопрос, пора ли использовать Istio Ambient в своем продакшне?

Доклад принят в программу конференции

Куб всему голова! Строим внутреннюю Kubernetes-платформу на baremetal

Технологии виртуализации и контейнеризации
Управление конфигурацией
Автоматизация разработки, доставки, эксплуатации
DevOps / Кубер
DevOps / SRE
Железо
Инфраструктура

Kubernetes уже давно стал стандартом де-факто в построении платформ для удобной разработки. Но что делать, если ваша платформенная команда располагает только «голым» железом, а вашу платформу в любой момент может потребоваться развернуть под ключ в закрытом контуре за короткое время? Мы собрали нашу «коробку» на основе легковесных Open Source-инструментов, поставив во главу угла подход Infrastructure as a Code, и хотим поделиться своим опытом в этом деле.

В ходе доклада затронем следующие темы:
* Как мы пришли к архитектуре нашего решения, и откуда родилась идея с mgmt-кластером.
* Как реализовать декларативную «наливку» железных хостов?
* Как спрятать секреты от любопытных глаз и дать рукоятку деплоя разработчикам?
* Как раздеплоить сам куб, причем тут вообще terraform, и как выглядит инфраструктурный релиз?

Доклад принят в программу конференции

Как мы сделали оркестратор релизного конвейера для 2500+ команд Сбера

В своем докладе я расскажу о том, почему классические подходы к DevOps, работающие для небольших команд, теряют свою эффективность при масштабировании в десятки раз. Как при этом пройти через этап роста и получить эффективно работающий CI/CD-процесс и инструмент.

Почему оркестратор оркестраторов открывает новые возможности для масштабирования, и сколько уровней абстракции нужно для построения конвейеров любого уровня сложности. Как мы решаем проблему масштабирования и надежности продукта, и почему важно вовремя выделять время на техдолг.

Ну и самое главное — что получают пользователи, а точнее, от чего могут легко отказаться при использовании нашего инструмента оркестрации.

Доклад принят в программу конференции

Developer Experience: обзор подходов и как мы их применяем

В какой-то момент в Авито у нас появилась необходимость системно подойти к определению векторов развития PaaS — нашей платформы, которая позволяет разработчикам имплементировать фичи, не отвлекаясь на борьбу с деплоями, линтерами, кафками, трейсингом и подобными компонентами.

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

В докладе я хочу рассказать, какие подходы к DevEx есть в мировой индустрии, рассмотрим несколько фреймворков. И, наконец, расскажу о нашем опыте применения этих знаний. Покажу, как анализировали результаты и какие инсайты получили.

Доклад принят в программу конференции

Путь от «хаоса» к облачной инфраструктуре

Автоматизация разработки, доставки, эксплуатации
Облака
Инфраструктура

Большой телеком-оператор, один из лидеров индустрии достаточно долго игнорировал развитие своей инфраструктуры и отдавал разработку вендорам.

Начиная с 2021 года билайн поменял свой курс на максимальное развитие внутренней разработки. 3000+ новых разработчиков за 3 года с большим числом legacy-продуктов и большое желание стать высокоинженерной компанией.

В данном докладе расскажу о том, как мы дошли до Kubernetes, Kafka, PostgeSQL as a Service.

Доклад принят в программу конференции

JumpStart для новых сервисов

Перед тем, как начать разработку нового сервиса, нужно сделать много мелких шагов:
* создать репозиторий,
* настроить репозиторий,
* добавить шаблон сервиса,
* добавить шаблон CI/CD pipeline,
* добавить шаблон helm app-chart для деплоя в различные окружения,
* добавить секреты в Vault,
* etc.

В Magnit Tech новые сервисы появляются каждый день: на подготовку уходит достаточно много времени, которое можно было бы потратить на разработку. Поэтому мы задумались: а как можно упростить и ускорить этот процесс?

В докладе рассказываем, как устроен процесс запуска новых сервисов в Magnit Tech, какой внутренний тулинг для этого используется, какие проблемы возникали во время разработки и как мы их решили.

Поговорим о том, как сервисы взаимодействуют между собой, что такое общий helm app-chart и общий CI/CD pipeline, DORA-метрики и их имплементация.

Доклад принят в программу конференции

В чем польза IT-платформы? Как её лучше делать?

На каждом месте работы я так или иначе строю платформу для помощи разработчикам, это получается само собой, интуитивно. Но нужно ли это делать? Правильно ли я поступаю? Как оценить? В чем основная ценность?

Я расскажу, в чем вижу основную цель платформы, покажу пример денежной оценки пользы от платформы. Взгляну на вопрос не глазами инженера, а глазами CTO, который думает в том числе и про выручку и рост компании и стремится на это повлиять. Также коротко пройдусь по основным этапам создания платформы.

Доклад принят в программу конференции

Безопасность, DevSecOps (11)

Secret as a code и случайно заDevSecOps'или?

Управление конфигурацией
Непрерывное развертывание и деплой
Непрерывная интеграция
Сетевое администрирование
Управление изменениями
Безопасность
Безопасность инфраструктуры
Станислав Левин

Лаборатория Касперского

Андрей Сухоруков

Лаборатория Касперского

Это доклад о том, как мы переосмыслили логику работы с разработчиками, автоматизацией и менеджментом секретов. И точно не о том, как мы внедрили HC Vault.

В принципе, он у нас есть, но мы хотим рассказать, как при наличии в команде 40+ сервисов и 4-6 стендов, мы сократили себе работу в плане автоматизации, менеджмента секретов и набега разработчиков.

Для этого мы придумали логику процессов и создали инструменты, которые упростили нам работу, не создавая при этом платформы с огромными затратами.

И случайно заDevSecOps'или.

Доклад принят в программу конференции

Безопасность Kubernetes-кластеров: вредные советы

Тестирование безопасности
Микросервисы
DevOps / Кубер
Безопасность
Безопасность инфраструктуры

У всех нас есть какой-то опыт, и мы всегда стараемся переносить его с собой повсюду. Так, например, велик соблазн перенести свой опыт обеспечения безопасности Linuх/Docker-инфраструктур (не говоря уже о Windows) на Kubernetes-кластера. При этом, к сожалению, до конца не понимая самой природы Kubernetes. И это может быть ваш личный опыт или опыт кого-то из коллег, которые писали корпоративный стандарт с «лучшими практиками» по безопасности в Kubernetes, а вам ему уже необходимо следовать... К сожалению, то, что работало раньше и где-то, очень полезно, на практике неэффективно, бесполезно или вообще может привести к авариям как кластера, так и приложений в нем.

Рассмотрим, что в теории звучит очень полезно, а на практике приводит к авариям, падениям приложений и Kubernetes-кластеров.

Доклад принят в программу конференции

Hardening Jenkins: как подать блюдо, чтобы оставили чаевые

Непрерывное развертывание и деплой
Атаки
Безопасность
Безопасность инфраструктуры

Пайплайн — это блюдо, которое подается в холодном виде. Привнося в свою систему такой CI/CD-сервер, как Jenkins, мы не только добавляем гибкий и удобный Open Source-продукт с большим сообществом и безграничными возможностями по его настройке, но также размещаем большое количество «черных дыр» в нашей системе, позволяющих злоумышленникам проводить через них атаки на инфраструктуру. А ряд популярных плагинов лишь увеличивает уязвимость системы перед лицом врага. Настало время это исправить! Цель этого доклада — показать приемы усиления безопасности и выстраивания безопасной разработки с использованием Jenkins.

В докладе мы рассмотрим:
* что такое Jenkins и какая экосистема есть вокруг него,
* уязвимости Jenkins Core — основного ядра системы,
* уязвимости в популярных плагинах,
* какие практики с использованием Jenkins актуальны, а какими лучше не пользоваться,
* решения, позволяющие повысить безопасность Jenkins и закрыть часть уязвимостей.

Доклад принят в программу конференции

Подготовка SecChamp’ов: как обработать все проблемы и не сойти с ума

При нехватке AppSec-специалистов на рынке DevSecOps-инструменты внедряются тяжело и справиться с огромным потоком результатов очень сложно. Всё это не очень позитивно влияет на time-to-market. Но если взрастить своих Security Champions в командах разработки, то можно улучшить многие метрики.

В докладе я расскажу об опыте Cloud.ru, а также развею миф о неэффективности практики Security Champions.

Доклад принят в программу конференции

AppSecJob: как с помощью К8s-операторов поставить проверки безопасности на автопилот

Микросервисы, SOA
Технологии виртуализации и контейнеризации
Непрерывная интеграция
Application security
DevOps / Кубер

В мире разработки, где скорость выпуска продуктов на рынок становится приоритетом, процесс проверок безопасности не должен становиться узким местом. Оркестрация SAST-, SCA-, SecretScanning-инструментов в контейнерной среде обеспечивает единообразное и эффективное управление ими. Использование механизмов управления микросервисами, предоставляемых Kubernetes, позволяет создать более высокоуровневые интерфейсы для проведения сканирований безопасности, упрощая процесс и реализуя «shift-left»-подход.

В этом контексте рассмотрим:
* существующие решения и подходы для автоматизации внедрения проверок безопасности в CI/CD;
* оркестрацию инструментов: управление выбором, конфигурацией и запуском набора AppSec-инструментов при различных условиях;
* когда Kubernetes — это больше, чем манифесты, или наш UP от yaml-разработки к написанию операторов;
* концепцию создания AppSecJob и её преимущества для AppSec-инженеров, DevOps’ов и команд разработки.

Доклад принят в программу конференции

Безопасность CI/CD в условиях компрометации

CI/CD-система — это сердце разработки в любой современной компании, ведь на ее базе выстраиваются процессы хранения кода, его сборки и доставки. Очень удобно, когда все это совмещается в рамках одного продукта, например Giltab. Однако при таком подходе формируется единая точка компрометации и повышаются риски с точки зрения безопасности.

В данном докладе мы с точки зрения злоумышленника под микроскопом посмотрим на Gitlab и предложим разнообразные решения для его защиты.

Доклад принят в программу конференции

Kyverno: старт без грабель

Антон Гаврилов

Инфосистемы Джет

Kyverno – потрясающий инструмент, обладающий весьма обширным функционалом по анализу манифестов Kubernetes и образов контейнеров. На практике часто встречаюсь с тем, что «про него слышали, но явно не использовали» или «использовали, но только для определенного типа политик на ограниченном объеме».

В своем докладе я расскажу более подробно про возможности этого инструмента и дам рекомендации о том, как можно начать свой путь в работе с Kyverno. Вместе со слушателями ответим на вопросы:
* Почему Kyverno?
* Какие бывают типы политик?
* Что анализировать в первую очередь?
* Как работать с результатами?
* Как выстроить процесс по устранению найденных несоответствий?

Приходите, будет весело!

Доклад принят в программу конференции

Реализация Kerberos в Kubernetes/Istio Service mesh

Сегодня многие крупные компании используют K8s в своей собственной инфраструктуре. Размещение и интеграция сервисов в рамках уже существующей IT-архитектуры организации и обеспечение механизмов безопасности в таких инсталляциях зачастую бывают затруднены.

Расскажем, как мы реализовали работу протокола Kerberos в средах K8s/Istio Service Mesh, почему это было так сложно и какие преимущества мы получили. В процессе доклада рассмотрим несколько конкретных примеров организации работы сервисов с протоколом Kerberos в средах K8s/Istio Service Mesh под высокой нагрузкой.

Доклад принят в программу конференции

Все как код

Компания движется путем реализации направлений DevOps/ARCH/Sec как код. Мы реализуем:
* архитектуру как код,
* инфраструктуру и CMDB как код,
* угрозы как код.

Расскажем о том, как мы к этому пришли, как это объединило команды IT/ARCH/Sус и каким мы увидели наш технологический ландшафт благодаря реверс-подходу. И как модель угроз легла на реальный технологический ландшафт.

Поделимся планами развития.

Доклад принят в программу конференции

Secrets Management в зависимости от зрелости инфраструктуры компании: как понять, что пора переходить на новый уровень

Рано или поздно компания приходит к тому, что нужно как-то централизованно хранить и защищать чувствительные данные: пароли, ключи, токены и прочее.

При этом нужно учитывать тот факт, что в определенный момент, кроме централизованного хранения, встает вопрос управления этими данными: управление доступами, выделение ответственных лиц, ведение аудитных логов, версионирование. При этом важно не забыть про удобство управления, изменения и распространения.

Компании все разные. Где-то всего одна-две продуктовые команды, которые, в принципе, не знают, зачем им вообще как-то централизованно хранить секреты и тем более не задумываются об их версионировании и управлении доступами, т.к. все имеют доступ везде. Другие компании уже прошли все этапы принятия неизбежного и дошли до уровня, когда столкнулись со всеми особенностями управления секретами.

Мы с вами вместе пройдемся по этапам роста компании, которая уже приняла Kubernetes как неизбежное и столкнулась с проблематикой Secrets Management, рассмотрим различные подходы и инструменты, которые помогут в решении этой проблемы, выделим плюсы и минусы этих подходов, а также варианты их комбинаций.

В частности:
* посмотрим, почему не стоит хранить секреты в открытом виде в Git;
* уберем секреты в переменные CI/CD-инструментов (Gitlab, Github, Jenkins и т.д.);
* захотим все-таки хранить секреты в Git, но зашифруем (SOPS, Sealed Secrets);
- вспомним о проблеме хранения ключей шифрования (Yandex Lockbox, CI/CD, AWS KMS и другие).
* подрастем до Hashicorp Vault;
* рассмотрим интеграцию с CI/CD tools и GitOps Tools;
* использование Vault Injector;
* External Secrets Operator;
* наши разработчики придут до интеграции приложений напрямую с Vault.

Доклад принят в программу конференции

Куда (и как) встроить SAST-решение?

Непрерывная интеграция
Управление изменениями
Управление уязвимостями
Поддерживаемый код

Раздражающая правда жизни – писать код тяжело, а гарантировать его безопасность и защищённость зачастую ещё сложнее. Добиться высокого качества программы можно, только используя сочетание различных методик. При этом желательно не потратить на тестирование слишком много сил и нервов команды.

Статический анализ (или SAST-решение) является одним из помощников в тестировании приложений. Главное преимущество статического анализа состоит в возможности существенного снижения стоимости устранения дефектов в программе и гарантированном полном покрытии кода.

В докладе мы поговорим о том:
* как понять, получают ли команды пользу от SAST-решения, и окупается ли оно на конкретном проекте (и это будет интересно менеджерам проектов);
* как SAST-решение, в конце концов, внедрить в пайплайн, и на какую его стадию (и это будет интересно для DevOps-инженеров).

Доклад принят в программу конференции

DevOps практики и культура (25)

От доработки Helm к разработке Nelm: эволюция развертывания в werf

Непрерывное развертывание и деплой
Автоматизация разработки, доставки, эксплуатации
DevOps / Кубер

Как мы поняли на практике, что должен уметь инструмент для развертывания. Почему в итоге отказались от Helm в качестве подсистемы развертывания для werf и начали разработку Nelm — обратно совместимой альтернативы Helm.

Расскажем о наиболее значимых улучшениях по сравнению с Helm:
* отображение плана изменений — какие изменения действительно произойдут с ресурсами при развертывании;
* выкат ресурсов последовательно группами или параллельно на основе дерева зависимостей;
* продвинутое отслеживание готовности ресурсов, в том числе автоматическое отслеживание даже неизвестных Custom Resources;
* отображение статуса ресурсов, логов и эвентов во время развертывания;
* решение всех проблем Helm, приводящих к некорректным обновлениям ресурсов;
* полноценная поддержка CRD и множество других исправлений и улучшений.

Поговорим о наших долгосрочных планах и о новой функциональности, которая появятся в ближайшее время.

Доклад принят в программу конференции

K8s-операторы для СУБД: быстро готовим сотни стейджей

Непрерывное развертывание и деплой
Непрерывная интеграция
Эффективное использование облаков
DevOps и аутсорсинг
Автоматизация разработки, доставки, эксплуатации
DevOps / Кубер

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

Для решения данных ограничений мы используем kubernetes operator, который работает с нашими окружениями в процессе CD и во время эксплуатации. Наш оператор называется Базовозик и может создавать новые базы managed postgresql и managed redis в облаках, ориентируясь на аннотации деплойментов Kubernetes.

* В чём плюсы такого подхода, и почему мы не используем для этого sidecar-контейнеры, которые деплоятся вместе с приложением?
* Как мы интегрировали между собой git, доску задач и окружение?
* Масштабирование, включение и выключение компонентов отдельных окружений, как это реализовано и как этим можно управлять?

Доклад принят в программу конференции

CUE — лучшая альтернатива для работы с манифестами K8s

API
Прочие языки
Управление конфигурацией
Непрерывное развертывание и деплой
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
Непрерывная интеграция
DevOps и аутсорсинг
Микросервисы
DevOps / Кубер
Инфраструктура
Георгий Абрамов

АО "СберТех"

На сегодняшний день микросервисная архитектура находится в самой активной стадии своего развития. При масштабировании увеличивается и число манифестов, с которыми необходимо работать инженерам. Но как структурировать такой объем конфигураций?

Расскажу, как упростить работу с K8s-манифестами с помощью инструмента CUE, о его основных преимуществах, его реализации в больших проектах и сравню с уже активно используемым Helm.

Доклад принят в программу конференции

Как мы меняли DevOps в телекоме

* Расскажу, как изменился DevOps в кластере телеком после начала экосистемной трансформации МТС.
* Покажу, как новая оргструктура поддерживает этот переход, и чем обоснованы перемены в CI/CD-стеке.
* На примере телекома объясню, какие DevOps-практики помогли нам улучшить свои процессы и сократить TTM.
* Расскажу, как работа с внутренним комьюнити помогает актуализировать компетенции инженеров и собирать обратную связь при внедрении изменений.

Доклад принят в программу конференции

DevOps приходит в 1С

1. Кому нужен этот ваш CI/CD — критерии и ценность.
2. Инструменты (накручиваем шаг за шагом).
3. Боль и страдания:
3.1 Боль заказчика.
3.2 Боль разработчика.

Доклад принят в программу конференции

DevOps для 1C-приложений

В докладе рассмотрим организацию доставки изменений в информационных системах на 1С в соответствии с современными требования IT-аудита. Как ОneScript может помочь командам, разрабатывающим приложения 1С на обычных и управляемых формах, быстро внедрить CI у себя.

Расскажу, какие инструменты существуют для построения сборочной линии и какие выбрали мы: Gitlab, Allure Testops, SonarCube, Gitsync, Vanessa, Vault, Grafana и Prometheus. Наш СI (подготовка, сборка, тестирование и деплой). Обсудим наш флоу разработки — без функциональных веток, с хранилищем 1С — и как это все можно мониторить.

Доклад принят в программу конференции

DevOps в металлургии, история про большие и сложные задачи IТ в производственной отрасли

Сложные и интересные задачи существуют только в сфере IТ? В своем докладе я постараюсь вас переубедить. Расскажу про задачи и проблемы, которые существуют у крупного производственного бизнеса. Покажу, как мы на протяжении нескольких лет решаем эти проблемы, как и какие инструменты используем, каких результатов достигли и какие задачи еще впереди.

Доклад принят в программу конференции

Руководство по внедрению практик и процессов на примере Trunk Based Development

Методологии и процессы разработки ПО; Сроки и приоритеты
Управление / другое
Управление командой
Управление разработкой
Трансформационные изменения
Agile / Scrum
Злата Занина

Независимый эксперт

Итак, вы задумались, что в вашей команде пора что-то менять. Или у вас есть потребность что-то улучшить в процессах. В общем, вам нужно внедрить какую-то гибкую практику и изменить процессы в вашей команде.

В своем докладе я расскажу вам, как подойти к реализации этой задумки системно и организованно. Рецепт проверен на моем опыте в двух больших компаниях с более чем 1000 сотрудников IТ.

Доклад принят в программу конференции

Как DevOps влияет на эффективность организации?

Devops / другое
Время разработки и поставки задач
Автоматизация разработки, доставки, эксплуатации
Евгений Харченко

Райффайзен Банк

В своем выступлении я расскажу, как в Райфе с помощью DevOps-сообщества мы пришли к тому, что нужно проводить внутренние исследования инженерной культуры.

• Поговорим про то, как строился процесс исследования: какую модель исследования мы взяли, какие гипотезы строили и как научились измерять культуру, а также как смогли показать, как практики влияют на производительность компании.
• Обсудим, что из всего этого мы получили и какие инсайты открыли.
• Поговорим про выводы.

Доклад принят в программу конференции

Древние свитки CI/CD: смыслы, которые мы потеряли

Devops / другое
Практики программирования
Время разработки и поставки задач

Аббревиатура CI/CD стала банальностью за последние несколько лет. Тема, казалось бы, настолько изъезжена и тривиальна, что недостойна внимания. Но дьявол кроется в деталях.

В докладе расскажу об идеях CI/CD, которые часто остаются за бортом, превращая ценный набор практик в карго-культ.

Доклад принят в программу конференции

Kubernetes vs Mesos: как мы кластер из 240 микросервисов мигрировали в кубер из mesos/marathon

Микросервисы
DevOps / Кубер

* Сравнение: как кубер, который вроде бы так же жонглирует контейнерами, работает значительно стабильнее.
* Подводные камни, с которыми столкнулись, — проблемы с DNS и прочие.
* Кишки решения — ansible-скрипты, пайплайны и прочее.
* Как и почему мы пришли к такой жизни.
* Плюсы и минусы.

Доклад принят в программу конференции

«Кровавый» GitOps на ArgoCD. Истории практической реализации на крупных проектах

Мой доклад — это наша история внедрения практик GitOps: от внутренних инфраструктурных задач до применения в промышленной эксплуатации на основных системах компании.

Для практической реализации GitOps мы выбрали ArgoCD. При этом во время внедрения наступили на множество «граблей», изобрели свои собственные «велосипеды» и в полной мере познали тёмную сторону GitOps: реальная жизнь оказалась не такой сказочной, как в многочисленных обзорных статьях, которые мы прочитали до того.

Чтобы решить поставленные задачи, нам пришлось научиться работать с большим количеством сервисов — с сотнями как с единым целым. Вокруг этого выстроили свои собственные решения и в итоге получили проработанные внутренние процессы и сервисы. Они основаны на кирпичиках Open Source и склеены внутрикорпоративными требованиями и особенностями.

Используемый технический стек: ArgoCD, GitLabCI, Kubernetes, Jenkins

Основные вопросы моего доклада:
* подход к релизному циклу для сотен сервисов — от dev до prod;
* Argo CD Config Management Plugins и интеграция с Hashicorp Vault;
* переиспользование Helm Template и Values через Config Management Plugins;
* автоматизированное тестирование и развертывание приложений ArgoCD;
* основные проблемы внедрения практик GitOps и поиск оптимального решения.

Обо всём этом постараюсь успеть рассказать в докладе :)

Доклад принят в программу конференции

От молекул до галактики. Организация общего пространства для Ansible-контента

В нашей компании множество департаментов. И в большей части из них используется автоматизация на базе Ansible. Почти везде разные нужды и подходы: кому-то нужен Docker, кому-то — Java, а третьим важен набор системных пакетов. Нередко возникают ситуации, когда автоматизация, необходимая сразу нескольким командам, пишется по-разному и несколько раз.

Появилась потребность в унификации подхода работы с Ansible. Для этого мы запустили рабочую группу и создали единое пространство для Ansible-контента, где каждый может взять наработки своих коллег или же поделиться своими находками с инженерами из других департаментов.

В своём докладе я расскажу о том, какие есть возможности для распространения ролей, что необходимо для подключения автоматической сборки документации, какие Self-Hosted-сервисы позволяют хранить Ansible-контент, каким образом можно настроить тестирование Molecule и не уничтожить сервер и как мы в YADRO перешли от кучи приватных репозиториев к единому открытому проекту для Ansible-решений.

Доклад принят в программу конференции

Почему я виню no blame culture

Devops / другое
Время разработки и поставки задач
Доверие команды внутри и снаружи
Безопасная коммуникация, культура
Кирилл Пономарев

Райффайзен Банк

Каждый день мы общаемся с коллегами. Иногда бывает так, что по чей-то ошибке происходит авария. Один забыл указать правильный конфиг, другой решил перезагрузить сервер,третий решил «сейчас тут быстро поправлю и будет хорошо». Что делать? Стоит ли сказать коллеге, что он плохо работает и вообще не понимает, что делает? Конечно, нет — каждый имеет право на ошибку. Этим и руководствуется такой культурный паттерн, как «no blame culture».

Данный культурный аспект говорит о том, что не надо выделять виноватых людей. Проблемы случаются и вместо того, чтобы «тыкать» пальцем, следует проанализировать ситуацию и решить, что сделать, чтобы ситуация не повторилась.

Но что, если это выходит за рамки? Что, если все конфликты и проблемы покрываются этой культурой и не находят решения? Что, если человек не хочет исправляться, а ему потакают?

Я хочу обсудить, почему практика «no blame culture» не всегда хороша:
* как мы пересекаем ту черту, когда она перестает работать и скрывает плохие конфликты. Обсудим, когда конфликты хорошо, а когда — плохо, и что можно вынести из хороших конфликтов;
* как практика влияет на культуру команды, а культура — на ее эффективность. Посмотрим в цифрах влияние культуры на производительность;
* немного поговорим о «no blame culture» и бирюзовых компаниях, а еще почему бирюза не такая классная, как думается.

Доклад принят в программу конференции

Объединяй и властвуй: как объединить два кластера K8s без даунтайма

В докладе я раскрою тему оптимизации инфраструктуры, снижения ее стоимости и повышения безопасности трафика внутри периметра путем поэтапной подготовки объединения нескольких K8s-кластеров и тонкой фильтрации трафика.

Доклад принят в программу конференции

Envoy Proxy — один за всех Load Balancer

В современной инфраструктуре нет недостатка в решениях для балансировки и межсервисных коммуникаций. Почти все используют Nginx, HAProxy, есть адепты Treafik, а публичные облака предлагают LB как сервис.

Но что делать, если текущие инструменты не справляются с ростом масштабов и нужно автоматизируемое cloud-native-решение? На помощь может прийти Envoy Proxy.

В докладе обсудим:
* основные термины и топологию Envoy,
* статическую и динамическую конфигурацию Envoy,
* фильтры Envoy,
* Envoy control plane,
* типовые кейсы перехода на Envoy.

Доклад принят в программу конференции

Храним секреты для прода в 1password

Во всех компаниях от мала до велика рано или поздно поднимается важный вопрос — где хранить секреты для продакшна и как их подгружать в развернутое приложение?

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

В этом докладе я расскажу про далеко не самый популярный способ хранения секретов: 1password.

Из доклада вы узнаете:
* как настроить хранение секретов в 1password с помощью helm secrets (дам пошаговую инструкцию);
* как все это упаковать в Argo CD;
* какие плюсы и минусы есть у данного решения.

Доклад принят в программу конференции

DevOps без ClickOps. Как terraform и gitlab ускорили нам деплой инфраструктуры в 20 раз

Непрерывное развертывание и деплой
Эффективное использование облаков
Автоматизация разработки, доставки, эксплуатации
Облака

Что делать, если деплой инфраструктуры в ручном режиме занимает десятки часов, а хочется, чтобы все работало по кнопке автоматически? В докладе расскажу, как мы ускорили деплой ML-инфраструктуры в 20 раз, используя terraform.

Что вас ждет:
1) рассмотрим плюсы и минусы terraform как единого инструмента деплоя;
Поговорим про хранение стейта инфраструктуры, идемпотентность, динамически создаваемые переменные и секреты и т.д.;
2) обсудим способы, как управлять зависимостями (helm-чарты, инфраструктура) при деплое большого окружения;
3) увидим, как убрать узкие горлышки и минимизировать ручную работу.

Доклад принят в программу конференции

Всё идёт по плану. Как запускать Ansible вовремя так, чтобы все были довольны

Управление конфигурацией
Непрерывная интеграция
Devops / другое
Автоматизация разработки, доставки, эксплуатации

На рынке существует не так много инструментов для запуска Ansible по расписанию, а материалов, предлагающих сравнить их между собой, еще меньше.

Чаще всего выбор осуществляется «по знакомству» или «по рекомендации»: что-то видели раньше, что-то посоветовали, что-то будет просто быстрее развернуть и настроить.

В ходе выступления я расскажу про основные преимущества систем и сравню уже существующие решения с теми, которые инженер может собрать сам, «на коленке». Поговорим про запуск Ansible из web ui и исполнение плейбуков и ролей по расписанию.
Если уж автоматизировать Ansible, так до конца:
* сверим функционал: что умеют, а что не умеют web-панели для работы с Ansible;
* атака Титанов: монструозный AWX;
* проезд разрешен: прелести использования Semaphore;
* старикам у нас везде дорога: неочевидная связка Foreman и Ansible;
* Last but not least: Rundeck, PoleMarch и прочие инструменты.

Доклад принят в программу конференции

Архитектура поставки: как мы боролись за качественный деплой

Управление конфигурацией
Непрерывное развертывание и деплой
Менеджмент в эксплуатации
Непрерывная интеграция
Управление изменениями

Многие компании идут в крайности в вопросе управления деплоем. Кто-то идет по модели «дикого Запада» и в процессе эволюции получает высокие косты владения девопс-процессами. Другие, стремясь к унификации и стандартизации, создают сложные и непрозрачные процессы, которые могут «убивать» Т2М.

Мой доклад будет интересен тем, кто занимается построением и оптимизацией девопс-процессов в крупных компаниях. Я расскажу о недостатках подходов, основанных как на максимальной независимости команд разработки, так и на унификации, и стандартизации, а также о способах найти золотую середину.

Доклад принят в программу конференции

Рассказ о том, как мы внедряли IAC для электрических автономных грузовиков

Внедрение процесса непрерывной поставки и практик IAC в условиях, когда продакшн-сервера ездят по дорогам и теряют связь с сетью. CI/CD в экстремальных условиях.

Доклад принят в программу конференции

NextOps — что будет после DevOps

Devops / другое
DevOps / SRE

DevOps как термин и профессиональное движение появились 15 лет назад, самое время подвести итоги и посмотреть, что будет дальше.

В докладе я расскажу, что будет после DevOps, будет ли вторая волна, появились ли новые лидеры, сообщества и организации. Обсудим тренды и нерешенные проблемы в разработке и эксплуатации, новые подходы и инструменты. Разберем исследования, публикации и отчеты, книги и конференции, компании и экспертов. Рассмотрим такие направления, как Platform Engineering, Developer Experience, Internal Developer Platforms, Productivity Engineering, DevTools 2.0, ClickOps, AIOps, Cloud Native, Reliability Engineering, Resilience Engineering, Team Topologies.

Доклад принят в программу конференции

DevOps в Сбере — ретроспектива 2017 – 2024

В этом докладе мы ретроспективно взглянем на то, как развивался DevOps в Сбере с 2017 года. Какие практики и подходы применялись, как они повлияли на метрики, команды, процессы и инструменты. На какие грабли мы наступили, какие надежды оправдались, и какие решения привели к серьезным вызовам, с которыми пришлось столкнуться.

В частности, посмотрим на DevOps в цифрах, как происходило внедрение Project DevOps, разберем практики DevSecOps и Quality Gates, принципы DORA CALMS, запуск и развитие DevOps Community, переход к DevOps as a platform way и многое другое.

Доклад принят в программу конференции

«Conan-варвар»: как мы масштабировали разработку автономных машин и зафакапились

Непрерывное развертывание и деплой
Непрерывная интеграция
Управление изменениями

Расскажу, какой путь мы прошли, внедряя технологии при росте компании от стартапа до полноценного бизнеса. Как мы иногда на это тратили много ресурсов и ничего не получали. Хотя, на самом деле, не совсем ничего — и об этом доклад! Поделюсь, какие проблемы мы сами себе создавали и какие выводы сделали.

Доклад будет про DevOps-философию и про то, почему важно лидам и разработчикам применять её в своей работе.

Доклад принят в программу конференции

Тестовая инфраструктура «Так исторически сложилось»

Представьте, что вам отдают в один день всю тестовую инфраструктуру, которую делали порядка 5-7 лет, и говорят, что она работает плохо, а надо, чтобы работала хорошо. Через боль и страдания, спустя один год мы сделали хорошо. Что же мы сделали?

В докладе поговорим о четырех самых важных моментах в любых процессах:
* о метриках. Какие собирали, как собирали, к чему пришли;
* об архитектуре. Какая была, как ее строили, как перестраивать и как эволюционно готовиться к техническим реформам;
* о процессах вокруг тестовой инфраструктуры. О хороших и не очень практиках в процессах;
* о людях, которые участвуют в метриках, архитектуре и процессах.

Доклад принят в программу конференции

Практики управления в Devops (5)

Как навести порядок в горящем проекте

Менеджмент в эксплуатации
Работа со внешним заказчиком/исполнителем
Teamlead
Коммуникация
Управление проектами
DevOps и аутсорсинг

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

В своем докладе я расскажу о нескольких простых шагах, которые помогут:
* потушить пожары;
* установить взаимопонимание с окружающими;
* вернуть предсказуемость в работу;
* и в целом сделать работу более спокойной.

Доклад принят в программу конференции

Как быстро создать dev-среду в K8s на основе ArgoCD

Управление конфигурацией
Непрерывное развертывание и деплой
DevOps / Кубер
Инфраструктура

Расскажу про один из вариантов организации dev-окружения в Kubernetes, который является относительно простым и быстрым в реализации.

* Автоматический деплой feature-ветки через ApplicationSet с SCM Provider Generator в ArgoCD.
* Конфигурация приложений через Consul и Vault.
* Организация репозиториев и CI при GitOps-подходе.
* Жизненный цикл feature-ветки и ресурсов, относящихся к этой ветке.

Доклад принят в программу конференции

Неизбежность, или Как приучить Devops-инженеров к проектированию

DevOps-инженеры легко становятся заложниками одной из двух моделей восприятия:
1) Задача DevOps — автоматизировать процессы, чтобы быстрее поставлять ценность конечному потребителю (при сохранении или росте качества), а значит DevOps’ы должны отвечать и за то, какую ценность несет поставка. То есть думать о бизнесе, стратегии и поддержке процессов разработки!
2) Задача DevOps — закрыть на уровне инфраструктуры все проблемы, которые можно снять с плеч разработки и бизнеса, чтобы те сосредоточились на «действительно важном». То есть решать проблемы, не задавать вопросы, подставлять «инфраструктурные костыли».

Но я предлагаю рассмотреть DevOps-инженера, как одного из «проектировщиков» компании — обязательного участника архитектурных комитетов, ответственного за полноту представляемых решений и экспертизу.

В докладе я хочу показать, каким суперзрением должен обладать человек, занимающийся проектированием. Разобрать кейсы, в которых «губительными» могут стать решения «латать инфрой и руками DevOps» имеющиеся проблемы.

Мы рассмотрим 5 видов зрения, которыми должен обладать проектировщик: бизнес, системное, интеграционное, инфраструктурное и управленческое видения. Разберем на примерах, как связаны эти вижны между собой и с какими задачами помогают справиться. А также обсудим, как откалибровать зрение с помощью метрик.

Поделюсь опытом включения DevOps-инженеров в практики архитектурных решений (включая участие в формировании артефактов ADR и ADL — продемонстрирую шаблоны), инцидент-менеджмента (включая контроль PIR — поделюсь шаблоном), формирования корпоративной библиотеки инструментов.

Доклад принят в программу конференции

Как мы перешли от аутсорса и создали эффективную команду DevOps

Непрерывное развертывание и деплой
Менеджмент в эксплуатации
Управление изменениями
Логи, метрики, ошибки

Представьте, что в вашей компании работают несколько подрядчиков-аутсорсеров: одни предоставляют услуги DevOps, другие — услуги разработки. Изначально их работа вас полностью устраивает. Однако с ростом компании растут требования и количество задач для аутсорсеров. В какой-то момент баланс стоимости и профита рушится, и компания решает перенести все, что было на аутсорсе, к себе. В момент решения мне доверили направление DevOps + SRE.

Доклад будет полезен тимлидам и руководителям отделов. Расскажу, как нам удалось за 1 месяц полностью пересмотреть работу команд DevOps, с помощью каких метрик мы нашли свои точки роста и как достигли 99% попадания в оценки по задачам от команд разработки.

Доклад принят в программу конференции

Из огня да в полымя: налаживаем работу подразделения DevOps при помощи сервисного подхода

Методологии и процессы разработки ПО; Сроки и приоритеты
Управление изменениями

Приходя в компанию, ты всегда начинаешь изучать: какие процессы, культура и технологии в ней используются. Ты смотришь на допустимые уровни трансформации и готовность команд к изменениям на пользу компании, параллельно с её ростом.

Отловив насущные проблемы, потушив самые пламенные пожары и внедрив, хоть и со скрежетом, процессы «DevOps as a Service», начинаешь размышлять о следующих шагах развития данной модели.

Совместив знания и опыт itsm, dasa devops, maturity matrix, DevOps governance, westrum, kanban, картинка дальнейших шагов начинает складываться. А те решения, которые могли показаться спорными или неоптимальными, остаются в прошлом или претерпевают изменения.

Повествование пойдёт о том, как на примере компании Bimeister поэтапно осуществилось внедрение DaaS. Какие сложности ждали на этом пути, какие решения были изначально верными, а какие спорными, к чему это привело и какие мысли о будущем посещают сейчас.

Доклад принят в программу конференции

Reliability Engineering (11)

Эволюция DNS в VK

Надёжность продакшена
DevOps / SRE
Инфраструктура

Расскажу, как мы строили сервис DNS, способный выдерживать десятки миллионов запросов в секунду и не деградировать. Как не нагружать NXDOMAIN'ами бэкенды. Как потерять все бэкенды и при этом продолжить корректно отвечать на запросы. Поговорим про эволюцию DNS в компании: как мы прошли путь от нескольких серверов, торчащих непосредственно в мир, до сложной многоуровневой схемы с сотнями инстансов. Рассмотрим, как мы используем dnsdist для балансировки нагрузки, фильтрации запросов и создания гибких правил управления DNS-трафиком.

Доклад принят в программу конференции

Как внедрить телеметрию в on-premise-инфраструктуре

Скорее всего, вы уже знаете, что такое телеметрия и зачем она вам нужна. Если нет, то узнаете из моего доклада. А еще о том, какие инструменты могут вам помочь в деле формирования, сбора, хранения и отображения данных телеметрии. Также расскажу вам, какие инструменты не могут помочь, если у вас on-premise-инфраструктура и нет облаков. Немного поиграем в конструктор и соберем решение из разных деталей. Потом разберем и снова соберем, но уже из других. В очередной раз переработаем архитектуру решения под множество окружений — и наконец получим результат.

Доклад принят в программу конференции

История отказа ceph. Как была потеряна часть данных

Управление конфигурацией
Devops / другое
Техдолг
Управление инцидентами
Надёжность продакшена
Инфраструктура

Ceph - это большой, сложный программный продукт, требующий не только глубоких знаний о нём, но и о сопутствующих вещах. Непонимание некоторых процессов, недостаток опыта или невнимательность могут привести к большим проблемам.

В докладе разберём ситуацию отказа ceph и потери части данных. Почему это произошло, какие ошибки были допущены в изначальном проектировании и в эксплуатации, какие действия пришлось предпринять, чтобы всё починить. Разберём нетипичные решения, которые пришлось применить для восстановления работоспособности и данных.

В конце поговорим, как можно было этого избежать, на что стоит обращать внимание, а также дам рекомендации по эксплуатации и проектированию ceph.

Доклад принят в программу конференции

Логи: как EFK нас довел... до Vector и Clickhouse

Логирование и мониторинг
Автоматизация разработки, доставки, эксплуатации
DevOps / SRE

Когда-то мы впервые сталкиваемся с логами. Обычно это просто файл, содержащий данные о работе программы. Кто из вас слышал фразу «погрепать логи»? Так вот, это работает до сих пор во многих случаях. Но всегда ли это удобно? Конечно, нет.

В докладе я поделюсь, как построить удобную и производительную централизованную систему сбора и хранения логов на основе Vector. dev, Kafka и Clickhouse, позволяющую экономить на ресурсах и обслуживать высоконагруженные приложения.

Ссылка на материалы использованные в докладе https://github.com/vseinstrumentiru/devopsconf2024/blob/main/resentation-from-efk-to-vector-and-clickhouse/references.md

Доклад принят в программу конференции

Кто возьмет метрик пачку, тот получит ресурсов недостачку...

Логирование и мониторинг
Devops / другое
Эффективное использование облаков
Observability в enterprise
Логи, метрики, ошибки
DevOps / Кубер
DevOps / SRE

Сложно представить себе современный проект без эффективной системы мониторинга, и в этом контексте Prometheus выделяется как стандарт де-факто.

В своем докладе я проанализирую, почему Prometheus потребляет столько ресурсов и расскажу, как можно этого избежать. Начнем анализ с изучения механизмов хранения серий данных в Time Series Database (TSDB) Prometheus. Особое внимание уделим тому, как выбор метрик, отправляемых в Prometheus, влияет на потребление ресурсов системы.

Затем перейдем к обсуждению различных подходов и инструментов, которые могут помочь оптимизировать работу Prometheus. Основной задачей будет найти баланс между сокращением потребления ресурсов и сохранением информативности и полезности данных, хранящихся в системе.

Эти аспекты являются ключевыми для обеспечения эффективного и экономичного мониторинга в современных проектах.

Доклад принят в программу конференции

Мониторим надежность бизнес-процессов с помощью Opentelemetry и Jsonnet

Логирование и мониторинг
Надёжность продакшена
Михаил Морев

Райффайзен Банк

В Райффайзен Банке только и разговоров, что о надежности и устойчивости. Все говорят о том, как чертовски здорово наблюдать за дашбордами с доступностью не просто микросервисов и монолитов, а бизнес-функций для конечного пользователя. Поговорим и мы с вами!

Вы наверняка тоже много раз слышали про надежность и устойчивость, но до сих пор не все знают, что именно они означают на практике, а главное — как их измерять. А те, кто знают, делают это по-разному. Поэтому в программе доклада:
* Надежность и устойчивость — это еще не метрики. Что же мы тогда измеряем?
* Доступность как комплексная метрика и ее производные.
* Два подхода к измерению доступности приложений.
* Что такое SLI, SLO и SLA.
* Автоматизация дашбордов Grafana с помощью Jsonnet.

Доклад принят в программу конференции

Как мы вырастили отказоустойчивость Яндекс Go

Архитектурные паттерны
Отказоустойчивость
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
Антикризисный менеджмент
Надёжность продакшена
Микросервисы
DevOps / SRE

Яндекс Go — это система из 800 микросервисов. Два года назад перед нами встала задача сильно вырастить аптайм всей системы.

Основа доклада — это шесть челленджей по росту аптайма, как мы с ними успешно справлялись и какие ошибки совершали.

Будет обзор наших практик (митигации и др), технологий (chaos engineering и др), архитектурных паттернов (DOMA и др), процессов (инцидент-менеджмент и др) и ментальных моделей (metastable failure state и др). Будет много ссылок для углубленного изучения этих аспектов.

Буду объяснять все на выдуманных примерах инцидентов, но на основе реальных событий.

Доклад принят в программу конференции

Distributed Observability

Распределенные системы
ClickHouse
Observability в enterprise
Максим Залысин

Positive Technologies

Представьте, что у вас инфраструктура поделена на множество сетевых сегментов, имеющих слабую связанность, и не из каждого можно «выйти», а мониторинг нужен везде. В таких условиях организовать надежную наблюдаемость привычными средствами с централизованным хранением и выводом телеметрии (метрики, логи, трассировки) становится сложно и дорого. А ещё, представьте, вы создаете сложные продукты, поставляемые в изолированные контуры инфраструктуры клиента, и там тоже нужен мониторинг.

В докладе будет:
* как и, главное, зачем связкой "Vector > ClickHouse < Grafana" собирать инфраструктуру Observability;
* как форматировать и сколько хранить телеметрию;
* как SQL’ем работать с телеметрией и выводить её в Grafana;
* как организовать централизованный доступ к данными телеметрии;
* насколько Vector готов к бою, а ClickHouse — к большим объемам телеметрии.

Доклад принят в программу конференции

Инженерия устойчивости как основной инструмент выживания вашей организации: история, подходы и примеры внедрения

Отказоустойчивость
Методы и техника разработки ПО
Архитектуры / другое
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
Модели руководства
Антикризисный менеджмент
Поддержка и развитие legacy систем
Управление изменениями
Управление инцидентами
ROI DevOps трансформации
Надёжность продакшена
Теория
Расширение кругозора
Сергей Реусин

СберМаркет

В докладе представлю историю инженерии устойчивости, разницу определений и методов в сравнении с надежностью, стабильностью. Расскажу о применении DORA за рамками ускорения деплоев. Узнаете о ключевых принципах, персонах и сообществе, а также о пересечении методов с другими доменами (медицина, энергетика и т. п.). Как происходило внедрение в СберМаркет — ключевые цели, этапы, успехи и провалы. С чего начать в вашей организации.

Доклад принят в программу конференции

Kafka. Деградировавший кластер, или 168 часов траблшутинга

Распределенные системы
Обработка данных

Мы используем высоконагруженный кластер Kafka для обработки входящего потока логов в Sage, собственной платформе мониторинга Тинькофф. В докладе я поделюсь опытом траблшутинга кластера в момент деградации производительности. Расскажу про методы поиска узкого места и использованный инструментарий. В докладе будет минимум информации по API клиентской части, напротив, будет сделан фокус на работе кластера и брокеров под капотом. Мы пройдем весь пайплайн внутри брокера Kafka: от записи данных в сетевой сокет до сброса обработанных данных на диск.

Доклад принят в программу конференции

SLO: одно уравнение, множество ответов

Надёжность продакшена
Теория
DevOps / SRE
Кирилл Борисов

VK, VK Реклама

В своей практике я много раз встречал кейсы, когда к выбору и подсчету SLO подходят, как к самоцели — насчитать 99.99 и забыть, что это не просто цифра, а инструмент обеспечения качества сервиса.

Специально для всех, кто хочет не запутаться и разобраться в тонкостях правильного выбора SLO, при этом не попасть в «закон Гудхарта», я подготовил доклад, в котором вместе поговорим про:
* определение SLO и его значение в контексте предоставления услуг;
* обзор типов SLO (ведь это не только про известные всем Availability, Latency) + примеры кейсов;
* почему выбирать правильные типы SLO важно: как это влияет на производительность сервиса и NPS пользователей;
* определение требований пользователей, бизнеса и команды;
* согласование типов SLO с разработчиками и командой эксплуатации;
* значимость SLO. Как не допустить превращение в «цифру, к которой все стремятся», и не забыть о том, что это действительно важный инструмент для улучшения доступности?

Доклад принят в программу конференции

Рост и развитие специалиста (4)

Как организовать базу знаний так, чтобы даже новичок-джун всё смог найти сам?

Онбординг и прокачка новичков — головная боль лида всегда. Как не отвечать на лишние вопросы при помощи верной организации базы знаний — вопрос, на который я постараюсь дать подробный ответ.

Доклад принят в программу конференции

Как расспрашивать экспертов, чтобы развиваться профессионально?

Soft Skills
Личное развитие
Татьяна Кыркалова

Независимый исследователь

Задача доклада — научить задавать вопросы экспертам, с помощью которых специалисты смогут профессионально развиваться.

Участники конференции узнают:
* о типовых ошибках: почему люди боятся и не умеют задавать вопросы?
* о неочевидных рекомендациях: как задавать вопросы экспертам, чтобы продвинуться по карьерному пути и вырасти профессионально?
* о темах, на которые можно расспросить эксперта.

Доклад принят в программу конференции

Как и чему учить в SRE

Я расскажу о программе курса по подготовке SRE, который с 2022 года читается в Школе Анализа Данных Яндекса.

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

Доклад принят в программу конференции

Что ты сделал для DevOps'а в свои годы... по мнению рекрутера

HR
Подбор команды

У каждого специалиста есть так называемый «цифровой портрет», который состоит не только из резюме на job-сайте или профиля в Linkedin. Помимо стандартных площадок, его формируют GitHub, Хабр, StackOverflow, Codeforces, сайты конференций, личные страницы, VK, FB, X, YouTube и куча других ресурсов.

Современные инструменты подбора (например, программы, которые автоматически интерпретируют GitHub-профили) сейчас позволяют рекрутеру быстро собрать сведения о кандидате со всех площадок, составить свое мнение о «реальном опыте» и на основании этого предложить ту или иную вакансию.

Нередко «цифровой портрет» не соответствует реальному опыту. Разные профили одного и того же человека содержат противоречащую друг другу информацию, например, о локации, опыте, интересах и т. д., и в таком случае этот специалист либо получает нерелевантные вакансии, либо рекрутеры его просто обходят и не предлагают ничего, опасаясь очередного хейта из серии «вы вообще мое резюме читали».

«Цифровой портрет» — это гигиенический минимум для того, чтобы самостоятельно формировать свой карьерный трек, а не просто откликаться на предложения.

Поговорим о том, какие площадки участвуют в формировании «цифрового портрета» и какой вес имеет каждая из них, как устранить противоречия в разных профилях, как сформировать портрет, не только отражающий реальность, но и показывающий рекрутерам желательные перспективы развития.

Доклад принят в программу конференции

Жизнь в облаках и без (4)

Управление горизонтальным автоскейлингом в on-premise-инсталляциях K8s

Масштабирование с нуля
Эффективное использование облаков
Микросервисы
Инфраструктура
Алексей Игнатов

АО "СберТех"

В докладе я расскажу, как мы сформировали требования к работе автоскейлера в фиксированных ресурсных квотах, как реализовали прототип на KEDA, как реализовали свой собственный автоскейлер и как с помощью нашего автосклейлера упростить сопровождение системы и сэкономить ресурсы.

Доклад принят в программу конференции

FinOps в Облаках

Управление конфигурацией
Эффективное использование облаков
Облака
Инфраструктура
Илья Кочнев

СберМаркет

Облака предоставляют огромное количество плюсов по сравнению с собственной инфраструктурой. Они позволяют быстрее выводить новые продукты на рынок, брать почти неограниченное количество ресурсов в любой момент времени, сокращать TTM. Но за все хорошее приходится чем-то платить. Обратной стороной облаков является существенно большая стоимость ресурсов ядра/памяти, чем на собственной инфре.

Этот доклад о том, как получать максимум от облачных решений и остаться в рамках разумного бюджета с помощью подходов FinOps. Ценный опыт и инсайты прилагаются.

Доклад принят в программу конференции

Переходим на мульти-ЦОД-архитектуру

Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
Администрирование баз данных
DevOps на собственном (арендованном) оборудовании

С ростом компаний растут и требования к надёжности систем. Многие сталкиваются с вопросом, как эту самую доступность обеспечивать. Чаще всего со стороны инфраструктуры используется схема 2-х ЦОДов active-passive, так было и у нас до определённого момента...

Доклад будет полезен тем, кто отвечает за доступность сервисов и ещё не сделал этого перехода. Расскажу про общие подходы, наши вызовы, ошибки и практические решения при переходе на мульти-ЦОД-архитектуру.

Доклад принят в программу конференции

Динозавр в магазине: опыт публикации YTsaurus в YC.Marketplace

Эффективное использование облаков
Хранилища
Обработка данных
Облака
DevOps / Кубер

YTsaurus — BigData-платформа с открытым исходным кодом от Яндекса. Кластер YTsaurus представляет собой сложную stateful-систему: в зависимости от настроек он содержит от 8 до 15 компонентов различного типа. Для упрощения развёртывания и управления кластерами YTsaurus мы разработали K8s-оператор, но даже при этом составление разумного yaml-манифеста и установка базовой инсталляции — кропотливая и непростая задача.

Чтобы привлекать пользователей, нужно снижать порог входа. Что может быть проще, чем вместо yaml-программирования заполнить несколько полей в интерфейсе Yandex. Cloud и получить кластер по кнопке? YC. Marketplace позволяет сделать именно это. Но как упихнуть трёхстраничный манифест в форму из нескольких полей? Какие грабли подложил нам helm? И чем примечательна константа 93Gb? Об этом вы сможете узнать из моего доклада.

Доклад принят в программу конференции

Сколько стоит свободное ПО (1)

Open Source как часть R&D

Методы и техника разработки ПО
Разработка библиотек, включая open source библиотеки
Расширение кругозора
Безопасность

* Open Source для корпорации или корпорации для Open Source – роль крупного бизнеса в развитии открытого кода и инструменты поддержки.
* Как корпорациям работать с Open Source - может ли эту проблему решить Open Source Programs Office?
* Экономика Open Source в примерах: как развивалась, какие проблемы возникли в процессе и методики для решения проблем.
* Open Source и безопасность кода.

Доклад принят в программу конференции

Big Data и Data Engineering (3)

Построение горизонтально масштабируемой системы обработки данных с беспилотного транспортного средства

Логирование и мониторинг
Администрирование баз данных
Devops / другое
Эффективное использование облаков
DevOps / Кубер
Инфраструктура

Self-driving-разработчикам необходимо иметь возможность легко и оперативно получать обработанные данные с проездов беспилотных автомобилей для развития технологии и решения множества разнообразных повседневных задач: вычисления метрик проездов, определения качества доработок, получения датасетов для обучения моделей, построения HD-карты, разметки целевых ситуаций с проездов и пр.

Перед нами была поставлена задача разработать пайплайны обработки и автоматической разметки логов проездов беспилотных автомобилей и предоставить удобные инструменты для доступа к этим данным.

Из доклада вы узнаете:
* как мы научились обрабатывать большой объем сериализованных данных с беспилотных автомобилей (130-150 Tb в сутки);
* какой Open Source-стек мы для этого выбрали;
* почему отказались от Apache Airflow и остановились на Dagster;
* где и как мы запускаем вычисления на Spark, а где обходимся Apache Arrow и Polars;
* чем нас не устроил стандартный планировщик Kubernetes, и чем мы его заменили (спойлер: Volcano);
* как мы реализовали автоматическую эволюцию схем табличных данных в Spark + Hive Metastore.

Доклад принят в программу конференции

MLOps: как не потеряться в 10 тысячах фич

Архитектуры / другое
Непрерывная интеграция
Hadoop
Machine Learning
Автоматизация разработки, доставки, эксплуатации
Автотесты
Инфраструктура
Инструменты

В архитектуре Data Mesh команды могут пользоваться данными других команд. Часто продукты зависят от качества данных нескольких команд. Пайплайны ломаются, данные дрифтят, и это не всегда можно оперативно отследить в чужих данных. Мы столкнулись с этим в аспекте подготовки фич для моделей машинного обучения.

В докладе я расскажу, как нам удалось эффективно отслеживать зависимости между фичами и ML-моделями и реагировать на инциденты в данных.

Доклад принят в программу конференции

Как создать ML-платформу по выводу 100 моделей в неделю

Непрерывное развертывание и деплой
Machine Learning
Управление разработкой
Автоматизация разработки, доставки, эксплуатации
Обработка данных
DevOps / Кубер
Инфраструктура
Обзор
Инструменты

Сфера машинного обучения постоянно развивается, команды разработки расширяются, а вместе с ними растет и число моделей. Также появляется и проблема удобства совместного труда и вывода гигантского количества моделей в production.

В докладе я расскажу о способах создания удобной среды разработки на основе платформы Kubernetes, ориентированной на команды с более чем двумя сотнями Data Scientists и Data Engineers, позволяющей выпускать более 100 моделей в течение нескольких недель. Данная платформа уже реализована в Альфа-Банке.

В этом докладе я поделюсь:
* какие сложности встречаются при работе с JupyterHub с большой командой;
* как объединить множество инструментов из жизненного цикла машинного обучения;
* где эффективно хранить и как использовать данные;
* как можно просто настроить вывод и переобучение не только отдельных моделей, но и целых ансамблей.

Доклад принят в программу конференции

Технологическая независимость (1)

ГосТех Cookbook

Евгений Коваленко

Лига Цифровой Экономики

Лига Цифровой Экономики первой столкнулась с необходимостью разобраться, как устроен «ГосТех» — цифровая платформа для консолидации государственных сервисов. Нашей целью было интегрировать с «ГосТехом» один из проектов Росимущества. Рассказываем, чему научил нас этот интересный опыт.

Доклад принят в программу конференции

Применение ИИ в Devops (1)

ChatGPT: декларативная автоматизация

Варвара Подольская

Независимый эксперт

1) Критерии автоматизируемой архитектуры в проектах:
* Как можно определить, что в проекте присутствует архитектура, почему это важно для автоматизации и сколько архитектур нужно проекту?
* Почему необходимо устранить всякую неопределенность в архитектуре перед началом написания/генерации кода ее автоматизации?
* Что такое изолированные модули в автоматизации, зачем это нужно и как влияет на работу с ChatGPT?
2) Требования к коду для оптимальной работы с ChatGPT:
* Какие атрибуты качества кода автоматизации необходимо учитывать и можно ли сгенерировать с помощью ChatGPT хороший код?
3) Эффективная постановка задачи для ChatGPT:
* Какие ключевые атрибуты ресурсов необходимы для их развертывания, являются они константами или переменными?
* Какие стратегии следует применять в ситуациях, когда кажется необходимым использовать переменные?
* Какие ключевые элементы следует учитывать при формулировке запросов к ChatGPT для получения эффективного и точного кода?
4) Бест практис в постановке задач для ChatGPT и не только.

Доклад принят в программу конференции

Актуальные практики инженеров эксплуатации (2)

Несколько реплик приложения — это отказоустойчивое решение?

Все хотят отказоустойчивые приложения, многие их пишут, а многие ли осмотрелись вокруг?

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

Доклад принят в программу конференции

Stateful в Kubernetes. Казнить нельзя помиловать!

Управление конфигурацией
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
Надёжность продакшена
Безопасность от планирования до эксплуатации
DevOps / Кубер
DevOps / SRE
Инфраструктура

Kubernetes, изначально созданный для stateless-приложений, претерпел изменения, адаптировавшись к работе со stateful-приложениями. В докладе мы рассмотрим историю развития K8s, изменения в оркестраторе и инженерных подходах, а также поясним, почему запуск stateful-приложений в Kubernetes стал более удобным и безопасным.

Размещение stateful- и stateless-приложений рядом друг с другом позволяет унифицировать подходы к разработке и управлению инфраструктурой и упростить работу инженеров. Однако запуск stateful-приложений требует внимания к ряду деталей — например, конфигурирования Persistent Volumes. И даже работая в Kubernetes с cloud native-приложениями вроде MongoDB, Kafka инженеры сталкиваются с многочисленными неочевидными нюансами. Поэтому разработчикам K8s и облачных инструментов необходимо дорабатывать имеющиеся решения, чтобы cloud native-экосистема созрела для подобного рода приложений.

Мы накопили солидный опыт эксплуатации различных stateful-приложений: Patroni, ELK, CH, Redis, MongoDB, RabbitMQ в Kubernetes — и на докладе подсветим ключевые особенности их конфигурирования, а также поделимся практическим опытом их использования в разных сценариях. После доклада слушатели смогут сформировать полное представление о текущем состоянии и перспективах работы со stateful-приложениями в Kubernetes и внедрить новые знания на практике.

Доклад принят в программу конференции

Митапы (1)

Fail-митап

Конференции завалены историями успеха. Но путь к успеху всегда лежит через фейлы, о которых рассказывать не принято. Но только не на нашем fail-митапе!

В своих коротких, но зажигательных выступлениях спикеры поделятся настоящими историями фейлов. Без записи, без трансляции, без комплексов.

Доклад принят в программу конференции

Круглые столы (3)

Облака, вендор или делать все самому? Как строить Platform Engineering в компании

Александр Титов

Экспресс 42

Сейчас к построению внутренних платформ в компаниях для cloud-native-приложений есть три подхода:
1) сделать самим,
2) использовать облако как основу платформы,
3) купить вендорское решение.

Мы пригласили руководителей из разных компаний, которые исповедуют разные подходы, поговорить об их опыте. Наша задача на этом круглом столе — понять, когда и почему какой подход применим и с какими сложностями вы столкнетесь на пути его имплементации.

Приходите, если вы еще не выбрали для себя подход и думаете об этом или выбрали, но хотите получить более широкий взгляд.

Доклад принят в программу конференции

Баттл «Стартап vs Корпорат vs Аутсорс? Выбираем следующего работодателя»

Ты сидишь и в очередной раз размышляешь о смене работы. Друг зовёт к себе в классный стартап, который «вот-вот станет убийцей Икс и вернет былой твиттер», бывший лид рефералит в крупнейший корпорат, в котором «наша команда и продукт вообще отдельно от основной компании, у нас тут всё иначе, вот увидишь!», а рекрутер неумолимо манит оффером в крупный аутсорс «с самыми адекватными клиентами и командами».

Дилемма...

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

А что если?..

Доклад принят в программу конференции

FinDevSecOps или безопасная разработка в финтехе: перспективы, вызовы и совместные планы

Управление уязвимостями
Observability в enterprise
Безопасность от планирования до эксплуатации
Максим Кожокарь

Центральный Банк Российской Федерации

Илья Шмаков

ПАО Росбанк

Безопасная разработка все больше и больше становится важной составляющей технологического ландшафта компаний.
Сообщество FinDevSecOps создано в 2023 году на площадке Ассоциации ФинТех при поддержке Московской биржи для объединения усилий участников финансового рынка и смежных отраслей в развитии безопасной разработки программного обеспечения и opensource-решений. В сообщество вошли эксперты - представители участников Ассоциации.

На круглом столе с лидерами FinDevSecOps обсудим:
1. ТТМ против appsec: увеличивает ли внедрение процессов и инструментов DevSecOps время разработки? Как найти баланс между бизнесом и безопасной разработкой?
2. ИБ против ИТ или вместе с ИТ? Какая должна быть стратегия безопасности в финансовых компаниях?
3. Что делать со срочными хотфиксами: сначала в прод, а потом проверки? Все ли проверки надо делать?
4. Отличие процессов разработки в финансовых компаниях от нефинансовых? Перспективы развития регуляторных требований.
5. Нужны ли дополнительные роли в командах (appsec, secchamp, secanalyst...)? Во что трансформируется роль классического специалиста ИБ?
6. Снижает ли инцидент ИБ ее рыночную стоимость в долгосрочной перспективе? Зависит ли это от типа бизнеса?
7. Инструментарий: перспективы развития? Использовать опенсорс или закрытые инструменты? Каковы регуляторные требования?
8. Нужно ли проводить анализ защищенности ML-моделей в продукте? MLsecOps?
9. Что делать если нужен внешний мониторинг? Как контролировать инциденты: инфра, конвейер.

Доклад принят в программу конференции

Воркшопы (5)

Локальные LLM: как с легкостью применять большие языковые модели в ежедневных задачах

В этом мастер-классе я расскажу, как максимально быстро и безопасно автоматизировать часть своей работы с помощью локально развернутых LLM. Мы вместе попробуем несколько моделей для базовых DevOps-задач, научимся писать промпты (да, они немного отличаются от промптов для Chat GPT), а также поговорим про то, как можно улучшить ответ модели за N шагов.

Доклад принят в программу конференции

Воркшоп по risk-storming

Дмитрий Бардин

Яндекс Маркет

Пока жива система, ей угрожают риски. Можно их игнорировать и получать интересные сайд-эффекты. А можно попробовать управлять. Существуют техники выявления рисков на базе архитектуры решения и других имеющихся артефактов. Какие-то техники слишком долгие и сложные (ATAM, например), какие-то слишком субъективные (архитектор взял и подумал).

На воркшопе будем:
* говорить про риски в среде обитания;
* искать только полезные с помощью метода Risk-Storming — золотой середины по времени/усилиям. На примере и самостоятельно;
* продумывать контроли и способы снижения.

Доклад принят в программу конференции

Переезд в Managed Postgres с помощью Data Transfer: как обойти все грабли и минимизировать даунтайм

PostgreSQL
Администрирование баз данных
Работа с облачными сервисами
Инфраструктура

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

Я вам расскажу, как можно уменьшить эту боль с помощью инструмента Data Transfer для миграции в Yandex Cloud на Managed PostgreSQL. Современная база данных — это не только данные, но еще и много различных сущностей: пользователи, права, хранимые функции, экстеншны, триггеры, индексы. В докладе мы разберем этапы подготовки и миграции, различные нюансы, которые нужно учесть при подготовке и тестовой миграции. Также уделим внимание таким аспектам, как рассинхронизация, статистика, индексы и внешние ключи, которые нужно не забыть при переключении рабочего трафика со старой базы на новую.

Ну и немного подискутируем, кто же должен этим заниматься: DBA или DevOps-инженеры?

Доклад принят в программу конференции

Helm: эволюция от стартера до суперчарта

Непрерывное развертывание и деплой
Непрерывная интеграция
Devops / другое
Автоматизация разработки, доставки, эксплуатации
Насими Мамед-заде

Независимый эксперт

Использование Helm-чартов для упрощения упаковки, настройки и развертывания приложений и сервисов в кластерах Kubernetes уже стало индустриальным стандартом. Чарты позволяют использовать один шаблон под разные окружения и в разы сэкономить время. Но есть ли способ еще больше упростить процесс?

На воркшопе:
* посмотрим, что такое Helm chart, как создать свой стартер и внести изменения, которые сделают его гибче и функциональнее. Есть ли смысл делать из стартера суперчарт?
* рассмотрим, что представляет собой helmfile, сравним helmfile и umbrela chart в эксплуатации, и поймем, почему первый способ удобнее для команды;
* научимся подключать чарт библиотеки для упрощения модификаций в имеющиеся чарты.

Доклад принят в программу конференции

Введение в нетворкинг: базовые навыки кулуарного общения

Алексей Обровец

на фрилансе

Расскажу о нетворкинге (не путать со смол-током):
* ЗАЧЕМ?!
* что это за общение и как быть целеустремленным в любой коммуникации,
* с чего начать разговор,
* чем продолжить,
* как закончить,
* как обменяться контактами,
...произведя правильное впечатление.

Участники мастер-класса унесут с собой
* наброски рассказа о себе несколькими способами,
* понимание ЧТО, КОМУ, О ЧЁМ и КОГДА рассказывать,
* какие и кому задавать вопросы.

Доклад принят в программу конференции

TechTalk (1)

Russia DevOps Report. Анализ состояния IТ-рынка DevSecOps в 2023-2024. Замена инструментов и динамика рынка импортозамещения

Евгений Калашников

Платформа Сфера (Холдинг Т1)

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

Доклад принят в программу конференции