એક રોલઆઉટ વાર્તા જેણે દરેક વસ્તુને અસર કરી

વાસ્તવિકતાના દુશ્મનો 12f-2 દ્વારા

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

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

પૃષ્ઠભૂમિ + આ કેવા પ્રકારની કાર્યક્ષમતા છે?

અમે ક્લાઉડ પ્લેટફોર્મ બનાવી રહ્યા છીએ Mail.ru ક્લાઉડ સોલ્યુશન્સ (MCS), જ્યાં હું ટેકનિકલ ડિરેક્ટર તરીકે કામ કરું છું. અને હવે અમારા પ્લેટફોર્મમાં IAM (ઓળખ અને એક્સેસ મેનેજમેન્ટ) ઉમેરવાનો સમય આવી ગયો છે, જે તમામ વપરાશકર્તા ખાતાઓ, વપરાશકર્તાઓ, પાસવર્ડ્સ, ભૂમિકાઓ, સેવાઓ અને વધુનું એકીકૃત સંચાલન પ્રદાન કરે છે. ક્લાઉડમાં તે શા માટે જરૂરી છે તે એક સ્પષ્ટ પ્રશ્ન છે: વપરાશકર્તાની બધી માહિતી તેમાં સંગ્રહિત છે.

સામાન્ય રીતે આવી વસ્તુઓ કોઈપણ પ્રોજેક્ટની શરૂઆતમાં જ બાંધવામાં આવે છે. પરંતુ ઐતિહાસિક રીતે MCS માં વસ્તુઓ થોડી અલગ રહી છે. MCS બે ભાગોમાં બાંધવામાં આવ્યું હતું:

• ઓપનસ્ટૅક તેના પોતાના કીસ્ટોન અધિકૃતતા મોડ્યુલ સાથે,
• Mail.ru ક્લાઉડ પ્રોજેક્ટ પર આધારિત Hotbox (S3 સ્ટોરેજ),

જેની આસપાસ પછી નવી સેવાઓ દેખાઈ.

અનિવાર્યપણે, આ બે અલગ અલગ પ્રકારની અધિકૃતતા હતી. ઉપરાંત, અમે કેટલાક અલગ Mail.ru વિકાસનો ઉપયોગ કર્યો, ઉદાહરણ તરીકે, સામાન્ય Mail.ru પાસવર્ડ સ્ટોરેજ, તેમજ સ્વ-લિખિત ઓપનઆઈડ કનેક્ટર, જેનો આભાર SSO (એન્ડ-ટુ-એન્ડ અધિકૃતતા) Horizon પેનલમાં પ્રદાન કરવામાં આવ્યો હતો. વર્ચ્યુઅલ મશીનો (મૂળ OpenStack UI).

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

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

અમે શું રોલ આઉટ કરવા જઈ રહ્યા છીએ?

તેને ખૂબ જ અંદાજે મૂકવા માટે, લગભગ 4 મહિનામાં અમે નીચેની તૈયારી કરી:

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

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

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

રોલઆઉટ વ્યૂહરચના

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

વિષયાંતર: રોલઆઉટ શું છે?

<સાવધાની, ફિલસૂફી>

દરેક આઇટી નિષ્ણાત સરળતાથી જવાબ આપી શકે છે કે રોલઆઉટ શું છે. તમે CI/CD ઇન્સ્ટોલ કરો છો, અને બધું આપમેળે સ્ટોર પર વિતરિત થાય છે. 🙂

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

અને આખું ચિત્ર આ પ્રમાણે છે. રોલઆઉટમાં ચાર મુખ્ય પાસાઓનો સમાવેશ થાય છે:

1. કોડની ડિલિવરી, ડેટા ફેરફાર સહિત. ઉદાહરણ તરીકે, તેમનું સ્થળાંતર.
2. કોડ રોલબેક એ કંઈક ખોટું થાય તો પાછા જવાની ક્ષમતા છે. ઉદાહરણ તરીકે, બેકઅપ બનાવવા દ્વારા.
3. દરેક રોલઆઉટ/રોલબેક કામગીરીનો સમય. તમારે પ્રથમ બે મુદ્દાઓની કોઈપણ કામગીરીનો સમય સમજવાની જરૂર છે.
4. અસરગ્રસ્ત કાર્યક્ષમતા. અપેક્ષિત હકારાત્મક અને સંભવિત નકારાત્મક અસરો બંનેનું મૂલ્યાંકન કરવું જરૂરી છે.

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

