Кто-то встречал удобный в использовании инструмент ведения кабельного журнала в электронном виде? Последнее с чем сталкивался сам - RackTables (стойки, юниты, порты), но не сказать, что прям сильно удобно
Взгляните на статью о SCIN и соответствующий дата-сет от Google на GitHub. Интересен как общий подход к формированию датасета, так и с точки расширения функциональности вашего мобильного приложения
До последнего был уверен, что статья — стёб в духе «Вредных советов» Григория Остера, сплошь перлы – нарочно не придумаешь))…
«Когда админы работают, как на конвейере», а количество «инженерных систем в районе тысячи» как раз спихнуть на них ещё одну — проще всего.
«Не смешно» — это глубина проработки проблемы… «Корневая причина: Неработоспособность БД. Накопление очередей SQL запросов»… Серьёзно?! Разработка / вендор — ни чем помочь не могут, DBA возможностей не видит.
«Потушили» проблему, «залив» её новым железом.. — идеальная модель решения проблем)
Попробую перефразировать данный опус. Менеджер проекта обо#%@лся, крайним остался отдел эксплуатации среды виртуализации. Из-за задействования резервных ресурсов, бедолаги теперь вынуждены решать не только проблемы горе-менеджера, но и «снежный ком» проблем от систем, уже находившихся в эксплуатации, ведь не зря же существовал резерв ресурсов!?
Но горе-менеджер не унывает, ведь есть Service Desk! Главное верно изложить контекст проблемы: { “корневая причина”: “неработоспособность БД”, “организационный фактор”: “кто угодно, кроме Я”, “зона ответственности”: “отдел эксплуатации виртуальной среды” }
Остаётся только «дёргать за нужные веревочки» для повышения приоритета выполнения «операции перезагрузки Postgre», чтобы снизить MTTR от простоя новодела.
Главное — грамотное разграничение ответственности между сотрудниками. Менеджер проектов не парится за реализацию обходных решений и развёртывание, мнение админа «за организационную составляющую» никого не интересует (снижаются затраты на футбол).
Такая модель управления хорошо подходит в ситуациях, когда некогда думать, сроки горят, и ничего нет.
P.S. последнюю фразу полностью позаимствовал из статьи, надеюсь автор не обидится.
В наиболее примитивных случаях построение "цифрового ядра" основывается на понимании бизнес-целей и декомпозиции KPI. И только спустя годы выясняется, что компания профукала по настоящему золотую жилу, когда решила не тратить ресурсы на сбор и накопление на первый взгляд "бессмысленной информации".
Статья - пустышка, про практику Data driven в ней ни слова
в первоначальном пресс-релизе Amazon Go тоже указывалось полностью автоматически, а на деле - индусы) На профильном ресурсе маркетинговый булшит без технических потрошков - ну такое себе(
Я прежде всего про то, чтобы была возможность загрузить готовый xml-файл BPMN2.0 в lsFusion и уже на платформе обвязать его узлы декларативно и использовать в рабочих процессах.
Просто тут круговая порука получается: если система классифицирована, как ГИС, то и бюджет и ФОТ на её защиту должен быть выделен. Иначе, зачем её классифицировать, как ГИС, и самим себя наказывать.
Самым сложным здесь представляется выполнение деперсонализации и обеспечение конфиденциальности (врачебной тайны)
При этом платформа не хранит в себе объёмные файлы, такие как рентгеновские исследования в формате DICOM, поскольку их размещение в хранилище очищенных данных замедляло бы работу системы.
Размещение в том же Yandex Object Storage вряд ли замедлит работу системы, другой вопрос - уложились ли бы вы в любезно выделенный Яндексом бюджет b2g под этот проект.
Опыт интересный, жаль что результаты пока не доступны для широкого круга исследователей.
Кто-то встречал удобный в использовании инструмент ведения кабельного журнала в электронном виде? Последнее с чем сталкивался сам - RackTables (стойки, юниты, порты), но не сказать, что прям сильно удобно
Снёс от греха подальше. А есть такое же, но про Firefox / Chrome?
Странно, что не упомянута Natasha
Взгляните на статью о SCIN и соответствующий дата-сет от Google на GitHub. Интересен как общий подход к формированию датасета, так и с точки расширения функциональности вашего мобильного приложения
Вместо
fuzzywuzzyуже пора использовать RapidFuzz наверно)Спасибо, интересное решение, надо попробовать
GEOMETRY например)
РедОС сертифицированная, или обычная? Полагаю с сертифицированной версией нюансов на порядок больше, любопытно почитать о подобном опыте
ORM справляется с чтением / записью в колонки с json-native и прочих СУБД-специфичных типов данных, или из коробки только текст, числа и булево?
До последнего был уверен, что статья — стёб в духе «Вредных советов» Григория Остера, сплошь перлы – нарочно не придумаешь))…
«Когда админы работают, как на конвейере», а количество «инженерных систем в районе тысячи» как раз спихнуть на них ещё одну — проще всего.
«Не смешно» — это глубина проработки проблемы… «Корневая причина: Неработоспособность БД. Накопление очередей SQL запросов»… Серьёзно?! Разработка / вендор — ни чем помочь не могут, DBA возможностей не видит.
«Потушили» проблему, «залив» её новым железом.. — идеальная модель решения проблем)
Попробую перефразировать данный опус. Менеджер проекта обо#%@лся, крайним остался отдел эксплуатации среды виртуализации. Из-за задействования резервных ресурсов, бедолаги теперь вынуждены решать не только проблемы горе-менеджера, но и «снежный ком» проблем от систем, уже находившихся в эксплуатации, ведь не зря же существовал резерв ресурсов!?
Но горе-менеджер не унывает, ведь есть Service Desk! Главное верно изложить контекст проблемы: { “корневая причина”: “неработоспособность БД”, “организационный фактор”: “кто угодно, кроме Я”, “зона ответственности”: “отдел эксплуатации виртуальной среды” }
Остаётся только «дёргать за нужные веревочки» для повышения приоритета выполнения «операции перезагрузки Postgre», чтобы снизить MTTR от простоя новодела.
Главное — грамотное разграничение ответственности между сотрудниками. Менеджер проектов не парится за реализацию обходных решений и развёртывание, мнение админа «за организационную составляющую» никого не интересует (снижаются затраты на футбол).
Такая модель управления хорошо подходит в ситуациях, когда некогда думать, сроки горят, и ничего нет.
P.S. последнюю фразу полностью позаимствовал из статьи, надеюсь автор не обидится.
В наиболее примитивных случаях построение "цифрового ядра" основывается на понимании бизнес-целей и декомпозиции KPI. И только спустя годы выясняется, что компания профукала по настоящему золотую жилу, когда решила не тратить ресурсы на сбор и накопление на первый взгляд "бессмысленной информации".
Статья - пустышка, про практику Data driven в ней ни слова
в первоначальном пресс-релизе Amazon Go тоже указывалось полностью автоматически, а на деле - индусы)
На профильном ресурсе маркетинговый булшит без технических потрошков - ну такое себе(
Я прежде всего про то, чтобы была возможность загрузить готовый xml-файл BPMN2.0 в lsFusion и уже на платформе обвязать его узлы декларативно и использовать в рабочих процессах.
А нет ли в планах "завезти на IsFusion" BPMN?
учитывая полное отсутствие технических делателей, выглядит как Amazon с 1000 индусов вместо ИИ
что позволено Юпитеру, то не позволено быку)
Самым сложным здесь представляется выполнение деперсонализации и обеспечение конфиденциальности (врачебной тайны)
Размещение в том же Yandex Object Storage вряд ли замедлит работу системы, другой вопрос - уложились ли бы вы в любезно выделенный Яндексом бюджет b2g под этот проект.
Опыт интересный, жаль что результаты пока не доступны для широкого круга исследователей.
Интересно, почему не выбрали готовые OTel и OpenTelemtry Collector, а начали со своего велосипеда?
пока гром не грянет, мужик не перекрестится