# Диаграмма шагов при проектировании новой системы (шаг 1) **Category:** [Ввод сервиса](https://discuss.rabkesov.ru/c/service/5) **Created:** 2025-07-18 02:12 UTC **Views:** 28 **Replies:** 0 **URL:** https://discuss.rabkesov.ru/t/diagramma-shagov-pri-proektirovanii-novoj-sistemy-shag-1/147 --- ## Post #1 by @ivan Вам требуется спроектировать новое решение сложной ИТ-системы. Ваши действия? Прежде чем приступать к разработке плана действий, все лучшие практики от руководителей и специалистов следует соединить в понятную (хотя бы по частям) схему. В примере ниже представлена диаграмма, которая объясняет, что всегда должен найтись один фактор, который встанет во главе. Это первый кирпичик, который будет определять формат всей работы. При разработке ПО я предлагаю брать в качестве такого кирпичика сервер Gitlab или GitHub и формат Markdown в качестве документации, находящейся в одном месте и подразумевающей работу с ней как с кодом. Предлагаю взять и никогда не менять. Потому что документация в любом проекте это ваше всё (к этому мы больше возвращаться не будем - принято). >Проблема устаревания документации по мере разработки или развития продукта в такой схеме минимальна. Главные причины устаревания информации: >- документация никем не пишется >- документация расползлась и невозможно собрать полную актуальную версию из кусков > >Оба эти фактора в указанной схеме удерживаются под контролем. >В некоторых командах есть шанс на появление коммьюнити, где самостоятельно развивается направление персонального вклада в документацию любым сотрудником. ![На экране компьютера изображена сгорающая голова, символизирующая стресс и переутомление, а девушка, сидящая перед ним, выглядит подавленной и измученной. (Подпись к изображению от AI)|689x394](upload://tnNoJMCtHTYPVAc1EO1yaCJ9l84.jpeg) Три силы должны идти параллельно: это архитектор, специалист и куратор проекта. От специалиста требуется выполнять задачи, намеченные архитектором. Специалисты разного уровня самостоятельно находят решение. Архитектор задает формат для описания проекта. А куратор проекта занимается ролями и правилами, чтобы работа шла гладко, предсказуемо и по возможности комфортно. Без четкого донесения зон ответственности, как со стороны разработчика ПО, так и со стороны заказчика, работа будет неэффективной. Этот топик является введением в тему Gemba - японскому подходу отслеживания рабочих процессов. --- Начинать работу на крупном проекте нужно с высокоуровневой диаграммы (напоминаю, кирпичик в виде git+markdown был заложен ранее). Она позволяет говорить всем участникам на одном языке и избавляет от разночтения и объяснения на пальцах. На каждом этапе подключаются сотрудники различных направлений и специальностей. Распространенным подходом среди заказчиков является визуализация архитектуры ПО "Модель C4" (си-четыре: Context, Containers, Components, Code) и ее вариации. Диаграммы разных уровней детализированы по-разному, поэтому понятны как техническим, так и нетехническим специалистам. В своей работе я использую: >High Level Design - это диаграмма с нарисованными сетевыми устройствами и контурами. Она включает в себя сетевой экран и средства защиты. На схеме отражают потоки данных, отмечая расположение чувствительных данных. Компоненты соединяются линиями без стрелок с указанием портов и протоколов. ![Изображение демонстрирует сложную сетевую архитектуру, включающую интернет, внешнюю DMZ и внутреннюю LAN с множеством серверов и устройств, соединенных между собой. (Подпись к изображению от AI)|437x500](upload://ogr3AruwLX957HqwN4C2IggEjg9.jpeg) Из этой диаграммы составляется диаграмма развертывания (без примера), на которой добавляются: - платформа виртуализации - название и версии ОС и СУБД - контейнеры и оркестратор - требования к железу - привязка к вендору оборудования - среда развертывания По этой диаграмме понятно, как система развертывается и обслуживается. Каким образом производится масштабирование ее частей. Как происходят регламентные работы и резервное копирование/восстановление. В последнюю очередь составляется контейнерная диаграмма, в которой указываются серверы (как сервисы), службы, микросервисы, описывается IaaS, интерфейсы, протоколы связи, тип интеграций, СУБД, брокеры сообщений, шины, шлюзы, синхронность обмена и тип взаимодействия (XML, API, файлы). (Последняя диаграмма, Диаграмма классов используется по желанию, это опционально). >Расписывая компоненты каждой диаграммы поэтапно, у куратора и архитектора есть понимание, какие задачи возникают и как они должны распределяться между участниками. А диаграмма шагов позволит видеть каждому участнику, в каком месте он находится и каков его следующий шаг. Скачать диаграмму Mermaid: [flow_new_arch.md|attachment](upload://hGbtta8WJSDgxoG6cZf8dbB1sK9.md) (2,5 КБ) ```mermaid flowchart TD classDef pclass fill:#f5f5dc classDef wclass fill:#f96 classDef pmclass fill:#4f7 classDef yclass fill:#ff9 classDef oclass fill:#ffbf00 classDef gclass fill:#c5e384 a((Начало)):::gclass --1--> b(Карточка решения
в проекте Gitlab
формат Markdown):::wclass --> q{ } -.2.-> g[Процессы] --3--> h[Регламенты] --4--> i[Зоны ответственности] -.-> p g --> s(Схема взаимодействия людей на проекте с учетом типов задач и их последовательности):::pclass h --> t(Требования соблюдать правила: оформление кода, ревью, оформление, коммуникации, порядок, культура , комплаенс):::pclass i --> u(Точность в назначении и выполнении задач, бесшовность в совместной работе):::pclass q --5--> c(HLD-диаграмма):::oclass --6--> d(Диаграмма развертывания):::oclass --7--> e(Контейнерная диаграмма):::oclass --8--> p(Онлайн-документация):::yclass --> j[[Техническое решение]]:::pmclass c --> k(сетевые контуры, распределение контейнеров, МСЭ и элементы защиты, способы подключения техподдержки):::pclass c --> o(ключевые потоки данных, расположение чувствительных данных по типу: ПДН, коммерческая тайна и т.д.):::pclass d --> m(требования к типу железа, к оборудованию, к производительности, привязка к вендору, виртуализация, контейнеризация, оркестрация, среда развертывания):::pclass e --> n(серверы как сервис, службы, IaaS, микросервисы, интерфейсы, протоколы и тип интеграций, СУБД, брокеры, внешние компоненты, интеграции: шины, очереди, гейтвеи, тип связанности sync/async, протоколы взаимодействия):::pclass ``` Всегда следуйте блокам диаграммы. Находите соответствия и стройте работу так, чтобы в ней не было белых пятен. Если требуется внести изменения в процесс, постепенно делайте их. --- **Canonical:** https://discuss.rabkesov.ru/t/diagramma-shagov-pri-proektirovanii-novoj-sistemy-shag-1/147 **Original content:** https://discuss.rabkesov.ru/t/diagramma-shagov-pri-proektirovanii-novoj-sistemy-shag-1/147