Доклады

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

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

Для корпоративных систем телекома и не только требуется высокая доступность с неизменным качеством.
В докладе говорится о том, как в сервисах МТС применяются практики SRE, проводится параллель с практиками в Google, основываясь на Google SRE book.
Автор является CTO одной из высоконагруженных телекомовских платформ с повышенными требованиями к скорости и надежности, где четко определен SLO и существуют обязательства перед потребителями. На примере данной системы в докладе развивается мысль чем и как обосновывается достижимость SLO по доступности в 3,5 девятки. Приводится пример того, какие потребуются мероприятия и какими станут трудозатраты, если потребуется повысить доступность до 4 девяток и если более. Как это повлияет на архитектуру, инфраструктуру и команду эксплуатации. И почему подавляющему большинству сервисов в реальности не потребуется более высокого процента доступности чем 99.95.

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

1) Самый часто используемый вами тип метрики будет DistributionSummary
2) Дефолтные конфигурации регистрируют десятки готовых метрик за вас
3) Micrometer, как заявляют его разработчики, является фасадом для JVM фреймворков, но он таким не совсем является, в прочем он и не только фасад

Тезисы:
Что такое семплироваение и зачем оно нужно?
Метрики и трейсы на основе семплированных данных. Бесполезная игрушка или рабочий инструмент?
Head vs Tail. Отличия и сценарии использования.
Реализация и алгоритмы head-based семплирования.
Реализация и алгоритмы tail-based семплирования. Подводные камни и способы из обхода.
Применение семплированных трейсов в разборе реальных инцидентов.

Потраченные миллионы на DevOps ради всего лишь мнимого слова Time-to-Market?

Безостановчный рост бюджетов на "Не понятно что?"

Или текущие суровые реалии дерби, под названием DevOps?

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

И в рамках доклада затронем тему Platform Engineering - кровавый энтерпрайз, который будет стоить миллиарды и иметь нулевой ROI.

- В 2022 году с рынка хранилищ артефактов РФ ушли два ключевых игрока
- Мы, как и все, постарались исследовать возможность создать такое хранилище на OpenSource Nexus
- Поймали кучу граблей связанных с производительностю Nexusa и поняли, что их никак не обойти. Он вообще очень плохо подходит для больших команд, которые генерируют большую нагрузку
- Разобрались с лицензированием Nexus и поняли, что в РФ им не получится воспользоваться
- Поняли, что современное хранилище должно еще и безопасно хранить артефакты
- Приняли решение сделать свое хранилище с нуля на зарекомендовавших себя технологиях
- Релизовали хранилище артефактов, которое спобно работать в высоконагруженных системах
-Сделали это хранилище безопасным

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

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

Техписы всё время пишут не то? Как ни ставь задачу, результат всё равно будет хуже, чем минимальные ожидания? Ну и ты уже готов смириться с бесполезностью техписа? Зря! Вам просто нужно научиться говорить на одном языке и техпис станет knowlege manager на минималках.
Мой доклад о том, как это сделать и выжить.

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

В этом докладе я хочу рассказать про наш опыт ускорения релизов и стандартизации этого процесса в сервисах Mail.ru и
поделиться подходами и инструментами, которые практически каждый сможет внедрить в собственные проекты.
– Почему мы за это взялись
– Как правильно организовать выкатки? Какие есть подходы и что выбрали мы
– Как устроен пайплайн: сборки образов, мерж веток, джобы, механизм раскатки, виды апрувов и другое
– Как мы следим за пайплайном: графики, алерты и нотификации
– Особенности организации пайплайнов в GitLab CI
– Результаты, которых мы достигли, и ближайшие планы по развитию
– Как внедрить себе

Воркшоп: Разработка инженерных практик для крупных компаний

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

Что вас ждет:

- Обсуждение лучших практик: Узнаем, как глобальные компании адаптируют и внедряют современные подходы к разработке и эксплуатации (CI/CD, DevOps, SSDLC, API-first, cloud-native).

