تیکت شما بسته شد. کاربر هنوز نتوانست پرداخت کند.
بکاند شما کد وضعیت ۲۰۰ را برگرداند. اپلیکیشن موبایل خطا نشان داد. کاربر سه بار روی «پرداخت» ضربه زد. سه بار از حساب او کسر شد. یک سفارش انجام شد. حالا موجودی او کم است. لاگهای شما هیچ خطایی را نشان نمیدهند.
هر مهندس وظیفهاش را انجام داد. اما هیچکس مشکل را حل نکرد.
تیمها اغلب نه به دلیل کد بد، بلکه به این دلیل شکست میخورند که کار اشتباهی را انجام میدهند. ممکن است سیستمی را عرضه کنید که بینقص کار میکند، اما تجربه کاربری وحشتناکی ایجاد میکند.
مهندسان جونیور با تیکتها فکر میکنند. تیکت اختصاص داده شد. کد نوشته شد. تستها پاس شدند. PR ادغام شد. تیکت بسته شد.
این طرز فکر با رشد شما، به یک نقطه ضعف تبدیل میشود. مهندسی که تیکتها را میبندد مفید است. اما مهندسی که میپرسد «آیا این واقعاً مشکل بیزنس را حل میکند؟» غیرقابل جایگزین است.
یک جریان پرداخت را در نظر بگیرید. مهندس بکاند یک endpoint میسازد. آن endpoint تراکنشها را پردازش کرده و کدهای صحیح را برمیگرداند. پوشش تست ۱۰۰٪. تیکت بسته شد. مهندس موبایل صفحه را میسازد. آن صفحه endpoint را فراخوانی کرده و پاسخ را نشان میدهد. رابط کاربری روان. تیکت بسته شد.
مشکلی که هیچکس مسئولیتش را نپذیرفت: وقتی بعد از کسر وجه اما قبل از اینکه اپلیکیشن موبایل تاییدیه را دریافت کند، شبکه قطع میشود، چه اتفاقی میافتد؟
بکاند موفقیت را نشان میدهد. اپلیکیشن موبایل خطا نشان میدهد. کاربر دوباره تلاش میکند و دو بار از حسابش کسر میشود.
راه حل فقط یک اصلاح در بکاند یا موبایل نیست. این کار به کلیدهای Idempotency نیاز دارد. اپلیکیشن موبایل باید برای هر تلاش، یک کلید منحصربهفرد تولید کند. بکاند باید از آن کلید استفاده کند تا اطمینان حاصل شود که تلاش مجدد هرگز باعث ایجاد تراکنش تکراری نمیشود.
این راه حل تنها زمانی اتفاق میافتد که مهندسان درباره تجربه کاربری در زمان قطع شبکه با یکدیگر گفتگو کنند.
همین اتفاق برای سختافزار هم میافتد. مهندس سختافزار فریمور (firmware) را عرضه میکند. مهندس موبایل اپلیکیشن را عرضه میکند. مهندس بکاند API را عرضه میکند. هر بخش کار میکند. هر تست پاس میشود.
اما کاربر دکمهای را فشار میدهد و چراغ ۱۱ ثانیه بعد روشن میشود. تأخیر (latency) در شکافهای بین اجزا نهفته است. هیچ مهندس واحدی مسئولیت سرعت سرتاسری (end-to-end) را بر عهده نداشت.
قابلیت اطمینان واقعی، یک ویژگی سیستم است، نه یک ویژگیِ تکتک اجزا.
برای حل این مشکل، باید نحوه کار خود را تغییر دهید:
- به جای تعریف SLOهای صرفاً مربوط به اجزا، SLOهای سرتاسری (end-to-end) تعریف کنید.
- تستهای یکپارچهسازی (integration tests) بنویسید که کاربران واقعی و شبکههای کند را شبیهسازی کنند.
- قبل از عرضه محصول، تحلیل حالتهای شکست (failure mode analysis) انجام دهید.
- کل سفر کاربر را اندازهگیری کنید، نه فقط زمان پاسخگویی API را.
عنوان شغلی شما توصیفکننده مهارتهای شماست، اما تعیینکننده مرز مسئولیتهای شما نیست.
اگر مهندس بکاند هستید، مسئولیت شما تضمین پرداخت بدون نقص کاربران است. اگر مهندس موبایل هستید، مسئولیت شما حفظ اعتماد کاربران است.
بستن تیکتها، کفِ کار است. مالکیتِ نتیجهی کار برای کاربر، سقفِ کار است.
منبع: https://dev.to/walosha/your-ticket-was-closed-the-user-still-couldnt-pay-14di