یک داستان رونمایی که همه چیز را تحت تاثیر قرار داد

دشمنان واقعیت توسط 12f-2

در پایان آوریل، زمانی که وایت واکرها وینترفل را محاصره کردند، اتفاق جالب تری برای ما افتاد؛ ما یک انتشار غیرعادی انجام دادیم. در اصل، ما دائماً در حال ارائه ویژگی های جدید در تولید هستیم (مانند بقیه). اما این یکی فرق داشت. مقیاس آن به گونه ای بود که هر گونه اشتباه احتمالی که می توانستیم مرتکب شویم، بر همه خدمات و کاربران ما تأثیر می گذاشت. در نتیجه، ما همه چیز را طبق برنامه، در مدت زمان توقف برنامه‌ریزی‌شده و اعلام‌شده، بدون عواقب فروش، عرضه کردیم. مقاله در مورد این است که چگونه به این امر دست یافتیم و چگونه هر کسی می تواند آن را در خانه تکرار کند.

من اکنون تصمیمات معماری و فنی که گرفتیم را شرح نمی دهم یا نمی گویم که همه اینها چگونه کار می کند. اینها بیشتر یادداشت هایی در حاشیه درباره چگونگی انجام یکی از دشوارترین عرضه ها هستند که من مشاهده کردم و مستقیماً در آن نقش داشتم. من ادعای کامل بودن یا جزئیات فنی ندارم، شاید در مقاله دیگری ظاهر شوند.

پس زمینه + این چه نوع عملکردی است؟

ما در حال ساخت یک پلتفرم ابری هستیم Mail.ru Cloud Solutions (MCS)، جایی که من به عنوان مدیر فنی کار می کنم. و اکنون زمان آن رسیده است که IAM (مدیریت هویت و دسترسی) را به پلتفرم خود اضافه کنیم، که مدیریت یکپارچه همه حساب‌های کاربری، کاربران، گذرواژه‌ها، نقش‌ها، خدمات و موارد دیگر را فراهم می‌کند. چرا در ابر مورد نیاز است یک سوال واضح است: تمام اطلاعات کاربر در آن ذخیره می شود.

معمولاً چنین چیزهایی در همان ابتدای هر پروژه ساخته می شوند. اما از نظر تاریخی همه چیز در MCS کمی متفاوت بوده است. MCS در دو بخش ساخته شده است:

• Openstack با ماژول مجوز Keystone خودش،
• هات باکس (ذخیره سازی S3) بر اساس پروژه Mail.ru Cloud،

سپس خدمات جدیدی در اطراف آن ظاهر شد.

در اصل، اینها دو نوع مختلف مجوز بودند. به علاوه، ما از برخی پیشرفت‌های جداگانه Mail.ru استفاده کردیم، به عنوان مثال، یک ذخیره‌سازی عمومی رمز عبور Mail.ru، و همچنین یک رابط بازنویسی خودکار، که به لطف آن SSO (مجوز سرتاسر) در پانل Horizon ارائه شد. ماشین های مجازی (واسط کاربری OpenStack بومی).

ساخت IAM برای ما به این معنی بود که همه آن را به یک سیستم واحد و کاملاً خودمان متصل کنیم. در عین حال، ما هیچ کارکردی را در طول مسیر از دست نخواهیم داد، بلکه پایه‌ای برای آینده ایجاد خواهیم کرد که به ما امکان می‌دهد آن را به‌طور شفاف و بدون بازسازی و مقیاس‌بندی آن از نظر عملکرد، اصلاح کنیم. همچنین در ابتدا، کاربران یک الگو برای دسترسی به خدمات (RBAC مرکزی، کنترل دسترسی مبتنی بر نقش) و برخی چیزهای کوچک دیگر داشتند.

معلوم شد که این کار بی اهمیت است: پایتون و پرل، چندین پشتیبان، سرویس های نوشته شده مستقل، چندین تیم توسعه و ادمین. و مهمتر از همه، هزاران کاربر زنده در سیستم تولید رزمی وجود دارد. همه اینها باید نوشته می شد و مهمتر از همه بدون تلفات منتشر می شد.

قرار است چه چیزی را عرضه کنیم؟

به طور کلی در عرض 4 ماه موارد زیر را آماده کردیم:

• ما چندین دیمون جدید ایجاد کردیم که توابعی را که قبلاً در بخش‌های مختلف زیرساخت کار می‌کردند جمع‌آوری کردند. مابقی خدمات، باطن جدیدی در قالب این شیاطین تجویز شد.
• ما ذخیره‌سازی مرکزی خودمان از رمزهای عبور و کلیدها را نوشتیم، که برای همه سرویس‌هایمان در دسترس است، که می‌توان آزادانه آن‌ها را در صورت نیاز تغییر داد.
• ما 4 Backend جدید برای Keystone از ابتدا نوشتیم (کاربران، پروژه ها، نقش ها، انتساب نقش)، که در واقع جایگزین پایگاه داده آن شد و اکنون به عنوان یک مخزن واحد برای رمزهای عبور کاربر ما عمل می کند.
• ما به همه سرویس‌های Openstack خود آموزش دادیم که به‌جای خواندن این خط‌مشی‌ها به صورت محلی از هر سرور، به یک سرویس خط‌مشی شخص ثالث برای خط‌مشی‌های خود مراجعه کنند (بله، Openstack به طور پیش‌فرض اینگونه کار می‌کند!)

چنین بازسازی عمده ای مستلزم تغییرات بزرگ، پیچیده و مهمتر از همه، تغییرات همزمان در چندین سیستم است که توسط تیم های توسعه مختلف نوشته شده است. پس از مونتاژ، کل سیستم باید کار کند.

چگونه می توان چنین تغییراتی را ایجاد کرد و آن را خراب نکرد؟ ابتدا تصمیم گرفتیم کمی به آینده نگاه کنیم.

استراتژی عرضه

• می‌توان محصول را در چند مرحله عرضه کرد، اما زمان توسعه را تا سه برابر افزایش می‌دهد. علاوه بر این، برای مدتی ما همگام سازی کامل داده ها در پایگاه داده ها را خواهیم داشت. شما باید ابزارهای همگام سازی خود را بنویسید و برای مدت طولانی با چندین فروشگاه داده زندگی کنید. و این باعث ایجاد طیف گسترده ای از خطرات می شود.
• هر چیزی که می توانست به صورت شفاف برای کاربر آماده شود از قبل انجام شده است. 2 ماه طول کشید.
• ما به خودمان برای چندین ساعت زمان از کار افتادن اجازه دادیم - فقط برای عملیات کاربر برای ایجاد و تغییر منابع.
• برای بهره برداری از همه منابع از قبل ایجاد شده، خرابی غیرقابل قبول بود. ما برنامه ریزی کردیم که در طول عرضه، منابع باید بدون توقف کار کنند و بر مشتریان تأثیر بگذارند.
• برای کاهش تأثیر روی مشتریانمان در صورت بروز مشکل، تصمیم گرفتیم عصر یکشنبه عرضه کنیم. مشتریان کمتری در شب ماشین های مجازی را مدیریت می کنند.
• ما به همه مشتریان خود هشدار دادیم که در طول دوره انتخاب شده برای عرضه، مدیریت خدمات در دسترس نخواهد بود.

انحراف: عرضه چیست؟

<احتیاط، فلسفه>

هر متخصص فناوری اطلاعات می تواند به راحتی پاسخ دهد که عرضه چیست. شما CI/CD را نصب می کنید و همه چیز به طور خودکار به فروشگاه تحویل داده می شود. 🙂

البته این درست است. اما مشکل این است که با ابزارهای اتوماسیون تحویل کد مدرن، درک خود از عرضه از بین می رود. چگونه با نگاه کردن به حمل و نقل مدرن، حماسه اختراع چرخ را فراموش می کنید. همه چیز به قدری خودکار است که عرضه اغلب بدون درک کامل تصویر انجام می شود.

و کل تصویر به این صورت است. انتشار شامل چهار جنبه اصلی است:

1. تحویل کد، از جمله اصلاح داده ها. مثلا مهاجرت هایشان.
2. بازگشت کد توانایی بازگشت به عقب در صورت بروز مشکل است. به عنوان مثال، از طریق ایجاد پشتیبان.
3. زمان هر عملیات عرضه/بازگشت. شما باید زمان هر عملیات دو نقطه اول را درک کنید.
4. عملکرد تحت تأثیر قرار گرفته است. ارزیابی هر دو اثر مثبت و احتمالی منفی ضروری است.

همه این جنبه ها باید برای عرضه موفقیت آمیز در نظر گرفته شوند. معمولاً فقط اولین یا در بهترین حالت نقطه دوم ارزیابی می شود و سپس عرضه موفقیت آمیز در نظر گرفته می شود. اما سومین و چهارمین اهمیت بیشتری دارند. اگر عرضه به جای یک دقیقه 3 ساعت طول بکشد، کدام کاربر آن را دوست دارد؟ یا اگر چیزی غیر ضروری در طول عرضه تحت تأثیر قرار گیرد؟ یا توقف یک سرویس منجر به عواقب غیر قابل پیش بینی می شود؟

