નેટવર્કર્સ (નથી) જરૂરી છે

આ લેખ લખતી વખતે, "નેટવર્ક એન્જિનિયર" વાક્ય માટે લોકપ્રિય જોબ સાઇટ પરની શોધે સમગ્ર રશિયામાં લગભગ ત્રણસો ખાલી જગ્યાઓ પરત કરી. સરખામણી માટે, "સિસ્ટમ એડમિનિસ્ટ્રેટર" શબ્દસમૂહની શોધ લગભગ 2.5 હજાર ખાલી જગ્યાઓ અને "DevOps એન્જિનિયર" - લગભગ 800 પરત કરે છે.

શું આનો અર્થ એ છે કે વિજયી વાદળો, ડોકર, કુબરનેટ્સ અને સર્વવ્યાપક જાહેર Wi-Fiના સમયમાં નેટવર્કર્સની હવે જરૂર નથી?
ચાલો તેને શોધી કાઢીએ (c)

ચાલો પરિચિત થઇએ. મારું નામ એલેક્સી છે, અને હું નેટવર્કર છું.

હું 10 વર્ષથી વધુ સમયથી નેટવર્ક્સમાં સંકળાયેલો છું અને 15 વર્ષથી વધુ સમયથી વિવિધ *નિક્સ સિસ્ટમ્સ સાથે કામ કરું છું (મને Linux અને FreeBSD બંને સાથે ટિંકર કરવાની તક મળી). મેં ટેલિકોમ ઓપરેટર્સમાં કામ કર્યું છે, મોટી કંપનીઓ કે જેને "એન્ટરપ્રાઇઝ" ગણવામાં આવે છે, અને તાજેતરમાં હું "યુવાન અને હિંમતવાન" ફિનટેકમાં કામ કરી રહ્યો છું, જ્યાં ક્લાઉડ્સ, ડેવોપ્સ, કુબરનેટ્સ અને અન્ય ડરામણા શબ્દો જે ચોક્કસપણે મને અને મારા સાથીદારોને બિનજરૂરી બનાવશે. . કોઈ દિવસ. કદાચ.

અસ્વીકરણ: "આપણા જીવનમાં, બધું હંમેશા અને દરેક જગ્યાએ નથી, પરંતુ કંઈક, ક્યારેક સ્થળોએ" (c) મેક્સિમ ડોરોફીવ.

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

મારી દુનિયા માં તમારું સ્વાગત છે.

તમે નેટવર્કર્સને પણ ક્યાં મળી શકો?

1. ટેલિકોમ ઓપરેટર્સ, સર્વિસ કંપનીઓ અને અન્ય ઇન્ટિગ્રેટર્સ. અહીં બધું સરળ છે: તેમના માટે નેટવર્ક એ એક વ્યવસાય છે. તેઓ કાં તો સીધા કનેક્ટિવિટી (ઓપરેટર્સ) વેચે છે અથવા તેમના ગ્રાહકોના નેટવર્કને શરૂ/જાળવવા માટે સેવાઓ પ્રદાન કરે છે.

અહીં ઘણો અનુભવ છે, પરંતુ વધુ પૈસા નથી (જ્યાં સુધી તમે ડિરેક્ટર અથવા સફળ સેલ્સ મેનેજર નથી). અને તેમ છતાં, જો તમને નેટવર્ક ગમે છે, અને તમે તમારી મુસાફરીની શરૂઆતમાં જ છો, તો કેટલાક ખૂબ મોટા ન હોય તેવા ઓપરેટરના સમર્થનમાં કારકિર્દી એક આદર્શ પ્રારંભિક બિંદુ હશે (ફેડરલ લોકોમાં બધું ખૂબ જ સ્ક્રિપ્ટેડ છે, અને ત્યાં સર્જનાત્મકતા માટે થોડી જગ્યા છે). ઠીક છે, તમે કેટલાંક વર્ષોમાં ફરજ પરના એન્જિનિયરથી સી-લેવલ મેનેજર સુધી કેવી રીતે પ્રગતિ કરી શકો તે વિશેની વાર્તાઓ પણ એકદમ વાસ્તવિક છે, જોકે સ્પષ્ટ કારણોસર દુર્લભ છે. હંમેશા કર્મચારીઓની જરૂર રહે છે, કારણ કે ટર્નઓવર થાય છે. આ એક જ સમયે સારું અને ખરાબ બંને છે - ત્યાં હંમેશા ખાલી જગ્યાઓ હોય છે, બીજી બાજુ - ઘણીવાર સૌથી વધુ સક્રિય/સ્માર્ટ લોકો પ્રમોશન માટે અથવા અન્ય, "ગરમ" સ્થાનો પર ઝડપથી જતા રહે છે.