- Инструменты и процессы: Разберём ключевые инструменты автоматизации, мониторинга и их интеграцию в ежедневные рабочие процессы.

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

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

- Реальные кейсы: Изучим примеры компаний, успешно реализовавших переход к продвинутым инженерным практикам, и разберём их на конкретных примерах.

Для кого этот воркшоп:

- Руководители технических команд
- DevOps инженеры
- Технические лидеры и архитекторы
- Инженеры по качеству и безопасности

Результат:

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

Интерфейсы нового уровня: как создать визуально привлекательные и удобные интерфейсы в Jenkins, которые заменят старые, сложные системы.
Минимум действий от пользователя: никакой путаницы или инструкций — пользователю нужно лишь нажимать кнопки, всё остальное происходит автоматически.
Красота и автоматизация в одном флаконе: интеграция с Git, автоматическое подтягивание данных и полное отсутствие ручного ввода, что упрощает и ускоряет работу.
Безопасность прежде всего: расскажу, как сделать платформы не только удобными, но и защищёнными, чтобы минимизировать риски.
Удобная разработка без шишек: я покажу, как организовать процесс разработки этих платформ так, чтобы избежать проблем, на которых я уже сам учился.
Обучение и поддержка: научу вас, как воплотить всё это в жизнь — от создания красивого интерфейса до безопасного и удобного рабочего процесса.

Доклад посвящен организации канареечного деплоя при GitOps. Обсудим организацию GitOps-репозиториев, применение GitFlow, различные стратегии деплоя, интеграцию Argo Rollouts с ArgoCD и безопасное выполнение миграций.
Доклад будет полезен инженерам, работающим с Kubernetes


- Организация GitOps-репозиториев ArgoCD
- Flow CI/CD
- Стратегии деплоя
- Интеграция Argo Rollouts с АrgoCD
- Как подружить канарейку с миграциями

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

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

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

Доклад посвящен популярному GitOps-инструменту ArgoCD, который помогает унифицировать и автоматизировать процессы развертывания приложений в Kubernetes. Обсудим различия между pull и push моделями, особенности установки и преимущества ArgoCD, а также организацию GitOps-репозиториев и использование Flow разработки. Кроме того, кратко обсудим организацию доставки секретов для такой модели.

- Сравнение pull и push моделей
- Особенности установки ArgoCD
- Преимущества
- Организация GitOps-репозиториев
- Flow CI/CD
- Организация контроля доступа
- Организация доставки сенситив данных / Секретов

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

Из доклада вы узнаете о проблемах и наших решениях автоматизации производственного конвейера на
примерах.
• Автоматизация ручных действий на всех этапах от сборки до ПРОМа.
• Автоматизация проверок Quality Gates (включая ИБ) в джобе CI.
• Реализация pipeline для разного стека на собственном движке Fulcrum с
использованием пакетного менеджера Helm и шаблонизации Synapse Service Mesh
/Prometheus.
• Особенности Jenkins CD в Enterprise, шардированное решение для него “Dream
Jenkins”(SberWorks).
• Переход из Jenkins в ArgoCD
• Реализация BlueGreen и Canary стратегии деплоя и его применимость в
зависимости от стека.
• Автоматизация ручных шагов производственного процесса с помощью сервисных
Pipeline для автоматического создания и изменения объектов релизной деятельности Jira.
• Оборачивание конвейера в «человеческий вид» с помощью оркестратора
оркестраторов DPM (SberWorks).

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

Расскажем наш подход:
- итеративное создание DRP - от частных планов систем к общему плану бизнес-услуги
- чеклист анализа системы и создание плана восстановления
- ключевое - восстановление основной функциональности, точка готовности системы
- общий план восстановления бизнес-услуги и работа с зависимостями
- планы требуют учений (бумажных и реальных)
- изменяем архитектуру систем / услуг
- доопределяем риски, их источники и признаки их реализации
- выравниваемся с требованиями регуляторов
- услуги и системы динамически изменяются - внедряем гигиену SRE команд по поддержке планов в актуальном состоянии

