તમારા નેટવર્ક ઈન્ફ્રાસ્ટ્રક્ચરને કેવી રીતે નિયંત્રિત કરવું. પ્રથમ પ્રકરણ. પકડી રાખવું

આ લેખ "તમારા નેટવર્ક ઈન્ફ્રાસ્ટ્રક્ચર પર કેવી રીતે નિયંત્રણ મેળવવું" લેખોની શ્રેણીમાં પ્રથમ છે. શ્રેણીના તમામ લેખોની સામગ્રી અને લિંક્સ મળી શકે છે અહીં.

હું સંપૂર્ણપણે કબૂલ કરું છું કે એવી પર્યાપ્ત સંખ્યામાં કંપનીઓ છે કે જ્યાં એક કલાક અથવા એક દિવસનો નેટવર્ક ડાઉનટાઇમ મહત્વપૂર્ણ નથી. કમનસીબે કે સદનસીબે, મને આવી જગ્યાએ કામ કરવાની તક મળી નથી. પરંતુ, અલબત્ત, નેટવર્ક્સ અલગ છે, જરૂરિયાતો અલગ છે, અભિગમો અલગ છે, અને તેમ છતાં, એક અથવા બીજા સ્વરૂપે, ઘણા કિસ્સાઓમાં નીચેની સૂચિ ખરેખર "કરવી જોઈએ" હશે.

તેથી, પ્રારંભિક શરતો.

તમે નવી નોકરીમાં છો, તમને પ્રમોશન મળ્યું છે અથવા તમે તમારી જવાબદારીઓ પર નવેસરથી દેખાવ કરવાનું નક્કી કર્યું છે. કંપની નેટવર્ક એ તમારી જવાબદારીનું ક્ષેત્ર છે. તમારા માટે, આ ઘણી રીતે એક પડકાર અને નવું છે, જે આ લેખના માર્ગદર્શક સ્વરને કંઈક અંશે ન્યાયી ઠેરવે છે :). પરંતુ હું આશા રાખું છું કે લેખ કોઈપણ નેટવર્ક એન્જિનિયર માટે પણ ઉપયોગી થઈ શકે છે.

તમારું પ્રથમ વ્યૂહાત્મક ધ્યેય એંટ્રોપીનો પ્રતિકાર કરવાનું શીખવાનું અને પ્રદાન કરેલ સેવાના સ્તરને જાળવી રાખવાનું છે.

નીચે વર્ણવેલ ઘણી સમસ્યાઓ વિવિધ માધ્યમો દ્વારા ઉકેલી શકાય છે. હું ઇરાદાપૂર્વક તકનીકી અમલીકરણનો વિષય ઉઠાવતો નથી, કારણ કે... સૈદ્ધાંતિક રીતે, તે ઘણીવાર એટલું મહત્વનું નથી કે તમે આ અથવા તે સમસ્યાનું નિરાકરણ કેવી રીતે કર્યું, પરંતુ મહત્વપૂર્ણ છે કે તમે તેનો ઉપયોગ કેવી રીતે કરો છો અને તમે તેનો ઉપયોગ કરો છો કે નહીં. ઉદાહરણ તરીકે, જો તમે તેને જોતા નથી અને ચેતવણીઓનો પ્રતિસાદ આપતા નથી, તો તમારી વ્યવસાયિક રીતે બનાવેલ મોનિટરિંગ સિસ્ટમનો થોડો ઉપયોગ થશે.

સાધનો

પ્રથમ તમારે એ સમજવાની જરૂર છે કે સૌથી મોટા જોખમો ક્યાં છે.

ફરીથી, તે અલગ હોઈ શકે છે. હું કબૂલ કરું છું કે ક્યાંક, ઉદાહરણ તરીકે, આ સુરક્ષા સમસ્યાઓ હશે, અને ક્યાંક, સેવાની સાતત્ય સાથે સંબંધિત સમસ્યાઓ, અને ક્યાંક, કદાચ, કંઈક બીજું. કેમ નહિ?

ચાલો ધારીએ, સ્પષ્ટપણે, કે આ હજી પણ સેવાની સાતત્ય છે (હું જ્યાં કામ કરતો હતો તે બધી કંપનીઓમાં આ કેસ હતો).

