કેઓસ એન્જિનિયરિંગ: ઇરાદાપૂર્વક વિનાશની કળા. ભાગ 2

નૉૅધ. અનુવાદ: આ લેખ AWS ટેક્નોલોજી પ્રચારક એડ્રિયન હોર્ન્સબીના લેખોની એક મહાન શ્રેણી ચાલુ રાખે છે, જે IT સિસ્ટમ્સમાં નિષ્ફળતાના પરિણામોને ઘટાડવા માટે પ્રયોગના મહત્વને સરળ અને સ્પષ્ટ રીતે સમજાવે છે.

"જો તમે કોઈ યોજના તૈયાર કરવામાં નિષ્ફળ જાઓ છો, તો તમે નિષ્ફળ થવાની યોજના બનાવો છો." - બેન્જામિન ફ્રેન્કલિન

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

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

મહાન પ્રશ્ન! જો કે, તે આ પાંડાથી ખાસ પરેશાન હોય તેવું લાગતું નથી...

અરાજકતા પાંડા સાથે ગડબડ કરશો નહીં!

ટૂંકો જવાબ: વિનંતિના માર્ગ પર નિર્ણાયક સેવાઓને લક્ષ્યાંકિત કરો.

લાંબો પરંતુ સ્પષ્ટ જવાબઅરાજકતા સાથે પ્રયોગ ક્યાંથી શરૂ કરવો તે સમજવા માટે, ત્રણ ક્ષેત્રો પર ધ્યાન આપો:

1. જુઓ ક્રેશ ઇતિહાસ અને પેટર્ન ઓળખો;
2. નક્કી કરો નિર્ણાયક અવલંબન;
3. કહેવાતા ઉપયોગ કરો અતિવિશ્વાસની અસર.

તે રમુજી છે, પરંતુ આ ભાગને સરળતાથી કહી શકાય "સ્વ-શોધ અને જ્ઞાનની સફર". તેમાં આપણે કેટલાક શાનદાર વાદ્યો વડે "વગાડવાનું" શરૂ કરીશું.

1. જવાબ ભૂતકાળમાં રહેલો છે

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

"વર્તમાનને સમજવા માટે, તમારે ભૂતકાળને જાણવાની જરૂર છે." - કાર્લ સાગન

નિષ્ફળતાઓનો ઇતિહાસ જુઓ, તેમને COE અથવા પોસ્ટમોર્ટમમાં ટેગ કરો અને તેનું વર્ગીકરણ કરો. સામાન્ય પેટર્નને ઓળખો જે ઘણીવાર સમસ્યાઓ તરફ દોરી જાય છે, અને દરેક COE માટે, તમારી જાતને નીચેનો પ્રશ્ન પૂછો:

"શું આની આગાહી કરી શકાઈ હોત અને તેથી ફોલ્ટ ઈન્જેક્શન દ્વારા અટકાવી શકાય છે?"

મને મારી કારકિર્દીની શરૂઆતમાં એક નિષ્ફળતા યાદ છે. જો અમે થોડા સરળ અરાજકતા પ્રયોગો હાથ ધર્યા હોત તો તેને સરળતાથી અટકાવી શકાયું હોત:

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

જો કે, થોડા સમય માટે બધું બરાબર હતું.

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

અચાનક, અન્ય તમામ દાખલાઓ પણ આરોગ્ય તપાસમાં નિષ્ફળ થવા લાગ્યા.

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

પછી અમે કાયમ નીચેના મુદ્દાઓને સમજી શક્યા:

• નવો દાખલો બનાવતી વખતે સૉફ્ટવેર ઇન્સ્ટોલ કરવામાં લાંબો સમય લાગે છે અને અપરિવર્તનશીલ અભિગમને પ્રાધાન્ય આપવું વધુ સારું છે ગોલ્ડન AMI.
• મુશ્કેલ પરિસ્થિતિઓમાં, આરોગ્ય-તપાસ અને ELBs માટેના પ્રતિસાદોને પ્રાથમિકતા આપવી જોઈએ - બાકીના કિસ્સાઓમાં જીવનને જટિલ બનાવવાની છેલ્લી વસ્તુ તમે ઇચ્છો છો.
• આરોગ્ય તપાસની સ્થાનિક કેશીંગ ઘણી મદદ કરે છે (થોડી સેકંડ માટે પણ).
• મુશ્કેલ પરિસ્થિતિમાં, ક્રોન કાર્યો અને અન્ય બિન-જટિલ પ્રક્રિયાઓ ચલાવશો નહીં - સૌથી મહત્વપૂર્ણ કાર્યો માટે સંસાધનો બચાવો.
• ઑટોસ્કેલિંગ કરતી વખતે, નાના ઉદાહરણોનો ઉપયોગ કરો. 10 નાના નમુનાઓનું જૂથ 4 મોટાના જૂથ કરતાં વધુ સારું છે; જો એક ઉદાહરણ નિષ્ફળ જાય, તો પ્રથમ કિસ્સામાં 10% ટ્રાફિક 9 પોઈન્ટ પર વિતરિત કરવામાં આવશે, બીજામાં - 25% ટ્રાફિક ત્રણ પોઈન્ટથી વધુ.

