Root Conf 2017

5-6 июня 2017
Сколково, Россия
Купить видео
В избранное

Данила Штань

Технический менеджер и архитектор в Точка

Иван Евтухович

Генеральный директор в Express42

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

Управляющий партнер в Экспресс 42

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

Разработчик в Одноклассники

Денис Яковлев

Ведущий разработчик в 2ГИС

О мероприятии

Конференция о поддержке и эксплуатации IT-проектов: логирование и мониторинг, технологии виртуализации и контейнеризации, управление конфигурацией, непрерывное развёртывание и деплой, технологии отказоустойчивости и катастрофоустойчивости, а также управление в эксплуатации.

Для кого

  • Техническим директорам
  • Тимлидам
  • Разработчикам
  • Системным администраторам
  • Архитекторам данных
Поделиться

Расписание

Развернуть все
05 июня (понедельник)
День 1
Показать
цену в
$
Получить доступ ко всем докладам
Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €
Управление в эксплуатации

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

Управляющий партнер в Экспресс 42
и ещё 1
докладчик

Мифы о DevOps

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

Мы не хотим рассказывать, что такое DevOps, а расскажем о мифах, которые вредят пониманию. Их не так много, но важно о них знать, потому что эти мифы для вас будут маркерами неправильных управленческих и инженерных решений:
1) DevOps может делать DevOps-отдел или DevOps-инженер.
2) DevOps — это про то, что надо нанимать специалистов-многостаночников, которые умеют все.
3) Мы разрабатываем корпоративную ИТ-систему, и у нас DevOps уже с 1995 года.
4) DevOps — это "правильные" инструменты.
5) DevOps — это "философия", специальная культура, которая уникальна и не может быть повторена.
6) В ITIL уже этот ваш DevOps заложен и не надо старое выдавать за новое.
7) DevOps — это маркетинговое словечко, за которым ничего нет.

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

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €
Управление конфигурацией

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

Разработчик в Одноклассники

Everything as a Code

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

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

В докладе будет представлен личный опыт автора по автоматизации различных элементов разработки ПО.

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €
Управление в эксплуатации

Денис Яковлев

Ведущий разработчик в 2ГИС

Как подружить команду админов с N командами разработки

Web-отдел 2ГИС - это 5 команд разработки и более 20 проектов разного калибра. Это означает множество релизов каждый день и постоянные изменения. 

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

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

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €
Логирование и мониторинг

Алексей Владышев

Разработчик в Zabbix

Zabbix 3.4 - простая непростая дружба с сообществом

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

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

Я расскажу о том, как мы работаем с сообществом, мониторим и реализуем запросы. Всегда ли мы это делаем эффективно или что-то можно улучшить?

Приходите! Доклад будет интересен не только тем, кто интересуется Zabbix и мониторингом в целом, но, надеюсь, что и разработчикам открытых программных продуктов.

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €
Логирование и мониторинг

Павел Труханов

Директор в okmeter.io

MathOps или математика в мониторинге

Мониторинг — это и cpu usage, iowait, load average, и времена ответа сайта и отдельных сервисов.

Тайминги ответа — среднее по всем запросам? Нет, подайте лучше медиану, а то и 99-перцентиль!

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

Когда со всем этим разобрались, то вы решили задать SLA на тайминги ответа сайта, допустим на 99-перцентиль. Не мало? Сколько 9-ок взять? 3, 5, 10? Что на самом деле происходит со временем ответа сервиса за пределами этих девяток? 
Какое распределение у самих этих перцентилей? Насколько они шумные? Какая ошибка в минутных перцентилях накапливается за день, за неделю? 
Может, есть что-то получше? Гистограммы! Но они не так гибки — надо заранее выставлять и угадать пороги.

В общем, если вам интересно знать, как сервисы _на самом деле_ ведут себя с точки зрения latency, то вам стоит прийти на мой доклад.

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €
Технологии отказоустойчивости и катастрофоустойчивости

Лев Николаев

Разработчик в Макснет

Пряморукий DNS: делаем правильно

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

Несмотря на все свои крутые преимущества, вроде split horizon, bind, к сожалению, далек по своей производительности от оптимального выбора.

В докладе рассматриваются следующие конфигурации:

1. Просто (быстрый) резольвер. Области применения: организация, провайдер, ЦОД

Провайдеру и ЦОДу это нужно по-умолчанию. Организациям это нужно тогда, когда объем запросов к провайдерским DNS начинает жать спереди.

