Site Reliability Engineering

ما در تیم سعدی، از تیم‌های قسمت پیام‌رسانی «بله»، جلسات همخوانی کتاب Site Reliability Engineering را برگزار می‌کنیم. اینجا خلاصۀ مطالبی را که می‌خوانیم و یاد می‌گیریم، به‌مرور می‌نویسم.

این کتاب را گوگل منتشر کرده است و می‌توان آن را به‌صورت رایگان در لینک بالا مطالعه کرد.

(برای اختصار، SRE را هم به‌جای Site Reliability Engineering و هم Site Reliability Engineer به کار می‌بریم. اینکه کجا کدام است، به نظر واضح خواهد بود.)

کتاب به‌صورت کلی دربارۀ SRE حرف می‌زند؛ ولی لزوماً به شرح یک عنوان شغلی نمی‌پردازد و شامل توضیح فرهنگ‌های سازمانی و کاری است که نهایتاً هدفش رسیدن به یک سیستم پایدار و مطمئن است.

در این قسمت، به خلاصه بخش Introduction کتاب می‌پردازیم.

متن را با این سؤال آغاز می‌کنیم: SRE کیست؟

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

اما حالا کمی جزئی‌تر به بررسی کلمات این موقعیت شغلی می‌پردازیم:

• اول Engineer:‌ این اشخاص مهندس هستند و طبعاً مهارت‌های یک Computer Engineer و Computer scientist را دارند. یعنی توسعه و طراحی سرویس‌ها جزو کارهایشان است، یا توسعۀ ابزارهایی کمکی برای سایر مهندسان، ازجمله: لودبالانسینگ، بک‌آپ‌گیری و ... .
• دوم Reliability: مهم‌ترین ویژگی هر محصول، این است که بتوان به آن اعتماد کرد و اگر این ویژگی را نداشته باشد، عملاً به درد نمی‌خورد و موفق هم نمی‌شود. بنابراین، SREها بر این موضوع تمرکز ویژه‌ای دارند و به نوعی اصلی‌ترین و اولویت‌دارترین وظیفۀ خودشان را حفظ reliability سرویس می‌دانند و اگر به این هدف مهم رسیدند، سراغ کارهای دیگر می‌روند.
• سوم Site: منظور از این کلمه در واقع Service است و دلیل انتخاب این اسم برایش، این است که در اوایل هدف فقط سایت سرچ google.com بوده است؛ به همین دلیل، این اسم مانده است و تغییرش هم نداده‌اند! :) نهایتاً منظور از سرویس همان نرم‌افزارهایی است که در یک سازمان در حال اجرا هستند، مثلاً در گوگل، یوتیوب، م‍پ و... .

حالا این سؤال پیش می‌آید که آیا همیشه و در همۀ شرکت‌ها این موقعیت شغلی وجود دارد و باید وجود داشته باشد؟ جواب خیر است. زیرا با توجه به حجم کار و عمر شرکت، ممکن است اصلاً چنین پوزیشنی (position) به‌طور خاص وجود نداشته باشد؛ اما همیشه افرادی هستند که این کارها را انجام می‌دهند و اگر برای آن‌ها اسم بگذاریم و کمی منظمشان کنیم، می‌شوند SRE.

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

داستان مارگارت

در زمینۀ خودکار‌ کردن، کتاب یک داستان واقعی را از ناسا تعریف می‌کند.

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

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

اما با این ایدۀ مارگارت مخالفت می‌شود. به این دلیل که می‌گویند: «فضانوردان ما آن‌قدر حرفه‌ای هستند که بدانند نباید این دکمه را بزنند!» نهایتاً با اصرارهای وی، یک داکیومنت (document) اضافه می‌شود مبنی بر اینکه اگر به هر دلیلی این دکمه فشار داده شد، برای برگرداندن اطلاعات چه اقداماتی لازم است.

نهایتاً در اولین سفری که با این سفینه انجام می‌شود، یکی از همین فضانوردان حرفه‌ای (!)‌ این دکمه را به‌اشتباه فشار می‌دهد و اطلاعات برگشت پاک می‌شود. آن‌ها با مراجعه به همان داکیومنت می‌توانند این خطر را دفع کنند و به زمین برگردند.

نتیجۀ داستان واضح است!

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

روش SysAdmin در مدیریت نرم‌افزار

اول باید به این سؤال جواب بدهیم که sysAdmin کیست؟ کسانی که کامپوننت‌های مختلف نرم‌افزار را به هم ملحق می‌کنند و نهایتاً سیستم را اجرا می‌کنند.

کارهای این افراد بیشتر در زمینۀ راه‌اندازی سیستم است و پاسخ‌ دادن به آپدیت‌هایی که از تیم‌های توسعه می‌آید و خطاهایی که رخ می‌دهد.

هرچقدر که لود و استفاده از نرم‌افزار زیاد شود، باید sysAdminهای بیشتری استخدام شوند؛ چراکه لزوماً توسعه‌دهندگان نرم‌افزار، توانایی انجام و دسترسی به تسک‌های این افراد را ندارند و این جایگاه، نیازمند برخی مهارت‌های خاص است.

