۱۰۰ مفهوم شبکه و پشتیبانی را کوتاه و کاربردی یاد بگیرید

VLAN شبکه را در لایه دوم به Broadcast Domainهای جدا تقسیم می‌کند. هدف فقط نظم نیست؛ جداسازی کاربران، سرورها، تلفن‌ها یا مهمان‌ها می‌تواند امنیت و عیب‌یابی را هم بهتر کند. VLAN بدون طراحی IP، Routing و Policy مناسب فقط جداسازی ظاهری است.

Subnet Mask تعیین می‌کند کدام بخش IP متعلق به Network و کدام بخش متعلق به Host است. اشتباه در Mask می‌تواند باعث شود دو سیستم تصور متفاوتی از هم‌محلی شبکه داشته باشند و ترافیک به Gateway اشتباه برود.

CIDR روش فشرده نمایش اندازه شبکه است؛ مثلاً /24 یعنی ۲۴ بیت برای Network. CIDR در طراحی Subnet، Route Summarization و ACLها کاربرد دارد و جایگزین مدل قدیمی Classful شده است.

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

این مهم‌ترین نقش DNS است، اما رکوردهای MX، TXT، SRV، CNAME و PTR نیز برای ایمیل، احراز هویت، سرویس‌یابی و Reverse Lookup استفاده می‌شوند. بسیاری از اختلال‌های ظاهراً «شبکه‌ای» در واقع DNS هستند.

DHCP تنظیمات IP، Gateway، DNS و گزینه‌های دیگر را خودکار به کلاینت‌ها می‌دهد. طراحی بد Scope، Lease یا Relay می‌تواند باعث کمبود IP یا دریافت تنظیمات اشتباه شود.

ARP در IPv4 نگاشت IP محلی به MAC Address را انجام می‌دهد. اگر ARP Table اشتباه، قدیمی یا آلوده شود، ممکن است سیستم IP درست را داشته باشد اما فریم به مقصد درست نرسد.

MAC شناسه لایه دوم رابط شبکه است و IP آدرس منطقی لایه سوم. Switch معمولاً براساس MAC تصمیم می‌گیرد و Router براساس IP. دانستن این تفاوت برای عیب‌یابی مسیر بسیار مهم است.

Trunk چند VLAN را روی یک لینک حمل می‌کند و معمولاً از 802.1Q Tag استفاده می‌کند. عدم تطابق Native VLAN یا Allowed VLAN می‌تواند باعث قطع بخشی از ترافیک شود در حالی که لینک فیزیکی Up است.

Spanning Tree Protocol از Loop لایه دوم جلوگیری می‌کند. بدون STP یک حلقه ساده می‌تواند Broadcast Storm ایجاد کند و کل شبکه را از کار بیندازد. طراحی Redundancy بدون درک STP خطرناک است.

MTU حداکثر اندازه Packet قابل حمل بدون Fragmentation در یک مسیر است. عدم تطابق MTU در VPN، Tunnel یا WAN می‌تواند باعث شود Ping کار کند ولی بعضی سایت‌ها یا Sessionها ناقص باز شوند.

NAT آدرس‌های IP را هنگام عبور از یک مرز شبکه ترجمه می‌کند. رایج‌ترین کاربرد آن اشتراک‌گذاری IP عمومی است، اما در Publish سرویس‌ها و اتصال شبکه‌های هم‌پوشان نیز استفاده می‌شود.

Port یک شماره منطقی برای تفکیک سرویس‌ها روی یک Host است. باز بودن IP به‌تنهایی کافی نیست؛ ممکن است Host در دسترس باشد اما Port سرویس بسته، فیلتر یا Listen نشده باشد.

برای مسیرهای ساده، پایدار و محدود Static Route شفاف و قابل کنترل است. در شبکه بزرگ یا پویا، نگهداری دستی Routeها می‌تواند خطاپذیر شود و Routing Protocolها مناسب‌تر باشند.

خیر. قدرت سیگنال فقط یکی از عوامل است. Interference، Channel Utilization، تعداد Client، Roaming، Backhaul و ظرفیت AP نیز کیفیت واقعی را تعیین می‌کنند.

مانیتورینگ زمان بین شروع مشکل و آگاه شدن تیم را کاهش می‌دهد. ارزش واقعی وقتی ایجاد می‌شود که Alert به اقدام، Ticket و تحلیل علت متصل شود؛ نه صرفاً تعداد نمودارها بیشتر شود.

ممکن است سرویس Up باشد اما بسیار کند کار کند. Availability می‌گوید سرویس قابل دسترس است؛ Performance می‌گوید با چه کیفیتی پاسخ می‌دهد. پشتیبانی حرفه‌ای هر دو را می‌سنجد.

