𝗬𝗼𝘂𝗿 𝗧𝗶𝗰𝗸𝗲𝘁 𝗪𝗮𝘀 𝗖𝗹𝗼𝘀𝗲𝗱. 𝗧𝗵𝗲 𝗨𝘀𝗲𝗿 𝗦𝘁𝗶𝗹𝗹 𝗖𝗼𝘂𝗹𝗱𝗻'𝘁 𝗣𝗮𝘆.
તમારા બેકએન્ડ દ્વારા 200 સ્ટેટસ કોડ રિટર્ન કરવામાં આવ્યો હતો. મોબાઈલ એપમાં એરર દેખાઈ. યુઝરે ત્રણ વાર "Pay" પર ટેપ કર્યું. તેમના ખાતામાંથી ત્રણ વાર ચાર્જ કપાયા. એક ઓર્ડર સફળ રહ્યો. હવે તેમનું બેલેન્સ ઓછું થઈ ગયું છે. તમારા લોગ્સમાં શૂન્ય નિષ્ફળતાઓ (zero failures) દેખાય છે.
દરેક એન્જિનિયરે તેમનું કામ કર્યું. કોઈએ સમસ્યાનું નિરાકરણ કર્યું નહીં.
ટીમો ઘણીવાર ખરાબ કોડને કારણે નહીં, પરંતુ તેઓ ખોટું કામ કરે છે તેથી નિષ્ફળ જાય છે. તમે એક એવું સિસ્ટમ મોકલી શકો છો જે સંપૂર્ણ રીતે કામ કરે છે પરંતુ એક ખરાબ અનુભવ (experience) બનાવે છે.
જુનિયર એન્જિનિયરો ટિકિટના સંદર્ભમાં વિચારે છે. ટિકિટ સોંપવામાં આવી. કોડ લખવામાં આવ્યો. ટેસ્ટ પાસ થયા. PR મર્જ થઈ. ટિકિટ બંધ થઈ.
જેમ જેમ તમે આગળ વધો છો તેમ આ માનસિકતા એક જવાબદારી (liability) બની જાય છે. જે એન્જિનિયર ટિકિટો બંધ કરે છે તે ઉપયોગી છે. જે એન્જિનિયર પૂછે છે કે "શું આ ખરેખર બિઝનેસ સમસ્યાનું નિરાકરણ કરે છે?" તે અનિવાર્ય (indispensable) છે.
પેમેન્ટ ફ્લો (payment flow) પર વિચાર કરો. બેકએન્ડ એન્જિનિયર એક એન્ડપોઈન્ટ (endpoint) બનાવે છે. તે ચાર્જ પ્રોસેસ કરે છે અને સાચા કોડ રિટર્ન કરે છે. 100% ટેસ્ટ કવરેજ. ટિકિટ બંધ. મોબાઈલ એન્જિનિયર સ્ક્રીન બનાવે છે. તે એન્ડપોઈન્ટને કોલ કરે છે અને રિસ્પોન્સ બતાવે છે. સ્મૂધ UI. ટિકિટ બંધ.
જે સમસ્યાનું કોઈએ માલિકી લીધી નથી: જ્યારે ચાર્જ થયા પછી પણ મોબાઈલ એપને કન્ફર્મેશન મળતા પહેલા નેટવર્ક ડ્રોપ થાય ત્યારે શું થાય છે?
બેકએન્ડ સફળતા (success) બતાવે છે. મોબાઈલ એપ નિષ્ફળતા (failure) બતાવે છે. યુઝર ફરીથી પ્રયાસ કરે છે અને બે વાર ચાર્જ થઈ જાય છે.
આનું નિરાકરણ માત્ર બેકએન્ડ કે મોબાઈલ ફિક્સ નથી. તે માટે idempotency keys ની જરૂર છે. મોબાઈલ એપે દરેક પ્રયાસ માટે એક યુનિક કી (unique key) જનરેટ કરવી જોઈએ. બેકએન્ડે તે કીનો ઉપયોગ એ સુનિશ્ચિત કરવા માટે કરવો જોઈએ કે રિટ્રાય કરવાથી ક્યારેય ડુપ્લીકેટ ચાર્જ ન થાય.
આ ઉકેલ ત્યારે જ શક્ય બને છે જો એન્જિનિયરો નેટવર્ક ડ્રોપ દરમિયાન યુઝર એક્સપિરિયન્સ વિશે એકબીજા સાથે વાત કરે.
હાર્ડવેર સાથે પણ આવું જ થાય છે. હાર્ડવેર એન્જિનિયર ફર્મવેર (firmware) મોકલે છે. મોબાઈલ એન્જિનિયર એપ મોકલે છે. બેકએન્ડ એન્જિનિયર API મોકલે છે. દરેક ભાગ કામ કરે છે. દરેક ટેસ્ટ પાસ થાય છે.
પરંતુ યુઝર બટન દબાવે છે અને 11 સેકન્ડ પછી લાઈટ ચાલુ થાય છે. લેટન્સી (latency) ઘટકો વચ્ચેના અંતરાલમાં રહેલી છે. કોઈ એક એન્જિનિયરે એન્ડ-ટુ-એન્ડ સ્પીડની જવાબદારી લીધી નહોતી.
સાચી વિશ્વસનીયતા (reliability) એ સિસ્ટમનો ગુણધર્મ છે, ઘટકનો (component) ગુણધર્મ નથી.
આને સુધારવા માટે, તમારે તમારી કામ કરવાની પદ્ધતિ બદલવી પડશે:
- માત્ર કમ્પોનન્ટ SLOs ને બદલે એન્ડ-ટુ-એન્ડ SLOs વ્યાખ્યાયિત કરો.
- એવા ઇન્ટિગ્રેશન ટેસ્ટ લખો જે વાસ્તવિક યુઝર્સ અને ધીમા નેટવર્કનું અનુકરણ (simulate) કરે.
- શિપ કરતા પહેલા failure mode analysis કરો.
- માત્ર API રિસ્પોન્સ ટાઈમ જ નહીં, પરંતુ સમગ્ર યુઝર જર્ની (user journey) માપો.
તમારો હોદ્દો તમારી કુશળતાનું વર્ણન કરે છે. તે તમારી જવાબદારીની મર્યાદા નક્કી કરતો નથી.
જો તમે બેકએન્ડ એન્જિનિયર હોવ, તો વપરાશકર્તાઓ દ્વારા વિશ્વસનીય રીતે ચુકવણી થાય તેની જવાબદારી તમારી છે. જો તમે મોબાઈલ એન્જિનિયર હોવ, તો વપરાશકર્તાના વિશ્વાસની જવાબદારી તમારી છે.
ટિકિટો બંધ કરવી એ માત્ર પાયાનું કામ છે. વપરાશકર્તાના પરિણામની સંપૂર્ણ જવાબદારી લેવી એ સર્વોચ્ચ સ્તર છે.
સ્ત્રોત: https://dev.to/walosha/your-ticket-was-closed-the-user-still-couldnt-pay-14di