Здесь властвует unbound. Важные пункты:
- никаких форвардов на Яндекс или Гугл
- SO_REUSEPORT
- prefetch
- DNSSEC-валидация обязательно
- что мониторить?

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

2. Свои зоны. Области применения: организация, провайдер, иногда ЦОД

Своя DNS-зона рано или поздно появляется у каждого. Здесь, конечно, только PowerDNS. Важные пункты:
- почему только база данных, только хардкор
- почему никаких XFR, а только уровень базы данных
- почему репликация БД тут плохо, и что тут хорошо?
- и как насчет хранения зоны, гм, в git-репозитории?
- что мониторить?

3. Сочетание своих зон и резольвера

У провайдеров, да и часто в крупных организациях, возникает необходимость блокировать резолвинг каких-то записей. Причин тому масса - от требований закона до вирусов. Здесь нужно использовать PowerDNS и unbound в режиме Apache + nginx.

- PowerDNS принимает запрос изначально
- если может ответить на него, то отвечает
- а если не может, то отдает unbound для обработки

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €
Управление в эксплуатации

Владимир Ярцев

CTO в Castle Digital Partners

Продуктовые проблемы при создании очередной Docker PaaS

Благодаря Docker'у, контейнеры стали доступны каждому. Однако, чтобы развернуть production-систему на Docker'е, нужно решить ряд инфраструктурных задач: логи, мониторинг, бэкапы, отказоустойчивость, апдейты, безопасность. Решить эти задачи "для себя" не сложно, но при попытке превратить свое контейнерное решение в программный продукт возникают проблемы: "глупые" пользователи, нестабильный хостинг, коварные конкуренты и неясное будущее продукта. Эти трудности - системные, и лучше о них знать заранее. Я расскажу о них на примере проекта dockhero.io.

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €
Технологии виртуализации и контейнеризация

Данила Штань

Технический менеджер и архитектор в Точка

Самоорганизующаяся сервисная инфраструктура на базе Docker

Я расскажу об удачной попытке сделать современную распределённую экосистему для эксплуатации софта на базе Docker-контейнеров, которая собрана из базовых и довольно простых компонентов, без переусложнённости Kubernetes или Mesos+Marathon.

Мы обсудим, как можно упростить сетевой слой, как без особых проблем работать с Docker Swarm, как построить service discovery, мониторинг, rolling updates и прочие красивые слова, максимально отдав это на уровень разработчиков.

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €
Непрерывное развертывание и деплой

Дмитрий Чумак

Системный администратор в ITSumma

От репозитория до CI/CD-инфраструктуры в продакшне за неделю

В докладе я разберу развертывание CI/CD в сжатые сроки на реальном технологически нагруженном проекте. Несколько PostgreSQL, кластер Neo4J, нейронные сети, dev-stage-prod окружения.

Планирование архитектуры проекта с точки зрения приложения, мотивация выбора конкретной схемы.
Как настроить связку Ansible+Docker+Consul на живом проекте за три дня. Почему Amazon не всегда хорошо, проблемы с балансерами, VPC и нюансы ECS.

Этапы разворачивания CD, планирование, концепции, реальность. Коррективы со стороны разработчиков и влияние требований разработки на итоговую инфраструктуру.

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

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €
06 июня (вторник)
День 2
Показать
цену в
$
Технологии виртуализации и контейнеризация

Александр Акбашев

Senior DevOps Engineer в команде Common Continuous Integration в HERE Technologies

Мониторинг CI

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €
Получить доступ ко всем докладам
Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €
Непрерывное развертывание и деплой

Дмитрий Столяров

Технический директор и соучредитель в Флант

Наш опыт с Kubernetes в небольших проектах

Опыт эксплуатации Kubernetes в production есть пока далеко не у всех. Компании «Флант» удалось за последний год внедрить Kubernetes многим клиентам, и именно об этом мы хотим рассказать. Широкий и систематизированный опыт, собранный в этом докладе, должен вызвать интерес у всех тех, кто только слышал о контейнерах Docker или начинает их использовать, или только выбирает «платформу» (Marathon, Rancher, Kubernetes)… или уже давно что-то использует!

