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

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

SRE-практики

Как удовлетворить SRE или сервис на Go в контейнере за 5 минут

Игорь Должиков

За 2 года работы в SRE с использованием языка Go приходилось сталкиваться с множеством проблем, как помочь разработчикам быстро и оптимально создавать микросервис. При этом соблюсти все требования, нюансы работы сервиса в контейнере, использования конфигурации, тестирования, исполнения и доставки кода в различные среды (Docker, Kubernetes, локально или в кластер).

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

Будут рассмотрены вопросы:
- Генерация сервиса с выбором необходимых модулей.
- Наиболее яркие решения в виде примеров кода.
- Способы тестирования и валидации кода.
- Доставка и исполнение кода в контейнере локально и в кластере.
- Структура модулей сервиса из лучших практик.
- Вежливое закрытие сервиса (graceful shutdown).
- И многое другое из бесценного опыта разработки в контейнерах.

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

Бэкапы в Kubernetes

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

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

В рамках данного доклада мы расскажем о том:
* почему мы используем наше собственное решение;
* как нами осуществляется резервное копирование Etcd Kubernetes;
* как мы бэкапим такие сервисы как: MySQL, MongoDB, Redis и др;
* где хранится и как бэкапится код приложений;
* где хранить сами резервные копии;
* как использовать собранные бэкапы:
** для восстановления определённого сервиса,
** для восстановления всего k8s.

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

MySQL on the cloud, from virtual machines to serverless options

Renato Losio

From AWS to Google Cloud, the major cloud providers offer different options to run a MySQL or a MySQL compatible database on the cloud. You can spin up virtual machines and configure your own cluster or rely on managed services with the ability to modify or scale vertically a database with the click of a button. From sharding to backups, from provisioning to monitoring, the talk will cover the operational costs of running relational databases on the cloud and how to integrate them in your infrastructure as a code. Can serverless databases be the answer?

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

Базовая гигиена системы мониторинга или как снизить количество событий

Антон Касимов

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

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

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



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

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

SAST, борьба с потенциальными уязвимостями

Андрей Карпов

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

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

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

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

Защищаем кластер Kubernetes

Нарек Татевосян

В 2018 году компания Bi.Zone провела соревнование Capture the Flag для специалистов по ИБ, где участвовало более 1000 команд из 90 стран мира. Все онлайн-задания работали в кластере kubernetes, и нам пришлось серьезно потрудиться над его безопасностью.

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

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

Зачем нужны стандарты кодирования и как их применять

Максим Стефанов

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

Стандарты кодирования - благо или вред? Попробуем разобраться.

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

Нестандартный способ контроля уязвимостей инфраструктуры

Николай Самосват

* Хотите знать, какие у вас в инфраструктуре есть уязвимости, но у вас нет ресурсов на разворачивание и сопровождение сложных сканеров безопасности?
* Нет понимания, какие уязвимости необходимо патчить в первую очередь, а какие риски можно принять?
* Нужны регулярные отчеты об актуальных для вашей специфики уязвимостях и эксплоитах?

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

Для этого вам понадобится лишь уже существующая у вас система мониторинга Zabbix и агрегатор уязвимостей Vulners.

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

Преимущества эксплуатации Kerberos + OpenLdap в большом продакшене

Андрей Бугрин
Наталия Наумова (Jacky)

Наш доклад посвящён методам централизации доступа к инфраструктурам посредством использования Keberos и OpenLdap. Мы рассмотрим основные технологии, реализованные продукты.

Основные темы:
- создание централизованной системы аутентификации и авторизации
- защищённая доменная система, основные реализации (Microsoft AD, Samba, FreeIPA, JSS)
- SSO доступ к сервисам, интеграция
- создание юзер-менеджмента

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

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

What is DevSecOps? Increasing more protected applications

Stacey Jenkins, M. Psych

In today’s world of CYBER-RISK and CYBER-SECURITY, we sometimes forget about the individuals, or dare I say SUSPECTS behind the BREACH, ATTACH or THEFT. We neglect these individuals until it is too late, and the damage has been done. Individuals such as:

EDWARD J. SNOWDEN!

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

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

.NET на Linux, а DevOps на коне

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

В своем докладе я расскажу на примере реализованного проекта для крупного заказчика с более 100 000 конечных пользователей, как играючи доставлять проект в rpm, используя TFS, Puppet, Linux .NET core, и о том, как поддерживать версионирование БД проекта, если разработка впервые слышит слова Postgres и Flyway, а дедлайн послезавтра. О сломанных костылях и работающих решениях.

