Podlodka #397 – AIOps

Всем привет-привет, друзья. Это подкаст «Подлодка», и сегодня мы будем писать выпуск про AIOps. Честно говоря, до того, как мы списались с Матвеем, я не знал значения этого термина, мог только предполагать. Ну и, в общем, я до сих пор не уверен, что до конца...

разобрался. Сегодня выпуски, прекрасно, разберемся в этой теме. Мне разбираться в этой теме будет сегодня помогать Егор. Привет, Егор. Привет. Не знаю ничего про AI, не знаю ничего про Operations, но буду про AIOps знать. Прекрасно, прекрасно. Сразу, видишь, перепрыгнул через две ступени. Великолепно. Да, а в гости к нам пришел Матвей Кукуй, кофаундер KeepHQ Dev, в прошлом инжиниринг-директор в Grafana Labs, SEO, а миксер, инженер и программист Матвей.

Рады тебя видеть у нас на подкасте. Привет-привет. Спасибо, что позвали. Очень рад. Поговорим сегодня про EOPS. Поймем, что это такое. Надеюсь. Тоже надеюсь. Расскажи немножко про свой бэкграунд. Хочешь, можешь, более широко, хочешь, можешь, более конкретно. Твой опыт, связанный непосредственно с темой нашего сегодняшнего выпуска. Мой опыт, он прямо подводил меня к этой теме.

много-много лет, наверное, лет 10. Ты как будто на собеседовании. Да. Потому что я работал сначала программистом, потом я потихонечку-потихонечку оказывался тем самым парнем, который... знает, как работает инфраструктура, знает, как метрики настроить, графан наладить. И потихонечку я так сваливался в Operations. Последняя моя программистская инженерная должность называлась DevOps.

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

И потихонечку-потихонечку я пришел к мысли делать стартап в этой сфере. Так появился мой первый стартап, про который мы поговорим потом, наверное, про этот рынок инструментов для... alert-менеджмента и инцидент-менеджмента. И второй мой стартап, вот Keep, он тоже в смежной сфере, и IOPS — это сфера, которая очень близка к operations и к помощи людям, которые резолвят инциденты, сидят на алертах, мониторят какую-то IT-инфраструктуру.

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

Ну что, я предлагаю тогда уже двигаться непосредственно... по плану нашего сегодняшнего выпуска. И самое первое, в чем хочется разобраться, прям совсем такой TLDR, что такое AIOps. Так стоп, это же 2024 год. Если хочешь поднять инвестиции, ты к любому слову должен AI приделать, и все получится.

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

Эта часть обычно называется Instant Response Management, то, что отвечает за эскалации, поиск дежурных, доставку алертов в SMS, в звонки, может быть, кто-то знает PagerDuty. И AIOps — это... Такая новая ниша, которая расцветает между этими двумя, которая декларирует, что мы сейчас приведем сюда AI, и AI повлияет и на observability, где вы метрики логии трейса собираете. и на ваши алерты, которые вы в итоге получаете. Можем это сейчас начать раскапывать, с какой удобной стороны.

А перед тем, как начнем, хотим и рассказать про онлайн-конференцию iOS Crew. Многопоточность не просто тренд, а необходимость для каждого iOS-разработчика, который хочет создавать быстрые и надежные приложения. Уже 11 ноября на полотке iOS Crew разберем, что нового появилось. за последние годы в управлении потоками и как внедрить это в реальных проектах.

Будет много интересного. Например, Евгений Ёлчев поделится секретами, как акторы исполняют задачи и сможет ли AsyncStream заменить старые добрые синхронные очереди. Илья Харламов расскажет, как вынести ViewModel с главного потока, другими словами, магия внехода. На воркшопе с Александром Игнатьевым разберем, что делать, если нужного лока нет в минимально поддерживаемой версии iOS и как Apple решает такие проблемы. Ковнем и под капот.

Александр Сычев приоткроет завесу над тем, как треды работают внутри и почему это важно для стабильности. Антон Марченко выяснит, как взаимодействуют алгоритмы и многопоточность для улучшения производительности. Это еще далеко не все. Полностью программу можно посмотреть по ссылке в описании, ну или загуглив подлодка iOS Crew. А вот что загуглить точно не получится, так это приятную скидку на 500 рублей по промокоду IOS, нижнее подчеркивание, конкареси.

Все на английском капсом. Конференция стартует 11 ноября. Сессии идут всю неделю утром и вечером. Переходите по ссылке. Программа почти полностью готова. Ну а теперь к выпуску.

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

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

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

как-то мерились более интеллектуально, чем просто, не знаю, треш-шолды по проценту или по каким-то абсолютным числам. Но, в общем, разберемся. Интересно. Я тогда предлагаю как раз начать, ну, дать какой-то небольшой обзор. как раз вот двух соседних коробочек, что получает, с одной стороны, потенциально на вход вот эта наша коробочка с AI, и, соответственно, блин, я забыл слово, ARM. ARM называется, Incident Response Management. Да, да, да. Вот, и, соответственно, про вторую.

Предлагаю с observability, может быть, начать. Observability — это мне вообще очень близкая тема, потому что я только еще недавно работал в Grafana. Grafana — это open-source observability платформа. И observability platform на самом деле очень много, это такой...

Классный большой рынок с точки зрения бизнеса и много опенсорсных. Вы, наверное, знаете, я обращаюсь к слушателям, DataDog, New Relic. Вообще, в принципе, все, что мы называем мониторингами, это так или иначе observability. Это то, что собирает... и визуализировать логи, трейсы и метрики. Еще много всяких побочных артефактов, но это такие три столпа observability.

И observability — это то, что пришло, можно сказать, на нашу полянку первым. Потому что, если вы вспомните, кто занимается этим чуть подольше, 10 лет назад или 15 лет назад все сорвались. как безумные заниматься observability, собирать логи на масштабе, особенно какие-нибудь большие масштабные системы. Это была прям большая такая задачка, когда все переходили от...

