All of us enterprise developers are doing proper Continuous Delivery, including end-to-end testing, database migrations, canarying, monitoring, and rollbacks, all in a fully automated approach, right? Most real-world projects are not quite there (yet). The reasons, or excuses, are mostly complexity, insufficient testing, discrepancies between environments, or database migrations.

This session shows how a fully-fledged pipeline approach can be implemented, using Jenkins X, for enterprise applications that run in cloud native environments. We’ll see why automated testing only allows us to fully automate our setup, how to handle data in test scenarios, and how to tackle database schema changes. We’ll have a look at typical scenarios and pitfalls and how to effectively introduce CD without writing much code or configuration ourselves. We’ll furthermore see how Progressive Delivery and automated canarying approaches limit the blast radius of our changes. Join us if you strive to improve how your projects are shipped with fast pace and predictable quality, or if you simply want to sleep better at night.

Как не улететь при нагрузке и проходить QG быстро на примере Единого Биллинга МегаФон.

A traditional deployment scenario includes a central point of control, which sends updates to server nodes. In our Zold cryptocurrency project we were forced to create a different and reversive deployment model, where distributed and anonymous servers pull updates from an open public repository and restart themselves. The biggest problems we had to solve were related to error tracking and resolving of exceptional situations. In the presentation I will demonstrate how it works and we will deploy a new version right on the stage.

Как известно, построение CI/CD — дело непростое. Приглашаю вас за кулисы этого трудоемкого процесса в Wargaming Platform. Я расскажу, какими путями мы двигались и продолжаем двигаться на пути к поставленным целям, и покажу, как мы развивали инструментарий и совершенствовали команду, чтобы решать возникающие вопросы минимальными усилиями.

· Внедрение в условиях масштабной архитектурной трансформации.
· Высокоскоростное внедрение изменений в распределенной инфраструктуре компании.
· Способы достижения быстрого цикла внедрения.
· Объединенные кросс-функциональные команды как целевая схема взаимодействия с производством вендора.
· Уровни зрелости продуктов и требования к увеличению зрелости.
· Участие заказчика в командах разработки и внедрения.

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

Многие не понимают саму суть DevOps. Как правильно анализировать спектр проблем, как выстроить план деятельности? Как правильно рассчитать KPI и когда следует вовремя остановиться.

Поговорим о том:
* как мы живем в биллинге с заказной разработкой от нескольких поставщиков ПО;
* как выполняем сценарии развертывания и управления высоконагруженных биллинговых приложений на базе Jenkins, Ansible, Git, сохраняя требуемый уровень отказоустойчивости;
* как нам удалось построить единый пайплайн управления циклом доставки для всех продуктов по средствам Active Choice Parameter, Shared Library и Scripted Pipeline Jenkins;
* каким образом осуществляется управление сервисами после их установки;
* как обеспечивается катастрофоустойчивость.

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

В этом докладе я поделюсь историями и некоторыми решениями из собственного опыта навигации организаций через DevOps-трансформацию.

1С производит инструменты для быстрой разработки кросс-платформенных бизнес-приложений и рантайм для их работы (общее название – платформа «1С:Предприятие»). Бизнес-софт, разработанный на нашей платформе, работает на Windows, Linux, macOS, Android, iOS, в браузерах, использует СУБД MS SQL, Oracle, IBM DB2, PostgreSQL. Наш софт используют 5 миллионов конечных пользователей в 1.5 миллионах организаций. Исходники платформы «1С:Предприятие» - более 10 млн. строк кода (C++, Java, JavaScript).

С одной стороны, мы производим среду разработки бизнес-софта, и это напоминает Visual Studio или Eclipse. С другой стороны, мы производим рантайм для бизнес-софта, и это продукт типа .NET Framework или Java runtime. Одновременно в работе у нас находится до 6 версий продукта, включая как уже выпущенные и поддерживаемые версии, так и новые, пока не пошедшие в релиз.

Расскажем об особенностях поддержки цикла разработки большого тиражного кросс-платформенного продукта, об одновременном фиксе ошибок в нескольких версиях, о стратегиях тестирования (функционального и нагрузочного).

