Конференция завершена. Ждем вас на DevOpsConf в следующий раз!

Доклады

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

Как управлять сотнями sidecar-контейнеров в Kubernetes без боли и сожаления

Технологии виртуализации и контейнеризации
Управление конфигурацией
Облака
DevOps / Кубер

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

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

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

Модульное IТ, или Как угодить бизнесу, разработке и сопровождению одновременно

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

Возможно ли угодить всем и сразу?

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

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

Как DevOps-инженеру стать платформенным, используя фреймворк Platen.dev

Архитектурные паттерны
Корпоративная культура и мотивация
Поиск и развитие команды
Продуктовая разработка
Управление командой
Трансформационные изменения
Управление изменениями
Профессиональное развитие инженера
Методологии

Уверен, что вы слышали про 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. что такое самодостаточные/потокоцентричные команды, и причем здесь ответственность в конвейере производства. Как командам доставлять изменения до клиентов самостоятельно в платформенной модели.

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

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

Строим NoOps-платформу, или Как импортозаместиться

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

Расскажу:
* про то, как стандартизировать подходы, упростить DevOps и не выстрелить себе в ногу;
* про жизнь в новых реалиях — как создать импортозамещенную Kubernetes-платформу;
* про технологии, которые убеждают команды разработки «жить дружно».
А также обсудим перспективы развития движения.

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

Сказ о том, как мы платформу в продукт превращали

Выбор стратегии долгосрочного развития, KPI
Метрики
Лайфхаки
Анвар Туйкин

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

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

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

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

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

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

Как управлять базой знаний и не сойти с ума (на примере Confluence)

Типовые ошибки
Лайфхаки
Базы знаний / wiki
Документация
Knowledge Ops

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

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

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

16 точек потери эффективности при работе с базой знаний

Базы знаний / wiki
Инструменты
Привитие культуры КМ
Николай Сенин

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

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

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

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

Вы ещё нанимаете? А мы уже учим!

Артём Кротов

Мир Plat.Form

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

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

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

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

Инфраструктура как код (9)

Автоматизированное создание окружений для R&D-команд

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

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

Декларативное управление конфигурацией узлов Kubernetes в масштабе

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

CTO «Лаборатория числитель»

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

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

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

Разбираемся во внутренностях CI/CD Ozon, или Как мы получили единую CI/CD-систему?

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

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

Как перестать быть YAML-разработчиком. Переходи на сторону CUE

Оптимизация производительности
Рефакторинг
Управление конфигурацией
Непрерывное развертывание и деплой
Непрерывная интеграция
Devops / другое
Управление изменениями
Поддерживаемый код
Автоматизация разработки, доставки, эксплуатации
DevOps / Кубер
Инфраструктура
Инструменты

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

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

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

Ваши админы за 10 лет так и не смогли стать девопсами. Разработчики смогли

Микросервисы, SOA
Архитектурные паттерны
Методы и техника разработки ПО
Поддерживаемый код
Практики программирования
Слабо связанная архитектура

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

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

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

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

Terraform-код — в поисках Грааля

Непрерывное развертывание и деплой
Поддерживаемый код
Практики программирования
Облака
Инфраструктура
Максим Кострикин

ИП Кострикин Максим Николаевич

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

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

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

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

Операторы в Kubernetes — теория и практика создания

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

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

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

GitOps + FluxCD: продвинутые практики управления K8s-инфраструктурой

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

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

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

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

Минимализм, лаконичность и LowOps: управляй конфигурацией хостов с помощью kubectl apply

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

История о том, как мы получили минималистичный инструмент управления конфигурацией хостов в виде host-group-operator, используя Kubernetes в качестве универсального control-plane.

Затронем следующие темы:
* Как перестать думать о поддержке системы управления конфигурацией.
* Как управлять конфигурацией хостов так же просто и единообразно, как мы управляем стандартными объектами Kubernetes.
* Как упростить управление релизами логики, отвечающей за изменение конфигурации хостов.
* Как мы разработали host-group-operator, какие шишки при этом набили и сколько ушло времени на разработку.
* Когда стоит задуматься о разработке собственного оператора для управления произвольными объектами инфраструктуры.

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

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

Observability распределенных приложений

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

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

Мониторинг бизнес-процессов c помощью Opentelemetry

Логирование и мониторинг
Observability в enterprise
Метрики
Михаил Морев

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

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

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

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

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

