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

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

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

Что делать и не делать если компанию вашего заказчика купили!

Андрей Филатов

Почти два года я проработал на проекте одного заказчика(в режиме out-staffing), за это время множество раз менялся технический топ менеджмент и у каждого нового CTO было своё видиние того как и куда должна развиваться инфраструктура и соотвественно автоматизация онной, было допущено огромнейшее количество ошибок как со стороны менеджмента так и с нашей(стороны исполнителей/делателей). Этот доклад должен быть интересен, и возможно поучителен, как непосредственным разработчикам автоматизации инфраструктуры, так и менеджерам которые занимаются управлением подобных команд так и тем менеджерам кто является decision maker'ами на высоком уровне.

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

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

KPI технической поддержки как индикатор восприятия клиентом продукта. Как и чем полезны KPI технической поддержки для анализа продукта разработчиком/администратором приложения.

Александр Соловьев

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

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

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

НТ в CI/CD большого решения

Владимир Хонин

Как не улететь при нагрузке и проходить QG быстро на примере Единого Биллинга МегаФон.

Оптимизация производительности
,
Непрерывное развертывание и деплой
,
Большие проекты/команды
,
Работа со внешним заказчиком/исполнителем
,
Нагрузочное тестирование
,
Интеграционное тестирование
Доклад принят в программу конференции

Progressive Delivery, for sleeping better at night

Себастьян Дашнер

All of us enterprise developers are doing proper Continuous Delivery, including end-to-end testing, database migrations, canarying, monitoring, and rollbacks, all in a fully automated approach, right? Most real-world projects are not quite there (yet). The reasons, or excuses, are mostly complexity, insufficient testing, discrepancies between environments, or database migrations.

This session shows how a fully-fledged pipeline approach can be implemented, using Jenkins X, for enterprise applications that run in cloud native environments. We’ll see why automated testing only allows us to fully automate our setup, how to handle data in test scenarios, and how to tackle database schema changes. We’ll have a look at typical scenarios and pitfalls and how to effectively introduce CD without writing much code or configuration ourselves. We’ll furthermore see how Progressive Delivery and automated canarying approaches limit the blast radius of our changes. Join us if you strive to improve how your projects are shipped with fast pace and predictable quality, or if you simply want to sleep better at night.

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

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-трансформация

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

Ахмед Шериев

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

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

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

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

Leon Fayer

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

В этом докладе я поделюсь историями и некоторыми решениями из собственного опыта навигации организаций через DevOps-трансформацию.

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

DevOps-трансформация. Опыт Miro

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

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

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

Приносим DevOps в DWH/BI. Проблемы и их решение

Василий Куценко

- Как развивать IT-культуру в разработке данных;
- фундаментальные проблемы в DWH/BI с т.з. DevOps;
- как принести культуру DevOps в работу с данными? Практические советы;
- в чем отличия Pipeline для работы с данными от “классических” приложений;
- какие средства автоматизации реально полезны в контексте работы с данными.

Базы данных / другое
,
Методы и техника разработки ПО
,
Архитектура данных, потоки данных, версионирование
,
Управление конфигурацией
,
Непрерывная интеграция
,
Devops / другое
,
Автоматизация разработки и тестирования
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Hadoop
,
Machine Learning
,
ETL
Доклад принят в программу конференции

Банковский DevOps для Legacy и не только. С чего начать и как тиражировать.

Игорь Шваков

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

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

Применение DevOps в разработке сложного кросс-платформенного фреймворка – платформы 1С:Предприятие

Петр Грибанов

1С производит инструменты для быстрой разработки кросс-платформенных бизнес-приложений и рантайм для их работы (общее название – платформа «1С:Предприятие»). Бизнес-софт, разработанный на нашей платформе, работает на Windows, Linux, macOS, Android, iOS, в браузерах, использует СУБД MS SQL, Oracle, IBM DB2, PostgreSQL.
Наш софт используют 5 миллионов конечных пользователей в 1.5 миллионах организаций.
Исходники платформы «1С:Предприятие» - более 10 млн. строк кода (C++, Java, JavaScript).
С одной стороны, мы производим среду разработки бизнес-софта, и это напоминает Visual Studio или Eclipse. С другой стороны, мы производим рантайм для бизнес-софта, и это продукт типа .NET Framework или Java runtime. Одновременно в работе у нас находится до 6 версий продукта, включая как уже выпущенные и поддерживаемые версии, так и новые, пока не пошедшие в релиз.
Расскажем об особенностях поддержки цикла разработки большого тиражного кросс-платформенного продукта, об одновременном фиксе ошибок в нескольких версиях, о стратегиях тестирования (функционального и нагрузочного).

