Прошлый год стал немалым испытанием для многих из нас, но дал он и толчок к новому восприятию, выстраиванию новых рабочих процессов и возникновению новых вопросов. Что находится на современном срезе индустрии DevOps и каковы тренды будущего? Об этом председатель программного комитета конференции DevOpsConf 2021 Артем Каличкин рассказал во время интервью подкасту DevOps Дефлопе, а мы перенесли беседу в текстовый вариант.
Из этой статьи вы узнаете о том, кто в российском девопсе идет в ногу со временем, или даже немного опережает мировых лидеров, посмотрите на особенности командных топологий и задумаетесь о том, кого еще нужно подружить, кроме Devов и Opsов, для того, чтобы все работало отлично. А еще заглянете в закулисье DevOpsConf 2021.
Расскажи немного о себе.
С 2004 года я занимаюсь вопросами отказоустойчивости высоконагруженных систем и поддержкой mission critical systems. В индустрии, в целом, работаю уже 22 года. Последние три года я являюсь техническим директором сервисов Faktura.ru это интернет-банк как для физических, так и для юридических лиц.
Впервые на публичной конференции я выступил в 2014 году. Это был Город IT в Томске, и на ней я рассказывал про паттерны/антипаттерны отказоустойчивых приложений. Я постоянно говорю про отказоустойчивость, потому что это непосредственно имеет отношение ко всему, что касается Operations.
Мне очень близок вопрос дружбы Devов и Opsов. Если что-то не так, Opsы забывают о сне. А я, как руководитель, обычно стараюсь сделать так, чтобы спокойный сон закончился у всех причастных, чтобы все были в одном положении.
Потом я выступил на RootConf и рассказал, как мы, в рамках энтерпрайзной компании, ставили сервис на рельсы DevOps. Тогда еще доклады о том, есть ли devOps в энтерпрайзе, не были в тренде.
А дальше пошло-поехало: каждый год я выступал на трех-четырех конференциях. Последние четыре года в программном комитете DevOpsConf, и в 2020 был избран председателем программного комитета.
Есть ощущение, что сегодня в России индустрия финтеха интенсивно развивается.
Да, действительно это так. Финтех в России очень динамично развивающаяся отрасль, которая подстегивается, в том числе, и инициативами Центробанка. В качестве примера можно привести систему быстрых платежей по номеру телефона, раньше это было доступно только клиентам Сбера, но с прошлого года есть СБП, и это доступно всем.
В России финтех на гребне волны, именно в этой сфере задействованы передовые технологии. Мало где в мире можно встретить такой уровень банковского обслуживания и такое всеобъемлющее проникновение электронных платежей в абсолютно все сферы жизни. Например, между Новосибирском и Томском есть федеральная трасса, и где-то посередине есть общественный туалет. Так вот оплачивать его прикосновением телефона можно было раньше, чем поездки в московском метро. Это все, что нужно знать о финтехе в России.
Развивающиеся экосистемы
Какие отрасли, на твой взгляд, идут в российской индустрии в ногу со временем, а возможно, даже опережают зарубежные рынки? Кроме финтеха, конечно. С ним всё понятно. За рубежом самая большая новость последних лет была о том, что появилась Apple-карта. А мы этим пользуемся уже довольно давно.
Сейчас в России многие ориентированы на движение в сторону супер-приложений и супер-сервисов B2C. Сегодня вперед вырываются те, кто задумывается о цифровизации клиентского опыта.
Многие крупные компании встраивают в линейку своих программ не специфичные для их основного бизнеса сервисы. В качестве примера можно привести службы доставки у банка и такси. Причем, к этому привыкаешь. Яндекс-Go поначалу хейтили очень сильно. Сейчас волна возмущений, вроде бы стихла, или я уже привык, что в одном приложении находятся и еда, и такси.
Но я лично все-таки сторонник того, чтобы платформы выступали неким шлюзом для сервисов. И было поменьше корпораций и побольше свободного рынка. Потому что когда мы под экосистемой понимаем компании, принадлежащие одним бенефициарам, эта вся история, с моей точки зрения является неким тормозом. Я за то, чтобы крупные компании создавали платформы, через которые любой мог бы заходить со своей версией сервиса.
Потому что если мы дождемся того, что все станет единой экосистемой, шагнем в антиутопичное будущее, которое мне не кажется правильным.
Кому полезна DevOpsConf
Мы поговорили о том, каково текущее состояние индустрии и о том, куда мы движемся. Исходя из парадигмы цифровизации пользовательского опыта и формирования больших экосистем, хочется понять, как быть молодым разработчикам? И вопрос с другой стороны: кому полезна DevOpsConf?
Я преподаю в Новосибирском государственном университете на факультете информационных технологий. И всегда пытаюсь донести до своих студентов: пока не взяли ипотеку, попробуйте замутить что-то свое, ведь сейчас для этого есть масса возможностей, в том числе благодаря App Store и Google Play. Каждый может попробовать написать что-то, что зайдет аудитории, не выходя из дома.
Вернемся к конференции и оценке состояния отрасли. В этом году Agile-манифест, по-моему, отпраздновал свое двадцатилетие. И мы сегодня находимся в том состоянии отрасли, когда все должны быть максимально нацелены на поиск. Казалось бы, история Agile-манифеста о том, что нужно быть гибким, адаптироваться, или умереть, уже всем приелась. Но, по факту, мы еще недостаточно научились быть гибкими. Стоит лишь вспомнить 2020 год со всеми его особенностями. COVID 2019 уже назвали главным цифровизатором. И он показал, что мы еще недостаточно трансформировались.
С моей точки зрения, основной тренд современности это поиск. Поиск форматов взаимодействия и управленческих форматов, поиск технологических решений. Пару лет назад говорили о том, что Docker это конец истории. Сейчас мы уже думаем: да ну, наверняка будет что-то еще. Продолжается поиск решений для повышения степени иммутабельности кода, сборок, окружений, средств изоляции. Это нужно чтобы снижать или хотя бы сдерживать рост количества ошибок в усложняющихся экосистемах. Их ищут для того, чтобы сделать клиентский опыт еще более комфортным.
Зачем делать программу, которая редко ломается? Чтобы клиент был доволен. Зачем выстраивать пайплайн, который позволяет быстро выкатывать фичу? Для того, чтобы построить FastTrack, чтобы быстро понимать, что мы сделали что-то не то, исправили это, а клиент получил новые возможности, соответствующие изменяющимся потребностям.
У меня на работе до сих пор сотрудники спрашивают о том, как мы будем работать: удаленно или в офисе? Ответов нет, но наверняка как раньше работать уже не будет никто.
И во всех основных отраслях в этом году все мы похожи на сурка, выглядывающего из норы и пытающегося понять, что будет дальше? С моей точки зрения, это потрясающий для творческого начала период период пересмотра.
Мы находимся в периоде пересмотра, поэтому основная цель DevOpsConf 2021 рассмотреть вопросы вокруг взаимодействия разных цехов в рамках производства ПО, вокруг доступности, отказоустойчивости SRE-практик. Потому что все это аффектит клиентский опыт. В этом году мы в явном виде ввели в тематику контекст топологии. Например, прозвучал вопрос о том, кто такой тимлид в DevOps команде. Мы его услышали и постараемся дать ответ.
Я надеюсь, что конференция будет не суммой констатаций каких-то вещей, отраслевых решений, очевидностей, а станет окном, которое открывает сознание. Что ее участники осознали нынешнюю эру поиска и начали в ней активно участвовать. На нашей конференции есть замечательный постоянный докладчик Андрей Квапил, который рассказывает про Kubernetes, но всегда задает вопрос: Почему вообще это с ним нужно делать, что за извращение?. И это искусство, в определенном смысле слова.
То есть основная цель DevOpsConf в 2021 показать все разнообразие возможностей для команды и зародить идею, что мы все динамично развиваемся, это мир возможностей, и что будет завтра непонятно? Это все можно будет посмотреть, потрогать на конференции, позадавать вопросы спикерам оффлайн?
Именно так. Мы планируем, что на конференции будут два зала для докладчиков и еще один будет целиком отведен под дискуссионную зону и митапы со спикерами. Чтобы была возможность коллаборации, по которой мы так изголодались, участвуя в мероприятиях онлайн.
Конечно, вся яркость обсуждений зависит, в первую очередь, от участников. Роль докладчика состоит в том, чтобы подкинуть классную идею, стать огнем, который зажжет пожар в обсуждениях.
На любой конференции я воспринимаю себя не только в роли докладчика, но в первую очередь, в роли участника. Докладчик я всего на полтора часа (40 минут доклада, и еще где-то час нужно отвести на вопросы в дискуссионной зоне), все остальное время я участник. Если я не участвую, значит, я зря потратил время и деньги.
Мы стараемся отобрать темы, которые должны побудить к живым обсуждениям. Надеюсь, что у нас будет максимальный состав, который только возможно собрать на конференции вживую. А мы уж постараемся максимально поддержать огонь в нетворкинге и кулуарах.
Темы конференции
На конференции будут подниматься вопросы про эксплуатацию, про надежность программного обеспечения разрабатываемого продукта, про скорость процессов поставки, про командное взаимодействие. Будут ли освещены на DevOpsConf вопросы продуктовой разработки?
Таких тем в явном виде нет. Но когда мы говорим про DevOps в широком контексте, они все равно затрагиваются. Не бывает growth hacking без FastTrack, не бывает growth hacking без возможностей ставить фичу по факту ее коммита и прогона автотестов.
Что такое DevOps? С точки зрения философии Dev и Ops должны не ругаться, а научиться договариваться. Но почему только Dev и Ops? На самом деле, все участники производственного цикла для того, чтобы он был эффективен, должны научиться договариваться.
С моей точки зрения целевая аудитория конференции это представители всех цехов в рамках производства ПО, потому что есть те, кто непосредственно делают озвученные в докладах вещи, а есть те, кто должен понимать, что происходит в соседнем цеху. Для того, чтобы договариваться, нужно понимать, чем живут твои соседи. Наша конференция для инженеров и всех, кто должен понимать инженеров.
Хочется, чтобы на конференцию пришли все участники процесса, чтобы посмотреть, что происходит с другой стороны. Есть ли цель в рамках конференции научить взаимодействию оба лагеря?
Это звучит прямо как миссия! Ровно такую цель мы старались реализовывать в рамках DevOps Life 2020. Там даже были прямые столкновения. Например, доклад о том, почему техдир не понимает продакта.
Очень важно начать с возникновения интереса к тому, что происходит в соседнем лагере за стенкой. И здесь мы переходим к моей философии малых команд.
Нассим Талеб в книжке Рискуя собственной шкурой развивал мысль о том, что полноценное равенство-братство возможно только внутри трайба. Так уж устроено человеческое общество. Полагаться на любовь, вселенское братство не жизнеспособный путь в долгосрочной перспективе. Весь предыдущий опыт показывает, что в обществе подобные ценности не приживаются.
Я считаю, что команды должны быть малыми, потому что большие команды несут за собой формирование бюрократических машин и неповоротливость. У маленьких команд совершенно другая цель функционирования.
Тут мы снова возвращаемся к цифровизации клиентского опыта. Когда я работаю в малой команде, цель которой заключается в том, чтобы сделать удачную цифровизацию клиентского опыта, я максимально вовлечен в ментальную конструкцию вознаграждения (как потопали, так и полопали). То есть заинтересован в конечном результате: в удовлетворенности клиента.
А если я буду работать в большой команде, не уверен, что мотивация останется такой же сильной. Почему сейчас так часто говорят о цифровых трансформациях, в том числе, в энтерпрайзах и крупных компаниях? Что там происходит? Они вынуждены делиться на маленькие команды, потому что в большой команде с большой бюрократической системой интерес сотрудников в том, чтобы выполнить свои функциональные обязанности. А когда моя цель лишь в том, чтобы выполнить функциональные обязанности, никто не заставит меня интересоваться тем, что происходит за стенкой. Это две противоречащие установки.
Если мы работаем в парадигме малых команд, персонажа, не вовлеченного в общий процесс, перевоспитают. Либо, простите, от него избавятся. Жесткая закрытая позиция в малых командах обычно не жизнеспособна.
О командных топологиях
Сейчас я вижу проблему в понимании, как взаимодействовать между маленькими командами. Есть люди, которые отвечают за инфраструктуру, люди, которые отвечают за SRE практики, люди из других сервисов, и общение между ними нужно выстраивать.
Я бы хотел кейсов из российской индустрии, не только о том, что говорят в командных топологиях, но и о построении межкомандных взаимоотношений.
Навскидку, на DevOpsConf уже есть пара докладов, близких по тематике. Есть доклад о том, как используется Scaled Agile Framework, чтобы выстроить взаимодействие команд. Для меня это один из самых ожидаемых докладов из этой области.
Тематика безусловно важна. Я уже говорил о том, что мы находимся в поиске. И сегодня поиск направлен в сторону вопросов о том, как именно организовать взаимодействие между командами.
Когда мы говорим о командах и их взаимодействии, мы неизбежно вспоминаем об API. Должен быть decoupling, нужны правила взаимодействия. То есть мы говорим о некой универсальности. Но чем выше универсальность, тем дороже стоимость предоставления той или иной функции. Поэтому, в том числе, многие энтерпрайз-компании, которые заточены на расчеты финансовых показателей эффективности, трясет из стороны в сторону. Потому что, с одной стороны, хочется универсальности, с другой: правда в том, что она обходится дороже.
Я не знаю великой истины о том, как наладить межкомандное взаимодействие. Но считаю, что нужно искать хороший способ, приняв эту историю как данность. Могу привести метафорический пример, который меня тревожит.
Меня пугает такое явление, как GraphQL: вроде бы, мы все пытались уйти от энтерпрайз-шины, от некого большого бэкенда, резались на микро-сервисы, но в итоге, как мне кажется, сами себя обманули и при помощи GraphQL создаем пятую колонну новый старый бэкенд.
Мне кажется, инфраструктурные и платформенные команды это что-то типа GraphQL, и меня это смущает. Во всех крупных Agile фреймворках есть подобные команды: в Nexus это infrastructure team, в SAFe system team, в LeSS undone work team.
То есть везде есть так называемые платформенные команды. Но в SAFe это норм, к ним относятся как к константе, а в Nexus и LeSS заявляется, что это переходный этап, и со временем они должны уйти.
Опять же про взаимодействие взаимодействовать нужно не только Dev и Ops, но и внутри Dev бэкендерам с фронтендерами.
На одном проекте мы выстроили взаимодействие фронтенда и бэкенда таким образом: специально брали задачу в один спринт и бэкенд, и фротненд. В начале спринта бэкенд формировал спеку, показывал ее всем фронтендерам. А те хейтили ее, ругались, расходились, через час собирались снова и решали, что делать дальше. Это был лучший, с моей точки зрения, процесс взаимодействия: только совместно, в рамках одного спринта, обязательно с ранним согласованием интерфейсов. Всякий раз, когда я вижу, что отходят от этой позиции, неизбежно потом начинается: А это он! А это он!.
Если смотреть на успешные стартапы и сервисы, есть такая парадигма: зачастую они конечным пользователем используются совсем не так, как задумывалось авторами. Мне кажется, что возможное решение универсальных взаимодействий может быть таким: нужно смириться с тем, что вызывающий сервис будет использовать вызываемый сервис не так, как было задумано изначально. Весь клиентский опыт показывает, что правда за этим подходом.
Когда команды научатся делать свой сервис, возможно, проблема командных топологий решится. Но возникает вопрос о том, как консистентность данных, единые базы, CAP-теорема будут жить в условиях такого использования?
Ожидаешь ли ты на DevOpsConf доклады об архитектуре приложения?
По-моему, у нас уже есть парочка. Я периодически сам люблю делать подобные доклады. О чем мы говорим в контексте? Об архитектуре и о принципах архитектуры, когда целью доклада является проброс дальше: как тот или иной аспект архитектуры, заложенной в решение, влияет на жизненный цикл продукта. С моей точки зрения, DevOps включает в себя все, что касается жизненного цикла продукта.
Соответственно, мы с большим интересом рассматриваем любой контекст, влияющий на жизненный цикл продукта, и разбираем его с позиции того, как он влияет, какие последствия имеет для жизненного цикла продукта.
Простой пример: появились микросервисы. Разработчики этому рады, а классические Opsы совсем нет.
Архитектура аффектит жизненный цикл, и то, что одной стороне кажется откровением и спасением, другой приносит боль. Я видел это лично: когда у нас в одном из продуктов появились микросервисы, ко мне каждый день прибегали Opsы со словами: Артем, останови это немедленно! Пусть они прекратят!. Я выяснил, что они переживают о том, что невозможно будет читать логи, и предложил собраться всем вместе и решить эту проблему.
Любой аспект архитектуры прямо влияет на жизненный цикл. Любой подход несет как хорошее, так и плохое, и эти вектора рассмотрения очень интересны в контексте нашей конференции.
Доклады, которые хотелось бы увидеть
А что вообще ждет нас на конференции? Возможно, у тебя есть доклад, которого ты ждешь-не дождешься, чтобы послушать и обсудить его в зале?
Мне кажется, что наша конференция может стать ориентиром для того самого поиска и пересмотра, в эре которых мы находимся.
Есть тематика, которая, с моей точки зрения, по-прежнему освещается слабо, по-прежнему про нее говорится мало и разрозненно, по-прежнему нет попытки системного осмысления именно нашего, российского, опыта. Я говорю про SRE. Про SRE-практики у нас, к сожалению, в инфо-поле всех конференций, я слышу мало крутого, системного, из чего бы сложилась мозаика. Это по-прежнему остается набором практик и подходов.
Я сейчас выступаю не за то, чтобы превратить это в строго связанные процессы. Даже ITIL в 4 версии отошел от трактовки себя, как процессов жизненного цикла ПО. Но какая-то мозаика из этого набора должна появиться.
Почему важна мозаика? Потому что она позволяет понять, достаточно ли этого набора практик? Нет ли здесь лишних и избыточных? Для этого нужен системный взгляд на этот набор. А я его не вижу.
Поэтому тему SRE (Site Reliability Engineering) мне очень хочется прокачать. Я знаю, что у нас уже есть доклады по GitOps, по ChatOps. Это, конечно, не напрямую связано с SRE, но все же находится довольно близко. Я сам сейчас заявил доклад в названии которого значится, что SRE это тот же самый ITIL. Но уже в тезисах я напрямую говорю о том, что это то же самое, но не то же самое. По сути, речь идет о практике ITIL с человеческим лицом.
С одной стороны, нет ничего принципиально нового, с точки зрения самих практик. С другой стороны, с точки зрения того, как именно они заходят у людей, в командах, это абсолютно новая страница эволюции. Сейчас надеюсь склонить своих коллег на то, чтобы эту тему вынести на круглый стол и похаливарить немножечко.
Вся тематика по SRE, особенно с точки зрения попытки осознать ее системно, а не как набор разбросанных практик и подходов, для меня очень интересна. Это личное, я с 2004 года по сути дела занимаюсь, помимо всего прочего, SRE. Чем бы я ни занимался и разработкой, и архитектурой, и аналитикой со SRE я остаюсь всегда, все эти 17 лет. Поэтому тема для меня важна. Надеюсь, что она будет хорошо раскрыта.
А что делать на конференции прожженным технарям? Я услышал про GitOps, про ChatOps. Будет ли Kubernetes?
Конечно, будут и Kubernetes, и операторы Kubernetes. Инструментальный хардкорный трек мы традиционно стараемся держать на актуальном высоком уровне. Пока у меня вырисовывается план того, что один зал можно целиком отдать под инструменты, туллинг и всякую хардкоровщину, а во втором будем обсуждать топологии и процессы.
То есть будет поле для того, чтобы похаливарить, какой сетевой драйвер или service mesh использовать, а с другой стороны, будет возможность столкнуться мнениями с другими людьми и подумать о том, как сделать все еще лучше с точки зрения командного взаимодействия? Выглядит клево.
Мы работаем над этим. И делаем все возможное для того, чтобы так и было.
Профессиональная конференция по интеграции процессов разработки, тестирования и эксплуатации DevOpsConf 2021 пройдет 31 мая и 1 июня в московской Radisson Slavyanskaya. Программа ожидается насыщенной! Готовы творить будущее devOps вместе? Спешите за билетами, их можно купить тут.
А уже 24 марта, 19:00 (МСК) состоится митап Настоящее и будущее DevOps. На нем поговорим о текущих задачах DevOps-инженеров и погрузимся в технические детали управления релизами бессерверных приложений (AWS) с помощью terraform. Чтобы получить ссылку на трансляцию, нужно всего лишь зарегистрироваться.
Хотите бесплатно получить материалы предыдущей конференции? Подписывайтесь на нашу рассылку.
