Tweet

https://twitter.com/kian1024/status/1317248978510032898

@threadreaderapp

More from @kian1024

Kian

@kian1024

21 Oct

برای داشتن یک #سیستم_همیشه_بالا، از کارهایی که باید مرتب و مکرر روی سرویس‌ها انجام داد مانورهای تاب‌آوری/بهبودی در برابر فاجعه (disaster recovery test = DiRT) است - برای نمونه‌های جالب و تجربیاتِ آموخته جستجو کنید Google dirt program. مسلما شرکت‌های دیگر هم دارند. (۱)

مثلا ما هر سال اون سیستمی رو که سپر اصلی‌مون در برابر overload است--چه organic مثلا فینال مسابقات کریکت چه بر اثر outage و کاهش ظرفیت سرویس--با خارج کردن چند datacentre از مدار، تست می‌کنیم. یا یک cache که سیستم ما بهش وابسته‌ست رو disable می‌کنیم. یا حتی ساز و کار ... (۲)

... خودکاری داریم که هر روز چند سرور از N سرور واقعی (نه سرور تست!) رو انگولک کنه و اگر چکش‌خوار (resilient) نبودن هشدار بده - حتی سر این مورد آخری مقاومت وجود داشت ولی الان که جاافتاده همه از یافته‌هاش راضی‌اند.

چنین ساز و کارهایی از ملزومات پیش‌گیری از سورپریزهای دردناکه. (۳)

Read 6 tweets

Kian

@kian1024

19 Oct

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

#فرهنگ_سازمانی
#منابع_انسانی

https://twitter.com/kian1024/status/1315855548999401474

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

https://twitter.com/kian1024/status/1315855548999401474

شما نردبان خودتون رو تعریف کنید. نمونه‌ها در اینترنت هست. اون‌هایی که به اسم گوگل دیدم، چند جابجایی داشتن ولی برای نمونه خوبن. (۲)

فرآیند ارزیابی تقریبا همون فرآیند استاندارد ۳۶۰ درجه‌ست: افراد خود-ارزیابی‌شون (self assessment) رو می‌نویسن و چند هم‌کار (peer) برای گرفتن نظر/بازخورد انتخاب می‌کنن. مدیر برای کارمند، کارمند برای مدیر، و هم‌کاران انتخاب شده برای هم‌دیگه، نظر/بازخورد می‌نویسن. (۳)

Read 29 tweets

Kian

@kian1024

17 Oct

https://twitter.com/kian1024/status/1316891831649566721

از دیگر مهم‌هایی که شاید در آغاز، دغدغه‌ی توسعه‌دهندگان نباشه ولی بعدا که سیستم بزرگ شد پشیمون می‌شن، بُعد دادن به سنجه‌ (metric) هاییه که گفتیم دست و دل‌بازانه در کُدها می‌ذاریم، تا بتونیم قاچ (slice) های ریز رو پایش کنیم نه فقط مجموعِِ فلّه‌ایِ رو. (۱)

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

https://twitter.com/kian1024/status/1316891831649566721

مثلا در مثال فروشگاه اینترنتی، اگر کالاهایی که پیشنهاد می‌دیم از ۲ جور مخزن A و B میان و کاربر از دو شیوه‌ی app یا web با ما تعامل می‌کنه، به همه‌ی سنجه‌های مهم‌مون بُعد «مخزن» و «محیط کاربر» می‌دیم. اون وقت نه تنها مقدار مجموع سنجه‌ی الف رو می‌بینیم، بلکه مقدار الف در هر ... (۲)

... قاچ {A:web, A:app, B:web, B:app} رو هم. مثلا اگر app ما دچار bug شد و یک سیگنال لازم برای پیشنهاددهی بهینه به کاربر از مخزن B رو نفرستاد، از قاچ B:app می‌فهمیم. در عمل بعدهای بیشتری هم لازمه مثل سیستم عامل و مرورگر تا مثلا اگر apple یک نسخه داد که به ما نمی‌ساخت، بفهمیم. (۳)

Read 7 tweets

Kian

@kian1024

16 Oct

https://twitter.com/kian1024/status/1316891831649566721

