Devopsconf

Прошлый год стал немалым испытанием для многих из нас, но дал он и толчок к новому восприятию, выстраиванию новых рабочих процессов и возникновению новых вопросов. Что находится на современном срезе индустрии 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. Чтобы получить ссылку на трансляцию, нужно всего лишь зарегистрироваться.

Хотите бесплатно получить материалы предыдущей конференции? Подписывайтесь на нашу рассылку.

Общепринятые мировые практики против проведения нескольких трансформаций в компании одновременно. И все же они возможны, при соответствующей подготовке, привлечении необходимых ресурсов и правильном мониторинге результатов. Плюсами и минусами одновременных трансформаций на конференции DevOps Live 2020 поделился лидер трайба IT4IT в ОТП Банке Максим Ефимов.

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

Как происходит любая трансформация в крупной организации?

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

Впереди перемен Джона Коттера мировой бестселлер, который может стать настольной книгой любого лидера трансформации.

Accelerate это произведение о том, как инженерные практики и DevOps культура меняются сами, меняют организации и бизнес, увеличивают performance и profitability любой организации.

Team topologies рассказывает о практиках организации взаимодействия между командами.

Основная мысль, которую можно вынести из книги Впереди перемен, это:

Никогда нельзя делать несколько крупных глобальных изменений одновременно.

Это анти-паттерн того, как выполняются трансформации, потому что такие действия влекут за собой:

• Гораздо большие риски;

• Размытие фокуса;

• Выгорание сотрудников;

• Взаимное негативное влияние трансформаций.

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

Кроме того, трансформации могут иметь негативное влияние друг на друга. И занимаясь, вроде бы, хорошими делами, вы в конце концов приходите к отрицательному результату.

Трансформация в ОТП

Предпосылки для начала трансформации в ОТП были серьезными: процессы критично устарели и усложнились, а TTM был очень низким (4 релиза в год).

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

И в ОТП решили сделать все и сразу:

• Изменить оргструктуру, перейти к Spotify-модели и внедрить продуктовые трайбы;

• Создать институты чаптеров и гильдий;

• Сфокусироваться на продуктовой разработке и поменять процессы IT;

• Провести редизайн IT ландшафта и модернизацию IT;

• Внедрить DevOps и автоматизацию;

• Кардинально привязать работу к облакам и микросервисной архитектуре.

Обсудим подробнее, что произошло по каждому из этих пунктов.

Трайбы и оргструктура

В ОТП запустили трайбы, отказались от линейной подчиненности и ввели матричное подчинение.

У каждого трайба есть трайб-лидер и трайб-техлидер. Первый отвечает за бизнес-направление и доходность, второй за IT-составляющую в каждом трайбе.

Трайб состоит из нескольких команд. У каждой из них есть product owner и бизнес-эксперты.

В ОТП есть своя особенность: в их командах нет выделенных DevOpsов и QA, это роли, которые выполняют разработчики.

Но для того, чтобы это было возможно, разработчики должны улучшать свои навыки и развиваться. Увы, нельзя сразу набрать исключительно крутых профессионалов, как это делают в Google. Не ко всем же выстраивается очередь из экспертов. В ОТП решили организовать институт чаптеров для того, чтобы сеньоры могли развивать чуть менее экспертных разработчиков в их профессиональной области.

Например, есть Java senior бэкенд разработчик Вася. Он бы хотел развиваться в качестве менеджера, а еще не прочь поделиться экспертизой. Вася становится лидером чаптера бэкенд разработки в трайбе 1. Он помогает наращивать экспертизу и повышать профессиональные хардскиллы людям из его трайба, которые занимаются Java бэкенд разработкой.

Важный нюанс: в компании хотели, чтобы люди переопылялись не только внутри трайба, но и кросс-трайбово. Для этого был запущен институт гильдий. Разница между подходами в том, что участие в трайбе условно обязательно. Если вы бэкенд-разработчик, то попадете к сеньору Васе в чаптер бэкенд-разработки, трайба 1. Гильдия это сообщество, можно сказать, кружок по интересам.

Например, в ОТП есть гильдия Kubernetes. В ней состоят сотрудники, которым интересна эта технология. В гильдии постоянно идет диалог на профильные темы, сообщество реализовывает автоматизации и лучшие мировые практики, то есть все, что связано с Kubernetes внутри организации.

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

Продуктовая разработка и изменение IТ процессов

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

Было важно организовать взаимодействие между всеми этими командами так, чтобы:

1. Продуктовые команды могли вносить изменения в функционал CORE систем;

2. Эти изменения не влияли негативно на стабильность в CORE системах;

