احجز عرضًا

الاحتياط الذي يجعل النظام المعطّل يبدو سليمًا

نقلنا مرفقات كل العملاء إلى تخزين جديد خلال سبعة أيام. لكن الشيفرة التي جعلت ذلك ممكنًا كانت قادرة أيضًا على إخفاء خطأ في الإعداد إخفاءً تامًا — وتبيّن أن الإصلاح في مكان غير الذي أشارت إليه المراجعة أول الأمر.

في الليلة الأخيرة من سبتمبر فقدت إحدى أكبر المنصات السحابية اتصال بواباتها في ثماني عشرة منطقة لما يقارب ست ساعات. انقطاعات كهذه صاخبة: تحمرّ لوحات المراقبة، وتُحدَّث صفحات الحالة، ويتبعها تقرير ما بعد الحادث. ليست هذه الأعطال التي تقلقنا أكثر. ما يقلقنا هو الهادئ منها — نظام خاطئ في العمق بينما يقول كل فحص إنه سليم. وكدنا نبني واحدًا منها الأسبوع الماضي، عن قصد، ولأسباب وجيهة.

نقل الملفات بينما يستخدمها الناس

كل محادثة على روبوديسك يمكن أن تحمل ملفات: صورة شحنة تالفة، أو رسالة صوتية، أو فاتورة PDF، أو مقطع فيديو لضوء خطأ يومض. تعيش هذه الملفات في تخزين كائنات، بحاوية مستقلة لكل عميل. وفي الأسبوع الماضي أنهينا نقلها كلها من مخزن كنا نشغّله بأنفسنا إلى خدمة سحابية مُدارة — أكثر من ثلاثين عميلًا، يُنقل كل واحد منهم على حدة خلال سبعة أيام.

كان الترتيب مقصودًا. خذ نسخة احتياطية من كل شيء أولًا. طبّق سياسة الاحتفاظ المتفق عليها، تسعين يومًا، قبل النسخ، حتى لا ندفع ثمن نقل ملفات تعهدنا بحذفها. انسخ حاوية كل عميل، ثم انقله خارج ساعات عمله هو — وهذا تطلّب جمع تلك الساعات عميلًا عميلًا، لأن أحدهم يعمل على مدار الساعة وآخر يغلق في الثالثة عصرًا. وبعد كل نقل كان شخص ما يجري الفحوص الستة عشر نفسها يدويًا: إرسال واستقبال صورة، ورسالة صوتية، وملف، وفيديو، وعدة مرفقات معًا؛ ثم معاينة كل منها وتنزيله؛ ورفع شعار؛ وفتح مرفق في محادثة عمرها أشهر. والعملاء الذين يقرأ ذكاؤهم الاصطناعي الصور والرسائل الصوتية خضعوا لفحوص إضافية.

أثبتت هذه الفحوص قيمتها في الليلة الأولى. فشل العميل الأول الذي نُقل في اثنين منها: إرسال عدة مرفقات معًا أعاد خطأ «معامل غير صالح»، وصيغة صور أقل شيوعًا ظهرت مكسورة. توقفنا، وأبقينا العميلين التاليين على التخزين القديم، وأصلحنا الخطأين، ثم واصلنا. ولاحقًا رفضت الوسائط القديمة لأحد العملاء أن تُفتح إطلاقًا — ولم تُفتح من المخزن القديم أيضًا. تلك الملفات كانت مفقودة قبل النقل بزمن طويل، وهي مشكلة مختلفة، ومعرفتها مفيدة في حد ذاتها.

ولم يكن الجزء الأبطأ حيث توقّع أي أحد. شُغّلت الدفعة الأولى، ثلاث حاويات، بستة عشر عاملًا متوازيًا وحدّ زمني قدره اثنتا عشرة ساعة، فبلغت الحد. وحين كان العامل يبدأ النسخ، كان ينقل نصيبه في دقيقة أو اثنتين. ذهب معظم الوقت في سؤال المخزن القديم عن قائمة ما يحتويه. نقل البيانات رخيص؛ أما معرفة ما لديك فقد تكون المهمة كلها.

الاحتياط، وما يمكن أن يخفيه

لعملية نقل كهذه منتصف مُربك. العميل نُقل، لكن ملفًا رفعه قبل النقل بساعة ربما لم يُنسخ بعد. لذلك أُعطيت عمليات القراءة مسارًا احتياطيًا: إذا قال المخزن الجديد إنه لا يحتوي الملف، اسأل القديم. أما الكتابة فلا احتياط لها؛ الملفات الجديدة تذهب إلى المخزن الجديد وحده. هذا ما سمح لنا بنقل العملاء دون تجميد، وهو التصميم الصحيح لهذه المهمة.

