Обновить
64K+

Инженерные системы *

Инфраструктурные и инженерные системы

223,39
Рейтинг
Сначала показывать
Порог рейтинга

«Сибур-Нефтехим» заработал 160 миллионов рублей на том, что закончил ремонт на восемь суток раньше.

Меняли катализатор в реакторах окисления этилена. Раньше на это уходило 28 суток на каждую линию, и всё это время установка стоит. В этот раз одну линию закрыли за 25 суток, вторую за 23. Установка отработала выигранные сутки и дала лишние 4,5 тысячи тонн продукции.

Катализатор меняют в вертикальных реакторах объемом 50+ кубометров
Катализатор меняют в вертикальных реакторах объемом 50+ кубометров

Опыт этого ремонта не остался на площадке: его разобрали, оформили и передали на другие заводы компании. Несколько лет назад так бы не вышло.

Поговорили с Василием Можаровым. Он отвечает за систему управления знаниями в СИБУРе. Вот что рассказал:

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

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

Сложить документы в одно место оказалось мало

За пару лет мы набрали в базу больше 20 000 страниц. Новые появлялись быстрее, чем мы успевали проверять старые. Документ по названию ещё найдёшь, а решение, о котором не знаешь, уже нет.

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

Пора вмешиваться, когда появляются дубли или люди жалуются, что ничего не найти.

Разделы мы нарезали по задачам, а не по отделам

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

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

Ждать, что сотрудник сам расскажет о своей практике, не стоит

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

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

Всё это оформили как лучшую практику и передали на «Нижнекамскнефтехим» и другие предприятия, где меняют катализатор.

Один реестр мы отдали языковой модели целиком

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

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

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

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

Владельцев разделов и регламент обновления мы завели задолго до всякого ИИ. Восемь суток на ремонте катализатора выиграли тоже без него.

Подписывайтесь на наш тг‑канал. Он полезен айтишникам, которые хотят понять, что реально происходит в промышленном ИТ.

Теги:
-3
Комментарии0

Про нестандартные решения и продуктовых инженеров

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

***

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

Так вот, мы по-прежнему командами работаем. Небольшими командами. Может быть расскажу как-нибудь об этом подробнее.

Но сегодня о другом.

Обновили и утвердили очередную методологию процесса разработки. В моменте все счастливы. Но вы думаете она нас сделает успешными? Ну нет конечно.

Успешными людей и компании делают нестандартные решения.

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

Либо вы дурак или новичок, что в данном случае практически равноценно, и просто еще не знаете, что так нельзя.

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

Все, кто посередине, обычно лучше всех знают, как правильно. 

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

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

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

Решил об этом не в командных чатах, а с трибуны, как Владимир Ильич. Может кому тоже полезно будет. 

Неотправленный пост моим командам:

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

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

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

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

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

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

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

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

Другими словами, включает голову, по полной.

Теги:
+1
Комментарии0

Прицепить газоанализатор к дрону мы собирались за вечер. Провозились 3 месяца и поменяли крепление, корпус прибора, протокол связи и сам дрон.

Поговорили с Андреем Лантратом, он руководит робототехникой и беспилотными технологиями в Цифровом СИБУРе. Вот что рассказал:

У «Запсибтрансгаза» больше 3000 км трубопроводов в Сибири, и добраться до многих точек трудно даже летом. Труба лежит прямо на дне в тех местах, где пересекает реку. Каждый подводный участок надо регулярно проверять на утечки.

По трубе идёт ШФЛУ — широкая фракция лёгких углеводородов. Проще представить её как «недобензин»: те же углеводороды, что в топливе, только легче и летучее. Из-за этой лёгкости продукт при утечке не расплывается по реке пятном, как нефть, а выходит из воды и испаряется в воздух. Значит, и ловить его логичнее в воздухе.

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

При этом мы мерили не то

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

Все превышения, которые мы находили в воде, давали соседи-нефтяники, их в регионе хватает. А свою ШФЛУ этот анализ не показывал вообще. Поэтому мы взяли газоанализатор с детектором пропана — он ловит как раз те газы, из которых состоит ШФЛУ, — и подняли его в воздух на дроне.

Искали место для газоанализатора

Готового решения не было: производители не рассчитывают, что дрон будет летать с газоанализатором.

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

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

На морозе трескался пластик и падал заряд