Easy-peasy dev. Как мы меняем инфраструктуру разработки с помощью продуктовых подходов

* Работа с дев-инфраструктурой как с продуктом.
* Dora-metrics.
* История развития дев-инфраструктуры, проблемы и вызовы.
* Observability деплоя в дев.

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

Мимо тёщиного дома я без метрик не хожу. То им пром в забор просуну, то mimir'у покажу!

Логирование и мониторинг
Devops / другое

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

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

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

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

Архитектура систем (8)

KubeVirt: внутреннее устройство и сеть. Как достигнуть совершенства?

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

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

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

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

Как рефакторить архитектуру микросервисов при живом продакшне?

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

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

А также порассуждаем, как же жить с двумя и более версиями архитектуры, пока рефакторинг ещё не доехал до прода.

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

SaltStack at Scale

Python
Управление конфигурацией
Администрирование баз данных

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

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

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

Istio в разрезе: что умеет и не умеет самый популярный Service Mesh

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

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

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

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

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

Как сделать просто сетевую изоляцию в рамках кластера K8s

Сетевое администрирование
Devops / другое
Безопасность от планирования до эксплуатации
DevOps / Кубер
Сеть

1. В чем суть zero trust. Как делать развертывание приложений безопасно.
2. Варианты имплементации zero trust в рамках кластера K8s (Service-mesh, CNI).
3. Как сделать безопасно и быстро. Баланс между уровнем безопасности и временем, потраченным на его настройку.
4. Использование Calico. Разберем кейсы, посмотрим код.

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

Справляемся с проблемами после переезда в Kubernetes

Логи, метрики, ошибки
DevOps / Кубер

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

Проблемы:
* CFS и троттлинг CPU;
* Slow connect (TCP Retransmit) via Node Port;
* рандомные рестарты POD с PHP.

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

Арх. принципы: бумага или реальность

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

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

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

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

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

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

Istio: распределенное приложение

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

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

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

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

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

SRE-практики (7)

Особенности SRE и Observability в мобильных приложениях

Мониторинг и эксплуатация мобильного приложения
Производительность и мониторинг фронтенда
Mobile first

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

В этом докладе я расскажу про особенности SRE в мобильных приложениях и сосредоточусь на их observability. На основе опыта мобильного банка — основного приложения Тинькофф — расскажу, как и за какими метриками мы следим.

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

Все, что надо знать о рейт-лимитах, и даже больше

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

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

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

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

Мониторинг SLA микросервисов без регистраций и СМС

Логирование и мониторинг
Observability в enterprise
Логи, метрики, ошибки
Автоматизация разработки, доставки, эксплуатации
Микросервисы
Метрики
Дмитрий Куянов

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

"Ваш сервис работает медленно и с ошибками!" Как часто приходилось такое слышать? А что такое медленно и какое количество ошибок считать допустимым? А главное, как узнавать о проблемах раньше, чем пользователи? В таких случаях вспоминают про SLA и фиксируют для других и самих себя требования к работе сервиса.

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

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

Инцидент-менеджмент и управление рисками

Управление инцидентами
Надёжность продакшена
DevOps / SRE

Из доклада вы узнаете, как построить процесс управления инцидентами с нуля, снизить риски и улучшить свой RTO. Компания YCLIENTS поделится своим опытом улучшения уровня качества обслуживания за счет инцидент-менеджмента, а также раскроет подводные камни и сложности выстраивания процесса.

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

Alert Fatigue. Когда алертов слишком много

Избыточные алерты убивают людей. Буквально.

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

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

Почему не работает SRE в Enterprise?

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

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

Почему для SRE важно уметь читать код

Логирование и мониторинг
DevOps / SRE

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

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

Безопасность (7)

Топ некритичных ошибок в инфраструктуре, приводящих к критичным проблемам

Управление конфигурацией
Техдолг
Управление уязвимостями
Application security
Безопасность от планирования до эксплуатации
Инфраструктура
Атаки
Безопасность
Безопасность инфраструктуры

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

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

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

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

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

DevSecOps без безопасников: пределы возможного

Работа со внешним заказчиком/исполнителем
Тестирование безопасности
Управление разработкой
Application security
Безопасность
Илья Поляков

Angara Security

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

И всё это в зависимости от размера компании, поскольку он имеет значение.

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

Гид автостопщика по HashiCorp Vault

