اگر برای سرویستون پایش و هشدار (monitoring & alerting) انجام میدید شاید این به دردتون بخوره. از تیمهایی که روی هم سرویس فعلی ما رو میسازن، برخیها هم یک نیروی گوشبهزنگ (oncall) از تیم توسعهدهنده (dev) دارن و هم یکی از SRE (سرویسهای ... (۱)
... حیاتیتر و پیچیدهتر)، برخی فقط SRE و برخی فقط dev. همه جورش، ذیل یک سرویس مادر یکسان، هست. سرویس دیگر (CDN) که کوچکتر بود هم، هم SRE گوشبهزنگ داشت و هم dev. برخی هشدارها به این گروه میره و برخی به اون. دربسیاری مواقع، این دو همدیگر رو (یا تیمهای دیگر رو) فرامیخونن. (۲)
این جزییات رو برای این میگم که نقش SRE اخیرا در بازار ایران پررنگ شده و دربارهش میپرسن. طبیعتا کاری که ما میکنیم مرجع نیست، هدف فقط دادن دادهی پراکنده هست. دربارهی همکاریهای dev و SRE و غیره اگر به درد میخوره میتونم بیشتر بنویسم. (۳)
هنگام یک outage غیربدیهی معمولا نمایندههای چندین تیم (از جمله رهبران فنی اگر نصف شب نباشه، نه فقط شخص گوشبهزنگ فعلی که شاید تازهکار باشه) به گروه پاسخ میان و همکاری میکنن، در چارچوب یک پروتکل سادهی پاسخ به حادثه (incident response roles) برای جلوگیری از دور خود چرخیدن. (۴)
این کار ممکنه چند دقیقه یا چند روز طول بکشه - بسته به پیچیدگی سیستم و outage. توصیه میشه اشخاص پس از چند ساعت جایگزین بشن و یک ماراتن طولانی پای خط پاسخ و debug نباشن تحت آدرنالین. به خصوص SREها خوب اینو رعایت میکنن. devهای نکرده، پشیمونن. راستش پاسخ به حادثه به نوعی جذابه. (۵)
شاید مهمترین بخش: هنگام هشدار، یک اشتباه شایع، آغاز به «ریشهیابی» توسط پاسخدهندهست ولی نخستین گام باید بررسی شدت (impact) حادثه و درجهدهی باشه، سپس تسکین (mitigation) یا اصطلاحا جلوگیری از خونریزی (مثلا برگردوندن اجزای سیستم به حالت پیشین یا دور کردن بار از محدودهی ... (۶)
... تحت تاثیر)، و در نهایت «ریشهیابی». البته در برخی موارد گزینههای موجود برای تسکین، مشکل رو حل نمیکنه و دو گام آخر ترکیب میشه که معمولا یکی کار dev و دیگری کار SREهاست و معمولا همین موارده که به چند ساعت و چند روز میرسه.
برای داشتن یک #سیستم_همیشه_بالا، از کارهایی که باید مرتب و مکرر روی سرویسها انجام داد مانورهای تابآوری/بهبودی در برابر فاجعه (disaster recovery test = DiRT) است - برای نمونههای جالب و تجربیاتِ آموخته جستجو کنید Google dirt program. مسلما شرکتهای دیگر هم دارند. (۱)
مثلا ما هر سال اون سیستمی رو که سپر اصلیمون در برابر overload است--چه organic مثلا فینال مسابقات کریکت چه بر اثر outage و کاهش ظرفیت سرویس--با خارج کردن چند datacentre از مدار، تست میکنیم. یا یک cache که سیستم ما بهش وابستهست رو disable میکنیم. یا حتی ساز و کار ... (۲)
... خودکاری داریم که هر روز چند سرور از N سرور واقعی (نه سرور تست!) رو انگولک کنه و اگر چکشخوار (resilient) نبودن هشدار بده - حتی سر این مورد آخری مقاومت وجود داشت ولی الان که جاافتاده همه از یافتههاش راضیاند.
چنین ساز و کارهایی از ملزومات پیشگیری از سورپریزهای دردناکه. (۳)
برای «ارزیابی کارکنان»، سیستم گوگل یکی از معقولترینها میان شرکتهای مشابهه که شنیدم و خوندم. جزییات این سیستم در اینترنت هست. چند ویژگی مهم در این سیستم محقق میشه (مثل سلیقهزدایی و رشد) و البته کاستیهایی داره، که در این رشته خلاصه میکنم. (۱)
شما نردبان خودتون رو تعریف کنید. نمونهها در اینترنت هست. اونهایی که به اسم گوگل دیدم، چند جابجایی داشتن ولی برای نمونه خوبن. (۲)
فرآیند ارزیابی تقریبا همون فرآیند استاندارد ۳۶۰ درجهست: افراد خود-ارزیابیشون (self assessment) رو مینویسن و چند همکار (peer) برای گرفتن نظر/بازخورد انتخاب میکنن. مدیر برای کارمند، کارمند برای مدیر، و همکاران انتخاب شده برای همدیگه، نظر/بازخورد مینویسن. (۳)
از نزدیک ۱۰۰۰ سال پیش یادداشتی به جا مونده از «ابوالفضل شاگرد بونصر مشکان»، احتمالا همون بیهقی، برای برگردان فارسی و عربی. اون زمان، فارسینویسی داشت از نو شکوفا میشد در حضور پررنگ عربی - مثلا یک وزیر سلطان محمود فارسی رو زبان رسمی میکرد و بعدی باز عربی و ... (۱)
چند نمونهی خوشگل از برگردانها رو اینجا مینویسم. اصلش در «پارسی نغز» در ۱۳۳۰ و «چند سخن که دبیران در قلم آرند» در ۱۳۵۵ چاپ شده.
خود تاریخ بیهقی هم سراسر عبارت چشمنواز فارسیه مثل «گُرگآشتی» (توافق الکی) و «خاکی و نمکی بیختن» (سَمبَل کردن) و ... اگر علاقه داشتید بخونید. (۲)
برگردانها به این شکله: بدان که به جای «ترسانیدن» «تهدید» نویسند و به جای «شوریدگی» «اضطراب».
یعنی واژهسازیِ فارسی نیست بلکه مثلا «بستاخی / خویشتن کشیدن» (انبساط / انقباض)، واژگان متعارف فارسیسخنانِ روز بوده و میگه ما در نامههای رسمی دربار چه عبارت عربی به جاش مینویسیم. (۳)
از دیگر مهمهایی که شاید در آغاز، دغدغهی توسعهدهندگان نباشه ولی بعدا که سیستم بزرگ شد پشیمون میشن، بُعد دادن به سنجه (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) نیست چون داریم میگیم ... (۳)
سرویس ما اگر قراره موفق باشه، زود یا دیر پایش سطح بالا خواهد داشت. مثلا اگر یک سرویس خرید اینترنتی داریم، فقط سالم بودن سرورها و مصرف پردازش و حافظه رو پایش نخواهیم کرد بلکه نمودار تعداد خرید بر ثانیه و تعداد نمایش فلان پیشنهاد بر ثانیه و نتایجی که به دلیل الف و ب ... (۱)
... فیلتر میکنیم و غیره و غیره رو هم خواهیم پایید تا (دلیل اول) اگر یک bugی فعال شده یا یک مدل یادگیری پسرفت کرده یا به هر دلیلی داریم خراب میکنیم، خبردار شیم - بدیهتا روی هر چیزی هشدار تعریف نمیکنیم و شاید بعدتر از مسالهی لوث شدن هشدار بنویسم. خوب خبردار شدیم، حالا ... (۲)
... چه طور کند و کاو میکنیم؟ (دلیل دوم) از طریق همون دادههای پایشی - چندین برابر سنجه (metric) هایی که برای هشداردهی تعریف کردیم معمولا سنجه برای کند و کاو تعریف کردیم. (دلیل سوم) همین سنجهها هستن که یک قناری موفق رو ممکن میکنن: هنگام بیرون دادن (release) هر نسخهی ... (۳)