નિષ્ફળતા: પૂર્ણતાવાદ અને... આળસ આપણને બરબાદ કરી રહી છે

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

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

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

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

શ્તોષ (c) અમે બીજી સાઇટ લઈએ છીએ, એક સરખી સિસ્ટમ બનાવીએ છીએ... જટિલતા બમણી થઈ જાય છે - અમારી પાસે બે એન્ટિટી છે. અમે એક સાઇટથી બીજી સાઇટ પર ડેટા ટ્રાન્સફર કરવા માટે ચોક્કસ તર્ક પણ રજૂ કરીએ છીએ - એટલે કે, ડેટાની નકલ કરવી, સ્ટેટિક ડેટાની નકલ કરવી વગેરે. તેથી, પ્રતિકૃતિ તર્ક સામાન્ય રીતે ખૂબ જટિલ હોય છે, અને તેથી, સિસ્ટમની કુલ જટિલતા 2 નહીં, પરંતુ 3, 5, 10 ગણી વધારે હોઈ શકે છે.

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

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

આ સમય છે “વાર્તાઓ ફ્રોમ ડબલ્યુ”... જીવનની, અલબત્ત.

ઉદાહરણ નંબર એક

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

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

ઉદાહરણ નંબર બે

કંપનીનો બ્લોગ: ખાસ પ્રશિક્ષિત લોકો ત્યાં સમાચાર લખે છે, અમે આવા અને આવા પ્રદર્શનમાં ભાગ લીધો હતો, પરંતુ અમે બીજી નવી પ્રોડક્ટ રિલીઝ કરી છે, વગેરે. ચાલો કહીએ કે આ વર્ડપ્રેસ, એક નાનો ડેટાબેઝ અને થોડો સ્થિર સાથે પ્રમાણભૂત PHP છે. અલબત્ત, તે ફરીથી મનમાં આવે છે કે તમારે કોઈ પણ સંજોગોમાં સૂવું જોઈએ નહીં - "પાંચ મિનિટથી વધુ નહીં!" બસ. પણ ચાલો આગળ વિચારીએ. આ બ્લોગ શું કરે છે? લોકો ત્યાં યાન્ડેક્ષથી, Google તરફથી કેટલીક ક્વેરીઝના આધારે, સજીવ રીતે આવે છે. મહાન. શું વેચાણને તેની સાથે કોઈ લેવાદેવા છે? એપિફેની: ખરેખર નથી. જાહેરાત ટ્રાફિક મુખ્ય સાઇટ પર જાય છે, જે અલગ મશીન પર છે. ચાલો બુકિંગ સ્કીમ વિશે વિચારવાનું શરૂ કરીએ. સારી રીતે, તેને થોડા કલાકોમાં ઉછેરવાની જરૂર છે, અને આ માટે તૈયારી કરવી સરસ રહેશે. અન્ય ડેટા સેન્ટરમાંથી મશીન લેવું, તેના પર પર્યાવરણને ફેરવવું, એટલે કે વેબ સર્વર, PHP, WordPress, MySQL, અને તેને ત્યાં છોડી દેવાનું વાજબી રહેશે. આ ક્ષણે જ્યારે આપણે સમજીએ છીએ કે બધું તૂટી ગયું છે, ત્યારે આપણે બે વસ્તુઓ કરવાની જરૂર છે - mysql ડમ્પને 50 મીટર રોલ આઉટ કરો, તે એક મિનિટમાં ત્યાં ઉડી જશે, અને ત્યાં બેકઅપમાંથી ચોક્કસ સંખ્યામાં ચિત્રો બહાર પાડશે. આ પણ નથી ભગવાન જાણે ક્યાં સુધી. આમ, અડધા કલાકમાં આખી વાત વધી જાય છે. કોઈ પ્રતિકૃતિ, અથવા ભગવાન મને માફ કરો, આપોઆપ નિષ્ફળતા. નિષ્કર્ષ: બેકઅપમાંથી આપણે જે ઝડપથી બહાર પાડી શકીએ છીએ તેનો બેકઅપ લેવાની જરૂર નથી.

ઉદાહરણ નંબર ત્રણ, વધુ જટિલ

