رهان Canonical على Ubuntu Pro هو صيانة الأسطول، وليس لينكس مجاني

الملخص

• المنتج المدفوع من Canonical ليس تحميل Ubuntu. بل هو غلاف الصيانة حول Ubuntu LTS: التغطية الأمنية، Livepatch، Landscape، أدوات الامتثال، صور Pro للسحابة العامة، إثبات مصدر الحزمة، والدعم التصعيدي.
• السؤال الشرائي المفيد ليس ما إذا كان Ubuntu Pro يحتوي على ميزات أكثر من Ubuntu المجتمعي. بل هو ما إذا كان بإمكان Canonical الحفاظ على أسطول مختلط عادي داخل حدود دعم معروفة بينما تنجرف النوى وحزم universe والصور السحابية والحزم التابعة لجهات خارجية ونوافذ التغيير.
• أقوى دليل عام هو التوثيق الفني وإشعارات الأمان المباشرة، وليس دراسات نتائج العملاء الخاضعة للرقابة. تنشر Canonical آليات واضحة لـ ESM، Livepatch،pro fix، security-status وتبعيات الشبكة، لكن هذه الآليات لا تزيل تخطيط إعادة التشغيل أو اختبار الحزم أو حوكمة المستودعات أو التعرض للانقطاع.
• تتحسن الحالة التجارية عندما يكون لدى المؤسسة العديد من أنظمة Ubuntu LTS، واحتياجات تدقيق منظمة، وإصدارات قديمة لا يمكن نقلها بسرعة، أو فرق تشغيل صغيرة. وتضعف عندما يكون الأسطول بالفعل سريع الزوال، معاد بناؤه بإحكام من الصور، أو معتمدًا على حزم تابعة لجهات خارجية غير مدعومة، أو غير راغب في قبول قواعد دورة حياة Canonical.

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

لهذا السبب، يجب تقييم Canonical Group Limited بشكل يشبه مشغل دورة حياة لنظام تشغيل مفتوح المصدر أكثر من كونه بائع برامج تقليدي. يسرد Companies HouseCanonical Group Limitedكشركة خاصة بريطانية نشطة، تأسست في 2009، مع تطوير البرامج كنشاط تجاري لها. تقول صفحة Canonical الخاصة أن المنظمة رعت مجتمع Ubuntu منذ 2004 وتقدم الآن مجموعة تساعد المؤسسات على اعتماد المصادر المفتوحة الموثوقة مع التعامل مع التعقيد المحيط بنظام التشغيل والتطبيقات. الشركة لا تملك Linux، أو Debian، أو مشاريع الحزم الأولية، أو أعباء العملاء، أو صور hyperscaler، أو قاعدة مساهمات مجتمع Ubuntu بأكملها. سلطتها التجارية تأتي من تحديد وتوثيق ودعم حدود صيانة Ubuntu.

هذه الحدود هي جوهر Ubuntu Pro. تقولصفحة منتج Ubuntu Proأن Pro يتضمن الصيانة الأمنية الموسعة، التصحيح المباشر للنواة، ميزات الامتثال والتقوية، إدارة الأسطول المركزية عبر Landscape، وتكاملات السحابة العامة. تشرحصفحة دورة إصدار Ubuntuالساعة الأساسية: الإصدارات المؤقتة تتلقى تسعة أشهر من التحديثات، إصدارات LTS تُنشر كل عامين وتتلقى خمس سنوات من الصيانة الأمنية القياسية، ويمكن لـ Ubuntu Pro تمديد التغطية الأمنية عبر ESM وإضافة Legacy. هذه العبارات تجعل الادعاء الاقتصادي ملموسًا. تبيع Canonical طريقة لإبطاء الترقيات القسرية دون التظاهر بأن أنظمة التشغيل يمكن تجاهلها.

وبالتالي، فإن وحدة التحليل المفيدة هي الجهاز المُصان، وليس التحميل. جهاز Ubuntu المُصان له إصدار محدد، ومصدر تحديث، وجرد حزم، وسياسة إعادة تشغيل مقبولة، ومسار تفسير إشعار أمني، ومالك يمكنه شرح الحزم التي تغطيها Canonical والتي لا تغطيها. يمكن أن يكون الخادم "على Ubuntu" مع كونه أصل مؤسسي سيئ إذا كان يحتوي على حزم من مصادر غير معروفة، أو PPAs تتفوق على الحزم المتوقعة، أو نواة لا تغطيها Livepatch، أو مؤقتات unattended-upgrades معطلة، أو صورة سحابية قديمة، أو عبء عمل لا يمكنه تحمل إعادة التشغيل اللازمة لإكمال الإصلاح. أدوات Canonical تقلل هذا التشتت فقط عندما يعاملها المشتري كجزء من انضباط الأسطول.

الحد الأول الصعب هو إثبات مصدر الحزمة. مستودعات Ubuntu ليست ضمانًا واحدًا موحدًا. توثيق Pro Client يميز مستودعmainعنuniverse، موضحًا أنmainيحتوي على الحزم التي التزمت Canonical تاريخيًا بدعمها أمنيًا لمدة خمس سنوات في إصدار LTS، بينماuniverseأكبر بكثير ولم يحمل تاريخيًا أي التزام صيانة مكافئ من Canonical. يقول نفسشرح ESMأن Ubuntu Pro وسع التزام Canonical إلىuniverse، معesm-appsلتغطية حزم universe وesm-infraلتغطية حزم main بعد انتهاء الدعم القياسي. هذا تغيير تشغيلي كبير، ولكنه أيضًا قاعدة حوكمة. يساعد فقط إذا كان الأسطول يستطيع معرفة الحزم التي جاءت من أي مصدر.