сбора логов в файлик на сервер, и там tail-f, чтобы их читать, когда постепенно приходило понимание, что нужно все это собирать централизованно, анализировать, атрибутировать. И за последним...

Несколько лет я могу сказать, что проблема observability, наверное, решена. Появилось столько, много прикольных, классных вендоров, инструментов, стандартизации. Появился такой стандарт, как OTEL, OpenTelemetry, который позволил... пользователям, на самом деле, перескативать с одной обзоробити-платформы на другую, когда ты можешь пользоваться чем-то опутсорсным, потом так отстегнуть это от своей инфраструктуры, пристегнуть что-нибудь другое, другой обзоробити-платформы и продолжить пользоваться.

а я уже касается observability platform и здесь Как раз отвечая на твой, Стас, вопрос первый, ты упомянул, чтобы вот трэш-холды не выставлять вручную, да, то есть обращался к своему предыдущему опыту и говорил, что вы там... расставлять какие-то треш-холды. И observability-платформа — это туда, куда первым пришел AI. Это, по сути, выставление вот этих треш-холдов. Анализ рядов, анализ метрик.

анализ логов, анализ трейсов. Это то, чем сейчас заняты большие разработчики игроки, такие как Grafano DataDog точно. Про остальные я не настолько сильно осведомлен. Но эти продукты появились, наверное, в последний год-полтора. Elastic еще этим очень сильно занимается. И в основном это то, что отличает платные, большие, дорогие интерпрайзные версии от...

бесплатных, доступных широкой публике. То есть сейчас еще AI в Observability, он как бы не стал таким mass-adopted. Еще нельзя сделать GitPool, сказать AI, иди. Присылай мне алерт, когда что-то не так. И учитывай, пожалуйста. праздники Black Friday, и он начнет. Пока это такая немножко фича для элиты, которая платит очень много, но в будущем, конечно, то, что произойдет на рынке, это когда по идее, как бы в идеале мы будем просто загружать метрики в какую-то коробку.

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

на данных конкретной компании надо обучиться и релевантно алертить. Я думаю, что это связано с общим движением. Большим компаниям нужно монетизироваться, и им нужно что-то предлагать своему топ-тир. кастомеру, какому-то там 1% самых классно платящих клиентов. Модели, которые анализируют метрики, есть open source, есть очень крутые модели, которые анализируют метрики. Я знаю, что их...

То ли Facebook, то ли LinkedIn их выкладывал в паблик. То есть можно прям скачать модели, которые будут предсказывать поведение графиков. Причем они очень круто работают. На наших графиках, которые мы любим, которые с резкими спайками, которые с учетом дня вечера и ночи, дня недели, выходных, они очень круто на них работают. Но пока просто такое движение рынка, что они предложили сначала самым дорогим кастомерам.

потом потихонечку будут двигать вниз по стеку. И когда я говорю «доступны всем», я имею в виду, что, конечно, когда это станет частью open-source какого-то solution, который будет плагиниться условно-бесплатно. и будет хорошо инструментализирован, чтобы можно было это раскатить себе и не болеть. Сейчас уже что-то можно опенсорсное раскатить, но это скорее такие поделки, и есть несколько докладов, но пока я еще не видел такого решения, что прям вот...

включил и поехал. Про observability. Хотим что-то еще добавить или будем двигаться к incident management уже? Ну вот представим, что вы настроили свои метрики, собрали метрики со своего софта, со своих сервисов. собрали логи, собрали трейсы. И теперь у вас возникает следующая проблема, что вы смотрите на эти свои прекрасные графики, смотрите на эти свои прекрасные дашборды, вы такие довольны, показали начальство, они все рады, потому что выглядят красиво, ничего не понятно.

но очень интересно. И вам нужно настроить какие-то алерты. Здесь начинается большая головная боль, особенно когда алертов у вас больше трех. И людей, которые работают с этими алертами, их больше одного.

Потому что если ты один, ты сам знаешь, что ты там настроил и как с этим всем работать. А если вас несколько и алерты вы, допустим, отправляете себе в Slack или на почту или куда-то еще, Вам нужно как-то разрулить, а кто когда будет на эти алерты отвечать, а какие алерты критичные, а какие некритичные, а какие замьюченные, а какие являются вообще инцидентами и много алертов являются собой.

сущность как один большой инцидент и нужно какой-то надзор над этим всем имеет и может быть инцидент даже передавать через смены, если вы не можете какой-то инцидент решить несколько дней, здесь в игру вступают incident response management платформы. Это PagerDuty, Ops Genie, Grafano OnCall, который я сделал. Вместе с Grafano Incident они как два продукта работают в связке. Еще появилось очень много игроков. Мы триггернули рынок, который...

Работали над графаном Колом и графанной инцидентом. И прям столкнули такой камень, потому что раньше это был неинтересный такой бизнес, а когда... В общем, мы показали, что бизнес — это хороший, и можно подчерктировать конкурентов. Такие компании, как Rootly, Firehydrant, Instantio, они тоже выкатили свои онкоу-решения. И, в принципе, сейчас есть еще что выбрать. Графаном колумбенсорсный. Цены везде упали. Можно за хорошие...

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

Петя позвонил, Петя не взял трубку, звоним Васе, потом звоним их менеджеру, менеджер злится. Петя и Вася поэтому реагируют на инциденты, потому что они хотят, чтобы менеджер дозвонился. всякие аналитика, метрики и так далее. Это то, что касается IRM, это можно сказать, что за последние там пять лет, вот, и немножко моими усилиями мы эту проблему закрыли, и на рынке появилась куча-куча прикольных инструментов. Тоже, кто их не практикует, советую.

набежать, везде зарегаться и все попробовать. Кстати, я хочу напомнить, что у нас есть уже два выпуска похожих по теме. Один про observability, а другой про мониторинг, который мы записывали еще короче, до там ряда революций, которые в сфере произошли. Один — это, собственно, 306-й выпуск про Observability как раз-таки, второй — про мониторинг 152-й. Поэтому, короче, если захотите еще поглубже закопаться и узнать, а как было...