2. શરતી "એન્ટરપ્રાઇઝ". તેની મુખ્ય પ્રવૃત્તિ આઈટી સાથે સંબંધિત છે કે નહીં તેનાથી કોઈ ફરક પડતો નથી. મુખ્ય બાબત એ છે કે તેનો પોતાનો IT વિભાગ છે, જે કંપનીની આંતરિક સિસ્ટમના સંચાલનને સુનિશ્ચિત કરે છે, જેમાં ઑફિસમાં નેટવર્ક, શાખાઓ સુધીની સંચાર ચેનલો વગેરેનો સમાવેશ થાય છે. આવી કંપનીઓમાં નેટવર્ક એન્જિનિયરના કાર્યો સિસ્ટમ એડમિનિસ્ટ્રેટર દ્વારા "પાર્ટ-ટાઇમ" કરી શકાય છે (જો નેટવર્ક ઇન્ફ્રાસ્ટ્રક્ચર નાનું હોય અથવા બાહ્ય કોન્ટ્રાક્ટર દ્વારા નિયંત્રિત કરવામાં આવે છે), અને નેટવર્ક નિષ્ણાત, જો ત્યાં હોય, તો તે કરી શકે છે તે જ સમયે ટેલિફોની અને SAN (સારું નથી). તેઓ અલગ રીતે ચૂકવણી કરે છે - તે વ્યવસાયની નફાકારકતા, કંપનીના કદ અને માળખા પર ખૂબ આધાર રાખે છે. મેં એવી કંપનીઓ સાથે કામ કર્યું કે જ્યાં સિસ્કો સિસ્ટમ્સ નિયમિતપણે "બેરલમાં લોડ કરવામાં આવી હતી", અને એવી કંપનીઓ સાથે જ્યાં નેટવર્ક મળ, લાકડીઓ અને વાદળી ટેપથી બનાવવામાં આવ્યું હતું, અને સર્વર્સ ક્યારેય અપડેટ થયા ન હતા (કહેવાની જરૂર નથી, કોઈ અનામત પણ પ્રદાન કરવામાં આવી ન હતી). અહીં ઘણો ઓછો અનુભવ છે, અને તે લગભગ ચોક્કસપણે કડક વિક્રેતા-લોકના ક્ષેત્રમાં હશે, અથવા "કંઈક બહાર કઈ રીતે બનાવવું." અંગત રીતે, મને તે જંગલી રીતે કંટાળાજનક લાગ્યું, જો કે ઘણા લોકોને તે ગમે છે - બધું ખૂબ માપવામાં આવે છે અને અનુમાનિત છે (જો આપણે મોટી કંપનીઓ વિશે વાત કરીએ છીએ), "દોરખા-બહાતો", વગેરે. વર્ષમાં ઓછામાં ઓછા એક વખત, કેટલાક મોટા વિક્રેતા કહે છે કે તેઓ બીજી મેગા-સુપર-ડુપર સિસ્ટમ સાથે આવ્યા છે જે હવે બધું સ્વચાલિત કરશે અને બધા સિસ્ટમ સંચાલકો અને નેટવર્કર્સને વિખેરવામાં આવશે, એક સુંદર ઇન્ટરફેસમાં બટનો દબાવવા માટે એક યુગલને છોડીને. વાસ્તવિકતા એ છે કે, જો આપણે ઉકેલની કિંમતને અવગણીએ તો પણ, નેટવર્કર્સ ત્યાંથી ક્યાંય જશે નહીં. હા, કદાચ કન્સોલને બદલે ફરીથી વેબ ઈન્ટરફેસ હશે (પરંતુ હાર્ડવેરનો ચોક્કસ ભાગ નહીં, પરંતુ એક વિશાળ સિસ્ટમ કે જે દસ અને આવા સેંકડો હાર્ડવેરના ટુકડાઓનું સંચાલન કરે છે), પરંતુ "અંદર બધું કેવી રીતે કાર્ય કરે છે" નું જ્ઞાન હજી પણ હશે. જરૂર પડશે.

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