3. Сохранялся необходимый темп доработок.

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

IT модернизация и редизайн IT ландшафта

Для того, чтобы все вышеописанное стало возможно, в ОТП решили создать слой API вокруг CORE систем.

Например, есть платформенная команда, развивающая сервис В. Она, посредством API, взаимодействует с сервисом А, который развивает продуктовая команда. В ОТП выработали стандарт, проясняющий, каким образом можно делать интеграции, как они должны работать и как организовано синхронное/асинхронное взаимодействие.

DevOps и автоматизация IT4IT (enabling team)

Если вспомнить про Team Foundation, IT4IT та самая enabling team.

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

В ОТП не стали выбирать путь создания пайплайнов за команды. Вы ведь помните, что DevOpsов в командах нет?:) Эксперты из IT4IT приходят в команду, которой требуется определенная помощь (например, с пайплайном). В этом случае члены команды разбираются в проблематике с девелопером и вместе пишут пайплайн.

Почему был выбран именно этот путь? Есть ведь распространенная альтернатива создание пайплайна вместо команды. Давайте посмотрим, как бы это выглядело на практике: эксперт из Enabling team делал бы пайплайн, отдавал его в эксплуатацию и уходил из команды.

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

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

Облака и микросервисы

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

В ОТП выбрали подход использования облачной инфраструктуры, заключили договор с провайдером и начали осваивать public clouds. Важный нюанс: речь идет о банке, где очень беспокоятся о безопасности. В публичные облака договорились выносить только то, что не содержит чувствительных клиентских данных.

Сейчас в ОТП идет работа над внедрением Private cloud, которое позволит размещать любые сервисы и даст командам возможность еще более гибко управлять своей инфраструктурой. В дальнейшем public и private будут связаны. Командам не придется ждать, пока будет создана необходимая классическая инфраструктура. Это положительно отличает ОТП от других банков.

Все эти изменения произошли буквально за полгода.

На данный момент в ОТП уже есть:

• 8 трайбов, 60+ команд и продуктовая разработка;

Часть трайбов сфокусирована на определенных бизнес-направлениях, а еще есть три IT трайба, которые поддерживают CORE-платформы, общебанковские сервисы и сервисы для IT.

• Матричная структура и функционально/административная подчиненность;

• Чаптеры и гильдии по всем трайбам;

• Слой в 60+ API вокруг CORE-систем;

• Большая часть (90%) команд находятся на централизованном стеке CI/CD;

Изначально у всех были и GitLab, и Jenkins, и инстансы Nexus. Однако централизация важный аспект для банка. Она позволяет ускорить наращивание экспертизы, упрощает обмен опытом и знаниями.

Уроки, вынесенные во время трансформации

Lesson 1. Негативный эмоциональный фон

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

Настолько, что несколько человек решили уйти без какой-то конкретной причины, а просто из-за ощущения неопределенности. Казалось, что ситуация тяжелая, но обратившись к сухим фактам, в ОТП поняли, что даже в самый пиковый по уходам месяц среднегодовой показатель текучки персонала не превысил 13%, при рыночном бенчмарке в 10-15%. То есть происходящее ощущалось страшнее, чем было на самом деле.

Кроме того, оказалось, что всех уходящих объединяло одно желание: они хотели просто писать код. То есть you build it, you run it, DevOps, автоматизация и прочие штуки были им не интересны. Таким узко-специализированным профессионалам стало сложно продолжать получать удовольствие, когда вокруг наступили всеобщие эджайл и гонка за тайм ту маркетом. Сложившаяся ситуация была взаимовыгодной: уходящие, будучи крутыми профи в своей сфере, нашли себе команду по душе, а в ОТП продолжают развитие культуры, не тратя силы и время на перевоспитание тех, кому это не интересно.

Lesson 2: Внезапный COVID

Следующий важный момент, с которым все столкнулись в 2020 году это пандемия, которую никто не мог предусмотреть. Любая трансформация достаточно хрупкая вещь, неустойчивая к внешним изменениям. С учетом количества изменений в ОТП, эта хрупкость была гораздо более заметной.

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

Lesson 3: Измерения важная часть DevOps культуры

В ОТП хотели понять, насколько происходящие внутри организации трансформации, успешны, чтобы понимать, правильно ли заданное направление.

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

Поэтому было принято решение запустить ручной assessment и условно измерить, насколько в командах все хорошо с точки зрения:

• Процессов;

• Техники;

• Архитектуры.

