Программа форума

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

Кирилл Меньшов
Ростелеком
Старший вице-президент по информационным технологиям, член Правления
Mark Smalley, Netherlands
Smalley.IT
CEO
Ant Weiss, Israil
Otomato
CEO
Carlos Leon, Netherlands
Independent consultant
Кофе-брейк
Секция #1
Зал "Сокольники 1"

Модератор:
Ant Weiss
Otomato
, генеральный директор
Михаил Бижан, Москва
Райффайзенбанк
Директор по автоматизации
Егор Маслов, Москва
Манго Телеком
Руководитель группы разработки
Юрий Минаев, Тула
PVS-Studio
C++ разработчик
Секция #2
Зал "Сокольники 2"

Модератор:
Кирилл Ветчинкин
БКС брокер
, руководитель управления

Максим Васильев, Москва
Kublr
Senior DevOps Engineer
Иван Пономарев, Москва
КУРС
Tech Lead
Карен Товмасян, Нидерланды
NewMotion
Инженер-архитектор облачных решений
Платные
мастер-классы
Алексей Егоров, Минск
Kublr
Senior DevOpsEngineer
Евгений Овчинцев, Москва
Neoflex
Старший специалист
Игорь Авдеев, Москва
Neoflex
Руководитель группы DevOps-практик
Обед
Секция #1
Зал "Сокольники 1"

Модератор:
Ant Weiss
Otomato
, генеральный директор

Егор Иванов, Москва
Silver Bulleters
Ведущий разработчик
Модератор:
Евгений Злобин, Москва
SoftwareONE
Senior Cloud & DevOps Solution Architect
Секция #2
Зал "Сокольники 2"

Модератор:
Кирилл Ветчинкин
БКС брокер, руководитель управления

Андрей Бешков, Москва
Softline
Руководитель направления развития бизнеса DevOps
Игорь Авдеев, Москва
Neoflex
Руководитель группы DevOps-практик
Кирилл Мельничук, Украина
AlterEGO
CBDO
Дмитрий Иртегов, Новосибирск
Kublr
Разработчик
Роман Пономарев, Москва
Райффайзенбанк
Руководитель группы поддержки внутрених ИТ сервисов
Алексей Лосев, Калуга
Logrocon
Директор по разработке
Артур Аюханов, Москва
Silver Bulleters
Руководитель отдела разработки
VIP круглый стол
Зал "Лубянка"

Модератор:
Андрей Бешков, Москва
Softline
Руководитель направления развития бизнеса DevOps
Открытый микрофон
Зал "Сокольники 2"

Модератор:
Михаил Жучков
Neuron.Digital,
SRE TeamLead
Бесплатные
мастер-классы
Алексей Лосев, Москва
Logrocon
Директор по разрвботке
Вадим Рутковский, Чехия
Red Hat
Senior Software Engineer
Закрытие
VIP-ужин
Иван Пономарев, Москва
Непрерывный статический анализ
Статические анализаторы – наши верные помощники, умеющие зорко просматривать код на предмет нарушений форматирования, характерных багов и даже ошибок правописания и конфигурации. В докладе мы рассмотрим, как заставить анализаторы приносить пользу в вашем конвейере непрерывной интеграции, в том числе для старых и не использовавших ранее анализ проектов. Обсудим ограничения анализаторов и их место в процессе непрерывной интеграции. Рассмотрим «метод храповика» уменьшения количества находок статического анализа. Примеры кода будут на Jenkins, но общие принципы могут быть применены для любой CI системы.
Карен Товмасян, Нидерланды
Переезд в публичное облако (на примере AWS)
  1. Вступительная часть: AWS vs On-Prem, почему люди уезжают в облако, какие виды миграций бывают, что учитывать перед миграцией
  2. Стадии миграции. Делать ли миграцию своими силами, почему, как к этому подготовиться. Важность foundation и IaC. Как не потерять данные при переезде, Day 2 operations.
  3. Дальнейшие шаги. Освоение serverless, переход от self-hosted сервисов к managed сервисам. Пара слов o Cloud Native.