Раньше обязательно послушайте. 152-ое, это прям уже историческая запись такая, как это было тогда. О боже, да. Но не до конца понятно, зачем, если теперь все это может сделать AI просто, и все. Так, мне кажется, то, что пора как раз начать закапываться и разбираться, что непосредственно AI делает, какие задачи решает, и насколько это все круто, потому что верхний уровень, когда слушают...

Продолжение следует... как-то обучается, периодически ты ему говоришь, насколько по шкале от 1 до 10 ты, в общем, доволен тем, как он решал конкретный инцидент, он немножко подстраивается, да обучается, и все шикарно, все прекрасно, на выходе какой-то черный ящик, никто не понимает. как она работает, но работает великолепно.

Я предложил бы вначале, перед тем, как обсудить конкретное решение, поговорить, о какие сейчас уже есть готовые решения на этом же самом месте. Потому что мы как будто поговорили про две стороны, а вот посередине какие коробки заменяют... Вот это вот коробочное AI-решение интересно. Есть две платформы, которые все знают, кто касался AIOps за последние, наверное, 5-6 лет, когда эта тема появилась.

Может быть, она была и раньше, но, по крайней мере, в массовом сознании ее не было. Это BigPanda и MoogSoft. Это как раз две платформы, которые пытаются спозиционировать себя вот между Observability и ARM. Они стараются не трогать функционал ARM, не позволять тебе составлять там расписание дежурства, как именно кому звонить. И они не особо трогают функционал observability, потому что...

В принципе, есть чуваки, которые гораздо лучше их в этом разбираются, собирают данные на объеме и так далее. Это очень сложные таски. Кстати, кому интересно тронуть... Вот в чем сложность собрать там метрики, у графана есть несколько блокпостов жесткотехнических, потому как устроен внутренний мир. Очень советую их найти, о том, как хайлодно это все тестировалось, это сбор метрик. И эти две платформы, BigPanda и MoogSoft, они появились лет 6, наверное, назад.

они заняли очень интересную нишу. Потому что 5-6 лет назад рынок observability, рынок источников алертов, он выглядел так, что в корпорации была одна система или было две системы мониторинга. корпораций, компаний, где было несколько систем мониторинга и где они бы создавали такой масс из алертов, в которых сложно разобраться,

Их было очень мало, это были прям супер-топ корпорации, очень большие, где сотни тысяч людей и так далее. И Big Panda и Moogsoft, они пошли к этим ребятам и говорят, у вас... три десятка observability платформ, какие-то старые, какие-то новые. Давайте мы все это объединим, все эти алерты в такой один хаб, который будет с помощью AI что-нибудь вам делать. И большие ребята сказали им yes.

Бизнес пошел. И потом, когда они начали применять реальный AI к этой проблеме, они немножко спотыкнулись, как я понимаю, о том, что они начали чуть-чуть пораньше. Они начали до... революция, которая случилась два года назад, когда AI стал настолько доступен для всех. То есть я знаю, что в обеих компаниях есть какой-то большой Data Science Research, и они делают свои модели, но, в принципе, эти две платформы, они сфокусировались на том, чтобы помочь тебе разманджевить эти...

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

А теперь мы притащим себе в продукты AIOps. И сделали это как фичи к своим платформам. То есть если вы... пользователей Ластика, интерпрайзник пользователей Ластика, там есть галочка включить EOPS. То же самое есть у DataDog, то же самое, наверное, когда-то будет у Grafana, и, может быть, уже есть у New Relic. И они...

Ну, добавили просто AI-ный функционал к своим платформам. Это вторая категория AIOps, и она интересна тем, что это AIOps только в рамках одной платформы. То есть если у тебя есть... три десятка опенсорсных графана, одноплатная графана и датадог, ты в платном датадоге можешь включить IOPS. Но остальные алерты и ивенты он тебя покрывать не будет. Что случилось потом?

Несколько лет назад, мне кажется, около года назад, может быть, чуть-чуть дольше, вышло несколько отчетов о том, как будет вообще трансформироваться рынок observability и какую AI будет играть здесь роль. И, в принципе, всем уже понятно, что я сделал что-то большое, но как именно это сформулировать, было неясно. И Гартнер выпустил большой отчет о том, что, ребята, вообще-то ваш рынок observability — это несколько десятков миллиардов в год.

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

observability, мониторилками и IRM, она будет нечто большое в будущем. И, собственно, в этот момент мы с командой и ринулись делать наш стартап. Всем советую так же поступать. Круто, круто. Предлагаю начать закапываться немножко в кишочке. И первый вопрос, который есть, это по поводу того, как происходит обработка вот этих данных. Когда я впервые прочитал про IOPS, у меня мысль возникла на тему того, что круто было бы, если бы как раз не нужно было...

много думать, и можно было бы просто в этот черный ящик лить данные примерно в таком же виде, как мы льем какой-нибудь там чат GPT. То есть мы не особо запариваемся на тему того, что как-то нормализовывать. Есть много задач, в которых можно достаточно плохо структурированные, сырые данные вставлять и получать достаточно хороший, приемлемый результат. Интересно, как с этим обстоят дела в контексте AIOps.

можно там условно подключить, все ненормализованное, и яичек разберется. Здесь наши фантазии о AI сталкиваются с реальным миром. К сожалению, пока вот в такой черной коробке модельки, которые можно было бы запустить в All-Lamme и кинуть туда, я не знаю, 3 терабайта алертов, чтобы получить обратно хорошие постсенсы интервью, таких еще моделей нет.

потому что это очень большой объем данных, здесь появляются требования, потому что это все должно работать предсказуемо, повторяемо и так далее. И, конечно, ты... прямо в точку, что нормализация — это большая-большая проблема. В нашем случае мы подошли к этому так, что у нас платформа, которая отвечает за сбор всего, это open-source. И...