أمرpro security-statusكاشف لأنه يعامل التغطية كمشكلة جرد قبل أن يعاملها كوعد تسويقي. يُظهر توثيقsecurity-statusأعداد الحزم مقسمة عبر main/restricted، universe/multiverse، حزم الطرف الثالث والحزم غير المتاحة. يظهر أيضًا كيف يبلغ جهاز مربوط بـ Pro عن التغطية لـ main/restricted عبرesm-infraو universe/multiverse عبرesm-apps. هذا هو بالضبط المكان الذي يجب أن ينظر فيه المشتري. إذا كانت العديد من الحزم المهمة من طرف ثالث، أو مثبتة محليًا، أو غير متاحة بعد الآن، أو مثبتة من مصادر خارجية، فقد يكون Ubuntu Pro مفيدًا للنظام الأساسي لكنه لا يمكن أن يصبح عقد الدعم لكل شيء يعمل على المضيف.

يغير ESM أيضًا سلوك اختيار الحزمة. يقول توثيق ESM أن Pro Client يسلم ملفات تفضيل APT بحيث تكون تحديثات ESM مفضلة عند تمكين خدمات ESM، وأن هذا التفضيل يمكن أن يؤثر أيضًا على الحزم حيث يوجد PPA تابع لجهة خارجية. هذه آلية أمان معقولة إذا كان الهدف هو تجنب التراجع العرضي عن تصحيح أمني. وهي أيضًا سبب للاختبار بعناية في البيئات التي تعتمد على PPAs أو مستودعات البائعين أو الحزم المعاد بناؤها داخليًا. قد يرحب مهندس الأمن بالربط الأقوى. قد يرى مالك التطبيق مسار إصدار غير متوقع. كلاهما محق. تقلل Canonical فئة واحدة من مخاطر الصيانة من خلال إضفاء الطابع الرسمي على أولوية الحزمة، لكن العميل لا يزال يتعين عليه حوكمة الاستثناءات.

الحد الثاني الصعب هو سياسة إعادة التشغيل. Livepatch هو الجزء الأكثر جاذبية في Ubuntu Pro للفرق التي تقيس وقت التوقف عن العمل في الإيرادات المفقودة أو نوافذ الصيانة الفائتة أو المخاطر التشغيلية. تقولصفحة Livepatchأن Livepatch تعالج ثغرات النواة عالية وحرجة بين نوافذ الصيانة المجدولة ولا تقوم بتصحيح مكتبات مساحة المستخدم مثل OpenSSL أو glibc. نفس الصفحة واضحة بشكل غير معتاد أن Livepatch ليست بديلاً عن إعادة التشغيل. إعادة التشغيل لا تزال تمسح حالة نظام التشغيل المتراكمة، ومحاولة تجنبها تمامًا يمكن أن تخلق تغطية غير كاملة واستراتيجيات تصحيح هشة. هذا الاعتراف مهم. تبيع Canonical التحكم في توقيت إعادة التشغيل، وليس إلغاء اقتصاديات إعادة التشغيل.

الفرق التشغيلي مهم في أي أسطول Ubuntu طويل العمر. قد يتم تخفيف ثغرة النواة في الذاكرة بواسطة وحدة Livepatch، بينما تحتاج مكتبة مساحة المستخدم إلى تثبيت حزمة عادي وربما إعادة تشغيل خدمة، وقد يتطلب تحديث نواة أو ABI منفصل إعادة تشغيل لإكماله. توثيقpro fixيجعل ذلك صريحًا. يمكن للأمر الإبلاغ عن عدم إصدار إصلاح بعد، أو أن الإصلاح يتطلب Ubuntu Pro، أو أن خدمة Pro ذات الصلة معطلة، أو أن إعادة التشغيل مطلوبة، أو أن CVE تم حلها جزئيًا فقط لأن بعض الحزم المتأثرة تفتقر إلى الإصلاحات. هذه أتمتة مفيدة لأنها تحول التعامل الغامض مع الثغرات إلى خطة. إنها ليست ضمانًا أن الخطة قصيرة أو مؤتمتة بالكامل أو خالية من الألم الجدولي.

لـ Livepatch أيضًا حدود تغطية على مستوى النواة. يُظهر توثيقحالة Livepatchأن العميل يبلغ ما إذا كانت سلسلة نواة مغطاة، وما إذا كان إصدار نواة معين مغطى حتى تاريخ، وما إذا كانت التغطية قد انتهت، وما إذا كان لا يمكن تصحيح ثغرة مباشرة، وما إذا كان يجب ترقية النواة وإعادة التشغيل. صفحة Pro Client تحذر بشكل منفصل من أن نواة غير مدعومة يمكنها تمكين Livepatch ولكن لا تتلقى تحديثات. هذا تحذير حاد لبيئات السحابة وسطح المكتب وتمكين الأجهزة والحافة حيث يمكن أن تتحرك إصدارات النواة أسرع من مصفوفة الدعم. القيمة التجارية هي الأعلى عندما يمكن للمشتري توحيد النوى بما يكفي لنموذج تغطية Canonical ليكون ذا أهمية.