Крепления мы печатали на 3D-принтере, и обычный пластик зиму не выдержал: в тепле он держал, а на морозе трескался, как дешёвая игрушка, которую оставили на балконе в минус тридцать. А если крепление лопнет над водой, прибор уйдёт на дно. Пришлось искать морозостойкий пластик.

Триста граммов оказались перегрузом

Газоанализатор весит около трёхсот граммов, как полный стакан воды. Первый дрон с такой нагрузкой летал 3 минуты вместо 15-20. Обидно было упереться в грузоподъёмность после всей возни. Взяли аппарат мощнее.

В тайге нет связи, данные отправляли по «рации»

Сотовых вышек в тех местах нет. Обычный переносной газоанализатор пишет данные в память, а нам надо было отдавать показания сразу оператору. Взяли LoRaWAN — это протокол, который работает как рация: связывает передатчик и приёмник напрямую, без вышек и оператора связи. В тайге он достаёт на 2–5 километров, в открытом поле на 15–20.

Оператор берёт приёмник с собой и видит показания на дашборде — открывает его прямо в поле с телефона.

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

Подписывайтесь на наш тг‑канал. Он полезен айтишникам, которые хотят понять, что реально происходит в промышленном ИТ.

Теги:
+1
Комментарии3

Границы между системным администрированием, DevOps и DevSecOps сегодня настолько размыты, что часто на сайтах поиска работы пишут: «Ищем DevOps-инженера со знанием безопасности».

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

Обсуждаем это всё в новом подкасте #Криптонит_говорит о системных инженерах!

Смотрите на любой удобной платформе:

В выпуске приняли участие:

  • Александр Телевной, директор департамента инфраструктуры в «Криптоните»;

  • Артём Пузанков, руководитель отдела консалтинга безопасной разработки в «Бастионе»;

  • Иван Морщагин, ИТ-консультант

Теги:
+1
Комментарии0

Как «Страна Девелопмент» перевела всю ИТ‑инфраструктуру в облако и ускорила проектирование

🏭Что за компания
«Страна Девелопмент» — федеральный девелопер с 17‑летним опытом, который строит жилую и коммерческую недвижимость в Тюмени, Екатеринбурге, Новосибирске, Санкт‑Петербурге, Москве и Подмосковье. Компания закрывает полный цикл — проектирование, строительные и подрядные работы, технический надзор, продажи, гарантийное обслуживание и управление недвижимостью. Параллельно с этим компания разрабатывает собственные отраслевые ИТ‑продукты.

⚡ Задача
Инфраструктура была разделена между собственными физическими серверами и облаком сторонней площадки, где не хватало ни запаса ресурсов, ни набора сервисов, ни нормальной поддержки контейнеризации. Отдельной проблемой были рабочие места проектировщиков: на видеокартах T4 крупные BIM‑модели приводили к «черному экрану», результаты работы терялись, схемы прорисовывались медленно. Бизнес требовал не менее 50 новых удаленных рабочих мест в месяц, но скорость проектирования падала из-за медленной коммуникации (сотрудники были разбросаны по разным городам) и нехватки компьютеров.

☁️ Что сделали
Сначала девелопер протестировал платформы Облако VMware и Cloud.ru Advanced, построил сетевой канал до дата‑центра и примерно за два месяца ушел с локальных серверов и от прежнего провайдера. Потом в виртуальный ЦОД переехали standalone‑приложения, 1С и внутренние продукты — со временем это выросло до 120 серверов, с резервным копированием и объектным хранилищем S3. Разработку вынесли на Cloud.ru Advanced: сервис контроля качества и сроков работы подрядчиков собрали на Cloud Container Engine (Kubernetes), пропускную способность обеспечили распределенным брокером сообщений Kafka, туда же перенесли корпоративный портал и подключили защиту от DDoS. После развернули VDI с GPU под проектировщиков: 18‑ядерные процессоры от 3 ГГц, карты A40, высокочастотная DDR4 и сертифицированные инженеры VMware на стороне провайдера обеспечили удобство работы и высокую скорость миграции. Первые 200 рабочих мест из 600 запланированных настроили уже за первые две недели, при плане рассчитанном на два месяца.