Перевод Continuous Deployment процесса развертывания Openstack облака с раскатки docker контейнеров инструментами ansible на kubernetes+ArgoCD+Helm.
Изначально мы имели 2 кластера openstack - клиентский и инфраструктурный. В последнем поднимались виртуалки, в которых запускаслись инфраструктурные сервисы (мониторинг, логирование и пр.) В клиентском облаке сервисы openstack раскатывались с помощью большого ansible плейбука. Возникали сложности, как с версионированием, так и с обновлением openstack компонент (некоторые компоненты можно обновлять только с миграцией клиентской нагрузки). Были сложности с поддержкой 2х кластеров openstack (один ванильный, другой - разработанный компанией cloud.ru). Некоторые инфраструктурные сервисы располагались в kubernetes, развернутом на публичном облаке внутри виртуальных машин, что создавало сложности с маршрутизацией, прохождением межсетевых экранов и некоторые другие. В качестве решения была реализована архитектура, в которой 2 кластера схлопнулись в 1, часть нагрузки перестала быть виртуализованной и перешла на уровень контейнеризации на baremetal kubernetes. Сервера подключаются к сети напрямую через cilium bgp агента, persistent storage реализуется средствами longhorn, превращая control ноды в гиперконвергентные. Обновления выполняются как стандартными средствами kubernetes, так и операторами.
Данный доклад описывает подробно существовавшие сложности, пути их решения, архитектуру нового облака.

Кажется, что важность надежности продуктов – вещь очевидная. Ни один из владельцев продуктов не ставит цель по созданию продукта, который будет постоянно “падать”. Однако на деле оказывается, что для обеспечения надежности то времени не хватает, то компетенций. Чтобы решить эту проблему в МТС была создана платформа Operations или OpsPlatform. В докладе поделимся опытом создания платформы и как мы за пол года внедрили платформу во все MC/BC продукты экосистемы, какие эффекты получили, и что о нас думают крупнейшие продукты экосистемы.

Что нужно, если ты хочешь учить людей техническим навыкам, например, разворачивать Kubernetes или повелевать Docker? А еще, хочешь это делать онлайн?

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

Совершенно точно нужно помогать ученику. Ну вот пишет он "kubeadm init ..." и делает опечатку в параметре "--pod-network-
cidr": преподаватель увидит это моментально, а глаз ученика с этим будет бороться долго.

Кажется, не выглядит как работа для DevOps? Нет, выглядит.

Для каждого ученика создадим LXC-контейнер. Или виртуалку. А что удобнее? Ну, для курса по Kubernetes удобно контейнер, чтобы в нем запустить VirtualBox и создавать виртуалки, по количеству нод. А в курсе по Docker лучше дадим виртуалку и будем в нее ставить, что нужно.

Дальше к этому контейнеру мы сделаем VNC. Но он небезопасен и не очень удобен, поэтому возьмем Guacamole и завернем это в TLS. А еще поставим Epoptes, чтобы преподаватель мог быстро подключаться к ученику.

А теперь, мы это автоматизируем. Почему? Потому что если ты проводишь 50+ групп в год, то разворачивать тебе все эти штуки должен бездушный CI/CD-пайплайн. На чем? Конечно, на Astra Linux.

Платформы - тренд последних лет. Многие компании идут в их разработку, но положительного эффекта не наблюдают. Либо вообще выкидывают через некоторое время. Хочется порассуждать, а когда и, главное, зачем такие платформы нужны (как IDP, так и внутренние бизнесовые) и обсудить, что может привести их к провалу.

Создать кластер Kubernetes – не самая сложная задача, но что делать если их требуются тысячи?

Расскажу о том, как мы в Сбере пришли к идее создания Managed-сервиса и как это позволило не сойти с ума и справиться с обслуживанием огромного количества кластеров. Также разберёмся в ключевых особенностях и плюсах нашего решения и посмотрим на его возможности.

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

