Доклады секции "DevOps и эксплуатация"

VML — это инструмент для простой и прозрачной работы с виртуальными машинами qemu. VML может инициализировать образы с помощью cloud-init. Виртуальные машины с ALT, Arch Linux, Centos, Debian, Fedora, openSUSE и Ubuntu можно создать всего одной командой.

Изначально VML разрабатывался для тестирования облачных образов, но потом оказался полезен и при решении других задач. Одна из основных фич — древовидность. Практически все команды можно запустить сразу на группу виртуалок. Запустить новую виртуальную машину почти так же просто, как сказать "Я люблю Linux" — нужно всего 3 слова...

ПО сторонних производителей сложно мониторить из-за отсутствия удобного API, интерфейсов, а также из-за лицензионных ограничений. На помощь приходит eBPF — современная подсистема в ядре Linux, позволяющая вставлять ваши вызовы в любой пользовательский код и некоторые системные функции ядра. Теперь задачу мониторинга может решить даже менеджер, у которого лапки.

Как и многие другие компании, 5 лет назад мы перешли от монолитной архитектуры к микросервисной. Наши нагрузки за это время существенно выросли, а вместе с ними выросла и потребность в быстрой и масштабируемой инфраструктуре. Наш Kubernetes прошёл путь от Kubespray к своим плейбукам, а от них — к подходам, похожим на подходы облачных провайдеров. От трёх статичных кластеров до сотни, поднимаемых за 3 минуты.

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

* API management — что это такое и с чем его едят.
* Зачем это, вообще, надо.
* Публичные API.
* Обзор решений для API management.
* Наш опыт с Gravitee GW — чего оно умеет, и какие проблемы помогло решить.

Задача обеспечения стабильности и отказоустойчивости приложений остаётся актуальной во все времена. Задача эта комплексная и лежит в нескольких плоскостях:
* отказоустойчивой должна быть инфраструктура, в которой мы эксплуатируем приложение;
* архитектура приложения должна быть построена с учетом требований по отказоустойчивости.

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

Давайте разберём эти возможности и рассмотрим паттерны создания отказоустойчивой инфраструктуры для приложений в Kubernetes.

В СДЭК вместе с Кроликом мы прошли тернистый путь от 1 ноды до крупного кластера. Мы поделимся нашим опытом использования инструмента и расскажем:
* как мы живем с хайлоад-кластером из 8 нод;
* почему мы отказались от HA-cluster;
* почему мы не используем Kafka?
* какие опасности вас могут ждать, если вы хотите делать распределенный кластер между ЦОД-ами;
* отказоустойчивость или скорость — а можно все вместе?
* почему в Exchange мы отказываемся от Topic и уходим на Fanout?
* история наших факапов, и как PHP сжег кролика;
* что нового появилось в RabbitMQ за последний год.

Цель инфраструктурной команды — улучшить надежность и отказоустойчивость, уменьшить time to market, снизить когнитивную нагрузку. Для этого многие компании реализуют свою домашнюю платформу (PaaS).

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

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

Поделимся тем, как мы используем графы в задачах мониторинга и observability и как Root Cause Analysis в мониторинге помогает командам эксплуатации.

Как и многие другие вендоры ПО, 1С давно предлагает свои продукты в облачном варианте. Это, в первую очередь, наши облачные сервисы 1С:ГРМ (Готовое Рабочее Место) и 1cFresh. Предоставление облачных сервисов требует наличия соответствующей инфраструктуры — прежде всего серверов, на которых размещаются виртуальные машины с приложениями, и софта, управляющего физическими и виртуальными машинами.

Представим, что команда DevOps делает не только всё, что связанно с CI/CD, но и сильно выходит за эти рамки.

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

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

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

Как мы собрали сервис онлайн-тестирования за 2 месяца и провели "Экологический диктант" для 72 стран мира.

В 2021 году состоялся публичный OpenSource-релиз платформы для автоматизации обслуживания Kubernetes-кластеров — Deckhouse. До этого платформа более трех лет развивалась исключительно как внутренний DevOps-инструмент «Фланта». Deckhouse аккумулировала технологический опыт и лучшие практики, полученные нами в многочисленных и разнообразных highload-проектах. Сейчас Deckhouse — это платформа Enterprise-уровня, которая сертифицирована в CNCF и входит в единый реестр российского ПО.

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

Какие вопросы рассмотрим в ходе доклада:
* процессы разработки, тестирования и управления релизами Deckhouse;
* интеграция со сторонними решениями для мониторинга, работы сети, безопасности и с другими необходимыми компонентами;
* как мы приносим исправления и доработки в код сторонних решений вроде Cilium и KubeVirt;
* наш ​​вклад в развитие «ванильного» Kubernetes;
* как организована техническая поддержка;
* как мы сопровождаем пользователей — команды клиентов и внутренние DevOps-команды «Фланта»;
* планы по развитию платформы.