🦾 Что получили в итоге
Вся ИТ‑инфраструктура девелопера теперь работает в облаке Cloud.ru. Оно держит растущую нагрузку и остается отказоустойчивым, SLA и обслуживание оборудования перешли к провайдеру: внутренняя команда больше не тратит время на железо и обновления. Cloud.ru Advanced стал платформой для новых продуктов компании, часть из которых регистрируется в реестре отечественного ПО Минцифры. Сейчас девелопер арендует 850 виртуальных рабочих мест с A40: архитекторы со всех уголков страны работают в единой инфраструктуре и подключаются к моделям прямо на Revit‑серверах, не выкачивая их на локальные машины. Производительность специалистов выросла на 30%, что дает до десяти дополнительных объектов в проектировании за год, а гибкая тарификация снизила расходы на инфраструктуру. Дальше в планах — Managed Arenadata DB для задач big data, пилот платформы Cloud.ru Evolution и новые типы виртуальных рабочих мест, в том числе сессионные.

Читайте подробнее на сайте.

Теги:
0
Комментарии0

Представлен открытый набор навыков text-to-cad для ИИ-агентов для инженеров, чтобы создавать детальные CAD-модели. Достаточно описать нужную деталь, а ИИ-агент сам строит модель с экспортом в STEP, STL и другие форматы. В комплекте есть просмотр в браузере, поиск готовых винтов, подшипников и моторов, проверка толщины стенок и нависаний перед 3D-печатью. Работает не только с Codex, но и с Claude Code и другими ИИ-агентами.

Теги:
+7
Комментарии0

Люди восстали против ИИ

В США введено уже более 500 ограничений в отношении создания ЦОДов для ИИ в различных штатах. Причина — в протестах жителей против возведения новых дата-центров: такие объекты требуют значительного количества воды и энергии. В результате для местных жителей эти ресурсы дорожают или вовсе оказываются недоступны.

Теперь компаниям недостаточно просто денег, чтобы ввести в строй новый дата-центр. А как же законы свободного рынка?

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

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

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

Человек может успешно воевать против ИИ, только потом он вернётся домой и захочет запустить LLM — кажется, в интересах обеих сторон договориться.

Теги:
Всего голосов 12: ↑11 и ↓1+22
Комментарии1

Письмо на завод Mechanic:

我數了你們盒子裡的焊錫已經11年了──有時是9999個,有時是10002個,甚至有時是9998個。你們是不是都瘋了?

Теги:
Всего голосов 10: ↑9 и ↓1+10
Комментарии3

Хабр и коммуникационное агентство FRC проводят двойное исследование о том, как технический контент влияет на решения инженеров. «Мы хотим сравнить взгляд тех, кто создаёт этот контент, и тех, кто его читает», — пояснили организаторы опроса.

Опрос для инженеров «Отраслевое расследование в 3 сериях: контент, которому (не) верят» займёт 10–15 минут. Все ответы анонимны и будут использоваться только в обобщённом виде.

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

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии0

Мы делаем легкую опенсорс PDM систему, под названием DraftSync.ru
Сама идея возникла очень давно, наблюдая за процессом работы инженеров конструкторов небольших КБ задаешься вопросом: почему у них нет нормальный процессов, как у нас в IT ?

- Контроль версий
- Ревью
- Демонстрация заказчику
- База доступна и всегда под рукой
- Поиск среди кучи различных сущностей, заказчиков и ТД
- Работа с одной базой разных CAD в одном месте

Да, PDM существуют и существуют уже очень давно!, но они тяжелые, сложные и СТАРЫЕ - мы хотим это поменять

Прошу сообщество помочь мне в этом и ответить на несколько вопросов тут: https://forms.gle/tUVgtkm9RjAkh4xJ8
Буду очень благодарен за поддержку всем!

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии1

Прилетело и в очередной раз и резануло по живому...

Системность - это ... (продолжите фразу)

Системность - это модное словечко из лексикона "эффективных менеджеров", которое скорее вводит в заблуждение, чем отражает суть.

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

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

Вот только системный подход - это системный подход, а системность - это признак системы. И как признак системы это ...

НЕ ПРО ПОРЯДОК!

Системы вообще никакого отношения к порядку не имеют - любая система стремится к хаосу (тут умное слово - энтропия).

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

некоторый полет мысли имени очень искусственного как бы интеллекта
некоторый полет мысли имени очень искусственного как бы интеллекта
Теги:
Всего голосов 4: ↑3 и ↓1+4
Комментарии0

NVidia анонсировала, что для их новой ЦОДовской AI платформы DSX система охлаждения работает на базе горячей воды.

