قصة البداية التي أثرت على كل شيء

أعداء الواقع بواسطة 12f-2

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

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

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

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

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

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

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

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

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

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

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

وبعبارة أخرى، في حوالي 4 أشهر قمنا بإعداد ما يلي:

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

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

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

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

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

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

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

يمكن لكل متخصص في تكنولوجيا المعلومات الإجابة بسهولة على ماهية الطرح. تقوم بتثبيت CI/CD، ويتم تسليم كل شيء تلقائيًا إلى المتجر. 🙂

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

والصورة كاملة هكذا. يتكون الطرح من أربعة جوانب رئيسية:

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

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

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

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

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

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

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

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

و حينئذ…

الفعل الأخير، قبل طرحه

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

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

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

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

المتداول خارج

لفة اثنين، 8 لا تتدخل

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

في المجموع

خلال شهرين من الإعداد النشط للطرح، تم إكمال 2 مهمة، استمرت من بضع ساعات إلى عدة أيام.

أثناء الطرح:

• شياطين جديدة ومتغيرة - 5 قطع، لتحل محل وحدتين متراصتين؛
• التغييرات داخل قواعد البيانات - تأثرت جميع قواعد البيانات الست التي تحتوي على بيانات المستخدم، وتم إجراء التنزيلات من ثلاث قواعد بيانات قديمة إلى قاعدة بيانات جديدة واحدة؛
• واجهة أمامية مُعاد تصميمها بالكامل؛
• كمية التعليمات البرمجية التي تم تنزيلها - 33 ألف سطر من التعليمات البرمجية الجديدة، ≈ 3 آلاف سطر من التعليمات البرمجية في الاختبارات، ≈ 5 آلاف سطر من كود الترحيل؛
• جميع البيانات سليمة، ولم يتضرر أي جهاز افتراضي خاص بالعميل. 🙂

الممارسات الجيدة للطرح الجيد

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

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

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

المصدر: www.habr.com