شناخت نیاز
کاربران، سرویسها و ساعت پرترافیک را ثبت کنید.
در حال آمادهسازی صفحه
اتصال مناسب، فقط بزرگترین عدد سرعت نیست. اینترنت سازمان باید با تعداد کاربران، سرویسهای ابری، ارسال فایل و نیاز دسترسی بیرونی هماهنگ باشد؛ کیفیت در ساعت کاری و مسیر رسیدگی به اختلال هم بخشی از انتخاباند.
نقشهٔ مفهومی آموزشی؛ ظرفیت اسمی با کیفیت تجربهٔ کاربران یکی نیست.
نیاز سازمان، مجموعهای از ظرفیت، کیفیت، دسترسی و نگهداری است. تماس تصویری، ارسال بکاپ، برنامهٔ ابری و انتشار سرویس، رفتار یکسانی ندارند. تعداد کاربران بهتنهایی برای تعیین ظرفیت کافی نیست؛ همزمانی و نوع کار مهماند.
این راهنما برای نیازسنجی و تحویل اتصال است، نه فروش یک نوع خط برای همهٔ شرکتها. پوشش، شرایط قرارداد و امکانات ارائهدهنده باید برای نشانی واقعی بررسی شوند؛ قیمت، سرعت یا زمان راهاندازی عمومی تضمین نمیشود.
کاربران، سرویسها و ساعت پرترافیک را ثبت کنید.
پوشش، کیفیت، قرارداد و دسترسی را بسنجید.
تجهیزات و سیاست شبکه را کنترلشده آماده کنید.
کارکرد سرویسهای واقعی را بررسی و مستند کنید.
ابتدا سرویسهای حیاتی و تعداد استفادهکنندگان همزمان را مشخص کنید. برای تیمی که فایل بزرگ ارسال میکند، آپلود اهمیت زیادی دارد؛ برای مکالمه، تأخیر و تغییر آن مهماند. ظرفیت دانلود بالا الزاماً ضعف آپلود یا اختلال یک مسیر را جبران نمیکند.
در صورت امکان، وضعیت ساعت کاری را اندازه بگیرید و نیاز توسعه را جدا ثبت کنید. اندازهگیری نباید با اشباع شبکه یا ارسال اطلاعات محرمانه به ابزار ناشناس انجام شود. نتیجهٔ یک دستگاه در یک ساعت، تصویر کامل مصرف سازمان نیست.
ADSL روی بستر مسی و TD-LTE روی دسترسی رادیویی ارائه میشوند؛ فیبر، بستر انتقال نوری است. نام فناوری، بهتنهایی کیفیت واقعی سرویس را تعیین نمیکند. وضعیت محل، تجهیزات، بار شبکهٔ ارائهدهنده و شرایط بسته باید بررسی شوند.
پهنای باند اختصاصی یک ادعای قراردادی است که باید دقیق خوانده شود: ظرفیت در کدام نقطه تضمین شده، مسیر و پشتیبانی چیست و چه مواردی خارج از تعهدند؟ هر اتصال فیبری را اختصاصی و هر سرویس اختصاصی را بدون قطعی فرض نکنید. انتخاب باید بر مبنای نیاز و شرایط واقعی باشد.
سرعت قابل استفاده، تأخیر، تغییر تأخیر و از دسترفتن بسته میتوانند تجربهٔ کار را عوض کنند. آزمون در حالت خلوت و زیر بار مجاز، و برای مقصدهای مرتبط با سازمان، مفیدتر از یک عدد بدون زمینه است. شرایط آزمون و ترافیک همزمان ثبت شوند.
چارچوب آزمون TCP در RFC 6349 بر سنجش عملکرد ارتباط TCP تمرکز دارد. نتیجهٔ آزمون باید با مسیر و شرایط تفسیر شود؛ انتقال واقعی ممکن است به سرور مقصد، تجهیزات و برنامه نیز وابسته باشد. اینترنت را تنها علت هر کندی ندانید.
برای دسترسی بیرونی مجاز، فقط ثابتبودن IP کافی نیست؛ عمومیبودن نشانی، NAT ارائهدهنده و سیاست دسترسی هم باید مشخص باشند. پورتفوروارد روی روتر داخلی، اختیار یا قابلیت عبور از همهٔ لایههای ارائهدهنده را ایجاد نمیکند.
RFC 6598 فضای نشانی مشترک برای شبکهٔ ارائهدهنده را توضیح میدهد. شرایط واقعی خط را از ارائهدهنده بررسی کنید. برای انتشار سرویس، طراحی امن و مجوز لازماند؛ بازکردن مستقیم پنل مدیریت یا همهٔ پورتها راهکار عمومی این مقاله نیست.
توان روتر در حالت اجرای سیاست، ظرفیت رابط، وضعیت کابل و شبکهٔ بیسیم را بررسی کنید. دستگاهی که بدون کنترل ترافیک سریع است ممکن است زیر بار قواعد یا تونل رفتار دیگری داشته باشد. خرید بر اساس یک عدد آزمایشگاهی، نیاز واقعی را ثابت نمیکند.
DNS، مسیر پیشفرض و تنظیمات شبکه با سرویسهای داخلی هماهنگ شوند. اگر مشکل از Wi-Fi، شبکهٔ داخلی یا مقصد است، ارتقای خط بهتنهایی رفع آن را تضمین نمیکند. برای مصرف مشترک، مدیریت پهنای باند را جدا طراحی کنید.
برای سرویس حساس، اثر قطع اتصال و نیاز خط جایگزین را مشخص کنید. دو خط ممکن است مسیر فیزیکی، برق یا تجهیزات مشترک داشته باشند؛ داشتن دو قرارداد، استقلال واقعی را ثابت نمیکند. ظرفیت خط پشتیبان باید نیاز حداقلی هنگام اختلال را پوشش دهد.
Failover اینترنت انتقال به مسیر جایگزین را هدف میگیرد و تجمیع چند خط دربارهٔ توزیع بار است. هیچکدام بهتنهایی بقای تمام نشستهای فعال یا دوبرابرشدن سرعت هر اتصال را تضمین نمیکنند.
ابتدا بکاپ تنظیمات و مسیر بازگشت داشته باشید؛ تغییر خط یا DNS با اطلاع مالک سرویس انجام شود. بعد از نصب، سرویس کاری، ارسال فایل، مکالمه و دسترسی مجاز در شرایط توافقشده آزموده شوند. آزمون پایداری را با ایجاد قطعی بدون هماهنگی اجرا نکنید.
هزینهٔ خط، آمادهسازی محل، تجهیزات، IP و پشتیبانی ممکن است جدا باشند. گزینهها را با شرایط مشابه مقایسه کنید، نه صرفاً قیمت ماهانه. هزینهٔ خط پشتیبان و نگهداری نیز در برآورد دیده شوند.
دامنهٔ پشتیبانی و مسیر اعلام اختلال مشخص باشند: ارائهدهنده مسئول کدام بخش است و تیم شبکه کدام بخش را بررسی میکند؟ این مقاله مبلغ ثابت یا زمان رفع اختلال عمومی ارائه نمیکند؛ برآورد پس از نیازسنجی و بررسی پوشش معتبرتر است.
برای شروع، نشانی پوشش را از مسیر مناسب، نوع سرویس فعلی و نیاز اصلی سازمان مشخص کنید. انتخاب اتصال، تجهیزات و معیار تحویل پس از بررسی قابل تعریف است. تعداد کاربران و هدف بررسی را در بخش پشتیبانی ویوان نت توضیح دهید؛ رمز، کلید یا تنظیمات محرمانه را در درخواست معمولی نفرستید.
فرض کنید تماسهای تیم هنگام ارسال فایل بزرگ کیفیت خوبی ندارند، اما تست دانلود در زمان خلوت عدد مناسبی دارد. تیم باید آپلود، ترافیک همزمان و تأخیر زیر بار را بررسی کند، نه اینکه فقط بستهٔ دانلود را ارتقا دهد.
پس از شناخت گلوگاه، انتخاب ظرفیت و سیاست مصرف در دامنهٔ مجاز اصلاح و کارکرد سرویس دوباره آزموده میشود. عدد تبلیغاتی یا یک تست کوتاه، کیفیت همهٔ فعالیتها را ثابت نکرده بود.
این مثال آموزشی است، نه پروژهٔ واقعی یا نتیجهٔ عددی ویوان نت؛ روش اجرا و آزمون باید با بستر و اختیار سازمان هماهنگ شوند.
این راهنما از مجموعهٔ پهنای باند، اینترنت و ارتباطات امن ویوان نت است. برای شناخت مجموعه، معرفی ویوان نت را ببینید.
گزینه مناسب به پوشش محل، نیاز آپلود و کیفیت، شرایط قرارداد و پشتیبانی بستگی دارد. نام فناوری بهتنهایی تصمیم را مشخص نمیکند؛ اتصال در شرایط واقعی سازمان بررسی شود.
تعداد استفادهکنندگان همزمان، نوع سرویس و مصرف آپلود و دانلود را اندازهگیری کنید. عدد ثابت بهازای هر کاربر برای همهٔ فعالیتها معتبر نیست؛ نیاز رشد هم جدا دیده شود.
خیر. ثابتبودن، تغییرنکردن نشانی را توصیف میکند؛ عمومیبودن و امکان دسترسی ورودی، به آدرسدهی، NAT و سیاست ارائهدهنده وابستهاند. شرایط واقعی خط باید بررسی شود.
خیر. فیبر بستر دسترسی است و اختصاصیبودن ظرفیت و تعهد کیفیت موضوع قرارداد است. نقطه و دامنهٔ تعهد و محدودیتها را از ارائهدهنده بررسی کنید.
خیر. مسیر مشترک، برق، روتر و ظرفیت خط جایگزین میتوانند محدودیت ایجاد کنند. طراحی و آزمون Failover باید با سرویس واقعی انجام شوند؛ بقای همهٔ نشستها تضمین نمیشود.
خط، آمادهسازی، تجهیزات، IP، نصب و نگهداری بسته به پیشنهاد جدا هستند. شرایط پوشش و تعهد پشتیبانی را همراه قیمت بررسی کنید؛ مبلغ ثابت بدون نیازسنجی قابل اتکا نیست.
منابع برای مبانی و نمونهٔ روشها هستند؛ انتخاب محصول، ظرفیت و تنظیمات واقعی باید در زمان اجرا و بستر سازمان بررسی شوند.
نوع خط فعلی، سرویسهای مهم و مشکل اصلی را بگویید تا مسیر بررسی و تحویل روشن شود.
ثبت درخواست مشاوره ←