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

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

Обратная связь

Grafana/loki как альтернатива e[l|f]k

Олег Ногин

Что из себя представляет loki, сравнение с eflk, как использовать, пример реализации из прода movista.ru

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

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

Reversive Decentralized Deployment: Zold Cryptocurrency Example.

Егор Бугаенко

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.

Управление конфигурацией
,
Непрерывное развертывание и деплой
Программный комитет ещё не принял решения по этому докладу

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

Наследование legacy систем и процессов или первые 90 дней в роли CTO

Leon Fayer

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

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

DevOps в разработке: автоматизация написания кода веб-приложений

Роман Ахмадуллин

Сегодня DevOps находится на волне успеха. Практически на любой конференции, посвященной автоматизации, можно услышать от спикера мол “мы внедрили DevOps и тут и там, применили это и то, вести проекты стало значительно проще и т. д. и т. п.”. И это похвально. Но, как правило, внедрение DevOps во многих компаниях заканчивается на этапе автоматизации IT Operations, и очень мало кто говорит о внедрении DevOps непосредственно в сам процесс разработки.

Мне бы хотелось исправить это маленькое недоразумение. DevOps в разработку может прийти через формализацию кодовой базы, например, при написании GUI для REST API.

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

Из доклада вы узнаете:
- как ускорить внедрение новых фич в веб-приложение;
- как подружить back-end и front-end;
- почему формализованная кодовая база это хорошо.

Single page application, толстый клиент
,
Взаимодействие с серверной стороной (API)
,
Фронтенд / другое
,
Devops / другое
Программный комитет ещё не принял решения по этому докладу

Сталкиваем лбами DevOps и реальность

Василий Останин

Пройдемся по популярным телодвижениям во время внедрения практик:
- Библиотека сервисов
- Выбор технологий для обеспечения петли DevOps (логирование, метрики и прочее)
- Безопасность
- Наши велосипеды и костыли
- k8s/docker swarm/nomad

И как с этим жить в команде:
- Как разрабатывать
- Как поддерживать
- Как не сгореть

Всё это из начинки из наших и известных фейлов и напряженностей, соуса из духа стартапа и приправленная регламентами банка под регуляцией ЦБ РФ и PCI DSS.

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

Когда CI/CD недостаточно или внедрение DevOps культуры

Ахмед Шериев

Некоторые компании внедряют CI/CD/Docker/k8s и считают что у них есть DevOps. Но несмотря на это все сроки срываются, пользователи недовольны, ПМ продолжает конфликтовать с разработчиками. В докладе рассмотрим темы трансформации культуры компании. Ошибки совершаемые со стороны ПМ и разработчиков и как исправлять их.

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

Основы DevOps - вхождение в проект с нуля

Андрей Юмашев

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

Непрерывное развертывание и деплой
,
Менеджмент в эксплуатации
,
Аппаратное обеспечение
,
Сетевое администрирование
,
Devops / другое
Программный комитет ещё не принял решения по этому докладу

А можно ли Bitrix в Kubernetes?

Станислав Тибекин

Предположим, у вас в компании есть своя выстроенная (и выстраданная) инфраструктура на Kubernetes с настроенным логированием, мониторингом, обвязками, автоматизациями и т.д. И в один прекрасный день вдруг возникает задача развернуть проект на 1С-Битрикс. Как быть? Разворачивать отдельную инфраструктуру и перекраивать существующие процессы эксплуатации из-за одного сайта ну совсем не хочется. Зачем городить второй огород, если уже есть первый? Взвесив все за и против, возникает вопрос: "А может всё-таки попробовать запихать 1С-Битрикс в Kubernetes?".

1. А нужно ли? Какой минимальный уровень должен быть у команды разработки, чтобы эта идея в голове DevOps'а не разбилась о суровую реальность отсутствия необходимых компетенций у проектной команды?
2. Как быть с лицензией? Что она позволяет и какие есть подводные камни?
3. Что зашивать в Docker-контейнер, а что выносить из него? Пройдёмся по структуре каталогов 1С-Битрикс и разберёмся, что можно положить в Docker, а что нет.
4. Как организовать структуру репозитория?
5. Как быть с миграциями БД?
6. Подведём итог. И всё-таки, можно ли и нужно ли 1С-Битрикс в Kubernetes?

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

