Конференция прошла. Ждем вас на RootConf Moscow 2018 в октябре! Подать доклад

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

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

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

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

Поиск по тегам:

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

Оптимизация размещения виртуальных машин по мастер-серверам

Глеб Альшанский

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

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

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

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

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

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

Mobile DevOps: автоматизируем и улучшаем процесс мобильной разработки

Вячеслав Черников

Адепты DevOps утверждают, что этот подход применим только для больших команд, работающих со сложными проектами, желательно без UI. Мобильные приложение, вроде как, поменьше, команды всего по 3-5 человек на платформу, чистого Ops почти нет, однако проблем в проектах меньше от этого не становится. На помощь приходит Mobile DevOps!

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

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

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

Речь пойдет про iOS/Android без привязки к технологическому стеку: Objective C/Swift для iOS; Java/Kotlin для Android; ReactNative для iOS/Android; Xamarin для iOS/Android; Cordova для iOS/Android. В довесок немного рассмотрим, кто и что есть на рынке Mobile DevOps.

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

В поисках идеального CI-пайплайна

Илья Сауленко

Continuous Integration — важная часть современного процесса разработки. Сборка на каждый коммит, интеграционные тесты, деплой каждого коммита в продакшн, фиче-флаги — выглядит как идеальный пайплайн? Однако чаще всего разработка приложения не ограничивается написанием кода и запуском тестов.

Я расскажу о том, как и зачем внедрить в CI процессы разработки, которые там обычно не представлены: написание документации, обновление зависимостей, аудиты безопасности, capacity management и даже дизайн интерфейсов. Сравню возможности, которые предоставляют для этого популярные CI-серверы, разобью пайплайны на самые базовые составляющие и расскажу, чем TeamCity принципиально отличается от Concourse.

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

Методы и техника разработки ПО
,
Критерии выбора технологий для проекта
,
Непрерывное развертывание и деплой
,
Непрерывная интеграция
,
Devops / другое
,
Автоматизация разработки и тестирования
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Тестирование безопасности
,
Интеграционное тестирование
Доклад принят в программу конференции

От 1 релиза в неделю к 30 релизам в день

Алексей Паршуков

Многие команды до сих пор мучительно выкатывают 1-2 релиза в неделю. Часто с остановкой сервиса. А потом ещё неделю исправляют ошибки.

Я расскажу, как мы в DocDoc прошли путь от 1 релиза в неделю до 30 релизов в день. Зачем мы это сделали, сколько это стоит, и самое главное: как это работает.

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

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

Даниил Мигалин

В 2018 году людей трудно удивить самим фактом наличия худо-бедно работающего CI/CD, благо, что всевозможных технических средств реализовать его сейчас хватает: SCM, контейнеры, всевозможная оркестрация и т.д.

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

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

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

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

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

Мониторинг и Kubernetes

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

С переходом на Kubernetes появляется возможность очень быстро и просто создавать новые сервисы, поэтому их количество начинает расти «как на дрожжах». Вместе с ними увеличивается и число окружений, из-за чего даже в небольшом проекте с десятком сервисов мы очень быстро оказываемся в ситуации, что в кластере уже 50 namespace’ов и 500 pod’ов. Что все они делают? Как понять, что все работает хорошо?

Я поделюсь обширным опытом настройки мониторинга, полученным в результате эксплуатации 21 проекта на Kubernetes (в production), в состав которых входят более 200 различных приложений, написанных на 8 языках программирования.

В частности, в докладе будут даны ответы на следующие вопросы:
* Что именно в Kubernetes нужно мониторить (кроме состояния pod’ов и результатов выполнения job’ов)?
* Какие компоненты самого Kubernetes стоит мониторить и на что стоит обращать внимание?
* Какова специфика мониторинга Ingress Nginx?
* Как мониторить инфраструктурные компоненты (Redis, RabbitMQ, MongoDB и т.п.)?
* Почему мы используем именно Prometheus, и какие вопросы он решает?
* Как правильно интегрировать Prometheus с Kubernetes (и сделать Service Discovery всех метрик)?
* Как сделать удобные дашборды в Grafana?
* Как отделить разные окружения, чтобы получать только нужные алерты?
* Как видеть тренды на больших периодах и оптимизировать затраты на инфраструктуру мониторинга?

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

