قصة تمهيدية أثرت على كل شيء

أعداء الواقع 12f-2

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

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

الخلفية + أي نوع من الوظائف هو هذا

نحن نبني منصة سحابة Mail.ru Cloud Solutions (MCS) ، حيث أعمل CTO. والآن - حان الوقت لإرفاق منصتنا IAM (إدارة الهوية والوصول) ، والتي توفر إدارة موحدة لجميع حسابات المستخدمين والمستخدمين وكلمات المرور والأدوار والخدمات وغيرها. سبب الحاجة إليها في السحابة سؤال واضح: يتم تخزين جميع معلومات المستخدم فيه.

عادةً ما تبدأ هذه الأشياء في البناء في بداية أي مشروع. لكن MCS تاريخيا كانت مختلفة قليلا. تم تصميم MCS في جزأين:

• Openstack مع وحدة ترخيص Keystone الخاصة بها ،
• Hotbox (S3 التخزين) على أساس مشروع Cloud Mail.ru ،

حولها الخدمات الجديدة التي ظهرت بعد ذلك.

في جوهرها ، كان هذان نوعان مختلفان من التصريح. بالإضافة إلى ذلك ، استخدمنا بعض التطورات المنفصلة Mail.ru ، على سبيل المثال ، تخزين كلمة مرور Mail.ru العامة ، بالإضافة إلى موصل openid مكتوب ذاتيًا ، والذي مكّن SSO (ترخيص المرور) في لوحة Horizon من الأجهزة الافتراضية (UI OpenStack الأصلية).

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

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

ما الذي سنطرحه؟

إذا كان وقحًا للغاية ، فقد أعدنا هذا في مكان ما خلال 4 أشهر:

• لقد صنعوا العديد من الشياطين الجديدة التي جمعت الوظائف التي عملت في السابق في أجزاء مختلفة من البنية التحتية. وصفت خدمات أخرى خلفية جديدة في شكل هذه الشياطين.
• لقد كتبنا مستودعنا المركزي الخاص بكلمات المرور والمفاتيح ، المتاح لجميع خدماتنا ، والذي يمكن تعديله مجانًا حسب حاجتنا.
• من البداية ، كتبوا 4 معلومات أساسية جديدة لـ Keystone (المستخدمون والمشاريع والأدوار وتعيينات الأدوار) ، والتي ، في الواقع ، حلت محل قاعدتها ، وتعمل الآن كمستودع مفرد لكلمات مرور المستخدم الخاصة بنا.
• قاموا بتدريس جميع خدمات Openstack الخاصة بنا للذهاب إلى خدمة سياسة الجهة الخارجية لسياساتهم بدلاً من قراءة هذه السياسات محليًا من كل خادم (نعم ، يعمل Openstack افتراضيًا على هذا النحو!)

مثل هذا التغيير الكبير يتطلب تغييرات كبيرة ومعقدة ، والأهم من ذلك ، تغييرات متزامنة في العديد من الأنظمة التي كتبها فرق تطوير مختلفة. بعد التجميع ، يجب أن يعمل النظام بأكمله.

كيفية طرح مثل هذه التغييرات وليس المسمار؟ أولاً ، قررنا أن ننظر قليلاً في المستقبل.

طرح استراتيجية

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

الاستطراد: ما هو التدريجي؟

<الحذر الفلسفة>

سوف يجيب كل متخصص في تكنولوجيا المعلومات بسهولة على ماهية الإصدار. كنت وضعت CI / CD ، ويتم تسليم كل شيء تلقائيا إلى همز. :)

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

والصورة كاملة هي على النحو التالي. يتكون تطبيق Rollout من أربعة جوانب كبيرة:

1. تسليم الرمز ، بما في ذلك تعديل البيانات. على سبيل المثال ، هجرتهم.
2. استعادة رمز - القدرة على العودة إذا حدث خطأ ما. على سبيل المثال ، من خلال إنشاء نسخ احتياطية.
3. الوقت من كل عملية التدريجي / الاستعادة. يجب على المرء أن يفهم توقيت أي عملية من النقطتين الأوليين.
4. وظيفة المتأثرة. من الضروري تقييم كل من الآثار السلبية الإيجابية المحتملة.

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

قانون 1..n ، التحضير للافراج

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

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

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

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

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

و هكذا ...

الفعل النهائي ، قبل طرحه

... حان الوقت لطرح.

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

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

1. تأثير (مقدس لنا ، أثمن) على البنية التحتية للمستخدم ،
2. الوظيفة: يجب أن يكون استخدام خدمتنا بعد طرحها هو نفسه كما كان من قبل.

طرح

اثنان المتداول ، 8 لا تتداخل

نتوقف عن العمل لجميع الطلبات الواردة من المستخدمين خلال 7 ساعات. في هذا الوقت ، لدينا كل من خطة البدء وخطة العودة.

• يستغرق بدء التشغيل نفسه حوالي 3 ساعات.
• 2 ساعة - للاختبار.
• 2 ساعة - احتياطي لاستعادة التغييرات المحتملة.

لقد تم تجميع مخطط جانت لكل إجراء ، وكم من الوقت يستغرق ، وما يجري في التسلسل ، وما يتم بالتوازي.


شريحة من مخطط جانت التمهيدي ، وهي واحدة من الإصدارات السابقة (بدون تنفيذ موازٍ). أداة التزامن الأكثر قيمة

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

وقائع الأحداث

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

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

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

كل شخص لديه خطة مطبوعة للنقاط ، يعرف الجميع من يفعل ماذا وفي أي وقت. بعد كل إجراء ، نتحقق من التوقيتات التي لا تتجاوزها ، وكل شيء يسير وفقًا للخطة. أولئك الذين لا يشاركون في النسخة التجريبية مباشرة في المرحلة الحالية ، يعدون من خلال إطلاق لعبة على الإنترنت (Xonotic ، النوع 3 kwaki) ، حتى لا يتدخلوا مع الزملاء. :)

