Kurgan-Telecom Ru | Информационные технологии

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

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

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

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

Но… помните, количество метрик, которыми вы собираетесь управлять компанией, должно быть разумно…

Но давайте прыгнем немного в очень даже реальную историю

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

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

Читать далее

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

Когнитивная наука подтверждает, что человеческий мозг использует два канала мышления — текстовый (вербальный) и визуальный (невербальный). Но современные мультимодальные модели (MLLM) чаще всего полагаются на текстовые объяснения даже там, где визуальное мышление было бы намного эффективнее. До мая 2025 года не было серьезных исследований, которые бы ответили на вопрос: могут ли современные модели решать задачи исключительно с помощью визуальной информации без использования слов?

Читать далее

Привет, меня зовут Александр Ткаченко. Сейчас я занимаю позицию исполнительного директора, но начал свой путь в банке как разработчик.Расскажу вам о том, как моя команда сократила время вывода продуктов в эксплуатацию с нескольких недель до 15 минут, увеличила скорость внедрения изменений в 19 раз, и почему модульная архитектура — это не просто модный термин, а реальный инструмент повышения гибкости и скорости. Ещё расскажу, как внедрить у себя этот подход, и как избежать сделанных нами ошибок. 

Если хотите вживую услышать доклады топовых спикеров, присоединяйтесь к конференции «Sbergile: продакты для продактов». 29 мая 2025 года она впервые пройдёт в открытом формате для всех — онлайн и бесплатно. Регистрируйтесь для участия!

Представьте: у вас есть несколько десятков сервисов, от CMS до систем аналитики и уведомлений. Одни написаны на Java, другие на Python, третьи используют ClickHouse или Greenplum. Вместо того, чтобы собирать всё в монолит, мы разбили их на сотни маленьких модулей, которые можно комбинировать как кубики Lego. И превратили во внутреннюю платформу «Среда», которая работает по принципу модульной микросервисной архитектуры. По сути, это конструктор, где каждый сервис или функциональность разбита на мелкие независимые модули. Платформа сама по себе ничего не делает, она лишь позволяет бизнесу самому соединять модули между собой и получать готовый продукт. Расскажу о том, как мы к этому пришли. 

Читать далее

На основе разговоров с выпускниками ведущих вузов Москвы и комментариев на Хабре.

___Военные/сотрудники спецслужб быстро и/или эффективно выучивают языки.

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

А спалишься на любой мелочи. Обычная шпана вычисляет самозванцев с полпинка: «Кого знаешь?» Штирлица не то, что не было – его быть не могло, потому что никогда ещё он не был так близок к провалу, как КАЖДУЮ СЕКУНДУ. Тем более под лупой гестапо. (Окей, персонаж Ю.Семёнова правдоподобный: набор исключительных качеств + хорошая легенда.)

Поэтому в реальной жизни разведчик работал не под видом местного, а под видом иностранца. И разведданные получал через завербованных МЕСТНЫХ чиновников и военных. Оно и сейчас так происходит. (То, что язык для разведчика – только полдела, мы даже не обсуждаем.)

Нет и не было никогда у спецслужб никаких суперэффективных методик. Уровень среднего выпускника ВИИЯ подразумевал вполне легальную работу военного переводчика, которому до носителя как до луны.

___Про детей.

Никто не спорит с тем, что они круто усваивают языки. Миф заключается в том, что они якобы делают это «легко» и/или «быстро». Очень многим детям ставят диагноз «задержка развития речи», и причины далеко не всегда патологические. Дети даже без этого диагноза в 3-м классе пишут прошедшее время глагола «цвести»: «цвестил», «цвестила». Школьные учителя могут и пострашнее истории рассказать...

По поводу детей и ин.языков: 42 секунды и с 30:02

Читать далее

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

Читать далее

Всех приветствую, читатели Хабра! В сегодняшней статье я поделюсь примером взлома уязвимой ОС Vulnix и энумерацией порта/сокета/службы smtp. После чего опять же пример брутфорса паролей

Примечание

Правовая информация:

Данная статья создана исключительно в ознакомительных/образовательных/развивающих целях.
Автор статьи не несет ответственности за ваши действия.
Автор статьи ни к чему не призывает, более того напоминаю о существовании некоторых статей в уголовном кодексе РФ, их никто не отменял:
УК РФ Статья 272. Неправомерный доступ к компьютерной информации
УК РФ Статья 273. Создание, использование и распространение вредоносных компьютерных программ
УК РФ Статья 274. Нарушение правил эксплуатации средств хранения, обработки или передачи компьютерной информации и информационно-телекоммуникационных сетей

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

Читать далее

Digital nomad - это человек, который добровольно решил сняться с якоря и жить свободно. Я к этой категории не отношусь. Меня скорее обстоятельства заставили сняться с большого тяжёлого якоря и двинуть куда подальше. Этим "куда подальше" оказались Штаты. Пока я жил во Владивостоке, я умудрился несколько раз отказаться от предложений с релокацией в Корею (Южную, на всякий случай уточняю), в Сингапур, в Канаду и США. Поэтому довольно иронично, что спустя 5 лет я оказался здесь.