નેટવર્કર સિસ્ટમ એડમિનિસ્ટ્રેટરથી કેવી રીતે અલગ છે?

IT ના લોકોની સમજણમાં - કંઈ નથી. તે બંને કાળા સ્ક્રીન તરફ જુએ છે અને કેટલાક સ્પેલ્સ લખે છે, ક્યારેક શાંતિથી શપથ લે છે.

પ્રોગ્રામરોની સમજણમાં - કદાચ વિષય વિસ્તાર દ્વારા. સિસ્ટમ એડમિનિસ્ટ્રેટર્સ સર્વર્સનું સંચાલન કરે છે, નેટવર્કર્સ સ્વીચો અને રાઉટરનું સંચાલન કરે છે. કેટલીકવાર વહીવટ ખરાબ હોય છે, અને દરેક માટે બધું અલગ પડી જાય છે. ઠીક છે, કંઈપણ વિચિત્ર કિસ્સામાં, નેટવર્કર્સ પણ દોષિત છે. માત્ર કારણ કે તમે વાહિયાત, તેથી જ.

હકીકતમાં, મુખ્ય તફાવત એ કાર્ય કરવાનો અભિગમ છે. કદાચ, તે નેટવર્કર્સમાં છે કે "જો તે કામ કરે છે, તો તેને સ્પર્શ કરશો નહીં!" અભિગમના મોટાભાગના સમર્થકો છે. નિયમ પ્રમાણે, કંઈક માત્ર એક જ રીતે (એક વિક્રેતાની અંદર) કરી શકાય છે; બૉક્સની સંપૂર્ણ ગોઠવણી તમારા હાથની હથેળીમાં છે. ભૂલની કિંમત ઊંચી હોય છે, અને કેટલીકવાર ખૂબ ઊંચી હોય છે (ઉદાહરણ તરીકે, તમારે રાઉટરને રીબૂટ કરવા માટે કેટલાક સો કિલોમીટરની મુસાફરી કરવી પડશે, અને આ સમયે હજારો લોકો સંચાર વિના હશે - ટેલિકોમ ઓપરેટર માટે એકદમ સામાન્ય પરિસ્થિતિ) .

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

પરંતુ જો તમારી પાસે હોસ્ટર હોય તો તમારે નેટવર્કરની શા માટે જરૂર છે?

વધારાના પૈસા માટે (અને જો તમે ખૂબ મોટા અને પ્રિય ક્લાયન્ટ છો, તો કદાચ મફતમાં પણ, "મિત્ર તરીકે"), ડેટા સેન્ટર એન્જિનિયર્સ તમારી જરૂરિયાતોને અનુરૂપ તમારી સ્વીચો ગોઠવશે, અને કદાચ તમને પ્રદાતાઓ સાથે BGP ઇન્ટરફેસ સ્થાપિત કરવામાં પણ મદદ કરશે. (જો તમારી પાસે જાહેરાત માટે તમારું પોતાનું IP એડ્રેસનું સબનેટ છે).