https://blogs.nvidia.com/blog/liquid-cooling-ai-factories/

Основная идея - спроектировали систему, в которой все компоненты охлаждаются не воздушным потоком, как в классических ЦОДах с подачей охлажденного воздуха в "холодный коридор", а непосредственно водой. Причём - охлаждаем непосредственно водой до уровня чипов.

Причем - гораздо более горячей водой, чем обычно. В классических системах воду, подаваемую на внутренние межрядные блоки системы кондиционирования, надо охлаждать градусов до 10°. А NVidia спроектировала систему, у которой даже на входе в сервера поступает ода с температурой 45° С. На выходе же - и все 55° С.

В результате существенно меньше разницы температур на входе и выходе системы охлаждения - можно снаружи обойтись сухими градирнями. И в итоге - сократить до нуля текущие потери воды на испарение. Составляющие, по оценке Нвидиа - до 2.6 миллионов галлонов (~10 000 куб.метров) воды в год на каждый мегаватт мощности.

Теги:
Всего голосов 2: ↑1 и ↓1+2
Комментарии1

Модернизировали дата-центры для быстрого внедрения ИИ

Команда Yandex Infrastructure модернизировала подход к строительству и охлаждению дата‑центров. Новая концепция кампусов дата‑центров и внедрение жидкостного охлаждения поможет ускорить создание и вывод на рынок ИИ‑сервисов Яндекса.

Концепция «кампус дата‑центров». Кампусы — несколько независимых дата‑центров в одной локации с общей внешней инфраструктурой. Команда внедрила концепцию кампусов, чтобы повысить эффективность использования ресурсов, снизить издержки и увеличить мощности в три раза до 180 МВт — рекордного в России показателя.

Жидкостное охлаждение. Для модернизации существующей инфраструктуры инженеры компании разработали сайдкары — дополнительные стойки с жидкостно‑воздушными радиаторами. Они позволяют использовать жидкостное охлаждение в дата‑центрах с фрикулингом без масштабной реконструкции. Сочетание двух технологий обеспечивает эффективное терморегулирование и ускоряет адаптацию инфраструктуры к растущим нагрузкам. 

Благодаря фрикулингу и отказу от доохлаждения дата‑центры Яндекса уже достигают показателя энергоэффективности PUE 1,1. Внедрение жидкостного охлаждения позволит дополнительно снизить энергозатраты и повысить экологичность дата‑центров, делая их ещё более «зелёными».

Теги:
Всего голосов 8: ↑8 и ↓0+10
Комментарии0

Ближайшие события

Два месяца бесплатного тестирования ВИДЕОБЛЕЙЗЕРА

Для всех, кто ценит честный подход и свободу выбора

ОФИЦИАЛЬНАЯ ОФЕРТА!

Каждый желающий может приобрести видеоблейзер - умный видеорегистратор на основе нейросетей, протестировать его в реальных условиях и — если вдруг устройство не подойдёт — вернуть без объяснения причин.

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

Спецлаб дает 60 дней на возврат оборудования и ПО без каких-либо вопросов. Единственный возможный расход — пересылка.

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

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

И самое удивительное — за всё время ни один тестировщик так и не вернул оборудование.

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии0

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

Теги:
Всего голосов 10: ↑5 и ↓5+2
Комментарии2

Кто такой UX/UI разработчик на практике?

Чем он занимается в реальной приземленной разработке?

P.S. делаю программу для завода и глазам больно от интерфейса

Теги:
Рейтинг0
Комментарии4

llm-nano-vm v0.8.0 — выход в PyPI, валидация вывода и per-step таймауты

В прошлом посте мы описывали концепцию nano-vm — детерминированного ядра исполнения на базе конечных автоматов (FSM) для LLM-воркфлоу, где модель не является оркестратором, а лишь предлагает действия внутри жесткого графа \delta(S, E) \to S'.

За это время проект перерос стадию концепта. Мы опубликовали рантайм на PyPI и выпустили релиз v0.8.0. Ниже — сухой отчет о том, что конкретно было сделано, измененено и протестировано.

Что нового в v0.8.0

1. Выход на PyPI и релиз пакетов

Рантайм и сопутствующие компоненты полностью изолированы и доступны для установки:

pip install llm-nano-vm==0.8.0
pip install llm-nano-vm[litellm]==0.8.0   # поддержка провайдеров через LiteLLM
pip install nano-vm-mcp                    # MCP-шлюз

