Заявки на доклады

Поиск по тегам:
Показать все доклады

Платформа и платформенные команды

Описание проблем при настройке Istio
- Ожидание vs реальность

Абстракции Istio и Envoy
- Не все так однозначно

Маппинг абстракций Istio к абстракциям Envoy
- Костыли и веревочки

Подходы к траблшутингу
- Инструменты и практики

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

Всем давно известно, что pod в Kubernetes может включать в себя несколько контейнеров. Например, один для приложения, второй для Service Mesh, третий – журналирование, а еще четвертый, пятый и т.д. В итоге много контейнеров, много вопросов:
* Зачем нужны дополнительные контейнеры, какие задачи они должны решать, а какие нет?
* Как изолировать платформенные контейнеры от пользовательских приложений?
* Как организовать автоматизацию процесса и не сломать кластер Kubernetes?
Давайте поговорим об этом в рамках доклада: обсудим, чем паттерн sidecar отличается от ambassador, узнаем про опыт использования типовых sidecar-инжекторов и универсальный подход к работе с дополнительными контейнерами.

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

Уверен, что вы слышали про platform engineering. Это процесс создания и предоставления удобных сервисов самообслуживания командам и инженерам, с целью ускорения потока создания ценностей, снижения объема нецелевых активностей команд, а также повышения качества, надежности и безопасности создаваемых решений. Звучит круто! Но, как начать работать в таком процессе, как набрать нужные компетенции или систематизировать практики? Именно эти вопросы являются одними из причин создания мной открытого фреймворка Platen (www.platen.dev), который раскладывает все по полочкам.

Весь доклад будет построен исключительно на реальных кейсах, раскрывающих следующие вопросы:
1. отличия между различными ролями: "devops-инженер" и платформенный инженер;
2. зачем нужно становиться платформенным инженером;
3. почему нельзя "купить" платформу или найти "готовую";
4. дорожная карта становления платформенным инженером;
5. основные роли в платформенной команде: владелец платформы, платформенный инженер, архитектор платформы. Карьерный трек инженера;
6. что такое фреймворк Platen и зачем он нужен;
7. основные части фреймворка: введение, артефакты, оценка и стратегирование, реализация;
8. про Platen metrics radar(PMR) и почему отслеживание "4 ключевых метрик" вам не помогут;
9. как составить модель предоставления платформенных сервисов (as-is и to-be);
10. инструменты изменения мышления/культуры всей компании и инженеров, в сторону платформизации;
11. что такое самодостаточные/потокоцентричные команды, и причем здесь ответственность в конвейере производства. Как командам доставлять изменения до клиентов самостоятельно, в платформенной модели.

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

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

Я - Product Manager технических (платформенных) инструментов в Toptal. У нас в компании работает несколько сотен разработчиков. И от эффективности их работы зависит многое.
Недавно мы нашли проблему, которая нам стоит 16 человеко-месяцев в год. И даже придумали, как ее решить. Но решили этого не делать. Почему? Об этом я поведаю в своем докладе.

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

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

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

С-level engineering

* Чем отличается найм в гугл от найма в ООО "Рога и копыта"?
* Как нанять программиста в команду, чтобы он выполнял те цели, которые мы от него (нее) ждем? Как спронозировать время онбординга? Как оценить синьерность? Как оценить "мягкие скилы" (soft skills)? Как оценить навыки лидерства?
* Как нанять специалиста умнее себя?
* Нужно ли нанимать джунов и как? Поделюсь практическими результатами.
* Как нанять сотрудника, которому со всех сторон предлагают офферы (актуально на 2021 год)?
* Как изменился процесс найма в 2022 году и как он измениться в будущем - тема для открытой дискуссии.

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

Управление знаниями (KnowledgeConf)

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

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

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

Многие компании тратят сотни, а то и тысячи часов на поиск идеальных кандидатов, разрабатывают свои стратегии найма и продвигают свои бренды на рынке. Бывает, что весь рабочий график лида состоит почти из одних интервью, знакомо?

А что если пойти другим путём? Не искать идеальных кандидатов, подходящих именно для вашей компании и проекта, а вырастить их самим?

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

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

Инфраструктура как код

Сравнение различных подходов для автоматизированного создания окружений для R&D-команд.
Три подхода:
* Terragrunt multiple environments;
* Kubernetes Namespaces as Environments;
* Crossplane.
Для всех трех подходов используется Git as Source of Truth.

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