التاريخ العام أيضًا يجادل ضد معاملة Livepatch كسحر. فيتحقيق حادثة 2021، وصفت Canonical تصحيحًا مباشرًا معيبًا لـ Ubuntu 16.04 LTS لم يتم اكتشافه لأن الخلل اعتمد على سلوك خاص بعبء العمل تحت الحمل. تم سحب التصحيح بعد النشر إلى الطبقة المجانية، ونشرت Canonical دروسًا بما في ذلك اختيار أضيق لـ CVE، وتغطية اختبار أفضل طويلة الأمد، وطرح تدريجي أكثر للطبقة، وإزالة أسهل للتصحيحات المعيبة، وتحسين الكشف. هذا التقرير لا يجعل Livepatch غير جديرة بالثقة. إنه يطرح النقطة الصحيحة للمشترين: التصحيح المباشر للنواة هو هندسة أنظمة تشغيل صعبة. يقلل من وقت التوقف غير المخطط له عندما يعمل، لكنه لا يزال يحتاج إلى طبقات، وقابلية الملاحظة، وممارسة التراجع، وإعادة التشغيل المجدولة.

الحد الثالث هو جاهزية الأتمتة. يمكن لـ Canonical نشر التصحيحات، ولكن يجب تكوين جهاز العميل لتطبيقها. يسرد توثيقunattended-upgrades endpointالمتطلبات الأساسية ليكونunattended_upgrades_runningصحيحًا: تمكين وظائف APT الدورية، تردد تحديث قائمة الحزم غير الصفري، تشغيل مؤقتات systemd، تكوين الأصول المسموح بها، تردد غير صفري لـ unattended-upgrades. هذا مثال ممتاز على المقام الذي تبيعه Canonical حقًا. تعتقد العديد من الفرق أن الجزء الصعب هو اتخاذ قرار التصحيح. في الممارسة العملية، الجزء الصعب هو التأكد من أن حلقة التصحيح تعمل فعليًا على كل فئة من الآلات، وتُبلغ عن حالتها، وتفشل بصوت عالٍ عندما يكسر تكوين محلي الأمر.

هذا هو المكان الذي تتناسب فيه Landscape مع قصة المنتج. تصفصفحة Landscapeأداة إدارة أنظمة قائمة على الويب أو يمكن الوصول إليها عبر API، متاحة كخدمة مُدارة، أو برنامج كخدمة، أو خادم مستضاف ذاتيًا، مع عملاء مثبتين على آلات Ubuntu. تقول إن Landscape يؤتمت التصحيح الأمني والتدقيق وإدارة الوصول ومهام الامتثال، ويمكنه تحديث وترقية الآلات مع جمع مقاييس الصحة. لا تحل Landscape محل التصميم الجيد للأسطول، لكنها تعطي Canonical مستوى إدارة للعمل العادي: تجميع الآلات، وتوزيع التحديثات، ورؤية المخزون، وإدارة المستودعات، وإثبات وضع التدقيق. القيمة تزداد مع عدم تجانس الأسطول لأن التفتيش اليدوي لا يتوسع.

تقدم Landscape أيضًا سؤال تكلفة وسلطة. نشر Landscape مستضاف ذاتيًا يجب أن يُنشر ويُحدث ويُنسخ احتياطيًا ويُراقب ويتكامل مع سياسة الهوية والشبكة. نسخة SaaS أو مُدارة تقلل بعض هذا العبء لكنها تزيد الاعتماد على الخدمات التي تديرها Canonical. تقول صفحة التسعير أن Landscape SaaS مشمول في اشتراك Ubuntu Pro وتدرج Landscape المُدارة كإضافة مدفوعة للآلات الافتراضية أو المادية. هذا لا يعني أن الإضافة مبالغ في سعرها أو أقل من سعرها. يعني أن المشترين يجب أن يقارنوا Landscape ليس مع "Linux مجاني" ولكن مع العمل اليدوي للحفاظ على عرض حزمة موثوق، وحلقات التحديث، وقوائم الاستثناء، ومخزون الأصول، وأدلة الامتثال عبر مئات أو آلاف الآلات.

الحد الرابع هو انجراف الصور السحابية. يقول توثيقصور Pro للسحابة العامةأن صور Ubuntu Pro تُنشر إلى AWS و Azure و GCP، وتُربط تلقائيًا بعقد دعم Pro عند التشغيل الأول، وتفعيل خدمات Pro الضرورية بحيث لا يتطلب جهاز آمن ومدعوم إعدادًا منفصلاً. هذا مناسب لفرق السحابة التي تشتري الأمان من خلال الفوترة السحابية الحالية. يعني أيضًا أن عقد التشغيل يمر عبر عدة أطراف: Canonical، سوق السحابة، عملية نشر الصورة، إعداد هوية العميل وسياساته، وأي نظام لخبز الصور أو الصور الذهبية يستخدمه العميل بعد التشغيل الأول. يمكن أن تبدأ صورة سحابية نظيفة وتظل تنحرف بمجرد أن تقوم الفرق بتثبيت الحزم، أو تغيير النوى، أو تعطيل المؤقتات، أو تجاوز المستودعات.