نه. عدد ثابت برای همه تجهیزات و ساعات لزوماً مناسب نیست. Baseline، Trend و الگوی مصرف کمک می‌کنند هشدارها با رفتار واقعی سرویس هم‌خوان‌تر شوند.

وقتی تیم با تعداد زیادی هشدار کم‌اهمیت روبه‌رو شود، حساسیتش به Alert واقعی کم می‌شود. راه‌حل، حذف مانیتورینگ نیست؛ تنظیم Severity، Deduplication، Dependency و Escalation است.

SNMP برای خواندن وضعیت و Counterهای تجهیزات و در برخی سناریوها اعمال تنظیمات استفاده می‌شود. Interface Traffic، CPU، Temperature و Errorها از داده‌های رایج آن هستند.

Metric می‌گوید چه چیزی تغییر کرده؛ Syslog اغلب توضیح می‌دهد چه رویدادی رخ داده است. ترکیب Event و Metric می‌تواند مسیر تشخیص را بسیار کوتاه‌تر کند.

یک عدد واحد برای همه سرویس‌ها وجود ندارد. Voice، Video و Remote Session به Loss و Jitter حساس‌ترند. اهمیت Loss باید با نوع سرویس، مدت و محل وقوع سنجیده شود.

Jitter تغییرپذیری زمان رسیدن Packetهاست. حتی اگر میانگین Latency مناسب باشد، Jitter بالا می‌تواند Voice و Video را خراب کند.

بسیاری از بحران‌ها ناگهانی نیستند؛ Disk، Bandwidth، Memory یا Sessionها آرام‌آرام به سقف نزدیک می‌شوند. Trend ظرفیت فرصت می‌دهد قبل از Incident اقدام شود.

اگر یک Core Switch Down شود ممکن است ده‌ها Alert فرعی ساخته شود. شناخت Dependency کمک می‌کند Root Cause از علائم ثانویه جدا شود و تیم روی نقطه درست تمرکز کند.

Monitoring ابزار دیدن است؛ NOC مدل عملیاتی برای مشاهده، تحلیل، Escalation و هماهنگی پاسخ است. داشتن داشبورد به‌تنهایی NOC نمی‌سازد.

Baseline رفتار معمول یک سرویس یا تجهیز در شرایط عادی است. بدون Baseline ممکن است افزایش تدریجی مصرف یا افت کیفیت دیده نشود چون هنوز از Threshold ثابت عبور نکرده است.

Mean Time to Detect میانگین زمانی است که طول می‌کشد تیم از شروع مشکل باخبر شود. مانیتورینگ و Alerting خوب باید MTTD را کم کند، اما فقط وقتی هشدار قابل اقدام باشد.

Endpoint هر دستگاه انتهایی متصل به شبکه است؛ لپ‌تاپ، دسکتاپ، سرور، موبایل یا حتی برخی تجهیزات تخصصی. در عملیات پشتیبانی معمولاً تمرکز Endpoint Management روی دستگاه‌های کاربری و سرورهاست.

Patch فقط موضوع امنیت نیست. نسخه‌های قدیمی سیستم‌عامل و نرم‌افزار می‌توانند خطا، ناسازگاری و هزینه پشتیبانی ایجاد کنند. Patch Management منظم هم ریسک و هم Incident قابل پیشگیری را کم می‌کند.

وقتی مدل دستگاه، RAM، Disk، سیستم‌عامل و نرم‌افزارها معلوم باشد، کارشناس برای هر Ticket از صفر سؤال نمی‌پرسد. Inventory خوب زمان تشخیص را کم و تصمیم خرید را هم دقیق‌تر می‌کند.

وقتی حضور و رضایت کاربر بخشی از سیاست سازمان است، Attended Support مناسب‌تر است. برای سرور یا سیستم‌های بدون کاربر ممکن است Unattended Access با کنترل دسترسی قوی‌تر لازم باشد.

هر ابزار Agent، حساب، Policy و مسیر اتصال خودش را دارد. تعدد ابزار باعث پیچیدگی، ضعف Audit و سردرگمی کارشناس می‌شود. استانداردسازی Remote Support هزینه عملیاتی را کم می‌کند.

دسترسی Local Admin سطح اثر Malware و خطای انسانی را بالا می‌برد. بهتر است نصب و تغییرات حساس با فرآیند مشخص یا ابزار مدیریتی انجام شوند، نه با Administrator دائمی.

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

پر شدن Disk یکی از علت‌های رایج اختلال سرویس و کندی Endpoint است. Trend ظرفیت اجازه می‌دهد قبل از رسیدن به مرز بحرانی اقدام شود.

