برای هر سیستم در حال سرویس‌دهی و حتا سرویس‌هایی که در مرحله‌ی راه‌اندازی هستند، مانیتورینگ از اهمیت ویژه‌ای برخوردار است. مانیتورینگ در چند لایه و توسط ابزارهای مختلف انجام می‌شود، اما در بخش NOC چه مواردی باید مانیتور شود؟ بزرگترین دغدغه‌ی مدیران در تیم‌های نگهداری ابتدا این است که سامانه‌های پایش توانایی شناخت درست مشکل را داشته باشند و نفرات تیم درک درستی از اتفاق‌ها و پیشامدها داشته باشند. در صورتی که پنل مانیتورینگ شلوغ و پر از موارد سطح یک باشد، عملا بعد از مدتی نیروهایی که باید اولین حرکت را پس از اتفاق انجام بدهند، نسبت به اتفاق‌ها بی‌حس و پس از مدتی دچار عادت به شرایط همیشه ویژه خواهند شد. در این مقاله قصد دارم با توجه به تجربیات نه‌چندان خوشایند خودم در مدیریت تیم‌های نگهداری، این موارد را تبین کنم.
سطح‌بندی وقایع قطعا هر واقعه یا حادثه‌ی پیش‌آمده حیاتی نیست! پس از مدتی با ازدیاد موارد حیاتی سیستم مانیتورینگ از کار می‌افتد. عملا SLA و OLA نقض خواهد شد و کارها با پیچیده‌شدن در یکدیگر عملا غیر قابل حل خواهند شد. از طرفی اکثر وقایع توسط یک‌نفر یا یک تخصص مورد بررسی نیست و باید توسط چند تخصص مختلف بازبینی شود و این موارد را پیچیده‌تر می‌کند. شناخت مواردی که ممکن‌است پیش‌بیاید و سطح‌بندی آن‌ها این امکان را می‌دهد که ابتدا موارد را از نظر اهمیت دسته‌بندی و مدت زمان مورد نیاز برای حل آن‌ها را پیش‌بینی کنیم. در اکثر سیستم‌های سطح‌بندی در نظر گرفتن چهار یا پنج سطح توصیه می‌شود.
جداسازی زیرساخت از سرویس باید بپذیریم که زیرساخت از سرویس جدا نیست، اما نحوه‌ی نگرش به آن‌ها مهم است. به عنوان نمونه اگر سوییچ هسته‌ی یک زیرساخت از مدار خارج یا دچار مشکل شود، عملا هیچ سرویسی در کار نخواهد بود. برای همین منظور ایجاد افزونگی یا همان Redundancy در لایه‌ی زیرساخت در همه‌ی سطوح توصیه می‌شود. عملا از هر المان در زیرساخت باید دو مورد داشته باشیم با درنظر گرفتن تمام موارد شامل برق، پوپی‌اس، تابلوی مجزا، رک مجزا، حتا دیتاسنترهای موازی برای پوشش سرویس. در این صورت با این جداسازی، نگرش تیم مانیتورینگ نسبت به وقایع پیشامده‌ی زیرساختی با سرویسی متفاوت خواهد بود.
پنل‌های اختصاصی برای نیروی پایش صفحه‌های اختصاصی در نرم‌افزار‌های مانیتورینگ باید در نگاه اول باید به فرد پایشگر بگوید که در سیستم (اعم از زیرساخت و سرویس) مشکلی وجود دارد یا خیر. به همین سادگی! خیلی واضح وضعیت کلی سرویس را با علامت سبز و موراد مشکل را با رنگ قرمز نشان دهد. آلارم‌های صوتی در صورت رخداد حادثه نیز می‌تواند تکمیل کننده‌ی این نگاه اول باشد. اما چه چیزهای دیگری مورد نیاز است؟ صفحه‌ای از تمام وقایع مهم، لیست اتفاق‌ها باید با ذکر ساعت وقوع در جلوی چشم نیروی مانیتورینگ باشد. همچنین در صورتی که نیروی مانیتورینگ واقعه را می‌بیند، باید در بخش Acknowledge هر واقعه موارد پیگیری شده را بنویسد تا موارد دیده نشده یا پیش‌آمده در زمان پیگیری موارد قبلی از قلم نیوفتند. همچنین یادداشت در این بخش می‌تواند برای بررسی موضوع راهگشا باشد. صفحه‌ای برای نمایش ابزارهایی که زیرساخت و سرویس را در زمان‌های منظم تست می‌کنند نیز باید وجود داشته باشد تا سیستم نقص‌های منطقی سرویس را نیز مشخص کند.
تیکت‌شدن هر واقعه درست است که هر موضوعی باید تیکت شود، اما با فرض اینکه در بالاترین لایه‌ی زیرساخت می‌تواند منجر به ایجاد هزاران تیکت شود. ارتباط دادن این حجم از تیکت با موضوع عملا غیر ممکن است. برای همین در این بخش زنجیره‌ی اهمیت و سطح‌بندی اهمیت ویژه‌ای پیدا می‌کند. اما تیکت شدن دستی هر اتفاق با وجود اینکه خالی از عیب نیست، اما در شروع راه‌حل مناسب‌تری است. بررسی روزانه و هفتگی تیکت‌ها باعث فهمیدن نقص در طراحی و جلوگیری از پیشامدهای یکسان می‌شود.
ایجاد پایگاه دانش پس از هر رخداد، باید در پی رفع آن ایراد بود. پس از آن باید در پی یافتن علت بود و سپس ایجاد راهکارهای موقت و قطعی برای جلوگیری از پیشامد یا حل کردن آن مساله بایستی انجام شود. در صورتی که سیستم اصلاح نشود، یک اتفاق بارها و بارها بلای جان سرویس می‌شود. با رفت و آمد نیروها هم معمولا دانش و تجربه به درستی منتقل نمی‌شود. ایجاد پایگاه دانش مبتنی بر تیکت‌ها و قراردادن علت و راهکاری حل مساله می‌تواند کمک شایانی به حل مسائل در موراد بعدی باشد. همچنین کار را برای فرآیند جانشینی و آموزش نیروهای جدید هموار می‌کند.
آموزش، آموزش و آموزش تمامی ابزارها، تست‌ها و تجارب دنیا هیچ تاثیری در سرویس‌دهی بهتر ندارند اگر نیروی مانیتورینگ درک درستی از تصویر کلی زیرساخت و نحوه‌ی عملکرد سرویس نداشته باشد. تشخیص درست در زمان کم مهمترین دستاورد یک تیم نگهداری خوب است. این مهم بدون آموزش مداوم به دست نخواهد آمد.
