За 2 года работы в SRE с использованием языка Go приходилось сталкиваться с множеством проблем, как помочь разработчикам быстро и оптимально создавать микросервис. При этом соблюсти все требования, нюансы работы сервиса в контейнере, использования конфигурации, тестирования, исполнения и доставки кода в различные среды (Docker, Kubernetes, локально или в кластер).

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

Будут рассмотрены вопросы:
- Генерация сервиса с выбором необходимых модулей.
- Наиболее яркие решения в виде примеров кода.
- Способы тестирования и валидации кода.
- Доставка и исполнение кода в контейнере локально и в кластере.
- Структура модулей сервиса из лучших практик.
- Вежливое закрытие сервиса (graceful shutdown).
- И многое другое из бесценного опыта разработки в контейнерах.

From AWS to Google Cloud, the major cloud providers offer different options to run a MySQL or a MySQL compatible database on the cloud. You can spin up virtual machines and configure your own cluster or rely on managed services with the ability to modify or scale vertically a database with the click of a button. From sharding to backups, from provisioning to monitoring, the talk will cover the operational costs of running relational databases on the cloud and how to integrate them in your infrastructure as a code. Can serverless databases be the answer?

Расскажу про управление секретами в Avito с помощью Hashicorp Vault. Как используем Puppet и Kubernetes. Также перечислю, какие шишки набили за полтора года использования, и поделюсь мыслями, как это можно исправить.

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

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

Дополнительно обсудим тему внедрения SAST в цикл разработки программного обеспечения, что может представлять интерес для DevSecOps-специалистов.

У нас было 2 анализатора кода, 4 инструмента для динамического тестирования, свои поделки и 250 скриптов. Не то, чтобы это всё было нужно в текущем процессе, но раз начал внедрять DevSecOps, то иди до конца.

Доклад посвящен проблемам перехода от классической модели Application Security к процессу DevSecOps. Разберем, как правильно подойти к встраиванию процесса безопасной разработки в процесс DevOps и как при этом ничего не сломать. Проясним основные этапы тестирования на безопасность, какие инструменты можно применять, посмотрим, чем они отличаются и как их правильно настроить. Ну и, конечно же, подводные камни, которые встречаются в любом процессе, попробуем их избежать или хотя бы подготовиться к столкновению.

Ещё покажу, как это работает в реальной жизни на примере процессов внутри нашей компании.

Мы в Qiwi решили повысить эффективность существующего процесса Patch Management.

Расскажу об инструментах, которые мы для этого применяем:
- Zabbix Threat control,
- Patch scheduler.

А также о том, с какими проблемами столкнулись при этом и к чему в итоге пришли.

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

Будет показан механизм разработки как публичных ролей (Ansible Galaxy = Ansible role + GitHub + Travis CI),
так и публичных ролей но с тестовыми прогонами в приватной инфраструктуре (Ansible Galaxy = Ansible role + GitHub + GitLab CI for GitHub).

В конце 2017 года наша команда начала работу над новым мобильным SDK, используя как самые последние опенсорс-технологии, так и самые последние внутренние разработки. И, конечно, мы хотели исправить и те недочеты, которые видели в CI наших предыдущих продуктов.

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

Список ключевых слов: Jenkins, AWS, Serverless, Docker, Mac mini, git, repo, Gerrit, Java, Go.

В своем докладе я расскажу на примере реализованного проекта для крупного заказчика с более 100 000 конечных пользователей, как играючи доставлять проект в rpm, используя TFS, Puppet, Linux .NET core, и о том, как поддерживать версионирование БД проекта, если разработка впервые слышит слова Postgres и Flyway, а дедлайн послезавтра. О сломанных костылях и работающих решениях.

Расскажу о том, как мотивировать .NET-разработчиков отказаться от Windows и смузи в пользу Puppet и Linux, и что делать, когда ты девопс и обслуживать винду в продакшне нет ни сил, ни желания, да и ресурсы не резиновые. О методах разрешения идеологических конфликтов.

Как готовят TFS в Золотой Короне. Расскажу о практиках использования TFS в существующих проектах. Как интегрированы с Docker, о Web deploy, тестировании и CI.

Два года назад нам не хватило готового решения для доставки приложений в Kubernetes, и мы придумали собственное. Взглянем на историю развития PaaS в 2ГИС, сравнив его со стандартным путём доставки приложений и инфраструктуры на бой. Вспомним, каким был Helm в конце 2016 года. И в итоге увидим, зачем нам понадобился свой способ доставки в Kubernetes.

