Есть особый тип облачных диаграмм, от которых ревьюерам становится не по себе, хотя они не вполне понимают почему. Всё нарисовано серыми прямоугольниками. Балансировщик нагрузки, очередь, объектное хранилище и управляемая база данных выглядят одинаково и различаются только словами внутри. Технически всё верно. Но пробежать такую диаграмму глазами невозможно, а диаграмма, которую приходится читать слово за словом, едва ли быстрее абзаца, который она заменила.
Хорошие облачные диаграммы кажутся лёгкими потому, что опираются на общий визуальный язык. Инженер, работавший с платформой, знает форму вычислительного сервиса, объектного хранилища, управляемой очереди ещё до того, как прочтёт подпись. Когда ваша диаграмма использует собственную иконографию провайдера, она подключается прямо к этой общей памяти, и картинку можно читать бегло. В этом вся разница между диаграммой, которой доверяют, и диаграммой, в которую вглядываются, прищурившись.
Иконки несут смысл, а не украшают
Соблазнительно считать иконки финальной полировкой. Это не так; именно ими облачная диаграмма кодирует тип. Как только на блоке появляется иконка объектного хранилища, читатель понимает его надёжность, характер доступа и модель стоимости, хотя вы ничего из этого не написали. Иконка управляемой БД говорит «это эксплуатирует кто-то другой» так, как простой прямоугольник никогда не скажет. Уберите иконки, и вы выбросите целый слой информации; вот почему полностью серая диаграмма кажется такой плоской.
Используйте настоящие иконки AWS, Azure и GCP
В LetDraw есть библиотеки иконок в официальном стиле для трёх крупнейших облаков (AWS, Azure и GCP), так что вам не нужно изображать вычислительный сервис общим значком сервера. Откройте библиотеку фигур, выберите провайдера и перетащите на холст настоящие сервисы: балансировщик, который выглядит как балансировщик этого провайдера, очередь, которая выглядит как его очередь. Диаграмма из правильного набора читается верно любым, кто работает с этой платформой, а обычно именно они и есть аудитория диаграммы.
Смешивать провайдеров тоже нормально, и это честно, если ваша система действительно охватывает несколько облаков. Иконки делают границу очевидной (эта половина в одном облаке, та в другом), а не прячут мультиоблачную реальность за одинаковыми серыми блоками.
Правильная иконка говорит читателю, что это за блок, ещё до того, как он прочтёт хоть слово. В этом вся задача облачной диаграммы.
Начните с уже описанной инфраструктуры
Не нужно расставлять каждый сервис вручную. Если ваша инфраструктура описана в Terraform или похожей декларации, этот файл уже перечисляет ресурсы и связи между ними. Вставьте его в «Создать из кода», и LetDraw разложит компоненты за вас; затем поставьте на блоки правильные иконки провайдера, чтобы сгенерированный черновик читался как настоящая архитектура, а не как граф зависимостей.
resource "aws_lb" "web" { # → load balancer icon } resource "aws_ecs_service" "api" { # → compute icon } resource "aws_db_instance" "main" { # → managed DB icon } resource "aws_s3_bucket" "assets" { # → object-store icon }
Диаграмма облачной архитектуры, которая остаётся читаемой при росте
Настоящие облачные диаграммы становятся плотными, и губят их стрелки, проведённые прямо сквозь всё, что попалось на пути. Пусть холст прокладывает соединители в обход сервисов, сгруппируйте каждый уровень или регион в контейнер, и картинка останется читаемой на тридцати блоках так же, как на пяти. Когда она нужна в виде кода (для документа, вики, пул-реквеста), экспортируйте в Mermaid или D2 и закоммитьте рядом с Terraform, который она описывает.
Хорошая облачная диаграмма не красивее плохой; она быстрее читается. Используйте настоящие иконки, генерируйте первый черновик из инфраструктуры и дайте ревьюерам картинку, которую они узнают с первого взгляда.