Расскажу о том, как мотивировать .NET-разработчиков отказаться от Windows и смузи в пользу Puppet и Linux, и что делать, когда ты девопс и обслуживать винду в продакшне нет ни сил, ни желания, да и ресурсы не резиновые. О методах разрешения идеологических конфликтов.

Как готовят TFS в Золотой Короне. Расскажу о практиках использования TFS в существующих проектах. Как интегрированы с Docker, о Web deploy, тестировании и CI.

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

Эффективная разработка и сопровождение Ansible-ролей

Александр Харкевич

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

Будет показан механизм разработки как публичных ролей (Ansible Galaxy = Ansible role + GitHub + Travis CI),
так и публичных ролей но с тестовыми прогонами в приватной инфраструктуре (Ansible Galaxy = Ansible role + GitHub + GitLab CI for GitHub).

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

Как мы пришли к Continuous Delivery. Шишки, грабли, планы на будущее

Андрей Ермаков
Юрий Трегубов

Заказчик: "Давайте поставлять фичи каждый день, и без ручного регресс-тестирования?".
Команда: "А давайте!".

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

Что спустя полгода?
Каждый день изменения катятся на продакшн, разработчики пишут тесты, а тестировщики предлагают, как улучшить покрытие. Достигли ли Святого Грааля continuous delivery? Нет, еще в пути.

Расскажем, как живется команде из 16 разработчиков, 3 тестировщиков и 2.5 девопсов. Грабли, шишки, успехи, и какие ставим цели сейчас.

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

Based on a true story - building a PCI compliant cloud application

David O'Brien

You deal with credit card information? Then you have heard the dreaded word - PCI. But what does this actually mean? What do we need to do and what horrendous things do we have to do to make our workload PCI compliant?

This is not your regular true crime story. This is the story of an IT consultant navigating the waters of PCI compliance while making sure that his customer is successful in hosting their business critical application on Microsoft Azure. Come to this session to find out, first hand, what hurdles we had to take to achieve full PCI compliance. What Azure services were used? Which ones did we want to use, but couldn’t? What grotesque workarounds did we have to build to make the application stable? This is a no-holds-barred tale of deploying a real PCI compliant application onto Azure services with lots of drawings and demos.

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

Доставляем в Kubernetes. Непрерывно и по-своему

Евгений Дехтярёв

Два года назад нам не хватило готового решения для доставки приложений в Kubernetes, и мы придумали собственное. Взглянем на историю развития PaaS в 2ГИС, сравнив его со стандартным путём доставки приложений и инфраструктуры на бой. Вспомним, каким был Helm в конце 2016 года. И в итоге увидим, зачем нам понадобился свой способ доставки в Kubernetes.

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

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

Делаем CI для мобильного SDK с нуля

Артем Никитин

В конце 2017 года наша команда начала работу над новым мобильным SDK, используя как самые последние опенсорс-технологии, так и самые последние внутренние разработки. И, конечно, мы хотели исправить и те недочеты, которые видели в CI наших предыдущих продуктов.

Доклад о том, как мы подходили к построению CI для нашего нового продукта, что попробовали, что выбрали, от чего отказались и что оставили на потом.

Список ключевых слов: Jenkins, AWS, Serverless, Docker, Mac mini, git, repo, Gerrit, Java, Go.

Работа с Amazon
,
Критерии выбора технологий для проекта
,
Технологии виртуализации и контейнеризации
,
Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Непрерывная интеграция
,
Devops / другое
,
Автоматизация тестирования
,
Интеграционное тестирование
,
Юнит-тестирование
,
Инфраструктура как сервис (IaaS), платформы как сервис (PaaS)
,
Особенности процессов разработки и тестирования мобильного ПО
,
Кросплатформенная разработка
,
GO
Программный комитет ещё не принял решения по этому докладу

Metrics! Metrics! Metrics!

David O'Brien

Metrics are important to understand what is happening in your environment and the health of your application. Microsoft Azure has a powerful and easy way of surfacing metrics for all kinds of workloads and we will see how we can leverage all of them.