Ant Weiss, Израиль
ДевОпс 10 Лет Спустя: Что Дальше?
Ровно 10 лет назад в Генте прошла первая конференция DevOpsDays. Именно этот день считается днем рождения всего того, что мы сегодня называем ДевОпс. Самое время посмотреть назад, увидеть, чего мы уже достигли, а главное - посмотреть вперед и понять куда мы идем. Скорость изменений только растет, инструментарий обновляется каждый день, а волна хайпа так и грозит накрыть нас с головой. Кто-то запускает Куб на IoT девайсах, кто-то барахтается в сервисном сите, а кто-то мечтает попасть в бессерверный рай. Ну а инженеры? Как говорил классик: "обыкновенные люди… в общем, напоминают прежних… квартирный вопрос только испортил их".

Давайте же разберемся - что происходит, что делать дальше - и нужен ли нам вообще ДевОпс в 20-ых годах.
Алексей Лосев, Калуга
Статистические методы в управлении разработкой
В рамках мастер-класса посмотрим, как вероятности влияют на процесс разработки. Обсудим, что такое системное и несистемное отклонение. Узнаем, почему нельзя назначать премии за эффективность в предыдущем периоде. Посмотрим, почему Канбан действительно экономит деньги. Увеличим производительность системы в ~1,5 раза, выделив в системе ограничение.
Мастер-класс проходит в виде небольших вставок теории и практических упражнений с кубиками. Сначала моделируется система в которой все участники имеют одинаковые кубики имитирующие производительность участников процесса. Смотрим, что система не достигает среднего и растет объем незавершенного производства. Разбираемся, что незавершенное производство - зло. Требование написанное пол года назад -устарело, надо переделывать. Смержить ветку которую не трогали пол года - целая эпопея. Анализируем какая реальная производительность была у разных участников и что она не всегда зависела от человека. После этого вводим практику Канбан, и смотрим, что производительность не меняется, а запасы сокращаются. Третий цикл, расширение производства до и после ограничения. Смотрим, как растет производительность системы. Изменяем систему, привязав объем взятия в работу к работе ограничения и увидим, что производительность высокая, а объем незавершенного производства не растет. Последний кейс с обнаружением не системных отклонений, когда у двух участников кубик становиться не шестигранный и как это сразу видно на графиках. Подводим итоги.
Алексей Лосев, Калуга
Почему люди сопротивляются изменениям и как им помочь принять их
Внедрение практик DevOps - это процесс изменений, совершенствование процессов - это опять процесс изменений. Мы все время меняемся. Как помочь людям принять изменения, как донести до них именно то в изменениях, что позволит им не только их принять, но и стать проводником. Об этом и поговорим.
Егор Маслов, Москва
Автоматизация полного цикла тестирования в SCRUM команде
В докладе будет показано, как две нередкие проблемы скрам-команд - "сырая" документация и нечеткий цикл тестирования - решаются за счет практик и инструментов автоматизации (Testrail + Behave + GitLab-CI). Мы расскажем о том, как гармонично внедрить работу с этими инструментами в регламент работы по спринту без дополнительных временных затрат. Также мы покажем, каких результатов достигли лично мы и сколько рабочих часов нам удалось при этом сэкономить.
Дмитрий Иртегов, Новосибирск
Kubernetes: etcd – сердце и желудок
Ключевая часть инфраструктуры Kubernetes – это распределенное транзакционное хранилище etcd. Кластер etcd в значительной степени определяет производительность и стабильность Kubernetes API и кластера в целом.

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

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

Заявления разработчиков и наши опыты показывают, что etcd устойчив к отказу одного узла, в том числе – к отказам сети между узлами, перезагрузке или даже длительному отключению узла и даже к отказу диска (например, к отключению iscsi хранилища, на котором размещены данные узла). После всех этих ситуаций кластер довольно легко восстанавливается сам, когда будет устранена проблема, вызвавшая отказ.

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

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