Когда assessment был запущен, его показали топ-менеджменту, и все сказали: Вау! Круто! Давайте это запускать везде, где только сможем. И в этот момент было принято важное решение о том, что полученные оценки не должны стать KPI. Ведь assessment базируется на честности и открытости. И ОТП доверяют своим сотрудникам какая же DevOps культура без доверия?

В какой-то момент heatmap выглядел так (это только часть, просто чтобы дать некоторое общее видение):

Есть определенный трайб, в нем команда 1,2,3, а у них несколько приложений. Базируясь на их ответах, можно понять, что происходит, и построить heatmap вместе с Agile коучами и архитекторами. Здесь можно увидеть интересующие практики, подчеркнуть сильные стороны трайба и команды, наметить основные зоны роста.

В дальнейшем планируется, что, как минимум, техническая часть этого assessment будет автоматизирована.

Кроме того, принято решение о том, что в ОТП станут опираться на четыре основные метрики DORA, о которых много говорится в Accelerate. Например, есть идея, чтобы Lead time распадался в дальнейшем на все составляющие SDLC процесса, которые происходят условно от события git push до выкатки в продакшен. Таким образом, его можно будет измерить. А каждая из составляющих второго уровня метрик распадется, в свою очередь, на еще большее количество технических метрик (наличие и использование код-ревью, сколько времени согласовывается pull request и пр.).

И, конечно, этот assessment будущего по-прежнему не будет являться основой для KPI.

Lesson 4 Любая трансформация это в первую очередь люди

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

Важно управлять ожиданиями со старта трансформации. Сейчас даже на этапе интервью в компании уделяют большое внимание проверке вовлеченности: насколько человек в принципе готов к продуктовой разработке, как относится к T-shape или готов ли он надеть на себя шапочку QA, когда и если это потребуется?

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

Подытожим

Что в ОТП вынесли для себя:

• Запуск нескольких трансформаций значительно увеличивает риски неуспешности каждой из них.

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

• Важна плотнейшая работа с людьми, в том числе:

Информационные события и постоянный подогрев информационного поля;

Трансформация в ОТП протекала исключительно в правильно сформированном информационном поле. Чтобы у людей всегда было понимание, что происходит в каждый момент времени, пришлось серьезно вложиться во внутренние митапы, конференции, информационно-популяризационные мероприятия;

Персональное общение и индивидуальный подход.

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

• Существенные единовременные затраты.

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

• Во время трансформации рекрутменту придется несладко.

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

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

Профессиональная конференция по интеграции процессов разработки, тестирования и эксплуатации DevOpsConf 2021 пройдет 31 мая и 1 июня 2021. Билеты на нее вы можетеприобрестиуже сейчас, успев сделать это до повышения цены.

С 1 апреля стоимость билетов на наши ближайшие конференции:TeamLead Conf 2021,DevOpsConf 2021иHighLoad++ Весна 2021возрастет.

Хотите получать полезные материалы по DevOps?Подписывайтесьна рассылку.

Монолитная и микросервисная архитектуры два диаметрально разных подхода. Во время круглого стола на конференции DevOps Live 2020 столкнулись адепты этих архитектур, которые в формате баттла искали ответы на самые актуальные вопросы. Избыточны ли ресурсы на каждый микросервис? Есть ли необходимость в постоянном рефакторинге? И как грамотно организовать рабочее место?

Адвокатом микросервисов выступил Алексей Шарапов, а обвинительную речь зачитал Андрей Булов. Оба сотрудники Deutsche Telekom IT Solutions стратегического подразделения крупнейшей в Европе телекоммуникационной компании Deutsche Telekom и не новички в обсуждаемом вопросе.

Андрей Булов: Я работаю в довольно крупном энтерпрайзе, в котором берут свое начало молодые стартапы. Побывал в разных ролях: архитектора, девелопера. С 2016 года начал писать на микросервисах.

С тех пор я невзлюбил паттерн Microservice as a goal, которым грешат многие энтерпрайзы, и стал пропагандировать здравый смысл. Честно говоря, я считаю, что микросервис и текущая разработка это что-то типа Spotify в Agile: все хотят внедрить, но не все понимают, зачем это нужно.

Тема этого мини-баттла родилась чуть ли не из кухонного спора. Я устал всем доказывать, что микросервис это не Грааль, не панацея, и готов поделиться своим мнением.

А еще я люблю лямбды, и считаю, что микросервис это некое переходное звено.

Алексей Шарапов: На данный момент я являюсь DevOps евангелистом. То есть хожу и очень громко всем говорю: Давайте делать DevOps!. Я в разработке с 2010 года. Занимался разработкой фронтенда и немного бэкенда. С 2015 года влюбился в DevOps и DevOps-практики. Стараюсь заниматься ими ежедневно и приносить счастье нашим разработчикам.

