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

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

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

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

Адепты 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.

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

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

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

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

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

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

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

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

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

С переходом на 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?
* Как отделить разные окружения, чтобы получать только нужные алерты?
* Как видеть тренды на больших периодах и оптимизировать затраты на инфраструктуру мониторинга?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В докладе я расскажу, как выглядит 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.

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

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

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

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

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

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

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