گفتار پیش درباره‌ی پایش بر اساس سنجه‌های بی‌درنگ (real time) از سرورها بود. یک مکتب موازی در پایش، پایش بر اساس logهاست - نه debug log (مثل info و warning و ...) بلکه log ردگیری (trace) که به ازای هر درخواست ذخیره می‌کنیم. (۱)

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

https://twitter.com/kian1024/status/1316891831649566721

پایش از روی logهای تجمیع و پردازش شده (که مثلا بر اساسش پرداخت انجام می‌دیم) سودهایی داره مثل:‌ (۱) به اون‌چه نهایتا برای ما مهمه نزدیک‌تره تا سنجه‌های خام از وسط کُد، (۲) با logها می‌شه قاچ (slice) های ریزدانه‌تر پایش کرد مثلا نمودار فلان چیز قاچ‌شده بر اساس نسخه‌ی مرورگر. (۲)

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

Read 5 tweets

Kian

@kian1024

16 Oct

سرویس ما اگر قراره موفق باشه، زود یا دیر پایش سطح بالا خواهد داشت. مثلا اگر یک سرویس خرید اینترنتی داریم، فقط سالم بودن سرورها و مصرف پردازش و حافظه رو پایش نخواهیم کرد بلکه نمودار تعداد خرید بر ثانیه و تعداد نمایش فلان پیشنهاد بر ثانیه و نتایجی که به دلیل الف و ب ... (۱)

#پایش

... فیلتر می‌کنیم و غیره و غیره رو هم خواهیم پایید تا (دلیل اول) اگر یک bugی فعال شده یا یک مدل یادگیری پس‌رفت کرده یا به هر دلیلی داریم خراب می‌کنیم، خبردار شیم - بدیهتا روی هر چیزی هشدار تعریف نمی‌کنیم و شاید بعدتر از مساله‌ی لوث شدن هشدار بنویسم. خوب خبردار شدیم، حالا ... (۲)

... چه طور کند و کاو می‌کنیم؟ (دلیل دوم) از طریق همون داده‌های پایشی - چندین برابر سنجه‌ (metric) هایی که برای هشداردهی تعریف کردیم معمولا سنجه برای کند و کاو تعریف کردیم. (دلیل سوم) همین سنجه‌ها هستن که یک قناری موفق رو ممکن می‌کنن: هنگام بیرون دادن (release) هر نسخه‌ی ... (۳)

Read 9 tweets

Kian

@kian1024

15 Oct

اگر برای سرویستون پایش و هشدار (monitoring & alerting) انجام می‌دید شاید این به دردتون بخوره. از تیم‌هایی که روی هم سرویس فعلی ما رو می‌سازن، برخی‌ها هم یک نیروی گوش‌به‌زنگ (oncall) از تیم توسعه‌دهنده (dev) دارن و هم یکی از SRE (سرویس‌های ... (۱)

#پاسخ_به_حادثه
#سیستم_همیشه_بالا

... حیاتی‌تر و پیچیده‌تر)، برخی فقط SRE و برخی فقط dev. همه جورش، ذیل یک سرویس مادر یکسان، هست. سرویس دیگر (CDN) که کوچک‌تر بود هم، هم SRE گوش‌به‌زنگ داشت و هم dev. برخی هشدارها به این گروه می‌ره و برخی به اون. دربسیاری مواقع، این دو همدیگر رو (یا تیم‌های دیگر رو) فرامی‌خونن. (۲)

این جزییات رو برای این می‌گم که نقش SRE اخیرا در بازار ایران پررنگ شده و درباره‌ش می‌پرسن. طبیعتا کاری که ما می‌کنیم مرجع نیست، هدف فقط دادن داده‌ی پراکنده هست. درباره‌ی هم‌کاری‌های dev و SRE و غیره اگر به درد می‌خوره می‌تونم بیشتر بنویسم. (۳)

Read 8 tweets

Share this page!

Kian

Try unrolling a thread yourself!

More from @kian1024

Kian

Kian

Kian

Kian

Kian

Kian

Did Thread Reader help you today?

Like this author's thread?