ممکن است Server و Network Up باشند اما کاربر با Login، DNS، Profile، Browser یا Endpoint مشکل داشته باشد. سلامت فنی زیرساخت معادل تجربه خوب کاربر نیست.

بسته به سازمان: CPU، Memory، Disk، Patch، Antivirus، Connectivity، Serviceهای حیاتی و خطاهای تکراری. هدف جمع‌کردن داده نیست؛ پیدا کردن نشانه‌هایی است که به اقدام منجر می‌شوند.

User Account Control اجرای عملیات با سطح دسترسی بالاتر را قابل تشخیص‌تر می‌کند. خاموش کردن UAC برای راحتی پشتیبانی معمولاً انتخاب مناسبی نیست؛ ابزار Remote باید Elevation را درست مدیریت کند.

ثبت زمان، کارشناس، دستگاه و نتیجه Session برای Audit، پیگیری Ticket و حل اختلاف مفید است. برای محیط حساس ممکن است Session Recording هم لازم باشد.

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

درخواست استاندارد کاربر مثل نصب نرم‌افزار، ایجاد دسترسی یا تحویل تجهیزات Service Request است، نه Incident. جداکردن این دو باعث می‌شود آمار خرابی واقعی‌تر بماند.

Problem علت یا علت احتمالی یک یا چند Incident است. اگر یک اختلال مرتب تکرار شود، بستن Ticketها کافی نیست؛ باید الگو و علت ریشه‌ای بررسی شود.

Known Error مشکلی است که علت یا Workaround آن شناخته شده است. ثبت آن کمک می‌کند Incidentهای بعدی سریع‌تر حل شوند تا زمانی که اصلاح نهایی انجام شود.

تغییرات زیرساخت می‌توانند Incident جدید بسازند. ثبت دلیل، مسئول، زمان، ریسک و Rollback باعث می‌شود تغییر قابل کنترل و قابل بازبینی باشد.

Service Level Agreement تعهد سطح خدمت است؛ مثلاً زمان پاسخ، زمان بازیابی یا Availability. SLA زمانی ارزش دارد که تعریف روشن، داده قابل اندازه‌گیری و گزارش منظم داشته باشد.

Operational Level Agreement توافق داخلی بین تیم‌ها برای پشتیبانی از SLA بیرونی است. اگر تیم شبکه، سرور و Service Desk تعهد داخلی روشن نداشته باشند، SLA مشتری ممکن است روی کاغذ بماند.

Severity شدت فنی یا اثر مشکل را توصیف می‌کند؛ Priority تعیین می‌کند چه زمانی باید به آن رسیدگی شود. Priority معمولاً ترکیبی از Impact و Urgency است.

وقتی زمان، سطح تخصص، ریسک یا اثر Incident از محدوده تیم فعلی خارج شود، Escalation لازم است. Escalation خوب از قبل تعریف شده و وابسته به شناخت شخصی افراد نیست.

Backlog تعداد کارهای باز انباشته‌شده است. افزایش پیوسته آن می‌تواند نشانه کمبود ظرفیت، ضعف اولویت‌بندی یا مشکلات تکراری باشد؛ صرف تعداد Ticket بسته‌شده کافی نیست.

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

Mean Time to Repair یا Restore میانگین زمانی برای بازگرداندن سرویس است. کاهش MTTR معمولاً با تشخیص سریع‌تر، Runbook بهتر، دسترسی مناسب و Escalation روشن حاصل می‌شود.

Knowledge Base راه‌حل‌های تکرارشونده و تجربه تیم را از ذهن افراد خارج می‌کند. مقاله خوب باید قابل جستجو، به‌روز و متصل به Problem یا Service مرتبط باشد.

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

Major Incident رخدادی با اثر بالا است که نیاز به هماهنگی سریع، نقش‌های مشخص، ارتباطات و گاهی War Room دارد. همه Incidentها نباید با همان شدت مدیریت شوند.

هر کاربر یا کارشناس فقط به حداقل دسترسی لازم برای انجام وظیفه دسترسی داشته باشد. این اصل دامنه اثر خطا، سوءاستفاده و Malware را کم می‌کند.

حساب‌های پشتیبانی معمولاً دسترسی گسترده دارند. MFA ریسک سوءاستفاده از رمز افشاشده را کاهش می‌دهد، به‌ویژه برای VPN، Remote Access و پنل‌های مدیریتی.

برای دسترسی‌های ممتاز مثل Domain Admin، Firewall، Hypervisor یا Database، PAM می‌تواند Credential، Approval و Session را کنترل کند. برای هر Remote ساده کاربر الزاماً PAM لازم نیست.