Я работаю с Андреем в одной компании. Это крупный энтерпрайз. И у нас есть исключительно микросервисные проекты, которые я полюбил всем сердцем. Поэтому я выступлю адвокатом микросервисов.

Андрей Булов: Начнем с меня. Почему микросервисы это плохо? Во-первых, потому что это очень дорого. Почему-то считается, что у всех, как у Google, есть куча намаринованных маленьких серверов, в которые можно засунуть маленькие сервисы, и все будет прекрасно работать.

На самом деле, вам придется купить облако и Кубер, и во всей этой виртуализации будет работать Docker, в котором зашиты ОС Java-машина, Application Server и микросервис, раздающий три строчки. А вы будете греть воздух всей этой чудесной инфраструктурой.

С точки зрения программной оптимизации, микросервис это постоянная перегонка из строк в строки. Это съедает массу памяти, и возникает нагрузка и на сеть, и на программистов. Микросервисы дорого имплементировать, и не всегда понятно, зачем люди их выбирают.

Тот же монолит или мелкая галька прекрасно выполняются на Bare Metal, не требуют особых ресурсов, Application Server JVM. И внутри себя они общаются по бинарным внутренним протоколам, байтики бегают по серверу: все прекрасно и довольно быстро работает.

Да, можно писать не на JVM, но все равно выходит недешево. Микросервисы обходятся дорого с точки зрения перформанса, скорости разработки и работы внутри.

Алексей Шарапов: На все это могу ответить, как человек, занимающийся инфраструктурой в крупных компаниях последние несколько лет, что мы можем делать очень много классных вещей. В первую очередь, ограничивать минимум. Если на наш сервис нет нагрузки в спокойном состоянии, можем сделать ему минимальные ресурсы. Мы должны содержать Kubernetes-кластер, какие-то дополнительные сущности, но запуском внутренних компонентов можем управлять очень-очень тонко. И если в какой-то момент нам на определенное время нужны сущности, мы можем использовать CronJob. А еще Openfaas, о чем часто забывают. Мы не греем наш кластер ненужными сущностями, а запускаем только то, что необходимо.

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

Например, можно использовать те же самые AWS лямбды и запускать в них какой-то код да, может быть, это будет не в кластере, а отдельно. Кроме того, не стоит забывать, что у нас есть Kubernetes-кластер. Мы можем не иметь его у себя, а запускать где-то на стороне. Такую возможность предоставляет облачный провайдер.

Не стоит забывать и о том, что когда мы запускаем на Bare Metal, нужно какое-то общее окружение, с которым мы работаем. Если все это учесть, получается даже чуть больше, чем в кластере Kubernetes.

Андрей Булов: Микросервисы это штука, которая требует некоей Java-команды и постепенного обучения. То есть вы девелопите какой-то микросервис, и в нем может постепенно меняться его бизнес-контекст. Многие забывают, что помимо обычного советского рефакторинга, который нужно делать практически каждый день, микросервисы еще требуют бизнес-рефакторинга. Если в монолите вы можете просто порефачить модули и сделать git push force, как тимлид или девелопер, то в микросервисах вам придется договориться с другими командами, с другими людьми и, например, перенести функционал из одного микросервиса в другой.

Мой личный опыт: когда разрастается какой-нибудь важный микросервис типа Order-микросервиса, или Booking-микросервиса, который выполнял 90% функционала приложения, по-моему, немного теряется смысл. Нам требовался временный рефакторинг в заказной разработке или в бизнесе. Довольно трудно продать людям, которые заведуют деньгами, что нам нужно еще пару спринтов, чтобы перекроить бизнес boundaries наших микросервисов. Потому что с первого раза (и со второго, и с третьего) мы не смогли понять этот контекст, зато теперь научились.

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

Алексей Шарапов: С мыслями о рефакторинге я не согласен. Если API меняется от версии к версии, возможно, это включает в себя несколько проблем, которые больше на совести девелопера, разрабатывающего эту часть. Либо нужно запланировать, что не стоит вводить постоянные изменения, включая новый функционал микросервисов.

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

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

Как всегда, когда собрались архитекторы, происходит рефакторинг ради рефакторинга. Но нужен ли он здесь на самом деле, или хочется впихнуть то, что в формат микросервиса впихивать не нужно? В монолите мы привыкли к тому, что можно что-то переписать, поменять модуль, и все классно! Но чтобы отрефакторить монолит, которому 20 лет (а я с таким сталкивался в реальном мире, это не сказки), только для того, чтобы разобраться, как это сделать, нужно полгода. И это без учета времени на необходимые изменения.