અને તેથી, શું આની આગાહી કરી શકાઈ હોત, અને તેથી સમસ્યા રજૂ કરીને અટકાવી શકાય?

હા, અને ઘણી રીતે.

પ્રથમ, જેમ કે સાધનોનો ઉપયોગ કરીને ઉચ્ચ CPU વપરાશનું અનુકરણ કરીને stress-ng અથવા cpuburn:

❯ stress-ng --matrix 1 -t 60s

તણાવ-એનજી

બીજું, સાથેના ઉદાહરણને ઓવરલોડ કરીને wrk અને અન્ય સમાન ઉપયોગિતાઓ:

❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health

પ્રયોગો પ્રમાણમાં સરળ છે, પરંતુ વાસ્તવિક નિષ્ફળતાના તણાવમાંથી પસાર થયા વિના વિચાર માટે થોડો સારો ખોરાક આપી શકે છે.

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

શું તે એક સ્વપ્ન હતું, અથવા તે ખરેખર બન્યું હતું?

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

પછી સૌથી મોટી શ્રેણી સાથે સૌથી સામાન્ય પેટર્ન પર સ્વિચ કરો.

2. નિર્ભરતા નકશો બનાવો

તમારી અરજી વિશે વિચારવા માટે થોડો સમય ફાળવો. શું તેની નિર્ભરતાનો સ્પષ્ટ નકશો છે? શું તમે જાણો છો કે નિષ્ફળતા મળે તો તેમની શું અસર થશે?

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

નિર્ભરતાને ઓળખવા અને દસ્તાવેજીકરણને "નિર્ભરતા નકશો બનાવવો» (નિર્ભરતા મેપિંગ). આ સામાન્ય રીતે કોડ પ્રોફાઇલિંગ ટૂલ્સનો ઉપયોગ કરીને મોટા કોડ બેઝ ધરાવતી એપ્લિકેશનો માટે કરવામાં આવે છે. (કોડ પ્રોફાઇલિંગ) અને ઇન્સ્ટ્રુમેન્ટેશન (ઇન્સ્ટ્રુમેન્ટેશન). તમે નેટવર્ક ટ્રાફિકનું નિરીક્ષણ કરીને નકશો પણ બનાવી શકો છો.

જો કે, બધી અવલંબન સમાન હોતી નથી (જે પ્રક્રિયાને વધુ જટિલ બનાવે છે). કેટલાક જટિલ, અન્ય - ગૌણ (ઓછામાં ઓછા સૈદ્ધાંતિક રીતે, કારણ કે ક્રેશ ઘણીવાર નિર્ભરતાની સમસ્યાઓને કારણે થાય છે જેને બિન-નિર્ણાયક માનવામાં આવતી હતી).

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

બધા API માં જઈને પ્રારંભ કરો. સૌથી વધુ હાઇલાઇટ કરો નોંધપાત્ર અને નિર્ણાયક. લો નિર્ભરતા કોડ રીપોઝીટરીમાંથી, તેને તપાસો કનેક્શન લોગ, પછી જુઓ દસ્તાવેજીકરણ (અલબત્ત, જો તે અસ્તિત્વમાં છે - અન્યથા તમારી પાસે હજી પણ છેоમોટી સમસ્યાઓ). માટે સાધનોનો ઉપયોગ કરો પ્રોફાઇલિંગ અને ટ્રેસિંગ, બાહ્ય કૉલ્સને ફિલ્ટર કરો.

તમે જેવા પ્રોગ્રામ્સનો ઉપયોગ કરી શકો છો netstat - કમાન્ડ લાઇન યુટિલિટી કે જે સિસ્ટમમાં તમામ નેટવર્ક કનેક્શન્સ (સક્રિય સોકેટ્સ) ની યાદી દર્શાવે છે. ઉદાહરણ તરીકે, બધા વર્તમાન કનેક્શન્સને સૂચિબદ્ધ કરવા માટે, ટાઇપ કરો:

❯ netstat -a | more 

AWS માં તમે ઉપયોગ કરી શકો છો પ્રવાહ લોગ (ફ્લો લૉગ્સ) VPC એ એક પદ્ધતિ છે જે તમને VPCમાં નેટવર્ક ઇન્ટરફેસ પર અથવા તેના પરથી જતા IP ટ્રાફિક વિશેની માહિતી એકત્રિત કરવાની મંજૂરી આપે છે. આવા લૉગ્સ અન્ય કાર્યોમાં પણ મદદ કરી શકે છે - ઉદાહરણ તરીકે, ચોક્કસ ટ્રાફિક દાખલા સુધી કેમ પહોંચતો નથી તે પ્રશ્નનો જવાબ શોધવા.

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

