أربع مرات في السنة، أصبحت منصة إدخال الطلبات في Nike الأصل الرقمي الأكثر أهمية في الشركة. آلاف بائعي المنتجات من كل حجم ونوع اصطفوا لتقديم طلباتهم للموسم التالي. أسبوع واحد، موعد نهائي واحد، 13 مليار دولار في التزامات المخزون.
المنصة والضغط ربع السنوي الذي لم تتمكن من الهروب منه
الحجم كان مستحيل تجاهله. معالجة Nike لأكثر من 13 مليار دولار في طلبات المخزون المخطط لها خلال كل دورة طلب ربع سنوية. جاءت هذه الطلبات من كل مكان في نظام البيع بالتجزئة التابع لـ Nike، من بائعي التجزئة الوطنيين الرئيسيين إلى متاجر الرياضة الصغيرة المستقلة. كان لديهم جميعاً موعد نهائي. تقاربوا جميعاً ضمن أسبوع واحد، أربع مرات في السنة.
كانت المنصة التي تعالج هذا مبنية على البنية التحتية الموروثة من الماضي. أجهزة مخصصة باهظة الثمن مصممة لأعباء عمل ثابتة وقابلة للتنبؤ. كانت كائن ضخم من القرن العشرين. لم تتمكن من التوسع بشكل ديناميكي. لم تتمكن من التعامل مع الارتفاع ربع السنوي دون أن تئن من الإرهاق. بعد انقضاء كل موعد طلب، جلس 75% من تلك البنية التحتية المكلفة في خمول لمدة ثلاثة أشهر حتى اقترب الموعد النهائي التالي.
كانت المشكلة الهيكلية واضحة. تم بناء منصة للتعامل مع متوسط الحمل الكهربائي مطلوب منها التعامل مع أحمال ذروة كانت أكبر بأوامر من الحجم. ببساطة، لا يمكن للأجهزة التقليدية امتصاص هذا القدر من التقلب دون هدر ضخم.
كانت Nike تستخدم هذا النظام منذ سنوات. عمل، تقنياً. لكنها عملت بتكلفة باهظة. وعملت بطريقة ضمنت قيوداً على كيف يمكن للعمل أن يتطور.
لماذا كان الرفع والنقل هو القرار الصحيح
كانت الشراكة الموجودة لـ TechSparq مع Nike هي المسرع. سنوات من فهم منطق أعمال Nike والأنظمة البرمجية والإيقاعات التشغيلية. عندما تم الموافقة على هجرة إدخال الطلبات، تم إحضار مهندسي TechSparq على الفور. لم تكن هناك فترة تصعيد تقضيها في السؤال "ماذا يفعل هذا النظام؟" كان الفريق يعرف بالفعل.
كان الاختيار الاستراتيجي هو نهج الرفع والنقل. تم نسخ كل مكون من التطبيق الموروث ضمن بيئة Amazon باستخدام ما هو قريب جداً من موطئ القدم المادي الأصلي. لم تكن محاولة للتحسين أو إعادة البناء من الصفر. كان قرار متعمد للحفاظ على المنطق المعروف الجيد، لإثبات عمل الهجرة، وتأجيل التحسين إلى المرحلة 2.
كان حجم ما يتم نقله كبيراً. مائة عقدة على الأقل تتكون من خوادم تطبيقات Java وقواعد بيانات Oracle 11i وعناقيد MongoDB ومخدمات الويب Apache وبنية تحتية للبحث Apache SOLR ومراسلة RabbitMQ وتقنيات أخرى مترابطة مختلفة. كان يجب أن تعمل جميعاً في المرة الأولى، وإلا فإن دورة الطلب في Nike ستعاني.
اعتمد الفريق منهجيات Agile Scrum. أثبت هذا الاختيار أنه حرج لما حدث بعد ذلك.
كيف أصبح جدول زمني لـ 12 شهراً إلى 5 أشهر
بدأ المشروع بنافذة تسليم مدتها 12 شهراً. كان هذا هو تقدير الأساس بناءً على النطاق والتعقيد. بحلول الشهر الثاني، كان هناك شيء تحول.
أنشأت Agile Scrum رؤية في ما كان فعلياً ممكناً. أظهرت مقاييس السرعة أن الفريق يتحرك بشكل أسرع من المتوقع. كشفت الرشقات عن التبعيات التي يمكن التخلص منها. أظهرت الاستعراضات ما كان يعمل وما لم يكن كذلك. بدلاً من انتظار 12 شهراً لاكتشاف المشاكل، وجدوها كل أسبوعين.
بعد شهرين من التطوير، انضغط الجدول الزمني من 12 شهراً إلى 9 أشهر. كان الفريق يتحرك ببساطة بشكل أسرع مما قدره التقدير الأصلي. مع استمرار تفاقم السرعة، انضغط الجدول الزمني مرة أخرى. أصبح تسعة أشهر سبعة. أصبح سبعة أشهر خمسة.
كل هذا حدث خلال الشهرين الأوليين من التطوير. كان الفريق قد تحرك بسرعة كبيرة وتعلم الكثير حتى عرفوا أن المشروع يمكن أن ينزل في خمسة أشهر، ليس لأنهم عملوا ساعات أطول، بل لأن التخطيط الشلالي كان متشائماً بشأن ما كان قابلاً للتحقيق مع التسليم التكراري.
بحلول الوقت الذي وصل الجدول الزمني لمدة خمسة أشهر، كانت منصة إدخال الطلبات بأكملها تعمل على AWS. كان المشروع نجاحاً متحمساً.
ما فتحته AWS بما يتجاوز توفيرات التكاليف
كان التأثير المالي الفوري مستحيل تجاهله. تحقق Nike ملايين الدولارات من المدخرات سنوياً من الهجرة وحدها. اختفت البنية التحتية الضخمة التي جلست في خمول 75% من السنة. في مكانها كانت منصة توسعت فقط بقدر ما تحتاجه، عندما تحتاجه.
لكن فتح أكبر كان القدرة. تم نقل خط أنابيب التجارة الإلكترونية بأكملها إلى AWS. خط الأنابيب المستمر للتكامل الذي ينشئ الرمز والاختبارات والنشرات يعمل الآن داخل AWS نفسه. يمكن لفرق التطوير إعداد البيئات حسب الطلب. يمكنهم هدمهم عندما ينتهون. تم التخلص من احتكاك توفير الأجهزة.
بدأت المرحلة 2. سيضيف التطور التالي للمنصة التوسع الديناميكي. سيزيد الحساب عندما تقترب مواعيد الطلب ربع السنوية. بعد مرور الموعد النهائي، يتم التحجيم الخلفي للموارد. ستطابق المنصة الآن موطئ قدمها من الموارد للطلب الفعلي. اكتشفت Nike أن نظاماً مبنياً للانفجار غالباً ما يكون أفضل طريقة لخدمة المتوسط أيضاً.
تقدر تكاليف الاستضافة بـ 20% من نفقات السنة الأصلية. انخفاض بنسبة 80%. لكن هذا الرقم وحده لا يلتقط التحول الحقيقي. كان ما يهم أكثر أن العمل أصبح رشيقاً. يمكن لفريق التجارة الإلكترونية أن يطلق البرنامج بشكل أسرع. يمكنهم تجربة الميزات التي كانت مستحيلة للاختبار في نموذج الأجهزة القديمة.
ما يعنيه هذا بالنسبة للمنصات المؤسسية ذات مشاكل حركة المرور المتفجرة
دورة الطلب ربع السنوية في Nike ليست فريدة. البيع بالتجزئة الموسمي وإطلاقات المنتجات والمبيعات السريعة والأحداث الترويجية المحددة بوقت والإفراجات ربع السنوية عن الأرباح. التجارة الإلكترونية مليئة بالانفجارات القابلة للتنبؤ. أي علامة تجارية بموسم بيع محدد تفهم المشكلة.
ينشئ نموذج الأجهزة الموروث فخاً هيكلياً. جهز للذروة، وتضيع المال 75% من الوقت. جهز للمتوسط، وتفشل عندما تصل الذروة. لا توجد إجابة جيدة في النموذج القديم. يحل التوسع الديناميكي السحابي هذا. الموارد تطابق الطلب. الفاتورة تطابق الاستهلاك.
لكن ضغط الجدول الزمني يكشف عن شيء مهم بنفس القدر. كان وجود شريك بمعرفة مسبقة بالنظام مهماً بشكل كبير. لم تكن TechSparq بحاجة للتعلم عن منطق أعمال Nike من البداية. كانت هذه السياق موجوداً بالفعل. كان التصعيد مقاساً بالأسابيع، وليس الأشهر. قفز الفريق مباشرة إلى التسليم.
هذا العمق الشراكة هو ما جعل عملية Agile Scrum فعالة جداً. تتفاقم السرعة عندما يعرف الفريق بالفعل ما يبنونه ولماذا يهم ذلك.
- عمق الشراكة يقلل وقت التصعيد. الشريك الذي يفهم بالفعل أنظمتك يمكنه التحرك بشكل أسرع من الفريق الذي يتعلم من الصفر.
- الرفع والنقل يحافظ على تحمل المخاطر. إثبات عمل الهجرة قبل التحسين يعني عدم وجود مفاجآت غير متوقعة.
- تتفاقم السرعة الرشيقة. يكشف التسليم التكراري عما هو فعلاً ممكن أسرع مما يمكن للتخطيط الشلالي فعله.
- السحابة تفتح التوسع الديناميكي. الأجهزة لم تستطع أبداً. التوسع الديناميكي هو الإجابة على حركة المرور المتفجرة التي لن تختفي أبداً.
هل منصتك مبنية للحظات التي تهم؟
حركة المرور المتفجرة والطلب الموسمي وأحمال العمل التي تحركها الأحداث لم تعد مشاكل غير قابلة للحل. دعنا نتحدث عن كيفية ترحيل البنية التحتية الخاصة بك لمطابقة اللحظات الأكثر أهمية لعملك.
حجز استشارة