JavaScript
,
Фреймворки
,
Java
,
C/C++
,
Организация доступа к базам данных, ORM, собственные драйвера
,
Архитектурные паттерны
,
Отказоустойчивость
,
Методы и техника разработки ПО
,
Управление конфигурацией
,
Непрерывная интеграция
,
Совместная работа, система контроля версий, организация веток
,
Автоматизация разработки и тестирования
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Большие проекты/команды
,
Функциональное тестирование
,
Нагрузочное тестирование
,
Автоматизация тестирования
,
Интеграционное тестирование
,
Юнит-тестирование
,
Профилирование и отладка кода
,
Тестирование фронтенда
,
Кросплатформенная разработка
Доклад принят в программу конференции

DevOps: практика без теории. История внедрения в отдельно взятом банке.

Александр Рыгалов

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

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

Devops / другое
,
Модели руководства
,
Корпоративная культура и мотивация
,
Работа со внешним заказчиком/исполнителем
,
Legacy системы, жизненный цикл продуктов
,
Agile-практики в госкомпаниях, банках, предприятиях
Программный комитет ещё не принял решения по этому докладу

Поливать 300 лет, или Почему нельзя сделать быструю технологическую трансформацию

Максим Ефимов

- Почему у нас не будет 30 команд уровня “элит перформерс” к концу года.
- Можно ли вообще эффективно воздействовать на майндсет человека, лимит принятия изменений.
- Почему нам так важно сопровождать трансформацию соответствующим информационным полем, а не только внедрять инженерные практики.
- Почему пайплайн с лид-таймом в 1 час бесполезен без изменения производственного процесса команды.
- Почему мы должны помогать команде не только с инженерными практиками, но и с любыми изменениями, важными для продукта.
- Почему нет универсального пути трансформации команды и как важна постоянная обратная связь.
- Почему в любом случае вам следует поставить для себя амбициозную, почти недостижимую цель, например, стать Элит перформером до конца года.

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

От релиза до FastTrack

Евгений Фоменко

· Внедрение в условиях масштабной архитектурной трансформации.
· Высокоскоростное внедрение изменений в распределенной инфраструктуре компании.
· Способы достижения быстрого цикла внедрения.
· Объединенные кросс-функциональные команды как целевая схема взаимодействия с производством вендора.
· Качество и автоматизация тестирования в условиях непрерывного внедрения.
· Влияние непрерывного развертывания на эксплуатационные показатели.
· Уровни зрелости продуктов и требования к увеличению зрелости.
· Участие заказчика в командах разработки и внедрения.
· Роль эксплуатации в командах FastTrack.



Непрерывное развертывание и деплой
,
Менеджмент в эксплуатации
,
Непрерывная интеграция
,
Devops / другое
,
Автоматизация разработки и тестирования
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Большие проекты/команды
,
Модели руководства
,
Корпоративная культура и мотивация
,
Поиск и развитие команды
,
Выбор стратегии долгосрочного развития, KPI
,
Работа со внешним заказчиком/исполнителем
,
Продуктовая разработка
,
Антикризисный менеджмент
,
Enterprise-системы
Программный комитет ещё не принял решения по этому докладу

DevOps в заказной разработке. Путь к Continuous Deployment в биллинге у телеком-оператора

Антон Хлевицкий

Поговорим о том:
* как мы живем в биллинге с заказной разработкой от нескольких поставщиков ПО;
* как выполняем сценарии развертывания и управления высоконагруженных биллинговых приложений на базе Jenkins, Ansible, Git, сохраняя требуемый уровень отказоустойчивости;
* как нам удалось построить единый пайплайн управления циклом доставки для всех продуктов по средствам Active Choice Parameter, Shared Library и Scripted Pipeline Jenkins;
* каким образом осуществляется управление сервисами после их установки;
* как обеспечивается катастрофоустойчивость.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Automation tools don’t fix bad processes

Al

So often, organizations working to adopt DevOps initially focus on selecting tools and manipulating their choices to automate bad practices hoping to maximize efficiency. Automation is the easy part. But without culture transformation and process optimization, an organization will never realize their true potential. Optimizing the system as a whole – a system made up of people, processes and tools - means reviewing, questioning and potentially changing how things are across the entire lifecycle. During this meetup, let’s collaborate on techniques to change culture, the value of mapping the value stream, and the automation tools available to help.

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