این شیوه همانند همه‌چیز در دنیا، مزایا و معایبی دارد:

مزیت‌ها

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

معایب

معایب این روش را می‌توان در دو روش مستقیم و غیرمستقیم تقسیم‌بندی کرد:

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

غیر مسقیم: این مشکل که شاید خیلی ظریف و اتفاقاً خیلی مهم‌تر از مشکل مستقیم است، تعارض منافع تیم توسعه و دوآپس است.

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

این عین جملۀ کتاب دربارۀ این تعارض منافع است:

We want to launch anything, any time, without hindrance "versus" We won’t want to ever change anything in the system once it works.

بنابراین تیم عملیات در برابر این تغییرات مقاومت می‌کنند. مثلاً شرایطی را وضع می‌کنند که قبل از هر انتشار باید انجام شود و... .

اما رویکرد SRE این موضوع را تا حد زیادی حل می‌کند. چگونه؟

همان‌طور که گفتیم، یک SRE در واقع کسی است که هم مهارت‌های Dev-Opsی و هم مهارت‌های مهندسی دارد و هم در توسعه و هم در نگهداری نرم‌افزار نقش دارد؛ اما گوگل می‌گوید این دو به‌طور مساوی انجام می‌شود. یعنی یک SRE، پنجاه درصد وقت خود را برای کارهای عملیاتی و بقیه را برای توسعۀ نرم‌افزار می‌گذارد.

یعنی اگر کارهای عملیاتی به‌قدری زیاد شد که این پنجاه درصد را رد کرد، آن کارها به توسعه‌دهنده‌ها اساین (assign) می‌شود و همین باعث می‌شود که آن‌ها هم با این‌جور کارها درگیر شوند و همین تعارض در ذهنشان کم‌رنگ‌تر بشود.

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

برخی استانداردها را این‌گونه بیان می‌کند که وقتی یک SRE، هشت تا دوازده ساعت on-call است، حداکثر دو و حداقل یک ایونت برایش اساین شود.

حالا ایونت (event) چیست؟ منظور خطایی است که رخ می‌دهد یا اتفاقی غیرعادی است که می‌افتد و باید با در نظر گرفتن اولویت‌ها درست شود. مثلاً یک سرویس داون (down) می‌شود یا لیتنسی (latency) یک سرویس افزایش پیدا می‌کند و... .

حالا بعد از دریافت این ایونت (event)، آن شخص موظف است پس از رفع آن، جلسۀ پست‌مرتمی (postmortem) برایش تشکیل دهد و مکتوبش کند.

در چه شرایطی جلسه پست‌مرتم برگزار می‌شود؟

وقتی اتقاق بدی می‌افتد! حالا چه این اتفاق را سیستم آلرت، هشدار داده باشد چه انسانی فهمیده باشد. اتفاقاً این دومی خیلی مهم‌تر است؛ زیرا این اتفاق گپی در سیستم نظارت و هشدار شما را نشان می‌دهد که آن هم باید پیدا شود.

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

اصطلاح قشنگی که گوگل برای این فرهنگ به کار می‌برد، blame-free postmortem culture است.

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

یک فصل از کتاب به پست‌مرتم اشاره می‌کند که ان‌شاءالله در نوشتۀ‌ بعدی به آن خواهم پرداخت.

حالا آن‌قدر گفتیم، ولی خود گوگل اعتراف می‌کند که چون تفکر SRE تفکر جدیدی است، هنوز قابلیت توسعۀ فرهنگی و فنی دارد و اتفاقاً این کار در حال انجام شدن است! اینکه این افراد چه مهارت‌هایی داشته باشند، چگونه جذب بشوند و چگونه با سایر افراد شرکت رابطه داشته باشند، چالش‌هایی است که یک سازمان دارای این فرهنگ با آن روبه‌روست.

در همین فرهنگ رابطۀ تیم عملیات و توسعه، گوگل در این تفکر یک فرهنگ قشنگ دیگر هم دارد و آن بودجۀ ارور است. یعنی اگر در دسترس بودن یک متریک برای سرویس تعریف شود، لزوماً هدف آن را ۱۰۰ نمی‌گذارند و مقداری از آن‌را، مثلاً ۰.۰۱ به‌عنوان بودجه‌ای در نظر می‌گیرند که تیم توسعه حق دارد در سیستم خطا ایجاد کند و این در دسترس بودن را پایین بیاورد.

اما حالا چرا هدف ۱۰۰ نیست؟ خود گوگل که سرویس‌های همیشه پایداری دارد، می‌گوید که وقتی اینترنت و شبکه و همه راه‌هایی که کاربر شما باید طی کند تا به سرویس شما برسد، ۱۰۰ نیست بلکه خیلی کمتر است، ۱۰۰ بودن شما را کسی متوجه نمی‌شود!

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

این خلاصه اینجا پایان می‌یابد و امیدوارم برایتان مفید باشد.

امیدوارم در نوشتۀ بعدی سراغ جلسۀ پست‌مرتم بروم و این فصل از کتاب را برایتان خلاصه کنم.