Şəbəkə infrastrukturunuza necə nəzarət etmək olar. Birinci fəsil. Tutun

Bu məqalə “Şəbəkə İnfrastrukturunuza Necə Nəzarət Edin” məqalələr silsiləsində birincidir. Serialdakı bütün məqalələrin məzmunu və keçidləri ilə tanış ola bilərsiniz burada.

Tamamilə etiraf edirəm ki, şəbəkənin bir saat və ya hətta bir gün dayanmasının kritik olmadığı kifayət qədər sayda şirkət var. Təəssüf ki, ya xoşbəxtlikdən belə yerlərdə işləmək imkanım olmadı. Ancaq, əlbəttə ki, şəbəkələr fərqlidir, tələblər fərqlidir, yanaşmalar fərqlidir və buna baxmayaraq, bu və ya digər formada aşağıdakı siyahı bir çox hallarda həqiqətən "edilməli" olacaq.

Beləliklə, ilkin şərtlər.

Yeni bir işdəsiniz, yüksəliş almısınız və ya öhdəliklərinizə yeni bir nəzər salmaq qərarına gəldiniz. Şirkət şəbəkəsi sizin məsuliyyət sahənizdir. Sizin üçün bu, bir çox cəhətdən çətin və yenidir, bu məqalənin mentorluq tonunu bir qədər əsaslandırır :). Ancaq ümid edirəm ki, məqalə hər hansı bir şəbəkə mühəndisi üçün də faydalı ola bilər.

İlk strateji məqsədiniz entropiyaya qarşı durmağı öyrənmək və göstərilən xidmət səviyyəsini saxlamaqdır.

Aşağıda təsvir olunan problemlərin bir çoxu müxtəlif vasitələrlə həll edilə bilər. Mən qəsdən texniki icra mövzusunu qaldırmıram, çünki... prinsipcə, çox vaxt bu və ya digər problemi necə həll etdiyiniz o qədər də vacib deyil, amma vacib olan ondan necə istifadə etdiyiniz və ümumiyyətlə istifadə edib-etmədiyinizdir. Məsələn, ona baxmasanız və xəbərdarlıqlara cavab verməsəniz, peşəkar şəkildə qurulmuş monitorinq sisteminizin faydası azdır.

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

Əvvəlcə ən böyük risklərin harada olduğunu başa düşməlisiniz.

Yenə də fərqli ola bilər. Etiraf edirəm ki, haradasa, məsələn, bunlar təhlükəsizlik məsələləri, haradasa xidmətin davamlılığı ilə bağlı məsələlər, haradasa, bəlkə də, başqa bir şey olacaq. Niyə də yox?

Tutaq ki, aydın olmaq üçün bu, hələ də xidmətin davamlılığıdır (bu, işlədiyim bütün şirkətlərdə belə idi).

Sonra avadanlıqdan başlamaq lazımdır. Diqqət etməli olduğunuz mövzuların siyahısı:

  • avadanlığın kritiklik dərəcəsinə görə təsnifatı
  • kritik avadanlıqların ehtiyat nüsxəsi
  • dəstək, lisenziyalar

Mümkün uğursuzluq ssenariləri üzərində düşünməlisiniz, xüsusən də kritiklik təsnifatınızın yuxarı hissəsində olan avadanlıqla. Adətən, ikiqat problemlərin yaranma ehtimalı diqqətdən kənarda qalır, əks halda həlliniz və dəstəyiniz əsassız olaraq baha başa gələ bilər, lakin uğursuzluğu biznesə əhəmiyyətli dərəcədə təsir göstərə bilən həqiqətən kritik şəbəkə elementləri halında, bu barədə düşünməlisiniz.

Misal

Tutaq ki, məlumat mərkəzində kök keçiddən danışırıq.