В этой статье я больше хочу поделиться не тем как и почему я решил переехать, а скорее историей "оседания" там, куда приехал. Конкретно, я хочу затронуть три важных темы: культура и язык, быт, поиск работы. Это мой опыт, мой путь, конкретно про США (Калифорния). Кому-то он будет полезен - класс! Если кого-то это заденет за живое - сочувствую вам. Итак, пристегните ремни, мы...

садимся.

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

Каким образом?

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

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

В этой статье мы разберём, как устроен order book на биржах типа Binance, OKX и Bybit, и какие манипуляционные паттерны можно наблюдать в реальном времени. Мы изучим:

Читать далее

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

Читать далее

В прошлой части мы оставили немецких хакеров из группы Гесса и пытающегося поймать их Столла в весьма своеобразный момент января 1987 года. Немцы на подряде у советской разведки уже ощущали себя в американских сетях как дома — и хотя по-настоящему секретная информация лежала в изолированных от большого Интернета местах, для толкового OSINTера добытые ими вкусности вроде сопроводительных документов о планировании действий на случай войны в Европе могли рассказать многое. Меж тем Столла американские спецслужбы и западногерманские детективы продолжали морозить из-за проблем с формальностями. Чтобы вычислить адрес хакера в ФРГ, Клиффорд с его девушкой Мартой создали обширный фейковый свод документов по несуществующей военной сети SDInet — и благополучно его «скормили» адресатам. Вскоре сисадмин получил внезапное приглашение на закрытое совещание силовиков — и вскоре со смешанными чувствами он сидел в самолёте, несущем его через всю страну на авиабазу Боллинг под Вашингтоном. Читать дальше →

Любой, кто хоть раз пытался «по-быстрому» проанализировать CSV-файл или прототип БД, сталкивался с выбором из неудобств: открывать в Excel, запускать Jupyter, возиться с pandas, или поднимать Postgres/ClickHouse ради пары запросов. Мне показалось странным, что в 2025 году до сих пор нет удобной zero-setup SQL-песочницы для локальных данных.

Так родился PondPilot - open-source инструмент для анализа данных, работающий прямо в браузере, без серверов и настройки.

Читать далее

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

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

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

В книге «I am sorry, I Broke Your Company» (простите, я разрушил вашу компанию) Карен Фелан, бросает вызов стереотипной культуре, навязанной консультантами и специалистами по достижению успеха. Карен есть, что сказать: она имеет тридцатилетний опыт работы консультантом, является успешным руководителем в компаниях из списка Fortune 100. 

Читать далее

Мы команда проектировщиков интерфейсов Экзона, а Экзон — это продукт для цифровизации строительства.

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

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

Читать далее

Технические команды часто избегают лишней документации, но информация всё равно каким-то образом передаётся, сохраняется и развивается. В этой статье — попытка разобрать скрытые механизмы общения внутри инженерных команд: как выстраиваются негласные соглашения, каким образом рождаются "внутренние диалекты" и зачем вообще всё это, если есть JIRA, Confluence и куча других инструментов. Много примеров, блоков кода на разных языках и немного личного опыта.

Читать далее

После проведения HAZOP и формирования контуров безопасности ПСБ с определением целевого уровня полноты безопасности, нам, как инженерам реализующим систему безопасности прислали исходные данные: технологическая схема с КИП, перечень контуров безопасности, матрица причинно-следственных связей, значение целевого УПБ. Мы, как подготовленные инженеры, понимаем из чего могут быть построены контура безопасности, отвечающие заданному целевому УПБ. Осталось подобрать оборудование, собрать контура,  посчитать результирующее значение УПБ и сравнить его с целевым.

Если подходить к решению задачи правильно и грамотно, ПСБ еще на предыдущих этапах должна быть разделена на систему аварийного останова ESD и систему технологических защит PSD. ESD предназначена именно для предотвращения катастрофы, аварии и гибели людей. PSD предназначена для защиты оборудования и технологического процесса (например, не дает загубить катализатор в реакторе или выпустить некачественную продукцию). Позже, когда будем разбираться, в чем разница между ESD и ПАЗ разберем этот вопрос подробнее.

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

Весь перечень контуров безопасности сразу делим на две части: контура с целевым УПБ1 и ниже, и контура с целевым УПБ2,3. При объективно проведенном анализе рисков контуров УПБ3 будет очень ограниченное количество, обычно несколько единиц. Подобрать оборудование для обеспечения УПБ3 контура в целом достаточно сложно.

тут 30 станиц текста с формулами и графика

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

Можно выделить следующие слои безопасности:

- совершенствование технологического процесса с целью исключения опасных факторов – уменьшить давление в системе, снизить объем опасных веществ, изменить технологическую схему, уменьшить количество оборудования…;