Павел Яньков

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

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

Мы проделали весь этот путь, собрали много граблей и хотим поделиться опытом.

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

Контроль безопасности стороннего кода при разработке

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

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

В ходе доклада мы разберемся, как контролировать сторонние зависимости в вашем продукте, как бороться с malware/protestware в библиотеках/пакетах, какие меры помогут обезопасить ваш продукт.

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

История построения AppSec в огромном Enterprise и опыт его применения в бирюзовой компании

1. Не надо стесняться! Или история о том, когда глаза боятся, а руки делают.
2. Цифровая трансформация и проблемы безопасности Энтерпрайза.
3. Цифровая трансформация — совместный вызов ИБ и IТ.
4. Изменение фокуса команд разработки и подсвечивание задач ИБ.
5. Автоматизация — двигатель прогресса! История создания платформ безопасности.

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

Quality Gate ИБ в CI — как получить понятный результат от контролей безопасности

Управление уязвимостями
Application security
Безопасность
Инфобезопасность

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

В этом докладе я расскажу о нашем опыте работы с Open Source-инструментами безопасности и про внутренний инструмент Quality Gate, который позволил привести различные контроли безопасности к единой схеме работы в CI.

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

Supply chain security. Позитивный опыт

Безопасность программного кода, SQL и прочие инъекции
Application security
Безопасность от планирования до эксплуатации
Безопасность
Максим Залысин

Positive Technologies

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

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

Митапы, круглые столы, воркшопы (3)

Круглый стол "DevOps в Enterprise. Вендорские решения vs Open Source vs аутсорс"

Юрий Семенюков

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

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

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

Александр Подмосковный

Московский Кредитный Банк

Евгений Харченко

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

Евгений Ефименко

ООО "ДМ-Тех"

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

О том, как CTO и CIO решают проблемы цифровизации энтерпрайза в 2023, какой путь выбрали — отечественное ПО, Open Source, самостоятельную поддержку, а может быть, аутсорс? Где проблемы решили, а где еще предстоит?

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

Интенсив: понять Kafka за 90 минут

Базы данных / другое
Глеб Гончаров

СберМаркет

Интенсив «Kafka за 90 минут» состоит из двух частей: теории и практики. Теория поможет составить ментальную модель Kafka, а практика — попробовать инструмент в действии и получить набор готовых конфигураций для применения их в своих лабораторных и тестовых средах на работе.

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

Практика:
* Склонируем репозиторий с конфигурацией Docker Compose.
* Подберём конфигурации топиков и создадим их.
* Настроим и запустим продюсер.
* Настроим и запустим консумер.
* Изменим оффсет для консумер-группы.
* Посмотрим на основные показатели в Grafana.

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

Круглый стол “Эффективный наем технических специалистов в компании — от стартапов до корпораций”

Дмитрий Матвеев

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

Злата Занина

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

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

Не упусти свой шанс узнать ответы на эти вопросы на круглом столе с экспертами отрасли!

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

Трансформация (6)

IТ-трансформация в компании уровня Enterprise. Нестандартные кейсы. Опыт Газпром-Медиа Холдинга

Технологии виртуализации и контейнеризации
Трансформационные изменения
Время разработки и поставки задач
Логи, метрики, ошибки
DevOps / Кубер
Константин Тарасевич

ГПМ Цифровые Инновации

Юрий Игнатов

Экспресс 42

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

Однако среди существующих лидеров случаются и нестандартные кейсы. Одним из них является опыт «Газпром-Медиа Холдинга», который запустил свою OTT-платформу кинотеатр Premier.

В своем докладе мы поделимся опытом выстраивания процессов с учетом уникальных и неординарных продуктов компании:
• Специфика отрасли. Особенности разработки и эксплуатации медиа- и видеосервисов;
• Capability создания динамических окружений для разработки и тестирования. Нюансы технологических решений (Управление множеством Kubernetes кластеров, Multitenant с GitOps);
• SDLC-метрики. Что было до внедрения платформы и после. Мониторинг эффективности разработки и поставки ПО с использованием ключевых DevOps-метрик;
• Вызовы и сложности, возникавшие при внедрении SDLC-метрик и платформы;
• Оценка эффекта от изменений и перспективы развития.

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

DevOps умер. Да здравствует DevOps!

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

Экспресс 42

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

