أذكر ذلك اليوم جيدًا، كان يوم ثلاثاء رماديًا في المكتب. وصلني إيميل من “سامر”، أحد أمهر المطورين في فريقي، بعنوان مقتضب: “استقالة”. شعرت وكأن دلوًا من الماء البارد قد سُكب فوق رأسي. سامر لم يكن مجرد مطور، كان هو “الساحر” الذي يعرف كل خبايا نظامنا القديم، وهو الوحيد الذي يفهم شيفرة إطلاق نماذج الذكاء الاصطناعي الجديدة على الخوادم الإنتاجية.
في الأسابيع التي تلت، عشنا في جحيم حقيقي. كل مهمة كانت تحتاج سامر تحولت إلى لغز. “كيف كنا نربط قاعدة البيانات X مع الواجهة Y؟”، “ما هي كلمة السر لخادم الاختبارات المؤقت؟”، “لماذا يتعطل النظام كل أول شهر؟ سامر كان يعرف السبب!”. كنا نقضي ساعات في البحث في محادثات قديمة ورسائل بريد إلكتروني، محاولين تجميع قطع الأحجية التي تركها وراءه. ضاعت مواعيد تسليم، وزاد التوتر، وشعرت أن الفريق الذي بنيته لسنوات بدأ يتفكك. يومها، وقفت أمام الفريق وقلت لهم بلهجتي الفلسطينية الواضحة: “يا جماعة، هيك ما بنفع! إحنا مش شركة، إحنا صرنا مجموعة جزر معزولة. لازم نلاقي حل.”
هذه الأزمة كانت الشرارة التي قادتنا إلى تبني مفهوم غيّر طريقة عملنا تمامًا: كتيبات التشغيل (Playbooks).
ما هي ‘كتيبات التشغيل’ (Playbooks) وليش هي مش مجرد توثيق عادي؟
عندما يسمع المبرمج كلمة “توثيق” (Documentation)، غالبًا ما يتخيل مجلدات ضخمة من النصوص النظرية التي لا يقرأها أحد، والتي تصبح قديمة بعد أسبوع من كتابتها. لكن كتيبات التشغيل شيء مختلف تمامًا.
ببساطة، كتيب التشغيل هو دليل إرشادي، خطوة بخطوة، لتنفيذ عملية محددة ومتكررة. فكر فيه كـ “وصفة طبخ” للمهام التقنية. الوصفة لا تشرح لك تاريخ الطماطم، بل تخبرك مباشرة: “أضف ملعقتين من معجون الطماطم، ثم حرك لمدة دقيقتين”. هذا هو جوهر كتيبات التشغيل.
الفرق الجوهري: التوثيق التقليدي يجيب على سؤال “ما هو هذا الشيء؟”، بينما كتيب التشغيل يجيب على سؤال “كيف أفعل هذا الشيء؟”.
الزبدة (أي الخلاصة) هي أن كتيب التشغيل مصمم للاستخدام تحت الضغط. عندما يتعطل الخادم في منتصف الليل، أنت لا تريد قراءة رواية عن بنية الخادم، بل تريد قائمة خطوات واضحة لإعادة تشغيله بأمان.
أمثلة على عمليات تحتاج لكتيب تشغيل:
- نشر تحديث جديد على الخادم الإنتاجي (Deployment).
- إعداد بيئة عمل لمطور جديد (New Developer Onboarding).
- الاستجابة لحادثة أمنية (Security Incident Response).
- إنشاء نسخة احتياطية من قاعدة البيانات واسترجاعها.
- تشخيص وحل خطأ شائع ومتكرر.
كيف تبني أول كتيب تشغيل لفريقك؟ (خطوات عملية من الميدان)
البداية قد تبدو صعبة، لكن السر يكمن في البدء صغيرًا والتركيز على الألم. لا تحاول توثيق كل شيء دفعة واحدة. ابدأ بالعمليات التي تسبب لك أكبر قدر من الصداع.
الخطوة الأولى: تحديد العمليات الحرجة (وين بوجعك؟)
اجمع فريقك واسألهم سؤالًا واحدًا: “ما هي المهمة التي إذا غاب الشخص المسؤول عنها غدًا، سنتورط جميعًا؟”. الإجابات التي ستحصل عليها هي نقطة البداية المثالية. في حالتنا، كانت أولى الأولويات هي:
- عملية نشر الكود على خادم الاختبار (Staging).
- إعداد حسابات الوصول لمطور جديد.
- إعادة تشغيل خدمة معالجة البيانات عند توقفها.
ابدأ بواحدة فقط. اختر الأكثر إيلامًا.
الخطوة الثانية: هيكل الكتيب الموحّد (الترتيب بغلّب الشطارة)
لضمان أن تكون كل الكتيبات سهلة القراءة والفهم، اتفقنا على هيكل موحد. هذا يسهل على أي شخص في الفريق فتح أي كتيب وفهم محتواه بسرعة. هيكلنا كان كالتالي:
- الغرض (Purpose): جملة واحدة تشرح الهدف من هذا الكتيب. مثال: “هذا الكتيب يشرح كيفية نشر نسخة جديدة من الواجهة الأمامية على بيئة الاختبار.”
- المتطلبات المسبقة (Prerequisites): ما الذي يحتاجه المستخدم قبل البدء؟ (برامج معينة، صلاحيات وصول، مفاتيح API).
- الخطوات (Steps): هنا يكمن قلب الكتيب. خطوات مرقمة، واضحة، ومباشرة. كل خطوة يجب أن تكون فعلًا واحدًا بسيطًا.
- نقاط التحقق (Verification): كيف يتأكد المستخدم من أن الخطوة نجحت؟ (رؤية رسالة معينة، التحقق من رابط، فحص سجلات الأخطاء).
- استكشاف الأخطاء وإصلاحها (Troubleshooting): ماذا تفعل إذا ساءت الأمور؟ مثال: “إذا ظهر الخطأ ‘Permission Denied’، تأكد من أن مفتاح SSH الخاص بك مضاف إلى الخادم.”
- لمن تسأل؟ (Escalation): إذا فشل كل شيء، من هو الشخص أو الفريق الذي يجب التواصل معه.
الخطوة الثالثة: كتابة المحتوى (مثال عملي لكتيب نشر)
لنجعل الأمر عمليًا، هذا مثال مبسط جدًا لجزء من كتيب تشغيل لنشر تحديث باستخدام سكربت بسيط. افترض أننا نستخدم أداة مثل Notion أو Confluence أو حتى ملفات Markdown في مستودع Git.
عنوان الكتيب: [P-001] نشر الواجهة الأمامية على بيئة الاختبار
الغرض: نشر آخر التغييرات من الفرع `develop` إلى خادم الاختبار.
المتطلبات المسبقة:
- وصول SSH إلى خادم الاختبار (
staging.our-app.com). - أن تكون عضوًا في فريق المطورين على GitHub.
الخطوات:
- افتح الطرفية (Terminal) على جهازك.
- اتصل بالخادم عبر SSH بالأمر التالي:
ssh ahmad@staging.our-app.com - انتقل إلى مجلد المشروع:
cd /var/www/frontend - شغّل سكربت النشر الآلي. هذا السكربت سيقوم بسحب آخر التحديثات، تثبيت الحزم، وبناء المشروع.
./scripts/deploy-staging.sh
نقاط التحقق:
- يجب أن ترى رسالة “✅ Deployment to staging successful!” في نهاية السكربت.
- افتح الرابط https://staging.our-app.com في متصفحك وتأكد من أن التغييرات الجديدة ظاهرة.
استكشاف الأخطاء وإصلاحها:
- خطأ: `npm install` فشل.
- السبب المحتمل: مشكلة في الاتصال بالإنترنت على الخادم أو مشكلة في npm.
- الحل: حاول حذف مجلد `node_modules` وتشغيل السكربت مرة أخرى.
rm -rf node_modules && ./scripts/deploy-staging.sh
كيف تحول ‘كتيبات التشغيل’ من عبء إلى عادة وثقافة في الفريق؟
هنا يكمن التحدي الأكبر. كتابة أول كتيب سهلة، لكن المحافظة على هذه العادة وجعلها جزءًا من ثقافة الفريق هو الأصعب. إليك بعض النصائح من خبرتي الشخصية:
نصيحة أبو عمر الذهبية: لا توثّق كل شيء، وثّق ما يتكرر وما يؤلم
الحماس في البداية قد يدفعك لمحاولة كتابة كتيبات لكل شيء. قاوم هذا الإغراء! سيرهق الفريق ويجعل العملية تبدو كعبء. ركز فقط على العمليات المتكررة (تحدث أكثر من مرتين)، والعمليات الحرجة (غياب المسؤول عنها يسبب كارثة).
اجعلها جزءًا من ‘تعريف الإنجاز’ (Definition of Done)
في منهجيات الأجايل، لدينا ما يسمى بـ “تعريف الإنجاز”. أضفنا بندًا جديدًا إليه: “هل تم إنشاء أو تحديث كتيب التشغيل المتعلق بهذه الميزة؟”. هذا يضمن أن المعرفة لا تبقى في رأس المطور الذي أنشأ الميزة، بل تنتقل مباشرة إلى “ذاكرة الفريق”.
“قاعدة الكشافة”: اترك المكان أفضل مما وجدته
شجعنا كل فرد في الفريق على اتباع هذه القاعدة البسيطة: إذا استخدمت كتيب تشغيل ووجدت أن خطوة ما غير واضحة، أو أمرًا قديمًا، أو أن هناك طريقة أفضل للقيام بذلك، خذ 5 دقائق من وقتك وقم بتحديث الكتيب. هذا التحسين المستمر والتراكمي هو ما يحافظ على حيوية الكتيبات وقيمتها.
استخدم الأدوات المناسبة والبسيطة
الأداة ليست هي الحل، بل العملية. يمكنك البدء بـ Google Docs أو مستودع Git خاص بملفات Markdown. نحن نستخدم Notion حاليًا لأنه يتيح لنا إنشاء قوالب، ووضع علامات (tags)، والبحث بسهولة. المهم هو أن تكون الأداة متاحة للجميع وسهلة التعديل.
الثمار التي جنيناها: من فريق على حافة الهاوية إلى مؤسسة معرفية صامدة
بعد مرور عام على تبنينا لكتيبات التشغيل، تغيرت الأمور بشكل جذري:
- انضمام المطورين الجدد: أصبح أسرع وأكثر سلاسة. المطور الجديد يحصل في يومه الأول على مجموعة من الكتيبات التي تمكنه من إعداد بيئة عمله، نشر أول تغيير له، وفهم العمليات الأساسية دون الحاجة إلى مقاطعة زملائه باستمرار.
- الاستقالات والإجازات: لم تعد كارثة. عندما يستقيل شخص ما، تكون 80% من معرفته العملية موثقة بالفعل. عملية التسليم أصبحت تركز على السياق الاستراتيجي بدلًا من التفاصيل التقنية الدقيقة.
- تقليل الأخطاء البشرية: عندما تتبع قائمة خطوات واضحة، يقل احتمال نسيان خطوة مهمة، خاصة في المهام التي تتم تحت ضغط.
- راحة البال (لي شخصيًا): أصبحت أستطيع أخذ إجازة وأنا مطمئن أن الفريق لديه الموارد اللازمة للتعامل مع معظم المشاكل الشائعة. لم يعد هاتفي يرن في منتصف الليل بسبب مشكلة يمكن حلها بخمس خطوات بسيطة.
خلاصة أبو عمر: استثمر في ذاكرة فريقك 🧠
في عالم البرمجة سريع التغير، الكود الذي نكتبه اليوم قد يصبح قديمًا غدًا. لكن الأصول الحقيقية لأي شركة تقنية هي المعرفة الجماعية والقدرة على التنفيذ بكفاءة. فقدان المعرفة مع كل استقالة هو نزيف بطيء ولكنه قاتل.
كتيبات التشغيل ليست حلًا سحريًا، بل هي استثمار منضبط في بناء “ذاكرة مؤسسية” صامدة. إنها تحول المعرفة الفردية المحبوسة في عقول الأشخاص إلى أصل مشترك ومتاح للجميع.
نصيحتي الأخيرة لك: لا تنتظر حتى تحدث أزمة مثل التي مررت بها. ابدأ اليوم. اختر عملية واحدة مؤلمة، واكتب أول كتيب تشغيل لك. قد تكون هذه الخطوة الصغيرة هي أهم ما ستفعله لضمان استمرارية ونجاح فريقك على المدى الطويل.
