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

Поиск по тегам:
Показать только принятые доклады

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

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

Доклад принят в программу конференции

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

Доклад принят в программу конференции

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

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

При разработке и эксплуатации сервисов у нас остро стояла проблема хранения и доставки актуальных секретов к сервисам.

За многолетний опыт компании мы использовали множество инструментов. Большинство из них не подходят для использования в Kubernetes. Мы выбрали Vault и Sidecar Injector, и я расскажу, почему. Как мы решали возникающие трудности (unseal, ENV, cronjobs). Что мы храним в коде (spoiler: все).

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

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

Доклад принят в программу конференции

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

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

Обучение и управление знаниями

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

Каждый проект мы сопровождаем пакетом документов. От заказчика к заказчику набор инструментов для сопровождения и ведения документации меняется. В итоге нам, как разработчикам, приходится поддерживать у себя несколько инструментов для версионирования и хранения документации: SVN, Gitlab, Confluence.

В докладе мы расскажем о том:
- Как подружить эти три системы друг с другом
- Какую документацию можно вести в гите и при каких условиях
- С какими техническими и организационными проблемами мы столкнулись
- Что изменилось в процессах разработки и тестирования с введением такого DocOps подхода
- Какую пользу увидел бизнес в таком решении

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

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

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

Доклад принят в программу конференции

Нет плохих и хороших компаний.
Нет плохих и хороших кандидатов.
Есть просто более подходящие и менее подходящие друг другу.

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

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

3. А сколько ты зарабатываешь?
Поговорим с кандидатами о том, как задавать вопросы о потенциальной зарплате, как и зачем "торговаться".
Нанимающие лиды смогут определить зарплатную вилку и сумму в оффере для конкретного кандидата, не сравнивая людей внутри компании.

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

5. Испытательный срок и серьезные отношения. Пройти нельзя уйти.
Почему 3 месяца, зачем нужен, что проверить.

Доклад принят в программу конференции

SRE-практики

Расскажу о том как мы обнаружили проблемы производительности нашего сервиса трекинга рекламных компаний, почему мы обвинили во всех наших проблемах nginx (зря), почему нельзя доверять безоговорочно транспорту (даже kafka), чем может быть плох open tracing, почему мониторинга никогда не бывает мало и что технические проблемы могут принести хорошие организационные изменения

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

Поговорим о том, как и зачем команда разработчиков Kubernetes тестирует свои релизы. Какой опыт можно из этого извлечь и чем это может помочь администраторам кластеров.

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

Соберем свой hollow-cluster и проверим, как Kubernetes переносит масштабирование, когда количество нод переваливает за 5к. Рассмотрим, как это влияет на API-сервер и попытаемся побить некоторые рекорды горизонтального масштабирования.

Найдем отличия реального кластера от hollow-кластера и сравним основные показатели производительности control plane.

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

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

Доклад принят в программу конференции

* FAANG SRE vs текущие реалии.
* Мы написали свой оркестратор — у нас теперь SRE?
* Как живут без SRE? На примере энтерпрайза.
* Кого ищут под словом SRE?
* SRE — антипаттерн DevOps.
* Кому нужен SRE по книге?

Доклад принят в программу конференции

С точки зрения процессов и практик, все, что описано в SRE => детально описано и специфицировано уже 20 лет как в ITIL (первую редакцию не принимаю в расчет).

При этом SRE — слава и почет в нашей с вами милой тусовочке. А ITIL всячески поливается лучами ненависти.
Значит, отличия все же есть? Да, конечно, и не только культурные.

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

15+ лет в Operations — интересно все это вспоминать в ретроспективе.

Доклад принят в программу конференции

В этом докладе мы:
•‎ Разберёмся в терминах Continuous Integration, Continuous Delivery и Continuous Deployment.
•‎ Выясним наконец, что такое GitOps и какие проблемы он решает.
•‎ Рассмотрим популярные утилиты: ArgoCD, FluxCD и паттерны их использования.
•‎ Разберём практики организации Git-репозитория и настройки пайплайнов.
•‎ А так же копнём чуть глубже и детально рассмотрим настройку прав доступа и кастомных плагинов в ArgoCD.

Наконец я расскажу про наш опыт использования ArgoCD для развёртывания Kubernetes-кластеров и управления приложениями в Bare Metal-среде.

Доклад принят в программу конференции

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

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

В докладе я расскажу про все те способы, которые перепробовал: Helm-чарты, операторы, Jenkins, GitLab и даже AirFlow. Так получилось, что Kubernetes не очень хорошо умеет в jobs. Он все-таки оркестратор, а не scheduler. Поэтому, если хотим сделать хорошо, то приходится делать самим!

Доклад принят в программу конференции