2. allowed_outputs — LLM enum guard

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

{
    "id": "classify",
    "type": "llm",
    "prompt": "Classify. Reply ONLY with: refund / query / other",
    "allowed_outputs": ["refund", "query", "other"],
    "on_error": "skip",   # → подставит "refund" (первый элемент) на mismatch
}

Реализовано три политики обработки ошибок: fail (trace \to FAILED), skip (подстановка allowed_outputs[0]) и retry (перезапрос модели до max_retries).

3. timeout_seconds + on_timeout — таймауты на уровне шага

Решена проблема «зависания» внешних LLM API. Любой llm-шаг теперь можно ограничить по времени выполнения с политиками fail или fallback (подстановка дефолтного значения без падения автомата).

4. Стабилизация ASTEngine

Мы окончательно избавились от eval() для условий (condition). Написан кастомный песочный интерпретатор JSON AST. Любые системные вызовы и скрытые вызовы методов (вроде .lower()) теперь вызывают ASTEvalError на этапе компиляции графа.

Результаты бенчмарков (v0.8.0 · WSL2 · Python 3.12)

Тесты производительности на синтетическом адаптере (3 провайдера \times 5 сценариев \times 10k итераций) показали 1,096,500 операций и 0 нарушений контракта графа.

СценарийСредний TPSp95Refund pipeline2,200/s123 msDouble-execution guard2,800/s69 msBudget enforcement2,400/s97 msParallel throughput1,000/s196 msGovernanceEnvelope (аудит-лог)2,100/s108 ms

  • Crash consistency (BM-INT-07): При crash_rate=100% повторное воспроизведение (replay) пайплайна после симулированного падения рантайма выдает идентичный хэш трейса в 100% случаев.

  • Memory leak test (BM-INT-10): Пиковый RSS — 76.5 MB, аллокация — 3.62 MB для программ на 1000 шагов. Утечек памяти нет.

Валидация на реальных платежных API

Концепт успешно проверен на двух интеграционных сценариях (9/9 тестов пройдены):

  1. MoMo Payment API v4: 3-way ветвление, HMAC-SHA256 IPN верификация, цикл пуллинга статуса с ретраями.

  2. Stripe Payment API v1: Обработка 3DS-флоу (REQUIRES_ACTION), refund-пайплайн и верификация вебхуков.

В процессе интеграции со Stripe пофиксили важный баг: коллизию доменного статуса "PENDING" от API Stripe с внутренним сентинелом рантайма, который триггерил заморозку (SUSPEND) автомата.

Текущий фокус и краткосрочный роадмап

  • Phase 0: Разработка ProgramValidator для статического анализа графов до их выполнения (поиск циклов, недостижимых шагов и битых таргетов). Актуально, когда сами программы генерируются «на лету» внешними моделями.

  • Phase 1: Консистентность шлюза. Перенос StateContext между вызовами MCP в SQLite WAL (execution_contexts + UPSERT на каждый шаг). Это полностью уберет риск повторного списания (Double-Spend) при перезапуске процесса шлюза.

  • Phase 2: Интеграция OpenTelemetry для распределенного трассирования шагов.

Репозитории проекта:

Теги:
Всего голосов 3: ↑1 и ↓2-1
Комментарии0

ИИ не должен управлять исполнением. Заметки о детерминированном FSM-рантайме для агентов

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

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

В процессе подготовки части наших внутренних агентов к деплою, мы пришли к необходимости полностью разделить процессы «рассуждения» (reasoning) и право на исполнение (execution authority).

Мы написали nano-vm — детерминированный FSM-рантайм (конечный автомат), в котором:

  • модель лишь предлагает действия;

  • рантайм жестко контролирует переходы состояний и сайд-эффекты.

Рантайм принудительно обеспечивает:

  • конечные графы исполнения;

  • строгий порядок шагов, зафиксированный при компиляции (compile-time ordering);

  • capability-gating для инструментов (жестко изолированные доступы);

  • границы идемпотентности и защиту от replay-атак;

  • append-only историю аудита.

Одно из архитектурных решений, которое оказалось критически важным: слой политик намеренно сделан менее выразительным, чем Python.

Мы полностью отказались от eval-подобного исполнения и ограничили политики небольшим детерминированным подмножеством AST:

  • только простые операторы;

  • никаких циклов;

  • никаких системных вызовов.

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