Андрей Булов: Микросервисы copy & paste driven development. Согласно идеологии микросервисов, в них не должно быть общих зависимостей, кроме какого-нибудь спринга, или общих либ. Но почему-то все забывают о том, что когда микросервисы пишутся для энтерпрайза, пусть и не очень кровавого, у него есть enterprise-specific вещи. А есть еще базовые, типа общей аутентификации, общего логирования, общих доменных объектов.

В зависимости от упорства адептов микросервиса, мы будем либо копипастить весь этот код между нашими микросервисами, либо сделаем библиотеку, либо вынесем это в отдельный микросервис.

Я прекрасно помню кейс, когда мы деплоимся на какой-то init или prod, у нас собираются нормально десять микросервисов, а одиннадцатый бабах! падает. Мы забыли туда скопипастить наш общий user-объект, в котором есть пермиссии. И с матами, конечно, все это дело правим.

Поэтому от идеологии всегда приходится отступать, и делать либы. Но тогда это уже перестает быть микросервисом.

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

За это я микросервисы не очень люблю.

Алексей Шарапов: В этом моменте я с тобой согласен, но не во всем. Мне нравится подход, когда библиотека выносится отдельно, и все ее куски делаются при помощи CTRL-C CTRL-V. С июля мы начали новый проект, в котором изначально используется микросервисный подход. И я слышал что-то подобное от наших архитекторов: либо мы копируем, либо выносим в библиотеки.

Но подключать библиотеку стоит, наверное, на стадии сборки самого микросервиса. А мы сейчас говорим про наш энтерпрайз Agile, и в этом нет ничего страшного. Это просто зависимость, которая будет выполнять близкий функционал. Либо к чему мы пришли только спустя четыре месяца работы стоит выносить этот функционал в отдельный микросервис.

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

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

Андрей Булов: Собственно, именно поэтому: в микросервисах нет единого хорошего стандарта, а есть набор практик и адепты, каждый из которых агитирует за свое. Если микросервис разрабатывает программист или команда программистов, вы получите свой уникальный стиль микросервиса с такими вещами, как POST vs PUT (холивар на кухне), и рассуждениями о том, какие ошибки мы возвращаем при валидации, какое возвращаем время и в каком стиле мы возвращаем API.

Это требует либо постоянного ревью: чтобы пришел архитектор или лид-девелопер и вставил руки в нужное место, либо нужен общий гайдлайн на проект. Но опять же, общих best practices для микросервисов, к сожалению, нет. Адепты спорят друг с другом. И ты думаешь: Хм, разработчик Василий так любит двухсотый код возвращать, надо учесть эту специфику. А этот, наверное, 404 бросит. Ведь тут не сервер упал, просто у него код ошибки такой. Либо требуется централизованное управление, и тогда теряется весь смысл микросервисов. У тебя получается команда с многими модулями, которые просто деплоятся отдельно, и архитектор ходит и пишет для них гайдлайны.

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

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

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

По поводу всего остального. Во-первых, инфраструктура as a code становится проще. То есть деплой становится everything as a code, а все части деплоя, инфраструктуры и самого кода вы можете посмотреть в Гите. Разработчику проще, когда он деплоит какое-то количество микросервисов, и отлавливает эти ошибки быстрее. Ему не нужно лезть в тяжелый монолит, рассматривать его и пытаться понять, что происходит. Он понимает, что происходит от написания первой строчки до попадания на ProdStage, и на каждой отдельной части.

Плюс выпуск происходит намного быстрее, и ему легче свериться с документацией. Ему не нужно разбираться с внутренними взаимодействиями, с тем, как работает система. Он написал свою часть. Видит, с чем это все вместе работает, и может выпускать этот кусочек. С Андреем я согласен в одном: в команде должны быть люди, которые понимают, что они делают. Даже несмотря на кровавый энтерпрайз, они должны понять, что они создают микросервис по определенным законам. И все будет круто до тех пор, пока люди соблюдают установленные правила, хотя бы из взаимоуважения.

Андрей Булов: Да, давайте наймем команду космонавтов, которая нам все хорошо сделает.

О, мое любимое.

На самом деле картинка это практически реальный ландшафт системы и реальный кейс. Прибегает ко мне заказчик, говорит: Слушай, там бага. Из Гуя на проде неправильно заказ считается для такой-то модели машинки для немецкого рынка. Для остальных все хорошо работает. Вот тебе логи, прод не трогай. На деве это воспроизводится. И вот тебе данные.