IBM Cloud Garage method или как правильно готовить DevOps

Екатерина Николаевна Кривцова

Миграцию приложений в облако невозможно представить без изменений в организации, культуре и самого процесса разработки.
IBM Garage for Cloud это системный подход позволяющий решать такие проблемы, как множество человеческих ошибок, постоянный поиск виноватого, простои во время обновления, скорость выхода новой версии. Метод представляет собой набор конкретных практик, поделённых на семь категорий, охватывающих полный цикл трансформации в облако. Данный метод был разработан руководствуясь лучшими международными практиками, как при построении IBM Cloud, так и при работе с крупнейшими мировыми заказчиками.
Использование метода IBM Garage for Cloud позволит грамотно выстроить DevOps процессы, сократить время выхода в продуктив и количество человеческих ошибок. Построить мосты между смежными подразделениями, поменять мировоззрение людей и их отношение к задачам. Повысить эффективность работы команды в целом.
В докладе будет рассмотрено использование метода IBM Garage for Cloud в одном из крупных российских банков.

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

Как стать кросс-функциональной командой

Михаил Бижан

В жизни (почти) каждого ИТ-специалиста рано или поздно наступает момент, когда он попадает в маленькую agile/devops-команду, которая должна раз в 2 недели поставлять клиенту "ценность". Иногда эта метаморфоза случается даже без смены работы - это называют digital-трансформацией. И тогда наш (почти) каждый ИТ-специалист обычно нервно усмехается и говорит: "Камон, ребята, вдесятером за две недели придумать, разработать, протестировать и внедрить новый функционал в высоконагруженный сервис? Да вы издеваетесь!".

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

Распределенные системы
,
Менеджмент в эксплуатации
,
Devops / другое
,
Продуктовая разработка
,
Управление / другое
,
Enterprise-системы
Доклад принят в программу конференции

SRE-практики

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

Матвей Кукуй

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

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

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

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

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

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

Под капотом хранилища большого облака, или отказ Шрёдингера

Артемий Капитула

Публичные облака — это и высокие нагрузки, и большая ответственность. Какое бы решение ни было использовано для построения облака, в его основе всегда минимум один компонент, от которого зависят все остальные — блочное хранилище.
Мы расскажем, как из источника проблем превратили блочный сторадж, поверх которого работают сервисы Compute Cloud, в один из самых стабильных компонентов платформы Mail.ru Cloud Solutions. Это блочное хранилище используется большинством компонентов IaaS и PaaS, включая наши сервисы, популярные в DevOps-практике: базы данных Mail.ru Cloud Databases и кластеры Kubernetes в облаке Mail.ru Cloud Containers.
А еще мы расскажем об одном из случаев, когда расширенная диагностика и детализированный мониторинг помогли определить сложную и непонятную проблему, возникшую у клиента.

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

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

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

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

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

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

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

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

SDLC & Compliance. Через тернии в продакшн

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

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

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

Большие проекты/команды
,
Управление изменениями, управление требованиями
,
Enterprise-системы
Доклад принят в программу конференции

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

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

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

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

Как техническими средствами решить проблему «все работает, а пользователь недоволен»

Даниил Тихомиров

В докладе показывается эволюция съема мониторинговых данных от систем до e2e сервисов. В высоконагруженных системах с большим географическим распределением, которые обслуживает распределенная команда из 800+ человек, возникают проблемы когда операционные системы, базы данных, сервера приложений работают, но в итоге сервис, основанный на нескольких системах, не оказывается и пользователь недоволен итоговой доступностью системы. Команды ответственные за системы говорят «у нас все хорошо и все работает», пользователь говорит «ничего не работает». Мы покажем как начиная от мониторингов отдельно взятых систем, был пройден путь мониторинг серверов, приложений до мониторинга сервиса глазами пользователя. Как на эти показатели KQI начали ориентироваться все технические специалисты, заказчики от бизнеса и вендор поставляющий решение. В качестве визуального средства мониторинга используется grafana, в ней же построена математическая модель с прогнозом по показателям с итоговым расчетом доступности, ориентируясь на SLO и SLI

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

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

Будущее 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 / другое
Доклад принят в программу конференции

Зачем мы разработали Kubernetes оператор и какие уроки из этого вынесли

Григорий Михалкин

Вы хотите сделать свой Kubernetes чуточку умнее? Научить его правильно восстанавливать сервисы после сбоя, производить масштабирование или редеплой сервисов на определенные события. Мы прошли долгий и сложный путь от разработки kubernetes оператора, до его деплоя и применения, и мы хотим поделиться нашим опытом.