ઑનલાઇન સ્ટોર. ખુલ્લા હૃદય સાથે પીએચપી થોડો ટ્વીક કરેલ છે, નક્કર આધાર સાથે mysql. ઘણી બધી સ્થિર (છેવટે, ઑનલાઇન સ્ટોરમાં સુંદર HD છબીઓ અને તે બધી સામગ્રી છે), સત્ર માટે Redis અને શોધ માટે Elasticsearch. અમે ડાઉનટાઇમ વિશે વિચારવાનું શરૂ કરીએ છીએ. અને અહીં, અલબત્ત, તે સ્પષ્ટ છે કે ઑનલાઇન સ્ટોર એક દિવસ માટે પીડારહિત રીતે આજુબાજુ ન બોલી શકે. છેવટે, તે જેટલો લાંબો સમય આવે છે, તેટલા વધુ પૈસા આપણે ગુમાવીએ છીએ. તે ઝડપી બનાવવા યોગ્ય છે. કેટલુ? મને લાગે છે કે જો આપણે એક કલાક સૂઈશું તો કોઈ પાગલ નહીં થાય. હા, આપણે કંઈક ગુમાવીશું, પરંતુ જો આપણે સખત મહેનત કરવાનું શરૂ કરીશું, તો તે વધુ ખરાબ થશે. અમે પ્રતિ કલાક મંજૂર ડાઉનટાઇમની સ્કીમ વ્યાખ્યાયિત કરીએ છીએ.

આ બધું કેવી રીતે અનામત રાખી શકાય? તમારે કોઈ પણ સંજોગોમાં કારની જરૂર છે: સમયનો એક કલાક ઘણો ઓછો છે. Mysql: અહીં આપણને પહેલાથી જ પ્રતિકૃતિ, જીવંત પ્રતિકૃતિની જરૂર છે, કારણ કે એક કલાકમાં 100 GB મોટાભાગે ડમ્પમાં ઉમેરવામાં આવશે નહીં. સ્ટેટિક્સ, ચિત્રો: ફરીથી, એક કલાકમાં 500 GB ઉમેરવાનો સમય નથી. તેથી, તરત જ ચિત્રોની નકલ કરવી વધુ સારું છે. રેડિસ: આ તે છે જ્યાં વસ્તુઓ રસપ્રદ બને છે. રેડિસમાં, સત્રો સંગ્રહિત થાય છે - અમે તેને લઈ શકતા નથી અને તેને દફનાવી શકતા નથી. કારણ કે આ ખૂબ સારું રહેશે નહીં: બધા વપરાશકર્તાઓ લૉગ આઉટ થઈ જશે, તેમની બાસ્કેટ ખાલી કરવામાં આવશે, વગેરે. લોકોને તેમના વપરાશકર્તાનામ અને પાસવર્ડ ફરીથી દાખલ કરવાની ફરજ પાડવામાં આવશે, અને ઘણા લોકો છૂટા પડી શકે છે અને ખરીદી પૂર્ણ કરી શકશે નહીં. ફરીથી, રૂપાંતરણો ઘટશે. બીજી તરફ, Redis સીધું જ અદ્યતન છે, છેલ્લા લોગ-ઇન થયેલા વપરાશકર્તાઓને કદાચ પણ જરૂર નથી. અને સારી સમજૂતી એ છે કે રેડિસ લો અને તેને ગઈકાલથી બેકઅપમાંથી પુનઃસ્થાપિત કરો, અથવા, જો તમે દર કલાકે કરો છો, તો એક કલાક પહેલાથી. સદનસીબે, તેને બેકઅપમાંથી પુનઃસ્થાપિત કરવાનો અર્થ એ છે કે એક ફાઇલની નકલ કરવી. અને સૌથી રસપ્રદ વાર્તા Elasticsearch છે. કોણે ક્યારેય MySQL પ્રતિકૃતિ પસંદ કરી છે? કોણે ક્યારેય Elasticsearch પ્રતિકૃતિ પસંદ કરી છે? અને તે કોના માટે સામાન્ય રીતે પછી કામ કરતું હતું? મારો કહેવાનો અર્થ એ છે કે આપણે આપણી સિસ્ટમમાં ચોક્કસ એન્ટિટી જોઈએ છીએ. તે ઉપયોગી લાગે છે - પરંતુ તે જટિલ છે.
જટિલ અર્થમાં કે અમારા સાથી ઇજનેરોને તેની સાથે કામ કરવાનો અનુભવ નથી. અથવા નકારાત્મક અનુભવ છે. અથવા અમે સમજીએ છીએ કે આ હજી પણ ઘોંઘાટ અથવા અછત સાથે એકદમ નવી તકનીક છે. અમને લાગે છે કે... અરે, સ્થિતિસ્થાપક પણ તંદુરસ્ત છે, તેને બેકઅપમાંથી પુનઃસ્થાપિત કરવામાં પણ ઘણો સમય લાગે છે, મારે શું કરવું જોઈએ? અમે સમજીએ છીએ કે અમારા કિસ્સામાં સ્થિતિસ્થાપકનો ઉપયોગ શોધ માટે થાય છે. અમારું ઑનલાઇન સ્ટોર કેવી રીતે વેચે છે? અમે માર્કેટર્સ પાસે જઈએ છીએ અને પૂછીએ છીએ કે લોકો ક્યાંથી આવે છે. તેઓ જવાબ આપે છે: "યાન્ડેક્ષ માર્કેટમાંથી 90% સીધા ઉત્પાદન કાર્ડ પર આવે છે." અને કાં તો તેઓ તેને ખરીદે છે અથવા તેઓ નથી કરતા. તેથી, 10% વપરાશકર્તાઓ દ્વારા શોધની જરૂર છે. અને સ્થિતિસ્થાપક પ્રતિકૃતિ રાખવા, ખાસ કરીને વિવિધ ઝોનમાં વિવિધ ડેટા કેન્દ્રો વચ્ચે, ખરેખર ઘણી ઘોંઘાટ છે. કઈ બહાર નીકળો? અમે આરક્ષિત સાઇટ પરથી સ્થિતિસ્થાપક લઈએ છીએ અને તેની સાથે કંઈ કરતા નથી. જો મામલો આગળ વધે છે, તો અમે કદાચ કોઈ દિવસ તેને ઉઠાવીશું, પરંતુ આ ચોક્કસ નથી. વાસ્તવમાં, નિષ્કર્ષ એ જ છે, વત્તા અથવા ઓછા: અમે, ફરીથી, એવી સેવાઓ અનામત રાખતા નથી જે નાણાંને અસર કરતી નથી. આકૃતિને સરળ રાખવા માટે.

