DevOps للمختبِرين
DevOps طريقة عمل يتشارك فيها التطوير (بما فيه الاختبار) والعمليات (Operations) هدفاً واحداً: إيصال التغييرات إلى المستخدمين بسرعة وأمان، والحفاظ على سلامة المنتج بعد إطلاقه. ويصفها منهج ISTQB للمستوى التأسيسي v4.0 بأنها نهج تنظيمي يتطلب تحولاً ثقافياً، وتدعمه استقلالية الفريق والتغذية الراجعة السريعة وسلاسل الأدوات المتكاملة وممارسات مثل التكامل المستمر (Continuous Integration) والتسليم المستمر (Continuous Delivery).
فمثلاً، بدلاً من أن يفحص المختبِرون ميزة مكتملة بعد أسبوع ثم يثبّتها فريق العمليات في ليلة إصدار، يُطلق فريق DevOps الميزة على شكل تغييرات صغيرة؛ يُبنى كل تغيير ويُختبر آلياً خلال دقائق من إيداعه، ويُنشر مع فحص صحة (Health check)، ويُراقَب في الإنتاج.
لماذا يهم
عندما يعمل من يبنون المنتج ومن يختبرونه ومن يشغّلونه في جزر منفصلة، تتراكم التغييرات في إصدارات كبيرة محفوفة بالمخاطر، وتصل الملاحظات عن العيب بعد أيام من كتابة الكود، وتبلغ مشكلات الإنتاج الفريقَ عبر مستخدمين مستائين.
وبالنسبة إلى المختبِر، يغيّر DevOps طبيعة العمل ولا يلغيه. فالإصدارات أكثر تكراراً من أن تُجرى معها جولة انحدار يدوية كاملة في كل مرة، لذا يجب أتمتة الفحوص المتكررة وجعلها جديرة بالثقة، بينما تزداد أهمية الاختبار الاستكشافي وتحليل المخاطر، لأن الفحوص المؤتمتة لا تجد إلا ما فكّر فيه أحدٌ مسبقاً. والمختبِر الذي يفهم خط الأنابيب (Pipeline) وإشارات الإنتاج ومقاييس التسليم يستطيع أن يبيّن أين تضيع الجودة، وأن يدافع عن الإصلاح بالبيانات.
ثقافة أولاً، ثم مجموعة ممارسات
تجمع الكلمة بين التطوير (Development) والعمليات (Operations). والمقصود ليس مسمى وظيفياً ولا أداة، بل إزالة الجدار بين من يغيّرون النظام ومن يحافظون على تشغيله. يتشارك الفريق كله مسؤولية المنتج في الإنتاج، ويتعامل مع الإخفاقات بوصفها فرصة للتعلم لا مناسبة للّوم، ويحسّن طريقة عمله بخطوات صغيرة كما رأيت في درس كانبان. وتلخّص بعض الفرق الفكرة في الاختصار CALMS: الثقافة (Culture) والأتمتة (Automation) والتفكير اللين (Lean) والقياس (Measurement) والمشاركة (Sharing).
- التحكم بالإصدارات لكل شيء: الكود والاختبارات وتعريفات خط الأنابيب والإعدادات والبنية التحتية.
- الدفعات الصغيرة: تغييرات صغيرة كثيرة بدلاً من إصدارات كبيرة قليلة، يسهل اختبار كل منها والتراجع عنه.
- التكامل المستمر والتسليم المستمر: خط أنابيب مؤتمت يبني كل تغيير ويختبره ويجهّزه للإصدار (وهو موضوع الدرس التالي).
- البنية التحتية ككود (Infrastructure as Code): تُبنى البيئات من سكربتات، فيمكن أن تطابق بيئةُ الاختبار الإنتاجَ.
- المراقبة ومراجعات ما بعد الحادثة دون لوم: تتحول كل حادثة إلى تحسين.
حلقة DevOps: الاختبار في كل مرحلة
كثيراً ما تُرسم DevOps حلقةً لا تنتهي: التخطيط، والبرمجة، والبناء، والاختبار، والإصدار، والنشر، والتشغيل، والمراقبة. هذه صورة شائعة لا معيار، لكنها تُظهر أن «الاختبار» مرحلة واحدة، بينما تجري أنشطة الاختبار في المراحل كلها.
في التخطيط تناقش معايير القبول وتتفق على كيفية اختبار كل تغيير ومراقبته. وفي البرمجة والبناء تقدّم اختبارات الوحدة التي يكتبها المطورون والتحليلُ الساكن تغذيةً راجعة خلال دقائق. وفي الاختبار تعمل اختبارات الانحدار واختبارات API المؤتمتة بينما تستكشف أنت الجديد. وفي الإصدار تغذّي نتائج الاختبار والمخاطر المعروفة بوابةَ الجودة (Quality Gate)، وهي نقطة فحص يجب أن يستوفي فيها التغيير معايير متفقاً عليها قبل أن ينتقل إلى المرحلة التالية. وفي النشر تتحقق اختبارات الدخان (Smoke Tests)، أي الفحوص السريعة لعمل الوظائف الرئيسية بعد النشر، ومعها فحوص الصحة، من النسخة الجديدة مقابل معايير تراجع (Rollback) متفق عليها. وفي التشغيل والمراقبة تكشف الحوادث وإشارات الإنتاج ما فات الاختبار، ويعود كل اكتشاف إلى التخطيط التالي اختباراً جديداً.
- 1التخطيطناقش معايير القبول، واتفق على كيفية اختبار كل تغيير ومراقبته
- 2البرمجةيكتب المطورون اختبارات الوحدة مع الكود
- 3البناءتقدّم اختبارات الوحدة والتحليل الساكن تغذية راجعة خلال دقائق
- 4الاختبارتعمل اختبارات الانحدار وAPI المؤتمتة بينما يستكشف المختبِر الجديد
- 5الإصدارتغذّي نتائج الاختبار والمخاطر المعروفة بوابة الجودة
- 6النشراختبارات الدخان وفحوص الصحة مقابل معايير تراجع متفق عليها
- 7التشغيلتكشف الحوادث ما فات الاختبار
- 8المراقبةإشارات الإنتاج مثل زمن الاستجابة ومعدلات الأخطاء
طوال الخطوات 1–8 تجري أنشطة الاختبار في كل مرحلة، لا في مرحلة الاختبار وحدها.
عودة إلى الخطوة 1 يعود كل اكتشاف إلى التخطيط التالي اختباراً جديداً
طريقة شائعة لرسم DevOps لا معيار: تختلف الفرق في تسمية المراحل وتقسيمها.
موقع ضمان الجودة: الأتمتة والتغذية الراجعة السريعة والمراقبة
يعدّد منهج ISTQB ما تقدمه DevOps للاختبار، ومنه تغذية راجعة سريعة عن جودة الكود وعن الانحدار، وبيئات اختبار مستقرة، واهتمام أكبر بالأداء والموثوقية، وتقليل الاختبار اليدوي المتكرر. ويذكر أيضاً مخاطر وتحديات: يجب تعريف خط أنابيب التسليم وإعداده، وإدخال أدوات CI/CD وصيانتها، وتحتاج أتمتة الاختبار إلى موارد إضافية وقد يصعب إنشاؤها وصيانتها. ويبقى الاختبار اليدوي، ولا سيما من منظور المستخدم، ضرورياً. وتتوزع مساهمة المختبِر على ثلاثة مجالات.
- الأتمتة: اتفق مع الفريق على الفحوص التي تعمل مع كل تغيير وعلى مستواها (معظمها اختبارات وحدة وAPI، وقليل من رحلات المستخدم الشاملة End-to-End)، وحافظ على موثوقيتها. فالاختبار المتذبذب (Flaky)، أي الذي ينجح أو يفشل عشوائياً على الكود نفسه، يعلّم الفريق تجاهل البناءات الحمراء.
- التغذية الراجعة السريعة: الفحص الذي يفشل بعد خمس دقائق من الإيداع يصلحه المطور الذي كتب الكود للتو، أما العيب نفسه إذا اكتُشف بعد أسبوعين فيكلّف تبديل سياق وتقرير خطأ وإعادة اختبار. ويؤكد وصف Martin Fowler للتكامل المستمر على إبقاء البناء سريعاً.
- المراقبة: الإنتاج وحده فيه مستخدمون وبيانات وحمل حقيقية. تعرّف على ما يراقبه الفريق، إذ يوصي كتاب SRE من Google بالإشارات الذهبية الأربع: زمن الاستجابة (Latency) والحركة (Traffic) والأخطاء (Errors) والتشبّع (Saturation)، واطلب فحوصاً كانت ستلتقط الحوادث الأخيرة، مثل تسجيل دخول اصطناعي (Synthetic login) كل بضع دقائق.
جرّبها: مولّد سيناريوهات الانحدار جرّبها: فاحص صحة API جرّبها: محلّل زمن الاستجابة
مقاييس DORA: إشارات على جودة التسليم
يصف برنامج DORA (DevOps Research and Assessment)، وهو برنامج بحثي تديره Google Cloud، أداءَ التسليم بخمسة مقاييس: ثلاثة للإنتاجية (Throughput)، أي سرعة وصول التغييرات إلى المستخدمين، واثنان لعدم الاستقرار (Instability)، أي عدد المرات التي تضرّهم فيها. فحزمة الاختبار البطيئة أو المتذبذبة تطيل زمن التنفيذ، وثغرات الاختبار تظهر في صورة عمليات نشر فاشلة. اقرأ المقاييس إشاراتٍ على منظومة التسليم كلها، لا درجاتٍ للمختبِرين، وقِس تطبيقاً أو خدمةً واحدة في كل مرة وقارنها باتجاهها هي.
- زمن تنفيذ التغيير (Change lead time)، للإنتاجية: الزمن من الإيداع حتى التشغيل في الإنتاج. وهو يبدأ من الإيداع، لذا يكون أقصر من زمن التسليم (Lead Time) الذي تتابعه فرق كانبان كثيرة من الطلب حتى التسليم.
- تكرار النشر (Deployment frequency)، للإنتاجية: عدد مرات وصول التغييرات إلى الإنتاج.
- زمن التعافي من النشر الفاشل (Failed deployment recovery time)، للإنتاجية: المدة اللازمة للتعافي بعد نشر يفشل ويتطلب تدخلاً فورياً.
- نسبة فشل التغييرات (Change fail rate)، لعدم الاستقرار: نسبة عمليات النشر التي تتطلب تدخلاً فورياً بعدها، مثل التراجع أو إصلاح عاجل (Hotfix)؛ وهي أقرب إشارة على مستوى التسليم إلى العيوب المتسرّبة.
- نسبة إعادة العمل في النشر (Deployment rework rate)، لعدم الاستقرار: نسبة عمليات النشر غير المخطط لها التي تسببها حادثة في الإنتاج.
مثال تطبيقي: شهر من بيانات التسليم
فريق يدير متجراً إلكترونياً يعرض بيانات التسليم في الاجتماع الاسترجاعي (Retrospective) الشهري، مقارناً الأسابيع 5–8 بالأسابيع الأربعة التي سبقتها.
| مقياس DORA | الأسابيع 1–4 | الأسابيع 5–8 | التغيّر |
|---|---|---|---|
| تكرار النشرالإنتاجية | 12 | 16 | أكثر تكراراً |
| زمن تنفيذ التغيير (الوسيط)الإنتاجية | يومان | 3 أيام | أبطأ |
| زمن التعافي من النشر الفاشل (الوسيط)الإنتاجية | 45 دقيقة | 3 ساعات | أبطأ |
| نسبة فشل التغييراتعدم الاستقرار | 1 من 12 (8%) | 4 من 16 (25%) | أسوأ |
| نسبة إعادة العمل في النشرعدم الاستقرار | 1 من 12 (8%) | 3 من 16 (19%) | أسوأ |
- ساء
صار الفريق ينشر أكثر، لكن عدم الاستقرار ارتفع والتعافي صار أبطأ، فالسرعة الإضافية ليست تحسناً. والمقياس يدلّك أين تبحث لا لماذا حدث الخلل، لذا يفحص المختبِر عمليات النشر الأربع الفاشلة وزيادةَ زمن التنفيذ.
- إخفاقان في الدفع: كان خط الأنابيب يختبر مقابل نسخة محاكاة (Mock) من مزوّد الدفع فقط، وكان المزوّد قد غيّر حقلاً في واجهته البرمجية. الإجراء: اختبار API ليلي مقابل البيئة التجريبية (Sandbox) للمزوّد.
- ترحيل (Migration) لقاعدة البيانات انتهت مهلته على بيانات بحجم الإنتاج. الإجراء: التدرّب على الترحيلات في Staging على نسخة مجهّلة بالحجم نفسه.
- خصم خاطئ أبلغ عنه العملاء بعد ساعات، والإخفاقات التي تُكتشف بهذه الطريقة هي التي رفعت زمن التعافي. الإجراء: اختبار دخان بعد النشر يضع طلباً تجريبياً ويفحص إجماليه.
- طال زمن التنفيذ لأن التغييرات انتظرت جولة انحدار يدوية تُجرى مرتين في الأسبوع. الإجراء: أتمتة الفحوص الثابتة وتخصيص جلسات الاستكشاف للمناطق المتغيرة، وهو تفكير زمن الانتظار نفسه في كانبان.
النسخة النصية
Online shop, production deployments Weeks 1-4 Weeks 5-8
Deployment frequency 12 16
Change lead time (median) 2 days 3 days
Failed deployment recovery (median) 45 min 3 h
Change fail rate 1 of 12 (8%) 4 of 16 (25%)
Deployment rework rate 1 of 12 (8%) 3 of 16 (19%)أخطاء شائعة
- التعامل مع DevOps كأداة أو مسمى وظيفي، بينما لا يزال المختبِرون والمطورون والعمليات يمرّرون العمل من فوق الجدار.
- الاعتقاد بأن الأتمتة تحلّ محل المختبِرين، مع أن الفحوص المؤتمتة لا تؤكد إلا ما فكّر فيه أحدٌ مسبقاً.
- إعادة تشغيل البناءات الحمراء حتى تنجح. فكل فشل غير مفسَّر إما عيب وإما اختبار متذبذب، وكلاهما يحتاج إلى مالك.
- التوقف عند النشر بدلاً من السؤال عمّا يُراقَب وكيف ستعرف أن الإصدار أخفق.
- استخدام مقاييس DORA لترتيب الفرق أو الأفراد، أو مطاردة مقياس واحد وحده؛ فزيادة عمليات النشر مع ارتفاع نسبة فشل التغييرات ليست تقدماً.
من منظور ضمان الجودة
في فريق DevOps يمتد عملك على الحلقة كلها. ففي جلسات التهذيب (Refinement) تسأل كيف ستُختبر القصة وكيف سيعرف الفريق أنها تعمل في الإنتاج. وأثناء التطوير تتفق على الفحوص التي تنتمي إلى خط الأنابيب، وتراجع نتائج كل تغيير بدلاً من انتظار مرحلة اختبار. وقبل الإصدار ترفع صوتك حين تكون البوابة خضراء وهناك خطر لم يُختبر، وبعده تراجع نتائج اختبارات الدخان ولوحات المراقبة.
لكل نشر فاشل أو حادثة، سجّل ما الذي أخفق، وكيف اكتُشف، وكم استغرق التعافي، وأي اختبار أو مراقبة كانت ستلتقطه أبكر، واعرض هذه القائمة في الاجتماعات الاسترجاعية مع اتجاه مقاييس DORA. واطلب الوصول إلى السجلات (Logs) ولوحات المراقبة، فأنت لا تستطيع اختبار ما لا تراه.
تمرين عملي
اقرأ أسبوعاً من عمليات النشر
فريق ينشر واجهة API لطلب الطعام. باستخدام سجل الأسبوع أدناه، احسب مقاييس DORA الخمسة، واقترح لكل نشر فاشل اختباراً أو مراقبة واحدة كانت ستمنعه أو تقصّر التعافي منه، واذكر ما لا تستطيع بيانات أسبوع واحد أن تخبرك به.
Food-ordering API: production deployments, one week
Lead time = from commit to production
# Deployed Lead time Result
1 Sun 10:00 20 h OK
2 Mon 11:00 18 h OK
3 Mon 16:00 75 h Login returns 500 when two-factor sign-in is on;
rolled back at 16:50
4 Tue 12:00 26 h OK
5 Wed 09:30 16 h Receipts show prices without the currency;
a customer reports it at 12:00
6 Wed 13:30 1 h Hotfix for #5 (unplanned); receipts correct
7 Thu 14:00 28 h OK
8 Thu 18:00 55 h OK- عُدّ عمليات النشر واحسب الوسيط لزمن تنفيذ التغيير.
- حدّد عمليات النشر التي احتاجت تدخلاً فورياً وأزمنة التعافي منها.
- حدّد عمليات النشر غير المخطط لها.
- اقترح فحصاً أو مراقبة لكل إخفاق، وسمِّ مرحلة الحلقة التي يعمل فيها.
إظهار الإجابة النموذجية
تكرار النشر: 8 عمليات في الأسبوع (7 مخطط لها وإصلاح عاجل واحد). زمن تنفيذ التغيير بعد الترتيب: 1، 16، 18، 20، 26، 28، 55، 75 ساعة، والوسيط (20 + 26) / 2 = 23 ساعة. واسأل لماذا استغرق النشران #3 و#8 كل هذا الوقت.
نسبة فشل التغييرات: النشر #3 (تراجع) والنشر #5 (إصلاح عاجل)، أي 2 من 8، وهي 25%. التعافي: 50 دقيقة للنشر #3، و4 ساعات للنشر #5 (من 09:30 حتى الإصلاح في 13:30)؛ ومع إخفاقين فقط اذكر القيمتين كلتيهما. نسبة إعادة العمل في النشر: النشر #6، أي 1 من 8، وهي 12.5%.
النشر #3: اختبار API مؤتمت لتسجيل الدخول مع تفعيل التحقق بخطوتين (Two-factor) وتعطيله (مرحلة الاختبار)، وتسجيل دخول اصطناعي مع تنبيه على أخطاء تسجيل الدخول (مرحلة المراقبة). ويُظهر التعافي خلال 50 دقيقة أن التراجع نجح.
النشر #5: فحص لتنسيق الإيصال، بما فيه العملة، ضمن حزمة الانحدار (مرحلة الاختبار)، وطلب تجريبي ضمن اختبار دخان بعد النشر يفحص الإيصال (مرحلة النشر). اكتشفه عميل بعد ساعتين ونصف، أي أن المراقبة لم تلتقطه.
أسبوع واحد و8 عمليات نشر أقل من أن تكشف اتجاهاً، والأرقام لا تقول من يُلام، ولا تُظهر العيوب التي لم يلاحظها أي مستخدم بعد.
أسئلة شائعة
هل أحتاج إلى تعلّم البرمجة للعمل في فريق DevOps؟
تحتاج إلى ما يكفي لقراءة الاختبارات المؤتمتة وصيانتها، وقراءة نتائج خط الأنابيب وسجلاته، وتشغيل سكربتات بسيطة، ولا يلزمك أن تكون مطوراً متفرغاً. وتقدّر الفرق المختبِر الذي يعمل مع المطورين على كود الاختبارات ويفهم ما تفحصه كل مرحلة من خط الأنابيب. وتبني وحدات الأتمتة اللاحقة في خارطة الطريق هذه المهارات.
هل DevOps هو نفسه CI/CD؟
لا. CI/CD مجموعة ممارسات وأدوات تعتمد عليها فرق DevOps، أما DevOps فطريقة العمل الأوسع التي تشمل أيضاً الثقافة والمسؤولية المشتركة والمراقبة والتعلّم من الحوادث. ويشرح الدرس التالي التكامل المستمر والتسليم المستمر والنشر المستمر.
هل مقاييس DORA مقاييسُ اختبار؟
ليس مباشرةً، فهي تقيس منظومة التسليم كلها لا فريق الاختبار. لكن الاختبار يؤثر فيها بقوة: مدة حزمة الاختبار جزء من زمن تنفيذ التغيير، والعيوب المتسرّبة من الاختبار ترفع نسبة فشل التغييرات. استخدمها إلى جانب مقاييس الاختبار مثل معدل تسرّب العيوب، لا بديلاً عنها.
هل يعني DevOps الاختبار في الإنتاج بدلاً من الاختبار قبل الإصدار؟
لا. يبقى الاختبار قبل الإصدار أساسياً، وتضيف DevOps المراقبة والفحوص في الإنتاج لأن بعض المشكلات لا تظهر إلا مع مستخدمين وبيانات وحمل حقيقية. أما ممارسات الإزاحة لليمين (Shift-right) مثل الإطلاق الكناري (Canary release) فيتناولها درس الإزاحة لليسار والإزاحة لليمين.
المراجع
- ISTQB Certified Tester Foundation Level (CTFL) v4.0المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
- DORA's software delivery performance metricsمقاييس DORA للتسليم — زمن تنفيذ التغيير وتكرار النشر وزمن التعافي من النشر الفاشل ونسبة فشل التغييرات وما يتصل بها — مجمّعة حسب الإنتاجية وعدم الاستقرار.
- Monitoring Distributed Systems — Site Reliability Engineering (Rob Ewaschuk)إرشادات SRE من Google في المراقبة: المراقبة من الخارج (black-box) مقابل المراقبة من الداخل (white-box)، والإشارات الذهبية الأربع — زمن الاستجابة والحركة والأخطاء والتشبّع.
- Continuous Integration (Martin Fowler)الوصف الأكثر استشهاداً للتكامل المستمر: ادمج كثيراً، واجعل البناء يختبر نفسه وسريعاً، وأصلح البناء المكسور فوراً.
تدرّب بأدوات متقن
افحص عدة نقاط نهاية لصحة API دفعة واحدة واحصل على الحالة وزمن الاستجابة وملخّص نجاح/فشل.
اختبر نقاط نهاية REST بتحكم كامل في الطريقة والترويسات وجسم JSON، ثم أضف تأكيدات على الحالة والترويسات ومسارات JSON.
تحقّق سريعاً من إمكانية الوصول إلى نقطة نهاية API: الحالة وزمن الاستجابة والحجم ونوع المحتوى وTLS.
قِس زمن استجابة نقطة نهاية عبر عدة عيّنات: الحد الأدنى والأقصى والمتوسط والوسيط وp95.
ولّد سيناريوهات اختبار الانحدار من وصف التغيير وقائمة الوحدات المتأثرة والمرتبطة.
للتعمّق أكثر
- مقاييس الاختبار التي تقود القراراتمقاييس التدفق والتسليم: مقاييس DORA
- الاختبار في خطوط CI/CDماذا يفعل المختبِر في CI/CD
- اختبار التحقق من النشرإشارات المراقبة التي تُتابع
- الاختبارات المتذبذبةما الذي يجعل اختبارات الواجهة متذبذبة — التوقيت والحالة المشتركة والبيانات والبيئة والأطراف الثالثة — وكيف تُشخَّص، وسياسة معقولة لإعادة المحاولة والحجر.
تقدّمك في هذا الموضوع
سجّل الدخول لتتابع تقدّمك
علّم الموضوعات مكتملة، وتابع من حيث توقفت، وافتح امتحانات التخصص.