- State файл и методы и боли его хранения
- Логическое разделение terraform проектов внутри репозитория
- Как сделать CI чтобы ничего не сломать по дороге к продакшену
- Шаги по ревью и аппруву изменений
- Чиним если сломали, и откат state файлов

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

Облачная аналитическая платформа дома на коленке:
- конфигурация k8s-кластера;
- описание задач;
- план аварийного восстановления.

Доклад принят в программу конференции

Вам знакомы такие проблемы, как:
- долгое создание тестовых окружений и стендов для разработки;
- как поменять одну или несколько переменных на 5 стендах, на 10 или на 100;
- непонимание того, что происходит на стендах, какой они версии, какие на них инфраструктурные компоненты?

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

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



Доклад принят в программу конференции

* Краткая предыстория *
У нас было два монолита, полтора десятка сервисов и полсотни окружений dev-qa-prod. Мы хотели бы остановиться, но, раз нырнув в SOA, приходится барахтаться.

Что болело: всё это никак не лезло в docker, постоянно требовало рефакторинга и сложно поддерживалось.

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

...
Прошло 3 года.
— Ну? когда уже откажемся от Puppet'а?
— Скоро, — грустно отвечаем мы, выгребая баги после теста нового стейджинга.

* Финал *
За 4 года мы выросли втрое по ИТ (и в 6 раз по выручке) и торжественно останавливаем Puppet-сервер!

* Эпилог *
Сидя с рюмочкой шампанского у себя в квартале, легко фантазировать: "Вот была бы у нас машина времени, что я бы сам себе сказал за 45 минут лет пять назад?":
- Куда смотреть?
- Что считать?
- Сколько людей было, а сколько нужно? И, главное, как это посчитать?
- Какой план составлять на эту работу? И какие сроки обозначить?
- Как, когда и по каким точкам контролировать?
- Как это можно "продать бизнесу"?
- Когда менять план и как это объяснить?

Доклад принят в программу конференции

Вы разрабатываете servrless-приложения и хотите выстроить для них правильные CI/CD-пайплайны?

В рамках доклада я расскажу, какие инструменты предлагает AWS для реализации таких пайплайнов. Мы рассмотрим новые возможности по упаковке AWS Lambda в контейнеры и как это может упростить переиспользование уже существующих подходов. Рассмотрим такие инструменты, как AWS Serverless Application Model, AWS CodeBuild, AWS CodePipeline и AWS CodeDeploy.

Доклад принят в программу конференции

* Что это такое и как она поможет эволюционировать из "DevOps как сервис" в "DevOps как платформа"
* Какое ПО, попадающее под определение гиперконвергенции есть на рынке?
* IaC
* CI/CD по кнопке — миф или реальность?

Доклад принят в программу конференции

- Когда вам нужно внедрять тестирование терраформ-кода на безопасность?
- Инструменты для линтинга.
- Инструменты для тестирования кода на безопасность.
- Проблема кастомизации инструментов для тестирования безопасности.
- Интегрирование инструментов тестирования в CI.
- Куда и как отправлять репорты, чтобы их заметили и не игнорировали.

Доклад принят в программу конференции

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

Доклад принят в программу конференции

Подход immutable infrastructure известен многим, но при этом количество организаций, активно использующих этот подход, не так уже и велико.

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

Доклад принят в программу конференции

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

Меня зовут Виталий, и так получилось, что я упоролся по Ceph и SDS в целом. До такой степени, что в итоге реализовал собственную систему — Vitastor — быструю, простую, при этом имеющую аналогичную Ceph-архитектуру и, в принципе, потенциал для развития в его полную замену. В отличие от многих других «убийц цефа». :)

В докладе я хочу рассказать о том, зачем я это сделал, в каком состоянии разработка сейчас и что я планирую делать дальше.

Для начала и для тех, кто менее погружён в тему, я расскажу о том, что такое SDS (программные СХД) и зачем их вообще используют — а используют их многие «облачные» провайдеры — Amazon, Google, Yandex, mail.ru… Кратко остановлюсь на том, почему Ceph и внутренние SDS в облаках на самом деле не очень-то быстрые, а многие другие — вообще непригодны для production (консистентность — не пустой звук).

После этого перейду к рассказу о Vitastor. На данный момент система разрабатывается мной в 1 лицо примерно год в расслабленном темпе в свободное время (идеи до этого вынашивались ещё год-два) и насчитывает примерно 25000 строк кода — пожалуй, можно сказать «всего лишь 25000 строк кода» — и при этом поддерживает базовый функционал распределённой программной СХД без единой точки отказа. Я расскажу о выбранной архитектуре, о том, чем она схожа с Ceph и чем она от него отличается, почему я считаю такой путь правильным и какие у него могут быть недостатки и преимущества.