પછી તમારે સાધનો સાથે પ્રારંભ કરવાની જરૂર છે. અહીં ધ્યાન આપવાના વિષયોની સૂચિ છે:

• જટિલતાની ડિગ્રી દ્વારા સાધનોનું વર્ગીકરણ
• જટિલ સાધનોનો બેકઅપ
• આધાર, લાઇસન્સ

તમારે સંભવિત નિષ્ફળતાના દૃશ્યો દ્વારા વિચારવાની જરૂર છે, ખાસ કરીને તમારા જટિલતા વર્ગીકરણની ટોચ પરના સાધનો સાથે. સામાન્ય રીતે, બેવડી સમસ્યાઓની સંભાવનાને અવગણવામાં આવે છે, અન્યથા તમારું સોલ્યુશન અને સપોર્ટ ગેરવાજબી રીતે ખર્ચાળ બની શકે છે, પરંતુ ખરેખર નિર્ણાયક નેટવર્ક ઘટકોના કિસ્સામાં, જેની નિષ્ફળતા વ્યવસાયને નોંધપાત્ર રીતે અસર કરી શકે છે, તમારે તેના વિશે વિચારવું જોઈએ.

ઉદાહરણ:

ચાલો કહીએ કે અમે ડેટા સેન્ટરમાં રૂટ સ્વિચ વિશે વાત કરી રહ્યા છીએ.

કારણ કે અમે સંમત થયા છીએ કે સેવાની સાતત્ય એ સૌથી મહત્વપૂર્ણ માપદંડ છે, આ સાધનનો "હોટ" બેકઅપ (રિડન્ડન્સી) પ્રદાન કરવું વાજબી છે. પરંતુ તે બધુ જ નથી. તમારે એ પણ નક્કી કરવાની જરૂર છે કે જો પ્રથમ સ્વીચ તૂટે છે, તો શું તમારા માટે માત્ર એક જ બાકી રહેલી સ્વીચ સાથે જીવવું સ્વીકાર્ય છે, કારણ કે તે પણ તૂટવાનું જોખમ છે.

મહત્વપૂર્ણ! તમારે આ મુદ્દો જાતે નક્કી કરવાની જરૂર નથી. તમારે મેનેજમેન્ટ અથવા કંપની મેનેજમેન્ટના જોખમો, સંભવિત ઉકેલો અને ખર્ચનું વર્ણન કરવું આવશ્યક છે. તેઓએ નિર્ણયો લેવા જોઈએ.

તેથી, જો એવું નક્કી કરવામાં આવ્યું હોય કે, ડબલ નિષ્ફળતાની નાની સંભાવનાને જોતાં, એક સ્વીચ પર 4 કલાક કામ કરવું, સૈદ્ધાંતિક રીતે, સ્વીકાર્ય છે, તો તમે ફક્ત યોગ્ય ટેકો લઈ શકો છો (જે મુજબ સાધન 4 ની અંદર બદલવામાં આવશે. કલાક).

પરંતુ એક જોખમ છે કે તેઓ પહોંચાડશે નહીં. કમનસીબે, આપણે એક વખત આવી પરિસ્થિતિમાં આવી ગયા. ચાર કલાકને બદલે, સાધનસામગ્રીએ એક અઠવાડિયા સુધી મુસાફરી કરી !!!

તેથી, આ જોખમની પણ ચર્ચા કરવાની જરૂર છે અને, કદાચ, તમારા માટે બીજી સ્વીચ (ત્રીજું) ખરીદવું અને તેને સ્પેરપાર્ટ્સ પેકેજ ("કોલ્ડ" બેકઅપ)માં રાખવું અથવા પ્રયોગશાળાના હેતુઓ માટે તેનો ઉપયોગ કરવો વધુ યોગ્ય રહેશે.

મહત્વપૂર્ણ! સમાપ્તિ તારીખો સાથે તમારી પાસેના તમામ સપોર્ટની સ્પ્રેડશીટ બનાવો અને તેને તમારા કેલેન્ડરમાં ઉમેરો જેથી કરીને ઓછામાં ઓછા એક મહિના અગાઉ તમને એક ઈમેલ મળે કે તમારે તમારા સપોર્ટને રિન્યૂ કરવાની ચિંતા કરવાનું શરૂ કરવું જોઈએ.

