چگونه زیرساخت شبکه خود را کنترل کنیم فصل اول. نگه دارید

این مقاله اولین مقاله از سری مقالات «چگونه کنترل زیرساخت شبکه خود را در دست بگیرید» است. محتویات تمام مقالات این مجموعه و پیوندها را می توان یافت اینجا.

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

بنابراین، شرایط اولیه.

شما در شغل جدیدی هستید، ترفیع دریافت کرده اید یا تصمیم گرفته اید نگاهی تازه به مسئولیت های خود داشته باشید. شبکه شرکت حوزه مسئولیت شماست. برای شما، این از بسیاری جهات یک چالش و جدید است، که تا حدودی لحن مربیگری این مقاله را توجیه می کند :). اما امیدوارم این مقاله بتواند برای هر مهندس شبکه نیز مفید باشد.

اولین هدف استراتژیک شما این است که یاد بگیرید در برابر آنتروپی مقاومت کنید و سطح خدمات ارائه شده را حفظ کنید.

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

Оборудование

ابتدا باید بفهمید که بزرگترین خطرات کجاست.

باز هم می تواند متفاوت باشد. اعتراف می کنم که یک جایی مثلاً اینها مسائل امنیتی خواهد بود و یک جایی مسائل مربوط به تداوم سرویس و یک جایی شاید چیز دیگری. چرا که نه؟

بیایید فرض کنیم، برای روشن شدن، این هنوز تداوم خدمات است (این مورد در همه شرکت‌هایی بود که من در آنها کار می‌کردم).

سپس باید با تجهیزات شروع کنید. در اینجا لیستی از موضوعاتی است که باید به آنها توجه کنید:

  • طبقه بندی تجهیزات بر اساس درجه بحرانی
  • پشتیبان گیری از تجهیزات حیاتی
  • پشتیبانی، مجوزها

شما باید در مورد سناریوهای شکست احتمالی فکر کنید، به خصوص با تجهیزاتی که در بالای طبقه بندی بحرانی شما قرار دارند. معمولاً احتمال بروز مشکلات مضاعف نادیده گرفته می شود، در غیر این صورت راه حل و پشتیبانی شما ممکن است به طور غیر منطقی گران شود، اما در مورد عناصر واقعاً حیاتی شبکه که شکست آنها می تواند تأثیر قابل توجهی بر تجارت داشته باشد، باید در مورد آن فکر کنید.

مثال

فرض کنید در مورد سوئیچ ریشه در یک مرکز داده صحبت می کنیم.

از آنجایی که ما توافق کردیم که تداوم خدمات مهمترین معیار است، منطقی است که پشتیبان گیری (زائد) "داغ" از این تجهیزات ارائه شود. اما این همه ماجرا نیست. شما همچنین باید تصمیم بگیرید که اگر سوئیچ اول خراب شود، چه مدت برای شما قابل قبول است که تنها با یک سوئیچ باقی مانده زندگی کنید، زیرا این خطر وجود دارد که سوئیچ نیز خراب شود.

مهم! لازم نیست خودتان در این مورد تصمیم بگیرید. شما باید ریسک ها، راه حل های ممکن و هزینه های مدیریت یا مدیریت شرکت را شرح دهید. آنها باید تصمیم بگیرند.

بنابراین، اگر تصمیم گرفته شد که با توجه به احتمال کوچک خرابی مضاعف، در اصل، 4 ساعت کار روی یک سوئیچ قابل قبول است، می توانید به سادگی از پشتیبانی مناسب استفاده کنید (بر اساس آن تجهیزات ظرف 4 تعویض می شوند. ساعت ها).

اما این خطر وجود دارد که آنها را تحویل ندهند. متأسفانه یک بار در چنین شرایطی قرار گرفتیم. وسایل به جای چهار ساعت یک هفته رفت!!!

بنابراین، این خطر نیز نیاز به بحث دارد و شاید بهتر باشد که سوئیچ دیگری بخرید (سوم) و آن را در بسته لوازم یدکی (پشتیبان "سرد") نگهداری کنید یا از آن برای اهداف آزمایشگاهی استفاده کنید.

مهم! یک صفحه گسترده از تمام پشتیبانی هایی که دارید با تاریخ انقضا تهیه کنید و آن را به تقویم خود اضافه کنید تا حداقل یک ماه قبل ایمیلی دریافت کنید که باید نگران تمدید پشتیبانی خود باشید.

اگر فراموش کنید پشتیبانی خود را تمدید کنید و روز پس از پایان آن سخت افزار شما خراب شود، بخشیده نخواهید شد.

کار اضطراری

هر اتفاقی که در شبکه شما بیفتد، در حالت ایده آل باید دسترسی به تجهیزات شبکه خود را حفظ کنید.

مهم! شما باید به تمام تجهیزات دسترسی کنسول داشته باشید و این دسترسی نباید به سلامت شبکه داده کاربر بستگی داشته باشد.