Доклад состоит из трёх частей:
1. Эволюция инфраструктуры приложений: как выглядела веб-инфраструктура раньше, а как — сегодня. Какие проблемы и вызовы привели инженеров к созданию Kubernetes?
2. Как устроен Kubernetes? Простыми словами изложена самая суть этой системы: её базовые компоненты, принципы работы, ключевые возможности. Как в Kubernetes запускаются современные приложения и почему решаются актуальные проблемы в инфраструктуре?
3. Практика использования Kubernetes в небольших проектах (от нескольких до сотен серверов). Как мы сами внедряем и обслуживаем Kubernetes: общая архитектура, основные принципы, связка с CI/CD, имеющиеся ограничения.

P.S. Мы так довольны результатом внедрения Kubernetes, что всерьез планируем уже в этом году перевести на него еще ~50 существующих проектов. А что останавливает вас?

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €
Логирование и мониторинг

Владимир Буянов

Разработчик в Ultimate Guitar

Мониторинг быстродействия web-проекта

Знаете ли вы, что видят пользователи после деплоя вашего кода на продакшн? 

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

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €
Непрерывное развертывание и деплой

Илья Беда

Технический директор и основатель в beda.software

How to build solid CI-CD pipeline

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

Единствено верный способ упаковки приложений - это Docker-контейнеры, благодаря этому способу вы сможете унифицировать процесс деплоя. Нужно деплоить приложения с помощью Ansible-плейбука, запакованного в Docker-контейнер, это снижает требования к окружению CI-ранера. Вам нужен только Docker.

Полная интеграция между между таск-трекером, хранилищем исходного кода, CI, хранилищем Docker-образов и CD позволит команде иметь всю информацию о состоянии staging- и production-окружений в одном единственном веб-интерфейсе. Такие современные SaaS, как github.com, travis-ci.org, circleci.com не дают достаточного контроля над окружением, поэтому я выбрал Gitlab-CE и Gitlab-CI для построения CI-CD pipeline.

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €
Технологии виртуализации и контейнеризация

Александр Акбашев

Senior DevOps Engineer в команде Common Continuous Integration в HERE Technologies

Использование Docker в CI

В своём докладе я расскажу о том, почему мы решили использовать Docker в рамках Continuous Integration: ускорить тесты, повысить стабильность, улучшить контроль над окружением и используемыми библиотеками.

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

В конце доклада я покажу, как именно мы следим за стабильностью Docker в нашей инфраструктуре. И насколько Docker стабилен на больших объемах (>100k билдов в сутки).

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €
Технологии виртуализации и контейнеризация

Александр Шалимов

Ведущий программист-разработчик в ЦПИКС

SDN & DEVOPS ?= ❤: Практики использования SDN в реальной жизни DevOps

Об SDN/OpenFlow говорят давно и много: разделение уровней управления и передачи данных, сетевая логика выносится в отдельный централизованный узел, называемый контроллером сети. На выходе получаем удешевление оборудования, автоматизацию и упрощение управления сетями. Уже сейчас эти технологии применяются и в ЦОД, и у операторов связи, и в больших корпоративных сетях. Но возникает справедливый вопрос: "Мы, конечно, рады за Google, AT&T и Microsoft, но что они дают нам, простым пользователям? Где мы можем их применить в наших задачах и можем ли мы вообще?". Короткий ответ: "Да, можем!".

В докладе будут рассмотрены практические примеры использование SDN/OpenFlow в реальной жизни и решение своими силами следующих задач: ACL (черные, белые списки), DPI (URL filtering), зеркалирование, QoS (приоритезация, ограничение полосы пропускания), балансировка нагрузки ("IPVS" на 10Gbps), защита от DDOS. Будет представлен используемый инструментарий (программные коммутаторы - Open vSwitch, Lagopus и OpenFlow контроллеры - Ryu, ODL, Runos), примеры скриптов и кода. 

Цель такого workshop'а показать простоту, удобство и, главное, полезность существующего инструментария из мира SDN/OpenFlow.

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €

Билеты

Показать
цену в
$
Видеозапись
Доступ к записям всех докладов
Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €

Организатор

Ontico
http://ontico.ru

Организационный комитет: Олег Бунин, support@ontico.ru, 74956460768

Похожие мероприятия

31 мая - 1 июня 2016
Докладов 16
Просмотров 6
Веб, Данные, Деплой, Логирование, ПО, Программирование, Разработка, Софт, Эксплуатация
5 апреля 2018
Докладов 10
Просмотров 10
Иб, Ит, Код иб
29 марта 2018
Докладов 13
Просмотров 14
Conference, Иб, Ит, Код иб
показать еще