Управляемость - это не только про потоки железа и денег. Это про потоки данных.
https://t.iss.one/TheDigitalTwin/175
Коллеги, всех приветствую! Прочитал важный пост Сергея о возврате управляемости через контроль материальных и финансовых потоков. Согласен на 100%, что без этого «фундамента» все разговоры о развитии повисают в воздухе.
Но хочу предложить взгляд в развитие этой мысли, который, как мне кажется, критически важен именно сегодня.
Проблема не только в том, что мы плохо управляем станками и деньгами. Проблема в том, что мы плохо управляем информацией об этих станках и деньгах.
Представьте, что вы управляете сложным механизмом с завязанными глазами. Вам говорят: «Вот рычаги! Деньги! Материалы! Держи под контролем!». Но вы не видите, что на самом деле происходит внутри. Нет точных, своевременных и связанных между собой данных.
Так и у нас:
· Мы не можем построить «оптимальные программы», потому что не видим полной картины в реальном времени: какие мощности реально загружены, какие материалы в пути, какие компетенции есть у людей.
· Мы не можем «согласовать развитие отраслей и территорий», потому что данные из одного муниципалитета не стыкуются с данными из региона, а данные из министерства - с данными с конкретного завода. Каждый говорит на своем «языке данных».
Сергей прав - нам нужен путь сильного руководства и стратегической дисциплины, как в Сингапуре или Китае. Но давайте посмотрим, как они этого добиваются сегодня? Через тотальную цифровизацию и создание единого контура управления данными.
Данные - это новый стратегический актив, такой же важный, как нефть или металл.
Поэтому я бы развил мысль коллеги так:
Вернуть управляемость можно, только взяв под контроль ДВЕ вещи одновременно:
1. Материальные и финансовые потоки (о чем справедливо говорит Сергей).
2. Потоки данных, которые эти материальные потоки описывают.
Без второго первый контроль будет всегда запаздывающим, неточным и фрагментарным.
В моем понимании на практике это меняет следующее:
· Вместо «либерализации» или жесткого администрирования «вслепую» - мы получаем цифровое планирование. Моделируем решения на основе данных, а не только на основе интуиции или отчетов месячной давности.
· Производственно-инвестиционные программы становятся не просто планами, а живыми цифровыми двойниками отраслей и территорий, где можно отслеживать выполнение в реальном времени.
· Согласование развития происходит через единые стандарты данных и платформы, где все участники - от федерации до завода - общаются на одном языке.
Это не отменяет сильное руководство. Наоборот, это дает ему самый мощный инструмент XXI века - единую, достоверную картину происходящего для принятия решений.
Коллеги, как вам такая постановка вопроса? Возможно, я что-то упускаю? Готов обсудить в комментариях.👇
https://t.iss.one/TheDigitalTwin/175
Коллеги, всех приветствую! Прочитал важный пост Сергея о возврате управляемости через контроль материальных и финансовых потоков. Согласен на 100%, что без этого «фундамента» все разговоры о развитии повисают в воздухе.
Но хочу предложить взгляд в развитие этой мысли, который, как мне кажется, критически важен именно сегодня.
Проблема не только в том, что мы плохо управляем станками и деньгами. Проблема в том, что мы плохо управляем информацией об этих станках и деньгах.
Представьте, что вы управляете сложным механизмом с завязанными глазами. Вам говорят: «Вот рычаги! Деньги! Материалы! Держи под контролем!». Но вы не видите, что на самом деле происходит внутри. Нет точных, своевременных и связанных между собой данных.
Так и у нас:
· Мы не можем построить «оптимальные программы», потому что не видим полной картины в реальном времени: какие мощности реально загружены, какие материалы в пути, какие компетенции есть у людей.
· Мы не можем «согласовать развитие отраслей и территорий», потому что данные из одного муниципалитета не стыкуются с данными из региона, а данные из министерства - с данными с конкретного завода. Каждый говорит на своем «языке данных».
Сергей прав - нам нужен путь сильного руководства и стратегической дисциплины, как в Сингапуре или Китае. Но давайте посмотрим, как они этого добиваются сегодня? Через тотальную цифровизацию и создание единого контура управления данными.
Данные - это новый стратегический актив, такой же важный, как нефть или металл.
Поэтому я бы развил мысль коллеги так:
Вернуть управляемость можно, только взяв под контроль ДВЕ вещи одновременно:
1. Материальные и финансовые потоки (о чем справедливо говорит Сергей).
2. Потоки данных, которые эти материальные потоки описывают.
Без второго первый контроль будет всегда запаздывающим, неточным и фрагментарным.
В моем понимании на практике это меняет следующее:
· Вместо «либерализации» или жесткого администрирования «вслепую» - мы получаем цифровое планирование. Моделируем решения на основе данных, а не только на основе интуиции или отчетов месячной давности.
· Производственно-инвестиционные программы становятся не просто планами, а живыми цифровыми двойниками отраслей и территорий, где можно отслеживать выполнение в реальном времени.
· Согласование развития происходит через единые стандарты данных и платформы, где все участники - от федерации до завода - общаются на одном языке.
Это не отменяет сильное руководство. Наоборот, это дает ему самый мощный инструмент XXI века - единую, достоверную картину происходящего для принятия решений.
Коллеги, как вам такая постановка вопроса? Возможно, я что-то упускаю? Готов обсудить в комментариях.👇
Telegram
DigitalTwin. Цифровой Двойник
Возврат управляемости системой
Единственный способ вернуть управляемость в социально-экономическом развитии — это взять под контроль движение материальных и финансовых потоков в реальном секторе, в состоянии производительных сил.
Без этого невозможно выстроить…
Единственный способ вернуть управляемость в социально-экономическом развитии — это взять под контроль движение материальных и финансовых потоков в реальном секторе, в состоянии производительных сил.
Без этого невозможно выстроить…
👍3💯1
Анализ эволюции рынка данных: от «пробивов» к государственно-корпоративным экосистемам.
Коллеги, приветствую.
В контексте последних законодательных инициатив и уголовных дел против сервисов по «пробиву» данных провел комплексный анализ этой отрасли деятельности. Меня, как специалиста по управлению корпоративными данными, интересует трансформация рынка с технологической и архитектурной точек зрения, а также последствия этой трансформации для бизнеса.
Результатами делюсь ниже.
Два мира российского рынка данных:
Исторически рынок нелегального и полулегального доступа к данным в России делился на два сегмента: B2C (массовые сервисы вроде «Глаза Бога») и B2B (закрытые системы для профессионалов). Именно B2B-сегмент представляет наибольший интерес, так как он демонстрирует эволюцию от примитивных баз к сложным аналитическим платформам, тесно интегрированным с государственным аппаратом.
Архитектура российского рынка - технологии и игроки:
Чтобы наглядно представить структуру рынка, я выстроил его архитектурную модель. Ее можно описать как многоуровневую экосистему. (Представлена в схеме)
На верхнем уровне находятся государственные заказчики и регуляторы (ФСБ, МВД, Роскомнадзор). Именно их потребности в контроле и анализе формируют спрос.
Ключевым технологическим звеном, обеспечивающим сбор первичных данных, является система СОРМ. Это «черные ящики», установленные у всех операторов связи, которые в режиме реального времени фиксируют метаданные интернет-трафика и передают их в силовые ведомства. Важно понимать, что современные протоколы шифрования (HTTPS) и анонимизаторы (VPN, Tor) ограничивают возможности СОРМ по перехвату содержимого, но не метаданных.
Следующий уровень - поставщики решений и данных. Здесь мы видим две ключевые группы:
Разработчики инфраструктурного ПО. Компании вроде «Норси-Транс», которые не только поставляют сами системы СОРМ государству, но и на их базе создают коммерческие аналитические продукты. Яркий пример - ОСINT-платформа «Виток», способная проводить анонимный поиск по десяткам идентификаторов (от паспорта до Bitcoin-кошелька) и работавшая по контракту с ГИАЦ МВД.
Операторы информационных систем. Такие компании, как Cronos, предлагают готовые оболочки и базы данных для проверки граждан и компаний. Их технологии часто архаичны, но бизнес-модель живуча благодаря связям с силовыми структурами и глубокой интеграции в профессиональную среду.
Потребителями этой архитектуры являются конечные B2B-клиенты: безопасники частных компаний, банки, коллекторы. B2C-сегмент, будучи вытесненным на нелегальное положение, становится все менее значимым.
Глобальный контекст - три модели регулирования:
Российский путь не уникален, но представляет собой гибридную модель.
В Евросоюзе доминирует регуляторный подход (GDPR). Акцент сделан на защите прав человека, а работа с данными строится вокруг легальных платформ управления данными, таких как Collibra (Data Governance) и Informatica (качество данных). Сбор и анализ строго регламентированы и требуют явного согласия субъекта.
США практикуют рыночно-ориентированную модель. Данные - это в первую очередь товар. Здесь созданы и получили широкое распространение мощные аналитические платформы, такие как Palantir Gotham для силовых структур и Snowflake для корпоративного сектора. Контроль точечный, но крайне жесткий в сферах национальной безопасности и коммерческой тайны.
Китай представляет этатистскую модель тотального контроля. Граница между персональными и государственными данными размыта. Технологии социального рейтинга, распознавания лиц и интеграции данных (например, на платформах Alibaba Cloud и Tencent) служат одной цели - управлению обществом. Аналоги СОРМ являются естественной и неотъемлемой частью цифровой инфраструктуры.
Российская модель, как видно из анализа, движется в сторону китайской, но с критически важными отличиями: отсутствием столь же мощных собственных stack-решений и сохранением элементов «дикого» рынка.
Экспертное резюме для корпоративного управления
Эпоха «диких» данных окончена.
#Аналитика@data_capital
Коллеги, приветствую.
В контексте последних законодательных инициатив и уголовных дел против сервисов по «пробиву» данных провел комплексный анализ этой отрасли деятельности. Меня, как специалиста по управлению корпоративными данными, интересует трансформация рынка с технологической и архитектурной точек зрения, а также последствия этой трансформации для бизнеса.
Результатами делюсь ниже.
Два мира российского рынка данных:
Исторически рынок нелегального и полулегального доступа к данным в России делился на два сегмента: B2C (массовые сервисы вроде «Глаза Бога») и B2B (закрытые системы для профессионалов). Именно B2B-сегмент представляет наибольший интерес, так как он демонстрирует эволюцию от примитивных баз к сложным аналитическим платформам, тесно интегрированным с государственным аппаратом.
Архитектура российского рынка - технологии и игроки:
Чтобы наглядно представить структуру рынка, я выстроил его архитектурную модель. Ее можно описать как многоуровневую экосистему. (Представлена в схеме)
На верхнем уровне находятся государственные заказчики и регуляторы (ФСБ, МВД, Роскомнадзор). Именно их потребности в контроле и анализе формируют спрос.
Ключевым технологическим звеном, обеспечивающим сбор первичных данных, является система СОРМ. Это «черные ящики», установленные у всех операторов связи, которые в режиме реального времени фиксируют метаданные интернет-трафика и передают их в силовые ведомства. Важно понимать, что современные протоколы шифрования (HTTPS) и анонимизаторы (VPN, Tor) ограничивают возможности СОРМ по перехвату содержимого, но не метаданных.
Следующий уровень - поставщики решений и данных. Здесь мы видим две ключевые группы:
Разработчики инфраструктурного ПО. Компании вроде «Норси-Транс», которые не только поставляют сами системы СОРМ государству, но и на их базе создают коммерческие аналитические продукты. Яркий пример - ОСINT-платформа «Виток», способная проводить анонимный поиск по десяткам идентификаторов (от паспорта до Bitcoin-кошелька) и работавшая по контракту с ГИАЦ МВД.
Операторы информационных систем. Такие компании, как Cronos, предлагают готовые оболочки и базы данных для проверки граждан и компаний. Их технологии часто архаичны, но бизнес-модель живуча благодаря связям с силовыми структурами и глубокой интеграции в профессиональную среду.
Потребителями этой архитектуры являются конечные B2B-клиенты: безопасники частных компаний, банки, коллекторы. B2C-сегмент, будучи вытесненным на нелегальное положение, становится все менее значимым.
Глобальный контекст - три модели регулирования:
Российский путь не уникален, но представляет собой гибридную модель.
В Евросоюзе доминирует регуляторный подход (GDPR). Акцент сделан на защите прав человека, а работа с данными строится вокруг легальных платформ управления данными, таких как Collibra (Data Governance) и Informatica (качество данных). Сбор и анализ строго регламентированы и требуют явного согласия субъекта.
США практикуют рыночно-ориентированную модель. Данные - это в первую очередь товар. Здесь созданы и получили широкое распространение мощные аналитические платформы, такие как Palantir Gotham для силовых структур и Snowflake для корпоративного сектора. Контроль точечный, но крайне жесткий в сферах национальной безопасности и коммерческой тайны.
Китай представляет этатистскую модель тотального контроля. Граница между персональными и государственными данными размыта. Технологии социального рейтинга, распознавания лиц и интеграции данных (например, на платформах Alibaba Cloud и Tencent) служат одной цели - управлению обществом. Аналоги СОРМ являются естественной и неотъемлемой частью цифровой инфраструктуры.
Российская модель, как видно из анализа, движется в сторону китайской, но с критически важными отличиями: отсутствием столь же мощных собственных stack-решений и сохранением элементов «дикого» рынка.
Экспертное резюме для корпоративного управления
Эпоха «диких» данных окончена.
#Аналитика@data_capital
👍2
Использование нелегальных «пробивных» сервисов несет неприемлемые репутационные и уголовные риски. Качество данных в них низкое, происхождение - непрозрачное.
Будущее - за легальными платформами. Корпоративному сектору необходимо инвестировать в построение легальных активов данных на базе MDM-систем (например, Ataccama ONE, Talend), платформ Data Governance и платформ Дата Каталогов синхронизированных с BPM решениями. Это создает цифровой золотой фонд компании, в котором компания объективно работает, а не собирает информационный мусор.
Цифровая гигиена становится KPI. С введением ответственности за «потребление контента» корпоративная политика информационной безопасности должна быть пересмотрена. Риск сотрудника, использующего рабочее устройство и трафик для доступа к сомнительным ресурсам, становится прямым риском компании, при этом заблокировать сотрудника от взаимодействия с внешними информационными ресурсами тоже недопустимая "роскошь".
Итог: Рынок проходит этап санации и государственной консолидации. Нашим компаниям пора проводить аналогичную «санацию» внутри, отказываясь от серых схем в пользу построения прозрачных, качественных и легальных активов данных.
Далее представлена графическая схема в нотации ArchiMate, визуализирующая описанную выше архитектурную модель: уровень государственных заказчиков, уровень СОРМ, уровень поставщиков решений (ПО/данные) и уровень потребителей (B2B/B2C).
Буду рад обсуждению в комментариях.👇
#Аналитика@data_capital
Будущее - за легальными платформами. Корпоративному сектору необходимо инвестировать в построение легальных активов данных на базе MDM-систем (например, Ataccama ONE, Talend), платформ Data Governance и платформ Дата Каталогов синхронизированных с BPM решениями. Это создает цифровой золотой фонд компании, в котором компания объективно работает, а не собирает информационный мусор.
Цифровая гигиена становится KPI. С введением ответственности за «потребление контента» корпоративная политика информационной безопасности должна быть пересмотрена. Риск сотрудника, использующего рабочее устройство и трафик для доступа к сомнительным ресурсам, становится прямым риском компании, при этом заблокировать сотрудника от взаимодействия с внешними информационными ресурсами тоже недопустимая "роскошь".
Итог: Рынок проходит этап санации и государственной консолидации. Нашим компаниям пора проводить аналогичную «санацию» внутри, отказываясь от серых схем в пользу построения прозрачных, качественных и легальных активов данных.
Далее представлена графическая схема в нотации ArchiMate, визуализирующая описанную выше архитектурную модель: уровень государственных заказчиков, уровень СОРМ, уровень поставщиков решений (ПО/данные) и уровень потребителей (B2B/B2C).
Буду рад обсуждению в комментариях.👇
#Аналитика@data_capital
👍1
Схема в нотации ArchiMate, визуализирующая описанную выше архитектурную модель: уровень государственных заказчиков, уровень СОРМ, уровень поставщиков решений (ПО/данные) и уровень потребителей (B2B/B2C).
#Аналитика@data_capital
#Аналитика@data_capital
👍1
От хаоса к антихаосу: как приручить цифровой бардак
Бывает, от вороха таблиц, чатов и отчетов голова идёт кругом? Это и есть Хаос Данных - прямой наследник той самой зияющей бездны, из которой, по легендам Античного мира, родился мир. Ваша папка «Загрузки» - тому подтверждение 😉
Но природа подсказывает выход: Антихаос. Это не идеальный порядок, а состояние, когда внутри бардака рождаются ясные структуры.
Мое мнение: наш путь с данными - это эволюция от паники к осмысленности.
Стадия 1: Хаос как стресс
Мы тонем в потоке разных данные и информации. Если вы чувствуете себя не в своей тарелке - это нормально! Просто включите осознанность: Хаос - не приговор, а естественная стадия начала роста. Просто отправная точка «А» на карте.
Стадия 2: Антихаос как прорыв
Здесь мы перестаем быть жертвой и задаём системе один мощный вопрос: «Что я хочу понять или решить прямо сейчас?»
Найдя ответ, вы создаете «вихрь» ясности:
• Единую систему для паролей
• Автоотчет, экономящий часы
• Чек-лист ежедневных приоритетов
• и многое другое)
Вы не строите стену против океана данных - вы учитесь ставить паруса и ловить его ветер. Данных не становится меньше, но они начинают работать на вас.
Итог: Не нужно раскладывать всю жизнь по полочкам. Достаточно научиться танцевать среди творческого беспорядка, точно зная, где ваш главный инструмент.
Сначала был Хаос. Потом появились вы. И станет возможным всё.
Выходные впереди, есть время подумать 😉
Ваше мнение важно 👇
Бывает, от вороха таблиц, чатов и отчетов голова идёт кругом? Это и есть Хаос Данных - прямой наследник той самой зияющей бездны, из которой, по легендам Античного мира, родился мир. Ваша папка «Загрузки» - тому подтверждение 😉
Но природа подсказывает выход: Антихаос. Это не идеальный порядок, а состояние, когда внутри бардака рождаются ясные структуры.
Мое мнение: наш путь с данными - это эволюция от паники к осмысленности.
Стадия 1: Хаос как стресс
Мы тонем в потоке разных данные и информации. Если вы чувствуете себя не в своей тарелке - это нормально! Просто включите осознанность: Хаос - не приговор, а естественная стадия начала роста. Просто отправная точка «А» на карте.
Стадия 2: Антихаос как прорыв
Здесь мы перестаем быть жертвой и задаём системе один мощный вопрос: «Что я хочу понять или решить прямо сейчас?»
Найдя ответ, вы создаете «вихрь» ясности:
• Единую систему для паролей
• Автоотчет, экономящий часы
• Чек-лист ежедневных приоритетов
• и многое другое)
Вы не строите стену против океана данных - вы учитесь ставить паруса и ловить его ветер. Данных не становится меньше, но они начинают работать на вас.
Итог: Не нужно раскладывать всю жизнь по полочкам. Достаточно научиться танцевать среди творческого беспорядка, точно зная, где ваш главный инструмент.
Сначала был Хаос. Потом появились вы. И станет возможным всё.
Выходные впереди, есть время подумать 😉
Ваше мнение важно 👇
👍1
Разговор с главным механиком. Что на самом деле нужно производству
На днях состоялся сложный и очень честный разговор с одним из ключевых руководителей горнодобывающего предприятия. Это всегда самый важный диалог. Он отсекает всю шелуху и показывает истинную ценность данных для бизнеса.
Ему не интересны ИТ «системы» и ИТ «технологии». Его интересует одно: надежность.
Когда оборудование или экскаватор стоит - это его боль. Когда нет нужной запчасти - это его проблема. Когда механик, снабженец и бухгалтер называют одну деталь по-разному или приобретают за кратно разную сумму - это его ежедневный стресс.
И вот главный вывод, который я еще раз для себя подтвердил:
Проекты со справочниками материалов или номенклатуры предприятия, это не про ИТ, это строго бизнес-проекты по повышению надежности предприятия.
Как это работает и в чем ценность?
1. Создаем один язык. Мы сажаем за один стол снабжение, бухгалтерию и производство и договариваемся, как называть вещи. Это кажется банальным, но именно эта «банальность» - основа порядка. Больше никаких «у нас так, а у них по-другому».
2. Превращаем хаос в стандарт. Четкие стандарты описания оборудования и его характеристик - это не бюрократия. Это возможность, наконец, собирать статистику, понимать, какое оборудование работает дольше, а какое ломается чаще, и планировать ремонты до того, как все остановилось.
3. Даем инструмент для управления, а не для тушения пожаров. Когда у руководителя есть ясная и единая картина по всем материалам и запчастям, он начинает не экстренно закупать, а упреждающе управлять ресурсами. Он видит неликвиды, оптимизирует складские запасы и точно знает, что заказывать.
Что бизнес получает в итоге?
Не «внедренную очередную ИТ систему», а сервисы, которые напрямую влияют на эффективность:
· Сервис точного подбора аналогов, особенно критично с уходом западных вендоров.
· Сервис управления лимитами и ремонтами, когда бюджет планируется под конкретные задачи, а не «в слепую».
· Сервис быстрого поиска и идентификации любой позиции на складе, экономящий часы рабочего времени.
После таких разговоров не остается сомнений: мы движемся в правильном направлении. Мы строим не IT-инфраструктуру, а фундамент для устойчивого и предсказуемого бизнеса. И это та ценность, которую по-настоящему понимает любой сильный руководитель.
Хотите поделиться своими историями или мнениями? Пишите в комментариях 👇
#Истории@data_capital
На днях состоялся сложный и очень честный разговор с одним из ключевых руководителей горнодобывающего предприятия. Это всегда самый важный диалог. Он отсекает всю шелуху и показывает истинную ценность данных для бизнеса.
Ему не интересны ИТ «системы» и ИТ «технологии». Его интересует одно: надежность.
Когда оборудование или экскаватор стоит - это его боль. Когда нет нужной запчасти - это его проблема. Когда механик, снабженец и бухгалтер называют одну деталь по-разному или приобретают за кратно разную сумму - это его ежедневный стресс.
И вот главный вывод, который я еще раз для себя подтвердил:
Проекты со справочниками материалов или номенклатуры предприятия, это не про ИТ, это строго бизнес-проекты по повышению надежности предприятия.
Как это работает и в чем ценность?
1. Создаем один язык. Мы сажаем за один стол снабжение, бухгалтерию и производство и договариваемся, как называть вещи. Это кажется банальным, но именно эта «банальность» - основа порядка. Больше никаких «у нас так, а у них по-другому».
2. Превращаем хаос в стандарт. Четкие стандарты описания оборудования и его характеристик - это не бюрократия. Это возможность, наконец, собирать статистику, понимать, какое оборудование работает дольше, а какое ломается чаще, и планировать ремонты до того, как все остановилось.
3. Даем инструмент для управления, а не для тушения пожаров. Когда у руководителя есть ясная и единая картина по всем материалам и запчастям, он начинает не экстренно закупать, а упреждающе управлять ресурсами. Он видит неликвиды, оптимизирует складские запасы и точно знает, что заказывать.
Что бизнес получает в итоге?
Не «внедренную очередную ИТ систему», а сервисы, которые напрямую влияют на эффективность:
· Сервис точного подбора аналогов, особенно критично с уходом западных вендоров.
· Сервис управления лимитами и ремонтами, когда бюджет планируется под конкретные задачи, а не «в слепую».
· Сервис быстрого поиска и идентификации любой позиции на складе, экономящий часы рабочего времени.
После таких разговоров не остается сомнений: мы движемся в правильном направлении. Мы строим не IT-инфраструктуру, а фундамент для устойчивого и предсказуемого бизнеса. И это та ценность, которую по-настоящему понимает любой сильный руководитель.
Хотите поделиться своими историями или мнениями? Пишите в комментариях 👇
#Истории@data_capital
👍6
Кризис доступности данных - почему ИБ и разработка воюют, а бизнес теряет деньги?
Коллеги, на днях наблюдал в одном рабочем чате жаркую дискуссию. Разработчики спрашивали у ИБ: «Можно ли использовать Python или актуальный C#?». Ответы были в стиле: «ИБ не запрещает языки… но если найдем неразрешенное ПО на сервере - пишите объяснительную».
Думаю, это знакомая ситуация, это не просто спор, это системный кризис доступности данных.
В чем суть кризиса? Компания платит за дорогих специалистов, закупает лицензии, но работа стоит на месте.
В чем проблема? Данные заблокированы устаревшими правилами, которые путают среду разработки (dev/test) с продакшеном.
Почему инструменты недоступны? Чтобы получить нужную библиотеку или фреймворк, нужно пройти десятки согласований. Пока их согласуют - бизнес-возможность ушла, возникли другие задачи и начинаем сначала круг согласований.
Почему мы живем в культуре запретов? Вместо управления рисками данных - запрет инструментов. Notepad++ становится «врагом безопасности», хотя проблема не в нем.
Что происходит на самом деле? Мы защищаем не то. Защищать нужно данные, а не программы. Python, C#, ИИ-модели - это просто инструменты. Бессмысленно запрещать инструмент, нужно научиться безопасно им пользоваться.
Пока ИБ контролирует «железо» и софт, а разработка не может работать, данные, наш главный капитал и ценность, лежат мёртвым грузом и "тухнут". Бизнес не получает ценность, компания теряет конкурентоспособность, время и деньги.
Целевое решение, которое следует рассмотреть, это переход от управления доступом к управляемой доступности.
Выход из кризисной ситуации заключается в смене парадигмы. Вот примерный рабочий план для крупных компаний:
Создать «Безопасный магазин/сервис решений». Единый внутренний портал, где ИБ заранее проверит и одобрит версии Python, библиотек, контейнеров, а разработчик, в свою очередь, как и продвинутый пользователь для изучения и тестирования, берет нужное в один клик, без писем и ожидания. Это снимает 80% конфликтов, это экономит недели и месяцы согласования и освоение новых технологий.
Нужно четко разделить "миры". Мир разработки (dev/test) - это полигон с тестовыми данными. Правила здесь должны быть гибкими, чтобы можно было экспериментировать. Мир продакшена - это святая святых с живыми данными, и тут контроль строгий. Риски разные, подход разный.
Автоматизировать проверки данных, а не людей. Внедрить «Security as Code»: система сама проверяет код и данные на уязвимости в процессе разработки, а не постфактум ищет виноватых. ИБ становится архитектором безопасности, а не надзирателем.
Смоделировать работающие процессы вместе. Сесть всем - ИБ, разработке, архитекторам, дата-инженерам и прописать простые и ясные "правила игры". Не 100-страничный Нормативный документ для внутреннего применения, а живую модельную инструкцию, как быстро и безопасно довести идею до продукта или сервиса.
Резюмирую. Пока мы спорим о версиях Python, наш data-капитал не работает. Современная экономика требует скорости и гибкости. Пора перестать хоронить данные в корпоративных сейфах и начать управлять их доступностью.
Готовы обсудить, как внедрить такой подход в вашей компании? Пишите в комментарии, разберем ваши кейсы. Ваши данные должны приносить прибыль, а не головную боль.👇
#Истории@data_capital
Коллеги, на днях наблюдал в одном рабочем чате жаркую дискуссию. Разработчики спрашивали у ИБ: «Можно ли использовать Python или актуальный C#?». Ответы были в стиле: «ИБ не запрещает языки… но если найдем неразрешенное ПО на сервере - пишите объяснительную».
Думаю, это знакомая ситуация, это не просто спор, это системный кризис доступности данных.
В чем суть кризиса? Компания платит за дорогих специалистов, закупает лицензии, но работа стоит на месте.
В чем проблема? Данные заблокированы устаревшими правилами, которые путают среду разработки (dev/test) с продакшеном.
Почему инструменты недоступны? Чтобы получить нужную библиотеку или фреймворк, нужно пройти десятки согласований. Пока их согласуют - бизнес-возможность ушла, возникли другие задачи и начинаем сначала круг согласований.
Почему мы живем в культуре запретов? Вместо управления рисками данных - запрет инструментов. Notepad++ становится «врагом безопасности», хотя проблема не в нем.
Что происходит на самом деле? Мы защищаем не то. Защищать нужно данные, а не программы. Python, C#, ИИ-модели - это просто инструменты. Бессмысленно запрещать инструмент, нужно научиться безопасно им пользоваться.
Пока ИБ контролирует «железо» и софт, а разработка не может работать, данные, наш главный капитал и ценность, лежат мёртвым грузом и "тухнут". Бизнес не получает ценность, компания теряет конкурентоспособность, время и деньги.
Целевое решение, которое следует рассмотреть, это переход от управления доступом к управляемой доступности.
Выход из кризисной ситуации заключается в смене парадигмы. Вот примерный рабочий план для крупных компаний:
Создать «Безопасный магазин/сервис решений». Единый внутренний портал, где ИБ заранее проверит и одобрит версии Python, библиотек, контейнеров, а разработчик, в свою очередь, как и продвинутый пользователь для изучения и тестирования, берет нужное в один клик, без писем и ожидания. Это снимает 80% конфликтов, это экономит недели и месяцы согласования и освоение новых технологий.
Нужно четко разделить "миры". Мир разработки (dev/test) - это полигон с тестовыми данными. Правила здесь должны быть гибкими, чтобы можно было экспериментировать. Мир продакшена - это святая святых с живыми данными, и тут контроль строгий. Риски разные, подход разный.
Автоматизировать проверки данных, а не людей. Внедрить «Security as Code»: система сама проверяет код и данные на уязвимости в процессе разработки, а не постфактум ищет виноватых. ИБ становится архитектором безопасности, а не надзирателем.
Смоделировать работающие процессы вместе. Сесть всем - ИБ, разработке, архитекторам, дата-инженерам и прописать простые и ясные "правила игры". Не 100-страничный Нормативный документ для внутреннего применения, а живую модельную инструкцию, как быстро и безопасно довести идею до продукта или сервиса.
Резюмирую. Пока мы спорим о версиях Python, наш data-капитал не работает. Современная экономика требует скорости и гибкости. Пора перестать хоронить данные в корпоративных сейфах и начать управлять их доступностью.
Готовы обсудить, как внедрить такой подход в вашей компании? Пишите в комментарии, разберем ваши кейсы. Ваши данные должны приносить прибыль, а не головную боль.👇
#Истории@data_capital
👍3
DATA КАПИТАЛ / Аналитический выпуск
🔥 ДАННЫЕ ТЭК: СИСТЕМНЫЙ КРИЗИС УПРАВЛЕНИЯ
Отраслевой анализ на основе отчета InfoWatch за I полугодие 2025 показывает тревожную картину:
⚡️ КЛЮЧЕВОЙ ВЫВОД
Ситуация с утечками в ТЭК, это не случайность, а симптом системного кризиса управления данными. Компании отрасли защищают не те активы, не видят реальных угроз и не понимают ценности своих цифровых активов.
Главная проблема: Данные до сих пор не воспринимаются как стратегический актив, сравнимый по ценности с нефтью или газом. Отсюда, фокус на формальных показателях вместо реальной защиты бизнес-критических активов.
Ключевой вопрос: Какие решения, по вашему мнению, могут кардинально изменить ситуацию? Что должно стать приоритетом - технологии, процессы или изменение культуры управления?
📚 Источники: Отчет InfoWatch "Утечки информации из предприятий ТЭК", 1 полугодие 2025; исследование IBM Security; данные SecurityScorecard.
Ваши предложения пишите в комментариях 👇
#Аналитика@data_capital
🔥 ДАННЫЕ ТЭК: СИСТЕМНЫЙ КРИЗИС УПРАВЛЕНИЯ
Отраслевой анализ на основе отчета InfoWatch за I полугодие 2025 показывает тревожную картину:
📊 МАСШТАБЫ УТЕЧЕК
• 4 млн записей ПДн скомпрометировано в России
• 82 млн записей ПДн утекло в мире из предприятий ТЭК
• Россия - 4-е место в мире по утечкам в ТЭК
• 43 инцидента ИБ зафиксировано в мире, 3 - в России
🎯 СТРУКТУРА ИНЦИДЕНТОВ
• 71,4% утечек - результат кибератак
• 57,1% утечек - персональные данные
• 14,3% - государственная тайна
• 0% утечек коммерческой тайны в статистике
💸 ФИНАНСОВЫЕ ПОТЕРИ
• Средняя стоимость утечки для ТЭК - $4,83 млн
• 90% энергокомпаний страдают от утечек через партнеров
• 35,7% мировых утечек в ТЭК приходятся на США
⚡️ КЛЮЧЕВОЙ ВЫВОД
Ситуация с утечками в ТЭК, это не случайность, а симптом системного кризиса управления данными. Компании отрасли защищают не те активы, не видят реальных угроз и не понимают ценности своих цифровых активов.
Главная проблема: Данные до сих пор не воспринимаются как стратегический актив, сравнимый по ценности с нефтью или газом. Отсюда, фокус на формальных показателях вместо реальной защиты бизнес-критических активов.
Ключевой вопрос: Какие решения, по вашему мнению, могут кардинально изменить ситуацию? Что должно стать приоритетом - технологии, процессы или изменение культуры управления?
📚 Источники: Отчет InfoWatch "Утечки информации из предприятий ТЭК", 1 полугодие 2025; исследование IBM Security; данные SecurityScorecard.
Ваши предложения пишите в комментариях 👇
#Аналитика@data_capital
👍3
Дорогие коллеги, вот она, наша книга!
Согласовали обложку. Это выстраданная, живая история про то, как мы вместе превращаем хаos в порядок.
Я бесконечно благодарен каждому, кто является частью этого пути. Книга родилась благодаря вам.
Скоро книга готова будет своими знаниями поделиться этим с миром)))
#Антихаос@data_capital
Согласовали обложку. Это выстраданная, живая история про то, как мы вместе превращаем хаos в порядок.
Я бесконечно благодарен каждому, кто является частью этого пути. Книга родилась благодаря вам.
Скоро книга готова будет своими знаниями поделиться этим с миром)))
#Антихаос@data_capital
🔥6👍4🎉2
DATA КАПИТАЛ | Пути решения
Продолжаю предыдущий пост: «ДАННЫЕ ТЭК: СИСТЕМНЫЙ КРИЗИС УПРАВЛЕНИЯ »
Предлагаю рассмотреть следующий подход: системный кризис требует системного ответа. Приоритетом должна стать комплексная архитектура компании, которая должна связать культуру, процессы и технологии воедино и быть актуальной через сервисную поддержку.
Опираясь на глубокий отраслевой анализ, я вижу три реалистичных сценария для компаний ТЭК, которые дают максимальный эффект при минимальных затратах:
1. Сценарий «Безопасный конвейер»
Создание внутреннего сервиса с предварительно проверенными ИБ инструментами и компонентами. Разработчики и аналитики получают доступ к актуальным версиям Python, библиотек и фреймворков в один клик, без писем и месяцев согласований. Это не «все разрешить», а создать управляемую и безопасную среду для разработки.
2. Сценарий «Фокус на ценности»
Вместо тотальной защиты всего - точечная концентрация на 20% данных, которые приносят 80% стоимости или рисков. Это ноу-хау, модели месторождений, стратегические контракты. Методология включает экспресс-аудит и назначение бизнес-владельцев за эти критические активы.
3. Сценарий «Проактивный щит»
Внедрение непрерывного мониторинга цифрового следа компании и ее партнеров. Речь не о том, чтобы ждать утечку, а чтобы находить уязвимости и следы утечек в открытых источниках до того, как ими воспользуются конкуренты или хакеры.
Ключевой вывод: Нельзя решить проблему, просто купив новую систему защиты. Нужно менять логику управления: от реакции на инциденты - к проектированию защищенной и доступной data-среды. Именно это превращает данные из источника рисков в рабочий капитал.
А какой из этих сценариев, по-вашему, наиболее критичен для российского ТЭК? Жду ваше мнение в комментариях 👇
#Аналитика@data_capital
Продолжаю предыдущий пост: «ДАННЫЕ ТЭК: СИСТЕМНЫЙ КРИЗИС УПРАВЛЕНИЯ »
Предлагаю рассмотреть следующий подход: системный кризис требует системного ответа. Приоритетом должна стать комплексная архитектура компании, которая должна связать культуру, процессы и технологии воедино и быть актуальной через сервисную поддержку.
Опираясь на глубокий отраслевой анализ, я вижу три реалистичных сценария для компаний ТЭК, которые дают максимальный эффект при минимальных затратах:
1. Сценарий «Безопасный конвейер»
Создание внутреннего сервиса с предварительно проверенными ИБ инструментами и компонентами. Разработчики и аналитики получают доступ к актуальным версиям Python, библиотек и фреймворков в один клик, без писем и месяцев согласований. Это не «все разрешить», а создать управляемую и безопасную среду для разработки.
2. Сценарий «Фокус на ценности»
Вместо тотальной защиты всего - точечная концентрация на 20% данных, которые приносят 80% стоимости или рисков. Это ноу-хау, модели месторождений, стратегические контракты. Методология включает экспресс-аудит и назначение бизнес-владельцев за эти критические активы.
3. Сценарий «Проактивный щит»
Внедрение непрерывного мониторинга цифрового следа компании и ее партнеров. Речь не о том, чтобы ждать утечку, а чтобы находить уязвимости и следы утечек в открытых источниках до того, как ими воспользуются конкуренты или хакеры.
Ключевой вывод: Нельзя решить проблему, просто купив новую систему защиты. Нужно менять логику управления: от реакции на инциденты - к проектированию защищенной и доступной data-среды. Именно это превращает данные из источника рисков в рабочий капитал.
А какой из этих сценариев, по-вашему, наиболее критичен для российского ТЭК? Жду ваше мнение в комментариях 👇
#Аналитика@data_capital
👍4
DATA КАПИТАЛ | Пути решения часть 2
«ДАННЫЕ ТЭК: СИСТЕМНЫЙ КРИЗИС УПРАВЛЕНИЯ »
Еще несколько сценариев и технологий хочу показать. Уже достаточно давно была сформулирована Концепция Zero Trust, которую только сейчас начали осознавать и, из-за этого она становится все популярнее в бизнесе, и важно понимать: это не просто еще одна технология, а принципиально новая архитектура управления, где главным защищаемым активом становятся сами данные.
Вот что меняется на практике:
1. От защиты периметра к защите каждого информационного объекта (данных)
Раньше мы защищали границы сетей. Теперь нужно защищать каждую единицу информации не только при хранении, использовании, но и при ее перемещениях. Ключевое решение: мандатная метка становится частью метаданных любого информационного объекта. Представьте: каждый файл, каждая запись в базе данных, каждый сетевой пакет знает, кто может с ним работать. Это особенно важно, когда конфиденциальные данные передаются по общим каналам в облаке.
2. Мандатный контроль как основа безопасности
Когда каждый информационный объект содержит встроенные правила доступа, мы достигаем максимальной детализации контроля. Это реализация принципа "ничего не доверяй, все проверяй" на уровне данных.
3. Постепенный переход вместо революции
Модель зрелости CISA показывает: переход к Zero Trust это эволюционный процесс. Мы движемся от традиционных подходов к оптимальным через конкретные шаги в пяти направлениях: идентичность, устройства, сети, приложения и данные.
Вывод:
Сценарий "Фокус на ценности" становится по-настоящему эффективным в сочетании с Zero Trust. Сначала определяем самые ценные объекты, самые ценные данные (те самые 20%, что приносят 80% результата), применяем к ним мандатный контроль, а затем постепенно выстраиваем полную систему защиты.
По сути, мы создаем систему управления цифровыми активами, где безопасность встроена в саму архитектуру данных через контролируемые метрики их состояния, а не добавляется как отдельный компонент.
#Аналитика@data_capital
«ДАННЫЕ ТЭК: СИСТЕМНЫЙ КРИЗИС УПРАВЛЕНИЯ »
Еще несколько сценариев и технологий хочу показать. Уже достаточно давно была сформулирована Концепция Zero Trust, которую только сейчас начали осознавать и, из-за этого она становится все популярнее в бизнесе, и важно понимать: это не просто еще одна технология, а принципиально новая архитектура управления, где главным защищаемым активом становятся сами данные.
Вот что меняется на практике:
1. От защиты периметра к защите каждого информационного объекта (данных)
Раньше мы защищали границы сетей. Теперь нужно защищать каждую единицу информации не только при хранении, использовании, но и при ее перемещениях. Ключевое решение: мандатная метка становится частью метаданных любого информационного объекта. Представьте: каждый файл, каждая запись в базе данных, каждый сетевой пакет знает, кто может с ним работать. Это особенно важно, когда конфиденциальные данные передаются по общим каналам в облаке.
2. Мандатный контроль как основа безопасности
Когда каждый информационный объект содержит встроенные правила доступа, мы достигаем максимальной детализации контроля. Это реализация принципа "ничего не доверяй, все проверяй" на уровне данных.
3. Постепенный переход вместо революции
Модель зрелости CISA показывает: переход к Zero Trust это эволюционный процесс. Мы движемся от традиционных подходов к оптимальным через конкретные шаги в пяти направлениях: идентичность, устройства, сети, приложения и данные.
Вывод:
Сценарий "Фокус на ценности" становится по-настоящему эффективным в сочетании с Zero Trust. Сначала определяем самые ценные объекты, самые ценные данные (те самые 20%, что приносят 80% результата), применяем к ним мандатный контроль, а затем постепенно выстраиваем полную систему защиты.
По сути, мы создаем систему управления цифровыми активами, где безопасность встроена в саму архитектуру данных через контролируемые метрики их состояния, а не добавляется как отдельный компонент.
#Аналитика@data_capital
👍3
Data Quality в Ozon: сильное техрешение, но слабая методология 🤦♂️
Прочитал большой разбор про Data Quality в Ozon и хочу поделиться личным анализом.
Ситуация показательная: команда построила систему контроля данных в Hadoop. Технически решение сильное, но, как эксперт по управлению данными, я вижу системные пробелы.
Что я увидел в их подходе:
Технически все грамотно: выбрали Spark Connect Server, обошли ограничения Kubernetes, честно описали компромиссы. С инженерной позиции я оцениваю высоко их решение, но с позиции управления данными, я вижу проблему с серьезными последствиями. Они создали инструмент для поиска проблем с данными, но не выстроили систему, чтобы эти проблемы решались.
Мои ключевые выводы после анализа:
1. Технологии без методологии - это тупик. Можно построить идеальный детектор ошибок, но если не определены владельцы данных и процессы исправления, как следствие бизнес-риски не снижаются.
2. 80 команд используют данные, но кто за них отвечает? Без ответа на этот вопрос любая DQ-система превращается в дорогой дашборд с красными метриками, которые никто не исправляет.
3. Понимание уровня зрелости, это когда вы управляете данными, а не просто их проверяете. Ozon решил техническую задачу, но не управленческую.
Личная позиция:
Я убежден, что успешные data-проекты начинаются не с выбора технологий, а с ответов на вопросы «зачем?» и «кто отвечает?». Без этого даже самые совершенные технические решения не дают бизнесу реальной ценности.
А что вы думаете? Сталкивались с подобными ситуациями?
https://habr.com/ru/companies/ozontech/articles/962174/
Прочитал большой разбор про Data Quality в Ozon и хочу поделиться личным анализом.
Ситуация показательная: команда построила систему контроля данных в Hadoop. Технически решение сильное, но, как эксперт по управлению данными, я вижу системные пробелы.
Что я увидел в их подходе:
Технически все грамотно: выбрали Spark Connect Server, обошли ограничения Kubernetes, честно описали компромиссы. С инженерной позиции я оцениваю высоко их решение, но с позиции управления данными, я вижу проблему с серьезными последствиями. Они создали инструмент для поиска проблем с данными, но не выстроили систему, чтобы эти проблемы решались.
Мои ключевые выводы после анализа:
1. Технологии без методологии - это тупик. Можно построить идеальный детектор ошибок, но если не определены владельцы данных и процессы исправления, как следствие бизнес-риски не снижаются.
2. 80 команд используют данные, но кто за них отвечает? Без ответа на этот вопрос любая DQ-система превращается в дорогой дашборд с красными метриками, которые никто не исправляет.
3. Понимание уровня зрелости, это когда вы управляете данными, а не просто их проверяете. Ozon решил техническую задачу, но не управленческую.
Личная позиция:
Я убежден, что успешные data-проекты начинаются не с выбора технологий, а с ответов на вопросы «зачем?» и «кто отвечает?». Без этого даже самые совершенные технические решения не дают бизнесу реальной ценности.
А что вы думаете? Сталкивались с подобными ситуациями?
https://habr.com/ru/companies/ozontech/articles/962174/
👍4
Если ИИ создает данные, то можно ли с помощью ИИ решать сложные и критичные задачи?
Коллеги, после разбора нового кейса с Habr, где инженер успешно применил ИИ для моделирования процессов и генерации кода, я хочу поделиться ключевым выводом. Технологическая возможность есть. Но она упирается в культурный уровень эксперта.
Личное наблюдение: можно быть блестящим технологом, но без культурной зрелости работа с ИИ в сложных задачах превратится в рулетку.
Что такое культурная зрелость эксперта в этом контексте?
Это не про знание языков программирования или умение строить запросы. Это про внутренние установки:
Готовность к итеративной работе.
Настоящий специалист не ждет волшебного результата по одному запросу. Он выстраивает диалог с системой: запрос, проверка, уточнение, коррекция. Это требует терпения и дисциплины.
Принятие ответственности,
ИИ не виноват в ошибках. Ответственность за финальный результат всегда на эксперте. Зрелый специалист не ищет виноватых, а выстраивает процессы верификации.
Способность к критическому мышлению.
Самая опасная ловушка это доверие к результатам ИИ без проверки. Культурно зрелый эксперт сохраняет здоровый скепсис и проверяет каждую деталь.
Понимание границ компетенций.
ИИ не может заменить экспертизы, а может их только усилить. Нужно четко понимать, где система может помочь, а где без глубоких предметных знаний не обойтись.
Технологии развиваются быстрее нашей культуры работы с ними. Мы можем иметь совершенные инструменты, но без зрелого подхода они не дадут надежных результатов.
Итог: успех в работе со сложными ИИ задачами определяется не только технологической подготовкой, но и культурной зрелостью команды. Без этого даже самый совершенный инструмент становится опасным.
https://habr.com/ru/companies/architeezy/articles/953642/
Готов обсудить ваше видение в комментариях.
#Аналитика@data_capital
Коллеги, после разбора нового кейса с Habr, где инженер успешно применил ИИ для моделирования процессов и генерации кода, я хочу поделиться ключевым выводом. Технологическая возможность есть. Но она упирается в культурный уровень эксперта.
Личное наблюдение: можно быть блестящим технологом, но без культурной зрелости работа с ИИ в сложных задачах превратится в рулетку.
Что такое культурная зрелость эксперта в этом контексте?
Это не про знание языков программирования или умение строить запросы. Это про внутренние установки:
Готовность к итеративной работе.
Настоящий специалист не ждет волшебного результата по одному запросу. Он выстраивает диалог с системой: запрос, проверка, уточнение, коррекция. Это требует терпения и дисциплины.
Принятие ответственности,
ИИ не виноват в ошибках. Ответственность за финальный результат всегда на эксперте. Зрелый специалист не ищет виноватых, а выстраивает процессы верификации.
Способность к критическому мышлению.
Самая опасная ловушка это доверие к результатам ИИ без проверки. Культурно зрелый эксперт сохраняет здоровый скепсис и проверяет каждую деталь.
Понимание границ компетенций.
ИИ не может заменить экспертизы, а может их только усилить. Нужно четко понимать, где система может помочь, а где без глубоких предметных знаний не обойтись.
Технологии развиваются быстрее нашей культуры работы с ними. Мы можем иметь совершенные инструменты, но без зрелого подхода они не дадут надежных результатов.
Итог: успех в работе со сложными ИИ задачами определяется не только технологической подготовкой, но и культурной зрелостью команды. Без этого даже самый совершенный инструмент становится опасным.
https://habr.com/ru/companies/architeezy/articles/953642/
Готов обсудить ваше видение в комментариях.
#Аналитика@data_capital
👍1
Иллюзия зрелости: почему методология без глубины остаётся просто игрой в слова
Только что завершил дистанционное участие в одном семинаре по управлению данными. Отключаю IVA и ещё долго сижу в тишине, пытаясь вернуть себе ощущение реальности. Словно наблюдал за сложной театральной постановкой, где вместо настоящих ценностей со сцены транслировали идеально упакованные иллюзии.
Мне, прошедшему путь осознания от Хаоса к «Антихаосу», сегодня снова пытались объяснить, что такое качество данных. Объясняли «специалисты-методологи», для которых Data Governance это не система для поддержки принятия точных бизнес решений, а коллекция слайдов с заимствованными концепциями. Люди, которые, кажется, никогда не чувствовали тяжести ответственности за реальные бизнес последствия ошибочных данных.
Я слушал и понимал: мы говорим на разных языках. Для них «владелец данных» это тот, кто «определяет требования». Для меня это человек, отвечающий за ценность и риски. Для них «качество» это проценты и графики. Для меня это доверие, которое можно потерять в один момент из-за одной ошибки.
Самое тревожное осознание пришло позже: таким специалистам методологам крупные компании доверяют строить свои цифровые экосистемы. Что вместо фундаментального подхода, вместо глубокой методологии, вместо четкой связи с бизнес целями нам предложили яркий суррогат. Инструменты выдавались за стратегию, процессы за культуру, а шаблонные роли за зрелую модель управления.
И за всем этим полная тишина там, где должен звучать главный вопрос: зачем? Как эти данные двигают бизнес? Как они создают ценность? Где экономика, где риски, где жизнь?
Отключив семинар, я понял: мы живем в эпоху великой путаницы. Когда технические исполнители пытаются играть в архитекторов ценностей. Когда ремесло пытается выдать себя за профессию. И это не их вина, это системная болезнь. Болезнь, при которой легко говорить на языке скриптов и дашбордов, и так сложно на языке смыслов (Огромное спасибо Владимиру Арсентьевичу Рубанову) и ответственности.
Грустно. Не потому что время потрачено зря. А потому что за этим семинаром стоят реальные бюджеты, реальные ожидания и реальные люди, которые верят, что их ведут к цифровому преображению. А на самом деле их ведут в красиво оформленный тупик.
И пока мы не начнем называть вещи своими именами и не потребуем от коллег не слайдов, а глубины, мы будем продолжать ходить по кругу. Строить витрины, в которых нет товара. И писать код, который не решает главного.
#Аналитика@data_capital
Только что завершил дистанционное участие в одном семинаре по управлению данными. Отключаю IVA и ещё долго сижу в тишине, пытаясь вернуть себе ощущение реальности. Словно наблюдал за сложной театральной постановкой, где вместо настоящих ценностей со сцены транслировали идеально упакованные иллюзии.
Мне, прошедшему путь осознания от Хаоса к «Антихаосу», сегодня снова пытались объяснить, что такое качество данных. Объясняли «специалисты-методологи», для которых Data Governance это не система для поддержки принятия точных бизнес решений, а коллекция слайдов с заимствованными концепциями. Люди, которые, кажется, никогда не чувствовали тяжести ответственности за реальные бизнес последствия ошибочных данных.
Я слушал и понимал: мы говорим на разных языках. Для них «владелец данных» это тот, кто «определяет требования». Для меня это человек, отвечающий за ценность и риски. Для них «качество» это проценты и графики. Для меня это доверие, которое можно потерять в один момент из-за одной ошибки.
Самое тревожное осознание пришло позже: таким специалистам методологам крупные компании доверяют строить свои цифровые экосистемы. Что вместо фундаментального подхода, вместо глубокой методологии, вместо четкой связи с бизнес целями нам предложили яркий суррогат. Инструменты выдавались за стратегию, процессы за культуру, а шаблонные роли за зрелую модель управления.
И за всем этим полная тишина там, где должен звучать главный вопрос: зачем? Как эти данные двигают бизнес? Как они создают ценность? Где экономика, где риски, где жизнь?
Отключив семинар, я понял: мы живем в эпоху великой путаницы. Когда технические исполнители пытаются играть в архитекторов ценностей. Когда ремесло пытается выдать себя за профессию. И это не их вина, это системная болезнь. Болезнь, при которой легко говорить на языке скриптов и дашбордов, и так сложно на языке смыслов (Огромное спасибо Владимиру Арсентьевичу Рубанову) и ответственности.
Грустно. Не потому что время потрачено зря. А потому что за этим семинаром стоят реальные бюджеты, реальные ожидания и реальные люди, которые верят, что их ведут к цифровому преображению. А на самом деле их ведут в красиво оформленный тупик.
И пока мы не начнем называть вещи своими именами и не потребуем от коллег не слайдов, а глубины, мы будем продолжать ходить по кругу. Строить витрины, в которых нет товара. И писать код, который не решает главного.
#Аналитика@data_capital
👍4❤1
Сервисный подход к данным, просто, как водопровод. И так же невозможно без него жить. Мысли в выходные дни о простом и сложном.
Коллеги, я постоянно слышу один вопрос: «Если сервисный подход к данным такой простой и логичный, почему его мало кто качественно делает?»
Отвечу как есть, потому что мы предпочитаем жить в цифровом средневековье.
Представьте поселок, где у каждого дома свой колодец. Один копает его в огороде, другой - в подвале, третий и вовсе берет воду из ближайшего болота. Воду никто не проверяет, колодцы мешают друг другу, а когда один источник пересыхает, то его хозяин начинает тайком носить ведром от соседа.
И так живут годами. Потому что «так исторически сложилось».
Вот это и есть типовая компания без сервисного подхода к данным.
Каждый отдел, каждая система, это тот самый дом с персональным, сомнительным колодцем.
- Отдел маркетинга пьет из одного колодца («активные клиенты»).
- Финансы, из другого («плательщики по договорам»).
- Служба поддержки, из третьего («заявители в техподдержку»).
- Канцелярия общается со всем миром вокруг берет воду из всех ручьев («корреспонденты»).
И вы удивляетесь, почему у вас разная цифра по количеству клиентов? Почему акции доходят не до всех? Почему отчёты не сходятся? Вы не решаете проблему, вы постоянно латаете дыры в «ведрах».
Сервисный подход в данных, это не про IT. Это про то, чтобы провести в этот посёлок центральный водопровод, или чтоб у всех был свет.
Это про целостность:
- Один источник.
- Чистая, проверенная вода для всех.
- Стандартный кран (API), из которого все берут.
- Команда сантехников (владельцы сервисов), которая отвечает за качество и бесперебойную работу.
Почему же это «просто», но не делается?
Потому что «просто», это на схеме в PowerPoint. А в жизни, это титаническая работа:
1. Нужно договориться, что такое «вода». То есть, что такое «клиент». Какие у него атрибуты. Кто имеет право его создавать и менять. Это не техническая, а политическая и методологическая битва.
2. Нужно перекрыть старые колодцы. А это значит, пойти против годами устоявшихся процессов, против «а мы всегда так делали», против людей, которые считают «свой» колодец своей вотчиной.
3. Нужно признать, что водопровод будет всегда. Его нельзя один раз провести и забыть. Его нужно обслуживать, модернизировать, защищать. Это не проект, а новая культура жизнеобеспечения компании.
И когда вы это понимаете, фраза «просто сделать один источник истины» начинает звучать как «просто построить город будущего».
Мы не делаем этого не потому, что не понимаем. А потому, что боимся этой титанической организационной работы. Проще продолжать бегать с вёдрами и винить во всем «кривые» отчеты.
Но в тот день, когда в вашей компании появится первый такой «водопровод» для ключевых данных, вы можете испытать катарсис, хотя обычно это ощущение, а разве может быть иначе. Вы поймёте, что наконец-то тратите силы не на борьбу с хаосом, а на движение вперёд.
Это трудно. Но жить в цифровом средневековье, когда у других уже есть умные сети, ещё труднее. И гораздо дороже.
Коллеги, я постоянно слышу один вопрос: «Если сервисный подход к данным такой простой и логичный, почему его мало кто качественно делает?»
Отвечу как есть, потому что мы предпочитаем жить в цифровом средневековье.
Представьте поселок, где у каждого дома свой колодец. Один копает его в огороде, другой - в подвале, третий и вовсе берет воду из ближайшего болота. Воду никто не проверяет, колодцы мешают друг другу, а когда один источник пересыхает, то его хозяин начинает тайком носить ведром от соседа.
И так живут годами. Потому что «так исторически сложилось».
Вот это и есть типовая компания без сервисного подхода к данным.
Каждый отдел, каждая система, это тот самый дом с персональным, сомнительным колодцем.
- Отдел маркетинга пьет из одного колодца («активные клиенты»).
- Финансы, из другого («плательщики по договорам»).
- Служба поддержки, из третьего («заявители в техподдержку»).
- Канцелярия общается со всем миром вокруг берет воду из всех ручьев («корреспонденты»).
И вы удивляетесь, почему у вас разная цифра по количеству клиентов? Почему акции доходят не до всех? Почему отчёты не сходятся? Вы не решаете проблему, вы постоянно латаете дыры в «ведрах».
Сервисный подход в данных, это не про IT. Это про то, чтобы провести в этот посёлок центральный водопровод, или чтоб у всех был свет.
Это про целостность:
- Один источник.
- Чистая, проверенная вода для всех.
- Стандартный кран (API), из которого все берут.
- Команда сантехников (владельцы сервисов), которая отвечает за качество и бесперебойную работу.
Почему же это «просто», но не делается?
Потому что «просто», это на схеме в PowerPoint. А в жизни, это титаническая работа:
1. Нужно договориться, что такое «вода». То есть, что такое «клиент». Какие у него атрибуты. Кто имеет право его создавать и менять. Это не техническая, а политическая и методологическая битва.
2. Нужно перекрыть старые колодцы. А это значит, пойти против годами устоявшихся процессов, против «а мы всегда так делали», против людей, которые считают «свой» колодец своей вотчиной.
3. Нужно признать, что водопровод будет всегда. Его нельзя один раз провести и забыть. Его нужно обслуживать, модернизировать, защищать. Это не проект, а новая культура жизнеобеспечения компании.
И когда вы это понимаете, фраза «просто сделать один источник истины» начинает звучать как «просто построить город будущего».
Мы не делаем этого не потому, что не понимаем. А потому, что боимся этой титанической организационной работы. Проще продолжать бегать с вёдрами и винить во всем «кривые» отчеты.
Но в тот день, когда в вашей компании появится первый такой «водопровод» для ключевых данных, вы можете испытать катарсис, хотя обычно это ощущение, а разве может быть иначе. Вы поймёте, что наконец-то тратите силы не на борьбу с хаосом, а на движение вперёд.
Это трудно. Но жить в цифровом средневековье, когда у других уже есть умные сети, ещё труднее. И гораздо дороже.
👍6🔥3
Водопровод провели. А пить воду некому.
Коллеги, спасибо за понимание поста про «водопровод». Вы правы: без единого источника истины, это путь в никуда. Но я хочу пойти дальше.
Представьте: мы проложили идеальные трубы. Вода кристальная, давление отличное, краны (API) работают. Но в домах - тишина. Люди продолжают ходить к своим старым, заиленным колодцам. Потому что привыкли. Потому что не доверяют «центральному водопроводу». Потому что их не научили поворачивать новый кран. Знакомая же история, может и сами этому подвержены?
Технологическая задача, как правило может быть решена. А организационная и культурная, она только начинается. Это тот самый момент, когда цифровое средневековье не хочет сдаваться без боя.
Меня всегда интересовало: а что, если довести идею «водопровода» до абсолютного уровня? Не просто дать доступ к данным, а сделать так, чтобы сама жизнь компании зависела от их качества и прозрачности. Чтобы не было «сантехников» и «потребителей», а были только ответственные жильцы поселка.
И чтоб этот пост не выглядел фантазией, я приложу к нему документ, который мне попал уже достаточно давно.
Есть одна компания, которая живёт так уже 30 лет. Valve. Многие, кто следит за развитием online игр, о ней давно слышал. У них нет менеджеров, отделов и KPI сверху. Нет того, кто «владеет» данными. Но их выручка на сотрудника - одна из самых высоких в мире более 50 млн. $ в год.
Парадокс? Нет. Их секрет в том, что они построили не водопровод. Они построили город на основе доверия к данным.
Вот как это работает:
Прозрачность как воздух. Вся информация о проектах, сервисах, метриках, экспериментах - открыта. Любой сотрудник может посмотреть на «счётчики» в любом «доме». Выбор, над чем работать, он делает, опираясь на эти данные, а не на приказ.
Владельцы, а не сантехники. Ответственность за качество «воды» (данных) распределена между всеми. Если ты используешь метрику в своём решении, ты по умолчанию отвечаешь за её адекватность. Это как если бы каждый житель города был ещё и инженером водоканала.
Культура, где ошибка в данных, позорнее, чем провал проекта. Репутацию здесь строят не на красивых отчётах и презентациях, а на точности и полезности предоставляемой коллегам информации. Ежегодное ранжирование, это в том числе и оценка твоего вклада в общее поле данных.
Мы говорим «сервисный подход» и думаем об архитектуре, API и пайплайнах. Valve показала, что это в первую очередь культурный код. Можно иметь лучший в мире водопровод, но если в компании нет зрелости доверять единому источнику, если люди боятся делиться «своей» водой или не умеют читать общие счётчики, система рухнет.
Трансформация, а особенно цифровая трансформация, это когда мы перестаём просто качать воду и начинаем воспитывать сообщество ответственных потребителей. Где данные, не актив отдела аналитики или канцелярии, а общий язык, на котором говорит вся компания с управляемой доступностью.
Это следующий шаг. Сложный, глубокий, человеческий. От построения инфраструктуры, к изменению мышления. Именно здесь рождается настоящая эффективность.
Интересно, на каком этапе находимся мы? Прокладываем трубы или уже учимся пить из одного источника?
Коллеги, спасибо за понимание поста про «водопровод». Вы правы: без единого источника истины, это путь в никуда. Но я хочу пойти дальше.
Представьте: мы проложили идеальные трубы. Вода кристальная, давление отличное, краны (API) работают. Но в домах - тишина. Люди продолжают ходить к своим старым, заиленным колодцам. Потому что привыкли. Потому что не доверяют «центральному водопроводу». Потому что их не научили поворачивать новый кран. Знакомая же история, может и сами этому подвержены?
Технологическая задача, как правило может быть решена. А организационная и культурная, она только начинается. Это тот самый момент, когда цифровое средневековье не хочет сдаваться без боя.
Меня всегда интересовало: а что, если довести идею «водопровода» до абсолютного уровня? Не просто дать доступ к данным, а сделать так, чтобы сама жизнь компании зависела от их качества и прозрачности. Чтобы не было «сантехников» и «потребителей», а были только ответственные жильцы поселка.
И чтоб этот пост не выглядел фантазией, я приложу к нему документ, который мне попал уже достаточно давно.
Есть одна компания, которая живёт так уже 30 лет. Valve. Многие, кто следит за развитием online игр, о ней давно слышал. У них нет менеджеров, отделов и KPI сверху. Нет того, кто «владеет» данными. Но их выручка на сотрудника - одна из самых высоких в мире более 50 млн. $ в год.
Парадокс? Нет. Их секрет в том, что они построили не водопровод. Они построили город на основе доверия к данным.
Вот как это работает:
Прозрачность как воздух. Вся информация о проектах, сервисах, метриках, экспериментах - открыта. Любой сотрудник может посмотреть на «счётчики» в любом «доме». Выбор, над чем работать, он делает, опираясь на эти данные, а не на приказ.
Владельцы, а не сантехники. Ответственность за качество «воды» (данных) распределена между всеми. Если ты используешь метрику в своём решении, ты по умолчанию отвечаешь за её адекватность. Это как если бы каждый житель города был ещё и инженером водоканала.
Культура, где ошибка в данных, позорнее, чем провал проекта. Репутацию здесь строят не на красивых отчётах и презентациях, а на точности и полезности предоставляемой коллегам информации. Ежегодное ранжирование, это в том числе и оценка твоего вклада в общее поле данных.
Мы говорим «сервисный подход» и думаем об архитектуре, API и пайплайнах. Valve показала, что это в первую очередь культурный код. Можно иметь лучший в мире водопровод, но если в компании нет зрелости доверять единому источнику, если люди боятся делиться «своей» водой или не умеют читать общие счётчики, система рухнет.
Трансформация, а особенно цифровая трансформация, это когда мы перестаём просто качать воду и начинаем воспитывать сообщество ответственных потребителей. Где данные, не актив отдела аналитики или канцелярии, а общий язык, на котором говорит вся компания с управляемой доступностью.
Это следующий шаг. Сложный, глубокий, человеческий. От построения инфраструктуры, к изменению мышления. Именно здесь рождается настоящая эффективность.
Интересно, на каком этапе находимся мы? Прокладываем трубы или уже учимся пить из одного источника?
👍3
Что такое DataOps? Откуда он взялся и зачем он нам?
DataOps - это достаточно новая культура и практика, которая делает работу с данными быстрой, надёжной и командной.
Представьте хоккей. Можно собрать пять лучших игроков лиги, поставить их на лёд и... с треском проиграть слаженной команде среднего уровня. Потому что нет общей стратегии, передачи не отработаны, а защита разваливается. Ровно так же выглядит типичная среда данных во многих компаниях.
DataOps, это тренер, система тренеровок и сама система, которые превращают вашу «сборку из звёзд» (гениального инженера, дотошного аналитика, талантливого ML-специалиста) в чемпионскую команду. Это набор правил, практик и инструментов, которые настраивают слаженную работу так, чтобы данные не застревали, не ломались и не терялись по пути от источника до принятия решения.
Откуда это взялось?
Концепция DataOps была формально представлена в 2014 году Ленни Либманом (Lenny Liebmann) в статье «3 Reasons Why DataOps Is Essential for Big Data Success». Её популяризации и развитию как методологии сильно способствовали Энди Палмер (Andy Palmer, сооснователь Tamr) и компания DataKitchen, основанная в 2015 году. Это был закономерный ответ на вызовы времени:
- DevOps (сформировался к концу 2000-х) доказал, что автоматизация и культура сотрудничества радикально ускоряют доставку ПО.
- Agile (Манифест 2001 года) утвердил гибкость и итеративность как стандарт.
- Мир данных упёрся в тупик, процессы стали слишком медленными от объема и "качества структуризации", ручными и хрупкими, не успевая за потребностями бизнеса.
DataOps - это осмысленное применение принципов DevOps (автоматизация, CI/CD, мониторинг) к полному жизненному циклу данных, от сырья до готового продукта.
Почему это важно для культуры?
Потому что без DataOps вы управляете «сборкой из звёзд». Ваш лучший инженер ночами вручную чинит сломанный канал данных. Талантливый аналитик неделями «колдует» в Excel, чтобы сделать единственный верный отчёт. Учёный по данным не может воспроизвести свою же модель, потому что исходные данные куда-то исчезли. Каждый - "звезда" в своём виде, но общий результат непредсказуем, медленен и ненадёжен.
DataOps меняет культуру с «культа звезд» на культуру командной игры и надёжных процессов. Это позволяет не просто «делать аналитику», а быстро, безопасно и предсказуемо превращать данные в рабочие инструменты для бизнеса: дашборды, отчёты, ML-модели.
Где это применяется?
Пионерами стали технологические компании, для которых данные, это основа продукта (Netflix, Airbnb, Spotify, LinkedIn). Сегодня это обязательный стандарт для любого серьёзного бизнеса, который зависит от масштабной аналитики, BI и машинного обучения.
Что в следующем посте?
Разберём ключевой сквозной процесс DataOps, это тот самый «игровой план» или отлаженную комбинацию, которую команда выполняет, чтобы доставить ценность. Будет понятная схема.
#DatаOps@data_capital
DataOps - это достаточно новая культура и практика, которая делает работу с данными быстрой, надёжной и командной.
Представьте хоккей. Можно собрать пять лучших игроков лиги, поставить их на лёд и... с треском проиграть слаженной команде среднего уровня. Потому что нет общей стратегии, передачи не отработаны, а защита разваливается. Ровно так же выглядит типичная среда данных во многих компаниях.
DataOps, это тренер, система тренеровок и сама система, которые превращают вашу «сборку из звёзд» (гениального инженера, дотошного аналитика, талантливого ML-специалиста) в чемпионскую команду. Это набор правил, практик и инструментов, которые настраивают слаженную работу так, чтобы данные не застревали, не ломались и не терялись по пути от источника до принятия решения.
Откуда это взялось?
Концепция DataOps была формально представлена в 2014 году Ленни Либманом (Lenny Liebmann) в статье «3 Reasons Why DataOps Is Essential for Big Data Success». Её популяризации и развитию как методологии сильно способствовали Энди Палмер (Andy Palmer, сооснователь Tamr) и компания DataKitchen, основанная в 2015 году. Это был закономерный ответ на вызовы времени:
- DevOps (сформировался к концу 2000-х) доказал, что автоматизация и культура сотрудничества радикально ускоряют доставку ПО.
- Agile (Манифест 2001 года) утвердил гибкость и итеративность как стандарт.
- Мир данных упёрся в тупик, процессы стали слишком медленными от объема и "качества структуризации", ручными и хрупкими, не успевая за потребностями бизнеса.
DataOps - это осмысленное применение принципов DevOps (автоматизация, CI/CD, мониторинг) к полному жизненному циклу данных, от сырья до готового продукта.
Почему это важно для культуры?
Потому что без DataOps вы управляете «сборкой из звёзд». Ваш лучший инженер ночами вручную чинит сломанный канал данных. Талантливый аналитик неделями «колдует» в Excel, чтобы сделать единственный верный отчёт. Учёный по данным не может воспроизвести свою же модель, потому что исходные данные куда-то исчезли. Каждый - "звезда" в своём виде, но общий результат непредсказуем, медленен и ненадёжен.
DataOps меняет культуру с «культа звезд» на культуру командной игры и надёжных процессов. Это позволяет не просто «делать аналитику», а быстро, безопасно и предсказуемо превращать данные в рабочие инструменты для бизнеса: дашборды, отчёты, ML-модели.
Где это применяется?
Пионерами стали технологические компании, для которых данные, это основа продукта (Netflix, Airbnb, Spotify, LinkedIn). Сегодня это обязательный стандарт для любого серьёзного бизнеса, который зависит от масштабной аналитики, BI и машинного обучения.
Что в следующем посте?
Разберём ключевой сквозной процесс DataOps, это тот самый «игровой план» или отлаженную комбинацию, которую команда выполняет, чтобы доставить ценность. Будет понятная схема.
#DatаOps@data_capital
👍6❤2
Игровой план DataOps. Как хоккейная комбинация превращает данные в голы.
В прошлый раз мы договорились, что DataOps, это тренер, который из "сборки звёзд" делает чемпионскую команду. Но как выглядит сама игра? Как команда данных слаженно движется к цели?
Представьте ту самую идеальную хоккейную атаку. Это не суматошный бег за шайбой, а чёткая, отточенная комбинация: выход из своей зоны, быстрый проход через центр, контроль на синей линии и точный бросок в створ ворот. Каждый участок льда соответствует своему этапу работы с данными.
Вот как выглядит ключевой сквозной процесс DataOps.
Разберем эту комбинацию по эпизодам:
1. Выход из своей зоны (Извлечение & Загрузка)
Это начало любой атаки. Шайба (сырые данные) должна быть чисто вброшена и вывезена из опасной зоны. В DataOps это значит надёжно и автоматически забрать данные из всех источников: CRM, ERP, логи, внешние API. Инструменты оркестрации (как Apache Airflow или Prefect) — это наш распорядитель, который по свистку запускает этот выход.
2. Быстрый проход через центр (Трансформация & Обогащение)
Шайба в движении. Её нужно провести через нейтральную зону, обводя препятствия (плохие форматы, лишние поля), и, возможно, отдать передачу (объединить с другими данными). На этом этапе сырые данные очищаются, приводятся к единому стандарту и обогащаются бизнес-логикой. Это сердце работы инженеров данных.
3. Ключевой момент: Контроль на синей линии (Тестирование)
Самая важная часть комбинации. Прежде чем войти в зону атаки, нужно убедиться, что шайба (данные) введена правильно, нет офсайда (критических ошибок). В DataOps этим занимается «станция контроля качества» — набор автоматических тестов (с помощью Great Expectations, dbt test, AWS Deequ).
Проверка на офсайд: Все ли обязательные поля на месте? (Полнота)
Проверка на проброс: Соответствуют ли значения ожидаемому формату? (Валидность)
Проверка на количество игроков: Нет ли дублирующихся записей? (Уникальность)
Если тесты пройдены - зелёный свет. Комбинация развивается.
Если обнаружена ошибка - зажигается красная лампа. Пайплайн останавливается, и уведомление мгновенно летит «тренеру» и «игрокам» (инженерам). Это не провал, а часть системы - быстрое обнаружение и изоляция проблемы.
4. Точный бросок в створ (Публикация)
Всё готово для результативного действия. Проверенные, готовые данные публикуются в целевую витрину, озеро данных или хранилище - туда, где их могут использовать аналитики и дата-сайентисты для создания дашбордов, отчётов и моделей. Гол!
Почему именно такая комбинация стандарт?
Потому что она отражает суть DataOps:
Скорость: Автоматизация заменяет ручной вброс и ручное ведение шайбы.
Надёжность: Контроль на синей линии (тесты) предотвращает попадание брака в зону атаки.
Командность: Процесс виден всем. Если игра встала, все понимают, где и почему, и могут скоординироваться для исправления.
Именно так команды в Netflix и Spotify обрабатывают петабайты данных ежедневно, не скатываясь в хаос.
Что в следующем посте?
Мы увидели, как команда красиво атакует. Но как новичку понять все эти комбинации? Как тренеру анализировать игру? Для этого нужна видеоаналитика, в мире данных её роль играет Каталог данных и управление метаданными. Об этом в следующем разборе.
#DatаOps@data_capital
В прошлый раз мы договорились, что DataOps, это тренер, который из "сборки звёзд" делает чемпионскую команду. Но как выглядит сама игра? Как команда данных слаженно движется к цели?
Представьте ту самую идеальную хоккейную атаку. Это не суматошный бег за шайбой, а чёткая, отточенная комбинация: выход из своей зоны, быстрый проход через центр, контроль на синей линии и точный бросок в створ ворот. Каждый участок льда соответствует своему этапу работы с данными.
Вот как выглядит ключевой сквозной процесс DataOps.
Разберем эту комбинацию по эпизодам:
1. Выход из своей зоны (Извлечение & Загрузка)
Это начало любой атаки. Шайба (сырые данные) должна быть чисто вброшена и вывезена из опасной зоны. В DataOps это значит надёжно и автоматически забрать данные из всех источников: CRM, ERP, логи, внешние API. Инструменты оркестрации (как Apache Airflow или Prefect) — это наш распорядитель, который по свистку запускает этот выход.
2. Быстрый проход через центр (Трансформация & Обогащение)
Шайба в движении. Её нужно провести через нейтральную зону, обводя препятствия (плохие форматы, лишние поля), и, возможно, отдать передачу (объединить с другими данными). На этом этапе сырые данные очищаются, приводятся к единому стандарту и обогащаются бизнес-логикой. Это сердце работы инженеров данных.
3. Ключевой момент: Контроль на синей линии (Тестирование)
Самая важная часть комбинации. Прежде чем войти в зону атаки, нужно убедиться, что шайба (данные) введена правильно, нет офсайда (критических ошибок). В DataOps этим занимается «станция контроля качества» — набор автоматических тестов (с помощью Great Expectations, dbt test, AWS Deequ).
Проверка на офсайд: Все ли обязательные поля на месте? (Полнота)
Проверка на проброс: Соответствуют ли значения ожидаемому формату? (Валидность)
Проверка на количество игроков: Нет ли дублирующихся записей? (Уникальность)
Если тесты пройдены - зелёный свет. Комбинация развивается.
Если обнаружена ошибка - зажигается красная лампа. Пайплайн останавливается, и уведомление мгновенно летит «тренеру» и «игрокам» (инженерам). Это не провал, а часть системы - быстрое обнаружение и изоляция проблемы.
4. Точный бросок в створ (Публикация)
Всё готово для результативного действия. Проверенные, готовые данные публикуются в целевую витрину, озеро данных или хранилище - туда, где их могут использовать аналитики и дата-сайентисты для создания дашбордов, отчётов и моделей. Гол!
Почему именно такая комбинация стандарт?
Потому что она отражает суть DataOps:
Скорость: Автоматизация заменяет ручной вброс и ручное ведение шайбы.
Надёжность: Контроль на синей линии (тесты) предотвращает попадание брака в зону атаки.
Командность: Процесс виден всем. Если игра встала, все понимают, где и почему, и могут скоординироваться для исправления.
Именно так команды в Netflix и Spotify обрабатывают петабайты данных ежедневно, не скатываясь в хаос.
Что в следующем посте?
Мы увидели, как команда красиво атакует. Но как новичку понять все эти комбинации? Как тренеру анализировать игру? Для этого нужна видеоаналитика, в мире данных её роль играет Каталог данных и управление метаданными. Об этом в следующем разборе.
#DatаOps@data_capital
👍2