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

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

Безопасность, DevSecOps

- Базовый набор тестирования на проникновение: обзор популярного инструментария для поиска недостатков в сетевых сервисах и веб-приложениях
- Фаервол нам не помеха или техники пивотинга
- Распространенные ошибки разработчиков и системных администраторов, которые помогают атакующим достигать цели
- Как теперь с этим жить? Оцениваем риски и противодействуем атакам

Программный комитет ещё не принял решения по этому докладу

Непрерывная поставка

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

Кроме прозрачности процессов мы получили прирост эффективности в среднем на 13 500 рублей в месяц в команде из 9 человек. В докладе расскажу о том, как перестраивались инструменты и люди.

Программный комитет ещё не принял решения по этому докладу

Инфраструктура как код

Часто мы предпочитаем работать с готовыми инструментами, просто потому что они уже есть, и закрываем глаза на их недостатки. Мы долго управляли Github-ом вручную, а в какой-то момент решили внедрить подход Infrastructure-as-a-Code, для чего выбрали популярный Terraform.  И на наших объёмах -- 350+ человек и 400+ репозиториев -- это оказалось не очень хорошим решением.  Тщательно потоптавшись по граблям, мы запилили свой вариант на Ansible.
• Я расскажу про найденные грабли (лимиты Github, низкая производительность, провоцирует ошибки), и почему при наших размерах у Терраформа нет плюсов (хотя мы честно искали).
• Покажу наше решение на Ansible, которое отрабатывает в 10--100 раз быстрее, с простыми конфигами и другими плюшками.  Представлю типичные задачи, которые стало проще решать.
• И поделюсь реализацией своего решения в виде открытого проекта на Github.

Программный комитет ещё не принял решения по этому докладу

Способов развёртывания кластера kubernetes насчитывается не один десяток, как на bare-metal, так и на различных облачных платформах. Начинающие администраторы k8s обычно используют одну из известных утилит для сборки кластера и лишь намного позже узнают о подводных камнях того или иного решения. Каждый инсталлятор k8s содержит набор предубеждений его создателя, которые могут помешать настроить и собрать кластер так, как нужно конкретной компании. Когда приходит осознание, что дефолты инсталлятора не подходят для нужд компании, на кластере давным-давно production-нагрузки и пересобирать его уже нельзя. Я расскажу, как неинвазивно переехать на наиболее конфигурируемый kubernetes the hard way и приведу примеры сценариев факапов и как их избежать.

Программный комитет ещё не принял решения по этому докладу

Инфраструктурная платформа

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

Именно это позволяет вам сделать Cloud Custodian - опенсорсный и бесплатный продукт, позволяющий админам настраивать политики контроля за облачными ресурсами в любом из трёх облачных сервисов - GCP, AWS, Azure. Можно задать и действия, которые будут автоматически выполняться по тому или иному интересующему вас событию. Cloud Custodian может отслеживать старт новых виртуальных машин в Compute Engine, развертывание новых кластеров Kubernetes, создание новых ролей в IAM, добавление прав пользователям, появление бесхозных бекапов и т.п.

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

Программный комитет ещё не принял решения по этому докладу

С ростом компании инфраструктура становится сложнее, постепенно стремясь IaaS. В докладе мы рассмотрим IaaS как внутренний внутренний продукт компании.

Ответим на вопросы:
- Почему нужно смотреть на инфраструктуру как на продукт?
- Что это требует и какой приносит профит?
- Какие практики нужно использовать из продуктовой разработки?
- Какие вызовы встают перед командой?
- Как изменятся команда и процессы внутри нее?

Программный комитет ещё не принял решения по этому докладу

Булиты:
- Как развернуть инфраструктуру Data Science в Kubernetes
- Как автоматизировать жизненный цикл модели от эксперимента до эксплуатации при помощи MlFlow
- Как обучать модель используя Mlflow и kubernetes
- Как быстро превратить модель в современный масштабируемый облачный сервис.

Описание:
Приглашаем на вебинар "Создаём инфраструктуру для Data Science с помощью MLFlow в Kubernetes". На вебинаре мы расскажем вам о том, как организовать процесс разработки моделей машинного обучения на базе технологии MLFlow и интегрировать его в общий процесс разработки в вашей организации. Для этого мы сделаем небольшой теоретический экскурс в основные понятия и концепции, после чего развернём все необходимые инфраструктурные компоненты в кластере Kubernetes, продемонстрируем принципы работы с MLFlow и его возможности по автоматизации жизненного цикла модели, продемонстрируем процесс обучения моделей с помощью MLFlow в Kubernetes и, в заключение, расскажем о способах превращения полученных моделей в REST сервис и UDF функцию с последующим их запуском в Kubernetes.
Ждём Вас!​

Программный комитет ещё не принял решения по этому докладу

SRE-практики

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

Программный комитет ещё не принял решения по этому докладу