Поделюсь ссылкой на OpenSource-версию, которая просто обязана сделать мир лучше.

Заказчик: "Давайте поставлять фичи каждый день, и без ручного регресс-тестирования?".
Команда: "А давайте!".

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

Что спустя полгода?
Каждый день изменения катятся на продакшн, разработчики пишут тесты, а тестировщики предлагают, как улучшить покрытие. Достигли ли Святого Грааля continuous delivery? Нет, еще в пути.

Расскажем, как живется команде из 16 разработчиков, 3 тестировщиков и 2.5 девопсов. Грабли, шишки, успехи, и какие ставим цели сейчас.

Рассмотрим пример. В системе огромное количество приложений, которые обновляются не реже одного раза в неделю. Притом производственное окружение невозможно повторить на тестовом окружении, и нет группы тестирования. Можно ли минимизировать ошибки разработки? Можно!

В докладе будет рассказано, как используя метод «canary releases» с реализацией на метриках Prometheus, удалось обезопасить микросервисы от ошибок разработки и архитектуры, каким образом проходило внедрение, а также детали реализации.

Суть метода заключается в следующем. При работе при высокой нагрузке приложение разворачивается на один узел с уменьшенным количеством трафика, а после проверки производится обновление на всех узлах. Сравниваются метрики, полученные с тестового узла с историческими метриками других узлов, и принимается решение о стабильности версии. Это и называется «canary releases».

Также будет рассказано о роли Prometheus и сложностях внедрения.

I truly believe that quality is not what programmers should care about. They must care only about speed—close tasks as soon as possible— which means make money. Won't this attitude ruin the project and turn the code base into a mess? Yes, it will. If the project doesn't care about its quality either. There must be a permanent conflict between a project and its programmers: 1) the project must be configured to reject anything that lowers the quality of its artifacts and 2) programmers must be interested in making changes to those artifacts. The project cares about the quality, the programmers care about fast delivery of modifications.

I wrote about this: http://www.yegor256.com/2018/03/06/speed-vs-quality.html

В начале мы мигрировали наши микросервисы в Kubernetes. Со временем научились молниеносно выводить в прод новые микросервисы с помощью стандартизации и фиксирования в коде всех договоренностей между админами и разработчиками. Получая из коробки ci/cd. Ничего не забывая. Накапливая опыт эксплуатации и сразу распространяя его на все приложения. Как, почему и зачем..

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

Доклад будет подан с позиции проактивного devops-инженера и разработчика. Мы рассмотрим весь цикл существования (микро)сервиса на примере python-сервиса, начиная от создания проекта и заканчивая эксплуатацией/мониторингом в проде. Осветим все связанные и показавшие эффективность подходы/ процессы/инструменты, которые используем в данный момент.

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

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

Как распознать сироту? Как они получаются? Чем грозит присутствие сирот в инфраструктуре?
Можно ли этого избежать? И как - с примерами из 6-летнего жизненного цикла сервисной архитектуры Банки.ру.

Прошлые и нынешние ведущие подкаста DevOps Deflope соберутся вместе, чтобы в формате BoF (Birds of a Feather), то есть неформально, обсудить с гостями последние новости в мире DevOps в прямом эфире. Они также расскажут о жизни подкаста и одноименного телеграмм-канала, и ответят на все вопросы гостей.

Задача DevOps — сделать процесс разработки и поставки программного обеспечения согласованным с эксплуатацией. Но что делать, когда разработка живет отдельно от эксплуатации уже долгое время и по Agile? Как стабилизировать процесс доставки и эксплуатации?

- В чем проблема Agile?
- Как начать переход от классической разработки и эксплуатации инфраструктуры к DevOps (что есть и чего, как правило, нет).
- Способ анализа текущей ситуации ("силосные башни" Dev и Ops).
- Как должна происходит та самая "DevOps-трансформация" (утопия DevOps).
- Реальность воплощения (с чем столкнулись мы, и наверняка столкнетесь и вы).
- Роли в Ops (кто, кому и что должен).

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

Между тем, DevOps служит конкретной цели, решает конкретные задачи. Мы поговорим с вами о том, какие задачи DevOps решает и как решает, какие практики есть в DevOps и почему именно они, что такое культура в DevOps и является ли эта культура более “культурной”. Какие проблемы есть с точки зрения организации и командного взаимодействия.