મુખ્ય સમસ્યા એ છે કે ડેટા સેન્ટર તમારું IT વિભાગ નથી, તે એક અલગ કંપની છે જેનું લક્ષ્ય નફો કરવાનું છે. ગ્રાહક તરીકે તમારા ખર્ચે સહિત. ડેટા સેન્ટર રેક્સ પૂરા પાડે છે, તેમને વીજળી અને ઠંડી પૂરી પાડે છે અને ઇન્ટરનેટ સાથે કેટલીક "ડિફોલ્ટ" કનેક્ટિવિટી પણ પૂરી પાડે છે. આ ઈન્ફ્રાસ્ટ્રક્ચરના આધારે, ડેટા સેન્ટર તમારા સાધનો (કોલોકેશન) હોસ્ટ કરી શકે છે, તમને સર્વર ભાડે આપી શકે છે (સમર્પિત સર્વર), અથવા વ્યવસ્થાપિત સેવા પ્રદાન કરી શકે છે (ઉદાહરણ તરીકે, OpenStack અથવા K8s). પરંતુ ડેટા સેન્ટરનો વ્યવસાય (સામાન્ય રીતે) ક્લાયંટ ઈન્ફ્રાસ્ટ્રક્ચરનો વહીવટ નથી, કારણ કે આ પ્રક્રિયા તદ્દન શ્રમ-સઘન છે, નબળી સ્વચાલિત છે (અને સામાન્ય ડેટા સેન્ટરમાં જે શક્ય છે તે બધું સ્વયંસંચાલિત છે), એકીકૃત વધુ ખરાબ છે (દરેક ક્લાયંટ વ્યક્તિગત છે) અને સામાન્ય રીતે ફરિયાદોથી ભરપૂર છે ("તમે મને કહો કે સર્વર સેટ કરવામાં આવ્યું હતું, પરંતુ હવે તે ક્રેશ થઈ ગયું છે, તે તમારી બધી ભૂલ છે!!!111"). તેથી, જો હોસ્ટર તમને કંઈક મદદ કરે છે, તો તે તેને શક્ય તેટલું સરળ અને અનુકૂળ બનાવવાનો પ્રયાસ કરશે. કારણ કે તે કરવું અઘરું છે, ઓછામાં ઓછું આ જ હોસ્ટરના એન્જિનિયરોના મજૂર ખર્ચના દૃષ્ટિકોણથી (પરંતુ પરિસ્થિતિઓ અલગ છે, અસ્વીકરણ જુઓ). આનો અર્થ એ નથી કે હોસ્ટર આવશ્યકપણે બધું જ ખરાબ રીતે કરશે. પરંતુ તે બિલકુલ હકીકત નથી કે તે તમને ખરેખર જે જોઈએ છે તે જ કરશે.

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

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

કયા કિસ્સાઓમાં નેટવર્કરની જરૂર છે?

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

ઉદાહરણ 1, ક્લાસિક

ધારો કે કોઈ કંપની સાર્વજનિક IP સરનામાંવાળા એક સર્વરથી શરૂ થાય છે, જે ડેટા સેન્ટરમાં સ્થિત છે. પછી બે સર્વર છે. પછી વધુ... વહેલા કે પછી, સર્વર્સ વચ્ચે ખાનગી નેટવર્કની જરૂર પડશે. કારણ કે "બાહ્ય" ટ્રાફિક બેન્ડવિડ્થ દ્વારા મર્યાદિત છે (ઉદાહરણ તરીકે 100Mbit/s કરતાં વધુ નહીં) અને દર મહિને ડાઉનલોડ/અપલોડ કરેલા જથ્થા દ્વારા (વિવિધ હોસ્ટર્સ પાસે અલગ-અલગ ટેરિફ હોય છે, પરંતુ બહારની દુનિયામાં બેન્ડવિડ્થ સામાન્ય રીતે વધુ ખર્ચાળ હોય છે. ખાનગી નેટવર્ક).

હોસ્ટર સર્વરોમાં વધારાના નેટવર્ક કાર્ડ ઉમેરે છે અને તેમને અલગ vlan માં તેમના સ્વિચમાં સમાવે છે. સર્વર વચ્ચે "ફ્લેટ" સ્થાનિક વિસ્તાર દેખાય છે. આરામદાયક!

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

શું કરવું જોઈએ?

નેટવર્કને સેગમેન્ટ્સમાં વિભાજીત કરો - vlans. દરેક vlan માં તમારું પોતાનું સરનામું ગોઠવો, એક ગેટવે પસંદ કરો જે નેટવર્ક્સ વચ્ચે ટ્રાફિકને સ્થાનાંતરિત કરશે. સેગમેન્ટ્સ વચ્ચે ઍક્સેસ મર્યાદિત કરવા માટે ગેટવે પર acl ને ગોઠવો, અથવા નજીકમાં એક અલગ ફાયરવોલ પણ ઇન્સ્ટોલ કરો.

