HighLoad++, Evgeniy Kuzovlev (EcommPay IT): જ્યારે ડાઉનટાઇમની એક મિનિટનો ખર્ચ $100000 થાય ત્યારે શું કરવું

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

આગામી હાઇલોડ++ કોન્ફરન્સ 6 અને 7 એપ્રિલ, 2020ના રોજ સેન્ટ પીટર્સબર્ગમાં યોજાશે. માટે વિગતો અને ટિકિટો કડી. નવેમ્બર 9, 18:00. હાઇલોડ++ મોસ્કો 2018, દિલ્હી + કોલકાતા હોલ. થીસીસ અને પ્રસ્તુતિ.

એવજેની કુઝોવલેવ (ત્યારબાદ - EC): - મિત્રો, હેલો! મારું નામ કુઝોવલેવ એવજેની છે. હું EcommPay કંપનીમાંથી છું, એક વિશિષ્ટ વિભાગ EcommPay IT છે, જે કંપનીઓના જૂથનો IT વિભાગ છે. અને આજે આપણે ડાઉનટાઇમ્સ વિશે વાત કરીશું - તેમને કેવી રીતે ટાળવું, જો તે ટાળી ન શકાય તો તેના પરિણામોને કેવી રીતે ઘટાડવું તે વિશે. વિષય નીચે મુજબ જણાવવામાં આવ્યો છે: "જ્યારે ડાઉનટાઇમની એક મિનિટનો ખર્ચ $100 થાય ત્યારે શું કરવું"? આગળ જોતાં, અમારી સંખ્યા તુલનાત્મક છે.

EcommPay IT શું કરે છે?

આપણે કોણ છીએ? હું અહીં તારી સામે કેમ ઊભો છું? મને અહીં તમને કંઈક કહેવાનો અધિકાર કેમ છે? અને આપણે અહીં વધુ વિગતમાં શું વાત કરીશું?

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

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

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

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

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

ડાઉનટાઇમ્સ. ઓપરેશનના આદેશો.

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

જ્યારે અમે અમારા અભિગમો બદલવાનું શરૂ કર્યું, ત્યારે અમે 4 કમાન્ડમેન્ટ્સની રચના કરી. મેં તેમને સ્લાઇડ્સ પર રજૂ કર્યા છે:

આ આદેશો એકદમ સરળ છે:

• સમસ્યાને ઝડપથી ઓળખો.
• તેનાથી પણ ઝડપથી છુટકારો મેળવો.
• કારણ સમજવામાં મદદ કરો (પછીથી, વિકાસકર્તાઓ માટે).
• અને અભિગમોને પ્રમાણિત કરો.

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

મુશ્કેલીનિવારણ: તેઓ ક્યારે થાય છે અને તેમના વિશે શું કરવું?

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

આ આવશ્યકતાઓ ઘડવા માટે, અમે પોતાને પ્રશ્ન પૂછવાનું નક્કી કર્યું: "અમને ક્યારે સમસ્યાઓ આવે છે"? અને સમસ્યાઓ, જેમ તે બહાર આવ્યું છે, ચાર કિસ્સાઓમાં થાય છે:

• હાર્ડવેર નિષ્ફળતા.
• બાહ્ય સેવાઓ નિષ્ફળ.
• સૉફ્ટવેર સંસ્કરણ બદલવું (સમાન જમાવટ).
• વિસ્ફોટક લોડ વૃદ્ધિ.

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

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

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

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

આ ચાર સમસ્યાઓમાંથી, જો તમારી પાસે વાદળ હોય તો ઘણી સમસ્યાઓ તરત જ ઉકેલાઈ જાય છે. જો તમે Microsoft Azhur, Ozone ક્લાઉડ્સમાં છો, અથવા Yandex અથવા Mailમાંથી અમારા ક્લાઉડનો ઉપયોગ કરો છો, તો ઓછામાં ઓછી હાર્ડવેરની ખામી તેમની સમસ્યા બની જાય છે અને હાર્ડવેરની ખામીના સંદર્ભમાં તમારા માટે તરત જ બધું ઠીક થઈ જાય છે.

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

સૉફ્ટવેર સંસ્કરણ બદલવું. પાયા

અમારા વિકાસકર્તાઓને ઉત્પાદનની ઍક્સેસ નથી. તે શા માટે છે? તે માત્ર એટલું જ છે કે અમે PCI DSS પ્રમાણિત છીએ, અને અમારા વિકાસકર્તાઓને ફક્ત "ઉત્પાદન" માં પ્રવેશવાનો અધિકાર નથી. બસ, સમયગાળો. બધા પર. તેથી, વિકાસની જવાબદારી બરાબર તે જ ક્ષણે સમાપ્ત થાય છે જ્યારે વિકાસ પ્રકાશન માટે બિલ્ડ સબમિટ કરે છે.

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

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