Уже сейчас можно выделить три крупных блока практик:
* SRE-практики (вобрали в себя инженерию работы с распределенными системами, практики совместной работы со сложными системами),
* Platform Engineering (инженерия инфраструктурных решений, работа с платформой),
* Value Stream Manegement (командные топологии и взаимодействие команд).

В докладе хочу разделить эти практики, рассказать их суть и показать, что это и есть DevOps.

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

Практика применения DevOps-аутсорса на разных этапах жизненного цикла продукта

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

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

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

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

Как развивать техническую культуру через исследования команд и не сгореть

Теории и техники анализа
Аналитика / другое
Процессы и инструменты в enterprise
Управление командой
Управление разработкой
Личное развитие
Профессиональное развитие инженера
Захар Фролов

Росбанк

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

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

DevOps-трансформация. Как раздать инженеров по командам и не погибнуть

Менеджмент в эксплуатации
DevOps / SRE

История о том, как мы превратили классический "отдел DevOps" в продуктовую команду с сильным техническим центром.

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

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

DevOps Governance в Enterprise

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

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

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

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

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

Представляем отчет о рынке инструментов DevOps: Russia DevOps Report 2022

В рамках доклада эксперты Платформы Сфера впервые представят результаты исследования российского рынка инструментов DevOps за 2022 год.

О чем можно будет узнать из отчета:
* в каком объеме применяются инструменты DevOps в российских компаниях;
* что, с точки зрения IТ-менеджеров и DevOps-разработчиков, является основными преимуществами в использовании подходов DevOps;
* сдерживающие факторы для использования DevOps и планы компаний по расширения использования этих инструментов;
* степень автоматизации процессов конвейера разработки с применением инструментов, поддерживающих DevOps, в российских компаниях;
* планы по замене инструментов разработки в связи с уходом ряда компаний с российского рынка (что на что планируется менять);
* степень использования облачных сервисов и ПО с открытым кодом.

Исследование проводилось с декабря 2022 по конец февраля 2023. Все участники сессии смогут бесплатно получить электронную версию отчета.

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

Реализация FinOps-практик в облаках. Облака, бюджеты и Serverless

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

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

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

Коллаборативные практики разработки и при чем тут Болонский процесс

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

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

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

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

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

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

OOP Pipeline As a Service: декомпозиция пайплайна на ООП-интерфейсы для лучшего переиспользования и поддержки

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

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

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

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

Локальная инфраструктура для разработки K8s-native ПО

Мы расскажем про полностью локальную инфраструктуру для разработки Kubernetes-native ПО на примере разработки Luntry. Как, купив 2 сервера в самом начале, можно пережить трехкратный рост количества микросервисов и трехкратный рост команды. Как при этом минимизировать ручную работу, сделать разработчиков довольными и не платить за облака.

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

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

DevOps — путь на социальное дно, или Пробиваем дно DevOps-колодца

Кирилл Демченко

Х5 Технологии

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

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

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

Хочешь расти в DevOps, но не знаешь как? Приходи, расскажу!

Devops / другое
DevOps / SRE
Инструменты
Методологии
Менторинг
Внутреннее обучение
Евгений Харченко

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

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

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

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

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

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

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

Как нанять продуктового разработчика

Поиск и развитие команды
HR
Команда
Подбор команды
Техинтервью
Злата Занина

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

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

В своём докладе я расскажу, как построено техническое интервью в нашей команде.

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

TechTalks (4)

Выбор CI/CD-системы

1. Что такое CI/CD.
2. Что должна уметь CI/CD-система.
3. Какие CI/CD-системы есть на рынке, сравнение, выбор.
4. Каким должен быть идеальный CI/CD-пайплайн.
5. Какие CI/CD-системы есть в Газпромбанке, почему именно они.

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

Развитие контейнерной инфраструктуры Мир Plat.Form

Контейнерная инфраструктура — это не новшество или тренд, а уже проверенный и надежный подход к развитию IT-платформ. Мы в Мир Plat.Form пришли к технологиям контейнеризации в уже далеком 2017 году. И Антон расскажет, "как было" и "как стало".

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

Тестовые полигоны Банка ГПБ и инструменты DevOps

Игорь Чернов

Газпромбанк

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

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

Формирование команд и запуск новых проектов — путь от автотестера до тимлида тимлидов

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

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

Фейл-секция (1)

Fail-митап

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

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

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

Резерв (1)

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

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

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