ઉદાહરણ 1, ચાલુ રાખ્યું

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

શું કરવું જોઈએ?

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

શું આ બધું "સામાન્ય" સિસ્ટમ એડમિનિસ્ટ્રેટર દ્વારા કરી શકાય છે કે જેને નેટવર્કનું ઊંડું જ્ઞાન નથી? ચોક્કસ નથી. શું હોસ્ટર આ કરશે? કદાચ તે થશે, પરંતુ તમારે એકદમ વિગતવાર તકનીકી સ્પષ્ટીકરણની જરૂર પડશે, જે કોઈને પણ દોરવાની જરૂર પડશે. અને પછી તપાસો કે બધું બરાબર થયું છે.

ઉદાહરણ 2: વાદળ

ચાલો કહીએ કે તમારી પાસે કેટલાક સાર્વજનિક ક્લાઉડમાં VPC છે. ઓફિસમાંથી અથવા VPC ની અંદરના સ્થાનિક નેટવર્કમાં ઈન્ફ્રાસ્ટ્રક્ચરના ઓન-પ્રેમ ભાગ મેળવવા માટે, તમારે IPSec અથવા સમર્પિત ચેનલ દ્વારા કનેક્શન ગોઠવવાની જરૂર છે. એક તરફ, IPSec સસ્તું છે, કારણ કે વધારાના હાર્ડવેર ખરીદવાની જરૂર નથી; તમે તમારા સર્વર વચ્ચે જાહેર સરનામા અને ક્લાઉડ સાથે ટનલ સેટ કરી શકો છો. પરંતુ - વિલંબ, મર્યાદિત પ્રદર્શન (કારણ કે ચેનલને એન્ક્રિપ્ટેડ કરવાની જરૂર છે), વત્તા ગેરેંટી વગરની કનેક્ટિવિટી (એક્સેસ નિયમિત ઇન્ટરનેટ દ્વારા છે).

શું કરવું જોઈએ?

સમર્પિત ચેનલ દ્વારા કનેક્શન વધારવું (ઉદાહરણ તરીકે, AWS તેને ડાયરેક્ટ કનેક્ટ કહે છે). આ કરવા માટે, એક ભાગીદાર ઓપરેટરને શોધો જે તમને કનેક્ટ કરશે, તમારી સૌથી નજીકના કનેક્શન પોઇન્ટ નક્કી કરશે (તમે બંને ઑપરેટર અને ઑપરેટર ક્લાઉડ પર), અને છેવટે, બધું સેટ કરો. શું નેટવર્ક એન્જિનિયર વિના આ બધું કરવું શક્ય છે? ચોક્કસ હા. પરંતુ સમસ્યાઓના કિસ્સામાં તેના વિના મુશ્કેલીનિવારણ કેવી રીતે કરવું તે હવે એટલું સ્પષ્ટ નથી.

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

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

નેટવર્કરે શું જાણવું જોઈએ?

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

વધુમાં, હકીકતમાં, નેટવર્ક્સ - જો કે અભ્યાસ માટે ફક્ત એક અનંત ક્ષેત્ર છે, પછી ભલે તમે ફક્ત એક જ ક્ષેત્ર પર ધ્યાન કેન્દ્રિત કરો (પ્રદાતા નેટવર્ક્સ, સાહસો, ડેટા કેન્દ્રો, Wi-Fi ...)

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