الحد الخامس هو الامتثال. يتضمن Ubuntu Pro ميزات FIPS و CIS و DISA-STIG وميزات تقوية أمنية أخرى، لكنها خاصة بالإصدار والسياسة. يقول توثيقامتثال CISأن Ubuntu لديه أدوات أصلية لتدقيق وتقوية CIS، مع إصدارات معيار مرتبطة بإصدارات Ubuntu محددة ولا يمكن مقارنتها عبر الإصدارات. تشير صفحة تسعير Canonical بشكل منفصل إلى حالة FIPS وأدوات دليل الأمن وتفاصيل التقوية الخاصة بالإصدار. للمشترين الخاضعين للتنظيم، هذا مفيد لأنه يحول بعض أعمال التدقيق إلى أدوات مدعومة. لا يجعل التطبيق متوافقًا بذاته. يمكن للمضيف المُقوى أن يدير خدمة مهيأة بشكل سيء، أو يخزن الأسرار بشكل سيء، أو يكشف البيانات من خلال خطأ في التطبيق، أو يفشل في تحكم خاص بالمؤسسة.

تسعير Canonical يجعل الاقتراح ملموسًا بما يكفي للمقارنة مع العمل اليدوي. تسردصفحة تسعير Ubuntu ProUbuntu Pro بـ 25 دولارًا لكل محطة عمل سنويًا و 500 دولار لكل خادم مع آلات افتراضية غير محدودة سنويًا، مع إضافات دعم 24/7 بسعر أعلى و Pro سحابي محسوب عبر موفري السحابة. تقول نفس الصفحة أن التغطية الكاملة تصل إلى أكثر من 36000 حزمة مفتوحة المصدر deb في مستودع Universe، بينما تستشهد وثائق Canonical الأخرى بأعداد حزم universe بشكل مختلف حسب الإصدار والسياق. السعر المتفاوض عليه بالضبط سيختلف حسب العميل وسوق السحابة ومستوى الدعم، لكن شكل الفاتورة واضح: Canonical تريد أن تكون أرخص من الجهد الداخلي للعميل لتتبع وترجمة واختبار والدفاع عن أسطول Ubuntu طويل العمر بمفرده.

بالنسبة للعديد من فرق البنية التحتية، هذا معقول. البديل لـ Ubuntu Pro نادرًا ما يكون برنامج توزيع Linux داخلي مثالي. غالبًا ما يكون خليطًا من إصدارات LTS، وبعض الآلات غير المدعومة، وجدول بيانات للاستثناءات، ونصوص برمجية محلية الصنع، ونوافذ صيانة متأخرة، وماسح ثغرات يغمر الفرق بالنتائج، وصور سحابية تُعاد بناؤها أحيانًا، واستثناءات أمنية تصبح دائمة لأنه لا أحد يملك التبعية القديمة. في هذه البيئة، مساهمة Canonical الرئيسية ليست أنها كتبت كل تصحيح أولي. بل إنها تعبئ التصحيح في مسار دعم خاص بالإصدار، وتكشف الحالة من خلال الأدوات، وتنشر USNs وصفحات CVE، وتعطي المشتري طريق تصعيد.

يُظهر موجز USN العام هذه الآليات في الحركة. تشرحصفحة إشعارات أمان Ubuntuأن إشعارات أمان Ubuntu تُصدر عند إصلاح مشكلة أمنية في حزمة Ubuntu رسمية، وأن Canonical تنتج أيضًا ملفات OVAL لبيانات الثغرات والإصلاحات القابلة للقراءة آليًا. يُظهر إشعارcurl الأخير، USN-8525-1كيف يمتد تنبيه أمني واحد عبر عدة إصدارات Ubuntu وكيف يمكن للإصدارات الأقدم إظهار إدخالات "إصلاح Ubuntu Pro متاح". هذا ليس معيارًا لسرعة التصحيح عبر جميع الثغرات. إنه دليل على أن منتج الصيانة الأمنية لـ Canonical هو نظام نشر جارٍ وواعي بالإصدار وليس مجرد صفحة مبيعات.

يكشف نفس دليل USN أيضًا لماذا تحتاج فرق التشغيل إلى الإشراف. يمكن أن يتضمن إشعار curl واحد إصدارات مختلفة متأثرة، وإصدارات حزم مختلفة، وتحديثات قياسية لبعض الإصدارات، وإصلاحات Pro للإصدارات الأقدم، ومؤشرات دعم Legacy لإصدارات أقدم. يمكن أن يتطلب إشعار النواة إعادة تشغيل ويمكن أن يحذر من أن تغييرات ABI تتطلب إعادة بناء وحدات النواة التابعة لجهات خارجية. اشتراك Pro لا يزيل هذه الشروط. يعطي المنظمة مسارًا مدعومًا من خلالها. يجب أن يكون هذا التمييز صريحًا في أي قرار شراء.

متطلبات الشبكة لـ Canonical هي دليل آخر واقعي. يسردمتطلبات شبكة Pro Clientcontracts.canonical.comللمصادقة،esm.ubuntu.comلخدمات APT الموثقة، ونقاط نهاية snap و Livepatch لـ Livepatch،ubuntu.com/securityلبيانات أمانpro fix. هذا يخبر المشتري أن Ubuntu Pro ليس مجرد مجموعة حزم ثابتة. يعتمد على الوصول إلى الشبكة، والمصادقة، وتوفر الخدمة، وتكوين الوكيل للعميل. للأسطول المتصل، هذا طبيعي. للبيئات المعزولة أو المقيدة، هو قيد تصميم يجب حله قبل أن يتمكن الاشتراك من تقديم وفورات العمالة الموعودة.