Sabotage Mode и семантика отказов

Чтобы протестировать семантику отказов, мы добавили в демо-стенд «Sabotage Mode» с несколькими векторами атак:

  • неавторизованная инъекция инструментов (tool injection);

  • попытки повторного выполнения (replay-атаки);

  • подделка хешей (hash corruption);

  • пропуск шагов пайплайна (skipped transitions).

С точки зрения эксплуатации самым полезным свойством пока оказались именно детерминированные границы повторного воспроизведения вокруг сайд-эффектов.

Нам также пришлось решать крайне неудобную compliance-проблему: как сохранить неизменяемые цепочки аудита (immutable audit chains) и при этом выполнить требования 152-ФЗ / GDPR об уничтожении данных. Наш текущий подход заменяет ссылки в хранилище на маркеры-надгробия (tombstones), полностью сохраняя криптографическую непрерывность хешей и ссылочную целостность графа.

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

Теги:
Рейтинг0
Комментарии0

Скрупулёзность и вертикальная интегрированность.

Trinasolar недавно (месяц назад) официально презентовала новую линейку солнечных модулей Vertex N G3. G3, наверное, это третье поколение, но факт в том, что у двух моделей этой серии, а именно NEG21C.20Q (760Вт) и NEG19RC.20Q (670Вт) повысился КПД относительно предшественников. Причём, прилично. С 23,3% до 24,5% и 24,8% соответственно. То есть, в минимуме на 1,5%.

Новые линейки модулей от Trina Solar
Новые линейки модулей от Trina Solar

Обе модели являются двусторонними и в связке с трекерами от той же Trina – Vanguard 1P от Trinatracker – позволяют не просто добиться шикарных результатов выработки, но и снизить не только LCOE (средняя расчётная себестоимость производства электроэнергии на протяжении всего жизненного цикла электростанции), но также и BOS (это расходы, связанные с компонентами системы, которые необходимы для её функционирования, но не включают стоимость самих солнечных панелей). Наверное, Вангарды ребята продают «в нагрузку» с новыми модулями с какой-то специальной скидкой.

Ещё, в пресс-релизе написано, что модули Vertex N G3 шикарно подходят «для задач AIDC (AI Data Center), которые требуют не только достаточной выходной мощности, но и долгосрочной стабильности, простоты крупномасштабного развертывания и низкого LCOE» (цитата). Но, судя по тому, что у них стекло и спереди и сзади по 2мм, я что-то сильно сомневаюсь в том, что они более надёжны, чем такие же, но со стеклом 3,2мм или даже 2,5мм. Но что поделать? За выходную мощность приходится платить рисками. Ну, про гарантию написано, что она 30 лет, но только на выходную мощность. На конструкцию гарантийных обещаний я не нашёл. Если вы найдёте – маякните в комментариях.

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

#trinasolar #презентации #Китай #КПД Больше новостей солнечной энергетики рассказываю у себя в канале "Солар-Ньюс"​ (https://t.me/Solarnews)

Теги:
Рейтинг0
Комментарии2

Прибыль Samsung от производства чипов на фоне спроса на ИИ выросла в 48 раз

Аналитики ожидают, что подразделение Samsung увеличит свою рекордную прибыль в течение следующих нескольких кварталов, поскольку контрактные цены продолжают стремительно расти на фоне ограниченного предложения. Они указывают на рост экспорта полупроводниковых приборов из Кореи в 2,8 раза за первые 20 дней апреля.

Полный текст новости по ссылке: https://www.kommersant.ru/doc/8633092

  1. Просто значение немного удивило: 48. Даже немногим лучше чем ответ на все вопросы Вселенной!😁

  2. Радует (лично меня, как желающего увеличить память своего ПК) новость от производителя оборудования для литографии. Количество литографического оборудования, заказанного для производства чипов памяти, за последний год превысило число заказов для производства CPU.

    2.1. Год назад литографы, в основном, заказывали для производства CPU.

    2.2. Ссылку на новость про литографическое оборудование сходу не нашёл. Но это было примерно месяц назад, тут же на Habr.

  3. IMHO сугубо, много желающих включиться/вложиться в производство памяти. Через сколько времени пойдет производство памяти на максимум, вот тут предположения высказывать не возьмусь. Но желающих заработать на этом (и не только этом) "железе" много!

Теги:
Всего голосов 1: ↑0 и ↓1-1
Комментарии0