قانون 1..n، آماده سازی برای آزادی

در ابتدا به این فکر افتادم که جلسات خود را به طور خلاصه شرح دهم: کل تیم، بخش‌های آن، انبوهی از بحث‌ها در نقاط قهوه، بحث‌ها، آزمون‌ها، طوفان فکری. بعد فکر کردم غیر ضروری است. چهار ماه توسعه همیشه شامل این است، به خصوص زمانی که چیزی نمی نویسید که بتوان به طور مداوم ارائه کرد، بلکه یک ویژگی بزرگ برای یک سیستم زنده است. که همه سرویس‌ها را تحت تأثیر قرار می‌دهد، اما هیچ چیز برای کاربران به جز «یک دکمه در رابط وب» نباید تغییر کند.

درک ما از نحوه ارائه از هر جلسه جدید و کاملاً قابل توجه تغییر می کند. به عنوان مثال، ما قرار بود کل پایگاه داده صورتحساب خود را به روز کنیم. اما ما زمان را محاسبه کردیم و متوجه شدیم که انجام این کار در زمان عرضه معقول غیرممکن است. تقریباً یک هفته بیشتر طول کشید تا پایگاه داده صورتحساب را بایگانی کنیم. و هنگامی که سرعت عرضه مورد انتظار هنوز رضایت بخش نبود، سخت افزار اضافی و قدرتمندتر را سفارش دادیم، جایی که کل پایگاه کشیده شد. اینطور نیست که ما نمی خواستیم این کار را زودتر انجام دهیم، اما نیاز فعلی به عرضه، هیچ گزینه ای برای ما باقی نگذاشت.

وقتی یکی از ما شک داشت که عرضه می‌تواند بر در دسترس بودن ماشین‌های مجازی ما تأثیر بگذارد، یک هفته را صرف انجام آزمایش‌ها، آزمایش‌ها، تجزیه و تحلیل کد کردیم و متوجه شدیم که این اتفاق در تولید ما نمی‌افتد، و حتی مشکوک‌ترین افراد نیز موافقت کردند. با این.

در این بین، بچه‌های پشتیبانی فنی آزمایش‌های مستقل خود را برای نوشتن دستورالعمل‌هایی برای مشتریان در مورد روش‌های اتصال انجام دادند، که قرار بود پس از عرضه تغییر کند. آنها روی UX کاربر کار کردند، دستورالعمل ها را تهیه کردند و مشاوره های شخصی ارائه کردند.

ما تمام عملیات عرضه را که امکان پذیر بود، خودکار کردیم. هر عملیاتی، حتی ساده‌ترین آنها، برنامه‌نویسی شده بود و آزمایش‌ها دائماً اجرا می‌شد. آنها در مورد بهترین راه برای خاموش کردن سرویس بحث کردند - حذف دیمون یا مسدود کردن دسترسی به سرویس با فایروال. ما یک چک لیست از تیم ها برای هر مرحله از عرضه ایجاد کردیم و آن را دائماً به روز کردیم. ما نمودار گانت را برای همه کارهای عرضه شده با زمان بندی ترسیم کردیم و دائماً به روز کردیم.

و بنابراین…

عمل نهایی، قبل از انتشار

... زمان عرضه است.

همانطور که می گویند، یک اثر هنری را نمی توان تکمیل کرد، فقط کار روی آن را تمام کرد. شما باید با اراده تلاش کنید، درک کنید که همه چیز را پیدا نخواهید کرد، اما باور داشته باشید که تمام فرضیات منطقی را انجام داده اید، برای همه موارد ممکن، تمام اشکالات مهم را بسته اید، و همه شرکت کنندگان هر کاری که می توانستند انجام دادند. هرچه کد بیشتری را منتشر کنید، متقاعد کردن خود در این مورد دشوارتر است (علاوه بر این، همه می دانند که پیش بینی همه چیز غیرممکن است).

وقتی متقاعد شدیم که هر کاری ممکن است انجام داده‌ایم تا تمام خطرات ناشی از تأثیرات غیرمنتظره و خرابی‌ها را برای کاربران خود پوشش دهیم، تصمیم گرفتیم که آماده عرضه باشیم. یعنی هر چیزی ممکن است اشتباه کند به جز:

