Анализ и проектирование систем *

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

Ниже я буду рассказывать о своем опыте. Сайтами я занимаюсь  уже порядка 15 лет, а вплотную – около 10 лет. Почему это так? Сейчас любая трансформация в организации, любые изменения в организации, так или иначе, касаются информационных систем. То есть, если мы хотим получить продажи, мы должны создать сайт. Если мы хотим повысить качества сервиса, то, скорее всего, это должно каким-то образом отображаться на сайте, например, в личном кабинете и как следствие ведет за собой создание нового сайта.

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

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

В данной статье делимся опытом внедрения решения на базе СУБД ClickHouse и сервисов Yandex Cloud. Мы не коснёмся тонких настроек ClickHouse или его масштабирования, но затронем достаточно интересные на наш взгляд темы:

• как загружать данные из On-premise в облачный ClickHouse с использованием сервисов Yandex Cloud – Functions, Object Storage, Message Queue;

• как обрабатывать/преобразовывать данные в облачном ClickHouse – очищать и строить витрины; какие «подводные камни» нам встретились на этом пути.

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

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

- мощности и производительности

- безопасности, соответствию стандартам и законодательству

- переносимости и совместимости.

Когда говорят о выборе архитектуры IT-системы, почти всегда упускают один ма-а-аленький нюанс: мы делаем продукты для пользователей, не для себя. А пользователям совершенно неважно, какая у сервиса архитектура. Никто в отзывах не ставит звёздочки за event-driven подход или классную реализацию service mesh — разве что в редких случаях, когда речь о продуктах для разработчиков. 

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

Привет! 24 сентября (суббота) мы в Sportmaster Lab проведем One Day Offer для системных аналитиков в онлайн-формате.

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

В целом же механика события выглядит так:

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

Система поддержания уровня металла в кристаллизаторе компании Vesuvius Sert (Франция) как рождественский слоёный пирог, пропитанный насквозь изысканным французским коньяком. Чем глубже ковыряешся в деталях, тем более утончённые вкусы всплывают на поверхность.

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

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

Это текст появился в процессе работы над лекциями по теории автоматического управления (пример лекции здесь...), когда я заметил, что мой уровень подготовки явно ниже, чем требуется для этих лекций, при том, что с математикой у меня всегда было хорошо. Более того, я когда-то сдал курс по этим лекциям на честную «тройку», но мне материал кажется очень сложным. Поразмышляв, я пришёл к выводу: проблема в том, что я не использовал этот математический аппарат в деле, а сразу перешел к моделированию на компьютере.  Что, как мне кажется, совсем не положительно сказалось на моей сообразительности. И все из-за этих чертовых компьютеров.

Далее текст-предположение, кто виноват и что делать.

Торговая система QUIK ^{_{[ссылка удалена мод.]}} для большинства серьёзных игроков рынка является очень популярной системой предоставления своим клиентам интерфейса для торговли ценными бумагами. Но в большинстве своём внутренности этой системы, как и любого коммерческого продукта являются закрытыми, в связи с чем могут возникать проблемы интеграции во внутреннюю инфраструктуру предприятия. В этой статье будут рассмотрены возможные механизмы интеграции QUIK в системы предприятия являющегося клиентом брокера или самостоятельным брокером.

Привет, Хабр! На связи снова Юрий Кацер, эксперт по ML и анализу данных в промышленности, а также руководитель направления предиктивной аналитики в компании «Цифрум» Госкорпорации “Росатом”.

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

Интеграционная или shared база данных это архитектурный подход с которым мне часто приходилось сталкиваться, и практически никогда эта встреча не сулила ничего хорошего. Как правило, команда выбирает данный подход по нескольким причинам:

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

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

Не надо снимать бэкапы с нескольких хранилищ, если можно снимать с одной единственной БД.

Как и многие другие вендоры ПО, 1С давно предлагает свои продукты в облачном варианте. Это, в первую очередь, наши облачные сервисы 1С:ГРМ (Готовое Рабочее Место) и 1cFresh. Предоставление облачных сервисов требует наличия соответствующей инфраструктуры – прежде всего серверов, на которых размещаются виртуальные машины с приложениями, и софта, управляющего физическими и виртуальными машинами.

Чем сложнее инфраструктура, тем выше вероятность возникновения ошибок. Своевременно исправлять ошибки (а ещё лучше – предсказывать их возникновение и своевременно реагировать) – одна из главных задач провайдера облачных сервисов. Для таких задач разрабатываются системы интеллектуального мониторинга, которые помогают в сопровождении больших облачных продуктов. И у нас такая система тоже есть, мы разработали её сами на Java. О ней мы и хотим рассказать.

Всем привет, мы – Таня и Лиза, системные аналитики в МТС Банке, работаем над мобильным приложением и сайтом для физических лиц. В этой статье мы поделимся опытом внедрения структурированного шаблона функциональных требований (ФТ) к разработке ПО в нашем банке.

Статья будет полезна тем, кто работает с фронтовым функционалом – системными и бизнес-аналитикам. Неважно, Junior вы или Lead, в большой работаете компании или в стартапе, – наш рассказ вас наверняка заинтересует. Поговорим не только о том, как мы докатились до такой жизни, приняли единый формат ФТ, но и том, какие именно артефакты аналитик готовит в ходе своей работы. А еще мы подробно расскажем про причины поиска подходящего формата, сложности перехода и составляющие наших ФТ. 

Добро пожаловать под кат!

Привет, Хабр! Мы Сабина Бадирханова и Светлана Юдина из UX-лаборатории Сравни и сегодня хотим поделиться нашим опытом создания и развития направления UX-исследований в компании. Мы расскажем, с чего всё начиналось, к каким результатам удалось прийти и как получилось встроить исследования в общий дизайн-процесс, не вызвав активного сопротивления коллег.

Привет, Хабр! На связи Юрий Кацер, эксперт ML и анализу данных в промышленности, а также руководитель направления предиктивной аналитики в компании «Цифрум» Госкорпорации “Росатом”.

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

Сегодня хочу поговорить на примере этого проекта о реализации data science проектов в промышленности. С подобным докладом я также выступал ранее, видео выступления доступно по ссылке. Обычно нашей основной задачей является разработка моделей на основе данных, но работает ли такой подход всегда? Давайте поговорим об основных этапах и проблемах таких проектов и посмотрим, как мы двигались к финальному результату на примере проекта по диагностике электролизеров.

Краткое руководство по гарантированному получению льгот ИТ-компанией.

Легко получить, легко потерять.

Всем привет! Меня зовут Филипп Бочаров, я руководитель центра мониторинга и наблюдаемости в МТС Digital. Мы с командой делаем платформу Наблюдаемости – это набор сервисов, который позволяет сделать работу других продуктов МТС прозрачной и понятной. Сегодня я расскажу про распределенную трассировку экосистемы МТС. 

Давайте вместе спроектируем коммунальную систему, в которой соберем распределенную трассировку всей нашей экосистемы. Отмасштабируем ее от 0 до 50 тысяч документов в секунду и посмотрим, как меняется наша архитектура, откуда берутся потери и пиковые нагрузки, какие есть пределы и ограничения. В общем, постараемся выжить под нагрузкой!

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

Под катом: формат данных, способы отправки, типы метрик и их применение, кардинальность.

Этот пост является дополнением предыдущего. В нём расскажу о новых возможностях инструмента (с блэкджеком и шлюпками с примерами и картинками).