Изменять конфигурацию узла Kubernetes нужно не только в момент создания кластера, но и при изменениях в инфраструктуре и при обновлениях кластера. Хорошо, если узлы можно автоматизированно пересоздать или изменения не требуют перезагрузки узла. А что, если нет, и узлов в кластере под сотню?

В докладе будут рассмотрены распространенные варианты реализации с помощью Ansible, Cluster API, OpenShift Machine Config с разбором плюсов и минусов и предложен собственный оператор с описанием основных решений:
1. Элементы конфигурации — чем управляем.
2. Логика контроллеров (как не уронить весь кластер одним движением).
3. Drift prevention & self healing.
4. Как масштабировать решение на сотни узлов.

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

В своем докладе расскажу:

- Как устроен CI/CD в Ozon (архитектура и чуть детальнее рассмотрим каждую компоненту)
- Какие основные кронджобы для автоматизации рутинных задач мы используем
- На примере покажу как происходит взаимодействие компонент автоматизации работы джоб в пайплайне (баш скрипт, который курлом подкачивается в джобах, который подкачивает консольную утилиту + хелм чарт)
- Отдельно уделим внимание консольной утилите, реализующей автоматизацию пайплайнов
- И покажу как мы реализуем джобы с помощью консольной утилиты с подробным разбором
Про кодфриз, как он у нас релизован
- О подсчете времени работы джоб/секций скриптом внутри джобы и как мы эту информацию отправляем в елк/пром и что с этим делаем (вводная про ТТМ)
- О ТТМ, что это для нас, как считаем, какой процесс по снижению ТТМ и тд

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

Kubernetes — это YAML-манифесты. Так было для нашей DevOps-команды долгие годы: Helm, GitOps, Senior YAML Developers. Когда конфигурация приближается к десяткам и сотням наборов YAML-манифестов, появляются большие сложности с их поддержкой. Лишний отступ, булевое значение вместо строки или число в кавычках легко превращаются в часы отладки. Можно ли сделать лучше? Можно!

В своем выступлении я расскажу, как опять начать радоваться жизни при написании манифестов, получить возможность наследования, композиции и валидации структур и полей. А бонусом — я покажу, как жить без Helm в контексте работы GitOps.

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

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

Встает интересный вопрос — прошли ли практики написания инфраструктурного кода такую же трансформацию разработки, какая произошла в разработке?
Или все по-прежнему пишут инфраструктурные монолиты, которые запускаются, только если всей командой взяться за руки?
Кто на самом деле являлся драйвером DevOps-трансформации?

Поговорим об этом на докладе.

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

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

Работая с terraform на многих проектах, хотелось найти такой подход к архитектуре кода, чтобы он хорошо подходил сразу по многим требованиям:
* и для проекта в начальной стадии — общих ресурсов по максимуму;
* и для проекта в релизной стадии, когда нужна изоляция dev и prod;
* обеспечивалась достаточная безопасность в pipeline и разграничение доступа к управляемым IaC-ресурсам;
* скорость и минимизация времени выполнения pipeline;
* DRY — как можно меньше повторяющегося кода;
* гибкость в использовании такого кода;
* минимальный TTM и TCO;
* максимальная возможная автоматизация;
* простой git flow.

Спешу поделиться тем, что в итоге получилось.

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

В докладе я раскрою тему создания и использования операторов Kubernetes.

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

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

FluxCD v2 это яркий и преданный представитель GitOps принципов.
За несколько лет был проделан путь от просто полезного инструмента до зрелой масштабируемой GitOps платформы.
Материалов о том, как организовать структуру GitOps репозиториев, не хватает, и на старте сложно предсказать с какими ограничениями и сложностями можно столкнуться на крупных масштабах.
В своем докладе я попробую показать FluxCD непредвзято, со всеми плюсами и минусами, расскажу о чем стоит подумать при добавлении инструмента в свою инфраструктуру. Продемонстрирую возможности модульного подхода к управлению множеством кластеров, используя принцип DRY и сохраняя структурность и читаемость кода инфраструктуры. Рассмотрю применимость к средам, создаваемым по требованию на этапе PR. Также поговорю про автоматическую проверку и тестирование изменений в код инфраструктуры. Идем со мной в GitOps?

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