Обе эти опасности связаны с логикой работы протокола Raft, при помощи которого etcd реализует распределенные транзакции, и с особенностями реализации Raft в etcd. Используя средства мониторинга etcd, можно с большой детализацией увидеть, к чему именно приводит неправильно выбранная дисковая конфигурация.
Юрий Минаев, Москва
Статические анализаторы кода как DevSecOps решение
Многие слышали или сталкивались со статическим анализом кода (SAST). Их репутация была существенно подпорчена старыми инструментами, которые для простоты назовём "линтерами". Доклад будет полезен тем, кто пробовал, но ему не понравилось :). Статические анализаторы не стояли на месте. Продемонстрируем возможности современных инструментов и поговорим об интеграции в существующие старые проекты. Отдельное внимание уделим вопросам информационной безопасности и таким стандартам, как CWE.
Вадим Рутковский, Чехия
Тут всю систему менять надо: чиним сломанные k8s кластеры вместе с сертифицированными слесарями
Во время этого мастеркласса мы сыграем в ролевую игру, где участники будут играть новичков в молодой, динамично развивающейся компании "ООО Вектор". Предыдущий сисадмин уже ушел, а в компании сломаны 10 кластеров Кубернетеса. Участникам предлагается объединиться в команды и починить их до обеда, после чего пить чай, делиться историями о сломанных кластерах и обсудить меры по предотвращению подобного в будущем.
Carlos Leon, Нидерланды
Management sucks: why won't they listen to me?
If you've been in the industry long enough you most likely have been there: you understand the technical challenges of a problem and know that the solution lies on adopting technology X or getting rid of that old piece of code on project Y.
However, no matter how you put it, management just doesn't get it. How frustrating is that? Very frustrating, if you ask me.
Or how about that raise that you were asking for? Didn't go as expected, did it?
The problem is not management. It's your selling skills that suck.
This talk is targeted at developers & operators struggling to get ideas up to management.
It's also targeted at managers struggling to get approval for their budgets/transitions/revamping of projects.
Spoiler alerts: I'll teach you how to sell ideas and how to sell yourself.
Михаил Бижан, Москва
Итак, вы научились автоматически деплоить в продакшн, но бизнес все еще не рад. Что дальше?
Мы в Райффайзенбанке очень верим в DevOps и автоматизацию. Эта вера основана на том, что мы хоть и не сразу, но поняли, что они нам дают, кроме увеличения рыночной стоимости отдельных инженеров.
Теперь мы умеем пользоваться автоматизированным производственным конвейером, так, чтобы это приносило банку пользу. На пути к этому умению мы решили несколько вопросов, ответами на которые я поделюсь с вами:

  1. Зачем нужна возможность быстро деплоить в теории, и как мы используем ее на практике. Почему CI/CD + SAST/DAST + K8s недостаточно, для того, чтобы компания начала больше зарабатывать.
  2. Почему автоматизация обычно слабо влияет на Time to market. Как сделать, чтобы повлияла.
  3. Что сделать, чтобы спонсор вашей DevOps-трансформации остался довольным. Как убедиться, что вы не продали бизнесу DevOps как серебряную пулю.
  4. Вишенка на торте: Continuous assessment. Как спроектировать систему мониторинга процесса производства ПО так, чтобы ей захотели пользоваться разработчики.

Алексей Егоров, Минск
Canary Releases on Kubernetes with Spinnaker, Istio, and Prometheus
In a microservices world, applications consist of dozens, hundreds, or even thousands of components. Manually deploying and verifying deployment quality in production is virtually impossible. Kubernetes, which natively supports rolling updates, enables blue-green application deployments with Spinnaker. However, gradual rollouts is a feature that doesn't come out-of-the-box but can be achieved by adding Istio and Prometheus to the equation.
Евгений Овчинцев, Москва
OpenShift + OpenWhisk = мечты разработчика сбываются или FaaS в действии
РАСКАЖЕМ о концепции FaaS, которая упрощает процесс разработки приложений и позволяет сосредоточиться на бизнес-логике.
РАЗВЕРНЕМ, и настроим в OpenShift – необходимую инфраструктуру для разработки функций как сервисов. СОЗДАДИМ несколько функций на базе современных технологий, образующих полноценное IT-решение.
НАСТРОИМ с нуля конвейер непрерывной доставки новых функций, реализующий принцип разработки через поведение (BDD) для контроля качества нашего решения.
Mark Smalley, Netherlands
If-then-maybe
In case you hadn't already noticed, the 'systems' that you work with, are not always predictable. There is not always enough information available for analysis and decision-making. Part of the world is simply unknowable. This is frustrating for developers who are used to the 'if-then-else' mental model. So how do we deal with 'if-then-maybe'?

Fortunately, a model with four boxes comes to the rescue. It's called the Cynefin Framework. It helps you make sense of the environment and decide on the most effective way of working. Many people have found it liberating, because they always had doubts about the control that those thick projects plans promised.

The major takeaway of this session is a better understanding of how the world really works, and different approaches to deal with ordered, complex and chaotic systems.
Игорь Авдеев, Москва
Функция-как-сервис (FaaS) - будущее бизнес-вычислений! Бессерверные вычисления уже здесь!
Многие эксперты считают, что будущее за бессерверными вычислениями (serverless computing), поскольку мобильные приложения и приложения Интернета вещей (IoT) продолжают питать спрос на бессерверную архитектуру в сочетании с растущей потребностью в интеграции облачных приложений с мобильными и настольными приложениями.