В докладе ответим на следующие вопросы:
- Что такое оператор и для чего он нужен
- Наш use case. Почему мы решили разработать собственный оператор.
- Проблемы с которыми мы столкнулись при разработке и деплое
- Зачем и в каких ситуациях стоит разрабатывать собственный оператор. Какие готовые решения уже существуют.

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

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

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

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

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

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

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

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

Инфраструктура для разработчиков на примере облака Tionix

Игошин Иван Анатольевич

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

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

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

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

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

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

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

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

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

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

Как мы при выпуске софта начали использовать SCA

Дарья Орешкина

Мы узнали про новую технологию проверки open source с помощью инструмента класса software composition analysis, решили проверить на себе. Технически все было просто - развертывание и эксплуатация инструмента затруднений не вызывали, тем не менее, простым этот проект не назовешь... Реальный опыт и неожиданные вопросы на пути к безопасной разработке.

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

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

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

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

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

Заделываем дыры в кластере Kubernetes

Павел Селиванов

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

Я расскажу о некоторых направлениях атаки на кластер Kubernetes и о способах защиты кластера от них. Расшифрую PSP, RBAC, Resource Quota и Limit Range. И покажу, чем грозит незнание этих терминов.

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

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

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

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

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

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

Как внедрить DevSecOps в легаси-проект

Александр Сеничкин

Доклад будет посвящен переходу от практики DevOps к DevSecOps в больших проектах.

С ростом размера проекта и размера команды всё острее встают вопросы обеспечения качества и надёжности разрабатываемого программного кода. Чем быстрее ошибка найдена, тем дешевле её устранение. И тем более важно устранять потенциальные уязвимости, пока они не проявили себя и не нанесли финансовый/репутационный вред. Встаёт вопрос, как внедрить SAST (статический анализ кода) в уже существующий процесс разработки. Разберём этапы внедрения, типовые ошибки, способы интеграции с CI и другие релевантные темы.

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

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

Extending MPLS Domain into AWS

Тарас Котов

Развёртывание и поддержка сетевой инфраструктуры для энтерпрайз компаний в AWS достаточна проста. Но что, если это телекоммуникационная компания, имеющая свою опорную IP/MPLS сеть, точки присутствия в десятках стран и желающая идти в Публичные Облака? Я хочу поделиться с вами опытом построения такой инфраструктуры.

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

Функции как сервис для Private Cloud

Дмитрий Змитрачёнок

Представьте, что у вас своя платформа виртуализации, и вам очень нужно реализовать аналог AWS Lambda.

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

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

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

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

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

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

Hashicorp vault как сервис

Юрий

* Как правильно готовить волт для разнообразных команд
* Доклад будет интересен средним и крупным команиям которые хотят внедрить vault и убрать секреты из общедоступных мест

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

Webhook на микросервисах для актуализации зависимостей между 100+ репозиториями

Дмитрий Марков

В своём докладе я хочу рассказать о том, как мы в компании ООО "РДП.РУ" организовали работу webhook-приложения в связке с GitLab с использованием микросервисного подхода для поддержания актуального состояния зависимостей между 100+ репозиториями. Какие встретили трудности и о том, как мы организовали end-to-end-тестирование webhook-приложения и GitLab, используя GitLab CI.

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

Атоматизированная система полного цикла эксплуатации, мониторинга и анализа работоспособности высоконагруженного ПО

Игорь Мартынов

* Построение ПО, использование статического анализатора кода.
* Регрессионное тестирование.
* Тестирование стабильности в лаборатории, сбор и анализ метрик.
* Автоматическая доставка и настройка ПО.
* Мониторинг и анализ метрик во время эксплуатации.

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

Использование Hekiti для организации распределенного хранилища в kubernetes

Жуков Станислав

Использование Hekiti для предоставления интерфейса управления томами GlusterFS кластеру kubernetes

Heketi — это открытый проект, предназначенный для предоставления сторонним приложениям RESTful интерфейса управления жизненным циклом дисков в GlusterFS

Persistent storage - claims для хранения логов в кластере под управлением Rancher 2.0

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

Строим надежную сеть

Анастасия Фиделина
Анастасия Фиделина

От простого к надежному. Как строится избыточность и отказоустойчивость в сети.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В программе:

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

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

Docker Swarm в проде. Особенности простоты

Сергей Кочубиевский

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

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

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

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

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

Микросервисы, SOA
,
Архитектурные паттерны
,
Отказоустойчивость
,
Распределенные системы
,
Архитектуры / другое
Доклад принят в программу конференции

