Как ИИ изменит практики DevOps и SRE | Better Stack Podcast, эп. 12
BBetter Stack
컴퓨터/소프트웨어튜닝/매니아경영/리더십재택/원격 근무정신 건강AI/미래기술
스크립트
00:00:00Я скажу так: откройте проект в Claude Code и попросите его спроектировать вам мост
00:00:05Или небоскреб.
00:00:08А потом я хочу, чтобы вы взяли этот проект и пошли его построить.
00:00:12А затем я хочу, чтобы вы сели внутри него. Вам будет комфортно это делать?
00:00:16Вам будет комфортно ехать по тому мосту, который он спроектировал?
00:00:19Прямо... пока вы не перестанете качать головой. Нам нужны те самые инженеры на своих местах.
00:00:25Добро пожаловать на подкаст Better Stack, где мы беседуем о разработке ПО, ИИ и самых разных новых технологиях.
00:00:32Я один из ваших ведущих, Андрис, и сегодня ко мне присоединился Уэш... Привет.
00:00:38И Амин Астани. Привет, Амин. Как дела? Рад видеть тебя здесь!
00:00:44Да, э-э, спасибо, что пригласили. Для меня это большая честь. Судя по тому, что я о вас знаю,
00:00:51мне кажется, что вы...
00:00:53вроде настоящего мастера SRE. Вы очень глубоко погружены в эту сферу, ведете собственный подкаст на эту тему.
00:01:01Поэтому нам любопытно: с чего вы начинали в этой области? И как складывался ваш путь
00:01:08в карьере разработчика ПО?
00:01:11Да, отличный вопрос, Андрис и Уэш. Спасибо, что пригласили. Да, как я начал?
00:01:17Ну, когда я учился в старшей школе, мама моей девушки познакомила меня с Red Hat Linux.
00:01:23Она проходила курс компьютерных наук в общественном колледже и
00:01:29просто показала мне свой рабочий стол. Это был не Windows и не Mac. Я был очень сбит с толку, а это оказался рабочий стол KDE на базе
00:01:37Red Hat Linux. Я был очарован и начал увлекаться этим еще в юниорском классе старшей школы,
00:01:44а затем получил свою, эм...
00:01:47степень по компьютерным наукам. Меня очень интересовала инфраструктура, операционные системы и обучение компьютера тому,
00:01:55чего мы раньше не могли контролировать. Так все и началось.
00:02:00Значит, вы всегда были сторонником открытого ПО? Полагаю, раз уж вы пользовались Linux.
00:02:06О, на все сто.
00:02:08Linux — моя основная система
00:02:10уже более двух десятилетий, примерно с
00:02:122005 года.
00:02:15Понятно. Да, а когда вы всерьез занялись SRE?
00:02:20Да, это было около 10 лет назад. До этого я был классическим специалистом по операциям в стремительно растущей
00:02:29SaaS-компании под названием Acquia. Вы наверняка слышали о Drupal, основателе проекта с открытым исходным кодом Drupal.
00:02:34Он основал компанию, которая предоставляла профессиональные услуги, хостинг и поддержку для сайтов на Drupal.
00:02:38Я работал в их операционной команде, но компания росла, причем росла бешеными темпами.
00:02:45Было очень много крупных клиентов, чьи имена вы бы узнали. С таким масштабом пришло и множество рутинной работы. Вот именно!
00:02:51Теперь мы говорим об SRE. Было много рутины, происходило много инцидентов.
00:02:55Мы начали сталкиваться с реальностью работы на масштабном уровне в сравнении с архитектурой, с которой мы изначально
00:03:01стартовали, и нашими первоначальными процессами. Поэтому я начал читать «Проект „Феникс“». Я увлекся
00:03:09практикой системного администрирования в облаке, что было первой книгой по SRE.
00:03:12Это была не книга Google по SRE, там SRE уделялось всего пара страниц и описывалось 12 практик.
00:03:17И опять же, меня это очень-очень заинтриговало, и я начал применять это на практике.
00:03:21А я на самом деле не знаю, что такое «Проект „Феникс“». — О боже мой!
00:03:26Да, да. «Проект „Феникс“» — это была самая первая книга по DevOps.
00:03:31И это действительно хорошая книга.
00:03:34Да, это история о том, как
00:03:39вице-президент по ИТ-операциям сталкивается с серьезными организационными проблемами и
00:03:45под руководством загадочного наставника, который, как выясняется позже, является членом совета директоров компании,
00:03:53узнает о
00:03:55том,
00:03:56как концепции старой школы заводского производства напрямую применимы к разработке ПО и ИТ-операциям.
00:04:05В ней представлено множество концепций, которые я использую и по сей день и о которых рассказываю клиентам, потому что они чрезвычайно актуальны.
00:04:11Так что да, это была первоначальная книга, но затем,
00:04:13помимо нее, я читал целую кучу всего, многое из области менеджмента.
00:04:18Так что в дополнение ко всей технической литературе, которую я читал для повышения квалификации как SRE и разработчик ПО,
00:04:24была и управленческая литература, ведь DevOps и SRE — это социотехническая практика.
00:04:29Вы преодолеваете разрыв между тем, что могут технологии, и тем, как люди используют их для достижения хороших бизнес-результатов.
00:04:36И я представляю, сколько здесь связано с человеческим фактором и борьбой с ним, верно?
00:04:42О да, абсолютно. Черт возьми, есть даже книга о человеческом факторе, которую вам тоже стоит прочитать.
00:04:50Да, один джентльмен... К сожалению, его имя сейчас вылетело у меня из головы, но он
00:04:57профессор в Сиднее, в Австралии, и все, о чем он говорит — это авиакатастрофы и то, как велик человеческий фактор.
00:05:05Это очень полезно для культуры пост-мортемов: человеческий фактор — это не конец.
00:05:10Если вы говорите: «О да, причиной этого инцидента, этого сбоя в продакшене, был человеческий фактор»,
00:05:16нет, это начало дискуссии, а не ее конец. Какие факторы способствовали тому,
00:05:21что этот человек в том месте промахнулся мимо клавиш и снес продакшн-базу данных?
00:05:27Должен ли был у него быть доступ к продакшн-базе? Были ли инструменты эргономичными? Спал ли он прошлой ночью?
00:05:34Как часто его пейджили? Знаете, там есть самые разные нюансы.
00:05:38Но да, когда люди говорят «человеческий фактор», я сразу вспоминаю ту книгу. Обязательно скину вам ссылку для заметок к выпуску.
00:05:45Да, я помню свое самое первое
00:05:49знакомство с сквозным тестированием. Я слушал курс, где кто-то рассказывал
00:05:54об инциденте, когда было разработано какое-то программное обеспечение
00:05:58для хирургов, и нужно было нажимать кнопки в определенном порядке.
00:06:03Но хирурги так привыкли нажимать их, что делали это
00:06:07настолько быстро, что программа начинала сбоить, и никто не ожидал, что такое может произойти.
00:06:13Так что это довольно интересно.
00:06:15Да, определенно, пересечение между людьми и автоматизацией — это то, на что мы всегда должны обращать внимание в продуктах, которыми управляем.
00:06:25Да.
00:06:26А еще я слышал, что вы начинали
00:06:28с DevOps и SRE в эпоху пейджеров, когда приходилось пользоваться ими. Это правда?
00:06:35Да, на самом деле да. Когда меня впервые вызвали на дежурство, мне выдали физический
00:06:42пейджер. И представьте себе. Ого, а в каком году это было?
00:06:46Это был 2005 год.
00:06:48Ого, понятно. Так что моя первая, моя первая работа в техсфере... о, это здорово.
00:06:55Я работал в гараже, как и положено любому успешному стартапу, в Плант-Сити, штат Флорида.
00:07:02У моего хорошего друга
00:07:04отец подрабатывал тем, что прямо из своего гаража управлял веб-хостингом, почтовым хостингом и коммутируемым интернет-провайдером.
00:07:12Его звали... его зовут Кертис Феллаини, я питаю к нему огромное уважение, и он...
00:07:18он научил меня всему, что я знаю. Но да, мы использовали инструмент для дежурств под названием What's Up Gold.
00:07:24Знакомо это название? И суть была в том, что он делал не HTTP-проверки,
00:07:33а отправлял ICMP-пинги на серверы, то есть просто старый добрый пинг. И если не получалось ответа,
00:07:40он отправлял
00:07:42оповещение. И у меня был пейджер, я носил пейджер некоторое время, когда работал в том месте.
00:07:48Сразу после этого, когда я работал в своем альма-матер с суперкомпьютерами и HPC, это был Nagios
00:07:54и, знаете, текстовые сообщения на мобильный телефон.
00:07:57Это был осознанный выбор, или к тому моменту уже появились новые технологии, как вы сказали, SMS-сообщения и все такое?
00:08:07Ну да, в те дни инструментов было просто больше.
00:08:11Конечно, выбор был ограничен, но для мониторинга инфраструктуры
00:08:15уже было доступно больше инструментов. И когда я работал в отделе HPC в Университете Южной Флориды,
00:08:22мы уже имели дело с масштабом в сотни серверов, потому что это HPC.
00:08:27У вас стойки серверов выполняют вычислительные задачи, так что нам требовалось
00:08:31нечто большее,
00:08:34чем просто пейджер. Содержимое сообщения в пейджере тоже имело значение, потому что если вы получали
00:08:40просто сообщение вроде «ну ладно, надо пойти проверить, что там случилось», по сигналу бипера,
00:08:45то с Nagios вы получали хотя бы немного контекста: этот сервер
00:08:50лежит или эта служба на сервере упала. Так что даже тогда,
00:08:56в те дни, была определенная искушенность в плане возможности настраивать,
00:09:01знаете,
00:09:03то, что вы хотите мониторить для каждого хоста или каждой службы.
00:09:06Конечно, это было задолго до всяких SLO, мы об этом даже не думали.
00:09:13Мы думали только о том, открыт ли этот порт и дает ли он ожидаемый ответ.
00:09:17Да, ого, 2005 год. Я тогда, кажется, учился в средней школе, я даже не думал ни о каких
00:09:26компьютерных
00:09:28науках в то время.
00:09:30Да, по мне не скажешь, но я старше, чем выгляжу. Да, я понял. Ну, вы отлично выглядите. — Большое спасибо.
00:09:37Итак, судя по моим небольшим поискам, вы вроде бы работали в Meta. Чем вы там занимались?
00:09:43И каково это — работать в Meta?
00:09:45О боже мой. Э-э, я был инженером по продакшену
00:09:48и менеджером инженеров по продакшену.
00:09:52В общем, это означает их версию SRE. Я работал над двумя проектами. Первый проект, длившийся всего несколько месяцев,
00:10:00был в команде под названием Conveyor. На самом деле есть публичные статьи, кажется, в IEEE, о
00:10:06Conveyor. Conveyor — это, пожалуй, одна из крупнейших систем непрерывной доставки на планете.
00:10:11Все артефакты сборки, которые выпускаются для бэкенд-сервисов в Meta,
00:10:18проходят через Conveyor, и происходит поэтапное развертывание всех изменений на тысячах и тысячах бэкенд-сервисов.
00:10:25Это сугубо внутренний инструмент Meta?
00:10:29Только внутренние, да.
00:10:31Но да, есть статья Бориса Губрика, которую вам стоит почитать о том,
00:10:37что они создали, и это очень-очень интересно.
00:10:39Так что я был там несколько месяцев, когда они масштабировали это
00:10:43и помогали им с настройкой оповещений, потому что поначалу
00:10:46там получаешь по сотен — сотни алертов в неделю, и я такой: «Подождите,
00:10:49давайте это почистим»
00:10:51и, знаете, приведем их наблюдаемость в порядок, чтобы они хотя бы знали, когда происходят сбои. А еще я
00:10:58подготовил кое-какие
00:11:00как бы сказать, экстренные процедуры для отключения ключевых функций с помощью их инструмента управления фичами,
00:11:06э-э, просто чтобы убедиться, что мы сможем быстро оправиться от инцидентов.
00:11:10Так что я занимался этим несколько месяцев, но большую часть времени я провел
00:11:13в другой команде, которая
00:11:16была чем-то вроде внутреннего Heroku. То есть у вас есть очень простые stateless-сервисы,
00:11:23и, знаете, команды штампуют их постоянно, и их нужно где-то запускать, и эта
00:11:29команда и сервис существовали для того, чтобы упростить этот процесс, потому что в старые времена развернуть сервис было очень сложно. Э-э, так что я был первым
00:11:37production-инженером
00:11:40в этой команде, и это было довольно дико. Но вот что я там делал.
00:11:44Это было, безусловно, очень весело. Люди, с которыми я работал,
00:11:48просто обладали мозгами раза в пять
00:11:51больше моих, понимаете? Люди, с которыми работаешь в компаниях такого рода, просто
00:11:55сверхъестественно блестящи, и я очень многое там узнал. Я как раз хотел сказать, что есть такая компания Honeycomb, и
00:12:02человек, который ее основал, Чарити Мейджерс, она ведь работала в Meta?
00:12:06Вы ее знаете? Вы с ней встречались?
00:12:09Э-э, да, это очень-очень интересно,
00:12:12что вы спросили. Я встречался с ней на мероприятии Observability Days полтора года назад в Бостоне. Я познакомился с ней лично.
00:12:20Да, она действительно работала в Meta, э-э, и
00:12:22вдохновением для Honeycomb послужил
00:12:26инструмент наблюдаемости планетарного масштаба под названием Scuba.
00:12:30Да, я пользовался Scuba, и он мне очень нравился, и я рад, что она, э-э,
00:12:37основала компанию для этой цели. Мы с ней в последнее время то общались, то прерывались в LinkedIn
00:12:44из-за нашего общего интереса к тому,
00:12:47как агентное программирование повлияет на надежность, так что
00:12:51мы периодически обсуждали эту тему.
00:12:54Но да, она очень крутой человек, и это привилегия — время от времени общаться с ней.
00:12:59Да-да, так что это отличный переход к тому, о чем мы тоже хотели вас спросить. Куда, по вашему мнению, ИИ
00:13:06приведет SRE, DevOps и все эти практики?
00:13:13О боже, ладно. Какая потрясающая подводка. Большое спасибо. Перейду сразу к сути.
00:13:19У нас есть разработчики программного обеспечения, которым дали
00:13:24потрясающий инструмент — агентную разработку. Все поголовно генерируют код по щелчку пальцев, э-э, с помощью таких инструментов, как Claude и тому подобных.
00:13:35Так вот, это значит, что через наш поток создания ценности,
00:13:39наши CI/CD-пайплайны, тестирование,
00:13:42ревью, развертывание кода, реагирование на инциденты, процедуры управления изменениями — будет проходить
00:13:50на порядок больше кода. Весь этот код хлынет через систему, которую каждый из нас построил для своих компаний,
00:13:56и это значит, что мы подвергнем стресс-тесту
00:13:58все эти возможности. Например,
00:14:01существует линейная
00:14:04зависимость
00:14:06между количеством изменений, которые вы вносите в ПО, и количеством пейджеров или инцидентов, которые вы получаете.
00:14:12Это установленный факт.
00:14:14Так что
00:14:15вполне разумно предположить, что если вы увеличите поток кода через свой пайплайн в 10 раз,
00:14:20у вас будет в 10 раз больше алертов.
00:14:23И как же
00:14:26ваша организация на это ответит? — вот в чем вопрос. Поэтому со стороны SRE я ожидаю,
00:14:32что в будущем мы, специалисты по эксплуатации, станем очень, э-э,
00:14:39очень востребованы, потому что мы окажемся узким горлышком. Теперь
00:14:42дело уже не в том, чтобы просто писать код, э-э, и отправлять его в прод. Теперь вопрос в том, как мы им управляем?
00:14:49Работает ли оно? Отвечает ли ожиданиям клиентов?
00:14:51эм
00:14:53и
00:14:55И поэтому я ожидаю, что это станет главным изменением.
00:14:58Это огромная проблема, потому что во время этого перехода многое может пойти не так.
00:15:04Как я уже упоминал, у вас может быть гораздо больше инцидентов. Как вы учитесь на ошибках и
00:15:09знаете, продолжаете ли вы проводить разборы полетов? Строите ли вы CI/CD пайплайн, который действительно работает, знаете,
00:15:15и в основном делает так, чтобы человеческие усилия всегда давали высокий результат?
00:15:20Самое смешное, что мы готовились к этому событию десятилетиями. Просто, понимаете,
00:15:27мы привыкли думать об этом в контексте бигтеха, где у вас 20 000 инженеров,
00:15:31но
00:15:33теперь у нас есть небольшие организации, которые могут писать в 10 раз больше кода, и поток при этом тот же.
00:15:38Так что все те фундаментальные принципы,
00:15:40о которых эти крупные компании писали и говорили на протяжении последнего десятилетия,
00:15:47теперь нам всем придется претворять в жизнь.
00:15:49Все основы действительно нужно соблюдать. И помимо этого,
00:15:53существует также вопрос о том, что
00:15:56организации, например, команды разработки ПО, выстраивали свою работу вокруг идеи о том, что написание кода
00:16:03занимает больше всего времени.
00:16:05Поэтому нужно было следить, чтобы инженеры кодировали как можно больше. Если это больше не так,
00:16:09нам придется перестроить процессы вокруг тех задач, которые теперь отнимают больше всего времени.
00:16:15Так что произойдет определенный сдвиг в управлении такими организациями, и наконец,
00:16:20думаю, вы видели это в тренде ИИ-SRE,
00:16:23о котором я часто рассказываю в своем подкасте, — нам нужно будет грамотно внедрять
00:16:31эти технологии в подходящих местах, чтобы извлекать максимум пользы для выполнения операций, верно?
00:16:37Потому что, например, существуют компании — думаю, хороший пример incident.io, — куда приходит пейджинг-алерт,
00:16:44и еще до того, как вы встали с постели,
00:16:47уже запускается агентный воркфлоу, который анализирует: какие изменения недавно вносились в кодовую базу?
00:16:53Что именно говорится в алертах? Что показывают метрики? И пытается
00:16:59сделать первичный анализ, пока вы еще не встали с постели и не протерли глаза от сна,
00:17:04Так что в некоторых наших операционных обязанностях
00:17:09можно извлечь большую пользу из ИИ, но не нужно внедрять абсолютно всё подряд.
00:17:12Вам нужно подумать о том, каковы реальны проблемы, какова окупаемость инвестиций
00:17:16Но в любом случае, это моя теория. Я как раз провожу вебинар через пару недель на эту тему
00:17:23Это так интересно, потому что тот вариант использования, о котором вы упомянули ранее,
00:17:29когда вас вызывают из-за чего-то,
00:17:32разве это уже реализовано на практике, потому что
00:17:36одна проблема, которая, как мне кажется, может возникнуть: допустим, у вас есть уровни триажа, где на первом этапе
00:17:43ИИ, возможно, справится сам. Но затем, на втором, нам нужен человек в цепочке принятия решений, и иногда я
00:17:51просто для сравнения с написанием кода: иногда я вижу, как Claude Code рассуждает и думает:
00:17:56«Я должен сделать вот так», а потом вдруг говорит:
00:17:59«Стоп,
00:17:59нет, пожалуй, мне нужно удалить всё это и начать сначала».
00:18:02И мне кажется, то же самое может произойти с этими ботами для управления инцидентами. Они думают: «О, это легко исправить.
00:18:10Погодите, может, я справлюсь сам», — в ситуациях вроде этой.
00:18:13Нет, вы абсолютно правы.
00:18:15Кажется, в последнее время популярна цитата IBM из 1970-х: «Никогда не поручайте компьютеру принимать
00:18:22управленческие решения». Что я имею в виду? Есть два способа использования
00:18:27этого
00:18:29инструментария ИИ или автоматизации в целом. Существует две философии автоматизации,
00:18:32о которых писали люди. Первая называется «принципом остатка», когда вы по сути говорите: «Хорошо, у нас будет ПО»
00:18:38(и необязательно ИИ, это могут быть просто инструменты), которое выполняет всю эту работу
00:18:43автономно за нас, и нам не нужно об этом думать.
00:18:46А нам, людям, достается то, что осталось — как правило, задачи, для решения которых нужна степень PhD.
00:18:51Эм,
00:18:53во-первых,
00:18:54это не очень эффективно, ведь тогда весь ваш бюджет уходит на специалистов с PhD,
00:18:57а во-вторых, вы возлагаете слишком большие надежды на автономную систему, и если она примет неверное решение, у вас будут проблемы.
00:19:04Более
00:19:07эффективная философия — это так называемый «компенсаторный принцип», когда вы приумножаете человеческие усилия,
00:19:15позволяя компьютерам и автоматизации делать то, что у них получается хорошо, а людям — выполнять то,
00:19:22что хорошо удается людям,
00:19:25а именно:
00:19:26Мы понимаем контекст наших систем. Мы понимаем проблему, которую пытаемся решить, и, знаете, пользовательский опыт.
00:19:33В нашей голове хранится огромный пласт контекста, который делает
00:19:38для нас гораздо более выгодным использовать его, а не поручать ИИ делать абсолютно всё. Так что, отвечая на ваш вопрос более прямо,
00:19:44я считаю, что переоснащение с помощью ИИ действительно не должно
00:19:50вносить изменения в рабочую среду, если это не строго ограниченный и четко определенный путь.
00:19:58Я приведу пример: автоматический откат кода. Мы делаем это автоматически без ИИ, если вы думаете о Kubernetes.
00:20:06Верно? Если у вас есть развертывание, вы меняете, знаете, версию своего нового образа контейнера, и если ваши
00:20:13проверки готовности не проходят успешно — угадайте что?
00:20:16Изменения не будут развернуты.
00:20:19Верно. Так что эти механизмы очень просты, их легко понять, и они позволяют нам безопасно внедрять изменения.
00:20:26Знаете, решение таких четко определенных задач можно оставить автоматизации, и она уже это делает.
00:20:32Но позволять
00:20:35ИИ прямо сейчас заявлять: да, мы должны внести эти изменения в нашу инфраструктуру без участия человека —
00:20:41я считаю безответственным. Я думаю, что мы, люди, возвращаясь к вопросу об ограничениях,
00:20:46будем тратить свое время на то,
00:20:49действительно ли это правильное решение.
00:20:52Знаете, вынесение подобных одобрений, проверка кода и анализ любых изменений инфраструктуры,
00:20:59как мне кажется, станут тем,
00:21:00чему мы будем уделять много сил.
00:21:03И да, мы захотим это автоматизировать, где это возможно, но это требует дисциплины и подтвержденной надежности.
00:21:09Да, и еще один вытекающий из ваших слов вопрос касательно линейного сравнения: чем больше у вас кода,
00:21:19тем больше инцидентов у вас будет. Вы работаете консультантом
00:21:22в этой сфере. Слышали ли вы, что компании сталкиваются с этим прямо сейчас, например,
00:21:28поскольку они
00:21:30перекладывают
00:21:31или создание большего объема кода на ИИ, они в результате получают больше инцидентов?
00:21:36Безусловно, определенно да.
00:21:39Определенно да, и я бы также добавил, что начинают проявляться и другие типы сбоев из-за
00:21:47этих изменений.
00:21:49Думаю, о чем-то очень простом для понимания и осмысления —
00:21:53это
00:21:54перегрузка ваших CI/CD-пайплайнов. Задержка между созданием артефакта сборки и его отправкой в продакшн становится всё больше,
00:22:00потому что через них проходит больше изменений. Так что да, организации начинают
00:22:05уже чувствовать эти болевые точки. То есть, если привести быстрый пример или кейс, у меня есть
00:22:12клиент, для которого я недавно проводил оценку, потому что одна из моих задач — изучать
00:22:17общий операционный подход компании, то, как они выпускают код, как они его запускают, и давать им рекомендации о дальнейших действиях.
00:22:24Так вот, одна из команд сказала: да, эта штука с Клодом очень хороша, давайте начнем штамповать фичи.
00:22:31И они сделали это, но
00:22:33они не изменили процесс релизов, у них не было хорошего, надежного процесса проверки кода,
00:22:38и поэтому количество инцидентов сразу же подскочило, так что вместо того,
00:22:43чтобы сосредоточиться на коде и выпускать всё подряд, как они планировали, их завалили эскалациями от клиентов
00:22:49и инцидентами.
00:22:51Так что да, это не теория, это происходит прямо сейчас,
00:22:55и этот многократно возросший объем изменений в продакшене
00:23:01обнаружит
00:23:03все слабые места в вашем операционном подходе.
00:23:06И когда вы вроде как
00:23:09врач SRE, у которого есть клиент с такой проблемой, что вы порекомендуете делать в этом случае,
00:23:16как вы только что упомянули?
00:23:18Верно. Я уже упоминал об этом ранее: все те фундаментальные принципы, о которых мы говорили
00:23:24последние пару десятилетий — мы должны сосредоточиться на них.
00:23:27Например,
00:23:29командам необходимо иметь надежную стратегию тестирования.
00:23:35Они должны быть уверены, что код, который они собираются отправить в продакшн, высокого качества.
00:23:39Всё то, чему они научились в прошлом... я большой сторонник целевых уровней обслуживания,
00:23:43я большой сторонник SLO.
00:23:47Потому что это позволяет нам оценивать работоспособность нашей производственной системы с точки зрения клиента,
00:23:52так что
00:23:54это важная часть головоломки, поскольку она позволяет вам на основе данных регулировать объем изменений,
00:23:59вносимых в продакшн, в виде запросов на функции и тому подобного. Таким образом,
00:24:03Вы не подвергали риску существующий источник дохода
00:24:07в погоне за новыми
00:24:10Такова бизнес-причина внедрения SLO. Что я заметил в отношении SLO в прошлой компании:
00:24:16там считали, что
00:24:19каждая команда должна соблюдать целевые показатели SLO. Но поскольку мы двигались очень быстро,
00:24:25мы не укладывались в эти цели,
00:24:28и многие команды отставали.
00:24:30Руководство решило: «Неважно, выпускать новые функции важнее, чем соблюдать показатели SLO».
00:24:36Да.
00:24:37И это, пожалуй, главная причина, почему SLO оказались не так эффективны, как обещали Google десять лет назад.
00:24:44Дело в том — и я уже говорил об этом ранее, — что у вас может быть программа SLO.
00:24:49Можно пройти через процесс, когда инженеры собираются и думают: «Хм, каков путь пользователя?»
00:24:55Давайте это оцифруем, настроим систему наблюдаемости,
00:24:57подключим Prometheus или OpenTelemetry и сделаем очень красивые дашборды.
00:25:01Но если продакт-менеджер,
00:25:05если продуктовая команда не готова играть по правилам,
00:25:07если топ-менеджмент не готов играть по правилам,
00:25:09тогда
00:25:12все впустую.
00:25:14Тогда у вас просто будут SRE и инженеры, которые сидят по углам и говорят: «Эй, дела плохи»,
00:25:19в то время как
00:25:21руководство хочет продолжать релизы. Чтобы SLO работали,
00:25:26в эту игру должны играть все. И когда я оцениваю
00:25:32зрелость SLO в организации, — а я этим часто занимаюсь, — я обычно задаю вопрос: если бюджет ошибок исчерпан,
00:25:38что делает продакт-менеджер?
00:25:41Если продакт-менеджер говорит: «Хорошо, в следующем спринте мы меняем объем задач»,
00:25:46то отлично.
00:25:48У вас средний уровень зрелости. Если нет —
00:25:50низкий. Я даже разработал модель зрелости SLO от одного до пяти (где один — незрелая, а пять — оптимизированная), чтобы помочь
00:25:58компаниям понять, на каком этапе они находятся. Но вы правы: во многих организациях
00:26:03не используют SLO по-настоящему. У них есть дашборд, метрики, инженеры получают за них зарплату,
00:26:08но
00:26:10бизнес-решения на основе SLO не принимаются.
00:26:12Это просто алерты.
00:26:16А какие типы клиентов обращаются к вам? В какой
00:26:21ситуации они находятся, что
00:26:24им требуется ваша помощь? Это хорошая ситуация, плохая или что-то среднее?
00:26:28По-разному. Обычно я работаю с клиентами в двух ключевых точках перелома. Первая точка — это
00:26:37ранняя стадия компании, которая только что получила раунд финансирования, отдел продаж преуспевает, найден Product/Market Fit,
00:26:44но они еще «зеленые» и никогда раньше не строили инфраструктуру корпоративного уровня,
00:26:49никогда не продавали крупным клиентам и начинают ломаться
00:26:53под давлением возросших масштабов. Очень похоже на мой собственный опыт в начале карьеры.
00:26:59Я отлично это понимаю, потому что сам через это прошел. Это первая точка перелома.
00:27:04И это интересный момент. Это хорошая проблема, хотя сотрудникам может быть непросто.
00:27:09Вторая точка перелома
00:27:12обычно наступает, когда вы становитесь крупной организацией и вам нужно стандартизировать
00:27:17работу процессов в разных командах.
00:27:21Возможно, у вас есть программа SRE, и нужно оценить, насколько она эффективна, работают ли процессы,
00:27:28работает ли модель взаимодействия, участвуют ли в этом инженерные команды и продуктовый отдел.
00:27:34Компании, которые совершают много поглощений,
00:27:37обычно обращаются ко мне, потому что пытаются обуздать этот хаос: при каждом поглощении
00:27:44появляется совершенно новый стек, который нужно интегрировать. Тут приходится задумываться о верхнеуровневом управлении
00:27:50и о том, чтобы все играли по одним правилам.
00:27:55Конечно.
00:27:57И я думаю, что в небольших компаниях, которые привлекли финансирование,
00:28:02с появлением ИИ люди стали использовать его для создания функций,
00:28:06и этот недостаток структуры усугубится, ведь все просто пишут функции с помощью ИИ
00:28:13и не думают ни о логах, ни о метриках, ни о трейсах.
00:28:16С какими проблемами чаще всего приходят компании на ранней стадии — с такими, которые
00:28:23для вас очевидны, а они их даже не замечают?
00:28:27Да, я уже отчасти упоминал об этом в предыдущем ответе, но сформулирую общую картину.
00:28:34так что
00:28:36Самая вопиющая вещь, которую я вижу — это разорванная обратная связь между тем, что происходит в продакшене,
00:28:41и тем, каков клиентский опыт, а также тем, как расставляются приоритеты в продукте.
00:28:46И я наблюдаю это уже долгое время во многих командах. Во многих командах. Это, пожалуй, общая проблема.
00:28:55Поэтому, когда я работаю консультантом,
00:28:58одна из мыслей, которые крутятся у меня в голове — как убедиться, что эта обратная связь налажена?
00:29:03Поразительно,
00:29:05сколько компаний сталкиваются с инцидентами,
00:29:08клиенты начинают расстраиваться,
00:29:10они создают тикеты в поддержке, и поддержку затапливает обращением.
00:29:13У поддержки есть этот потрясающий дар, который можно передать продуктово-инженерной организации — он называется обратной связью. Они знают,
00:29:23что злит клиента, что мешает ему пользоваться сервисом и что потенциально заставляет его уйти.
00:29:30И я снова и снова видел,
00:29:33как эту обратную связь полностью игнорируют или ставят в приоритете ниже работы над фичами.
00:29:41И в конечном итоге
00:29:44все силы брошены на фичи, даже несмотря на то, что продукт пылает в огне, и для меня
00:29:51это то, что я замечаю сразу же, когда опрашиваю команды и оцениваю их.
00:29:55Но обычно, когда вы работаете внутри компании, вы этого не видите, потому что думаете: «Ну, я софт-инженер,
00:29:59я мотивирован выпускать фичи. В прошлом квартале я выпустил 50 виджетов, круто, я получу бонус».
00:30:05Продуктовые менеджеры думают точно так же:
00:30:07«Да, мы выкатили эти проекты, этот клиент подписывает контракт с нами, потому что мы это сделали».
00:30:11Между тем существующие клиенты просто в ярости, они недовольны происходящим.
00:30:16Так что обратная связь разорвана,
00:30:19и это из-за культуры в Сан-Франциско или просто потому,
00:30:22что люди хотят выглядеть лучше конкурентов? Не знаю. Как вы думаете, в чем причина?
00:30:28Я не думаю, что это свойственно только Сан-Франциско. Я думаю, это свойственно бизнесу в целом, структурам мотивации,
00:30:36бизнес-культурам, потому что
00:30:39когда
00:30:41у вас
00:30:42появляются разные отделы,
00:30:44а по мере роста компании это происходит естественно, потому что нужно организовывать работу,
00:30:49вы начинаете изолироваться.
00:30:51У меня софт-инженеры здесь, у меня продакт-менеджеры здесь. Да, возможно, они внедрены
00:30:55в инженерные команды, но у них свой набор стимулов. Есть поддержка, DevOps и SRE-специалисты.
00:31:01У них свои стимулы, но все они разрознены и противоречат друг другу.
00:31:06Верно, и
00:31:09обычно
00:31:11на этом этапе игры никто не садился с ними и не говорил:
00:31:13«Как нам изменить структуру мотивации так, чтобы
00:31:18мы все двигались в одном направлении?» Одна из вещей, которые делала Meta
00:31:21и которые мне очень нравились и, как мне кажется, отлично работали,
00:31:25заключалась в том, что при оценке работы инженера, по крайней мере в командах, где я работал,
00:31:31смотрели не только на фичи.
00:31:34Они оценивали операционное превосходство, надежность продакшена, смотрели на то, в каких инцидентах они участвовали,
00:31:41над какой работой по надежности они трудились, над какой масштабируемостью они работали.
00:31:45Как они сделали систему более надежной и удобной в эксплуатации, и это влияло на то, получат ли они бонус,
00:31:51получат ли повышение. Это была важная часть
00:31:54критериев.
00:31:57И поэтому,
00:31:58когда они действительно начали уделять этому внимание, это означало, что стимулы для софт-инженеров изменились, и в команде, где я работал,
00:32:05где мы действительно
00:32:07продвигали это вместе с инженерными лидами, с которыми я сотрудничал,
00:32:12эти инженеры волшебным образом начали подходить ко мне и говорить: «Эй, я хотел бы поучаствовать с тобой в работе над надежностью,
00:32:18могу ли я взять на себя этот процесс нагрузочного тестирования?»
00:32:20Конечно. Абсолютно. Вот инструкции, вот скрипты, ну знаешь,
00:32:25вперед и с песней. Поразительно, что происходит, когда стимулы
00:32:29сдвигаются.
00:32:31Так что я думаю, это просто естественное развитие для любой организации: если вы крошечный стартап, где каждый отвечает за всё,
00:32:38и вы пытаетесь получить финансирование, и пытаетесь, знаете, привлечь первых клиентов и сделать их счастливыми,
00:32:43я думаю, стимулы уже согласованы,
00:32:45Иначе компания бы не выжила, но по мере роста и появления разделения обязанностей
00:32:51становится все сложнее поддерживать единую систему мотивации во всей организации.
00:32:55Так что да, именно здесь начинают проявляться социотехнические аспекты, когда мы говорим о SRE и DevOps.
00:33:00Отлично, и вы также упомянули, что на фоне этого стремительного развития ИИ
00:33:06потребуется больше таких специалистов, как вы, работающих в этой сфере, и знаете, с другой стороны
00:33:12мы слышим, что разработка ПО умирает. Рабочих мест больше нет, так?
00:33:17Как вы считаете, для джуниор-разработчиков, которые слушают этот подкаст,
00:33:23являются ли SRE и DevOps хорошим направлением для старта именно сейчас? Да, и еще раз да.
00:33:30Я возражу и не буду тем человеком, который скажет, что разработка ПО мертва.
00:33:36На самом деле, я думаю, что фундаментальные знания
00:33:38становятся еще более
00:33:41важными.
00:33:43Понимание языков программирования, их работы, алгоритмов и их устройства теперь еще важнее,
00:33:50потому что
00:33:53как иначе мы сможем проверять код, который генерирует ИИ?
00:33:56И как мы будем проектировать работающие системы, ведь если просто сказать LLM-модели: «Эй, спроектируй это»,
00:34:04вы уверены, что это сработает? Скажу так: откройте проект в Claude Code
00:34:08и попросите его спроектировать для вас мост
00:34:11или небоскреб.
00:34:15А затем я хочу, чтобы вы взяли этот проект и пошли его строить.
00:34:18А потом я хочу, чтобы вы пошли и посидели там. Вам будет комфортно это сделать?
00:34:22Вам будет комфортно ехать по мосту, который он спроектировал?
00:34:25До тех пор, пока вы не перестанете качать головой, нам будут нужны инженеры.
00:34:31Верно, а что касается SRE и DevOps специалистов... Да, очевидно,
00:34:34нас должно быть больше, потому что именно там возникают ограничения. Если мы вносим так много изменений в систему,
00:34:39мы определенно должны убедиться, что она в порядке, и что мы понимаем последствия этих изменений для продакшена.
00:34:43Что у нас есть CI/CD пайплайн, поток создания ценности, если экстраполировать это на верхний уровень,
00:34:51который исправен, мониторится и рассматривается как продакшен-сервис. Потому что, на мой взгляд, все эти навыки станут еще важнее.
00:34:58Вот как я обычно на это смотрю. Это похоже на гонки Формулы-1, где есть пит-стоп команда.
00:35:04И эта команда знает всё об автомобиле, может заменить любую деталь и дает водителю возможность доминировать на трассе.
00:35:12Вам нужны такие люди,
00:35:15потому что они создают для продакт-менеджеров и архитекторов среду,
00:35:22в которой можно быстро итерировать и выпускать изменения без возникновения этих ограничений.
00:35:27Так что, на мой взгляд,
00:35:29знаете,
00:35:30сейчас отличное время быть SRE. Пару лет назад все было иначе, потому что всех увольняли,
00:35:35но я думаю, что
00:35:37если вы действительно сосредоточитесь на основах, если вы понимаете
00:35:39Linux и работу систем, а также социотехнические аспекты, то есть суть того, что значит быть SRE,
00:35:46я думаю, вы сможете зайти
00:35:49очень далеко
00:35:51в этой карьере. Но мы должны быть в курсе появления этой агентной разработки.
00:35:57Мы не можем прятать голову в песок.
00:35:59Итак, вы упомянули,
00:36:02Кажется, «Проект Феникс»? Да, книгу.
00:36:05Да. Какие еще ресурсы вы считаете ценными для тех, кто хочет глубоко погрузиться в эту тему?
00:36:12Ох, их просто масса. Позвольте мне назвать вам самые мощные книги.
00:36:18Например, «Руководство по DevOps» — отличная книга. Когда она вышла, я почувствовал,
00:36:21что это отличная выжимка всего, что я знал до её появления. Это превосходное,
00:36:27просто идеальное универсальное пособие. «Впереди перемен» Джона Коттера
00:36:30рассказывает о лидерстве при трансформационных изменениях и об организациях.
00:36:34Она дает вам фреймворк, и когда вы работаете SRE в команде или пытаетесь провести трансформацию надежности,
00:36:41её очень полезно знать. Книга «Тойота Ката»,
00:36:45которая рассказывает о том, как Toyota занимается непрерывным совершенствованием в производстве автомобилей.
00:36:52Очень полезно. Они одни из первых, кто придумал эту систему. Да, думаю, я слышал об этом. Да.
00:36:59Кайдзен
00:37:02Был ли это концепт Toyota?
00:37:04Японское экономическое чудо — вот что породило Agile
00:37:07и DevOps, это было их предшественником. Из других книг — «Практика системного и сетевого администрирования».
00:37:13Я уже упоминал её, кажется, у них вышло новое издание. Очень, очень полезная вещь.
00:37:17Да, книги по SRE от Google тоже хороши, но я сделаю одну оговорку.
00:37:22Это книги, написанные людьми, которые работают в компаниях-гигантах
00:37:27и обладают бесконечными бюджетами.
00:37:30Поэтому их практики и подходы будут отличаться от того, как всё устроено
00:37:35в вашем стартапе из четырех человек, но я думаю,
00:37:37что объединение всех этих элементов даст вам понимание с точки зрения инженера,
00:37:44лидера
00:37:44и стратега,
00:37:46как продвигать инициативы в области DevOps и SRE.
00:37:49Так что у меня, пожалуй, уникальный взгляд, потому что я смотрю на вещи системно. Я не просто углубляюсь
00:37:55во всё, что связано с Kubernetes. Я стараюсь наладить работу команд,
00:37:59а уже после этого мы разбираемся с техническими проблемами.
00:38:03И для всех слушателей: мы разместим ссылки на упомянутые книги в описании выпуска.
00:38:09Эм, я хотел спросить: возвращаясь к ИИ, я согласен с тем, что людям нужно изучать основы и что
00:38:16программная инженерия или разработка никуда не денутся, но наблюдается такая тенденция,
00:38:21когда всё больше людей отправляют код в продакшн без предварительного ревью.
00:38:26И я уверен, что это делают какие-то пользователи Twitter или X, либо те,
00:38:30кто просто хвастается, и на самом деле это не так.
00:38:32Но есть и лидеры мнений, например, руководители ИИ-компаний, такие как Дарио или Маск, говорящие: «Эй,
00:38:39Типа в следующем году, в 2027-м, или вроде того
00:38:41вы сможете писать код и выпускать его, даже не заглядывая в него, или писать код,
00:38:47компилируемый ИИ без знания языков программирования». Что вы об этом думаете?
00:38:54Я очень сомневаюсь, что эти лидеры мнений дежурят по поддержке,
00:38:58потому что если бы это было так, они бы говорили совсем другое.
00:39:02Их нет
00:39:04Они не они не они не в инфраструктуре. Они не отдел информационной безопасности
00:39:08которые бьют тревогу
00:39:09из-за внедряемых уязвимостей, и они не имеют дела с недовольством клиентов. Послушайте,
00:39:13конечно, LLM могут выдавать
00:39:16синтаксически корректный и отчасти логичный
00:39:21код.
00:39:23Пишут ли они примерно на 20-30%?
00:39:25Возможно.
00:39:29Но даже в этом случае
00:39:31вам всё равно понадобятся нормальный мониторинг и наблюдаемость.
00:39:37Знаете, тесты в продакшене. Если вы хотите тестировать в продакшене, как пропагандирует Чарити,
00:39:42требуются определенные
00:39:45предварительные инвестиции, и по ее мнению,
00:39:48это будет наблюдаемость и понимание поведения вашего ПО. Но даже при этом, если бы я,
00:39:54например,
00:39:56был госструктурой и мне нужно было купить программное обеспечение,
00:39:59оно должно соответствовать моим требованиям безопасности.
00:40:03Если бы я работал в медицинской компании и вы писали ПО, которое буквально отвечает за поддержание жизни пациентов,
00:40:09вы действительно хотите, чтобы LLM генерировала его без проверки? Это было бы немыслимо.
00:40:15Это возвращает нас к примеру с мостом или небоскребом. Вы действительно хотите, чтобы LLM спроектировала мост или небоскреб
00:40:21и сразу сдала проект: залейте раствор и арматуру, погнали? Нет.
00:40:27Нет, абсолютно нет.
00:40:31Да, аналогия с мостом и небоскребом — отличный способ посмотреть на это, я никогда об этом так не думал.
00:40:37Знаете, если бы вы были инженером
00:40:39прошедшим путь от новичка до профи, захотели бы вы пройти по собственному мосту?
00:40:43Да, и вот о чем нам нужно подумать. Я упоминал Кертиса
00:40:49— обожаю этого парня — в начале этого выпуска.
00:40:52Он был профессиональным инженером
00:40:56в области электротехники, а это значит, что он учился,
00:41:02сдал экзамен на лицензию, стажировался в компании несколько лет, и только после сдачи сложнейшего экзамена
00:41:09и никак иначе он получил право заниматься инженерными проектами. Здесь высочайший уровень дисциплины
00:41:18в том,
00:41:21как вы всё делаете. То же самое с врачами:
00:41:23вы учите теорию, но затем годами практикуетесь на местах под надзором, прежде чем получить допуск к лечению людей.
00:41:30И для этого есть причина. Она в том, что
00:41:33принимаемые нами решения имеют огромные последствия для жизней людей, окружающей среды и
00:41:40И в мире, э-э, и в разработке ПО пока ещё
00:41:44не до конца до этого дошли.
00:41:47И я не обязательно говорю, что нам нужно копировать те модели, но
00:41:52мы должны по крайней мере
00:41:54признавать риски, которые мы создаем. Нам необходима дисциплина при создании систем, влияющих на жизни людей,
00:42:01нам нужна эта дисциплина. Мы должны думать о рисках, мы должны думать о неблагоприятных последствиях,
00:42:05мы должны брать на себя ответственность, и я думаю,
00:42:08есть много организаций, которые не хотят этого слышать, потому что это ограничивает их способность двигаться вперед,
00:42:14но
00:42:16зачем мы пишем ПО? Мы решаем проблемы людей, а не создаем новые.
00:42:23Да, и очень интересный момент, который ты сказал про своего друга — прости, забыл его имя, профессиональный инженер Кертис, — ведь Кертис...
00:42:31Да, ведь здесь, в Канаде,
00:42:33шла дискуссия о том, что для того, чтобы называться инженером, вам обязательно нужна профессиональная сертификация.
00:42:40И тогда возник спор о том, что инженеры-программисты не должны носить звание инженера, поскольку у них нет этой сертификации
00:42:48Да.
00:42:51Да, это отзывается, это отзывается.
00:42:53Да, уровень дисциплины просто совершенно разный в нашей индустрии и в их.
00:42:57Да, точно. Эм, я хотел затронуть кое-что, что ты написал у себя в
00:43:03профиле в LinkedIn: ты упомянул «от выгорания и узких мест — к надежным, быстро развивающимся командам и системам».
00:43:12Так каков твой каков твой опыт столкновения с выгоранием?
00:43:16О боже мой. У меня огромный опыт выгорания.
00:43:21Знаешь, как человек, занимающийся операционной деятельностью в быстро растущих компаниях,
00:43:26там
00:43:28определенно есть люди с комплекс героя, люди, которые хотят себя доказать, люди, у которых
00:43:35есть те мелкие психологические особенности, когда они чувствуют необходимость
00:43:39включиться и взять всё на себя. Это уязвимость, верно? Синдром самозванца,
00:43:45все эти склонности, которые есть у всех нас, стремление угодить людям — всё это может способствовать выгоранию, когда ты
00:43:52так мотивирован доказать другим, что ты хорошо работаешь, что ты не прислушиваешься к своему телу,
00:43:59не прислушиваешься
00:44:02к своим эмоциям, к своему эмоциональному состоянию. Ты не занимаешься самоанализом. Ты не даешь себе времени и пространства для отдыха.
00:44:08Твои отношения с отдыхом дисфункциональны: был период времени, когда я думал, что отдых — это плохо,
00:44:14что праздность
00:44:16была пустой тратой времени, тогда как в
00:44:20нынешний период моей жизни, когда я много думаю об этом: нет, отдых
00:44:25дает тебе возможность совершать большие свершения позже.
00:44:29Знаешь, люди, которые занимаются бодибилдингом, они же не ходят в зал каждый
00:44:35день, качая каждую группу мышц, они дают себе время
00:44:40на восстановление волокон в мышцах.
00:44:45Так почему же мы
00:44:47знаешь,
00:44:49говорим, что не можем делать так же с нашим разумом?
00:44:51Так что в этом и суть, но я помню,
00:44:55что после ухода из Meta я был словно нулевым пациентом в гигантской волне увольнений,
00:45:01так что меня затронули сокращения. Извини за это.
00:45:04О нет, в смысле... Мото бы не существовало, если бы не это. О, круто,
00:45:08верно, феникс из пепла, да? Точно, это была моя реакция на это,
00:45:13моя реакция на это, но тот период, когда я начинаю собственный бизнес
00:45:18и делаю шаг назад от индустрии, размышляя о том, как я хочу работать, действительно заставил меня
00:45:23осознать то выгорание, которое я носил с собой и которого не замечал, и...
00:45:32Знаешь, я помню себя в начале карьеры — ворчливым сисадмином. Если кто-то из ребят
00:45:38из Acquia или бывших сотрудников Acquia это слушает, вы понимаете, о чем я.
00:45:42Раньше я был очень ворчливым,
00:45:44и сейчас я очень жизнерадостный, потому что немного поработал над собой, но
00:45:49это было выгорание, и я его не замечал.
00:45:51Я просто думал, что слишком много людей обращаются ко мне с какими-то запросами,
00:45:56хотя они должны делать это сами, вроде: «читайте man-страницы», понимаешь о чем я?
00:45:59Я столкнулся с сильным выгоранием, и я думаю, что мой бизнес и то, как я им управляю, дает мне
00:46:04пространство,
00:46:07чтобы
00:46:08решать эти проблемы лицом к лицу и взаимодействовать с работой более здоровым образом,
00:46:13который больше соответствует тому, как работает мой мозг, чего я хочу в жизни, и гарантия того,
00:46:20Знаешь, я не хочу
00:46:23жить ради работы. Я работаю
00:46:25ради ярких впечатлений, которые наполняют меня изнутри, понимаешь?
00:46:28Что ты об этом думаешь? Я тут немного отвлекся.
00:46:31Я хотел сказать насчет угрюмого
00:46:34системного администратора — мне это знакомо, не по своему опыту, но в компаниях, где я работал, всегда есть парень,
00:46:40который разбирается в Kubernetes или знает всё об AWS, и если тебе что-то от него нужно,
00:46:44он такой: «Серьезно? Ладно», — идет и делает, хотя ему вовсе не хочется. Так что мне это близко.
00:46:49Но да, я понимаю, почему так происходит и откуда это берется, просто потому, что это случается сплошь и рядом, и
00:46:56поэтому я могу понять эту фрустрацию.
00:46:59И да, я считаю, что полезно от этого отдохнуть и, эм, нужно работать над собой и пробовать что-то новое,
00:47:05это точно. Тут есть личная ответственность, но также важно четко осознавать культуру
00:47:11тех сред, где ты работаешь, команд, в которых ты состоишь, людей, с которыми общаешься,
00:47:15и выбирать те места, которые подходят тебе лучше всего. Я знаю, рынок труда сейчас все еще немного странный,
00:47:21и может быть сложно сделать
00:47:22вот такой выбор и заявить: «Я просто пойду в другое место».
00:47:26Наверное, это действительно трудно, я это понимаю, но по крайней мере стоит прислушиваться
00:47:30к тому, где ты находишься, прислушиваться к своим эмоциям, к своему телу и что-то с этим делать,
00:47:36мне кажется, это важная часть головоломки. Есть
00:47:39доктор, доктор Маслак. Она создала так называемый опросник выгорания.
00:47:44Изначально она разработала его для медицинского персонала, потому что сама была из сферы медицины,
00:47:49но этот опросник выгорания и ее исследования чрезвычайно применимы в сфере технологий.
00:47:56И вы можете даже, например,
00:47:58послушать некоторые ее выступления. Кажется, она
00:48:01выступала на ежегодных мероприятиях по DevOps, которые организовывал автор «Проекта „Феникс“»,
00:48:06так что
00:48:08да.
00:48:09Я немного читал о клинической стороне выгорания, а также испытал его на собственном опыте.
00:48:15Да, и я очень рад, что это увольнение обернулось для тебя чем-то хорошим, оно проложило путь
00:48:24к созданию собственной компании, и мне кажется очень интересным, судя по тому, что я вижу в твоих соцсетях,
00:48:31что ты управляешь этой компанией
00:48:33буквально в дороге, верно? Ты
00:48:35постоянно переезжаешь. Ты живешь кочевой жизнью, я правильно понимаю? Да, все верно.
00:48:42Я действительно живу кочевником, я буквально созваниваюсь с вами через Starlink посреди высокой пустыни в Неваде прямо сейчас,
00:48:50эм, я переоборудовал свой пикап Tacoma...
00:48:54Я зову ее Молли. Я переоборудовал свой пикап в
00:48:59мобильную боевую станцию. Я стою
00:49:02в кузове грузовика,
00:49:04эм,
00:49:05и у меня здесь удобное спальное место, солнечные панели на 300 ватт,
00:49:09эм, холодильник, ну вы знаете, система питания, которую я собрал сам. Так что я сделал
00:49:16из этого грузовика микродом и работаю отовсюду: от моего участка здесь, в Неваде, до
00:49:23парковки кинотеатра AMC где-нибудь в Бостоне. Короче, я работаю отовсюду, и это очень весело.
00:49:29Я занимаюсь подобными вещами уже
00:49:31два с половиной года. Я основал Shirtomoto три года назад,
00:49:34последние два с половиной года живу кочевником, и это лучший опыт и приключение в моей жизни, типа...
00:49:41знаете,
00:49:43работаю в горах. Однажды ко мне в кузов залез медведь.
00:49:46Ого, ничего себе!
00:49:48Да, каково это было?
00:49:51Это было, пожалуй, страшновато. Эм, в те дни я жил в палатке на крыше,
00:49:54а не в своем нынешнем крутом кемпере. Это был черный медведь или бурый?
00:49:58Ну, я же жив, следовательно, это был черный медведь. Да уж, круто.
00:50:02Это был самый большой черный медведь из всех, что я видел, просто гигантский.
00:50:06Он, видимо, искал корзинки для пикника или вроде того,
00:50:08но
00:50:09он залез в кузов пикапа, где я спал наверху, на багажнике с палаткой, и от его веса машина качнулась.
00:50:17Мне пришлось нащупать в кармане ключи, нажать кнопку сигнализации,
00:50:21сделать это, и тогда медведь убежал.
00:50:24Да, после этого я понял необходимость построить что-то закрытое, вроде того, что у меня сейчас. По крайней мере, медведь меня не видит и не сможет забраться внутрь, так что...
00:50:30или зайти туда, так что
00:50:33Ты упоминал Неваду и Бостон, то есть ты каждый год совершаешь поездки через всю страну на своем пикапе? Да, каждый год.
00:50:42Я вообще планирую вернуться на северо-восток через месяц. Прямо сейчас у меня есть грузовой прицеп 6 на 10 футов, который я переоборудую.
00:50:48Прямо после этого звонка я буду сверлить отверстия, устанавливать окна и вентиляционные люки,
00:50:52а также солнечные панели на тысячу ватт, короче, делаю все по полной, и это будет мой мобильный...
00:50:58Мой мобильный командный пункт и офис, где я смогу работать в хорошую погоду.
00:51:02Это так круто. А для инженеров или людей, которые тоже этим интересуются,
00:51:08какова цена создания такого дома на колесах, как у тебя?
00:51:13Слушай, сам грузовой прицеп обойдется довольно недорого, его можно взять где-то за 4–5 тысяч, а потом...
00:51:20В зависимости от твоих запросов цена может вырасти, но его нужно утеплить,
00:51:24очевидно, сделать вентиляцию и провести электричество.
00:51:27Существует целая вселенная людей, которые занимаются подобными вещами.
00:51:31Эм, я просто один из тех немногих, кто объединил кочевую жизнь с высокими технологиями и заставил это работать.
00:51:36Но, знаешь, пикап — это Tacoma с кастомным жилым модулем сверху от компании Go Fast.
00:51:41Этот я взял б/у, но, эм...
00:51:44Да, все зависит от твоих потребностей. Я видел ребят, которые путешествуют прямо в Prius,
00:51:51знаешь, а еще вижу людей в более навороченных домах на колесах, но...
00:51:55да, порог вхождения может быть довольно низким, если ты немного разбираешься в машинах и готов...
00:52:01знаешь, засучить рукава и поработать.
00:52:04Так что вдохновило тебя начать это занятие...
00:52:07кемпингом, путешествиями и
00:52:10прокачкой своей тачки?
00:52:11Да, эм, ну, до этого путешествия я жил всего в двух местах,
00:52:14и всю жизнь потратил на работу, по сути делая то, что мне говорили окружающие:
00:52:21чего ждут от молодого парня — мол, поступай в колледж, получи диплом, найди хорошую работу
00:52:26и поднимайся по карьерной лестнице. Я так и сделал,
00:52:28и...
00:52:29в конце этого корпоративного пути я понял: эй, парень, я далеко не так счастлив,
00:52:34как должен быть. У меня есть огромные достижения, но я этого не чувствую. А когда я начал свой бизнес и подумал: эй,
00:52:41действительно ли я хочу платить такую арендную плату в районе Большого Бостона?
00:52:44Если бы я не остался в Бостоне, что бы я делал? И я наткнулся на видео на YouTube про парня, который взял грузовик U-Haul,
00:52:51ну, знаете, фургон для переездов,
00:52:53и превратил его в квартиру на колесах, и я подумал:
00:52:55Хм,
00:52:58а это довольно круто.
00:53:00И я начал погружаться в эту кроличью нору на YouTube и узнал, что существует целое,
00:53:05знаете, сообщество людей, которые живут вот так, и я просто
00:53:08изучал всё, пересмотрел кучу роликов на YouTube, а потом решил — я всё распродал,
00:53:13не стал продлевать договор аренды той квартиры
00:53:16и поехал на запад на своем Civic, а через несколько месяцев у меня появилась Молли, и я всё обустроил,
00:53:22и тронулся в путь... Да, это было понимание того, что у меня накопилось много
00:53:28жизненного опыта, который мне нужно наверстать.
00:53:31Эм, понимаете, я слишком много времени, по иронии судьбы, уделял технологическому подкасту, я проводил слишком много времени
00:53:37за компьютером и недостаточно — в реальном мире, и я понял, что мне нужен этот опыт для баланса, потому что
00:53:44я больше, чем просто помешанный на разработке чувак. Я человек со своими
00:53:49особенностями.
00:53:52У меня есть опыт, мне нужно выйти и потрогать траву.
00:53:55Мне нужно потрогать траву, а здесь, в реальном мире, я потрогал кое-что покруче травы — скалы,
00:53:59знаете, горы, воду и всё такое. Здесь столько всего можно потрогать. Да, сто процентов.
00:54:04Итак, вы упомянули историю с медведем, а были ли у вас какие-то другие
00:54:08интересные приключения во время поездок?
00:54:12Ой, их так, так много. Например, мы с друзьями проехали перевал Синнамон в Колорадо, а это бездорожье,
00:54:18немного техничное, немного сложное. Я был в Вайоминге, в Йеллоустоне, Гранд-Тетоне.
00:54:24Я разбивал лагерь на общественной земле неподалеку, где можно увидеть медведей. Иногда я, эм, слышу
00:54:30диких ослов там, где нахожусь. Пару дней назад я видел диких лошадей.
00:54:34Их шаги можно услышать, выглядываешь в окно папки — а там они. Там лошади.
00:54:39Эм...
00:54:41Но да, я из конца в конец пересекал страну уже немало раз,
00:54:45эм...
00:54:47и да, это было здорово. У меня есть любимая девушка, которая готова
00:54:51потакать моему безумию, и мы вместе отправляемся в приключения.
00:54:54эм, и да, это было весело. То есть, об этом можно было бы снять целый выпуск — обо всех безумных местах, где я побывал
00:55:01О да
00:55:03Звучит круто. Наверное, у тебя в подкасте уже есть такой выпуск, да?
00:55:08Знаешь, пожалуй, стоит сделать. Обычно-то я приглашаю гостя, и мы обсуждаем какую-то
00:55:15конкретную тему, но, может, записать соло-выпуск как раз об этом?
00:55:20Да, даже твои мысли и выводы насчет выгорания — думаю, это был бы очень
00:55:25полезный эпизод для многих инженеров, особенно в наши дни, потому что мне кажется,
00:55:29что нам обещали, будто ИИ
00:55:33сделает нас продуктивнее и работать придется меньше, но на деле всё выглядит с точностью до наоборот
00:55:41Иной раз просто выгораешь от объема задач, которые теперь ожидают от тебя с появлением этих инструментов
00:55:50Да, мои взгляды на этот счет многие сочли бы довольно радикальными
00:55:53И пожалуй, я просто остановлюсь на этом. Нам, будем честны, нужно больше работников
00:55:58Ведь кто мы такие? Мы — работники. И нам нужны более человечные условия труда
00:56:03Точно
00:56:06Да, согласен
00:56:08Мы всегда спрашиваем наших гостей: есть ли у тебя какие-то смелые мысли об SRE, DevOps,
00:56:14ИИ или любой другой техсфере? Да. Что ж, держи непопулярное мнение. И говорю я это с глубочайшим
00:56:22уважением — я вовсе не пытаюсь монополизировать или гейткипить практику SRE
00:56:26Но замечу вот что: если у вас есть должность SRE,
00:56:29ваш официальный титул — SRE,
00:56:32но прямо сейчас вы сидите в уголке, пишете YAML
00:56:34и получаете алерты по пейджеру,
00:56:37я хочу, чтобы вы всерьез задумались, действительно ли это работа SRE
00:56:40SRE — это практика, в рамках которой вы берете ненадежную систему
00:56:45и превращаете ее в надежную,
00:56:47радуете пользователей соблюдением SLO,
00:56:50боритесь с рутиной (toil), занимаетесь планированием емкости — короلем всех этих высокоуровневых операционных задач с применением программной инженерии
00:56:59Это очень, очень важно. Вот это и есть настоящая практика SRE
00:57:01Так что YAML — это не язык программирования. Если вы занимаетесь только им,
00:57:06я призываю вас выйти на открытую воду. Здесь здорово,
00:57:11здесь отличное сообщество, и многие с радостью всему вас научат. Но
00:57:15убедитесь, что находите роли, которые бросают вам вызов и помогают расти
00:57:18Книга «Проект „Феникс“» популяризировала слово DevOps, и с тех пор появились люди, которые называют себя DevOps-инженерами и делают что?
00:57:26Как ты сказал, пишут YAML и
00:57:29разворачивают Kubernetes и всё в таком духе. То есть суть DevOps,
00:57:33о которой говорилось в книге — это вовсе не тот, кто занимается подобным. Это скорее то, что ты объяснил: объединение двух разных...
00:57:39как подобрать слово? Не систем, а скорее дисциплин вместе?
00:57:43И я думаю, довольно часто можно услышать: «Я DevOps-инженер,
00:57:48я учу DevOps». И дело же не в этом, а в том,
00:57:51что ты объяснил. Сейчас трудно вернуть всё назад, потому что термин «DevOps-инженер» стал настолько привычным,
00:57:56что его уже не воспринимают так, как ты пояснил. Но да, отыграть назад теперь сложно, не так ли?
00:58:02Да, мы тут говорим о семантике и названиях, так что я постараюсь уточнять, что именно я имею в виду под DevOps
00:58:09Да, безусловно
00:58:10Мы ведь говорим не о наборе инструментов. Мы не говорим о какой-то конкретной команде — люди вечно спорят о титулах, инструментах или командах.
00:58:15Нет, дело не в этом. DevOps — это практика объединения
00:58:19технологий, людей, лидерства и процессов так, чтобы доставлять софт клиенту настолько быстро,
00:58:27насколько это возможно, безопасно и с максимальной пользой для бизнеса. Вот что для меня значит DevOps,
00:58:34и средства достижения этой цели
00:58:35гораздо шире. Это не просто Kubernetes — Kubernetes лишь часть пазла. Это не только CI/CD
00:58:40— это тоже часть пазла. Иногда это значит просто сесть и выслушать людей. Иногда — обсудить создание видения и стратегии. А иногда
00:58:47это отправка команды отдохнуть после того, как их в очередной раз подняли по тревоге в 3 часа ночи.
00:58:52DevOps охватывает всю эту картину целиком,
00:58:55а не только инструменты. Инструменты, конечно, выглядят привлекательно, я понимаю, их все пытаются продать,
00:59:01но это лишь одна грань всего опыта. Кстати, говоря об инструментах, есть ли у тебя любимые, которыми ты пользуешься?
00:59:08О боже, так. Дайте-ка подумать. Ладно, предложу один вариант сам.
00:59:14В последнее время
00:59:15у GitHub участились сбои,
00:59:20и мы как-то привыкли к мысли: «Хорошо бы процессы сборки и конвейеры тестирования
00:59:26размещать локально на собственных серверах». Для этого есть инструмент под названием Concourse.
00:59:32Если вы хотите хостить всё сами,
00:59:35мне нравится Concourse. Он позволяет выстраивать очень сложные
00:59:38пайплайны для тестирования, сборки, деплоя или чего угодно на YAML, где каждый небольшой фрагмент запускается в контейнере.
00:59:47При этом вы хостите его сами, и причина, почему он мне так нравится,
00:59:50заключается в том, что модель управления
00:59:53этого опенсорс-сообщества принадлежит им самим.
00:59:56Она не принадлежит какой-то компании, которая может взять и сменить лицензию, превратив проект в SaaS,
01:00:01что мы уже неоднократно видели с другими проектами. Так что если вас раздражает
01:00:06использование
01:00:09модного облачного сервиса для CI/CD, обратите внимание на Concourse, запустите его on-premise.
01:00:16Знаете, возможно, в плане философии это шаг назад на 5 или 10 лет, но это может оказаться стабильнее. Кто знает?
01:00:20Круто. Никогда о нем не слышал. Обязательно посмотрю
01:00:23Да, я тоже
01:00:26Да, штука хорошая. Есть компании, которые определенно его используют.
01:00:29И да, друзья не позволяют друзьям запускать Jenkins — всё, это в прошлом. Не делайте так, не надо
01:00:35То есть ты хочешь сказать, что Jenkins мертв?
01:00:38Разве я это сказал?
01:00:41Нет-нет, это был не сُводный вопрос с подвохом
01:00:44Но я говорю о том, что существуют и другие варианты,
01:00:47и я не думаю, что люди хотят и дальше писать скрипты на Groovy. Так что да
01:00:51Другие инструменты тоже доставляли мне немало боли
01:00:54Да, когда я ими пользовался
01:00:57Да
01:00:59Отлично
01:01:01Хочешь что-нибудь прорекламировать? Ты ведь ведешь подкаст. Есть ли что-то еще, о чем стоит сказать перед завершением?
01:01:06Конечно, с радостью. Давай
01:01:09Я консультирую в своей компании Cherto Moto — это c-e-r-t-o-m-o-d-o.io. Я специализируюсь на оценке
01:01:18состояния надежности, практик DevOps и SRE в компаниях. Если вас часто будят по ночам,
01:01:22если релизы выходят редко, а клиенты злятся,
01:01:26вам определенно стоит заглянуть в мой календарь. Также я веду подкаст Reliability Rebels,
01:01:31где беру интервью у людей и мы обсуждаем,
01:01:33что SRE — это не просто инструменты, это еще и вызов устоявшемуся порядку,
01:01:38разговоры о социотехнических аспектах. А еще 24-го
01:01:41февраля я провожу вебинар о
01:01:45так называемом
01:01:47ИИ-потоке кода —
01:01:48кажется, я назвал это «цунами кода от ИИ». Я ежемесячно провожу вебинары на самые разные интересные темы,
01:01:54так что если вам интересно, заглядывайте на мой сайт и узнаете обо всем подробнее. Большое спасибо за возможность рассказать об этом
01:01:59Не за что. Спасибо тебе
01:02:03за рассказ обо всех этих приключениях и извлеченных уроках. С тобой было очень здорово
01:02:09Так что спасибо всем, кто слушал этот выпуск подкаста Better Stack
01:02:13Подписывайтесь на наш шоу везде, где слушаете подкасты: Apple, Spotify, YouTube, выбирайте, что по душе. Ну а пока
01:02:20это прощание от меня
01:02:22И прощание от меня
01:02:25И прощание от меня
01:02:33(бодрая музыка)