الإسراع بالتسليم المتواصل

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

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

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

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

صحة النشر: يضمن شكل اختبار النشر الأساسي أنه يمكن بدء العناصر التي نُشرت حديثًا كما يمكنها الاستجابة للعمل. وكجزء من تدفق العمل اللاحق، فإننا نُشغِّل عمليات فحص سريعة تضمن أنه تم بدء العناصر التي نُشرت حديثًا وهي تخدم الآن حركة مرور الشبكة. على سبيل المثال، نحن نستخدم خطاطيف حدث دورة الحياة في ملف AWS CodeDeploy AppSpec لحث البرامج النصية البسيطة على وقف النشر وبدئه والتحقق منه. كما أننا نتحقق أيضًا من امتلاكنا السعة الكافية لخدمة حركة مرور العملاء. لقد أنشأنا تقنيات مثل أدنى حد من المضيفين السليمين في CodeDeploy للتحقق من أننا نمتلك دومًا سعة كافية لخدمة عملائنا. وأخيرًا، إذا تمكن محرك النشر من الكشف عن عيب، يجب أن يقوم بإرجاع التغيير لتقليل وقت رؤية العملاء للعيب.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

التشغيل السريع حتى اليوم. وصلت Amazon الآن إلى المرحلة التي تهدف فيها الفرق إلى إجراء أتمتة كاملة بمجرد كتابتهم تعليمة برمجية جديدة. وبالنسبة لنا، تعد الأتمتة الطريقة الوحيدة التي تمكننا من خلالها من مواصلة نمو أعمالنا.