Привет! Я Ксения, основатель As-Is🔴
Со студенческой скамьи мечтала стать ИТ-архитектором: проектировать системы, которых ещё не существует. Но первый реальный проект быстро отрезвил: чтобы строить To-Be, нужно сначала распутать As-Is. Составить реестр ВМ и микросервисов на всех стендах, понять связи, собрать диаграммы деплоя. Что-то можно узнать из CMDB и RHDH, но многое - только из уст разработчиков и сисадминов (а люди могут забывать и ошибаться).
На следующих работах история повторилась. Архитектора чаще зовут не "с нуля", а когда всё уже запуталось: сначала навести порядок и поддерживать его, а уже потом - проектировать.
Эту рутину я хочу автоматизировать.
Так появился As-Is: я разрабатываю инструмент, который будет автоматически строить карту сервисов и артефакты As-Is - чтобы архитектор быстрее переходил к To-Be.
✔️ Что делаю:
🔘 На этом канале - путь продукта, находки, грабли и практические материалы. Присоединяйтесь.
✔️Если нужна карта сервисов для вашего проекта - напишите мне
Со студенческой скамьи мечтала стать ИТ-архитектором: проектировать системы, которых ещё не существует. Но первый реальный проект быстро отрезвил: чтобы строить To-Be, нужно сначала распутать As-Is. Составить реестр ВМ и микросервисов на всех стендах, понять связи, собрать диаграммы деплоя. Что-то можно узнать из CMDB и RHDH, но многое - только из уст разработчиков и сисадминов (а люди могут забывать и ошибаться).
На следующих работах история повторилась. Архитектора чаще зовут не "с нуля", а когда всё уже запуталось: сначала навести порядок и поддерживать его, а уже потом - проектировать.
Эту рутину я хочу автоматизировать.
Так появился As-Is: я разрабатываю инструмент, который будет автоматически строить карту сервисов и артефакты As-Is - чтобы архитектор быстрее переходил к To-Be.
✔️ Что делаю:
🔻 As-Is как услуга. Подключаюсь к вашему проекту и описываю текущую архитектуру (конфиги, логи, репозитории, интервью с командами). Для вас на выходе - карта сервисов, диаграммы деплоя и C4. Для меня - полевая практика для создания универсального инструмента.
🔻 "Архитектура по кнопке". Разрабатываю продукт, который собирает As-Is автоматически.
🔘 На этом канале - путь продукта, находки, грабли и практические материалы. Присоединяйтесь.
✔️Если нужна карта сервисов для вашего проекта - напишите мне
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4🔥1
Недавно Random Coffee внутри клуба @spbfounders смэтчил меня с продакт-менеджером, сильно увлечённой AI-агентами. Я, конечно, рассказала про боль, которую решает As-Is: автоматизацию описания ИТ-инфраструктуры. А она сказала: "Так это же банальный AI-агент".
🤔 Я уже не раз слышала предложение "ИИ-изировать" идею. Обычно отвечаю, что прелесть будущего продукта - в его детерминированности. Разработчики могут что угодно вайбкодить, нейросети - сколько угодно галлюцинировать, девопсы - играть в войнушку зомби-сервисами, но As-Is всё покажет как есть: без видеокарт, без галлюцинаций, без СМС.
Но в этот раз я посмотрела на проблему под другим углом. Допустим, нейросеть. Откуда она возьмёт данные? Как открыть ей все двери, чтобы картина была цельной?
Приятно было увидеть, что вчера тот же вопрос поднял Александр Кусургашев в докладе "Продукт без боли: скорость без риска, качество без тормозов". Он рассказывал про инженерную экосистему, которая позволяет тестировать продуктовые гипотезы за сутки: идея → код → данные → идея.
Сейчас в Т-банке есть отдельные сервисы, которые ускоряют разработку ("база данных по кнопке" и т.п.), но нет единого конвейера, соединяющего их в понятный процесс. Они как раз на пути к его реализации. И одна из ключевых задач на этом пути - сделать все сервисы AI-friendly (MCP + A2A), чтобы на каждом этапе к каждому из них мог постучаться AI-агент за информацией.
Отличный доклад и вдохновляющее направление мысли!🔥
🤔 Я уже не раз слышала предложение "ИИ-изировать" идею. Обычно отвечаю, что прелесть будущего продукта - в его детерминированности. Разработчики могут что угодно вайбкодить, нейросети - сколько угодно галлюцинировать, девопсы - играть в войнушку зомби-сервисами, но As-Is всё покажет как есть: без видеокарт, без галлюцинаций, без СМС.
Но в этот раз я посмотрела на проблему под другим углом. Допустим, нейросеть. Откуда она возьмёт данные? Как открыть ей все двери, чтобы картина была цельной?
Приятно было увидеть, что вчера тот же вопрос поднял Александр Кусургашев в докладе "Продукт без боли: скорость без риска, качество без тормозов". Он рассказывал про инженерную экосистему, которая позволяет тестировать продуктовые гипотезы за сутки: идея → код → данные → идея.
Сейчас в Т-банке есть отдельные сервисы, которые ускоряют разработку ("база данных по кнопке" и т.п.), но нет единого конвейера, соединяющего их в понятный процесс. Они как раз на пути к его реализации. И одна из ключевых задач на этом пути - сделать все сервисы AI-friendly (MCP + A2A), чтобы на каждом этапе к каждому из них мог постучаться AI-агент за информацией.
Отличный доклад и вдохновляющее направление мысли!🔥
❤1
Продолжаю размышлять про применимость ИИ для составления карты сервисов As-Is.
Несмотря на то, что я много вокруг наблюдаю случаев, когда корпоративный код и документацию без фильтров загружают в западные или восточные нейросети, я понимаю, что эта временная сладкая свобода рано или поздно закончится. Все крупные компании развернут локальные gpt (как это уже сделал, например, Авито) и "сливать" можно будет только туда.
А что же со стартапами на базе gpt, которым для работы нужен доступ к чувствительной информации?
Мне кажется, что если прямо сейчас их никто не пустит в контур, то буквально через год-два достаточно будет добавить кнопку переключения с условного ChatGPT на локальную нейросеть и всё будет работать. И в контур пустят, и результат генерации всех устроит.
Cursor уже доказал нам, что интерфейс для работы с нейросетью не должен ограничиваться окном чата. Так что давайте придумывать новые интерфейсы😌
Классным примером является российский стартап Phygital (на фото их питч), который сделал удобный интерфейс для генерации и редактирования изображений (Cursor для дизайнеров). Они уже успешно работают на B2B.
Но им в контур помогло войти то, что они не работают с чувствительными данными. Тем же, кому эти данные нужны, думаю, нужно уже сейчас готовить интерфейсы под будущие повсеместные инхаус LLM.
Несмотря на то, что я много вокруг наблюдаю случаев, когда корпоративный код и документацию без фильтров загружают в западные или восточные нейросети, я понимаю, что эта временная сладкая свобода рано или поздно закончится. Все крупные компании развернут локальные gpt (как это уже сделал, например, Авито) и "сливать" можно будет только туда.
А что же со стартапами на базе gpt, которым для работы нужен доступ к чувствительной информации?
Мне кажется, что если прямо сейчас их никто не пустит в контур, то буквально через год-два достаточно будет добавить кнопку переключения с условного ChatGPT на локальную нейросеть и всё будет работать. И в контур пустят, и результат генерации всех устроит.
Cursor уже доказал нам, что интерфейс для работы с нейросетью не должен ограничиваться окном чата. Так что давайте придумывать новые интерфейсы😌
Классным примером является российский стартап Phygital (на фото их питч), который сделал удобный интерфейс для генерации и редактирования изображений (Cursor для дизайнеров). Они уже успешно работают на B2B.
Но им в контур помогло войти то, что они не работают с чувствительными данными. Тем же, кому эти данные нужны, думаю, нужно уже сейчас готовить интерфейсы под будущие повсеместные инхаус LLM.
👍2
Сергей Баранов на днях написал в своем канале:
Считаю, что вайб-проекты - самые целевые пользователи As-Is. В какой-то момент за вайб-кодингом последует вайб-девопсинг... И тогда нам останется только с интересом наблюдать за динамикой изменения инфраструктуры As-Is в реальном времени😄
Вопрос только в том, будет ли это реверс-инжиниринг или вайб-реверс-инжиниринг.
Судя по тенденциям, общению, анализу, скоро появится потребность в навыке архитектурного устранения последствий vibe coding.
А проблема там усугубляется тем, что при обычной архитектурной диагностике есть носители контекста, а люди (с разной степенью) последовательны, даже если архитектура не очень «стройная».
А вот с вайб кодингом проблема оказалась в том, что носителя контекста как-бы нет, точнее контекст порой вообще не бьется с физическим воплощением и много странных заплаток, то есть пока непонятно, как-будто требуется полное проектирование с нуля (пока кейсов очень мало, но я не нашел других рабочих методов, пока не нашел), но с использованием хотя бы данных о реальном использовании пользователями и эксплуатации в проде.
Считаю, что вайб-проекты - самые целевые пользователи As-Is. В какой-то момент за вайб-кодингом последует вайб-девопсинг... И тогда нам останется только с интересом наблюдать за динамикой изменения инфраструктуры As-Is в реальном времени😄
Вопрос только в том, будет ли это реверс-инжиниринг или вайб-реверс-инжиниринг.
👍2🙈1
Недавно на инфраструктурном митапе клуба Inview в ИТМО попросили поднять руки тех, у кого есть адекватная документация, которая соответствует проду. В большом зале подняли руки… четыре человека.
И вроде бы когда я на кастдевах спрашиваю, стоит ли проблема инвентаризации инфры / архитектурных диаграмм / сервисных карт - мне скучающим голосом перечисляют: CMDB, Grafana Service Map, DataDog, NetBox, Zabbix и т.д.
Столько всего есть, а актуальной документации нет. Как так?
В эпоху данных часто спрашивают: "А знаете ли вы, чем данные отличаются от информации?" Кажется, с этим мы уже разобрались.
Теперь хочется понять другое: чем инвентаризация отличается от документации? И почему у всех так много данных - но всё равно нет актуальной архитектуры As-Is?🔴
И вроде бы когда я на кастдевах спрашиваю, стоит ли проблема инвентаризации инфры / архитектурных диаграмм / сервисных карт - мне скучающим голосом перечисляют: CMDB, Grafana Service Map, DataDog, NetBox, Zabbix и т.д.
Столько всего есть, а актуальной документации нет. Как так?
В эпоху данных часто спрашивают: "А знаете ли вы, чем данные отличаются от информации?" Кажется, с этим мы уже разобрались.
Теперь хочется понять другое: чем инвентаризация отличается от документации? И почему у всех так много данных - но всё равно нет актуальной архитектуры As-Is?
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
На одном из кастдевов мне посоветовали обратить внимание на DataDog. Это сервис мониторинга, который в том числе строит сервисные карты.
Я человек очень конкретный, поэтому мы с моей новой разработчицей Дарьей отправились в Дубай на выставку Gitex, чтобы пообщаться с представителями DataDog (и не только)😄
Один из вопросов, который меня интересовал: как отобразить на сервисной карте виртуалку, к которой нет доступа и потеряны все пароли.
Я думала в сторону того, чтобы не отображать связи вообще (всё равно время жизни такой виртуалки - до первого сбоя). Или показать только входящие стрелки. Или попробовать анализировать сетевой трафик... Но веселые сотрудники DataDog мне на это сказали, что в таком случае надо просто сделать brute force (иными словами хакнуть виртуалку).
Что думаете? Стоит ли включить функционал "хакнуть забытую виртуалку" в состав As-Is?))🔴
Я человек очень конкретный, поэтому мы с моей новой разработчицей Дарьей отправились в Дубай на выставку Gitex, чтобы пообщаться с представителями DataDog (и не только)😄
Один из вопросов, который меня интересовал: как отобразить на сервисной карте виртуалку, к которой нет доступа и потеряны все пароли.
Я думала в сторону того, чтобы не отображать связи вообще (всё равно время жизни такой виртуалки - до первого сбоя). Или показать только входящие стрелки. Или попробовать анализировать сетевой трафик... Но веселые сотрудники DataDog мне на это сказали, что в таком случае надо просто сделать brute force (иными словами хакнуть виртуалку).
Что думаете? Стоит ли включить функционал "хакнуть забытую виртуалку" в состав As-Is?))
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7❤2🥰2
VictoriaMetrics - хороший пример того, как можно вырасти в инфра-сегменте без революций и ломки привычек.
Есть рынок мониторинга: компании собирают метрики с сервисов, хотят хранить их подольше и по этим данным разбирать инциденты. Prometheus стал стандартом де-факто: под него уже написаны экспортеры почти для всего, команды умеют с ним работать, вокруг него сложилась целая экосистема. Но у классического Prometheus быстро появляются больные места: дорого хранить много данных, сложно тянуть длинный ретеншн, архитектура раздувается.
VictoriaMetrics не пришла с идеей "мы вместо Prometheus". Они сделали умнее: оставили весь мир Prometheus как есть (экспортеры, формат метрик, привычные дашборды) и заменили только хранилище и обработку метрик там, где особенно больно по ресурсам и деньгам.
VictoriaMetrics понимает протокол Prometheus, работает с теми же экспортерами и поддерживает PromQL. Для команды это не новый продукт "с нуля", а почти прозрачный апгрейд: подключили другой backend - и мониторинг продолжает жить как раньше, только хранить стало дешевле и можно держать данные дольше.
Урок простой: "То же самое, что у вас уже есть, но без финансовой боли и с нормальным ретеншном" продаётся лучше, чем "новый мир наблюдаемости".
И здесь важно понять для As-Is: нам тоже не обязательно изобретать всё заново. Вопрос в том, что мы можем взять готовым и каким минимальным усилием можно добавить максимальный результат к уже существующей инфраструктуре клиентов?🔴
P.S. Спасибо бывшей разработчице As-Is Дарье за этот кейс.
Есть рынок мониторинга: компании собирают метрики с сервисов, хотят хранить их подольше и по этим данным разбирать инциденты. Prometheus стал стандартом де-факто: под него уже написаны экспортеры почти для всего, команды умеют с ним работать, вокруг него сложилась целая экосистема. Но у классического Prometheus быстро появляются больные места: дорого хранить много данных, сложно тянуть длинный ретеншн, архитектура раздувается.
VictoriaMetrics не пришла с идеей "мы вместо Prometheus". Они сделали умнее: оставили весь мир Prometheus как есть (экспортеры, формат метрик, привычные дашборды) и заменили только хранилище и обработку метрик там, где особенно больно по ресурсам и деньгам.
VictoriaMetrics понимает протокол Prometheus, работает с теми же экспортерами и поддерживает PromQL. Для команды это не новый продукт "с нуля", а почти прозрачный апгрейд: подключили другой backend - и мониторинг продолжает жить как раньше, только хранить стало дешевле и можно держать данные дольше.
Урок простой: "То же самое, что у вас уже есть, но без финансовой боли и с нормальным ретеншном" продаётся лучше, чем "новый мир наблюдаемости".
И здесь важно понять для As-Is: нам тоже не обязательно изобретать всё заново. Вопрос в том, что мы можем взять готовым и каким минимальным усилием можно добавить максимальный результат к уже существующей инфраструктуре клиентов?
P.S. Спасибо бывшей разработчице As-Is Дарье за этот кейс.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍1🔥1
Получила на Хэллоуин благословление на свой инфра-стартап от Крестного отца DevOps @top1ceo🔥
Хороший знак?
Уверена, что да🔴
Хороший знак?
Уверена, что да
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4