Этот хабрапост — интервью с Антоном Вайсом, совладельцем технологического консалтинга Otomato Software, обладателем более чем 15-летнего опыта в области высоких технологий. Является экспертом по техническому преподаванию, инициатором и соавтором первого в Израиле курса DevOps-сертификации. Антон участвует в международных конференциях и известен как крутой докладчик.
Мы поговорим на следующие темы:
- Разница в работе между Россией и Израилем;
- Разница между стартапами и гигантами, особенно в плане DevOps;
- Тенденция к увеличению сложности, и что с этим делать;
- Совмещение технических и нетехнических навыков;
- Быстрое обучение и внедрение в работу;
- Наиболее полезные практики и технологии из мира DevOps;
- На какие доклады стоит ходить.
Разница между Россией и Израилем
Олег: Расскажи, пожалуйста, кто ты такой и чем ты занимаешься.
Антон: Я — Антон, родился в Питере, но в 15 лет переехал в Израиль и с тех пор живу там. Последние двадцать лет в Израиле занимаюсь IT в разных его ипостасях. Из этих двадцати лет последние десять специализируюсь на всем, что связано с доставкой программного обеспечения: интеграцией, тем, что называлось в своё время configuration management, и тем, что теперь называется DevOps. Я работал в больших компаниях — в международных энтерпрайзах типа AT&T, BMC. Работал в стартапах. Последние четыре года у меня своя консалтинговая компания, называется Otomato Software, где мы занимаемся тем, что помогаем организациям оптимизировать процессы доставки и осваивать новые инструменты: то есть мы делаем и техническую часть, и всё что вокруг.
Олег: А разница есть между Россией и Израилем в плане работы?
Антон: С российскими клиентами я почти не работал. То, что меня связывает с Россией последние 3 года — это конференции. И в нескольких российских компаниях мы проводили что-то вроде аудита: приехали, посмотрели, разобрались, выдали какие-то рекомендации и уехали. То есть конкретно такой повседневной работы не было, поэтому мне сложно точно сказать, чем отличается. Я думаю, что везде есть всякое разное. То есть в том же самом Израиле у нас есть такие тяжёлые корпоративные организации, в которых люди работают уже по 15 лет, и всё очень тяжело двигается. И как бы они там ни пытались сделать какую-то трансформацию, улучшить процессы: они поговорят-поговорят, но… У нас есть такой клиент, с которым два года назад мы всё сделали и приняли все решения, разработали все программы, и в какой-то момент это всё застопорилось, мы оттуда вышли. Вот буквально пару дней назад встретил оттуда начальников, с которыми мы работали, говорю:
— Ну как?
— Ну так. Тяжело, — говорят, — делаем, вот сейчас что-то начинает происходить.
Спустя два года. Есть политика, есть зоны влияния. Есть люди, которые не хотят эти зоны влияния отпускать, соответственно, когда такая ситуация, очень тяжело что-то поменять. Ну а сам по себе инструментарий как-то движется вперёд. С другой стороны, в Израиле есть стартапы, в которых всё меняется очень быстро, легко поднимать новый тулинг, и они уже все cloud native и полностью сидят в облаке. Вот это, кстати, может быть одна из таких, ощутимых разниц между Россией и Израилем. В Израиле с публичным облаком гораздо проще. Из того, что я увидел. В России, например, кажется, всем, кроме стартапов, очень тяжело идти в публичное облако, а в Израиле всё-таки легче. Сегодня уже есть некое понимание даже у банков, у страховых компаний, что по крайней мере часть своих вещей можно выкатывать в публичное облако. И здесь никого не пугают контракты с Google и Amazon. Из того, что я слышал на конференциях в России, там всё-таки это всё ещё пока сложнее, ну даже с точки зрения санкций-не санкций и каких-то юридических вопросов.
Разница между стартапами и гигантами
Олег: Я понял. Кстати, где тебе интереснее и приятнее работается: в стартапах или в больших организациях?
Антон: Приятнее, понятное дело, в стартапах, потому что большие организации… ну реально просто материал очень тяжело двигается. Там есть свои преимущества, конечно. Если посмотреть на большие организации, то у них, например, гораздо больше того, что называется diversity. Большие компании просто из-за того, что им нужно много людей или из-за того, что это какая-то организационная культура, которая складывалась годами, готовы разных людей нанимать. Вот конкретно у нас в Израиле, например, в стартапах ты почти не найдёшь, например, арабов, их почти нет. В больших организациях с этим гораздо проще. А вот стартапы вырастают уже из какого-то культурного бэкграунда, в котором большинство участников — это в основном те самые белые мужчины. Там есть культура того, что нужно как следует порваться, и желательно поработать 10-12 часов в день, и это тоже маловато. Кажется, как будто бы у нас за спиной Москва (то есть Тель-Авив), отступать некуда, и поэтому должны вот здесь и сейчас кровью истечь.
Олег: А что с разницей в подходе к DevOps в маленьких и больших компаниях? То есть если ты, например, работаешь на два человека, ты можешь не настраивать себе CI/CD, а копировать артефакты по SCP.
Антон: С одной стороны, так. А с другой стороны, сегодня настроить CI/CD ещё не значит, что ты действительно делаешь continuous delivery. Но настроить себе пайплайн какой-то, если ты компания из двух человек, очень и очень просто. Если раньше тебе нужно было как-то заморочиться, то сегодня у тебя полно облачных сервисов. Написал YAML — и вперёд, поехали. С этим проще. На самом деле челлендж представляют из себя стартапы-переростки. Те которые вышли за 20 человек, и вот тут у них начинаются боли с масштабированием, потому что процессов нет. Раньше всё как-то работало, а тут начинается весь этот бардак, и непонятно, как нам сохранить эту былую динамичность и при этом вести процессы, и решить, кто ещё будет этим всем заниматься.
И вот тогда начинаются все вещи типа «у нас будет команда DevOps, которая будет отвечать за DevOps», мы знаем, к чему это в большинстве случаев приводит. Появляется бутылочное горлышко, и постепенно они растут туда, где сейчас находятся большие компании. В больших компаниях совсем другая беда, у них уже есть даже не бутылочное горлышко, а уже просто шлюз такой мощный, который открывается раз в день, и всё остальное время там накапливается огромное количество мусора. И вот они думают: «Как нам сейчас из этого шлюза сделать много маленьких шлюзиков, которые можно будет открывать гораздо проще?» То есть совсем другие проблемы. У стартапов проблема с тем, что «нас засасывает в воронку, как нам выплыть?», а у больших компаний — они уже в воронке, они уже в подземном царстве, теперь они думают, как им выплыть обратно наверх.
Тенденция к увеличению сложности, и что с этим делать
Олег: Ну и плюс технической части: когда у тебя мало людей, простые технологии, тебе надо знать какой-то базовый Linux, и всё. А при малейшем масштабировании тебе нужно какой-нибудь Kubernetes изучить, и это, кажется, проблема.
Антон: И это, несомненно, проблема. У нас была конференция буквально два дня назад, и было очень ощутимо что почти все, кто что-то там говорил, упоминали одно слово: «complexity» (сложность). Это стало каким-то определяющим словом вообще всего DevOps-дискурса сегодня.
Олег: А было так год назад?
Антон: В попытках сделать всё быстро, динамично, для достижения пресловутой гибкости мы себе накрутили такой сложности. Действительно, очень много маленьких пайплайников, которые по отдельности работают замечательно, а потом мы пытаемся собрать из всего этого какую-то картину мира, и вот там сложность вдруг и зарождается. Потому что мы из всех этих маленьких пайплайников теперь строим какой-то один процесс так, чтобы вся компания работала по-человечески.
Олег: И какой ответ? Как этой сложностью управлять?
Антон: Ну нет ответов, они в процессе рождаются. Мой доклад был об одном из таких решений. По большому счёту это всё к чему идёт? Я в своё время был заражён системным , в DevOps о нём много упоминается. Я заинтересовался, я почитал книжки Питера Сенге, Рассела Акоффа, Донеллы Медоуз — людей, которые в своё время системное каким-то образом начинали и по большому счёту основные его постулаты изложили. Одна из основных призм, через которые системное смотрит на мир — петли обратной связи. С этой сложностью сейчас возникают эти петли обратной связи, то есть сложность становится очень и очень высокой, мы начинаем искать инструменты для того, чтобы как-то эту сложность ну хотя бы взять в узду. Я не говорю уменьшить — взять в узду, чтоб не раскатало.
Появляются централизованные решения, по большому счёту даже Kubernetes — это что-то такое. У тебя есть централизованный control plane, который в тот момент, когда ты его контролируешь, будет контролировать всю сложность тех сервисов, которые бегут вокруг. Сервисное сито, тот самый service mesh, это такого же типа решение. Мы говорим: «У нас куча сервисов, нужно, чтобы они могли разговаривать как-то друг с другом, потому что они непонятно где сидят и непонятно, ответят им или нет, и они сами не справятся. Поэтому давайте мы сейчас вот так сделаем, в середине вставим некий вселенский ум, который будет им говорить, с кем можно разговаривать, с кем нельзя разговаривать, и охранять их, если им вдруг что-то грубое скажут в ответ». И с этим много вопросов. С одной стороны, это некая необходимость, потому что организации не справляются. Мы за последние пару лет помогали нескольким организациям переходить на новый смелый мир Cloud Native, особенно, когда это связано с ростом компании, с масштабированием, и люди просто теряются. Посредине всего этого находится какая-нибудь маленькая команда так называемых DevOps-ов, которым приходится писать тысячи строк YAML, для того чтобы как-то со всем этим справиться, и всё просто трещит по швам.
Cloud Native
Олег: Ты не можешь немножко объяснить, что такое Cloud Native? Потому что это стало каким-то баззвордом, сейчас все его на каждой стене пишут. Как ты это видишь?
Антон: По большому счёту всё началось с того, что появился подход «платформа как сервис», то есть когда нам понадобилось запускать гораздо больше ПО и гораздо больше веб-сервисов, чем нужно было раньше. Мы поняли, что выкатывать каждый сервис отдельно как любимое домашнее животное, которое мы знаем по имени и ухаживаем за ним всю жизнь, больше невозможно, нам нужно с ними справляться как с неким стадом. Для этого нам нужна какая-то однородная платформа, на которую мы сможем этот код забрасывать, а платформа будет достаточно умная, чтобы его обслуживать. Автопоилка, короче говоря, автопоилка-автокормилка для сервиса.
Пионерами этого подхода были Heroku. Они сказали, что для того, чтобы эти вот сервисы могли пользоваться нашими инфраструктурами, они тоже должны быть коровами. То есть, у них должны быть определенные качества. Так и появилось 12-факторное приложение, которое должно было в себе иметь как можно меньше устойчивого состояния. Такое приложение обязательно собирается неким конвейером, в котором проверяется его совместимость с платформой. Оно должно уметь быть resilient (устойчивым) — знать, что, если что-то пошло не так, то сразу падать не надо. С другой стороны, в неком смысле полагаться на платформу. В общем, некий гибрид такой. Понимать, что ты не сам по себе, что есть платформа и надо уважать её ограничения. По большому счёту всё началось оттуда.
Но почему-то этот подход «платформа как сервис» себя не оправдал, и обещанного бума не произошло. То есть да, было Heroku, потом вслед за ними сразу все большие ребята тоже подняли аналоги: Google App Engine, у Amazon — Elastic Beanstalk. Мне немало пришлось работать с компаниями, которые начинали с этого. Но в тот момент, когда ты делаешь что-то, что чуть выходит за границы разрешенного платформой, это превращается в ужасную головную боль. Потому что начинаешь натыкаться на стенки, которые везде. И как людям свойственно, когда они натыкаются на стенки, они начинают искать способ стенку прорубить.
Современный Cloud Native вырос оттуда: как сделать так, чтобы бежать всё ещё в облаке, пользоваться какими-то услугами платформы, но при этом ещё и обеспечить потрясающую гибкость всего, что происходит. Мы постоянно балансируем между гибкостью и простотой. Гибкость вызывает сложность, а упрощение и создание чёткой платформы всегда вызывает ограничения. Cloud Native — это, видимо, нахождение какого-то баланса между ограничениями облачной платформы и гибкостью, которую тебе позволяет облако с его автоматическим масштабированием, и у всего этого есть цена.
Олег: Наверное, сама организация должна как-то научиться жить процессно со всей этой штукой.
Антон: Естественно, естественно! Всё это накладывает отпечаток. Микросервисы тоже к этому относятся. По большому счёту, это представление о том, что у нас есть небольшие сервисы, небольшие приложения, которые разбросаны по облаку и могут находиться в любой момент где угодно, и их может быть сейчас 10 реплик, а завтра — 1500, это тоже всё часть Cloud Native. Представление о том, что мы не ограничены физическими границами дата-центра. По большому счёту, весь мир — моё облако, это совершенно замечательное видение, замечательное стремление, но у него есть цена, и цена эта — сложность, цена — то, что по большому счёту никто в голове не может уместить то, что будет происходить, когда наше приложение вдруг вырастет с 10-ти инстансов до 1500. Никто не может себе представить такое, и начинают возникать все артефакты масштабирования. Мы как люди, как операторы, не можем ничего с этим сделать, кроме как реагировать на происходящий хаос. И вот мы начинаем думать: «А как же нам так построить наше приложение и нашу инфраструктуру, чтобы, когда эти артефакты возникают, во-первых, их можно было предвидеть, а во-вторых, каким-то образом с этими артефактами справиться и продолжать функционировать?»
Совмещение технических и нетехнических навыков
Олег: У тебя есть доклады про технические вещи, например, про сервисное сито и есть доклады про лидерство, про менеджмент, всё такое. Ты вообще больше технический человек, или ты менеджер, или у тебя как-то по-другому устроено?
Антон: Я даже начал писать в какой-то момент об этом пост, не дописал пока. Я в некотором смысле разрываюсь чисто личностно между этими двумя вещами, потому что, с одной стороны, мне нравится понимать, как вещи работают, мне нравится с ними разбираться. Когда удаётся решить какую-то техническую проблему, это просто само по себе даёт потрясающее ощущение своих способностей, то, что называется instant gratification, немедленное вознаграждение, дофаминовый вброс: «Ох, круто, я могу, я решил». И от этого тяжело отказаться, с этого тяжело слезть. И поскольку это есть, я продолжаю заниматься техническими вещами. Новые технологии меня возбуждают: круто что-то расковырять, что-то понять. Из-за этого получается, что поскольку есть эти знания, то люди хотят их покупать, и я продолжаю их продавать.
С другой стороны, я понимаю, что это просто маленький кусочек большой картины, я достаточно долго проработал в индустрии, и я не могу не видеть, что технология — это всего лишь уголок большой системы, всего лишь один из компонентов. Я управлял командами, и понимаю, насколько важно учитывать взаимодействие технологий и инструментов с теми людьми, которые ими пользуются. В конце концов, информационные технологии, собственно, любые технологии, существуют для того, чтобы ими пользовались люди. И создавать технологии, не думая о том, кто ими пользуется, это совершенно бессмысленно. Технология сама по себе не интересна вообще, если не думать о её применении, а применение всегда связано с людьми, которые каким-то образом получают от этого пользу. И поэтому всё, что вокруг технологий, меня тоже очень сильно интересует. Я чувствую, что об этом необходимо говорить, я понимаю, что без этого всё действительно теряет смысл. До той степени, что мне иногда кайф посидеть, что-то там похакать в течение двух-трёх дней, иногда недель. Я могу увлечься какой-то проблемой, которая у меня не решается, я могу решить её, получить от этого потрясающий приход. Но потом я поднимаю голову от клавиатуры, смотрю вокруг, и я понимаю, что кругом происходит что-то, что проигнорировать я никоим образом не могу. И тогда код и ковыряние в Линуксе мне становятся совершенно неинтересными, неважными, и хочется начать решать проблемы на другом уровне, на человеческом уровне.
Как быстро разобраться в DevOps
Олег: Слушай, а ты можешь посоветовать что-нибудь людям, которые сейчас занимаются инженерией и изучением практик DevOps одновременно? Как в себя это всё впихнуть и в каком порядке? Условно говоря, как распланировать, может быть, свою карьеру, чтобы стать более успешным в короткие сроки?
Антон: Эх… Ну нет универсальных советов, опять же, по своему опыту. Я достаточно долго, наверное, первые лет 10 своей карьеры, был недоволен своим местом. Искал, что мне не нравится, фокусировался на этом, искал, чем мне было бы интереснее заняться. Но по большому счёту, ничего не предпринимал по этому поводу. Основной совет такой… В какой момент я считаю, что моя карьера пошла в гору? В тот момент, когда я начал разговаривать о вещах, которые мне были интересны. Область технического знания, даже не только технического, вообще сама по себе сфера информационных технологий — очень широкая, то есть можно быть и технарём: разработчиком, и тестером, и интегратором, и сисадмином — это всё разные вещи, там каждый может найти свою нишу. Не хочешь быть технарём полностью, тебя интересует и технические, и в то же время бизнес-вещи? Занимайся продактом, проджектом. Ниш полным-полно, найди свою нишу, которая тебе будет интересна.
Сейчас много говорится о профессионалах в форме «Т». Нужно понять, где находится ножка твоего Т, выбрать что-то одно, начать копать в этом месте. В момент копания обнаружатся потрясающие глубины. Но копать можно куда угодно. И я прекрасно осознаю, что есть много районов, которые я глубоко не копнул, потому что пытался посмотреть и понял, что это не моё. А вот там, где тебе интересно копать — продолжай копать, и тут уже очень важно говорить об этом. То есть, опять же, я понимаю, что это не для всех. Но и тут у всех есть разные формы выражения: кому-то, может быть, подходит писать блоги, не можешь писать блоги литературные и весёлые — пиши просто технические блоги, публикуй Gist'ы на GitHub. Вот ты какую-то проблему решил — публикуй.
По большому счёту сегодня карьерное развитие происходит за счёт шеринга. Не зря в DevOps обмен знаниями — это такая важная ценность. От этого выигрывают и все остальные, и ты сам всегда тоже выигрываешь, если делишься своими знаниями. Любой человек, который опенсорсил свой код, прекрасно знает, насколько нужно причесать код, как нужно вообще по-другому подумать в момент, когда ты даёшь это кому-то другому, и ты понимаешь, что кто-то другой будет этим пользоваться. В игру сразу входят те самые социотехнические вещи, о которых я говорил. Ты начинаешь думать, что это не просто код, а код, который другой человек будет читать, возможно, он захочет его изменять, ему нужно будет понять, что этот код делает. И когда возникают эти взаимодействия, и ты уже в своём начинаешь взаимодействовать с другими людьми. А карьера человека развивается только за счёт взаимодействия с другими людьми. По большому счёту что такое карьера? Карьера — это значит, что я становлюсь полезен большему количеству людей, полезен и нужен. Я получаю знания, которые нужны, полезны большему количеству людей. Для этого нужно понимать, что эти люди хотят и что им нужно. Как-то так. Всё всегда утыкается в людей.
Олег: Допустим, вот мы такие клёвые, мы занимаемся DevOps'ом, всякими новыми практиками, прочим. Но вот есть те, кто это знают и уважают, а есть все остальные. И вот представь, что ты работаешь в команде в какой-нибудь, особенно в большой компании, и там это пока ещё… скажем аккуратно, не очень знают и не очень уважают. Есть ли какие-то способы, как начать внедрять все эти идеи? Если ты не руководитель. Понятно, если ты руководитель, ты можешь просто сказать: «Внедряем завтра». А что будет, если ты обычный человек и ты хочешь улучшить?
Антон: Во-первых, необязательно, что это будет работать, если ты скажешь как начальник: «Внедряем завтра». Люди будут выполнять какие-то задания, но это не значит, что глубокое понимание того, зачем это внедряется, возникнет откуда ни возьмись. И потом, любые изменения никто не любит, особенно когда ему говорят: «Тебе надо поменяться».
Олег: И что делать?
Антон: Ну смотри, я был в этом месте и занимался внедрением таких процессов, фактически, снизу, будучи просто работником в команде, и потом уже будучи тимлидом. Единственный подход, который работает — это подход наркоторговца. Это то, что я называю, «сотрудничество, основанное на осознании того, что ты предоставляешь услуги», то есть услуго-ориентированное сотрудничество. По большому счёту ты знаешь, что у тебя есть какие-то люди вокруг тебя, которых ты можешь воспринимать как своих клиентов. Мы что-то делаем, кто-то другой этим пользуется. В самом простом сценарии, о котором в своё время говорил Agile: вот я разработчик, у меня есть клиент, соответственно, я должен понимать, чего хочет мой клиент для того, чтобы эффективно разрабатывать ПО.
В большой компании зачастую у меня нет непосредственного взаимодействия с заказчиком, с пользователем. Но вокруг меня есть люди. Например, я пишу библиотеку — другие люди с ней интегрируются, я пишу какой-то бэкенд — у меня есть фронтендщики, которые должны с ним разговаривать, я пишу код — у меня есть тестеры, которые либо для меня пишут тесты, либо, опять же, я им выдаю версии для того, чтобы им было что протестировать. И по большому счёту нужно просто подумать: «Вот я — поставщик услуги, у меня есть клиенты. Лучше всего всё будет работать, если я сделаю так, чтобы мои клиенты были довольны. То есть если мои клиенты будут довольны, то и я буду доволен. Я, видимо, заработаю, во-первых, себе некую репутацию, я заработаю хорошее отношение, я получу положительный фидбэк». И возвращаясь к подходу драгдилера, я хочу, чтобы эти клиенты вернулись ко мне, чтобы получить ещё того же.
То есть если я считаю, что какой-то подход правильный, например, continuous integration с тестами… Есть программисты, которым сегодня, например, сложно протестировать свою работу. Нужно сделать так, чтобы им действительно не приходилось об этом слишком много думать, чтобы они получали эти проверки как можно проще. Сегодня это выглядит достаточно банально, 10 лет назад это вообще не было тривиально: в тот момент, когда я запушил свой код, чтобы всё автоматически там где-то построилось, развернулось, и только в случае, если есть ошибка, я бы получил сообщение, а пока я мог бы спокойно пойти пить кофе и не думать о том, что мне нужно сейчас запускать компиляцию и на своём компьютере, чтобы у меня были все необходимые тулзы, потому что это всё тоже головная боль. То есть если уменьшить количество головной боли — люди на это подсаживаются. Мы все это видим: в тот момент, когда у тебя есть хорошо работающий пайплайн, очень быстро все, кто им пользуются, уже не могут без него себе жизни представить. Eсли я хочу что-то поменять, нужно создать процесс, от которого у людей возникнет определённая эмоциональная зависимость.
Олег: Хорошо. Вот многие люди надеются, что придёт какой-нибудь царь, великий лидер, ещё что-то и расскажет, как им жить, и после этого все, конечно же, перейдут в новый смелый мир с DevOps или ещё с чем-нибудь. Обязателен ли такой царь?
Антон: Нет, царь, который расскажет, как жить, точно не обязателен. Начальник, который готов прислушиваться к своим работникам, готов доверять им и готов поддерживать их в том, чтобы делать работу так, как им кажется максимально удобно и правильно? Да, такой человек необходим, потому что без этого это будет просто борьба. А борьба подчинённых против своего начальства не заканчивается ничем хорошим. В результате для кого-то одного это точно закончится плохо, либо для начальника, либо для подчинённых.
Но проблема заключается в том, что очень сложно людям говорить, что надо и что не надо делать. Они в результате делают то, к чему их привёл их культурный бэкграунд, эго или сиюминутное эмоциональное состояние.
Наиболее полезные практики и технологии из мира DevOps
Олег: Кстати, вот сейчас проповедуется огромное количество всевозможных практик: есть подходы от Google, есть подходы от Netflix, от всяких докладчиков с конференций. Скажи, какие практики ты считаешь наиболее полезными?
Антон: Проблема большинства организаций, не важно, большие они или маленькие (как раз стартапы от этого страдают сильнее) в том, что у них нет наблюдаемости процессов — понимания того, как вообще мы работаем, как мы доставляем ПО, где вещи застревают. Я обычно предлагаю упражнение, которое происходит из подхода бережливого управления, lean management — называется value stream mapping. Картирование потока доставленной ценности. Это требует определённой готовности, собрать в одной комнате основных игроков в организации, всех людей, которые каким-то образом участвуют в процессе доставки: те, кто определяют необходимые изменения, продакты, проджекты, разработчики, тестеры, сисадмины, даже продажники, которые работают с клиентами. Взять, собрать их всех вместе и понять, как происходит изменение в программном обеспечении, какой путь оно проходит обычно.
Это кажется достаточно тривиальным: ну что там? Кто-то придумал — кто-то закодировал, у нас есть пайплайн, пробежало — выкатилось. Ну да, вот мы знаем, что здесь у нас билд много времени занимает, да, это мы решим. Ну да, мы знаем, что программисты сейчас не могут собирать на своих компьютерах, потому что у них Java, там нужно очень много памяти, про это мы тоже знаем, мы решим. И я часто прихожу к организациям, они говорят:
— Вот там нужно это автоматизировать, это решить.
— А вы уверены, что начинать вообще с этого нужно? Откуда вы это знаете?
— Ну мы точно не знаем, но мы чувствуем, что там болит.
Есть теория ограничений Голдратта, которая говорит, что по большому счёту решать вопрос в любом месте, которое не является ограничением, — это ничего не решать, это только усложнит проблему. Чего многим не хватает — понятия того, где вещи застревают и каким образом они текут.
Иногда просто вдруг собираешь разных людей, один говорит:
— Вот здесь вот в этот момент релиз идёт на одобрение туда.
А другой говорит:
— Нет, у нас не так, у нас не идёт. Здесь мы ждем окружение под нагрузочные тесты.
Или, например, тестеры говорят:
— Вот в этом месте мы обычно делаем вот это всё руками.
А программеры им говорят:
— Так у нас же есть автоматизированный процесс для этого. Почему вы им не пользуетесь?
А тестеры говорят:
— А мы не знали, что есть.
Каждая команда видит только свой кусок, и никто не видит всей картинки в целом— это то, что зачастую влияет на нашу способность эффективно выкатывать ПО гораздо сильнее, чем наличие или отсутствие инструмента. Вот эти вот вещи. Начинать стоит с картирования процессов. Понятно, если в компании нет на нынешний момент никакого CI/CD — это уже прошлый век. Понятно, что это построить тоже нужно. Но стоит сначала ответить на вопрос, сколько в это вкладывать, какие проблемы это решит. Для этого тоже нужны люди, которые понимают, как это правильно делать.
Олег: С технической точки зрения, на какие технологии стоит обратить внимание? Понятно, что про простой CI/CD можно уже не говорить. Что из клёвых новых технологий стоит посмотреть?
Антон: Во-первых, совершенно для всех очевидно, что контейнеры победили. И поэтому если кто-то ещё не делает контейнеры, на них обязательно нужно посмотреть и смотреть как можно скорее, потому что движение идёт в эту сторону, уже и большие компании все понимают, что им нужно уже заворачивать своё ПО в контейнеры. Ну и на уровне платформы победил Kubernetes: неважно, в облаке или нет — мы будем клиентам выкатывать коробочку с Kubernetes. Вот теперь и VMware объявили, что у них будет Kubernetes прямо на гипервизоре. Всё понятно, Google победил. Что, в общем, ни для кого не стало сюрпризом.
Олег: Google победил?
Антон: Ну если мы оглянемся буквально на пару лет назад, там ещё было не очень понятно, Swarm или Kubernetes, и убьют ли Docker. Docker убили, совершенно очевидно. То есть все вместе навалились, и Microsoft, и Amazon тоже помогли — «давайте все вместе убьём Docker». Убили Docker! Но по большому счёту Docker сами были виноваты. Они рассчитывали, что они придут, всем сделают разрыв шаблона, никому не захотят продаваться и победят всех сразу, завалят сразу и Google, и Microsoft, и Amazon? Очень мало шансов было, что это случится. Они, видимо, не нашли, с кем подружиться. Когда ты ни с кем не подружился, то в результате тебя завалят. Так и произошло.
Так вот. Поэтому на контейнеры необходимо смотреть. Контейнеры и оркестрация — это сегодня уже потихоньку становится общим местом. То есть уже сейчас доклады на конференциях — это «Начинать с Kubernetes никогда не поздно, даже если вы пенсионер». Так что это нужно. И вокруг Kubernetes сейчас начинает происходить на самом деле куча всего интересного. Потому что одна из прикольных фишек Kubernetes — это по большому счёту создание какого-то универсального API, которое позволяет нам описывать всё, что происходит в нашей инфраструктуре. Последний год мы видим попытки вокруг этого API закрутить кучу всего остального. Вот сервисное сито — одна из таких попыток, почти все имплементации, сервисного сита, которые есть сейчас, они в некотором смысле говорят: «Вот мы расширим API, мы добавим ума, мы опишем объекты вне Kubernetes, но будем считывать объекты из Kubernetes и таким образом знать, что делать».
Другой такой пример — это то, что происходит сейчас с Continuous Delivery Foundation, который организовался где-то года полтора назад, опять же, это Google, это CloudBees, GitLab. Есть гугловский проект Tekton, его основная идея — это создание некого универсального API для описания continuous delivery-процесса. По большому счёту они пытаются разбить это всё на определённые объекты, которые должны обязательно присутствовать в continuous integration / continuous delivery-системе и неким образом дать возможность записать эти вещи в Kubernetes, чтобы потом могли быть всякие разные компоненты, которые умеют читать эти определения и решать, что с ними делать. С сервисными ситом происходят те же самые вещи, об этом я говорил на своем докладе. Microsoft сейчас пытаются сделать спек того, что должно делать сервисное сито, так называемый SMI Spec. С идеей того, что любая имплементация сервисного сита будет уметь выполнять всё, что в этом спеке написано плюс что-то ещё.
Именно поэтому Kubernetes и выиграл. В тот момент, когда ты становишься платформой для дальнейших инноваций, очень сложно тебя куда-то выкинуть потом, потому что на нём уже наросло, теперь выбросить Kubernetes — это нужно младенца вместе с водой выплёскивать.
На какие доклады стоит ходить
Олег: На какие доклады ты сам ходишь, что ты считаешь интересным?
Антон: Во-первых, если есть какая-то новая технологическая фишка, приблуда, которую просто ещё не успел сам посмотреть, и есть докладчик, который умеет об этом доходчиво рассказать, то я считаю, что это вообще дикое преимущество, потому что вместо того, чтобы сейчас читать, и раскапывать, и, возможно, с трудом понимать, ты можешь прийти и за полчаса послушать, как человек тебе покажет, расскажет. Опять же, для этого нужно определённое умение и желание уметь рассказать о технологии. И я понимаю, что это тоже не приходит ниоткуда, над этим нужно работать. У меня это тоже заняло много времени. Кстати, то, что я занимаюсь техническим преподаванием, мне очень в этом помогло. Когда перед тобой класс, тебе нужно людям что-то объяснить, и ты понимаешь, что, как ты ни объясняешь, они тупят — то осознаешь, что, видимо, проблема в том, как ты объясняешь, а не в том, что люди тупые.
Олег: А что за техническое преподавание? Что ты делаешь?
Антон: Я где-то уже лет 7-8 занимаюсь преподаванием чисто технических дисциплин. Началось с того, что я преподавал такие вещи, как Maven и shell scripting в течение года. Поскольку я очень плотно занимался Jenkins-ом и глубоко его знал, то я преподавал людям работу с Jenkins, администрирование. В последние годы — всё, что связано с cloud native: Kubernetes, контейнеры и всё вокруг этого. Скоро еду в Лондон, буду делать мастер-класс по Istio. Это не основная часть моей деятельности, но где-то раз в месяц-два я провожу мастер-классы.
Олег: Ты идёшь в основном на доклад, на тему или на человека?
Антон: Если я знаю, что докладчик хороший, то я иду на человека просто потому, что мне ещё очень важно учиться у других людей, как хорошо рассказывать. Учиться всегда важно. Если есть тема, а докладчика я не знаю, то я пойду посмотреть, но это как обычно, как пойти на стендап: посмотрел первые 10-15 минут, не зашло — ушёл. Либо есть докладчики, на которых я действительно пойду по-любому, потому что они всегда интересно рассказывают, даже вещи, которые ты знаешь, умеют показать под своим углом, это просто и для тебя самого поворачивает вообще весь вопрос с новой стороны. Из тех кто мне нравится в последнее время… Во-первых, есть Саймон Уордли — консультант, у него есть своя такая фишка с рисованием карт, он при помощи карт объясняет, каким образом компании выстроить свою стратегию правильно, он был когда-то каким-то там CTO, CEO стартапов, он много говорит об этом, о технологии. Он, кстати, постоянно топит за serverless и говорит, что те, кто сегодня serverless не делают, у них большие проблемы.
Олег: Это тот товарищ, у которого на Medium книжка? Он её в виде постов сделал. Необычный формат.
Антон: Он реально рассказывает очень прикольно. Его лекции за последние 2-3 года мне запомнилась больше всего. Ну вот Джон Уиллис, который приезжал в прошлом году на DevOops — просто потому что он реально умеет рассказать. С ним есть некоторая проблема, потому что он очень много рассказывает про американскую реальность, вещи, которые иногда просто не применимы ни к российской, ни к израильской реальности. Вот у них есть некая война сейчас с какими-то change approval boards, о который они постоянно говорят. Это, видимо, некая вещь, которая существует в американских энтерпрайзах, там есть такой процесс для проведения и одобрения изменений в IT, нужно проходить какие-то коммитеты.
Олег: А у нас такого нет — я даже не понимаю, о чём ты сейчас.
Антон: Вот я тоже не очень понимаю, в Израиле тоже такого нет. А там они об этом говорят. Если послушать всех этих товарищей, вроде DORA, которые делают State of DevOps Report, они тоже об этом много пишут. В общем, я о том, что люди говорят о какой-то проблеме, которая есть только у них, а она тебе вообще никак не интересна.
Олег: Ты был на прошлом DevOops, на какие доклады там стоит ходить и пересматривать записи?
Антон: Смотрите всех. Чуть-чуть тема интересует — сходить.
Олег: Там есть какой-то Антон Вайс, по-моему. Наверное, стоит на него посмотреть.
Антон: Да нет, на этого не ходите, скукотища какая-то :-)
Олег: Ну ладно, спасибо большое. Это было круто! Я вижу, что ты уже подал доклад на следующую конференцию, так что — встретимся на следующем DevOops!
Конференция DevOops 2020 Moscow пройдёт 29-30 апреля, на этот раз — в Москве. Суть конференции мы описали на Хабре в анонсе «DevOps-инженеров не существует». Программа активно формируется (до конференции еще много месяцев), но первых спикеров уже можно увидеть на сайте. Там же можно приобрести билеты.
Автор: olegchir