AWS એક્સ-રે કન્સોલ

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

ઘણી એપ્લિકેશનો નિર્ભરતા સાથે જોડાવા માટે DNS નો ઉપયોગ કરે છે, જ્યારે અન્ય સેવા શોધ અથવા તો રૂપરેખાંકન ફાઇલોમાં હાર્ડ-કોડેડ IP સરનામાંનો ઉપયોગ કરી શકે છે (દા.ત. /etc/hosts).

ઉદાહરણ તરીકે, તમે બનાવી શકો છો DNS બ્લેકહોલ ની મદદ સાથે iptables અને જુઓ શું તૂટે છે. આ કરવા માટે, નીચેનો આદેશ દાખલ કરો:

❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"

DNS બ્લેક હોલ

જો અંદર /etc/hosts અથવા અન્ય રૂપરેખાંકન ફાઇલો, તમને એવા IP સરનામાંઓ મળશે કે જેના વિશે તમે કશું જાણતા નથી (હા, કમનસીબે, આવું પણ થાય છે), તમે ફરીથી બચાવમાં આવી શકો છો iptables. ચાલો કહીએ કે તમે શોધ્યું 8.8.8.8 અને ખબર નથી કે આ Google નું સાર્વજનિક DNS સર્વર સરનામું છે. ઉપયોગ કરીને iptables તમે નીચેના આદેશોનો ઉપયોગ કરીને આ સરનામાં પર આવતા અને જતા ટ્રાફિકને અવરોધિત કરી શકો છો:

❯ iptables -A INPUT -s 8.8.8.8 -j DROP -m comment --comment "Reject from 8.8.8.8"
❯ iptables -A OUTPUT -d 8.8.8.8 -j DROP -m comment --comment "Reject to 8.8.8.8"

ઍક્સેસ બંધ કરી રહ્યા છીએ

પહેલો નિયમ Google ના સાર્વજનિક DNS માંથી તમામ પેકેટો છોડી દે છે: ping કામ કરે છે, પરંતુ પેકેટ પરત કરવામાં આવતા નથી. બીજો નિયમ તમારી સિસ્ટમમાંથી ઉદ્ભવતા તમામ પેકેટોને Google ના સાર્વજનિક DNS તરફ ડ્રોપ કરે છે - જવાબમાં ping અમે મેળવીએ છીએ ઓપરેશનની પરવાનગી નથી.

નોંધ: આ ચોક્કસ કિસ્સામાં તેનો ઉપયોગ કરવો વધુ સારું રહેશે whois 8.8.8.8, પરંતુ આ માત્ર એક ઉદાહરણ છે.

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

જો તમે લાલ ગોળી લો છો, તો તમે વન્ડરલેન્ડમાં જ રહો છો, અને હું તમને બતાવીશ કે સસલાના છિદ્ર કેટલા ઊંડે જાય છે."

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

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

પરિણામ, જોકે, અત્યંત રસપ્રદ અને ઉપયોગી છે. તમે તમારી સિસ્ટમ, તેની નિર્ભરતા અને કામગીરી વિશે ઘણું શીખી શકશો. ફરીથી, ધીરજ રાખો: તે જ પ્રવાસ છે જે સૌથી મહત્વપૂર્ણ છે.

3. વધુ પડતા આત્મવિશ્વાસથી સાવધ રહો

"જે કોઈ સ્વપ્ન જુએ છે, તે તેનામાં વિશ્વાસ કરે છે." - ડેમોસ્થેનિસ

શું તમે ક્યારેય સાંભળ્યું છે અતિવિશ્વાસની અસર?

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

વૃત્તિ અને અનુભવના આધારે...

મારા અનુભવ પરથી, હું કહી શકું છું કે આ વિકૃતિ એ અરાજકતા એન્જિનિયરિંગથી ક્યાંથી શરૂઆત કરવી તે એક મહાન સંકેત છે.

વધુ પડતા આત્મવિશ્વાસવાળા ઓપરેટરથી સાવધ રહો:

ચાર્લી: "આ વસ્તુ પાંચ વર્ષમાં ઘટી નથી, બધું સારું છે!"
ક્રેશ: "રાહ જુઓ... હું ટૂંક સમયમાં ત્યાં આવીશ!"

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

સારાંશ

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

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

અનુવાદક તરફથી પીએસ

અમારા બ્લોગ પર પણ વાંચો:

• «કેઓસ એન્જિનિયરિંગ: ઇરાદાપૂર્વક વિનાશની કળા. ભાગ 1»;
• «કુબરનેટ્સમાં ઉચ્ચ ઉપલબ્ધતા કેવી રીતે પ્રાપ્ત કરવી»;
• «મોનિટરિંગ અને કુબરનેટ્સ (સમીક્ષા અને વિડિયો રિપોર્ટ)»;
• «Kubernetes માં kube-proxy અને નોડની અનુપલબ્ધતા સાથે પ્રયોગ».

સોર્સ: www.habr.com