Reference Architectures

سناریوهای مرجع

معماری‌های نمونه برای وضعیت‌های پرتکرار سازمانی

این صفحه فهرست پروژه‌های انجام‌شده نیست. مجموعه‌ای از الگوهای طراحی ماست: وضعیتی که در سازمان‌ها تکرار می‌شود، الزام‌هایی که طرح باید برآورده کند، تصمیم‌های معماری و دلیل هرکدام.

توضیح مهم: آنچه در این صفحه می‌بینید معماری‌های مرجع است، نه شرح پروژه‌های تحویل‌شده. هیچ سازمان، آمار یا نتیجهٔ اندازه‌گیری‌شده‌ای در این صفحه به ما نسبت داده نشده است. اعداد و اهداف ذکرشده، اهداف طراحی‌اند و برای هر سازمان پس از اندازه‌گیری وضعیت واقعی بازنویسی می‌شوند.

Resilient Core for a Multi-Branch Organization

هستهٔ مقاوم برای سازمان چندشعبه‌ای

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

در این آرایش، قطع ارتباط یک شعبه با مرکز برای آن شعبه معنایی جز توقف کار ندارد؛ و قطع سرویس در مرکز، همهٔ شعب را با هم از کار می‌اندازد. ریسک متمرکز شده است، بی‌آنکه عمداً چنین طراحی شده باشد.

نمودار شمایی — هستهٔ مقاوم برای سازمان چندشعبه‌ای
خوشهٔ مجازی‌سازیکاربراندفتر و دورکاربروکر اتصالمیزبان ۱ماشین‌های سرویسمیزبان ۲دسکتاپ مجازیذخیره‌ساز مشترک

برای دیدن کامل نمودار، آن را به چپ و راست بکشید.

الزام‌های طرح
  • — هویت کاربران باید یکپارچه باشد؛ حساب جداگانه در هر شعبه پذیرفته نیست
  • — خروج از دسترس مسیر ارتباطی اصلی نباید کار شعبه را متوقف کند
  • — هر شعبه باید فقط به سرویس‌هایی برسد که به آن‌ها نیاز دارد
  • — تغییر پیکربندی باید از یک نقطه و با امکان بازگشت انجام شود
تصمیم‌های معماری
  1. اجرای سرویس‌های اصلی روی خوشهٔ مجازی‌سازی در مرکز، تا سرویس از سخت‌افزار جدا شود و جابه‌جایی میان میزبان‌ها بدون بازسازی ممکن باشد.
  2. یک دامنهٔ اکتیو دایرکتوری با کنترلر دوم در مرکز و کنترلر محلی خواندنی در شعب بزرگ، تا احراز هویت در قطعی ارتباط هم کار کند.
  3. اتصال شعب با دو مسیر مستقل و انتخاب مسیر بر پایهٔ کیفیت لحظه‌ای، نه بر پایهٔ یک مسیر اصلی و یک مسیر خاموش.
  4. تفکیک شبکه به بخش‌های کاربر، سرور، تلفن و مدیریت، با سیاست عبور مشخص میان آن‌ها روی فایروال مرکزی.
  5. نسخهٔ پشتیبان در مرکز با یک نسخهٔ خارج از محل، و تعریف هدف زمان بازگشت برای هر سرویس به‌تفکیک اهمیت آن.
اهداف طراحی
  • — ادامهٔ احراز هویت و دسترسی محلی در شعبه، هنگام قطع ارتباط با مرکز
  • — جابه‌جایی سرویس میان میزبان‌ها برای نگهداری، بدون پنجرهٔ توقف طولانی
  • — مسیر روشن و آزمودنی برای بازگرداندن هر سرویس، با هدف زمانی مشخص
  • — امکان افزودن شعبهٔ جدید بر پایهٔ همان الگو، بدون بازطراحی هسته

Recoverable by Design

بازیابی‌پذیری طراحی‌شده، نه امیدوارانه

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