Вот этот хаб алертов, где можно алерты раутить, фильтровать, по ним энричить, делать даже какие-то workflow, мини-скрипты, запускать их — это все опенсорсное. И нам повезло в этом плане, что комьюнити... Мы когда выложили эту платформу, мы сначала рекламировали ее как такой GitHub Actions над вашими алертами. Эта идея залетела. Какое-то время этот пост пролетел в топе. К нам набежала комьюнити, и люди начали билдить интеграции.

А создание интеграции — это самый занудный процесс во всей работе. Это очень сложно. И если в графанном коле мы сами делали интеграции целиком полностью, и поэтому у нас там... Наверное, их не так много. Не знаю, как сейчас. Команда, может быть, налегла. Но... Здесь комьюнити, во-первых, насела на нас, чтобы мы сделали нормальную доку, как билдить интеграции, а во-вторых, нарезала 80 с лишним интеграций, причем таких глубоких.

И они с пониманием источников, из которых они забирают алерты и ивенты, они сделали интеграцию и нормализовали наши... как бы составной частью интеграции является момент, когда alert так формится и превращается в наш data object, и...

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

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

То есть вот с чем у вас там интеграция? Со Slack'ом? Со Slack'ом, Telegram'ом? Там же тоже нужно какой-то набор опишек. Чем угодно. Здесь, опять же, суперлак, что комьюнити набежало и наделало интеграции. Вообще сейчас я, наверное, начну ныть, потому что продажи большим корпорациям, ты никогда не можешь продать им коробку. Поставьте себе, включите и пользуйтесь. Ты всегда продаешь такой софт, и он как паучок должен соединиться со всем софтом, который у них есть.

внутри, причем половина софта у них настолько устарела, что ты даже не знал, что такие версии существуют. Половину софта они написали сами, сделал подрядчик, который уже много лет с ним не работает на Каболе. Еще как... какие-то новые тулы, они сами внутри у себя тестируют. А еще они, допустим, хипа-каплайент. Это значит, что они работают с медицинскими данными американцев, и им надо отчитываться в одну конкретную платформу обо всех...

изменениях, которые они там делают у себя. И ты к ним приходишь, и они говорят, вы же со всем этим интегрируетесь, да? И ты, конечно, говоришь да. И это мы решили с помощью движка Workflow. Workflow — это что-то вроде визуального такого скриптера. Есть несколько опенсорсных солюшенов. У нас это часть платформы, мы сами запилили. По сути, ты когда хочешь, допустим, что-то скачать из планка,

потом сходить в Jira, взять номер тикета и потом обратно положить Splunk. Если в Jira есть определенный лейбл, ты составляешь себе такой в UI скриптик и закачиваешь его нам в платформу. И там это начинает в бэкграунте работать. Мы так решили вот эту проблему этих невероятно сложных, тяжелых, болезненных интеграций. То есть что-то в духе того, что делает Альфред или вот Apple скрипты тоже вот. Да-да-да, такая авто.

User-friendly, насколько мы можем. Чем-то похоже на GitHub Actions. Это такой YAML можно написать, где мой любимый use case — это сходить в базу, проверить за affection для клиента, который платит деньги. Это вот юзкейс, который все обожают. Если не заaffection платящий клиент, не присылайте нам этот аллерг. Это прям вот все хотят. И это, наверное, самый популярный у нас workflow, который крутится.

Нормально, нормально. Но второй по популярности не зафикчен ли личный аккаунт SEO в сервисе? Да-да-да. Тогда сразу звонить архитектору. Кажется, про модельку поговорить. Тут я как-то... Так разогнался и начал утверждать про то, что вот одна модель, но на самом деле, если так задуматься, как будто бы то, что нужно сделать внутри этой коробки, можно...

разделить на две части. Первая из них, то есть нужно как-то взять, получить вот эти все данные, их интерпретировать. Второе, это то, что на выходе этой интерпретации нужно правильно подергать вот эти вот flow соответствующие. Расскажи, как это вообще устроено, одна, две, три, сколько моделей, как они между собой дружат, как это, в общем, работает внутри. Здесь вообще интересно. Мы подошли к этой задачке как визионеры. Мы понимаем, что должно происходить.

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

Эта штука каким-то магическим образом должна еще запускать вот эти workflow, которые мы уже переходим к author-mediation. Такая тема, когда что-то само себя чинит. Может быть, скейлится, может быть... деградирует его сервис как-то кусочками. Ну, так или иначе, запускать какие-то workflow. И если эту задачку разложить на...

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

Самый идеальный клиент — это человек, у которого просто из Прометеуса летят алерты. Хорошо все размечено. Самый сложный — это у нас есть одна компания, которая занимается, как называется, когда девайсы... Интернет вещей. И они шлют алерты с Edge девайсов. У них по городу висят миллионы гаджетов.

Там сим-карты, гаджет говорит, мне плохо, мне горячо, у меня сим-карта выпала. Не знаю, как он отправит алерт в этом случае, но тем не менее. И... Вот это прям большая проблема, потому что там супер все ненормально, они катят новые версии, алерты они отправляют JSON, иногда plaintext, там большая проблема, у них вот мы занимаемся нормализацией. Дальше возникает проблема, что нам из потока нормализованных алертов надо сгенерировать инцидент. Здесь у нас есть...

Такой барабан моделей. Есть статистические, чисто статистические модели, никакого дженеративного AI, ничего fancy, просто co-accurance по временным рядам. Это работает для клиентов, у которых... Супер большой объем и очень длинная история. Если у них 15 лет истории, там...

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

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

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

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

эту задачу интерпретации данных и алертинга. Здесь, конечно, есть ограничение скейла, очень большое, потому что компании, у которых сотни тысяч алертов в день... У них просто засовывать в ЛМ-ке их алерты — это такой... на несколько бюджетов этих самых компаний. Конечно, самый простой критерий — это валидация. То есть мы все модельки, когда мы крутим этот банк, когда что-то мы выбираем, мы проверяем, насколько хорошо он работает.

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

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

