Стачка.DevOps

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

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

На секции расскажем о методах внедрения техник DevOps в рабочий процесс и практическом использовании инструментов. Разберем успешные и провальные кейсы автоматизации процессов разработки.

Секция для тех, кому не безразличны понятия Continuous Delivery и Configuration Management.


Дмитрий Столяров
Технический директор и соучредитель @ Флант
Ульм
Андрей Климентьев
Solutions Engineer @ Флант
Нижний Новгород
Сидоров Андрей
DevOps-инженер @ Флант
Симферополь

На данный момент (февраль 2019) у нас, компании Флант, в production-окружениях Kubernetes функционируют 55 проектов, в состав которых входят более 1000 различных приложений в 70+ кластерах.

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

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

  • Какие метрики нам важны для оценки ресурсов, требуемых приложениям?
  • Как соблюсти требования к SLA и SLO приложения?
  • Как, используя полученные метрики, обеспечить работу сервиса, применив механизмы автомасштабирования Kubernetes?

Ответив на эти вопросы и обеспечив их реализацию в production, мы поделимся практическими рекомендациями, как, используя Kubernetes в качестве фундамента, обеспечить высокую доступность приложений (PDB, QoS, PriorityClass...) и гарантировать их максимальную производительность (VPA, HPA, cluster-autoscaler).

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

Голосование


Руслан Серкин
Software Engineer @ DataArt
Санкт-Петербург

- Разберем что такое Serverless и с чем его "едят"

- Рассмотрим основные проблемы с которыми вы можете столкнуться во время разработки

- Поделюсь своим опытом и практиками


Иван Пономарёв
Tech Lead @ КУРС
Москва

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

Голосование


Олег Блохин
Site Reliability Engineer @ Dodo Pizza
Нижний Новгород

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

С одной стороны - это модно, консультанты с удовольствием расскажут вам как DevOps внедрить, а если на консультантов денег нет, вам поможет пол дюжины книжек. А с другой - каждый вкладывает в это слово своё, периодически прикрывая им дыры в организационной структуре и нежелание системно решать проблемы.

Я расскажу об истории эксплуатации нашей информационной системы, взаимодействия "сисдаминов" и "программистов" в Dodo, о том как мы шли от классического отдела эсплутации из пары сисадминов, ходили под флагом DevOps и эволюционировали до Site Reliability Engineering команды, состоящей почти целиком из программистов. Расскажу какой профит и какую боль мы собрали по пути, и какие инженерные решения принимали. Как мы пытаемся сохранить гибкость дерзкого стартапа при росте команды разработки до 250 человек.


Ярослав Былевский
Системный администратор @ РТК ИНФОТЕХ
Москва

Когда мы начинали строить Платформу Цифровых Продуктов для Ростелекома, ещё не было каких-то устоявшихся традиций организации CI/CD процессов.

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

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

В докладе я хочу показать:

- какой набор ПО и какая схема CI/CD используется у нас

- почему были выбраны именно такие решения

- какие плюсы и минусы такой организации процесса

- как используется наша схема с точки зрения разработчиков и системных администраторов

- какие ещё есть популярные решения сборок и выкатов на данный момент

В итоге сравнить нашу систему CI/CD с другими вариантами билдов и деплоев по пунктам:

- утилизация ресурсов - баланс между скоростью сборок и затратами на содержание кластера

- использование чистых окружений против подготовленных

- конфигурация билда в Git против конфигурации в системе сборок

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

Или понять, как и по каким принципам вообще строится система CI/CD - для тех, кто этого ещё не делал.

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

Голосование


Иван Мороз
Инженер-программист @ SUPPORTix
Ульяновск

Время работы c FTP давно прошло.

Мы начали смотреть в поисках легкого средства разворачивания приложений для PHP.

Capistrano, — поставляется вместе с многочисленными связанными с Ruby/Rails возможностями.

У него есть версионирование разворачиваемых версий, шаренные папки и возможность выполнять таски.

Но есть недостатки.

Как мне кажется, обычному PHP-разработчику, не знакомому с Ruby, будет довольно сложно установить Capistrano.

И тут я познакомился с Mina.

Mina – эффективный и быстрый инструмент развертывания.

Инструмент который можно использовать для развертывания как Wordpress так и Rails приложений.

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

Действительно быстрый инструмент развертывания и серверной автоматизации. Чертовски быстрый!

Главное преимущество Mina от Capistrano это скорость.

Mina работает исключительно быстро, потому что это генератор скриптов Bash.

Он создает целую процедуру в виде сценария Bash и запускает ее удаленно на сервере.

Он также поддерживает интеллектуальное выполнение команд.


Евгений Дехтярёв
Инфраструктурный инженер @ 2ГИС
Новосибирск

Мы поддерживаем распределённый сервис доставки, обработки и хранения логов на ElasticSearch-Logstash-Kibana. Сервис непростой — в него летят 50К сообщений в секунду.

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

Выводы каждый сделает для себя — tail’ить дальше или пользоваться удобными фильтрами из Kibana.

Голосование


Михаил Макуров
Инженер @ Интерсвязь
Челябинск

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

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

И подробно рассмотрю вопросы, возникшие при кластеризации системы - разрешение конфликтов идентификаторов в БД, немного о "CAP theorem" и мониторинге с распределенными БД, и ньюансах работы Zabbix в кластерном режиме: резервирование и координирование работы серверов и прокси, о "доменах мониторинга" и новом взгляде на архитектуру системы. Коротко расскажу о том, как запустить кластер у себя, где взять исходники, какие доп. настройки потребуются для кластера.


Артем Пулявин
VP of Engineering @ Zarabotal.ru
Москва

Часто ли у вас бывает такое, что код из репозитория сервиса бэкэнда еще пишется, но с ним уже хотят работать front и mobile команда? А отдел тестирования постоянно бегает к mobile команде за релизными сборками, по которым готовы еще не все таски в спринте?

Я расскажу как мы раздали каждому участнику нашей команды выделенный стейдж и GUI, через который можно деплоить нужные ветки для 15+ сервисов и собирать мобильные приложения, работающие с API этого стейджа.

И как наступило счастье.


Спикер
Моя должность @ Моя компания
Мой город

Алексей Кирпичников
@ Контур
Екатеринбург
Аварии помогают учиться
из Голосование

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

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

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

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