پرسش تعیین‌کننده این نیست که «آیا بکاپ داریم؟»، بلکه این است که «بازگرداندن سامانهٔ اصلی چقدر طول می‌کشد و چه مقدار داده از دست می‌رود؟» تا وقتی این دو عدد نوشته و آزموده نشده باشند، پاسخ نامعلوم است.

نمودار شمایی — بازیابی‌پذیری طراحی‌شده، نه امیدوارانه
لایه‌های نسخهداده‌های زندهکار پشتیبان‌گیرینسخهٔ محلیبازگردانی سریعنسخهٔ جدا از محلخارج از دسترسضد باج‌افزارآزمون بازیابی

برای دیدن کامل نمودار، آن را به چپ و راست بکشید.

الزام‌های طرح
  • — برای هر سرویس باید هدف زمان بازگشت و بیشینهٔ داده از دست‌رفته تعیین شود
  • — دست‌کم یک نسخه باید خارج از محل و خارج از دسترس مدیریتی سامانهٔ اصلی باشد
  • — طرح بازیابی باید دوره‌ای و روی محیط جدا آزموده شود، نه فقط مستند
  • — فرایند بازیابی نباید به دانش ذهنی یک نفر وابسته باشد
تصمیم‌های معماری
  1. دسته‌بندی سرویس‌ها بر پایهٔ تحمل توقف سازمان، و تعیین هدف زمانی جداگانه برای هر دسته — چون یکسان‌سازی اهداف، هم پرهزینه است و هم غیرواقعی.
  2. لایهٔ پشتیبان‌گیری با نسخهٔ محلی برای بازگشت سریع و نسخهٔ خارج از محل برای رویداد گسترده.
  3. جدا کردن دسترسی مدیریتی سامانهٔ پشتیبان از دامنهٔ اصلی، تا نفوذ به دامنه به حذف نسخه‌ها نرسد.
  4. محیط جدا برای آزمون بازیابی، تا آزمودن طرح به سرویس عملیاتی آسیب نزند.
  5. مستندسازی رویهٔ بازیابی به شکل گام‌به‌گام و قابل اجرا توسط فرد دوم.
اهداف طراحی
  • — دو عدد نوشته و آزموده‌شده برای هر سرویس: زمان بازگشت و بیشینهٔ داده از دست‌رفته
  • — اطمینان از اینکه نسخهٔ پشتیبان در رویداد باج‌خواهی هم در دسترس می‌ماند
  • — اجرای آزمون بازیابی به‌صورت دوره‌ای، با گزارش قابل ارائه به مدیریت
  • — استقلال فرایند بازیابی از حضور یک فرد مشخص

Controlled Remote Work

دورکاری کنترل‌شده بدون باز کردن شبکه

سازمانی که لازم است بخشی از همکاران از بیرون دفتر کار کنند: کارشناس پشتیبانی، تیم فروش، مدیرانی که در سفرند، یا پیمانکاری که باید به یک سامانهٔ مشخص دسترسی داشته باشد.

راه‌حل سریع معمولاً باز کردن یک مسیر مستقیم از اینترنت به سرویس داخلی است. این کار مسئله را حل می‌کند و در همان لحظه، سطح حملهٔ سازمان را به اندازهٔ همان مسیر گسترش می‌دهد.

نمودار شمایی — دورکاری کنترل‌شده بدون باز کردن شبکه
سرویس‌های مجازکاربر دورکارپیمانکاردسترسی موقتاحراز هویت چندعاملیدروازهٔ دسترسیسامانهٔ مالیفایل سرور

برای دیدن کامل نمودار، آن را به چپ و راست بکشید.

الزام‌های طرح
  • — هیچ سرویس داخلی نباید مستقیم روی اینترنت منتشر شود
  • — دسترسی باید به هویت فرد گره بخورد، نه به دانستن یک نشانی و گذرواژه
  • — دامنهٔ دسترسی هر گروه باید محدود به سرویس‌های مورد نیاز همان گروه باشد
  • — داده نباید به‌ناچار روی دستگاه شخصی ذخیره شود
