Discover and read the best of Twitter Threads about #سیستم_همیشه_بالا
Most recents (7)
از موضوع‌های همیشگی در گپ و گفت با هم‌کاران در بازار ایران، پایداری برای سرویس‌هاست. مطالبی گِرد این موضوع نوشتم که در چند بخش منتشر خواهم کرد. بخش نخست در پایین آمده. اگر در شرکتتان مساله‌های مشابه دارید، پای مطالب بنویسید یا پیغام دهید برای گفتگوی بیشتر. (۱)
#سیستم_همیشه_بالا
#سیستم_همیشه_بالا
سپاس‌گزارِ عزیزانی که لطف کردند و در بازبینی پیش‌نویس‌ها کمک کردند هستم، به ویژه @mehrdd_seno و @reza_sameei.
بخش آغازین: تصویر کلی و گام نخست. از این‌جا بخوانید: vrgl.ir/UKAsU.
چکیده‌ی کوتاهی در زیر آمده. (همین‌ها در نوشتار اصلی هم هست؛ تا دوباره‌خوانی نکنید.) (۲)
بخش آغازین: تصویر کلی و گام نخست. از این‌جا بخوانید: vrgl.ir/UKAsU.
چکیده‌ی کوتاهی در زیر آمده. (همین‌ها در نوشتار اصلی هم هست؛ تا دوباره‌خوانی نکنید.) (۲)
مساله‌ی پایداری سرورها در برابر سرریز بار و مساله‌ی کارایی و نیاز به سخت‌افزار کمتر، دو مساله‌ی برادرند با راه حل‌های دوگانه.
فرض کنید سرویسی داریم برساخته از یک یا چند job (مثال: vrgl.ir/frRFK) هر یک مستقر روی تعدادی نمونه (instance). مشخصا در پی موارد زیر هستیم: (۳)
فرض کنید سرویسی داریم برساخته از یک یا چند job (مثال: vrgl.ir/frRFK) هر یک مستقر روی تعدادی نمونه (instance). مشخصا در پی موارد زیر هستیم: (۳)
این هفته ارائه‌ای در اتکاپذیری بود با عنوان «لامصب رادَسته» (gosh darn convenient) که نکات جالبی داشت، نکات سرراست و بدیهی ولی معمولا مغفول در طراحی‌ها. (۱)
#سیستم_همیشه_بالا
#سیستم_همیشه_بالا
مثلا برای یک سیستم که فلان فایل ورودی/پیکربندی رو می‌گیره (مثلا برای مدیریت ترافیک، برای اِعمال بر درخواست‌ها، برای کنترل سهمیه‌ها، …) اون فایل رو براش کجا بگذاریم که بره برداره؟ چه جایی بهتر و رادَست‌تر از سرویس مدیریت نسخه‌های کُد (مثلا git)؟ هم دم دسته، هم به سادگی ... (۲)
قابل جستجو و مروره، هم بازبینی (code review) داره، هم می‌شه براش تست‌های پیش-از-submit نوشت، هم مدیریت نسخه و تاریخچه داره. از قضا در گوگل زیاد این کارو می‌کنیم (البته git نیست) و از قضا حادثه‌های بزرگی آفریده چون این کار یعنی وابستگی محیط عملیاتی (production) به آن‌چه نباید. (۳)
امروز برخی سرویس‌های گوگل برای ۴۵ دقیقه خوابید و رفت در خبرها. بیشتر outageهای بزرگ حاصل تعامل چند اشکال با همه، این بار در file system توزیع‌شده‌ی گوگل (Colossus) برای سرویس‌دهی به سیستم احراز هویت گوگل (GAIA). بهانه‌ایست تا یک رویکرد سازمانی مرتبط و خیلی مهم رو مرور کنیم: (۱)
یک مثال که معمولا در کلاس‌های دوره‌ی معارفه مرور می‌شه اینه که یک بار یک بابایی یک configای در سیستم مدیریت jobها (سیستم Borg که بابای Kubernetes است) push کرد و کلّ گوگل رفت پایین! pagerها شروع کرد به زنگ و SREها این ور اون ور می‌دویدن و این حرفا. (۲)
این بابا، با این pushاش ظاهرا نامرتبط بود و بعید بود کار اون باشه، سریع به همه خبر داد و rollback هم کرد. و قضیه حل شد. این شخص که کل گوگل رو برای چند دقیقه آورده بود پایین، توبیخ شد؟ نه اتفاقا جایزه گرفت (peer bonus که هم‌کار به هم‌کار می‌ده) چون دقیقا کارِ درست رو کرده بود. (۳)
برای داشتن یک #سیستم_همیشه_بالا، از کارهایی که باید مرتب و مکرر روی سرویس‌ها انجام داد مانورهای تاب‌آوری/بهبودی در برابر فاجعه (disaster recovery test = DiRT) است - برای نمونه‌های جالب و تجربیاتِ آموخته جستجو کنید Google dirt program. مسلما شرکت‌های دیگر هم دارند. (۱)
مثلا ما هر سال اون سیستمی رو که سپر اصلی‌مون در برابر overload است--چه organic مثلا فینال مسابقات کریکت چه بر اثر outage و کاهش ظرفیت سرویس--با خارج کردن چند datacentre از مدار، تست می‌کنیم. یا یک cache که سیستم ما بهش وابسته‌ست رو disable می‌کنیم. یا حتی ساز و کار ... (۲)
... خودکاری داریم که هر روز چند سرور از N سرور واقعی (نه سرور تست!) رو انگولک کنه و اگر چکش‌خوار (resilient) نبودن هشدار بده - حتی سر این مورد آخری مقاومت وجود داشت ولی الان که جاافتاده همه از یافته‌هاش راضی‌اند.
چنین ساز و کارهایی از ملزومات پیش‌گیری از سورپریزهای دردناکه. (۳)
چنین ساز و کارهایی از ملزومات پیش‌گیری از سورپریزهای دردناکه. (۳)
از دیگر مهم‌هایی که شاید در آغاز، دغدغه‌ی توسعه‌دهندگان نباشه ولی بعدا که سیستم بزرگ شد پشیمون می‌شن، بُعد دادن به سنجه (metric) هاییه که گفتیم دست و دل‌بازانه در کُدها می‌ذاریم، تا بتونیم قاچ (slice) های ریز رو پایش کنیم نه فقط مجموعِِ فلّه‌ایِ رو. (۱)
#پایش
#سیستم_همیشه_بالا
#پایش
#سیستم_همیشه_بالا
مثلا در مثال فروشگاه اینترنتی، اگر کالاهایی که پیشنهاد می‌دیم از ۲ جور مخزن A و B میان و کاربر از دو شیوه‌ی app یا web با ما تعامل می‌کنه، به همه‌ی سنجه‌های مهم‌مون بُعد «مخزن» و «محیط کاربر» می‌دیم. اون وقت نه تنها مقدار مجموع سنجه‌ی الف رو می‌بینیم، بلکه مقدار الف در هر ... (۲)
... قاچ {A:web, A:app, B:web, B:app} رو هم. مثلا اگر app ما دچار bug شد و یک سیگنال لازم برای پیشنهاددهی بهینه به کاربر از مخزن B رو نفرستاد، از قاچ B:app می‌فهمیم. در عمل بعدهای بیشتری هم لازمه مثل سیستم عامل و مرورگر تا مثلا اگر apple یک نسخه داد که به ما نمی‌ساخت، بفهمیم. (۳)
گفتار پیش درباره‌ی پایش بر اساس سنجه‌های بی‌درنگ (real time) از سرورها بود. یک مکتب موازی در پایش، پایش بر اساس logهاست - نه debug log (مثل info و warning و ...) بلکه log ردگیری (trace) که به ازای هر درخواست ذخیره می‌کنیم. (۱)
#پایش
#سیستم_همیشه_بالا
#پایش
#سیستم_همیشه_بالا
پایش از روی logهای تجمیع و پردازش شده (که مثلا بر اساسش پرداخت انجام می‌دیم) سودهایی داره مثل: (۱) به اون‌چه نهایتا برای ما مهمه نزدیک‌تره تا سنجه‌های خام از وسط کُد، (۲) با logها می‌شه قاچ (slice) های ریزدانه‌تر پایش کرد مثلا نمودار فلان چیز قاچ‌شده بر اساس نسخه‌ی مرورگر. (۲)
ولی کاستی‌هایی داره مثل: (۱) تاخیر زیاد، چون logهای نهایی حاصل pipelineهای کُندِ پردازشیه (مثلا ترکیب میلیون‌ها رخداد «نمایش پیشنهاد» توسط ما و «کلیک روی اون» توسط کاربر و سپس تجمیع و سپس خطا/spam زدایی و سپس ...)، (۲) به خوبی عمل‌پذیر (actionable) نیست چون داریم می‌گیم ... (۳)
اگر برای سرویستون پایش و هشدار (monitoring & alerting) انجام می‌دید شاید این به دردتون بخوره. از تیم‌هایی که روی هم سرویس فعلی ما رو می‌سازن، برخی‌ها هم یک نیروی گوش‌به‌زنگ (oncall) از تیم توسعه‌دهنده (dev) دارن و هم یکی از SRE (سرویس‌های ... (۱)
#پاسخ_به_حادثه
#سیستم_همیشه_بالا
#پاسخ_به_حادثه
#سیستم_همیشه_بالا
... حیاتی‌تر و پیچیده‌تر)، برخی فقط SRE و برخی فقط dev. همه جورش، ذیل یک سرویس مادر یکسان، هست. سرویس دیگر (CDN) که کوچک‌تر بود هم، هم SRE گوش‌به‌زنگ داشت و هم dev. برخی هشدارها به این گروه می‌ره و برخی به اون. دربسیاری مواقع، این دو همدیگر رو (یا تیم‌های دیگر رو) فرامی‌خونن. (۲)
این جزییات رو برای این می‌گم که نقش SRE اخیرا در بازار ایران پررنگ شده و درباره‌ش می‌پرسن. طبیعتا کاری که ما می‌کنیم مرجع نیست، هدف فقط دادن داده‌ی پراکنده هست. درباره‌ی هم‌کاری‌های dev و SRE و غیره اگر به درد می‌خوره می‌تونم بیشتر بنویسم. (۳)
