Хабрахабр

DevOps на HightLoad++ Siberia: развенчаем мифы и обсудим инструменты

Интервью с Александром Титовым, одним из членов программного комитета нашей июньской конференции HighLoad++, отдельная секция которой будет посвящена DevOps.
Под катом про то, в каком направлении дует «ветер» DevOps, и какие именно аспекты этой концепции будут обсуждаться на форуме.

В данный момент он является управляющим партнером в компании Экспресс 42, которая выращивает DevOps в технологических компаниях.
Александр достаточно хорошо знаком нашему сообществу, он является организатором DevOps Moscow и конференции DevOpsDays Moscow, не первый год выступает на наших мероприятиях и помогает в формировании их программ. До этого, в 2009-2010 годах, был техническим директором первого облачного хостинга в России «Скалакси». Ранее, с 2010 по 2012, Александр прошел увлекательный путь поглощений вместе с компанией Qik — от эксплуатации быстрорастущего стартапа к эксплуатации в крупной международной компании Microsoft.

Какие изменения наблюдаются в этой сфере в последние годы? — Начнем издалека: эволюционирует ли культура DevOps? И как вообще DevOps выглядит в России?

Изначально базовой проблемой было само производство и эксплуатация программного обеспечения в век цифровых технологий. Безусловно, в мире, где технологии сменяют друг друга раз в три года, все постоянно и очень сильно меняется. Теперь же базовая проблема поделилась на много подкатегорий — управление инфраструктурой, мониторинг, continuous integration, continuous delivery, работа с людьми (в частности, проблема выгорания людей, которые занимаются одновременно и эксплуатацией, и разработкой), некоторые технологические вещи (например появление Kubernetes, как такого стандарта де-факто всей инфраструктурной платформы в компаниях). Вокруг этой проблемы и собралось движение DevOps. Но при этом инструменты и процессы во многих компаниях по всему миру все равно остаются низкокачественными либо очень плохо формализованными. То есть во многом появилась конкретика: мы прошли стадию понимания, что надо делать не так, как раньше, попробовали много новых подходов и пришли к формированию каких-то стандартизированных процессов для решения общих (типовых) проблем.

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

— И в чем причина таких радикальных преобразований?

Изначально классические IT решали задачу автоматизации бизнес-процессов внутри корпорации. Как я уже упомянул, мы начали решать другую задачу. С 2000 года — после кризиса доткомов — IT переключились на создание цифровых продуктов, которые могут массово предоставлять кастомизированный сервис, поставляя некую ценность. Под это была подстроена вся инфраструктура — базы данных, шины и т.п. Это решение другой задачи, для которого нужны принципиально другие подходы и технологии — другой процесс производства ПО. Если раньше предприятие выпускало определенную модель авто, теперь оно переключилось на кастомизацию для каждого клиента. Теперь эти процессы запускаются одновременно. Здесь уже не получается делать разработку, тестирование и эксплуатацию последовательно.

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

На какие доклады планируется сделать упор на секции в рамках сибирской HighLoad?

Классный пример — доклад Максима Лапшина на РИТ++ (в рамках весенней RootConf 2018) про то, как использовать DevOps в коробочной разработке. Если раньше были в основном эксплуатационные доклады, то именно в этом году мы хотим добавить больше информации про связь с разработкой, например про процессы continuous delivery, continuous integration, тестирование. В то же время внутри у нее DevOps. У такой компании в принципе нет эксплуатации — она делает коробку, которую продает клиенту. Это наш первый базовый фокус. Такой подход рвет шаблон, но одновременно помогает развенчать упомянутый миф о том, что DevOps касается только эксплуатации.

Сейчас модно говорить про Kubernetes, Prometheus и другие. Второй фокус — это новые технологии. То есть не только настроили и заставили работать, но и включили это в свой процесс разработки. И мы ищем людей, которые смогли пощупать эти технологии на практике. Если об этом не рассказывать, люди начинают работать с технологиями как с карго-культом: «Давайте мы поставим Kubernetes и у нас получится Google». Вообще все технологии мы стараемся рассматривать под призмой того, как они включаются в процесс производства программного обеспечения — какую задачу они решают, какие цели перед ними ставятся и т.п. Так не получится.

Кроме конкретных инструментов здесь есть, о чем говорить? — Концепция continuous integration уже хорошо принята рынком.

Базовый, можно даже сказать переломный концепт заключается в том, что в контексте DevOps внутри процесса continuous integration продукты не тестируются на качество. Конечно. Важно проверить, как хорошо он запускается и готов ли к интеграции с другими компонентами. То есть здесь не важно, насколько продукт функционально зрелый.