В этом докладе мы дадим обзор бессерверной архитектуры и FaaS, в том числе:

  • Что такое бессерверная архитектура?
  • Почему стоит использовать бессерверные архитектуры?
  • Достоинства и недостатки бессерверной архитектуры
  • Виды приложений бессерверной архитектуры (FaaS, BaaS)
  • Что такое Function-as-a-Service (FaaS)?
Кирилл Мельничук, Украина
Практический опыт переезда боевого проекта со 100 Гб базы данных из MySQL Percona в кластер на базе Vitess для горизонтального масштабирования
  • Горизонтальное масштабирование - проблемы MySQL
  • Партиционирование, шардинг и почему это не всегда возможно
  • Варианты горизонтального масштабирования для MySQL
  • Vitess - запуск и первичная настройка
  • Типичные проблемы и пути их решения
  • Итоговая архитектура
  • Результаты нагрузочных тестов
Егор Иванов, Москва
1C + Docker = <3
  • Зачем вообще контейнеризировать 1С?
  • Windows Containers и 1С. Возможно ли?
  • Быстрая организация тестового стенда для типового разработчика.
  • Тестирование под разные комбинации 1C / OS в рамках CI pipeline.
  • Пробуем построить production-ready кластер 1С на основе контейнеров.
Максим Ваильев, Москва
Kubernetes in Highly Secure Environments (Cloud-native vs enterprise governance and security requirements)
Installing Kubernetes is easy. Ensuring it complies with your organization's enterprise governance and security requirements isn't. During this session, Kublr team will outline common prerequisites to run Kubernetes in production. How to leverage fine-grained controls and separation of responsibilities to meet enterprise governance and security needs. He'll cover basic requirements for audit, security, authentication, authorization, integration with existing identity broker, logging, and monitoring. Additionally, he'll discuss whether cloud-hosted Kubernetes cover these requirements, how to integrate a compliant Kubernetes installation with your existing cloud infrastructure and handle cross-team communication (network/compute/storage/security). Yet on-premise Kubernetes deployments don't come without challenges. We'll dive into the limitations of a bare-metal installation, interactions with vSphere's API, achieving HA, reliability and disaster recovery, as well as handling OS upgrades, security patches, and Kubernetes upgrades. We'll close with a quick outlook of what's next, such as infrastructure as a code, immutable infrastructure, and gitops.
Роман Пономарев, Москва
Continuous feedback – почему мы ставим непрерывную оценку во главу технологической трансформации продукта
В докладе я расскажу про такую штуку как непрерывную оценку (Continuous feedback). Многие команды при внедрении подходов DevOps в своею работу отдают приоритет внедрению инструментов или ускорению доставки релизов на прод. Но при значительном увеличении частоты поставок, количество непредвиденных ситуаций, ошибок и т.д. начинает расти. Разбираться с такими случаями съедает кучу времени и нивелируют всю пользу от нашей высокой скорости доставки на прод.
Поэтому нужно иметь инструмент, который будет предоставлять обратную связь на любое действие, которое совершается в конвейре: ручное или автоматизированное; и как это действие влияет на ключевые показатели работы.
Я расскажу, как мы стоим и развиваем трехуровневую систему метрик в нашей команде на стеке продуктов Atlassian, ELK, Grafana, где внизу такие метрики как частота сборок и деплоя по средам, средняя длительность билда и деплоя, покрытие юнит тестами, частота и время стат анализа, выполнение автотестов и их время выполнения и т.д., которые по сути интересны только разработчикам или тестировщикам, а наверху те самые показатели, на которые мы ориентируемся чтобы войти в число elite performers.
Андрей Бешков, Москва
Цельно облачный DevOps. Как построить весь процесс не имея практически ничего своего?
Построение процессов DevOps вещь не простая нужно проинтегрировать довольно много компонентов зачастую они от разных производителей и не всегда плотно подходят друг к другу. Но можно поступить по другому. В рамках этого доклада я покажу как построить все процессы жизненного цикла программного продукта для полностью в облаке. Основное внимание будет посвящено кроссплатформенной разработке и облегчению процессов разработки и тестирования мобильных приложений. Мы последовательно пройдем все этапы выпуска приложения через разработку, тестирование, работу с сообществами тестировщиков и дистрибуюцию в сторы.
Артур Аюханов, Москва
Как быстро развернуть автоматическую линию проверки своего решения на 1С, затратив 8 часов и получив выигрыш в 1 человеко/месяц
Цели выступления:
  • ознакомить с возможностью быстрого развертывания автоматической проверки;
  • кратко рассказать, как несложно получить качественные результаты с большой пользой для команды;
  • показать, что инструменты давно есть. все просто и доступно.
