اجرای هر پلتفرم توزیعشده مقیاسپذیر نیازمند تعهد به قابلیت اطمینان است تا اطمینان حاصل شود که مشتریان در صورت نیاز آنچه را که نیاز دارند، دارند. وابستگی ها می توانند نسبتاً پیچیده باشند، به خصوص با پلتفرمی به بزرگی Roblox. ایجاد سرویس های قابل اعتماد به این معنی است که، صرف نظر از پیچیدگی و وضعیت وابستگی ها، هر سرویس داده شده قطع نخواهد شد (یعنی بسیار زیاد در دسترس)، بدون اشکال کار می کند (یعنی زیاد کیفیت) و بدون خطا (یعنی تحمل خطا).
چرا قابلیت اطمینان مهم است
تیم هویت حساب ما متعهد به دستیابی به قابلیت اطمینان بالاتر است، زیرا خدمات انطباق که ایجاد کردهایم اجزای اصلی پلتفرم هستند. انطباق شکسته می تواند عواقب شدیدی داشته باشد. هزینه مسدود کردن عملکرد طبیعی Roblox بسیار بالا است، با منابع اضافی لازم برای بازیابی پس از شکست و تجربه کاربری ضعیف.
رویکرد معمولی به قابلیت اطمینان در درجه اول بر در دسترس بودن تمرکز دارد، اما در برخی موارد اصطلاحات مخلوط شده و مورد استفاده نادرست قرار می گیرند. اکثر اندازهگیریها برای در دسترس بودن فقط ارزیابی میکنند که آیا سرویسها راهاندازی و در حال اجرا هستند، در حالی که جنبههایی مانند تحمل پارتیشن و سازگاری گاهی فراموش میشوند یا اشتباه درک میشوند.
مطابق با قضیه CAP، هر سیستم توزیع شده تنها میتواند دو مورد از این سه جنبه را تضمین کند، بنابراین خدمات انطباق ما برای اینکه بسیار در دسترس و تحمل پارتیشن باشد، مقداری سازگاری را قربانی میکنند. با این وجود، خدمات ما اندکی قربانی کردند و مکانیسم هایی برای دستیابی به سازگاری خوب با تغییرات معقول معماری که در زیر توضیح داده شده است، یافتند.
فرآیند دستیابی به قابلیت اطمینان بالاتر تکراری است، با اندازهگیری دقیق که با کار مداوم تطبیق داده میشود تا از بروز، جلوگیری، پیدا کردن، شناسایی و رفع نقص قبل از وقوع حوادث جلوگیری شود. تیم ما ارزش قوی را در شیوه های زیر شناسایی کرد:
- اندازه گیری درست - ایجاد قابلیت مشاهده کامل در مورد نحوه ارائه کیفیت به مشتریان و نحوه ارائه وابستگی ها به ما کیفیت.
- پیش بینی فعال – انجام فعالیت هایی مانند بررسی های معماری و ارزیابی ریسک وابستگی.
- اصلاح را در اولویت قرار دهید - توجه بیشتری را به حل گزارش حادثه برای سرویس و وابستگی هایی که به سرویس ما مرتبط هستند جلب کنید.
ایجاد قابلیت اطمینان بالاتر نیازمند فرهنگ کیفیت است. تیم ما قبلاً روی توسعه مبتنی بر عملکرد سرمایهگذاری میکرد و میدانست که موفقیت یک فرآیند به پذیرش آن بستگی دارد. تیم این فرآیند را به طور کامل اتخاذ کرد و شیوه ها را به عنوان یک استاندارد به کار برد. نمودار زیر اجزای فرآیند را برجسته می کند:
قدرت اندازه گیری درست
قبل از غواصی عمیق تر در معیارها، یک توضیح سریع در مورد اندازه گیری سطح خدمات وجود دارد.
- SLO (هدف سطح خدمات) هدف قابل اعتمادی است که تیم ما به دنبال آن است (یعنی 99.999٪).
- SLI (نشانگر سطح خدمات) قابلیت اطمینان به دست آمده با یک بازه زمانی (یعنی 99.975٪ در فوریه گذشته) است.
- SLA (توافقنامه سطح خدمات) قابلیت اطمینانی است که در یک بازه زمانی معین (یعنی 99.99٪ در هفته) توسط مصرف کنندگان ما ارائه می شود و مورد انتظار است.
SLI باید در دسترس بودن (بدون پاسخ کنترل نشده یا از دست رفته)، تحمل شکست (بدون خطای سرویس) و کیفیت به دست آمده (بدون خطای غیرمنتظره) را منعکس کند. بنابراین، ما SLI خود را به عنوان «نسبت موفقیت» پاسخهای موفق در مقایسه با کل درخواستهای ارسال شده به یک سرویس تعریف کردیم. پاسخ های موفق آن دسته از درخواست هایی هستند که در زمان و شکل ارسال شده اند، یعنی خیر اتصال، سرویس یا خطاهای غیرمنتظره رخ داده است.
این SLI یا نسبت موفقیت از دیدگاه مصرف کنندگان (یعنی مشتریان) جمع آوری می شود. هدف این است که تجربه انتها به انتها واقعی ارائه شده به مصرف کنندگان خود را اندازه گیری کنیم تا احساس کنیم که SLA ها برآورده شده اند. انجام ندادن این کار باعث ایجاد حس کاذب از قابلیت اطمینان می شود که تمام نگرانی های زیرساختی برای ارتباط با مشتریان خود را نادیده می گیرد. مشابه SLI مصرف کننده، ما SLI وابستگی را برای ردیابی هرگونه خطر احتمالی جمع آوری می کنیم. در عمل، تمام SLA های وابستگی باید با سرویس SLA هماهنگ باشند و وابستگی مستقیم با آنها وجود دارد. شکست یکی به معنای شکست همه است. ما همچنین معیارها را از خود سرویس (یعنی سرور) پیگیری و گزارش میکنیم، اما این منبع عملی برای قابلیت اطمینان بالا نیست.
علاوه بر SLIها، هر ساختنی معیارهای کیفیتی را که توسط گردش کار CI گزارش میشود جمعآوری میکند. این عمل به اجرای قوی گیتهای با کیفیت (یعنی پوشش کد) و گزارش سایر معیارهای معنیدار، مانند انطباق استاندارد کدگذاری و تجزیه و تحلیل کد استاتیک کمک میکند. این موضوع قبلاً در مقاله دیگری مطرح شده بود، ساخت میکروسرویسهای مبتنی بر عملکرد. هنگام صحبت از قابلیت اطمینان، رعایت دقیق کیفیت افزایش می یابد، زیرا هرچه بیشتر برای دستیابی به امتیازات عالی سرمایه گذاری کنیم، اطمینان بیشتری داریم که سیستم در شرایط نامطلوب شکست نخواهد خورد.
تیم ما دو داشبورد دارد. یکی تمام نمایان بودن را در SLI مصرف کنندگان و SLI وابستگی ها ارائه می دهد. مورد دوم تمام معیارهای کیفیت را نشان می دهد. ما در حال ادغام همه چیز در یک داشبورد واحد هستیم، به طوری که همه جنبه هایی که به آنها اهمیت می دهیم ادغام شده و آماده گزارش در هر بازه زمانی مشخصی هستند.
شکست را پیش بینی کنید
در حال انجام بررسی های معماری بخش اساسی قابل اعتماد بودن است. ابتدا، تعیین می کنیم که آیا افزونگی وجود دارد یا خیر و آیا سرویس ابزاری برای بقا در هنگام کاهش وابستگی ها دارد یا خیر. فراتر از ایدههای تکراری معمولی، اکثر خدمات ما از تکنیکهای بهبود یافته هیدراتاسیون کش دوگانه، استراتژیهای بازیابی دوگانه (مانند صفهای محلی شکست) یا استراتژیهای از دست دادن داده (مانند پشتیبانی تراکنش) استفاده میکنند. این موضوعات به اندازهای گسترده هستند که ورود وبلاگ دیگری را تضمین کنند، اما در نهایت بهترین توصیه اجرای ایدههایی است که سناریوهای فاجعه را در نظر میگیرند و هرگونه جریمه عملکرد را به حداقل میرسانند.
یکی دیگر از جنبه های مهم برای پیش بینی هر چیزی است که می تواند اتصال را بهبود بخشد. این به معنای تهاجمی بودن در مورد تأخیر کم برای مشتریان و آماده کردن آنها برای ترافیک بسیار بالا با استفاده از تکنیکهای کنترل حافظه پنهان، خطوط جانبی و سیاستهای عملکردی برای زمانبندی، قطع کننده مدار و تلاش مجدد است. این شیوهها برای هر مشتری از جمله کش، فروشگاهها، صفها و مشتریان وابسته به هم در HTTP و gRPC اعمال میشود. همچنین به معنای بهبود سیگنال های سالم از خدمات و درک این موضوع است که بررسی های سلامت نقش مهمی در هماهنگی همه کانتینرها ایفا می کند. اکثر سرویسهای ما سیگنالهای بهتری را برای تخریب به عنوان بخشی از بازخورد بررسی سلامت انجام میدهند و قبل از ارسال سیگنالهای سالم، کارکرد همه اجزای حیاتی را تأیید میکنند.
تجزیه سرویس ها به بخش های مهم و غیر حیاتی برای تمرکز بر عملکردی که بیشترین اهمیت را دارد مفید است. ما قبلاً در یک سرویس نقاط پایانی فقط برای سرپرست داشتیم، و در حالی که اغلب از آنها استفاده نمی شد، بر معیارهای تأخیر کلی تأثیر می گذاشت. انتقال آنها به خدمات خود بر هر معیاری در جهت مثبت تأثیر گذاشت.
ارزیابی ریسک وابستگی ابزار مهمی برای شناسایی مشکلات بالقوه وابستگی است. این بدان معناست که ما وابستگیهایی را با SLI پایین شناسایی میکنیم و از همترازی SLA درخواست میکنیم. این وابستگی ها در طول مراحل ادغام نیاز به توجه ویژه دارند، بنابراین ما زمان بیشتری را برای معیار و بررسی اینکه آیا وابستگی های جدید به اندازه کافی برای برنامه های ما بالغ هستند، اختصاص می دهیم. یک مثال خوب، پذیرش اولیه ما برای Roblox Storage-as-a-Service است. ادغام با این سرویس مستلزم ثبت بلیط های اشکال و جلسات همگام سازی دوره ای برای برقراری ارتباط با یافته ها و بازخوردها بود. همه این کارها از برچسب "قابلیت اطمینان" استفاده می کنند تا بتوانیم به سرعت منبع و اولویت های آن را شناسایی کنیم. شخصیت پردازی اغلب اتفاق می افتاد تا زمانی که ما اطمینان پیدا کردیم که وابستگی جدید برای ما آماده است. این کار اضافی به رساندن وابستگی به سطح موردنیاز از قابلیت اطمینان کمک کرد که انتظار داریم با هم برای یک هدف مشترک عمل کنیم.
ساختار را به آشوب بیاورید
وقوع حوادث هرگز مطلوب نیست. اما زمانی که آنها اتفاق میافتند، اطلاعات معناداری برای جمعآوری و یادگیری وجود دارد تا قابل اعتمادتر باشد. تیم ما یک گزارش رویداد تیمی دارد که بالاتر و فراتر از گزارش معمولی در سطح شرکت ایجاد میشود، بنابراین ما روی همه حوادث بدون توجه به مقیاس تأثیر آنها تمرکز میکنیم. ما علت اصلی را اعلام می کنیم و همه کارها را برای کاهش آن در آینده اولویت بندی می کنیم. به عنوان بخشی از این گزارش، ما از تیمهای دیگر دعوت میکنیم تا حوادث وابستگی را با اولویت بالا برطرف کنند، با حل مناسب پیگیری کنند، به گذشته نگاه کنند و به دنبال الگوهایی باشند که ممکن است برای ما اعمال شود.
این تیم تولید می کند گزارش ماهانه قابلیت اطمینان در هر سرویس که شامل تمام SLIهایی است که در اینجا توضیح داده شده است، هر بلیطی که به دلیل قابلیت اطمینان باز کرده ایم و هر گونه حادثه احتمالی مرتبط با سرویس. ما آنقدر به تولید این گزارش ها عادت کرده ایم که گام طبیعی بعدی استخراج خودکار آنهاست. انجام این فعالیت دوره ای مهم است و یادآوری این است که قابلیت اطمینان دائماً در حال پیگیری و در توسعه ما است.
ابزار دقیق ما شامل معیارهای سفارشی و هشدارهای بهبودیافته است تا در صورت بروز مشکلات شناخته شده و مورد انتظار، در اسرع وقت صفحه نمایش داده شود. همه هشدارها، از جمله مثبت کاذب، هر هفته بررسی می شوند. در این مرحله، صیقل دادن تمام اسناد مهم است تا مصرفکنندگان ما بدانند که هنگام شروع هشدارها و زمانی که خطاها رخ میدهند، چه انتظاری داشته باشند، و سپس همه میدانند چه کاری انجام دهند (مثلاً کتابهای راهنما و دستورالعملهای یکپارچهسازی مرتب شده و اغلب بهروزرسانی میشوند).
در نهایت، اتخاذ کیفیت در فرهنگ ما حیاتی ترین و تعیین کننده ترین عامل در دستیابی به قابلیت اطمینان بالاتر است. ما میتوانیم مشاهده کنیم که چگونه این شیوههای اعمال شده در کار روزمره ما در حال حاضر نتیجه میدهند. تیم ما به قابلیت اطمینان وسواس دارد و این مهمترین دستاورد ما است. ما آگاهی خود را از تأثیری که نقصهای بالقوه میتوانند داشته باشند و زمان معرفی آنها افزایش دادهایم. سرویسهایی که این شیوهها را اجرا میکنند به طور مداوم به SLO و SLA خود رسیدهاند. گزارشهای قابل اعتمادی که به ما کمک میکنند همه کارهایی را که انجام دادهایم ردیابی کنیم، گواهی بر کاری است که تیم ما انجام داده است، و به عنوان درسهای ارزشمندی برای اطلاعرسانی و تأثیرگذاری بر تیمهای دیگر میباشد. این گونه است که فرهنگ قابلیت اطمینان همه اجزای پلتفرم ما را لمس می کند.
راه رسیدن به قابلیت اطمینان بالاتر آسان نیست، اما اگر میخواهید یک پلتفرم قابل اعتماد بسازید که نحوه گردهمایی افراد را دوباره تصور کنید، ضروری است.
آلبرتو یک مهندس نرم افزار اصلی در تیم حساب کاربری در Roblox است. او مدتهاست که در صنعت بازیسازی فعالیت میکند، با اعتبار در بسیاری از عناوین بازیهای AAA و پلتفرمهای رسانههای اجتماعی با تمرکز قوی بر روی معماریهای بسیار مقیاسپذیر. اکنون او با استفاده از بهترین شیوه های توسعه به Roblox کمک می کند تا به رشد و بلوغ برسد.
پست ارائه قابلیت اطمینان پلت فرم در مقیاس بزرگ به نظر می رسد برای اولین بار در وبلاگ Roblox.
- "
- درباره ما
- حساب
- رسیدن
- فعالیت ها
- فعالیت
- افزودن
- اضافی
- اتخاذ
- توافق
- معرفی
- تحلیل
- دیگر
- هر چیزی
- روش
- معماری
- دور و بر
- مقاله
- دسترس پذیری
- در دسترس
- قبل از
- محک
- بهترین
- بهتر
- بلاگ
- اشکال
- ساختن
- نهانگاه
- صدا
- اهميت دادن
- موارد
- علت
- چک
- مشتریان
- رمز
- برنامه نویسی
- مشترک
- ارتباط
- پیچیدگی
- انطباق
- اجزاء
- اعتماد به نفس
- اتصال
- عواقب
- مصرف کننده
- مصرف کنندگان
- ظرف
- مداوم
- میتوانست
- ایجاد
- ایجاد شده
- اعتبار
- بحرانی
- فرهنگ
- مشتریان
- داشبورد
- داده ها
- از دست رفتن داده ها
- ارائه
- تحویل
- پروژه
- مستقیم
- فاجعه
- پایین
- رانده
- در طی
- e
- در اوایل
- مهندس
- خطاها
- تجربه
- استخراج
- شکست
- باز خورد
- نام خانوادگی
- رفع
- تمرکز
- تمرکز
- به دنبال
- فراموش
- فرم
- کامل
- آینده
- G
- بازی
- صنعت بازی
- گیتس
- مولد
- داده
- خوب
- رشد
- دستورالعمل ها
- سلامتی
- کمک
- اینجا کلیک نمایید
- زیاد
- بالاتر
- چگونه
- HTTPS
- i
- شناسایی
- هویت
- تأثیر
- اجرا
- مهم
- بهبود
- بهبود
- بهبود
- از جمله
- صنعت
- نفوذ
- اطلاعات
- شالوده
- ادغام
- معرفی
- سرمایه گذاری
- سرمایه گذاری
- IT
- یاد گرفتن
- سطح
- محلی
- طولانی
- مسائل
- ممکن است
- اندازه
- رسانه ها
- جلسات
- متریک
- مخلوط
- بیش
- هدف
- تنظیم و ارکستراسیون
- سفارش
- دیگر
- خود
- مردم
- کارایی
- سکو
- سیستم عامل
- بازی
- نقطه
- نقطه مشاهده
- سیاست
- مثبت
- ممکن
- پتانسیل
- قدرت
- در حال حاضر
- اصلی
- روند
- کیفیت
- سریع
- رسیدن به
- بهبود یافتن
- بهبود
- گزارش
- گزارش ها
- درخواست
- منابع
- بررسی
- راست
- خطر
- جاده
- Roblox
- در حال اجرا
- مقیاس پذیر
- مقیاس
- حس
- سرور
- محصولات
- خدمات
- مشابه
- So
- آگاهی
- رسانه های اجتماعی
- رسانه های اجتماعی
- نرم افزار
- مهندس نرمافزار
- بزودی
- وضعیت
- پرده
- استراتژی
- موفقیت
- موفق
- پشتیبانی
- زنده ماندن
- سیستم
- سخنگو
- تیم
- تکنیک
- آزمون
- La
- زمان
- با هم
- تحمل
- تاپیک
- مسیر
- ترافیک
- مورد اعتماد
- us
- ارزش
- چشم انداز
- دید
- هفته
- چی
- مهاجرت کاری
- گردش کار
- کارگر