- Управление группами хостов как объектами kubernetes.
- Как мы гарантируем воспроизводимость процесса конфигурации.
- Что мы делаем в случае проблем с kubernetes control plane.
- Проблемы, с которыми мы столкнулись при разработке host-group-operator.
- Как мы управляем конфигурацией сервисов на базе ydb с помощью host-group-operator.
- Как мы организовали Continuous Deployment выкатываемых с помощью host-group-operator изменений.

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

Мониторинг, метрики, observability

* Как получить full stack-распределенную трассировку — от клика пользователя в SPA или мобильном приложении через все сервисы до SQL-запросов в БД.
* Автоматическая и ручная инструментация приложений.
* Как найти узкие места в работе приложений путем анализа трейсов, логов и метрик.
* Блеск и нищета OpenTelemetry, настоящее и будущее стандарта.

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

- Кратко, как мы разворачиваем дев стенды
- Работа с дев инфраструктурой как с продуктом
- Dora-metrics
- История развития дев инфраструктуры проблемы и вызовы
- Observability деплоя в дев
- Инструменты, которые используем: ansible, gitlab-ci

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

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

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

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

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

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

Начнем с паттернов, лежащих в основе любой современной TSDB. Вспомним, что было до Prometheus и почему именно Prometheus (с TSDB под капотом) стал стандартом.

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

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

Архитектура систем

Даже грамотно спроектированная микросервисная архитектура с течением времени требует пересмотра и рефакторинга.
— Как не пропустить этот момент в случае проектирования и разработки с нуля?
— Как понять, что легаси микросервисы спроектированы не лучшим образом?
— Как, собственно, начать рефакторинг архитектуры и, немало важно, закончить его и довести до прода в виде реализации?
Попробуем ответить на эти и другие вопросы в ходе доклада. Рассмотрим тревожные сигналы о необходимости рефакторинга, поговорим о принципах рефакторинга в переложении на архитектуру микросервисов, наметим конкретные шаги и этапы безопасного и итерационного рефакторинга архитектуры на практике с постепенным их выводом в бой.
А также порассуждаем как же жить с двумя и более версиями архитектуры пока рефакторинг ещё не доехал до прода.

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

Подробный разбор основных инструментов для управления трафиком, которые даёт нам Istio:
* DestinationRule
* PeerAuthentication
* AuthorizationPolicy
* VirtualService

В рамках доклада мы разберёмся в деталях, как устроены эти инструменты на уровне сайдкара, что умеют и, самое главное, что не умеют. Также мы изучим неочевидные нюансы при реализации паттернов управления сетевым трафиком:
* Mutual TLS
* Outlier Detection
* Authorization
* HTTP Routing (Canary Deployment)

Дополнительно мы рассмотрим возможности Istio по организации отказоустойчивых геораспределённых кластеров и я поделюсь опытом компании Флант по внедрению разных подходов:
* Multicluster
* Federation

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

Расскажу о том, как используется Salt (saltproject.io) в Managed Databases в Yandex Cloud.

* Зачем нам вообще Salt, какой частью функциональности мы пользуемся
* Что делать, когда хостов десятки тысяч, один salt-master не справляется, а выкатить нужно на конкретную машину
* Как мы отлаживаем упавшие запуски стейтов/модулей
* Про интеграцию Salt'а в систему распределенной трассировки
* Как тестируем свои модули/стейты и всю конструкцию в целом

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

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

Помочь могут архпринципы, но есть еще две проблемы:
1. команда не понимает, что это;
2. после написания их никто не применяет.

Как собрать и автоматизировать архпринципы, в которые команда поверит .

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

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

В этом докладе я покажу вам, как работает KubeVirt изнутри.

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

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

SRE-практики

Так уж сложилось, что тема SRE получила наибольшее распространение именно в серверных средах - бекенды, апишки, базы. Однако с ростом количества мобильных телефонов и увеличением их роли в жизни людей, вопросы доступности, наблюдаемости и надёжности мобильных приложений стали вставать всё острее.
В этом докладе я расскажу о том, какие SRE-практики мы применяем при разработке мобильного банка Тинькофф и что хорошего мы сделали, чтобы быстрее выявлять и исправлять проблемы (и не допускать их повторения). На основе нашего опыта предложу набор практик, которое прокачает надёжность вашего мобильного приложения.

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