С точки зрения процессов и практик, все что описано в SRE => детально описано и специфицировано уже 20 лет как в ITIL (первую редакцию не принимаю в расчет).
При этом SRE - слава и почет в нашей с вами милой тусовочке. А ITIL всячески поливается лучами ненависти.
Значит отличия все же есть? Да конечно, и не только культурные.
Какой единый фундамент заложен в SRE и ITIL и почему его обязательно важно знать и понимать всем кто занимается Operations. Какие отличия между этими двумя подходами вызывают такое противоположное отношение, не только культурологические, хотя и они тоже. Я постараюсь ответить на эти вопросы с позиции техдира, который внедрял ITIL, проводил DevOps трансформацию, и наблюдал стихийную эволюцию практик подразделения в модель как раз SRE, хотя ребята даже об этом не догадывались.
15+ лет в operations - интересно все это вспоминать в ретроспективе.

Программный комитет ещё не принял решения по этому докладу

DevOps-трансформация

- Что такое Kubernetes и почему он так популярен.
- Почему Kubernetes это не только платформа для запуска контейнеров, а нечто большее.
- Как работает Service Discovery в Kubernetes, что такое headless-сервисы.
- Разберём сущности Kubernetes и почему их так много. Чем отличаются StatefulSet от Deployment и Daemonset.
- Компоненты из которых состоит Kubernetes: etcd, kube-apiserver, kube-controller-manager, какова роль каждого из них.
- Что такое неймспейсы ядра linux и контейнеры как таковые.
- Как работает сеть в Kubernetes, зачем нужны kube-proxy и CNI-плагин.
- Посмотрим как создавать свои приложения и запускать их в Kubernetes.
- Почему нужно применять подход по процессу на контейнер, и нежелательно использовать latest-тэги
- Как собираются логи и метрики с ваших сервисов.
- Что такое CustomResourceDefinition и как их можно использовать.

Программный комитет ещё не принял решения по этому докладу

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

Программный комитет ещё не принял решения по этому докладу

Доклад на тему как оптимизировать CI инфраструктуру, как найти проблемы в текущей инфраструктуре, советы по оптимизации Jenkins, процесса сборки и тестирования. Как мониторить свои достижения - мониторинг и KPI.

Программный комитет ещё не принял решения по этому докладу

- Как начать проект, создавая сразу необходимую DevOps атмосферу в коллективе
- Как получить DevOps как процесс , а не как отдельного человека
- Как бороться с возражениями команды
- В какой момент получилось продолжать строить процессы силой Dev и QA команд, без участия так называемого "DevOps инженера"
- Какие инструменты автоматизации мы использовали и как происходило обучение QA и Dev коллег использованию
На все эти вопросы я дам предельно четкие ответы!

Программный комитет ещё не принял решения по этому докладу

Архитектура в DevOps, DevOps для CTO

Опять боль и страдания!!! Внедряя NoOps в большой компании я услышал много разного от простых эмоций:
- Да вы теперь просто операторы приватного облака…!
- У нас кончилось админстово в компании!!!
- А что я теперь и в мидлваре должен разбираться...

До вполне интересных вопросов:
- Оптимизацией СУБД кто теперь занимается?
- Кто отвечает за бэкап?
- А кто теперь отвечает за инциденты?

Есть безусловно полезные вещи которые очень трудно оспорить, например автоматизация запросов на обслуживание(любые действия имеющие обкатанный скрипт исполнения) где вы интегрируете свою инфраструктуру с роботами и нет больше лагов и ошибок при исполнение. Все "энтерпрайз вахтёры" (политики и регламенты безопасности) тоже эффективно автоматизируются и самое прикольное тут, что никто вам даже спасибо не скажет, все привыкнут к хорошему через неделю даже не вспомнят что может быть по другому. Самое тонкое место это передача компетенций, как быть Томом Сойером, а не "вертухаем" заставляющим делать «чужую» работу. Все это мы прошли, причём в серьезном масштабе 500 дев на 10 опс.
По классике жанра, мы собрали все возможные "грабли", где то пошлось пойти на компромиссы ибо любая концепция требует обработки напильником под себя, что бы максимально решать свои задачи. У нас есть все и NoOps и DevOps и просто Ops. Хочу рассказать про свой опыт погони за хайпом!

Программный комитет ещё не принял решения по этому докладу

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

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

В програме:

Обзор стораджей:
- Чем отличется блочное хранилище от файлового или объектного.
- Когда следует использовать каждый из этих типов хранения.
- Поговорим о плюсах и минусах каждого из них.
- Что такое Linstor и чем он лучше Ceph.
- NFS-server-provisioner и неужели создавать RWX-тома можно так просто.

Сеть:
- Что делать если в Kubernetes нельзя назначать статический айпишник подам но нам так хочется

Архитектура Stateful-приложений в Kubernetes:
- Поды это не виртуалки, что общего у stateful-подов с виртуальными машинами, почему это сравнение крайне некорректно.
- Как обеспечить надёжность запуска stateful-приложения в Kubernetes.
- Как работает simple leader election и как просто добавить его к вашему приложению
- Как работает fencing и проблемы которые он решает.

Программный комитет ещё не принял решения по этому докладу