همچنین باید سناریوهای منفی احتمالی را از قبل پیش بینی کرده و اقدامات لازم را مستندسازی کنید. در دسترس بودن این سند نیز حیاتی است، بنابراین نه تنها باید در یک منبع مشترک برای بخش پست شود، بلکه باید به صورت محلی در رایانه های مهندسان ذخیره شود.

باید وجود داشته باشد

  • اطلاعات مورد نیاز برای باز کردن بلیط با پشتیبانی فروشنده یا ادغام کننده
  • اطلاعاتی در مورد نحوه دسترسی به هر تجهیزات (کنسول، مدیریت)

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

همکاران فروش

اکنون باید خطرات مرتبط با شرکا را ارزیابی کنید. معمولا این

  • ارائه دهندگان اینترنت و نقاط تبادل ترافیک (IX)
  • ارائه دهندگان کانال های ارتباطی

چه سوالاتی باید از خود بپرسید؟ همانند تجهیزات، سناریوهای مختلف اضطراری باید در نظر گرفته شوند. به عنوان مثال، برای ارائه دهندگان اینترنت، می تواند چیزی شبیه به:

  • اگر ارائه دهنده اینترنت X به دلایلی ارائه خدمات به شما را متوقف کند چه اتفاقی می افتد؟
  • آیا سایر ارائه دهندگان پهنای باند کافی برای شما خواهند داشت؟
  • اتصال چقدر خوب باقی خواهد ماند؟
  • ارائه دهندگان اینترنت شما چقدر مستقل هستند و آیا قطعی جدی یکی از آنها باعث ایجاد مشکل برای سایرین می شود؟
  • چند ورودی نوری به مرکز داده شما؟
  • اگر یکی از ورودی ها به طور کامل از بین برود چه اتفاقی می افتد؟

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

و البته نه تنها باید این سوالات را بپرسید، بلکه باز هم با حمایت مدیریت، در هر شرایطی راه حل قابل قبولی ارائه دهید.

پشتیبان گیری

اولویت بعدی ممکن است تهیه نسخه پشتیبان از تنظیمات تجهیزات باشد. در هر صورت این نکته بسیار مهمی است. من مواردی را که می توانید پیکربندی را از دست بدهید لیست نمی کنم؛ بهتر است به طور منظم نسخه پشتیبان تهیه کنید و به آن فکر نکنید. علاوه بر این، پشتیبان گیری معمولی می تواند در نظارت بر تغییرات بسیار مفید باشد.

مهم! روزانه پشتیبان تهیه کنید. این حجم زیادی از داده برای صرفه جویی در این مورد نیست. صبح مهندس کشیک (یا شما) باید گزارشی از سیستم دریافت کند که به وضوح نشان می دهد که آیا بک آپ گیری موفق بوده یا خیر و در صورت ناموفق بودن بک آپ باید مشکل برطرف شود یا تیکت ایجاد شود ( فرآیندهای بخش شبکه را ببینید).

نسخه های نرم افزار

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

در اینجا باید بهترین گزینه را پیدا کنید. چند توصیه واضح

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

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

در مورد تجهیزات حیاتی، می‌توانید با پشتیبانی فروشنده تماس بگیرید تا در ارتقاء به شما کمک کند.

سیستم بلیط

حالا می توانید به اطراف نگاه کنید. شما باید فرآیندهایی را برای تعامل با سایر بخش ها و درون بخش ایجاد کنید.

این ممکن است ضروری نباشد (مثلاً اگر شرکت شما کوچک است)، اما من به شدت توصیه می کنم کار را به گونه ای سازماندهی کنید که تمام کارهای خارجی و داخلی از طریق سیستم بلیط انجام شود.

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

بیایید یک مثال از یک کار مهم و رایج باز کردن دسترسی را مثال بزنیم. من الگوریتمی را شرح خواهم داد که در یکی از شرکت ها به خوبی کار می کرد.

مثال

بیایید با این واقعیت شروع کنیم که اغلب مشتریان دسترسی خواسته های خود را به زبانی غیرقابل درک برای یک مهندس شبکه فرموله می کنند، به عنوان مثال، به زبان برنامه، به عنوان مثال، "به من دسترسی به 1C بدهید."

بنابراین، ما هرگز مستقیماً درخواست چنین کاربرانی را نپذیرفته ایم.
و این اولین نیاز بود

  • درخواست‌های دسترسی باید از بخش‌های فنی باشد (در مورد ما اینها یونیکس، ویندوز، مهندسین Helpdesk بودند)

شرط دوم این است که

  • این دسترسی باید ثبت شود (توسط بخش فنی که ما این درخواست را از آن دریافت کردیم) و به عنوان یک درخواست پیوندی به این دسترسی ثبت شده دریافت می کنیم

شکل این درخواست باید برای ما قابل درک باشد، یعنی.

  • درخواست باید حاوی اطلاعاتی در مورد اینکه کدام زیرشبکه و دسترسی به زیرشبکه باید باز باشد، و همچنین پروتکل و پورت‌ها (در مورد tcp/udp) باشد.

همچنین باید در آنجا مشخص شود

  • توضیح اینکه چرا این دسترسی باز شده است
  • موقت یا دائم (اگر موقت، تا چه تاریخی)