Паттерн рейтлимитера кажется одним из самых очевидных паттернов. Так ли он прост на самом деле?

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

Как бонус обещаю роадмап по устранению техдолга для задач с рейтлимитером и рассказ о том, почему идея "сейчас добавим istio, и всё заработает само" может привести к фиаско в крупных приложениях.

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

"Ваш сервис работает медленно и с ошибками!" Как часто приходилось такое слышать? А что такое медленно и какое количество ошибок считать допустимым? А главное, как узнавать о проблемах раньше, чем пользователи? В таких случаях вспоминают про SLA и фиксируют для других и самих себя требования к работе сервиса.
У нас было несколько команд разработки, большой объем критичных для компании задач, сжатые сроки для их реализации, много новых микросервисов и старого легаси, команда SRE, которой нужно всё это поддерживать, и платформенная команда, которая попыталась реализовать решение для мониторинга SLA микросервисов с минимальными отвлечениями на это всех остальных команд. На выходе получили оповещения о нарушениях SLA "из коробки" и много пунктов для дальнейших улучшений.

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

В докладе я расскажу, как умение погружаться в код и отладку сторонних продуктов помогает нам повышать стабильность и находить исходную причину отказов на примере реальных сбоев высоконагруженного сервиса мониторинга с входящим потоком 2,5 Гбайт/сек, использующего Elasticsearch и VictoriaMetrics под капотом.

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

Безопасность

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

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

Существует большое количество различных инструментов безопасности (SCA, SAST, CA, etc.) которые встраиваются в CI. OpenSource инструменты для этих задач ведут себя по-разному, имеют различные форматы отчетов и механизмы исключений.
В этом докладе я расскажу о нашем опыте работы с OpenSource инструментами безопасности и про внутренний инструмент Quality Gate который позволил привести различные инструменты к единой схеме работы в CI.

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

Организация, развертывание и поддержание инфраструктуры современных приложений — сложный процесс, в котором многое может пойти не так.

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

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

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

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

В докладе рассматриваются вопросы, с которыми сталкиваются компании при первом подходе к внедрению управления секретами через Vault. Сколько ресурсов ему нужно? Как быстро он работает? Какое хранилище выбрать и почему? Как подключать приложения? Как запустить в него команды? Как скрыть секреты в пайплайне?
Мы проделали весь этот путь, собрали много граблей и хотим поделиться опытом.

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

Год назад мы познакомились с феноменом Protestware и хотя сейчас он встречается реже, нельзя сказать что перестал существовать полностью. Protestware не единственный пример нежелательного кода, никуда не исчез вредоносный код. Периодически случаются взломы разработчиков популярных пакетов, выкладываются новые версии пакетов, содержащие malware в своем составе.
В ходе доклада мы разберемся: как контролировать сторонние зависимости в вашем продукте, как бороться с malware/protestware библиотеках/пакетах, какие меры помогут обезопасить ваш продукт.

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

Supply chain security или безопасность цепочки поставок приложений – это отдельный мир со своими угрозами и практиками по защите. На базе основных шагов превращения исходного кода в готовый продукт / сервис, предоставляемый конечному пользователю, в этом докладе будет рассмотрено:
- Основные угрозы применимые к CI/CD и примеры их реализации;
- Методы и способы их защиты, не всегда требующие сложных технических перемен.

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

Митапы и workshop

TechLeadы и Синьоры

Коллаборативные практики проникают в IT на всех уровнях разработки: парное программирование, архитектурные комитеты, профессиональные комьюнити. Ex nihilo nihil fit - говорили римляне.

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

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

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

Надеюсь, доклад будет интересен и для С-level, и для руководителей, в чью зону ответственности входит выстраивание коммуникации и корпоративной культуры. А ещё для инженеров, которые понимают, что ценность она всегда в людях и в том, чего можно достичь совместно.

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

Трансформация

Наиболее технологичные компании у всех на слуху. Скорость, с которой они реализуют свои технические и процессные изменения, мало кого может удивить. Вполне типичная ситуация для лидеров сфер.
Однако, можно найти и вполне нетипичные истории. Одной из таких историй является опыт компании Холдинга Газпром-Медиа, которая запустила свою OTT-платформу кинотеатр Premier.