Обсудим основные практики DevOps — Инфраструктура как код, Непрерывная поставка, Обратная связь, что отличает практику здорового человека от практики “курильщика”.

В качестве бонуса после доклада вы получите список вопросов, которые надо себе задать, чтобы понять, а DevOps ли у вас?

В своём докладе я расскажу о DevOps-трансформации Альфа-Банка и о том, с какими проблемами сталкивается компания в процессе трансформации. Проблемы возникают везде, от уровня governance, то есть некоей неопределённости у руководящего состава, что делать и куда двигаться в плане DevOps, до конкретной технической реализации.

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

Как можно организовать pipeline по доставке изменений с учётом требований всех "заинтересованных лиц" и как сделать так, чтобы это работало. Какие продуктовые команды оказались успешными в плане DevOps, а какие нет, и почему у них не получилось.

Все IT-компании давно пришли к тому, что необходимо собирать как много больше метрик из происходящих вокруг процессов. Я говорю не только о технических показателях, таких как количество запросов и cpu usage, но и о бизнес-метриках, таких как revenue, retention, quality и прочих.

К сожалению, очень часто эти метрики анализируются отдельно друг от друга, и никто не пытается их соотнести. Знаете ли вы, сколько денег вам приносит веб-сервер? Как увидеть проблемы, когда все системы технического мониторинга горят зеленым? Сколько денег теряет бизнес, когда база данных загружена на 90%? А на 50%?

Если интересно узнать про наш опыт - приходите, будет жарко!

Расскажу про архитектуру и принцип работы Istio как Service Mesh.

Поговорим о:
- технической части взаимодействия сервисов при использовании этого подхода;
- том, за что отвечают основные компоненты и какие есть подводные камни;
- возможностях Canary deployment, фильтрации трафика, реализации паттерна circuit breaker и outlier detection в частности;
- flow общего сбора метрик и логов;
- неочевидных моментах работы абстракции над сетью (как происходит взаимодействие с внешними компонентами вне Service Mesh, как отлаживать проблемы с перехватом трафика, как нужно настроить service сущности Kubernetes для корректной работы таких фич, как tracing).

Доклад позволит вам понять, какие задачи решает Service Mesh, проще и быстрее начать работать с Istio.

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

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

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

Платформы потоковой обработки данных, построенные на Apache Stack, стали стандартом во множестве сфер - от финтеха и рекламных сетей до платформ интернета вещей.

Apache Kafka вытесняет с рынка другие брокеры сообщений, Apache Spark и Apache Flink зарекомендовали себя как платформы процессинга данных, Apache Cassandra и Apache HBase - уже фактически промышленный стандарт для хранения обработанных данных.

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

1. Системы потоковой обработки данных в 2018-году.
1.1. Архитектура систем брокеров сообщений и шин данных.
1.2. Архитектура систем процессинга данных.
1.3. Архитектуры СУБД для потоковой обработки данных.

2. Мониторинг и поддержка.
2.1. Обеспечение мониторинга: что мониторить, как мониторить?
2.2. Схемы обеспечения отказоустойчивости и катастрофоустойчивости элементов систем потоковой обработки данных.

3. И как с этим жить в продакшне?
Реальные примеры аварий, как не наступить на наши грабли?

Про kubernetes сейчас говорят часто, громко и восхищенно.

Мы в okmeter.io в какой-то момент поняли, что нам тоже нужен k8s в production, хотя у нас нет даже CI/CD, но есть задача делить общий пул серверов между приложениями и достаточно легко добавлять мощности в кластер. При этом был ряд обстоятельств, которые усложняли внедрение k8s:
* мы очень заботимся об отказоустойчивости (мы не притаскиваем новые технологии в prod, пока не разберемся в них на достаточном уровне);
* у нас есть сервисы со временем ответа < 10ms;
* у нас очень мало человеческих ресурсов на эту задачу (узнать 10 новых терминов ОК, 50 - уже нет).

В докладе я расскажу, как нам все-таки удалось решить эту задачу:
* HA k8s на bare metal из зубочисток и синей изоленты.
* Сеть k8s: как мы чуть не внедрили аппаратную виртуализацию сети для подов (sriov), но потом успокоились и взяли flannel host-gw. Как обеспечивали связность k8s кластера и соседних серверов.
* Почему мы не используем k8s service network, а делаем headless-сервисы и используем envoy+dns discovery везде, где только можно.
* Как мы готовили наши НЕ cloud native-приложения работать в k8s.
* Неочевидные проблемы в ограничении ресурсов.

