تیم ما عاشق آزمایش است. هر Slurm تکرار ثابت قبلی نیست، بلکه بازتابی بر تجربه و گذار از خوب به بهتر است. اما با ما تصمیم گرفتیم یک قالب کاملاً جدید را اعمال کنیم - شرایطی را که شرکت کنندگان تا حد امکان به "مبارزه" نزدیک می شوند، ارائه دهیم.
اگر آنچه را که در دوره فشرده انجام دادیم به اختصار بیان کنیم: "ما می سازیم، می شکنیم، تعمیر می کنیم،
ما داریم مطالعه می کنیم." SRE در تئوری صرف ارزش کمی دارد - فقط عمل، راه حل های واقعی، مشکلات واقعی.
شرکت کنندگان به تیم ها تقسیم شدند تا روحیه رقابتی شدید به کسی اجازه ندهد که به خواب رود یا "پرندگان خشمگین" را به دنبال نمونه دیمیتری آناتولیویچ روی آیفون راه اندازی کند.
مشکلات، اشکالات، اشکالات و وظایف توسط چهار مربی به شرکت کنندگان ارائه شد. ایوان کروگلوف، توسعه دهنده اصلی در Booking.com (هلند). بن تایلر، توسعه‌دهنده اصلی در Booking.com (ایالات متحده آمریکا). ادوارد مدودف، CTO در آزمایشگاه های تنگستن (آلمان). Evgeniy Varavva، توسعه دهنده عمومی در گوگل (سانفرانسیسکو).
علاوه بر این، شرکت کنندگان به تیم ها تقسیم می شوند و با یکدیگر رقابت می کنند. جالب هست؟
ایوان، بن، ادوارد و اوگنی قبل از شروع مسابقه با نگاه‌های خیره‌کننده لنینیستی به شرکت‌کنندگان فقیر Slurm SRE نگاه می‌کنند.
بنابراین وظیفه:
ما از آن خودمان هستیم، دنیای جدیدی خواهیم ساخت...
یک وب سایت جمع آوری بلیط سینما وجود دارد. حوادث توسط مربیان در یک سناریوی از پیش کار شده اختراع می شوند (اگرچه هیچ کس بداهه پردازی پیچیده و موذیانه را حذف نمی کند)، عملکرد سایت با معیارهای مختلفی توصیف می شود. مشکلات می توانند بسیار متفاوت باشند: بلیط های تئاتر مولن روژ در پایگاه داده بارگذاری نمی شوند. پوسترهای فیلم ها و اجراها در بیش از 10 ثانیه در پایگاه داده بارگذاری می شوند. توصیف یک فیلم فردی منجمد می شود. 0,1٪ از سفارشات قبلا رزرو شده است. هر از گاهی سیستم پردازش پرداخت برای یک یا دو دقیقه از کار می افتد. و خیلی، خیلی، خیلی چیزهای ناخوشایندی که می تواند برای یک شرکت کننده Slurm SRE در شغل واقعی اش رخ دهد.
ما آماده‌ایم تا با هر چیزی... و هرکسی مقابله کنیم.
وب سایت پر رنج ما از چندین میکروسرویس تشکیل شده است. وظیفه آن جمع‌آوری داده‌ها در مورد نمایش‌ها، قیمت‌ها و صندلی‌های موجود از همه سینماها است؛ اعلان‌های فیلم را نشان می‌دهد، به شما امکان می‌دهد سینما، نمایش، سالن و مکان را انتخاب کنید، رزرو کنید و بلیط را پرداخت کنید. به طور کلی، همه چیزهایی که بیننده فقط می تواند رویاهایش را ببیند. اما کاربر حتی مشکوک نیست که چه مبارزه بزرگی برای ثبات و دسترسی به سایت در داخل آن در جریان است.
برای سایت فشرده، شاخص‌های SLO، SLI، SLA را تولید کردیم، معماری و زیرساخت را توسعه دادیم، سایت را مستقر کردیم، نظارت و هشدار را راه‌اندازی کردیم. و ما دور می شویم.
SLO، SLI، SLA
SLI - نشانگرهای سطح خدمات. SLOها اهداف سطح خدمات هستند. SLA - قراردادهای سطح خدمات.
SLA یک اصطلاح روش شناسی ITIL است که به توافق رسمی بین مشتری یک سرویس و تامین کننده آن اشاره می کند که شامل شرح خدمات، حقوق و تعهدات طرفین و مهمتر از همه، سطح کیفیت توافق شده برای ارائه این خدمات است. سرویس.
SLO یک هدف سطح خدمات است: یک مقدار هدف یا محدوده ای از مقادیر برای یک سطح خدمات که توسط SLI اندازه گیری می شود. یک مقدار نرمال برای SLO "SLI ≤ Target" یا "Low Limit ≤ SLI ≤ Upper Limit" است.
SLI یک شاخص سطح خدمات است - یک معیار کمی که با دقت تعریف شده از یک جنبه از سطح خدمات ارائه شده است. برای اکثر سرویس‌ها، کلید SLI به عنوان تأخیر درخواست در نظر گرفته می‌شود - چه مدت طول می‌کشد تا یک پاسخ به یک درخواست بازگردانده شود. سایر SLIهای رایج عبارتند از نرخ خطا که اغلب به صورت کسری از تمام درخواست های دریافتی بیان می شود و توان عملیاتی سیستم که معمولاً بر حسب درخواست در ثانیه اندازه گیری می شود.
اول از همه هواپیماها رو میشکنیم و بعد دخترا و بعد دخترا...
عوامل داخلی و خارجی از همان دقایق اولیه شروع به "تخریب" SLO کردند. همه چیز روی سر مدیران افتاد - اشتباهات توسعه دهندگان، خرابی زیرساخت ها، هجوم بازدیدکنندگان و حملات DDoS. هر چیزی که SLO را بدتر می کند.
"- شرکت کنندگان عزیز، من عجله دارم تا شما را راضی کنم، اولین چیزی که شکست می خورید... همه چیز است!"
در طول مسیر، سخنرانان درباره ثبات، بودجه خطا، تمرین تست، مدیریت وقفه ها و بار عملیاتی بحث کردند.
ما نه استخر هستیم و نه نجار...
سپس شرکت کنندگان شروع به تعمیر چیزها کردند - نکته اصلی این است که بفهمیم ابتدا چه چیزی را بگیریم.
"- پروردگارا، من هرگز ندیده ام که آن را به این شکل و در چنین موقعیتی بشکند!"
بنابراین، یک تصادف رخ داد. سرویس پردازش پرداخت قطع شده است. چگونه برای بازیابی عملکرد در کوتاه ترین زمان ممکن اقدام کنیم؟
کارشناسان با نگاه محبت آمیز به شرکت کنندگان در حال تدارک ترفند دیگری هستند.
هر تیم کار گروه را برای از بین بردن حادثه سازماندهی می کند - همکاران را درگیر می کند، به افراد علاقه مند (ذینفعان) اطلاع می دهد. در عین حال اولویت ها تعیین می شود. به این ترتیب شرکت کنندگان برای کار تحت فشار در شرایط زمانی بسیار محدود آموزش دیدند.
"چه نوع وحشت بیرون آمده است؟"
بازدم ... و تمرین را تمام کنید
به همراه سخنرانان، پس از رفع هر مشکل و تثبیت موقت سایت، تیم حوادث را از نقطه نظر SRE مورد مطالعه قرار داد. ما مشکلات را با جزئیات تجزیه و تحلیل کردیم - علل وقوع، پیشرفت حذف. پس از آن، هم تیم به تیم و هم به طور جمعی، تصمیماتی در مورد نحوه جلوگیری بیشتر از آنها گرفتیم: نحوه بهبود نظارت، نحوه تغییر عاقلانه معماری، نحوه تنظیم رویکرد توسعه و عملیات، نحوه اصلاح مقررات. سخنرانان تمرین انجام پس از مرگ را به نمایش گذاشتند.
«دیگر کی عذاب می خواهد! - من!"
موفقیت های تیم ها به طور دقیق و واضح در اسکوربورد الکترونیک ثبت شد.
برای مکان های اول - یک جایزه از طرف سهامداران.
منبع: www.habr.com