Kian Profile picture
15 Oct, 8 tweets, 2 min read
اگر برای سرویستون پایش و هشدار (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هاست و معمولا همین موارده که به چند ساعت و چند روز می‌رسه.

بعدتر درباره‌ی پایش و هشدار بیشتر می‌نویسم. (۷)

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Kian

Kian Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @kian1024

21 Oct
برای داشتن یک #سیستم_همیشه_بالا، از کارهایی که باید مرتب و مکرر روی سرویس‌ها انجام داد مانورهای تاب‌آوری/بهبودی در برابر فاجعه (disaster recovery test = DiRT) است - برای نمونه‌های جالب و تجربیاتِ آموخته جستجو کنید Google dirt program. مسلما شرکت‌های دیگر هم دارند. (۱)
مثلا ما هر سال اون سیستمی رو که سپر اصلی‌مون در برابر overload است--چه organic مثلا فینال مسابقات کریکت چه بر اثر outage و کاهش ظرفیت سرویس--با خارج کردن چند datacentre از مدار، تست می‌کنیم. یا یک cache که سیستم ما بهش وابسته‌ست رو disable می‌کنیم. یا حتی ساز و کار ... (۲)
... خودکاری داریم که هر روز چند سرور از N سرور واقعی (نه سرور تست!) رو انگولک کنه و اگر چکش‌خوار (resilient) نبودن هشدار بده - حتی سر این مورد آخری مقاومت وجود داشت ولی الان که جاافتاده همه از یافته‌هاش راضی‌اند.

چنین ساز و کارهایی از ملزومات پیش‌گیری از سورپریزهای دردناکه. (۳)
Read 6 tweets
19 Oct
برای «ارزیابی کارکنان»، سیستم گوگل یکی از معقول‌ترین‌ها میان شرکت‌های مشابهه که شنیدم و خوندم. جزییات این سیستم در اینترنت هست. چند ویژگی مهم در این سیستم محقق می‌شه (مثل سلیقه‌زدایی و رشد) و البته کاستی‌هایی داره، که در این رشته خلاصه می‌کنم. (۱)

#فرهنگ_سازمانی
#منابع_انسانی
همه‌ی ارزیابی از آغاز تا پایان، گِرد نردبان سطح‌بندی می‌گرده که پیش‌تر نوشتم. بازخوانی‌ش پیش از خواندن این گفتار لازمه.



شما نردبان خودتون رو تعریف کنید. نمونه‌ها در اینترنت هست. اون‌هایی که به اسم گوگل دیدم، چند جابجایی داشتن ولی برای نمونه خوبن. (۲)
فرآیند ارزیابی تقریبا همون فرآیند استاندارد ۳۶۰ درجه‌ست: افراد خود-ارزیابی‌شون (self assessment) رو می‌نویسن و چند هم‌کار (peer) برای گرفتن نظر/بازخورد انتخاب می‌کنن. مدیر برای کارمند، کارمند برای مدیر، و هم‌کاران انتخاب شده برای هم‌دیگه، نظر/بازخورد می‌نویسن. (۳)
Read 29 tweets
17 Oct
از نزدیک ۱۰۰۰ سال پیش یادداشتی به جا مونده از «ابوالفضل شاگرد بونصر مشکان»، احتمالا همون بیهقی، برای برگردان فارسی و عربی. اون زمان، فارسی‌نویسی داشت از نو شکوفا می‌شد در حضور پررنگ عربی - مثلا یک وزیر سلطان محمود فارسی رو زبان رسمی می‌کرد و بعدی باز عربی و ... (۱)

#فارسی_دوستی
چند نمونه‌ی خوش‌گل از برگردان‌ها رو این‌جا می‌نویسم. اصلش در «پارسی نغز» در ۱۳۳۰ و «چند سخن که دبیران در قلم آرند» در ۱۳۵۵ چاپ شده.

خود تاریخ بیهقی هم سراسر عبارت چشم‌نواز فارسیه مثل «گُرگ‌آشتی» (توافق الکی) و «خاکی و نمکی بیختن» (سَمبَل کردن) و ... اگر علاقه داشتید بخونید. (۲)
برگردان‌ها به این شکله: بدان که به جای «ترسانیدن» «تهدید» نویسند و به جای «شوریدگی» «اضطراب».

یعنی واژه‌سازیِ فارسی نیست بلکه مثلا «بستاخی / خویشتن کشیدن» (انبساط / انقباض)، واژگان متعارف فارسی‌سخنانِ روز بوده و می‌گه ما در نامه‌های رسمی دربار چه عبارت عربی به جاش می‌نویسیم. (۳)
Read 7 tweets
17 Oct
از دیگر مهم‌هایی که شاید در آغاز، دغدغه‌ی توسعه‌دهندگان نباشه ولی بعدا که سیستم بزرگ شد پشیمون می‌شن، بُعد دادن به سنجه‌ (metric) هاییه که گفتیم دست و دل‌بازانه در کُدها می‌ذاریم، تا بتونیم قاچ (slice) های ریز رو پایش کنیم نه فقط مجموعِِ فلّه‌ایِ رو. (۱)

#پایش
#سیستم_همیشه_بالا
مثلا در مثال فروشگاه اینترنتی، اگر کالاهایی که پیشنهاد می‌دیم از ۲ جور مخزن A و B میان و کاربر از دو شیوه‌ی app یا web با ما تعامل می‌کنه، به همه‌ی سنجه‌های مهم‌مون بُعد «مخزن» و «محیط کاربر» می‌دیم. اون وقت نه تنها مقدار مجموع سنجه‌ی الف رو می‌بینیم، بلکه مقدار الف در هر ... (۲)
... قاچ {A:web, A:app, B:web, B:app} رو هم. مثلا اگر app ما دچار bug شد و یک سیگنال لازم برای پیشنهاددهی بهینه به کاربر از مخزن B رو نفرستاد، از قاچ B:app می‌فهمیم. در عمل بعدهای بیشتری هم لازمه مثل سیستم عامل و مرورگر تا مثلا اگر apple یک نسخه داد که به ما نمی‌ساخت، بفهمیم. (۳)
Read 7 tweets
16 Oct
گفتار پیش درباره‌ی پایش بر اساس سنجه‌های بی‌درنگ (real time) از سرورها بود. یک مکتب موازی در پایش، پایش بر اساس logهاست - نه debug log (مثل info و warning و ...) بلکه log ردگیری (trace) که به ازای هر درخواست ذخیره می‌کنیم. (۱)

#پایش
#سیستم_همیشه_بالا

پایش از روی logهای تجمیع و پردازش شده (که مثلا بر اساسش پرداخت انجام می‌دیم) سودهایی داره مثل:‌ (۱) به اون‌چه نهایتا برای ما مهمه نزدیک‌تره تا سنجه‌های خام از وسط کُد، (۲) با logها می‌شه قاچ (slice) های ریزدانه‌تر پایش کرد مثلا نمودار فلان چیز قاچ‌شده بر اساس نسخه‌ی مرورگر. (۲)
ولی کاستی‌هایی داره مثل: (۱) تاخیر زیاد، چون logهای نهایی حاصل pipelineهای کُندِ پردازشیه (مثلا ترکیب میلیون‌ها رخداد «نمایش پیشنهاد» توسط ما و «کلیک روی اون» توسط کاربر و سپس تجمیع و سپس خطا/spam زدایی و سپس ...)، (۲) به خوبی عمل‌پذیر (actionable) نیست چون داریم می‌گیم ... (۳)
Read 5 tweets
16 Oct
سرویس ما اگر قراره موفق باشه، زود یا دیر پایش سطح بالا خواهد داشت. مثلا اگر یک سرویس خرید اینترنتی داریم، فقط سالم بودن سرورها و مصرف پردازش و حافظه رو پایش نخواهیم کرد بلکه نمودار تعداد خرید بر ثانیه و تعداد نمایش فلان پیشنهاد بر ثانیه و نتایجی که به دلیل الف و ب ... (۱)

#پایش
... فیلتر می‌کنیم و غیره و غیره رو هم خواهیم پایید تا (دلیل اول) اگر یک bugی فعال شده یا یک مدل یادگیری پس‌رفت کرده یا به هر دلیلی داریم خراب می‌کنیم، خبردار شیم - بدیهتا روی هر چیزی هشدار تعریف نمی‌کنیم و شاید بعدتر از مساله‌ی لوث شدن هشدار بنویسم. خوب خبردار شدیم، حالا ... (۲)
... چه طور کند و کاو می‌کنیم؟ (دلیل دوم) از طریق همون داده‌های پایشی - چندین برابر سنجه‌ (metric) هایی که برای هشداردهی تعریف کردیم معمولا سنجه برای کند و کاو تعریف کردیم. (دلیل سوم) همین سنجه‌ها هستن که یک قناری موفق رو ممکن می‌کنن: هنگام بیرون دادن (release) هر نسخه‌ی ... (۳)
Read 9 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!