ISMS کنترل دسترسی، Asset، Incident، Change، Backup، Logging و Supplier را به مدیریت ریسک امنیت اطلاعات متصل می‌کند. پشتیبانی شبکه در عمل با بسیاری از همین کنترل‌ها درگیر است.

GRC کمک می‌کند ریسک، کنترل، الزام، شواهد و مسئولیت از کار روزانه جدا نباشند. یک تغییر یا دسترسی حساس می‌تواند هم‌زمان اثر عملیاتی و حاکمیتی داشته باشد.

Rule بدون Owner و دلیل کسب‌وکاری معمولاً سال‌ها باقی می‌ماند. Owner کمک می‌کند هنگام Review بدانیم Rule هنوز لازم است یا باید حذف شود.

خیر. VPN فقط مسیر رمزگذاری‌شده یا دسترسی شبکه می‌دهد. هویت، MFA، سطح دسترسی، Endpoint Security و Audit همچنان مهم‌اند.

Logging رویدادها را ثبت می‌کند؛ Monitoring داده را برای تشخیص وضعیت و هشدار تحلیل می‌کند. هر دو لازم‌اند و SIEM یا Log Management می‌تواند دید امنیتی عمیق‌تر بدهد.

خیر. Backup باید قابل بازیابی، محافظت‌شده، دوره‌ای تست‌شده و متناسب با RPO/RTO باشد. نسخه‌ای که Restore آن آزموده نشده تضمین تداوم نیست.

تقسیم شبکه به Zone یا VLAN مناسب می‌تواند حرکت جانبی مهاجم و دامنه Broadcast را محدود کند. Segmentation باید با Policy و نیاز سرویس هماهنگ باشد.

نه. Vulnerability یک ضعف است؛ Risk نتیجه ترکیب احتمال، اثر، Exposure و کنترل‌هاست. یک ضعف بحرانی روی سیستم غیرحیاتی ممکن است اولویت متفاوتی از ضعف متوسط روی سرویس حیاتی داشته باشد.

Zero Trust یعنی اعتماد دائمی و ضمنی نداشته باشیم؛ هویت، Context، Device و Policy برای هر دسترسی ارزیابی شوند. هدف کنترل پیوسته است، نه بی‌اعتمادی انسانی.

Audit Trail نشان می‌دهد چه کسی چه تغییری را چه زمانی انجام داده است. در اختلال یا ممیزی، این تاریخچه برای فهم علت و پاسخ‌گویی بسیار ارزشمند است.

Hypervisor لایه‌ای است که ماشین‌های مجازی را اجرا و منابع سخت‌افزاری را بین آن‌ها تقسیم می‌کند. سلامت Host، Storage و Network آن می‌تواند روی چندین سرویس هم‌زمان اثر بگذارد.

High Availability برای کاهش Downtime سرویس است؛ Backup برای بازیابی داده یا وضعیت قبلی. HA جای Backup را نمی‌گیرد و Backup هم الزاماً Availability لحظه‌ای نمی‌دهد.

خیر. RAID خرابی برخی Diskها را تحمل می‌کند اما حذف فایل، Ransomware، خرابی منطقی یا حادثه سایت را پوشش نمی‌دهد.

در محیط‌های حیاتی بهتر است سرویس‌های زیرساختی Single Point of Failure نباشند. مدل Redundancy باید با طراحی Active Directory و شبکه هماهنگ شود.

هویت، Group Policy، Authentication و بسیاری از سرویس‌های سازمانی به AD وابسته‌اند. اختلال AD می‌تواند ظاهراً ده‌ها مشکل مجزا برای کاربران ایجاد کند.

GPO می‌تواند روی تعداد زیادی سیستم اثر بگذارد. تغییر بدون Scope، Test و Rollback مناسب ممکن است یک تنظیم اشتباه را در کل سازمان پخش کند.

اختلاف زمان می‌تواند Authentication، Certificate، Log Correlation و Kerberos را خراب کند. NTP یکی از سرویس‌های ساده اما حیاتی زیرساخت است.

کندی Storage می‌تواند روی چند VM و Database هم‌زمان اثر بگذارد و به شکل CPU یا Application Slowness دیده شود. فقط Capacity کافی نیست؛ Latency و IOPS هم مهم‌اند.

Recovery Point Objective مشخص می‌کند سازمان حداکثر چه مقدار از داده را از نظر زمان می‌تواند از دست بدهد. RPO روی فاصله Backup یا Replication اثر مستقیم دارد.

Recovery Time Objective مدت هدف برای بازگرداندن سرویس پس از اختلال است. RTO باید با اهمیت سرویس و توان واقعی بازیابی هماهنگ باشد.

