Интервью с Александром Титовым, одним из членов программного комитета нашей июньской конференции HighLoad++, отдельная секция которой будет посвящена DevOps.
Под катом про то, в каком направлении дует «ветер» DevOps, и какие именно аспекты этой концепции будут обсуждаться на форуме.
Александр достаточно хорошо знаком нашему сообществу, он является организатором DevOps Moscow и конференции DevOpsDays Moscow, не первый год выступает на наших мероприятиях и помогает в формировании их программ. В данный момент он является управляющим партнером в компании Экспресс 42, которая выращивает DevOps в технологических компаниях. Ранее, с 2010 по 2012, Александр прошел увлекательный путь поглощений вместе с компанией Qik — от эксплуатации быстрорастущего стартапа к эксплуатации в крупной международной компании Microsoft. До этого, в 2009-2010 годах, был техническим директором первого облачного в России «Скалакси».
— Начнем издалека: эволюционирует ли культура DevOps? Какие изменения наблюдаются в этой сфере в последние годы? И как вообще DevOps выглядит в России?
Безусловно, в мире, где технологии сменяют друг друга раз в три года, все постоянно и очень сильно меняется. Изначально базовой проблемой было само производство и эксплуатация программного обеспечения в век цифровых технологий. Вокруг этой проблемы и собралось движение DevOps. Теперь же базовая проблема поделилась на много подкатегорий — управление инфраструктурой, мониторинг, continuous integration, continuous delivery, работа с людьми (в частности, проблема выгорания людей, которые занимаются одновременно и эксплуатацией, и разработкой), некоторые технологические вещи (например появление Kubernetes, как такого стандарта де-факто всей инфраструктурной платформы в компаниях). То есть во многом появилась конкретика: мы прошли стадию понимания, что надо делать не так, как раньше, попробовали много новых подходов и пришли к формированию каких-то стандартизированных процессов для решения общих (типовых) проблем. Но при этом инструменты и процессы во многих компаниях по всему миру все равно остаются низкокачественными либо очень плохо формализованными.
В российском контексте дополнительная проблема заключается в том, что мы не понимаем, зачем это все нужно. Многих это дезориентирует. У нас разработка, тестирование и эксплуатация существуют порознь, а тут приходит какой-то Kubernetes, чтобы решить некие проблемы, но они пытаются его внедрять, не меняя процессы, подходы и компетенцию людей. Все ломается. И зачем эти новые технологии — непонятно.
— И в чем причина таких радикальных преобразований?
Как я уже упомянул, мы начали решать другую задачу. Изначально классические IT решали задачу автоматизации бизнес-процессов внутри корпорации. Под это была подстроена вся инфраструктура — базы данных, шины и т.п. С 2000 года — после кризиса доткомов — IT переключились на создание цифровых продуктов, которые могут массово предоставлять кастомизированный сервис, поставляя некую ценность. Если раньше предприятие выпускало определенную модель авто, теперь оно переключилось на кастомизацию для каждого клиента. Это решение другой задачи, для которого нужны принципиально другие подходы и технологии — другой процесс производства ПО. Здесь уже не получается делать разработку, тестирование и эксплуатацию последовательно. Теперь эти процессы запускаются одновременно.
Кстати, несмотря на это, бытует заблуждение, что DevOps — это про эксплуатацию. Классических системных администраторов, которые выполняют эксплуатационную работу, просто переименовывают в DevOps-инженеров, дискредитируя термин в принципе. На самом деле концепция намного шире. Это отдельный набор практик, отдельный фреймворк, позволяющий решать конкретные задачи в определенных условиях и с людьми определенной компетенции — не больше, не меньше. Просто мало кто понимает, зачем это нужно. И это одна из проблем, которые мы пытаемся решать через конференции.
— На какие доклады планируется сделать упор на секции в рамках сибирской HighLoad?
Если раньше были в основном эксплуатационные доклады, то именно в этом году мы хотим добавить больше информации про связь с разработкой, например про процессы continuous delivery, continuous integration, тестирование. Классный пример — доклад Максима Лапшина на РИТ++ (в рамках весенней RootConf 2018) про то, как использовать DevOps в коробочной разработке. У такой компании в принципе нет эксплуатации — она делает коробку, которую продает клиенту. В то же время внутри у нее DevOps. Такой подход рвет шаблон, но одновременно помогает развенчать упомянутый миф о том, что DevOps касается только эксплуатации. Это наш первый базовый фокус.
Второй фокус — это новые технологии. Сейчас модно говорить про Kubernetes, Prometheus и другие. И мы ищем людей, которые смогли пощупать эти технологии на практике. То есть не только настроили и заставили работать, но и включили это в свой процесс разработки. Вообще все технологии мы стараемся рассматривать под призмой того, как они включаются в процесс производства программного обеспечения — какую задачу они решают, какие цели перед ними ставятся и т.п. Если об этом не рассказывать, люди начинают работать с технологиями как с карго-культом: «Давайте мы поставим Kubernetes и у нас получится Google». Так не получится.
— Концепция continuous integration уже хорошо принята рынком. Кроме конкретных инструментов здесь есть, о чем говорить?
Конечно. Базовый, можно даже сказать переломный концепт заключается в том, что в контексте DevOps внутри процесса continuous integration продукты не тестируются на качество. То есть здесь не важно, насколько продукт функционально зрелый. Важно проверить, как хорошо он запускается и готов ли к интеграции с другими компонентами.
Это серьезное изменение, потому что continuous integration есть и в последовательной разработке, эксплуатации и тестировании. Но там на этом уровне проверяется качество продукта по требованиям пользователя, а в рамках DevOps осуществляется проверка функциональных качеств. Именно эта стадия позволяет максимально быстро проводить интеграцию отдельных сервисов в рамках микросервисной инфраструктуры (а DevOps в целом без микросервисной архитектуры не существует).
— Какие инструменты в этом году в фокусе?
В первую очередь — уже упомянутый Kubernetes. Он появился некоторое время назад, но лишь совсем недавно дошел до стадии, когда его можно использовать. Сейчас он может задействоваться любыми компаниями, разрабатывающими обновляемый цифровой сервис, например предоставляющими услуги через сайты или мобильные приложения.
Часто упоминается Prometheus — это система мониторинга, GitLab — как система именно continuous integration. А также весь HashiCorp-стек — Vault, Terraform (оба разработки HashiCorp). Ну и, понятно, Docker — как формат поставки.
— Есть ли в последнее время какие-то сдвиги в рамках концепции «everything as a code»?
Сама практика «everything as a code», очевидно, полезна. Это один из фундаментальных принципов, на которых базируется DevOps-процесс. Kubernetes как раз продолжает эту идеологию.
В DevOps основная история — это «infrastructure as a code». И это не только концепт, но и процесс, в рамках которого все компоненты представляются в виде кода, который позволяет отдельным «кускам» инфраструктуры взаимодействовать друг с другом. Кардинальных изменений здесь нет, но, как практика, она теперь развивается внутри Kubernetes. Например, развиваются инструменты управления зависимостями, такие как Helm, средства создания отдельных модулей, описания инфраструктуры, например, операторы (и там появляются фреймворки для написания операторов в Kubernetes) и т.д. Иными словами, происходит здоровое развитие инструмента и проникновение практики внутри него.
— А сама практика «everything as a code» в отрыве от инструмента стоит того, чтобы о ней говорить?
Мы пока еще до конца не сформировали программу, поэтому я не могу сказать, будем ли мы поднимать такие темы именно на HighLoad++. Но само по себе это возможно.
Есть очень много подходов по организации инфраструктуры, по управлению зависимостью внутри инфраструктурного кода и по его тестированию. Мы, конечно, будем говорить о концепциях по работе с практикой — например о том, что инфраструктурный код должен быть разделен на модули. Мне кажется, что рафинированно, в отрыве от практики, такие темы не очень хорошо заходят. Но, возможно, мы выберем доклад, где будут собраны все возможные подходы в рамках какого-то одного системного описания. Однако гораздо ценнее, когда люди рассказывают и показывают, как в реальности реализуются эти теоретические концепции. О теории, которая лежит в основе практик, можно потом поговорить с теми же людьми в кулуарах.
— Есть мнение, что популярность event-driven архитектуры со временем растет. Согласны ли вы с этим утверждением?
Event-driven infrastructure всегда была частью подхода chatops — по событию мы в чате принимаем какое-то решение о том, что должно происходить с куском инфраструктуры. Эта история очень нужна большим крупным компаниям, но для остальной аудитории она еще не совсем зрелая. Чтобы по событию принимать решения о том, что должно произойти (что мы должны сделать), необходимо выработать некоторый фреймворк правил внутри команд о том, как мы принимаем эти решения, чтобы все делали это более-менее одинаково — смотрели с одной стороны. А с этим пока все сложно. Формат выработки такого фреймворка — то, о чем сейчас идут все разговоры: как это можно автоматизировать, увести в инструмент, как это надо делать на уровне командообразования и как согласовывать с разными командами.
— Отражено ли это как-то в докладах конференции?
Нет, HighLoad++ — это больше про высоконагруженные системы и тулзы, поэтому здесь мы можем поговорить про инструменты, но не про выработку такого фреймворка. Но осенью у нас будет отдельная конференция RootConf, которая пройдет 1-2 октября. До 2011 года она была посвящена вопросам эксплуатации (т.е. только одной составляющей всего процесса «разработка-тестирование-эксплуатация»). В 2015 году мы ее реинкарнировали уже в контексте всего DevOps — так мы плавно расширили тему. На RootConf мы обсуждаем, как обеспечить взаимодействие разработчиков и инженеров по эксплуатации, говорим о новых процессах и технологиях, про инфраструктурные платформы и управление инфраструктурой, которой в парадигме DevOps занимается не только эксплуатация, но и разработка (просто они выполняют разную работу).
— Появились ли в последние пару лет интересные технологии повышения отказоустойчивости проектов? Будет ли о них речь на конференции?
Сегодня мы наткнулись на парадокс, связанный с тем, что «отказоустойчивость» не значит «надежность». Отказоустойчивость (fault-tolerance) сейчас вытеснена надежностью (reliability).
Отказоустойчивость — понятие из парадигмы монолитных систем, где проблему надежности решали через дублирование, наращивание ресурсов и т.д. Сейчас такие подходы уже не работают. Надежность же опирается на принципиально другие подходы — она подразумевает «антихрупкость» системы. То есть система становится «мягкой»: если мы воздействуем на нее, она меняется, а не разрушается. Иными словами, если вы собираетесь построить какой-то новый сервис, вы должны предусматривать такие варианты его поведения, в которых если пользователь или среда, в которой он работает, пытаются его разрушить, то сервис просто меняет свои свойства, при этом услуга все равно предоставляется, выдается какой-то результат.
Хороший маркер тенденции — появление site reliability engineering как практики и отдельных специалистов — site reliability engineer (SRE) как замены прошлой компетенции системного администратора. В качестве некой иллюстрации этого процесса упомяну, что Google свою практику реализации DevOps выпустили в виде книги по site reliability engineering и активно продвигают эту идею в массы.
Об этом мы тоже будем говорить на RootConf. Сейчас эта тема на хайпе на Западе, и мы (силами сообщества DevOps Moscow) стараемся ее постепенно затаскивать и к нам.
Автор: olegbunin