Поговорим о том, почему это совсем не так и как современный мир "бежит" к большой красной кнопке

Уже давно не секрет, что в Т-Банк есть своя observability-платформа Sage.
Внутри банка, мы предоставляем сервис мониторинга, у которого ежедневно более 5000 активных пользователей(DAU).

И как это принято, у нас есть SLA с нашими пользователями,
но "как понять предоставляем ли мы сейчас услугу или нет?" - именно с этого вопроса начинатся мой рассказ о построении SLOs/SLIs для нашей платформы Sage. Метрики для метрик.

На примере домена метрик в Sage, в своем докладе я расскажу:
* как мы измеряем надежность;
* как мы строили SLOs/SLIs;
* как мы работали с нашими клиентами, чтобы выявить их ожидания от нашей надежности;
* как выглядит наша подсистема метрик на сегодня

Доклад будет интересен как экспертам, так и людям, которые только погружаются в тему построения SLOs/SLIs

Надежность в современном цифровом мире - это одна из ключевых характеристик любой системы. Методология SRE предполагает строгое фокусирование на надежности и поддержании заявленного SLA. Одновременно с этим, системы постоянно развиваются и совершенствуются. Но любое вносимое в систему изменение/обновление/релиз несет в себе риски и эти риски зачастую не воспринимаются таковыми. На нашем проекте Sage в Тинькофф, мы, как команда SRE, убедились на собственном опыте, что не бывает безопасных релизов и к любой модификации продакшн контура нужно относиться внимательно.
В докладе я поделюсь следующими кейсами, подтверждающими нашу позицию:

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

В начале 2024 года мы собрали команду и начали разрабатывать своё приложение для проведения хаос тестирования. Поговорим о том, почему мы решили так делать, вспомним про то, что такое хаос тестирование, чем хуже другие инструменты. Расскажем про то, как команды отреагировали на наше решение, чего мы хотим добиться. Немного про планы развития нашего продукта.

Фича флаги позволяют изменять поведение системы без правки кода и повторного развертывания. На нашем проекте мы могли бы их имплементировать сами, но, как говорят ребята из Unleash, "друзья не позволяют друзьям создавать свою собственную систему фича флагов", поэтому мы взяли их Open Source решение. И не прогадали!

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

Язык программирования Go предоставляет возможности, которые значительно оптимизируют разработку инструментов для DevSecOps и Red Team. Он отличается простотой, что облегчает его изучение и использование. Компиляция программ на Go для Windows, Mac и Linux из единого исходного кода позволяет экономить ценное время. Именно поэтому злоумышленники активно используют Go для создания современных вредоносных программ. Мы будем моделировать эти угрозы, чтобы лучше понять, как защищаться.

Hashicorp Vault является стандартом де-факто хранения чувствительных данных. Интегрируется он примерно с чем угодно и, естественно, с другим фактическим стандартом размещения нагрузки - Kubernetes.
Инструментов для интеграции Hashicorp Vault с Kubernetes существует немало и каждый обладает своими примуществами и недостатками, поэтому в докладе рассмотрим и сравним популярные инструментов доставки секретов из Hashicorp Vault:
- External Secrets Operator
- Hashicorp Vault Secrets Operator
- Hashicorp Vault Agent Injector
- Hashicorp Vault CSI Provider
- (Banzai Cloud) Bank Vaults-Vault Secrets Webhook
Для каждого из интрументов приведу пример настройки, рассмотрю как именно доставляется секрет до приложения и принцип работы инструмента. Сравню инструменты с точки зрения механизмов ротации секретов, а также удобства использования. Подсвечу ограничения инструментов.

Новая жизнь бросает нам новые вызовы - и вот уже CNI и Service Mesh-и с EBPF под капотом это не что-то из области фантастики или экспериментов, это уже повсеместно внедряется на production инфраструктуру. Однако не так много инженеров понимают, что происходит под капотом этой системы. И еще меньше инженеров знает, как системы на базе eBPF могут быть скомпроментированы и как защититься от угроз если не полностью, то хотя бы минимизировав риски. И сегодня я расскажу вам об этом.