كان المهندسون الذين كتبوها يعرفون الخطر. ففي الشيفرة تعليق يشرح لماذا يجب ألا تُفعّل أخطاء الشبكة المسار الاحتياطي: لو تعذّر الوصول إلى المخزن الجديد ببساطة، لذهبت كل قراءة بصمت إلى القديم، ولبدا العميل سليمًا بينما يُخدَم بالكامل من تخزين ما قبل النقل. هذا هو العطل الهادئ بعينه — وفي المراجعة وجدنا بابًا ثانيًا إليه. كانت الحاوية المفقودة تُعامل معاملة الملف المفقود. اكتب اسم حاوية خطأً في إعدادات عميل، أو احذف الحاوية، فتنتقل كل قراءة إلى الاحتياط وتنجح. المرفقات القديمة تُفتح، والموظفون لا يلاحظون شيئًا. وحدها الملفات الجديدة تفشل في الرفع، وهذا يرسل من يحقق في الاتجاه الخطأ، لأن «التخزين معطّل» لا يتفق مع شاشة مليئة بملفات تعمل.

محقّ في الخطر، مخطئ في الإصلاح

اقترحت المراجعة تغييرًا من سطر واحد: التوقف عن احتساب خطأ «لا توجد حاوية بهذا الاسم» على أنه ملف مفقود. وافق المهندس المسؤول عن الشيفرة على وجود الخطر، ثم بيّن أن التغيير ما كان ليغيّر شيئًا. فالحاوية المفقودة لا تصل أبدًا بهذا الاسم. عمليات التنزيل تعامل أي رد «غير موجود» على أنه ملف مفقود دون أن تقرأ ما يقوله المخزن، وفحوص الوجود طلبات بلا محتوى أصلًا، فلا شيء هناك ليُقرأ. لم تكن الثغرة مدخلًا خاطئًا واحدًا في قائمة، بل كانت في كل مزوّد، عبر كل مسار.

فانتقل الإصلاح إلى مكان آخر. بدل محاولة التمييز بين حاوية مفقودة وملف مفقود في كل طلب على حدة — وهو ما كان سيعني مطابقة رسائل خطأ تصوغها كل مكتبة بطريقتها — تحقّق من وجود الحاوية عند بدء تشغيل الخدمة وكلما نُقل عميل، وارفض العمل إن لم تكن موجودة. هذا الإصلاح قيد المراجعة الآن. إنه يستبدل تخمينًا يُجرى عند كل قراءة بيقين يُثبَت مرة واحدة، في اللحظة التي يكون فيها رؤية الخطأ أرخص ما يكون.

وهناك سبب ثانٍ للاهتمام، وهو السؤال المطروح الآن: متى يمكن إيقاف المخزن القديم؟ ما دام الاحتياط قادرًا على خدمة القراءات بصمت، لا يستطيع أحد أن يجزم بأنه لم يعد يخدم بعضها. الاحتياط الذي جعل النقل آمنًا هو نفسه ما يجعل الخطوة الأخيرة منه صعبة الحسم. وينطبق المنطق نفسه على المكان المسموح أن تعيش فيه بيانات العملاء: عبارة «نقلناها» لا تصدق إلا إذا لم يكن شيء ما يزال يقرأ من المكان القديم.

ما يمكن تعميمه

المسارات الاحتياطية هي المكان الذي تتعلّم فيه الأنظمة أن تكذب بأدب. وُجدت لتُبقي العميل يعمل بينما شيء ما في العمق خاطئ، وهي تؤدي هذه المهمة بقدر ما تخفيه تمامًا. ومن هنا ثلاث عادات. حدّد كتابةً أي الأعطال يجوز للاحتياط أن يمتصها — ملف مفقود، نعم؛ حاوية مفقودة أو مخزن لا يمكن الوصول إليه، أبدًا — وافحص الإعدادات مرة واحدة وبصوت عالٍ عند بدء التشغيل، بدل استنتاجها من الأخطاء في كل طلب. واحسب كل قراءة يخدمها الاحتياط، لأن احتياطًا لا يراه أحد هو نظام إنتاج ثانٍ لا يشغّله أحد عن قصد. وامنحه تاريخ انتهاء: النقل ينتهي يوم يصل ذلك العدد إلى الصفر ويبقى عنده، لا يوم تُنسخ آخر حاوية.

شاهدها تعمل على حركتك أنت.

ثلاثون دقيقة مع مهندس تجربة عملاء. بلا شرائح عرض.