એક્ટ 1..n, પ્રકાશનની તૈયારી

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

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

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

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

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

અને તેથી…

રોલ આઉટ કરતા પહેલા અંતિમ કાર્ય

...તે રોલ આઉટ કરવાનો સમય છે.

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

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

1. અસર કરે છે (અમારા માટે પવિત્ર, સૌથી કિંમતી) વપરાશકર્તા ઈન્ફ્રાસ્ટ્રક્ચર,
2. કાર્યક્ષમતા: રોલઆઉટ પછી અમારી સેવાનો ઉપયોગ તે પહેલા જેવો જ હોવો જોઈએ.

બહાર રોલિંગ

બે રોલ, 8 દખલ કરશો નહીં

અમે વપરાશકર્તાઓની તમામ વિનંતીઓ માટે 7 કલાક માટે ડાઉનટાઇમ લઈએ છીએ. આ સમયે, અમારી પાસે રોલઆઉટ પ્લાન અને રોલબેક પ્લાન બંને છે.

• રોલઆઉટ પોતે જ લગભગ 3 કલાક લે છે.
• પરીક્ષણ માટે 2 કલાક.
• 2 કલાક - ફેરફારોના સંભવિત રોલબેક માટે અનામત.

દરેક ક્રિયા માટે એક ગેન્ટ ચાર્ટ તૈયાર કરવામાં આવ્યો છે, તે કેટલો સમય લે છે, ક્રમિક રીતે શું થાય છે, શું સમાંતર કરવામાં આવે છે.

રોલઆઉટ ગેન્ટ ચાર્ટનો એક ભાગ, પ્રારંભિક સંસ્કરણોમાંથી એક (સમાંતર અમલીકરણ વિના). સૌથી મૂલ્યવાન સિંક્રનાઇઝેશન ટૂલ

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

ઘટનાઓ ક્રોનિકલ

તો, 15 લોકો 29 એપ્રિલ, રવિવારના રોજ રાત્રે 10 વાગ્યે કામ પર આવ્યા હતા. મુખ્ય સહભાગીઓ ઉપરાંત, કેટલાક ફક્ત ટીમને ટેકો આપવા આવ્યા હતા, જેના માટે તેઓનો વિશેષ આભાર.

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

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

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

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

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

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

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

03:00. -2 સમસ્યાઓ +2 સમસ્યાઓ
અગાઉની બે મોટી સમસ્યાઓને ઠીક કરવામાં આવી છે, અને લગભગ તમામ નાની સમસ્યાઓ પણ. ફિક્સેસમાં અવ્યવસ્થિત તમામ લોકો સક્રિયપણે તેમના એકાઉન્ટ્સમાં કામ કરી રહ્યા છે અને તેઓ જે શોધે છે તેની જાણ કરી રહ્યા છે. અમે પ્રાધાન્ય આપીએ છીએ, ટીમોમાં વહેંચીએ છીએ અને સવાર માટે બિન-જટિલ વસ્તુઓ છોડીએ છીએ.

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

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

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

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

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

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

07:00. API લોડ સાથે સમસ્યાઓ
તે સ્પષ્ટ થાય છે કે અમે અમારા API પરના લોડનું થોડું ખોટું આયોજન કર્યું છે અને આ લોડનું પરીક્ષણ કર્યું છે, જે સમસ્યાને ઓળખી શક્યું નથી. પરિણામે, ≈5% વિનંતીઓ નિષ્ફળ જાય છે. ચાલો એકત્ર કરીએ અને કારણ શોધીએ.

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

08:00. ફિક્સ API
અમે લોડ માટે એક ફિક્સ રોલ આઉટ કર્યું, નિષ્ફળતાઓ દૂર થઈ ગઈ. અમે ઘરે જવાનું શરૂ કરીએ છીએ.

10:00. બધા
બધું નિશ્ચિત છે. તે મોનિટરિંગમાં શાંત છે અને ગ્રાહકોના સ્થાને, ટીમ ધીમે ધીમે સૂઈ જાય છે. બિલિંગ બાકી છે, અમે તેને આવતીકાલે પુનઃસ્થાપિત કરીશું.

પછી દિવસ દરમિયાન એવા રોલઆઉટ્સ હતા જેણે અમારા કેટલાક ક્લાયન્ટ્સ માટે લૉગ્સ, નોટિફિકેશન્સ, રિટર્ન કોડ્સ અને કસ્ટમાઇઝેશન ફિક્સ કર્યા હતા.

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