В жизни (почти) каждого ИТ-специалиста рано или поздно наступает момент, когда он попадает в маленькую agile/devops-команду, которая должна раз в 2 недели поставлять клиенту "ценность". Иногда эта метаморфоза случается даже без смены работы - это называют digital-трансформацией. И тогда наш (почти) каждый ИТ-специалист обычно нервно усмехается и говорит: "Камон, ребята, вдесятером за две недели придумать, разработать, протестировать и внедрить новый функционал в высоконагруженный сервис? Да вы издеваетесь!".

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

- Как развивать IT-культуру в разработке данных;
- фундаментальные проблемы в DWH/BI с т.з. DevOps;
- как привнести культуру DevOps в работу с данными? Практические советы;
- в чем отличия Pipeline для работы с данными от “классических” приложений;
- какие средства автоматизации реально полезны в контексте работы с данными.

Мы в Amixr.IO пропускаем через свой бэкенд production-инциденты клиентов. Готовы поделиться статистикой, инсайтами о том, как десятки команд по всему миру дежурят, разбирают инциденты, организуют работу и строят надежные системы.

Это вариант вводной лекции по SRE через кейсы из реальной жизни, подкрепленные статистикой и нашим опытом.

Когда вы — глобальный банк, и в вашем портфолио десятки тысяч приложений, вам не остается ничего другого, кроме как стандартизировать управление разработкой в масштабах всей компании. Это позволяет поддерживать и демонстрировать комплайнс, а также держать планку качества разрабатываемых приложений. С другой стороны, это не может не накладывать отпечаток на ежедневную рутину подготовки релизов: «все эти ваши процессы, апрувы, контролы — да кто их придумал, вообще?».

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

В Prisma мы обрабатываем на сервере более 500 тысяч фотографий в сутки.

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

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

Мы расскажем, как из источника проблем превратили блочный сторадж, поверх которого работают сервисы Compute Cloud, в один из самых стабильных компонентов платформы Mail.ru Cloud Solutions. Это блочное хранилище используется большинством компонентов IaaS и PaaS, включая наши сервисы, популярные в DevOps-практике: базы данных Mail.ru Cloud Databases и кластеры Kubernetes в облаке Mail.ru Cloud Containers.

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

В докладе показывается эволюция съема мониторинговых данных от систем до e2e-сервисов.

В высоконагруженных системах с большим географическим распределением, которые обслуживает распределенная команда из 800+ человек, возникают проблемы, когда операционные системы, базы данных, сервера приложений работают, но в итоге сервис, основанный на нескольких системах, не оказывается, и пользователь недоволен итоговой доступностью системы. Команды, ответственные за системы, говорят: «У нас все хорошо и все работает», пользователь говорит: «Ничего не работает».

Мы покажем, как, начиная от мониторингов отдельно взятых систем, был пройден путь мониторинга серверов, приложений до мониторинга сервиса глазами пользователя. Как на эти показатели KQI начали ориентироваться все технические специалисты, заказчики от бизнеса и вендор, поставляющий решение. В качестве визуального средства мониторинга используется grafana, в ней же построена математическая модель с прогнозом по показателям с итоговым расчетом доступности, ориентируясь на SLO и SLI.

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

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

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

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

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

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

В этом докладе я хотел бы поделиться с вами этим опытом и рассказать, как организовать управление большим количеством серверов в нескольких BareMetal-окружениях с использованием Kubernetes, Ansible и Continuous Integration.

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

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

В докладе ответим на следующие вопросы:
- что такое оператор и для чего он нужен;
- наш use case. Почему мы решили разработать собственный оператор;
- проблемы, с которыми мы столкнулись при разработке и деплое;
- зачем и в каких ситуациях стоит разрабатывать собственный оператор. Какие готовые решения уже существуют.

Многие наши заказчики уже адаптировали подход infrastructure as code. Но чтобы эффективно описать свою инфраструктуру, вам надо стать "YAML-гуру".

В своем докладе я расскажу о новом инструменте AWS Cloud Development Kit, который позволяет описывать инфраструктуру на знакомом языке (Python, TypeScript, JavaScript, Java). Я поделюсь советами, как начать использовать данный инструмент, создавать переиспользуемые компоненты для простого и удобного управления инфраструктурой.

Казалось бы, разработчики Terraform предлагают достаточно удобные best practices для работы с AWS-инфраструктурой. Только есть нюанс.

Со временем количество окружений увеличивается, в каждом появляются особенности. Появляется почти копия стека приложений в соседнем регионе. И Terraform-код нужно аккуратно скопировать и отредактировать согласно новым требованиям или сделать снежинку.