Как измерить успех? Стратегии мониторинга и их связь с бизнес-проблемами

Leon Fayer

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

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

Мониторинг безопасности сайтов: как обнаружить скрытый вредоносный код на сайтах автоматизированными средствами и вручную

Григорий Земсков

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

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

Безопасность в браузере
,
PHP
,
Perl
,
Защита информации
,
Бэкенд / другое
Доклад принят в программу конференции

Долгосрочное хранение метрик Prometheus’а

Алексей Палажченко

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

В своём докладе я расскажу про стандартные (но плохо документированные) средства Prometheus’а для решения этой проблемы, а также про возможности подключения внешних хранилищ (таких как InfluxDB и ClickHouse), их плюсы, минусы, подводные камни и производительность.

Миграции данных
,
API
,
Логирование и мониторинг
,
GO
Доклад принят в программу конференции

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

Database as a Code!

Максим Грамин

В последнее время во все сферы разработки ПО все больше проникает концепция "Everything as a Code" - CI (Jenkins pipeline), инфраструктура (Ansible playbooks), тестирование (сценарии Cucumber и Spock), документация (AsciiDoc(tor)) и многое другое. Весь этот код, наряду с основным кодом разрабатываемого приложения, так же находится под управлением системы контроля версий, собирается на билд-серверах, участвует в автотестах.

В докладе я могу рассказать, как этот подход применим к разработке и сопровождению БД, и что под эту схему подходят не только старые-добрые инкрементальные миграции (liquibase, flyway), а также исходный код объектов (baseline), код манипуляции объектами и самим сервером(инстансом) БД.

Еще расскажу о своем opensource-проекте, в котором я пытаюсь воплотить некоторые описываемые идеи.

Фреймворки
,
API
,
Java
,
PostgreSQL
,
Oracle
,
Базы данных / другое
,
Микросервисы, SOA
,
Организация доступа к базам данных, ORM, собственные драйвера
,
Разработка библиотек, включая open source библиотеки
,
Управление конфигурацией
,
Совместная работа, система контроля версий, организация веток
,
MySQL (MariaDB, Percona Server)
Доклад принят в программу конференции

Как мы тестируем развертывание на Windows-машины при помощи docker

Олег Блохин

Наши сервера - в основном Windows и немного Linux’ов.
Наше приложение - 160 проектов на C#, которые собираются в ~30 разных сайтов.

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

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

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

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

Конвейер поставки виртуальных машин

Михаил Кузьмин

Идеи continuous delivery можно применять не только к процессу разработки приложений, но и к управлению инфраструктурой.

Я расскажу:
- как управлять виртуальными машинами так же, как и кодом продуктов - с компиляцией, тестированием, публикацией артефактов и релизами;
- как HashiCorp Packer помогает создавать машины и настраивать софт;
- чем immutable infrastructure отличается от классического configuration management с Ansible/Chef/Puppet;
- какие сложности возникают, когда машин становится сотни, а параллельных сборок - десятки. И как TeamCity помогает нам с ними справляться;
- как мы привлекаем разработчиков к администрированию инфраструктуры и внедряем DevOps-культуру.

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

Devops в коробочной разработке

Максим Лапшин

Сегодня на слуху термин devops, и в его обсуждении, как правило, упоминаются сервисы и команды их разработки.

А что же с коробочными продуктами? Они с их релизами раз в полгода в стороне?

