ARCHITECTURE & DESIGN

طراحی خوب باید قبل از خرید، تصمیم‌های سخت پروژه را روشن کند

طراحی معماری یعنی تبدیل نیاز کسب‌وکار، محدودیت‌های فنی و واقعیت محیط به یک نقشه قابل اجرا. خروجی فقط یک دیاگرام نیست؛ باید مشخص کند چه اجزایی لازم‌اند، چطور به هم متصل می‌شوند، ظرفیت چقدر است، نقاط شکست کجاست و مسیر اجرا چه ترتیبی دارد.

درخواست جلسه طراحی مشاهده خدمات ارزیابی

قبل از BOM

معماری باید به این سؤال‌ها جواب بدهد

ظرفیت امروز و فردا چقدر است؟
کدام سرویس‌ها حیاتی‌ترند؟
Failure Domainها کجا هستند؟
Backup و DR چطور طراحی می‌شوند؟
چه اجزایی باید Redundant باشند؟
کدام وابستگی‌ها روی Migration اثر دارند؟

دیاگرام، خود معماری نیست

معماری خوب باید قابل اجرا، قابل دفاع و قابل توسعه باشد

اگر Design فقط ظاهر ارتباط اجزا را نشان دهد اما Capacity، Dependency، Failure، Security و مسیر اجرا را روشن نکند، هنوز برای تصمیم پروژه کافی نیست. معماری باید بین نیاز فعلی و رشد آینده تعادل ایجاد کند و مشخص کند چرا هر انتخاب انجام شده است.

ورودی‌های طراحی

قبل از معماری، باید مسئله و محدودیت‌ها روشن باشند

نیاز کسب‌وکار

کدام سرویس‌ها حیاتی‌اند، چه میزان توقف قابل قبول است و رشد مورد انتظار سازمان چقدر است.

وضعیت موجود

زیرساخت فعلی، Versionها، Capacity، محدودیت‌های فیزیکی و وابستگی‌هایی که طراحی جدید باید با آن‌ها کنار بیاید.

محدودیت اجرا

بودجه، پنجره تغییر، امکان Downtime، محدودیت خرید، فضای دیتاسنتر و توان عملیاتی تیم بخشی از Design هستند، نه موضوعات بعدی.

لایه‌های طراحی

معماری زیرساخت باید اجزا را در یک تصویر واحد ببیند

Compute و Virtualization

Cluster Design، تراکم Workload، Redundancy، Headroom و مدل توسعه Compute مشخص می‌شوند.

Storage و Data

Capacity، Performance، Availability، Growth و نحوه حفاظت از داده در طراحی دیده می‌شوند.

Network

Topology، Redundancy، East-West و North-South Traffic، Uplink و ارتباط بین سایت‌ها طراحی می‌شوند.

Security

Segmentation، Firewall Policy، Access Boundary و محل اعمال کنترل‌ها باید بخشی از معماری اصلی باشند.

Backup و Recovery

Repository، Retention، Immutability، Off-Site Copy و Recovery باید با نقش سرویس‌ها هماهنگ باشند.

DR و Site Design

RPO/RTO، Replication، Failover، Failure Domain و نقش سایت دوم در طراحی نهایی مشخص می‌شوند.

Failure قبل از Success

یک Design خوب فقط مسیر عادی را طراحی نمی‌کند

در معماری زیرساخت باید از ابتدا روشن باشد اگر Host، Storage، Link، Firewall یا یک سایت از دسترس خارج شد چه اتفاقی می‌افتد. Redundancy زمانی معنا دارد که Failure Domainها درست تعریف شده باشند.

سناریوهایی که Design باید پاسخ بدهد

خرابی یک Host یا Node
خرابی Storage یا مسیر دسترسی
قطع Uplink یا WAN
از دسترس خارج شدن Firewall
اختلال در سرویس مرکزی
از دسترس خارج شدن یک سایت کامل

Sizing قبل از BOM

تعداد تجهیزات باید نتیجه محاسبه باشد، نه نقطه شروع طراحی

