برای داشتن یک #سیستم_همیشه_بالا، از کارهایی که باید مرتب و مکرر روی سرویس‌ها انجام داد مانورهای تاب‌آوری/بهبودی در برابر فاجعه (disaster recovery test = DiRT) است - برای نمونه‌های جالب و تجربیاتِ آموخته جستجو کنید Google dirt program. مسلما شرکت‌های دیگر هم دارند. (۱)
مثلا ما هر سال اون سیستمی رو که سپر اصلی‌مون در برابر overload است--چه organic مثلا فینال مسابقات کریکت چه بر اثر outage و کاهش ظرفیت سرویس--با خارج کردن چند datacentre از مدار، تست می‌کنیم. یا یک cache که سیستم ما بهش وابسته‌ست رو disable می‌کنیم. یا حتی ساز و کار ... (۲)
... خودکاری داریم که هر روز چند سرور از N سرور واقعی (نه سرور تست!) رو انگولک کنه و اگر چکش‌خوار (resilient) نبودن هشدار بده - حتی سر این مورد آخری مقاومت وجود داشت ولی الان که جاافتاده همه از یافته‌هاش راضی‌اند.
چنین ساز و کارهایی از ملزومات پیش‌گیری از سورپریزهای دردناکه. (۳)
چنین ساز و کارهایی از ملزومات پیش‌گیری از سورپریزهای دردناکه. (۳)
اشتباه نشه، سرِ ریسک نکردن اتفاقا وسواس زیادی وجود داره - به درستی. برای مانور حتما طرح نوشته می‌شه، هزینه‌ها برآورد می‌شه، ریسک‌ها و چیزهایی که ممکنه از کنترلمون خارج بشه (مثلا cascading failures) و گزینه‌های موجود و ... مشخص می‌شه، و گاهی نیاز به تایید در رده‌های بالا داره. (۴)
به جز سیستم‌ها، برای فرآیندها هم مانور لازمه. مانور خوبی که نمونه‌برداری ازش توصیه می‌شه اینه که در هفته‌ی مشخصی از سال برخی سرویس‌های درونی شرکت مثل issue tracking برای کارکنان مختل می‌شه تا یادآوری بشه که برای شرایط اورژانسی نباید متکی به این باشید که همه چیز همیشه بالاست. (۵)
البته در همه‌ی این تست‌ها یک دکمه‌ی «شیشه شکستن» و دور زدن مانور هم وجود داره، اگر اون‌قدر بدشانسید که دقیقا در حین مانور، یک وضعیت اورژانسی واقعی هم پیش بیاد. (۶ و پایان)
• • •
Missing some Tweet in this thread? You can try to
force a refresh