1. بر زیرساخت‌های کاربر (برای ما مقدس، ارزشمندترین) تأثیر بگذارد،
2. عملکرد: استفاده از سرویس ما پس از عرضه باید مانند قبل باشد.

نورد کردن

دو رول، 8 دخالت نکن

ما برای تمام درخواست‌های کاربران به مدت ۷ ساعت از کار افتادگی می‌گیریم. در حال حاضر، ما هم یک برنامه رونمایی داریم و هم یک برنامه بازگشت.

• خود عرضه تقریباً 3 ساعت طول می کشد.
• 2 ساعت برای تست
• 2 ساعت - برای بازگشت احتمالی تغییرات رزرو کنید.

نمودار گانت برای هر عمل، مدت زمان طول می کشد، آنچه به طور متوالی اتفاق می افتد، آنچه به طور موازی انجام می شود، ترسیم شده است.

قطعه ای از یک نمودار گانت رولی، یکی از نسخه های اولیه (بدون اجرای موازی). با ارزش ترین ابزار همگام سازی

همه شرکت‌کنندگان باید نقش خود را در عرضه، وظایفی که انجام می‌دهند و مسئولیت آن‌ها را تعیین کنند. ما سعی می‌کنیم هر مرحله را به حالت خودکار برسانیم، آن را اجرا کنیم، بازگردانیم، بازخورد جمع‌آوری کنیم و دوباره آن را اجرا کنیم.

وقایع نگاری وقایع

بنابراین یکشنبه 15 فروردین ساعت 29 شب 10 نفر سر کار آمدند. علاوه بر شرکت کنندگان کلیدی، برخی از آنها صرفاً برای حمایت از تیم آمده بودند که از آنها تشکر ویژه ای دارم.

همچنین لازم به ذکر است که تستر کلید ما در تعطیلات است. راه اندازی بدون آزمایش غیرممکن است، ما در حال بررسی گزینه ها هستیم. یکی از همکاران موافقت می کند که ما را از تعطیلات آزمایش کند، که به خاطر آن از کل تیم تشکر فراوانی دریافت می کند.

00:00. متوقف کردن
درخواست‌های کاربر را متوقف می‌کنیم، تابلویی را می‌زنیم که می‌گوید کار فنی. مانیتورینگ فریاد می زند، اما همه چیز عادی است. ما بررسی می کنیم که چیزی به جز آنچه که قرار بود سقوط کند، سقوط نکرده باشد. و ما کار مهاجرت را شروع می کنیم.

هرکسی نقطه به نقطه یک طرح انتشار چاپ شده دارد، همه می دانند چه کسی چه کاری و در چه لحظه ای انجام می دهد. پس از هر اقدام، زمان‌بندی‌ها را بررسی می‌کنیم تا مطمئن شویم از آنها تجاوز نمی‌کنیم و همه چیز طبق برنامه پیش می‌رود. کسانی که در مرحله فعلی مستقیماً در رول اوت شرکت نمی کنند، با راه اندازی یک اسباب بازی آنلاین (Xonotic، نوع 3 quacks) آماده می شوند تا مزاحم همکاران خود نشوند. 🙂

02:00. رول شد
یک شگفتی خوشایند - به دلیل بهینه سازی پایگاه داده ها و اسکریپت های مهاجرت، ما یک ساعت زودتر عرضه را به پایان می رسانیم. فریاد عمومی، "غلتید بیرون!" همه توابع جدید در حال تولید هستند، اما تاکنون فقط ما می توانیم آنها را در رابط مشاهده کنیم. همه وارد حالت تست می شوند، آنها را به گروه دسته بندی می کنند و شروع می کنند تا ببینند در پایان چه اتفاقی افتاده است.

خیلی خوب نشد، ما این را بعد از 10 دقیقه متوجه می‌شویم، زمانی که هیچ چیز به پروژه‌های اعضای تیم متصل نیست یا کار نمی‌کند. همگام‌سازی سریع، مشکلات خود را بیان می‌کنیم، اولویت‌ها را تعیین می‌کنیم، به تیم‌ها تقسیم می‌شویم و به اشکال‌زدایی می‌رویم.

02:30. دو مشکل بزرگ در مقابل چهار چشم
ما دو مشکل بزرگ پیدا می کنیم. متوجه شدیم که مشتریان برخی از خدمات متصل را نخواهند دید و مشکلاتی با حساب‌های شریک ایجاد می‌شود. هر دو به دلیل اسکریپت های ناقص مهاجرت برای برخی از موارد لبه هستند. الان باید درستش کنیم