કુલ

રોલઆઉટ માટે સક્રિય તૈયારીના 2 મહિના દરમિયાન, 43 કાર્યો પૂર્ણ થયા, જે થોડા કલાકોથી કેટલાક દિવસો સુધી ચાલ્યા.

રોલઆઉટ દરમિયાન:

• નવા અને બદલાયેલા રાક્ષસો - 5 ટુકડાઓ, 2 મોનોલિથ્સને બદલીને;
• ડેટાબેસેસમાં ફેરફારો - વપરાશકર્તા ડેટા સાથેના અમારા તમામ 6 ડેટાબેસેસ પ્રભાવિત થયા છે, ત્રણ જૂના ડેટાબેસેસમાંથી એક નવામાં ડાઉનલોડ કરવામાં આવ્યા છે;
• સંપૂર્ણપણે ફરીથી ડિઝાઇન કરેલ અગ્રભાગ;
• ડાઉનલોડ કરેલ કોડની રકમ - નવા કોડની 33 હજાર લાઇન, ≈ પરીક્ષણોમાં કોડની 3 હજાર લાઇન, ≈ સ્થળાંતર કોડની 5 હજાર લાઇન;
• તમામ ડેટા અકબંધ છે, એક પણ ગ્રાહકના વર્ચ્યુઅલ મશીનને નુકસાન થયું નથી. 🙂

સારા રોલઆઉટ માટે સારી પદ્ધતિઓ

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

1. તમારે પ્રથમ વસ્તુ એ સમજવાની જરૂર છે કે રોલઆઉટ વપરાશકર્તાઓને કેવી રીતે અસર કરી શકે છે અથવા કરશે. શું ડાઉનટાઇમ હશે? જો એમ હોય, તો ડાઉનટાઇમ શું છે? આ વપરાશકર્તાઓને કેવી રીતે અસર કરશે? સંભવિત શ્રેષ્ઠ અને સૌથી ખરાબ સંજોગો શું છે? અને જોખમોને આવરી લે છે.
2. બધું પ્લાન કરો. દરેક તબક્કે, તમારે રોલઆઉટના તમામ પાસાઓને સમજવાની જરૂર છે:
   • કોડ વિતરણ;
   • કોડ રોલબેક;
   • દરેક ઓપરેશનનો સમય;
   • અસરગ્રસ્ત કાર્યક્ષમતા.
3. રોલઆઉટના તમામ તબક્કાઓ તેમજ તેમાંના દરેકમાં જોખમો સ્પષ્ટ ન થાય ત્યાં સુધી દૃશ્યો દ્વારા રમો. જો તમને કોઈ શંકા હોય, તો તમે વિરામ લઈ શકો છો અને પ્રશ્નાર્થ તબક્કાને અલગથી ચકાસી શકો છો.
4. જો તે અમારા વપરાશકર્તાઓને મદદ કરે તો દરેક તબક્કામાં સુધારો થઈ શકે છે અને થવો જોઈએ. ઉદાહરણ તરીકે, તે ડાઉનટાઇમ ઘટાડશે અથવા કેટલાક જોખમો દૂર કરશે.
5. કોડ ડિલિવરી ટેસ્ટિંગ કરતાં રોલબેક ટેસ્ટિંગ ઘણું મહત્વનું છે. તે તપાસવું જરૂરી છે કે રોલબેકના પરિણામે સિસ્ટમ તેની મૂળ સ્થિતિમાં પાછી આવશે, અને પરીક્ષણો સાથે તેની પુષ્ટિ કરો.
6. સ્વયંસંચાલિત થઈ શકે તે બધું સ્વયંસંચાલિત હોવું જોઈએ. દરેક વસ્તુ જે સ્વચાલિત થઈ શકતી નથી તે ચીટ શીટ પર અગાઉથી લખવી જોઈએ.
7. સફળતાના માપદંડને રેકોર્ડ કરો. કઈ કાર્યક્ષમતા ઉપલબ્ધ હોવી જોઈએ અને કયા સમયે? જો આવું ન થાય, તો રોલબેક પ્લાન ચલાવો.
8. અને સૌથી અગત્યનું - લોકો. દરેક વ્યક્તિને તેઓ શું કરી રહ્યા છે, શા માટે અને શું રોલઆઉટ પ્રક્રિયામાં તેમની ક્રિયાઓ પર આધાર રાખે છે તેની જાણ હોવી જોઈએ.

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

સોર્સ: www.habr.com