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

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

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

Что я узнал, протестировав 200 000 строк инфраструктурного кода

Лев Гончаров

Если мы говорим, что инфраструктура - это код, то за нас уже давно все придумано.

* Код должен быть покрыт тестами.
* Должно быть понятно, кто что и почему сделал.
* Скажем нет "write only code", т.к. в основном не пишут, а читают. Читают другие люди...
* Не надо изобретать велосипед. Уже давно есть наработанные практики/ паттерны/ подходы.
* Проекты не создаются волками-одиночками как раньше, а требуют слаженной работы команды.

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

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

Как мы уменьшили количество откатов серверных релизов на 99%

Виктор Еремченко

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

Доклад содержит, в том числе, реальные примеры использования различных инструментов и технические детали CI/CD-процесса.

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

werf — наш инструмент для CI/CD в Kubernetes

Дмитрий Столяров

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

В этом докладе я подробно расскажу о тех вызовах, с которыми сталкивается каждый при деплоее в Kubernetes, а также о нюансах, которые заметишь не сразу. Разбирая проблемы и вызовы, я не только покажу, как их можно решить, но и расскажу, как мы это реализовали в werf – нашем инструменте для CI/CD в Kubernetes.

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

Аварии помогают учиться

Алексей Кирпичников

За три последних года в Контуре произошло примерно 1000 факапов разной степени эпичности. Среди них, например, 36% были вызваны выкатыванием некачественного релиза в продакшн, а 14% — работами по обслуживанию железа в дата-центре.

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

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

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

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

Наш опыт автоматизации интеграционных тестов в изолированном окружении Docker

Дмитрий Волочаев

Я участвовал в разработке веб-приложения с использованием микросервисной архитектуры. Приложение работает в облаке Amazon Web Services и использует различные сервисы, предоставляемые облаком.

Я расскажу, как у нас устроены автоматические интеграционные тесты.

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

Для теста создается Docker-контейнер с сервисом, а также контейнеры с базой данных, Amazon AWS Localstack, HTTP-мок-сервером и Postman (а точнее, его консольная версия под названием Newman), на котором реализованы тесты. Все эти контейнеры объединяются в изолированную виртуальную сеть. В ходе тестов проверяется взаимодействие сервисом по HTTP, через очереди Amazon Simple Queue Service, взаимодействие, в котором тестируемый сервис является HTTP-клиентом, а также oauth-аутентификация. Наше приложение отправляет в браузер уведомления через SignalR. Для их тестирования пришлось разработать специальный инструмент, поскольку Postman не работает с веб-сокетами.

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

Ребрендинг и смена домена

Иван Демшин

В марте-апреле этого года RealtimeBoard стал Miro. Изменился не только дизайн, но и домен. Все прошло без остановки сервиса перед запуском нового бренда на фестивале SXSW в США. Если потенциальной аудитории будет интересно/полезно, то мы можем рассказать что было под капотом этого проекта.

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

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

Использование docker и kubernetes (k8s) для решений на платформе bitrix

Антон Тузлуков

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

Большинство известных нам проектов так или иначе обходят стороной решения для контейнеризации, и мы хотим исправить данный недостаток, показать, что bitrix-разработчикам не следует бояться таких решений, как docker и k8s. Использование k8s дает нам возможность достаточно легко тестировать наши релизы на окружении, аналогичном боевому, включая конфигурацию системного ПО, автоматический перезапуск сбойного компонента, возможность отката версии любого сервиса проекта. На примере демо-интернет-магазина мы покажем, как правильно собрать docker-контейнеры с необходимыми сервисами, преимущества использования контейнеров в жизненном цикле проекта, как k8s реализует возможность балансировки между pod'ами, что произойдет при падении pod'a c приложением, почему не следует контейнеризировать mysql в большом проекте, какие варианты существуют для реализации хранилища файлов совместного доступа.

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

Как в Айри.рф сократили SSD задержки в 61 раз

Николай Мациевский

В декабре 2018 года в Айри.рф для SSD дисков с кэшем под нагрузкой выявили большие задержки на отдачу файлов. В ходе профилирования задержек и точечных мер для их оптимизации удалось сократить число задержек на 2 порядка (с 1/1000 запросов до 1/100000 запросов).

Что мы сделали
* Внедрили метрики для отслеживания задержек по дискам. Несколько уровней метрик, включая ioping, prometheus, i/o wait, connect time.
* Выдвинули гипотезы, как улучшить производительность дисков. Снижение задержек тесно связано с утилизацией дисков.
* Пересобрали дисковые массивы, настроили файловую систему, поработали с логами, вынесли хранение в оперативную память, включили trim, изменили логику работы приложения и записи в кэш.

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

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

50 millions deployments a year – The Story of DevOps Culture at Amazon

Tomasz Stachlewski

DevOps culture is one of the most important aspects in Amazon – it helps to quickly build, develop, test and maintain services and products which are then delivered to millions users around the world. It’s about removing barriers and improving the whole processes of delivering products. In this talk we will see how and why Amazon moved from building monolithic applications to building microservices with help of DevOps, we will see what kind of tools and procedures are being used to maintain the speed of building new services and how to keep being agile when you need to do deployment every second throughout the whole year.

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

Azure DevOps - сервис для организации жизненного цикла программного продукта для любой платформы

Владимир Гусаров

Вы узнаете об эволюции и новых возможностях сервиса. Мы в деталях разберем все пять основных его компонента и сделаем упор на Azure Pipelines - гибкую систему CI/CD c неограниченными возможностями собирать что угодно и деплоить куда угодно.

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

Как навести порядок в инфраструктуре и начать спать спокойно

Денис Лысенко

