Operational excellence (OpEx) reviews: the weekly meeting that actually changes behavior

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

>> Этот подкаст ведется cortex.io. Мы помогаем организациям постоянно улучшать свою операционную зрелость и снижать трения разработчиков, чтобы вся организация работала как единое целое. Ознакомьтесь со ссылкой в описании, чтобы узнать, как мы помогли нашим клиентам сократить MTTR вдвое, удвоить частоту развертывания и сэкономить тысячи инженерных часов с помощью золотых [музыка] путей и правильных ограждений. Спасибо, что слушали Brain Trust, подкаст для инженеров-лидеров от инженеров-лидеров [музыка].

>> Привет, добро пожаловать на подкаст. Я Ганеш. Я один из соучредителей и технический директор Cortex.

>> Приятно вас здесь видеть.

>> Спасибо, рад быть здесь. Меня зовут Шон Берк. Я ведущий инженер в Cortex. Я работаю в Cortex около полутора лет. До Cortex я работал в таких компаниях, как SoFi, Uber и Microsoft. И поэтому я видел несколько разных подходов к операционному совершенству.

>> Круто, рад вас здесь видеть. Для аудитории, не могли бы вы быстро описать, чем занимается ведущий инженер? Звучит очень солидно.

>> Шутка, которую я люблю говорить, заключается в том, что это единственное звание, которое является оксюмороном.

>> А можно быть выдающимся и быть инженером?

>> [смех]

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

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

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

>> Почему это важно? Почему организация будет заботиться об операционном совершенстве?

>> Да, как я уже сказал, по двум причинам. Во-первых, эти вещи часто не попадают в обычные инженерные процессы планирования. Итак, есть набор работ для предоставления качественного сервиса клиентам, который обычно не появляется в регулярной инженерии. И причина, по которой вы хотите иметь это, заключается в том, что часто вы хотите сравнивать, как сервисы и системы работают в организации. И поэтому, без обзора операционного совершенства, у вас обычно нет возможности всем сесть и рассмотреть эти вопросы, и убедиться, что у вас есть сервис, который, возможно, у вас есть компания, которая заключает контракты с другими компаниями с SLA, где вы должны контрактно соблюдать определенные требования к производительности. Убедиться, что вы это делаете, обычно является частью обзора операционного совершенства. Кроме того, часто вы хотите убедиться, что вы смотрите на такие вещи, как время сборки и частота сбоев, и в целом на метапроцесс эксплуатации вашего программного обеспечения. И поэтому причина этого в том, что если у вас нет структурированного процесса вокруг этого, это обычно просто не происходит. Эти проблемы теряются. Они часто страдают от этого, вы не видите закономерностей по всей организации, что все ваши сервисы на самом деле имеют много проблем с задержками или проблемами системы сборки или тому подобное.

>> Заботятся ли об этом нетехнические заинтересованные стороны? Является ли это правильным взглядом для них, или это больше похоже на то, что инженерная организация может самоанализироваться и определять, правильно ли они делают, чтобы доставлять программное обеспечение правильным образом?

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

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

Единственное, что вы услышите от владельцев бизнеса или нетехнических технических людей, это: "Эй, что случилось с тем инцидентом на прошлой неделе или да, мы подписали SLA. У нас есть соглашение SLA с какой-то компанией, которая использует наш сервис, и, знаете, мы обеспокоены тем, что эти SLA нарушаются.

>> Итак, вы упомянули важность обзора операционного совершенства. Что такое обзор операционного совершенства?

>> Да, так вот, обычно обзор операционного совершенства заключается в том, что вы собираете группу людей в вашей команде, и давайте поговорим о разных типах людей, которые могут там присутствовать на регулярной основе, и пройдемся по своего рода сценарию метрик здоровья для вашей организации и сервисов. И поэтому, прежде чем перейти к деталям, я думаю, важно поговорить о том, почему это действительно важно. Я думаю, самое сложное в большинстве организаций — это изменение поведения. У людей есть много противоречивых вещей, на которые они тратят время и приоритеты, и они постоянно решают, что делать. И для лидера сказать организации: "Эй, нам нужно улучшить задержку наших сервисов", может иметь значение на минуту или час, но определенно не на день. Это просто быстро исчезает, и единственное эффективное, что я видел в организациях для достижения результата, — это проверять этот результат на повторяющейся основе еженедельно. Итак, номер один — это регулярность того, что у вас есть контрольная точка на очень распространенной частоте. Номер два — это то, что люди в комнате должны иметь возможность добиваться результатов. И поэтому вы не можете провести обзор операционного совершенства со всеми вашими младшими инженерами. Вам нужно провести обзор операционного совершенства с самым старшим разумным человеком, будь то ваш технический директор или ваш вице-президент по инженерии. Очень важно, чтобы команда получила сигнал о том, что это действительно важно, и мы действительно заботимся об этом. И, имея лидера, который ведет это совещание или присутствует на нем и внимателен, это действительно помогает укрепить это в организации. Так что я думаю, это действительно ключевой момент. Другие типы вещей, которые я видел, которые пытались это сделать, просто не работают, потому что этого не хватает. Итак, когда у вас есть нужные люди в комнате, то есть лидер, а затем вам нужен представительский набор людей, которые могут детально рассуждать о системах. Например, в моей последней компании технический директор и вице-президенты присутствовали на совещании, а также директора, старшие директора и штатные инженеры. Хорошо, вы хотите, чтобы совещание не было слишком большим, и поэтому для ваших различных составляющих областей вам нужны эти люди там, чтобы они могли отвечать на вопросы, почему это красное, и мы поговорим о красном и зеленом через секунду, но вам нужны правильные люди там, чтобы иметь контекст, чтобы иметь возможность свободно говорить о том, что происходит. Вполне нормально, что на совещании присутствуют другие люди. Я думаю, опасность проведения совещания, на котором присутствует множество лидеров, заключается в том, что все хотят быть на этом совещании, потому что там присутствуют лидеры. Поэтому вам нужно немного управлять этим. У нас не было строгих правил в моей последней компании. У нас были просто рекомендации, что если есть какая-то конкретная причина для вашего присутствия, то это нормально, но в целом посещаемость была ограничена. Итак, это своего рода то, что вы делаете. Мы делали это, я думаю, еженедельно. Я думаю, еженедельно — это, вероятно, хороший темп для большинства компаний. И теперь мы можем поговорить о том, что вы на самом деле делаете на этом совещании. И поэтому нет идеального состояния для обзоров операционного совершенства, которое требует много инженерной работы, и большинство людей еще не достигли этого, и это часто движущаяся цель. Что вы хотите, так это набор автоматизированных проверок, которые генерируют отчет, будь то панель мониторинга в DataDog или какой-то документ или что-то, что проходит через области, которые вас волнуют, и выделяет их как красные или зеленые. Идеальный обзор операционного совершенства — это когда вы все садитесь и проходите по красным областям, а затем вы закончили. И способ структурировать это — две вещи. Во-первых, вам нужно, чтобы люди владели различными областями и определяли, какими должны быть эти метрики, а затем они должны работать вместе, чтобы создать любой механизм отчетности, потому что, если люди будут нести ответственность за ручное составление отчета каждую неделю, все развалится. Это должно быть автоматизировано. Так что это действительно критично. Вы хотите иметь возможность просто проходить по красным областям, и этот отчет должен быть одинаковым для как можно большего числа ваших организаций. И затем вы проходите по подразделам вашего бизнеса. Итак, подразделение А, давайте посмотрим на ваши вещи. Как, что происходит с вашим SLO по доступности? И мы, вероятно, должны определить SLO, но мы сделаем это через секунду. Что происходит с этой метрикой? Что происходит с той метрикой? Вы говорите об этом. Причина, по которой так важно делать это группой, заключается в том, что часто несколько команд имеют одинаковые проблемы. И большинство организаций очень вертикальны. Информация движется вверх и вниз. Она не движется из стороны в сторону. И это совещание — отличное время для конструктивного обсуждения, когда кто-то другой говорит: "О, знаете что? Мы тоже с этим боролись". И теперь у вас могут быть семена общей проблемы.

>> Вы упомянули красное и зеленое и наличие правильных метрик. Как вы решаете, какие метрики вы смотрите?

>> Да. Итак, давайте на самом деле сделаем шаг назад и поговорим об SLO на секунду, а затем вернемся к этому. Итак, обычно, в зависимости от области, у вас могут быть разные типы метрик, но для общего состояния сервиса у вас есть то, что называется SLO, что означает Service Level Objective. И Service Level Objective гласит, что вы хотите сохранить, ну, вы можете представить, что у сервиса есть хорошие события и плохие события. Вы определяете, что это такое. И хорошее событие может быть успешным ответом менее чем за 200 миллисекунд. Если вы получаете ошибку или это занимает более 200 миллисекунд, это не успех. И поэтому вы можете агрегировать их и сказать, что я хочу, потому что мы все слышали о девятках. Обычно вы говорите, как только я определил свой SLI, я хочу три девятки. Я хочу, чтобы 99,9% запросов были хорошими событиями. И знаете, это ваш бюджет для плохих событий. И поэтому существует много отраслевых знаний об SLO, но это то, что вам нужно понять, чтобы провести надлежащий процесс операционного совершенства. Итак, команды или люди идут и, отвечая на ваш вопрос, решают, какими должны быть метрики. И обычно они смотрят на эти сервисы и используют основные, так называемые золотые сигналы. Итак, они смотрят на задержку, доступность, то есть достаточно ли быстрая задержка? Доступность, доступен ли он вообще? И затем они добавляют третью, обычно частоту ошибок. Это и есть золотые сигналы, и обычно они пытаются построить SLO вокруг них. Но обычно есть немного больше. Обычно есть некоторый локальный контекст. И поэтому в моей последней компании, например, мы использовали Cortex Scorecards как одну из таких вещей, и мы говорили в области: "Каковы ваши SLO для вещей, которые вы определили как важные, и сколько ваших Cortex Scorecards находятся на самом высоком уровне, который мы называем уровнем два?". И затем вы можете сделать то же самое для других вещей. Так что это, по сути, то, что важно для вас в вашей организации. Часто эти обсуждения выявляют новые области для работы, но вы хотите сохранить это так, чтобы вы могли пройти весь цикл за час.

>> Это имеет смысл. Полезно ли иметь бизнес-уровневые метрики или SLO здесь, или это в основном вещи типа золотых сигналов?

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

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

>> Да, наличие кого-то, кто отвечает за совещание по операционному совершенству, и кто может подумать, успеваем ли мы все за час или сколько времени вы тратите, сосредоточены ли разговоры? Не уходят ли они слишком быстро в детали, которые не на нужном уровне. Одна из приятных вещей в присутствии технического директора заключается в том, что это устанавливает уровень того, что вы собираетесь обсуждать, потому что есть определенный набор вещей, которые их будут волновать, или вице-президентов. И поэтому, я думаю, проблема перегрузки решается путем ограничения времени. Это то, что действительно помогает. И поэтому в моей последней компании мы фактически имели скрипт Python, который генерировал отчет каждую неделю. И поэтому я в понедельник утром запускал скрипт, который генерировал большой файл markdown. Мы фактически помещали этот файл markdown в репозиторий GitHub, который был посвящен отчетам об операционном совершенстве с названием, с датой в имени файла, и тогда все знали, где его найти. И это действительно хорошо работало.

>> Кто должен проводить обзор операционного совершенства? Например, технический директор? Или они просто участник, а кто-то другой проводит?

>> Да, они не должны его проводить. В моем случае мы чередовались между мной и некоторыми другими штатными инженерами. Это работало довольно хорошо. Иногда полезно иметь несколько разных людей, которые проводят эти регулярные совещания, потому что разные люди привносят немного разный фокус на совещание. Это не должен быть технический директор. Я думаю, это было бы нормально, если бы это был он, но человек, который генерирует отчет, понимает, как он генерируется, и может отладить его, если с ним возникнет проблема, — это тот, кто, вероятно, должен проводить совещание.

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

>> Это на самом деле зависит от варианта использования. То есть, есть некоторые SLO, которые подкреплены SLA, например, которые являются жесткими и быстрыми. Если вы нарушаете их, могут быть денежные штрафы. Но во многих случаях SLO, вы хотите, чтобы ваши SLO были немного сложными. Вы хотите чувствовать, что можете их достичь. Знаете, я думаю, что в программных системах могут быть базы данных под дополнительной нагрузкой, вы можете, знаете ли, и вы принимаете решение о том, насколько плохим является красное или насколько оно красное. И это все нормально. Есть еще один аспект в SLO, называемый бюджетом ошибок, о котором мы говорили о красных и зеленых событиях. Итак, если вы говорите, что хотите иметь 99,9% зеленых, за определенный период времени это дает вам количество событий, которые могут быть красными в течение окна времени. И это называется вашим бюджетом ошибок. И поэтому вы можете видеть, как быстро вы приближаетесь к нулю. И причина, по которой это важно, заключается в том, что если вы исчерпываете бюджет ошибок, и вы становитесь красным по своим SLO, это обычно означает, что команде нужно уделять больше времени операционным вопросам. Если вы работаете действительно зелено и не тратите свой бюджет ошибок, например, давайте представим, что ваш сервис всегда на 100% зеленый, и вы генерируете много трафика. Это означает, что вы можете добавлять новые функции сколько угодно. Когда вы начнете добавлять новые функции, я гарантирую, что это число начнет падать, и тогда вы узнаете, как немного регулировать его туда и обратно.

>> Решаете ли вы в какой-то момент, что были слишком агрессивны со своей целью? Например, вы проводите 6 недель, и вы говорите: "Это просто красное все время, и такова реальность, поэтому мы должны обновить наш SLO". Происходит ли это, и если да, то как вы это решаете?

>> О, да, это происходит все время, и я могу привести пару разных вариантов того, как это происходит. Один из них заключается в том, что с SLO вы хотите установить их как можно ниже, чтобы удовлетворить вашего клиента. И требуется время, чтобы научиться этому уроку, и они учатся этому уроку, потому что, знаете ли, инженер, который чувствует, что его вещи действительно велики, скажет: "Давайте стремиться к пяти девяткам". И они быстро обнаружат, что вселенная не заботится о таком подходе, и они будут красными все время. И поэтому обычно требуется некоторое обучение и здравый смысл относительно того, что означает, когда у этой вещи возникают сбои. Сбой задержки — это не то же самое, что сбой доступности. Знаете, если это, возможно, некоторые из этих вещей, если вы установите свою цель по задержке, скажем, на 200 миллисекунд, и вы знаете, что вы получаете несколько на 250. Может быть, вам стоит немного отступить, а затем, знаете ли, подумать с точки зрения вашего клиента. Может быть, это просто не имеет значения. Итак, одна категория заключается в том, что вы просто установили планку слишком высоко, и система не может ее поддержать. Каждая дополнительная девятка требует экспоненциально больше усилий для достижения, и поэтому она очень дорога. Это одна из причин, почему вы хотите иметь наименьшую доступность, которую вы можете получить, потому что это становится дороже. Итак, одна категория — мы просто установили планку слишком высоко. Другая категория, которую мы часто видим, заключается в том, что в рамках сервиса существует подмножество запросов к этому сервису, которые медленнее других по какой-то необычной причине. У вас есть клиент, у которого гораздо больше данных, или он выполняет более сложный запрос, и поэтому иногда вам приходится работать над тем, означает ли это, что ваша система нездорова, или у вас есть проблема, которую вам нужно решить, и поэтому иногда вам нужно формулировать это так, чтобы попытаться охватить весь опыт вашего клиента и не быть слишком предвзятым одним.

>> Это имеет смысл. Меняя тему, давайте поговорим о повестке дня одного из них. Итак, что именно вы охватываете? Какова повестка дня этого совещания? Как это выглядит? Мы просто проходим отчет? Происходит ли что-то в начале или в конце? Как выглядит фактическая структура одного из этих совещаний?

>> Да, ну, знаете, это своего рода любой инструмент равен одному. Я думаю, есть пара способов сделать это. Отчет, который я упомянул, был отличным, потому что это была структура совещания, и наша цель заключалась в том, чтобы пройти через все группы каждую неделю. Иногда мы этого не делали, и тогда мы бы продолжили в следующий раз с командой, которая была следующей, и это позволило бы отчету обычно не доходить до них на этой неделе, и вы бы посмотрели, и если ничего ужасного, то это нормально. Вы бы продолжили с ними. Итак, обсуждение совещания, мы бы составили отчет таким образом, чтобы самые важные вещи были вверху каждого раздела. Итак, каждый раздел был по подразделению или, знаете ли, инженерному бизнес-подразделению или чему-то еще, и мы стремились иметь менее 10 бизнес-подразделений и менее 10 функциональных областей в рамках бизнес-подразделения. И поэтому, например, давайте просто представим, что у вас есть бизнес-подразделение под названием "Платежи". И поэтому, в вашей компании, "Платежи" могут быть бизнес-подразделением, и, знаете ли, если ваша компания занимается какой-то онлайн-торговлей, возможно, каталог или, скажем, ваши SKU — это другое подразделение. Но так, "Платежи", а затем в рамках "Платежей" у них будут подразделения, у них будет набор сервисов и функций. И поэтому мы поощряем команды делать это, мы хотели иметь менее 10 или менее функциональных областей верхнего уровня, а в их рамках мы хотели иметь, мы хотели, чтобы было семь или менее функциональных областей, потому что, знаете ли, многие из этих систем имеют несколько областей внутри себя. Возможно, у них есть платежная система, которая имеет входящие и исходящие данные для платежных поставщиков, возможно, у них есть собственный реестр. Так что у них есть отдельные компоненты внутри. И поэтому первое, что вы хотите сделать, это создать эту топологию вашей организации, которая является вашей организацией в форме функционального дерева, фактически. И затем мы бы запустили этот отчет. У нас был файл YAML, который определял все это, а затем для каждого из них было, я думаю, у нас было, прежде чем мы смогли автоматически обнаружить SLO, вы просто вставляли идентификаторы SLO, например, идентификаторы DataDog. Вы могли бы вставить сервисы, которые составляют это. И мы всегда стремились сделать это на 100% автоматизированным, но, по сути, для каждой функциональной подобласти у вас есть список вещей, на основе которых строится отчет. Это то, что заставляет отчет делать свою работу.

>> [хмыкает]

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

>> Должны ли отдельные команды также принять эту практику? Является ли это просто общеорганизационным делом, которое вы делаете на уровне вице-президента, технического директора, штатного инженера, или отдельные подкоманды должны практиковать проведение собственных обзоров операционного совершенства в своем индивидуальном масштабе?

>> Я думаю, что у команд должна быть панель мониторинга операционного совершенства, на которую они обращают внимание в рамках своей рутины "поддержания света", будь то их дежурство. Иногда за это отвечает дежурный. Иногда команды действительно имеют операционную, я имею в виду, если вы управляете очень операционно-тяжелым сервисом, если вы управляете S3, у вас, вероятно, есть это совещание. Но если вы управляете парой отдельных сервисов, я не хочу говорить "нет", Ганеш, но я думаю, что это, вероятно, немного громоздко для небольших команд. Вам нужна эта машина, чтобы действительно эффективно ее использовать. И я думаю, что по мере того, как мы получаем лучшие инструменты, которые могут делать эти вещи автоматически, да, инструменты искусственного интеллекта и другие виды каталогов сервисов, такие как Cortex, я думаю, вы окажетесь в положении, когда, возможно, у вас будут эти данные готовы, и вы сможете пройти и сделать это.

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

>> Это отличный вопрос. Я думаю, что способ справиться с этим зависит от того, кто находится в вашей организации. Если у вас есть TPM, может иметь смысл, чтобы TPM присутствовал на совещании, а затем создавал заявки для всех результатов. Это, по сути, то, что мы делали: мы создавали заявки для результатов. Что мы делали на совещании, чтобы совещание было динамичным, мы делали заметки о том, каковы были эти результаты, а затем мы шли и убеждались, что заявки были созданы. Но это действительно важная часть этого. Знаете, я думаю, возвращаясь к тому, о чем мы говорили раньше, наличие лидера на совещании — это то, что действительно укрепляет многое из этого, потому что многие люди на случайном совещании могут сказать: "Конечно, я это исправлю" и не сделать этого. Но если технический директор присутствует, у них немного больше мотивации.

>> Несет ли кто-то на совещании ответственность за то, чтобы, например, остановить разговор и спросить: "Хорошо, как мы будем с этим разбираться?" Потому что эти разговоры могут деградировать, и у вас могут быть действительно интересные технические разговоры, но это чья-то ответственность? Должен ли каждый разговор заканчиваться вопросом "Что мы будем с этим делать?" Или нормально просто вести некоторые открытые разговоры?

>> Да, всегда нормально иметь, я имею в виду, вы действительно хотите, чтобы совещание было ориентировано на действия. Как будто вы хотите, чтобы эти вещи появились зелеными на следующей неделе. И мы увидели действительно удивительный прогресс за 12 месяцев с момента начала до вещей, которые стали полностью зелеными по различным вопросам. Я, я как бы забыл упомянуть это, мы также включили сюда соответствие. Так, например, уязвимости, мы определили SLA для того, сколько времени могут быть старые критические уязвимости, знаете ли, и мы отслеживаем такие вещи. И я думаю, вы хотите видеть, я думаю, что разговор в основном сводится к тому, движутся ли команды в правильном направлении или нет. Знаете, некоторые вещи, такие как уязвимости, которые постоянно меняются. Так не растут ли они? И и Jira-заявки и тому подобное. Так что я думаю, что большая часть разговора может быть о том, что происходит с вашим процессом, из-за которого вы отстаете. Разговор может быть о том, какая инженерная работа требуется для исправления этого. Я думаю, вы действительно хотите результата, потому что цель — вернуться к зеленому на следующей неделе. Как будто вы не хотите быть красным каждую неделю.

>> Меняется ли структура или метрики или что-то подобное теперь с увеличением использования ИИ-помощников для кодирования? Поскольку люди потенциально производят больше кода или больше кода [кашляет] они не обязательно понимают, достаточно ли иметь те же SLO и золотые сигналы? Должны ли мы изменить то, о чем думаем?

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

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

>> Да, абсолютно. Я имею в виду, я думаю, некоторые компании сочтут это не операционными проблемами. Я думаю, они очень хорошо вписываются в этот процесс. Итак, любые метрики, касающиеся вашего внутреннего цикла разработчика. Мы определяем внутренний цикл как своего рода цикл кода, тестирования и отладки, через который проходят разработчики. Существует много науки о том, что, в той степени, в которой вы можете ускорить этот цикл, вы увидите лучшие результаты в вашей организации. Я думаю, абсолютно уместно следить за этим. И вещи, которые замедляют такой процесс, — это медленные конвейеры сборки, ненадежные тесты, долгое время сборки и тому подобное. Так что я думаю, что эти вещи были бы абсолютно уместны. Проблема с ними заключается в определении того, как выглядит хорошее и плохое на организационном уровне, потому что определенные области, например, время сборки, очень часто фронтенд-код на TypeScript не имеет этой проблемы, а бэкенд-код имеет проблему со временем сборки. Так что вам придется управлять этим, но я думаю, что ненадежные тесты и частота успешных сборок — это довольно стандартная вещь, которая абсолютно применима. Да.

>> Последний вопрос от меня: вы упомянули, что главный помощник — это интересно. Если бы у вас был главный помощник, что бы вы поручили главному помощнику?

>> Я хотел бы, чтобы главный помощник мог объяснить мне причину метрик, которые я вижу. Например, если бы это были ненадежные тесты, я хотел бы, чтобы он точно объяснил мне, почему тесты терпят неудачу. Это сбои оборудования? Это тайм-ауты? Это гонки условий? И попытаться указать на то, что в моем процессе можно было бы изменить, чтобы я мог легче выявлять их и работать над ними.

>> Так что кто-то займется этим для вас.

>> Да, да, да, да. Да.

>> Ну, большое спасибо, что пришли. Просто чтобы резюмировать то, о чем мы говорили: важность обзоров операционного совершенства, чтобы убедиться, что вы действительно предоставляете услуги, которые должны предоставлять, рассмотрение золотых сигналов, наличие правильных метрик и правильных пороговых значений, использование SLO для этого, наличие правильных людей в комнате, в идеале старшее руководство от технических директоров до вице-президентов, директоров и штатных инженеров, наличие четкой повестки дня. В идеале повестка дня — это отчет, это структура, и обеспечение того, чтобы люди следили за этими вещами и действовали в соответствии с ними. Есть ли что-нибудь еще, что вы хотели бы добавить?

>> Это хорошее резюме.

>> Большое спасибо, что присоединились ко мне в подкасте.

>> Спасибо, что пригласили.