نحن عادة لا نعرف مدى اعتمادنا على شيء حتى نفقده. يبدو نظام العمل مستقرًا ما دامت الكهرباء موجودة، والإنترنت يعمل، والحاسوب متصلًا بكل الخدمات التي يحتاجها. الملفات تفتح، المستودعات تتزامن، كلمات المرور تصل، والمراجع متاحة بضغطة زر. ثم ينقطع أحد هذه الخيوط. وفجأة نكتشف أن ملفًا مهمًا موجود فقط في السحابة، أو أن أداة نستخدمها يوميًا لا تستطيع حتى تسجيل الدخول دون إنترنت، أو أن المشروع موجود محليًا لكن التوثيق اللازم لتشغيله ليس كذلك. هذه اللحظة ليست أفضل وقت لاكتشاف نقاط الضعف. الأفضل أن نختبرها ونحن ما زلنا نملك رفاهية الإصلاح.
المرونة ليست فكرة نظرية
يمكن أن نقول إن لدينا Backup. وأن المشروع موجود على Git. وأننا نستطيع العمل Offline. لكن هذه كلها افتراضات حتى يتم اختبارها. في هندسة الأنظمة لا يكفي أن يكون لدينا تصميم جيد على الورق. نحتاج إلى معرفة كيف يتصرف النظام عندما يفقد جزءًا من موارده. والأمر نفسه ينطبق على بيئة العمل الشخصية. السؤال ليس: هل أعتقد أنني أستطيع العمل دون إنترنت؟ بل: ماذا يحدث فعلًا إذا اختفى الإنترنت الآن؟ هذا الفرق الصغير يحول المرونة من شعور بالاطمئنان إلى قدرة يمكن قياسها.
التمرين الأول: ساعة بلا إنترنت
يمكن إجراء اختبار بسيط جدًا. اختر وقتًا لا توجد فيه مكالمة أو عملية حرجة، ثم افصل اتصال الإنترنت عن الجهاز لمدة ساعة. لا تجهّز كل شيء قبلها خصيصًا للاختبار. ابدأ بالمهمة التي كنت ستنفذها أصلًا. افتح المشروع. اكتب. راجع المستندات. شغّل الأدوات المحلية. وكلما وصلت إلى شيء لا تستطيع فعله، سجله. قد تكتشف مثلًا:
- المرجع الذي تحتاجه غير محفوظ محليًا.
- التوثيق التقني موجود فقط على موقع خارجي.
- التطبيق يعمل Offline، لكن تسجيل الدخول لا يعمل.
- بعض ملفات المشروع غير متوفرة إلا على خدمة سحابية.
- لا تعرف آخر حالة للمشروع دون الوصول إلى أداة إدارة المهام.
- بيانات اعتماد معينة لا تستطيع الوصول إليها من دون الشبكة.
بعد ساعة، ستكون لديك خريطة حقيقية للاعتماد على الإنترنت. وهذه الخريطة أثمن من عشرات الافتراضات.
ليس كل اعتماد على الإنترنت مشكلة
من المهم ألا نفهم الاختبار بطريقة متطرفة. هناك أشياء من الطبيعي أن تحتاج إلى الإنترنت. إرسال بريد. رفع تغييرات إلى مستودع بعيد. عقد اجتماع فيديو. مزامنة ملفات. البحث عن معلومات جديدة. هذه ليست نقاط ضعف بحد ذاتها. ما نبحث عنه هو الاعتماد الذي لا توجد حاجة حقيقية له. عدم قدرتك على نشر الكود دون إنترنت أمر طبيعي. لكن عدم قدرتك على قراءة الكود لأن المستودع غير موجود محليًا أمر مختلف. عدم قدرتك على إرسال مستند طبيعي. لكن عدم قدرتك على فتح المستند الذي تعمل عليه لأن نسخته الوحيدة سحابية يستحق المراجعة. المرونة لا تعني إزالة الشبكة من حياتنا. تعني ألا يؤدي غيابها إلى تعطيل أشياء كان يمكن أن تستمر دونها.
التمرين الثاني: وضع الطاقة المحدودة
يمكن تنفيذ اختبار آخر دون قطع الكهرباء فعلًا. افترض ببساطة أن البطارية التي أمامك هي كل الطاقة التي ستحصل عليها خلال الساعات القادمة. ثم راقب بيئة العمل. هل تحتاج إلى تشغيل Docker طوال الوقت؟ هل تحتاج قاعدة البيانات المحلية بينما تكتب مستندًا؟ هل تحتاج عشرين تبويبًا مفتوحًا؟ هل توجد مهمة يمكنك تنفيذها من جهاز لوحي أو هاتف بدل تشغيل الحاسوب؟ الفكرة ليست تحويل العمل إلى سباق لتوفير كل واط. الهدف هو معرفة الحد الأدنى الذي يحافظ على الإنتاج. عندما تعرف هذا الحد مسبقًا، يصبح الانتقال إلى وضع الطاقة المحدودة قرارًا هادئًا بدل أن يبدأ بعد وصول البطارية إلى 8%.
التمرين الثالث: افترض أن الحاسوب الرئيسي غير متاح
هذا الاختبار يكشف نوعًا مختلفًا من الهشاشة. حاول أن تتخيل أن جهازك الرئيسي تعطل أو لم يعد معك. هل تستطيع من جهاز آخر: الوصول إلى المشروع؟ معرفة آخر نسخة؟ الدخول إلى الخادم؟ الوصول إلى مدير كلمات المرور؟ استخدام المصادقة الثنائية؟ قراءة نقاط الاستئناف؟ معرفة أوامر تشغيل النظام؟ قد تكون لديك ثلاث نسخ احتياطية رائعة، لكن لا تستطيع الوصول إليها لأن المفتاح الوحيد موجود على الجهاز المفقود. وهنا نكتشف أن الوصول نفسه جزء من النسخ الاحتياطي.
راقب الاحتكاك، لا الأعطال فقط
أثناء هذه الاختبارات لا تبحث فقط عن الأشياء التي تمنعك من العمل تمامًا. انتبه إلى الأشياء التي تجعل العودة بطيئة. استغرقت سبع دقائق للعثور على مستند. لم تعرف أي نسخة هي الأحدث. نسيت أمر تشغيل الخدمة. احتجت إلى البحث عن اسم خادم تستخدمه كل أسبوع. فتحت خمسة مجلدات قبل أن تجد المشروع. هذه الأمور لا تبدو كوارث. لكنها عندما تتكرر أثناء الانقطاعات تصبح استنزافًا حقيقيًا للوقت والانتباه. يمكن تسمية هذا احتكاك الاستمرارية. وأحيانًا تكون معالجته بسيطة جدًا. ملف README. أو RUNBOOK.md. أو اسم مجلد أفضل. أو ملاحظة تحتوي على آخر خطوة والخطوة التالية.
اختبر العودة إلى العمل أيضًا
من السهل التركيز على الاستمرار أثناء الانقطاع وننسى ما يحدث بعده. جرّب أن تغلق المشروع بعد انتهاء الاختبار، ثم عد إليه بعد عدة ساعات. واسأل: أين توقفت؟ ما آخر تغيير؟ ما المشكلة الحالية؟ ما الخطوة التالية؟ إذا احتجت إلى إعادة قراءة كل شيء لتفهم أين كنت، فهناك جزء من حالة العمل لم يكن محفوظًا. ولهذا فإن نقطة استئناف صغيرة قد تكون واحدة من أعلى الأدوات عائدًا.
أربعة أسطر قد تحفظ نصف ساعة في الجلسة التالية.
لا تحول نتائج الاختبار إلى مشروع ضخم
بعد أول تمرين قد تكتشف عشرات الملاحظات. لا تحاول إصلاحها كلها. اختر أكبر ثلاث نقاط ضعف. مثلًا:
- الملفات الأساسية غير متاحة محليًا.
- بيانات الوصول تعتمد على جهاز واحد.
- لا توجد نقاط استئناف للمشاريع.
أصلحها. ثم اختبر النظام مرة أخرى لاحقًا. بهذا تتحسن المرونة تدريجيًا دون أن تتحول هي نفسها إلى مشروع يستهلك كل وقتك.
الاحتياط الحقيقي هو القدرة على الاستمرار
هناك تصور شائع أن المرونة تعني امتلاك المزيد. بطاريات أكثر. خوادم أكثر. نسخًا أكثر. أدوات أكثر. لكن في بعض الأحيان، المرونة تأتي من شيء مختلف: معرفة ما الذي تحتاجه فعلًا، ومعرفة ما الذي يحدث عندما تفقد الباقي. إذا انقطع الإنترنت، هناك وضع للعمل. إذا أصبحت الطاقة محدودة، هناك وضع آخر. إذا تعطل الجهاز، توجد طريقة للعودة. وإذا توقفت المهمة، توجد نقطة استئناف. هنا لم نمنع الأعطال. بل منعنا الأعطال من أن تتحول كل مرة إلى بداية جديدة. وهذا هو الفارق بين نظام يبدو مستقرًا ونظام يعرف كيف يستمر. المرونة ليست في تجنّب الانقطاع، بل في قدرتك على الاستمرار بعده.