Конференция для фанатов DevOps-подхода

Речь, конечно, о DevOpsConf. Если не вдаваться в детали, то 30 сентября и 1 октября мы проведем конференцию об объединении процессов разработки, тестирования и эксплуатации, а если вдаваться — прошу под кат.

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

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

Закулисье

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

• senior-инженеров;
• разработчиков;
• тимлидов;
• CTO.

С одной стороны, это создаёт сложности и конфликты при обсуждении заявок на доклады. Если инженеру интересен разбор крупной аварии, то разработчику важнее понять, как создать софт, работающий в облаках и инфраструктурах. Но договариваясь, мы создаём такую программу, которая будет ценна и интересна всем: от инженеров до CTO.

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

Секции конференции останутся теми же, что и в прошлый раз.

• Инфраструктурная платформа.
• Инфраструктура как код.
• Непрерывная поставка.
• Обратная связь.
• Архитектура в DevOps, DevOps для CTO.
• SRE-практики.
• Обучение и управление знаниями.
• Безопасность, DevSecOps.
• DevOps-трансформация.

Call for Papers: какие доклады мы ищем

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

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

Для разработчиков важно разобраться с таким понятием, как cloud native application. То есть как надо разрабатывать софт, чтобы он работал в облаках и различных инфраструктурах. Разработчику необходимо постоянно получать обратную связь от программного обеспечения. Здесь мы хотим услышать кейсы о том, как компании выстраивают этот процесс, как нужно мониторить работоспособность ПО и как устроен весь процесс поставки.

Специалистам в области кибербезопасности важно понимать, как настроить процесс обеспечения безопасности таким образом, чтобы он не стопорил процессы разработки и изменений внутри компании. Интересны будут и темы о требованиях, которые DevOps предъявляет к таким специалистам.

Тимлиды хотят знать, как устроен процесс continuous delivery в других компаниях. Каким путём компании к этому шли, как выстраивались процессы разработки, обеспечения качества внутри DevOps. Cloud native тимлидам тоже интересен. А ещё — вопросы о взаимодействии внутри команды и между командами разработчиков и инженеров.

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

Если у вас есть, что сказать по этим поводам, не молчите, подавайте доклад. Крайний срок по Call for Papers — 20 августа. Чем раньше заявитесь, тем больше времени будет на доработку доклада и подготовку к выступлению. Так что, не затягивайте.

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

Как мы видим DevOps

Чтобы точно понимать, что мы вкладываем в понятие DevOps, рекомендую прочитать (или перечитать) мой доклад «Что такое DevOps». Гуляя по волнам рынка, я наблюдал, как трансформируется представление о DevOps в разных по величине компаниях: от небольшого стартапа до транснациональных компаний. Доклад построен на серии вопросов, отвечая на них, можно понять, движется ли ваша компания к DevOps или где-то есть проблемы.

DevOps — это сложная система, в ней должны быть:

• Цифровой продукт.
• Бизнес модули, которые этот цифровой продукт развивают.
• Продуктовые команды, которые пишут код.
• Практики Continuous Delivery.
• Платформы как сервис.
• Инфраструктура как сервис.
• Инфраструктура как код.
• Отдельные практики поддержания надежности, зашитые внутри DevOps.
• Практика обратной связи, которая описывает все это.

В конце доклада есть схема, которая даёт представление о DevOps-системе в компании. Она позволит увидеть, какие процессы в вашей компании уже отлажены, а какие только предстоит выстраивать.

Видео доклада можно посмотреть здесь.

А сейчас будет бонус: нескольких видео с РИТ++ 2019, которые касаются наиболее общих вопросов DevOps-трансформации.

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

Артём Науменко руководит DevOps-командой в Skyeng и заботится о развитии инфраструктуры своей компании. Он рассказал, как инфраструктура влияет на бизнес-процессы в SkyEng: как считать для неё ROI, какие метрики стоит выбрать для подсчёта и как работать над их улучшением.

На пути к микросервисам

Компания Nixys занимается поддержкой нагруженных web-проектов и распределённых систем. Её технический директор Борис Ершов рассказал, как перевести на современные рельсы программные продукты, разработка которых началась лет 5 назад (или даже больше).

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

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

• как выбрать подходящую для проекта архитектуру и привести в порядок инфраструктуру;
• какие инструменты использовать и какие подводные камни встречаются на пути к трасформации;
• что делать дальше.

Автоматизация релизов или как доставить быстро и без боли

Александ Коротков — ведущий разработчик системы CI/CD в ЦИАН. Он рассказал об инструментах автоматизации, которые позволили повысить качество и сократить время доставки кода в продакшн в 5 раз. Но таких результатов невозможно было бы добиться только одной автоматизацией, поэтому Александр обратил внимание и на изменения в процессах разработки.

Как аварии помогают учиться?

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

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

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

Мы понимаем, что ваше видение DevOps может не совпадать с нашими представлениями. Будет интересно узнать, как вы видите DevOps-трансформацию. Поделитесь в комментариях своим опытом и видением этой темы.

Какие доклады мы уже приняли в программу?

На этой неделе Программный комитет принял 4 доклада: о безопасности, инфраструктуре и SRE-практиках.

Пожалуй, самая больная тема DevOps-трансформации: как сделать так, чтобы ребята из отдела информационной безопасности не порушили уже выстроенные связи между разработкой, эксплуатацией и администрированием. Некоторые компании обходятся и без отдела ИБ. Как в таком случае обеспечить информационную безопасность? Об этом расскажет Мона Архипова из sudo.su. Из её доклада мы узнаем:

• что и от кого нужно защищать;
• каковы рутинные процессы безопасности;
• как пересекаются процессы ИТ и ИБ;
• что такое CIS CSC и как это внедрить;
• как и по каким показателям проводить регулярные проверки ИБ.

Следующий доклад касается развития инфраструктуры как кода. Уменьшить количество ручной рутины и не превратить весь проект в хаос, возможно ли это? На этот вопрос ответит Максим Кострикин из Ixtens. В его компании используют Terraform для работы с AWS-инфраструктурой. Инструмент удобный, но вопрос в том, как при его использовании избежать появления огромной глыбы кода. Обслуживание такого наследия с каждым годом будет обходиться всё дороже и дороже. 

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

Ещё один доклад об инфраструктуре услышим от Владимира Рябова из Playkey. Здесь речь пойдёт об инфраструктурной платформе, и мы узнаем:

• как понять, эффективно ли используется объём хранилища;
• как несколько сотен пользователей могут получить по 10 ТБ контента, если используются всего 20ТБ хранилища;
• как сжать данные в 5 раз и предоставлять их пользователям в real-time;
• как налету синхронизировать данные между несколькими дата-центрами;
• как исключить любое влияние пользователей друг на друга при последовательном использовании одной виртуальной машины.

Секрет этой магии — в технологии ZFS для FreeBSD и ее свежем форке ZFS on Linux. Владимир поделится кейсами от Playkey.

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

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

Источник: habr.com