Backup فقط برای فایل و Database نیست. Config تجهیزات شبکه، Firewall و سرویس‌های زیرساختی نیز باید نسخه‌بندی و قابل بازیابی باشند.

جزئی که خرابی آن به‌تنهایی می‌تواند کل سرویس را متوقف کند. شناسایی SPOF یکی از کارهای مهم در طراحی و بازبینی زیرساخت است.

Ping فقط ICMP و Reachability پایه را نشان می‌دهد. DNS، TCP Port، TLS، Proxy، Firewall یا خود Application می‌تواند مشکل داشته باشد.

اول Scope را مشخص کنید: یک کاربر، یک VLAN، یک سایت یا همه سازمان؟ محدود کردن دامنه مشکل جلوی تغییرات تصادفی و اتلاف زمان را می‌گیرد.

Traceroute مسیر تقریبی Hopها و محل افزایش Latency یا قطع پاسخ را نشان می‌دهد. عدم پاسخ یک Hop الزاماً به معنی خرابی نیست چون بعضی تجهیزات ICMP را محدود می‌کنند.

برای بررسی Name Resolution، رکورد، Server پاسخ‌دهنده و بعضی جزئیات DNS. اگر IP مستقیم کار می‌کند اما نام نه، DNS یکی از مظنون‌های اصلی است.

کاربر به سرویس روی یک Port مشخص نیاز دارد. ممکن است Host Ping شود اما TCP/443 یا TCP/3389 بسته باشد. تست Port به واقعیت سرویس نزدیک‌تر است.

قطع و وصل تصادفی، ARP متغیر، دسترسی ناپایدار یا هشدار سیستم‌عامل. بررسی DHCP، Static IP و ARP Table معمولاً مسیر تشخیص را روشن می‌کند.

پس از تغییر رکورد ممکن است Client یا Resolver هنوز مقدار قدیمی را نگه دارد. TTL و Cache باید قبل از نتیجه‌گیری درباره انتشار DNS بررسی شوند.

Restart ممکن است علامت را موقتاً حذف کند اما علت را پنهان کند. برای Incident تکراری باید Log، Trend و Root Cause بررسی شوند.

وقتی بعد از Change مشکلی ایجاد شده، مقایسه نسخه قبل و بعد Config می‌تواند تغییر مؤثر را سریع‌تر آشکار کند.

اگر تست‌ها و نتیجه‌ها ثبت نشوند، نفر بعدی همان مسیر را دوباره طی می‌کند. ثبت شواهد، زمان حل Incidentهای مشابه را کاهش می‌دهد.

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

KPI باید نتیجه را نشان دهد، نه فقط حجم کار. SLA، MTTR، Availability، Backlog، Incident تکراری و رضایت کاربر نمونه‌اند؛ انتخاب نهایی به هدف سرویس بستگی دارد.

KPI عملکرد را می‌سنجد؛ KRI نزدیک شدن به ریسک را هشدار می‌دهد. مثلاً درصد Backup موفق KPI است و تعداد Backupهای بدون تست Restore می‌تواند یک شاخص ریسک باشد.

جلسه دوره‌ای برای مرور SLA، Incidentهای مهم، Problemها، ظرفیت، ریسک و اقدامات باز. Service Review نباید فقط گزارش تعداد Ticket باشد.

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

Criticality، وابستگی سرویس، داده و اثر کسب‌وکاری متفاوت است. مدل پشتیبانی باید Monitoring، SLA و کنترل را متناسب با اهمیت دارایی تنظیم کند.

RACI روشن می‌کند چه کسی اجراکننده، پاسخ‌گو، مشاور و مطلع است. در Incident، Change و پروژه‌ها این شفافیت از پاس‌کاری مسئولیت جلوگیری می‌کند.

بعضی Incidentها به ISP، تولیدکننده، پیمانکار یا سرویس ابری وابسته‌اند. مالکیت Escalation و SLA Vendor باید از قبل روشن باشد تا زمان در بحران از دست نرود.

Managed Support بر نتیجه، فرآیند، مانیتورینگ، SLA، گزارش و بهبود مستمر تکیه دارد؛ نه صرفاً ساعت حضور یک فرد. مدل می‌تواند ترکیبی از Remote و On-site باشد.

چون تجربه عملی نشان می‌دهد نیروی متخصص بدون Visibility، Process و Governance مقیاس‌پذیر نیست. ابزار داده می‌دهد، ITIL فرآیند می‌دهد و COBIT/GRC مسئولیت و ریسک را به تصمیم مدیریتی وصل می‌کنند.