دليل الانقطاع العام يجعل هذا القيد ملموسًا. خلال حادثة توفر في مايو 2026، أبلغ OMG! Ubuntu أن مواقع وخدمات Canonical و Ubuntu تأثرت، مع تأثر API Livepatch و Landscape من بين الخدمات المتأثرة، بينما لاحظت أيضًا أن مستودعات APT الموزعة وتحميلات ISO لم تكن بالضرورة غير متصلة. يسجل موضوع منتدى مجتمع Ubuntu من سبتمبر 2025 مستخدمين يرون أخطاء 500 منsecurity.ubuntu.comونقاش يشير إلى صفحات حالة Canonical واسترداد جيب الأرشيف/الأمان. هذه ليست دراسات موثوقية خاضعة للرقابة، ولا تثبت فشلًا مزمنًا. إنها تثبت أن توفر المستودع والخدمة ينتمي إلى نموذج التكلفة. الأسطول الذي لا يمكنه تحمل تأخير استرجاع الحزم يحتاج إلى مرايا وذاكرة تخزين مؤقت وسياسة إعادة محاولة واستجابة مختبرة عندما تتذبذب الخدمات الأولية.

الحد السادس هو snaps وتغليف التطبيقات. تخلط أنظمة Ubuntu بشكل متزايد حزم deb مع snaps وصور الحاويات ومستودعات التطبيقات المحددة. تشرح صفحة دورة الإصدار أن snaps تحدث بشكل مستقل عن النظام الرئيسي وهي مناسبة للتطبيقات والأدوات التي تتحرك بشكل متكرر، مع أوضاع عزل مختلفة. يمكن أن يكون هذا ميزة لسرعة المطورين وتحديثات تطبيقات سطح المكتب. يمكن أن يخلق أيضًا احتكاكًا في السياسة في المؤسسات التي تريد أن يمر كل تحديث عبر بوابة مستودع واحدة، أو أن تكون كل حزمة معكوسة داخليًا، أو أن يتم مرحلة كل تغيير عبر حلقات. صيانة حزم deb في Ubuntu Pro لا تحل تلقائيًا سياسة snap للمؤسسة.

يجب على المشتري أن يقرر أين يُسمح بتحديثات snap، وكيف يتم تدقيقها، وما إذا كان نموذج Canonical يطابق قواعد التحكم في التغيير المحلية.

الحد السابع هو نطاق الدعم. تقولصفحة Ubuntu Pro القانونيةأن Pro هو حزمة خدمة Canonical لـ Ubuntu بمستويات دعم متدرجة لسطح المكتب والخادم والنشر السحابي، وأن اتفاقيات العملاء تحدد تفاصيل الخدمة بالضبط. تحددشروط الخدمةخدمات Canonical لتشمل مستودعات حزم Ubuntu، التحديثات، التصحيحات المباشرة للنواة، المراقبة الأمنية، إدارة الأنظمة وخدمات التشغيل. هذه التعريفات مهمة لأن المشترين المؤسسيين غالبًا ما يخلطون عدة أشياء تحت "دعم Linux": دعم الإصلاح العطل لنظام التشغيل، الصيانة الأمنية للحزم، المساعدة في منتجات البنية التحتية، دعم الصور السحابية، أدوات الامتثال، استكشاف أخطاء التطبيقات، والدعم الطارئ. Ubuntu Pro يغطي بعضًا من هذه بشكل مباشر والبعض الآخر فقط من خلال مستويات الدعم أو الخدمات المجاورة.

حد الدعم هذا مهم بشكل خاص لأن محفظة Canonical تمتد إلى ما وراء نظام التشغيل الأساسي. تقدم صفحة الشركة محفظة كاملة مفتوحة المصدر، وتدرج صفحة التسعير تغطية أو خطافات دعم حول أتمتة البنية التحتية، التخزين، السحب الخاصة والحافة، Kubernetes، منصات البيانات و MLOps. هذا الاتساع يمكن أن يكون نقطة بيع للمشترين الذين يريدون بائعًا واحدًا يفهم أكثر من النواة. يمكن أن يطمس التقييم إذا كانت الشركة تعامل كل تقنية مجاورة لـ Canonical كجزء من نفس الضمان التشغيلي. قد يحافظ Ubuntu Pro على حزم المضيف.

نشر Charmed Kubernetes أو بيئة MicroCloud أو مجموعة Ceph أو عقار MAAS أو منصة ذكاء اصطناعي مبنية على Ubuntu يضيف ترتيب ترقية خاص به، ومخاطر تخزين، وتوافق API، وتبعيات أجهزة، ومتطلبات نسخ احتياطي. يجب على المشتري أن يسأل أي الطبقات يغطيها الاشتراك، وأي منها يتطلب إضافات دعم، وأيها يبقى عمل تكامل العميل الخاص.

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

شراء Ubuntu Pro لا يستعين بمصادر خارجية لملكية الأسطول. يشتري مجموعة أفضل دعمًا من القرارات داخل الأسطول.

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

قيمة Canonical في هذه البيئات ليست أنها تجعل الثبات غير ضروري. إنها تعطي نظام التشغيل الأساسي وعالم الحزم مصدر صيانة مدعوم يمكن لمُنشئي الصور استهلاكه.