Xidmətin davamlılığının ən vacib meyar olduğuna razılaşdığımız üçün bu avadanlığın “isti” ehtiyat nüsxəsini (ehtiyatsızlığını) təmin etmək məqsədəuyğundur. Ancaq bu hamısı deyil. Siz həmçinin qərar verməlisiniz, əgər birinci açar qırılarsa, sizin üçün yalnız bir qalan açarla yaşamaq məqbuldur, çünki onun da qırılma riski var.

Vacibdir! Bu məsələni özünüz həll etməli deyilsiniz. Siz rəhbərlik və ya şirkət rəhbərliyi üçün riskləri, mümkün həll yollarını və xərcləri təsvir etməlisiniz. Onlar qərar qəbul etməlidirlər.

Beləliklə, ikiqat uğursuzluğun kiçik ehtimalını nəzərə alaraq, bir keçiddə 4 saat işləməyin, prinsipcə, məqbul olduğu qərara alınsa, sadəcə müvafiq dəstəyi götürə bilərsiniz (buna görə avadanlıq 4 saat ərzində dəyişdiriləcəkdir) saat).

Ancaq çatdırmamaq riski var. Təəssüf ki, biz bir dəfə belə vəziyyətə düşdük. Dörd saat əvəzinə avadanlıq bir həftə səyahət etdi!!!

Buna görə də, bu riski də müzakirə etmək lazımdır və bəlkə də, başqa bir açar (üçüncü) almaq və onu ehtiyat hissələri paketində (“soyuq” ehtiyat) saxlamaq və ya laboratoriya məqsədləri üçün istifadə etmək daha düzgün olar.

Vacibdir! Son istifadə tarixləri ilə sahib olduğunuz bütün dəstəyin elektron cədvəlini hazırlayın və onu təqviminizə əlavə edin ki, dəstəyinizi yeniləmək barədə narahat olmağa başlamağınız üçün ən azı bir ay əvvəl e-poçt alacaqsınız.

Dəstəyinizi yeniləməyi unutsanız və onun aparatınızın fasilələri bitdikdən bir gün sonra bağışlanmayacaqsınız.

Təcili iş

Şəbəkənizdə nə olursa olsun, ideal olaraq şəbəkə avadanlığınıza girişi təmin etməlisiniz.

Vacibdir! Bütün avadanlıqlara konsol girişiniz olmalıdır və bu giriş istifadəçi məlumat şəbəkəsinin sağlamlığından asılı olmamalıdır.

Siz həmçinin mümkün mənfi ssenariləri əvvəlcədən görməli və lazımi tədbirləri sənədləşdirməlisiniz. Bu sənədin mövcudluğu da çox vacibdir, ona görə də o, nəinki şöbə üçün paylaşılan resursda yerləşdirilməlidir, həm də mühəndislərin kompüterlərində yerli olaraq saxlanılmalıdır.

Olmalıdır

  • satıcı və ya inteqrator dəstəyi ilə bilet açmaq üçün tələb olunan məlumat
  • hər hansı bir avadanlığa necə çatmaq barədə məlumat (konsol, idarəetmə)

Əlbəttə ki, o, həmçinin hər hansı digər faydalı məlumatları ehtiva edə bilər, məsələn, müxtəlif avadanlıqların təkmilləşdirilməsi prosedurunun təsviri və faydalı diaqnostika əmrləri.

Tərəfdaşlar

İndi tərəfdaşlarla bağlı riskləri qiymətləndirmək lazımdır. Adətən bu

  • İnternet provayderləri və trafik mübadiləsi nöqtələri (IX)
  • rabitə kanalı təminatçıları

Özünüzə hansı sualları verməlisiniz? Avadanlıqda olduğu kimi, müxtəlif fövqəladə vəziyyət ssenariləri də nəzərə alınmalıdır. Məsələn, İnternet provayderləri üçün bu, belə bir şey ola bilər:

  • İnternet provayderi X nədənsə sizə xidmət göstərməyi dayandırsa nə olar?
  • Digər provayderlərin sizin üçün kifayət qədər ötürmə qabiliyyəti olacaqmı?
  • Bağlantı nə qədər yaxşı qalacaq?
  • İnternet provayderləriniz nə dərəcədə müstəqildir və onlardan birinin ciddi şəkildə kəsilməsi digərlərində problem yarada bilərmi?
  • məlumat mərkəzinizə nə qədər optik giriş var?
  • girişlərdən biri tamamilə məhv olarsa nə olacaq?