На деве все хорошо. Значит, мне нужно поднять у себя Docker, кучу микросервисов с базой, учесть взаимодействие этого всего. А потом сидеть, как обезьянка, переключаться между PyCharm и смотреть, куда приведет тот или иной breakpoint. Потому что проблема очень скользкая, и просто логами ее вычислить невозможно.

С точки зрения вычислительных мощностей, поднять у себя такое количество докеров, конечно, можно, но тогда тормозить будет зверски. Если мы подключаемся к какому-нибудь Куберу и удаленно пробрасываем порты, конечно, оно может сработать. Но тогда получается, что один девелопер блокирует все девовское окружение, а другие сидят, курят бамбук или девелопят локально. Либо нам нужно много-много окружения, иначе необходимо много-много серверов. Что возвращает нас к первому вопросу: все это совсем не дешево.

А в-третьих, чтобы банально сграбить данные со всех этих микросервисов, из БД, мне нужно залезть в каждый, вытащить какие-то данные и посмотреть, совпадают ли они. Потому что у нас констрейнтов нет. А потом нужно это все себе залить, или залить на дев, поднять и посмотреть, чтобы заработало. Да, чтобы еще у меня port forward не умер в самый интересный момент, потому что процесс растянут во времени.

Поэтому дебажить микросервисы я люблю очень сильно!

Алексей Шарапов: Андрей прямо по больному прошелся. Конечно, дебажить микросервисы довольно-таки сложно. Но, на самом деле, команда должна просто привыкнуть к освоению новых инструментов.

В мыслях о port forwarding я с Андреем абсолютно не согласен. Если приходится пробрасывать огромное количество каких-то сущностей в единицу времени, наверное, мы опять говорим о том, что у нас слишком большое количество взаимодействий. Нужно вообще прекратить это дебажить, поднимая какие-то локальные контейнеры. Либо, необходимо иметь достаточное количество неймспейсов. Понимайте изначально, во что вы вписываетесь. Да, это может быть дорого. Вы можете поднять какой-нибудь свой minikube.

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

Кроме того, можно прекратить создавать костыли, и позвать человека. Можно окружить все трассировкой, например использовать Jaeger, посмотреть, собирать логи с каждого момента. Логов не хватает: значит нужно посмотреть, как микросервисы взаимодействуют между собой. При нормальной трассировке можно обнаружить, где происходят падения. Придется поднять буквально несколько сервисов. И это займет не так много времени и ресурсов. И жизнь твоя улучшится.

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

Андрей Булов: Видимо, я морально устарел в микросервисах.

Есть еще вот такой интересненький кейс:

У нас есть микросервис со своими бизнес-контекстами, сервис, который делает Order, сервис, хранящий в себе Vehicle. Есть API GW, есть GUI. К нам приходит продактоунер и говорит: Эй, ребята, мы принимаем заказы на машины, и теперь занимаемся отделкой салона.

И начинается парад независимости. Это когда команды внедряют у себя один параметр и проносят его через все независимо друг от друга.

А потом начинается игра: давайте все это дело проинтегрируем! Мы возвращаемся к предыдущему слайду: как это дебажить?

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

Это абсолютно реальный пример: нам никуда не деться от того, что придется пронести бедный параметр VehicleCover через все микросервисы и базы. Давайте это сделаем и помолимся, чтобы все программисты микросервисов назвали это правильно, соблюли чудесный capital letter, сделали везде одинаковый тип, воркчар был правильным, все это прошло ревью архитектора и т.д.

В монолите это сделать довольно легко: открываем идею, смотрим, даем кому надо по рукам профит! В микросервисах придется побегать между командами.

Алексей Шарапов: Я согласен с тем, что это будет боль. Но самое главное не создавать SOA в этом случае. Это же не микросервис: протаскиваешь через распределенные данные монолита из кусков какое-то значение, которое ты должен везде обработать. Почему твое значение не может быть отдельным микросервисом, из которого все берут данные? Или который это обрабатывает отдельно от всех, чтобы не нарушать состояние остального. Если такие требования появились, как их вписать со стороны идеологии? А если это вам не подходит, зачем вы вообще начали делать микросервисы?

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

Я такое видел: берут какой-то проект, для которого не нужны микросервисы. Но нет, мы просто обязаны сделать классно и красиво, ведь решение о необходимости микросервисов спустили сверху. Но ведь главное не применять технологии там, где они не нужны. Плохо делать что-то просто потому, что так захотелось.

Больше по этому поводу мне нечего сказать. Наверное, это вопрос ко все участникам разработки.