здесь еще работе-работе. Правильно ли я понимаю то, что через какое-то время потенциально на барабане может выпадать сектор AI-модель вместо статистической? для больших компаний. I hope. Реально надеюсь на это. Здесь есть такое мото, это не учить базовые модели. Вообще генеративные модельки, LLM, устроены так. Расскажу, что есть какая-то базовая модель.

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

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

Иногда в air-gapped environment, это значит, что на серверах, где нет доступа к интернету, то есть у нас нет возможности использовать OpenAI, куда я бы с огромной радостью все это запихал и посмотрел просто, сколько денег это съест. нам нужно работать с моделями, которые в вопенсорсе, которые мы доучиваем и которые пытаемся дотюнить сами. Хочется вот как раз про деньги. Если начали говорить, мне кажется, надо...

Продолжить. Ты говорил о том, что вы в первую очередь разрабатываете open-source продукт. Насколько сама по себе модель open-source? Или, не знаю, в чате GPT, например... Там предлагают условно бесплатную версию, более старую, за денежку тебе предлагают там более умную, развесистую и так далее. Ну, то есть, условно, тиры какие-то появляются и так далее. Ну, то есть, условное качество модели, оно непосредственно завязано на модель монетизации.

Вот, например, в вашем случае, как это устроено? В нашем случае я огромный фанат опенсорса и бизнеса, который... работает на опенсорсе, и сейчас я буду это питчить. Прервите меня, когда будет слишком много. Или на монтаже отрежьте. Я прерву сразу, и моя сегодня роль — это напоминать про другие выпуски. У нас есть классный выпуск под названием, по-моему, «Бизнес на опенсорсе». Как раз таки.

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

Graphon on Call была такой, и Keep сейчас. Это компания, которая строит Open Core, верхний уровень ее приложения. То есть, когда мы делаем... уже такой прям апку, в которую можно тыкать, которая узкоспециализирована и которая будет, конечно, плагиниться и там вряд ли будет выступать основой для будущего СААСа чьего-то.

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

И отсюда я приведу к open source, и почему это круто. Когда ты продаешь компании обычно, ты проходишь как вендор через много-много кругов ада, потому что... Им нужно тебя выбрать и сделать этот выбор осознанно. Поэтому они хотят знать все про то, насколько у тебя секьюрно. насколько у тебя сотрудники соблюдают ритуалы всякие, как SOC2 и так далее, они выходят из офиса со служебными жесткими дисками.

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

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

И обычно все эти круги ада с security-чеками и так далее ты должен пройти перед тем, как ты выходишь на POC с клиентом. Раньше это как выглядело? Вендеры отдавали диск и Kgen. Там админ шоу ставил себе на сервак, и начиналось POC, которое длилось там 6 месяцев, у него были критерии приемки, и потом собирался какой-нибудь комитет и выделялся или не выделялся бюджет. А open source — это такая... удивительная механика, что он эту штуку хакает. Потому что в тот момент, когда ты подходишь к...

Security compliance к procurement и прочим страшным словам проверки тебя как вендора у покупателя обычно внутри корпорации уже все давно пользуются твоим опенсорсным софтом. Фанаты рады.

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

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

Как рендер, тебе вешают тикет, ты должен пофиксить. Там за 24 часа в течение рабочего дня. Это совершенно другая механика. То есть с точки зрения бизнеса, open source, open core, это такой вообще переворот механики.

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

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

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

схема, в которой, по сути, продажа идет снизу вверх, это, на самом деле, круто. Ну, то есть, и таких продуктов, я не знаю, вот мне на скидку приходит Slack в голову, потому что вот Slack, у него, на самом деле, во многом похожая такая история, то, что это...

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

Ну, собственно, люди, которые... Собственно, почему у JetBrains покупают и DE-шки? В основном не потому, что у нас есть там толпа сейлзов, которые ходят по компаниям и говорят купи-купи-купи. Это работает наоборот. все работало через bottom-up продажи. То есть есть разработчики, которым нравятся продукты, они пробуют, там, работают с комьюнити-версией или платят там из своего кошелька или триалки, а потом идут к менеджеру и говорят, купи, очень классно, нам нравится. А интересно, что...

когда разговор прошел про Slack, у Slack же есть open-source аналог, который хакает механику продаж Slack, которая в чем-то сложная, потому что... Блин, только не говори, что это Zulip. Это MotorMost. А. Он не нагрешил? Yes. Я пользовался очень ранней версией мотормозда, почему-то его фанат, хотя много лет его не видел, со слаком.

Интересно, да, ты классно упомянул, что Slack можно пойти и поставить с этой линейный сотрудник, но что мы видим, это когда-то линейный сотрудник и притащил какой-то SaaS, а потом потащил его наверх, сказал, а давайте у нас весь отдел будет пользоваться. Ваш менеджер очень часто говорит, о-о-о, а у нас есть compliance, мы не можем просто так куда-то какие-то сервера, какие-то данные грузить. И таких компаний очень много. И в этот момент они идут и ставят матермост.

И мотормост, как опытсорчный аналог Slack, он может продолжать дальше по корпорации вот это движение наверх. И когда уже вся корпорация пользуется мотормостом, там какие-то наверняка есть фичи, которые... только большой корпорации нужны. Не знаю, какое-нибудь чтение удаленных сообщений, за которые Матермост наверняка берет деньги. Не знаю, за что точно. Можно проверить. Но обычно так работает open-core модель, что какие-то вот фичи, которые нужны прям именно...

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

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

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

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

В нашем случае немножко легко, но вообще расскажу такую концепцию, что вообще как строится open-source компания, как она начинается. Есть там древние open-source компании, как Linux, ну там Red Hat, open-source-driven компании, которые не берем. Возьмем вот ренессанс новых open-source компаний, которые возникли как грибы за последние несколько лет. Это там Metabase, PostHawk, Grafana.

