Latest / // TODO: Переписать — IT без бигтеха и успешного успеха / // TODO: Быть девопсом

Transcript

// TODO: Быть девопсом · // TODO: Переписать — IT без бигтеха и успешного успеха

• Artem: ИИшка также меняет наши когнитивные способности, она их как бы усиливает видеть всю систему целиком, System Design, проектирование. этот человек пока что умеет делать лучше, железка. поэтому мы фигакнули сразу в продакшн и уронили продакшн базу она нас пролежала полтора часа если ты сделаешь rmrf slash, то она тебе удалит твой сервер. Alex: Кстати, не Artem: Всем привет, С вами снова подкаст «Туду переписать» и его ведущая Александр Ляпин и Артём Самойлов. Alex: Всем привет! Artem: у нас очередной выпуск с гостем. Сегодня у нас Артём Фетисов, он девопс-инженер в компании Navitec. И мы постараемся сегодня поговорить про… Чего? что касается девопса, но вообще хотим обсудить когнитивную сложность профессии и, конечно же, поговорить в том числе и про ИИ. Как же без этого? Ну, для начала я тогда предлагаю просто Артему рассказать о себе, о своем опыте, и уже будем дальше идти. Всем привет еще раз. зовут Артем. Я работаю в DevOps-инженером, как вот Артем уже сказал. Ну, свою карьеру в IT я начинал в 2014 году. 2014 у меня первая работа в IT была. Сис-админом я работал, в торговом центре, системно-администратором. Потом было несколько работ таких же там, в роли системно-администратора. Потом у меня примерно Да, непременно точно. В 2018 году случился такой поворотный момент. Я попал на IT-митап в компании PAM. Они проводили метап. И я там услышал несколько докладов про DevOps, про CICD, про Kubernetes, про Jenkins. И мне это всё очень понравилось. Я загорелся идеей и решил развиваться в этой сфере. Потом я попал в Канаду, ну уже второй раз я туда ездил. Я там достаточно долго жил. я пошел учиться в колледж на компьютерсайенс, на факультет компьютерсайенс. И в это время уже тоже самостоятельно пытался там развиваться. Ходил на метапы, слушал тоже про девопс. Вот еще такая, наверное, интересная история у меня там была. Летняя работа. Во время учебы в колледже у меня была летняя работа. Я попал в компанию CISCO. Но я не работал в штате компании CISCO, а просто мы были подрядчиками там и работали такие, низкоквалифицированные СИС-админы. Мы там, значит, разбирали всякие оптические кабели, устанавливали серверные стойки. Там были огромные тяжелые шкафы, двусоткилограммовые. стоячные сервера. Мне там удалось много чего интересного посмотреть, увидеть своими глазами. Ну и потом, в 2020 году случился ковид. Всё резко очень сильно поменялось. И нас перевели на удалённое обучение, заперли по домам, и мы все сидели дома и учились. В конце концов мне это все надоело. Я бросил учебу и вернулся в Россию. Это был 21-й год. потом я начал ходить по собеседованиям, искать себе работу. И в итоге я устроился как раз с дэвопс инженером в одной альцерской компании, где я проработал 4 года. Я недавно сменил работу на Витеке, работаю не очень давно, меньше одного года. Получается, меня опыт в сфере DevOps, где-то уже 5 лет, коммерческого. Наверное, на этом пока можно краткий экспорт закончить. Давайте, наверное, про что-нибудь еще поговорим. Интересно. да спасибо большое что рассказала историю очень интересно по факту у нас наверное примерно одно и то же вот время в профессии вот то есть у нас как разработчиков Угу. у тебя как у девопса ну понятно что тебя в целом больше опыта именно вот в IT сфере так как ты работал еще с sysadmin вот именно в девопсе 2021 прикольно слушай интересно очень вот 2021 год я прекрасно помню в то время, я начинал входить в разработку, интересно ли, помнишь ли ты про то время и каким вообще девовс был в то время, в 2021 году. Я не могу сказать, что он очень сильно отличается от моей текущей работы. Но, естественно, все было немножко по-другому. что, во-первых, весь код написали руками, никаких ИИшек, и чатов GPT в помине не было. Если я правильно помню, чат GPT, по-моему, появился в 2021 году как раз, но у нас в России про него в то время еще никто не знал. Я думаю, что более-менее... коммерческих компаниях им начали пользоваться где-то году в 22-м и позже. Вот мне так кажется. А так в целом работа была плюс-минус. Такое же... То есть интересно, вот опять же я из своего опыта могу сказать, что вот за последний год-полтора наша работа как разработчиков, она кардинально поменялась и сейчас вообще все выглядит по-другому. Как вот в DevOps, вот опять же по сравнению с там 2021 годом, когда ты вот только заходил, вот с тем, что сейчас происходит, неужели вот Угу. реально все то же самое? Нет, работа сильно поменялась, как раз последний год-полтора. Да, именно в плане Расскажи это подробнее. производительности. Я бы сказал, что в последние год-полтора производительность сильно увеличилась благодаря LLM-кам. И вообще характер работы изменился. Потому что большинство кода мы теперь пишем не руками, а с помощью книжек. Да, у нас то же самое. В принципе, весь код пишем сейчас с помощью агентов, и нас сейчас идут скорее дебаты не за то, что писать код руками или не писать, а читать код или не читать. Уже дошло до этого. И мы как раз с Алексом в прошлых выпусках это обсуждали и дебатировали, потому что, в принципе, сейчас настолько много всего хочет это бизнес. что у тебя даже не остаётся порой времени на то, чтобы, знаешь, нормально как-то читать код там строчку за строчкой, смотреть, что делают агенты и так далее. Вот интересно, опять же, в плане девопса, вот насколько поменялось то, что, не знаю, хочет бизнес, то есть, стало ли больше задач. Если стало их больше, то каких именно задач? Безусловно, стало больше. Я думаю здесь тоже самое. Мне кажется, этом плане Devops идет вместе с разработкой на говноугру, потому что неразрывно связан в любом случае. Alex: Слушай, то есть если... Если я правильно понял, то работа как таковая не поменялась у тебя как девопса только за исключением того, что теперь код пишешь руками не ты, а за тебя пишет агент. Но при этом сами задачи остались теми же, просто их стало больше. Artem: Я бы сказал так, Всё правильно. Ну в смысле задача осталась столько же, просто мы их можем делать быстрее. Допустим, если у тебя там в джире 10 не сделанных тикетов, то ты вместо того, чтобы их сделать там за неделю, теперь ты их можешь сделать за два дня там или за три дня. Ну, тут конечно всё Alex: Ммм. Artem: условно, но в целом это так. То производительность сильно увеличилась. Я вот очень люблю аналогии, например, переводить, да, и мне вот нравится в этом плане аналогия с каким-нибудь экзоскелетом, человек, у человека есть физические ограничения. Как правило, среднестатистический человек может поднять не больше 40-50 килограмм. Но если ты надеваешь их за скелет, то ты можешь поднять легко 100-120 кг с помощью вот этой штуки, этого приспособления. Мне кажется, ИИшка также меняет наши когнитивные способности, она их как бы усиливает и позволяет нам делать больше работы головой в единицу времени. Я бы вот с этим сравнил. Да, на самом деле мне нравится такая аналогия. Сейчас, конечно, сложно сказать, опять же, куда там придет вся вот эта история SE, к чему мы в итоге придем. Но да, то, что мы действительно сейчас делаем гораздо больше работы, это, ну успеваем, точнее, делать за определенное количество времени больше работы, это неоспоримый факт. Знаешь, мне вот интересно поговорить, наверное, про то, что... то, что ты делал руками постоянно, то есть мы сейчас не только про какую-то конфигурацию и так далее, просто не про код говорим, а вообще в целом про какие-то действия, которые ты как девопс инженера раньше выполнял с помощью, ну вот самостоятельно руками, типа там сервера настроил, не знаю, какие-то конфигурации и так далее, все что угодно, все что ты делал руками, и вот как ты сейчас, как сейчас вообще поменяла ситуация, что ты делаешь с помощью агентов. что ты им доверяешь, а что не доверяешь. В моей работе я использую ИИ и агентов буквально практически для всего. меня, наверное, 90 % работ я делаю с помощью LLM. Тут тоже можно примеры какие-нибудь привести. Например, дебаггинг можно взять раньше. Если тебя что-то случилось, то ты идешь... и делаешь все руками. Ты идешь читаешь логи, смотришь метрики. какие-то эксперименты проводишь на серверах, чтобы докопаться до истины. И сейчас для того же самого можно использовать ИИшку как еще один слой поверх того... Ну, не запускать обычный Linux команды в обычном терминале, а именно просить ИИшку, чтобы она запустила эти команды за тебя. Вот, это наверх... Alex: Ну, то есть ты, типа, говоришь ИИшке там типа по фиксе бака на какую-то часть работы делает или может быть даже всю, а ты потом, ну, типа проверяешь или добиваешь то, что она, ну, в том направлении, в котором она условно показала, да? Artem: Не совсем так. это может быть и так, но это если прям простая какая-то задача, простой баг. А если что-то более сложное, то тут вы работаете на пару с железкой. Она тебе Alex: Угу. Artem: там что-то подсказывает, какие-то кусочки логов выдает, подсказывает направление, куда смотреть и так далее. Часть работы ты можешь делать и руками тоже. Но... большую часть она делает сама. Alex: Короче, условно подсказывайте друг другу, да? Artem: Что-то такое, да. То есть бывает, что оно и ошибается, да. Бывает, что оно тебе неправильно подсказывает, и тебе приходится его поправлять. И говорить, нет, чувак, там совсем не то, что ты сказал, а там вот так. Alex: Угу. Artem: Такое тоже может быть. Alex: Угу. Artem: Но современные нейронки, достаточно мощные, там вот я опусом пользуюсь в львиную Alex: Угу. Artem: долю времени. Поэтому... да. тебя были моменты какие-то, когда тебе Иишка говорила какую-то откровенную фигню, и ты такой, ну не, это прям точно не так. То есть она что-то тебе советовала сделать, что было бы, например, опасным для прода. И условно ты такой, инженер, там, зная, что нет, это точно делать нельзя, и это просто какая-то ерунда. тебя такое было когда-нибудь? Я думаю, что было. Я просто сейчас конкретный пример вспомнить не могу. Но, как правило, сейчас они их тоже прикрутили, и мне кажется, сейчас они не выдают откровенной фигни, по крайней мере, последнее время. Это было больше... Таких ситуаций было больше, когда я только начинал работать с ИИ где-то, год-полтора назад. Они там галлюцинировали часто и всё такое. Alex: Ну вот ты кстати по-моему говорил недавно, что опус 5.5 тебе понравился в плане того как он типа решает задачки Artem: Да, Ops 5.5 мне кажется у них прям существенное улучшение по сравнению с пятой версией, а в пятой версии было много воды, выдавала какие-то длинные ответы, прям и много воды было, не нужная информация. Alex: Ну, то есть, короче, Artem: Ааааа Alex: последние вот эти продвинутые модельки в целом они нормальный результат дают, нет такого, что там они откровенно, что-то вредоносно могут предложить. Artem: Нет, всё равно могут. Всё равно Ишка, это не панацея, не серебряная пуля. Всё равно за ней нужно проверять. И техническая экспертиза. Alex: Улучшения есть, но все равно надо смотреть, присматривать, чтобы ничего не произошло Artem: Да. Alex: плохого. Artem: Интересно, отойдет ли это до такого, что не надо будет присматривать. Alex: Это интересный вопрос, Artem: Вопрос на подумать. Тут сильно зависит от задачи, кажется. Есть же задачи достаточно простые, пойти календарную апку написать. А есть задачи не знаю, программы для какого-нибудь ядерного реактора или самолета. Там ответственность совсем другая, уровни допуска совсем другие. проверять нужно более тщательно. Ну, риски отличаются, да. Слушай, интересно, давай знаешь, как поступим, наверное перейдем вот немножко к тому, чего мы хотели вообще начать, про когнитивную сложность поговорить. Мы сейчас ушли немножко Угу. в холиварную тему, как обычно, про И. Мы не можем молчать, естественно, про это дело. но хотелось бы вообще поговорить про именно когнитивную сложность в профессии Угу. девопса. У меня вот лично из моего опыта, то есть что я... подразумеваю под вот этой когнитивной сложностью, когда я это говорю. Это вот когда я начал работать в своей предыдущей компании, это было, по-моему, трех лет назад, я тогда в первый раз попробовал использовать AWS. То есть у компании вся инфраструктура была в AWS. И вот тогда вот я пришел и офигел. Типа это вообще что такое? Это что за странная Ага. машина? где вообще абсолютно всё нелогично, как будто бы ничего не понятно. А самое страшное — это, конечно, эти вот permissions и там шаг лево, шаг право, Ага, всё. что-то ты не настроишь, и всё, и там оно не работает, и ты как бы понять не можешь, а почему оно так. И вот эти вот все вещи, на тот момент казались очень сложными, понятно, что ты как бы привыкаешь ко всему, и ты уже знаешь там особенности той или иной системы. Но до этого я работал с Google Cloud Platform. И мне показалось, что она как будто бы полегче, попроще. То есть она как будто бы логичнее. Вот в моем представлении тогда была. Я перешел в AWS и все такое. Ну это что? Это вообще странная какая-то махина. Ничего не понятно. То есть это как... Мне казалось, как Facebook. Вот ты заходишь типа в Facebook, в какой-нибудь кабинет профессиональный, настраивать там рекламу. Либо с опишкой хочешь поработать. Но это просто кошмар. То есть там невозможно разобраться без бутылки. И вот здесь как будто бы то же самое. Вот, интересно, твой опыт, то есть расскажи вообще, какие вот были у тебя трудности при входе в профессию, что для тебя когнитивная сложность в данном случае. На самом деле, я тебя прекрасно понимаю. В IT даже шутка такая есть, что IAM политики и AWS — это язык программирования. Да. Они действительно очень сложные. Когда я начинал работать с AWS, у меня были ровно те же самые проблемы, которые ты сейчас говоришь. Для меня точно так же это было тяжело, и вот это вкатываться. Ну, к счастью... У меня был ментор, который мне помогал с этим. У меня было много времени, это все изучить, освоить. В конце концов, получилось это сделать. Ну, вот про твой вопрос, да, когнитивная сложность, когнитивная нагрузка. На самом деле, да, в профессии девопса эта нагрузка очень большая. Это все знают. Это вообще известный факт, что нужно знать много технологий, систем и так далее. Но постепенно к этому привыкаешь, как и ко всему остальному. Вот опять же, давай возьмем аналогию с потолка, командиру воздушного самолета. Там тоже у него куча кнопок, рычагов и куча всяких вещей, которые нужно держать в голове. Представляешь, он летит на самолете, него там 200 пассажиров, он ответственный за всех жизней. Там тоже, я думаю, очень высокая когнитивная сложность, но это все приходит со временем, с опытом. То каждую маленькую технологию можно в принципе выучить, освоить. На это уходит практика, чтение, теория и так далее. Написание скриптов каких-то. Со временем к этому привыкаешь. И опять же, если вернуться к Ишке, она нам облегчила жизнь очень сильно в этом плане. потому что, тоже вот я некоторых там деятелей читал, говорят, что ИИшка и человек, они как бы дополняют друг друга, Эта железка может делать некоторые вещи, которые человек не может, например, запоминать сто рандомных фактов подряд. А есть, наоборот, вещи, которые она не может, а мы можем, то есть это вот... видеть всю систему целиком, System Design, проектирование. этот человек пока что умеет делать лучше, железка. Это да, 100%. Я вообще вспоминаю, на самом деле, времена, когда приходилось читать логи самостоятельно, вот, делать какой-то дебаггинг, то есть то, что ты говорил в самом начале. И это, конечно, был ужас. Дикий ужас, когда приходилось сидеть, разбирать эти логи. Особенно, когда эти логи слишком verbose, и вот тебе приходится прям реально сидеть и просто выгрызать Угу. это всё. Это ужас. И сейчас ты, по сути, избавлен от этого. Вот у нас, например, в компании мы используем для мониторинга Datadog. И вот все, что касается там логов, трейсов, вообще, поведения вот именно нашего сервиса, находится в Datadog. И я очень сильно радовался, когда я увидел, что в Datadog есть AI bits. Вот, у него есть там как бы свои ограничения, он не знает контекст, котором ты работаешь, как разработчик, то есть он не видит твой код. И это меня смущало. Но он очень сильно помогал в том плане, что ты мог ему, например, скинуть вот такая-такая-то проблема, там случилось примерно в такое-то время. Там найди по трейсам, по логам вот эти данные. И расскажи мне почему, как это было связано с какими-то другими сервисами, То есть вот рода задачи. Потом я пошел еще дальше и подключил агента, с которыми я постоянно работаю, к Лода, по MCP к Datadog. И жизнь стала гораздо интереснее и веселее, потому что Claude знает твой код, и он знает контекст, то есть он может опираться Угу. на него. И это прям очень удобно, потому что он может подсказать тебе гораздо лучше. То есть он читает логи, читает всё, что необходимо, может самостоятельно строить виджеты какие-то, устанавливать метрики. И ты можешь за всем этим наблюдать и, по сути, руководить, принимать решения. А всю эту рутинную работу, которую раньше ты бы делал часами, потому что дебаггинг порой занимал просто какое-то нереальное количество времени. Да. Это было очень сложно, очень тяжело. Особенно если кейс какой-нибудь, прям реально сложный, где у тебя несколько сервисов разных, друг за другом как-то падают, то это кошмар. И в итоге вот сейчас с этим стало гораздо легче, и вот я как разработчик дико радуюсь этому. И вот мне интересно опять же, как у тебя это происходит. Вот расскажи про свое взаимодействие там в рамках AWS, то есть какого агента ты там используешь, как ты подключаешься. Про дебаггинг ты имеешь ввиду, Да, да, про дебаггинг и вообще в целом про работу. Я использую Cloud Code для всего, И для написания кода, и для дебаггинга тоже. Я просто авторизуюсь через command-строку и дальше Cloud Code. Он видит все cloud-ресурсы, все, что там есть. Он может подключиться к любой, не знаю, и situ инстанцию, и посмотреть какие-то логи. И к Kubernetes точно так же он может подключиться. Вот. интересы AWS CLI. В основном да. Угу. К AWS да. Kubernetes там другие есть команды, к Cube Control есть. В основном с Kubernetes он через Cube Control работает, а с AWS через AWS. Да, вот в этом случае интересно, наверное, проговорить еще и про какую-то, знаешь, секьюренность, безопасность, чтобы у агента был доступ, но не слишком много. Вот как ты это ограничиваешь? Ну, я, во-первых, не запускаю агентов самих по себе, они у меня все время супервайзят, я всегда вижу, что оно делает. Во-вторых, проде мы никогда не вносим изменения с помощью агентов и так далее, мы работаем только в Dev-среде. Ну, тут можно подумать, как это правильно сделать. вообще, как бы золотое правило такое, что надо использовать принципа List privilege — это вот у админов, это как бы золотое правило такое. Не давать никому больше разрешений, чем нужно, не давать доступ к тем ресурсам, которым не нужно, ну и так далее. Ну сейчас вот да, много историй, я читал там новости, в новостях написано, что у какого-то чувака там агент уронил продакшн базу и стер все бэкапы, заодно тоже... Ну, как бы да, действительно проблема была не просто в том, что ИИшку использовали, а в том, что неправильно был настроен доступ. В том, что у агента был доступ ко всем продакшн базам и бэкапы лежали на том же сервере. То есть это проблема, скорее, дизайна, я считаю, и архитектуры, чем проблема вот именно непосредственной работы с агентом. Вот. Ну как-то так. Вот еще плюс в том, что агент может очень быстро тебе накидать какой-то скриптик и проверить кучу гипотез. Если ты, например, не знаешь, где лежит проблема, то раньше приходилось руками писать какие-то скрипты, что-то там менять, какие-то параметры. То есть сейчас ты можешь просто высокоуровнево описать задачу. И он тебе этот скрипт напишет буквально за какие-то секунды и прогонит его тут же. И напишет результат. То есть у тебя буквально время сокращается в разы. Alex: Вот это кстати да очень классная фича, что ты можешь просто натуральным языком описать, что Artem: Да. Alex: тебе нужно проверить и он сразу бам все по pipeline фиганул и да это круто. А вы же в основном из всякого кликопса стараетесь этого... К этому не использовать, Artem: И сбегать, Alex: То есть да, да, да. И всякие, Вот эти принципы тоже зашиваете, как Infrastructure with Code, Artem: В основном, да, мы ClickOps не используем, используем именно Infrastructure as Code. У нас вся инфраструктура в репозиториях, в коде и так далее. У нас так же. Я думаю у Алекса тоже. Ну это как бы правильный подход, это кстати один из Alex: да да да да Artem: таких общепринятых подходов тоже в ДОПСе. Поэтому это правильно. Да, безусловно. знаешь, тогда вот интересно поговорить было бы про какие-то вот инциденты, если, конечно, ты помнишь из твоего опыта, например, то, о чем ты прям реально помнишь и было страшно, там условно. Помню, было такое. Production базовую уронили один раз на проекте. было, ну вот я тогда, как раз, наверное, был вот этот такой переходный момент, когда ИИшки прям только появились, это, по-моему, был 23-й год, если я не ошибаюсь. Мы работали на проекте, у нас был там один американский стартап, и мы там делали, значит, систему, ну там, это в сфере хлэвке. И... что случилось. написали миграции наши разработчики и вместо того чтобы их проверить на стейдже мы их выкатили сразу в прод потому что мы спешили там нам поставили задачу побыстрее задеплоить новую версию поэтому мы фигакнули сразу в продакшн и уронили продакшн базу она нас пролежала полтора часа пока мы ее не восстановили из бэкап Ну мы как бы нарушили основное правило. Alex: Тестим сразу в продюсерте. Artem: Зато протестировали. Но это был стартап, да? Я правильно вас слышал? Я работал в Outsource, я работал в другой компании, а мы Угу. просто делали проект для одного старта. Ну в принципе ладно, не так уж критично стартапу положить базу на полтора часа. Не так уж критично, но они нам быстренько прибежали и очень вежливо попросили, что, ребята, давайте побыстрее восстановим, потому что у нас тут как бы клиенты ходят уже, у них были реальные клиенты, которые деньги платят и так далее. есть, ну, это простое, и все-таки стоил им денег и репутации. Поэтому это было в наших же интересах – восстановить доступ по-быстрому. Ну да. интересно ну понятно что как бы надо естественно тестить всегда на стейджи у нас например есть dev, environment есть stage и потом уже только идет prod то есть два уровня Ага. Ага. защиты ну даже три потому что как бы и самый начальный это локалка когда ты у себя тестишь Да. вот но Тут как бы у нас сейчас ходят дебаты за то, чтобы может быть удалить ADF, потому что он по сути такой как бы не то не всё, и вот мы думаем, то есть мы за него вроде как деньги платим, а он не так то уже не нужен. И вот сидим и думаем. Ну да, для этого есть конкретные причины, почему делают 2-3 окружения и больше. Ну такой стандартный набор, это 3 окружения Dev, Stage и Prod, но бывает и больше. У меня были проекты, где у меня было 5 окружений. Помимо StageJ, еще был Pre-Prod и еще был Integration Testing среда. Потому что Погаси. проект большой, когда у тебя на проекте 30 человек и выкатывают разные фичи постоянно, то надо еще делать integration testing и надо делать pre-production testing. Поэтому было вот Да. Слушай, вот ты упоминал, что ты пишешь код, ну или агент пишет в данном случае. Ну, в любом случае, ты как бы ответственен, в том числе из-за написания там какой-то части кода. Вот ты, когда говоришь код, ты что имеешь в виду здесь? У меня большая часть, ну сейчас мы работаем текущей, большая часть кода это Infrastructure as Code, Terraform и Угу. Homecharta. И, наверное, оставшиеся процентов 10 это CI-CD. Ну логично. Я не знаю, я могу более подробно объяснить, там нужно. Ну, я думаю, в принципе, все понимают, что такое infrastructure scope, что такое холмчарты. Ну, я думаю, что в целом, да. Ну, HelmChart, если... Alex: Ооо... Artem: В двух словах, это как бы способ описания софта, чтобы его задеплоить в Kubernetes. Kubernetes есть такая штука, называется Helm. Это по сути, это пакетный менеджер для Kubernetes. Вот как в Linux есть, например, UpGit, или в RedHat есть DNF, вот точно так же в Kubernetes есть Helm, который... Он тебе позволяет с помощью специального языка, с помощью яму манифестов описать. софт, ресурсы, даже не софт я бы сказал-то больше как. можно сказать, объекты, потому что в Kubernetes это называется объекты. С помощью дяма-мунифестов ты описываешь объекты, и потом они с помощью Helm деплоидов в твой классный. Я вижу, как Алекс заинтересовался, Alex: ну короче Artem: потому что он мне недавно относительно записывал кучу голосовых про Helm и про Kubernetes. Ага, прикольно. Да, я знаю, кстати, Алекс, ты, по-моему, сейчас и изучаешь D-WOBS тоже, Как тебе, кстати? Расскажи. Alex: Да, думаю мы тобой тоже довольно часто все это обсуждаем. Очень крутая тема, погружается довольно усиленно в D.V.O.P.s часть тоже, потому что нас тоже и GCP, и Kubernetes Engine, и всякое такое, и Artem: Угу. Alex: Help Chart, и RGCD. В целом мне на самом деле очень нравится, и я тоже согласен, что там есть когнитивная нагрузка. довольно существенное сразу ты понимаешь, чувствуешь. Ну в общем я понял твой тек, что мы тоже на самом деле так и делаем, потому что нас агент он генерит в основном, ну вот это а-ля да, харнес там короче весь такой плюс-минус более плейк код по Artem: Угу. Alex: написанию там этих хелмчартов там всяких валюсов да шаблонов там плюс там всякие может быть ну и другие вещи да и инфрастракция с код тоже там все это самое Artem: Угу. Alex: Так что да, Ну логично короче применять агент. Artem: А вот на твой взгляд, что тебе показалось наиболее сложным в этой сфере? Вообще? вообще. Alex: Хороший вопрос. слушай, да в целом, самом деле, технологии все, ну если ты относительно только начинаешь это изучать, и особо нету Artem: Угу. Alex: какого-то продолжительного опыта работы с такими вещами, то поначалу, Artem: то всё сложно. Alex: Да, да. Поначалу, конечно, сложно, голова кружится, там, всё это нужно Artem: Ну да, да. Alex: как бы вкуривать, вот, но наверняка со временем всё это устаканивается. Ну, в целом какие-то базовые, ну, в целом вот бывают концепты довольно сложные, если ты никогда не сталкивался там, ну, же самое там много, по кубернетису есть там, да, и всё такое, вот. Artem: Мне вот ARGO CD показался очень сложным. Когда я начал изучать ARGO CD и GitOps, мне показалось, что это очень сложно. По началу особенно. Alex: Да, согласен. Бывает еще, у каждой компании по-своему, они так все Artem: а Alex: прожанглируют этими технологиями, и RxD, и Kubernetes, и если еще все в облаке, все вот так вот слепят, намешают. бывает, когда это впервые сталкиваешься, сложно понять, разобрать этот весь клубок. Сидишь там, вкуриваешь, короче, со временем. Artem: Ну, вообще, самом деле Devops — это очень тоже широкое поле. Вот если сравнивать с разработкой, это можно сравнить, например, с Backend. Backend-разработчики бывают разные. Некоторые пишут какие-то там, не знаю, оптимизации. Некоторые пишут, не знаю, какие-то event-based системы. То есть, бывает разных много Backend-разработчиков. Точно также и Devops. Бывает много разных. Двобс может больше уходить в СРЕ, сайт Reliability Engineering, поддержку инфраструктуры, допустим. Или наоборот, некоторые девобсы больше пишут всяких туллов, больше кода пишут. Могут, например, на GoLang писать какие-то инструменты для себя или для разработчиков. Тут тоже разные бывают очень. и это зависит от компаний, в разных компаниях тоже D-Box делает разную работу. Alex: А кстати, тебя какое большее? Ну, ты, я знаю, что у есть админское прошлое, но в целом, как бы себя классифицировал по балансу вот в то и другое? Artem: Сейчас меня в основном платформ инжиниринг и инфраструктур инжиниринг. Больше всего я работаю с инфраструктурой, с облачными технологиями. Alex: Угу, угу. Artem: Мы работаем с AWS и Soroku Cloud в основном. Ты уже успел поработать наверняка с разными платформами, типа AWS, Google Cloud, Oracle. Из всего, Угу. что ты уже успел попробовать, что твоё самое любимое, что нелюбимое. Это сложный вопрос, самом деле. Я скажу AWS, потому что просто по той простой причине, что я его знаю лучше всех из них. С Google Cloud я вообще очень мало работал, так очень поверхностно. Я еще немножко работал с Azure и работал с Oracle еще. Из этих всех AWS я знаю лучше всех. Ну, он считается такой передовой, да, у них там... очень большая доля рынка. Там есть Big3 в сфере именно cloud-провайдеров. Есть большая тройка. Это Azure, Google и AWS. На всех троих приходится около 80 % рынка. Из них, по-моему, 50 % — это AWS. Это очень большая, очень крупная компания, у них очень много сервисов, них больше стапов из менеджерсов, если я не ошибаюсь. Ну, порой, да, бывает сложно, но зато интересно. И них еще куча всяких сертификаций есть, так что, ну, прям поле огромное, там тоже много чего можно изучать. У меня на счёт AWS есть такие флешбеки вьетнамские, потому что у AWS есть сервис OpenSearch, которым, в общем-то, я и работаю. То есть это то, что является моей основной работой — отвечать за OpenSearch и за то, как он работает, какой поиск он нам даёт. Понятно, что нас там есть такой человек, отвечающий за инфраструктуру на нашей стороне. Но ключевое — это то, что вот этот сервис OpenSearch в AWS, насколько я понимаю, он работает через кого-то. То есть там есть какая-то компания-прослойка в AWS. И это не AWS предоставляет OpenSearch, а какая-то другая компания предоставляет OpenSearch. И в итоге все это сводится к тому, что если у нас появляются какие-то проблемы... которое мы не можем решить, потому что это managed cluster. То есть мы не можем самостоятельно управлять. Нам нужно писать в AWS. AWS пишут вот этим ребятам. И Угу. они потом отвечают точно такой же цепочкой обратно. И я помню, что у нас были проблемы, когда у нас просто cluster, ну он упал, и по-моему там часов 8 он просто лежал. Вот, просто лежал. И мы ничего не могли сделать. Просто потому что у нас, ну, нас лапки. То есть мы ничего не можем. Мы должны ждать от ребят, вот, как они ответят. И кошмар. вот это, нам очень, очень не понравилось. И из таких вот еще особенностей, которые у нас недавно были, это то, что какие-то индексы у нас внезапно стали read-only. И мы об этом не знали. И не знали вообще, что, ну, в принципе, почему-то вот это случилось. То есть нас никаких мониторов тогда не было, что вот индекс становится ридонли. И в итоге у нас сколько, по-моему дней 8-7 мы сидели с некоторыми индексами, которые были вот заплощены. Да, да, да, Протухли индексы, и их нельзя было обновить, да, я понял. И мы об этом узнали от клиента. То есть клиент нам сказал, что что-то у вас какая-то странная штука. Мы такие, в смысле? Я давай проверять, я полез смотреть и вижу странную ситуацию, что реально... несколько индексов, они просто read-only. Я спрашиваю нашего человека, который отвечает за инфу, он говорит типа, не знаю, я не вижу влогов ничего, то есть ну просто ничего нету. Мы пишем им, они тоже не знают. И вот это вообще странная ситуация, что никто ничего не знает. С OpenSearch там на самом деле интересная история, что OpenSearch вообще как появился? OpenSearch это же fork Elasticsearch, Эластик. то есть раньше это был Elasticsearch, и у Amazon он тоже присутствовал, он так и назывался Elasticsearch, а потом они там что-то сделали с лицензией, они по-моему закрыли лицензию, каким-то образом ее поменяли. и Amazon сказал, ну пошли вы нафиг, короче, мы сейчас форкнем и сделаем свое ну и видимо вот как ты говоришь, да, они начали сотрудничать с какой-то компанией, я не знаю как она называется, но видимо они как раз поддерживают этот самый форк, elasticsearch и так далее. Я немножко с ним работал, с opensearch, но я прям таких вот тонкостей не касался индексов. нас были даты инженера, которые этим занимались, поэтому я туда особо не лез. Ну да, тут скорее, point в копилку дополнительной когнитивной сложности, что у тебя через несколько рукопожатий идёт эта вот вся лестница, Ага. и ты можешь очень долго достучаться до кого-то. То есть, когда ты владеешь каким-то сервером, и тебя всё на нём находится, и ты полностью им владеешь, ты можешь делать всё, что угодно, это очень хорошо. очень здорово, но у тебя возникает другого рода проблемы, поэтому мы перешли большинство на облака. Но в Угу. такие моменты ты понимаешь, что хотелось бы иметь какой-то контроль, а его нету. Увы. Ну, это такая дилемма, да. есть вот для бизнеса это как раз дилемма, да. То есть оставлять какую-то managed инфраструктуру и платить Devops, чтобы они ее менеджили из-за тебя. Либо же уходить в Cloud и платить другим товарищам, чтобы они ее менеджили из-за тебя. То есть в любом случае это стоит дорого и так, и так. И тут просто надо находить какой-то компромисс. Все это делают по-разному. Кто-то полностью уходит в Cloud, у кого-то гибридная инфраструктура есть, например, часть инфраструктуры оставляют на менедж серверах, а часть уносятся в облако. У Amazon, кстати, них есть даже сервис специальный, который позволяет тебе работать с гибридной инфраструктурой. Да-да, тут действительно дилемма, я абсолютно согласен. Тут бизнес просто решать, какого рода рисками, какой баланс соблюдать. Наша задача только, наверное, показать плюсы минусы. Это все, что мы можем сделать, бизнес будет решать. Да, по сути, да. Ну, иногда ещё бывает. Бывает, что надо задизайнить что-то. архитекторы участвуют непосредственно в дизайне и разработке этой архитектуры. Поэтому они могут даже не только подсказать, они могут еще нарисовать диаграммы, взять на себя ownership, взять на себя ответственность за всю эту историю. Я, к сожалению, не архитектор еще пока. Когда-нибудь. К сожалению, то есть ты если хочешь быть архитектором. У меня были подвижки в эту сторону. У меня есть AWS-сертификат, архитекты associated. Но это начальный уровень, самый первый. Угу. То есть я какие-то движения делал в эту сторону. Alex: Слушай, ну ты вот говорил, что ну еще в целом в начале, что человека есть сейчас ключевая такая ну скилл, что он может у девопса, что он может там держать всю систему в голове, ну то есть знать там связи компонентов системы друг с другом а Artem: Угу. Alex: агенты там и это больше такая ну а-ля механическая работа, то есть может быстро такую работу делать, проверять гипотезы там и так далее, а вот Можешь это вкратце сказать, ну учитывая, не знаю, если это облачная инфраструктура, не облачная, то есть примерно вот какие компоненты системы ты держишь в голове, то есть там, я не знаю, ну вкратце, короче, вот скиллы, которые нужны, то есть там знать операционку, там все ICD там, безопасность там и так далее, база в очереди, быть там мониторинг и так далее. Artem: Я не совсем понял вопрос, но я, наверное, попробую ответить. Ты имеешь в виду, технологии, какие направления нужно учить, чтобы стать хорошим DWOPS? Я этот Alex: Да, да, да, да. Artem: базовый минимум для девопса. твой вопрос понимаю так. Ну, во-первых, вот, там были меня пару раз, я проводил собеседование по DWOPS. для найма в нашей компании. И нас это собеседование обычно было разделено на несколько блоков. Один блок – было администрирование Linux серверов. Потом еще блок был по виртуализации и докеру, как устроена контейнерная виртуализация и так далее. Третий был по клауду и все, что касается клауд-ресурсов. Ну там либо AWS, либо Google, либо Azure. кто что знает. и четвертый блок был... по CI-CD и еще пятый блок был по troubleshooting то есть как раз по поиску проблем по чтению логов и по мониторингу и всему что касается этого вот как-то так это такие основные моменты но как я уже сказал да то есть devops бывает разный и бывает много всякой специфики Я еще про базы данных не рассказал, что бывает... Я, например, встречал DevOps, которые узкоспециализированы, они занимаются только базами данных, все, больше ничего. Они там всякие ClickHaus настраивают, ClickHaus-кластеры и прочее. Индексы... Ну, тоже как бы однозначного ответа нет. Но основные, наверное, такие сказал, блоки, которые надо учить. Я сейчас еще System Design. Я сейчас тоже немного пытаюсь повышать свой уровень. Я сейчас начал читать статьи про System Design, тоже про troubleshooting, более правильный, и про Infrastructure as Code, ну это в основном Terragram. Ну, я знаю, что вот что интересно. Мы в первом нашем выпуске про ИИшку говорили про то, что с ИИшкой ты начинаешь тупить в каких-то вещах, которые раньше ты выполнял руками. Ну, например, те же команды. Наверняка там позитив опция — это знать команду Linux. Вот как у тебя с этим? Ты стал забывать команды? Ты знаешь, если честно, да, я тоже начинаю замечать, что некоторые команды я начал забывать. Ну, у меня есть там, есть шпаргалки, там файлики, которых я держу самые такие команды ходовые, Ха да вы и я. да, которые под рукой должны быть. Ну, сейчас это уже не... некоторые команды просто не требуются знать. ты просто можешь Ишку попросить, она за тебя все напишет. Единственное, что надо проверять, если ты сделаешь rmrf slash, то она тебе удалит твой сервер. Alex: Кстати, не знаешь, собеседованиях на девопсе допустим спрашивают, на память вот этих команды должен, знаете или нет, а-ля лайф кодинг. Artem: Я спрашивал, честно говоря, спрашивал, я тебе так скажу. И меня спрашивали, когда меня брали на работу, меня тоже просили назвать. Alex: М-м-м-м. Artem: А ты не отвечал? Типа, ну, яичко же делает. Я стараюсь так не отвечать, что это плохой признак. Ну чё, ну это же какое-то лицемерие, нет? Типа вот стараться спрашивать вещи, которые ты уже не используешь. И это как будто бы уже немножко органично. Наверное, наверное ты прав в чем-то. Сейчас, мне кажется, поменялся подход и поменялся даже процесс найма. есть, некоторые вещи уже не надо спрашивать. По понятной причине. Alex: Главное получается, чтобы тебя было понимание сути проблемы, фундаментальные знания, как все связано друг с другом, а не вот это точечное, Artem: да Alex: типа до синтаксиса команды, чтобы ты помнил. Artem: Да, например, пример типа вот low average, что означает low average в Linux. Команда uptime ты пишешь, тебе пишет три цифры, что они означают. Это стандартный вопрос такой, сисадминский. Он показывает загрузку процессора и Alex: Угу, угу. Artem: потребление памяти. В данном случае load average именно загрузку процессора показывает. сколько ядер загружено. Alex: Да, типа там 200%, 300%, угу. Artem: Да, в общем, интересно время мы живем. Ишка, все дела. А как еще поменяется профессия в ближайшее время? Непонятно. У тебя есть прогнозы какие-то? Вот интересно. Мы просто рассуждали на тему того, как может измениться разработка, если вот и будет прокрессировать в таком духе. Ну и я думаю, это тоже самое относится к EDWOPSE. Вот тебя какие вообще мысли на этот счет? знаешь, прогнозы, наверное, есть, но вообще это очень сложно, конечно, прогнозировать и видеть будущее. Никто не может, но какие-то оценки мы можем дать, да. Но если честно, вот мое мнение такое, что самый такой хайп, самое бурное развитие ИИ, оно уже прошло. Мы уже прошли этот пик, и сейчас мы движемся к какому-то плато, просто мы достигнем какого-то плато, насыщения, а когда... Эти технологии просто станут более мачурными, они войдут полностью в нашу жизнь, в нашу практику. Как когда-то было с интернетом, с телекомом. Ведь интернет же тоже был не всегда. Начал развиваться в конце 90-х, в начале 2000-х. И потом произошло насыщение, потом он прочно вошел в общедневную жизнь. И мы сейчас его просто используем и не замечаем. Он просто как телефон или как автомобиль. Это просто стандартная технология, которую мы используем каждый день. И то же самое, наверное, будет и с ИИшкой. То есть это будет просто сервис по подписке такой же, как мобильная связь или Netflix. И мы тоже просто не будем замечать. Это просто будет еще одна технология, которую мы будем использовать каждый день. Ну, я не сторонник вот этих всех теорий, знаешь, что... ИИшка скоро захватит мир и убьет человечество. Я считаю, что это все скорее теория заговора и так далее. Я не верю в это. По крайней мере, Alex: Это как... Artem: ближайшие лет 10 этого точно не будет. Alex: Это имеешь в всякие примеры типа то, что с Hagen-Phasen было, да? Artem: Да, вот недавно... Сейчас же вот крупные компании, там, Anthropic и OpenAI, и кто там еще, они друг другом соревнуются в том, кто более такую, знаешь, красочную картину нарисует, как скоро ИИИ захватит весь мир и так далее. Что его нужно скорее зарегулировать и скорее ослабить и так далее. Ты не скучаешь по тому времени до яичному? Типа, когда ты только входил в профессию, все ручками писал, логи читал, дебакинг делал Мммм... самостоятельно. Честно, нет. Мне больше нравится то, Короче, стало лучше, что есть сейчас. На мой взгляд, да, мне кажется, стало действительно лучше. Многого еще у нас нет. Я думаю, это все будет развиваться и дальше. Сейчас некоторые эксперты в области рисуют прогнозы, что дальше это все пойдет в сторону развития робототехники, что появятся нас домашние роботы, которые за нас будут посуду мыть и еду готовить. Их же тоже еще нет пока. Это только начинается все. Наверное, в этой... в этой сфере тоже будет много развития какого-то. Да, я абсолютно согласен с этим. меня вот тоже похожие мысли, что когда-то там, ближайшее, лет 10, нас будут какие-то супер-роботы, которые... Ну, это вот просто база для дома, типа как робот-пылесос там условно. И Угу. у тебя будет такая штука, да-да-да, она будет там готовить условно, не знаю, ходить в магазин за тебя, там, ну, какие-то вот базовые вещи выполнять. Да, Согласен. Мы даже хотели у нас вот с ребятами... Ну, я там жил в Казахстане несколько лет, и у нас с ребятами была идея, там, стартап организовать в сфере промышленной автоматизации. Мы как раз хотели использовать ИИшку в сфере промышленной автоматизации. Ну, к сожалению, ничего не получилось. Проект... сошел на нет. Но некоторые идеи остались. Я просто еще... Промышленные автоматизации знаю не по наслышке, я по образованию инженер по автоматизации. меня диплом буквально первый. Первый мой диплом это инженер по автоматизации. Я про это очень много знаю. Это интересно было посмотреть на стык технологий. Промышленность, ИИ, IT. Это как бы на стыке трех разных сфер получается. Я думаю, что в ближайшее время много таких решений появится. Мы их еще увидим, скорее всего. Интересно наблюдать, что у нас у всех образование такое, ну, по крайней мере, первое, не готичное вообще. Угу. Я с историческим образованием сижу, Алекс на звезды смотрел, у тебя вот автоматизация. Да, прикольно, да. А оказались все в одной сфере. Когда... как путь наш изменился, Это точно. Вот. Ну, я думаю, на этой ноте тогда можно завершать подкаст. Мне кажется, что мы обсудили достаточно много интересных тем. Вот. Поговорили и про когнитивную сложности, и про И. И даже какие-то прогнозы попытались стать насчёт будущего. Вот. Будет интересно посмотреть, не знаю, там, через пять провести снова подкаст, позвать Артёма и посмотреть, а как же всё поменялось. Насколько изменялась профессия и что у нас сейчас происходит. Вот, ну на сегодня все. Спасибо большое за внимание. Обязательно подписывайтесь на наш канал, ставьте лайки, пишите комментарии и до скорых встреч. Пока-пока! Да, ребята, большое, до свидания. Приятно Alex: До встречи, пока. Artem: было пообщаться.