هذا يجعل المقام الاقتصادي أوسع من "خوادم تحت الاشتراك". يجب أن يحسب نموذج المشتري المفيد كل مكان يدخل فيه Ubuntu البيئة: صور الآلات الافتراضية الأساسية، ومحطات عمل المطورين، وعمال بناء، وعقد Kubernetes، وأجهزة الحافة، وقواعد الحاويات، وصور WSL حيث تنطبق السياسة، والأنظمة القديمة التي تبقى على قيد الحياة لأسباب تجارية. يجب بعد ذلك تقسيم هذه الأنظمة حسب نمط الصيانة. بعضها يُعاد بناؤه أسبوعيًا. بعضها يتم تصحيحه في المكان. بعضها مجمد باستثناء الإصلاحات الطارئة. بعضها يتطلب تذاكر تغيير ونوافذ صيانة. بعضها خلف وكلاء. بعضها غير متصل. قد يكون Ubuntu Pro رخيصًا على ورقة الأسعار لكنه مكلف للتنفيذ إذا كانت كل فئة تحتاج نمطًا مختلفًا.

قد يكون رخيصًا أيضًا لأنه يمنع كل فريق من اختراع هذا النمط بمفرده.

الحد التاسع هو تفسير الثغرات. يمكن للماسح أن يقول إن الحزمة ضعيفة، لكن فريق التشغيل يحتاج إلى معرفة ما إذا كان الإصدار المثبت متأثرًا بالفعل، وما إذا كانت Canonical قد أعادت التصحيح دون تغيير الإصدار الأولي بالطريقة التي يتوقعها الماسح، وما إذا كان الإصلاح في التحديثات القياسية أو ESM، وما إذا كانت الحزمة من universe، وما إذا كانت الخدمة ذات الصلة ممكنة، وما إذا كانت إعادة التشغيل أو إعادة تشغيل الخدمة لا تزال مطلوبة. مواد Canonical من USN و CVE وpro fixقيمة لأنها تساعد في ترجمة معرفات الثغرات الأولية إلى إجراءات خاصة بـ Ubuntu. هذا تقليل حقيقي في العبء المعرفي. لكن التخفيض يعمل بشكل أفضل عندما تثق فرق الأمان في إعادة التصحيح من التوزيع وتعلم الماسحات قراءة أدلة Ubuntu بدلاً من مجرد مقارنة أرقام الإصدارات الأولية.

الحد العاشر هو حوكمة الاستثناءات. كل أسطول مؤسسي دائم لديه استثناءات: حزمة لا يمكن تحديثها حتى يشهد بائع التطبيق عليها، ونواة محتجزة لسائق، و PPA تستخدمه وحدة أعمال واحدة، ومنطقة حيث الوصول الصادر مقيد، وآلة قديمة جدًا بحيث لا يمكن نقلها بسرعة، أو نظام شبيه بالجهاز لا يريد أحد لمسه. يمكن لـ Ubuntu Pro جعل هذه الاستثناءات أكثر وضوحًا، لكنه لا يستطيع تحديد ما إذا كانت الشركة تقبلها. يمكن لـ Landscape تجميع الأنظمة وإظهار المخزون. يمكن لـpro security-statusكشف حزم الطرف الثالث والحزم غير المتاحة. يمكن لحالة Livepatch إظهار النوى غير المدعومة. لا شيء من هذه المخرجات هو قرار مخاطرة. قرار المخاطرة يخص العميل. وعد Canonical التجاري موثوق فقط إذا استخدم المشتري الأدلة لتقليل الاستثناءات غير المُدارة بدلاً من مجرد توثيقها.

هذا هو أيضًا المكان الذي يجب فيه مقارنة البدائل بصراحة. قد يكون Debian جذابًا للفرق التي تريد حوكمة مجتمعية ويمكنها تحمل المزيد من أعمال دورة الحياة بنفسها. قد يكون Red Hat Enterprise Linux جذابًا للمؤسسات التي تفضل نظامًا بيئيًا مختلفًا لـ Linux المؤسسي ونمط شهادة. قد تكون صور موفر السحابة كافية للفرق التي تبقى ضمن الخدمات المُدارة وتستبدل الآلات بسرعة. قد تقلل الحاويات والصور غير الموزعة من تعرض التطبيق على مستوى المضيف. قد تبني فرق المنصات الداخلية نظام الصور الذهبية والمرآة وإعداد تقارير التصحيح الخاص بها. لا تحتاج Canonical إلى التفوق على جميع البدائل في كل فئة.

تحتاج إلى التفوق على البديل الفعلي لعقار Ubuntu الثقيل: تكلفة ومخاطر تشغيل بنية تحتية شائعة مفتوحة المصدر بدون مالك صيانة واضح.

الاختبار العملي ليس ما إذا كانت Canonical يمكنها جعل كل دورة تصحيح سهلة. لا يمكن لأي بائع Linux ذلك. الاختبار هو ما إذا كان بإمكان العميل إظهار عدد أقل من المجهولات بعد اعتماد المنتج. عدد أقل من الحزم ذات المصدر غير الواضح. عدد أقل من الآلات بعد الدعم القياسي بدون خطة واضحة. عدد أقل من إعادة تشغيل النواة العاجلة. عدد أقل من النوى غير المدعومة المختبئة خلف ملخص حالة أخضر. عدد أقل من نتائج الأمان التي لا يمكن لأحد تعيينها لإصلاح Ubuntu. عدد أقل من المضيفين القدامى المستبعدين من التدقيق لأنهم غير ملائمين. عدد أقل من النصوص البرمجية المكتوبة يدويًا التي لا يفهمها إلا مسؤول واحد.

