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

Конференция RootConf проходит в рамках профессионального фестиваля "Российские интернет-технологии". Вам, как участнику конференции, доступны все доклады этой конференции.

Кроме этого, Вы cможете посетить все общие доклады фестиваля, интересные широкой публике, и специализированные доклады конференций блока серверных технологий: конференции "HighLoad++ Junior 2017", "Backend Conf 2017".

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

Технологии отказоустойчивости и катастрофоустойчивости

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

Лев Николаев

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

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

В докладе рассматриваются разные варианты применения PowerDNS и unbound для построения различных по своей производительности и отказоустойчивости конфигураций DNS.

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

Управление в эксплуатации

Борьба со спамом у хостинг-провайдера

Лев Николаев

Крутые игроки рынка, типа Яндекса и Google, хорошо умеют фильтровать спам. Однако воспользоваться их фильтрами просто так нельзя, нужно отдать им всю свою почту. Что делать тем, кто не может себе этого позволить?

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

Как сделать эту предварительную фильтрацию? Самым распространенным, но далеко не самым верным решением является использование DNSBL, т.н. "черных списков". Это здорово, однако правильное применение DNSBL не совсем простое и обладает рядом особенностей. Что это означает? Что нельзя ставить только DNSBL во главу системы фильтрации.

Аналогично, нельзя слепо полагаться грейлистинг, который на сегодня стал достаточно распространенным методом. Существует достаточно отправителей, которые не могут корректно работать с этим методом предотвращения спама.

В итоге, автор предлагает набор методов, которые позволят отсекать спам еще до контент анализа, добиваясь примерно следующих показателей на объеме почты 200 тысяч сообщений в день:
- отсечка 70% сообщений до контент-фильтрации
- отсечка еще 40% после контент-фильтрации

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

Управление конфигурацией

Everything as a Code

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

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

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

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

Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Непрерывная интеграция
,
Devops / другое
Программный комитет ещё не принял решения по этому докладу

Непрерывное развертывание и деплой

Мастер-класс "BDD для разработчиков или учимся тестировать свой код"

Евгений Савицкий

Непрерывное развертывание не существует без непрерывной интеграции и раннего тестирования. Тестирование все еще является одним из самых узких мест в процессе непрерывной поставки.

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

Решение состоит в автоматизации функциональных тестов подходом, близким к модульному тестированию. Этот подход называется Behavior Driven Development (BDD). Сперва мы пишем сценарии тестирования, затем пишем код, необходимый для их выполнения, коммитим в свою ветку и через некоторое время проверяем результат тестов. Таким образом, только тщательно протестированные модули попадают в основную ветку и доходят до ручного тестирования.

На мастер-классе вы не только напишете ваш первый сценарий на Gherkin + Selenium, но и сможете запрограммировать непрерывную поставку демо-приложения при помощи Jenkins2 Pipeline, docker, Firefox, mySQL, xvfb, а также узнаете как отмасштабировать непрерывную интеграцию на всю вашу команду.

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

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.

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

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

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

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

В последний год мало кого можно удивить такими словами, как Docker Swarm, Rancher, Marathon или Kubernetes. Очень многие крупные и динамично развивающиеся проекты или уже переехали на Docker (под управлением одной из систем), или всерьез прорабатывают этот вопрос, а уж у всех DevOps-специалистов эти слова тем более давно на слуху.

Но как это выглядит на практике? Мы поделимся своим опытом перехода на Kubernetes и его дальнейшей эксплуатации в проектах среднего размера (до 50 серверов), а именно:
- Расскажем, что потребуется для перехода на Kubernetes и как к этому подготовиться.
- Приведем несколько примеров архитектур, ставших уже типовыми для нас.
- Покажем, как мы обычно выстраиваем CI/CD (с использованием GitLab и dapp) и какие могут быть варианты.
- Постараемся ответить на вопрос, зачем Kubernetes может быть нужен вашему проекту, систематизировав и разложив по полочкам все (известные нам) плюсы и минусы.
- И наконец, поделимся сведениями о расположении и размерах подводных камней.

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

Микросервисы, SOA
,
Архитектурные паттерны
,
Технологии виртуализации и контейнеризации
,
Непрерывное развертывание и деплой
,
Непрерывная интеграция
,
Автоматизация разработки и тестирования
Доклад принят в программу конференции

Технологии виртуализации и контейнеризация

Kubernetes и микросервисы: быстрый старт

Юрий Тюрин

Рассмотрим, чем kubernetes может помочь при разработке микросервисов:
* Как развернуть сервис?
* Как управлять жизненным циклом сервиса?
* Как организовать взаимодействие между сервисами?
* Как их масштабировать?
* Как хранить данные?
* Как мониторить и собирать логи?
* Как отлаживать сервисы внутри kubernetes?

Микросервисы, SOA
,
Технологии виртуализации и контейнеризации
Программный комитет ещё не принял решения по этому докладу

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.

Технологии виртуализации и контейнеризации
,
Сетевое администрирование
,
Devops / другое
Доклад принят в программу конференции

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

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

Плюсы и минусы использования Docker в CI.
Какие очевидные вещи нужно знать про docker image:
* как организованы слои;
* как уменьшить размеры;
* как добавить "надежности" образу.
И какие особенности использования докера есть в CI.

Технологии виртуализации и контейнеризации
,
Непрерывная интеграция
Программный комитет ещё не принял решения по этому докладу

Логирование и мониторинг

Переезжаем с zabbix на prometheus

Василий Озеров