Но там на этом уровне проверяется качество продукта по требованиям пользователя, а в рамках DevOps осуществляется проверка функциональных качеств. Это серьезное изменение, потому что continuous integration есть и в последовательной разработке, эксплуатации и тестировании. Именно эта стадия позволяет максимально быстро проводить интеграцию отдельных сервисов в рамках микросервисной инфраструктуры (а DevOps в целом без микросервисной архитектуры не существует).

— Какие инструменты в этом году в фокусе?

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

А также весь HashiCorp-стек — Vault, Terraform (оба разработки HashiCorp). Часто упоминается Prometheus — это система мониторинга, GitLab — как система именно continuous integration. Ну и, понятно, Docker — как формат поставки.

— Есть ли в последнее время какие-то сдвиги в рамках концепции «everything as a code»?

Это один из фундаментальных принципов, на которых базируется DevOps-процесс. Сама практика «everything as a code», очевидно, полезна. Kubernetes как раз продолжает эту идеологию.

И это не только концепт, но и процесс, в рамках которого все компоненты представляются в виде кода, который позволяет отдельным «кускам» инфраструктуры взаимодействовать друг с другом. В DevOps основная история — это «infrastructure as a code». Например, развиваются инструменты управления зависимостями, такие как Helm, средства создания отдельных модулей, описания инфраструктуры, например, операторы (и там появляются фреймворки для написания операторов в Kubernetes) и т.д. Кардинальных изменений здесь нет, но, как практика, она теперь развивается внутри Kubernetes. Иными словами, происходит здоровое развитие инструмента и проникновение практики внутри него.

— А сама практика «everything as a code» в отрыве от инструмента стоит того, чтобы о ней говорить?

Но само по себе это возможно. Мы пока еще до конца не сформировали программу, поэтому я не могу сказать, будем ли мы поднимать такие темы именно на HighLoad++.

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

Согласны ли вы с этим утверждением? — Есть мнение, что популярность event-driven архитектуры со временем растет.

Эта история очень нужна большим крупным компаниям, но для остальной аудитории она еще не совсем зрелая. Event-driven infrastructure всегда была частью подхода chatops — по событию мы в чате принимаем какое-то решение о том, что должно происходить с куском инфраструктуры. А  с этим пока все сложно. Чтобы по событию принимать решения о том, что должно произойти (что мы должны сделать), необходимо выработать некоторый фреймворк правил внутри команд о том, как мы принимаем эти решения, чтобы все делали это более-менее одинаково — смотрели с одной стороны. Формат выработки такого фреймворка — то, о чем сейчас идут все разговоры: как это можно автоматизировать, увести в инструмент, как это надо делать на уровне командообразования и как согласовывать с разными командами.

— Отражено ли это как-то в докладах конференции?

Но осенью у нас будет отдельная конференция RootConf, которая пройдет 1-2 октября. Нет, HighLoad++ — это больше про высоконагруженные системы и тулзы, поэтому здесь мы можем поговорить про инструменты, но не про выработку такого фреймворка. только одной составляющей всего процесса «разработка-тестирование-эксплуатация»). До 2011 года она была посвящена вопросам эксплуатации (т.е. На RootConf мы обсуждаем, как обеспечить взаимодействие разработчиков и инженеров по эксплуатации, говорим о новых процессах и технологиях, про инфраструктурные платформы и управление инфраструктурой, которой в парадигме DevOps занимается не только эксплуатация, но и разработка (просто они выполняют разную работу). В 2015 году мы ее реинкарнировали уже в контексте всего DevOps — так мы плавно расширили тему.

Будет ли о них речь на конференции? — Появились ли в последние пару лет интересные технологии повышения отказоустойчивости проектов?

Отказоустойчивость (fault-tolerance) сейчас вытеснена надежностью (reliability). Сегодня мы наткнулись на парадокс, связанный с тем, что «отказоустойчивость» не значит «надежность».

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

В качестве некой иллюстрации этого процесса упомяну, что Google свою практику реализации DevOps выпустили в виде книги по site reliability engineering и активно продвигают эту идею в массы. Хороший маркер тенденции — появление site reliability engineering как практики и отдельных специалистов — site reliability engineer (SRE) как замены прошлой компетенции системного администратора.

Сейчас эта тема на хайпе на Западе, и мы (силами сообщества DevOps Moscow) стараемся ее постепенно затаскивать и к нам. Об этом мы тоже будем говорить на RootConf.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть