0: Так, спасибо, что нашли время. Я делаю исследование про то, как в крупных компаниях запускают новые сервисы и настраивают инфраструктуру. Интервью займёт больше 40 минут. Вероятнее всего, я не

1: Продаю продукт. Мне важно понять, как это устроено у вас.

2: Вы не против, если я буду записывать основные моменты и, возможно, сделаю аудиовидеозапись для себя?

3: Скажите, вы в последние 12 месяцев сами участвовали в запуске нового сервиса продукта? Не только сопровождали уже работающий. Если, да, примерно сколько запусков было за запусков новых продуктов, да?

4: Угу. Где-то в районе 4 продуктов.

5: Новых 4 продукта. Угу. Хорошо. Новых. Это важно. Да. Расскажите, пожалуйста, пару слов о себе. Роль команды. Чем занимаетесь в ежедневной работе? Являюсь руководителем направления девопс, лидером кластера по

6: Экспертизе девопс занимаюсь поддержкой и развитием девопс процессов внутри команд.

7: Ну, в целом, наверное, как-то так.

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

9: Command в районе 90 продуктов, наверное, где-то в районе около 100 штук.

10: Плюс минус.

11: Конкретно, да, ваш контроль над этим всем, да, соответственно, ну, в кластере.

12: Кластере, так какую часть времени вы лично проводите в задачах, связанных с инфраструктурой, сиайсиди, мониторингом и эксплуатацией?

13: Не очень большую, я думаю, что где-то процентов, наверное, 25.

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

15: Лидерство и управление командой.

16: Где-то 50 на 50, да? Ну, наверное, даже техническое лидерство побольше, где-то, наверное, 70 на 30, где-то так.

17: Угу. Так, в каких доменах вы сейчас в основном работаете? Биту си, сервисы, внутренний системы, платёжный, финансовый продукт или что-то ещё?

18: Угу. Так, представим, что у вас появляется новая продуктовая идея, и вы решаете запустить под неё сервис. Можете по шагам описать, что происходит от момента. Решили делать до 1 стабильного релиза вместе с защитой пра.

19: Это идея.

20: Да, соответственно, выносим за идею на защиту, получаем некое одобрение, заводим эту идею как некий продукт, да, в виде эмвипи, под этот продукт регис.

21: Информационную систему, эту информационную систему получаем ресурсы под неё. Соответственно. Ну и на этих ресурсах уже можно делать какое-то развёртывание первичное для

22: Соответственно, где могут разработчики, которые, ну, когда идея согласовывается, да, под неё выделяется и некий бюджет, который, в том числе, расходуется и на фонд оплаты труда, соответственно,

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

24: Через необходимое количество стендов.

25: Хорошо, как оформляется идея, какие пакет документов нужен или схем. Идея, как правило, оформляется в свободной форме. Далее рисуется её некая ди, как она

26: Будет верхнеуровнево работать, да, с точки зрения приземления этой идеи на архитектуру.

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

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

29: Ну и как-то вот приобретает. Угу. Свой вид. Опять же-таки, поначалу это все-таки идея, она доносится не как реализованный уже продукт там, да, а как некий писи, да, концепт. А в даль.

30: В дальнейшем как некий эмвипи.

31: Угу. Сейчас некоторые вопросы, которые описаны для контекста, они могут повторяться. Ну, то есть то, что вы уже сказали, ответы на них могут повторяться, но я на всякий случай их задам, так как это 1 пробный

32: Про оценку трудозатрат. На каком этапе вы обычно оцениваете трудозатраты на инфраструктурную часть? Стенды пайплайны? Мониторинг, безопасность. Как это происходит? Есть формальная оценка на глаз или вообще не считается отдельно? Как правило, у нас пост оплата идёт

33: Оплата, то есть в когда нам необходимы некие ресурсы, нам открывают, соответственно, доступ к неограниченному количеству ресурсов и под наши цели.

34: Под наши нагрузки мы расходуем тот объём ресурсов, который нам нужен. После этого. Команда, которая нам предоставляет ресурсы, либо делает взаимозачёт, да, с работодателем, либо выставляет счёт на

35: Просто плату, и оно уже закладывается в следующую защиту.

36: Угу. То есть другие сценарии невероятны. Сценарий оплатить. Ресурсы заранее вероятны, если мы используем. А посчитать, посчитать, посчитать, оценить, да? Ну, в целом.

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

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

39: Редко хорошо, как у вас обычно появляется первичная схема описания архитектуры элди для нового сервиса. Кто её делает? В каком виде диаграмма документ Вики? На каком этапе есть несколько вариантов?

40: Либо используются внутренние какие-то сервисы, уже готовое приложение внутреннего продукта, да, которым можно нарисовать архитектурную схему, либо какой-то

41: Внешний сервис наподобие draw или чего-нибудь, какой-нибудь доски, да, где описывается схема. Опять же-таки изначально она идёт верхнеуровнево и, как правило, в продукте.

42: Который только только доносит свою идею. Архитектуры ещё нету. Соответственно, она рисуется, ну, техлидом продукта, либо человеком, который эту идею придумал, соответственно, и по этой схе.

43: Реализуется пруфов концепт, ну или какая-то минимальная эмвипи, ка. Вот когда же уже продукт вступает в стадию принятия эмвипи, и мы понимаем, что наша идея реально имеет шанс на существование, да, то есть пруф,

44: Доказан тогда уже подключается архитектор и hd схема там и архитектурная схема рисуется уже непосредственно для production ready среды.

45: Угу, у меня в связи с этим вопрос про стандартизацию элди есть ли какие-то шаблоны или стандарты для hd или каждый архитектор техлит делает по своему насколько это вам мешает или помогает?

46: Стандарты есть. Соответственно, если внутри компании, да, продукт идёт, то он должен иметь ли по неким стандартам. То есть есть продукт, там у нас хопс, да, в котором это все отрисовывается.

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

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

49: Угу. Так, на каком, на каких этапах в этом процессе обычно появляются инфраструктурные задачи? Стенд, преплай, мониторинг, доступы, безопасность. Кто за них отвечает?

50: На этих этапах появляются вопросы инфраструктуры достаточно рано, поскольку у нас появляются первые разработчики. Тоже достаточно рано, да? Ну это как раз стадия про концепта.

51: И разработчики вместе с техлидом отвечают за инфраструктуру, которая необходима, но, как правило, это использование какого-то уже готового сервиса типа пас, да, где раз

52: Работчикам и там, ну, команде, да, которая ещё не имеет каких-то devops инженеров, либо системных администраторов.

53: Ей хватает, не обязательно нужна экспертиза, да, чтобы поднять какие-то инструменты для своей работы. Будь там, не знаю, там кубернетис, либо система наблюдаемости, которая включает там мониторинг, да, либо база данных.

54: Система вида parse сейчас предоставляет возможность просто накликивание получать необходимые ресурсы, инструменты, в которых уже как работать, разработка знает.

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

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

57: Угу. Ну, это будет зависеть прежде всего, от объёма тех идей, которые заложены в нашем, как бы, да, тех фич, которые заложены в нашей идеи. То есть.

58: Реализация, если vp vp, да, то есть там может быть 1 идея, да, как бы 1 фича в идее, может быть набор фич, то есть это более какой

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

60: Каких-то первых результатов по mw пишке. Ну, я думаю, что где-то месяца 2, наверное уходит.

61: Угу. Так, можете вспомнить 1, 2 последних запуска, рассказать, как это было по срокам и по ощущениям.

62: Запускали продукт уже в конце прошлого года по срокам на реализацию.

63: Продукта. Ну, ушло где-то, наверное, месяца полтора, 2, максимум с момента того, как были защище, был защищён бюджет, да, и команда присту.

64: До момента того, как появился какой-то 1 результат, то есть прошёл проф концепт, да, и появился какой-то mvp ный стенд, опять же-таки объём функциональности, который в этом эмвипи ном стенде, он

65: Просто минимален, ну и просто как, чтобы доказать, что продукт годен для существования, то где-то, наверное, полтора, 2 месяца необходимо

66: Угу. Так, с вашей точки зрения, насколько сильно отличаются инфраструктурные решения между разными продуктами? Это каждый раз уникальное творчество или есть повторы? Шаблоны сейчас, как правило,

67: С точки зрения архитектуры очень многое повторяется, это

68: Прежде всего, да, стеки под направление кубернетиса, контейнеризация. Кстати, если посмотреть последний отчёт гартнера, да, то там достаточно высокий процент в России уже продуктов, которые перешли

69: На cloud native и что-то подобное, в том числе используют кубернетис кубернетис как правило повторяется, база данных как правило повторяется ну более менее современный инструментальный стек плюс минус.

70: Повторяется, то есть есть какие-то альтернативы, но, как правило это 1, 2 инструмента в каждом направлении.

71: Угу. Хорошо. Если представить, что завтра надо запустить ещё 1 сервис очень похожего типа, насколько вы сможете переиспользовать существующее решение. А насколько все придётся с точки зрения инфраструктуры?

72: Да, очень, очень, очень сильно, да, очень сильно будет переиспользована.

73: Угу. Есть ли у вас внутри компании какие-то каталоги шаблонов, типовые пайплайны, эталонные сервисы, с которых обычно копируете подходы, как? Да, есть, если говорить про сиайсиди, то есть

74: Типовые сиайсиди в целом, они даже не копируются, а идёт просто подключение этих сиайсиди к проекту. Ну и, соответственно, раскатка идёт уже по заранее написанному сиайсиди, который дорабатывает

75: Определённой командой с учётом новых требований новых стандартов, которые появляются внутри компании, что является, конечно, бесспорно, очень большим плюсом против написания своих собственных пайплайнов.

76: Так вот, как раз дополню, есть ли у вас внутри кто то что-то вроде эталонного сервиса, с которого вы обычно берете пример инфраструктуры, да, с точки зрения инфраструк пайплайнов, да, с точки зрения эталонного сервиса которого мы берём

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

78: Является депрекейтит, есть которые в общем то разрешены и приветствуются. Ну и соответственно, инфраструктуру мы строим через эти инструменты.

79: Когда вы запускаете новый сервис, насколько часто удаётся переиспользовать существующее решение как есть, а когда приходится все собирать с нуля?

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

81: Где чаще всего все тормозится или ломается?

82: Чаще всего самый такой долгий этап это непосредственно как раз-таки регистрация, переход от идеи к регистрации продукта, который будет эту идею реализовывать. То есть под продукт нужно

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

84: Проходит наиболее количество времени.

85: Ну, где-то они, даже не знаю, если говорить по времени, то, наверное, где-то недели 2, грубо говоря, по подключению, по развёртыванию инфраструктуры, подключению, как правило, это достаточно быстрый процесс сейчас, то есть

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

87: То все про все. Я думаю, что это займёт где-то день 2 максимум. То есть это не такой большой срок.

88: А бывали ли случаи, когда именно недооценка инфраструктурной части, объёма работ, сложности, операций, интеграций, архитектурных рисков, серьёзно сдвигала сроки запуска, что там, да, такие ситуации часто бы.

89: Особенно в предыдущие года, когда были проблемы с получением ресурсов в связи с ограниченным потоком поступления новых ресурсов.

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

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

92: Ну, соответственно, нету и возможности создать какую-то среду и там сделать какое-то развёртывание. Это 1 этап, 2 этап. Бывали сложные технические продукты.

93: Которые изначально казались достаточно простыми, а в реализации они ограничивались на какие-то элементы безопасности, на какие-то сетевые моменты, когда нужно были, ну опять же-таки инфраструктурные

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

95: О том, что есть ли такая возможность, да, такая возможность есть. А сроки, ну, как получится, да, то есть, и вот эти сроки, как правило, растягивались.

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

97: Можно ещё раз вопрос можно ага, ну тогда по другому задам, что чаще всего идёт не так. В инфраструктуре пайплайнов на этапе выхода в prod можете вспомнить типичные инциденты или ошибки а, ну это уже.

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

99: Сетевые проблемы могут быть в пайплайнах, могут отваливаться какие-то раннеры, раннеры могут быть заняты какими-то другими процессами, ну соответственно, из за неправильного построения пула.

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

101: Что может также приводить к каким-то проблемам в продакшн среде. То есть по отдельности они все развёртываются на среды, а когда идёт в совокупности, ну это больше, наверное, связано с нехваткой сред инфра.

102: Структурных, чтобы провести какое-то предварительное тестировочное развёртывание. Тестовое развёртывание. Да, хорошо. Угу. Вспоминается ли ситуация, когда из за неполной или неточной архитек

103: Культурные схемы ald потом вылезали неожиданные проблемы на проде, что там было упущено такие ситуации были, когда?

104: Потоки данных на hd схеме указывались неверно или вообще пропускались, и соответственно, эта hd схема согласовывалась безопасностью, а на этой схеме да, повторюсь.

105: Не были указаны потоки информации, определённые, ну, либо какие, ну, какие-то стрелочки, в общем то, отсутствовали, да, после выхода в продакшн эти стрелочки, ну, информационные потоки все-таки.

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

107: Бывают ли кейсы, когда сервис формально готов функционально, но его запуск задерживается именно из за инфраструктуры мониторинга безопасности? Как часто и что это вам стоит?

108: Все готово, но мы не можем выкатиться из инфраструктуры.

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

110: Они имеют массовый эффект и, как правило, они быстро проходят, поэтому для продукта мало мало влияния имеют.

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

112: Все будет зависеть очень персонально от продукта.

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

114: Что он ещё сырой, да, и соответственно, если у него какие-то какая то появилась вдруг недоступность, он слетает посла, то в принципе на первых этапах это будет вполне нормально.

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

116: Там мало будет объёма переработок по стоимости.

117: Если посмотреть на последние 1 2 года, какие инфраструктурные ошибки вы бы назвали классическими, повторяющимися от запуска к запуску?

118: Отсутствие точного влияния мониторинга на развёртывание, то есть у нас происходит некое развёртывание продукта, но

119: Обновление продукта и, соответственно, проблема, связанная с его развёртыванием на мониторинге, выявляется слишком поздно, как правило, уже после заведения неких инцидентов и

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

121: По мониторингу и могла бы сама себя откатить.

122: Угу. Насколько вам хватает сейчас девопс сре ресурсов? Есть ли ощущение постоянной нехватки людей, часов или, наоборот, запас по мощности есть. Есть ощущение нехватки ресурсов.

123: Девопс эса, да.

124: Угу, если бы завтра вам дали ещё 2 сильных devops на какие задачи вы бы их сразу посадили ой, это все индивидуально, от продукта зависит.

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

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

127: Люди, которые пытаются их закрывать, хотя, по большому счёту, наверное, они должны больше заниматься процессами развития, нежели какими-то текущими решениями, в том числе аварий, часто повторяющихся и так далее.

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

129: Как правило, задачи, которые связаны, наверное, с какими-то новыми технологиями, в частности сейчас, ну, мы в целом берём, скажем,

130: Так, берём задачи, но, наверное, не все задачи мы берём, да, то есть не весь пул, а только там очень небольшую часть, которая очень сейчас приоритетная.

131: Много задач, связанных с автоматизацией, с использованием искусственного интеллекта, то есть написание каких-то ai агентов, которые могли бы помогать оптимизировать нашу деятельность.

132: Ну, как-то на неё влиять, да?

133: А если вспомнить последний год, какие инфраструктурные задачи чаще всего застревают из за нехватки людей и экспертизы?

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

135: Компании, которые могут оказать какую-то консультацию.

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

137: Не вижу каких-то в этом проблем в целом.

138: Сервис как девопс это штука интересная и часть каких-то задач очень с удовольствием бы отдали на такое.

139: Угу. А есть ли у вас сейчас какие-то се сервисы, инструменты для команд, шаблоны пайплайнов, кнопка завести сервис портал, что в них нравится, а что не работает или игнорируется? Ну, с точки зрения инфраструктуры, да, поскольку мы используем past

140: Соответственно, все инструменты, которые происходят от паса, они находятся на поддержке профильных команд, да? Ну, в частности, если мы так возьмём какой-нибудь пример, то если мы за берём, да, и развёртываем

141: Кластер, который в пасе нам предоставляют как менеджер сервис, то и ответственность за этот кластер несёт команда, которая его развёртывала, не наша продуктовая команда.

142: Аналогично по другим инфраструктурным каким-то вещам, что позволяет не иметь разовые какие-то компетенции у сотрудников, а их отдать на какой-то внешний сервис. Аналогично по

143: Сервисом построения сиайсиди есть шаблон, который подключаемый, да, общекорпоративный, который поддерживает некая и развивает некая команда, которая не связана с нашей продуктовой

144: Вопрос вхождения, вопрос экспертизы, который надо для подключения этого всего. Это интересно. Да, зачастую это приходится делать не совсем.

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

146: Может просто взять на какую-то поддержку процессы. Было бы действительно интересно. Необходимость такая, да, есть.

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

148: Очередь. Вы бы там хотели видеть в 1 очередь, а каталог типовых запусков чего?

149: Продуктов, то есть вот от старта и до финала какой-то

150: Типовой запуск. Здесь подразумевается, что есть шаблон, по которому мы действуем, и вот в них какие-то типы сервисов в 1 очередь должны быть остальные опциональны. Это вот основа

151: Ну, минимально написание дорожной карты для продукта, как и в какой последовательности, да, им.

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

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

154: Казалось бы, зачем нам информационная система, если у нас нет разработчиков, но зная, что она будет заводиться достаточно долгое время, как-то регистрироваться там и так далее, то мы могли бы начать с неё, а параллельно, да, там нанимать разработчиков, да, и к моменту, когда у нас

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

156: Сделать, чтобы получить готовые какие-то первые результаты, чтобы показать их на продакшн среде. Наши, ну, наши идеи, чтоб как-то развернуть.

157: Угу. А насколько вам было бы полезно, если бы при описании нового сервиса вы сразу видели примерный набросок архитектуры, сценария запуска и ориентир по трудозатратам на инфраструктуру? Что в таком подсказчике должно быть, чтобы вы ему

158: Доверяли, ну, наверное, объём уже проведённых реализованных продуктов через эту схему. Ну, в целом схема, если типовая, а типовые

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

160: Для продукта. Плюс какие-то дополнительные там элементы, как правило, тоже всегда стандартные. Думаю, что схему, да, нарисовать типовую для продукта достаточно просто. И по этой схеме выра,

161: Вот это порядок действий тоже, да, наверное, да, это было бы востребовано.

162: Так, а если представить идеальный мир, как бы вы хотели, чтобы выглядел процесс запуска нового сервиса через 1 2 года, что делается иначе, чем сейчас?

163: Не знаю, наверное, посмотрел бы в сторону какой-то.

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

165: Угу. Какие минимальные вещи по инфраструктуре, мониторингу и безопасности должны быть обязательно сделаны для нового сервиса, чтобы вы были спокойны за его запуск?

166: Ну, в общем то, развернуть инфраструктуру и чтобы она была надёжна.

167: Угу. По каким метрикам? Вы сами понимаете, что запуск прошёл успешно. С технической точки зрения, с технической точки зрения, запуск именно уже продуктов продакшн или запуск идеи в целом? А запуска?

168: Production. Дак, ну, как правило, есть 3 плоскости метрик, которые мы хотели бы смотреть. Это метрика, ну, инфраструктурная, да, стандартная, что мы понимаем, что инфраструктура у нас

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

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

171: Перевести в мониторинг, смотреть, как они работают, какими бизнес процессами больше пользуются и так далее.

172: Так есть ли у вас сейчас какие-то цели или kpi именно по скорости запуска новых сервисов тайм ту маркет ли time инфраструктуры и как они формулируются?

173: Да, это все есть, соответственно, и это все мониторится, собирается все эти параметры есть или там есть там маркеты и так далее, как

174: Правило идёт некий процесс, оформленный в трекере, да, таск трекере, где появляется некая идея, оформленная как идея. Потом из

175: Неё, ну она проходит стадию аналитики, далее у неё там появляются некие стори, да, там задачи, да, которые надо реализовать, которые являются как раз теми фичами, которые будут дальше.

176: Реализовываться, ну и соответственно, оно вот так поэтапно идёт. Реализация, тестирование, там развёртывание. И в конце оно представляется как некое законченное, завершённое объём задач. Вот.

177: Ну, идея является завершённой, и вот этот путь, да, как раз оценивается, как долго идея реализовывается и доходит до продакшена, и, соответственно, этот тайм пытается

178: Компания сокращать, используя различные инструменты.

179: А используете ли вы какие-то девопс метрики? Частота деплоев, время восстановления, доля неудачных изменений в качестве ориентиров при запуске новых сервисов? Если да, то какие из них вам? Ну, дора метрики, да, собираются, конечно же.

180: Какие ближе всего?

181: Да, наверное, все тут надо понимать, что эти дура метрики для разных продуктов.

182: Как правило, персональное, да, то есть нам не обязательно там, чтобы продукт выкатывался каждый, каждый час, например, да, потому что этот продукт, например, там не так часто изменяется.

183: Бывают изменения, соответственно, для него, например, там метрика, это может быть там раз в неделю вполне допустимая, не обязательно там раз в час развёртывание. Вот. Но при этом надо понимать, что в таких метриках очень важен вектор.

184: Да, который вектор изменения этой метрики для конкретного продукта. Вот. Поэтому, да, штука интересная, Нужная.

185: Если представить, что подготовка технической части запуска нового сервиса у вас стала занимать в полтора, 2 раза меньше времени, как это отразилось бы на бизнесе и на вашей работе это вообще заметно или нет? Да, это заметно, потому что

186: В целом у нас ещё есть такие продукты, которые очень сильно где-то

187: Провисают на этапе как раз-таки поставки продукта доставки продукта, да, соответственно, то есть с момента того, как разработка закончила работу над кодом, до момента, когда оно появилось на

188: Production, если это уменьшится в полтора раза. Ну, это будет очень хорошо.

189: Что для вас важнее? Сокращение сроков запуска, снижение числа ошибок инцидентов или уменьшение нагрузки на команду? Как бы вы расставили приоритеты, снижение количества инцидентов, снижение нагрузки на команду, увеличение частоты.

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

191: Инструментов, внешняя платформа, набор шаблонов, Гайдов и почему

192: Ну, в целом у нас инструменты развиты очень хорошо. Скорее, наверное, даже набор шаблонов Гайдов, ну, опять же, таки, с точки зрения платформы внешней никто не мешает эти Шабло.

193: Гайды в неё упаковать.

194: Хороший ответ, окей.

195: Что должно быть обязательно в таком инструменте подходе, чтобы вы реально стали им пользоваться, а не просто посмотрели и забыли. Мы ориентируемся как раз на последний ответ. Набор шаблонов, Гайдов, набор шаблонов, Гайдов, ну, как правило набор

