وبلاگ
قرارداد پشتیبانی شبکه در تهران؛ خدمات، SLA و هزینه ماهانه در ۱۴۰۵
ساعت ۹:۱۰ صبح است و واحد مالی به نرمافزار حسابداری دسترسی ندارد. همزمان وایفای طبقه دوم قطع شده و مدیر فروش میگوید VPN شعبه هم وصل نمیشود. اگر شرکت قرارداد پشتیبانی مشخصی نداشته باشد، اولین سؤال معمولاً این است: «الان با چه کسی تماس بگیریم؟» و سؤال بعدی اینکه کدام خرابی واقعاً فوریتر است. در یک قرارداد حرفهای، این تصمیمها از قبل گرفته شدهاند؛ رخداد ثبت میشود، سطح فوریت دارد، زمان پاسخ مشخص است و معلوم است چه کاری ریموت انجام میشود و چه زمانی کارشناس باید در محل حاضر شود.
پشتیبانی شبکه فقط «رفع خرابی کامپیوترها» نیست. برای یک شرکت، شبکه مجموعهای از سوئیچ، روتر، فایروال، سرور، سرویسهای ویندوز یا لینوکس، اینترنت، VPN، بکاپ، تجهیزات بیسیم، پرینترها و گاهی دوربین و VoIP است. قرارداد خوب باید مرز مسئولیت را شفاف کند؛ وگرنه ممکن است کارفرما تصور کند هر تغییر زیرساختی داخل مبلغ ماهانه است و پیمانکار آن را پروژه جدا بداند. این مقاله دقیقاً برای همین نقطه تصمیم نوشته شده است: چه خدماتی باید داخل Scope باشد، SLA چگونه تعریف شود و هزینه ماهانه در سال ۱۴۰۵ بر چه متغیرهایی تکیه دارد.
|
پاسخ سریع: برای انتخاب پشتیبانی شبکه تهران، فقط مبلغ ماهانه را مقایسه نکنید. ابتدا تعداد کاربران، سرورها و شعب، ساعات کاری، سرویسهای حیاتی، تعداد بازدید حضوری، سطح مانیتورینگ و بکاپ، زمان پاسخ رخدادهای بحرانی و موارد خارج از قرارداد را مشخص کنید. سپس قیمت را بر اساس Scope و SLA یکسان مقایسه کنید. |
اگر توقف شبکه برای مجموعه شما هزینه عملیاتی ایجاد میکند، قبل از مقایسه قیمت یک ارزیابی اولیه انجام دهید و محدوده پشتیبانی شبکه تهران را بر اساس سرویسهای واقعی شرکت تعریف کنید؛ صفحه مقصد هنگام انتشار باید مستقل، 200 و indexable باشد.
پشتیبانی شبکه دقیقاً شامل چه خدماتی است؟
محدوده خدمات باید به زبان قابل اندازهگیری نوشته شود. عبارتی مثل «پشتیبانی کامل شبکه» به تنهایی ارزش قراردادی کمی دارد، چون مشخص نمیکند چه تجهیزاتی، چه سرویسهایی و با چه سطحی پوشش داده میشوند. برای یک دفتر ۱۵ نفره ممکن است پشتیبانی شامل کلاینتها، یک سرور، سوئیچ، روتر، وایفای، پرینتر و بکاپ باشد؛ اما یک شرکت چندشعبهای ممکن است علاوه بر اینها VPN، فایروال، چند ماشین مجازی، لینکهای اینترنت، Active Directory، NAS و سرویسهای تلفنی را هم در Scope داشته باشد.
|
حوزه |
نمونه خدمات داخل قرارداد |
مرز مسئولیت که باید روشن شود |
|
کاربران و کلاینت |
رفع خطای اتصال، دسترسی منابع، نرمافزارهای عمومی و پرینتر |
نصب نرمافزار تخصصی، خرابی سختافزار و لایسنس جداست یا نه؟ |
|
شبکه و اینترنت |
سوئیچ، روتر، VLAN، Wi-Fi، DHCP/DNS و عیبیابی لینک |
تغییر طراحی، کابلکشی جدید یا خرید تجهیزات پروژه جدا محسوب میشود؟ |
|
سرور و سرویسها |
کاربران، سرویسهای پایه، VM، فضای ذخیرهسازی و Patch |
ارتقای نسخه، Migration و پروژه مجازیسازی داخل قرارداد است یا جدا؟ |
|
امنیت |
فایروال، دسترسیها، لاگها، Patch و بررسی رخداد |
Incident Response پیشرفته و تست نفوذ چه وضعی دارد؟ |
|
بکاپ |
کنترل Job، ظرفیت، خطا، نمونه Restore و گزارش |
فضای ابری، رسانه ذخیرهسازی و نگهداری خارج سایت چه کسی تأمین میکند؟ |
|
مستندسازی |
نقشه شبکه، لیست IP، تجهیزات، رمزهای مدیریتی کنترلشده |
مالکیت فایلها و روش تحویل در پایان قرارداد مشخص باشد. |
یک نکته تجاری مهم این است که پشتیبانی «فعال» و «پیشگیرانه» از پشتیبانی واکنشی جداست. اگر پیمانکار فقط بعد از تماس کاربر وارد عمل شود، بسیاری از مشکلات—پر شدن دیسک، خطای بکاپ، افزایش Packet Loss یا انقضای گواهی—تا زمان ایجاد اختلال دیده نمیشوند. قرارداد سازمانی بهتر است حداقل برای سرویسهای حیاتی، پایش و گزارش دورهای داشته باشد.
پشتیبانی موردی یا قرارداد ماهانه؟
پشتیبانی موردی زمانی منطقی است که شبکه کوچک، کمتغییر و کمریسک باشد و توقف چندساعته اثر جدی روی کسبوکار نگذارد. در این مدل، شرکت در زمان مشکل درخواست کارشناس میدهد و هزینه بر اساس مراجعه، ساعت یا نوع خدمت محاسبه میشود. مزیت آن هزینه ثابت کمتر است، اما زمان دسترسی به متخصص تضمینشده نیست و شناخت تیم پشتیبان از زیرساخت در هر مراجعه ممکن است از صفر شروع شود.
قرارداد ماهانه برای مجموعهای مناسبتر است که اینترنت، فایلسرور، VPN، تلفن، ERP یا نرمافزار فروش به عملیات روزمره آن متصل است. ارزش قرارداد فقط «تعداد مراجعه» نیست؛ بخشی از هزینه برای آماده نگه داشتن تیم، ثبت سابقه رخدادها، مستندسازی، مانیتورینگ و داشتن مسیر Escalation پرداخت میشود. اگر سه خرابی کوچک در ماه تکرار میشوند، قرارداد خوب باید فقط هر سه را حل نکند؛ باید علت مشترک را پیدا کند و اقدام اصلاحی پیشنهاد دهد.
|
معیار |
پشتیبانی موردی |
قرارداد ماهانه |
|
هزینه ثابت |
کم یا صفر |
دارد؛ بر اساس Scope و SLA |
|
زمان پاسخ |
وابسته به ظرفیت روز |
قابل تعریف در SLA |
|
شناخت زیرساخت |
معمولاً محدود |
با مستندسازی و سابقه تیکت افزایش مییابد |
|
مانیتورینگ و پیشگیری |
اغلب ندارد |
قابل تعریف و گزارشپذیر |
|
مناسب برای |
شبکه کمریسک و ساده |
شرکت وابسته به IT یا چندسرویس حیاتی |
SLA چیست و چه بندهایی باید داشته باشد؟
یا توافق سطح خدمت، بخش قابل سنجش قرارداد است. در آن باید مشخص شود برای هر سطح رخداد چه زمانی «پاسخ اولیه» داده میشود، چه زمانی بررسی فنی شروع میشود، چه شرایطی نیاز به اعزام حضوری دارد و چه مواردی به دلیل وابستگی به اپراتور اینترنت، سازنده نرمافزار یا تأمینکننده تجهیزات از کنترل پیمانکار خارج است. SLA خوب یک عدد ثابت برای همه مشکلات نیست؛ اختلالی که کل شرکت را متوقف کرده باید اولویت متفاوتی با نصب یک پرینتر جدید داشته باشد.
|
سطح رخداد |
نمونه واقعی |
نمونه هدف پاسخ* |
مسیر اقدام |
|
P1 بحرانی |
قطع کامل اینترنت اصلی، Down شدن سرور حیاتی یا VPN تمام شعب |
۱۵ تا ۶۰ دقیقه در پلن حساس |
تماس اضطراری + ریموت فوری + تصمیم اعزام/Failover |
|
P2 بالا |
اختلال یک سرویس مهم یا بخشی از کاربران |
۱ تا ۲ ساعت کاری |
ثبت تیکت + عیبیابی ریموت + اقدام حضوری در صورت نیاز |
|
P3 عادی |
مشکل یک کاربر، پرینتر یا درخواست دسترسی |
۲ تا ۴ ساعت کاری |
صف تیکت و انجام در ساعات کاری |
|
P4 برنامهریزیشده |
تغییر تنظیمات، اضافه کردن کاربر یا بهینهسازی |
طبق زمان توافقشده |
Change Request و زمانبندی خارج از اوج کاری |
*این زمانها نمونه طراحی SLA هستند، نه تعهد قطعی پارادایس ارتباط. زمان واقعی باید بر اساس ساعات پوشش، تعداد تیم، فاصله جغرافیایی و سطح سرویس در قرارداد نوشته شود.
در راهنماهای سرویسهای مدیریتشده AWS نیز زمان پاسخ بر اساس اولویت رخداد و Tier خدمت متفاوت تعریف میشود؛ این الگو نشان میدهد SLA باید «شدت اثر کسبوکار» را وارد تصمیم کند، نه اینکه همه تیکتها زمان پاسخ یکسان داشته باشند. برای قرارداد محلی نیز بهتر است تعریف P1 تا P4، کانال اعلام خرابی، ساعات سرویس، زمان پاسخ، زمان هدف بازیابی و سازوکار Escalation جداگانه نوشته شود.
هزینه پشتیبانی بر چه اساسی تعیین میشود؟
هزینه پشتیبانی شبکه در تهران را نمیتوان فقط از تعداد کامپیوترها محاسبه کرد. دو شرکت هرکدام با ۲۰ کاربر میتوانند هزینه بسیار متفاوتی داشته باشند: یکی یک روتر و یک سرور ساده دارد؛ دیگری چند ماشین مجازی، فایروال، VPN شعب، سرویس VoIP، بکاپ خارج سایت و الزام پاسخ زیر یک ساعت دارد. در بازار ۱۴۰۵ قیمتهای منتشرشده برای قراردادهای ماهانه از حدود تکرقمی تا دهها میلیون تومان دیده میشود و پلنهای سازمانی حتی به بازههای بالاتر میرسند. بنابراین عدد صحیح باید بعد از Inventory و تعیین SLA ساخته شود
|
عامل |
اثر معمول روی هزینه |
سؤال درست قبل از قیمتگیری |
|
تعداد کاربران و نقاط |
افزایش حجم تیکت و نیاز پشتیبانی کاربری |
چند کاربر ثابت، دورکار و شیفتی داریم؟ |
|
سرور و سرویس حیاتی |
نیاز به تخصص، بکاپ و پایش بیشتر |
کدام سرویس اگر قطع شود کسبوکار متوقف میشود؟ |
|
تعداد شعب و لینکها |
پیچیدگی WAN/VPN و اعزام |
چند نقطه جغرافیایی و چه لینک پشتیبانی وجود دارد؟ |
|
تعداد بازدید حضوری |
افزایش ظرفیت زمانی و رفتوآمد |
بازدید ثابت هفتگی لازم است یا فقط Incident؟ |
|
SLA و 24/7 |
رزرو ظرفیت و On-call پرهزینهتر |
ساعات کاری کافی است یا پاسخ شب/تعطیل لازم است؟ |
|
مانیتورینگ و گزارش |
راهاندازی ابزار و تحلیل دورهای |
کدام شاخصها باید پایش و گزارش شوند؟ |
|
امنیت و بکاپ |
کنترل و تست بیشتر |
Backup فقط اجرا شود یا Restore هم آزمایش شود؟ |
|
بازه برنامهریزی ۱۴۰۵: برای یک شرکت کوچک با Scope محدود و SLA اداری، بازار منتشرشده حدود ۹ تا ۲۵ میلیون تومان در ماه نمونه دارد؛ پلنهای متوسط حدود ۱۳ تا ۴۰ میلیون و پوششهای 24/7 یا سازمانی میتوانند به ۲۰ تا ۹۰ میلیون تومان و بیشتر برسند. این اعداد «قیمت پارادایس ارتباط» نیستند و فقط برای فهم پراکندگی بازارند. |
اگر بخشی از مشکلات فعلی شبکه ناشی از کابلکشی، رک، لیبلگذاری یا مسیر فیزیکی است، قبل از قرارداد نگهداری باید هزینه کابل کشی شبکه و Scope اصلاح پسیو جداگانه بررسی شود؛ این لینک پس از انتشار W6-1 بهصورت رفتوبرگشتی فعال شود.
پلن مناسب شرکت کوچک، متوسط و حساس
پلنها بهتر است به جای نامهای مبهم «طلایی» و «نقرهای»، بر اساس خروجی واقعی تعریف شوند. برای یک دفتر کوچک شاید ریموت نامحدود، یک بازدید ماهانه، کنترل بکاپ و SLA چهارساعته کافی باشد. شرکت متوسط معمولاً به بازدیدهای دورهای بیشتر، مانیتورینگ، مدیریت سرور و گزارش ماهانه نیاز دارد. مجموعه حساس—مثل شرکت فروش آنلاین، مرکز تماس یا دفتر چندشعبهای—ممکن است نیازمند پاسخ زیر یک ساعت، مسیر اضطراری، مانیتورینگ 24/7 و Failover تستشده باشد.
|
سناریو |
Scope پیشنهادی |
SLA نمونه |
بازه برنامهریزی ماهانه ۱۴۰۵* |
|
شرکت کوچک ۵–۱۵ کاربر |
ریموت، ۱ بازدید، روتر/سوئیچ، یک سرور یا NAS، بکاپ پایه |
۲ تا ۴ ساعت کاری |
حدود ۹ تا ۲۵ میلیون تومان |
|
شرکت متوسط ۱۵–۵۰ کاربر |
ریموت + ۲ تا ۴ بازدید، سرور/VM، VPN، مانیتورینگ، گزارش |
۱ تا ۲ ساعت برای P1/P2 |
حدود ۱۵ تا ۴۰ میلیون تومان |
|
شرکت حساس/چندشعبهای |
24/7، چند سرور، فایروال، شعب، مانیتورینگ، DR/Failover |
۱۵ تا ۶۰ دقیقه برای P1 |
حدود ۲۰ تا ۹۰ میلیون تومان و بیشتر |
*این بازهها جمعبندی تحریری از نمونه تعرفههای عمومی بازار در مرداد/شهریور ۱۴۰۵ هستند و بهدلیل تفاوت Scope، تعداد تجهیزات و SLA قابل تبدیل به پیشفاکتور قطعی نیستند. قیمت نهایی باید پس از بازدید و Inventory اعلام شود.
اگر در مرحله تجهیز یا جایگزینی سوئیچ، روتر و لوازم شبکه هستید، مشاهده تجهیزات مرتبط با شبکه میتواند برای بررسی گزینههای موجود سایت استفاده شود؛ انتخاب محصول باید بعد از مشخص شدن توپولوژی و نیاز پشتیبانی انجام شود.
مانیتورینگ، بکاپ و امنیت
سه بخشی که معمولاً ارزش قرارداد را از «تعمیرکاری» جدا میکنند، مانیتورینگ، بکاپ و امنیت هستند. مانیتورینگ باید فقط نمایش سبز یا قرمز تجهیزات نباشد؛ باید Threshold تعریف شود و معلوم باشد چه هشداری نیاز به اقدام دارد. بالا رفتن مصرف CPU یک بار در روز ممکن است عادی باشد، اما تکرار Packet Loss روی لینک اصلی در ساعات فروش میتواند یک Incident پیشرو باشد.
در بکاپ، «وجود فایل» با «قابل بازیابی بودن» یکی نیست. قرارداد باید مشخص کند چه دادههایی Backup میشوند، چند نسخه نگهداری میشود، یک نسخه خارج از سرور اصلی وجود دارد یا نه، رمزگذاری چگونه است و Restore نمونه هر چند وقت یکبار آزمایش میشود. برای سرویسهای حیاتی، هدف بازیابی (RTO) و میزان داده قابل از دست رفتن (RPO) باید با مدیر کسبوکار هماهنگ شوند؛ چون هزینه راهکار بکاپ بدون دانستن این دو هدف قابل طراحی نیست.
- مانیتورینگ لینک اینترنت، سرورها، فضای دیسک، سرویسهای حیاتی و تجهیزات کلیدی با Threshold مشخص.
- Patch Management برای سیستمعامل، فایروال و سرویسها با پنجره تغییر و
- Backup روزانه/هفتگی بر اساس سرویس و تست Restore دورهای؛ نه صرفاً مشاهده Successful بودن
- حسابهای مدیریتی مجزا، MFA در نقاط ممکن، اصل Least Privilege و حذف دسترسی کارکنان جداشده.
- گزارش ماهانه شامل Incidentها، علتهای تکرارشونده، ظرفیت، وضعیت بکاپ و اقدامات پیشنهادی.
معیار انتخاب شرکت پشتیبانی
بهترین شرکت پشتیبانی الزاماً شرکتی نیست که کمترین مبلغ ماهانه را اعلام میکند. معیار اصلی این است که آیا میتواند Scope را تبدیل به خروجی قابل اندازهگیری کند یا نه. قبل از قرارداد، یک جلسه فنی کوتاه باید به سؤالات مشخص پاسخ دهد: چه کسی Owner فنی حساب شماست؟ تیکتها کجا ثبت میشوند؟ اگر کارشناس اصلی در دسترس نباشد چه کسی جایگزین است؟ رمزها و مستندات کجا نگهداری میشوند؟ و در پایان همکاری چگونه تحویل داده میشوند؟
|
معیار ارزیابی |
نشانه خوب |
هشدار |
|
SLA مکتوب |
زمان پاسخ و سطح رخداد تعریف شده |
عبارتهایی مثل «در سریعترین زمان» بدون عدد |
|
مستندسازی |
Inventory، نقشه، IP Plan و تاریخچه تغییرات |
وابستگی اطلاعات به حافظه یک نفر |
|
تیم جایگزین |
Escalation و نفر پشتیبان مشخص |
فقط یک کارشناس بدون Backup |
|
امنیت دسترسی |
اکانت شخصی، MFA/VPN، لاگ تغییرات |
رمز مشترک یا Remote عمومی و بدون کنترل |
|
گزارش |
گزارش رخداد و وضعیت دورهای |
فقط فاکتور ماهانه بدون خروجی فنی |
|
تحویل پایان قرارداد |
خروجی اسناد و انتقال دسترسی تعریف شده |
نامشخص بودن مالکیت تنظیمات و فایلها |
در تهران، زمان اعزام نیز بخش مهمی از سرویس است؛ اما بهتر است «زمان پاسخ» با «زمان حضور» اشتباه نشود. ممکن است مشکل در ۲۰ دقیقه ریموت حل شود و اعزام بیفایده باشد. SLA حرفهای ابتدا پاسخ و تشخیص را هدف میگیرد و فقط زمانی اعزام را تعهد میکند که Incident واقعاً نیاز به حضور فیزیکی داشته باشد.
نمونه چکلیست شروع قرارداد
قبل از روز اول قرارداد، یک Baseline فنی ثبت کنید. بدون این مرحله، در ماه اول بخش زیادی از زمان صرف کشف زیرساخت میشود و بعداً مشخص نیست یک مشکل از قبل وجود داشته یا در طول قرارداد ایجاد شده است. خروجی Baseline لازم نیست پیچیده باشد؛ مهم این است که مشترک، قابل بهروزرسانی و در اختیار کارفرما باشد.
- لیست کاربران، کامپیوترها، پرینترها، سرورها، VMها، سوئیچها، روترها، فایروالها و Access Pointها تهیه شود.
- نقشه ساده شبکه، IP Plan، VLANها، لینکهای اینترنت، VPN شعب و مسیرهای حیاتی ثبت شوند.
- لیست سرویسهای حیاتی و Owner کسبوکاری هر سرویس مشخص شود؛ مثلاً مالی، ERP، VoIP یا فایلسرور.
- وضعیت Backup، آخرین Restore موفق، ظرفیت Storage و مقصد Off-site بررسی شود.
- حسابهای مدیریتی، MFA، VPN و فهرست دسترسی پیمانکار ثبت و حسابهای قدیمی حذف شوند.
- Patch Level، Warranty/Support تجهیزات، لایسنسها و تاریخ انقضای سرویسها در تقویم نگهداری ثبت شود.
- SLA، کانال تماس اضطراری، ساعت سرویس، سطح P1 تا P4 و مسیر Escalation با مدیر مجموعه تأیید شود.
- گزارش Baseline با ریسکهای فوری، اقدامات ۳۰روزه و پروژههای خارج از قرارداد تحویل شود.
|
CTA بریف: برای دریافت پیشنهاد SLA، تعداد کاربران و شعب، فهرست سرورها و سرویسهای حیاتی، ساعات کاری و سطح پاسخ مورد انتظار را ارسال کنید. این اطلاعات برای قیمتگذاری بسیار دقیقتر از «تعداد کامپیوتر» بهتنهایی هستند. |
سوالات متداول
اگر شبکه کوچک و خرابی کماثر است، پشتیبانی موردی میتواند اقتصادی باشد. برای شرکتی که توقف اینترنت، سرور، VPN یا نرمافزارهای کاری مستقیماً هزینه ایجاد میکند، قرارداد ماهانه با SLA، مستندسازی و مانیتورینگ قابل دفاعتر است.
عدد ثابت وجود ندارد. نمونه تعرفههای عمومی بازار از حدود ۹ میلیون تومان برای پلنهای محدود شروع میشوند و در سرویسهای متوسط، 24/7 یا سازمانی به دهها میلیون تومان میرسند. تعداد کاربران، سرورها، شعب، ساعات پوشش و SLA تعیینکنندهاند.
بهتر است پاسخ اولیه، شروع بررسی، Escalation و هدف بازیابی جدا تعریف شوند. بعضی خرابیها به اپراتور اینترنت، سازنده نرمافزار یا تأمین قطعه وابستهاند و زمان Resolution کامل همیشه در اختیار تیم پشتیبانی نیست.
خیر. مانیتورینگ 24/7 یعنی ابزار پایش و هشدار فعال است و مسیر پاسخ برای رخداد تعریف شده. حضور فیزیکی باید فقط در صورتی تعهد شود که Scope و SLA آن را پوشش دهند.
فقط وقتی سیاست مشخص داشته باشد: چه دادهای، چند نسخه، چه مدت، کجا و با چه تست Restore. بکاپی که بازیابی آن آزمایش نشده، برای سرویس حیاتی تضمین عملیاتی محسوب نمیشود.
تعداد کاربران و تجهیزات، سرورها، شعب، لینکها، سرویسهای حیاتی، ساعات کاری، وضعیت بکاپ و امنیت و زمان پاسخ مورد انتظار. یک بازدید Baseline کمک میکند Scope دقیق و قابل قیمتگذاری شود.
جمع بندی
قرارداد پشتیبانی شبکه زمانی ارزش دارد که ریسک توقف را به فرآیند قابل مدیریت تبدیل کند. Scope روشن، SLA مبتنی بر شدت رخداد، مستندسازی، مانیتورینگ، بکاپ قابل بازیابی و امنیت دسترسی اجزایی هستند که کیفیت واقعی سرویس را میسازند. هزینه ماهانه نیز باید نتیجه همین طراحی باشد؛ نه عددی که قبل از شناخت شبکه اعلام شده است.
برای شروع، یک صفحه ساده از زیرساخت خود تهیه کنید: تعداد کاربران، سرورها، شعب، سرویسهای حیاتی، ساعات کاری، تعداد بازدید موردنیاز و زمان پاسخ مطلوب. با همین دادهها میتوان مشخص کرد کدام سطح پشتیبانی برای شرکت منطقی است و کدام خدمات باید پروژه جداگانه تعریف شوند.
برای ارزیابی اولیه و دریافت Scope و SLA متناسب با مجموعه، درخواست پشتیبانی شبکه تهران را ثبت کنید؛ قیمت نهایی پس از بررسی وضعیت واقعی شبکه، سرویسهای حیاتی و سطح پاسخ مورد انتظار تعیین شود.