Sizing باید مصرف فعلی، Peak، Growth، Redundancy و Headroom را کنار هم ببیند. عددی که فقط برای امروز کافی است ممکن است خیلی زود پروژه را به محدودیت برساند؛ و Oversizing هم هزینه‌ای ایجاد می‌کند که الزام فنی ندارد.

در Sizing معمولاً این موارد دیده می‌شوند

Baseline مصرف فعلی
Peak و هم‌زمانی بار
رشد پیش‌بینی‌شده
Headroom عملیاتی
ظرفیت لازم در زمان Failure
محدودیت Power، Rack و Port

از Architecture به BOM

BOM باید از معماری بیرون بیاید، نه معماری از BOM

وقتی ابتدا محصول انتخاب شود، طراحی ناخواسته حول همان انتخاب شکل می‌گیرد. در مسیر درست، Requirement و Architecture مشخص می‌کنند چه مشخصات فنی لازم است و بعد BOM بر اساس آن بسته می‌شود.

مشخصات فنی

CPU، Memory، Storage، Port، Interface و License بر اساس نیاز معماری تعریف می‌شوند.

Compatibility

تناسب Hardware، Firmware، Software و License قبل از خرید کنترل می‌شود.

مسیر توسعه

BOM فقط برای Day-۱ بسته نمی‌شود؛ امکان افزودن Capacity و توسعه بعدی هم باید قابل پیش‌بینی باشد.

خروجی طراحی

Design باید چیزی تحویل بدهد که پروژه بتواند بر اساس آن جلو برود

Architecture Diagram

تصویر منطقی و فیزیکی اجزا، ارتباط‌ها و مرزهای معماری.

Sizing

ظرفیت موردنیاز، Headroom و مبنای محاسبه برای اجزای اصلی.

BOM

فهرست تجهیزات و لایسنس‌های لازم با مشخصات فنی متناسب با Design.

Dependency Map

وابستگی سرویس‌ها و اجزایی که روی ترتیب اجرا یا Migration اثر دارند.

Failure & Recovery

رفتار معماری در سناریوهای خرابی و مسیر بازیابی سرویس‌ها.

Implementation Roadmap

ترتیب اجرا، پیش‌نیازها، Milestoneها و نقاطی که نیاز به Validation دارند.

مسیرهای تخصصی طراحی

بعضی پروژه‌ها بعد از معماری کلان، وارد Design تخصصی‌تر می‌شوند

طراحی دیتاسنتر

معماری Compute، Storage، Network، برق، سرمایش و اجزای اجرایی دیتاسنتر.

طراحی و اجرای دیتاسنتر ←

VCF و Private Cloud

طراحی Foundation، Cluster، vSAN، NSX، Capacity و Lifecycle در معماری VCF.

مرکز VCF راگا ←

Multi-Site و DR

طراحی نقش سایت‌ها، Replication، Network، Failure Domain و ادامه سرویس بین چند موقعیت.

زیرساخت Multi-Site ←

فرآیند طراحی

از Requirement به معماری و از معماری به نقشه اجرا

۰۱

Requirement

نیاز، ظرفیت، ریسک و محدودیت‌های پروژه مشخص می‌شوند.

۰۲

Architecture

اجزا، ارتباط‌ها، Redundancy و Failure Domain طراحی می‌شوند.

۰۳

Sizing & BOM

ظرفیت و مشخصات فنی موردنیاز به BOM قابل خرید تبدیل می‌شوند.

۰۴

Roadmap

ترتیب اجرا، Migration، Test و Handover مشخص می‌شوند.

اگر BOM دارید اما هنوز مطمئن نیستید معماری پشت آن درست است، بهتر است قبل از خرید Design را مرور کنیم

Requirement، معماری فعلی یا BOM پیشنهادی را با تیم فنی راگا مطرح کنید. هدف جلسه اول این است که مشخص شود چه تصمیم‌هایی هنوز باید قبل از اجرا روشن شوند.

درخواست جلسه طراحی