الإطلاق الخفي هو أفضل إطلاق خفيف

بيض عيد الفصح في كل مكان

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

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

1. مكالمة طوارئ: تلقينا مكالمة هاتفية طارئة منهم في غضون دقائق بينما كنا بالفعل في حيرة من نتائج التوصيات ونحاول تصحيح الأخطاء فيها. كانت لدينا توصيات ببيض عيد الفصح على كل صفحة تقريبًا من صفحات موقعهم الإلكتروني. اتضح أننا أخطأنا في تهيئة معرف النموذج (model id) بالنموذج الذي دربناه في أبريل باستخدام بيانات تسوق عيد الفصح الخاصة بهم! قمنا على الفور بتبديل معرف النموذج إلى الجديد وتم إصلاح تلك المشكلة.
2. زيادة في وقت استجابة p90: اتضح أننا كنا نستخدم أوصاف المنتجات كميزات في نموذجنا، وكانت بعض الأوصاف طويلة جدًا مما زاد من وقت حساب الميزات لدينا. لم يكن من السهل اكتشاف ذلك أثناء اختباراتنا دون اتصال بالإنترنت لأن وقت استجابة النموذج بدا جيدًا في معظم الحالات. لم يكن هناك حل فوري جيد لهذه المشكلة، واضطررنا أساسًا إلى العودة إلى النظام القائم على القواعد حتى قمنا بإصلاح عملية استخلاص الميزات (featurization) وإعادة اختبار النموذج.

بشكل عام، أدى ذلك إلى الكثير من إطفاء الحرائق (حل المشكلات العاجلة)، والكثير من فقدان المصداقية، وعميل كاد أن يُفقد. من خلال مراجعتنا الداخلية اللاحقة، أدركنا أنه بينما كانت المشكلة رقم 1 مجرد خطأ يدوي، كان من المستحيل تقريبًا اكتشاف مشكلات مثل المشكلة رقم 2 دون اتصال بالإنترنت. منذ ذلك الحين، انتقلنا إلى الجانب المشرق من تنفيذ الإطلاقات المظلمة!

ما هو الإطلاق المظلم؟

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

الإطلاق المظلم هو طريقة خفيفة لإطلاق خدماتك.

بأقل قدر ممكن من السلبيات وإمكانات إيجابية هائلة.

كيفية تنفيذ الإطلاق المظلم؟

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

1. اعتماد بنية الخدمات المصغرة: من المهم اعتماد بنية خدمات مصغرة تعتمد على واجهة برمجة التطبيقات (API) لتتمكن من اختبار خدماتك الجديدة بشكل تدريجي. تتمثل طريقة تنفيذ الإطلاق الخفي في إعادة تشغيل نسخة من حركة المرور الإنتاجية إلى واجهة خلفية جديدة، ويتم ذلك على أفضل وجه إذا كانت خدمة الإنتاج الحالية والخدمة الجديدة متاحتين كخدمة مصغرة ويتم الاتصال عبر استدعاء REST / gRPC.
2. تقسيم حركة المرور: غالبًا ما تكون الواجهة الأمامية للتطبيق هي المكان الذي يقوم فيه الأشخاص بتقسيم حركة المرور، حيث يتم توجيه نسبة مئوية من حركة المرور الإنتاجية إلى الخدمة الجديدة.
3. استدعاءات غير متزامنة: المبدأ العام للاختبار هو أنه لا ينبغي أن يؤثر سلبًا على تجربتك الإنتاجية الفعلية. عند الإطلاق الخفي، فإنك تقوم عمليًا بتكرار حركة المرور الإنتاجية مما قد يضاعف زمن الاستجابة لديك ما لم تجعل استدعاءات الواجهة الخلفية غير متزامنة. إذا لم تكن خدمتك حساسة لزمن الاستجابة، فإن تحديد مهل زمنية معقولة يمكن أن يكون حلاً أيضًا.
4. البنية التحتية: من الناحية المثالية، تكون مؤسستك قد أنشأت بنية تحتية يسهل توسيعها أفقيًا، لأنه كلما زادت نسبة حركة المرور إلى خدمة الإطلاق الخفي لديك، ستحتاج إلى توسيع بنيتك التحتية تدريجيًا أيضًا. في معظم الحالات، قد يكون من المنطقي حتى محاكاة حركة المرور القصوى بالكامل وما بعدها للتأكد من أن خدمتك الجديدة ستتوسع حقًا.
5. التسجيل: ستحتاج إلى تسجيل الطلبات والاستجابات من خدمات الواجهة الخلفية القديمة والجديدة لتتمكن من مقارنة الاستجابة وأداء الخدمة. إذا كان نموذج تعلم آلة، فأنت تريد التأكد من أن تنبؤات نموذجك لا تقل جودة عن نموذجك القديم. يتطلب هذا تسجيلًا مكثفًا.
6. المراقبة: الإطلاق الخفي عديم الفائدة إلى حد كبير إذا لم يكن لديك لوحات معلومات جيدة للمراقبة والأجهزة حيث يمكنك مقارنة وقت التشغيل، وزمن الاستجابة، وقابلية التوسع، وجودة استجابة خدمتك الجديدة. من الناحية المثالية، يجب أن يحدث هذا في الوقت الفعلي حتى يمكن اكتشاف الشذوذات وإظهارها بسرعة.

هل الإطلاق الخفي مجرد اختبار متطور غير متصل بالإنترنت؟

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

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

إذا كان لديك فضول أكبر حول الإطلاقات الخفية أو ترغب في مشاركة بعض من تجربتك، يرجى التواصل معي على nikunj@truefoundry.com!

TrueFoundry هي منصة كخدمة (PaaS) لنشر تعلم الآلة (ML) تعمل فوق Kubernetes لتسريع سير عمل المطورين مع منحهم مرونة كاملة في اختبار ونشر النماذج، وضمان الأمان والتحكم الكامل لفريق البنية التحتية. من خلال منصتنا، نمكّن فرق تعلم الآلة من نشر ومراقبة النماذج في 15 دقيقة بموثوقية 100% وقابلية للتوسع، والقدرة على التراجع في ثوانٍ - مما يسمح لهم بتوفير التكلفة وإطلاق النماذج إلى الإنتاج بشكل أسرع، مما يحقق قيمة تجارية حقيقية.