• લિનક્સમાં વપરાશકર્તા તરીકે કામ કરવા માટે જ નહીં, પણ ઓછામાં ઓછા sysadmin-jun સ્તરે તેનું સંચાલન કરવા માટે સક્ષમ બનો: જરૂરી સોફ્ટવેર ઇન્સ્ટોલ કરો, નિષ્ફળ સેવાને પુનઃપ્રારંભ કરો, એક સરળ systemd-unit લખો.
• લિનક્સમાં નેટવર્ક સ્ટેક કેવી રીતે કામ કરે છે, હાઇપરવાઇઝર અને કન્ટેનર (lxc/docker/kubernetes)માં નેટવર્ક કેવી રીતે કામ કરે છે તે સમજો (ઓછામાં ઓછા સામાન્ય શબ્દોમાં).
• અલબત્ત, જવાબદાર/રસોઇયા/કઠપૂતળી અથવા અન્ય SCM સિસ્ટમ સાથે કામ કરવા સક્ષમ બનો.
• ખાનગી વાદળો (ઉદાહરણ તરીકે, TungstenFabric અથવા OpenvSwitch) માટે SDN અને નેટવર્ક વિશે એક અલગ લાઇન લખવી જોઈએ. આ જ્ઞાનનું બીજું વિશાળ સ્તર છે.

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

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

તારણો, અથવા ફક્ત TL;DR

1. નેટવર્ક એડમિનિસ્ટ્રેટર (જેમ કે ડીબીએ અથવા વીઓઆઈપી એન્જિનિયર) એક સાંકડી પ્રોફાઇલ ધરાવતા નિષ્ણાત છે (સિસ્ટમ એડમિનિસ્ટ્રેટર્સ/દેવ્સ/એસઆરઇથી વિપરીત), જેની જરૂરિયાત તરત જ ઊભી થતી નથી (અને હકીકતમાં લાંબા સમય સુધી ઊભી થઈ શકતી નથી) . પરંતુ જો તે ઉદ્ભવે છે, તો તેને બહારની કુશળતા (આઉટસોર્સ અથવા સામાન્ય સામાન્ય હેતુના સંચાલકો, "જેઓ નેટવર્કનું પણ ધ્યાન રાખે છે") દ્વારા બદલવામાં આવે તેવી શક્યતા નથી. કંઈક અંશે દુઃખદ બાબત એ છે કે આવા નિષ્ણાતોની જરૂરિયાત ઓછી છે, અને, શરતી રીતે, 800 પ્રોગ્રામરો અને 30 ડેવૉપ્સ/એડમિનિસ્ટ્રેટર્સ ધરાવતી કંપનીમાં, ફક્ત બે નેટવર્કર્સ હોઈ શકે છે જેઓ તેમની જવાબદારીઓ સાથે ઉત્તમ કાર્ય કરે છે. તે. બજાર હતું અને ખૂબ જ નાનું છે, અને સારા પગાર સાથે - તેનાથી પણ ઓછું.
2. બીજી બાજુ, આધુનિક વિશ્વમાં એક સારા નેટવર્કરને માત્ર નેટવર્ક્સ જ નહીં (અને તેમનું રૂપરેખાંકન કેવી રીતે સ્વચાલિત કરવું), પણ આ નેટવર્ક્સની ટોચ પર ચાલતી ઓપરેટિંગ સિસ્ટમ્સ અને સોફ્ટવેર તેમની સાથે કેવી રીતે ક્રિયાપ્રતિક્રિયા કરે છે તે પણ જાણવું જોઈએ. આ વિના, તમારા સાથીદારો તમને શું પૂછે છે તે સમજવું અને તેમને તમારી ઇચ્છાઓ/જરૂરિયાતો (વાજબી રીતે) પહોંચાડવી અત્યંત મુશ્કેલ હશે.
3. ત્યાં કોઈ વાદળ નથી, તે ફક્ત કોઈ બીજાનું કમ્પ્યુટર છે. તમારે એ સમજવાની જરૂર છે કે સાર્વજનિક/ખાનગી ક્લાઉડ અથવા હોસ્ટિંગ પ્રદાતાની સેવાઓનો ઉપયોગ "જે તમારા માટે ટર્નકી ધોરણે બધું કરે છે" એ હકીકતને બદલતી નથી કે તમારી એપ્લિકેશન હજી પણ નેટવર્કનો ઉપયોગ કરે છે, અને તેની સાથેની સમસ્યાઓના સંચાલનને અસર કરશે. તમારી અરજી. તમારી પસંદગી એ છે કે સક્ષમતા કેન્દ્ર ક્યાં સ્થિત હશે, જે તમારા પ્રોજેક્ટના નેટવર્ક માટે જવાબદાર હશે.

સોર્સ: www.habr.com