Покажу тесты производительности и сравнение с Ceph, расскажу о планах и потенциале дальнейшего развития. Конечно, система только недавно «родилась», многих функций в ней на данный момент ещё нет. Но в планах и реализация снапшотов, и контрольных сумм, и оптимизаций для SSD+HDD, и удобного Web-интерфейса, и даже, возможно, ФС. При должном запале всё это сделать вполне реально.

В общем, я выполнил совет — хватит ругать Ceph в чатах — возьми и сделай сам лучше! Взял, сделал. Осталось довести до production.

Доклад принят в программу конференции

- Есть ли DevOps в MLOps или это совершенно новая и уникальная сфера?
- MLOps вид сверху.
- MLOps-роли — дата-сатанист, МЛ-инженер и т.д.
- Пайплайны, везде CI/CD-пайплайны.
- Как MLOps интегрируется в другие процессы.
- Какие метрики есть в ML-процессе и как их замеряют и используют?
- Что делать с моделью после обучения? Как заставить ее работать?

Доклад принят в программу конференции

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

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

Поделимся опытом и некоторыми кейсами, связанными с решением задачи построения платформы.

Доклад принят в программу конференции

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

В этом докладе мы расскажем о том, как мы перевели наше облако на базе OpenStack с базовой архитектуры “один кластер хранилища на все зоны доступности” в отказоустойчивый вариант, не потеряв в удобстве работы с виртуальными машинами, дисками и образами.

Доклад принят в программу конференции

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

В докладе мы расскажем, как выбирали базу для хранения трейсов Jaeger и про дальнейший опыт эксплуатации Jaeger и Yandex Database в Auto.ru и Yandex.Cloud. Решение стало популярным внутри Яндекса, и мы выпустили Jaeger-драйвер для Yandex Database в Open Source. Появление Yandex Database Serverless дало пользователям возможность сэкономит, и мы хотим поделиться результатами тестов Jaeger с Yandex Database Serverless.

Доклад принят в программу конференции

Доклад очерчивает следующие проблемы и предлагает решение:
1. Проблемы с k8s: если на рынке есть одна альтернатива, то альтернативы нет. Или есть?
2. Проблемы с docker: более половины образов содержат уязвимости. Что делать?
3. Как быстро организовать альтернативу облаку k8s с аптаймом в год и поддержкой силами SRE-джуниоров?
4. Как при этом выводить приложения в пром одной командой из консоли?

Доклад принят в программу конференции

Вам требуется масштабировать CI/CD-пайплайны в облако AWS, но не хочется тратить много денег? Или, может быть, они уже в облаке и “бизнес” требует сократить расходы?

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

Доклад принят в программу конференции

1. Так что там с сетью вообще в Kubernetes?
Как вообще можно строить сети для контейнеров и что такое veth? Почему нам нужен иногда двойной NAT, чтобы делать вид, что у нас нет NAT? Зачем нам нужно столько правил iptables и почему это порой так не просто? Зачем нужно хранить это все в etcd? Почему в Kubernetes какие-то плагины реализуют сеть?

2. Почему так сложно, можно просто Flannel?
Мы же можем создать один бридж и просто покидать туда все veth? Может быть у нас может быть больше 255 подов на одном хосте? У нас же может быть простая таблица маршрутизации, да?

3. Мы поняли, бриджи плохо, давайте Calico?
Секундочку, это что, /32 маршрут на каждый под? Но ведь можно как-то элегантнее? А они говорят, что там поддерживаются какие-то правила фаервола? А они что, не везде?

4. Ответ на вопрос жизни, вселенной и всего такого про сеть
Какой плагин сети в итоге (не) брать. О чем думать в процессе планирования сети. Почему адресация важна.

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

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

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

Доклад принят в программу конференции

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

Оптимизация процессов, повышение качества контроля метрик, распределённая параллельная разработка

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

We will talk about all important steps that it takes to run the database on Kubernetes in production. Can you do it without operators? Can you work with k8s primitives only to run production-grade database and then DBaaS?

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

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

С Kubernetes вы можете собрать гибридное облако, которое заменит DBaaS. Kubernetes позволяет нам построить полностью open source DBaaS-подобное решение, которое может быть развернуто в любом месте, где работает Kubernetes - в общедоступном облаке и в вашем частном дата-центре, - без привязки к вендору.

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

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

Kubernetes Operator Pattern был создан для автоматизации роли человека-оператора, который управляет приложениями, имея глубокие знания о том как их правильно готовить. Это как раз то, что необходимо для управления базами данных! А в этой презентации я расскажу о том, как Kubernetes Operator для управления базой данных может быть устроен внутри и чему мы научились, создавая операторы для MySQL и MongoDB.

Доклад принят в программу конференции

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