3AM, on a Sunday, you should be asleep, but instead you are woken up by a text claiming that “the super-critical app is timing out again”. What is happening? Where is it slow? Why is it slow? In this session we will discover the services that Microsoft Azure offers to customers to collect logs and specifically metrics of our cloud workloads. We will understand what metrics we should be interested in when running on a cloud platform and how to get to those metrics. We will learn about open-source tools and will definitely build some nice dashboards. In the end attendees will have the knowledge to start building their own metrics dashboards and next time they are woken up at 3AM they will be able to quickly understand what is happening.

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

Communicating your technology so that everyone can understand: Using FBI Negotiation & Active Listening Skills

Stacey Jenkins, M. Psych

You Ever hear a Client or Costumer say “Repeat that so, I can understand what you just said?" Well here is a way: Connect & Inform the World to Understand the Essences of Technological, by Translating it Into Common Terms.

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

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

Главное не качество, а количество!

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

I truly believe that quality is not what programmers should care about. They must care only about speed—close tasks as soon as possible— which means make money. Won't this attitude ruin the project and turn the code base into a mess? Yes, it will. If the project doesn't care about its quality either. There must be a permanent conflict between a project and its programmers: 1) the project must be configured to reject anything that lowers the quality of its artifacts and 2) programmers must be interested in making changes to those artifacts. The project cares about the quality, the programmers care about fast delivery of modifications.

I wrote about this: http://www.yegor256.com/2018/03/06/speed-vs-quality.html

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

Canary Releases with Prometheus

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

Будет рассказано про технику развертывания версий с тестированием на "проде". Данный подход набирает популяность у Евангелистов кубернетиса. Здесь же будет рассказано про применении этой техники для Java микросервисов с использованием Prometheus. Будут показаны примеры, а также рассматрены ограничения. плюсы и минусы.

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

Кто живет на облаках, или что такое cloud-native infrastructure

Антон (Энт) Вайс

Облачные инфраструктуры пару лет как перестали быть инновацией. Сегодня вопрос уже не : “Лезть ли нам на облако?”, а “Как правильно жить в облаках?”.

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

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

Именно это мы и обсудим:
* Что такое cloud-native infrastructure.
* Что такое cloud-native applications.
* Какие проекты входят в CNCF и почему.
* Зачем нужен service mesh.
* Чем "infrastructure as software" отличается от "infrastructure as code".
* Как все это проверять.
* Как все это связано с ДевОпс.

API
,
Микросервисы, SOA
,
Архитектурные паттерны
,
Распределенные системы
,
Логирование и мониторинг
,
Технологии виртуализации и контейнеризации
,
Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Инфраструктура как сервис (IaaS), платформы как сервис (PaaS)
,
Web-scale IT / другое
Программный комитет ещё не принял решения по этому докладу

Реальные юзкейсы применения serverless-подхода для решения инфраструктурных задач

Артем Никитин

В докладе мы рассмотрим применение подхода serverless на примере AWS Lambda для решения различных практических задач, связанных с инфраструктурой.

Примеры задач, которые мы решаем Lambda'ой:
- Поддержание AMI в обновленном состоянии (решение похоже на Packer от HashiCorp, но с нашей спецификой).
- Отправка фидбэка от CI в код ревью.
- Выключение неиспользуемых EC2-инстансов.
- Микросервис для сбора метрик и др.

В докладе будет рассмотрено как практическое применение AWS Lambda, так и затронуты вопросы тестирования, деплоя и мониторинга serverless-приложений.

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

DevOps-cага "о шаблонном микросервисе": как дать возможность разработчикам самостоятельно выводить в прод новые сервисы за один час и ничего при этом не забывать

Максим Вихарев

В начале мы мигрировали наши микросервисы в Kubernetes. Со временем научились молниеносно выводить в прод новые микросервисы с помощью стандартизации и фиксирования в коде всех договоренностей между админами и разработчиками. Получая из коробки ci/cd. Ничего не забывая. Накапливая опыт эксплуатации и сразу распространяя его на все приложения. Как, почему и зачем..

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

Доклад будет подан с позиции проактивного devops-инженера и разработчика. Мы рассмотрим весь цикл существования (микро)сервиса на примере python-сервиса, начиная от создания проекта и заканчивая эксплуатацией/мониторингом в проде. Осветим все связанные и показавшие эффективность подходы/ процессы/инструменты, которые используем в данный момент.

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

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

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

Рефакторинг эксплуатации

Владимир Буянов

Что делать, когда приходишь на проект и видишь, что степень его автоматизации и количество костылей в его поддержке можно описать словами “Деплоить - это просто как ездить на велосипеде, который горит. И ты горишь, и всё горит, и ты в аду”, а все инфраструктурные инструменты делятся на 2 типа: уже EOL и “написаны на коленке и никогда и не поддерживались”.

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



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

