النطاق المحدد أم العام: لماذا تعطّل تطبيق ServiceNow لديك بعد الترقية

هناك حوار يتكرر بعد كل ترقية لـ ServiceNow. تطبيق مخصص ظل يعمل عامين كاملين يتوقف عن العمل، أو يبدأ بسلوك غريب لا يستطيع أحد إعادة إنتاجه بثبات. الفريق الذي بناه انتقل إلى عمل آخر. والتوثيق، إن وُجد، يصف ما يفعله التطبيق لا لماذا بُني على هذا النحو.

في الغالب، يعود السبب الجذري إلى قرار اتُّخذ في الساعة الأولى من التطوير، حين اختار أحدهم النطاق العام لأنه أسهل الطرق.

ماذا يغيّر النطاق فعليًا

يعمل التطبيق محدد النطاق داخل حدود واضحة. له مساحة أسماء خاصة به، والأهم أنه لا يستطيع الوصول إلى ما هو خارج هذه الحدود إلا عبر واجهات تدعمها المنصة صراحةً. أما النطاق العام فلا حدود فيه: يستطيع الكود قراءة أي شيء وكتابته، وتوسيع الجداول الأساسية مباشرة، واستدعاء دوال داخلية لم تُصمَّم يومًا لتكون واجهة عامة.

يبدو هذا الفرق قيدًا، وهو كذلك أثناء التطوير. لكنه السبب الكامل في نجاة التطبيقات محددة النطاق من الترقيات.

عند ترقية المنصة، تُصان الواجهات المدعومة. سلوكها موثّق، وإيقاف استخدامها يُعلَن عنه، وتغييراتها تُدار. أما الدوال الداخلية فلا تحمل أيًا من هذه الضمانات. هي داخلية تحديدًا ليكون تغييرها ممكنًا، وهي تتغير فعلًا — غالبًا دون إعلان، لأن شيئًا عامًا لم يتغير من وجهة نظر المنصة.

التطبيق في النطاق العام الذي يعتمد على سلوك داخلي يعتمد على أمر لم يَعِد أحد بإبقائه ثابتًا.

لماذا يُختار النطاق العام رغم ذلك

ليس بإهمال. هناك ثلاثة أسباب متكررة، اثنان منها مفهومان.

لأنه أسرع في اليوم الأول. يتطلب التطبيق محدد النطاق أن تعرف الطريقة المدعومة لإنجاز الأمر. أما النطاق العام فيتيح لك إنجازه بالطريقة المباشرة. وعندما يقترب الموعد النهائي ويكون المطلوب صغيرًا، تفوز الطريقة المباشرة.

لأن المتطلب يمتد فعلًا عبر المنصة. بعض التطبيقات تحتاج إلى الوصول إلى الجداول الأساسية بطرق يصعب على التطبيقات محددة النطاق تنفيذها. هذا قيد حقيقي وليس ذريعة، لكنه أندر بكثير مما توحي به كثرة التطبيقات في النطاق العام.

لأن أحدًا لم يتخذ قرارًا أصلًا. هذا هو السبب الأكثر شيوعًا. بدأ التطوير في النطاق العام لأنه المكان الذي تبدأ فيه التجارب السريعة، ثم أصبحت التجربة مفيدة، وانتقل المفيد إلى الإنتاج دون أن يعيد أحد النظر في السؤال. لا يوجد قرار يمكن الإشارة إليه، ولهذا لا يوجد توثيق يشرحه.

هل نوسّع task أم ننشئ جدولًا مستقلًا؟

هذا هو القرار الثاني، وهو منفصل عن النطاق.

توسيع task يمنحك قدرًا كبيرًا من سلوك المنصة دون مقابل: اتفاقيات مستوى الخدمة، والموافقات، والإسناد، وملاحظات العمل، وسجل النشاط. وفي أي شيء يشبه عملًا ينتقل بين الحالات، يكون هذا الخيار صحيحًا عادةً ويوفّر جهدًا كبيرًا.