SRE-практики

Что мы узнали об SRE, когда обработали первые 150к production инцидентов

Матвей Кукуй

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

Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
,
Менеджмент в эксплуатации
,
Devops / другое
Доклад принят в программу конференции

Почему стартапу нужны SRE практики

Алексей Андреев

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

PostgreSQL
,
Логирование и мониторинг
,
Непрерывное развертывание и деплой
,
GO
Программный комитет ещё не принял решения по этому докладу

Путь разработчика в SRE. История о том, что может побудить пойти в инфраструктуру целую команду разработчиков и как это продать бизнесу.

Матвей Григорьев

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

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

Методы и техника разработки ПО
,
Архитектуры / другое
,
Менеджмент в эксплуатации
,
Devops / другое
Программный комитет ещё не принял решения по этому докладу

Управление инцидентами с OpsGenie

Андрей Маркелов

Современные сервисы работают с терабайтами данных и миллионами пользователей на тысячах физических или виртуальных машин. На этапах разработки и тестирования в распределенных приложений, состоящих из сотен микросервисов едва ли получится предусмотреть разнообразие будущих сбоев. Для поддержания работоспособности продуктов нанимают специальные команды и используют средства мониторинга такие как Prometheus, DataDog, AppDynamics. В момент когда сбой все-таки случится, то будет быстро обнаружен, но минимизировать время обнаружения и заэскларивать проблему соответствующей команде. Сбой, который заметен для внешних клиентов, называется инцидентом и доклад посвящен управлению инцидентами с помощью OpsGenie.
Рассмотрим как «разбудить» нужного инженера и правильно оформить отчет. Также разберем возможные сценарии интеграции с Prometheus и Jira, а также “грабли” на которые успели наступить.

Логирование и мониторинг
,
Непрерывное развертывание и деплой
,
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
,
Менеджмент в эксплуатации
,
Devops / другое
,
Другое
Программный комитет ещё не принял решения по этому докладу

Как релизить сто тысяч приложений. Рассказ с полей про SDLC Governance

Илья Митруков

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

Большие проекты/команды
,
Управление изменениями, управление требованиями
,
Enterprise-системы
Программный комитет ещё не принял решения по этому докладу

NixOS. Практический опыт рационализации процессов разработки и доставки в условиях быстро меняющейся среды.

Максим Романов

1) NixOps: введение новых технологий без ломки процессов разработки и доставки ПО.
2) NixOS, или как с комфортом сидеть на 8 стульях: выбор операционных систем для разработки и продакшена.

Пакетные менеджеры и организация модульности
,
Оффлайн и кэширование в локальных хранилищах
,
Интерактивные приложения
,
API
,
PostgreSQL
,
Организация системы кеширования
,
Распределенные системы
,
Методы и техника разработки ПО
,
Разработка библиотек, включая open source библиотеки
,
Критерии выбора технологий для проекта
,
Логирование и мониторинг
,
Технологии виртуализации и контейнеризации
,
Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
,
Проектирование информационных систем
Программный комитет ещё не принял решения по этому докладу

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

Уменьшение влияния человеческого фактора на инфраструктуру компании

Александр Конюков

==Механизм Postmortems==
- Как было совсем давно 
- Переходной этап
- SLA который не совсем SLA
- Как сейчас и какой положительный эффект это нам дало, а именно:
- Робот который следит за тем что у всех задач в эпике постмортема (FAIL) (с высшим приоритетом) стоит спринт 
- Всегда понятно кто сейчас занимается задачами по FAIL и понятны сроки решения задач
- Проставление тегов компонентов позволяет понять самые болезненные компоненты 
- Разделили ошибки те, который зависят и не зависят от человеческого фактора. 

==Автоматизация инфраструктуры==

Как результат такой системы постмортемов мы породили ряд проектов, которые призваны уменьшить влияние кривых рук на инфраструктуру