Я у мамы инженер

Кирилл Сотников

System Engineer, Site Reliability Engineer, DevOps Engineer, Release Engineer, WTF Engineer: на рынке довольно много вакансий, в которых присутствует слово инженер, но, кажется, мы стали забывать, что же это слово значит, что значит быть инженером, а не оператором Kubernetes.

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

DevOps в Альфа-Банке

Антон Исанин

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

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

Как можно организовать pipeline по доставке изменений с учётом требований всех "заинтересованных лиц" и как сделать так, чтобы это работало. Какие продуктовые команды оказались успешными в плане DevOps, а какие нет, и почему у них не получилось.

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

Кто сказал, что нам нужен DevOps?

Владислав Андреев

Нередко кастомеру или product owner’у позиция DevOps в проекте видится как налог на разработку. Есть роль, у нее есть определенные функции, но со стороны бизнеса непонятно, какую пользу приносит этот загадочный человек под тегом DevOps и зачем он вообще нужен в текущем штате инженеров.

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

В докладе постараюсь ответить на вопрос - зачем и когда в проекте нужен DevOps и какую пользу несет эта роль для бизнеса.

* Кто такой DevOps.
* Админ и DevOps - это одно и то же?
* Нужна ли эта роль в вашем проекте.
* Какие проблемы решает DevOps.
* Культура DevOps в команде и на что она влияет.
* Зачем нам DevOps, и без него все работает неплохо.

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

Ops без Dev. Или что делать, когда уже поздно?

Илья Стекольников

Задача DevOps — сделать процесс разработки и поставки программного обеспечения согласованным с эксплуатацией. Но что делать, когда разработка живет отдельно от эксплуатации уже долгое время? Как вернуть все на рельсы стабильности?

- Как начать переход от классической эксплуатации инфраструктуры к DevOps (что есть и чего, как правило, нет).
- Как должна происходит та самая "DevOps-трансформация" (утопия DevOps).
- Реальность воплощения (с чем столкнулись мы, и наверняка столкнетесь и вы).
- Инструментарий (процессы, технологии и прочие средства).
- Роли в DevOps (кто, кому и что должен).
- Что нас ждет (что еще не решено).

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

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

Почему надежные дата-центры не надежны, или как выбирать на берегу?

Игорь Мызгин

В последнее время есть традиция, что почти каждую пятницу в ФБ идут очередные войны вида "ААА!!!111адинадинадин хостинг-провайдер XXXXXX упал! Мы теряем миллионы! Срочно спасите-помогите!!!".

В данном докладе я постараюсь систематизировать ответы на ряд вопросов:
1) какие хостинг-провайдеры бывают;
2) чем они отличаются;
3) какие "типовые" маркетинговые уловки есть в самопиаре большинства провайдеров;
4) как сравнить провайдеров до того, как вы начнете с ними работать (два переезда равны одному пожару - это и про миграцию с хостера на хостера тоже верно);
5) что такое Tier 2-3-4 и, вообще, какие сертификации / внешние рейтинги / независимые оценки "качества" для хостеров бывают?
6) что важно и не важно и на что посмотреть ДО, чтобы потом не задавать вопросов вида "Но ведь нам же обещали в договоре два независимых дата-центра, почему же мы лежим?" в паблике ФБ.

По опыту предыдущих докладов - половина времени будет посвящена слайдам, вторая половина - ответам на вопросы аудитории.

Работа со внешним заказчиком/исполнителем
,
Работа с зарубежным заказчиком/рынком
,
Инфраструктура как сервис (IaaS), платформы как сервис (PaaS)
Программный комитет ещё не принял решения по этому докладу

Где застревает софт? Применение измерений и системного анализа для выявления узких мест в конвейере доставки ПО

Антон (Энт) Вайс

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

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

ДевОпс зиждется на системном анализе и измерениях.

На лекции мы рассмотрим все части конвейера доставки ПО и обсудим:
* что измерять,
* как измерять,
* как использовать системный анализ для выявления этих узких мест,
* и как это поможет вам в оптимизации сроков доставки ценности вашей IT-организации.

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

Revenue Based Monitoring

Василий Озеров

