Вам требуется спроектировать новое решение сложной ИТ-системы. Ваши действия?
Прежде чем приступать к разработке плана действий, все лучшие практики от руководителей и специалистов следует соединить в понятную (хотя бы по частям) схему.
В примере ниже представлена диаграмма, которая объясняет, что всегда должен найтись один фактор, который встанет во главе. Это первый кирпичик, который будет определять формат всей работы.
При разработке ПО я предлагаю брать в качестве такого кирпичика сервер Gitlab или GitHub и формат Markdown в качестве документации, находящейся в одном месте и подразумевающей работу с ней как с кодом. Предлагаю взять и никогда не менять. Потому что документация в любом проекте это ваше всё (к этому мы больше возвращаться не будем - принято).
Проблема устаревания документации по мере разработки или развития продукта в такой схеме минимальна. Главные причины устаревания информации:
- документация никем не пишется
- документация расползлась и невозможно собрать полную актуальную версию из кусков
Оба эти фактора в указанной схеме удерживаются под контролем.
В некоторых командах есть шанс на появление коммьюнити, где самостоятельно развивается направление персонального вклада в документацию любым сотрудником.
Три силы должны идти параллельно: это архитектор, специалист и куратор проекта.
От специалиста требуется выполнять задачи, намеченные архитектором. Специалисты разного уровня самостоятельно находят решение. Архитектор задает формат для описания проекта. А куратор проекта занимается ролями и правилами, чтобы работа шла гладко, предсказуемо и по возможности комфортно.
Без четкого донесения зон ответственности, как со стороны разработчика ПО, так и со стороны заказчика, работа будет неэффективной.
Этот топик является введением в тему Gemba - японскому подходу отслеживания рабочих процессов.
Начинать работу на крупном проекте нужно с высокоуровневой диаграммы (напоминаю, кирпичик в виде git+markdown был заложен ранее). Она позволяет говорить всем участникам на одном языке и избавляет от разночтения и объяснения на пальцах.
На каждом этапе подключаются сотрудники различных направлений и специальностей.
Распространенным подходом среди заказчиков является визуализация архитектуры ПО “Модель C4” (си-четыре: Context, Containers, Components, Code) и ее вариации.
Диаграммы разных уровней детализированы по-разному, поэтому понятны как техническим, так и нетехническим специалистам.
В своей работе я использую:
High Level Design - это диаграмма с нарисованными сетевыми устройствами и контурами. Она включает в себя сетевой экран и средства защиты. На схеме отражают потоки данных, отмечая расположение чувствительных данных. Компоненты соединяются линиями без стрелок с указанием портов и протоколов.
Из этой диаграммы составляется диаграмма развертывания (без примера), на которой добавляются:
- платформа виртуализации
- название и версии ОС и СУБД
- контейнеры и оркестратор
- требования к железу
- привязка к вендору оборудования
- среда развертывания
По этой диаграмме понятно, как система развертывается и обслуживается. Каким образом производится масштабирование ее частей. Как происходят регламентные работы и резервное копирование/восстановление.
В последнюю очередь составляется контейнерная диаграмма, в которой указываются серверы (как сервисы), службы, микросервисы, описывается IaaS, интерфейсы, протоколы связи, тип интеграций, СУБД, брокеры сообщений, шины, шлюзы, синхронность обмена и тип взаимодействия (XML, API, файлы).
(Последняя диаграмма, Диаграмма классов используется по желанию, это опционально).
Расписывая компоненты каждой диаграммы поэтапно, у куратора и архитектора есть понимание, какие задачи возникают и как они должны распределяться между участниками. А диаграмма шагов позволит видеть каждому участнику, в каком месте он находится и каков его следующий шаг.
Скачать диаграмму Mermaid: flow_new_arch.md (2,5 КБ)
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(Карточка решения<br><i>в проекте Gitlab<br>формат Markdown</i>):::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
Всегда следуйте блокам диаграммы. Находите соответствия и стройте работу так, чтобы в ней не было белых пятен. Если требуется внести изменения в процесс, постепенно делайте их.