- В двух словах — в чём роль внедрения DevOps-практик в организации?
- Сколько инженеров нужно, чтобы описать инфраструктуру предприятия?
- Какая квалификация инженеров действительно важна?
- Какие вопросы необходимо задать самому себе, чтобы понять, что всё действительно в порядке?
- Архитектура идеального предприятия со стороны инфраструктуры — какая она?
- Метрики везде, что смотрим в первую очередь?
- Пару слов о безопасности, всё ли решает DevSecOps?
- Выше только SRE?

Доклад принят в программу конференции

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

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

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

В докладе я расскажу о причинах, по которым так неохотно выделяют время на техдолг, а также о том, как избежать «банкротства». Поделюсь инструментами и подходами, с помощью которых можно «продать» технический долг команде и/или бизнесу. Рассказ будет построен с точки зрения инженера эксплуатации и снабжен большим количеством реальных примеров.

Доклад принят в программу конференции

Если:
- у вас в компании есть DevOps-отдел;
- вы задумываетесь о том, чтобы объединить всех девопсов в один отдел;
- кто-то в компании раскатал кластер кубера, и теперь мы их зовем DevOps-отдел;
то у меня для вас плохие новости...

Доклад принят в программу конференции

Трейсинг распределенных запросов — один из столпов observability микросервисной архитектуры. Мы рассмотрим, как технически реализуется трейсинг, какие преимущества дает трейсинг для диагностики проблем производительности, необходимые усилия для внедрения трейсинга своими силами, стандарты в этой области и как им следуют производители APM-решений и opensource-инструменты.

Доклад принят в программу конференции

Слово DevOps появилось в 2009 г. и оно означало вполне конкретную вещь: набор практик, чтобы совместить разработку и эксплуатацию. Это звучит очень красиво, но работает ли оно в современных условиях?

В докладе мы попробуем разобрать идеи DevOps применительно к современной действительности — актуальны ли они, и в каком виде.

Доклад принят в программу конференции

Разберемся, к какому DevOps-инженеру идти, когда сервер упал, а к какому — когда пайплайн красный.

Доклад принят в программу конференции

Больше 10 лет прошло с момента первой легендарной конференции DevOps Days в Генте. За это время в мире появилось с несколько дюжин различных коллабораций с Ops-спецами, начиная с класических DevSecOps-ов, заканчивая диковинными HugOps-ами.
Рассмотрим боли и причины появления таких движений, возьмём их лучшие практики и проанализируем направления, куда можно развиваться DevOps специалисту.

Доклад принят в программу конференции

На воркшопе по командным топологиям мы научимся применять фреймворк Team Topologies на практике.

Фреймворк Team Topologies (https://teamtopologies.com) определяет ожидания и модели поведения для всех команд в компании, упрощает командные взаимодействия и действует как способ определения границ.

Фреймворку Team Topologies уже 2 года. Все больше компаний начинают его применять и делятся своим опытом. Я приведу примеры использования фреймворка, и мы вместе спроектируем текущую и идеальную топологию для вашей команды или компании.

Воркшоп будет проходить в Miro.

Доклад принят в программу конференции

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

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

Доклад принят в программу конференции

Путь Ак Барс Цифровые Технологии (Ак Барс Банк) от создания продуктовых команд с общим владением системами к появлению платформенных команд с ответственностью по системам.

Нужны ли платформенные команды, что это такое у нас, какие роли и зоны ответственности у такой команды, преимущества и недостатки модели «Продуктовые и платформенные команды», где место SRE в такой модели, баланс между гибкостью решений и целостностью систем — все это проходим на собственном опыте, чем и поделюсь в своем докладе.

Доклад принят в программу конференции

Вашему вниманию представляются тезисный план доклада "Детоксикация или Ускоряемся и строим Devops Community":

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

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

DevOps’у как явлению уже больше 10 лет и все мы прекрасно знакомы с лучшими практиками. Однако оказавшись в стартапе у истоков перед нами встает дилемма: Сделать все сразу по канонам и затянуть с первым касанием с пользователями или выбрать тактику тяп ляп и в продакшн.

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

Этот доклад - очередной повод задуматься о “Чтобы что мы это делаем?” и “Какую проблему мы решаем?”

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

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

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

В этом докладе я расскажу как мы подходили к созданию сообщества практики по автоматизации DevOps CI/CD в Сбере. Предпосылки, ключевые проблемы и мировые best practice, которые мы использовали.

Доклад принят в программу конференции

Devops отдел - суровое будущее больших компаний и не только
Кризисы и их решение благодаря проектному подходу к автоматизации
Роли в Devops отделе и подбор персонала для этих ролей.
Документация - необходимое зло или "один бокал хайпа bus-фактора за соседний столик"
Кто победит: "девопс в команде" или "девопс в команде в отделе в команде"

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