Философское - облако и разделение труда (4)
В начало цикла - Части 1-3
Как добиться роста кооперации.
Рост выгоден всем. Компаниям, государству, специалистам.
Если вы владелец или топ-менеджер платформы или сервиса, подумайте, как сделать, чтобы ваши клиенты захотели с вами кооперироваться. Подумайте, как для них нарастить выгоду от сотрудничества с вами и как снизить риски.
Как снизить риски в продукте
1️⃣ Начинайте с малого. Все клиенты из моего пула в облаке стартовали с небольших проектов и второстепенных сервисов. Тогда ваши клиенты точно будут знать, что именно вам можно доверить, а что нет. А ваши факапы не станут смертельными для сотрудничества.
Почти всегда вы пушите продажи и внедрение забрать сразу вообще все. Самые крупные проекты, самые сжатые сроки. В ответ получаете запредельную для вас планку по техническим требованиям и по доверию к вам. Факапитесь, и на этом вашим отношениям с клиентом конец.
Продукт или ваше предложение должен позволить начать с малого. Будьте готовы работать на небольших оборотах, имейте запас прочности, чтобы не оказаться в ситуации, когда нужно много денег вот прямо сейчас.
2️⃣ Продукт должен убирать собственные риски. Такие «второстепенные» функции ИТ-продукта как мониторинги, обсервабилити, безопасность - часто делается по остаточному принципу после «важных» фичей продукта. Это бич типичного российского ИТ-изделия.
Так вы получаете прекрасный и функциональный (но это не точно) продукт, которым невозможно пользоваться на практике. А ну как сломается, и что с этим делать? Как вот этому у которого нет базового дашборда мониторинга (зеленый - хорошо, красный - плохо), поручить критичные бизнес-процессы?
Давайте небольшой чеклист про риски.
*️⃣ Вы продумали, что делать, когда в вашем изделии все пойдет не так. У вас можно заметить проблемы на ранних подступах.
*️⃣ У вас есть документация, как это чинить, вы проводите обучение ответственных сотрудников заказчика, объясняете как пользоваться вашим изделием правильно и по назначению.
*️⃣ У вас есть база знаний типовых поломок и плохих ситуаций, что к ним может привести и как с ними бороться.
*️⃣ У вас есть качественная и быстрая поддержка. Вы готовы бросить все и сорваться чинить критическую проблему заказчика. Второй бич почти всех российских вендоров - поддержка вида «ну напишите нам в телегу или на почту, там разберемся»
Чеклист можно продолжить.
Когда вы приходите к заказчику, главный вопрос, который он решает - можно ли вот этим поручить серьезное дело? Правильно ли я поступаю, ставя себя в зависимость вот от них?
Думайте об этом, носите мысль в сердце своем.
В начало цикла - Части 1-3
Как добиться роста кооперации.
Рост выгоден всем. Компаниям, государству, специалистам.
Если вы владелец или топ-менеджер платформы или сервиса, подумайте, как сделать, чтобы ваши клиенты захотели с вами кооперироваться. Подумайте, как для них нарастить выгоду от сотрудничества с вами и как снизить риски.
Как снизить риски в продукте
Почти всегда вы пушите продажи и внедрение забрать сразу вообще все. Самые крупные проекты, самые сжатые сроки. В ответ получаете запредельную для вас планку по техническим требованиям и по доверию к вам. Факапитесь, и на этом вашим отношениям с клиентом конец.
Продукт или ваше предложение должен позволить начать с малого. Будьте готовы работать на небольших оборотах, имейте запас прочности, чтобы не оказаться в ситуации, когда нужно много денег вот прямо сейчас.
Так вы получаете прекрасный и функциональный (но это не точно) продукт, которым невозможно пользоваться на практике. А ну как сломается, и что с этим делать? Как вот этому у которого нет базового дашборда мониторинга (зеленый - хорошо, красный - плохо), поручить критичные бизнес-процессы?
Давайте небольшой чеклист про риски.
Чеклист можно продолжить.
Когда вы приходите к заказчику, главный вопрос, который он решает - можно ли вот этим поручить серьезное дело? Правильно ли я поступаю, ставя себя в зависимость вот от них?
Думайте об этом, носите мысль в сердце своем.
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Архитектор Данных
Философское - облако и разделение труда (1)
В одной умной книге по современной экономике натолкнулся на отличную мысль.
Прогресс и рост экономики последние сотни лет идет по линии разделения труда.
В городе три мастера, которые делают телеги сами от…
В одной умной книге по современной экономике натолкнулся на отличную мысль.
Прогресс и рост экономики последние сотни лет идет по линии разделения труда.
В городе три мастера, которые делают телеги сами от…
👍5❤1
Философское - облако и разделение труда (5)
В начало цикла. Части 1-3.
В плане разделения ИТ-труда и кооперации многие российские компании находятся на стадии натурального хозяйства. Все сделаем и разработаем сами, сами закупим железо, сами настроим, сами будем эксплуатировать, сами напишем код.
Отдельно грустно когда в большой компании или холдинге отдельные отделы и бизнесы ведут себя так же обособленно. Это уже не феодализм, а феодальная раздробленность, эпоха воюющих княжеств.
Как в таком состоянии можно с кем-то всерьез конкурировать? С тем, кто просто на другом этапе развития? Рыцари и бояре с копьями не имеют шансов против пулемета, какими бы лично сильными, храбрыми, выносливыми они ни были.
Внутри у себя поощряйте разделение труда. Чтобы хотя бы отделы сумели договориться админить базы сообща. Или почтовый сервер купили. Или хранилище данных с отчетами вместе одно на всех поддерживали. Выстраивание общих процессов ценно само по себе, растит экспертизу и экономит ресурсы. Бейте по голове менеджеров, которым проще самим все сделать, чем с кем-то пойти договориться. Выжигайте огнем культуру феодализма хоть бы и вместе с феодалами.
Ваши менеджеры должны искать способы купить машину, а не изобрести мопед. Найти тех кому можно доверять хотя бы в малом, чтобы хотя бы в этом малом сэкономить внутренние ресурсы.
Отдельно хотелось бы пожелать любимым регуляторам. Не растите риски на ровном месте. Самый большой риск - это риск возрастания рисков. Причем возрастания часто внезапного и нелогичного.
Позитивный тренд от регуляторов - принуждение к кооперации. Яркий пример - проект ГосОблака от Минцифры, который как-то движется.
Вдумайтесь, вместо того чтобы каждый сайт региональной прокуратуры, муниципалитета и детского сада решал проблему размещения своей инфраструктуры и сервисов самостоятельно, делаем общее для всех пространство. И это в то время когда большие и "цифровые" в сознании людей компании следуют подходу - мы будем делать все сами, пусть бедно и плохо, но зато ни от кого не завися. А в запущенных ситуациях - примерно то же но уже на уровне отдельных отделов и команд.
В начало цикла. Части 1-3.
В плане разделения ИТ-труда и кооперации многие российские компании находятся на стадии натурального хозяйства. Все сделаем и разработаем сами, сами закупим железо, сами настроим, сами будем эксплуатировать, сами напишем код.
Отдельно грустно когда в большой компании или холдинге отдельные отделы и бизнесы ведут себя так же обособленно. Это уже не феодализм, а феодальная раздробленность, эпоха воюющих княжеств.
Как в таком состоянии можно с кем-то всерьез конкурировать? С тем, кто просто на другом этапе развития? Рыцари и бояре с копьями не имеют шансов против пулемета, какими бы лично сильными, храбрыми, выносливыми они ни были.
Внутри у себя поощряйте разделение труда. Чтобы хотя бы отделы сумели договориться админить базы сообща. Или почтовый сервер купили. Или хранилище данных с отчетами вместе одно на всех поддерживали. Выстраивание общих процессов ценно само по себе, растит экспертизу и экономит ресурсы. Бейте по голове менеджеров, которым проще самим все сделать, чем с кем-то пойти договориться. Выжигайте огнем культуру феодализма хоть бы и вместе с феодалами.
Ваши менеджеры должны искать способы купить машину, а не изобрести мопед. Найти тех кому можно доверять хотя бы в малом, чтобы хотя бы в этом малом сэкономить внутренние ресурсы.
Отдельно хотелось бы пожелать любимым регуляторам. Не растите риски на ровном месте. Самый большой риск - это риск возрастания рисков. Причем возрастания часто внезапного и нелогичного.
Позитивный тренд от регуляторов - принуждение к кооперации. Яркий пример - проект ГосОблака от Минцифры, который как-то движется.
Вдумайтесь, вместо того чтобы каждый сайт региональной прокуратуры, муниципалитета и детского сада решал проблему размещения своей инфраструктуры и сервисов самостоятельно, делаем общее для всех пространство. И это в то время когда большие и "цифровые" в сознании людей компании следуют подходу - мы будем делать все сами, пусть бедно и плохо, но зато ни от кого не завися. А в запущенных ситуациях - примерно то же но уже на уровне отдельных отделов и команд.
Telegram
Архитектор Данных
Философское - облако и разделение труда (1)
В одной умной книге по современной экономике натолкнулся на отличную мысль.
Прогресс и рост экономики последние сотни лет идет по линии разделения труда.
В городе три мастера, которые делают телеги сами от…
В одной умной книге по современной экономике натолкнулся на отличную мысль.
Прогресс и рост экономики последние сотни лет идет по линии разделения труда.
В городе три мастера, которые делают телеги сами от…
👍5❤1
LakeFS приобрела DVC
Идет дальнейшая консолидация продуктов. В конце прошлого года 2 решения Git-over-S3 объединились
На моей практике многие ДС-команды "хотели" внедрять такие решения в свои пайплайны. Управлять версиями датасетов так же легко и теми же способами, как это делается для кода самих моделей. Валидировать вчерашнюю модель + сегодняшние данные против сегодняшняя модель + вчерашние данные. Быстро понимать, предикты испортились потому что в модели напортачили или потому что дрейф в данных пошел.
Но в проде такой логики я ни у кого не видел и не слышал.
Киньте ссылку, если видели статью или доклад про применение гитования данных в проде!
Идет дальнейшая консолидация продуктов. В конце прошлого года 2 решения Git-over-S3 объединились
На моей практике многие ДС-команды "хотели" внедрять такие решения в свои пайплайны. Управлять версиями датасетов так же легко и теми же способами, как это делается для кода самих моделей. Валидировать вчерашнюю модель + сегодняшние данные против сегодняшняя модель + вчерашние данные. Быстро понимать, предикты испортились потому что в модели напортачили или потому что дрейф в данных пошел.
Но в проде такой логики я ни у кого не видел и не слышал.
Киньте ссылку, если видели статью или доклад про применение гитования данных в проде!
lakeFS
lakeFS Acquires DVC, Uniting Data Version Control Pioneers to Accelerate AI-ready Data
Foundational technology for enterprise AI success now ranges from individual data science projects to Fortune 100 AI infrastructure.
❤5
О вайбкодинге
Сегодня впервые показывали навайбкоженное демо бизнес-заказчику.
Как было раньше: технически продуктовая часть работает, задача решается. Но показать это сложно, нужно залезать в «черные экраны» или в лучшем случае, Джупитер-ноутбуки. Бизнес-заказчик не понимает этих инструментов, ему нужен перевод с технического на бизнес-язык.
Сейчас: функциональная часть быстро оборачивается в интерфейс и заказчик видит билзко к тому, что будет в конечном продукте. Он видит свой UX, понимает его, доверие к показанному растет, а доверие это важно. В финале заказчик может попробовать демо сам, со своей мыши, для этого не нужно знать консольные команды или питон.
Стал лучше понимать, почему мой хороший знакомый Влад Каменский ушел с позиции фаундера и CEO компании в области данных и стал 100% вайб-кодером. Внимательно слежу за его экспериментом.
Как говорится, и я был скептик.
Сегодня впервые показывали навайбкоженное демо бизнес-заказчику.
Как было раньше: технически продуктовая часть работает, задача решается. Но показать это сложно, нужно залезать в «черные экраны» или в лучшем случае, Джупитер-ноутбуки. Бизнес-заказчик не понимает этих инструментов, ему нужен перевод с технического на бизнес-язык.
Сейчас: функциональная часть быстро оборачивается в интерфейс и заказчик видит билзко к тому, что будет в конечном продукте. Он видит свой UX, понимает его, доверие к показанному растет, а доверие это важно. В финале заказчик может попробовать демо сам, со своей мыши, для этого не нужно знать консольные команды или питон.
Стал лучше понимать, почему мой хороший знакомый Влад Каменский ушел с позиции фаундера и CEO компании в области данных и стал 100% вайб-кодером. Внимательно слежу за его экспериментом.
Как говорится, и я был скептик.
Telegram
Влад Каменский | Мастер данных
Дерзкий план
У меня зреет дерзкий план! Надеюсь, после поста про ИИ совет директоров все особо нервные впечатлительные уже вышли и я никого чересчур не шокирую )
Итак, я методично погружаюсь в вайбкодинг с одной лишь целью. Мне интересно, а смогу ли я создать…
У меня зреет дерзкий план! Надеюсь, после поста про ИИ совет директоров все особо нервные впечатлительные уже вышли и я никого чересчур не шокирую )
Итак, я методично погружаюсь в вайбкодинг с одной лишь целью. Мне интересно, а смогу ли я создать…
🔥10❤1👍1
Forwarded from Поляков считает: AI, код и кейсы
Домашний ИИ-бот, который заказывает продукты из ВкусВилл
С нового года хотел попробовать MCP-сервер ВкусВилл и OpenClaw — open-source фреймворк (181k+ звёзд на GitHub), который превращает LLM в Telegram-бота с навыками.
Вчера Даша сказала: нужен бот в чат с диетологом. Давай уже сделаем?
Быстро смотреть продукты, КБЖУ, собирать корзину. Основной поставщик у нашей семьи — ВкусВилл. Засел на вечер.
🧠 Opus — дорого даже для домашнего бота
Начал с Claude Opus 4.6. За 2 часа настройки и тестов с диетологом — $30. Для бота, который ищет творог — перебор. Подключать подписку Max — боюсь, может нарушать ToS.
Переехал на Kimi K2.5 от Moonshot AI. Спасибо за наводку @nobilix
Триллион параметров, MoE-архитектура. На бенчмарках рядом с Opus, подписка за 20 долларов и я не боюсь за ToS.
🛒 MCP ВкусВилл: ищет, но не проверяет наличие
MCP-сервер умеет искать товары, показывать КБЖУ и собирать корзину. Но не проверяет наличие по адресу доставки. Без этого бот собирает корзину из товаров, от которых нет пользы.
Сайт отдаёт блок наличия только настоящему браузеру — curl не проходит, сервер проверяет TLS-fingerprint.
🔧 Решение: Puppeteer рядом с Docker
Развернул headless Chrome через Puppeteer. Один раз авторизовался через chrome://inspect, прописал адрес доставки — куки сохранились. Keepalive раз в сутки, чтобы сессия не протухала.
Теперь бот перед сборкой корзины проверяет каждый товар: есть — добавляет, нет — предлагает замену. Единственная ручная работа — авторизация через DevTools.
💰 Стоимость: ~$33 в месяц
🔸 Kimi K2.5 API — $20
🔸 VPS (1 ядро, 2 ГБ) — $12
🔸 Perplexity API (веб-поиск) — ~$1
🔸 OpenAI API (голосовые) — копейки
Семейный ассистент с голосовыми, веб-поиском и интеграцией с продуктовым магазином. Настройку делал через Claude Code — следил за лимитами, хватило бы стандартной подписки.
🔒 Безопасность
Docker, allowlist по Telegram ID, изоляция сессий между пользователями. В интернет — только через проверенные эндпоинты.
📦 Гайд со всеми граблями
Конфигурация провайдера, heartbeat, Puppeteer, безопасность, cron-задачи:
🔗 GitHub: openclaw-homebot-guide
Если пост увидят во ВкусВилл — ребята, MCP крутой, но сделайте авторизацию для ИИ-агентов. Одна таблица в базе, связь с учёткой, SMS — и можно отдать ключ агенту без костылей с безголовым Chrome.
----
Поляков считает — AI, код и кейсы
С нового года хотел попробовать MCP-сервер ВкусВилл и OpenClaw — open-source фреймворк (181k+ звёзд на GitHub), который превращает LLM в Telegram-бота с навыками.
Вчера Даша сказала: нужен бот в чат с диетологом. Давай уже сделаем?
Быстро смотреть продукты, КБЖУ, собирать корзину. Основной поставщик у нашей семьи — ВкусВилл. Засел на вечер.
🧠 Opus — дорого даже для домашнего бота
Начал с Claude Opus 4.6. За 2 часа настройки и тестов с диетологом — $30. Для бота, который ищет творог — перебор. Подключать подписку Max — боюсь, может нарушать ToS.
Переехал на Kimi K2.5 от Moonshot AI. Спасибо за наводку @nobilix
Триллион параметров, MoE-архитектура. На бенчмарках рядом с Opus, подписка за 20 долларов и я не боюсь за ToS.
💡 OpenClaw имеет встроенную поддержку Kimi Coding — не нужно возиться с эндпоинтами. Указал модель, прописал ключ — работает.
🛒 MCP ВкусВилл: ищет, но не проверяет наличие
MCP-сервер умеет искать товары, показывать КБЖУ и собирать корзину. Но не проверяет наличие по адресу доставки. Без этого бот собирает корзину из товаров, от которых нет пользы.
Сайт отдаёт блок наличия только настоящему браузеру — curl не проходит, сервер проверяет TLS-fingerprint.
🔧 Решение: Puppeteer рядом с Docker
Развернул headless Chrome через Puppeteer. Один раз авторизовался через chrome://inspect, прописал адрес доставки — куки сохранились. Keepalive раз в сутки, чтобы сессия не протухала.
Теперь бот перед сборкой корзины проверяет каждый товар: есть — добавляет, нет — предлагает замену. Единственная ручная работа — авторизация через DevTools.
💰 Стоимость: ~$33 в месяц
🔸 Kimi K2.5 API — $20
🔸 VPS (1 ядро, 2 ГБ) — $12
🔸 Perplexity API (веб-поиск) — ~$1
🔸 OpenAI API (голосовые) — копейки
Семейный ассистент с голосовыми, веб-поиском и интеграцией с продуктовым магазином. Настройку делал через Claude Code — следил за лимитами, хватило бы стандартной подписки.
🔒 Безопасность
Docker, allowlist по Telegram ID, изоляция сессий между пользователями. В интернет — только через проверенные эндпоинты.
📦 Гайд со всеми граблями
Конфигурация провайдера, heartbeat, Puppeteer, безопасность, cron-задачи:
🔗 GitHub: openclaw-homebot-guide
Если пост увидят во ВкусВилл — ребята, MCP крутой, но сделайте авторизацию для ИИ-агентов. Одна таблица в базе, связь с учёткой, SMS — и можно отдать ключ агенту без костылей с безголовым Chrome.
----
Поляков считает — AI, код и кейсы
🔥12
Forwarded from Ai molodca (Dobrokotov)
This media is not supported in your browser
VIEW IN TELEGRAM
Из комментов, тест Seedance 2.0 подписчика, промт (!): A spectacular fight between a Tajik and an Uzbek over pilaf. They use pilaf to fight each other in spectacular hand-to-hand combat.
ЭТО ЧТО ТАКОЕ ВООБЩЕ?!😮
ЭТО ЧТО ТАКОЕ ВООБЩЕ?!
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from StarRocks and modern data stack
Снаряд два раза в одну воронку не падает
Интересно, что у архитектора данных вышел цикл постов о том, почему стоит ехать в облако. А тем временем в нашей вселенной идет все ускоряющийся цикл ухода от облачной инфраструктуры во внутреннюю платформу данных чисто на реализовавшихся рисках (деньги смысла считать даже нет, стоимость рисков с лихвой покрывает всё).
Про что речь? В своем докладе что на смартдате, что в остальных местах я рассказывал про блокировку аккаунта в Google BigQuery в прошлом году на время уточнения данных, и заняло это 3 недели. Что случилось 2 недели назад? Да, аккаунт опять заблокировали, опять уточнение, ну а работа - потерпите, чай не сахарные. И следом уже вчера заблокировали целый пул ip адресов европейских цодов из стран вокруг РФ - запрет на использование api своих сервисов (BQ, GCP). То есть ты находишься не в РФ, платишь не с РФ, но никого не волнует.
Итого последние 3 недели мы перевозим проекты в StarRocks днем и ночью. Но почему-то получилось, что вместо расчета их там все заехало в Spark. Причина достаточно простая - наши эксперименты с бигквери проходили на проектах малого размера, почти все модели в dbt считались на table материализации. Spark такие штуки раскладывает примерно за 10-15 секунд на витринку, нагружать же mpp бд такого рода нагрузкой кажется напрасной затеей. Ведь в чем всегда была притензия к данным в хадупе - медленное чтение, а вот витринки собираются порой быстрее вертики (да что там, кликхауз у меня тоже получалось когда-то в телекоме обогнать). В итоге пользователи, биай и сервисы читают и делают эдхоки через StarRocks, а счет идет в кластере хадупа - все по заветам современных историй лейкхаузов, правда без перекладывания данных в слой доступа.
Ну а какие выводы можно сделать за эти 2 недели? А вот такие:
* перевозить витрины можно очень быстро
* сверять результаты между системами - чудовищная по трудоемкости операция
* витрины начинают разбегаться между системами буквально на следующей недели после переноса - надо или следить, или очень быстро ехать
Даже если функции выглядят в двух системах похоже (именуются одинаково), то совсем не факт что их аргументы или возвращаемые результаты будут идентичными. И поверх накладывается проблема вскрывания ошибок во время написания витрин в исходной системе, когда мы вынуждены или переносить расчет данных и найденную ошибку, либо мы теряем возможность построчной сверки :(
Вообщем печаль, беда и разорение. Если кто знает уже готовый тулсет для сверки таблиц построчно-поколоночно на спарке - напишите в комментарии, пожалуйста. Написать свой вроде несложно, но вдруг древние уже учли все проблемы. Почему spark? Потому что можно в нем внутри сравнивать разные системы без материализации и копирования данных, а еще легко сделать select sha1(*) from...
Интересно, что у архитектора данных вышел цикл постов о том, почему стоит ехать в облако. А тем временем в нашей вселенной идет все ускоряющийся цикл ухода от облачной инфраструктуры во внутреннюю платформу данных чисто на реализовавшихся рисках (деньги смысла считать даже нет, стоимость рисков с лихвой покрывает всё).
Про что речь? В своем докладе что на смартдате, что в остальных местах я рассказывал про блокировку аккаунта в Google BigQuery в прошлом году на время уточнения данных, и заняло это 3 недели. Что случилось 2 недели назад? Да, аккаунт опять заблокировали, опять уточнение, ну а работа - потерпите, чай не сахарные. И следом уже вчера заблокировали целый пул ip адресов европейских цодов из стран вокруг РФ - запрет на использование api своих сервисов (BQ, GCP). То есть ты находишься не в РФ, платишь не с РФ, но никого не волнует.
Итого последние 3 недели мы перевозим проекты в StarRocks днем и ночью. Но почему-то получилось, что вместо расчета их там все заехало в Spark. Причина достаточно простая - наши эксперименты с бигквери проходили на проектах малого размера, почти все модели в dbt считались на table материализации. Spark такие штуки раскладывает примерно за 10-15 секунд на витринку, нагружать же mpp бд такого рода нагрузкой кажется напрасной затеей. Ведь в чем всегда была притензия к данным в хадупе - медленное чтение, а вот витринки собираются порой быстрее вертики (да что там, кликхауз у меня тоже получалось когда-то в телекоме обогнать). В итоге пользователи, биай и сервисы читают и делают эдхоки через StarRocks, а счет идет в кластере хадупа - все по заветам современных историй лейкхаузов, правда без перекладывания данных в слой доступа.
Ну а какие выводы можно сделать за эти 2 недели? А вот такие:
* перевозить витрины можно очень быстро
* сверять результаты между системами - чудовищная по трудоемкости операция
* витрины начинают разбегаться между системами буквально на следующей недели после переноса - надо или следить, или очень быстро ехать
Даже если функции выглядят в двух системах похоже (именуются одинаково), то совсем не факт что их аргументы или возвращаемые результаты будут идентичными. И поверх накладывается проблема вскрывания ошибок во время написания витрин в исходной системе, когда мы вынуждены или переносить расчет данных и найденную ошибку, либо мы теряем возможность построчной сверки :(
Вообщем печаль, беда и разорение. Если кто знает уже готовый тулсет для сверки таблиц построчно-поколоночно на спарке - напишите в комментарии, пожалуйста. Написать свой вроде несложно, но вдруг древние уже учли все проблемы. Почему spark? Потому что можно в нем внутри сравнивать разные системы без материализации и копирования данных, а еще легко сделать select sha1(*) from...
❤8👍3🔥1
На нас надвигается великий и ужасный 117-й приказ ФСТЭК.
Нашел хорошее почти трехчасовое (!) видео с объяснением и обсуждением его деталей. В видео прекрасные тайм-коды, можно быстро почерпнуть нужные именно вам темы.
Нашел хорошее почти трехчасовое (!) видео с объяснением и обсуждением его деталей. В видео прекрасные тайм-коды, можно быстро почерпнуть нужные именно вам темы.
VK Видео
Новая редакция Приказа ФСТЭК № 117: что теперь обязательно при защите ГИС
Приказ № 117 ФСТЭК России — один из ключевых документов для всех, кто отвечает за безопасность государственных информационных систем. Осенью 2025 года документ обновился: добавлены требования к взаимодействию с подрядчиками, защите сетевой инфраструктуры…
👍6🥱3
Команда Кликхауса опенсорснула Кубернетис оператор
https://clickhouse.com/blog/clickhouse-kubernetes-operator
https://clickhouse.com/blog/clickhouse-kubernetes-operator
ClickHouse
Introducing the Official ClickHouse Kubernetes Operator: Seamless Analytics at Scale
Introducing the Official ClickHouse Kubernetes Operator, open source under Apache 2.0 and free. Deploy production ClickHouse clusters on Kubernetes with sharding, replication, and ClickHouse Keeper. Scale up or out, update configuration and versions safel
✍5
О далеких доброжелателях
На днях подписчик прислал ссылку на пост в жанре площадной филиппики в мой адрес.
В целом мне приятно, что малознакомые люди, собравшись в кружок вечером в субботу, обсуждают меня. Пусть даже предметом являются мой кошелек, мои бонусы и сильно искаженная версия трудовой биографии. Видимо, так и приходит «известность».
На пару тезисов, тем не менее, отвечу.
Первое. Я не являюсь энтерпрайз архитектором в жанре «рисую стрелочки, дорого». Я не имею отношения к архитектуре ВК, где соцсети, почта, реклама. Я работаю с заказчиками ВК Облака, типичный мой заказчик - медиум и крупный российский бизнес. Те, кто размещают инфрастуктуру данных в облаке на IaaS, SaaS, PaaS или думают об этом. В реалиях рынка мне открыто сильно больше, чем типовому дата инженеру просто потому что перед глазами не 1 проект в котором я устроен, а 15-20 проектов заказчиков облака, с которыми я взаимодействую.
Второе. Бонусы у меня и правда есть, они и правда неплохие. Но привязаны они к перформансу моего продукта на рынке. Я кровно завишу от того, насколько интересно людям то что я говорю и насколько работают технологии, которые я предлагаю. Работают и приносят пользу - см. п.1 - в рядовом российском энтерпрайзе.
Третье - про обвинение в «воровстве» чье-то кода. Накатик в том, что я сделал демонстрационный репозиторий не с нуля, а на основе другого открытого. И если бы я скопипастил код без указания на авторский, это было бы воровство. Если бы я взял без спроса платный лицензируемый продукт, это было бы воровство. А когда ты берешь открытое произведение, указываешь автора, дополняешь своими соображениями и также выкладываешь в общий доступ - это нормальные опен-сорсные практики. Если поверх любого моего репо кто-то сделает что-то себе полезное, я только порадуюсь, и уверен, что автор оригинала тоже.
Расшифрую: если видишь кроме надписи forked рядышком также надпись This branch is N commit ahead of, это означает, что предлагаемое содержит дополнения по сравнению с. К примеру, в оригинале сборка не устанавливается на чистую систему и требует пререквизитов, в моей сборке - ставится. Есть расхардкоженные пароли, унесенные в зону вне репо и тд. Это все не инженерный мастерпис, но это экономит время и понижает порог входа в сборку. Если мы с командой сэкономили 30 минут каждому, кто попытается использовать сборку по назначению, считаю, что дополнения сделаны и выложены не зря. По факту уже сейчас воспользовались 50+ человек, те, о которых знаю.
Авторам пасквилей рекомендую обсудить что-то более духовное, чем чужой кошелек, когда в следующий раз они «соберутся на яхте». И заняться чем-то более полезным, чем распространение клеветы в адрес малознакомых людей.
Ссылка на филиппику - в первом комменте
P.S. Картинку в посте я тоже у Ильи Репина украл.
На днях подписчик прислал ссылку на пост в жанре площадной филиппики в мой адрес.
В целом мне приятно, что малознакомые люди, собравшись в кружок вечером в субботу, обсуждают меня. Пусть даже предметом являются мой кошелек, мои бонусы и сильно искаженная версия трудовой биографии. Видимо, так и приходит «известность».
На пару тезисов, тем не менее, отвечу.
Первое. Я не являюсь энтерпрайз архитектором в жанре «рисую стрелочки, дорого». Я не имею отношения к архитектуре ВК, где соцсети, почта, реклама. Я работаю с заказчиками ВК Облака, типичный мой заказчик - медиум и крупный российский бизнес. Те, кто размещают инфрастуктуру данных в облаке на IaaS, SaaS, PaaS или думают об этом. В реалиях рынка мне открыто сильно больше, чем типовому дата инженеру просто потому что перед глазами не 1 проект в котором я устроен, а 15-20 проектов заказчиков облака, с которыми я взаимодействую.
Второе. Бонусы у меня и правда есть, они и правда неплохие. Но привязаны они к перформансу моего продукта на рынке. Я кровно завишу от того, насколько интересно людям то что я говорю и насколько работают технологии, которые я предлагаю. Работают и приносят пользу - см. п.1 - в рядовом российском энтерпрайзе.
Третье - про обвинение в «воровстве» чье-то кода. Накатик в том, что я сделал демонстрационный репозиторий не с нуля, а на основе другого открытого. И если бы я скопипастил код без указания на авторский, это было бы воровство. Если бы я взял без спроса платный лицензируемый продукт, это было бы воровство. А когда ты берешь открытое произведение, указываешь автора, дополняешь своими соображениями и также выкладываешь в общий доступ - это нормальные опен-сорсные практики. Если поверх любого моего репо кто-то сделает что-то себе полезное, я только порадуюсь, и уверен, что автор оригинала тоже.
Расшифрую: если видишь кроме надписи forked рядышком также надпись This branch is N commit ahead of, это означает, что предлагаемое содержит дополнения по сравнению с. К примеру, в оригинале сборка не устанавливается на чистую систему и требует пререквизитов, в моей сборке - ставится. Есть расхардкоженные пароли, унесенные в зону вне репо и тд. Это все не инженерный мастерпис, но это экономит время и понижает порог входа в сборку. Если мы с командой сэкономили 30 минут каждому, кто попытается использовать сборку по назначению, считаю, что дополнения сделаны и выложены не зря. По факту уже сейчас воспользовались 50+ человек, те, о которых знаю.
Авторам пасквилей рекомендую обсудить что-то более духовное, чем чужой кошелек, когда в следующий раз они «соберутся на яхте». И заняться чем-то более полезным, чем распространение клеветы в адрес малознакомых людей.
Ссылка на филиппику - в первом комменте
P.S. Картинку в посте я тоже у Ильи Репина украл.
👍15😁15❤6👏3
Peace
Что ж, рад что мы во всем разобрались. Явную клевету убрали (хотя интернет помнит все), с Димой (@rockyourdata) мы объяснились. Что ж, кто не устранял последствия разгульных вечеринок, тот не жил и не дышал 🫢
Спасибо всем, кто оказал поддержку! Очень приятно знать, что вокруг люди, готовые помочь и словом и делом. Неимоверно вас ценю.
Теперь peace и архитектура
Что ж, рад что мы во всем разобрались. Явную клевету убрали (хотя интернет помнит все), с Димой (@rockyourdata) мы объяснились. Что ж, кто не устранял последствия разгульных вечеринок, тот не жил и не дышал 🫢
Спасибо всем, кто оказал поддержку! Очень приятно знать, что вокруг люди, готовые помочь и словом и делом. Неимоверно вас ценю.
Теперь peace и архитектура
❤16👍8
Forwarded from Mikhail Tokovinin
Предприниматель в 2026-ом
Логично в последний рабочий день 25-го подумать о том, как мы будем жить в грядущем 26-ом. Жить будем сложно, но весело. Гарантировано.
Степень неопределенности зашкаливает. Что будет с СВО? Что с санкциями? Как малый бизнес переживет новые налоги (и переживет ли)? Какая будет инфляция? Какая будет ставка? Что будет с авторынком при такой ставке и утиле? Добьют ли карго? А курс? Какой будет курс? А тут еще и WhatsApp забанили, и непонятно, где будет трафик и в какой канал инвестировать? А тут еще ИИ и ИИ-пузырь.
Всё это превращает бизнес в 26-ом немного в лотерею.
И что делать? Кто-то начнет рассказывать байки про некую «антихрупкость», а я скажу проще: маржа! У кого будет маржа, тот и выживет. В 26-ом нужно быть максимально маржинальными.
Режьте косты «не дожидаясь перитонита». Все эти прожекты, т.н. инвестиции и прочие фантазии - всё надо резать - сокращать расходы, ради сокращения расходов. Да, это порождает порочную спираль, ведь ваши расходы - это чьи-то доходы, а значит, если все начнут резать расходы, то у всех упадут и доходы. Но в бизнесе иногда не проблема «умереть», главное - «умереть последним».
Но как же будущее? А что потом? А вдруг мы пропустим рост?
Братцы, в России выживают пессимисты. Так что готовимся к худшему, надеемся на лучшее.
Логично в последний рабочий день 25-го подумать о том, как мы будем жить в грядущем 26-ом. Жить будем сложно, но весело. Гарантировано.
Степень неопределенности зашкаливает. Что будет с СВО? Что с санкциями? Как малый бизнес переживет новые налоги (и переживет ли)? Какая будет инфляция? Какая будет ставка? Что будет с авторынком при такой ставке и утиле? Добьют ли карго? А курс? Какой будет курс? А тут еще и WhatsApp забанили, и непонятно, где будет трафик и в какой канал инвестировать? А тут еще ИИ и ИИ-пузырь.
Всё это превращает бизнес в 26-ом немного в лотерею.
И что делать? Кто-то начнет рассказывать байки про некую «антихрупкость», а я скажу проще: маржа! У кого будет маржа, тот и выживет. В 26-ом нужно быть максимально маржинальными.
Режьте косты «не дожидаясь перитонита». Все эти прожекты, т.н. инвестиции и прочие фантазии - всё надо резать - сокращать расходы, ради сокращения расходов. Да, это порождает порочную спираль, ведь ваши расходы - это чьи-то доходы, а значит, если все начнут резать расходы, то у всех упадут и доходы. Но в бизнесе иногда не проблема «умереть», главное - «умереть последним».
Но как же будущее? А что потом? А вдруг мы пропустим рост?
Братцы, в России выживают пессимисты. Так что готовимся к худшему, надеемся на лучшее.
👍1
Mikhail Tokovinin
Предприниматель в 2026-ом Логично в последний рабочий день 25-го подумать о том, как мы будем жить в грядущем 26-ом. Жить будем сложно, но весело. Гарантировано. Степень неопределенности зашкаливает. Что будет с СВО? Что с санкциями? Как малый бизнес переживет…
Давно хотел запостить.
Это взгляд крупного бизнеса на 2026-й. Режем, откладываем, ужимаемся. Прожить год, потом инвестиции. В России выживают пессимисты.
Если вы торгуете любым инвестиционным товаром - поздравляю, у вас трудности. Привет платформам данных и ИИ.
Учитесь операционализировать свои предложения, говорить про пользу здесь и прямо сейчас, а не когда-то через год.
Ну и начинайте с малого, растите доверие у заказчика, пока все сидят на заборе со своими огромными капексными коробками и ждут хороших лет.
Это взгляд крупного бизнеса на 2026-й. Режем, откладываем, ужимаемся. Прожить год, потом инвестиции. В России выживают пессимисты.
Если вы торгуете любым инвестиционным товаром - поздравляю, у вас трудности. Привет платформам данных и ИИ.
Учитесь операционализировать свои предложения, говорить про пользу здесь и прямо сейчас, а не когда-то через год.
Ну и начинайте с малого, растите доверие у заказчика, пока все сидят на заборе со своими огромными капексными коробками и ждут хороших лет.
Telegram
Архитектор Данных
Философское - облако и разделение труда (4)
В начало цикла - Части 1-3
Как добиться роста кооперации.
Рост выгоден всем. Компаниям, государству, специалистам.
Если вы владелец или топ-менеджер платформы или сервиса, подумайте, как сделать, чтобы ваши…
В начало цикла - Части 1-3
Как добиться роста кооперации.
Рост выгоден всем. Компаниям, государству, специалистам.
Если вы владелец или топ-менеджер платформы или сервиса, подумайте, как сделать, чтобы ваши…
Так выглядит снапшот Айсберга. И какой это кладезь метаданных!
Тут есть
• когда изменились данные
• что именно произошло в этом изменении: аппенд 9 дата-паркетов.
• Какое состояние таблицы: записей, число дата-файлов всех видов
• через какой движок: Трино версия 468, библиотека Айсберг 1.7
• какой юзер это сделал
• какой айди запроса в точности
Через 2 дня это будет зачищено, но до того доступно для любых DG / Sec Audit тулов!
Тут есть
• когда изменились данные
• что именно произошло в этом изменении: аппенд 9 дата-паркетов.
• Какое состояние таблицы: записей, число дата-файлов всех видов
• через какой движок: Трино версия 468, библиотека Айсберг 1.7
• какой юзер это сделал
• какой айди запроса в точности
Через 2 дня это будет зачищено, но до того доступно для любых DG / Sec Audit тулов!
❤10👍5
Forwarded from дата инженеретта
Худшие фейлы в DE
Наткнулась на тред в реддите, где обсуждались фейлы на работе. Мне больше всего зашли 2 истории, они такие смешные и страшные одновременно🤯
1️⃣ Стриминг писал в то же самое место, откуда и читал. Это все длилось год, поэтому накопилось сотни триллионов миллиардов версий документов. Проблема обнаружилась, только когда к ним пришел AWS и пожаловался на проблемы в своих системах
Неужели за этот год они не заметили, как эти пайплайны работают все медленнее и медленнее, почему такая высокая нагрузка и что в таблицах кучи дублей?
2️⃣ DE понизил уровень логирования до DEBUG, и это привело к расходам в 100к долларов за неделю
Кажется, теперь я знаю способ, как можно уменьшить расходы компании. Ничего не логировать😁
💰 Мы сейчас тоже переходим в эру FinOps. Будем пугать аналитиков, чтобы писали оптимальные запросы 😁
А у вас было что-то супер серьезное?
Ссылка на тред
@data_engineerette
Наткнулась на тред в реддите, где обсуждались фейлы на работе. Мне больше всего зашли 2 истории, они такие смешные и страшные одновременно
Неужели за этот год они не заметили, как эти пайплайны работают все медленнее и медленнее, почему такая высокая нагрузка и что в таблицах кучи дублей?
Кажется, теперь я знаю способ, как можно уменьшить расходы компании. Ничего не логировать
А у вас было что-то супер серьезное?
Ссылка на тред
@data_engineerette
Please open Telegram to view this post
VIEW IN TELEGRAM
Reddit
From the dataengineering community on Reddit
Explore this post and more from the dataengineering community
👍8😭4
дата инженеретта
Худшие фейлы в DE Наткнулась на тред в реддите, где обсуждались фейлы на работе. Мне больше всего зашли 2 истории, они такие смешные и страшные одновременно🤯 1️⃣ Стриминг писал в то же самое место, откуда и читал. Это все длилось год, поэтому накопилось сотни…
Поставить на автоскейл нечто, что самопроизвольно грузится от скейла.
Ммм, классика
Ммм, классика
👌7😁4❤2