Hashicorp vault как сервис

Юрий

* Как правильно готовить волт для разнообразных команд
* Доклад будет интересен средним и крупным команиям которые хотят внедрить vault и убрать секреты из общедоступных мест

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

Опять витаем в облаках: Vault, Service Mesh, OpenTracing, SSO

Алексей Вахов

Более 3-х лет назад, упав под растущим трафиком, мы перевезли наши приложения в публичное OpenStack облако. Так началась наша дружба с Terraform, Ansible, Docker, Consul, Nomad, Prometheus и прочими. Про опыт работы с этими инструментами мы стараемся периодически рассказывать.

В этом году мы внедрили Vault для управления секретами и токенами, централизованное логирование, Service Mesh, OpenTracing, тотальный SSO для всех внутренних приложений, почти отказались от Ansible, экспериментируем с автоскейлингом.

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

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

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

Что скрывается за вашим мобильным банкингом?!

Олег Миронов

Расскажу про наш опыт в Ак Барс Цифровые Технологии построения платформы для онлайн-банкинга, позволяющей выводить новый функционал с минимальным циклом T2M.
Поговорим о микросервисной архитектуре, вызовах для SRE при работе с микросервисами в рамках комплексной enterprise-системы, выбранных решениях для деплоя, мониторинга, интеграционного взаимодействия микросервисов.
Подробнее остановимся на конфигурации CI/CD пайплайна в условиях требований PCI DSS и на преимуществах платформы OpenShift как основы приватного облака в банковском инфраструктурном ландшафте.

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

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

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

Мы живём в сложное микросервисное время. Нельзя просто взять и написать код. От современного разработчика требуется понимание и использование инструментов, которые выходят за рамки кода, отвечающего за бизнес-функционал. Service discovery, centralized configuration, distributed tracing, circuit breaking, API gateway — все эти штуки из удела высшего общества давно превратились в обыденные механизмы, без которых не построить современное приложение. Одно хорошо — обо всём этом уже позаботились другие люди и приготовили для нас замечательные готовые решения. Казалось бы, добавил новую библиотечку в зависимости — и готово, однако всё не так просто — обрастая функциональностью, мы теряем легковесность. Всё это сопровождается постоянным усложнением систем и новыми функциональными хотелками.

В докладе расскажу про способ, как мы в Леруа Мерлен справляемся с ожирением наших микросервисов.

Микросервисы, SOA
Доклад принят в программу конференции

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

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

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

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

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

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

Самообразованец или нет? Когда идти учить других?

Фарида Рословец

Высшее образование — это фактор, который позволяет войти в систему. Это игра и спектакль.
У нас у всех есть старт, в виде "корочки", а далее следует дикая конкуренция, давление снизу, сбоку и сверху. Только тот, кто учится без остановки, получает свое место под солнцем.

Требования мира мы чувствуем ежедневно. Если мы не можем соответствовать, мы либо впадаем в стереотипы и чувствуем себя легче, либо страдаем, уничижая себя, либо тихо пашем.
Скорость получаемой информации и ее объемы растут, появляются новые профессии, требования к навыкам сотрудника повышаются.

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

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

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

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

Продажи как непрерывный процесс, интегрированный в процесс разработки продукта

Артем Черневский

Гибкость и скорость изменения современных проектов разработки программных продуктов давно привела к тому, что стандартный цикл "Анализ-Продажа-СоставлениеТЗ- Разработка-Внедрение-Техническая поддержка" уже не актуален. Продажи осуществляются не только на стадии заключения договора, но и на каждом этапе уточнения требований и обновления плана разработки продукта. Независимо от того, реализуется ли проект внутренней командой или аутсорсинговой командой разработки - нужно постоянно "продавать" компетенцию и вовлеченность ИТ-специалистов, сложность решаемых технических проблем, необходимость управления техническим долгом. И роль классического продавца здесь во многом уступает роли технического руководителя проекта - постоянно осуществляющего допродажи и сопродажи дополнительных работ. На докладе совместно обсудим вопросы органического развития навыков "технических продаж" у технарей. Успехи и неуспехи таких подходов, лучшие практики из опыта автора доклада по построению "технических продаж" в крупных ИТ-вендорах, внутреннних командах разработки и аусторсинговых компаниях-разработчиках ПО работающих на глобальный рынок. После доклада Вы сможете оценить потенциал "технических продаж" для Вашей компании, а также наметить основные шаги для развития такого подхода.

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

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

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

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

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