- Почему prometheus?
- быстрый (golang)
- time series database
- простота развертывания через scm (ansible/chef/puppet/salt)
- готовые exports & dashboars for grafana

- Внедряем
- переносим базовый мониторинг систем в prometheus (cpu/disk/net/mem)
- настраиваем discovery новых хостов и сервисов
- подключаем визуализацию
- настраиваем алертинг

- Дополнительно
- резервируем prometheus (alertmanager + prometheus instance)
- получаем информацию из собственных приложений
- получаем статистику из логов

- Заключение
- возможности масштабирования
- какую нагрузку держим

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

Особенности мониторинга и профилирования JVM-based приложений

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

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

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

Java
,
Профилирование
,
Логирование и мониторинг
,
Devops / другое
Программный комитет ещё не принял решения по этому докладу

Zabbix: тернистый путь к мониторингу приложений из коробки

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

Нашу команду часто упрекают в том, что Zabbix не содержит готовых сценариев для мониторинга многих элементов инфраструктуры.

Узнаёте ситуацию? Установили Zabbix, разобрались с агентами и мониторингом Linux и Windows. А что делать дальше и как мониторить тот зоопарк приложений, устройств и облачных сервисов, который нас окружает? Даже мониторинг простого Apache сервера становится головной болью. Конечно, можно найти готовые шаблоны и скрипты, но их недостаточно, с ними трудно работать и очень часто они не соответствуют ожиданиям. Приходиться их допиливать или создавать заново. Много сложностей, которые не всем по силам.

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

Хочется помечтать и спросить, когда же Zabbix сможет мониторить всё это из коробки? Мой ответ - очень скоро, и это один из наших основных приоритетов разработки Zabbix в настоящее время!

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

Приходите и узнаете, за счёт чего Zabbix станет ещё гибче и приобретёт массу новых возможностей! Многое будет доступно уже в Zabbix 3.4!

Логирование и мониторинг
,
Управление конфигурацией
,
Сетевое администрирование
,
Devops / другое
Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

Насколько жив ваш CI

Андрей Кононов

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

Логирование и мониторинг
,
Непрерывное развертывание и деплой
,
Непрерывная интеграция
,
Devops / другое
Доклад принят в программу конференции

DevOps как стиль жизни продукта и компании

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

- Почему "облако"? Максимальная сосредоточенность на продукте и огромная экономия на эксплуатации. Кроме того - возможность очень много и часто экспериментировать.
- Автоматизируй это! Использование API AWS для деплоя, мониторинга, авто-скейлинга и т.п.
- Мониторинг - наше всё! Распределенная система real-time мониторинга (был nagios, стал shinken), аналитика, автоматизация, работа с инцидентами.
- Как прозрачно и бесшовно деплоить в распределенной ситеме (несколько провайдеров, несколько разных API управления инфраструктурой - AWS, VMware).

Отказоустойчивость
,
Работа с Amazon
,
Логирование и мониторинг
,
Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
,
Менеджмент в эксплуатации
,
Администрирование баз данных
,
Devops / другое
,
Нагрузочное тестирование
,
MySQL (MariaDB, Percona Server)
Программный комитет ещё не принял решения по этому докладу

Мониторинг облачной CI системы на примере Jenkins

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

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

В докладе будут рассмотрены вопросы, как следить за:
* очередью
* агентами
* сборками
* самими мастерами
* проблемами инфраструктуры
* мигающими тестами
* etc.

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

Внимание! Доклад может содержать код, скриншоты графиков и боли из реальной жизни.

Логирование и мониторинг
,
Управление конфигурацией
,
Непрерывная интеграция
Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

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

Может, есть что-то получше? Гистограммы! Но они не так гибки — надо выставлять пороги.
Какие гибридные варианты есть — qdigest и т.п.

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

Отказоустойчивость
,
Распределенные системы
,
Логирование и мониторинг
,
Devops / другое
,
Выбор стратегии долгосрочного развития, KPI
,
Проектирование информационных систем
,
Внедрение и поддержка
,
Теории и техники анализа
Программный комитет ещё не принял решения по этому докладу

Zabbix 3.4 - ответ на многие вопросы мониторинга

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

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

Для чего нужна гибкость? Вот весьма распространённый пример. Очень часто входные данные нуждаются в подготовке. Получаем JSON или XML, а что с ним делать дальше? Как разбить на понятные нам метрики? А что, если обрабатываемые значения ещё более сложные, и необходимо создать длинный конвейер обработки этих значений? Сможет ли с этим справиться Zabbix?

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

О производительности и не только. Традиционно, Zabbix использует SQL-базы данных для хранения всей информации. Но почему бы не попробовать хранить time-series данные в Elastic, OpenTSDB или InfluxDB и забыть о сложностях работы с терабайтами истории? А, может, даже в TimescaleDB, Tarantool или Clickhouse? Это возможно уже сейчас!

Многие из нас знают или используют замечательный плагин Zabbix-Grafana для более удобной визуализации данных. Собирается ли команда Zabbix предложить родное решение для визуализации? Да!

Это лишь некоторая часть тех улучшений, что мы сделали в версии Zabbix 3.4 и над которыми продолжаем работать. Обо всём этом я расскажу во время своего доклада.

Новая версия избавляет нас от многих насущных проблем и значительно упрощает повседневную работу. Приходите и убедитесь сами!

Логирование и мониторинг
,
Управление конфигурацией
,
Сетевое администрирование
,
Devops / другое
Программный комитет ещё не принял решения по этому докладу