Dit artikel is it earste yn in searje artikels "Hoe kinne jo kontrôle nimme oer jo netwurkynfrastruktuer." De ynhâld fan alle artikels yn 'e searje en keppelings is te finen .
Ik jou folslein ta dat d'r in foldwaande oantal bedriuwen binne wêr't in netwurkûnderbrekking fan ien oere of sels ien dei net kritysk is. Spitigernôch of gelokkich hie ik net de kâns om op sokke plakken te wurkjen. Mar, fansels, de netwurken binne oars, de easken binne oars, de oanpak binne oars, en dochs, yn ien of oare foarm, de list hjirûnder yn in protte gefallen eins in "must-do".
Dus, de earste betingsten.
Jo binne yn in nije baan, jo hawwe in promoasje krigen, of jo hawwe besletten in nije blik op jo ferantwurdlikheden te nimmen. It bedriuwsnetwurk is jo ferantwurdlikensgebiet. Foar jo is dit op in protte manieren in útdaging en nij, wat de mentoringtoan fan dit artikel wat rjochtfeardiget :). Mar ik hoopje dat it artikel ek nuttich kin wêze foar elke netwurkyngenieur.
Jo earste strategyske doel is om te learen om entropy te wjerstean en it nivo fan levere tsjinst te behâlden.
In protte fan 'e problemen beskreaun hjirûnder kinne wurde oplost troch ferskate middels. Ik bring it ûnderwerp fan technyske ymplemintaasje bewust net oan, om't ... yn prinsipe is it faak net sa wichtich hoe't jo dit of dat probleem oplost hawwe, mar wat wichtich is is hoe't jo it brûke en oft jo it hielendal brûke. Bygelyks, jo profesjoneel boud tafersjochsysteem is fan lyts nut as jo der net nei sjogge en net reagearje op warskôgings.
Wetter - Agrarwetter
Earst moatte jo begripe wêr't de grutste risiko's binne.
Nochris, it kin oars. Ik jou ta dat earne, bygelyks, dit sille wêze feiligens saken, en earne, saken yn ferbân mei de kontinuïteit fan de tsjinst, en earne, miskien, wat oars. Wêrom net?
Lit ús oannimme, om dúdlik te wêzen, dat dit noch altyd kontinuïteit fan tsjinst is (dit wie it gefal yn alle bedriuwen dêr't ik wurke).
Dan moatte jo begjinne mei de apparatuer. Hjir is in list mei ûnderwerpen om omtinken te jaan:
- klassifikaasje fan apparatuer troch mjitte fan kritikaliteit
- reservekopy fan krityske apparatuer
- stipe, lisinsjes
Jo moatte tinke troch mooglike faluta-senario's, foaral mei apparatuer oan 'e boppekant fan jo krityske klassifikaasje. Meastentiids wurdt de mooglikheid fan dûbele problemen ferwaarleazge, oars kinne jo oplossing en stipe ûnferstannich djoer wurde, mar yn it gefal fan wirklik krityske netwurkeleminten, wêrfan it mislearjen it bedriuw signifikant kin beynfloedzje, moatte jo der oer tinke.
Foarbyld:
Litte wy sizze dat wy it hawwe oer in root-skeakel yn in datasintrum.
Sûnt wy ôfpraat dat tsjinst kontinuïteit is de meast wichtige kritearium, it is ridlik te foarsjen "hot" reservekopy (oerstallich) fan dizze apparatuer. Mar dat is net alles. Jo moatte ek beslute hoe lang, as de earste switch brekt, is it akseptabel foar jo te libjen mei mar ien oerbleaune switch, want der is in risiko dat it sil brekke te.
Belangryk! Jo moatte dit probleem net sels beslute. Jo moatte de risiko's, mooglike oplossingen en kosten beskriuwe foar behear as bedriuwsbehear. Se moatte besluten nimme.
Dus, as it waard besletten dat, sjoen de lytse kâns op in dûbele mislearring, wurkje foar 4 oeren op ien switch yn prinsipe akseptabel is, dan kinne jo gewoan de passende stipe nimme (neffens wêrfan de apparatuer binnen 4 sil wurde ferfongen oeren).
Mar d'r is in risiko dat se net leverje. Spitigernôch hawwe wy ússels eartiids yn sa'n situaasje fûn. Yn stee fan fjouwer oeren reizge de apparatuer foar in wike!!!
Dêrom moat dit risiko ek besprutsen wurde en, miskien, sil it krekter wêze foar jo om in oare skeakel (tredde) te keapjen en it yn in reserve-ûnderdielenpakket te hâlden ("kâlde" reservekopy) of te brûken foar laboratoariumdoelen.
Belangryk! Meitsje in spreadsheet fan alle stipe dy't jo hawwe mei ferfaldatums en foegje it ta oan jo kalinder, sadat jo op syn minst in moanne fan tefoaren in e-post krije dat jo moatte begjinne te soargen oer it fernijen fan jo stipe.
Jo wurde net ferjûn as jo ferjitte jo stipe te fernijen en de dei nei't it einiget, brekt jo hardware.
Emergency wurk
Wat der ek bart op jo netwurk, ideaal moatte jo tagong hâlde ta jo netwurkapparatuer.
Belangryk! Jo moatte konsole tagong hawwe ta alle apparatuer en dizze tagong moat net ôfhinklik wêze fan 'e sûnens fan it brûkersgegevensnetwurk.
Jo moatte ek foarôf mooglike negative senario's foarsizze en de nedige aksjes dokumintearje. De beskikberens fan dit dokumint is ek kritysk, dus it moat net allinich pleatst wurde op in dielde boarne foar de ôfdieling, mar ek opslein lokaal op 'e kompjûters fan' e yngenieurs.
Der moat wêze
- ynformaasje dy't nedich is om in kaartsje te iepenjen mei stipe fan ferkeaper of yntegrator
- ynformaasje oer hoe't jo by elke apparatuer komme (konsole, behear)
Fansels kin it ek alle oare nuttige ynformaasje befetsje, bygelyks in beskriuwing fan 'e upgradeproseduere foar ferskate apparatuer en nuttige diagnostyske kommando's.
Us Partners
No moatte jo de risiko's beoardielje dy't ferbûn binne mei partners. Meastal dit
- Ynternetproviders en ferkearsútwikselpunten (IX)
- kommunikaasje kanaal providers
Hokker fragen moatte jo sels stelle? Krekt as by apparatuer moatte ferskate needscenario's wurde beskôge. Bygelyks, foar ynternetproviders kin it sa wêze as:
- wat bart der as ynternetprovider X ophâldt mei it leverjen fan jo tsjinst om ien of oare reden?
- Sille oare oanbieders genôch bânbreedte foar jo hawwe?
- Hoe goed sil de ferbining bliuwe?
- Hoe ûnôfhinklik binne jo ynternetproviders en sil in serieuze ûnderbrekking fan ien fan har problemen feroarsaakje mei de oaren?
- hoefolle optyske yngongen yn jo datasintrum?
- wat bart der as ien fan de yngongen wurdt folslein fernield?
Oangeande ynputs, yn myn praktyk yn twa ferskillende bedriuwen, yn twa ferskillende datasintra, ferneatige in graafmachine putten en allinich troch wûnder waard ús optyk net beynfloede. Dit is net sa'n seldsum gefal.
En, fansels, moatte jo net allinich dizze fragen stelle, mar, wer, mei de stipe fan management, om in akseptabele oplossing te leverjen yn elke situaasje.
Reservekopy
De folgjende prioriteit kin in reservekopy wêze fan apparatuerkonfiguraasjes. Dit is yn alle gefallen in tige wichtich punt. Ik sil dizze gefallen net listje as jo de konfiguraasje kinne ferlieze; it is better om regelmjittige backups te meitsjen en der net oer nei te tinken. Derneist kinne reguliere backups heul nuttich wêze by it kontrolearjen fan feroaringen.
Belangryk! Meitsje backups deistich. Dit is net sa'n grutte hoemannichte gegevens om hjirop te besparjen. Moarns moat de yngenieur fan tsjinst (of jo) in rapport krije fan it systeem, dat dúdlik oanjout oft de reservekopy suksesfol wie of net, en as de reservekopy net slagge, it probleem moat wurde oplost of in kaartsje moat wurde makke ( sjoch prosessen fan netwurkôfdieling).
Software ferzjes
De fraach oft it de muoite wurdich is om de software fan 'e apparatuer te ferbetterjen is net sa dúdlik. Oan 'e iene kant binne âlde ferzjes bekende bugs en kwetsberens, mar oan' e oare kant is nije software, yn it foarste plak, net altyd in pynleaze upgradeproseduere, en twad nije bugs en kwetsberens.
Hjir moatte jo de bêste opsje fine. In pear foar de hân lizzende oanbefellings
- ynstallearje allinnich stabile ferzjes
- Dochs moatte jo net libje op heul âlde ferzjes fan software
- meitsje in teken mei ynformaasje oer wêr't guon software leit
- periodyk lêze rapporten oer kwetsberens en bugs yn softwareferzjes, en yn gefal fan krityske problemen moatte jo tinke oer upgrade
Op dit stadium, mei tagong ta konsole ta de apparatuer, ynformaasje oer stipe en in beskriuwing fan 'e upgradeproseduere, binne jo yn prinsipe klear foar dizze stap. De ideale opsje is as jo laboratoariumapparatuer hawwe wêr't jo de heule proseduere kinne kontrolearje, mar, spitigernôch, bart dit net faak.
Yn it gefal fan krityske apparatuer kinne jo kontakt opnimme mei de stipe fan 'e ferkeaper mei in fersyk om jo te helpen mei de upgrade.
Ticket systeem
No kinne jo om jo hinne sjen. Jo moatte prosessen fêststelle foar ynteraksje mei oare ôfdielingen en binnen de ôfdieling.
Dit kin net nedich wêze (bygelyks as jo bedriuw lyts is), mar ik soe tige oanrikkemandearje om wurk op sa'n manier te organisearjen dat alle eksterne en ynterne taken troch it kaartsjesysteem geane.
It kaartsjesysteem is yn wêzen jo ynterface foar ynterne en eksterne kommunikaasje, en jo moatte dizze ynterface yn genôch detail beskriuwe.
Litte wy in foarbyld nimme fan in wichtige en mienskiplike taak fan it iepenjen fan tagong. Ik sil in algoritme beskriuwe dy't perfekt wurke yn ien fan 'e bedriuwen.
Foarbyld:
Lit ús begjinne mei it feit dat faak tagong klanten formulearje harren winsken yn in taal ûnbegryplik foar in netwurk yngenieur, nammentlik, yn 'e taal fan' e applikaasje, bygelyks, "jou my tagong ta 1C."
Dêrom hawwe wy nea oanfragen direkt fan sokke brûkers akseptearre.
En dat wie de earste eask
- oanfragen foar tagong moatte komme fan technyske ôfdielingen (yn ús gefal wiene dit unix, finsters, helpdesk-yngenieurs)
De twadde eask is dat
- dizze tagong moat oanmeld wurde (troch de technyske ôfdieling wêrfan wy dit fersyk krigen hawwe) en as fersyk krije wy in keppeling nei dizze oanmelde tagong
De foarm fan dit fersyk moat foar ús begryplik wêze, d.w.s.
- it fersyk moat ynformaasje befetsje oer hokker subnet en nei hokker subnet tagong moat iepen wêze, lykas it protokol en (yn it gefal fan tcp/udp) havens
Dêr moat ek oanjûn wurde
- beskriuwing fan wêrom't dizze tagong wurdt iepene
- tydlik of permanint (as tydlik, oant hokker datum)
En in heul wichtich punt is goedkarring
- fan it haad fan 'e ôfdieling dy't tagong hat inisjearre (bygelyks boekhâlding)
- fan it haad fan de technyske ôfdieling, wêrfan dit fersyk kaam nei de netwurkôfdieling (bygelyks helpdesk)
Yn dit gefal wurdt de "eigner" fan dizze tagong beskôge as it haad fan 'e ôfdieling dy't de tagong inisjearre (boekhâlding yn ús foarbyld), en hy is ferantwurdlik foar it garandearjen dat de side mei oanmelde tagong foar dizze ôfdieling aktueel bliuwt .
Logging
Dit is iets wêryn jo kinne ferdrinke. Mar as jo in proaktive oanpak wolle ymplementearje, dan moatte jo leare hoe't jo mei dizze gegevensfloed omgean moatte.
Hjir binne wat praktyske oanbefellings:
- jo moatte de logs deistich besjen
- yn it gefal fan in plande resinsje (en net in needsituaasje), kinne jo josels beheine ta earnstnivo's 0, 1, 2 en selekteare patroanen tafoegje fan oare nivo's as jo it nedich fine
- skriuw in skript dat logboeken parseart en dy logboeken negearret wêrfan jo patroanen hawwe tafoege oan de negearjelist
Dizze oanpak sil jo yn 'e rin fan' e tiid in negearje list meitsje mei logs dy't jo net ynteressearje en allinich dejingen litte dy't jo wirklik wichtich fine.
It wurke geweldich foar ús.
Monitoring
It is net ûngewoan dat in bedriuw in tafersjochsysteem mist. Jo kinne bygelyks fertrouwe op logs, mar de apparatuer kin gewoan "stjerre" sûnder tiid te hawwen om wat te "sizzen", of it udp syslog-protokolpakket kin ferlern gean en net oankomme. Yn it algemien is fansels aktyf tafersjoch wichtich en needsaaklik.
De twa meast populêre foarbylden yn myn praktyk:
- tafersjoch op de lading fan kommunikaasje kanalen, krityske keppelings (bygelyks, ferbining mei providers). Se tastean jo proaktyf te sjen it potinsjele probleem fan tsjinstdegradaasje fanwege ferlies fan ferkear en, dêrom, foarkomme.
- Grafiken basearre op NetFlow. Se meitsje it maklik om anomalies te finen yn ferkear en binne tige nuttich foar it opspoaren fan wat ienfâldige, mar wichtige soarten hacker-oanfallen.
Belangryk! Stel SMS-notifikaasjes yn foar de meast krityske eveneminten. Dat jildt foar sawol tafersjoch as logging. Hawwe jo gjin tsjinstferliening, dan moatte sms ek bûten wurktiid komme.
Tink troch it proses op sa'n manier dat jo net alle yngenieurs wekker meitsje. Dêr hiene wy in yngenieur foar yn tsjinst.
Feroarje kontrôle
Neffens my is it net nedich om alle feroaringen te kontrolearjen. Mar yn alle gefallen moatte jo, as it nedich is, maklik fine kinne wa't bepaalde wizigingen yn it netwurk makke en wêrom.
In pear tips:
- brûk in kaartsjesysteem om te detaillearjen wat op dat kaartsje dien is, bygelyks troch de tapaste konfiguraasje nei it kaartsje te kopiearjen
- brûke comment mooglikheden op netwurk apparatuer (Bygelyks, commit kommentaar op Juniper). Jo kinne opskriuwe it kaartsje nûmer
- brûk diff fan jo konfiguraasje-backups
Jo kinne dit as in proses ymplementearje, alle kaartsjes deistich kontrolearje op feroarings.
Prozessen
Jo moatte de prosessen yn jo team formalisearje en beskriuwe. As jo dit punt hawwe berikt, dan moat jo team op syn minst de folgjende prosessen al hawwe rinnen:
Deistige prosessen:
- wurkje mei kaartsjes
- wurkje mei logs
- feroarje kontrôle
- deistige check sheet
Jierlikse prosessen:
- ferlinging fan garânsjes, lisinsjes
Asynchrone prosessen:
- antwurd op ferskate needsituaasjes
Konklúzje fan it earste diel
Hawwe jo opfallen dat dit alles noch net oer netwurkkonfiguraasje giet, net oer ûntwerp, net oer netwurkprotokollen, net oer routing, net oer feiligens ... It is wat om. Mar dizze, hoewol miskien saai, binne fansels tige wichtige eleminten fan it wurk fan in netwurkdivyzje.
Sa't jo sjen kinne, hawwe jo oant no ta neat ferbettere yn jo netwurk. As d'r kwetsberens wiene foar feiligens, dan bleauwen se; as d'r min ûntwerp wie, dan bleau it. Oant jo jo feardichheden en kennis hawwe tapast as netwurkingenieur, wêr't jo nei alle gedachten in protte tiid, muoite en soms jild oan hawwe bestege. Mar earst moatte jo de stifting meitsje (of fersterkje), en dan begjinne de bou.
De folgjende dielen sille jo fertelle hoe't jo flaters fine en eliminearje, en jo ynfrastruktuer dan ferbetterje.
Fansels hoege jo net alles opfolgjend te dwaan. Tiid kin kritysk wêze. Doch it parallel as middels it tastean.
En in wichtige oanfolling. Kommunisearje, freegje, rieplachtsje mei jo team. Uteinlik binne it dejingen dy't dit alles stypje en dogge.
Boarne: www.habr.com