- Flow выкладки конфигов инфраструктурных компонентов ( начали с конфигов nginx  на фронтах )
- Написание различных тестов (юнит, интеграционные) по каждому прошлому FAIL для каждого компонента ( рассказываем как запускаем, как анализируем ) 
- Постулат  - не наступать на одни и те же грабли, то есть заниматься регрессионным тестированием.
- IaaC - оркестрация всех инфраструктурных компонентов с помощью saltstack + git ( salt: как было,  как есть, как хотим ) 
- Автоматизация рутинных действий ( для уменьшения ошибок во время форс мажоров и в рантайме 
- Авто-обнаружение серверов и сервисов на них в Prometheus. 

Логирование и мониторинг
,
Управление конфигурацией
,
Менеджмент в эксплуатации
Программный комитет ещё не принял решения по этому докладу

Применение техник CI/CD для развёртывания и управления BareMetal-инфраструктурой

Андрей Квапил (kvaps)

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

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

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

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

Технологии виртуализации и контейнеризации
,
Управление конфигурацией
,
Аппаратное обеспечение
,
Непрерывная интеграция
,
Devops / другое
Доклад принят в программу конференции

Будущее infrastructure as code - это код на CDK

Роман Бойко

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

Стандарты кодирования
,
Работа с Amazon
,
Критерии выбора технологий для проекта
,
Архитектуры / другое
,
Управление конфигурацией
,
Непрерывная интеграция
,
Devops / другое
Программный комитет ещё не принял решения по этому докладу

Паттерны в Terraform для борьбы с хаосом и ручной рутиной на крупных и долгих проектах

Максим Кострикин

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

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

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

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

Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Devops / другое
Доклад принят в программу конференции

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

Как (вы)жить без отдела безопасности

Мона Архипова

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

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

Могут ли контейнеры быть безопасными?

Александр Хаёров

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

Безопасность программного кода, SQL и прочие инъекции
,
Критерии выбора технологий для проекта
,
Технологии виртуализации и контейнеризации
,
Devops / другое
Программный комитет ещё не принял решения по этому докладу

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

Путь от RAID до распределенного хранилища с хот-свопом и кэшами.

Сергей Чеботарев

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

Есть и программные решения - нам удалось построить на сравнительно небольшие средства распределенное хранилище на основе Virtuozzo Cloud Storage (PStorage). В данном докладе я расскажу как устроено такое хранилище, какую выгоду мы от него получили при разработке и тестировании, и как обращаться с ним не стоит. 

Отказоустойчивость
,
Распределенные системы
,
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
,
Аппаратное обеспечение
Программный комитет ещё не принял решения по этому докладу

Облачная платформа OpenNebula

Андрей Квапил (kvaps)

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

OpenNebula является облачной платформой с простым дизайном и понятной архитектурой, которая без особых затрат поможет создать вам мощное, и главное гибкое облако для ваших нужд.
Control-plane состоит всего из нескольких компонентов, что позволяет легко контейниризировать и управлять ими как обычным приложением, а также применять стандартные DevOps-практики для деплоя OpenNebula прямо в Kubernetes.
В данном докладе я расскажу о компонентах, из которых состоит OpenNebula, о назначении каждого из них, а также особенностях архитектуры и построения виртуальной инфраструктуры, и как в этом деле нам помогает Kubernetes.

В программе:

- Из чего состоит OpenNebula и за что отвечает каждый из ее компонентов
- Посмотрим как OpenNebula общается с compute-нодами и как происходит запуск виртуальных машин на них
- Что из себя представляют драйверы в OpenNebula.
- Рассмотрим как выбрать и настроить хранилище, и сеть.
- Расскажу как мы разворачиваем OpenNebula в Kubernetes и как мы вообще пришли к такому решению.

Технологии виртуализации и контейнеризации
,
Управление конфигурацией
,
Devops / другое
Программный комитет ещё не принял решения по этому докладу

Apache Kafka в Авито: история о трех реинкарнациях

Анатолий Солдатов

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

Микросервисы, SOA
,
Архитектурные паттерны
,
Отказоустойчивость
,
Распределенные системы
,
Архитектуры / другое
Программный комитет ещё не принял решения по этому докладу

Как правильно использовать доступный объем хранилища. Рецепт Playkey.

Владимир Рябов

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

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

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

Практический опыт переезда боевого проекта со 100 Гб базы данных из MySQL Percona в кластер на базе Vitess для горизонтального масштабирования

Кирилл Мельничук

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

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

Мониторинг системы - дело рук самой системы

Руслан Зиганшин

В своем докладе я расскажу о том, как зарождалась, развивалась и интегрировалась в существующие операционные процессы прикладная подсистема мониторинга ЦФТ-Банк:
* почему родилась идея реализовать мониторинг внутри прикладной подсистемы;
* как развивалось реализованное техническое решение;
* с какими проблемами в процессе эксплуатации мы столкнулись и как их победили;
* какие преимущества мы получили, и как изменился наш подход к процессу мониторинга программно-аппаратного комплекса;
* что ждет подсистему мониторинга в дальнейшем.

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

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

Триптих инструментов: Nomad, Consul, Vault для разгона производительности

Сергей Крамер

В один момент мы в команде решили проапгрейдить процесс разработки, деплоя и запуска собственных сервисов и хотим поделиться с вами нашей историей.
Поговорим о:
- почему стоит подумать об использовании таких инструментов как - service discovery, secrets management, orchestration в команде
- как мы пришли к стеку от Hashicorp и что из этого получилось

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

Сделаем микросервисы легковесными снова

Дмитрий Сугробов

В этом докладе будет представлена разница в подходах, в которых весь набор инструментов, таких как механизмы централизованного хранения конфигурации, service dicsovery, load balancing, distributed tracing и многие другие, необходимые для выживания в микросервисную эпоху, в первом случае хранятся и используются в каждом приложении (подход, например, с множеством библиотек spring-cloud-netflix стека в java), и во втором случае весь этот набор находится на инфраструктурном слое (например, kubernetes).

Тема обретает всё большую и большую важность в наше время, когда де-факто архитектурой по умолчанию становится микросервисная (что бы это ни значило), а количество сервисов множится с каждым месяцем (а может и неделей) активной разработки. Возрастает количество систем, в составе которых используются наработки на нескольких языках одновременно, и это является дополнительным толчком для использования так называемых language-agnostic инструментов. Для того, чтобы избежать повторное проделывание работы дважды, следует заранее, на этапе проработки технической архитектуры и выбора стека ответственно отнестись к выбору инструментов, необходимых для работы распределенной системы.

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

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

Спринты или марафон. Нужен ли скрам инфраструктурной команде

Кирилл Демченко

Во многих компаниях в настоящее время придерживаются принципов Agile, а DevOps практики являются их логическим продолжением. Чтобы соблюдать принципы и уменьшать Т2М необходимо выбрать подходящую методологию.
Для работы команд выбор методологии зачастую падает на SCRUM. При этом мне редко встречалась выделенная роль SCRUM-мастера.
Расскажу об опыте работы на позиции SCRUM-мастера в команде, которая совмещала выполнение инфраструктурных задач, задач по развитию ядра продукта, DevOps задач, закрытию багов и "обкатке" новых технологий. Заодно разберемся стоит ли формировать подобные команды.
Расскажу, как планировать и выбирать общую цель, чтобы всем было интересно и у участников команды не пропадала мотивация. И как не превратиться в что-то среднее между поддержкой и справочным бюро для других команд. Подумаем с какими трудностями можно столкнуться.
Поговорим как совмещать роли SM и DevOps, при этом развиваться самому и развивать команду.
Разберемся нужен ли SCRUM, SCRUM-мастер и все эти митинги или можно выбирать более свободные практики.

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

Как тестировщикам выжить в Agile

Марина Куликова

-Cruel Agile: как выжить в постоянно изменяющейся среде
-Образ мышления тестировщика в таких условиях
-Как QA может влиять на процесс

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