В докладе мы затронем следующие темы:
- Что такое bpf как технология
- eBPF и как это работает
- Атаки на удаление ключей из ebpf maps
- Kernel exploits by eBPF
- Вызов незапланированных syscalls
- Falco bypass
И другие виды атак

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

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

Все что вам нужно знать про секреты, как их хранить и как обращаться с ними

Несколько лет назад я столкнулся с задачами по мониторингу киберинцидентов, нам приходилось внедрять инструменты безопасности для интеграции с Security Operations Center. Это помогло нашему проекту реагировать на угрозы безопасности на ранних стадиях и оперативно предотвращать инциденты. Постоянный рост числа подключенных устройств и сложность их взаимодействия требуют новых подходов к защите данных и предотвращению угроз.
Я уверен, что мой доклад поможет участникам глубже понять важность SOC, научиться эффективно использовать современные инструменты и технологии для мониторинга и реагирования на инциденты. Также выступление посвящена роли и значимости центров обеспечения безопасности (SOC) с применением современных методов по обеспечению кибербезопасности. Мы рассмотрим основные функции SOC, начиная с мониторинга и заканчивая реагированием на инциденты. Будет представлен анализ актуальных угроз, в том числе данные о масштабах и мотивации кибератак.
Доклад также охватит технологические вызовы, связанные с обработкой и нормализацией данных, будет рассмотрена SIEM-система Splunk.

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