Все IT-компании давно пришли к тому, что необходимо собирать как много больше метрик из происходящих вокруг процессов. Я говорю не только о технических показателях, таких как количество запросов и cpu usage, но и о бизнес-метриках, таких как revenue, retention, quality и прочих.

К сожалению, очень часто эти метрики анализируются отдельно друг от друга, и никто не пытается их соотнести. Знаете ли вы, сколько денег вам приносит веб-сервер? Как увидеть проблемы, когда все системы технического мониторинга горят зеленым? Сколько денег теряет бизнес, когда база данных загружена на 90%? А на 50%?

Если интересно узнать про наш опыт - приходите, будет жарко!

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

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

Kubernetes для тех, кому за 30

Николай Сивко

Про kubernetes сейчас говорят часто, громко и восхищенно.

Мы в okmeter.io в какой-то момент поняли, что нам тоже нужен k8s в production, хотя у нас нет даже CI/CD, но есть задача делить общий пул серверов между приложениями и достаточно легко добавлять мощности в кластер. При этом был ряд обстоятельств, которые усложняли внедрение k8s:
* мы очень заботимся об отказоустойчивости (мы не притаскиваем новые технологии в prod, пока не разберемся в них на достаточном уровне);
* у нас есть сервисы со временем ответа < 10ms;
* у нас очень мало человеческих ресурсов на эту задачу (узнать 10 новых терминов ОК, 50 - уже нет).

В докладе я расскажу, как нам все-таки удалось решить эту задачу:
* HA k8s на bare metal из зубочисток и синей изоленты.
* Сеть k8s: как мы чуть не внедрили аппаратную виртуализацию сети для подов (sriov), но потом успокоились и взяли flannel host-gw. Как обеспечивали связность k8s кластера и соседних серверов.
* Почему мы не используем k8s service network, а делаем headless-сервисы и используем envoy+dns discovery везде, где только можно.
* Как мы готовили наши НЕ cloud native-приложения работать в k8s.
* Неочевидные проблемы в ограничении ресурсов.

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

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

Внутренняя архитектура Кубернетеса для администраторов

Ben Tyler

Вы - сисадмин, SRE или devops-инженер. Ваша компания только что решила эксплуатировать Кубернетес, и теперь вам придется поддерживать эту систему всерьез. Большинство ресурсов про Кубернетес описывают его как фантастическую технологию, данную нам волшебниками из Гугла. Возможно, что да — штука крутая и полезная, принесет значительную пользу. Но администраторы знают: солнце встает на востоке, и сложные распределенные системы отказывают в продакшне. Приходит смутное время.

Цель этого доклада — составить рабочее представление о главных компонентах Кубернетеса и взаимодействии между ними. Рассмотрим такие вопросы, как:
* что за «контроллеры»?
* как они реагируют на разрыв соединения с API-сервером?
* какую роль играет kubelet, и что ожидается от него при потере кворума etcd?

Точно так же, как мы знаем базовые операционные характеристики ядра Linux, MySQL или nginx, так и нам стоит иметь мысленную модель Кубернетеса, которая нам поможет при системных авариях, отладке и других трудных моментах.

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

Как переехать с ESXi на KVM/LXD и не сойти с ума

Лев Николаев

Во многих организациях в качестве гипервизора используется VMware в разных его ипостасях. Чаще всего в его бесплатном виде - в виде ESXi. У себя в операторе связи мы использовали его достаточно давно, начиная с версии 5.0.

Разумеется, что у бесплатной версии есть ряд недостатков, которые успешно отсутствуют в платной версии продукта vSphere, однако модель лицензирования достаточно отпугивающая для малого бизнеса. А самое главное, что новые версии ESXi принесли целый ряд неудобств:
- веб-интерфейс, который не работает нормально (старый программный интерфейс несовместим с новыми версиями);
- сломан нормальный мониторинг RAID-массивов.

В итоге стало очевидно, что нужно сваливать и искать более универсальное и более открытое решение.

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

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

О чем будем говорить в докладе:

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

2. Хранилище
Сделайте общее сетевое хранилище. Даже если вы не готовы внутри сети использовать 10 Gbps, то даже 1 Gbps даст Вам 125 мегабайт в секунду стораджа. Для целого ряда нагрузок этого будет достаточно за глаза, а миграция виртуальных машин станет элементарным делом.

3. Контейнер или KVM?
Плюсы, минусы, подводные камни. Какие виды нагрузки лучше положить в контейнер, а какие лучше оставить в KVM?

