Ĉi tiu artikolo estas la unua el serio de artikoloj "Kiel Preni Kontrolon de Via Reta Infrastrukturo." La enhavo de ĉiuj artikoloj en la serio kaj ligiloj troveblas .
Mi plene konfesas, ke ekzistas sufiĉa nombro da kompanioj, kie reto malfunkcio de unu horo aŭ eĉ unu tago ne estas kritika. Bedaŭrinde aŭ feliĉe, mi ne havis la ŝancon labori en tiaj lokoj. Sed, kompreneble, la retoj estas malsamaj, la postuloj estas malsamaj, la aliroj estas malsamaj, kaj tamen, en unu formo aŭ alia, la suba listo en multaj kazoj efektive estos "nepra".
Do, la komencaj kondiĉoj.
Vi estas en nova laboro, vi ricevis promocion, aŭ vi decidis denove rigardi viajn respondecojn. La kompania reto estas via areo de respondeco. Por vi, ĉi tio estas multrilate defio kaj nova, kiu iom pravigas la mentoran tonon de ĉi tiu artikolo :). Sed mi esperas, ke la artikolo ankaŭ povas esti utila al iu ajn ret-inĝeniero.
Via unua strategia celo estas lerni rezisti entropion kaj konservi la nivelon de servo provizita.
Multaj el la malsupre priskribitaj problemoj povas esti solvitaj per diversaj rimedoj. Mi intence ne levas la temon de teknika efektivigo, ĉar... principe, ofte ne tiom gravas kiel vi solvis tian aŭ alian problemon, sed gravas kiel vi uzas ĝin kaj ĉu vi entute uzas ĝin. Ekzemple, via profesie konstruita monitora sistemo estas malmulte utila se vi ne rigardas ĝin kaj ne respondas al atentigoj.
Ekipaĵo
Unue vi devas kompreni, kie estas la plej grandaj riskoj.
Denove, ĝi povas esti malsama. Mi konfesas, ke ie, ekzemple, ĉi tiuj estos sekurecproblemoj, kaj ie, aferoj rilataj al la kontinueco de la servo, kaj ie, eble, io alia. Kial ne?
Ni supozu, por esti klare, ke ĉi tio ankoraŭ estas kontinueco de servo (tio estis la kazo en ĉiuj kompanioj, kie mi laboris).
Tiam vi devas komenci kun la ekipaĵo. Jen listo de temoj por atenti:
- klasifiko de ekipaĵo laŭ grado de kritikeco
- sekurkopio de kritika ekipaĵo
- subteno, licencoj
Vi devas pensi tra eblaj fiaskaj scenaroj, precipe kun ekipaĵo ĉe la supro de via kritikeca klasifiko. Kutime, la ebleco de duoblaj problemoj estas neglektita, alie via solvo kaj subteno povas fariĝi neracie multekostaj, sed en la kazo de vere kritikaj retaj elementoj, kies malsukceso povus grave influi la komercon, vi devus pensi pri tio.
Ekzemplo:
Ni diru, ke ni parolas pri radika ŝaltilo en datumcentro.
Ĉar ni konsentis, ke serva kontinueco estas la plej grava kriterio, estas racie provizi "varman" sekurkopion (redundo) de ĉi tiu ekipaĵo. Sed tio ne estas ĉio. Vi ankaŭ devas decidi kiom longe, se la unua ŝaltilo rompiĝas, ĉu estas akcepteble por vi vivi kun nur unu restanta ŝaltilo, ĉar estas risko, ke ĝi ankaŭ rompiĝu.
Grave! Vi ne devas mem decidi ĉi tiun aferon. Vi devas priskribi la riskojn, eblajn solvojn kaj kostojn al administrado aŭ kompania administrado. Ili devas fari decidojn.
Do, se estis decidite, ke, konsiderante la malgrandan probablecon de duobla fiasko, labori dum 4 horoj sur unu ŝaltilo estas principe akceptebla, tiam vi povas simple preni la taŭgan subtenon (laŭ kiu la ekipaĵo estos anstataŭigita ene de 4). horoj).
Sed estas risko, ke ili ne liveros. Bedaŭrinde, ni iam trovis nin en tia situacio. Anstataŭ kvar horoj, la ekipaĵo vojaĝis dum semajno!!!
Tial, ĉi tiu risko ankaŭ devas esti diskutita kaj, eble, estus pli ĝuste por vi aĉeti alian ŝaltilon (trian) kaj konservi ĝin en rezervaj pakaĵo ("malvarma" sekurkopio) aŭ uzi ĝin por laboratoriaj celoj.
Grave! Faru kalkultabelon de la tuta subteno, kiun vi havas kun limdatoj, kaj aldonu ĝin al via kalendaro, por ke vi ricevu retpoŝton almenaŭ unu monaton antaŭe, ke vi komencu zorgi pri renovigo de via subteno.
Vi ne estos pardonita se vi forgesos renovigi vian subtenon kaj la tagon post kiam ĝi finiĝos via aparataro paŭzoj.
Urĝa laboro
Kio ajn okazas en via reto, ideale vi devus konservi aliron al via reto-ekipaĵo.
Grave! Vi devas havi konzolan aliron al ĉiuj ekipaĵoj kaj ĉi tiu aliro ne devus dependi de la sano de la uzantdatumreto.
Vi ankaŭ devus antaŭvidi eblajn negativajn scenarojn anticipe kaj dokumenti la necesajn agojn. La havebleco de ĉi tiu dokumento ankaŭ estas kritika, do ĝi devus ne nur esti afiŝita sur komuna rimedo por la fako, sed ankaŭ konservita loke sur la komputiloj de la inĝenieroj.
Devas esti
- informoj necesaj por malfermi bileton kun subteno de vendisto aŭ integristo
- informoj pri kiel atingi ajnan ekipaĵon (konzolo, administrado)
Kompreneble, ĝi ankaŭ povas enhavi ajnan alian utilan informon, ekzemple, priskribo de la ĝisdatiga proceduro por diversaj ekipaĵoj kaj utilaj diagnozaj komandoj.
Niaj Partneroj
Nun vi devas taksi la riskojn asociitajn kun partneroj. Kutime ĉi tio
- Interretaj provizantoj kaj trafikaj interŝanĝopunktoj (IX)
- provizantoj de komunika kanalo
Kiajn demandojn vi faru al vi mem? Kiel kun ekipaĵo, malsamaj krizoscenaroj devas esti pripensitaj. Ekzemple, por interretaj provizantoj, ĝi povus esti io kiel:
- kio okazas se interreta provizanto X ĉesas provizi al vi servon ial?
- Ĉu aliaj provizantoj havos sufiĉan larĝan bandon por vi?
- Kiom bona restos la konektebleco?
- Kiom sendependaj estas viaj interretaj provizantoj kaj ĉu serioza malfunkcio de unu el ili kaŭzos problemojn kun la aliaj?
- kiom da optikaj enigaĵoj en via datumcentro?
- kio okazos se unu el la enigaĵoj estas tute detruita?
Pri enigaĵoj, en mia praktiko en du malsamaj kompanioj, en du malsamaj datumcentroj, elkavatoro detruis putojn kaj nur mirakle nia optiko ne estis tuŝita. Ĉi tio ne estas tia malofta kazo.
Kaj, kompreneble, vi devas ne nur demandi ĉi tiujn demandojn, sed, denove, kun la subteno de administrado, provizi akcepteblan solvon en ajna situacio.
Rezervo
La sekva prioritato povas esti sekurkopio de ekipaĵagordoj. Ĉiukaze, ĉi tio estas tre grava punkto. Mi ne listigos tiujn kazojn, kiam vi povas perdi la agordon; estas pli bone fari regulajn sekurkopiojn kaj ne pensi pri tio. Krome, regulaj sekurkopioj povas esti tre utilaj en monitorado de ŝanĝoj.
Grave! Faru sekurkopiojn ĉiutage. Ĉi tio ne estas tiom granda kvanto da datumoj por ŝpari pri tio. Matene, la deĵoranta inĝeniero (aŭ vi) devus ricevi raporton de la sistemo, kiu klare indikas ĉu la sekurkopio estis sukcesa aŭ ne, kaj se la sekurkopio estis malsukcesa, la problemo devus esti solvita aŭ bileto devus esti kreita ( vidu procezojn pri retsekcio).
Versioj de programaro
La demando ĉu aŭ ne indas ĝisdatigi la programaron de la ekipaĵo ne estas tiel klara. Unuflanke, malnovaj versioj estas konataj cimoj kaj vundeblecoj, sed aliflanke, nova programaro estas, unue, ne ĉiam sendolora ĝisdatiga proceduro, kaj due, novaj eraroj kaj vundeblecoj.
Ĉi tie vi devas trovi la plej bonan eblon. Kelkaj evidentaj rekomendoj
- instali nur stabilajn versiojn
- Tamen, vi ne devus vivi per tre malnovaj versioj de programaro
- faru signon kun informoj pri kie troviĝas iu programaro
- periode legu raportojn pri vundeblecoj kaj cimoj en programaraj versioj, kaj en kazo de kritikaj problemoj, vi devus pensi pri ĝisdatigo.
En ĉi tiu etapo, havante konzolan aliron al la ekipaĵo, informojn pri subteno kaj priskribo de la ĝisdatiga proceduro, vi principe estas preta por ĉi tiu paŝo. La ideala elekto estas kiam vi havas laboratoriajn ekipaĵojn, kie vi povas kontroli la tutan proceduron, sed, bedaŭrinde, ĉi tio ne okazas ofte.
En la kazo de kritika ekipaĵo, vi povas kontakti la subtenon de la vendisto kun peto helpi vin kun la ĝisdatigo.
Sistemo de biletoj
Nun vi povas ĉirkaŭrigardi. Vi devas establi procezojn por interagado kun aliaj fakoj kaj ene de la fako.
Tio eble ne estas necesa (ekzemple, se via kompanio estas malgranda), sed mi tre rekomendus organizi laboron tiel, ke ĉiuj eksteraj kaj internaj taskoj trairu la biletsistemon.
La biletsistemo estas esence via interfaco por internaj kaj eksteraj komunikadoj, kaj vi devus priskribi ĉi tiun interfacon sufiĉe detale.
Ni prenu ekzemplon de grava kaj komuna tasko malfermi aliron. Mi priskribos algoritmon, kiu funkciis perfekte en unu el la kompanioj.
Ekzemplo:
Ni komencu per la fakto, ke ofte alirklientoj formulas siajn dezirojn en lingvo nekomprenebla por retinĝeniero, nome, en la lingvo de la aplikaĵo, ekzemple, "donu al mi aliron al 1C."
Tial ni neniam akceptis petojn rekte de tiaj uzantoj.
Kaj tio estis la unua postulo
- petoj por aliro devus veni de teknikaj fakoj (en nia kazo ĉi tiuj estis uniksoj, fenestroj, helpdesk-inĝenieroj)
La dua postulo estas tio
- ĉi tiu aliro devas esti registrita (de la teknika fako de kiu ni ricevis ĉi tiun peton) kaj kiel peto ni ricevas ligilon al ĉi tiu registrita aliro
La formo de tiu ĉi peto devas esti komprenebla por ni, t.e.
- la peto devas enhavi informojn pri kiu subreto kaj al kiu subreta aliro estu malfermita, same kiel la protokolo kaj (kaze de tcp/udp) havenoj
Ĝi ankaŭ estu indikita tie
- priskribo de kial ĉi tiu aliro estas malfermita
- provizora aŭ konstanta (se provizore, ĝis kiu dato)
Kaj tre grava punkto estas aproboj
- de la estro de la fako kiu iniciatis aliron (ekzemple kontado)
- de la estro de la teknika fako, de kie ĉi tiu peto venis al la reto-fako (ekzemple helpservo)
En ĉi tiu kazo, la "posedanto" de ĉi tiu aliro estas konsiderata kiel la estro de la fako kiu iniciatis la aliron (kontadon en nia ekzemplo), kaj li respondecas pri certigi, ke la paĝo kun ensalutinta aliro por ĉi tiu fako restas ĝisdatigita. .
Enhavo
Ĉi tio estas io en kio vi povas droni. Sed se vi volas efektivigi iniciateman aliron, tiam vi devas lerni kiel trakti ĉi tiun datuman diluvon.
Jen kelkaj praktikaj rekomendoj:
- vi devas revizii la protokolojn ĉiutage
- en la kazo de planita revizio (kaj ne kriz-situacio), vi povas limigi vin al severecaj niveloj 0, 1, 2 kaj aldoni elektitajn ŝablonojn el aliaj niveloj, se vi konsideras ĝin necesa.
- skribu skripton, kiu analizas protokolojn kaj ignoras tiujn protokolojn, kies ŝablonojn vi aldonis al la ignora listo
Ĉi tiu aliro permesos al vi, kun la tempo, krei ignoran liston de protokoloj, kiuj ne estas interesaj por vi, kaj lasi nur tiujn, kiujn vi vere konsideras gravaj.
Ĝi bonege funkciis por ni.
Monitorado
Ne estas malofte por kompanio malhavi monitoran sistemon. Vi povas, ekzemple, fidi je protokoloj, sed la ekipaĵo povas simple "morti" sen havi tempon "diri" ion ajn, aŭ la udp syslog-protokola pako povas esti perdita kaj ne alveni. Ĝenerale, kompreneble, aktiva monitorado estas grava kaj necesa.
La du plej popularaj ekzemploj en mia praktiko:
- monitorante la ŝarĝon de komunikadokanaloj, kritikaj ligiloj (ekzemple, konekti al provizantoj). Ili permesas al vi proaktive vidi la eblan problemon de servo-degenero pro perdo de trafiko kaj, sekve, eviti ĝin.
- grafikaĵoj bazitaj sur NetFlow. Ili faciligas trovi anomaliojn en trafiko kaj estas tre utilaj por detekti iujn simplajn sed signifajn specojn de hacker-atakoj.
Grave! Agordu SMSajn sciigojn por la plej kritikaj eventoj. Ĉi tio validas kaj por monitorado kaj protokolado. Se vi ne havas deĵoran deĵoron, tiam sms ankaŭ devus alveni ekster laborhoroj.
Pripensu la procezon tiel, ke ne veku ĉiujn inĝenierojn. Ni havis deĵoran inĝenieron por tio.
Ŝanĝi kontrolon
Laŭ mi, ne necesas kontroli ĉiujn ŝanĝojn. Sed, ĉiukaze, vi devus povi, se necese, facile trovi kiu faris iujn ŝanĝojn en la reto kaj kial.
Kelkaj konsiloj:
- uzu biletsistemon por detaligi tion, kio estis farita sur tiu bileto, ekzemple kopiante la aplikatan agordon en la bileton
- uzu komentkapablojn sur retaj ekipaĵoj (ekzemple, fari komenton pri Juniper). Vi povas noti la biletan numeron
- uzu diferencon de viaj agordaj sekurkopioj
Vi povas efektivigi ĉi tion kiel procezon, reviziante ĉiujn biletojn ĉiutage por ŝanĝoj.
Procezoj
Vi devas formaligi kaj priskribi la procezojn en via teamo. Se vi atingis ĉi tiun punkton, tiam via teamo jam devus funkcii almenaŭ la sekvajn procezojn:
Ĉiutagaj procezoj:
- laborante kun biletoj
- laborante kun ŝtipoj
- ŝanĝi kontrolon
- ĉiutaga ĉekfolio
Ĉiujaraj procezoj:
- etendo de garantioj, licencoj
Nesinkronaj procezoj:
- respondo al diversaj krizaj situacioj
Konkludo de la unua parto
Ĉu vi rimarkis, ke ĉio ĉi ankoraŭ ne temas pri reta agordo, ne pri dezajno, ne pri retaj protokoloj, ne pri enrutado, ne pri sekureco... Ĝi estas io ĉirkaŭe. Sed ĉi tiuj, kvankam eble enuigaj, estas kompreneble tre gravaj elementoj de la laboro de retdivido.
Ĝis nun, kiel vi povas vidi, vi nenion plibonigis en via reto. Se estis sekurecaj vundeblecoj, tiam ili restis; se estis malbona dezajno, tiam ĝi restis. Ĝis vi aplikis viajn kapablojn kaj sciojn kiel retan inĝenieron, sur kiuj vi plej verŝajne elspezis grandan kvanton da tempo, peno kaj foje mono. Sed unue vi devas krei (aŭ plifortigi) la fundamenton, kaj poste komenci konstrui.
La sekvaj partoj diros al vi kiel trovi kaj forigi erarojn, kaj poste plibonigi vian infrastrukturon.
Kompreneble, vi ne devas fari ĉion sinsekve. Tempo povas esti kritika. Faru ĝin paralele se rimedoj permesas.
Kaj grava aldono. Komuniku, demandu, konsultu kun via teamo. En la fino, ili estas tiuj kiuj subtenas kaj faras ĉion ĉi.
fonto: www.habr.com