Girişlərə gəldikdə, iki fərqli şirkətdə, iki fərqli məlumat mərkəzindəki təcrübəmdə bir ekskavator quyuları məhv etdi və yalnız möcüzə ilə optikamıza təsir etmədi. Bu o qədər də nadir hal deyil.

Və təbii ki, siz təkcə bu sualları verməklə kifayətlənməli, yenə də rəhbərliyin dəstəyi ilə istənilən vəziyyətdə məqbul həll yolu təqdim etməlisiniz.

Yedəkləmə

Növbəti prioritet avadanlıq konfiqurasiyalarının ehtiyat nüsxəsi ola bilər. Hər halda, bu çox vacib məqamdır. Konfiqurasiyanı itirə biləcəyiniz halları sadalamayacağam, müntəzəm ehtiyat nüsxələri etmək və bu barədə düşünməmək daha yaxşıdır. Bundan əlavə, müntəzəm ehtiyat nüsxələri dəyişiklikləri izləmək üçün çox faydalı ola bilər.

Vacibdir! Gündəlik ehtiyat nüsxələrini çıxarın. Bu, qənaət etmək üçün o qədər də böyük məlumat deyil. Səhər növbətçi mühəndis (və ya siz) sistemdən ehtiyat nüsxəsinin uğurlu olub-olmadığını açıq şəkildə göstərən hesabat almalıdır və əgər ehtiyat nüsxəsi uğursuz olarsa, problem həll edilməli və ya bilet yaradılmalıdır ( şəbəkə şöbəsi proseslərinə baxın).

Proqram təminatı versiyaları

Avadanlığın proqram təminatını təkmilləşdirməyə dəyər olub-olmaması məsələsi o qədər də aydın deyil. Bir tərəfdən, köhnə versiyalar məlum səhvlər və zəifliklərdir, lakin digər tərəfdən, yeni proqram təminatı, birincisi, həmişə ağrısız bir yeniləmə proseduru deyil, ikincisi, yeni səhvlər və zəifliklərdir.

Burada ən yaxşı variantı tapmaq lazımdır. Bir neçə açıq tövsiyə

  • yalnız stabil versiyaları quraşdırın
  • Yenə də proqram təminatının çox köhnə versiyalarında yaşamamalısınız
  • bəzi proqram təminatının yerləşdiyi yer haqqında məlumat olan işarə yaradın
  • proqram versiyalarında zəifliklər və səhvlər haqqında hesabatları vaxtaşırı oxuyun və kritik problemlər olduqda, yeniləmə haqqında düşünməlisiniz.

Bu mərhələdə, avadanlıqlara konsol girişi, dəstək haqqında məlumat və təkmilləşdirmə prosedurunun təsviri ilə siz, prinsipcə, bu addıma hazırsınız. İdeal seçim, bütün proseduru yoxlaya biləcəyiniz laboratoriya avadanlıqlarınız olduqda, lakin təəssüf ki, bu, tez-tez baş vermir.

Kritik avadanlıq halında, təkmilləşdirmədə sizə kömək etmək üçün satıcının dəstəyi ilə əlaqə saxlaya bilərsiniz.

Bilet sistemi

İndi ətrafa baxa bilərsiniz. Siz digər şöbələrlə və şöbə daxilində qarşılıqlı əlaqə üçün proseslər yaratmalısınız.

Bu, lazım olmaya bilər (məsələn, şirkətiniz kiçikdirsə), amma işi elə təşkil etməyi məsləhət görərdim ki, bütün xarici və daxili tapşırıqlar bilet sistemindən keçsin.

Bilet sistemi mahiyyət etibarı ilə daxili və xarici kommunikasiyalar üçün interfeysinizdir və siz bu interfeysi kifayət qədər ətraflı təsvir etməlisiniz.