Кого еще можно вспомнить? Тот же самый Mattermost, GitLab. Это все компании, которые так или иначе работают по OpenCore модели.

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

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

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

Очень классно скругляет кнопки на ретинодисплеях. И эта библиотека, вот mpm install, ее ставят просто все.

Но человек, который отвечает за UX-компании, он никогда не поставит эту библиотеку сам. Это будет делать какой-то фронтендер, другой разработчик. В общем, это далекий от него человек. В нашем случае, когда мы выбирали вот эту OpenCore модель, Мы поняли, что Head of Operations или Director of Observability, который это ставит, который тестит эти продукты и сам их гоняет, он очень часто владеет этим бюджетом.

И это такой первый кристалл соединился. Теперь, скорее всего, это заработает. То есть нам теперь не важно, насколько у нас много звездочек, нам важно... сколько у нас сейчас установок в лайве. Возвращаясь к вопросу, как отрезать фичи для интерпрайза. Есть даже специальный сайт, который, по-моему, SSO Wall of... Shame — это такой сайт, где шеймят все компании, которые берут деньги за single sign-on. То есть это если ты делаешь какой-то open-core бизнес и...

Интеграцию с OAuth ты выносишь в платную фичу. Там есть группа людей, которые считают, что это неэтично. Есть комьюнити, которая ругает всех, кто... выносят в платные фичи то, что касается security. Есть компании, которые вот, если вам нужно какой-то advanced security, тогда это стоит денег. В нашем случае мы поступили очень просто. Мы вынесли...

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

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

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

потом собирать огромный датасет, чтобы тренить базовую модель и получить результаты хуже, чем базовая модель от Facebook, которая open-source, на которую дотренен небольшой слой на твоих данных. Это такая аксиома текущего... Текущая стартап-аксиома. И вообще, добрый, наверное, совет всем, кто нас слушает. В нашем случае мы вот работаем в этих достаточно... коварных ограничениях, что с одной стороны у нас, конечно, есть доступ ко всяким разным прикольным моделям. Мы...

Каждый раз, когда что-то выходит в open source, мы тут же это скачиваем, идем читать лицензию, тестируем, пробуем, играемся, как это обучается, какой там тулинг есть и так далее. Но, с другой стороны, мы хотим, чтобы наше решение, оно работало... в отрезанных от интернета окружениях и еще в окружениях, где кастомер говорит, вы нам дайте свой софт вот практически на диске, а мы вам обратно данные никакие для тренинга не дадим.

То есть мы сейчас просто проверим, насколько хорошо он работает. Если там аккуратность, точность вашей модели 95% и более, то то хорошо, а если нет, то нет. И мы со своим подходом с ААСК, где мы привыкли, когда все данные у нас лежат, и мы там можем, если что, на векенде перетренить и так далее. Нам, конечно, от этого очень грустно. Поэтому в нашем случае мы затаскиваем инфраструктуру обучения внутрь софта. То есть мы берем какую-то базовую модель, и прямо частью кипа являются модули, которые...

На эти базовые модели дотренивают по данным новые лоры и проверяют, насколько они хорошо работают. Такой немножко коварный... Коварная сложность B2B open-core бизнеса. Так, я немножко потерялся. Получается, базовая модель в итоге ваша или нет? Нет.

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

То есть что делает Keep? Он коннектится у тебя внутри корпорации к всему, что только можно. Хоть к GitHub, хоть к Slack, хоть к Graphane, хоть к PageRDuty, где у вас инциденты лежат, хоть к Jira, где инциденты очень часто лежат, или к ServiceNow, где, к сожалению, очень часто инциденты лежат. И он-то все вкачивает в себя. И, допустим, если инциденты атрибутированы с алертами, по сути, это датасет. То есть мы на этом датасете можем обучиться.

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

А у нас никакие данные не размечены, вообще никогда не были. У нас очень много алертов, много инцидентов, но инциденты у нас лежат в вордовских документиках, и какие алерты к ним относятся, это, ну, кто знает. Вот Петр Иванович знает. Как бы у Петра Ивановича пока нет API, мы это все смержить не можем. И в этом случае софт работает таким образом, что мы отдаем модель, которая натренена на ну, типа, среднем.

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

Получается, что до тех пор, пока вы не просунете под дверь вот этот вот диск, в каких-то случаях вы толком не сможете понять. Причем успешность прихождения теста, если в обратную сторону вам под дверью подсунули там, не знаю. Денег. Это сложность. Прямо мне было бы интересно послушать, как другие компании это решают, которые работают в таких же ограничениях. В нашем случае расскажу, что это работает так, что обычно у них уже какое-то время работает open source.

open-source-ный кип, он, по сути, внутри себя потихонечку создает вот этот датасет. То есть у нас такое случается false start, что мы там... Начинаем разговор о платной версии, и на этот момент обычно у них уже 3 месяца или 4 месяца крутится open-sourcing кип, где внутри собрался хороший датсет. И в этот момент мы...

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

созваниваются по Zoom, дебажат, без доступа к данным, это все больно, сложно, тяжело. Но это, можно сказать, стартап на раннем этапе. В конечном итоге мы, как все фаундеры кодят, мы сами написали этот софт, не какие-то аутсорсеры. Мы обычно можем прям руками туда залезть и понять, где у них там данные криво нормализовались или что-нибудь такое. Круто, круто. Предлагаю теперь поговорить непосредственно про пользовательский сценарий, потому что технически мы, кажется...

Все посмотрели, разобрали. И на самом деле про пользовательский сценарий. Мы уже как минимум один из них затронули. Это история про AI threshold. Матвей, что еще? Какие еще там? пользователями задачи можно решать при помощи этой замечательной коробки. Основная задачка — это там, окей, прилетели алерты, мы их сгруппировали, у нас появился инцидент, а теперь...

