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