જો તમે તમારા સપોર્ટને રિન્યૂ કરવાનું ભૂલી જશો અને તમારા હાર્ડવેર બ્રેક્સ સમાપ્ત થયાના બીજા દિવસે તમને માફ કરવામાં આવશે નહીં.

ઇમરજન્સી કામ

તમારા નેટવર્ક પર ગમે તે થાય, આદર્શ રીતે તમારે તમારા નેટવર્ક સાધનોની ઍક્સેસ જાળવી રાખવી જોઈએ.

મહત્વપૂર્ણ! તમારી પાસે તમામ સાધનોની કન્સોલ એક્સેસ હોવી જોઈએ અને આ એક્સેસ યુઝર ડેટા નેટવર્કના સ્વાસ્થ્ય પર આધારિત ન હોવી જોઈએ.

તમારે અગાઉથી સંભવિત નકારાત્મક દૃશ્યોની પણ આગાહી કરવી જોઈએ અને જરૂરી ક્રિયાઓનું દસ્તાવેજીકરણ કરવું જોઈએ. આ દસ્તાવેજની ઉપલબ્ધતા પણ નિર્ણાયક છે, તેથી તેને ફક્ત વિભાગ માટે વહેંચાયેલ સંસાધન પર જ પોસ્ટ કરવું જોઈએ નહીં, પરંતુ તેને સ્થાનિક રીતે એન્જિનિયર્સના કમ્પ્યુટર્સ પર પણ સાચવવું જોઈએ.

ત્યાં હોવુજ જોઈએ

• વિક્રેતા અથવા ઇન્ટિગ્રેટર સપોર્ટ સાથે ટિકિટ ખોલવા માટે જરૂરી માહિતી
• કોઈપણ સાધન (કન્સોલ, મેનેજમેન્ટ) સુધી કેવી રીતે પહોંચવું તેની માહિતી

અલબત્ત, તેમાં અન્ય કોઈપણ ઉપયોગી માહિતી પણ હોઈ શકે છે, ઉદાહરણ તરીકે, વિવિધ સાધનો અને ઉપયોગી ડાયગ્નોસ્ટિક આદેશો માટેની અપગ્રેડ પ્રક્રિયાનું વર્ણન.

અમારા પાર્ટનર્સ

હવે તમારે ભાગીદારો સાથે સંકળાયેલા જોખમોનું મૂલ્યાંકન કરવાની જરૂર છે. સામાન્ય રીતે આ

• ઈન્ટરનેટ પ્રદાતાઓ અને ટ્રાફિક એક્સચેન્જ પોઈન્ટ (IX)
• સંચાર ચેનલ પ્રદાતાઓ

તમારે પોતાને કયા પ્રશ્નો પૂછવા જોઈએ? સાધનસામગ્રીની જેમ, વિવિધ કટોકટીની પરિસ્થિતિઓને ધ્યાનમાં લેવી આવશ્યક છે. ઉદાહરણ તરીકે, ઇન્ટરનેટ પ્રદાતાઓ માટે, તે કંઈક આના જેવું હોઈ શકે છે:

• જો ઈન્ટરનેટ પ્રદાતા X કોઈ કારણસર તમને સેવા આપવાનું બંધ કરે તો શું થાય?
• શું અન્ય પ્રદાતાઓ પાસે તમારા માટે પૂરતી બેન્ડવિડ્થ હશે?
• કનેક્ટિવિટી કેટલી સારી રહેશે?
• તમારા ઈન્ટરનેટ પ્રદાતાઓ કેટલા સ્વતંત્ર છે અને શું તેમાંથી એકની ગંભીર આઉટેજ અન્ય લોકો સાથે સમસ્યા ઊભી કરશે?
• તમારા ડેટા સેન્ટરમાં કેટલા ઓપ્ટિકલ ઇનપુટ્સ છે?
• જો ઇનપુટમાંથી એક સંપૂર્ણપણે નાશ પામે તો શું થશે?

ઇનપુટ્સ વિશે, મારી પ્રેક્ટિસમાં બે અલગ-અલગ કંપનીઓમાં, બે અલગ-અલગ ડેટા સેન્ટરોમાં, એક ખોદકામકર્તાએ કુવાઓનો નાશ કર્યો અને માત્ર ચમત્કારથી જ અમારા ઓપ્ટિક્સને અસર થઈ ન હતી. આ એવો દુર્લભ કિસ્સો નથી.