تصمیم‌های معماری
  1. یک نقطهٔ ورود واحد و کنترل‌شده برای دسترسی از بیرون، به‌جای چند مسیر مستقل که هرکدام جداگانه باید محافظت شوند.
  2. احراز هویت بر پایهٔ همان هویت سازمانی موجود در دامنه، تا چرخهٔ ورود و خروج کارمند یک نقطهٔ کنترل داشته باشد.
  3. دسترسی گروهی و حداقلی: هر گروه کاربری فقط به سرویس‌های تعریف‌شدهٔ خود می‌رسد.
  4. برای نقش‌هایی که با دادهٔ حساس کار می‌کنند، دسکتاپ مجازی به‌جای دسترسی مستقیم؛ به این ترتیب داده در مرکز داده می‌ماند و تنها تصویر آن منتقل می‌شود.
  5. نگه‌داشتن سیاههٔ ورود و نشست‌ها، تا دسترسی قابل پیگیری باشد.
اهداف طراحی
  • — حذف انتشار مستقیم سرویس‌های داخلی روی اینترنت
  • — گره‌خوردن هر دسترسی به یک هویت مشخص و قابل غیرفعال‌سازی
  • — ماندن دادهٔ حساس در مرکز داده، در نقش‌هایی که این الزام را دارند
  • — امکان پاسخ به این پرسش که چه کسی، چه زمانی، به چه چیزی دسترسی داشته است

Observable Infrastructure

زیرساخت قابل مشاهده

در بسیاری از سازمان‌ها نخستین نشانهٔ خرابی، تماس کاربر است. تیم فناوری اطلاعات پس از آن شروع به بررسی می‌کند و معمولاً هم علت را می‌یابد — اما پس از وقوع، و بدون دادهٔ لحظهٔ رخداد.

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

نمودار شمایی — زیرساخت قابل مشاهده
منابع دادهسرورهاتجهیزات شبکهسرویس‌هاجمع‌آوریانباره و نگهداشتموتور هشدارداشبورد وضعیت

برای دیدن کامل نمودار، آن را به چپ و راست بکشید.

الزام‌های طرح
  • — هر سرویس مهم باید سنجهٔ سلامت و آستانهٔ هشدار مشخص داشته باشد
  • — هشدار باید به فرد یا نقش مسئول برسد، نه به یک صندوق مشترک بی‌صاحب
  • — سیاههٔ رخدادها باید متمرکز و برای مدت تعیین‌شده نگه داشته شود
  • — تعداد هشدارها باید قابل پاسخ‌دادن باشد؛ هشدار بی‌اثر، پایش را بی‌اعتبار می‌کند
تصمیم‌های معماری
  1. آغاز از تعریف سرویس و سنجه، نه از نصب ابزار: برای هر سرویس مشخص می‌شود چه چیزی «سالم» است.
  2. پایش لایه‌ای: دسترس‌پذیری سرویس، منابع میزبان، و وضعیت مسیر ارتباطی — تا علت خرابی از دل داده قابل تفکیک باشد.
  3. تمرکز سیاهه‌ها در یک نقطه، تا بررسی یک رخداد نیازمند ورود به ده سامانه نباشد.
  4. افزودن تحلیل رخداد امنیتی روی همان سیاههٔ متمرکز، برای الگوهایی که تنها در همبستگی چند منبع دیده می‌شوند.
  5. مرتبه‌بندی هشدارها و تعیین مسیر ارجاع، تا هشدار به اقدام منتهی شود.
اهداف طراحی
  • — اطلاع از خرابی پیش از رسیدن تماس کاربر، در سرویس‌های تعریف‌شده
  • — در دسترس بودن دادهٔ لحظهٔ رخداد هنگام بررسی علت
  • — امکان بررسی یک رخداد از یک نقطهٔ واحد
  • — کاهش هشدارهای بی‌اثر تا سطحی که هشدار جدی گرفته شود