- ОСУП (организация системы управления процессом) – контроль состояния оборудования, контроль за технологическим процессом, уменьшить количество персонала в потенциально опасной зоне, построить эффективную систему обучения и инструктажей …;

- система сигнализации о приближении к опасным границам и квалификация операторов – наладить полноценную систему сигнализации, выделить сигнализации приоритета 1, которые требуют незамедлительных действий от операторов, постоянно и квалифицированно вести анализ срабатывания сигнализации, максимально исключить ложные срабатывания, наладить систему постоянных тренингов для поддержания необходимой квалификации операторов (в правильно построенной системе, сигнализации уровня 1 срабатывают крайне редко при реальной угрозе аварии, количество параметров для крупного объекта не превышает 10-50, каждое ложное срабатывание детально исследуется, программа подготовки и квалификация операторов должны обеспечивать корректные действия персонала при срабатывании сигнализации). В правильно построенной системе, сигнализации должны быть разделены на аварийные и информационные, с разной схемой визуализации и разными журналами, но на практике все сигнализации собирают в один перечень, называют «Перечень сигнализаций и ПАЗ», и в системе управления нет разницы между сигнализацией о перегреве реактора и сигнализацией о низкой температуре теплофикационной воды в операторной. В результате в общий журнал сигнализаций каждый день пишется по 1000 записей, 999 из которых не имеют какого-то смысла.

Читать далее

В данной статье на примерах попробуем разобрать порядок построения системы безопасности технологического процесса на основе анализ рисков. Поскольку цель статьи постараться объяснить «нормальным инженерных языком» назначение и порядок создания системы безопасности технологических объектов на основе анализа рисков, придерживаться «процедур в соответствии с ГОСТ-МЭК..» и описывать процедуры я не буду.

Еще раз напомню, что любой технологический процесс или техническое устройство несет потенциальный риск – угрозу жизни и здоровью работающих или находящихся по близости людей. Риск есть всегда и для всех, все живое рискует погибнуть. Риск, которому мы все подвержены в повседневной жизни называют фоновым. Для каждого производства или технологического процесса существует значение риска, принятого как допустимое. При построении нового процесса или технологического объекта необходимо принять такие меры обеспечения безопасности, чтобы обеспечить расчетный риск не выше допустимого.

В целом порядок создания системы безопасности будет следующим:

- исследуем риски, выявляем факторы риска, оцениваем значение;

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

- если технологическими и организационными решениями снизить риск до приемлемого не удается, переходим к созданию приборной системы безопасности (ПСБ), определяем контура безопасности, оцениваем требуемый уровень полноты безопасности (SIL) контуров, строим систему аварийного останова (ESD);

Читать далее

Различие в подходах: нормы или анализ рисков.

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

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

В бывшем СССР сложилась система норм и правил, которые жестко регламентировали требования, как организационные, так и технические. Эта система была унаследована и РФ. Достаточно посмотреть «Общие правила взрывобезопасности для взрывопожароопасных химических, нефтехимических и нефтеперерабатывающих производств» утверждены приказом Федеральной службы по экологическому, технологическому и атомному надзору от 15 декабря 2020 года № 533. Документ содержит 70 страниц ценных указаний. И таких «нормативных документов» у нас бесконечное количество, при желании можно найти «нормативку» на все случаи жизни. Соответственно проектировщику не надо понимать процесс, детально знать все особенности технологии, иметь опыт эксплуатации, достаточно просто найти нужную «нормативку» и выполнить все требования. Эксперт при проведении экспертизы проектной документации также проверяет технические решения на соответствие «нормативке», и инспектор Ростехнадзора тоже будет проверять объект на соответствие этой же «нормативке». При этом никого не волнует, на сколько обеспечена реальная безопасность технологического процесса (технологической установки), эффективность и достаточность принятых решений, возможность устойчивой работы оборудования и т.д. Соответствие нормам снимает ответственность за конечный результат со всех – проектировщиков, экспертов, инспекторов, и перекладывает всю ответственность на эксплуатацию, людей, которые непосредственно работают на технологической установке и реально рискуют своей жизнью.

действительно интересно?

Что такое безопасность технологического процесса или технической системы (устройства), что такое риск и вообще зачем все это?

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

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

Данная статья, это попытка техническим инженерным языком объяснить подход к построению систем безопасности технологических объектов (технических устройств) на основе анализа риска и функциональной безопасности. В основу статьи положен собственный опыт участия в процедурах анализа рисков и построения функциональной безопасности, определения уровня SIL для контуров безопасности, формирования требований к техническому обслуживанию и периодичности испытаний систем противоаварийной защиты для сложных технологических установок переработки нефти. Статья полностью написана самостоятельно и не является переводом с англоязычных источников. Поскольку это собственный опыт, не буду утверждать, что все изложенное абсолютно правильно и объективно, возможны ошибки, недопонимание основополагающих положений стандартов, и вообще поверхностный и однобокий подход. Прошу понять и простить.

для тех, кому это интересно