અને, અલબત્ત, તમારે ફક્ત આ પ્રશ્નો પૂછવાની જરૂર નથી, પરંતુ, ફરીથી, મેનેજમેન્ટના સમર્થન સાથે, કોઈપણ પરિસ્થિતિમાં સ્વીકાર્ય ઉકેલ પ્રદાન કરવા માટે.

બેકઅપ

આગળની પ્રાથમિકતા સાધનોના રૂપરેખાંકનોનો બેકઅપ હોઈ શકે છે. કોઈ પણ સંજોગોમાં, આ એક ખૂબ જ મહત્વપૂર્ણ મુદ્દો છે. જ્યારે તમે રૂપરેખાંકન ગુમાવી શકો છો ત્યારે હું એવા કેસોની સૂચિ બનાવીશ નહીં; નિયમિત બેકઅપ લેવાનું વધુ સારું છે અને તેના વિશે વિચારવું નહીં. વધુમાં, નિયમિત બેકઅપ ફેરફારોને મોનિટર કરવામાં ખૂબ ઉપયોગી થઈ શકે છે.

મહત્વપૂર્ણ! દરરોજ બેકઅપ બનાવો. આના પર સાચવવા માટે આટલી મોટી માત્રામાં ડેટા નથી. સવારે, ફરજ પરના ઇજનેર (અથવા તમારે) સિસ્ટમમાંથી એક રિપોર્ટ મેળવવો જોઈએ, જે સ્પષ્ટપણે સૂચવે છે કે બેકઅપ સફળ થયું હતું કે નહીં, અને જો બેકઅપ અસફળ હતું, તો સમસ્યા હલ થવી જોઈએ અથવા ટિકિટ બનાવવી જોઈએ ( નેટવર્ક વિભાગ પ્રક્રિયાઓ જુઓ).

સોફ્ટવેર આવૃત્તિઓ

સાધનસામગ્રીના સૉફ્ટવેરને અપગ્રેડ કરવા યોગ્ય છે કે નહીં તે પ્રશ્ન એટલો સ્પષ્ટ નથી. એક તરફ, જૂના સંસ્કરણો જાણીતી બગ્સ અને નબળાઈઓ છે, પરંતુ બીજી તરફ, નવું સોફ્ટવેર એ, પ્રથમ, હંમેશા પીડારહિત અપગ્રેડ પ્રક્રિયા નથી, અને બીજું, નવી ભૂલો અને નબળાઈઓ છે.

અહીં તમારે શ્રેષ્ઠ વિકલ્પ શોધવાની જરૂર છે. કેટલીક સ્પષ્ટ ભલામણો

• ફક્ત સ્થિર સંસ્કરણો ઇન્સ્ટોલ કરો
• તેમ છતાં, તમારે સૉફ્ટવેરના ખૂબ જૂના સંસ્કરણો પર જીવવું જોઈએ નહીં
• અમુક સોફ્ટવેર ક્યાં સ્થિત છે તેની માહિતી સાથે એક સાઇન બનાવો
• સમયાંતરે સૉફ્ટવેર સંસ્કરણોમાં નબળાઈઓ અને ભૂલો પરના અહેવાલો વાંચો, અને ગંભીર સમસ્યાઓના કિસ્સામાં, તમારે અપગ્રેડ કરવા વિશે વિચારવું જોઈએ

આ તબક્કે, સાધનસામગ્રીની કન્સોલ ઍક્સેસ, સમર્થન વિશેની માહિતી અને અપગ્રેડ પ્રક્રિયાનું વર્ણન, તમે સૈદ્ધાંતિક રીતે, આ પગલા માટે તૈયાર છો. આદર્શ વિકલ્પ એ છે કે જ્યારે તમારી પાસે પ્રયોગશાળાના સાધનો હોય જ્યાં તમે સમગ્ર પ્રક્રિયાને ચકાસી શકો, પરંતુ, કમનસીબે, આવું વારંવાર થતું નથી.

જટિલ સાધનોના કિસ્સામાં, તમે અપગ્રેડ કરવામાં મદદ કરવા વિનંતી સાથે વિક્રેતાના સમર્થનનો સંપર્ક કરી શકો છો.

ટિકિટ સિસ્ટમ