196: Шаблонов. Гайдов должен быть все-таки очень широкий, да, то есть мы как продукт, когда мы строим некий продукт, продукты могут быть похожи друг на друга, но при этом все-таки они

197: Отличаются и какой-то гайд, какой-то шаблон, он должен строиться, быть как бы, да, разбит на части и подстраиваться персонально под конкретный

198: Продукт, то есть собираться из каких-то Кубиков. Понятное дело, что в 2 продуктах пересечение этих Кубиков может быть очень большое, там 90, 95%. И будет казаться, что это очень, очень, ну прям похожие продукты, но все равно вот эти 5

199: Процентов Кубиков, они будут разные. И, соответственно, шаблон, написанный для 1 продукта, будет отличаться от шаблона, написанного для другого. Но эти 5% опять же-таки могут пересекаться с каким-то другим продуктом, да, и в совокупности как-то из таких

200: Шаблонов можно было бы сделать 1. В целом такая интересная задумка могла бы быть очень полезна. То есть где у нас был бы выбор того, что у нас есть, а по после

201: Того, как мы выбрали, у нас персонально подгружался шаблон, который был бы сгенерирован для нас на основе данных, имеющихся уже у других продуктов. Ну и, соответственно, как они шли по этому шаблону.

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

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

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

205: Ну хотя бы минимум, потому что им у них даже нету очень большой какой-то площадки для того, что, чтобы им делать.

206: Сейчас у меня ещё можно ещё раз вопрос повторить?

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

208: Сократить дефицит высококвалифицированных специалистов в командах, да, вот как раз про дефицит высокоэффектив.

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

210: Уктурные какие-то части в инструменты, которые есть и так далее. То есть тут даже, наверное, ну тут я думаю, что 50 на 51 это эффект, который бы, да, могли бы на квалификацию специа.

211: Листов, скинуть другое на скорость вхождения

212: Угу, бывало ли, что вы пробовали какой-то новый инструмент для devops инфраструктуры и он не взлетает почему так вышло?

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

214: То есть инструмент полностью нам подходит, но при этом его версии интерпрайс, да, и в общем то мы готовы их купить, их просто не купить, а версии не интерпрайс, не

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

216: Что для вас является стоп фактором при выборе таких инструментов? Безопасность, кривой юикс, недоверие к автоматизации, отсутствие поддержки или что-то ещё? Ну, отсутствие поддержки, безопасность это, наверное, ключевые

217: Угу. Если я позже приду с более конкретной концепцией, прототипом на 20:30 минут, было бы вам интересно посмотреть и покритиковать? Да, можно?

218: Угу. Есть ли ещё что-то в теме запусков инфраструктуры, что я не спросил, но вам кажется важным. Ой, наверняка, наверняка есть. Да, это очень, очень широкая тема для обсуждения нас.

219: На самом деле, ну, мне, наверное, надо подумать, прежде чем сказать. Я, наверное, пока не готов. Так, сходу.

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

221: Опять же, таки все, что мы говорим по поводу девопса, имеет, ну как, как, как девопс, как даже, в принципе, девопсы, да, как правило, вот мы разделяем на 2

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

223: Кубернетис и так далее. И это девопсы, которые непосредственно персонально участвуют внутри продукта и выстраивают работу продукта. То есть это инфраструктурные, да, которые занимаются инструментами, и те, которые

224: Эти инструменты используют. Вот. Соответственно, надо посмотреть на людей, которых есть потребность, то есть каких-то продуктовых менеджеров, которые

225: Развёртывают свои продукты и у них есть какая-то проблематика с этим я просто больше как по части devops, а надо посмотреть больше по части именно менеджмента.

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

227: Потому что у него продуктов много и они часто сталкиваются с какими-то типовыми кейсами.

228: Хорошо. Так, ну, сценарий завершён. Интервью. Да, спасибо. Спасибо вам за ответ.