نمیدونم این موج «هر چیزی از من بپرس» (ask me anything) یا AMA به کجاها رسیده ولی دست کم در شرکت ما خیلی باب شده برای ارتباطگیریِ انسانی بین لایههای بالای شرکت با لایههای پایین و به نظر مفید بوده. یعنی مثلا یک مدیر (معمولا رده بالا) با یک مجری اون جلو مینشینن و حاضرین ... (۱)
... هر سوالی بخوان میپرسن، بیشتر هم شخصی تا کاری - طبیعتا بدون ورود به حریم خصوصی. حتی سوال چالشی. گاهی حضوری و گاهی هم به کمک یک سیستم سادهی ارسال و like زدن سوال. حالت گپ داره نه سخنرانیِ بالا به پایین.
یکی از مشکلات یک درخت یا زیردرخت سازمانی بزرگ اینه که منِ نوعی ... (۲)
... برام مهم نیست مدیر ۳ ۴ لایه بالاتر کیه یا چیا میگه چون در کار روزمرهی من تاثیر نداره. پس میزان شرکت در جلسههای فراگیر تیمی (جلسههای All Hands یعنی «همه بیان») که قراره باشه هزار نفر میشه فقط صد نفر، و ارتباط بالا و پایین قطع میشه و شاید اولیتبندیها زاویه پیدا کنه. (۳)
هر بار هم VPها میپرسن چه کار کنیم که شما بیاین. یک راهکار فرعی، همین انسانیتر کردن روابط بوده مثلا هر از گاهی چالشهای مفرح/لوس مثل خوانندگیِ طرف، و به ویژه اخیرا همین جلسههای AMA. کمک میکنه مدیرِ مدیر مدیر من برام «یه بابایی» نباشه بلکه «Jerry» باشه یا «امیرحسین» باشه. (۴)
• • •
Missing some Tweet in this thread? You can try to
force a refresh
برای داشتن یک #سیستم_همیشه_بالا، از کارهایی که باید مرتب و مکرر روی سرویسها انجام داد مانورهای تابآوری/بهبودی در برابر فاجعه (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) هر نسخهی ... (۳)