𝗬𝗼𝘂𝗿 𝗧𝗶𝗰𝗸𝗲𝘁 𝗪𝗮𝘀 𝗖𝗹𝗼𝘀𝗲𝗱. 𝗧𝗵𝗲 𝗨𝘀𝗲𝗿 𝗦𝘁𝗶𝗹𝗹 𝗖𝗼𝘂𝗹𝗱𝗻'𝘁 𝗣𝗮𝘆.
உங்கள் backend 200 status code-ஐத் திருப்பியளித்தது. மொபைல் ஆப் ஒரு பிழையைக் காட்டியது. பயனர் "Pay" என்பதை மூன்று முறை அழுத்தியது. அவர்களின் கணக்கில் மூன்று முறை பணம் எடுக்கப்பட்டது. ஒரு ஆர்டர் மட்டுமே நிறைவேறியது. இப்போது அவர்களின் இருப்புத் தொகை குறைவாக உள்ளது. உங்கள் logs-இல் எந்தத் தோல்வியும் காட்டப்படவில்லை.
ஒவ்வொரு பொறியாளரும் தங்கள் வேலையைச் செய்தார்கள். ஆனால் யாரும் பிரச்சனையைத் தீர்க்கவில்லை.
குழுக்கள் பெரும்பாலும் மோசமான குறியீட்டினால் தோல்வியடைவதில்லை, மாறாகத் தவறான வேலையைச் செய்வதால் தோல்வியடைகின்றன. நீங்கள் மிகச்சரியாகச் செயல்படும் ஒரு அமைப்பை உருவாக்கலாம், ஆனால் அது ஒரு மோசமான அனுபவத்தை உருவாக்கக்கூடும்.
ஜூனியர் பொறியாளர்கள் டிக்கெட்டுகளை மட்டுமே கருத்தில் கொள்கிறார்கள். Ticket assigned. Code written. Tests pass. PR merged. Ticket closed.
நீங்கள் வளர வளர இந்த மனநிலை ஒரு சுமையாக மாறும். டிக்கெட்டுகளை மூடும் பொறியாளர் பயனுள்ளவர். ஆனால் "இது உண்மையில் வணிகப் பிரச்சனையைத் தீர்க்கிறதா?" என்று கேட்கும் பொறியாளர் ஈடுஇணையற்றவர்.
ஒரு பணப்பரிமாற்றச் செயல்பாட்டை (payment flow) கருத்தில் கொள்ளுங்கள். Backend பொறியாளர் ஒரு endpoint-ஐ உருவாக்குகிறார். அது கட்டணங்களைச் செயலாக்கி சரியான குறியீடுகளைத் திருப்பியளிக்கிறது. 100% test coverage. Ticket closed. Mobile பொறியாளர் திரையை (screen) உருவாக்குகிறார். அது endpoint-ஐ அழைத்து பதிலைக் காட்டுகிறது. Smooth UI. Ticket closed.
யாரும் பொறுப்பேற்காத பிரச்சனை: கட்டணம் செலுத்தப்பட்ட பிறகு, ஆனால் மொபைல் ஆப் உறுதிப்படுத்தலைப் பெறுவதற்கு முன்பே நெட்வொர்க் துண்டிக்கப்பட்டால் என்ன நடக்கும்?
Backend வெற்றியைத் தெரிவிக்கிறது. Mobile ஆப் தோல்வியைக் காட்டுகிறது. பயனர் மீண்டும் முயற்சிக்கும்போது இரண்டு முறை பணம் எடுக்கப்படுகிறது.
இதற்கான தீர்வு வெறும் backend அல்லது mobile சார்ந்த தீர்வு மட்டுமல்ல. இதற்கு idempotency keys தேவை. ஒவ்வொரு முயற்சியிலும் மொபைல் ஆப் ஒரு தனித்துவமான சாவியை (unique key) உருவாக்க வேண்டும். மீண்டும் முயற்சிக்கும்போது இரட்டிப்பு கட்டணம் வசூலிக்கப்படுவதைத் தவிர்க்க backend அந்தச் சாவியைப் பயன்படுத்த வேண்டும்.
நெட்வொர்க் துண்டிக்கப்படும்போது பயனரின் அனுபவம் எப்படி இருக்கும் என்பது குறித்து பொறியாளர்கள் ஒருவருக்கொருவர் பேசினால் மட்டுமே இந்தத் தீர்வு சாத்தியமாகும்.
இது hardware-லும் நிகழ்கிறது. Hardware பொறியாளர் firmware-ஐ வழங்குகிறார். Mobile பொறியாளர் ஆப்பை வழங்குகிறார். Backend பொறியாளர் API-ஐ வழங்குகிறார். ஒவ்வொரு பகுதியும் செயல்படுகிறது. ஒவ்வொரு சோதனையும் வெற்றி பெறுகிறது.
ஆனால் பயனர் ஒரு பொத்தானை அழுத்தினால், 11 விநாடிகளுக்குப் பிறகு விளக்கு எரிகிறது. இந்தத் தாமதம் (latency) கூறுகளுக்கு இடையிலான இடைவெளியில் உள்ளது. முழுமையான வேகத்திற்கு (end-to-end speed) எந்த ஒரு பொறியாளரும் பொறுப்பேற்கவில்லை.
உண்மையான நம்பகத்தன்மை என்பது ஒரு அமைப்பின் பண்பு (system property), ஒரு தனிப் பகுதியின் பண்பு (component property) அல்ல.
இதைச் சரிசெய்ய, நீங்கள் வேலை செய்யும் முறையை மாற்ற வேண்டும்:
- வெறும் கூறுகளுக்கான SLO-களுக்குப் பதிலாக, முழுமையான (end-to-end) SLO-களை வரையறுக்கவும்.
- உண்மையான பயனர்களையும் மெதுவான நெட்வொர்க்குகளையும் உருவகப்படுத்தும் (simulate) integration tests-களை எழுதவும்.
- வெளியிடுவதற்கு முன் failure mode analysis மேற்கொள்ளவும்.
- API response times-ஐ மட்டும் அளவிடாமல், முழுமையான பயனர் பயணத்தையும் (user journey) அளவிடவும்.
உங்கள் பணியின் பெயர் உங்கள் திறன்களை விவரிக்கிறது. அது உங்கள் பொறுப்பின் எல்லையைத் தீர்மானிப்பதில்லை.
நீங்கள் ஒரு backend engineer என்றால், பயனர்கள் தடையின்றி பணம் செலுத்துவதை உறுதி செய்வது உங்கள் பொறுப்பு. நீங்கள் ஒரு mobile engineer என்றால், பயனர்களின் நம்பிக்கையைப் பாதுகாப்பது உங்கள் பொறுப்பு.
டிக்கெட்டுகளை முடிப்பது என்பது அடிப்படைத் தேவை மட்டுமே. பயனரின் இறுதித் தேவையை (outcome) முழுமையாக நிறைவேற்றுவதே உங்களின் உயர்ந்த இலக்கு.
ஆதாரம்: https://dev.to/walosha/your-ticket-was-closed-the-user-still-couldnt-pay-14di