لكنه يرث أيضًا كل حقل في task، بما فيها حقول لا يحتاج إليها تطبيقك، ويعني أن سجلاتك تعيش في جدول تستعلم عنه أشياء كثيرة أخرى. في نسخة كبيرة، تترتب على ذلك آثار على الأداء، ويصبح نموذج بياناتك أصعب في الفهم لأن معظم الأعمدة لا صلة لها بك.

أما الجدول المستقل فيمنحك نموذجًا نظيفًا يعكس مجالك بالضبط، ويتطلب منك إعادة بناء ما يفعله task مما تحتاج إليه.

القاعدة التي نعمل بها: إن كان للشيء مُسنَد إليه وكان ينتقل بين الحالات، فوسّع task. وإن كان بيانات مرجعية أو إعدادات أو سجلًا يُقرأ أكثر بكثير مما يُعمل عليه، فاجعله مستقلًا. والأهم أن يُحسم القرار لكل تطبيق على حدة لا بالعادة، لأن الخيارين الافتراضيين كليهما خاطئ في نصف الحالات تقريبًا.

مشكلة الحوكمة التي تخلقها الأكواد المنخفضة

كل ما سبق يخص تطبيقات بناها أشخاص يعرفون المنصة. أما نمط الفشل الآخر فيظهر حين تُوضع أدوات الأكواد المنخفضة (low-code) في أيدي فرق الأعمال دون خطوة مراجعة.

والنتيجة متوقعة: عدد كبير من التطبيقات الصغيرة، يملك كلًا منها من صادف أنه بناه، وبعضها يؤدي وظائف متداخلة، وبعضها يحتفظ ببيانات إنتاج، ولا يريد أحد صيانة أي منها. هذه ليست حجة ضد التطوير المُدار من فرق الأعمال (citizen development). إنها حجة بأن هذا التطوير دون بوابة مراجعة ينتج دينًا تقنيًا بواجهة ودودة.

لا يلزم أن تكون البوابة ثقيلة. تكفي مراجعة قصيرة قبل أي انتقال إلى الإنتاج، تتحقق من ثلاثة أمور، وبها يُلتقط معظم المشكلات:

• هل يوجد شيء قائم يؤدي هذه الوظيفة؟
• هل هو محدد النطاق؟ وإن لم يكن، فلماذا؟
• من سيملكه بعد ستة أشهر؟

السؤال الثالث يُسقط عددًا مفاجئًا من التطبيقات قبل بنائها، وهذا أرخص وقت ممكن لإسقاطها.

إن ورثتَ تطبيقًا في النطاق العام

إعادة الكتابة ليست الجواب تلقائيًا، والحساب الصادق يعتمد على أمور خاصة بنسختك.

ابدأ بمعرفة ما يعتمد عليه التطبيق فعلًا. التطبيق في النطاق العام لا يستخدم بالضرورة واجهات غير مدعومة؛ هو فقط يملك الصلاحية لذلك. فإن كان يستخدم واجهات مدعومة في كل موضع، فتحويله إلى نطاق محدد جهد أقل بكثير من إعادة كتابته، ويصبح القيد شبكة أمان لا عائقًا.

وإن كان يعتمد على سلوك داخلي، فأمامك خياران: إعادة كتابته، أو قبول أن كل ترقية ستحمل عبء اختبار وبعض المخاطرة. وهذا قرار مشروع إن اتُّخذ عن قصد — فبعض التطبيقات لا تستحق إعادة الكتابة — لكن ينبغي أن تكون له تكلفة معلنة تُراجَع حين تتغير، لا وضعًا لم ينظر فيه أحد.

وما يجعل الأمر قابلًا للمعالجة في الحالتين هو أن تعرف أيهما حالتك، وهذا يحتاج إلى يوم أو يومين من الفحص، لا إلى مشروع.

الخلاصة

اختر النطاق المحدد ما لم تستطع أن تبيّن لماذا لا، ودوّن السبب إذا لم تستطع. احسم task مقابل الجدول المستقل لكل تطبيق على حدة لا بالافتراض. وضع مراجعة خفيفة أمام كل ما ينتقل إلى الإنتاج.

لا شيء من هذا يبطّئ التطبيق الأول كثيرًا. لكنه كله يقرّر ما إذا كان التطبيق العاشر رصيدًا أم عبئًا.