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

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

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

Domain-Driven Design подход проектирования давно уже не новые слова, однако и не самая раскрытая тема. Я попытался объснить концепцию такого подхода к проектированию на собственных примерах.

Современная разработка ПО – это почти всегда про распределенные системы. Микросервисы, облака, глобальный охват – все это стало нормой. Но за красивыми диаграммами и модными словами скрывается фундаментальная сложность. Как заставить кучу разрозненных компонентов работать вместе надежно? Как гарантировать, что данные, размазанные по сети, останутся корректными и доступными? Эта головная боль знакома любому, кто проектировал системы сложнее калькулятора, будь то в требовательном финтехе, динамичном e-commerce или где-либо еще.

И вот тут на помощь (или, скорее, для обозначения поля боя) приходят три понятия: ACID, BASE и теорема CAP. Может показаться, что это сухая теория, но игнорировать их – все равно что выходить в море без компаса и карты. Эти концепции описывают фундаментальные компромиссы, с которыми приходится иметь дело каждому архитектору. Понимание их – не гарантия успеха, но его необходимое условие. Давайте погрузимся в их суть и посмотрим, как они влияют на реальные архитектурные решения.

Переход на микросервисы – это часто как переезд из тесной, но понятной коммуналки (монолита) в огромный город с кучей отдельных квартир. Свободы больше, масштабироваться проще, команды независимы – красота! Но тут же вылезает проблема, о которую разбиваются многие корабли: как поддерживать порядок и целостность данных, когда они размазаны по десяткам этих "квартир"-сервисов со своими собственными базами данных?

Старый добрый ACID, который спасал нас в монолитах с одной большой базой, здесь уже не помощник. Пытаться натянуть на микросервисы классические распределенные транзакции с двухфазным коммитом (2PC) – это почти всегда путь к страданиям. Представьте: один сервис захватывает блокировку, ждет подтверждения от другого, тот ждет третьего... Чуть что не так – вся цепочка висит, пользователи ждут, система тормозит, доступность падает. Звучит знакомо? Именно поэтому умные люди придумали альтернативу – паттерн, известный как Saga.

Привет, Хабр!

Скользящие метрики — это must-have в аналитике, но даже простые на первый взгляд вычисления могут парализовать вашу СУБД. Сегодня рассмотрим, почему стандартные оконные функции зачастую тормозят, как их можно оптимизировать через явные фреймы, когда выгоднее писать агрегаты вручную, как использовать предагрегированные таблицы и как проверять корректность расчётов на границах окон.

Если ваш сервис рассчитан на миллиарды пользователей, то несомненно возникнет вопрос о масштабировании.

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

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

Если честно, мы знаем ответ. Но ведь так неинтересно! Поэтому мы нарисовали комикс о том, как карьерный тупик трёх IT-специалистов — разработчика, аналитика и DevOps-инженера — внезапно превращается в портал, за которым их ждут испытания: Legacy-Хаос, техдолг и поток данных, грозящий поглотить всё живое. Чтобы пройти их, героям понадобятся не суперсилы, а кое-что куда важнее: автоматизация, гибкие подходы и возможность делать то, что имеет значение. Погружаемся в комикс — и проверим, что будет, если карьерным мечтам действительно дать пространство для развития.

Меня зовут Роман Ремизов. Я системный аналитик ГК Юзтех. В рамках цикла статей «Хроники архитектурного дизайна» я делюсь своей экспертизой о разных автоматизированных банковских системах (АБС) и о том, что нужно знать перед тем, как приступить к архитектурному дизайну.

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

В этой статье мы познакомимся или освежим в памяти знания о концепции «share nothing». Попробуем уйти от всем надоевшей Kafka и поговорить о других компонентах архитектуры.

Когда проект только стартует, в воздухе витает амбиция - Мы обязательно сделаем всё правильно. Чистая архитектура, ясные зоны ответственности, аккуратные контракты между сервисами, но реальность не знает о ваших планах.

Не потому, что кто-то не знал паттернов проектирования или выбрал не ту СУБД, а потому бизнес требует фичи "на вчера". И шаг за шагом архитектура сдаёт позиции. Что самое интересное - разрушение происходит незаметно. Никакого взрыва вертолетов на заднем фоне не будет. Только десятки небольших компромиссов, которые за относительно короткое время могут превратить систему в клубок боли. Тихо и буднично. Конечно, количество спринтов будет больше трех, но основной сути это не меняет.

Поэтому подготовил для тебя, системный аналитик (и не только), гайд “Как убить архитектуру за три спринта” даже если в начале все было относительно под контролем. Чтож… Щас выскажусь!)))

ривет! Меня зовут Ольга Матушевич, я наставница на курсе «Аналитик данных» в Яндекс Практикуме. А ещё я самый настоящий математик — у меня об этом и справка диплом есть. 

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

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

Системные и бизнес‑аналитики ежедневно пишут десятки требований, юскейсов и спецификаций. На каждый документ уходит 2–3 часа: собрать факты, договориться об уровне детализации, причесать стиль. Акроним КОМПОЗИТОР превращает ChatGPT, GigaChat, Deepseek и другие чат-боты на основе больших языковых моделей из капризного собеседника в штатного аналитика: он раскладывает промт на 10 чётких блоков, которые добавляются итерациями, или «слоями», и автоматически устраняют типичные ошибки — размытые формулировки, «галлюцинации» и несогласованность.

Предисловие

Цель этой статьи - объединить и кратко изложить все базовые архитектурные подходы: их терминологию, концепции и отличительные черты. Собрать всё воедино, чтобы можно было относительно быстро вникнуть в основы.

Я решил написать серию статей, посвящённых различным аспектам проектирования программных систем, но первоначальной идеей было показать архитектурное решение моего pet-проекта на FastAPI — пример реализации «чистой архитектуры» с использованием современного стека: Python3.13, FastAPI, Uvicorn, Nginx, PostgreSQL, Alembic, Celery, Redis, Pytest, Filebeat, Logstash, Elasticsearch, Kibana, Prometheus, Grafana, Docker и Docker Compose.

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

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

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

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

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

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

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

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

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

И вот тут начинается моя личная дизайнерская ирония, даже трагедия...

Скорочтение — это не про то, чтобы глотать страницы книг. Обучение — это не про курсы. Архитектурное мышление — это не про чертежи систем.

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

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

И самое интересное — вы сами увидите, как архитектурное мышление проявляется там, где его меньше всего ждёшь.

— Голдстейн. 

— Да, мистер Старк. 

— Дай мощный бит, под который я буду бить лучшего друга, писать эту статью. 

©Железный человек

Привет, Хабр! Меня зовут Дмитрий Сушков, последние 5 лет работаю железным человеком бизнес-аналитиком. Сегодня поговорим про одну из самых важных задач бизнес-аналитика (BA) — сбор и приоритизацию требований. Эта область довольно мутная, ибо редко бывает единый правильный подход. На каждом проекте есть свои «острые углы»: как договориться с заказчиком, прояснить его реальные потребности, оформить требования так, чтобы их поняли все участники, и при этом успеть всё в срок. Это как разжигать костёр в ливень, в открытом поле, пробовали?) И не стоит. 

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

Эта статья будет полезна:

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

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

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

Не поверхностно, а с разбором боевых кейсов, с примерами и выводами, которые можно вполне себе использовать, как чек-лист. Чтож! Щас выскажусь!)