ما پرس و جوهایی می نویسیم که این را ثبت می کنند، حداقل با 4 چشم. ما آنها را در طول پیش تولید آزمایش می کنیم تا مطمئن شویم که کار می کنند و چیزی نمی شکنند. می توانید رول کنید. در همان زمان، ما تست یکپارچه سازی منظم خود را اجرا می کنیم که چند مشکل دیگر را نشان می دهد. همه آنها کوچک هستند، اما نیاز به تعمیر دارند.

03:00. -2 مشکل +2 مشکل
دو مشکل بزرگ قبلی و تقریباً تمام مشکلات جزئی نیز برطرف شده اند. همه کسانی که در رفع مشکل مشغول نیستند به طور فعال در حساب های خود کار می کنند و آنچه را که پیدا می کنند گزارش می دهند. ما اولویت بندی می کنیم، بین تیم ها توزیع می کنیم و موارد غیر مهم را برای صبح می گذاریم.

دوباره تست ها را اجرا می کنیم، آنها دو مشکل بزرگ جدید را کشف می کنند. همه خط‌مشی‌های سرویس به درستی وارد نشده‌اند، بنابراین برخی از درخواست‌های کاربر مجوز را تأیید نمی‌کنند. به علاوه یک مشکل جدید با حساب های شریک. بیایید با عجله نگاه کنیم.

03:20. همگام سازی اضطراری
یک مشکل جدید برطرف شد برای دوم، ما در حال سازماندهی همگام سازی اضطراری هستیم. ما درک می کنیم که چه اتفاقی می افتد: راه حل قبلی یک مشکل را برطرف کرد، اما مشکل دیگری ایجاد کرد. ما استراحت می کنیم تا بفهمیم چگونه آن را به درستی و بدون عواقب انجام دهیم.

03:30. شش چشم
ما درک می کنیم که وضعیت نهایی پایه باید چگونه باشد تا همه چیز برای همه شرکا خوب پیش برود. ما یک درخواست را با 6 چشم می نویسیم، آن را در پیش تولید قرار می دهیم، آن را آزمایش می کنیم، آن را برای تولید قرار می دهیم.

ساعت 04:00 همه چیز کار می کند
تمام آزمایشات گذرانده شده است، هیچ مشکل مهمی قابل مشاهده نیست. هر از گاهی، چیزی در تیم برای کسی کار نمی کند، ما به سرعت واکنش نشان می دهیم. بیشتر اوقات زنگ هشدار نادرست است. اما گاهی اوقات چیزی نمی رسد، یا یک صفحه جداگانه کار نمی کند. می نشینیم، درست می کنیم، درست می کنیم، درست می کنیم. یک تیم جداگانه آخرین ویژگی بزرگ را راه اندازی می کند - صورتحساب.

04:30. نقطهی بدون بازگشت
به نقطه بی بازگشت نزدیک می شود، یعنی زمانی که اگر شروع به عقب نشینی کنیم، زمان توقفی که به ما داده شده است را برآورده نمی کنیم. در صورتحساب مشکلاتی وجود دارد که همه چیز را می داند و ثبت می کند، اما سرسختانه از حذف پول از مشتریان خودداری می کند. چندین اشکال در صفحات، عملکردها و وضعیت‌ها وجود دارد. عملکرد اصلی کار می کند، تمام تست ها با موفقیت سپری می شوند. ما تصمیم می گیریم که عرضه انجام شده است، ما عقب نشینی نمی کنیم.

06:00. برای همه افراد در رابط کاربری باز است
اشکالات رفع شد. برخی از آنها که برای کاربران جذابیتی ندارند برای بعد باقی می مانند. ما رابط را برای همه باز می کنیم. ما به کار روی صورت‌حساب ادامه می‌دهیم، منتظر بازخورد کاربر و نتایج نظارت هستیم.

07:00. مشکلات با بارگذاری API
مشخص می شود که ما بارگذاری را در API خود کمی اشتباه برنامه ریزی کردیم و این بار را آزمایش کردیم که نتوانست مشکل را شناسایی کند. در نتیجه ≈5% درخواست ها با شکست مواجه می شوند. بسیج شویم و دنبال دلیل بگردیم.