Girişin açılmasının vacib və ümumi vəzifəsini nümunə götürək. Mən şirkətlərdən birində mükəmməl işləyən bir alqoritmi təsvir edəcəyəm.

Misal

Gəlin ondan başlayaq ki, tez-tez daxil olan müştərilər öz istəklərini şəbəkə mühəndisi üçün anlaşılmaz bir dildə, yəni tətbiqin dilində, məsələn, “mənə 1C-yə giriş imkanı versinlər” ifadə edir.

Buna görə də biz heç vaxt bu cür istifadəçilərin sorğularını birbaşa qəbul etməmişik.
Və bu, birinci tələb idi

  • giriş sorğuları texniki şöbələrdən gəlməlidir (bizim halda bunlar unix, windows, yardım masası mühəndisləri idi)

İkinci tələb də budur

  • bu giriş daxil edilməlidir (bu sorğunu qəbul etdiyimiz texniki şöbə tərəfindən) və sorğu olaraq biz bu girişə keçid alırıq

Bu sorğunun forması bizim üçün başa düşülən olmalıdır, yəni.

  • sorğuda hansı alt şəbəkəyə və hansı alt şəbəkəyə girişin açıq olması, həmçinin protokol və (tcp/udp vəziyyətində) portlar haqqında məlumat olmalıdır.

Orada da göstərilməlidir

  • bu girişin niyə açıldığının təsviri
  • müvəqqəti və ya daimi (müvəqqətidirsə, hansı tarixə qədər)

Və çox vacib bir məqam təsdiqlərdir

  • girişə təşəbbüs göstərən şöbə müdirindən (məsələn, mühasibatlıq)
  • texniki şöbənin rəhbərindən, bu sorğunun şəbəkə şöbəsinə gəldiyi yerdən (məsələn, yardım masası)

Bu halda, bu girişin "sahibi" girişi başlatmış şöbənin rəhbəri hesab olunur (bizim nümunəmizdə mühasibatlıq) və o, bu şöbə üçün girişi olan səhifənin yenilənməsini təmin etmək üçün məsuliyyət daşıyır. .

Giriş

Bu, içində boğula biləcəyiniz bir şeydir. Ancaq proaktiv bir yanaşma tətbiq etmək istəyirsinizsə, bu məlumat daşqını ilə necə məşğul olmağı öyrənməlisiniz.

Budur bəzi praktik tövsiyələr:

  • gündəlikləri nəzərdən keçirməlisiniz
  • planlaşdırılmış baxış (və fövqəladə vəziyyət deyil) halda, özünüzü 0, 1, 2 ciddilik səviyyələri ilə məhdudlaşdıra və zəruri hesab edirsinizsə, digər səviyyələrdən seçilmiş nümunələri əlavə edə bilərsiniz.
  • logları təhlil edən və naxışlarını yox sayma siyahısına əlavə etdiyiniz qeydləri nəzərə almayan skript yazın

Bu yanaşma sizə zaman keçdikcə sizin üçün maraqlı olmayan qeydlərin laqeyd bir siyahısını yaratmağa və yalnız həqiqətən vacib hesab etdiyinizləri tərk etməyə imkan verəcəkdir.
Bu, bizim üçün çox işlədi.

Monitorinq

Bir şirkətdə monitorinq sisteminin olmaması qeyri-adi deyil. Siz, məsələn, jurnallara etibar edə bilərsiniz, lakin avadanlıq heç nəyi “deməyə” vaxt tapmadan sadəcə “ölə” bilər və ya udp syslog protokol paketi itə bilər və gəlmir. Ümumiyyətlə, təbii ki, aktiv monitorinq vacib və zəruridir.

