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

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

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

Практики программирования

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

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

В ходе демонстрации я затрону работу со следующими сервисами:
- AWS Amplify CLI: quickly provision backend resources on AWS.
- [AWS Amplify JavaScript library] (https://aws-amplify.github.io/): front-end React application invokes backend resources.
- Amazon Cognito: authenticate users.
- Amazon DynamoDB: store the posts, follow relationships and timelines.
- AWS AppSync: host a managed GraphQL API.
- AWS Lambda: implement complicated business logics on server-side.
- Amazon Elasticsearch Service: implement full-text search.

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

Observability в enterprise

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

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

Будут рассмотрены вопросы выбора и группировки значимых метрик и лейблов, представлен обзор open source инструментов для выявления аномалий в метриках Prometheus, а также рассмотрены подходы основных enterprise и open source вендоров платформ observability к выявлению baseline и аномалий в производительности приложений в микросервисной архитектуре.



Воркшоп: Observability для микросервисных приложений в Kubernetes.

Это практическая сессия для DevOps, на которой вы сможете за 1 час посмотреть вживую систему observability для микросервисных приложений, работающих в Kubernetes.

Что мы будем делать вместе:
1. Развернем в кластере демонстрационное гетерогенное микросервисное приложение (стэк - NodeJS, Java, Python, Golang, PHP, MongoDB, Redis, MySQL, RabbitMQ, Nginx, AngularJS): https://github.com/instana/robot-shop

2. Установим в кластер под с системой observability, получим контроль всего кластера и всех микросервисов, трейсинг всех запросов и видимость на уровне кода.

3. Сгенерируем нагрузку, инициируем инцидент.

4. Расследуем инцидент используя метрики Golden Signals, принципы observability и выявления аномалий в метриках.


Требования:
1. Запущенный Kubernetes кластер, настроенный kubectl и helm.
2. Регистрация в Instana для получения полнофункциональной SaaS системы observability на 14 дней: https://www.instana.com/trial/ (можно сделать в ходе воркшопа

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

Эффективное использование облаков

Доклад посвящен практическому примеру по размещению статического сайта в инфраструктуре Amazon. Затрагиваются следующие аспекты:
* Причины популярности статических сайтов
* Преимущества размещения в AWS
* Подводные камни и нюансы, встречающиеся на пути
* Сервисы, которые потребуются для реализации

Программный комитет ещё не принял решения по этому докладу

ROI DevOps трансформации

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

Плюсы:
- экономия времени и денег;
- возможность быстро догнать бизнес конкурентов.

Минусы:
- выгорание сотрудников от изменений и нагрузки в период трансформаций;
- совсем не все готовы работать по-новому;
- вырастает нагрузка на HR.

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

Уроки, которые мы вынесли:
- не все люди готовы к подобному количеству единовременных изменений в организации и их уход из компании иногда лучше, чем их негативное влияние на коллектив;
- на фит-интервью новых сотрудников нужно проверять на вовлеченность и I/T-shape, а не только их хард- и софт-скилы;
- уделять особое внимание донесению сотрудникам всех долгосрочных плюсов от трансформаций как для компании, так и для них самих.

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

Тестирование новых продуктов

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

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

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

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

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

Логи, метрики, ошибки

Зачем стандартизировать процесс, если и так всё работает — долго, дорого, не гибко, но ведь работает же? А вы нам тут говорите о какой-то единой экосистеме CI/CD на базе atlassian, средств bug tracking и мониторинга appdynamics, splunk.

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

Расскажу, как мы в "Додо Пицца" пришли к необходимости тестировать alerting и recording rules в Prometheus.

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

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

DevOps на собственном (арендованном) оборудовании

В докладе я расскажу о двух свободных проектах: Kubernetes-in-Kubernetes и Kubefarm, которые мы используем для быстрого развёртывания Kubernetes-кластеров на собственном оборудовании.

В программе дня:
• Простейший способ развернуть и поддерживать в актуальном состоянии сотни серверов on-premise.
• Легко спавнить и удалять физические ноды как виртуалки.
• Разделять кластера и властвовать.
• Cluster API? Не, не слышали...
• Деплоить Kubernetes Helm'ом, WAT?

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

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

Надёжность продакшена

- Что понимать под "навыками сисадмина";
- можно ли забыть про хождение "по ssh руками";
- как при этом понимать, что происходит;
- нужно ли уметь собирать ядро в 2020.

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

Совместное планирование и разработка

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

Детально изучим инструмент Cause effect diagram. И с помощью него подготовим продажу реального кейса для бизнеса.

На воркшопе участники получат:
* Алгоритм выбора инструментов для анализа их ситуации;
* Научатся проводить встречи с использованием инструмента Cause effect diagram;
* Готовую диаграмму по их кейсу, который можно использовать в своей практике;
* Познакомятся с опытом коллег в решении подобных проблем.

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

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

Безопасность от планирования до эксплуатации

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

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

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

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

Техдолг

Уже много было сказано про "распил монолитов". Много было дискуссий про то, переписывать или нет. Активно идут обсуждения о том, как и от чего отталкиваясь, нужно бороться с возрастающей сложностью микросервисов.

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

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

Но взять и посадить этот самолёт, у которого SLO 24/7, в ангар для исправления накопленного техдолга шансов нет никаких.

Как быть? Строить самолёт на лету! И да, это возможно. Управление техдолгом — это не сказка о розовых пони, это болезненный для техдиректора процесс, который вытягивает из него все соки, заставляет непрерывно находить компромисс, верить настраивать и вдохновлять, когда, кажется, никто не верит.

И это норм, это просто такая работа.

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

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

Безопасная коммуникация, культура

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

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

Обсуждения открытые, каждый может высказаться.

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

10 years ago we had the idea to organise a conference in Gent to bridge the gap between developers and the people runing their code. It was the start of a new global movement. We never predicted that #devops would be where #devops is today. The word devops has evolved, the community has evolved.

Docker has solved all of our problems, the ones left behind were solved by Kubernetes. Everybody and their neighbour is Scrum certified now and we are all happily sipping cocktails on the beach. Or not? Why after almost 10 years of pushing culture change, teaching about Infrastructure as Code, teaching about Monitoring and Metrics … and help people to share both their pain and their learnings are most organisations still struggling with software delivery.

Over the years the word devops lost it’s meaning at least it’s original meaning. The real challenge for the next decade will be to see how we can revive those original values and ideas, if at all… Can we fix Devops? This talk will give you some Ideas about that.

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

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

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

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

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

Мы обсудим технологию управления состояниями (режимами работы мозга): как выбирать подходящие для выполнения задачи состояния, как быстро их включать и быстро переключаться между разнообразными типами задач. Отдельно поговорим про переключение на отдых, чтобы давать возможность мозгу восстанавливать ресурс.

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

Крокодил спросонья бьется об корягу и занимается рефлексией, пока не вспоминает заветное словно "магнолия".

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

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

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

Агенда
1. О себе.
2. ЧТО: Путь самурая и в какой момент появляется цель. (Мотивация к действиям, и как получить свой пинок).
3. ПОЧЕМУ: Зачем это нужно, и как вы своим развитием поможете коллегам, компании, сообществу и в первую очередь себе.
4. КАК: простые советы, подсказки, подходы. Бережем здоровье, не выгораем, идем спокойно. Никуда не спешим!
5. Закрытие, финальные слова, парочка напутствий, вопросы/ответы.

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

Что мы пытаемся починить переходом в облако, а оно не поможет.

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

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

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

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

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

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

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

Доверие команды внутри и снаружи

Доверие является главным слагаемым эффективной команды. Больше 60% всех проблем в команде связаны с отсутствием доверия. Мы знаем, как решить эту проблему!

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

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

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

- Базовый набор тестирования на проникновение: обзор популярного инструментария для поиска недостатков в сетевых сервисах и веб-приложениях.
- Фаервол нам не помеха или техники пивотинга.
- Распространенные ошибки разработчиков и системных администраторов, которые помогают атакующим достигать цели.
- Как теперь с этим жить? Оцениваем риски и противодействуем атакам.

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

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

Программный комитет ещё не принял решения по этому докладу

Непрерывная поставка

Day 2 DevOps typically requires a deeper insight and critical.

Most CI/CD approaches require teams to piece together data insights from various systems in order to get a full understanding of the value stream: Where are we slow? Are all of our tools working together? How do we better coordinate? And, unfortunately, current tools typically only paint part of the picture.

This session will demonstrate how IBM’s portfolio of DevOps products can help organisations connect and expose metrics across their various DevOps tools in order to gain visibility into possible improvements, as well as orchestrate deliveries across multiple continuous delivery tool chains. Ultimately bringing increased quality, lower cost, shorter delivery time, and reduced risk when developing highly integrated, heterogeneous, and complex systems.

Программный комитет ещё не принял решения по этому докладу

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

Способов развёртывания кластера kubernetes насчитывается не один десяток — как на bare-metal, так и на различных облачных платформах. Начинающие администраторы k8s обычно используют одну из известных утилит для сборки кластера и лишь намного позже узнают о подводных камнях того или иного решения. Каждый инсталлятор k8s содержит набор предубеждений его создателя, которые могут помешать настроить и собрать кластер так, как нужно конкретной компании. Когда приходит осознание, что дефолты инсталлятора не подходят для нужд компании, на кластере давным-давно production-нагрузки и пересобирать его уже нельзя.

Я расскажу, как неинвазивно переехать на наиболее конфигурируемый kubernetes the hard way и приведу примеры сценариев факапов и как их избежать.

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

Первый день:
1. Берем простой Hello world на Flask и докеризируем его.
2. Смотрим, как можно быстро локально поднять виртуалочку (vagrant), куда это будем деплоить автоматически (Ansible) в виде Docker-контейнера.
3. Рисуем простенький Helm-чарт для нашего приложения.
4. Учимся использовать авторский набор костыликов (https://github.com/maniaque/k1s) для развертывания локально кластера для быстрых тестов

Второй день:
Пункт 4 выполняем в Managed Kubernetes у Яндекс.Облака или на Bare-metal виртуалках в любом облаке.

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

Часто мы предпочитаем работать с готовыми инструментами, просто потому что они уже есть, и закрываем глаза на их недостатки. Мы долго управляли Github-ом вручную, а в какой-то момент решили внедрить подход Infrastructure-as-a-Code, для чего выбрали популярный Terraform.  И на наших объёмах -- 350+ человек и 400+ репозиториев -- это оказалось не очень хорошим решением.  Тщательно потоптавшись по граблям, мы запилили свой вариант на Ansible.
• Я расскажу про найденные грабли (лимиты Github, низкая производительность, провоцирует ошибки), и почему при наших размерах у Терраформа нет плюсов (хотя мы честно искали).
• Покажу наше решение на Ansible, которое отрабатывает в 10--100 раз быстрее, с простыми конфигами и другими плюшками.  Представлю типичные задачи, которые стало проще решать.
• И поделюсь реализацией своего решения в виде открытого проекта на Github.

Программный комитет ещё не принял решения по этому докладу

Инфраструктурная платформа

С ростом компании инфраструктура становится сложнее, постепенно стремясь к IaaS. В докладе мы рассмотрим IaaS как внутренний продукт компании.

Ответим на вопросы:
- Почему нужно смотреть на инфраструктуру как на продукт?
- Что это требует и какой приносит профит?
- Какие практики нужно использовать из продуктовой разработки?
- Какие вызовы встают перед командой?
- Как изменятся команда и процессы внутри нее?

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

Я всегда считал service mesh лишней абстракцией которую используют большие корпорации. Но жизнь в service oriented architecture натерла мне много мозолей. И оказалось что как раз в этих местах прекрасно можно проложить envoy для исправления ситуации. И суета по организации лишней абстракции окупится с лихвой.

Программный комитет ещё не принял решения по этому докладу

- Как развернуть инфраструктуру Data Science в Kubernetes
- Как автоматизировать жизненный цикл модели от эксперимента до эксплуатации при помощи MlFlow
- Как обучать модель используя Mlflow и kubernetes
- Как быстро превратить модель в современный масштабируемый облачный сервис.

Описание:
Приглашаем на вебинар "Создаём инфраструктуру для Data Science с помощью MLFlow в Kubernetes". На вебинаре мы расскажем вам о том, как организовать процесс разработки моделей машинного обучения на базе технологии MLFlow и интегрировать его в общий процесс разработки в вашей организации. Для этого мы сделаем небольшой теоретический экскурс в основные понятия и концепции, после чего развернём все необходимые инфраструктурные компоненты в кластере Kubernetes, продемонстрируем принципы работы с MLFlow и его возможности по автоматизации жизненного цикла модели, продемонстрируем процесс обучения моделей с помощью MLFlow в Kubernetes и, в заключение, расскажем о способах превращения полученных моделей в REST сервис и UDF функцию с последующим их запуском в Kubernetes.
Ждём Вас!​

Программный комитет ещё не принял решения по этому докладу

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

Именно это позволяет вам сделать Cloud Custodian - опенсорсный и бесплатный продукт, позволяющий админам настраивать политики контроля за облачными ресурсами в любом из трёх облачных сервисов - GCP, AWS, Azure. Можно задать и действия, которые будут автоматически выполняться по тому или иному интересующему вас событию. Cloud Custodian может отслеживать старт новых виртуальных машин в Compute Engine, развертывание новых кластеров Kubernetes, создание новых ролей в IAM, добавление прав пользователям, появление бесхозных бекапов и т.п.

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

Программный комитет ещё не принял решения по этому докладу

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

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

Технологии: Kubernetes; KubeFlow; TensorFlow; Python; Apache Bean

Программный комитет ещё не принял решения по этому докладу

Типовой стенд продукта состоит из 40 различных программ, для корректной работы системы все программы должны быть корректно настроены, соединены между собой и внешними системами. У типовой инсталляции 7 стендов с 4 различными типовыми конфигурациями и интеграциями.
Добавление новой программы в такую инсталляцию занимало 1-5 дней и требовало участие системного инженера, изменение зависимой конфигурации так же требовало 1-4 часа системного инженера.
Мы построили первую систему абстракции на bash&python, которая позволила логически описать зависимости в системах и снизить время участия системного инженера до 10-15 минут для большого круга задач и расширили участие разработчиков в описании абстракций их программ.
Это повысило скорость работы, но все равно подразумевало участие системных инженеров в процессе разработки и все равно оставляло бутылочное горлышко, ограничивающее дальнейший рост количества сервисов и вариантов инсталляций.
Поэтому мы разработали новую систему абстракции и управления конфигурацией с помощью Terraform, которая позволила строить большие многовариантные системы основываясь на логических описаниях самих программ, которые хранятся вместе с кодом программы. Эта система позволила нам исключить прямое участие системного инженера из процесса внедрения и доставки новых компонентов системы до всех целевых инсталляций и стендов, превратив ее в рутинный автоматический процесс.

Программный комитет ещё не принял решения по этому докладу

Есть пару идей чем занимать паузы между

Программный комитет ещё не принял решения по этому докладу

Сокращение time-to-market, ускорение процессов разработки ПО, уменьшение релизного цикла, увеличение количества репозиториев кода и артефактов – всё это становится головной болью для специалистов ИБ. Сегодня поговорим о том, как автоматизировать проверки ИБ, как ими управлять, и как тиражировать их на все продукты. В общем, поговорим о DevSecOps.

Программный комитет ещё не принял решения по этому докладу

SRE-практики

В два часа ночи приходит алерт — «виртуалка с базой данных недоступна!»
Шеф, все пропало! Сервис лежит час.
На утро оказывается, что у вашего хостера произошел сбой.

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

Всем же понятно, кто тут п.д.р?
Или нет?

Факапы бывают у всех, и я расскажу историю о том, как сделать, чтобы даже если виноват провайдер, у вас все было хорошо.
Я расскажу, зачем Google придумал SRE, какую пользу из этой практики извлекают провайдеры и их пользователи.
Мы поговорим про SLA, кто и как должен его соблюдать.
Я покажу конкретные примеры факапов облачных провайдеров, расскажу, кто виноват и почему рабочее приложение лучше извинений.

Программный комитет ещё не принял решения по этому докладу

DevOps-трансформация

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

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

В докладе я пройдусь по истории DevOps'а и по тому, почему DevOps как методология _создания_ программных продуктов стала трендом в головах бизнеса (часто заменяя или дополняя "Agile"). Попробую объяснить инженерам, в чем разница между потребностями бизнеса и тем, что видят важным они.

1. История развития доставки программного обеспечения от дискет и компакт-дисков до контейнеров.
2. Agile-методологии, почему они появились и как они связаны с доставкой?
3. Как DevOps появился из Agile и заменил Agile и почему он так привлекателен для бизнеса?
4. Какие инженерные решения максимально совпадут с интересами бизнеса, а про какие лучше говорить в отрыве от DevOps как методологии? Соответствие бизнесовых DevOps-метрик инженерным решениям.

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

Keeping track of infrastructure, operational tasks, and configuration (among other things) can be a daunting tasks to accomplish in this modern Elastic/Cloud world. Clicking on a Console or a Wizard does not give us the flexibility and speed at scale. If we start treating everything as code, and that everything being Infrastructure, Configuration, Application Deployment, and Operations, we can ensure to have repeatable, testable and secure ways of running our applications. In this session we will see how can we orchestrate all of this, and manage our workloads with a text editor and git. Its time to stop clicking and start committing.

Программный комитет ещё не принял решения по этому докладу

Мы, компания Экспресс 42, совместно с конференциями Олега Бунина (Онтико), решили провести исследование о состоянии DevOps в России. Мы давно вынашивали эту идею, так как понимали, что отчеты других компаний (DORA, Puppet, DevOps Institute) не дают ответов на вопросы, как DevOps развивается у нас.

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

Исследование будет проводиться в течение августа, а в конце сентября мы оформим результаты исследования в общедоступный текстовый отчет и расскажем про основные выводы на конференции DevOps Live 2020.

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

Я работаю в компании аналитического приборостроения "Люмэкс". Мы разрабатываем, производим, продаем и обслуживаем приборы для химического анализа. Наши продукты объединяют три составляющие: железо, софт и методику работы. В докладе я расскажу, что мы делаем для того, чтобы развивать продукт, состоящий из этих разных слагаемых.

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

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

Доклад на тему как оптимизировать CI инфраструктуру, как найти проблемы в текущей инфраструктуре, советы по оптимизации Jenkins, процесса сборки и тестирования. Как мониторить свои достижения - мониторинг и KPI.

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

So often, organizations working to adopt DevOps initially focus on selecting tools and manipulating their choices to automate bad practices hoping to maximize efficiency. Automation is the easy part. But without culture transformation and process optimization, an organization will never realize their true potential. Optimizing the system as a whole – a system made up of people, processes and tools - means reviewing, questioning and potentially changing how things are across the entire lifecycle. During this meetup, let’s collaborate on techniques to change culture, the value of mapping the value stream, and the automation tools available to help.

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

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

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

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

Так всё же, может или нет существовать такое понятие? Как тогда должны называться люди, выступающие проводниками философии DevOps на практике? И если DevOps-инженеры существуют, то какие они?

Все эти горячие вопросы обсудим на полях данной дискуссии!

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

- Как начать проект, создавая сразу необходимую DevOps атмосферу в коллективе
- Как получить DevOps как процесс , а не как отдельного человека
- Как бороться с возражениями команды
- В какой момент получилось продолжать строить процессы силой Dev и QA команд, без участия так называемого "DevOps инженера"
- Какие инструменты автоматизации мы использовали и как происходило обучение QA и Dev коллег использованию
На все эти вопросы я дам предельно четкие ответы!

Программный комитет ещё не принял решения по этому докладу

DevOps is often perceived to be a technology centric topic. The struggle of aligning IT and Business on a shared understanding of DevOps is real. Without this alignment many DevOps transformation initiative fail to deliver desired outcomes. A DevOps strategy brings the biz-tech alignment to life. It helps to encapsulate gory technical details into business friendly language. In this session, we will explore a structured approach to create your own DevOps strategy using the DevOps Strategy Canvas. The canvas is an innovative tool for creating a shared vision and unlocking the promise of DevOps across the enterprise.

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

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

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

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

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

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

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

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

Архитектура в DevOps, DevOps для CTO

Java-архитектор и DevOps-архитектор встретятся в битве за микросервисы.

* Избыточны ли ресурсы на каждый микросервис?
* Есть ли необходимость в постоянном рефакторинге и как грамотно организовать рабочее место?
* Обсудим все вопросы, которые вы давно стеснялись обсудить!

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

Как современное IT меняет процесс производства товаров.

Программный комитет ещё не принял решения по этому докладу

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

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

Программный комитет ещё не принял решения по этому докладу