Тезисы:
  • проблематика;
  • хотим автоматических проверок своего 1С-решения и код-ревью кода;
  • боимся сложностей в первичной настройке;
  • не знаем, как и с чего начать;
  • решение с минимумом "магии" давно есть;
  • фоновое развертывание линии проверки;
  • для команды 1С фактически ничего не меняется, только дополнительные результат;
  • команда 1С все также пишет код и использует хранилище 1С;
  • проверено на различных командах - от компаний федерального масштаба до небольших компаний;
  • инфраструктура - OpenSource и другие варианты;
  • любой стек - можно перемешать, а можно и не взбалтывать;
  • Microsoft (TFS/VSTS/Azure DevOps);
  • Atlassian - Jira, Bamboo, Fisheye;
  • Jenkins, TeamCity и т.п.;
  • различные варианты развертывания - на нескольких серверах для больших команд или на одной машине для небольших команд;
  • что входит в автоматическую линию проверки;
  • Перенос исходников из хранилища 1С в репозиторий Git со всей историей;
  • авто-интеграция хранилища 1С с трекерами задач;
  • статический анализ кода и метаданных;
  • "дымовые" тесты - проверка открытия/закрытия форм, создания/перезаписи элементов/документов 1С, тесты печатных форм и т.д.;
  • подготовка файла развертывания для установки на Prod- и UAT-контуры;
  • простое и быстрое развертывание на 1С-контурах;
  • готовые инструменты - OpenSource и другие варианты;
  • OneScript - администрируем на языке 1С, чем сильно упрощаем жизнь команде 1С;
  • приложения OneScript - vanessa-runner, deployka, gitsync и т.д.;
  • Vanessa.ADD - тестирование 1С-решений;
  • SonarQube 1C (BSL) Plugin - статический анализ 1С-решений;
  • Yandex Allure - полезные и красивые отчеты о результатах тестирования;
  • платформа 1C, 1C:EDT.
Результаты:
  • автоматическая проверка при любом помещении в хранилище или по расписанию ("ночная" сборка);
  • сотни настоящих тестов;
  • статический анализ кода для облегчения дорогого "код-ревью";
  • немедленное выявление скрытых проблем уже при первом запуске автопроверок;
  • постоянный контроль качества;
  • значительное уменьшение ручных рутинных операций и зависимости от "человеческого" фактора;
  • результаты в цифрах.
Игорь Авдеев, Москва
Service Mesh on OpenShift in Action
  • расскажем об Istio, концепции Service Mesh, компонентах, реализующих данную концепцию, и плюсах их использования;
  • развернем в OpenShift Service Mesh-систему Istio и компоненты, которые вошли в её стек;
  • настроим Istio для существующего решения с микросервисной архитектурой на базе технологий Akka Framework, React JS и PostgreSQL;
  • поговорим о специфике использования Istio и изменениях, которые придётся сделать в существующих микросервисах для обеспечения его корректной работы;
  • покажем использование ключевых функций Istio на примере описанной группы микросервисов:
  1. продемонстрируем управление трафиком и осуществим тонкую настройку маршрутизации, настроим правила разрыва цепи для случая сетевых сбоев и покажем эмуляцию сетевых ошибок для тестирования отказоустойчивости решения;
  2. опишем спектр возможностей по обеспечению безопасности и покажем настройку политик аутентификации, авторизации сервисов на базе ролевой модели, а также проверки доступности микросервисов с помощью модуля Citadel;
  3. включим поддержку политик взаимодействия микросервисов и продемонстрируем их использование на практике – настроим лимитирование входящего трафика для одного из сервисов, покажем возможности по контролю хедеров и маршрутов и создание белых и чёрных списков для разграничения прав доступа;
  4. продемонстрируем возможности по отладке микросервисов во время эксплуатации – визуализации сервисной сетки, настройку визуализации сетевых метрик и распределённый трейсинг.
Press "Like" to follow Tilda Publishing on Facebook