4. LXD или LXC
А ведь LXD - это LXC? Или это другая версия? Или надстройка? Или что это вообще? Развеиваем мифы и поясняем на пальцах, в чем заключаются отличия между LXD и LXC.

5. Удобный provisioning
Что удобнее: брать одинаковый образ или инсталлировать систему с нуля каждый раз? Как это делать быстро, четко, ровно каждый раз?

6. Как делать виртуалку хорошо внутри?
Здесь будут страшные рассказы о загрузчиках, разделах, LVM и прочем ужасе.

И еще куча всяких мелких вопросов:
- как быстро перетащить виртуалку c ESXi на KVM?
- как хорошо мигрировать?
- как правильно виртуализировать диски?

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

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

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

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

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

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

Serverless: Code as Infrastructure. Choose Your Weapon.

Mikhail Koltsov

Serverless is a big trend now, as a new way to go beyond your own infrastructure relying on someone's PaaS instead. Most of the solutions people usually know are proprietary FaaS solutions provided by the major cloud providers.

But what would you do if you'd like to experiment, having your own servers or even data centers without exposing your customers' data in the cloud?

You can experiment with FaaS solutions built upon either Apache Mesos or Kubernetes. But, I would like to show a practical case of migrating an existing enterprise software to the Apache OpenWhisk platform by showing what to expect when you've decided to go "serverless" for real.

Микросервисы, SOA
,
Асинхронное программирование, реактивное программирование
,
Отказоустойчивость
,
Распределенные системы
,
Разработка библиотек, включая open source библиотеки
,
Масштабирование с нуля
,
Технологии виртуализации и контейнеризации
,
Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
,
Менеджмент в эксплуатации
,
Непрерывная интеграция
,
Devops / другое
,
Web-scale IT / другое
Программный комитет ещё не принял решения по этому докладу

Автоматизируем облака

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

За 5 лет инфраструктура компании Учи.ру выросла с нуля до достаточно большой системы. Сегодня мы поддерживаем более 300 приложений в 5 странах, 100% в публичных облаках на докерах. По мере роста компании и запросов бизнеса мы внедрили много инструментов, адаптировали разные концепции, а попробовали еще больше.

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

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

Ceph. Анатомия катастрофы

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

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

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

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

Monitoring Atlassian Applications

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

I am going to share about Prometheus exporters for Atlassian applications (Jira, Confluence, Bamboo and Bitbucket) which I implemented. Also will shows some awesome boards and why it is better then just JMX or other. I will overview every mentioned product in details about metrics and what we can extend.
These exporters are here: https://github.com/AndreyVMarkelov and on marketplace: https://marketplace.atlassian.com/vendors/1210741/andrey-v-markelov

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

Частые ошибки архитекторов и администраторов Ceph

Михаил Плужников

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

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

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

Istio up and running

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

Расскажу про архитектуру и принцип работы Istio как Service Mesh.

Поговорим о:
- технической части взаимодействия сервисов при использовании этого подхода;
- том, за что отвечают основные компоненты и какие есть подводные камни;
- возможностях Canary deployment, фильтрации трафика, реализации паттерна circuit breaker и outlier detection в частности;
- flow общего сбора метрик и логов;
- неочевидных моментах работы абстракции над сетью (как происходит взаимодействие с внешними компонентами вне Service Mesh, как отлаживать проблемы с перехватом трафика, как нужно настроить service сущности Kubernetes для корректной работы таких фич, как tracing).

Доклад позволит вам понять, какие задачи решает Service Mesh, проще и быстрее начать работать с Istio.

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

Инфраструктура мониторинга в Booking.com

Анна Степанян

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

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

Foreman, Smart Proxy и разработка плагинов

Анатолий Чмыхало

- Что такое Foreman?
- Как и где использовать Foreman.
- Что такое Smart Proxy?
- Что такое плагины для Foreman Smart Proxy?
- Пошаговая разработка DHCP-плагина.
- Деплой плагина и результат работы.

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

Миграция backend’а на Kubernetes, или К вопросу о том, есть ли жизнь в production после внедрения K8S

Seva Morotskiy

В докладе будут рассмотрены use cases, когда развитие сложной IT-инфраструктуры продукта привело к новым вызовам, ответом на которые стало создание инфраструктуры, основанной на Kubernetes и Docker.