إذا انخفضت هذه المجهولات، فإن Ubuntu Pro يقوم بعمل قيم حتى عندما لا يزال البشر يوافقون على التغييرات ويجدولون إعادة التشغيل. إذا بقيت هذه المجهولات، فإن الاشتراك لم يغير نموذج التشغيل بما يكفي.

لهذا السبب يصعب استنتاج نتائج نشر العميل من المواد العامة. يمكن لـ Canonical إظهار أنها تنشر ميزات Ubuntu Pro، USNs، APIs Pro Client، الصور السحابية و Landscape. لا يمكنها، من التوثيق العام وحده، إثبات أن عميلًا معينًا قلل من عمل التصحيح بنسبة مئوية معينة أو تجنب عددًا معينًا من الحوادث. تلك النتائج تعتمد على اختيارات الحزمة المحلية، واختبارات تراجع التطبيق، وسياسة إعادة التشغيل، ونوافذ الصيانة، والتوظيف، والمرايا، وإعداد الهوية، وتكامل موفر السحابة، وممارسة التصعيد. يجب على المشتري معالجة ادعاءات توفير Canonical التشغيلية كفرضيات معقولة للتحقق من صحتها مقابل أسطوله الخاص، وليس كنتائج عالمية.

أقوى حالة استخدام هي أسطول LTS طويل العمر مع ضغط تدقيق حقيقي. فكر في أعباء العمل في القطاع العام، وخوادم المؤسسات الخاضعة للتنظيم، وأجهزة الحافة التي لا يمكن ترقيتها كل عام، والبنية التحتية للذكاء الاصطناعي مع مجموعات حزم كبيرة، أو المنصات الداخلية حيث قام المطورون بالبناء على صور Ubuntu لسنوات. في هذه الإعدادات، تكلفة "فقط قم بالترقية" ليست شعارًا؛ إنها شهادة التطبيق، وتوافق الأجهزة، ونوافذ التغيير، ومخاطر مستوى البيانات، ووقت الموظفين. يمكن لـ Ubuntu Pro شراء الوقت من خلال تمديد التغطية وتوضيح حالة الحزمة. يمكن لـ Livepatch تقليص نافذة إعادة التشغيل العاجلة لمشكلات النواة المدعومة. يمكن لـ Landscape جعل حالة الأسطول مرئية.

يمكن للدعم إعطاء الفريق مكانًا للتصعيد عندما لا يكون منطق الحزمة العادي كافيًا.

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

هناك أيضًا بُعد للارتباط، لكنه أكثر دقة من الارتباط الاحتكاري الكلاسيكي. Ubuntu يبقى Linux مفتوح المصدر. يمكن للعملاء التوقف عن استخدام Pro، أو الترحيل إلى توزيعة أخرى، أو بناء سياسة المستودع الخاصة بهم، أو نقل أعباء العمل إلى حاويات. الارتباط في قواعد دورة الحياة والأدلة التشغيلية. بمجرد أن تعتمد الشركة على Ubuntu Pro لحزم ESM، وتغطية Livepatch، وأدوات CIS، وتدفقات FIPS، ومخزون Landscape، وسجلات الدعم، فإن الانتقال يعني إعادة بناء ليس فقط الحزم ولكن الثقة: حالة الثغرة، وقطع التدقيق، وحلقات التحديث، وخطوط الأساس للامتثال، وكتيبات الدعم. هذا ليس سيئًا بالضرورة. غالبًا ما يصبح البائع المفيد مدمجًا لأنه يزيل العمل.

السؤال هو ما إذا كان العمل المدمج يبقى مرئيًا وقابلاً للنقل بما يكفي.

أفضل طريقة لتجربة Canonical ليست طلب عرض توضيحي للميزات. بل هي اختيار مجموعة فرعية فوضوية ولكنها عادية من الأسطول وإجراء تدقيق صيانة. عد الحزم حسب المصدر. حدد حزم main و universe والطرف الثالث والحزم غير المتاحة. قارن تغطية LTS القياسية مع تغطية Pro. تحقق مما إذا كانunattended-upgradesيعمل بالفعل. حدد النوى التي تغطيها Livepatch والنوى التي لا تغطيها. اختر USNs حديثة ذات صلة بالحزم المثبتة واتبع خطةpro fix. قم بمرحلة إصلاح يتطلب إعادة تشغيل. اختبر تجميع Landscape وتحديثًا متدرجًا. جرب صورة Pro سحابية ثم افحص ما يحدث بعد خطوة خبز الصورة العادية للمؤسسة. سجل مقدار الحكم البشري المتبقي.

يجب أن يشمل ذلك التجربة الاستثناءات، وليس فقط المسارات السعيدة. أضف PPA الذي تستخدمه الشركة بالفعل. قم بتضمين آلة LTS قديمة. قم بتضمين آلة خلف وكيل. قم بتضمين مثيل سحابي، وخادم فعلي، وعقدة تشبه الحافة إذا كانت موجودة. قم بتضمين حزمة من universe يهتم بها الأمن وحزمة خارج تغطية Canonical. قم بتضمين مالك تطبيق يمكنه تحديد ما إذا كان تحديث المكتبة آمنًا. قم بتضمين شخص التدقيق الذي يحتاج إلى دليل بعد التغيير، وليس فقط المهندس الذي يشغل الأمر. إذا وفر Ubuntu Pro الوقت فقط في المسار النظيف، يحتاج المشتري إلى معرفة ذلك قبل الالتزام بالأسطول الفوضوي.