Что с этим инцидентом? Что это такое? Потому что, по сути, это такой мешок с алертами. А алерты, кто видел, это просто джейсоны, такие страшные, неприятные, вообще ничего не понятно. Если еще есть Прометеоса, то там прям вообще трэш. Теперь нам нужно как-то эти алерты, этот инцидент озвучить. Здесь мы идем уже в генеративную модельку, если в клауде мы иногда пользуемся third-party провайдерами, где Generative AI пишет нам красивый текст о том, что происходит, скорее всего.

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

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

В этот момент начинают там собираться какие-то Zoom-звонки, и вот этот архитектор, которого все бесит, что постоянно к нему ходят по всем инцидентам. У платформы, у нее есть весь контекст. У нее есть изменения из GitHub, все коммиты, все диплои. И этот контекст нужно подсовывать в каком-то диалоге этому человеку, который пытается пофиксить инцидент.

И мы очень хотим туда пойти. Это вот когда AI будет с тобой в диалоге, может быть, даже ходить в Kubernetes, там, кверить какие-то запросы, получать еще какой-то дополнительный контекст. Сейчас это так достаточно базово сделано у нас. но помогать тебе решать этот инцидент. И то, что уже есть, это тоже такая отдельная большая тема. Это от Remediation, это когда платформа сама фиксит. Это коварная штука.

Потому что от Remediation ты не хочешь дать ему SSH-ключики от продакшена и сказать «фикс», потому что он там, как самый джуниор из джунов, пойдет и нафиксит. Тем более, если это генеративная моделька. Там РМРФ у нее могут как-нибудь всплыть и так далее. Поэтому ты хочешь ограничить скоп, что именно она может у тебя делать.

И желательно, чтобы эти изменения, они еще были идемпатентны, чтобы, если что, она запустит этот скрипт несколько раз, чтобы у тебя прот не упал от того, что много раз все накатилось. Поэтому... Как это происходит у нас? У нас есть вот этот workflow редактор, YAML или визуальный, где можно написать, сходи по SSH, там что-то сделай, или там... сделай куб getpods и if что-нибудь еще. И это скрипт. И просто мы его запускаем. И моделька...

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

Вообще я про все это рассказываю и, может быть, звучит как рекламно, но мне очень хочется, чтобы мы те модели, которые у нас очень хорошо будут работать и те модели, которые не так критичны, чтобы мы их выкатили в open source. И тогда, мне кажется, у этой штуки будет такой прям широкий-широкий adoption, как у инструмента, который будет сам что-то фиксить.

Хочу немножко поглубже копнуть в авторы медиэйшн. Мне интересно, ну, то есть, как я услышал, основная проблема в том, что достаточно опасно позволять AI запускать у себя в проде какие-то рандомные скрипты.

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

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

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

У нас постоянно высказывает инцидент, когда нужно чистить какой-то кэш. И, в принципе, этот кэш можно было бы чистить по, там, Sleep 60. Тогда можно засунуть это от Repedition, и пусть оно себе чистит, когда оптимально, потому что моделька там придет к какому-то оптимуму. Здесь очень много стоит задач. Основная задача — это, конечно, если у нас... Мониторинг правильно покрывает работоспособность системы.

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

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

Пока не там. Будем ждать, будем ждать. Вторая вещь, про которую хотел пожаловаться, это про инцидент резолюшн. Периодически, ну, в общем... Не знаю, это можно назвать хобби. Мне интересно смотреть на границы того, чем мне может помочь, в частности, чай GPT. И там одна из вещей, где хочется им воспользоваться, это история про то, когда у тебя возникают какие-то проблемы инфраструктурные.

Ну, то есть, понятно, это прям небольшая инфраструктура, а вот часто какие-то проблемы именно с твоим локальным environment. Что-то не хватает, каких-то библиотек, еще что-то. Особенно, когда ты до этого весь код ты тоже взял, нагенерил при помощи чада GPT в своем неродном стеке. Оно работает. Но, блин, опять же взять какую-нибудь веб-разработку, там такое количество технологий, ты их всех затащил, ты сам уже не понимаешь, что происходит, и типа чат GPT, помоги, спаси, пожалуйста.

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

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

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

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

Этот кусочек планируем. Он у нас супербазовый. И, кстати, даже интересно проверить, войдет ли он в этот луп. Здесь у меня такой комментарий. Я, поскольку инцидентами и алертами занимаюсь фуллтайм практически последние лет 8-9, Я посмотрел, я, наверное, прочел все публичные постмортомы, если у компании что-то отваливается, и они обычно там классные компании, открытые, с открытой культурой, они пишут это в паблик.

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

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

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

В случае людей они просто замолкают и смотрят друг на друга в зум-зумке. А чат GPT замолчать и посмотреть на тебя серьезным взглядом не может, поэтому он возвращает тебя на круг один. В этом смысле, чем мы можем помочь, то есть платформы, которые находятся между Observability и IRM, Это мы можем в самом начале дать очень много вкусного широкого контекста, потому что какому результату, какой самый частый резолюшен

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

Мы знаем все, что когда выкатилось, весь код, который поменялся. И вот это поступило в контекст LLM. То есть первый запрос, который ты делаешь в LLM, он уже содержит большое количество всяких разных экспериментов и фоновой информации. И, скорее всего, она тебе сразу даст правильный ответ. А если ты еще туда загрузил старый пасмортом, это вообще чудо, потому что очень частая история, когда в большой корпорации что-то ломается.

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

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

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

Это как такой хороший поисковик. Представь, что в начале разбора инцидента ты все уже, возможно, погуглил. и про чем все старое. Лемка, она же ничего нового не может принести. Она может принести немножко методологии. Ты коснулся этого, что кто-то опытный, когда ты говоришь, кто-то опытный, обычно чем опытный... там инженер отличается неопытного он

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

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

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

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