Андрей Булов: О, я тебя заразил здравым смыслом!

Тестирование.

Мой любимый вопрос на Lead Test Engineer или Test Manager. Я рисую такую картинку и говорю:

Это система, которая работает с деньгами пусть будет продажа машин. Если мы там что-то потеряем, человек не получит машину, а компания не получит деньги, плюс ее ждут репутационные издержки и т.д. Вопрос: как нам релизиться раз в спринт, не падать в проде и не попасть на штрафы? Напиши мне такой процесс тестирования, и я смогу убедить разработчиков написать тест. Но только напиши мне так, чтобы я был уверен хотя бы на 85%, что я в проде не упаду.

На этот вопрос, к сожалению, пока мало, кто ответил. Все почему-то говорят про модульные тесты, про то, что нам нужно окружение, еще одно окружение, еще одно окружение.

Конечно, правильно было бы иметь какой-то хороший пре-прод, в котором мы все это тестируем. Но это не всегда возможно. В классической разработке с классическими программистами, тест-лидами, менеджерами и т.д., мы имеем все эти dev-test, int, какое-нибудь staging-окружение, куда мы релизимся по определенному процессу. И мы должны понимать, что у нас все это будет протестировано.

Ни технически, ни организационно идеальных практик пока, к сожалению, нет. В общем, тяжело это работает. С монолитом проще: взяли Selenium, все протестировалось, смоками покрыли, выкатываемся в прод все работает. Мы красавцы, мы восхитительны!

Алексей Шарапов: А как же без проблем, Андрей? Может быть, в том, что касается тестирования, я с тобой согласен. Я не то чтобы заразился здравым смыслом. Просто не так глубоко погружался в проблемы тестирования.

И я еще раз призываю прекратить думать о микросервисе, как о монолите. Мы привыкли тестить так, чтобы было красиво, но теперь условия изменились. Мы, например, во время тестирования очень активно используем testcontainers. И это решает часть проблем.

Я все время говорю о том, что нужно иметь достаточное количество стендов. Я хожу в свои команды и напоминаю: Ребят, поднимите нормальное количество стендов, прекратите страдать на одном, который упал, после чего все сломалось, и вы мучаетесь. Распределите запросы, и страдания закончатся. Человек, который у вас близко работает с инфраструктурой, как мне кажется, должен взаимодействовать и с и с девелопмент командой. Хотя бы для того, чтобы подойти и сказать им: Поднимите стенды, все пробросьте к себе на машину, используйте testcontainers, прекратите тестить это, как монолит, и все будет хорошо.

Не надо тащить за собой опыт монолита, применять его на микросервисах и говорить блин, ничего не работает, как нам теперь жить, и что же с этим делать?

Частично, Андрей, я с тобой согласен, но и монолит не отменяет множества стендов. Я не могу себе представить отчаянных людей, которые запустили монолит на одной машине, чтобы сэкономить свои ресурсы, и сказали: Все классно! Мы никогда не падали, а во время деплоя там огромный downtime.

Андрей Булов: Уел!

Хочу рассказать про каждому разработчику по своему Куберу. CI/CD моя любимая тема.

Во-первых, чтобы это все собрать, нам нужен очень хороший Jenkins с кучей слейвов. В разработке возникает несколько вопросов:

• Мы пересобираем все сервисы каждый коммит?

• Сколько нужно слейвов на сборку?

Приходит бизнес и говорит:

А сколько нам нужно заплатить за сборку? Сколько-сколько? Нет, вон там стоит под столом сервер, давайте его использовать.

• А почему все так медленно работает?

У меня пять разработчиков сделали коммиты, и пять раз подряд пересобирается весь этот зоопарк.

Помимо очень мощного окружения нужен очень мощный CI/CD.

• Можем ли мы считать, что у нас работает система, когда собралось 60 микросервисов, и 61, который мы не релизим, упал?

У меня вопрос: можем мы зарелизиться, или нет?

Тот сервис, конечно, релизить не будем, остальные зарелизим. Какая радость от того, что мы в проде упадем?

А нужно ли вообще смотреть, что с этим микросервисом? Мы его уже 100 лет не трогали, что-то упало.

Ну, не знаю. Может быть, сам заработает.

С continuous delivery отдельная песня, когда нам нужно заделиверить что-то. Мы деливерим, деливерим, деливерим это в прод бах! падает какая-нибудь джоба, нам это нужно пересобирать все по новой, и т.д. В общем, это гораздо больнее, чем собрать один Maven clean install, прогнать все тесты все работает, мы великолепны.

Алексей Шарапов: А как жить без CI/CD? Попробую описать, что я имею в виду.

