પબ્લિશ કર્યા પછી તરત ક્રેશ થતી એપ પકડવી

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

પબ્લિશ શેની રાહ જુએ છે

જ્યારે તમે બેકએન્ડ ધરાવતી એપ Mythex પર પબ્લિશ કરો છો, ત્યારે નવું વર્ઝન અમારા હોસ્ટિંગ પ્લેટફોર્મના મશીનો પર રોલ થાય છે, અને એક હેલ્થ ચેક નક્કી કરે છે કે પબ્લિશ લાઇવ થયું કે નિષ્ફળ ગયું. જો નિષ્ફળ ગયું હોય, તો રોલબેક પાછલું વર્ઝન પાછું મૂકે છે.

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

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

ત્રીજો ચેક જ અહીં નિષ્ફળ ગયો.

ગણતરી કેમ સ્થિર રહી

ક્રેશની માહિતી દરેક મશીનની ઇવેન્ટ-યાદીમાંથી આવે છે: શરૂઆત, બહાર નીકળવું, રિસ્ટાર્ટ. પ્લેટફોર્મ દરેક મશીન માટે ફક્ત છેલ્લી પાંચ ઇવેન્ટ રાખે છે.

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

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

તે 25 સપ્ટેમ્બરે ત્રણ વખત બન્યું, બે એપમાં. દરેક વખતે:

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

જે પબ્લિશ સમયસર નિષ્ફળ થાય તે સુધારી શકાય છે: રોલબેક પાછલું વર્ઝન પુનઃસ્થાપિત કરે છે. જે પબ્લિશ થોડી મિનિટો મોડું નિષ્ફળ થાય, સફળતા તરીકે જાહેર થયા પછી, તે તેનો રોલબેક પહેલેથી છોડી ચૂક્યું હોય છે.

અમે તે કેવી રીતે શોધ્યું

અમે તેને સ્થાનિક રીતે પુનઃઉત્પન્ન કર્યું: એક કામ કરતો API લીધો, તેને સૂવા દીધો, પછી એક એવા ફેરફાર સાથે ફરી પબ્લિશ કર્યો જે બૂટ પર ક્રેશ થાય. હેલ્થ ચેકે તેને લાઇવ ગણ્યું.

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

સુધારો: ગણતરીને બદલે સૌથી નવા ક્રેશની સરખામણી

ક્રેશ ગણવાને બદલે, ચેક હવે પબ્લિશ શરૂ થયા પછીના સૌથી તાજેતરના ક્રેશનો સમય જુએ છે.

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

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

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

અમે શું શીખ્યા

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

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