Бывают такие ситуации, когда ты приходишь руководить в проект, который поднимали с нуля разработчики без навыков DevOps. Никто не знает, где находятся серверы, как они настроены, у кого спрашивать пароли, что с бэкапами. У вас есть только доступ к SSH к нескольким серверам с аптаймом больше года, на которых критические сервисы не добавлены в автозагрузку.

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

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

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

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

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

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

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

SRE-практики

Отказоустойчивый кластер Postgreql+ Patroni. Реальный опыт внедрения

Виктор Еремченко

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

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

ClickHouse и тысяча графиков

Антон Алексеев

Мы долго жили с самописным подсчётом метрик на местах. «Гибкость» этого подхода приводила нас в уныние. А потом мы попробовали ClickHouse и подсели. Так у нас появились те самые графики о работе:
* нашего CDN — от стандартных rps и трафика до выявления аномалий;
* транспорта статистики — вплоть до поиска потерь и дубликатов.

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

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

Beware of the gorilla!

Krzysztof (Chris) Daniel

In 2013, a research paper was published that described a very interesting experiment - 24 radiologists were asked to review X-ray photos of lungs, and after they completed it, they have to answer a straightforward question: "Did you notice anything extraordinary? 83% of them said "No.". The problem is that each of the photos had a large gorilla picture embedded, and eye-tracking revealed that they looked at it, but failed to notice it.

The conclusion is compelling - we can see only what we expect. Now, the question arises - business and technology are all about the anticipation of the future, but the mere act of anticipating defines what we will be able to see, and sometimes, results can surprise us in a very unpleasant way (product flop, lost time).

In this presentation, I will show how to build with high situational awareness that allows for better anticipation of the future, and therefore, allocation of your personal and professional efforts to tasks that are most important.

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

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

Безопасность Helm

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

Helm - самый популярный пакетный менеджер для Kubernetes. Из-за новизны и отсутствия устоявшейся практики эксплуатация кластера с установленным Helm-сервисом может стать одной большой черной дырой или "root ssh" к вашей инфраструктуре.

В докладе будет подробно рассмотрена архитектура Helm и даны практические рекомендации, как сделать систему максимально безопасной. Остановимся подробно на взаимодействии с репозиторием чартов, серверной части - Tiller, настройке RBAC и service accout, а также переходу на использование K8s secrets для хранения релизной информации. Рассмотрим целесообразность tillerless-дизайна и его практическую применимость, а также поддержку нескольких профилей безопасности. Сделаем Helm полностью безопасным вместе!

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

Внедрение SAST: теория vs практика

Ярослав Александров

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

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

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

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

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

Сергей Хренов

В докладе я расскажу о важности сочетания различных методик программирования и технологий проверок кода для повышения качества кода.

Я уделю внимание важной технологии, которую, к сожалению, до сих пор часто игнорируют при разработке проектов. Речь идёт о преимуществах SAST (Static Application Security Testing) для разработки безопасных и надёжных приложений. Расскажу о преимуществах и ограничениях статического анализа. Приведу фрагменты кода (с ошибками, ставшими уязвимостями) из реальных проектов. Поговорим, почему современные статические анализаторы — это совсем не то же самое, что "линтеры", про которые многие слышали ещё 15 лет тому назад.

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

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

История service mesh в Авито

Александр Лукьянченко

Расскажу о нашем пути в построении и внедрении Service mesh решения. Посмотрим какие проблемы такие решения позволяют устранить. Пройдемся по пути от внедрения Istio до написания собственного решения netramesh.

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

Логи не нужны?

Алексей Данилов

Современная разработка сильно изменилась за последние годы. Вместо монолитных приложений пришли микросервисы и функции. За ними базы данных из универсальных промышленных монстров стали более узконаправленными. Docker изменил взгляд на деплой. А изменилось ли наше представление о логах?

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

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

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

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

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

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

Развёртывание сервисов без downtime в производстве зубных протезов

Иван Голованов

В компании Adalisk (подрядчик крупнейшей в США компании по зубному протезированию Glidewell Dental) мы занимаемся автоматизацией производства зубных протезов – коронок, мостов, имплантов и т.д. Вся автоматизация производства находится в облаке и представляет собой микросервисную архитектуру.

С самого начала у нас были сложности с развёртыванием новых сервисов в продакшне. Предварительное тестирование в QA-окружении не позволяет выявить все ошибки, т.к. реальные станки есть только в PROD. Поэтому приходилось деплоить редко, большими порциями, по воскресеньям, останавливая всё производство и прогоняя тестовые заказы. Это затягивалось на целый день (а это выходной) и иногда заканчивалось откатом деплоймента (что занимало ещё несколько часов).

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

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

Инфраструктура компании как продукт

Артём Науменко

Задавали вы себе вопрос, сколько стоит ваша инфраструктура (сервера, зарплаты, внешние сервисы и тому подобное)?

* Можно ли рассматривать инфраструктуру как продукт?
* Можно и нужно ли считать ROI для инфраструктуры?
* Какие ключевые метрики выбрать для подсчета?
* Как работать над улучшением выбранных метрик?

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

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

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

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

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

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

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

What's new in RRDtool and other stories from Tobi Oetiker's GitHub repo

Tobias Oetiker

I will give a short overview of RRDtools functionality and then go into some of the newer features. In the second part of the talk, I will present some other open source tools from my GitHub repo and tell the stories that lead to their creation.

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

Serverless vs Containers - which doors to choose? How to build modern applications?

Tomasz Stachlewski

Containers and Serverless are becoming the most popular ways of building modern applications. Microservices? DevOps? It’s just easier with containers and serverless. But which one is better? What are the criteria? Which one should we use? Or maybe it depends? In this talk we will discuss the most important aspects of both. This will be heavy ‘demo’ focused session – we will build and test small applications build based on cloud (AWS) serverless services and docker containers.

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

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

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

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

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

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