Многие наши решения при этом не очень изящные (мягко говоря), но мы добились нужного баланса от внедрения k8s (порог входа VS плюшки k8s VS контроль VS производительность).

За 5 лет инфраструктура компании Учи.ру выросла с нуля до достаточно большой системы. Сегодня мы поддерживаем более 300 приложений в 5 странах, 100% в публичных облаках на докерах. По мере роста компании и запросов бизнеса мы внедрили много инструментов, адаптировали разные концепции, а попробовали еще больше.

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

Во многих организациях в качестве гипервизора используется VMware в разных его ипостасях. Чаще всего в его бесплатном виде - в виде ESXi. У себя в операторе связи мы использовали его достаточно давно, начиная с версии 5.0.

Разумеется, что у бесплатной версии есть ряд недостатков, которые успешно отсутствуют в платной версии продукта vSphere, однако модель лицензирования достаточно отпугивающая для малого бизнеса. А самое главное, что новые версии ESXi принесли целый ряд неудобств:
- веб-интерфейс, который не работает нормально (старый программный интерфейс несовместим с новыми версиями);
- сломан нормальный мониторинг RAID-массивов.

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

У нас уже был достаточно неплохой опыт и приятное впечатление от LXC, Linux Containers. Поэтому стало очевидно, что гипервизор мечты будет гибридным, т.е. сочетать для разных нагрузок KVM и LXD - эволюционное продолжение LXC.

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

О чем будем говорить в докладе:

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

2. Хранилище
Сделайте общее сетевое хранилище. Даже если вы не готовы внутри сети использовать 10 Gbps, то даже 1 Gbps даст Вам 125 мегабайт в секунду стораджа. Для целого ряда нагрузок этого будет достаточно за глаза, а миграция виртуальных машин станет элементарным делом.

3. Контейнер или KVM?
Плюсы, минусы, подводные камни. Какие виды нагрузки лучше положить в контейнер, а какие лучше оставить в KVM?

4. LXD или LXC
А ведь LXD - это LXC? Или это другая версия? Или надстройка? Или что это вообще? Развеиваем мифы и поясняем на пальцах, в чем заключаются отличия между LXD и LXC.

5. Удобный provisioning
Что удобнее: брать одинаковый образ или инсталлировать систему с нуля каждый раз? Как это делать быстро, четко, ровно каждый раз?

6. Как делать виртуалку хорошо внутри?
Здесь будут страшные рассказы о загрузчиках, разделах, LVM и прочем ужасе.

И еще куча всяких мелких вопросов:
- как быстро перетащить виртуалку c ESXi на KVM?
- как хорошо мигрировать?
- как правильно виртуализировать диски?

Ваши разработчики вошли во вкус, и микросервисы растут как грибы? Что, если добавить новые пайплайны - это 5 строк кода?

Мы устали кликать по кнопкам в UI и с третьего раза написали Kotlin DSL, который описывает, какие у нас сервисы, а не как их деплоить.

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

Расскажу о том, какой путь прошли при внедрении подходов автоматизации управления инфраструктурой, а прошли мы пять стадий:
* Да зачем нам Devops, может просто обойтись десятком сисадминов?
* Убедились, что десяток админов не подошел, и начали анализировать ситуацию.
* Затем перешли к проектированию системы.
* Далее был выбор инструментария.
* Самым кропотливым был последний этап - наведение порядка. Но и самый приятный, т.к. его результаты видны невооруженным глазом, как непосредственным исполнителям т.е. нам, так и заказчику всех изменений.

Собственный провайдер IaaS.
Наши основные инструменты: git, ansible (AWX), jenkins.

CoreOS Container Linux - современная операционная система, созданная специально для запуска приложений в контейнерах, и отсутствие пакетного менеджера нисколько не мешает. Система минималистична, но для удобной эксплуатации там есть все необходимое - SSH, Bash, systemd, LVM, Docker, iptables, SELinux, ... У CoreOS Container Linux масса достоинств и одно из них - отсутствие всего лишнего. А все недостающее запускается в Docker. Но и недостатки у системы тоже есть.

В докладе поделюсь опытом:
- запуска на bare metal и в виртуальной среде: ESXi, DigitalOcean, AWS;
- первичной настройки через Ignition;
- управление с помощью SSH и Ansible;
- запуска Kubernetes;
- обновления.