يجب أن يكون مقياس القبول هو دورة الصيانة المكتملة، وليس الأمر الذي يبدأها. دورة مفيدة تبدأ بإشعار أو اكتشاف ثغرة، وتعيينها إلى إصدارات وحزم Ubuntu المتأثرة، وتحديد ما إذا كان الإصلاح قياسيًا أو ESM أو غير متاح، وتأكيد حق الجهاز والخدمات الممكنة، ومرحلة تغيير الحزمة أو Livepatch، وتسجيل ما إذا كانت إعادة التشغيل أو إعادة تشغيل الخدمة لا تزال مطلوبة، والتحقق من صحة التطبيق بعد التغيير، وترك مسار تدقيق يمكن لمشغل آخر فهمه لاحقًا. Canonical لديها آليات عامة للعديد من أجزاء هذه الدورة، خاصة USNs، وحالة Pro Client، وتخطيط الإصلاح، وإدارة Landscape. العميل لا يزال يمتلك البوابات المحلية حول اختبار التطبيق، والموافقة على التغيير، وتوقيع الاستثناء.

قياس الدورة الكاملة يمنع كلا الجانبين من المبالغة في تقدير المنتج: تحصل Canonical على الفضل في تقليل أعمال التفسير والتنسيق، بينما لا يزال المشتري يرى القرارات البشرية المتبقية.

هذا يشرح أيضًا لماذا يجب شراء المنتج من قبل التشغيل والأمن معًا. قد يقدر فريق الأمن تغطية أطول لـ CVE، وبيانات ثغرات قابلة للقراءة آليًا، وأدلة تدقيق أوضح. قد يقدر فريق التشغيل عددًا أقل من إعادة التشغيل الطارئة، وتجميع Landscape، وطريق تصعيد مدعوم. قد يقدر فريق المنصة صورًا أساسية متسقة وعددًا أقل من قرارات Linux الفردية لفرق التطبيق. هذه الفوائد تتداخل، لكنها ليست متطابقة. إذا اشترى الأمن الاشتراك فقط، فقد لا يزال التشغيل يفتقر إلى نوافذ الصيانة وسعة الاختبار لاستخدامه جيدًا. إذا اشتراه التشغيل فقط، فقد لا يزال الأمن يمسح ويبلغ عن الأسطول بطريقة تتجاهل إعادة التصحيح من Ubuntu وتغطية Pro.

أقوى نشر Canonical هو حيث تتفق هذه الفرق على نفس مسار الأدلة قبل ظهور CVE العاجل التالي.

ما الدليل الذي سيغير الحكم؟ أولاً، البيانات العامة أو الخاصة بالعميل تُظهر متوسط الوقت من نشر CVE إلى إصلاح Ubuntu المتاح حسب فئة الحزمة والإصدار سيشحذ القيمة الأمنية. ثانيًا، القياسات المستقلة لنجاح Livepatch والتراجع وتكرار إعادة التشغيل المطلوبة عبر النوى المدعومة ستساعد في فصل التسويق عن الموثوقية. ثالثًا، تاريخ الانقطاع الشفاف لخدمات Canonical الحرجة سيساعد المشترين في تصميم المرايا والأنماط غير المتصلة. رابعًا، دراسات الحالة التي تنشر أعداد الحزم وحجم الأسطول ونوافذ التغيير والعمل قبل وبعد والاستثناءات غير المحلولة ستكون أكثر فائدة من اقتباسات الشعارات.

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

حتى ذلك الحين، الاستنتاج العادل محدود لكنه ذو معنى. منصة Ubuntu التجارية من Canonical موثوقة لأنها مرتبطة بآليات نظام تشغيل حقيقية: دورات الإصدار، وتدفقات ESM، وأولويات APT، وإشعارات الأمان، وحالة Livepatch، وخططpro fix، وفحوصات unattended-upgrades، وربط الصور السحابية، وإدارة Landscape. تلك الآليات تعالج العمل المتكرر الذي يجعل أساطيل Linux باهظة الثمن بعد التثبيت الأول. لا تقضي على حوكمة الحزم، أو اختبار التراجع، أو إعادة التشغيل، أو تبعية الشبكة، أو انقطاع الخدمة، أو سياسة snap، أو برامج الطرف الثالث، أو التفاوض على نطاق الدعم. Ubuntu Pro هو الأقوى عندما يريد المشتري مزيدًا من الوقت المدعوم وأدلة أسطول أوضح. وهو الأضعف عندما يتوقع المشتري أن الاشتراك سيحول أسطول Linux غير المتجانس إلى نظام ذاتي الصيانة.

تبيع Canonical الوقت، ولكن ليس الوقت السلبي. تبيع طريقة لتأجيل بعض الترحيلات، وضغط بعض نوافذ الصيانة العاجلة، وجعل بعض التغطية مرئية، ونقل بعض أعمال دورة حياة Linux من العميل إلى بائع متخصص. لا يزال على العميل أن يقرر أي الآلات مهمة، وأي الحزم مسموحة، وأي النوى مدعومة، ومتى تحدث إعادة التشغيل، وأي الخدمات يمكنها الوصول إلى نقاط نهاية Canonical، وأي الاستثناءات مقبولة. هذا هو الاختبار التجاري الحقيقي لـ Canonical Group Limited: ليس ما إذا كان Ubuntu مجانيًا أو شائعًا أو محترمًا تقنيًا، ولكن ما إذا كانت Canonical تستطيع جعل دورة التصحيح العادية التالية أقل هشاشة من السابقة.