كيف يبدو التطبيق الصحي بعد النشر؟
ينتهي النشر. يتحول خط الأنابيب إلى اللون الأخضر. يسأل أحدهم في دردشة الفريق السؤال البديهي: "هل التطبيق يعمل؟"
تتفقد قائمة العمليات. عملية التطبيق حية. المنفذ مفتوح. الصفحة الرئيسية تُحمّل دون أخطاء. كل شيء يبدو على ما يرام. تغلق التذكرة وتنتقل إلى المهمة التالية.
لكن السؤال الحقيقي ليس ما إذا كان التطبيق قد بدأ. السؤال الحقيقي هو ما إذا كان التطبيق يعمل فعليًا لمن يستخدمونه.
فخ بدء التشغيل
العملية الجارية ليست نفس التطبيق الصحي. هذا الفرق أهم مما يدركه معظم الفرق.
تأمل سيناريو بسيطًا: ينشر فريقك إصدارًا جديدًا يغير سطرًا واحدًا من الكود في دالة التحقق من الإدخال. يبدأ التطبيق بشكل مثالي. لا توجد أخطاء في السجلات. تُحمّل الصفحة الرئيسية فورًا. من منظور الخادم، كل شيء على ما يرام.
لكن هذا التغيير في التحقق صارم جدًا. المستخدمون الذين حفظوا بيانات سابقة بتنسيق معين يُرفضون الآن. لا يمكنهم إكمال عملهم. التطبيق يعمل، لكنه معطل لمن يعتمدون عليه.
الخادم يقول صحي. المستخدم يقول معطل. أيهما أكثر أهمية؟
الصحة تتعلق بالمستخدمين، وليس بالعمليات
يمكن أن يكون التطبيق حيًا تقنيًا ولكنه ميت وظيفيًا. إليك ثلاث طرق شائعة يحدث بها هذا:
التراجع الوظيفي. يعمل التطبيق، لكن ميزة ما تتصرف بشكل مختلف أو تتوقف عن العمل تمامًا. لا تعطل، لا سجل أخطاء، مجرد سلوك غير صحيح. يلاحظ المستخدمون ذلك قبل الفريق.
تدهور الأداء. يغير إصدار جديد كيفية استعلام التطبيق عن قاعدة البيانات. الاستعلام الذي كان يُكمل في 50 مللي ثانية يستغرق الآن خمس ثوانٍ. لا يتعطل التطبيق أبدًا. لا تزال الصفحة الرئيسية تُحمّل. لكن كل تفاعل يبدو بطيئًا، ويبدأ المستخدمون في التخلي عن سير العمل.
فساد البيانات الصامت. يعمل التطبيق بشكل جيد، لكن البيانات التي ينتجها أو يعرضها خاطئة. يتغير حساب ما بشكل طفيف. تتغير قيمة افتراضية. يرى المستخدمون معلومات غير صحيحة ويتخذون قرارات بناءً عليها. لا يتم طرح أي خطأ لأن التطبيق يفعل بالضبط ما يخبره الكود بفعله.
جميع السيناريوهات الثلاثة تشترك في نفس النمط: التطبيق يعمل، لكنه لا يؤدي غرضه.
التأثير المتتابع
التطبيق الصحي أيضًا لا يضر بالأنظمة المحيطة به. هذا بُعد من أبعاد الصحة يغفل عنه العديد من الفرق.
تخيل أن فريقك ينشر إصدارًا جديدًا يغير كيفية جلب البيانات من قاعدة البيانات. التطبيق نفسه يعمل بشكل جيد. لا أخطاء. أوقات استجابة جيدة. لكن نمط الوصول الجديد يضع حملاً غير متوقع على خادم قاعدة البيانات. تتباطأ قاعدة البيانات. تبدأ التطبيقات الأخرى التي تشارك نفس قاعدة البيانات في المعاناة من زمن الوصول وانتهاء المهلة.
تطبيقك صحي. البيئة المحيطة به ليست كذلك. وفي النهاية، ستؤثر تلك البيئة على تطبيقك أيضًا.
لهذا السبب لا يمكن تقييم صحة التطبيق بمعزل عن الآخرين. التغيير الذي يعمل بشكل مثالي لخدمة واحدة ولكنه يضعف البنية التحتية المشتركة لا يزال تغييرًا إشكاليًا. يجب أن يظل النظام ككل مستقرًا.
ثلاثة أبعاد لصحة التطبيق
بعد كل نشر، تحتاج إلى التحقق من ثلاثة أشياء، وليس شيئًا واحدًا:
1. هل التطبيق قيد التشغيل ويمكن الوصول إليه؟ هذا هو الفحص الأساسي. العملية حية. المنفذ مفتوح. نقطة نهاية الصحة تستجيب. هذا ضروري لكنه غير كافٍ.
يوضح الرسم البياني أدناه كيف تتداخل هذه الأبعاد الثلاثة لتحديد تطبيق صحي حقًا.
2. هل يؤدي التطبيق وظائفه بشكل صحيح؟ هذا هو الفحص الوظيفي. هل يمكن للمستخدمين إكمال سير العمل الأساسي؟ هل المخرجات صحيحة؟ هل يتطابق السلوك مع التوقعات؟ يتطلب هذا اختبارًا يتجاوز "هل يبدأ".
3. هل يسبب التطبيق ضررًا لبيئته؟ هذا هو الفحص النظامي. هل يضع التطبيق حملاً زائدًا على الموارد المشتركة؟ هل يسبب أخطاء في الخدمات التابعة؟ هل يقلل من أداء الأنظمة الأخرى؟
إذا كنت تتحقق فقط من البعد الأول، فستفوتك المشكلات حتى يبدأ المستخدمون في الشكوى. وبحلول الوقت الذي يشكو فيه المستخدمون، يكون الضرر قد وقع بالفعل.
لماذا هذا مهم لعملية النشر الخاصة بك
فهم ما يعنيه "صحي" حقًا يغير طريقة تفكيرك في التحقق بعد النشر.
إذا كانت الصحة تتعلق فقط ببدء التطبيق، فإن فحص نقطة نهاية الصحة البسيط يكفي. ولكن إذا كانت الصحة تشمل السلوك الصحيح والاستقرار البيئي، فأنت بحاجة إلى استراتيجية تحقق أوسع.
لهذا السبب تنتقل العديد من الفرق إلى ما هو أبعد من فحوصات الصحة الأساسية. يضيفون مراقبة اصطناعية تحاكي سير عمل المستخدم الحقيقي. يتتبعون النسب المئوية لوقت الاستجابة، وليس فقط متوسط زمن الاستجابة. يراقبون أداء استعلامات قاعدة البيانات واستخدام تجمع الاتصالات. يراقبون معدلات الخطأ في الخدمات النهائية.
هذه الممارسات موجودة لأن الفرق تعلمت بالطريقة الصعبة أن التطبيق الجاري ليس بالضرورة تطبيقًا صحيًا.
قائمة تحقق عملية للتحقق بعد النشر
في المرة القادمة التي تنشر فيها، قم بتنفيذ هذه الفحوصات. ليست جميعها تنطبق على كل نشر، لكن النمط عالمي:
- عملية التطبيق قيد التشغيل ونقطة نهاية الصحة تستجيب
- سير عمل المستخدم الأساسي يُكمل بنجاح (فحص يدوي أو آلي)
- أوقات الاستجابة ضمن النطاق المتوقع، وليست متدهورة
- معدل الخطأ مستقر أو أقل مما كان عليه قبل النشر
- أداء استعلامات قاعدة البيانات لم يتراجع
- البنية التحتية المشتركة (قاعدة البيانات، ذاكرة التخزين المؤقت، قائمة الانتظار) لا تظهر حملاً متزايدًا
- الخدمات التابعة تبلغ عن حالة طبيعية
- لا توجد تغييرات غير متوقعة في حجم السجلات أو أنماطها
هذه القائمة ليست شاملة. سيطور فريقك قائمته الخاصة بناءً على ما تعطل في الماضي. لكن المبدأ ثابت: تحقق من أن التطبيق يعمل للمستخدمين، وليس فقط أنه يعمل على الخوادم.
الخلاصة
التطبيق الصحي هو الذي يخدم مستخدميه بشكل صحيح دون الإضرار بالأنظمة المحيطة به. العملية الجارية هي مجرد نقطة البداية. يبدأ التحقق الحقيقي بعد اجتياز فحص بدء التشغيل. إذا كنت تتحقق فقط مما إذا كان التطبيق قد بدأ، فأنت لا تتحقق مما إذا كان النشر قد نجح. أنت تتحقق فقط مما إذا كان النشر قد انتهى. هذان شيئان مختلفان تمامًا.