હવે તમે આસપાસ જોઈ શકો છો. તમારે અન્ય વિભાગો સાથે અને વિભાગની અંદર ક્રિયાપ્રતિક્રિયા માટે પ્રક્રિયાઓ સ્થાપિત કરવાની જરૂર છે.

આ જરૂરી ન હોઈ શકે (ઉદાહરણ તરીકે, જો તમારી કંપની નાની છે), પરંતુ હું ખૂબ જ ભલામણ કરીશ કે કાર્યને એવી રીતે ગોઠવો કે તમામ બાહ્ય અને આંતરિક કાર્યો ટિકિટ સિસ્ટમમાંથી પસાર થાય.

ટિકિટ સિસ્ટમ આવશ્યકપણે આંતરિક અને બાહ્ય સંદેશાવ્યવહાર માટે તમારું ઇન્ટરફેસ છે, અને તમારે આ ઇન્ટરફેસનું પર્યાપ્ત વિગતવાર વર્ણન કરવું જોઈએ.

ચાલો એક્સેસ ખોલવાના એક મહત્વપૂર્ણ અને સામાન્ય કાર્યનું ઉદાહરણ લઈએ. હું એક એલ્ગોરિધમનું વર્ણન કરીશ જેણે એક કંપનીમાં સંપૂર્ણ રીતે કામ કર્યું.

ઉદાહરણ:

ચાલો એ હકીકતથી શરૂઆત કરીએ કે ઘણીવાર ઍક્સેસ ગ્રાહકો તેમની ઇચ્છાઓને નેટવર્ક એન્જિનિયર માટે અગમ્ય ભાષામાં ઘડે છે, એટલે કે, એપ્લિકેશનની ભાષામાં, ઉદાહરણ તરીકે, "મને 1C ની ઍક્સેસ આપો."

તેથી, અમે આવા વપરાશકર્તાઓની સીધી વિનંતી ક્યારેય સ્વીકારી નથી.
અને તે પ્રથમ જરૂરિયાત હતી

• ઍક્સેસ માટેની વિનંતીઓ તકનીકી વિભાગો તરફથી આવવી જોઈએ (અમારા કિસ્સામાં આ યુનિક્સ, વિન્ડોઝ, હેલ્પડેસ્ક એન્જિનિયર્સ હતા)

બીજી જરૂરિયાત એ છે કે

• આ ઍક્સેસ લોગ થયેલ હોવી જોઈએ (તે ટેકનિકલ વિભાગ દ્વારા જેમાંથી અમને આ વિનંતી મળી છે) અને વિનંતી તરીકે અમને આ લૉગ કરેલ ઍક્સેસની લિંક પ્રાપ્ત થાય છે

આ વિનંતીનું સ્વરૂપ અમને સમજી શકાય તેવું હોવું જોઈએ, એટલે કે.

• વિનંતીમાં કયા સબનેટ અને કયા સબનેટની ઍક્સેસ ખુલ્લી હોવી જોઈએ તે અંગેની માહિતી તેમજ પ્રોટોકોલ અને (tcp/udpના કિસ્સામાં) પોર્ટ હોવા જોઈએ.

તે ત્યાં પણ સૂચવવું જોઈએ

• આ એક્સેસ શા માટે ખોલવામાં આવે છે તેનું વર્ણન
• કામચલાઉ અથવા કાયમી (જો કામચલાઉ હોય, તો કઈ તારીખ સુધી)

અને એક ખૂબ જ મહત્વપૂર્ણ મુદ્દો મંજૂરીઓ છે

• વિભાગના વડા તરફથી કે જેણે પ્રવેશ શરૂ કર્યો (ઉદાહરણ તરીકે, એકાઉન્ટિંગ)
• તકનીકી વિભાગના વડા પાસેથી, જ્યાંથી આ વિનંતી નેટવર્ક વિભાગને આવી (ઉદાહરણ તરીકે, હેલ્પડેસ્ક)

આ કિસ્સામાં, આ ઍક્સેસના "માલિક" એ વિભાગના વડા તરીકે ગણવામાં આવે છે જેણે ઍક્સેસની શરૂઆત કરી હતી (અમારા ઉદાહરણમાં એકાઉન્ટિંગ), અને તે ખાતરી કરવા માટે જવાબદાર છે કે આ વિભાગ માટે લૉગ કરેલ ઍક્સેસ સાથેનું પૃષ્ઠ અદ્યતન રહે. .