Мы не в стороне. Несмотря на релизы раз в месяц, у нас в Эрливидео внедрены полезные практики:
1) жесткое правило на отгружаемость мастер-ветки;
2) сборка в пакет каждого коммита;
3) регулярный прогон тестов;
4) методика ежедневной установки мастера клиентам.

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

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

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

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

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

Такой подход позволяет сократить количество сюрпризов для наших клиентов и багов для нас.

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

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

Cassandra: разделение и обновление без даунтайма

Никита Маслянников

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

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

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

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

Надежность World of Tanks Server. Как мы это делаем

Левон Авакян

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

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

Тонкая настройка балансировки нагрузки

Николай Сивко

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

Я расскажу о не очень популярных (пока) аспектах балансировки нагрузки:
- политика повторных попыток (retries);
- таймауты: connect/read/write/request timeout, tcp keep-alive* (чем они отличаются, как выбрать конкретные значения для своего сервиса);
- backoff, circuit breaker: как не убить нижележащие серверы в момент аварии/перегрузки;
- health checks: нужны ли они, достаточно ли их, что сервис должен проверять, прежде чем отдать HTTP-200;
- outlier detection в балансировке: способ работать при более сложных (плавающих) поломках нижележащих серверов.

В плане технологий: сначала мы мельком рассмотрим nginx, haproxy (а так же haproxy за nginx:), потом расскажу про наш опыт работы с envoy и балансировке внутри приложения (будет немного примеров на golang).

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

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

Построение вычислительного облака на современном ландшафте технологий

Евгений Потапов
Тимур Хасанов

Весной 2018 года к нам обратилась крупная производственная компания, которая попросила нас провести R&D-проект, в рамках которого мы попытались бы опробовать современные технологии контейнеризации, Continous Integration и понять, какие из них применимы для создания платформы приложений и обработки данных.

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

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

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

Используемые технологии:
k8s, consul, openstack, kafka, flink, cassandra, tarantool, ignite, mesos, marathon, grafana, gitlab, jenkins, zipkin, prometheus

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

Сетевые базисы kubernetes

Александр Хаёров

Использование кластеров на основе контейнеров плотно вошло в нашу жизнь. Повальный интерес к микросервисной архитектуре приложений и массовое разделение монолита привело к оправданному использованию оркестраторов, в частности - kubernetes.

Сложности с разворачиванием кластера из множества серверных нод ложится на матёрых системных админов или «поручается» публичным облачным провайдерам. Локальная разработка основывается на minikube или kubetbetes in docker. А все это приводит к тому, что порой задаешься вопросом: «Как и почему это работает?», и так необходимые базовые сетевые понятия никому не знакомы.

Поговорим о сетевой магии kubernetes - от пода до ingress. Вы узнаете, чем руководствовались создатели оркестратора, для каких задач можно применить те или иные компоненты и почему не стоит бояться Ingress. После доклада все станет ясно!

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

Пакеты и пакетные менеджеры для k8s

Иван Глушков

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

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

Сетевые технологии в современных частных облаках. История развития сетей, используемые технологии, проблемы и их решение

Вадим Пономарев

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

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

План доклада:
- небольшая историческая справка по частным облакам и применяемым технологиям, как они развивались, и почему современные решения именно такие, какие есть;
- общие понятия, используемые в облаках для сетевых ресурсов и управления ими;
- сеть "под капотом" - в деталях, как все устроено внутри, протоколы, технологии, топологии;
- небольшое отступление о физических сетях, какие изменения произошли там, какие решения используются у в bare-metal устройствах;
- что будет в будущем - немного поговорим о светлом будущем, которое ждет сетевые облачные технологии.

В деталях будет рассказано про работу сети в облаке на базе OpenStack, но такие же технологии и принципы работы используются и в других проектах (таких как kubernetes, mesos), поэтому доклад будет полезен и ИТ-специалистам, не работающим с OpenStack. Доклад также будет интересен сетевым инженерам для понимания "серверной части" облака.

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