Consolidated Enterprise Voice

ارتباط تلفنی یکپارچهٔ سازمانی

سازمانی که ارتباط تلفنی‌اش در طول زمان لایه‌لایه رشد کرده است: چند خط شهری در مرکز، خطوط مستقل در شعب، و تماس‌هایی که با شمارهٔ شخصی همکاران برقرار می‌شود.

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

نمودار شمایی — ارتباط تلفنی یکپارچهٔ سازمانی
داخلی‌های سازمانترانک ورودیخط شهریمرکز تلفنمنوی گویاصف تماسداخلی اداریداخلی دورکارمسیر امن

برای دیدن کامل نمودار، آن را به چپ و راست بکشید.

الزام‌های طرح
  • — شماره‌گذاری داخلی باید در همهٔ شعب یکپارچه باشد
  • — همکار دورکار باید با همان داخلی سازمانی در دسترس باشد
  • — کیفیت صدا نباید قربانی ترافیک دادهٔ شبکه شود
  • — مرکز تلفن نباید مستقیماً روی اینترنت در معرض باشد
تصمیم‌های معماری
  1. یک مرکز تلفن مرکزی با طرح شماره‌گذاری واحد، تا داخلی‌ها در کل سازمان معنا داشته باشند.
  2. اولویت‌دهی به ترافیک صدا در شبکه، چون صدا به تأخیر و نوسان حساس است و بدون اولویت‌دهی، نخستین قربانی شلوغی شبکه می‌شود.
  3. اتصال همکار دورکار از طریق همان نقطهٔ ورود کنترل‌شدهٔ سازمان، نه با انتشار مستقیم مرکز تلفن.
  4. تفکیک شبکهٔ تلفن از شبکهٔ کاربران، برای محدودکردن دامنهٔ خرابی و دسترسی.
  5. گزارش‌گیری از تماس‌ها به‌عنوان بخشی از طراحی، نه افزودهٔ بعدی.
اهداف طراحی
  • — یک طرح شماره‌گذاری واحد برای مرکز، شعب و همکاران دورکار
  • — امکان انتقال تماس و صف پاسخ‌گویی میان مکان‌های مختلف
  • — کیفیت صدای پایدار در زمان اوج ترافیک داده
  • — گزارش قابل استناد از تماس‌های ورودی، خروجی و از دست‌رفته

پرسش‌های متداول

چرا در این صفحه نام مشتری و شرح پروژهٔ انجام‌شده نیست؟

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

این معماری‌ها آماده‌اند یا برای هر سازمان بازنویسی می‌شوند؟

هیچ‌کدام آمادهٔ اجرا نیستند. هر الگو نقطهٔ شروع است: پس از اندازه‌گیری وضعیت واقعی سازمان، ظرفیت‌ها، اهداف زمانی و محدودیت‌ها تعیین می‌شوند و معماری نهایی از دل آن بیرون می‌آید. اعدادی که در این الگوها می‌بینید اهداف طراحی‌اند، نه نتیجهٔ اندازه‌گیری‌شده.

می‌توانم فقط بخشی از یک معماری را اجرا کنم؟

بله، و در عمل بیشتر همکاری‌ها همین‌طور شروع می‌شوند. در مرحلهٔ ارزیابی، ترتیب پیشنهادی اقدام‌ها را بر پایهٔ ریسک فعلی تعیین می‌کنیم؛ معمولاً یک یا دو گام نخست بیشترین کاهش ریسک را با کمترین تغییر می‌دهند.

کدام الگو به وضعیت سازمان شما نزدیک‌تر است؟

در جلسهٔ تخصصی، وضعیت فعلی شما را با این الگوها می‌سنجیم و ترتیب پیشنهادی اقدام‌ها را بر پایهٔ ریسک تعیین می‌کنیم.