02:00 صباحًا خرجت
مفاجأة سارة - لقد انتهينا من البدء بساعة قبل ذلك ، وذلك بسبب تحسين قواعد بياناتنا ونصوص الترحيل. الصرخة العالمية ، "خرجت!" جميع وظائف جديدة في همز ، ولكن حتى الآن فقط يمكننا أن نرى واجهة. ينتقل الجميع إلى وضع الاختبار ، ويتم فرزهم إلى أكوام ، ويبدأون في الاطلاع على ما حدث في النهاية.

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

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

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

03:00 صباحًا -2 المشاكل +2 المشاكل
تم إصلاح المشكلتين الكبيرتين السابقتين ، كل المشاكل الصغيرة أيضًا. جميع غير المشغولين في إصلاحات العمل بنشاط في حساباتهم والإبلاغ عن ما وجدوا. نعطي الأولوية للأولويات ونوزعها الأوامر ونتركها غير حرجة في الصباح.

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

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

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

04:00. كل شيء يعمل
جميع الاختبارات مرت ، لا توجد مشاكل حرجة مرئية. من وقت لآخر ، لا يعمل شيء ما في فريق ، نحن نرد بسرعة. في معظم الأحيان ، ناقوس الخطر غير صحيح. لكن في بعض الأحيان لم يصل شيء ما ، لا تعمل صفحة منفصلة في مكان ما. نجلس ، إصلاح ، إصلاح ، إصلاح. يطلق فريق منفصل آخر ميزة كبيرة - إعداد الفواتير.

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

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

07:00 صباحًا مشاكل تحميل API
يصبح من الواضح أن لدينا بعض الحمل المخطط بشكل غير صحيح على واجهة برمجة التطبيقات الخاصة بنا ونختبر هذا الحمل ، والذي لم يتمكن من تحديد المشكلة. نتيجة لذلك ، تفشل ≈5٪ من الطلبات. نحن نتحرك ونبحث عن سبب.

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

08:00. إصلاح API
طرحنا إصلاح للحمل ، فشل اليسار. نبدأ في العودة إلى المنزل.

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

ثم خلال اليوم ، كان هناك نشرات تحدد السجلات والإشعارات ورموز الإرجاع والرموز المخصصة لبعض عملائنا.

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

في المجموع

في غضون شهرين من الإعداد النشط للوقت المستغرق ، تم إنجاز 43 مهمة ، استمرت من ساعتين إلى عدة أيام.

أثناء المتداول:

• الشياطين الجديدة والمتغيرة - 5 قطع ، لتحل محل 2 متراصة.
• التغييرات داخل قواعد البيانات - تتأثر جميع قواعد البيانات الستة التي تحتوي على بيانات المستخدم ، ويتم إكمال عمليات التحميل من ثلاث قواعد بيانات قديمة إلى واحدة جديدة ؛
• إعادة بنائه بالكامل الواجهة الأمامية.
• عدد الشفرة التي تم ضخها - 33 ألف سطر من الكود الجديد ، thousand 3 آلاف سطر من الكود في الاختبارات ، thousand 5 آلاف سطر من كود الترحيل ؛
• جميع البيانات سليمة ، وليس هناك جهاز ظاهري واحد للعميل قد عانى. :)

الممارسات الجيدة للنشر الجيد

كنا نسترشد بهم في هذا الموقف الصعب. ولكن ، بشكل عام ، من المفيد أن نلاحظها في أي وقت. ولكن كلما كان التطبيق أصعب ، كلما زاد الدور الذي يلعبونه.

1. أول شيء عليك القيام به هو فهم كيف يمكن للتأثير أن يؤثر أو يؤثر على المستخدمين. هل سيكون هناك توقف؟ إذا كان الأمر كذلك ، فما هو التوقف؟ كيف سيؤثر هذا على المستخدمين؟ ما هي أفضل وأسوأ السيناريوهات؟ وإغلاق المخاطر.
2. خطة كل شيء. في كل مرحلة ، تحتاج إلى فهم جميع جوانب المتداول:
   
   • تسليم الكود
   • التراجع رمز؛
   • وقت كل عملية ؛
   • وظيفة المتضررة.
3. قم بتشغيل السيناريوهات حتى تصبح جميع مراحل النشر واضحة ، وكذلك المخاطر على كل منها. إذا كنت في أي شك ، يمكنك أخذ قسط من الراحة واستكشاف المرحلة المشكوك فيها بشكل منفصل.
4. كل مرحلة يمكن وينبغي تحسينها إذا كانت تساعد مستخدمينا. على سبيل المثال ، سوف يقلل من وقت التوقف أو يزيل بعض المخاطر.
5. يعد اختبار الاستعادة أكثر أهمية من اختبار تسليم الكود. من الضروري التحقق من أنه نتيجة الاستعادة ، سيعود النظام إلى حالته الأصلية ، ويؤكد ذلك من خلال الاختبارات.
6. كل ما يمكن أن يكون آليا يجب أن يكون آليا. كل شيء لا يمكن أن يكون آليا يجب كتابته مسبقا على ورقة الغش.
7. سجل معايير النجاح. ما هي الوظائف التي يجب أن تكون متاحة وفي أي وقت؟ إذا لم يحدث هذا ، فابدأ خطة التراجع.
8. والأهم من ذلك ، الناس. يجب أن يكون الجميع على دراية بما يفعله ، وما الذي يعتمد على تصرفاته وما الذي يعتمد عليه.

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