Təcrübəmdə ən məşhur iki nümunə:

  • rabitə kanallarının, kritik bağlantıların yükünün monitorinqi (məsələn, provayderlərə qoşulma). Onlar sizə trafikin itirilməsi səbəbindən xidmətin potensial deqradasiyası problemini fəal şəkildə görməyə və müvafiq olaraq ondan qaçmağa imkan verir.
  • NetFlow əsasında qrafiklər. Onlar trafikdə anomaliyaları tapmağı asanlaşdırır və bəzi sadə, lakin əhəmiyyətli haker hücumlarını aşkar etmək üçün çox faydalıdır.

Vacibdir! Ən kritik hadisələr üçün SMS bildirişləri qurun. Bu həm monitorinqə, həm də qeydlərə aiddir. Növbətçi növbəniz yoxdursa, iş vaxtından kənarda da sms gəlməlidir.

Prosesi elə düşünün ki, bütün mühəndisləri oyatmasın. Bunun üçün bir mühəndisimiz var idi.

Nəzarəti dəyişdirin

Məncə, bütün dəyişikliklərə nəzarət etmək lazım deyil. Ancaq hər halda, lazım gələrsə, şəbəkədə kimin və niyə müəyyən dəyişikliklər etdiyini asanlıqla tapa bilməlisiniz.

Bir neçə ipucu:

  • həmin biletdə nə edildiyini təfərrüatlandırmaq üçün bilet sistemindən istifadə edin, məsələn, tətbiq edilən konfiqurasiyanı biletə köçürməklə
  • şəbəkə avadanlıqlarında şərh imkanlarından istifadə etmək (məsələn, Juniper-də şərh vermək). Biletin nomresini yaza bilersiz
  • konfiqurasiya ehtiyat nüsxələrinizdən fərqli istifadə edin

Dəyişikliklər üçün hər gün bütün biletləri nəzərdən keçirərək, bunu bir proses kimi həyata keçirə bilərsiniz.

Proseslər

Komandanızdakı prosesləri rəsmiləşdirməli və təsvir etməlisiniz. Əgər bu nöqtəyə çatmısınızsa, komandanız artıq ən azı aşağıdakı prosesləri işləməlidir:

Gündəlik proseslər:

  • biletlərlə işləmək
  • loglarla işləmək
  • nəzarəti dəyişdirin
  • gündəlik yoxlama vərəqi

İllik proseslər:

  • zəmanətlərin, lisenziyaların uzadılması

Asinxron proseslər:

  • müxtəlif fövqəladə hallara reaksiya

Birinci hissənin yekunu

Diqqət etdinizmi ki, bütün bunlar hələ şəbəkə konfiqurasiyası haqqında deyil, dizayn haqqında deyil, şəbəkə protokolları haqqında deyil, marşrutlaşdırma haqqında deyil, təhlükəsizlik haqqında deyil ... Bu, ətrafda bir şeydir. Ancaq bunlar, bəlkə də darıxdırıcı olsa da, əlbəttə ki, şəbəkə bölməsinin işinin çox vacib elementləridir.

İndiyə qədər, gördüyünüz kimi, şəbəkənizdə heç nə təkmilləşdirməmisiniz. Təhlükəsizlik zəiflikləri varsa, onlar qaldılar, pis dizayn varsa, o, qaldı. Çox güman ki, çox vaxt, səy və bəzən pul xərclədiyiniz bir şəbəkə mühəndisi kimi bacarıq və biliklərinizi tətbiq etməyinizə qədər. Ancaq əvvəlcə təməl yaratmaq (və ya gücləndirmək), sonra isə tikintiyə başlamaq lazımdır.

Aşağıdakı hissələr sizə səhvləri necə tapmaq və aradan qaldırmaq, sonra isə infrastrukturunuzu təkmilləşdirməyi izah edəcək.

Əlbəttə ki, hər şeyi ardıcıllıqla etmək lazım deyil. Zaman kritik ola bilər. Resurs imkan verirsə, paralel olaraq edin.

Və vacib bir əlavə. Komandanızla ünsiyyət qurun, soruşun, məsləhətləşin. Sonda bütün bunları dəstəkləyən və edən də onlardır.

Mənbə: www.habr.com

Добавить комментарий