Мне кажется, что CI и CD необходимы для любого проекта. Ты используешь CI в проекте с монолитом, с микросервисами. Почему появляется необходимость на каждый коммит пересобирать все-все-все микросервисы? Здесь стоит опять задуматься о независимости. Возможно, разговор тут идет не про инструменты. Однако, предположим, какой-нибудь GitLab CI с его Docker runners сильно сэкономили бы тебе ресурсы. Мы не говорим про этот страшный Jenkins, который перегружен, огромную Java-машину. Мы можем использовать что-то более легковесное.

Может быть, каждый CI/CD должен заканчиваться на том моменте, где это на самом деле необходимо. Если речь идет об огромном монолите, который работает в нашем энтерпрайзе, скажу честно, CD у нас поскольку постольку, просто потому что есть такие условия. Однако же мы предоставляем и такой инструмент. И мы не берем jenkins , как мы привыкли, а находим необходимый инструмент легковесный, удобный. Именно с его помощью мы что-то делаем, и это классно работает.

Я просто не могу себе представить, как можно жить без CI/CD. У нас микросервисы это огромный проект, все они собирались отдельно. Был микросервис, который жил с самой первой версии, никогда не менялся, мы его не пересобирали, однако же он всегда работал. Вот она независимость.

Андрей Булов: О, вот это мой любимый вопрос на собеседовании отдельные DevOps команды.

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

Мой любимый вопрос DevOpsам: как написать такую чудесную синюю кнопку, которую жмешь, все базы в один момент с каким-то снепшотом бэкапятся. А еще все это можно потом либо восстановить одной зеленой кнопкой, либо слить разработчикам на дев-окружение. Причем мне нужно не ощущение: Ну, в принципе, нормально! Вроде, все закончилось, а что-то более доказательное. Если бизнес говорит: Ребята, это какая-то фигня, что мы ему можем возразить в ответ? Что, по нашим ощущениям, все должно работать?

Как останавливать кучу баз в один момент в микросервисах это хороший вопрос. Сможешь ли ты на него ответить?

Алексей Шарапов: Нет, потому что это один из самых сложных вопросов касательно микросервисов.

Есть разные подходы на данный момент. Предположим, что существует сложная система с балансировкой через Patroni. Мы в наших реалиях никому не можем передать имеющиеся snapshot базы, просто потому что это невозможно.

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

То есть нужно постараться максимально избегать ситуации, когда все это придется в огне восстанавливать, и это уже решит часть твоих проблем. Я обычно делаю ставку именно на это. Но, на самом деле, подходов много. Когда приходишь, а тебе говорят: Мы сделали одну базу, она крутится, все к ней обращаются. А у нас микросервисы, что теперь делать?, бывает страшно. Об это можно открыть отдельную дискуссию.

Андрей Булов:

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

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

Получается, все то, про что я говорил: все выливается в эти проблемы. Используйте паттерн мудро и только там, где это необходимо. Аминь.

Алексей Шарапов: Абсолютно согласен не нужно применять микросервисы там, где этого не требуется. Я хочу привести пример того, как я это представляю. Мы не можем запустить проект в продакшен, пока не будет написано большое количество бизнес-логики. Но мы можем посмотреть на это с другой стороны: у нас есть простой бизнес. Предположим, я сейчас делаю автоматическое создание ресурсов внутри нашей сети.

Крошечный скейтбордик это первый маленький микросервис, который дергает по REST какой-нибудь AWX и запускает создание первой машины: класс, продукт уже есть, и я могу пользоваться этим каждый день. Потом я хочу сделать самокат. Прикручиваю туда базу данных, чтобы ходить в стейты. Дальше велосипед, мотоцикл, в конце машина это уже AWX плюс Terraform, Cloud, которые взаимодействуют между собой через разные микросервисы, Kafka. Я могу создавать какие-то вещи уже с первой улыбающейся рожицы, которая на меня смотрит (LIKE THIS).

Или возьмем другой бизнес-кейс. Предположим, у вас магазин с напитками. Сегодня вы принимаете заказ с одним напитком, но когда у вас есть автомобиль, это уже огромная сеть ресторанов.

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

Профессиональная конференция по интеграции процессов разработки, тестирования и эксплуатации DevOpsConf 2021 пройдет 30 и 31 мая 2021. Но билеты на нее вы можете приобрести уже сейчас, успев сделать это до повышения цены.

А еще вы можете сами стать героями конференции, подав доклад.

Хотите бесплатно получить материалы предыдущей конференции по DevOps? Подписывайтесь на рассылку.