отвечать условно «да» или «нет». И как будто бы здесь вот Блин, это идеальный матч. Для чего AI-чик мог бы здесь помочь? Это в том, чтобы собирать, как раз смотреть на эти инциденты исторически в конкретной компании и условно там за 15 минут, за полчаса до большого взрыва говорить о том, что, ребята, кажется, мы летим в пропасть и звонить, собственно, главному там...

Кого мы там будили? Главного архитектора? Главный по пропасти. Да-да-да. Собственно, звонить там СТО главному архитектору не через 15 минут, как все прилегло, а, собственно, за полчаса до. То есть когда он еще чуть более трезвый к этому моменту. Вот мне очень нравится, на самом деле, рассказывать про эту индустрию людям, которые в ней там не очень глубоко, вот прям не day-to-day, потому что...

вот такой вот взгляд широкий на вещи, он помогает понять, к чему мы в итоге придем. А сейчас мы, когда смотрим очень близко на... предметная область, мы видим в ней разные компоненты и как сложность между их взаимодействием и так далее. Мне кажется, ты здесь упомянул два компонента, один из которых упоминали, другой нет. Первый компонент — это сбор метрик

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

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

То есть мы можем заалертить команды, которые там у нас есть база данных, есть команды, которые отвечают за базу данных.

Есть еще 35 разных отделов департаментов, которые этими базами данных пользуются. И вот у них сейчас прилег автоскейлинг, и нам надо сообщить всем, кто от этого зависит. Этот топик называется топология. В нашем случае... AIOps топология является входящим контекстом, то есть мы ее просто кушаем и можем использовать как контекст для raising инцидентов или описания инцидентов или помощи с incident resolution.

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

поможет неразлежащим инструментам строить правильную топологию из этого. Сейчас самый большой такой hot topic — это построение топологии из трейсов. То есть когда тебе прилетел трейс из разных сервисов, тебе прилетало много-много трейсов, а потом ты строишь такое большое-большое дерево. Кажется, это умеет Datadog и кто-то еще. Но мы видели такие очень-очень большие массивные деревья, больших компаний.

где там прям... У нас есть рендер топологии в open-source даже кипе. И он... Ну, мы когда тестировали, ну, мы там, не знаю, 100 нот загрузили, протестировали, как это все работает, как zoom in, zoom out. как навигироваться к определенному дереву, а потом... К нам подключился какой-то клиент, и у нас просто такой полный фриз экрана, потому что там, ну, я не знаю, 10 этих микросервисов, и просто UI не рендерил. Это была забавная задачка. Я такого даже не видел раньше.

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

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

В каком-то количестве случаев, когда у нас происходит некая катастрофа, у нас ивенты имеют там некоторые паттерны. И вот поиск таких паттернов, как будто бы это хорошая задача для AI. Вот какая была мысль. Наконец-то получилось сформулировать. Как тебе кажется, насколько можно для такой задачи... применять AI. Может быть, вы уже это делаете. А что есть паттерн? То есть паттерн — это когда у нас в субботу не нагрузился сервер днем. Да, это вот...

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

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

Вот этот use case, когда у нас по 500 сервис аутентификации, потом что-то там не забрало кэш, и где-то в другой части системы тоже что-то немножко обвалилось. И это предвестник большого-большого инцидента. Но мы об этом еще не знаем. Что видит observability платформа? Observability платформа видит сами пятисотки, логи о пятисотках. И метрики о том, что процент...

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

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

Там механизм ровно то же самое. Круто. Все. Наконец, к последнему вопросу я понял, какая основная идея и в каких сценариях у вас может все круто работать. Кажется, мне нужно учиться лучше объяснять. И тем временем, раз Стас наконец-то разобрался, я задам еще один вопрос, который, может быть, поможет. Который теперь он сможет понять. Есть ли еще какие-то... Что такое элш?

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

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

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

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

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

И поэтому мы хотим выкатить эти модельки в open source. Какие-то из них, которые позволят закрыть весь этот use case. И тогда человек в небольшой компании, из ста, наверное, инженеров, Он сможет накатить себе кип или какой-то другой инструмент, даже уже не говоря сейчас про него, подсоединить его к разработчику платформе и сказать, кип мне позвонит, когда что-то вот прям будет нужно. То есть это такая финальная цель, к которой мы хотим прийти. Здесь микс между доверием и технологией.

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

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

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

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

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

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

как раз вот про модели, о которой мы поговорили, как, соответственно, можно строиться. Спасибо тебе за это. Было очень интересно. Спасибо большое. Очень интересные вопросы. И надеюсь, кому-то что-то стало понятнее. Потому что я знаю, что в комьюнити, особенно в русскоязычном, очень большая экспертиза в observability, особенно в open source, и очень большая экспертиза в ARM, а AIOps пока еще так не был сильным.

Освещён. Надеюсь, чем-то здесь помог. Спасибо большое. Стас? Да-да? Можно ли задать тебе вопрос? Конечно. Что тебе нравится больше, чем понимать, что в целом, несмотря на то, что мы записали уже почти 400 выпусков, теперь мы можем записать их, по сути, по новой, говоря... Добавляя AI. да и говоря про то как как я все поменял

Блин, вот на самом деле вот эта вся история два года назад, она вообще практически спасла наш подкаст, мы уже собирались закрываться, но теперь мы просто... Не просто переговоры о зарплате, а AI-переговоры о зарплате. AI-осознанность. Ждем, ждем.

вот этот вот выпуск, он будет мега популярным. Блин, вот это будет топ. Да. Собственно, да. Больше этого, дорогие друзья, мне нравится, когда вы ставите нам 5 звезд в iTunes, и твитите, и ретвитите, и рассказываете о нас своих друзьям. А самое главное, слушайте подкаст «Подлодка». Это был выпуск... про AIOps. В гостях у нас был Матвей Кукуй. Шикарный выпуск. Еще услышимся. Всем пока-пока. Всем пока. Пока-пока. Спасибо.