صورت‌حساب سرسخت است و نمی‌خواهد کار کند. تصمیم داریم آن را به بعد موکول کنیم تا تغییرات را با آرامش انجام دهیم. یعنی تمام منابع در آن انباشته شده است، اما حذف از مشتریان انجام نمی شود. البته، این یک مشکل است، اما در مقایسه با عرضه عمومی، بی اهمیت به نظر می رسد.

08:00. رفع API
ما یک تعمیر برای بار راه اندازی کردیم، خرابی ها برطرف شدند. ما شروع به رفتن به خانه می کنیم.

ساعت 10:00 همه
همه چیز ثابت است. در نظارت ساکت است و در محل مشتریان، تیم به تدریج به خواب می رود. صورتحساب باقی می ماند، فردا آن را بازیابی می کنیم.

سپس در طول روز برنامه‌هایی وجود داشت که گزارش‌ها، اعلان‌ها، کدهای بازگشت و سفارشی‌سازی‌ها را برای برخی از مشتریان ما برطرف می‌کرد.

بنابراین، عرضه موفقیت آمیز بود! البته می‌توانست بهتر باشد، اما ما در مورد آنچه برای رسیدن به کمال کافی نبود نتیجه‌گیری کردیم.

در کل

در طول 2 ماه آماده سازی فعال برای عرضه، 43 کار تکمیل شد که از چند ساعت تا چند روز به طول انجامید.

در طول عرضه:

• شیاطین جدید و تغییر یافته - 5 قطعه، جایگزین 2 یکپارچه.
• تغییرات در پایگاه های داده - همه 6 پایگاه داده ما با داده های کاربر تحت تأثیر قرار گرفته اند، بارگیری ها از سه پایگاه داده قدیمی به یک پایگاه داده جدید انجام شده است.
• نمای ظاهری کاملاً بازطراحی شده؛
• مقدار کد دانلود شده - 33 هزار خط کد جدید، ≈ 3 هزار خط کد در تست، ≈ 5 هزار خط کد مهاجرت.
• تمام داده ها دست نخورده هستند، ماشین مجازی حتی یک مشتری آسیب ندیده است. 🙂

شیوه های خوب برای عرضه خوب

در این شرایط سخت ما را راهنمایی کردند. اما، به طور کلی، پیروی از آنها در طول هر عرضه مفید است. اما هرچه عرضه پیچیده تر باشد، نقش آنها بیشتر است.

1. اولین کاری که باید انجام دهید این است که بفهمید انتشار چگونه می‌تواند بر کاربران تأثیر بگذارد یا خواهد داشت. آیا خرابی وجود خواهد داشت؟ اگر چنین است، زمان از کار افتادگی چیست؟ این چه تاثیری بر کاربران خواهد داشت؟ بهترین و بدترین سناریوهای ممکن چیست؟ و خطرات را پوشش دهد.
2. همه چیز را برنامه ریزی کنید. در هر مرحله، شما باید تمام جنبه های عرضه را بدانید:
   • تحویل کد؛
   • بازگشت کد؛
   • زمان هر عملیات؛
   • عملکرد را تحت تاثیر قرار داد.
3. از طریق سناریوها بازی کنید تا زمانی که تمام مراحل عرضه و همچنین خطرات هر یک از آنها آشکار شود. اگر شک دارید می توانید استراحت کنید و مرحله مشکوک را جداگانه بررسی کنید.
4. هر مرحله می تواند و باید بهبود یابد اگر به کاربران ما کمک کند. به عنوان مثال، زمان خرابی را کاهش می دهد یا برخی از خطرات را از بین می برد.
5. تست برگشت بسیار مهمتر از تست تحویل کد است. لازم است بررسی شود که در نتیجه بازگشت سیستم به حالت اولیه خود باز می گردد و این را با آزمایشات تأیید کنید.
6. هر چیزی که می تواند خودکار شود باید خودکار باشد. هر چیزی که نمی‌تواند خودکار شود، باید از قبل روی یک برگه تقلب نوشته شود.
7. معیار موفقیت را ثبت کنید. چه عملکردی و در چه زمانی باید در دسترس باشد؟ اگر این اتفاق نیفتاد، یک برنامه بازگشتی اجرا کنید.
8. و مهمتر از همه - مردم. هرکسی باید بداند که چه کاری انجام می دهد، چرا و چه چیزی به اقدامات آنها در فرآیند عرضه بستگی دارد.

و در یک جمله، با برنامه ریزی و تفصیل خوب می توانید هر چیزی را که می خواهید بدون عواقب فروش عرضه کنید. حتی چیزی که بر تمام خدمات شما در تولید تأثیر بگذارد.

منبع: www.habr.com