લોગીંગ

આ એવી વસ્તુ છે જેમાં તમે ડૂબી શકો છો. પરંતુ જો તમે સક્રિય અભિગમ અમલમાં મૂકવા માંગતા હો, તો તમારે આ ડેટા પૂરનો સામનો કેવી રીતે કરવો તે શીખવાની જરૂર છે.

અહીં કેટલીક વ્યવહારુ ભલામણો છે:

• તમારે દરરોજ લોગની સમીક્ષા કરવાની જરૂર છે
• આયોજિત સમીક્ષાના કિસ્સામાં (અને કટોકટીની પરિસ્થિતિ નહીં), તમે તમારી જાતને ગંભીરતાના સ્તર 0, 1, 2 સુધી મર્યાદિત કરી શકો છો અને જો તમને જરૂરી લાગે તો અન્ય સ્તરોમાંથી પસંદ કરેલ દાખલાઓ ઉમેરી શકો છો.
• એક સ્ક્રિપ્ટ લખો જે લૉગ્સનું વિશ્લેષિત કરે છે અને તે લૉગ્સને અવગણે છે જેની પેટર્ન તમે અવગણો સૂચિમાં ઉમેર્યા છે

આ અભિગમ તમને સમય જતાં, તમારા માટે રસપ્રદ ન હોય તેવા લૉગ્સની અવગણનાની સૂચિ બનાવવાની પરવાનગી આપશે અને ફક્ત તે જ છોડશે જેને તમે ખરેખર મહત્વપૂર્ણ માનો છો.
તે અમારા માટે મહાન કામ કર્યું.

મોનીટરીંગ

કંપનીમાં મોનિટરિંગ સિસ્ટમનો અભાવ હોવો અસામાન્ય નથી. તમે, ઉદાહરણ તરીકે, લોગ પર આધાર રાખી શકો છો, પરંતુ સાધનસામગ્રી કંઈપણ "કહેવા" માટે સમય વિના ફક્ત "મૃત્યુ પામે છે" અથવા udp syslog પ્રોટોકોલ પેકેટ ગુમ થઈ શકે છે અને પહોંચશે નહીં. સામાન્ય રીતે, અલબત્ત, સક્રિય દેખરેખ મહત્વપૂર્ણ અને જરૂરી છે.

મારી પ્રેક્ટિસમાં બે સૌથી લોકપ્રિય ઉદાહરણો:

• સંદેશાવ્યવહાર ચેનલોના ભારનું નિરીક્ષણ કરવું, જટિલ લિંક્સ (ઉદાહરણ તરીકે, પ્રદાતાઓ સાથે કનેક્ટ કરવું). તેઓ તમને ટ્રાફિકના નુકસાનને કારણે સેવાના અધોગતિની સંભવિત સમસ્યાને સક્રિયપણે જોવાની મંજૂરી આપે છે અને તે મુજબ, તેને ટાળે છે.
• નેટફ્લો પર આધારિત આલેખ. તેઓ ટ્રાફિકમાં વિસંગતતાઓ શોધવાનું સરળ બનાવે છે અને કેટલાક સરળ પરંતુ નોંધપાત્ર પ્રકારના હેકર હુમલાઓને શોધવા માટે ખૂબ જ ઉપયોગી છે.

મહત્વપૂર્ણ! સૌથી મહત્વપૂર્ણ ઘટનાઓ માટે SMS સૂચનાઓ સેટ કરો. આ મોનીટરીંગ અને લોગીંગ બંનેને લાગુ પડે છે. જો તમારી પાસે ઓન-ડ્યુટી શિફ્ટ ન હોય, તો એસએમએસ પણ કામના કલાકોની બહાર આવવો જોઈએ.

પ્રક્રિયા દ્વારા એવી રીતે વિચારો કે જેથી બધા એન્જિનિયરો જાગે નહીં. આ માટે અમારી પાસે એક એન્જિનિયર ફરજ પર હતો.

નિયંત્રણ બદલો

મારા મતે, બધા ફેરફારોને નિયંત્રિત કરવું જરૂરી નથી. પરંતુ, કોઈ પણ સંજોગોમાં, જો જરૂરી હોય તો, તમારે નેટવર્ક પર ચોક્કસ ફેરફારો કોણે અને શા માટે કર્યા છે તે સરળતાથી શોધવા માટે સમર્થ હોવા જોઈએ.