સૉફ્ટવેર સંસ્કરણ બદલવા માટેની આવશ્યકતાઓ

ત્યાં ત્રણ આવશ્યકતાઓ છે:

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

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

  અહીં બીજા પ્રશ્નનો ઉકેલ લઘુત્તમીકરણ છે: તમે તમારા ટ્રાફિકનો માત્ર એક ભાગ જ નવી લાઇન પર, નવા કોડવાળી લાઇન પર મોકલી શકો છો (ઉદાહરણ તરીકે, 2% રહેવા દો). અને આ 2% 100% નથી! જો તમે અસફળ જમાવટને કારણે તમારો 100% ટ્રાફિક ગુમાવ્યો હોય, તો તે ડરામણી છે; જો તમે તમારો 2% ટ્રાફિક ગુમાવો છો, તો તે અપ્રિય છે, પરંતુ તે ડરામણી નથી. તદુપરાંત, વપરાશકર્તાઓ મોટે ભાગે આની નોંધ લેશે નહીં, કારણ કે કેટલાક કિસ્સાઓમાં (બધામાં નહીં) સમાન વપરાશકર્તા, F5 દબાવવાથી, બીજા, કાર્યકારી સંસ્કરણ પર લઈ જવામાં આવશે.

  વાદળી/લીલો જમાવટ. રૂટીંગ

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

  • આ અગ્રભાગ છે (ચુકવણી પૃષ્ઠો જે અમારા ગ્રાહકો જુએ છે);
  • પ્રોસેસિંગ કોર;
  • પેમેન્ટ સિસ્ટમ્સ સાથે કામ કરવા માટે એડેપ્ટર (બેંક, માસ્ટરકાર્ડ, વિઝા...).

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

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

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

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

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

  તેથી, અમે ચોથા વિકલ્પ પર આવ્યા. અમે સ્ટેરોઇડ્સ પર nginx લીધો (આ ઓપનરેસ્ટી છે) - આ તે જ nginx છે, જે વધુમાં છેલ્લી સ્ક્રિપ્ટોના સમાવેશને સમર્થન આપે છે. તમે છેલ્લી સ્ક્રિપ્ટ લખી શકો છો, તેને "ઓપન રેસ્ટ" આપી શકો છો, અને જ્યારે વપરાશકર્તા વિનંતી આવશે ત્યારે આ છેલ્લી સ્ક્રિપ્ટ એક્ઝિક્યુટ કરવામાં આવશે.

  અને અમે, વાસ્તવમાં, આવી સ્ક્રિપ્ટ લખી, આપણી જાતને "ઓપનરેસ્ટી" સેટ કરી અને આ સ્ક્રિપ્ટમાં આપણે "અથવા" જોડાણ દ્વારા 6 જુદા જુદા પરિમાણો દ્વારા સૉર્ટ કરીએ છીએ. એક અથવા બીજા પરિમાણની હાજરીના આધારે, આપણે જાણીએ છીએ કે વપરાશકર્તા એક અથવા બીજા પૃષ્ઠ પર, એક અથવા બીજી લાઇન પર આવ્યો છે.

  વાદળી/લીલો જમાવટ. ફાયદાઓ અને ગેરફાયદાઓ

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

  
  
  તેથી, આ અમારા માટે કામ કરતું નથી - અમે ઓપનરેસ્ટી કર્યું. તદનુસાર, રૂટીંગ સાથે અમને આના જેવું કંઈક મળ્યું:

  બ્લુ/ગ્રીન ડિપ્લોયમેન્ટમાં, તે મુજબ, મેં ઉલ્લેખ કરેલા ફાયદા અને ગેરફાયદા છે.

  બે ગેરફાયદા:

  • તમારે રૂટીંગ સાથે પરેશાન કરવાની જરૂર છે;
  • બીજો મુખ્ય ગેરલાભ એ ખર્ચ છે.

  તમારે બમણા સર્વર્સની જરૂર છે, તમારે બમણા ઓપરેશનલ સંસાધનોની જરૂર છે, તમારે આ સમગ્ર પ્રાણી સંગ્રહાલયને જાળવવા માટે બમણા પ્રયત્નો ખર્ચવાની જરૂર છે.

  માર્ગ દ્વારા, ફાયદાઓમાં એક બીજી વસ્તુ છે જેનો મેં પહેલાં ઉલ્લેખ કર્યો નથી: લોડ વૃદ્ધિના કિસ્સામાં તમારી પાસે અનામત છે. જો તમારી પાસે લોડમાં વિસ્ફોટક વૃદ્ધિ છે, તો તમારી પાસે મોટી સંખ્યામાં વપરાશકર્તાઓ છે, તો પછી તમે ફક્ત 50 થી 50 વિતરણમાં બીજી લાઇન શામેલ કરો છો - અને જ્યાં સુધી તમે વધુ સર્વર્સ રાખવાની સમસ્યાને હલ ન કરો ત્યાં સુધી તમારી પાસે તરત જ તમારા ક્લસ્ટરમાં x2 સર્વર્સ હશે.

  ઝડપી જમાવટ કેવી રીતે કરવી?

  અમે ન્યૂનાઇઝેશન અને ઝડપી રોલબેકની સમસ્યાને કેવી રીતે હલ કરવી તે વિશે વાત કરી, પરંતુ પ્રશ્ન રહે છે: "ઝડપથી કેવી રીતે જમાવટ કરવી?"

  
  
  તે અહીં ટૂંકું અને સરળ છે.

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

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

  વિસ્ફોટક લોડ વૃદ્ધિ

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

  અમે એક નવી સિસ્ટમ લખી છે - તે સેવા લક્ષી, ફેશનેબલ, સુંદર, દરેક જગ્યાએ કામદારો, દરેક જગ્યાએ કતારો, દરેક જગ્યાએ અસુમેળ છે. અને આવી પ્રણાલીઓમાં, ડેટા વિવિધ પ્રવાહો દ્વારા વહી શકે છે. પ્રથમ વ્યવહાર માટે, 1લા, 3જા, 10મા કાર્યકરનો ઉપયોગ કરી શકાય છે, બીજા વ્યવહાર માટે - 2જી, 4ઠ્ઠી, 5મી. અને આજે, ચાલો કહીએ કે, સવારે તમારી પાસે ડેટા ફ્લો છે જે પ્રથમ ત્રણ કામદારોનો ઉપયોગ કરે છે, અને સાંજે તે નાટકીય રીતે બદલાય છે, અને દરેક વસ્તુ અન્ય ત્રણ કામદારોનો ઉપયોગ કરે છે.

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

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

  આ આપણા માટે શા માટે સમસ્યા છે? ચાલો થોડો પાછળ જઈએ. અમારી પાસે હવે લગભગ 70 પેમેન્ટ સિસ્ટમ્સ છે. સવારે, ટ્રાફિક Sberbank મારફતે જાય છે, પછી Sberbank પડી, ઉદાહરણ તરીકે, અને અમે તેને બીજી ચુકવણી સિસ્ટમ પર સ્વિચ કરીએ છીએ. Sberbank પહેલાં અમારી પાસે 100 કામદારો હતા, અને તે પછી અમારે બીજી ચુકવણી સિસ્ટમ માટે 100 કામદારોને ઝડપથી વધારવાની જરૂર છે. અને તે ઇચ્છનીય છે કે આ બધું માનવ ભાગીદારી વિના થાય. કારણ કે જો માનવીય ભાગીદારી હોય, તો ત્યાં 24/7 એક એન્જિનિયર બેઠો હોવો જોઈએ, જેણે ફક્ત આ કરવું જોઈએ, કારણ કે આવી નિષ્ફળતાઓ, જ્યારે 70 સિસ્ટમ તમારી પાછળ હોય છે, તે નિયમિતપણે થાય છે.

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

  અત્યાર સુધી અમે તેને ઓપન સોર્સ કર્યો નથી, પરંતુ જો રિપોર્ટ પછી અચાનક ખબર પડી કે તમને આવી વસ્તુની જરૂર છે, તમારે તેની જરૂર છે, મારા સંપર્કો છેલ્લી સ્લાઇડમાં છે - કૃપા કરીને મને લખો. જો ત્યાં ઓછામાં ઓછા 3-5 લોકો હશે, તો અમે તેને સ્પોન્સર કરીશું.

  
  
  તે કેવી રીતે કામ કરે છે? ચાલો એક નજર કરીએ! આગળ જોઈએ છીએ: ડાબી બાજુએ અમારા મોનિટરિંગનો એક ભાગ છે: આ એક લાઇન છે, ટોચ પર ઇવેન્ટ પ્રોસેસિંગનો સમય છે, મધ્યમાં વ્યવહારોની સંખ્યા છે, નીચે કામદારોની સંખ્યા છે.

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

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

  મોનીટરીંગ. સમસ્યાને ઝડપથી કેવી રીતે ઓળખવી?

  હવે પ્રથમ મુદ્દો એ છે કે "સમસ્યાને ઝડપથી કેવી રીતે ઓળખવી?" મોનીટરીંગ! આપણે અમુક બાબતો ઝડપથી સમજવી જોઈએ. આપણે કઈ બાબતો ઝડપથી સમજવી જોઈએ?

  
  
  ત્રણ વસ્તુઓ!

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

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

  
  
  અમે હાર્ડવેરને મોનિટર કરવા, સર્વરના મુખ્ય સૂચકાંકોને મોનિટર કરવા માટે Zabbix નો ઉપયોગ કરીએ છીએ. અમે ડેટાબેસેસ માટે ઓકમીટરનો ઉપયોગ કરીએ છીએ. અમે બીજા બધા સૂચકાંકો માટે “Grafana” અને “Prometheus” નો ઉપયોગ કરીએ છીએ જે પહેલા બે સાથે બંધબેસતા નથી, કેટલાક “Grafana” અને “Prometheus” સાથે, અને કેટલાક “Influx” અને Telegraf સાથે “Grafana”.

  એક વર્ષ પહેલા અમે ન્યૂ રેલિકનો ઉપયોગ કરવા માંગતા હતા. સરસ વસ્તુ, તે બધું કરી શકે છે. પરંતુ તે જેટલું બધું કરી શકે છે તેટલું તે ખૂબ ખર્ચાળ છે. જ્યારે અમે 1,5 હજાર સર્વર્સના વોલ્યુમમાં વધારો કર્યો, ત્યારે એક વિક્રેતા અમારી પાસે આવ્યા અને કહ્યું: "ચાલો આવતા વર્ષ માટે એક કરાર પૂર્ણ કરીએ." અમે કિંમત તરફ જોયું અને કહ્યું ના, અમે તે કરીશું નહીં. હવે અમે ન્યૂ રેલિકને છોડી રહ્યા છીએ, અમારી પાસે ન્યૂ રેલિકની દેખરેખ હેઠળ લગભગ 15 સર્વર્સ બાકી છે. કિંમત એકદમ જંગલી હોવાનું બહાર આવ્યું.

  અને ત્યાં એક સાધન છે જે આપણે જાતે અમલમાં મૂક્યું છે - આ ડીબગર છે. પહેલા તો અમે તેને “બેગર” કહીને બોલાવ્યા, પણ પછી એક અંગ્રેજી શિક્ષક ત્યાંથી પસાર થયો, તેણે ખૂબ હસ્યા અને તેનું નામ બદલીને “ડિબેગર” રાખ્યું. તે શુ છે? આ એક એવું સાધન છે જે હકીકતમાં, દરેક ઘટક પર 15-30 સેકન્ડમાં, સિસ્ટમના "બ્લેક બોક્સ" ની જેમ, ઘટકના એકંદર પ્રદર્શન પર પરીક્ષણો ચલાવે છે.

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

  દેખરેખ માટે કયા સૂચકાંકો મહત્વપૂર્ણ છે?

  આપણે મુખ્યત્વે શું મોનીટર કરીએ છીએ? અમારા માટે કયા સૂચકાંકો મહત્વપૂર્ણ છે?

  
  

  • મોરચા પર પ્રતિભાવ સમય / RPS એ ખૂબ જ મહત્વપૂર્ણ સૂચક છે. તે તરત જ જવાબ આપે છે કે તમારી સાથે કંઈક ખોટું છે.
  • બધી કતારોમાં પ્રોસેસ કરેલા સંદેશાઓની સંખ્યા.
  • કામદારોની સંખ્યા.
  • મૂળભૂત શુદ્ધતા મેટ્રિક્સ.

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

  અમારા માટે તે કેવું લાગે છે તે અમારા બોર્ડમાંથી એકનું ઉદાહરણ છે:

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

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

  
  
  ગ્રાફ અમને બતાવે છે કે ચુકવણી પ્રણાલીમાંથી એક 3 સેકન્ડમાં પ્રતિસાદ આપવાનું શરૂ કર્યું - અમને સમસ્યાઓ છે. તદુપરાંત, જ્યારે સમસ્યાઓ શરૂ થાય ત્યારે 20-30 સેકંડના અંતરાલથી આ વસ્તુ પ્રતિક્રિયા આપશે.

  અને મોનિટરિંગ ભૂલોનો ત્રીજો વર્ગ જે અસ્તિત્વમાં છે તે લોજિકલ મોનિટરિંગ છે.

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

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

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

  આ સમસ્યાને ઝડપથી કેવી રીતે ઓળખવી તે વિશે હતું.

  જમાવટના કારણો કેવી રીતે નક્કી કરવા

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

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

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

  અમે એક વર્ષ પહેલાં આ વિચાર્યું, બજાર તરફ અમારું ધ્યાન દોર્યું, અને ત્યાં બે સાધનો હતા - “ઝિપકીન” અને “જેગર”. "જેગર" હકીકતમાં આવા વૈચારિક વારસદાર છે, "ઝિપકીન" ના વૈચારિક અનુગામી. Zipkin માં બધું સારું છે, સિવાય કે તે જાણતું નથી કે કેવી રીતે એકત્ર કરવું, તે જાણતું નથી કે ટ્રેસમાં લૉગ્સ કેવી રીતે શામેલ કરવા, ફક્ત સમય ટ્રેસ. અને "જેગર" એ આને સમર્થન આપ્યું.

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

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

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

  તદનુસાર, વસ્તુઓ અમારા માટે સારી હતી. અમે અમારું પોતાનું એક્સ્ટેંશન લખ્યું અને અમે તેને ઓપન સોર્સ કર્યું. જો તમે ટ્રેસિંગ સાથે કામ કરવા માંગતા હો, જો તમે PHP માં "જેગર" સાથે કામ કરવા માંગતા હો, તો અમારું એક્સ્ટેંશન છે, ઉપયોગ કરવા માટે આપનું સ્વાગત છે, જેમ કે તેઓ કહે છે:

  
  
  અમારી પાસે આ એક્સ્ટેંશન છે - તે OpenTracing Api માટે ક્લાયંટ છે, તે php-extention તરીકે બનાવવામાં આવ્યું છે, એટલે કે, તમારે તેને એસેમ્બલ કરવાની અને તેને સિસ્ટમ પર ઇન્સ્ટોલ કરવાની જરૂર પડશે. એક વર્ષ પહેલાં કંઈ અલગ નહોતું. હવે એવા અન્ય ગ્રાહકો છે જે ઘટકો જેવા છે. અહીં તે તમારા પર નિર્ભર છે: કાં તો તમે કંપોઝર સાથે ઘટકોને બહાર કાઢો છો, અથવા તમે તમારા સુધીના એક્સ્ટેંશનનો ઉપયોગ કરો છો.

  કોર્પોરેટ ધોરણો

  અમે ત્રણ આજ્ઞાઓ વિશે વાત કરી. ચોથો આદેશ અભિગમોને પ્રમાણિત કરવાનો છે. આ શું છે? તે આ વિશે છે:

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

  
  

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

  ડાઉનટાઇમ શું ગણવામાં આવે છે?

  
  
  આ બધું શું તરફ દોરી ગયું?

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

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

  બસ એટલું જ! તમારા પ્રશ્નો.

  
  

  બેલેન્સર્સ અને ડેટાબેઝ સ્થળાંતર વિશે

  પ્રેક્ષકો તરફથી પ્રશ્ન (ત્યારબાદ - B): - શુભ સાંજ. આવા એડમિન રિપોર્ટ માટે ખૂબ ખૂબ આભાર! તમારા બેલેન્સર્સ વિશે ટૂંકો પ્રશ્ન. તમે ઉલ્લેખ કર્યો છે કે તમારી પાસે WAF છે, એટલે કે, જેમ હું સમજું છું, તમે અમુક પ્રકારના બાહ્ય બેલેન્સરનો ઉપયોગ કરો છો...

  EK: - ના, અમે અમારી સેવાઓનો ઉપયોગ બેલેન્સર તરીકે કરીએ છીએ. આ કિસ્સામાં, WAF એ અમારા માટે વિશિષ્ટ રીતે DDoS સુરક્ષા સાધન છે.

  IN: - શું તમે બેલેન્સર્સ વિશે થોડા શબ્દો કહી શકો છો?

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

  IN: - પણ એક સરળ પ્રશ્ન. અહીં બ્લુ/ગ્રીન ડિપ્લોયમેન્ટ છે. તમે શું કરો છો, ઉદાહરણ તરીકે, ડેટાબેઝ સ્થળાંતર સાથે?

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

  મિત્રો, તમને પ્રોત્સાહિત કરવા માટે મારી પાસે થોડું ઇનામ પણ છે - એક પુસ્તક. અને મને શ્રેષ્ઠ પ્રશ્ન માટે એવોર્ડ મળવો જોઈએ.

  IN: - નમસ્તે. રિપોર્ટ માટે આભાર. પ્રશ્ન આ છે. તમે ચુકવણીઓનું નિરીક્ષણ કરો છો, તમે જેની સાથે વાતચીત કરો છો તે સેવાઓનું તમે નિરીક્ષણ કરો છો... પરંતુ તમે કેવી રીતે મોનિટર કરો છો જેથી કોઈ વ્યક્તિ તમારા ચુકવણી પૃષ્ઠ પર આવે, ચુકવણી કરે અને પ્રોજેક્ટે તેને પૈસા જમા કર્યા? એટલે કે, તમે કેવી રીતે મોનિટર કરશો કે માર્ચન્ટ ઉપલબ્ધ છે અને તેણે તમારો કૉલબેક સ્વીકાર્યો છે?

  EK: - આ કિસ્સામાં અમારા માટે "વેપારી" એ ચુકવણી સિસ્ટમ જેવી જ બાહ્ય સેવા છે. અમે વેપારીના પ્રતિભાવની ગતિ પર નજર રાખીએ છીએ.

  ડેટાબેઝ એન્ક્રિપ્શન વિશે

  IN: - નમસ્તે. મારી પાસે થોડો સંબંધિત પ્રશ્ન છે. તમારી પાસે PCI DSS સંવેદનશીલ ડેટા છે. મારે જાણવાની ઈચ્છા છે કે તમે PAN કતારોમાં કેવી રીતે સ્ટોર કરો છો જેમાં તમારે ટ્રાન્સફર કરવાની જરૂર છે? શું તમે કોઈપણ એન્ક્રિપ્શનનો ઉપયોગ કરો છો? અને આ બીજા પ્રશ્ન તરફ દોરી જાય છે: PCI DSS મુજબ, ફેરફારોના કિસ્સામાં ડેટાબેઝને સમયાંતરે ફરીથી એન્ક્રિપ્ટ કરવું જરૂરી છે (સંચાલકોની બરતરફી, વગેરે) - આ કિસ્સામાં સુલભતાનું શું થાય છે?

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

  IN: - શું તમને હવે 2 કિલોબાઈટની જરૂર છે?

  EK: - એવું લાગે છે કે ગઈકાલે જ તે 256 હતું... સારું, બીજું ક્યાં?!

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

  કેટલીકવાર ચુકવણીઓ મેન્યુઅલી કરવાની જરૂર પડે છે...

  IN: – એટલે કે, જો કોઈ કામગીરી માટે રિફંડ આવી ગયું હોય, તો પણ શું તમે તેને જૂની કી વડે ડિક્રિપ્ટ કરશો?

  EK: - હા.

  IN: - પછી એક વધુ નાનો પ્રશ્ન. જ્યારે કોઈ પ્રકારની નિષ્ફળતા, પતન અથવા ઘટના બને છે, ત્યારે ટ્રાન્ઝેક્શન દ્વારા જાતે જ દબાણ કરવું જરૂરી છે. આવી સ્થિતિ છે.

  EK: - હા ક્યારેક.

  IN: - તમે આ ડેટા ક્યાંથી મેળવો છો? અથવા તમે આ સ્ટોરેજ ફેસિલિટી પર જાતે જ જાઓ છો?

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

  
  
  IN: - મારી પાસે થોડા પ્રશ્નો છે. તેમાંથી એક PCI DSS ઝોનનું ચાલુ છે: તમે તેમના સર્કિટને કેવી રીતે લોગ કરશો? આ પ્રશ્ન એટલા માટે છે કારણ કે વિકાસકર્તા લોગમાં કંઈપણ મૂકી શક્યા હોત! બીજો પ્રશ્ન: તમે હોટફિક્સ કેવી રીતે રોલ આઉટ કરશો? ડેટાબેઝમાં હેન્ડલ્સનો ઉપયોગ કરવો એ એક વિકલ્પ છે, પરંતુ ત્યાં મફત હોટ-ફિક્સ હોઈ શકે છે - ત્યાં પ્રક્રિયા શું છે? અને ત્રીજો પ્રશ્ન કદાચ RTO, RPOને લગતો છે. તમારી ઉપલબ્ધતા 99,97 હતી, લગભગ ચાર નાઇન્સ, પરંતુ હું તેને સમજું છું તેમ, તમારી પાસે બીજું ડેટા સેન્ટર, ત્રીજું ડેટા સેન્ટર અને પાંચમું ડેટા સેન્ટર છે... તમે તેમને કેવી રીતે સિંક્રનાઇઝ કરો છો, તેમની નકલ કરો છો અને બીજું બધું?

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

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

  IN: - જો તમને બીજું મળ્યું, તો તમને ત્રીજું કેમ ન મળ્યું? કારણ કે હજુ સુધી કોઈનું મગજ વિભાજિત નથી...

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

  IN: - શુભ સાંજ. રિપોર્ટ માટે આભાર. તમે તમારા ડીબગર વિશે વાત કરી, જે ઉત્પાદનમાં કેટલાક પરીક્ષણ વ્યવહારો ચલાવે છે. પરંતુ અમને પરીક્ષણ વ્યવહારો વિશે કહો! તે કેટલું ઊંડાણમાં જાય છે?

  EK: - તે સમગ્ર ઘટકના સંપૂર્ણ ચક્રમાંથી પસાર થાય છે. એક ઘટક માટે, પરીક્ષણ વ્યવહાર અને ઉત્પાદન વ્યવહાર વચ્ચે કોઈ તફાવત નથી. પરંતુ તાર્કિક દૃષ્ટિકોણથી, આ સિસ્ટમમાં ફક્ત એક અલગ પ્રોજેક્ટ છે, જેના પર ફક્ત પરીક્ષણ વ્યવહારો ચલાવવામાં આવે છે.

  IN: - તમે તેને ક્યાં કાપી નાખો છો? અહીં કોરે મોકલ્યો...

  EK: – અમે પરીક્ષણ વ્યવહારો માટે આ કિસ્સામાં "કોર" પાછળ છીએ... અમારી પાસે રૂટીંગ જેવી વસ્તુ છે: "કોર" જાણે છે કે કઈ ચુકવણી સિસ્ટમને મોકલવી - અમે નકલી ચુકવણી સિસ્ટમ પર મોકલીએ છીએ, જે ફક્ત HTTP સિગ્નલ આપે છે અને બસ.

  IN: - મને કહો, કૃપા કરીને, તમારી અરજી એક વિશાળ મોનોલિથમાં લખવામાં આવી હતી, અથવા તમે તેને કેટલીક સેવાઓ અથવા તો માઇક્રોસર્વિસિસમાં કાપી હતી?

  EK: - અમારી પાસે મોનોલિથ નથી, અલબત્ત, અમારી પાસે સેવા-લક્ષી એપ્લિકેશન છે. અમે મજાક કરીએ છીએ કે અમારી સેવા મોનોલિથથી બનેલી છે - તે ખરેખર ખૂબ મોટી છે. તેને માઇક્રોસર્વિસિસ કહેવું મુશ્કેલ છે, પરંતુ આ એવી સેવાઓ છે જેમાં વિતરિત મશીનોના કામદારો કામ કરે છે.

  જો સર્વર પરની સેવા સાથે ચેડા થાય છે...

  IN: - પછી મારી પાસે આગળનો પ્રશ્ન છે. જો તે મોનોલિથ હોય, તો પણ તમે હજી પણ કહ્યું હતું કે તમારી પાસે આમાંના ઘણા ઇન્સ્ટન્ટ સર્વર્સ છે, તે બધા મૂળભૂત રીતે ડેટા પર પ્રક્રિયા કરે છે, અને પ્રશ્ન એ છે: “ત્વરિત સર્વર અથવા એપ્લિકેશનમાંથી કોઈ એક સાથે સમાધાનના કિસ્સામાં, કોઈપણ વ્યક્તિગત લિંક , શું તેમની પાસે કોઈ પ્રકારનું ઍક્સેસ નિયંત્રણ છે? તેમાંથી કોણ શું કરી શકે? કઈ માહિતી માટે મારે કોનો સંપર્ક કરવો જોઈએ?

  
  
  EK: - હા, ચોક્કસપણે. સુરક્ષા જરૂરિયાતો તદ્દન ગંભીર છે. સૌપ્રથમ, અમારી પાસે ઓપન ડેટા હિલચાલ છે, અને બંદરો ફક્ત તે જ છે જેના દ્વારા અમે અગાઉથી ટ્રાફિકની હિલચાલની અપેક્ષા રાખીએ છીએ. જો કોઈ ઘટક 5-4-3-2 દ્વારા ડેટાબેઝ (કહો, મસ્કુલ સાથે) સાથે વાતચીત કરે છે, તો ફક્ત 5-4-3-2 તેના માટે ખુલ્લું રહેશે, અને અન્ય બંદરો અને અન્ય ટ્રાફિક દિશાઓ ઉપલબ્ધ રહેશે નહીં. વધુમાં, તમારે એ સમજવાની જરૂર છે કે અમારા ઉત્પાદનમાં લગભગ 10 વિવિધ સુરક્ષા લૂપ્સ છે. અને જો એપ્લિકેશનમાં કોઈક રીતે ચેડા કરવામાં આવ્યા હોય, તો પણ ભગવાન મનાઈ કરે, હુમલાખોર સર્વર મેનેજમેન્ટ કન્સોલને ઍક્સેસ કરી શકશે નહીં, કારણ કે આ એક અલગ નેટવર્ક સુરક્ષા ઝોન છે.

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

  EK: - હુ સમજયો. જો સામાન્ય પરિસ્થિતિમાં બીજા સર્વર સાથે સંચારની મંજૂરી હતી, તો હા. SLA કરાર મુજબ, અમે મોનિટર કરતા નથી કે તમને ફક્ત પ્રથમ 3 "ક્રિયાઓ" કરવાની મંજૂરી છે, અને તમને 4 "ક્રિયાઓ" કરવાની મંજૂરી નથી. આ કદાચ આપણા માટે નિરર્થક છે, કારણ કે સર્કિટ માટે, સૈદ્ધાંતિક રીતે, અમારી પાસે પહેલેથી જ 4-સ્તરની સુરક્ષા સિસ્ટમ છે. અમે અંદરના સ્તરને બદલે રૂપરેખાથી પોતાનો બચાવ કરવાનું પસંદ કરીએ છીએ.

  વિઝા, માસ્ટરકાર્ડ અને Sberbank કેવી રીતે કાર્ય કરે છે

  IN: - હું વપરાશકર્તાને એક ડેટા સેન્ટરમાંથી બીજા ડેટા સેન્ટરમાં સ્વિચ કરવા વિશે એક મુદ્દો સ્પષ્ટ કરવા માંગુ છું. જ્યાં સુધી હું જાણું છું, વિઝા અને માસ્ટરકાર્ડ 8583 બાઈનરી સિંક્રનસ પ્રોટોકોલનો ઉપયોગ કરીને કાર્ય કરે છે, અને ત્યાં મિશ્રણો છે. અને હું જાણવા માંગતો હતો, હવે અમારો મતલબ સ્વિચ કરવાનો છે - શું તે સીધું “વિઝા” અને “માસ્ટરકાર્ડ” છે કે પેમેન્ટ સિસ્ટમ્સ પહેલાં, પ્રોસેસિંગ પહેલાં?

  EK: - આ મિશ્રણ પહેલા છે. અમારા મિક્સ એ જ ડેટા સેન્ટરમાં સ્થિત છે.

  IN: - લગભગ કહીએ તો, શું તમારી પાસે એક જોડાણ બિંદુ છે?

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

  IN: - તેમને કેવી રીતે અનામત આપી શકાય? હું જાણું છું કે વિઝા સિદ્ધાંતમાં ફક્ત એક જ જોડાણને મંજૂરી આપે છે!

  EK: - તેઓ જાતે જ સાધનો પૂરા પાડે છે. કોઈ પણ સંજોગોમાં, અમને એવા સાધનો મળ્યા છે જે અંદરથી સંપૂર્ણપણે બિનજરૂરી છે.

  IN: - તો સ્ટેન્ડ તેમના કનેક્ટ્સ ઓરેન્જનું છે?..

  EK: - હા.

  IN: - પરંતુ આ કેસ વિશે શું: જો તમારું ડેટા સેન્ટર અદૃશ્ય થઈ જાય, તો તમે તેનો ઉપયોગ કેવી રીતે ચાલુ રાખી શકો? અથવા શું ટ્રાફિક ફક્ત બંધ થાય છે?

  EK: - ના. આ કિસ્સામાં, અમે ટ્રાફિકને અન્ય ચેનલ પર બદલીશું, જે સ્વાભાવિક રીતે, અમારા માટે વધુ ખર્ચાળ અને અમારા ગ્રાહકો માટે વધુ ખર્ચાળ હશે. પરંતુ ટ્રાફિક વિઝા, માસ્ટરકાર્ડ સાથેના અમારા સીધા કનેક્શન દ્વારા નહીં, પરંતુ શરતી Sberbank (ખૂબ જ અતિશયોક્તિપૂર્ણ) દ્વારા જશે.

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

  
  
  

  કેટલીક જાહેરાતો 🙂

  અમારી સાથે રહેવા બદલ આભાર. શું તમને અમારા લેખો ગમે છે? વધુ રસપ્રદ સામગ્રી જોવા માંગો છો? ઓર્ડર આપીને અથવા મિત્રોને ભલામણ કરીને અમને ટેકો આપો, $4.99 થી વિકાસકર્તાઓ માટે ક્લાઉડ VPS, એન્ટ્રી-લેવલ સર્વર્સનું એક અનન્ય એનાલોગ, જેની શોધ અમારા દ્વારા તમારા માટે કરવામાં આવી છે: VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps વિશેનું સંપૂર્ણ સત્ય $19 થી અથવા સર્વર કેવી રીતે શેર કરવું? (RAID1 અને RAID10 સાથે ઉપલબ્ધ, 24 કોરો સુધી અને 40GB DDR4 સુધી).

  એમ્સ્ટરડેમમાં ઇક્વિનિક્સ ટાયર IV ડેટા સેન્ટરમાં ડેલ R730xd 2 ગણું સસ્તું? માત્ર અહીં 2 x ઇન્ટેલ ટેટ્રાડેકા-કોર Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ટીવી $199 થી નેધરલેન્ડમાં! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 થી! વિશે વાંચો ઇન્ફ્રાસ્ટ્રક્ચર કોર્પોરેશન કેવી રીતે બનાવવું. ડેલ R730xd E5-2650 v4 સર્વર્સના ઉપયોગ સાથેનો વર્ગ એક પેની માટે 9000 યુરોના મૂલ્યના છે?

સોર્સ: www.habr.com