Предоставить пользователям аналитическую базу данных - это не просто поднять гринплам, кликхауз или купить на них подписку. На примере внедрения в платформу данных базы нового поколения Starrocks (https://www.starrocks.io) расскажу про обеспечение необходимого минимума фунционала и автоматизации для потребителей - инженеров данных, инженеров-аналитиков или разработчиков dwh.
Постараюсь ответить на вопрос - каким требования должны удовлетворять инсталляции и сами движки баз, особенно если вы как поддержка хотите спать по ночам и не вздрагивать при слове обновление, блокирующие операции ddl или отказ мощностей.
В докладе будет k8s (куда же без него в современном мире), сервисы миграций, аутентификации и авторизации, dbt как сервис - и все это приправлено щепоткой golang и gitlab-ci.

Расскажу о трехлетнем опыте использования Канбан-метода в небольшой команде DevOps-инженеров. Отвечу на самый главный вопрос "Зачем?" Расскажу с чего начали, как провели воркшоп STATIK (Systems Thinking Approach to Introducing Kanban) - cистемный подход к применению Канбан-метода, какие инсайты обнаружили в ходе STATIK и чем он помог. Поделюсь возникшими трудностями на пути применения Канбан-метода в нашей команде и как их решали, чего достигли и что не получилось. Покажу какие метрики эффективности выполнения задач мы считаем и насколько помогают для этого Канбан-инструменты. Обсудим, что может помешать прозрачности работы и как работать с заказчиками, вырабатывать правила и достигать соглашений.

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

Несколько лет назад в Иви мы расформировали команды мониторинга и централизованной выгрузки релизов.
Причина: такая конфигурация имела несколько проблем.
Что мы сделали:
- функцию выгрузки релизов передали в продуктовые команды
- функцию мониторинга и 1-2 линии поддержки (сервисов) выполняем всеобщими дежурствами
...
Profit

В своем выступлении «загляну под капот» одного из самых популярных Ingress контроллеров в k8s – Nginx Ingress. Материалы доклада помогут вам добиться желаемых результатов при работе с данным инструментом.

DevOps существует уже более 15 лет, но лишь немногие организации могут сказать, что успешно внедрили DevOps. Эксперты отмечают, что в компаниях процветают анти-паттерны DevOps, компании продолжают страдать от большого T2M, а взаимодействие Dev-Ops все так же создает сложности.
Доклад поможет компаниям-новичкам в DevOps не совершать ошибок, а остальным пересмотреть свой подход к построению DevOps. Рассмотрим типичные ошибки построения DevOps в организациях и как их решать, а так же теорию взаимодействия инженерных команд.

У нас не задеплоилось с первого раза, давайте влепим кол инфраструктуре. А то, что мы криво поставили переменные пода - это не к нам, это к devops. Часто ли вы такое слышали от разработчиков, тестировщиков или поддержки? Как сделать доказательную базу того, что с инфраструктурой всё хорошо, а проблема в коде? Сегодня мы поговорим с вами о том, как можно организовать процесс снятия метрик удовлетворённости инфраструктуры для команд разработки и тестирования, рассмотрим вариант стэка технологий для этого, а так же пример реализации с видом метрик, которые могут оказаться полезными в вашей работе.

В чем основное различие Enabling-команд и команд с "Инженерами на час". Наше видение того, какие типы команд наиболее востребованы в Enterprise. Эти типы команд взаимоисключают друг друга или можно построить что то среднее? Наш опыт построения Enabling-команды.

Проблемы эксплуатации рано или поздно случаются в каждой команде разработки.
Поиск в интернете не даёт однозначных ответов, какого специалиста искать, для решения наших проблем.
1. Как понять кто нужен? Админ, DevOps или SRE?
2. Разберёмся как оценивать результаты работы той или иной роли и на что рассчитывать.
3. Поговорим о том как удержать специалиста.

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

Это доклад продолжение докладов про коллаборации, важность проектирования для DevOps(ов).

Около 2 лет назад от СТД “Петрович” отделилась продуктовая ИТ-компания “Петрович-Тех”, созданная для закрытия потребностей СТД. Бывший ИТ-департамент стал полностью самостоятельной единицей, а также значительно вырос - и по численности сотрудников, и по уровню решаемых задач.
Уровень сервисов и их доступность стали ключевыми показателями, под которые появилась необходимость перестроить процессы молодой ИТ-компании.
Как масштабировать и перестроить процессы бывшего департамента под структуру компании и новые отношения с заказчиком? Ответ мы нашли в адаптации ITIL под наши потребности и готовы поделиться своим маршрутным листом: на примерах и с кейсами.

Многие команды разработки за 15 лет существования Kubernetes внедрили этот инструмент в production как облачный сервис или bare-metal реализацию. В нашей компании bare-metal k8s стал основой внутренней платформы для разработчиков, которая должна быть отказоустойчивой, поэтому он живёт в нескольких цодах. На докладе я поделюсь:
- Экспертизой в расселении Kubernetes в разные цоды
- С какими проблемами мы столкнулись при внедрении DevOps практик на такую архитектуру
- Как мы решали вопросы межцодной коммуникации между ресурсами внутри K8s и контроля их доступности
- Каким образом можно обеспечить доступность ресурсов при сбоях в облаке или датацентре
- Какие есть варианты для безопасной коммуникации в межцоде

Я хочу рассказать как мы выстраивали разработку своего Linux дистрибутива для платформ на базе процессоров Эльбрус. Про выбор м/у полностью нативной средой или гибридной (Эльбрус+x86) и почему мы выбрали путь гибридной системы. Какой инструментарий мы тестировали и на чем в итоге остановились. Из каких частей строилась наша среда разработки.
Ну и конечно пару-тройку слайдов про сами Эльбрусы и чем они отличаются от привычных нам процессоров.

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

Этап сообщества и создания пространства для общения + наставничество
> Результаты

Этап внутренних митапов + Выводы
> Организация PI Planning и EventStorming

Этап организации платформенной команды c шарингом участников
> Прекращение активности и мысли на счет Орг дизайна

Этап Оценок + стандартизации грейдов специалистов + Выводы
> Пересмотр подходов к оценке Senior+ специалистов

Этап трансформации проблемных продуктов + выбор новых инструментов
> предварительные выводы

Общие выводы и текущие функции ЦК
Про будущее - Технический арбитраж

В современном процессе разработки программного обеспечения применение FrontOps-практик к фронтенд-приложениям становится все более важным для DevOps-инженеров. Автоматизация процессов сборки и деплоя фронтенда не только ускоряет выпуск новых фич, но и повышает надежность системы в целом. Внедрение автоматических тестов различных уровней (юнит, интеграционные, e2e) в CI/CD пайплайны гарантирует сохранность существующей функциональности при добавлении новых изменений. Оптимизация пайплайнов и выбор эффективных и современных инструментов, таких как pnpm, bun и vite, значительно улучшают эффективность и скорость доставки продукта.

Использование инфраструктуры как кода (IaC) для фронтенда решает проблему несоответствия сред разработки, тестирования и продакшена, снижая риски при деплое и облегчая масштабирование. Реализация наблюдаемости и мониторинга с помощью инструментов типа Sentry является критически важной для поддержания высокого качества пользовательского опыта и быстрого решения возникающих проблем. Уделение внимания безопасности с самого начала защищает от распространенных уязвимостей посредством интеграции DevSecOps-подходов и использования инструментов вроде ESLint, SonarLint и DefectDojo.

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

Этот доклад – не про технологии ради технологий. Он про создание эффективного, человечного и мотивирующего онбординга, создаваемого руками разработки для того, чтобы новичок становился частью команды и впитывал ДНК компании. Я уверена, что практики, подтвержденные реальными кейсами, помогут вам переосмыслить процесс онбординга и сделают его полезным не только для новичков, но и для всей команды.

В современном мире онбординг – это не просто введение нового сотрудника в курс дела. Это ключевой этап, от которого зависит, насколько быстро и эффективно новичок (и при этом не важно, это сотрудник новый для компании или перешедший из другого подразделения) станет полноценной частью команды. Я хочу поделиться с вами методиками, которые мы успешно внедрили в нашей компании и которые могут кардинально изменить ваш подход к онбордингу. А главное, почему НУЖНО взять ответсвенность за онбординг самой команде и почему команда может находить в этом процессе ценность для себя.

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

В докладе будут рассмотрены темы: передачи ответственности команде, процессы выбора и поддержки бадди для новичка, составления плана онбординга его актуализации и геймификации (руками команды), практика self-assessment - как базисная составляющая процесса.

Почему типовые карьерные треки не работают?
Опыт построения рабочего карьерного трека в компании Cloud.ru

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

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

Сo-pilot в разработке — тренд последних лет. Однако этот трек не единственный в ландшафте AI-оптимизации внутренних процессов в бигтехе.

Вместе c коллегами из Яндекса, VK, Т-Банк, Truffle и Авито обсудим:
1. как в целом можно замерять эффективность производственного процесса — овервью и типичные трудности;
2. как вовлечь разработчиков в использование новых инструментов, какие механики использовать для масштабирования внутри компании;
3. как можно использовать AI в разных ролях: поддержки, дизайна, аналитики, солюшн-архитектуры, тестирования;
4. когда это становится cost-effective.

Поищем общие и конфликтующие позиции, послушаем success-stories из первых рук.

Можно доклад, но круче будет собрать дискуссию и похоливарить на эту тему.

1. Краткая история метрик оценки разработки: строчки кода и прочее
2. DORA, QUANT, SPACE
3. Что делает и куда смотрит сбер.
4. Почему метрики для оценки разработки - разрушают команду
5. Как одна метрика разрушила всю команду.
6. А можно ли контролировать 800+ инженеров без метрик?
7. Почему метрики - это правильно и хорошо

Astra Linux содержит ряд инструментов для обеспечения информационной безопасности, которые не всегда хорошо понимаются. Например, мандатный контроль целостности (МКЦ), который совершенно не про контрольные суммы, а про то, что даже root не всегда root. Или приносит с собой мандатный контроль доступа (МКД), который крайне непросто понимать тем, кто не занимался этим вопросом никогда.

Посмотрим на практике, что означают механизмы МКЦ и МКД, своими руками потыкаем в Astra Linux и научимся понимать, где и что нам нужно из этого использовать.