થોડી ટીપ્સ:

• તે ટિકિટ પર શું કરવામાં આવ્યું હતું તેની વિગતો આપવા માટે ટિકિટ સિસ્ટમનો ઉપયોગ કરો, ઉદાહરણ તરીકે ટિકિટમાં લાગુ કરેલ ગોઠવણીની નકલ કરીને
• નેટવર્ક સાધનો પર ટિપ્પણી ક્ષમતાઓનો ઉપયોગ કરો (ઉદાહરણ તરીકે, જ્યુનિપર પર ટિપ્પણી કરો). તમે ટિકિટ નંબર લખી શકો છો
• તમારા રૂપરેખાંકન બેકઅપના તફાવતનો ઉપયોગ કરો

તમે આને પ્રક્રિયા તરીકે અમલમાં મૂકી શકો છો, ફેરફારો માટે દરરોજ તમામ ટિકિટોની સમીક્ષા કરી શકો છો.

પ્રક્રિયાઓ

તમારે તમારી ટીમમાં પ્રક્રિયાઓનું ઔપચારિકીકરણ અને વર્ણન કરવું આવશ્યક છે. જો તમે આ બિંદુએ પહોંચી ગયા છો, તો તમારી ટીમ પાસે પહેલેથી જ ઓછામાં ઓછી નીચેની પ્રક્રિયાઓ ચાલી રહી હોવી જોઈએ:

દૈનિક પ્રક્રિયાઓ:

• ટિકિટ સાથે કામ
• લોગ સાથે કામ
• નિયંત્રણ બદલો
• દૈનિક ચેક શીટ

વાર્ષિક પ્રક્રિયાઓ:

• ગેરંટી, લાઇસન્સનું વિસ્તરણ

અસુમેળ પ્રક્રિયાઓ:

• વિવિધ કટોકટીની પરિસ્થિતિઓ માટે પ્રતિભાવ

પ્રથમ ભાગનો નિષ્કર્ષ

શું તમે નોંધ્યું છે કે આ બધું હજી નેટવર્ક રૂપરેખાંકન વિશે નથી, ડિઝાઇન વિશે નથી, નેટવર્ક પ્રોટોકોલ વિશે નથી, રૂટીંગ વિશે નથી, સુરક્ષા વિશે નથી... તે કંઈક આસપાસ છે. પરંતુ આ, કદાચ કંટાળાજનક હોવા છતાં, અલબત્ત, નેટવર્ક વિભાગના કાર્યના ખૂબ જ મહત્વપૂર્ણ ઘટકો છે.

અત્યાર સુધી, જેમ તમે જોઈ શકો છો, તમે તમારા નેટવર્કમાં કંઈપણ સુધાર્યું નથી. જો ત્યાં સુરક્ષા નબળાઈઓ હતી, તો તે રહી, જો ત્યાં ખરાબ ડિઝાઇન હતી, તો તે રહી. જ્યાં સુધી તમે નેટવર્ક એન્જિનિયર તરીકે તમારી કુશળતા અને જ્ઞાનનો ઉપયોગ ન કરો, જેના પર તમે મોટાભાગે સમય, પ્રયત્નો અને ક્યારેક પૈસા ખર્ચ્યા હશે. પરંતુ પ્રથમ તમારે પાયો બનાવવા (અથવા મજબૂત) કરવાની જરૂર છે, અને પછી બાંધકામ શરૂ કરો.

નીચેના ભાગો તમને જણાવશે કે ભૂલો કેવી રીતે શોધવી અને દૂર કરવી અને પછી તમારા ઈન્ફ્રાસ્ટ્રક્ચરને કેવી રીતે સુધારવું.

અલબત્ત, તમારે બધું ક્રમશઃ કરવાની જરૂર નથી. સમય નિર્ણાયક બની શકે છે. જો સંસાધનો મંજૂરી આપે તો તેને સમાંતર કરો.

અને એક મહત્વપૂર્ણ ઉમેરો. તમારી ટીમ સાથે વાતચીત કરો, પૂછો, સલાહ લો. અંતે, તેઓ જ આ બધું સમર્થન કરે છે અને કરે છે.

સોર્સ: www.habr.com