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