وبینار صدای ضعیفی دارد، بنابراین ما آن را رونویسی کردیم.
نام من مدودف ادوارد است. امروز در مورد اینکه SRE چیست، چگونه SRE ظاهر شد، معیارهای کار برای مهندسان SRE چیست، کمی در مورد معیارهای قابلیت اطمینان، کمی در مورد نظارت آن صحبت خواهم کرد. ما روی قله ها راه می رویم، زیرا شما نمی توانید در یک ساعت چیز زیادی بگویید، اما من مطالبی را برای بررسی بیشتر ارائه می دهم و همه ما منتظر شما هستیم . در پایان ژانویه در مسکو.
ابتدا، اجازه دهید در مورد چیستی SRE - مهندسی قابلیت اطمینان سایت صحبت کنیم. و چگونه به عنوان یک موقعیت جداگانه، به عنوان یک جهت جداگانه ظاهر شد. همه چیز با این واقعیت شروع شد که در محافل توسعه سنتی، Dev و Ops دو تیم کاملاً متفاوت هستند، معمولاً با دو هدف کاملاً متفاوت. هدف تیم توسعه، ارائه ویژگی های جدید و برآورده کردن نیازهای کسب و کار است. هدف تیم Ops این است که مطمئن شوند همه چیز کار می کند و هیچ چیز خراب نمی شود. بدیهی است که این اهداف مستقیماً با یکدیگر در تضاد هستند: برای اینکه همه چیز کار کند و چیزی خراب نشود، تا حد امکان ویژگی های جدید را به کار ببرید. به همین دلیل، بسیاری از تضادهای داخلی وجود دارد که متدولوژی که اکنون DevOps نامیده می شود سعی در حل آنها دارد.
مشکل اینجاست که ما تعریف روشنی از DevOps و پیاده سازی واضح DevOps نداریم. من 2 سال پیش در یک کنفرانس در یکاترینبورگ صحبت کردم و تا به حال بخش DevOps با گزارش "DevOps چیست" شروع شد. در سال 2017، Devops تقریباً 10 ساله است، اما ما هنوز در حال بحث هستیم که آن چیست. و این وضعیت بسیار عجیبی است که گوگل چند سال پیش سعی در حل آن داشت.
در سال 2016، گوگل کتابی به نام مهندسی قابلیت اطمینان سایت منتشر کرد. و در واقع با این کتاب بود که جنبش SRE آغاز شد. SRE یک پیاده سازی خاص از پارادایم DevOps در یک شرکت خاص است. مهندسان SRE متعهد هستند که از عملکرد قابل اعتماد سیستم ها اطمینان حاصل کنند. آنها بیشتر از توسعه دهندگان، گاهی اوقات از مدیران با پیشینه توسعه قوی هستند. و همان کاری را انجام می دهند که مدیران سیستم قبلا انجام می دادند، اما پیشینه قوی در توسعه و دانش سیستم از نظر کد منجر به این می شود که این افراد تمایلی به کارهای اداری معمولی ندارند، بلکه به اتوماسیون تمایل دارند.
به نظر می رسد که پارادایم DevOps در تیم های SRE با این واقعیت پیاده سازی می شود که مهندسان SRE وجود دارند که مشکلات ساختاری را حل می کنند. اینجا همان ارتباط بین Dev و Ops است که مردم 8 سال از آن صحبت می کنند. نقش یک SRE شبیه نقش یک معمار است که افراد تازه وارد به SRE تبدیل نمی شوند. افرادی که در ابتدای کار خود هستند، هنوز هیچ تجربه ای ندارند، وسعت دانش لازم را ندارند. زیرا SRE به دانش بسیار ظریفی نیاز دارد که دقیقاً چه چیزی و چه زمانی ممکن است اشتباه کند. بنابراین، به عنوان یک قاعده، هم در داخل شرکت و هم در خارج، به تجربه ای در اینجا نیاز است.
آنها می پرسند که آیا تفاوت بین SRE و devops توضیح داده خواهد شد. او به تازگی توصیف شده است. ما می توانیم در مورد جایگاه SRE در سازمان صحبت کنیم. برخلاف این رویکرد کلاسیک DevOps، که در آن Ops هنوز یک بخش جداگانه است، SRE بخشی از تیم توسعه است. آنها در توسعه محصول نقش دارند. حتی رویکردی وجود دارد که در آن SRE نقشی است که از یک توسعه دهنده به توسعه دهنده دیگر منتقل می شود. آنها در بررسی کدها به همان شیوه ای شرکت می کنند که برای مثال، طراحان UX، خود توسعه دهندگان، گاهی اوقات مدیران محصول. SRE ها در همان سطح کار می کنند. ما باید آنها را تأیید کنیم، باید آنها را بررسی کنیم، به طوری که برای هر استقرار SRE بگوید: "خوب، این استقرار، این محصول بر قابلیت اطمینان تأثیر منفی نخواهد گذاشت. و اگر این کار را کرد، در برخی از محدوده های قابل قبول. در این مورد نیز صحبت خواهیم کرد.
بر این اساس، SRE دارای حق وتو برای تغییر کد است. و به طور کلی، اگر SRE به درستی اجرا نشود، این نیز منجر به نوعی درگیری کوچک می شود. در همین کتاب در مورد مهندسی قابلیت اطمینان سایت، بسیاری از بخش‌ها، حتی یکی، نحوه جلوگیری از این تضادها را بیان می‌کند.
آنها می پرسند که چگونه SRE با امنیت اطلاعات مرتبط است. SRE مستقیماً در امنیت اطلاعات دخالت ندارد. اساساً در شرکت های بزرگ این کار توسط افراد، آزمایش کنندگان، تحلیلگران انجام می شود. اما SRE همچنین با آنها تعامل دارد به این معنا که برخی از عملیات، برخی تعهدات، برخی استقرارهایی که بر امنیت تأثیر می گذارند نیز می توانند بر در دسترس بودن محصول تأثیر بگذارند. بنابراین، SRE به طور کلی با هر تیمی، از جمله تیم های امنیتی، از جمله تحلیلگران، تعامل دارد. بنابراین، SRE ها عمدتاً زمانی مورد نیاز هستند که در تلاش برای پیاده سازی DevOps هستند، اما در عین حال، بار روی توسعه دهندگان بسیار زیاد می شود. یعنی خود تیم توسعه دیگر نمی تواند با این واقعیت کنار بیاید که اکنون آنها نیز باید مسئولیت Ops را بر عهده بگیرند. و نقش جداگانه ای دارد. این نقش در بودجه برنامه ریزی شده است. گاهی اوقات این نقش در اندازه تیم تعیین می شود، یک فرد جداگانه ظاهر می شود، گاهی اوقات یکی از توسعه دهندگان آن را تبدیل می کند. به این ترتیب اولین SRE در تیم ظاهر می شود.
پیچیدگی سیستم که تحت تأثیر SRE قرار می گیرد، پیچیدگی که بر قابلیت اطمینان عملیات تأثیر می گذارد، ضروری و تصادفی است. پیچیدگی ضروری زمانی است که پیچیدگی یک محصول به میزان مورد نیاز ویژگی های محصول جدید افزایش یابد. پیچیدگی تصادفی زمانی است که پیچیدگی سیستم افزایش می یابد، اما ویژگی محصول و الزامات تجاری مستقیماً بر این امر تأثیر نمی گذارد. معلوم می شود که یا توسعه دهنده در جایی اشتباه کرده است یا الگوریتم بهینه نیست یا برخی از علایق اضافی معرفی می شوند که پیچیدگی محصول را بدون نیاز خاص افزایش می دهند. یک SRE خوب همیشه باید این وضعیت را قطع کند. یعنی هر commit، هر استقرار، هر درخواست کششی که در آن سختی به دلیل اضافه تصادفی افزایش می‌یابد، باید مسدود شود.
سوال این است که چرا فقط یک مهندس، یک مدیر سیستم با دانش زیاد در تیم استخدام نکنید. به ما گفته می شود که یک توسعه دهنده در نقش یک مهندس بهترین راه حل کارکنان نیست. توسعه‌دهنده در نقش مهندس همیشه بهترین راه‌حل کارمندی نیست، اما نکته اینجاست که توسعه‌دهنده‌ای که به Ops مشغول است کمی تمایل بیشتری به اتوماسیون دارد، کمی دانش و مهارت بیشتری برای پیاده‌سازی دارد. این اتوماسیون و بر این اساس، ما نه تنها زمان برخی از عملیات خاص، نه تنها روال، بلکه پارامترهای مهم تجاری مانند MTTR (میانگین زمان بازیابی، زمان بازیابی) را کاهش می دهیم. بنابراین، و ما نیز در این مورد کمی بعد صحبت خواهیم کرد، ما در هزینه سازمان صرفه جویی می کنیم.
حالا بیایید در مورد معیارهای عملکرد SRE صحبت کنیم. و اول از همه در مورد قابلیت اطمینان. در شرکت‌های کوچک، استارت‌آپ‌ها، اغلب پیش می‌آید که افراد تصور می‌کنند اگر سرویس خوب نوشته شود، اگر محصول خوب و درست نوشته شود، کار می‌کند، خراب نمی‌شود. همین است، ما کد خوبی می نویسیم، بنابراین چیزی برای شکستن وجود ندارد. کد بسیار ساده است، چیزی برای شکستن وجود ندارد. اینها در مورد همان افرادی هستند که می گویند ما به آزمایش نیاز نداریم، زیرا، ببینید، این سه روش VPI هستند، چرا اینجا شکسته می شود.
البته همه اینها اشتباه است. و این افراد اغلب در عمل توسط چنین کدهایی گزیده می شوند، زیرا همه چیز خراب می شود. گاهی اوقات چیزها به غیرقابل پیش بینی ترین راه ها خراب می شوند. گاهی اوقات مردم می گویند نه، هرگز اتفاق نمی افتد. و همیشه اتفاق می افتد. به اندازه کافی اغلب اتفاق می افتد. و به همین دلیل است که هیچ کس برای 100٪ در دسترس بودن تلاش نمی کند، زیرا در دسترس بودن 100٪ هرگز اتفاق نمی افتد. این هنجار است. و بنابراین، وقتی در مورد در دسترس بودن یک سرویس صحبت می کنیم، همیشه در مورد نه صحبت می کنیم. 2 نه، 3 نه، 4 نه، 5 نه. اگر این را به خرابی ترجمه کنیم، مثلاً 5 نهن، آنگاه این مقدار کمی بیشتر از 5 دقیقه توقف در سال است، 2 نهن معادل 3,5 روز توقف است.
اما بدیهی است که در مقطعی کاهش POI، بازگشت سرمایه وجود دارد. رفتن از دو نه به سه نه به معنای زمان توقف کمتر از 3 روز است. رفتن از چهار نه به پنج باعث کاهش 47 دقیقه از کار افتادگی در سال می شود. و معلوم می شود که برای تجارت ممکن است حیاتی نباشد. و به طور کلی، اطمینان مورد نیاز یک موضوع فنی نیست، اولاً یک موضوع تجاری است، یک موضوع محصول است. چه سطحی از خرابی برای کاربران محصول قابل قبول است، چه انتظاراتی دارند، چقدر می پردازند، به عنوان مثال، چقدر پول از دست می دهند، چقدر پول از دست می دهند.
یک سوال مهم در اینجا این است که قابلیت اطمینان اجزای باقی مانده چقدر است. زیرا تفاوت بین 4 و 5 نه در گوشی هوشمند با قابلیت اطمینان 2 نین قابل مشاهده نخواهد بود. به طور کلی، اگر چیزی در تلفن هوشمند 10 بار در سال در سرویس شما خراب شود، به احتمال زیاد 8 بار خرابی در سمت سیستم عامل رخ داده است. کاربر به این کار عادت کرده است و سالی یک بار دیگر به آن توجه نخواهد کرد. همبستگی قیمت افزایش قابلیت اطمینان و افزایش سود ضروری است.
فقط در کتاب SRE یک مثال خوب از افزایش به 4 نه از 3 نه وجود دارد. به نظر می رسد که افزایش در دسترس بودن کمی کمتر از 0,1٪ است. و اگر درآمد سرویس 1 میلیون دلار در سال باشد، افزایش درآمد 900 دلار است. اگر هزینه ای کمتر از 900 دلار در سال برای ما داشته باشد تا مقرون به صرفه بودن را 900 برابر افزایش دهیم، این افزایش منطقی است. اگر بیش از 3 دلار در سال هزینه داشته باشد، دیگر معنی ندارد، زیرا افزایش درآمد صرفاً هزینه های نیروی کار، هزینه های منابع را جبران نمی کند. و XNUMX نه برای ما کافی خواهد بود.
البته این یک مثال ساده است که در آن همه درخواست ها برابر هستند. و رفتن از 3 نه به 4 نه به اندازه کافی آسان است، اما در عین حال، به عنوان مثال، رفتن از 2 نه به 3، این در حال حاضر یک پس انداز 9 هزار دلاری است، می تواند منطقی مالی باشد. طبیعتا در واقعیت شکست درخواست ثبت نام بدتر از عدم نمایش صفحه است، درخواست ها وزن متفاوتی دارند. آنها ممکن است معیار کاملاً متفاوتی از نقطه نظر تجاری داشته باشند، اما به هر حال، به عنوان یک قاعده، اگر در مورد برخی خدمات خاص صحبت نکنیم، این یک تقریب نسبتا قابل اعتماد است.
ما یک سوال دریافت کردیم که آیا SRE یکی از هماهنگ کننده ها هنگام انتخاب یک راه حل معماری برای خدمات است؟ از نظر ادغام در زیرساخت های موجود بگوییم تا در پایداری آن ضرری نداشته باشد. بله، SREها، به همان روشی که درخواست‌های کششی، تعهدات، انتشارات بر معماری، معرفی سرویس‌های جدید، میکروسرویس‌ها، اجرای راه‌حل‌های جدید تأثیر می‌گذارند. چرا قبلاً گفتم تجربه لازم است، صلاحیت لازم است. در واقع SRE یکی از صداهای مسدود کننده در هر راه حل معماری و نرم افزاری است. بر این اساس، یک SRE به عنوان یک مهندس، قبل از هر چیز باید نه تنها درک کند، بلکه باید بفهمد که چگونه برخی از تصمیمات خاص بر قابلیت اطمینان، ثبات، و چگونگی ارتباط این امر با نیازهای کسب و کار، و از چه دیدگاهی قابل قبول و قابل قبول است. که نه
بنابراین، اکنون می توانیم فقط در مورد معیارهای قابلیت اطمینان صحبت کنیم که به طور سنتی در SRE به عنوان SLA (Service Level Agreement) تعریف می شوند. به احتمال زیاد یک اصطلاح آشنا. SLI (نشانگر سطح خدمات). SLO (هدف سطح خدمات). قرارداد سطح سرویس شاید یک اصطلاح نمادین باشد، به خصوص اگر با شبکه ها، با ارائه دهندگان و میزبانی کار کرده باشید. این یک توافق کلی است که عملکرد کل سرویس شما، جریمه ها، برخی از جریمه ها برای خطاها، معیارها، معیارها را توصیف می کند. و SLI خود معیار در دسترس بودن است. یعنی SLI چه چیزی می تواند باشد: زمان پاسخگویی از سرویس، تعداد خطاها به صورت درصد. اگر نوعی میزبانی فایل باشد، می تواند پهنای باند باشد. وقتی صحبت از الگوریتم‌های تشخیص به میان می‌آید، شاخص می‌تواند مثلاً حتی درستی پاسخ باشد. SLO (Service Level Objective) به ترتیب ترکیبی از شاخص SLI، مقدار و دوره آن است.
فرض کنید SLA می تواند اینگونه باشد. این سرویس در 99,95٪ مواقع در طول سال در دسترس است. یا 99 بلیط پشتیبانی بحرانی ظرف 3 ساعت در هر سه ماه بسته می شود. یا 85 درصد درخواست ها در عرض 1,5 ثانیه هر ماه پاسخ داده می شود. یعنی کم کم متوجه می شویم که خطاها و شکست ها کاملا طبیعی هستند. این وضعیت قابل قبولی است، ما در حال برنامه ریزی هستیم، حتی تا حدودی روی آن حساب می کنیم. یعنی SRE سیستم هایی می سازد که می توانند اشتباه کنند، که باید به طور معمول به خطاها پاسخ دهند، که باید آنها را در نظر بگیرد. و در صورت امکان، آنها باید خطاها را به گونه ای مدیریت کنند که کاربر یا متوجه آنها نشود یا متوجه شود، اما نوعی راه حل وجود دارد که به لطف آن همه چیز به طور کامل سقوط نمی کند.
به عنوان مثال، اگر یک ویدیو را در یوتیوب آپلود کنید، و یوتیوب نتواند آن را بلافاصله تبدیل کند، اگر ویدیو خیلی بزرگ باشد، اگر فرمت بهینه نباشد، طبیعتاً درخواست با وقفه شکست نمی خورد، یوتیوب خطای 502 نمی دهد. ، YouTube خواهد گفت: "ما همه چیز را ایجاد کرده ایم، ویدیوی شما در حال پردازش است. حدود 10 دقیقه دیگر آماده خواهد شد." اگر تا به حال این کار را انجام داده باشید، این اصل تخریب برازنده است، که برای مثال از توسعه front-end آشناست.
اصطلاحات بعدی که در مورد آنها صحبت خواهیم کرد، که برای کار با قابلیت اطمینان، با خطاها، با انتظارات بسیار مهم هستند، MTBF و MTTR هستند. MTBF میانگین زمان بین خرابی ها است. MTTR Mean Time To Recovery، میانگین زمان تا ریکاوری. یعنی از لحظه ای که خطا کشف شد، از لحظه ظاهر شدن خطا تا لحظه ای که سرویس به حالت عادی بازگردانده شد، چقدر زمان گذشته است. MTBF عمدتاً با کار بر روی کیفیت کد ثابت می شود. این واقعیت است که SRE ها می توانند "نه" بگویند. و شما نیاز به درک کل تیم دارید که وقتی SRE می گوید "نه"، او آن را می گوید نه به این دلیل که مضر است، نه به این دلیل که او بد است، بلکه به این دلیل که در غیر این صورت همه آسیب خواهند دید.
باز هم، بسیاری از مقالات، روش‌های بسیار، راه‌های بسیاری حتی در همان کتابی که من اغلب به آن مراجعه می‌کنم، وجود دارد، چگونه مطمئن شویم که توسعه‌دهندگان دیگر شروع به نفرت از SRE نمی‌کنند. MTTR، از سوی دیگر، در مورد کار بر روی SLO های شما (هدف سطح خدمات) است. و بیشتر اتوماسیون است. زیرا به عنوان مثال، SLO ما آپتایم 4 نه در هر سه ماهه است. این بدان معناست که در عرض 3 ماه می توانیم 13 دقیقه از کار بیفتیم. و معلوم می شود که MTTR نمی تواند بیش از 13 دقیقه باشد. اگر در 13 دقیقه حداقل به 1 تایم خرابی پاسخ دهیم، به این معنی است که ما قبلاً کل بودجه سه ماهه را تمام کرده ایم. ما در حال شکستن SLO هستیم. 13 دقیقه برای واکنش و رفع تصادف برای یک ماشین زیاد است، اما برای یک انسان بسیار کوتاه است. زیرا تا زمانی که یک فرد هشدار دریافت نمی کند، تا زمانی که واکنش نشان نمی دهد، تا زمانی که خطا را درک نمی کند، چندین دقیقه است. تا زمانی که یک نفر بفهمد چگونه آن را درست کند، دقیقاً چه چیزی را تعمیر کند، چه کاری انجام دهد، پس از آن چند دقیقه دیگر طول می کشد. و در واقع، حتی اگر فقط نیاز به راه اندازی مجدد سرور داشته باشید، همانطور که معلوم است، یا یک گره جدید ایجاد کنید، MTTR به صورت دستی در حال حاضر حدود 7-8 دقیقه است. هنگام خودکار کردن فرآیند، MTTR اغلب به یک ثانیه، گاهی اوقات میلی ثانیه می رسد. گوگل معمولاً در مورد میلی ثانیه صحبت می کند، اما در واقعیت، البته، همه چیز چندان خوب نیست.
در حالت ایده آل، SRE باید تقریباً به طور کامل کار خود را خودکار کند، زیرا این امر مستقیماً بر MTTR، معیارهای آن، SLO کل سرویس و بر این اساس، بر سود کسب و کار تأثیر می گذارد. اگر زمان بیش از حد باشد، از ما سوال می شود که آیا SRE مقصر است یا خیر. خوشبختانه هیچ کس مقصر نیست. و این یک فرهنگ جداگانه به نام پس از مرگ بی‌پروا است که امروز در مورد آن صحبت نمی‌کنیم، اما آن را در Slurm تحلیل خواهیم کرد. این موضوع بسیار جالبی است که می توان در مورد آن زیاد صحبت کرد. به طور تقریبی، اگر از زمان تعیین شده در هر سه ماه تجاوز شود، پس کمی مقصر همه هستند، یعنی سرزنش همه ثمربخش نیست، در عوض، شاید کسی را مقصر ندانیم، اما شرایط را اصلاح کنیم و با آنچه داریم کار کنیم. در تجربه من، این رویکرد برای اکثر تیم ها، به خصوص در روسیه، کمی بیگانه است، اما منطقی است و بسیار خوب عمل می کند. بنابراین، در پایان مقاله و ادبیاتی که می توانید در مورد این موضوع مطالعه کنید، توصیه می کنم. یا به Slurm SRE بیایید.
بگذار توضیح بدهم. اگر زمان SLO در هر سه ماه بیشتر شود، اگر زمان از کار افتادگی 13 دقیقه نبود، بلکه 15 دقیقه بود، چه کسی می تواند در این مورد مقصر باشد؟ البته ممکن است SRE مقصر باشد، زیرا او به وضوح نوعی ارتکاب یا استقرار بد انجام داده است. مدیر مرکز داده ممکن است در این مورد مقصر باشد، زیرا ممکن است نوعی تعمیر و نگهداری بدون برنامه را انجام داده باشد. اگر مدیر مرکز داده در این مورد مقصر است، پس شخص Ops در این مورد مقصر است که هنگام هماهنگی SLO، تعمیر و نگهداری را محاسبه نکرده است. مدیر، مدیر فنی یا شخصی که قرارداد مرکز داده را امضا کرده و به این موضوع توجه نکرده است که SLA مرکز داده برای مدت زمان توقف مورد نیاز طراحی نشده است در این امر مقصر است. بر این اساس، کم کم همه در این شرایط مقصر هستند. و این بدان معناست که در این شرایط هیچ فایده ای ندارد که کسی را مقصر بدانیم. اما البته باید اصلاح شود. به همین دلیل است که مرگ پس از مرگ وجود دارد. و اگر به عنوان مثال، پس از مرگ گیت هاب را بخوانید، و این همیشه در هر مورد خاص یک داستان بسیار جالب، کوچک و غیرمنتظره است، می توانید جایگزین کنید که هیچ کس هرگز نمی گوید که این شخص خاص مقصر بوده است. تقصیر همیشه بر عهده فرآیندهای ناقص خاص است.
بریم سراغ سوال بعدی. اتوماسیون. وقتی در مورد اتوماسیون در زمینه‌های دیگر صحبت می‌کنم، اغلب به جدولی اشاره می‌کنم که به شما می‌گوید چه مدت می‌توانید روی خودکار کردن یک کار کار کنید بدون اینکه زمان بیشتری برای خودکارسازی آن صرف کنید. یک مشکل وجود دارد. نکته مهم این است که وقتی SRE ها یک کار را خودکار می کنند، نه تنها در زمان صرفه جویی می کنند، بلکه در هزینه نیز صرفه جویی می کنند، زیرا اتوماسیون مستقیماً بر MTTR تأثیر می گذارد. آنها، به اصطلاح، روحیه کارمندان و توسعه دهندگان را ذخیره می کنند، که همچنین منبعی تمام نشدنی است. روال را کاهش می دهند. و همه اینها بر کار و در نتیجه بر تجارت تأثیر مثبت می گذارد، حتی اگر به نظر برسد که اتوماسیون از نظر هزینه های زمانی معنا ندارد.
در واقع، تقریباً همیشه وجود دارد، و موارد بسیار کمی وجود دارد که چیزی در نقش SRE خودکار نباشد. در ادامه در مورد آنچه بودجه خطا نامیده می شود، بودجه خطاها صحبت خواهیم کرد. در واقع، معلوم می شود که اگر همه چیز برای شما بسیار بهتر از SLO است که برای خود تنظیم کرده اید، این نیز خیلی خوب نیست. این نسبتاً بد است، زیرا SLO نه تنها به عنوان یک کران پایین، بلکه به عنوان یک کران تقریبی بالایی نیز کار می کند. وقتی برای خود یک SLO 99٪ در دسترس تعیین می کنید، و در واقع شما 99,99٪ دارید، معلوم می شود که فضایی برای آزمایش دارید که به هیچ وجه به کسب و کار آسیب نمی رساند، زیرا شما خودتان همه اینها را با هم تعیین کرده اید، و از این فضا استفاده نکنید شما بودجه ای برای اشتباهات دارید که در مورد شما تمام نمی شود.
با آن چه کنیم. ما از آن به معنای واقعی کلمه برای همه چیز استفاده می کنیم. برای آزمایش در شرایط تولید، برای عرضه ویژگی‌های جدید که ممکن است بر عملکرد تأثیر بگذارد، برای انتشار، برای تعمیر و نگهداری، برای زمان‌های توقف برنامه‌ریزی‌شده. قانون معکوس نیز اعمال می شود: اگر بودجه تمام شود، نمی توانیم چیز جدیدی منتشر کنیم، زیرا در غیر این صورت از SLO فراتر خواهیم رفت. بودجه قبلاً تمام شده است، اگر تأثیر منفی بر عملکرد داشته باشد، چیزی را منتشر کرده ایم، یعنی اگر این نوعی اصلاح نیست که به خودی خود مستقیماً SLO را افزایش می دهد، پس ما از بودجه فراتر می رویم و این وضعیت بدی است. ، نیاز به تجزیه و تحلیل، پس از مرگ و احتمالاً برخی اصلاحات فرآیند دارد.
یعنی معلوم می شود که اگر خود سرویس به خوبی کار نکند و SLO خرج شود و بودجه صرف آزمایش شود، نه برای برخی نسخه ها، بلکه به خودی خود، به جای برخی اصلاحات جالب، به جای ویژگی های جالب، به جای انتشارات جالب به جای هر کار خلاقانه، باید با اصلاحات احمقانه دست و پنجه نرم کنید تا بودجه را مرتب کنید، یا SLO را ویرایش کنید، و این نیز فرآیندی است که نباید زیاد اتفاق بیفتد.
بنابراین، معلوم می شود که در شرایطی که بودجه بیشتری برای خطاها داریم، همه علاقه مند هستند: هم SRE و هم توسعه دهندگان. برای توسعه دهندگان، بودجه زیاد برای اشکالات به این معنی است که می توانید با نسخه ها، آزمایش ها، آزمایش ها مقابله کنید. برای SREها، بودجه برای خطاها و وارد کردن آن بودجه به این معنی است که آنها مستقیماً کار خود را به خوبی انجام می دهند. و این بر انگیزه نوعی کار مشترک تأثیر می گذارد. اگر به عنوان توسعه دهنده به SRE های خود گوش دهید، فضای بیشتری برای کار خوب و روال بسیار کمتری خواهید داشت.
به نظر می رسد که آزمایشات در تولید بخش بسیار مهم و تقریباً جدایی ناپذیر SRE در تیم های بزرگ است. و معمولاً به آن مهندسی آشوب می‌گویند، که از تیم نتفلیکس می‌آید که ابزاری به نام Chaos Monkey را منتشر کرد.
Chaos Monkey به خط لوله CI/CD متصل می شود و به طور تصادفی سرور را از کار می اندازد. باز هم در ساختار SRE، ما در مورد این واقعیت صحبت می کنیم که یک سرور از کار افتاده به خودی خود بد نیست، انتظار می رود. و اگر در حد بودجه باشد قابل قبول است و ضرری به کسب و کار نمی زند. البته، نتفلیکس به اندازه کافی سرورهای اضافی دارد، به اندازه کافی تکرار می شود، به طوری که می توان همه اینها را برطرف کرد، و به طوری که کاربر به طور کلی حتی متوجه نمی شود، و حتی بیشتر از آن هیچ کس با هر بودجه ای یک سرور را ترک نمی کند.
نتفلیکس برای مدتی مجموعه کاملی از چنین ابزارهایی داشت که یکی از آنها، Chaos Gorilla، یکی از مناطق دسترسی آمازون را به طور کامل خاموش می کند. و چنین چیزهایی کمک می کند که اولاً وابستگی های پنهان آشکار شوند، زمانی که کاملاً مشخص نیست چه چیزی بر چه چیزی تأثیر می گذارد، چه چیزی به چه چیزی بستگی دارد. و این، اگر با یک میکروسرویس کار می کنید، و مستندات کاملاً کامل نیستند، ممکن است برای شما آشنا باشد. و باز هم، این کمک زیادی به گرفتن خطاهایی در کد می کند که در مرحله بندی نمی توانید آنها را بگیرید، زیرا هر مرحله بندی دقیقاً شبیه سازی دقیق نیست، به دلیل اینکه مقیاس بار متفاوت است، الگوی بار متفاوت است، تجهیزات همچنین، به احتمال زیاد، دیگر. اوج بار نیز می تواند غیر منتظره و غیر قابل پیش بینی باشد. و چنین آزمایش‌هایی که باز هم از بودجه فراتر نمی‌رود، به خوبی به کشف خطاهایی در زیرساخت کمک می‌کند که مرحله‌بندی، تست‌های خودکار، خط لوله CI / CD هرگز نمی‌تواند گرفتار شود. و تا زمانی که همه اینها در بودجه شما گنجانده شده باشد، مهم نیست که سرویس شما در آنجا پایین آمده است، اگرچه بسیار ترسناک به نظر می رسد، سرور از کار افتاده است، چه کابوس است. نه، این طبیعی است، خوب است، که به تشخیص اشکال کمک می کند. اگر بودجه دارید، می توانید آن را خرج کنید.
س: چه ادبیاتی را می توانم توصیه کنم؟ لیست در پایان ادبیات زیادی وجود دارد، من چند گزارش را توصیه می کنم. چگونه کار می کند، و آیا SRE در شرکت هایی بدون محصول نرم افزاری خود یا با حداقل توسعه کار می کند. به عنوان مثال، در شرکتی که فعالیت اصلی آن نرم افزار نیست. در شرکتی که فعالیت اصلی آن نرم افزار نیست، SRE دقیقاً مانند همه جاهای دیگر کار می کند، زیرا در یک شرکت شما همچنین باید از محصولات نرم افزاری، حتی اگر توسعه نیافته، استفاده کنید، باید به روز رسانی ها را منتشر کنید، باید تغییر دهید. زیرساخت، شما باید رشد کنید، باید مقیاس کنید. و SREها به شناسایی و پیش بینی مشکلات احتمالی در این فرآیندها و کنترل آنها پس از شروع رشد و تغییر نیازهای کسب و کار کمک می کنند. زیرا اگر حداقل چند سرور دارید و انتظار می رود حداقل رشد داشته باشید، برای داشتن یک SRE مطلقاً لازم نیست در توسعه نرم افزار شرکت کنید.
همین امر در مورد پروژه های کوچک، سازمان های کوچک نیز صدق می کند، زیرا شرکت های بزرگ بودجه و فضای لازم برای آزمایش را دارند. اما در عین حال، همه این ثمرات آزمایش ها را می توان در هر جایی استفاده کرد، یعنی SRE، البته، در گوگل، در نتفلیکس، در Dropbox ظاهر شد. اما در همان زمان، شرکت‌های کوچک و استارت‌آپ‌ها می‌توانند مطالب فشرده را بخوانند، کتاب بخوانند، گزارش‌ها را تماشا کنند. آنها شروع به شنیدن بیشتر در مورد آن می کنند، به نمونه های خاص نگاه می کنند، فکر می کنم اشکالی ندارد، واقعا می تواند مفید باشد، ما هم به این نیاز داریم، عالی است.
یعنی تمام کارهای اصلی روی استانداردسازی این فرآیندها قبلا برای شما انجام شده است. این برای شما باقی می ماند که نقش SRE را به طور خاص در شرکت خود تعیین کنید و شروع به اجرای واقعی تمام این اقدامات کنید، که مجدداً قبلاً توضیح داده شده است. یعنی از اصول مفید برای شرکت های کوچک، همیشه این تعریف SLA، SLI، SLO است. اگر درگیر نرم افزار نیستید، اینها SLAهای داخلی و SLOهای داخلی خواهند بود، بودجه داخلی برای خطاها. این تقریباً همیشه منجر به بحث‌های جالبی در تیم و درون کسب‌وکار می‌شود، زیرا ممکن است معلوم شود که شما برای زیرساخت‌ها، در نوعی سازماندهی فرآیندهای ایده‌آل هزینه می‌کنید، خط لوله ایده‌آل بسیار بیشتر از نیاز است. و این 4 عددی که در بخش IT دارید، الان واقعا به آنها نیاز ندارید. اما در همان زمان، می توانید زمان صرف کنید، بودجه را برای اشتباهات صرف چیز دیگری کنید.
بر این اساس، نظارت و سازماندهی نظارت برای یک شرکت در هر اندازه ای مفید است. و به طور کلی، این طرز تفکر، جایی که اشتباهات چیزی قابل قبول است، جایی که بودجه وجود دارد، جایی که اهداف وجود دارد، دوباره برای یک شرکت با هر اندازه ای مفید است، شروع از استارتاپ برای 3 نفر.
آخرین نکته ظریف فنی که باید در مورد آن صحبت کرد، نظارت است. زیرا اگر ما در مورد SLA، SLI، SLO صحبت می کنیم، بدون نظارت نمی توانیم بفهمیم که آیا با بودجه مطابقت داریم یا خیر، آیا با اهداف خود مطابقت داریم و چگونه بر SLA نهایی تأثیر می گذاریم. من بارها دیده‌ام که نظارت به این صورت انجام می‌شود: مقداری مقدار وجود دارد، به عنوان مثال، زمان درخواست به سرور، میانگین زمان، یا تعداد درخواست‌ها به پایگاه داده. او استانداردی دارد که توسط یک مهندس تعیین شده است. اگر معیار از هنجار منحرف شود، یک ایمیل می رسد. این همه کاملاً بی فایده است، به عنوان یک قاعده، زیرا منجر به چنین انبوهی از هشدارها، انبوهی از پیام های نظارتی می شود، زمانی که یک شخص، اولا، هر بار باید آنها را تفسیر کند، یعنی تعیین کند که آیا مقدار متریک به معنای نیاز به برخی اقدامات و ثانیاً، او به سادگی متوجه تمام این هشدارها نمی شود، در حالی که اساساً هیچ اقدامی از او لازم نیست. این یک قانون نظارت خوب است و اولین قانون زمانی که SRE اجرا می شود این است که اطلاع رسانی باید فقط زمانی انجام شود که اقدام لازم باشد.
در حالت استاندارد، 3 سطح از رویدادها وجود دارد. هشدار وجود دارد، بلیط وجود دارد، سیاهههای مربوط وجود دارد. هشدارها هر چیزی است که شما را ملزم به اقدام فوری می کند. یعنی همه چیز خراب است، باید همین الان درستش کنید. بلیط ها چیزی هستند که نیاز به اقدام تاخیری دارند. بله، شما باید کاری را انجام دهید، باید کاری را به صورت دستی انجام دهید، اتوماسیون شکست خورد، اما لازم نیست تا چند دقیقه آینده آن را انجام دهید. لاگ هر چیزی است که نیازی به عمل ندارد و به طور کلی، اگر همه چیز خوب پیش برود، هیچ کس هرگز آنها را نخواهد خواند. شما فقط زمانی نیاز به خواندن سیاهههای مربوط دارید که در نگاهی به گذشته معلوم شد که چیزی برای مدتی شکسته است، ما از آن اطلاعی نداشتیم. یا نیاز به تحقیق دارید. اما به طور کلی، هر چیزی که نیاز به هیچ اقدامی ندارد، به لاگ ها می رود.
به عنوان یک عارضه جانبی از همه اینها، اگر ما تعریف کرده باشیم که چه رویدادهایی نیاز به اقدامات دارند و به خوبی توضیح داده باشیم که این اقدامات باید چه باشند، به این معنی است که عمل می تواند خودکار باشد. یعنی چه اتفاقی می افتد. ما از حالت هشدار می رویم. بیایید وارد عمل شویم. به سراغ شرح این عمل می رویم. و سپس به سمت اتوماسیون می رویم. یعنی هر اتوماسیونی با واکنش به یک رویداد شروع می شود.
از نظارت، به اصطلاحی به نام مشاهده پذیری می رویم. همچنین در چند سال گذشته کمی هیاهو در مورد این کلمه وجود داشته است. و تعداد کمی از مردم معنی آن را خارج از زمینه درک می کنند. اما نکته اصلی این است که Observability معیاری برای شفافیت سیستم است. اگر مشکلی پیش آمده باشد، با چه سرعتی می‌توانید تشخیص دهید که دقیقاً چه مشکلی رخ داده و وضعیت سیستم در آن لحظه چگونه بوده است. از نظر کد: کدام عملکرد شکست خورد، کدام سرویس ناموفق بود. وضعیت مثلاً متغیرهای داخلی، پیکربندی چگونه بود. از نظر زیرساخت، این است که خرابی در کدام منطقه دسترس‌پذیری رخ داده است، و اگر کوبرنت نصب کرده‌اید، خرابی در کدام پاد رخ داده است، وضعیت پاد چگونه بوده است. و بر این اساس، مشاهده پذیری رابطه مستقیمی با MTTR دارد. هرچه میزان مشاهده پذیری سرویس بالاتر باشد، شناسایی خطا آسان تر است، رفع خطا آسان تر است، خودکارسازی خطا آسان تر است، MTTR کمتر می شود.
با حرکت دوباره به سمت شرکت های کوچک، حتی در حال حاضر نیز بسیار رایج است که بپرسیم چگونه با اندازه تیم کنار بیاییم و آیا یک تیم کوچک نیاز به استخدام یک SRE جداگانه دارد یا خیر. قبلاً در این مورد کمی قبل صحبت شده است. در اولین مراحل توسعه یک استارتاپ یا مثلاً یک تیم، این اصلا ضروری نیست، زیرا SRE می تواند نقش انتقالی داشته باشد. و این کمی تیم را احیا می کند، زیرا حداقل تنوع وجود دارد. و به علاوه مردم را برای این واقعیت آماده می کند که با رشد، به طور کلی، مسئولیت های SRE به طور قابل توجهی تغییر می کند. اگر فردی را استخدام کنید، مطمئناً او انتظاراتی دارد. و این انتظارات در طول زمان تغییر نمی کند، اما الزامات بسیار تغییر خواهد کرد. بنابراین، نحوه استخدام SRE در مراحل اولیه بسیار دشوار است. بزرگ کردن خودت خیلی راحت تره اما ارزش فکر کردن را دارد.
تنها استثنا، شاید زمانی باشد که الزامات رشد بسیار دقیق و کاملاً تعریف شده وجود داشته باشد. یعنی در مورد یک استارتاپ، این ممکن است نوعی فشار از سوی سرمایه گذاران باشد، نوعی پیش بینی رشد چند بار در یک زمان. سپس استخدام یک SRE اساساً موجه است زیرا می توان آن را توجیه کرد. ما نیازهایی برای رشد داریم، به شخصی نیاز داریم که مسئول این واقعیت باشد که با چنین رشدی هیچ چیز خراب نمی شود.
یک سؤال دیگر. وقتی چندین بار توسعه‌دهندگان یک ویژگی را قطع می‌کنند که آزمایش‌ها را با موفقیت پشت سر می‌گذارد، اما تولید را می‌شکند، پایه را بارگیری می‌کند، ویژگی‌های دیگر را خراب می‌کند، چه فرآیندی را اجرا می‌کند، چه باید کرد. بر این اساس، در این مورد، بودجه خطاها است که معرفی می شود. و برخی از خدمات، برخی از ویژگی ها در حال حاضر در حال آزمایش در تولید هستند. این می تواند قناری باشد، زمانی که فقط تعداد کمی از کاربران، اما در حال حاضر در حال تولید هستند، یک ویژگی به کار گرفته شده است، اما از قبل با این انتظار که اگر چیزی خراب شود، به عنوان مثال، برای نیم درصد از همه کاربران، باز هم مطابق با این ویژگی باشد. بودجه برای خطاها بر این اساس، بله، خطایی رخ خواهد داد، برای برخی از کاربران همه چیز خراب می شود، اما قبلاً گفته ایم که این طبیعی است.
یک سوال در مورد ابزارهای SRE وجود داشت. یعنی آیا چیز خاصی وجود دارد که SRE ها از آن استفاده کنند که بقیه از آن استفاده نمی کنند. در واقع، برخی از ابزارهای بسیار تخصصی وجود دارد، نوعی نرم افزار وجود دارد که به عنوان مثال، بارها را شبیه سازی می کند یا در تست قناری A / B مشغول است. اما اساساً جعبه ابزار SRE همان چیزی است که توسعه دهندگان شما در حال حاضر از آن استفاده می کنند. زیرا SRE مستقیماً با تیم توسعه تعامل دارد. و اگر ابزارهای مختلفی دارید، معلوم می شود که همگام سازی زمان می برد. به خصوص اگر SRE ها در تیم های بزرگ کار کنند، در شرکت های بزرگ که می توانند چندین تیم وجود داشته باشند، استانداردسازی در سطح شرکت است که در اینجا کمک زیادی می کند، زیرا اگر 50 ابزار مختلف در 50 تیم استفاده شود، این بدان معنی است که SRE باید آنها را بشناسد. همه. و البته این هرگز اتفاق نخواهد افتاد. و کیفیت کار، کیفیت کنترل حداقل برخی از تیم ها به میزان قابل توجهی کاهش می یابد.
وبینار ما رو به پایان است. من موفق شدم چند چیز اساسی را بگویم. البته در یک ساعت چیزی در مورد SRE نمی توان گفت و فهمید. اما امیدوارم که توانسته باشم این طرز تفکر، نکات کلیدی اصلی را منتقل کرده باشم. و پس از آن، اگر علاقه مند هستید، می توانید در موضوع تحقیق کنید، خودتان یاد بگیرید، ببینید چگونه توسط افراد دیگر، در شرکت های دیگر اجرا می شود. و بر این اساس، در اوایل فوریه، به ما در Slurm SRE بیایید.
Slurm SRE یک دوره فشرده سه روزه است که در مورد آنچه من اکنون در مورد آن صحبت می کنم صحبت می کند، اما با عمق بسیار بیشتر، با موارد واقعی، با تمرین، کل فشرده به کار عملی است. افراد به تیم ها تقسیم خواهند شد. همه شما روی موارد واقعی کار خواهید کرد. بر این اساس، ما مربیان Booking.com ایوان کروگلوف و بن تایلر را داریم. ما یک یوجین باراباس فوق العاده از گوگل، از سانفرانسیسکو داریم. و من هم یه چیزی بهت میگم پس حتما به ما سر بزنید.
بنابراین، کتابشناسی. منابعی در مورد SRE وجود دارد. در همان کتاب، یا بهتر است بگوییم در 2 کتاب در مورد SRE، نوشته شده توسط گوگل. یکی دیگه ، که در آن شرایط و کاربرد آنها کمی دقیق تر است. 3 مورد بعدی گزارش های مربوط به SRE در شرکت های مختلف است. اولین - ، این یک سخنرانی کلیدی از بن ترینر گوگل است. دومین - . سومی دوباره . گزارش چهارم از ، که تنها 5 کارمند کلیدی SRE در 190 کشور دارد. بررسی همه این موارد بسیار جالب است، زیرا همانطور که DevOps برای شرکت‌های مختلف و حتی تیم‌های مختلف معنای بسیار متفاوتی دارد، SRE نیز مسئولیت‌های بسیار متفاوتی دارد، حتی در شرکت‌هایی با اندازه‌های مشابه.
2 پیوند دیگر در مورد اصول مهندسی آشوب: , . و در پایان 3 لیست از سری Awesome Lists در مورد وجود دارد ، در باره و در مورد . لیست SRE فوق العاده بزرگ است، لازم نیست همه آن را مرور کنید، حدود 200 مقاله وجود دارد. من به شدت مقالاتی را از آنجا در مورد برنامه ریزی ظرفیت و در مورد پس از مرگ بی تقصیر توصیه می کنم.
مقاله جالب:
ممنون که در تمام این مدت به من گوش دادید. امیدوارم چیزی یاد گرفته باشید. امیدوارم مطالب کافی برای یادگیری بیشتر داشته باشید. و می بینمت. به امید خدا در فوریه
این وبینار توسط ادوارد مدودف برگزار شد.
PS: برای کسانی که دوست دارند بخوانند، ادوارد فهرستی از منابع ارائه کرد. کسانی که ترجیح می دهند در عمل درک کنند، خوش آمدید .
منبع: www.habr.com