و یک نکته بسیار مهم مصوبات است

  • از رئیس دپارتمان که دسترسی را آغاز کرده است (به عنوان مثال، حسابداری)
  • از رئیس بخش فنی، از جایی که این درخواست به بخش شبکه رسید (مثلاً میز پشتیبانی)

در این حالت، "مالک" این دسترسی به عنوان رئیس بخشی در نظر گرفته می شود که دسترسی را آغاز کرده است (حسابداری در مثال ما) و او مسئول اطمینان از به روز ماندن صفحه با دسترسی ثبت شده برای این بخش است. .

ورود به سیستم

این چیزی است که می توانید در آن غرق شوید. اما اگر می خواهید یک رویکرد پیشگیرانه را پیاده سازی کنید، باید یاد بگیرید که چگونه با این سیل داده ها مقابله کنید.

در اینجا چند توصیه عملی وجود دارد:

  • شما باید گزارش ها را روزانه مرور کنید
  • در مورد یک بررسی برنامه ریزی شده (و نه وضعیت اضطراری)، می توانید خود را به سطوح شدت 0، 1، 2 محدود کنید و اگر لازم می دانید الگوهای انتخابی از سطوح دیگر را اضافه کنید.
  • اسکریپتی بنویسید که لاگ ها را تجزیه کند و لاگ هایی را که الگوهای آنها را به لیست نادیده اضافه کرده اید نادیده بگیرد.

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

نظارت

این غیر معمول نیست که یک شرکت فاقد سیستم نظارت باشد. برای مثال، می‌توانید به گزارش‌ها تکیه کنید، اما ممکن است تجهیزات به سادگی «بمیرند» بدون اینکه وقت «گفتن» چیزی داشته باشند، یا بسته پروتکل udp syslog ممکن است گم شود و نرسد. به طور کلی البته نظارت فعال مهم و ضروری است.

دو نمونه محبوب ترین در عمل من:

  • نظارت بر بار کانال های ارتباطی، لینک های حیاتی (به عنوان مثال، اتصال به ارائه دهندگان). آنها به شما این امکان را می دهند که به طور فعال مشکل بالقوه کاهش خدمات را به دلیل از دست دادن ترافیک مشاهده کنید و بر این اساس از آن اجتناب کنید.
  • نمودارهای مبتنی بر NetFlow آنها پیدا کردن ناهنجاری ها در ترافیک را آسان می کنند و برای شناسایی انواع ساده اما قابل توجه حملات هکرها بسیار مفید هستند.

مهم! اعلان های پیامکی را برای مهم ترین رویدادها تنظیم کنید. این هم در مورد نظارت و هم برای ثبت گزارش صدق می کند. اگر شیفت کاری ندارید، پیامک نیز باید خارج از ساعات کاری برسد.

در طول فرآیند به گونه ای فکر کنید که همه مهندسان را از خواب بیدار نکنید. برای این کار یک مهندس وظیفه داشتیم.

کنترل را تغییر دهید

به نظر من کنترل همه تغییرات لازم نیست. اما، در هر صورت، در صورت لزوم، باید بتوانید به راحتی متوجه شوید که چه کسی و چرا تغییرات خاصی را در شبکه ایجاد کرده است.

چند راهنمایی:

  • از یک سیستم بلیط برای جزئیات بیشتر کارهایی که روی آن بلیط انجام شده است استفاده کنید، به عنوان مثال با کپی کردن پیکربندی اعمال شده در بلیط
  • از قابلیت های اظهار نظر در تجهیزات شبکه استفاده کنید (به عنوان مثال، کامنت نظر در Juniper). می توانید شماره بلیط را یادداشت کنید
  • از نسخه های پشتیبان پیکربندی خود استفاده کنید

شما می توانید این را به عنوان یک فرآیند پیاده سازی کنید و همه بلیط ها را روزانه برای تغییرات بررسی کنید.

فرایندها

شما باید فرآیندهای تیم خود را رسمی و توصیف کنید. اگر به این نقطه رسیده اید، تیم شما باید حداقل فرآیندهای زیر را در حال اجرا داشته باشد:

فرآیندهای روزانه:

  • کار با بلیط
  • کار با سیاهههای مربوط
  • تغییر کنترل
  • برگه چک روزانه

فرآیندهای سالانه:

  • تمدید ضمانت ها، مجوزها

فرآیندهای ناهمزمان:

  • پاسخ به شرایط مختلف اضطراری

نتیجه گیری قسمت اول

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

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

قسمت های زیر به شما می گویند که چگونه خطاها را پیدا و حذف کنید و سپس زیرساخت خود را بهبود ببخشید.

البته لازم نیست همه کارها را پشت سر هم انجام دهید. زمان می تواند حیاتی باشد. اگر منابع اجازه می دهند این کار را به صورت موازی انجام دهید.

و یک اضافه مهم با تیم خود ارتباط برقرار کنید، بپرسید، مشورت کنید. در نهایت آنها هستند که همه اینها را حمایت می کنند و انجام می دهند.

منبع: www.habr.com

اضافه کردن نظر