В своем докладе мы поделимся опытом выстраивания процессов с учетом уникальных и неординарных продуктов компании:
Специфика отрасли. Особенности разработки и эксплуатации медиа- и видеосервисов.
Capabilities платформы. Как пришли к решению создания единой, современной ИТ платформы. Из чего она состоит. Версия дефолтная, но с интересными нюансами (Harvester, Multitenant с GitOps, Kubernetes, растянутый на несколько ДЦ);
SDLC метрики. Что было до внедрения платформы и после. Результаты мониторинга эффективности разработки и поставки ПО, используя ключевые DevOps метрики.
Вызовы. Сложности, с которыми столкнулись при внедрении SDLC метрик и платформы.
Обязательно затронем такую тему, как эффект от изменений. Что было, что есть сейчас и какие наши следующие шаги.

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

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

Доклад научит DevOps'ов лучше понимать бизнес, а бизнес лучше понимать, что нужно от DevOps'ов.

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

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

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

Крупный бизнес активно идет в цифровизацию, ускоряет time-to-market и осваивает принципы DevOps. Но у Enterprise есть свои особенности, которые делают этот путь тернистым. CTO крупных компаний часто должен работать в условиях старого наследия on-premise ИТ-инфраструктуры, жестких требований безопасности и отказоустойчивости, множества легаси систем и вендорских решений. А если добавить ко всему уход вендоров и необходимость импортозамещаться, становится особенно больно. О том, как CTO и CIO решают проблемы цифровизации энтерпрайза в 2023, какой путь выбрали – отечественное ПО, Open Source, самостоятельная поддержка, а может быть, аутсорс? Где проблемы решили, а где еще предстоит?

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

В современных реалиях не так просто прийти к бизнесу и сказать: "Давайте всё автоматизируем, и всё будет хорошо!" Нет, это так не работает, особенно в крупных компаниях. А если у вас ещё и нет единого процесса внесения изменений, то каждый будет кто в лес по грибы, кто домой за скатертью самобраной приходить и навязывать свои идеи.

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

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

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

Практики разработки и тестирования

Что может быть прекраснее четко функционирующего конвейера? Только четко функционирующий конвейер, начинка которого сделана из качественных деталей и легко обслуживается. А ведь с кодом примерно та же история: о чистом коде все говорят, его редко видят, но еще реже — пишут. И зачастую непродуманная архитектура кода пайплайнов приводит к плохо переиспользуемым библиотекам, неявной структуре программы, его сложной дальнейшей модификации и адаптации под разные продуктовые команды. Особенную боль это доставляет тогда, когда им пользуетесь не только вы, но и ваши коллеги из соседних продуктовых команд. Настало время это исправить! Ведь пайплайн — это тоже сервис, и к нему должны предъявляться такие же требования, как и к внутреннему продукту компании.

В этом докладе мы:
* попробуем применить подход «12-факторного приложения» к пайплайну;
* посмотрим, как основные парадигмы ООП можно использовать при разработке пайплайна;
* научимся проводить декомпозицию кода пайплайна на интерфейсы;
* разберемся, как реализовывать платформно-зависимые участки кода так, чтобы ваш пайп мог работать и в Jenkins, и в Gitlab CI, и в любой другой среде;
* поймем, почему иногда полезно делать автотесты для кода пайплайнов.

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

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

Люди и сообщества

DevOps был призван сломать стену между Dev и Ops, но, оказалось, ломать её согласны только «девопс-инженеры» и то только для того, чтобы построить себе уютный колодец из её обломков.

В докладе спускаемся на дно колодца и обсуждаем проблему токсичности в DevOps-сообществе.

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

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

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

За последние два года я провел более ста собеседований и помогал развиваться многим людям, которые вырастали из Trainee в Junior из Middle в Senior и т. д. Всё это дало мне некоторое понимание и видение, которое культивировалось в open-source проект посвященный развитию инженеров и тех кому интересно DevOps направление.

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

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

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

Классические вопросы на технических интервью все мы уже знаем наизусть. Многие из них хороши и помогут нам найти классного специалиста в области внутреннего устройства библиотек. А как нам за час-полтора понять, что человек обладает нужным типом мышления, хорошо впишется в продуктовую команду и усилит её? Как построить интервью так, чтобы увидеть реальный уровень кандидата, а не его способность выучить все ответы из статьи "100 популярных вопросов на собеседовании"?
В своём докладе я расскажу, как построено техническое интервью в нашей команде.

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