ઉદાહરણ નંબર ચાર, વધુ મુશ્કેલ

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

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

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

ઉદાહરણ નંબર પાંચ, સંપૂર્ણ હાર્ડકોર

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

શું ખૂટે છે? એક - કસરતો. તેમના વિના તે અશક્ય છે. એવું લાગે છે કે અમારી સાથે બધું સંપૂર્ણ છે, અમારી પાસે સામાન્ય રીતે બધું નિયંત્રણમાં છે. અમે બટન દબાવો, બધું થાય છે. જો આવું હોય તો પણ - અને અમે સમજીએ છીએ કે તે આ રીતે થતું નથી - અમારી સિસ્ટમ કેટલીક અન્ય સિસ્ટમો સાથે ક્રિયાપ્રતિક્રિયા કરે છે. ઉદાહરણ તરીકે, આ રૂટ 53, s3 સ્ટોરેજ, અમુક api સાથે એકીકરણથી dns છે. અમે આ સટ્ટાકીય પ્રયોગમાં દરેક વસ્તુની આગાહી કરી શકીશું નહીં. અને જ્યાં સુધી આપણે વાસ્તવમાં સ્વીચ ખેંચીશું નહીં, ત્યાં સુધી તે કામ કરશે કે નહીં તે આપણને ખબર નથી.

તે કદાચ બધુ જ છે. આળસુ ન બનો અથવા તેને વધુ પડતું ન કરો. અને અપટાઇમ તમારી સાથે હોઈ શકે છે!

સોર્સ: www.habr.com