Через год-другой папка с Terraform-кодом превращается в снежный ком: много похожих ресурсов, но каждый описан чуть-чуть по-другому. Когда появляется breaking change, то необходимо обновить значительное количество кода, проверить его на соответствие реальным ресурсам. Прибавим сюда постоянные попытки точечного рефакторинга, чтобы улучшить полученный хаос. В итоге получаем кучу кода, обслуживание которого обходится весьма дорого.

Мой доклад — про паттерны размещения кода, нацеленные на упрощение автоматизации и дальнейшего развития. Расскажу, как работают такие паттерны и приведу примеры кода. Надеюсь, пригодится всем, кто работает или планирует работать с Terraform вдолгую.

Как часто вы задумываетесь об изоляции, внедряя очередное решение на основе контейнеров в вашей инфраструктуре? Docker, LXC или rkt нельзя назвать изолированными песочницами — да, они быстры, эффективны, но разделяют общее "хостовое ядро". Атаки на такую инфраструктуру могут иметь катастрофические последствия, особенно если вы существуете в multi-tenancy-окружении.

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

Основные темы, которые будут рассматриваться:
1) Основы безопасности. Что и от кого защищаем.
2) Оперативный мониторинг ИТ и ИБ: есть два стула. Основные подходы и параллели в построении мониторинга.
3) Рутинные процессы безопасности.
4) Пересекающиеся процессы ИТ и ИБ.
5) CIS CSC - что это такое и как это внедрять.
6) Регулярные проверки: как и зачем.
7) Enlarge your tools: ИТ-тулкит для безопасности (и наоборот).
8) Про KPI здорового человека. Какие показатели безопасности стоит включить в регулярную оценку?

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

Я расскажу о некоторых направлениях атаки на кластер Kubernetes и о способах защиты кластера от них. Расшифрую PSP, RBAC, Resource Quota и Limit Range. И покажу, чем грозит незнание этих терминов.

Что общего у брокера сообщений, платформы для потоковой аналитики и QaaS в Авито – все они построены на Apache Kafka. Про эти три кейса использования Apache Kafka расскажу на докладе.

* Как правильно готовить Vault для разнообразных команд.
* Доклад будет интересен средним и крупным компаниям, которые хотят внедрить Vault и убрать секреты из общедоступных мест.
* Инженерам, желающим строить сервисы, а не управлять руками.

— Горизонтальное масштабирование — проблемы MySQL.
— Партиционирование, шардинг и почему это не всегда возможно.
— Варианты горизонтального масштабирования для MySQL.
— Vitess — запуск и первичная настройка.
— Типичные проблемы и пути их решения.
— Итоговая архитектура.
— Результаты нагрузочных тестов.

Развёртывание и поддержка сетевой инфраструктуры для энтерпрайз-компаний в AWS достаточна проста. Но что, если это телекоммуникационная компания, имеющая свою опорную IP/MPLS-сеть, точки присутствия в десятках стран и желающая идти в Публичные Облака? Я хочу поделиться с вами опытом построения такой инфраструктуры.

* Что такое объем хранилища и эффективно ли вы его используете?
* Как дать нескольким сотням пользователей по 10 Тб доступного для изменения и модификации контента, используя всего 20 ТБ?
* Можно ли “на лету” синхронизировать эти данные между несколькими дата-центрами?
* Можно ли хранить данные пользователей со сжатием в 5 раз и предоставлять их в real-time?
* Как исключить любое влияние пользователей друг на друга при последовательном использовании одной и той же виртуальной машины?

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

Мы живём в сложное микросервисное время. Нельзя просто взять и написать код. От современного разработчика требуется понимание и использование инструментов, которые выходят за рамки кода, отвечающего за бизнес-функционал. Service discovery, centralized configuration, distributed tracing, circuit breaking, API gateway — все эти штуки из удела высшего общества давно превратились в обыденные механизмы, без которых не построить современное приложение. Одно хорошо — обо всём этом уже позаботились другие люди и приготовили для нас замечательные готовые решения. Казалось бы, добавил новую библиотечку в зависимости — и готово, однако всё не так просто — обрастая функциональностью, мы теряем легковесность. Всё это сопровождается постоянным усложнением систем и новыми функциональными хотелками.

В докладе расскажу про способ, как мы в Леруа Мерлен справляемся с ожирением наших микросервисов.