Мы поговорим о следующих проблемах, с которыми команда столкнулись в ходе реализации проекта, и о путях их решения:
• особенности написания custom tools для деплоя инфраструктуры системы и аргументы в поддержку переписывания данных tools на скрипты ansible;
• нюансы работы weave-сетей через WAN в K8S-кластерах;
• использование шифрования в weave-сетях для безопасного общения компонентов K8S-кластера между собой;
• фиксация/стабилизация версии kubeadm, weave и других компонент Kubernetes-инфраструктуры для обеспечения гарантии их корректной работы друг с другом;
• отказ от федерализации кластеров Kubernetes;
• безопасность хранения AWS-ключей на отдельных серверах инфраструктуры системы и контроль доступа компонентов системы, которые имеют full access к consul-кластеру для доступа к конфиг-данным системы;
• использование шаблонизаторов для установки K8S chart’ов и корректная генерация values-файлов для chart’ов;
• запуск Prometheus на каждом Kubernetes-кластере системы (backend/client-кластерах) и сложность консолидации этих данных в рамках центрального Prometheus-сервера;
• Prometheus vs InfluxDB – к вопросу о хранении оперативных и исторических данных.

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

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

Terraform modules inside out

Anton Babenko

Terraform module is the smallest reusable component of an infrastructure. Getting started to use modules is easy, but keep them in a good shape and make them really powerful is harder.

Your infrastructure almost always starts simply: few resources managed by few developers. As time goes it grows in all possible directions. You found your ways around grouping resources into Terraform modules, so what can possibly go wrong? (famous last words)

During the talk, I will explain several unknown, hard to find and rather green-field solutions related to Terraform modules. More specifically:
- Types of modules (resource and infrastructure modules, compositions)
- How to specify dependencies between modules
- Workflow for various types of modules

More advanced topics like:
- Refactoring, upgrades, rollbacks (without recreation of the resources)
- Poor-man modules manager
- What are the limitations of the current implementation of Terraform modules and workarounds (eg, jsonnet, cookiecutter, terrapin)

I will demonstrate and run the code which handles advanced problems based terraform-aws-modules from the Terraform Registry and explain why hundreds of developers are using those modules already (btw, they were downloaded 1 million of times already).

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

Good practices to not shoot yourself in the foot in the cloud

David O'Brien

Deploying workloads into the cloud is easy. Doing it the right way though? Not so much. This session will highlight lots of bad practices seen over time in customer environments and show how easy it is to not to the wrong thing.

With great power comes great responsibility. Cloud platforms give people immense power by enabling them to almost do whatever they want. In this session we will uncover the terrible things that your colleagues don’t want you to know that they did. From unpatched virtual machines over publicly accessible servers with default administrator passwords to money burning test environments. We’ll look at practices to save money and also the administrator’s sanity. You are in control of your company’s environments. Come to this session to hear about horror stories encountered in the wild and see how simple it can be to not shoot yourself in the foot when putting workloads into the cloud.

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

CoreOS Container Linux

Максим Залысин

CoreOS Container Linux - современная операционная система, созданная специально для запуска приложений в контейнерах, и отсутствие пакетного менеджера нисколько не мешает. Система минималистична, но для удобной эксплуатации там есть все необходимое - SSH, Bash, systemd, LVM, Docker, iptables, SELinux, ... У CoreOS Container Linux масса достоинств и одно из них - отсутствие всего лишнего. А все недостающее запускается в Docker.

В докладе поделюсь опытом:
- запуска на bare metal и в виртуальной среде: ESXi, DigitalOcean, AWS;
- первичной настройки через Ignition;
- эксплуатации по ssh и посредством Ansible;
- запуска Kubernetes;
- обновления.

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

Terraform best practices with examples and arguments

Anton Babenko

This talk is for the developers who want to learn best practices in using Terraform at companies and projects of various size (from small to very large), get pros&cons on code structuring, composition. Also, attendees will be able to learn Terraform (and Terragrunt) tricks and gotchas.

It is easy to get started with Terraform to manage infrastructure as code. Just read the documentation on terraform.io, and you are done. Almost.

The harder part begins when infrastructure grows in all directions (several AWS/GCP accounts, regions, teams, projects, environments, external integrations). One of the most frequent questions is "how to structure code".

In this talk, I will explain many of challenges related to that, what works, what does not work, why so, and most importantly I will show all the code which works from small projects to very-large infrastructures (featuring multi-cloud and multi-region setup).

This talk is best suitable for people who have been using Terraform at least for some time and already have practical questions.

All the code and solutions presented at the workshop will be open-sourced.

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