https://virgool.io/yektanet/feed بلاگ مهندسی یکتانت. این‌جا از تجربه‌هامون می‌نویسیم. چالش‌ها و دغدغه‌هامون رو شرح می‌دیم و یه کم از آینده‌مون حرف می‌زنیم. https://www.yektanet.com/careers/ fa 2026-06-16 16:20:11 https://files.virgool.io/upload/publication/pwpc77g7uhis/n6slrs.png https://virgool.io/yektanet https://virgool.io/yektanet/%DA%AF%D8%B2%D8%A7%D8%B1%D8%B4-%D8%AC%D8%B0%D8%A8-%D9%88%D8%A7%D8%AD%D8%AF-%D9%85%D9%87%D9%86%D8%AF%D8%B3%DB%8C-%DB%8C%DA%A9%D8%AA%D8%A7%D9%86%D8%AA-qappxqxysxsx جذب و استخدام از جمله فرآیندهای مستمر منابع‌انسانی است که همواره وقت، انرژی و هزینه‌ی بسیاری را به‌همراه دارد. لذا گزارش‌های مداوم از این فرآیند موجب شناسایی و رفع مشکلات موجود، صرفه‌جویی در وقت، هزینه و درنهایت بهینه شدن فرآیند استخدام می‌گردد.این گزارش مربوط به آمار جذب و استخدام بخش مهندسی یکتانت در بازه‌ی ۲۰ دی ۱۳۹۹ تا ۲۰ اردیبهشت ۱۴۰۰ است، که در آن پارامترهای زیر مورد بررسی قرار می‌گیرد.•آمار کل جذب•کانال‌های دریافت رزومه•نرخ پذیرش مصاحبه اول•نرخ پذیرش آفر•مدت زمان استخدام•هزینه جذبخواندن و بررسی این گزارش می‌تواند دید و اطلاعات بسیار خوبی نسبت به فرایند جذب و مسائل مرتبط با آن به شما بدهد.آمار کلیاز ۱۶۶ نفری که وارد پروسه جذب مهندسی یکتانت شده‌اند، تعداد ۲۳ نفر استخدام شدند. میانگین درصد جذب در واحد فنی یکتانت برابر ۱۴٪ است. باتوجه به اینکه در این گزارش فقط جذب در واحد مهندسی بررسی شده است، این درصد نسبت به میانگین درصد جذب در شرکت‌های مختلف(۱۶٪)، در سطح خوبی قرار دارد و می‌توان با بهبود فرایندهای جذب آن را افزایش داد.تعداد جذب در موقعیت‌های شغلی مختلف واحد مهندسی یکتانت در نمودار بالا می‌توان موقعیت‌های شغلی افراد جذب شده در بازه بررسی شده را مشاهده نمود. مهندسی نرم‌افزار و فرانت‌اند دولپر، بیشترین تعداد جذب را در این بازه در یکتانت داشته‌اند.کجا دنبال کارجو باشیم؟کانال‌های دریافت رزومهمتقاضیان کار از کانال‌های مختلف با ما ارتباط برقرار می‌کنند. با این حال استفاده از تمامی کانال‌های دریافت رزومه بهینه نیست.با مقایسه و انتخاب بهترین‌ کانال‌های ورود رزومه می‌توان در زمان و هزینه جذب صرفه‌جویی نمود.شاخص‌های مورد بررسی به تفکیک کانال‌ها: تعداد رزومه‌های دریافتی درصد رزومه‌های واجد شرایط همانطور که می‌بینید، جذب افراد از طریق ریفرال با توجه به کیفیت بالای این رزومه‌ها، بیشترین درصد را به خود اختصاص داده است. با مشخص کردن بهترین کانال‌ها از نظر تعداد افراد جذب‌شده و صرف زمان و هزینه بیشتر در آن‌ها، می‌توان بهره‌وری فرآیند جذب را افزایش داد.تعداد این افراد به تفکیک کانال دریافت رزومه محاسبه شده است.رزومه‌های ریفرال با %۶۱ بیشترین سهم را در جذب‌ افراد برای واحد مهندسی یکتانت دارد. علت این موضوع را می‌توان شناخت بهتر افراد داخل شرکت نسبت به فرهنگ شرکت، نیازمندی‌های موقعیت شغلی و توانایی‌های متقاضی شغل دانست.کانال‌های دریافت رزومه افراد جذب شده به تفکیک موقعیت شغلی به شرح زیر است:بر اساس داده‌ها و سطح مورد نیاز شرکت در هر پوزیشن برای جذب افراد با تجربه‌تر منبع ریفرال نتایج بهتری دارد و برای افراد فِرِش، سایت خود شرکت و سایر کانال‌ها از جمله جابینجا موثرتر هستند.دقت یکتانت در انتخاب رزومه‌ها چقدر است؟نرخ پذیرش مصاحبه اولبررسی رزومه اولین مرحله ارزیابی و سنجش افراد در فرآیند جذب است. در انتخاب رزومه‌ها سخت‌گیری زیاد منجر به از دست دادن متقاضیان مستعد و همچنین سهلگیری نیز منجر به ورود زیاد افراد در فرایند شده و نتیجه باعث اتلاف وقت و هزینه می‌شود.شاخص مورد استفاده، درصد موفقیت افراد در مصاحبه اول است.به طور مثال برای پوزیشن Software Engineer %۶۵ درصد افرادی که رزومه‌شان تایید شده و وارد فرایند جذب شدند در اولین مصاحبه پذیرفته شده‌اند.این شاخص به‌صورت میانگین در تمامی پوزیشن‌ها ۵۹٪ است که نشان دهنده دقت نسبتاً مناسب در انتخاب رزومه‌ها است.آفرهای یکتانت چقدر موفق بودند؟نرخ پذیرش آفرنرخ پذیرش آفر، میزان جذابیت و رقابت‌پذیری پیشنهاد شغلی یک شرکت نسبت به شرکت‌های هم‌رده را نشان می‌دهد. از عوامل تاثیرگذار بر این پارامتر می‌توان به موراد زیر اشاره کرد:میزان حقوقزمان کاریمزایاتجربه کاندیدها از فرآیند جذبتعداد آفر داده شده: ۲۵ تعداد آفر پذیرفته شده: ۲۳ نرخ پذیرش آفر: %۹۲این نرخ در گوگل بالای ۹۰٪ است و همچنین طبق تحلیل سایت Glassdoor در سال ۲۰۲۰ میانگین این نرخ در صنایع مختلف ۷۸.۴% بوده است.جذب یک نیرو در هر پوزیشن چقدر زمان می‌برد؟مدت زمان فرآیند جذبزمان فرایند جذب یکی از پارامترهای تاثیرگذار بر روی تجربه افراد از یک شرکت است. این پارامتر از زمان دریافت رزومه کارجو تا زمان ارسال آفر محاسبه می‌شود. طبق گزارش‌ها میانگین مدت زمان جذب افراد در شرکت‌های معتبر حداقل بین ۳ تا ۴ هفته بوده، که این عدد به صورت میانگین در یکتانت ۲۹ روز است. طولانی‌ترین فرآیند جذب مربوط به پوزیشنSoftware Engineer با متوسط زمان ۳۶ روز و کوتاه‌ترین فرآیند جذب مربوط به کارآموز فرانت با متوسط زمان ۸ روز است..جذب یک نیرو در هر پوزیشن چقدر هزینه می‌برد؟هزینه جذبهزینه جذب پارامتریست که کل هزینه‌های انجام شده برای هر استخدام در هر پوزیشن را نشان می‌دهد. که شامل هزینه‌ ثبت آگهی شغلی در کانال‌های مختلف، هزینه تیم منابع انسانی و هزینه‌‌ی زمان از دست رفته مصاحبه‌کنندگان در جلسه مصاحبه، کداینترویو و یا بررسی تسک است که به تعداد افراد جذب شده تقسیم می‌شود.هزینه‌های محاسبه شده تحت تاثیر تعداد افراد وارد شده به فرایند، تعداد مصاحبه‌ها و تسک‌های آن‌ها، مدت زمان پروسه جذب، سطح پوزیشن موردنیاز و در نهایت تعداد افراد جذب شده است.در استانداردهای جهانی هزینه‌ی جذب هر فرد بین ۰.۵ تا ۲ برابر حقوق یک ماه آن فرد است. نتایج به دست آمده در فرآیند جذب یکتانت در این بازه (کمتر از یک حقوق) قرار دارد.علاوه بر محاسبه هزینه کلی، هزینه‌ی مراحل جذب (مصاحبه، کداینترویو و یا بررسی تسک) به صورت جداگانه هم برای هر پوزیشن محاسبه می‌شود تا با کمک آن ترتیب مراحل جذب طوری تعیین شود که در نهایت بتوانیم مجموع هزینه‌های جذب را کاهش دهیم. به طور مثال برای کاهش هزینه‌ی کلی جذب، مصاحبه‌هایی که هزینه‌ی بیشتری دارند را در مراحل آخر جذب قرار می‌دهیم.متوسط هزینه‌ی یک مصاحبه ۹۰ دقیقه‌ای در یکتانت 778 هزار تومان است.متوسط هزینه‌ی بررسی یک تسک ۵۶۸ هزار تومان است.این مقادیر بر اساس هزینه‌ی افراد حاضر در جلسه، زمان مورد نیاز برای آماده شدن در مصاحبه، هزینه‌ی کارشناسان جذب منابع انسانی و هزینه‌های سربارشرکت محاسبه شده است.می‌توانید نحوه‌ی محاسبه هزینه جذب را از طریق این لینک مشاهده کنید.همچنین دید کلی نسبت به زمان و هزینه صرف‌شده در مصاحبه‌های یکتانت نشان داده شده است.سخن پایانیتهیه این دست گزارشات و بررسی نتایج آن قطعاً به بهبود فرایند جذب شرکت‌ها کمک می‌کند و امیدواریم به شما هم در بدست آوردن یک دید کلی نسبت به فرایند جذب مهندسی کمک کرده باشد.برای اطلاع از موقعیت‌های شغلی با جذب باز یکتانت، از صفحه فرصت‌های شغلی یکتانت دیدن کنید. همچنین برای آشنایی بیشتر با بخش مهندسی یکتانت، می‌توانید صفحه تِک یکتانت در اینستاگرام و تِک‌بلاگ یکتانت را دنبال کنید. یکتانت | Yektanet یکتانت | Yektanet Sat, 14 Aug 2021 15:03:04 +0430 https://virgool.io/yektanet/%DA%A9%DB%8C%D9%81%DB%8C%D8%AA-%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-%D8%AF%D9%87%DB%8C-%DA%86%DA%AF%D9%88%D9%86%D9%87-%D9%86%D8%AC%D9%88%D8%A7-%D8%B1%D8%A7-%D8%A8%D9%87%D8%A8%D9%88%D8%AF-%D8%AF%D8%A7%D8%AF%DB%8C%D9%85-tuz9xvu1y7i5 شاید بسیاری از شما با اصطلاح SLA یا توافقنامه‌ی سطح کیفیت خدمات آشنا باشید، اما این توافقنامه از کجا میاد؟ چه عواملی در اون دخیل هستن و نحوه‌ی محاسبه‌اش به چه صورته؟ در این نوشتار سعی می‌کنیم به سوالاتی از این دست با چندتا مثال عملی جواب بدیم. ضمنا لازم به ذکره که مرجع بسیاری از مطالب این نوشتار کتاب SRE گوگل هست.سرواژه‌ی SRE مخفف Site Reliability Engineering هست. اگر بخوام به صورت نادقیق بگم SREها کسانی هستند که زیرساخت امن، پایدار و قابل اتکا ارائه می‌دن و وظیفه‌ی ایجاد فرآیندهای اتوماتیک برای کارهای پرتکرار رو دارن.نجوا یک سرویس ارسال پوش نوتیفیکیشن و ایمیل مارکتینگ هست که روزانه میلیون‌ها پوش نوتیفیکیشن ارسال می‌کنه. مدتی بود که ما متوجه شده بودیم که این سرویس اون‌طوری که انتظار داریم کار نمی‌کنه و دنبال بهبود اون بودیم ولی نمی‌دونستیم که باید از کجا شروع کنیم و معیارهای ما برای کیفیت سرویس‌دهی باید چی باشه. معیارهای زیادی بود که می‌شد با استفاده از اون‌ها کیفیت سرویس‌دهی رو اندازه‌گیری کرد اما ما تصمیم گرفتیم که خودمون رو جای مشتری‌های این سرویس بذاریم و از دید اون‌ها به قضیه نگاه کنیم. این شد که سوالات زیر رو از خودمون پرسیدیم:من به عنوان مشتری چه انتظاراتی از این سرویس دارم؟در صورت مشاهده‌ی چه رفتاری از این سرویس اعتماد من به اون کاهش پیدا می‌کنه؟من به عنوان مشتری سرویس تا چه حد خرابی/کارکرد ناصحیح سرویس رو می‌تونم تحمل کنم؟این سوالات و سوالاتی از این دست ما رو به سمت تعریف SLA یا «توافقنامه‌ی سطح کیفیت خدمات» سوق داد. در ادامه با بررسی موردی سرویس نجوا اصطلاحاتی رو توضیح خواهیم داد که به ما در تعریف SLA کمک کردند.شاخص‌های سرویس، SLIیک SLI شاخصی از سطح سرویس‌دهی است؛ به عبارت دیگر یک معیار عددی از یک جنبه‌ی خاص سطح سرویس‌دهی است. ها ای که گفتی یعنی چه؟بذارید با یک مثال توضیح بدم. فرض کنید شما یک وب‌سرور دارید که به درخواست‌های کاربرها پاسخ میده؛ تاخیر یا latency می‌تونه یک SLI برای سرویس شما باشه. همینطور میشه نسبت خطاهای سرور (5xx) به کل درخواست‌ها رو یه SLI مناسب برای سرویس در نظر گرفت.در حالت ایده‌آل یه SLI خوب به صورت مستقیم سطح سرویس مورد نظر رو اندازه میگیره ولی ممکنه گاهی معیار گفته شده قابل اندازه‌گیری نباشه. به عنوان مثال ایده‌آل این هست که تأخیر پاسخ از دید کاربر نهایی اندازه‌گیری بشه ولی این کار شدنی نیست؛ پس تأخیر پاسخ‌دهی در سرور به عنوان معیاری از تأخیر کل اندازه‌گیری میشه.پس ما باید یک سری SLI رو به عنوان معیار کیفیت سرویس نجوا معرفی می‌کردیم؛ پس از بررسی و ارزیابی جنبه‌های مختلف سرویس به SLIهای زیر رسیدیم:در دسترس بودن وب‌سرور (درصد خطای درخواست‌های رسیده به وب‌سرور)تأخیر وب‌سرورتأخیر در ارسال پوش نوتیفیکیشن‌های غیر VIPتأخیر در ارسال پوش نوتیفیکیشن‌های VIPاما هنوز یک جای کار می‌لنگید؛ چه میزان از در دسترس بودن سرویس، ایده‌آل مشتری‌های ما بود؟ مشتری‌های ما تا چه میزان تأخیر رو می‌تونستن تحمل بکنن؟ ما هنوز نیاز به تعریف مفاهیم بیشتری داشتیم. نیاز داشتیم که معیارهای گفته شده رو به صورت دقیق و عددی تعیین و محدود کنیم. این کار با استفاده از تعریف SLO انجام شد که در ادامه اون رو توضیح می‌دیم.اهداف سرویس، SLOیک SLO هدف معینی برای سطح سرویس‌دهی است. به عبارت دیگر مقدار یا بازه‌ای از مقادیر از سطح سرویس‌دهی است که توسط یک SLI اندازه‌گیری می‌شود.به عبارت دیگه میشه SLO رو به صورت "SLI <= value" یا "lower bound <= SLI <= upper bound" تعریف کرد. برای نمونه، مثال وب‌سرور رو در نظر بگیرید؛ اگر SLI ما میانگین تأخیر درخواست‌ها باشه میشه SLO رو به این صورت تعریف کرد که این میانگین کمتر از ۲۵۰ میلی‌ثانیه باشه.اما هدف از مشخص کردن SLO چیه؟ هدف اینه که کاربران اون سرویس بدونن که باید چه انتظاری از نحوه‌ی کارکرد اون سرویس داشته باشن. اگر SLO به صورت دقیق و مناسب تعیین بشه می‌تونه مانع از ایجاد انتظارات بیش از حد از سرویس بشه. به عنوان یک مثال جالب از چنین انتظاراتی میشه به سرویس Chubby اشاره کرد. Chubby یک سرویس توزیع‌شده‌ی مدیریت قفل (lock service) هست که توسط گوگل توسعه داده شده و هدفش مدیریت قفل برای منابع مختلف و نگهداری فایل‌هایی مثل تنظیمات سیستم‌های توزیع شده است. به مرور زمان گوگل مشاهده کرد که هر بار که Chubby دچار مشکل میشه سرویس‌های متعددی با اون دچار مشکل میشن! دلیل این اتفاق این بود که Chubby اینقدر به ندرت دچار اشکال می‌شد که همه فرض کرده بودن همیشه بالاست و هیچوقت دچار مشکل نمیشه و به مرور زمان وابستگی به اون زیاد شده بود. اما راه‌حلی که گوگل برای این موضوع داشت جالب بود:تیم SRE گوگل انتهای هر فصل در صورتی که Chubby در اون فصل دچار مشکل نشده بود عمدا سیستم رو پایین میاوردن (البته نه به اندازه‌ای که SLO نقض بشه) تا مطمئن بشن انتظارات بی‌جا راجع به در دسترس بودن همیشگی سیستم شکل نمی‌گیره. اینطوری کسانی که به Chubby وابسته بودن مجبور می‌شدن فکری به حال این سناریوی بعید ولی محتمل بکنن.اما ما برای سرویس نجوا چه SLOهایی تعیین کردیم؟ بعد از بررسی عملکرد سیستم به نظر رسید که SLOهای زیر برای این سیستم مناسب باشه:۹۹.۵٪ درخواست‌های رسیده به سرور بدون خطا پاسخ داده شوند. (غیر 5xx)۹۵٪ درخواست‌های رسیده به سرور زیر ۱ ثانیه جواب داده شوند.۹۹٪ نوتیفیکیشن‌های کاربران غیر VIP در کمتر از ۱ ساعت ارسال شوند.۹۵٪ نوتیفیکیشن‌های کاربران VIP زیر ۵ دقیقه ارسال شوند.شاید برای شما عجیب به نظر برسه که چرا این SLOها به صورت درصدی تعریف شدن؟ برای مثال چه اشکالی داشت که بگیم «میانگین زمان پاسخ به درخواست‌های رسیده به سرور زیر ۱ ثانیه باشد»؟اینجاست که باید درباره‌ی نحوه‌ی انتخاب شاخص‌ها کمی توضیح بدیم.نحوه‌ی انتخاب شاخص‌هاشاید وقتی که در بادی امر راجع به تأخیر صحبت می‌کنیم نحوه‌ی اندازه‌گیری واضح به نظر برسه: مدت‌زمانی که طول می‌کشه تا یک درخواست جواب داده بشه. اما راجع به سیستمی که در ثانیه چندین درخواست رو پاسخ میده چطور؟ آیا اندازه‌گیری همینقدر واضحه؟ چه معیاری باید انتخاب بشه؟ آیا میانگین تأخیر درخواست‌ها در یک ثانیه خوبه؟ میانگین در یک دقیقه چطور؟فرض کنید که میانگین تأخیر درخواست‌ها در هر دقیقه SLIای هست که ما اندازه می‌گیریم. فرض کنید وب‌سرور ما دو API فراهم می‌کنه که اولی میانگین تأخیر ۱۰ میلی‌ثانیه و دومی میانگین تأخیر ۵۰۰ میلی‌ثانیه داره. حالا برای راحتی کار فرض کنید که در هر دقیقه تعداد مساوی از دو نوع درخواست به وب‌سرور می‌رسه. پس میانگین تأخیر ما در هر دقیقه ۲۵۵ میلی‌ثانیه خواهد بود. اما آیا این عدد معیار خوبی از کندی سیستم ماست؟ فرض کنید که تمامی درخواست‌ها از وبسایتی میاد که کاربر به صورت مستقیم باهاش کار می‌کنه و صفحه‌ای لود نمیشه مگر اینکه هر دو API مذکور رو فراخوانی کنه. درسته که در این حالت هم میانگین پاسخ ما عملا ۲۵۵ میلی‌ثانیه‌اس ولی لود شدن یک صفحه برای کاربر در بهترین حالت ۵۰۰ میلی‌ثانیه طول خواهد کشید. از طرف دیگه تجربه نشون داده که کاربران سیستم کند رو به سیستمی که واریانس زیادی در زمان پاسخش وجود داره ترجیح میدن؛ پس ما باید دنبال معیاری باشیم که اثر این واریانس رو بهتر در خودش نشون بده.اینجاست که توصیه میشه به جای میانگین، توزیع آماری SLI مورد توجه قرار بگیره. برای مثال شکل زیر رو که از کتاب SRE گوگل برداشته شده رو مشاهده کنید:رنگ‌ها به ترتیب از پایین نماینده‌ی ۵۰٪، ۸۵٪، ۹۵٪ و ۹۹٪ از درخواست‌ها هستند.محور عمودی میزانی هست که یک درخواست طول کشیده (به میلی‌ثانیه) و محور افقی زمان رو نشون میده. رنگ‌ها هم از پایین به بالا به ترتیب نشون‌دهنده‌ی ۵۰ درصد اول، ۸۵ درصد اول، ۹۵ درصد اول و ۹۹ درصد اول درخواست‌ها از نظر زمان پاسخگویی هستند.همونطور که می‌بینید گرچه یک درخواست در حالت عادی ممکنه ۵۰ میلی‌ثانیه طول بکشه (توی ۵۰ درصد اول باشه) ولی درخواست‌هایی هستند که تا ۲۰ برابر کندترن!به این ترتیب با اندازه‌گیری بازه‌های درصدی مختلف می‌تونید شکل توزیع آماری شاخص موردنظرتون رو تخمین بزنید. برای مثال بازه‌ی ۹۹.۹٪ تا ۱۰۰٪ معیار خوبی از بدترین حالت برای شاخص موردنظره.حالا شاید برای شما واضح شده باشه که چرا هنگام تعریف SLOهای نجوا از عباراتی شبیه به «۹۹.۵٪ درخواست‌های رسیده به سرور بدون خطا پاسخ داده شوند. (غیر 5xx)» استفاده کردیم.در ادامه مختصرا SLA رو توضیح میدیم و در باقی این نوشتار به توضیح فنی نحوه‌ی اندازه‌گیری این شاخص‌ها می‌پردازیم.قرارداد سطح سرویس، SLAقرارداد سطح سرویس یا SLA قراردادی است که به صورت التزامی یا ضمنی با کاربران سرویس منعقد شده و شامل تبعات ارضا و یا عدم ارضای SLOهاست.این بخش به صورت خاص مربوط به بخش مالی و بیزنسی کسب و کار و سرویس هست. برای مثال ممکنه شما به صورت دقیق با کاربرانتون توافق کنید که اگر سرویس شما بیش از مدت معینی در دسترس نبود بهشون مبلغی رو به عنوان جریمه پرداخت کنید؛ البته SLA همیشه به صورت ضمنی تعریف نمی‌شه. برای مثال ممکنه شما هیچ قراردادی با کاربرانتون برای سرویسی که بهشون میدین امضا نکرده باشین اما سرویس شما اینقدر حیاتی باشه که حتی یک وقفه‌ی کوتاه در عملکرد اون به اعتبار شما صدمه بزنه و یا باعث بشه منبع درآمدی شما دچار مشکل بشه.اگر به مثال این نوشتار راجع به سرویس نجوا برگردیم می‌بینیم که ما SLOای تحت عبارت «۹۵٪ نوتیفیکیشن‌های کاربران VIP زیر ۵ دقیقه ارسال شوند» تعریف کردیم. اگر این SLO محقق نشه به اعتبار این سرویس لطمه می‌خوره چون کاربری که پول داده و نوتیفیکیشن VIP تعریف کرده انتظار داره که در کوتاه‌ترین زمان ممکن نوتیفیکیشن ارسال بشه.نحوه‌ی تعریف اهداف سرویسبرای تعریف هر SLO لازمه که گفته بشه چطور اندازه‌گیری شده و تحت چه شرایطی معتبر هست. برای مثال:باید ۹۹٪ از پاسخ درخواست‌های وب‌سرور زیر ۱۰۰ میلی‌ثانیه پاسخ داده شوند (میانگین تمامی سرورها که در بازه‌های ۱ دقیقه‌ای اندازه‌گیری شده است).تعریف ۱۰۰ درصدی یک هدف معمولا اشتباه و یک کار بی‌معنیه چون باعث میشه افراد از خطا دوری کنن و در نتیجه تعداد دیپلوی‌ها و خلاقیت افراد کاهش پیدا کنه. اینجاست که مفهوم بودجه‌ی خطا یا Error Budget مطرح میشه.بودجه‌ی خطا معیاری عددی از میزان اجازه داده شده برای هزینه‌کردن از SLO در بازه‌ی معین (روز، هفته یا ماه) است.فرآیند تعریف بودجه‌ی خطاپروداکت منیجر یا کسی که آشنایی کافی با کاربران سیستم و انتظارات اون‌ها داره یک عدد به عنوان میزانی از سالم بودن سرویس که انتظار داره ارائه می‌کنه.مدت زمان واقعی سالم بودن سرویس توسط سیستم مانیتورینگ اندازه‌گیری میشه.تفاوت دو عدد بالا میزان بودجه‌ی خطا رو مشخص می‌کنه؛ یعنی میزانی از خرابی که در سیستم قابل تحمله.تا زمانی که بودجه‌ی خطا صفر نشده دولوپرها اجازه دارند که کد جدید دیپلوی کنند.نحوه‌ی محاسبه‌ی شاخص‌های سرویساما ما چطور این متریک‌ها رو اندازه میگیریم؟ با استفاده از پرومتئوس! پرومتئوس یک ابزار رایگان و متن‌باز هست که برای مانیتورینگ و اطلاع‌رسانی (Alerting) استفاده میشه. این ابزار متریک‌ها رو به صورت real-time در یک دیتابیس سری‌زمانی ذخیره میشه و زبان جستجوی نسبتا ساده‌ای داره. برای اطلاعات بیشتر می‌تونید به اینجا مراجعه کنید.در ادامه به جزئیات محاسبه‌ی یکی از متریک‌ها به صورت نمونه می‌پردازیم.سرویس نجوا یک اندپوینت برای تیم SRE فراهم کرده که از طریق اون متریک‌های مربوط به تأخیر در ارسال نوتیفیکیشن‌ها رو به صورت هیستوگرام در اختیار ما می‌ذاره. اگر با تایپ متریک‌های پرومتئوس آشنا نیستید اینجا رو مطالعه کنید. اگر بخوام به صورت مختصر هیستوگرام رو تعریف کنم باید بگم:هیستوگرام یک نمایش تقریبی از توزیع داده‌ی عددی است. برای اطلاعات بیشتر به این صفحه‌ی ویکی‌پدیا مراجعه کنید.برای مثال در تصویر زیر می‌تونید نتیجه‌ی کوئری روی این متریک رو در سرویس نجوا مشاهده کنید:نتیجه‌ی جستجو روی هیستوگرام تأخیر در ارسال نوتیفیکیشن‌های نجواهمونطور که از تصویر می‌بینید هر خط یک سری برچسب تحت عنوان "le" داره. یعنی «کوچکتر یا مساوی». به زبان ساده هر خط بیان می‌کنه که در یک زمان خاص، چه تعداد از نوتیفیکیشن‌ها تأخیری کوچکتر یا مساوی یک عدد خاص داشتن. برای مثال:‌ خط سبز رنگ نشون میده که در ۱۱:۳۰ تعداد ۱۵۰ نوتیفیکیشن وجود داشته که تأخیری کوچکتر یا مساوی ۱۰ ثانیه داشتن. واضحه که هرچیزی که کوچکتر یا مساوی ۱۰ باشه کوچکتر یا مساوی ۱۰۰ هم هست پس خط "le: +inf" نمایانگر تمامی نوتیفیکیشن‌هاست.حالا ما از این متریک چطور برای محاسبه‌ی SLI استفاده می‌کنیم؟ اینجاست که باید کمی با زبان PromQL یا زبان جستجوی پرومتئوس آشنا باشید. برای اطلاعات بیشتر به این صفحه مراجعه کنید.برای محاسبه‌ی SLI از این متریک ابتدا افزایش هر باکت و افزایش کل رو در بازه‌ی ۳۰ روزه محاسبه می‌کنیم:- record: najva:notification_delay_bucket:increase30d expr: |- increase(najva_najva_notification_delay_bucket[30d]) - record: najva:notification_delay_counter:increase30d expr: |- increase(najva_najva_notification_delay_count[30d])و سپس نسبت این دو رو به هم حساب می‌کنیم:- record: najva:non_vip_wait_time_slo:ratio_rate30d expr: |- ( sum( najva:notification_delay_bucket:increase30d{le=&quot3600.0&quot, queue=&quot1&quot} ) / sum( najva:notification_delay_counter:increase30d{queue=&quot1&quot} ) ) * 100عدد ۳۶۰۰ به ثانیه (برابر با ۱ ساعت) و queue=1 بیانگر غیر VIP بودن نوتیفیکیشن هست. عدد نهایی درصد نوتیفیکیشن‌هایی رو نشون میده که کمتر از ۱ ساعت منتظر ارسال بودن.حالا برای محاسبه‌ی بودجه‌ی خطا کافیه که این مقدار رو از SLO کم کنیم (اگر یادتون نیست SLO برای این متریک برابر با ۹۹٪ تعریف شده بود) یعنی:najva:non_vip_wait_time_slo:ratio_rate30d - 99که برای این سرویس در ابتدا نتیجه به صورت زیر شد:بودجه‌ی خطای نجوا برای نوتیفیکیشن‌های غیر VIP در روزهای اول این نمودار نشون میده که در طول زمان بودجه‌ی خطای سرویس نجوا برای SLOی مورد نظر چقدر هست. یعنی چی؟ به زبان ساده یعنی اینکه چقدر دیگه حق داریم که از این SLO مایه بذاریم! توی نمودار بالا می‌بینید که این مقدار منفی هست. به عبارت دیگه اگر SLOی مورد نظر ۹۹٪ بوده باشه این نشون میده که حوالی ساعت ۲ ظهر در نمودار بالا ۹۹ منهای ۲ درصد از نوتیفیکیشن‌های غیر VIP ما کمتر از ۱ ساعت منتظر ارسال بودن. به عبارت دیگه ۳ درصد از نوتیفیکیشن‌ها زمانی بیش از این مقدار رو در انتظار ارسال سپری کردن.همونطور که می‌بینید این مقدار منفی هست که به این معنیه که از مقدار SLO تخطی شده ولی چون به تازگی SLO برای این سرویس تعریف شده بود این موضوع قابل انتظار بود. همینطور تأثیر تعریف SLO رو در نمودار بالا می‌بینید که دولوپرها به محض اینکه متوجه شدند که وضعیت خوبی از نظر تأخیر در ارسال نوتیفیکیشن ندارند اون رو اصلاح کردند و بودجه‌ی خطا در حال برگشت به مقدار بالای صفر هست.الان که در حال اعمال اصلاحات نهایی روی این نوشتار هستم بودجه‌ی خطای نجوا به شکل زیر در اومده:بودجه‌ی خطای نجوا برای نوتیفیکیشن‌های غیر VIP هنگام انتشار این نوشتار و بله! می‌بینید که نه تنها از SLO تخطی نشده بلکه بودجه‌ی خطا روند صعودی داره و دولوپرهای نجوا با خیال آسوده می‌تونن به توسعه‌ی قابلیت‌های جدید بپردازن! و این نتیجه‌ی مانیتورینگ صحیح و آگاهی از وضعیت سیستم هست.سخن آخرهمانطور که در این نوشتار دیدیم تعریف SLI و SLO برای سرویس اهمیت بالایی داره و باعث شفافیت انتظارات از سرویس میشه. یکی از وظایف ما در تیم SRE یکتانت ایجاد زیرساخت برای تعریف، محاسبه و مانیتورینگ SLOهاست. در صورتی که علاقه‌مندید تا با مسائلی از این دست دست و پنجه نرم کنید خوشحال میشیم سری به صفحه‌ی فرصت‌های شغلی ما بزنید. یکتانت | Yektanet javadalipanah Sat, 31 Jul 2021 14:57:19 +0430 https://virgool.io/yektanet/%D8%AE%D8%B4%D8%AA-%D8%A7%D9%88%D9%84-%D8%AF%D8%B1-%D8%A8%D8%A7%D8%A8-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D8%B3%DB%8C%D8%B3%D8%AA%D9%85-%D8%AA%D8%A8%D9%84%DB%8C%D8%BA%D8%A7%D8%AA-%D9%81%D8%B1%D9%88%D8%B4%D9%86%D8%AF%DA%AF%D8%A7%D9%86-%D8%AF%DB%8C%D8%AC%DB%8C%DA%A9%D8%A7%D9%84%D8%A7-gme9xnpzphyw مقدمهتوضیح: تمام کلمات و اصطلاحاتی که از زبان بیگانه قرض گرفته شده‌اند با هدف خودنمایی و بالابردن بار ظاهری متن مورد استفاده قرار گرفته‌اند. پیشاپیش بابت ناتوانی در خودنمایی با کلمات زبان زیبای فارسی عذرخواهی می‌شود.دو سه ماهی بود که از شروع کارم در یکتانت می‌گذشت. به نقطه‌ای رسیده بودم که تکراری شدن تسک‌هایی که مسئولشون بودم باعث شده بود که موهام رو دونه دونه بکنم. دلم یه چالش سنگین می‌خواست. یک پروژه که هم جذاب و هم پر چالش باشه. داشتم پشت میزم کد می‌زدم که شنیدم (اسامی برای احترام به حریم خصوصی افراد با نام مستعار جایگزین شده است.) «سینا» به «کامیاب» گفت که قراره مسئولیت سیستمی برای تبلیغات دیجی‌کالا رو به عهده بگیریم. نیاز به سیستمی قوی داریم و احتمالا باید از Elasticsearch (الستیک) استفاده کنیم.من که بعد از شنیدن «پروژه جدید» و «الستیک» حسابی ذوق‌زده شده بودم پایان اون روز پیش سینا رفتم. ازش پرسیدم علت این که قصد استفاده از الستیک رو داریم چیه؟ گفت می‌خوایم با سرچ کاربرهای دیجی‌کالا از بین کلی تبلیغ مناسب‌ترین رو با کمترین زمان بدیم و طبق تجربه‌های قبلی الستیک گزینه خیلی خوبی به نظر می‌رسه چون عملا یک موتور جستجو به حساب میاد. بهش گفتم من تجربه کار با الستیک رو دارم و خیلی دلم می‌خواد بخشی از این پروژه باشم. بعد از این که سینا از پیشنهاد همکاریم در این پروژه استقبال کرد خوشحال شدم که باقی موهای سرم دست نخورده باقی خواهند موند.با کامیاب استارت پروژه رو زدیم. علی زحمت پنل و تمام بخش‌های فرانت و پوران بار پروداکت قضیه رو به دوش می‌کشید. با این که از قبل با کامیاب هم‌تیمی بودم پروژه دیجی‌کالا باعث همکاری عمیق‌تر و دوستی بین ما شد. بعد از یکی دو هفته می‌تونستیم به راحتی در مورد موضوعات مهم فلسفی مثل این که بهترین آلبوم رادیوهد کدومه، چه قسمتی از سریال ساینفیلد از بقیه خنده‌دارتره یا چرا سریال ریک و مورتی هر فصل داره افت می‌کنه صحبت کنیم.در ابتدای کار فشار زمانی زیادی بر تیم بود، نیازمندی‌های پیچیده و گوناگونی وجود داشت، همکاری با تیم و شرکتی بیرون از سازمان به دلیل اختلاف فرهنگ‌ها و فرآیندها چالش‌هایی مخصوص به خودش رو داشت و مثل هر پروژه دیگه، شروع کار شامل فعالیت‌هایی بسیار خسته کننده و متعدد (مثل تعیین اسم پروژه) بود.با وجود تمام این مسائل، من و کامیاب تصمیم گرفتیم که تا جایی که توان داریم کدهای تمیزی بنویسیم، با تست نویسی پروژه رو جلو ببریم و قواعد رو رعایت کنیم. سعی کردیم هر جایی که تصمیمی باید گرفته بشه تلاش در راستای بهینگی و نگاه به آینده پروژه داشته باشیم و میانبر نزنیم.تصمیم گرفته بودیم که از خشت اول همه چیز رو صاف بچینیم.نیازمندی‌ها و چالش‌هابهتره از قصه‌گویی بیشتر پرهیز کنیم و به بعد فنی ماجرا نگاهی کنیم. کلیت پروژه این بود که کاربر سایت دیجی‌کالا رو باز می‌کنه و ما باید تبلیغاتی رو بهش نشون بدیم. این تبلیغات به وسیله فروشندگان دیجی‌کالا (که از اینجا به بعد بهشون سلرها خواهیم گفت) برای محصولاتی که در این سایت می‌فروشند ساخته می‌شد. نمونه‌ای از این تبلیغات رو در عکس زیر می‌شه دید.نمونه‌ای از تبلیغات هنگام جستجوی کلمه «کفش»در ادامه این قسمت نیازمندی‌هایی که برای این سیستم وجود داشت و چالش‌هایی که هر کدوم از اون‌ها ایجاد می‌کرد رو بررسی می‌کنیم.اول از هر چیز ما باید پنلی ارائه می‌کردیم که سلرها بتونن در اون محصولات خودشون رو ببینن و به صلاح‌دیدی که دارند برای هر کدوم از اون محصولات تبلیغ بسازند. این موضوع چالش بزرگ همگام‌سازی داده‌ها بین ما و دیجی‌کالا رو تحمیل می‌کرد. برای مثال اگر کالایی تغییر نام پیدا می‌کرد، این تغییر باید سمت ما هم اتفاق می‌افتاد یا اگر موجودی یک کالا به پایان می‌رسید ما هم باید متوجه این موضوع می‌شدیم و اگر کالای جدیدی وارد می‌شد سمت ما هم باید افزوده می‌شد. در نتیجه دیجی‌کالا باید تغییرات موجودیت‌ها (entity) رو به سرعت به ما اطلاع می‌داد که سلرها احساس گسستگی بین دو سیستم نکنند.نیازمندی بعدی این پروژه تطبیق مناسب تبلیغات با کالاهایی که در صفحات مختلف نمایش داده می‌شه بود. نمی‌شه وقتی کاربر دنبال کفش می‌گرده تبلیغ آچار و پیچ‌گوشتی بهش نشون بدیم. اینطوری هم تجربه کاربری و هم احتمال کلیک کاربر روی یک تبلیغ پایین میاد. این باعث می‌شه که هنگام جستجو یا Fetch (فچ) تبلیغ، احترام به فیلترهای صفحه، مثل کلمه‌ای که جستجو شده یا دسته‌بندی کالا اهمیت بالایی پیدا کنه.سلرها باید بازخوردی از تبلیغاتشون داشته باشند. یک سلر برای تبلیغاتش هزینه می‌کنه و لازمه بدونه این هزینه به چه شکل مصرف می‌شه و چه تاثیرات مثبتی روی سودآوری و فروش خودش داشته. این بازخورد در قالب گزارش‌هایی داده می‌شه که باید از تبلیغات و هزینه‌ها به دست سلرها برسه؛ پس نیاز بود که تمام آمارهایی که از تبلیغ‌ها در میاد به درستی ذخیره بشن تا زمانی که سلر نیاز داشت به راحتی و به سرعت بتونه از اونها گزارشاتش رو استخراج کنه.مساله بعدی کارآمد بودن سیستم یا همون پرفورمنس بود. یک نیازمندی که از سمت تیم دیجی‌کالا به ما در ابتدای کار اعلام شده بود زمان پاسخ‌دهی (Response Time) کمتر از ۱۰۰ میلی‌ثانیه برای فچ هر تبلیغ بود. از طرف دیگه سایت دیجی‌کالا به صورت میانگین درخواست بر ثانیه (Request/Second - RpS) بالایی داره و ممکنه در شب‌هایی خاص مثل شب یلدا یا روز مادر میزان درخواست‌ها به ۷۰۰ تا ۱۰۰۰ عدد در ثانیه برسه. این دو موضوع ایجاد یک سیستم قوی و بهینه رو ضروری می‌کرد.تمام نیازمندی‌های قبلی مساله‌ای رو مشخص کرد. این امکان وجود نداره که با یک دیتابیس هم همگام‌سازی دیتا رو به خوبی انجام داد، هم آمارها و گزارشات رو ذخیره و پردازش کرد و هم با سرعت بالا بین تبلیغات جستجو کرد. در نتیجه باید از سیستم‌ها و دیتابیس‌های متفاوتی استفاده کرد. این موضوع چالش بعدی پروژه رو به وجود آورد. چطوری میشه دیتای بین این دیتابیس‌ها و سیستم‌ها رو با سرعت بالا همگام‌سازی کنیم که وقتی مثلا اسم یک محصول تغییر کرد موقع جستجوی تبلیغ اسمی اشتباه نمایش داده نشه؟عکسی سبک و کلیشه‌ای که برای به فکر بردن خواننده مورد استفاده قرار گرفته است.زیرسیستم‌هابرای ارضای تمام نیازمندی‌ها گفته شده باید زیر سیستم‌های مختلفی شکل می‌گرفت. در ادامه به معرفی هر یک از این زیر سیستم‌ها می‌پردازیم.پنلپنل مبدا همه چیز برای سلرهای دیجی‌کالاست. سلرها می‌تونن کالاهای خود رو در پنل ببینند، گروه‌های تبلیغاتی بسازند و گزارش تبلیغات از هزینه تا کلیک‌هایی که هر تبلیغ داشته رو ببینند. همچنین در صورت بروز هر مشکلی به پشتیبانی پیام بدن تا در اولین فرصت پاسخی برای حل این مشکلات دریافت کنند.کورسیستم کور (Core) قسمت Back-End پنل و لاجیک‌های بیزنسی برای تبلیغات، موجودیت‌ها، آمارها و همگام‌سازی‌های بین دیتابیس‌ها رو هندل می‌کنه. این زیر سیستم در واقع قلب تپنده‌ی کل سیستم رو تشکیل می‌ده.وب‌هوک‌هاوب‌هوک‌ اسمیه که به زیر مجموعه‌ای از سیستم کور دادیم که وظیفه همگام‌سازی داده‌های دیجی‌کالا و داده‌های ما رو داره. هر تغییری که در موجودیت‌هایی خاص مثل محصولات در سمت دیجی‌کالا اتفاق میافته، وب‌هوک متناظر با اون موجودیت صدا زده می‌شه تا این تغییرات در سیستم ما هم لحاظ بشه.تخلیصتخلیص نام انبار داده‌های یکتانته و ما از همین سیستم برای ثبت تمام آمار تبلیغات و نمایش گزارشات استفاده می‌کنیم. این آمارها موارد زیر رو تشکیل میدن:نمایش: میزان مشاهده شدن یک تبلیغ به وسیله کاربران دیجی‌کالاکلیک: میزان کلیک بر یک تبلیغ که هزینه یک تبلیغ بر اساس آن مشخص می‌گرددهزینه: مجموع هزینه‌ای که سلر برای یک تبلیغ پرداخت کرده استافزودن به سبد خرید: آماری که نشان می‌دهد یک کالا بعد از کلیک چند بار به سبد خرید کاربر افزوده شده استسفارش: آماری که نشان می‌دهد یک کالا بعد از کلیک چند بار به وسیله کاربر سفارش داده شده استفچاین سیستم وظیفه ارائه تبلیغات برای صفحه‌ای که کاربر مشاهده می‌کند را دارد. نیازمندی‌های اصلی این سیستم قابلیت تحمل لود بالا و ریسپانس تایم پایین است. فچ با استفاده از پارامترهای ورودی یک لینک از سایت دیجی‌کالا، در دیتابیس الستیک تبلیغات مناسب رو جستجو می‌کنه.اوراکل فرض کنید کاربر دیجی‌کالا کلمه‌ای مثل جاسوییچی رو جستجو می‌کنه و سیستم ما فاقد تبلیغ کالایی با این کلمه است؛ با این وجود تبلیغی برای کلمه «جاکلیدی» وجود داره. نیازه که برای جستجوی کاربر تبلیغاتی که معنای معادلی برای این جستجو دارند هم ارائه بشه. اوراکل وظیفه درک و استنباط این معادل‌ها هنگام جستجو رو داره.معماری کلیمعماری کلی سیستم (رسم شده در نرم‌افزار XMind)معماری این پروژه شامل بخش‌های زیادی می‌شه که می‌تونید تصویر کلی اون رو در عکس بالا مشاهده کنید. در ادامه این بخش قسمت‌هایی از این معماری شرح داده می‌شه.همگام‌سازی تبلیغات بین دیتابیس کور و الستیکوقتی که سلر در پنل تبلیغی می‌سازه، اطلاعات این تبلیغ در دیتابیس کور ذخیره خواهد شد. علت این موضوع اینه که روابط تبلیغ با سایر موجودیت‌ها در بهترین حالت خودش در یک دیتابیس رابطه‌ای نشون داده می‌شه. با این وجود این تبلیغات باید در الستیک هم ریخته بشه تا فچ بتونه برای لینک‌های متفاوت تبلیغاتی مرتبط ارائه کنه.برای یک تبلیغ دو اتفاق کلی میافته. تبلیغ می‌تونه فعال یا غیرفعال بشه و از طرف دیگه اطلاعاتش تغییر کنه. برای مثال اگر بودجه یک سلر به پایان برسه تبلیغاتش غیرفعال خواهند شد. اگر زمان یک گروه تبلیغاتی به پایان برسه تبلیغات اون گروه غیرفعال خواهند شد. اگر اسم یک کالا یا موجودی اون تغییر بکنه اطلاعات تبلیغ هم باید تغییر کنه.نیازه که فچ جستجو رو بین تبلیغات فعال انجام بده. اولین راه حلی که به نظر می‌رسه اینه که منطق فعال بودن یا نبودن یک تبلیغ رو خود فچ پیش ببره. این راه حل بهینه نیست چون منطق فعال بودن یک تبلیغ نیاز به یک کوئری پیچیده داره که برای سیستمی مثل فچ که در ثانیه بیش از ۳۰۰ درخواست رو پاسخ میده عملی نیست و زمان هر کوئری رو بالا می‌بره.بهتره از این جا به بعد دو حالت برای یک تبلیغ در نظر بگیریم. تبلیغ فعال (اکتیو) و تبلیغ کثیف (dirty). تبلیغ اکتیو تبلیغیه که می‌تونه نمایش بگیره. تبلیغ کثیف هم تبلیغیه که اطلاعاتش در دیتابیس کور تغییر کرده اما این تغییرات هنوز در الستیک لحاظ نشده. سوال اصلی اینه که ما چطوری تبلیغات فعال و تبلیغات کثیف رو به الستیک اعلام کنیم که هم در حجم بالا مشکلی رخ نده و هم سرعت بالایی داشته باشه؟نرخ فعال و غیرفعال شدن تبلیغات بالاست. ما برای هندل کردن همگام‌سازی تبلیغات فعال با الستیک از تکنیکی ساده استفاده کردیم که اسمش رو Active Ads Probing یا سرکشی به تبلیغات فعال گذاشتیم. روند به این صورته که تبلیغات فعال با همون لاجیک پیچیده‌ای که دارند، سمت کور کوئری خواهند شد. در مرحله بعدی با استفاده از شناسه این تبلیغات اون‌ها رو در الستیک probe می‌کنیم. probe کردن یک تبلیغ می‌تونه به معنای ورژن زدن یا افزودن یک timestamp به اون باشه. حالا فچ کافیه بین تبلیغاتی که آخرین probe رو دارند جستجو کنه.نرخ کثیف شدن تبلیغات هم بالاست. ما برای حل این مساله طور دیگه‌ای به موضوع نگاه کردیم. فچ برای جستجوی تبلیغ نیازی به تمام اطلاعات یک تبلیغ نداره. مثلا زمان شروع و پایان یک گروه تبلیغاتی فقط برای سنجش فعال بودن یا نبودن یک تبلیغ استفاده خواهد شد و هنگام جستجو اهمیتی نخواهد داشت. در نتیجه ما فقط فیلدهایی که برای جستجو به اون‌ها نیاز داریم رو در الستیک ریختیم. از اون‌جایی که نرخ کثیف شدن این فیلدها پایین‌تره، همگام‌سازی دوره‌ای بین کور و الستیک در لایه API، اعلام تبلیغات تغییر کرده و تغییر هر کدوم کفایت می‌کنه.وب‌هوک‌هااز ابتدای کار ضرورت همگام‌سازی داده بین ما و دیجی‌کالا مشخص بود. برای این کار مجموعه APIهایی که نام اونا رو WebHooks گذاشتیم تعبیه شد. وب‌هوک‌ها علاوه بر این که با نرخ بالایی دیتا می‌گیرند احتمال بروز مشکل Race Condition در اون‌ها خیلی بالاست. فرض کنید که موجودی یک کالا در کمتر از چند ثانیه تغییر کرده و این تغییرات به وب‌هوک‌ها داده می‌شوند. حال با دو Update سروکار داریم که هر دو سعی در تغییر یک فیلد در یک موجودیت دارند. همچنین اطلاعاتی که به وب‌هوک داده می‌شود می‌تواند اعلام تغییراتی به یک موجودیت از پیش داده شده یا اعلام موجودیتی جدید باشد.برای حل این مشکل‌ها اندپوینت‌های وب‌هوک تمام تغییرات گفته شده رو در یک صف می‌ریزن. این صف اسکن می‌شه و فقط جدیدترین موجودیت بین موجودیت‌های تکراری برای تغییر در نظر گرفته خواهد شد.آمارهاتبلیغات این سیستم کلیک محور هستند. یعنی سلر به ازای هر کلیکی که بر تبلیغش می‌شه هزینه‌ای پرداخت می‌کنه. برای همین آمارهای هزینه و تعداد کلیک در موقع کلیک شدن یک تبلیغ شمرده خواهند شد. آمار نمایش به علت تغییرات با نرخ بالا، هنگام جستجوی تبلیغ در فچ، همونجا ذخیره شده و به صورت دوره‌ای به کور داده خواهد شد. دو آمار دیگه که شامل افزوده شدن به سبد خرید و سفارش کالای یک تبلیغ از دیجی‌کالاست هم با استفاده از وب‌هوک‌ها به ما اعلام می‌شه.اوراکلاوراکل یکی از جذاب‌ترین بخش‌های این پروژه بود. هدف اصلی این زیرپروژه اینه که بتونیم دامنه بیشتری از تبلیغات رو ارائه بدیم و خودمون رو محدود به پارامترهای لینک نکنیم. ما می‌خواستیم کوئری‌هایی که فچ انجام می‌ده هوشمندانه‌تر باشه تا تبلیغاتی که به واقع کاملا مرتبط هستند اما به طور کامل با فیلترها همخوانی ندارند هم ارائه بشن.به صورت کلی اوراکل دو کار اصلی انجام میده. «نرم‌کردن» (relaxation) و «بسط‌دادن» (augmentation) کوئری. نرم‌کردن کوئری به این معناست که اگر کاربر دنبال کالایی با بازه قیمتی بین ۱ تا ۲ میلیون تومان می‌گشت؛ اگر تبلیغی برای این بازه وجود نداشت ما با نرم‌کردن کوئری تبلیغاتی که در بازه قیمتی (مثلا) ۵۰۰هزار تومان تا ۳ میلیون تومان می‌گنجند هم نمایش بدیم.داستان بسط‌دادن کوئری پیچیدگی‌های زیادی داره. اوراکل گرافی از ارتباطات بین موجودیت‌های سرچ مثل کلمه کلیدی، دسته‌بندی و برند کالا می‌سازه که میزان شباهت دو موجودیت بر اساس وزن یالی که بین اونهاست مشخص می‌شه. وقتی که فچ به دنبال تبلیغی برای کلمه کلیدی جاسوییچی می‌گرده، اوراکل برای موجودیت «کلمه کلیدی جاسوییچی» جستجوی اول سطحی در گراف خواهد کرد و شبیه‌ترین همسایه‌های این کلمه کلیدی رو پیدا می‌کنه. بعد از این که کوئری با این کلمات ارتقا پیدا کرد یا به قول ما augment شد،‌ جستجو در بین تبلیغات انجام می‌شه.گام‌های آیندهتعامل بین دیجی‌کالا و یکتانت در ابتدای کار خودشه. با بلوغ این پروژه سلرهای بیشتری به سیستم وارد خواهند شد تا بتونن به بهترین شکل کالاهای خودشون رو در معرض دید قرار بدن. تلاش ما در یکتانت اینه که بستری مناسب و بدون مشکل برای این کار ارائه کنیم. همچنین تبلیغات رو به مرتبط و کاربردی‌ترین شکل ممکن ارائه بدیم که هم از تجربه کاربری مصرف‌کننده‌های دیجی‌کالا کم نکنه و هم تبلیغ‌کننده‌ها تاثیر خوبی از هزینه‌هایی که می‌کنند بگیرن.کلام آخربا وجود سختی‌های کار و فشار زمانی پروژه، شروع خوب و ساختارمندی که از ابتدا داشتیم به ما کمک کرد که بتونیم گام‌های بعدی رو با سرعت و اطمینان بیشتری برداریم. از اول سعی داشتیم به ته قضیه فکر کنیم. به وقتی که همه سلرهای دیجی‌کالا به سیستم اضافه شدند، به زمانی که سیستم زیر بار شدیده و باید بی‌خوابی بکشیم تا یه سری مشکلات رو حل کنیم. این شروع خوب کمک خیلی بزرگی به ما کرد. همه این‌ها رو گفتم که بگم فکر نکنید شروع پروژه مهم نیست. همه چیز توی همون خشت اوله.به تازگی سه نیروی جدید به پروژه اضافه شدند و طراحی و معماری اولیه پروژه کمک شایانی به سرعت توسعه فعلی برای کل تیم کرده. اگر دوست داشته باشی شما هم می‌تونید نفر بعدی باشید که به تیم ما اضافه می‌شه (اینجا رو ببین). اگر سوالی یا مساله‌ای در مورد یکتانت یا سیستم سلرهای دیجی‌کالا داشتید هم می‌تونید با من در اینجا یا اینجا در ارتباط باشید و همچنین از بقیه مقاله‌های یکتانت هم استفاده کنید.جا داره در نهایت یک تشکر ویژه از کامیاب برای تحمل گیرهایی که می‌دادم و از سینا بابت بحث‌هایی طولانی که در مورد مسائل معماری باهم داشتیم بکنم. یکتانت | Yektanet امین فدائی Mon, 07 Jun 2021 13:02:03 +0430 https://virgool.io/yektanet/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D8%A7%D8%AD%D8%B1%D8%A7%D8%B2-%D9%87%D9%88%DB%8C%D8%AA-%DB%8C%DA%A9%D8%AA%D8%A7%D9%86%D8%AA-dqsxziraa2gk در این مقاله می‌خوام درباره‌ی سرویس احراز هویت یکتانت بنویسم. این سرویس که همزمان با تولد یکتانت ایجاد شده، در طی این چهار سال تغییرات زیادی را به خود دیده است. این تغییرات جزئی از زندگی یک نرم‌افزار است و تا یکتانت زنده است ادامه خواهد داشت.هر سرویسی که می‌خواهد خدمتی اختصاصی به کاربرانش بدهد نیاز دارد که بتواند کاربران خود را احراز هویت کند. سرویس اکانتس در یکتانت این وظیفه را برعهده دارد. چهار سال پیش که یکتانت تازه داشت متولد می‌شد، فقط یک سرویس داشتیم که نیازمند احراز هویت کاربران بود و برای آن از مکانیزم احراز هویت نشست (Session Authentication) جنگو استفاده کردیم. با گذر زمان و با افزایش سرویس‌ها و در مسیر معماری میکروسرویس، نیاز ایجاد مکانیزم مناسبی برای احراز هویت کاربران به وجود آمد.تجربه کاربری نباید از معماری سرویس‌ها آسیب می دید. کاربری که می‌خواست همزمان از چندین سرویس‌ تبلیغاتی یکتانت استفاده کند باید همه‌ی این سرویس‌ها را یک سرویس واحدی از طرف یکتانت می‌دید. یعنی کاربر فقط باید یک‌بار ثبت‌نام می‌کرد و یکبار وارد سیستم می‌شد و پس از آن باید می‌توانست از همه‌ی سرویس‌های یکتانت استفاده کند. اصطلاحا به چنین مکانیزمی SSO یا Single Sign On می‌گویند.با گذر زمان و با تولد پلتفرم‌های دیگر و یکپارچه شدن‌ آنها با پلتفرم یکتانت، چالش‌های جدیدی برای ایجاد یک مکانیزم امن و راحت برای احراز هویت کاربران به وجود آمد. در این مقاله می خواهم درباره‌ی چالش‌ها و راه‌حل‌های ایجاد چنین مکانیزمی در طی این چهار سال حرف بزنم.سرویس اکانتس در یکتانت وظیفه‌ی احراز هویت کاربران را دارد و اجازه‌ی استفاده از پلتفرم‌ها و سرویس‌های مختلف را به کاربران می‌دهد.اولین نشانه‌های مقیاسدر ابتدای یکتانت، همه‌ی سرویس‌ها به شکل یکپارچه‌ (monolithic) بودند و از پایگاه‌داده مشترکی استفاده می‌کردند. همچنین احراز هویت سرویس‌ها توسط مکانیزم نشست جنگو صورت می‌گرفت.با ایجاد سرویس تبلیغاتی بنری‌ یکتانت می‌خواستیم در مسیر میکروسرویس شدن پیش برویم و تا جای ممکن سرویس‌های مستقلی داشته باشیم. این انتخاب به این معنا بود که سرویس‌های جدید دیگر دسترسی به پایگاه‌داده‌ی اصلی که اطلاعات کاربران و نشست‌ها در آن ذخیره شده بود، نخواهند داشت. بنابراین مکانیزم احراز هویت پیش‌فرض جنگو برای ما مناسب به نظر نمی‌رسید.مهندسی معماری سرویس‌ها نباید تجربه‌ی کاربری را تحت تاثیر قرار می‌داد. در مثال ما کاربران یک انتظار کاملا منطقی از یکتانت داشتند. اینکه یک بار ثبت‌نام کنند. یک بار وارد سیستم شوند و یک بار از سیستم خارج شوند.اولین ایده استفاده از پایگاه‌داده مشترک برای کاربران و اطلاعات نشست‌ها بین همه‌ی سرویس‌ها بود. این معماری هر چند ساده و خوب به نظر می‌رسید ولی ایرادات متعددی داشت. مهمترین ایرادش این بود که واسط (interface) سطح پایینی در اختیار سرویس‌ها برای کار با داده‌های کاربران می‌داد. یعنی هر تصمیمی که منجر به تغییر پایگاه‌داده‌ی مشترک می‌شد باید همه‌ی سرویس‌ها را هم تغییر می‌دادیم. از طرفی این پایگاه‌داده‌ی مشترک گلوگاه سرویس‌ها می‌شد. یعنی در صورت بروز هر گونه مشکل برای این پایگاه‌داده‌ی مشترک، همه‌ی سرویس‌ها با اختلال مواجه می‌شدند.معماری پایگاه‌داده‌ی مشترک هر چند ساده است ولی واسط سطح پایینی در اختیار سرویس‌ها می‌گذارد و تبدیل به گلوگاه می‌شود. معماری سرویس‌ واسطاستفاده از یک سرویس واسط (Proxy Service) ایده‌ای بود که ابتدا توجه‌مان را جلب کرد. ایده‌ی کلی این بود که کاربران فقط به یک سرویس واسط درخواست دهند و این سرویس واسط درخواست را به سرویس مرتبط دوباره ارسال کند. در این صورت این سرویس واسط می‌توانست با مکانیزم نشست جنگو، کاربر را احراز هویت نماید و ارتباطش با سرویس‌های دیگر با استفاده از احراز هویت توکنی (Token Authentication) صورت پذیرد.معماری سرویس واسط که در آن همه‌ی درخواست‌ها ابتدا به سرویس احراز هویت زده می‌شوند.این معماری چندین ایراد داشت. اولا همه‌ی ترافیک از یک سرویس واسطی عبور می‌کرد که باعث می‌شد گلوگاه ترافیک شود. یعنی در صورت بروز هرگونه مشکل در این سرویسِ واسط، همه‌ی درخواست‌های کاربران دچار مشکل می‌شدند. از طرفی تعداد درخواست‌های سرویس واسط تقریبا برابر مجموع درخواست‌های دیگر سرویس‌ها بود. این نشان‌دهنده‌ی چالش‌های مقیاس‌پذیری این سرویس بود. به خاطر چنین ایراداتی، از این معماری استفاده‌ای نشد.معماری صدور بلیتمعماری بعدی که تا حد خوبی مشکلات معماری‌های قبلی را حل می‌کرد، معماری صدور بلیت بود که از پروتکل کربروس (Kerberos) اقتباس شده بود. در این معماری سرویسی وظیفه‌ی احراز هویت کاربران و ایجاد بلیت‌های دسترسی به سرویس‌های دیگر را داشت. کاربران برای اینکه بتوانند از سرویس خاصی استفاده کنند باید بلیت خود را به آن سرویس ارسال می‌نمودند.بلیت‌ها باید دو ویژگی اصلی داشته باشند. ابتدا باید اطلاعاتی از کاربر مانند شناسه و نام کاربری را در خودشان ذخیره کنند. این باعث می‌شود تا سرویس‌هایی که بلیتی دریافت کرده‌اند بتوانند در همان لحظه بفهمند که این بلیت مربوط به چه کاربری است و نیازی به API‌های اضافی برای دریافت اطلاعات کاربر نباشد. در ثانی بلیت‌ها باید قابلیتی داشته باشند که تنها توسط سرویسی که بلیت‌ها را صادر می‌کند ساخته شوند و کسی نتواند بلیتی بسازد یا آن را تغییر دهد. پس از این به این بلیت‌ها توکن‌های دسترسی می‌گوییم چون دسترسی استفاده از سرویس‌های دیگر را به کاربر می‌دهند.مراحل پروتکل کربروس: ۱- ابتدا کاربر، نام‌کاربری و رمز عبور خود را به سرویس احراز هویت ارسال می‌کند. ۲- سرویس احراز هویت در صورت معتبر بودن اطلاعات کاربر، نشست ایجاد می‌کند. ۳- کاربر درخواست ایجاد بلیتِ دسترسی را به سرویس صدور بلیت می‌فرستد. ۴- سرویس صدور بلیت، بلیت ایجاد شده را در اختیار کاربر می‌گذارد. ۵- کاربر با ارائه‌ی بلیتِ دسترسی، درخواستی به سرویس مورد نظر می‌زند. ۶- سرویس مورد نظر، در صورت معتبر بودن بلیتِ کاربر به درخواست پاسخ می‌دهد.برای تولید چنین توکن‌هایی از استاندارد JWT یا Json Web Tokens استفاده می‌کنیم. این استاندارد که برای ایجاد توکن‌های امن (مانند توکن دسترسی) در محیط‌های ناامن (مانند ارتباط کلاینت با سرور در یک وب اپلیکیشن) که امکان تغییر توکن توسط اشخاص دیگر وجود دارد، استفاده می‌شود. این توکن دارای سه بخش هدر، بدنه و امضا است. در بخش هدر تنظیمات کلی توکن مانند الگوریتم مورد استفاده، در بدنه داده‌هایی مانند شناسه و نام کاربر و در بخش امضا، امضای دیجیتال توکن ذخیره می‌شود.ساختار یک توکن در استاندارد JWT: توکن سه بخش هدر، بدنه و امضا دارد. هر کدام از این سه بخش با base64 کد می‌شوند و با کاراکتر نقطه از هم جدا می‌شوند. در بخش هدر الگوریتم مورد استفاده برای امضا و دیگر توضیحات کلی توکن قرار می‌گیرد. در بخش بدنه، داده‌ها به شکل JSON قرار می‌گیرند. در بخش امضا هم امضای دیجیتال توکن توسط الگوریتم رمزنگاری که در بخش هدر تعیین شده است برای محافظت از توکن در برابر تغییرات تعبیه می‌شود.امضای دیجیتال مکانیزمی است که به کمک شیوه‌های رمزنگاری مانع از تغییر توکن می‌گردد. به این صورت که سرویسی که توکن دسترسی دریافت می‌کند می‌تواند بررسی کند که آیا امضای دیجیتال توکن معتبر است یا نه. در صورت معتبر نبودن درخواست کاربر را رد می‌کند. هر گونه دستکاری و تغییر در توکن منجر به نامعتبر شدن امضای دیجیتال توکن می‌شود. امضای دیجیتال با استفاده از رمزنگاری نامتقارن باعث می‌شود تا توکن‌های دسترسی مشکل امنیتی برای احراز هویت کاربران نداشته باشند.در یکتانت سرویس اکانتس وظیفه‌ی احراز هویت کاربر و تولید توکن دسترسی را دارد. ابتدا کاربر با نام کاربری و رمز عبور خود وارد سرویس اکانتس می‌شود. سپس برای اینکه کاربر به سرویس‌های تبلیغاتی یکتانت دسترسی داشته باشد، توکن دسترسی ایجاد می‌کند. حال پنلِ یکتانت می‌تواند با این توکنِ دسترسی، به سرویس‌های مختلف از طریق API درخواست بفرستد. سرویس‌ها نیز می‌توانند در صورت معتبر بودن توکن، اطلاعات کاربر را از آن استخراج کنند و به درخواست کاربر پاسخ دهند.باز هم مقیاس و باز هم چالشمعماری که در بالا اشاره شد تا پاییز پارسال به خوبی به نیاز سرویس‌ها پاسخ می‌داد. ولی تصمیم بیزینسی گرفته شد که نیازمند مقیاس بیشتر در سرویس احراز هویت بود. پلتفرم‌های نجوا و تریبون ایجاد شده بودند و می‌خواستیم کاربران پلتفرم‌ها و فرآیند احراز هویت‌شان با سرویس اکانتسِ یکتانت یکپارچه شوند. یعنی کاربران فقط یکبار ثبت‌نام و وارد می‌شدند و پس از آن از همه‌ی پلتفرم‌های تبلیغات یکتانت، پوش نجوا و رپورتاژ تریبون و دیگر پلتفرم‌هایی که در آینده ایجاد می‌شدند می‌توانستند استفاده کنند.مهمترین چالش مهندسی این بود که توکن دسترسی پلتفرم‌ها نمی‌توانست یک توکن واحدی باشد و سرویس اکانتس می‌بایست برای هر پلتفرم توکن دسترسی اختصاصی به آن را ایجاد کند. دلیل این مورد این بود که مشکلات امنیتی یک پلتفرم خاص نباید دیگر پلتفرم‌ها را در معرض خطر قرار دهد. یعنی اگر توکن‌های دسترسی بین همه‌ی پلتفرم‌ها یکسان بودند و پلتفرمی به خاطر مشکلات امنیتیِ خود، منجر به نشتی توکنِ دسترسی می‌شد، با استفاده از این توکن نشت شده می‌شد در همه‌ی پلتفرم‌ها تغییرات ناخواسته ایجاد کرد.برای ایجاد توکن‌های دسترسی مخصوص هر پلتفرم، پنل‌ هر پلتفرم که وظیفه‌ی درخواست ایجاد توکن برای پلتفرم خود را از سرویس اکانتس دارد باید به نحوی ثابت می‌کرد که واقعا متعلق به آن پلتفرم است. چون نمی‌خواستیم به طور مثال پنل پلتفرم تریبون بتواند برای پلتفرم یکتانت درخواست ایجاد توکن دسترسی دهد.برای حل این مشکل، در سرویس اکانتس توکن میانی به نام refresh token ایجاد کردیم. این توکن بعد از اینکه کاربری تصمیم استفاده از پلتفرمی را می‌گرفت ایجاد می‌شد که مخصوص آن پلتفرم بود. این توکن در کوکی‌های دامنه‌ی آن پلتفرم تعبیه می‌گردید. در نتیجه پنل‌ها هنگام درخواست توکنِ دسترسی، با ارسال این توکن میانی به سرویسِ اکانتس می‌توانستند توکن دسترسی دریافت نمایند.ابتدا کاربر با ارائه‌ی نام کاربری و رمز عبور خود به سرویس اکانتس، نشستی ایجاد می‌کند. برای دسترسی به پلتفرمی که دامنه‌ی اختصاصی خودش را دارد باید توکن میانی (YRT) توسط اکانتس برای آن ایجاد شود. کاربر با ارسال توکن میانی به سرویس اکانتس می‌تواند توکن دسترسی (YAT) برای دسترسی به سرویس‌های آن پلتفرم ایجاد نماید. در نهایت کاربر با ارائه‌ی توکن دسترسی می‌تواند به سرویس‌های پلتفرم دسترسی پیدا کند.چون دامنه‌ی سرویس اکانتس و پلتفرم‌ها متفاوت بود و مرورگر اجازه‌ی ذخیره‌ کردن کوکی برای دامنه‌ی دیگری را نمی‌دهد این کار توسط مکانیزم redirection صورت گرفت. هر پلتفرم باید یک API‌ فراهم می‌کرد تا کوکی میانی را که به صورت کوئری‌پارام ارسال می‌شد را در دامنه‌ی خودش ذخیره نماید تا پنل آن پلتفرم بتواند به آن دسترسی پیدا کند.جزئیات دیگری برای پیاده‌سازی این معماری چند دامنه‌ای وجود دارد که خارج از حوصله‌ی این مقاله است.سخن آخرطراحی مکانیزم SSO برای احراز هویت پلتفرم‌های یکتانت علاوه بر ایجاد تجربه‌ی کاربری بهتر، بازاریابی کم‌هزینه‌ای را برای پلتفرم‌های جدید یکتانت فراهم کرد. در طی این چهار سال بار‌ها این مکانیزم عوض شد ولی چیزی که ثابت ماند این تفکر است که کمینه چیزی را بسازیم که در شرایط فعلی کار می‌کند. چنین تفکری از پیچیدگی سیستم‌ها و هزینه‌ی بالای توسعه‌ی آن‌ها جلوگیری می‌کند.هر چند معماری میکروسرویس چالش‌های مهندسی بعضا زیادی برای مقیاس سرویس‌ها ایجاد می‌کند و نیازمند پروتکل‌های ارتباطی بین سرویس‌هاست ولی علاوه بر جذابیت‌های مهندسی مطمئنا سرمایه‌گذاری خوبی برای کاهش هزینه‌ها و افزایش قابل اعتماد بودن سرویس‌ها در بلند مدت است.اگر دوست دارید به تیم یکتانت بپیوندید به این لینک مراجعه کنید. یکتانت | Yektanet رضا عباسی Mon, 23 Nov 2020 13:23:36 +0330 https://virgool.io/yektanet/%D9%85%D8%B9%DB%8C%D8%A7%D8%B1%D9%87%D8%A7%DB%8C-%D8%A7%D9%86%D8%AA%D8%AE%D8%A7%D8%A8-%D8%B4%D8%BA%D9%84-ub6q8tinjsdi امروز که این مقاله رو آماده می کنم، تجربه کار یا حضور موقت توی چند شرکت رو داشتم و سیستم های مختلف کاری و خوبی ها و بدی های هر کدوم رو هر چند محدود تجربه کردم. کارآموزی رهنما کالج، سافتور دولوپمنت مامان پز، پروژه کارشناسیم با تپسی، ریسرچ دانشگاه کلگری و مهم تر از همه یکسالی که در یکتانت دیتاساینتیست بودم، ذهنیت تازه ای نسبت به کار بهم داده. ذهنیتی که بهم نشون میده تصمیماتی که در گذشته برای انتخاب شغل می گرفتم - اگر نگیم اشتباه - بسیار ناپخته و خام بودند. تصمیماتی که اگر بهتر گرفته می شد با زمان و انرژی کمتر، نتایج بهتری به همراه داشت.مطالب این مقاله، نمونه کامل تری هست از لایوی که اخیرا با کوئرا در مورد معیارهای انتخاب شغل برگزار شد.انتخاب تصمیم درست توی هر مرحله زندگی اهمیت بالایی داره. یک نفر با تصمیم اشتباه - هر چند با تلاش و کوشش بسیار - ممکن هست به نتایج بسیار ضعیف تری از یک تصمیم درست برسه. مطالب این مقاله جمع بندی هست از تمام عواملی که به نظر من یک برنامه نویس باید در تصمیم مهم انتخاب شغل در نظر داشته باشه. عواملی که سهل انگاری توی هر کدوم می تونه هزینه های پنهان زیادی در پی داشته باشه.آدم ها توی انتخاب شغل معمولا به پارامترهایی مثل حقوق، بیمه، امکانات شغلی - و به طور خاص دولوپرها به تکنولوژی ها و زبان ها - توجه می کنند. فضای جدید استارتاپی و مهیا شدن فرصت شغلی توی شرکت های جامعه تِکِ تهران که محصولاتشون رو توی زندگی روزمره استفاده می کنیم، مثل اسنپ و تپسی، اسنپفود و ریحون، بازار و دیوار و غیره، کار کردن توی این مجموعه ها رو بیش از پیش جذاب می کنه، مخصوصا وقتی معیارهای اولیه مثل حقوق هم در سطح بالایی قرار داشته باشه. اما من فکر می کنم که این جذابیت ها تنها بخش کوچکی از تصمیم گیری رو می تونند تشکیل بدند.بازیکنی تموم زندگیش رو به امید بازی کردن در باشگاه های بزرگ اروپا تمرین می کرد. جذابیت های یک باشگاه محبوب و پر افتخار و بازی در کنار بازیکنان بزرگ و مربی های کارکشته رویای هر شب اون بود. زمانی که ناباورانه قرارداد استخدام پنج ساله در باشگاه بارسلونا رو جلوی چشمش دید، بی درنگ اون رو امضا کرد. اون شب، اون به دستمزد زحمات چندین سالش رسیده بود.پنج سال بعد، بازیکن قصه ما به پنج سالی که گذشته بود، نگاه می کرد. زمانی که به بارسلونا ملحق شده بود، 24 سال سن داشت. حالا یک بازیکن 29 ساله که سال های پایانی فوتبال خودش رو سپری می کنه بود. در این سال ها به دلیل وجود بازیکن های قوی تر، او همیشه سکونشین بود. فرصت حضور در میدان، تاثیرگذاری در زمین و گل زدن رو از دست داده بود. چون مربی ها میدیدند اون در برد و باخت تیم تاثیری نداره، ازش حمایتی نمی کردند و ازش انتظاری نمی رفت. اون که خودش انگیزش رو از دست داده بود، ناراحت و افسرده زمان حرفه ای بازیگری رو از دست داده بود. حالا اون بود که به پنج سال پیش زمانی که زرق و برق باشگاه بارسلونا اجازه انتخاب دیگه ای بهش نمی داد، با دید افسوس نگاه می کرد.چون اطلاعات یک نفر نمی تونه کامل باشه این مقاله رو با کمک جمعی از دوستان و همکارانم نوشتم که ضامن جامعیتش هم از نظر پوزیشن های مختلف برنامه نویسی (بک اند، زیرساخت، دیتاساینس و فرانت) و هم از نظر سلیقه ها و افکار گوناگون باشه. مقاله به صورت بررسی یکی یکی و تیتروار معیارهای مختلف انتخاب شغل نوشته شده و امیدوارم که خوندنش براتون مفید باشه.تشکر ویژه از - جواد علی پناه، رضا کرمی، محمد گنجی، میثم باوفا، سیناحمیدیان، کامیاب زارع، حسن اسماعیلی، ثمین اعتماد مقدم و پیمان فخاریان - که به صورت آگاهانه یا غیرآگاهانه اندیشه ها و نظراتشون رو در اختیار من و این مقاله قرار دادند.حقوقمعمولا یکی از معیارهای متداول و مهم انتخاب شغل میزان حقوق و درآمد هست. مخصوصا توی این موقعیت و شرایط کشورمون، نمی تونیم نقش مهم پول رو توی زندگیمون نادیده بگیریم که احتمالا همه به اهمیت اون واقف هستند. اما پارامتر حقوق رو من از دوجنبه گسترده تر می کنم.اول، به غیر از حقوق، معیار شادابی محیط کار تاثیر مستقیم روی سطح رضایتممون از زندگی داره. ما بخش زیادی از زمانمون رو توی فضای کاری و با افکار و مسائل شغلمون سپری می کنیم که مثبت یا منفی بودنش می تونه نقش درآمد رو به عنوان تنها پارامتر زیر سوال ببره. به طور ساده، اگه به ما حقوق بیشتری بدن تا در یک اداره دولتی مشغول به کار بشیم که کارهای روزمره انجام می ده، مهارت خاصی نمیخواد و هویتی هم نداره، چند درصدمون اون رو قبول می کنیم؟ کار در کنار همکارهای خیلی بداخلاق، در جوار مدیر بداخلاق و در محیط سمی از مسائل انسانی رو با چه قدر حقوق بیشتر حاضریم قبول کنیم؟دوم، آفر حقوقی شرکت ها رو در لحظه استخدام ارزیابی می کنیم، در صورتی که یک کار با رشد و تجربه زیاد ما رو یک سال دیگه به حقوق و درآمد خیلی بهتری میرسونه ولی یک کار بدون پیشرفت ما رو در همون سطح حقوقی اول کار نگه می داره.به نظر من، غیر از حقوق سه تا دسته کلی اهمیت دارند. دسته اول: چه قدر رشد می کنیم. دسته دوم: چه قدر محیط شادابی داریم. دسته سوم: چه قدر توی جامعه تاثیرگذاریم.رشد و پیشرفترشد یعنی شش ماه دیگه - از نظر فنی و غیر فنی - چه برتری نسبت به الان داریم. اگه الان به عنوان کارآموز - که فیچرهای ساده می تونه به پروژه اضافه کنه - استخدام می شیم، شش ماه دیگه یه پروژه کامل رو می تونیم بالا بیاریم؟ توانایی گرفتن تصمیمات مهم خواهیم داشت؟ قدرت داریم ابزار جدید بیاریم تو شرکت؟ به مسیر توسعه تیم فنی می تونیم جهت بدیم؟ اگه الان خودمون نیروی جونیور هستیم شش ماه دیگه منتور یه نیروی جونیور دیگه میتونیم بشیم؟ شش ماه بعدش یک تیم مهندسی رو میتونیم لید کنیم؟خیلی مهمه که رشد و پیشرفت رو محدود به یادگرفتن چهار تا سینتکس و زبون ندونیم. این پیشرفتیه که تو هر شرکتی پیدا میشه. رشد و پیشرفت رو گسترده تر باید ارزیابی کنیم.توی حوزه هوش مصنوعی، ماشین لرنینگ یا دیتاساینس، اگه امروز به من یه الگوریتم خیلی مشخص در حد K-Nearest Neighbor میتونم تیون کنم، شش ماه دیگه یه مسئله ای که راه حل در حد دیپ لرنینگ می خواد از عهده من بر میاد؟ برای مسائلی که راه حل مشخص ندارند، می تونم ایده بزنم؟ با ابزارای پردازش دیتای سنگین تر بلدم کار کنم؟توی نرم افزار، اگه امروز کار با دیتابیس های ساده رو بهم می سپرن، شش ماه دیگه میتونم ترکیبی از دیتابیس ها و تکنولوژی ها رو برای پیاده سازی یه سیستم لارج اسکیل کنار هم بچینم؟ اگه امروز یه معماری سه لایه بلدم، شش ماه دیگه معماری های پیچیده تر استفاده می کنم؟بعد دیگه ای این پیشرفت توی مسائل انسانی هست. اگه الا یه دولوپر ساده ام، شش ماه دیگه مسئولیت هایی منتوری آدم های جوان، لیدرکردن تیم ها یا پوزیشن های مدیریتی چه قدر به من سپرده می شه؟سیستم ریکامندر یکتانت یه مثال خوبیه از این قضیه. سیستمی که با یه الگوریتم بیسیک در محیط آفلاین ژوپیتر نوت بوک شروع شد، یک ماه بعد توی محیط پروداکشن بود و برای یک سایت ریکامندیشن تولید می کرد، یک ماه بعد به چندتا وب سایت با لاجیک ها و پارامترهای متنوع تر اسکیل شد، یک ماه بعد از 20 ریکوئست بر ثانیه رفت رو 60 ریکوئست بر ثانیه و لایو بهش وب سایت ها می تونستن اضافه بشن، یک ماه بعد الگوریتمای مختلف بهش اضافه شدن تا در معیارها و دومین های مختلف خوب عمل کنه، یک ماه بعد مجیک های قوی تری رو شامل شد تا ریکامندیشن های خفن تری - مثل کاربرمحور - تولید کنه، یک ماه بعد نهایتا برای خودش یه سیستم پیچیده با سرورهای مختلف و کدهای گوناگون با قابلیت اسکیل 500 ریکوئست بر ثانیه داشته باشه. نکته این جاست که وقتی شما با این پروژه جلو میرید توانایی های شما هم با پروژه به سرعت اسکیل می شن.(زنگ تفریح)حالا برای من سواله که چطور می تونیم رشدمون توی یه مجموعه رو پیش بینی کنیم؟ یا به عبارتی چه عواملی توی مجموعه باعث رشد بیشتر ما می شه؟هسته فنی شرکتخیلی از شرکت هایی که اطرافمون می بینیم و میشناسیمشون و خیلی هم دوست داریم توشون کار کنیم، فنی نیستند. یعنی اولویت پیشرفت اون شرکت پلتفورم و زیرساخت فنی (سافتوری) نیست. مثلا کارخونه ایران خودرو رو در نظر بگیرید. این کارخونه برای فروش و درآمدزایی بیشتر مایله که ماشین هایی با حداقل کیفیت و قیمت تولید کنه که بازار رو دستش بگیره و سود بیشتری کسب کنه. توی مناسبات دولتی خیلی دوست داره که بتونه از رانت ها بهره مند بشه که این براش سود کلان بیاره. و نهایتا توی مارکتینگ با تبلیغات گسترده می تونه اعتماد مردم رو کسب کنه. حالا شما اگه به عنوان دولوپر توی ایران خودرو استخدام بشید، چه قدر برای اون شرکت مهمه که بتونید سایت با قابلیت اسکیل بالا یا با UX خفن دولوپ کنید؟ تقریبا هیچ.زمانی که برای انجام پروژه کارشناسیم توی تپسی بودم - درست یا غلط (من قضاوت نمی کنم) - ذهنیت همه این بود که تپسی خیلی تیم فنی قدرتمندتری نسبت به رقیبشون (اسنپ) داره. یک روز که با تپسی به خونه برمی گشتم، از راننده در مورد مقایسه تپسی و اسنپ پرسیدم. راننده گفت اسنپ خیلی اپلیکیشن بهتری داره. با تعجب پرسیدم چرا؟! گفت برای مثال خیلی مسافرهای نزدیک تری رو بهمون می ده و از این نظر درست تر کار می کنه.تیم فنی دولوپرهای باهوش تپسی ممکنه خیلی قوی عمل کرده باشه و الگوریتم های پیچیده ای برای اختصاص دادن نزدیک ترین راننده به مسافر دولوپ کرده باشه. اما در نظر بگیرید که اسنپ بهتر تبلیغات کرده باشه و راننده ها و مسافران بیشتری داشته باشه، پس یه الگوریتم رندوم یا باگی تر هم می تونه بهتر از الگوریتم تپسی خروجی داشته باشه. این جاست که به نظر می رسه چیزهای دیگه ای غیر از پلتفرم فنی اولویت های بالای شرکت رو تعیین می کنند. طبیعتا تعجبی نداره اگه شرکت سرمایه گذاری روی دولوپرهاش رو اولویت پایین تری از سرمایه گذاری رو احداث بیلبوردهای تبلیغاتی تو اتوبان ها کنه.خیلی سازمان هایی که اطرافمون می بینیم فنی نیستند ولی فکر می کنیم فنی اند. باید مراقب باشیم که جایی استخدام بشیم که کورش (core) فنی باشه و کار تخصصی سافتوری بکنه. در چنین شرکتی، دولوپرها مسئولیت دارن پروژه هارو لید کنن و به جای خفنی برسونند. ازشون انتظارات بالا میره و در نتیجه، سیستم های پیچیده تر با الگوریتم های خفن تر به عهده اون ها سپرده می شه. سرمایه گذاری های مالی و انسانی روشون انجام می شه که همه منجر به پیشرفت مستقیم یا غیر مستقیمشون می شه. از طرف دیگه، اگه مجموعه فنی نباشه، ممکنه یک دولوپر کلی زحمت بکشه، بهینه سازی کنه و سیستم های جدید بیاره بالا، در صورتی که اصلا برای مجموعه این مهم نیست و مسئولیت ها رو در حد پشتیبانی ساده از سیستم هاشون می بینند. در چنین فضاییه که مجموعه به جای افزایش حقوق دولوپرها و یا پشتیبانی های دیگه ای که باید ازشون بکنه، سرمایه کلانی خرج مسائل دیگه مثل مسائل اوپریشنال و اجرایی اجرایی می کنه. (زنگ تفریح)اسکیلاسکیل اون چیزیه که تو گوگل بالاست تو موتور جست و جو گر ملی خلیج فارس پایینه. اون چیزیه که توی علی بابا بالاست و توی سایت آژانس سر کوچه ما پایینه. ریکوئست پِر سکند، تعداد سرورها، سیستم ها و پروژه ها، حجم و تنوع دیتا از نمونه معیارهای اسکیل هستند.مثلا توی یکتانت حدود 500 سرور کار می کنند. حدود 20 هزار ریکوئست بر ثانیه میاد سمت اینا. حدود 50 تا سرویس مختلف هست که همه با هم به نوعی در ارتباطن. دیتابیس ها از بیسیک هایی مثل PostgreSQL و MongoDB شروع می شه تا نیاز خاص آدم ها به Redis و Elastic و Timescale می ره. حدود 130 میلیون دیوایس رو به عنوان کاربر داره که معادل تقریبا 55 میلیون انسانه. این اسکیل بالا محسوب می شه.چرا این اسکیل خوبه؟اگه سافت ور دولوپر باشیم، مشخصه وقتی یه سرور میاریم بالا که هزار ریکوئست در ثانیه قراره بگیره، حجم زیادی دیتا داخل دیتابیسش داره و باگ هاش حساس ترن، معماری های خفن تری یاد می گیریم، کار سنگین تری انجام می دیم و کلی استک و تکنولوژی میاد توی تجربمون.اگه دیتاساینتیست باشیم، اسکیل حجم و تنوع دیتا رو تعیین می کنه و به تبعش طیف متنوع مسائلی که در اختیارت قرار می ده. حجم سنگین تر دیتا پردازش ها رو سنگین تر می کنه و چالش اضافه کردن پروژه به پروداکشن رو آموزنده تر می کنه. برعکس، تو یه مجموعه کوچیک که مشکل استیبیلیتی داره، کی فرصت می کنه دنبال ماشین لرنینگ بیفته؟اگه زیرساختی، تنوع و گستردگی سرور ها برات چالش ایجاد می کنه. یه تیم سرورش مشکل رم داره، یکی هارد. هر کدوم نیازمندی ها چالش ها و زبان متفاوتی دارن. حملات به این سرورا بیشتر می شه. بیشتر میان پایین و خراب می شن. حساسیت دپلویمنت جدی تره و دست آخر فرصت اوردن ابزارها و متدهای مختلف مثل فست ریکاوری و استکایی مثل استک الستیک و گرافانا مهیا می شه.همه اینا خیلی مستقیم رو پیشرفت تاثیر می ذاره. نه فقط تو سافتور بلکه هر جای دیگه این موضوع صادقه. خودتون قضاوت کنید که مثلا مدیر یه شرکت هزار نفره بیشتر تجربه داره یا مدیر یه تیم پنج نفره؟وقتی دبیرستان بودیم، همه مسائل ساده بود و راه حل مشخصی داشت. وقتی اومدیم دانشگاه یهو خیلی پیچیده و سخت شد. اون موقع من حس کردم که خیلی پیشرفت کردم. حالا همین تفاوت بین پیچیدگی مسائل یک شرکت با اسکیل کوچیک و یک شرکت اسکیل بزرگ هست.استک و تکنولوژیتکنولوژی ها و ابزارهایی که تو یه شرکت باش کار می کنن، برای تجربه و پیشرفت مهمه. ممکنه یه شرکت مثلا کار بانکی بکنه ابزارشون جاوا باشه یکی دیگه کار استارتاپی بکنه پایتون باشه. توی انتخاب بین این ها سلیقه آدم ها بیشتر تعیین کندست. من خودم قبلا جاوایی بودم ولی بعدتر که دیتاساینتیست شدم طبعا بهترین ابزار برام پایتون بود. توی یکتانت کارایی دیتایی و بک اند با پایتون (اسپارک و جنگو) و فچ های سنگین با Node.js انجام می شه.غیر از زبان، تکنولوژی ها مثل ابزارها و دیتابیس ها معیار کامل تریه. ابزارهایی مثل گرافانا، استک الستیک، آپاچی اسپارک و … . هرچه قدر بیشتر از این ابزارها ببینیم، تجربمون و توانایی هامون بیشتر می شه و دید بهتری روی حوزه های دولوپمنت پیدا می کنیم. هم بیشتر خوش می گذره و هم برای آینده رزومه ایمون بهتره.اعتماد، آزادی عمل و اختیاروقتی اومدیم دانشگاه، بهمون گفتن که کتابی برای جواب سوالای شما نیست. گوگل کنید و سعی کنید گلیم خودتون رو از آب بیرون بکشید. یادمه اون موقع همه توی هیجان این کشف بودن و باهاش خیلی پیشرفت کردند. چون یادگرفته بودن سِلف استادی کنند، جواب سوالاشون رو پیدا کنند و مسئولیت حل مشکل رو خودشون به عهده بگیرند.من وقتی اومدم یکتانت، مسئولیت اجرای صفر تا صد ریکامندر سیستمی که وجود نداشت رو بهم دادند که همه مسئولیت ها و کارهاش رو دوش خودم بود. وقتی می بینی خودتی و خودت و مجبوری سیستمت رو رشد بدی و مشکلاتش رو حل کنی براش راه حل پیدا کنی، خیلی رشد می کنی. حل مشکل رو یاد می گیری. اعتماد به نفس پیدا می کنی و مستقل می شی. ممکنه خیلی جاها تصمیمات غلط و اشتباه بگیری ولی هم تصمیم اشتباه رو بهتر درک می کنی و عواقبلش رو می فهمی و هم در تصمیمات بعدی بهتر با ترس کمتر عملکرد معقول تری نشون می دی. در مقابل اگه اختیار ندن و بگه اَخه، دست نزن، جونیور طول می کشه تا راه بیفته و اینا، باعث می شه عقب و ناتوان بمونیم. اعتماد به نفسمونو از دست بدیم و وابسته بشیم. من بعد از چندماهی که این فضا رو تجربه کردم، خیلی سریع ترسهایی که همیشه داشتم برطرف شد تا نهایتا احساس استقلال پیدا کردم.خیلی مجموعه ها نیروهاشون رو به ربات هایی تبدیل می کنند که کپی کردن یک سری کد رو یاد میگیرند. به دولوپر می گن این فرهنگ کد زدن ما باید یه پارچه باشه تو فعلا سعی کن کدهای بقیه رو میمیک کنی. ایده نزن و تغییر هم نده. به نظر من، این جلوی یادگیری یک سری مهارت های اساسی که باعث استقلال می شه رو میگیره. ممکنه خیلی خوب مدل کد زدن اون شرکتو - که ممکنه از اساس غلط و بد باشه - رو یاد بگیریم. ولی وقتی بیرون میریم و یه جا دیگه بهمون می گن سیستم دیزاین کن، مهارت هاش رو یاد نگرفتیم. مدل برنامه نویسی، طراحی سیستم ها و ایده هایی که از جای قبلی یادگرفتیم ممکنه کلا به درد جای جدید نخورن. این ها همه جدای از اعتماد به نفس از دست رفتمونه. ممکنه در ظاهر حس خوب یادگرفتن یه سری چیزای سازمان قبلی - که ممکنه اون جا مثل قرآن مقدس باشه - رو بهمون بده ولی در عمل فایده ای برای آیندمون نداره. مثل حفظ کردن مطالب درسی دبیرستان می مونه که بعد از امتحان آخر سال محو می شه.سطح توانایی و باهوشی همکاراناین که چه قدر بین ادمای باهوش و توانمند هستی، مستقیما سطح تو رو تعیین می کنه. اگه دورت آدمایی باشن که مغزشون کار کنه باهوش و فرز باشن تو هم مثل اونا می شی. سریع در سطح اون ها قرار می گیری و سبک کاری و حرفه ای و مسیرشون رو یاد می گیری. مهم تر از همه این که از حرف زدن و حل مسئله باهاشون لذت می بری. در مقابل اگه بین آدم های ضعیف تر - یا مثلا بی انگیزه تر و بی هدف تر - از خودت قراربگیری، به سرعت انتظاراتت از خودت بیاد پایین و در سطح اون ها کاهش کیفیت می دی.فرایند منتورشیپ و آنبوردینگاین تجربه رو تو یکی از این شرکت ها داشتم که وقتی وارد شدم گفتن اون صندلی برو بشین کار کن. گفتم پروژه کو گفتن پروژه هم می خوای؟ برو فلن یکم پیپر بخون. بعد پیپر خوندم اومدن یه ایمیل و یه سرور دادن. گفتم خب هیچی نمی دونم یه کدی هم دادن گفتن اینم کد. یه جلسه هم توضیح. سه ماه بعد دست از پا دراز تر بدون هیچ دست آوردی خارج شدم.تو یکتانت که اومدم، ایمیل بهم ندادن ولی یه منتور گذاشتن که دقیق برام پروژه تعریف کنه. بهم فیدبک بده و همراهی کنه. اون اولش که تو در و دیوار می رفتم، راهنمایی کنه و ... . این یه فرایندی بود که شرکت روش سرمایه گذاری کامل می کرد. ینی مطالعه می کرد، ایده می زد. روش فیدبک می گرفت. داشتن چنین فرایند تمیز آنبوردینگ و منتورشیپی باعث می شه که شرایط بهتری داشته باشی و بهتر پیشرفت کنی. وقت تلف نکنی و درجا نزنی.من و سیناحمیدیانرشد خود مجموعهیکی از عواملی که بهش کمتر توجه می کنیم، رشد مجموعه ای هست که داخلش کار می کنیم. مثلا یک مجموعه ممکنه 100 نفر نیرو داشته باشه و بعد از یک سال این تعداد ثابت بمونه یا رشد اندکی داشته باشه. یه مجموعه دیگه ممکنه 20 نفر باشه و سال بعد همین موقع 60 نفر شده باشه. به حالت دوم می گن رشد و اسکیل شرکت.حالا چرا رشد شرکت مهمه؟ شما در نظر بگیرید مجموعه ای که از 20 نفر می ره 60 نفر توش کلی کار جدید به وجود میاد. مثلا به کلی تیم لید جدید نیاز داره. یا کارها تخصصی می شه و پوزیشن های تخصصی جدیدتر مثل SRE و Data Engineer خلق می شه. حالا این مجموعه به این سرعت نمی تونه این نیروها رو استخدام کنه در نتیجه کارهای بزرگ و جدیدش رو باید بده به همون نیروهای قبلیش. این یک موهبت و یک فضای فوق العاده برای دولوپرهاست که بتونن به سرعت رشد کنند. اهمیت این رشد رو من در یک سال اخیر خیلی عمیق درک کردم. وقتی که با بزرگ شدن شرکت و تیم ها، کارها تخصصی تر می شد و فرایندها بهتر شکل می گرف. بی تردید رشد شرکت با رشد شما یک کوریلیشن خیلی مستقیم داره و از مهم ترین عامل هاست که پیشرفت شما رو تضمین می کنه.در مقابل اگه رشد نداشته باشه، میشه مثل یک شرکت که یک دوستی رفته بود و از فضای ارتقای شغلی می پرسید. بهش گفتند که شرکت پره و ارتقای شغلی نداریم، مگه این که یک نفر از بالادستی ها فوت کنه و تو جاش رو بگیری. پرسید چه قدر طول می کشه؟ گفتند چون همه جوونند حداقل 50 سال.شادابی محیط کارمنظور از شادابی اینه که چقدر از رفتن و حضور در محیط کارت خوشحالی. معمولا شادابی محل کار با امکاناتی مثل اتاق بازی یا جشن های دوره ای سنجیده می شه. البته این ها خیلی مهم اند ولی به نظر من پارامترهای دیگه ای تاثیر گذاری عمیق تری دارند. یکیش اینه که روابط آدم ها (همکارها و مدیر) چه قدر دوستانست…روابط همکارهاروابط بین همکارها بخش خوبی از ارتباطات ما رو شکل می ده. اگه همکارای حامی، خوش برخورد و خوش اخلاق داشته باشیم حس خوبی می گیریم. در مقابل اگه آدم های تندخو، مغرور، ایرادگیر، خودخواه یا مثلا خیلی درونگرا کنارمون ببینیم، اذیتمون می کنه. اگه همکارها بدموقع مزاحممون بشن یا انتظارات بالایی ازمون داشته باشند، روابط کاریمون به هم می خوره. اگه دنبال زیرآب زدن باشند، مجبوریم کارمونو ول کنیم و به جاش دنبال راه حل برای این مشکلات باشیم.روابط بین مدیر و شمارابطه با مدیر هم از نقاط حساس و حیاتیه. خیلی مهمه که مدیرها نگاه بالا به پایین نداشته باشن. رابطه دوستانه از رابطه کاری جدا باشه و نقش و جایگاه مدیریتی به شکل اخمو بودن یا جواب سلام ندادن در نیاد. نباید مدیر روی کارهاتون خط کش بذاره یا اگر تازه کارید نباید ضعف ها و اشتباهاتتون رو به شکل ناراحت کننده تو سرتون بزنه.تو یکی از شرکتایی که رفتم مصاحبه دیدم یه آقایی خیلی اخمو و ناراحت انگار که به تازگی ورشکست شده داشت می چرخید. از بچه ها پرسیدم این آقاهه چشه؟ گفتن مدیر تیم فنیمونه و می خواد جدی باشه. به نظرم، رابطه مدیریتی می تونه توی ریپورت گرفتن از انجام تسک ها باشه، اما نباید به شکل جواب سلام ندادن در بیاد. نباید حالت اخم به خودش بگیره. این رفتار می تونه خیلی آزارتون بده و انگیزتون رو خورد کنه.توی یکتانت تیم لید (به صورت رسمی) نقش کاپیتان (و نه رئیس) رو بازی می کرد و هیچ وقت حس بالا به پایین نداشتیم. رابطه دوستانه از رابطه کاری جدا بود و مسائل کاری تو روابط فردی تاثیر نداشت. مدیر یکتانت رابطه مدیریتی مستقیم داشت ولی صمیمیت توی برنامه های بیرون و تفریحی حس می شد طوری که اصلا احساس این رو نداشتیم که با مدیر بیرونیم. انگار که یه جمع دوستانه ایم. این جلوگیری می کرد از خیلی مشکلاتی که آدم ها توی محل کارشون دارند (و منم خیلی زیاد در یکی از شرکت های قبلی حس کردم) به خاطر این که مدیران رفتار مناسبی ندارند.به طور کلی مهمه که مدیر نقش لیدر و رهبر رو بازی کنه، شمارو حمایت کنه و کمکتون کنه که پیشرفت کنید. اگه شکی دارید توی این که یه لیدر خوب چه انگیزه هایی می تونه بهتون بده به آدم هایی نگاه کنید که تحت تاثیر لیدرهایی - که حتی ارتباط نزدیک باهاشون نداشتن - خودشونو به جنگ و کام مرگ فرستادن! پس وجود یه لیدر نزدیکتون و تو محیط کارتون همراستا با پیشرفتتون خیلی می تونه خوشحال نگهتون داره.محیط سمیتو کشور ما خیلی پتانسیل مافیا بالاست. تو هر جایی بریم یه سری گَنگ راه انداختن. هنر، فوتبال، سیاست یا هر جای دیگه، گروه ها منابع رو بر می دارن، بین خودشون تقسیم می کنن، مجموعه رو نابود می کنن و با دست آوردها از منجلابی که خودشون درست کردن فرار می کنن. من به چنین فضایی می گم فضای سمی. فضایی که توی دانشگاه - از داخل ساختار اداری و آموزشی تا داخل تشکل ها - باهاش آشنا شدم و عمیق اثر مخربش رو حس کردم. باید ببینید توی مجموعه ای که می خواهید کار بکنید این فضای سمی چه قدر شایعه. کارکردن تو محیط سمی نه تنها حس خوب رو ازتون میگیره بلکه تمرکزتون روی کار و پیشرفت رو هم تحت تاثیر قرار میره.مراسم خداحافظی با یکی از قدیمی ها، مروارید بخشیپروموشن و کار به اندازهخیلی مهمه که جایی که کار می کنید، سیستم و مکانیزم درست درمونی برای ارزیابی تلاش هاتون و واکنش نشون دادن به اون ها از جهت پروموشن های مالی یا شغلی داشته باشه. به زبان ساده اگه انرژی بیشتری می زارید بهتون حقوق و مسئولیت های بیشتری بده تا انگیزتون رو بلند مدت حفظ کنه و کار رو لذت بخش نگه داره. سیستم حقوقی شرکت باید مشخص باشه و معیار حقوق، شایستگی ها و توانایی های فرد باشه. شرکت به کسی باج نده و از اون ور حق کسی رو چون صداش کمتره یا چون سربه زیر تره سرکوب نکنه. به علاوه، حفظ حریم شخصی هم اهمیت بالایی داره. یعنی اگر زمانی دغدغه شخصی دارید یا مثلا آخر هفته رو مسافرت هستید، مجموعه با فهمیدن این موضوع مراقب اذیت نکردنتون باشه.شنیده شدن اعتراضات/ حرف ها / فیدبکهایه سری شرکت ها هستن مشکل دارن و هیچ وقت تغییر نمی کنند. بالا برید پایین بیاید یک ساله یه مشکل توی روابط انسانی یا تیم فنی هست و هیچ تغییری نمی کنن. مهمه که شرکتتون مکانیزم مشخصی برای شنیده شدن اعتراضات و فیدبک ها و اقدامات متناسب برای بهبود اوضاع داشته باشه. بهتر از اون اینه که خود شرکت فعالانه دنبال حل مشکلات باشه و این رو جز اولویت های بالاش دسته بندی بکنه.تیم منابع انسانیتیم منابع انسانی خیلی مهمه. اونه که این روابط انسانی رو می چینه و تعیین می کنه. اونه که فضای شرکتو کنترل می کنه. همون تیم منابع انسانی اگه توزرد از آب در بیاد به جا این که شرایطو بهتر بکنه بدتر می کنه.از کجا بفهمیم منابع انسانی چه وضعی داره؟ سالی که نکوست از بهارش پیداست. از همون روال مصاحبه.من وقتی می خواستم بیام یکتانت اولین چیزی که به چشمم اومد ارتباط سریع و گرم تیم منابع انسانی و روال راحت مصاحبه بود. روالی که توش فرم پرکردن اضافی نداشت و به سرعت از وضعیت مصاحبه و نتیجش مطلع می شدم. مثلا وقتی یه نفر از مصاحبه یکتانت ریجکت میشه، اگه درخواست بده بهش فیدبک می دن. این نشون دهنده انرژی و وقتیه که روی پروسه های انسانی میزارن. نشونه تیم منابع انسانی کامل و آماده. و در برعکس اگه تاخیر زیاد هست و می گن سرشون شلوغه و نمی رسن احتمالا بعدا که برید تو شرکت هم سرشون شلوغه و باز هم به مسائل شما نمی رسند.حفظ روابط انسانی - تمام عوامل پیشین اعم از نگه داشتن فرهنگ مثبت بین آدم ها و جلوگیری از گسترش فساد - نیاز به اراده و عملکرد بالادستی داره. توی فضای ایران نمی شه انتظار داشت که یک مجموعه به حال خودش رها بشه و آدم ها مشغول خرابکاری نشن. وقتی مصاحبه سوم یکتانت اومدم از مدیر شرکت پرسیدم که آدم هایی که توی شرکت شما استخدام می شن سطحشون از نظر فنی از من بالاتره یا پایین تر؟ گفت هم بالاتر از تو داشتیم رد شده، هم پایین تر از تو که استخدام شده. گفتم چرا؟ گفت چون ۵۰ درصد معیار انتخابمون فنیه و ۵۰ درصد فرهنگی.این که شرکتی موقع استخدام به اخلاقیات و فرهنگ آدم ها توجه بکنه و مراقب باشه مغرورها و بدخلق هارو استخدام نکنه (حتی به قیمت از دست دادن نیروی خوب) باعث می شه که فرهنگ اون سازمان به یه فرهنگ پالایش شده و صمیمی تبدیل بشه. فرهنگی که عاری از فساد باشه و داخلش همواره آدم های خوب و همراه ببینی. وقتی اولین بار داشتم مصاحبه تلفنی می رفتم، تیم منابع انسانی یک برگه دستورالعمل طور بهم دادند که یک موردش خیلی توجهم رو جلب کرد. "مراقب باشید مصاحبه شونده حس بازجویی پیدا نکند." وقتی مجموعتون این طوری قوانین و رویکردها رو برنامه ریزی کنه، شما هم یاد میگیرید که مراقب رفتارتون باشید. در مقابل اگر نکنه، به سرعت با فضایی مواجه می شیم که یک سری از اتاق های مصاحبه در شرکت های جامعه تک تهران به اتاق ترس و بازجویی برای مصاحبه شونده تبدیل می شه و وقتی این فضا توی مصاحبه باشه طبیعتا توی مناسبات داخل شرکتی هم خواهد بود.تاثیرگذاری تو جامعه و برندینگ سازمانیتاثیر توی جامعه و برندینگ دو تا پارامترین که یکم سلیقه ای هستند. یعنی نمی شه گفت مهمه یا نه ولی برای خیلیا خیلی مهمه. خیلی هامون دوست داریم جایی کار کنیم که تو جامعه تاثیرگذاره. خیلی ها جذب کمپانی هایی شدن که رو ویروس کرونا کار می کنن. به خاطر این که حس می کنن می تونن مشکلی رو حل کنند که مدت هاست دنیا رو درگیر خودش کرده. خیلی ها آرزوی کار توی گوگل رو دارند، به خاطر این که توی دنیا شناخته شده هست. تاثیرگذاریتاثیری گذاری برای خیلی ها از طریق پارامتر تعداد یوزر سنجیده می شه. یعنی اگه اپ فلان شرکت فروش کالا ۱۰ میلیون یوزر داره، حس تاثیر گذاری بالایی بهشون می ده چون تغییراتشون رو ۱۰ میلیون نفر تاثیر می ذاره. این حس خوب می ده که محصولت رو خیلی ها استفاده کنند ولی با تاثیرگذاری فرقی می کنه چون شما یه سرویس رو ممکنه به ۱۰ میلیون نفر ارائه بدید که تاثیر شگرفی توی جامعه، سطح زندگی یا اقتصاد نداشته باشه. من تاثیر گذاری رو کجا می بینم؟ مثلا این که توی همون اپ تاکسیرانی، سیستمی دیزاین کنید که موجب کاهش ترافیک و به طبعش آلودگی هوا بشه. باید دید که چه قدر توی رسالت ها و اهداف مجموعتون تاثیرگذاری مثبت هست. برند سازمانیگوگل بِرَنده و برای خیلی ها جذابه که داخل گوگل کار کنن. این هم پارامتر شخصیه که چه قدر برند براتون مهم باشه ولی مراقب باشید که برندها یک سری ملاحظات دارند. اول این که برند بیزینسی با برند فنی فرق می کنه. مثلا برند بزرگ ترین آژانس مسافرتی آنلاین (علی بابا یا فلایتیو)، یک برند بیزینسیه در صورتی که برند بزرگ ترین اسکیل، یا سطح فنی دولوپرها یک برند فنیه. خیلی از شرکت هایی که ماها جذبش می شیم برند های بیزینسی دارند. دوم این که یک سری شرکت ها مثل یکتانت b2b یعنی business to business هستند و مشتری هاشون به جای مردم بیزینس هاند. در نتیجه برندشون رو توی همون دنیای بیزینس های مخاطبشون درست کردند و طبیعتا هزینه ای برای برندسازی بین عموم مردم نمی کنند. باید ببینید برند بین مردم براتون مهمه یا این که توی دنیای مخاطب خودش هم برند باشه براتون کافیه.نهایتا باید روی برند یک بازنگری بکنید که کدوم بخش از برندها و چه قدر براتون مهمند.نمایش و پروپاگانداتاریخ گذشته - نسل کشی ها و جنایات جنگی - به ما نشون می ده که پروپاگاندا و تبلیغات چه قدر می تونه ذهنیت آدم ها رو دستکاری کنه و دنیا رو جور دیگری نشون بده. اگه پروپاگاندا زمانی در کنترل دولت ها و کشورها بود، حالا به مجموعه ها و شرکت ها هم سرایت کرده. اگه زمانی مدال افتخار، آدم ها رو به فدا کردن زندگیشون مجاب می کرد، امروز برچسب اکسپرت (expert) یا (senior) می تونه دولوپرها رو به فدا کردن زندگی حرفه ایشون سوق بده.اهدای مدال به بچه ها توسط هیتلر در روز پایانی جنگ (فیلم Downfall)برچسب زدن به افراد برای ایجاد حس کاذب یکی از ابزارهای ایجاد حس پیشرفت کاذبه. افرادی در شرکت های تِکِ تهران مرتبا پروموشن شغلی می گیرند که پیشرفتی فنی یا غیر فنی چندانی نمی کنند یا پشرفتشون از هوش و توانایی هاشون خیلی کمتره. این برچسب ها (مثل Senior Software Developer) اعتبار و مقبولیت میاره اما توانایی نمیاره. این برچسب ها تا وقتی اعتبار داره که داخل اون مجموعه باشید و وقتی خارج بشید دیگه کسی ارزشی براش قائل نیست. تنها معیار ارزشمند توانایی شماست. افراد زیادی اومدن مصاحبه که برچسب های رنگارنگ از شرکت های قبلیشون گرفته بودند ولی توی ارزیابی ها عملکرد خوبی نداشتند. صادقانه بگم اون قدر این برچسب ها زیاد شدن که دیگه توی مصاحبه ها بهشون توجهی نمی شه.یکی دیگه از ابزارهای تبلیغ، شعارنویسی های در و دیواره. شرکتی که هیچ مسئولیتی به افرادش نمی ده، دیوارهاش رو با شعار اعتماد و مسئولیت پر کرده و توی شبکه های اجتماعی فیلم های دولوپرهاش رو پخش می کنه که میگن ما از بودن ای جا خیلیییی خوشحالیم.اولویت های شخصیطبیعتا کنار همه این عوامل پارامترهای شخصی قرار می گیره. مثلا اگر دانشجو هستید، انعطاف ساعت کاری مهمه. برای بعضی ها مثل من نزدیکی محیط کار به محل زندگی خیلی مهمه و برای بعضی ها تفاوتی نمی کنه. مسائل جزئی مثل غذا می تونه خیلی تاثیرگذار باشه. مثلا اگه غذا به عهده خودتون باشه ممکه وقت زیادی رو در روز صرف سفارش غذا بکنید و این دغدغه اضافی براتون ایجاد کنه. فرهنگ مذهبی سازمان، داشتن امکانات جانبی مثل بیمه کیفیت محیط کاری از جمله عواملی شخصی هست که به ذهن من میرسه.مهمه که معیارهای شخصیتون هم جداگانه مورد بررسی قرار بدید. شاید جایی که برای من عالیه، برای شما گزینه مناسبی نباشه.(زنگ تفریح)پروسه واقعی انتخاب شغل بین گزینه های موجودسخن آخرشرکت هایی که اوضاع خوبی دارند، نیروهاشون مایلند اون جا بمونند. شرکت هایی که اوضاع خوبی ندارند، گاهی اوقات به زور و تهدید نیروها رو حفظ می کنن. خیلی ها سفته می گیرند، خیلیا تعهدات اخلاقی کاذب ایجاد می کنند و خیلی ها هم خروج کننده ها رو بدنام می کنند.سعی کنید تعهدات اخلاقی کاذب رو کنار بزارید و به روابط حرفه ای و تعهدات واقعی فکر کنید. اگه سازمان شما توی جلب رضایتتون ناموفقه یک بار دیگه همه پارامترها رو در نظربگیرید. تصمیم نهاییتون رو به موقع بگیرید چون سن جوانی محدوده و ما فقط یک بار دوره جوانیمون رو می گذرونیم.این نوشته در بلاگ شخصی من و بلاگ مهندسی یکتانت منتشر می شه. اگه خوشتون اومد این دو صفحه رو دنبال کنید تا مطالب بعدی رو هم از دست ندید. لایک و شیر هم فراموش نشه;)اگه دوست داشتید برای یکتانت رزومه بفرستید، از طریق صفحه فرصت های شغلی می تونید اقدام کنید. میتونید بلاگ مهندسی و صفحه اینستاگرام تیم مهندسی رو هم برای اطلاعات بیشتر بررسی کنید.خوشحال می شم کامنت بگذارید و فیدبک ها و نظراتتون رو در مورد معیارهای مقاله بگید. اگه مطلب به نظرتون مفیده با دوستانتون به اشتراک بگذارید. اگه کاری داشتید از طریق لینکدین من، می تونید با من ارتباط برقرار کنید. یکتانت | Yektanet آرمین زیرک | Armin Zirak Sun, 15 Nov 2020 17:59:58 +0330 https://virgool.io/yektanet/%D9%85%D8%A7-%D8%AA%D9%88-%DB%8C%DA%A9%D8%AA%D8%A7%D9%86%D8%AA-%DA%86%D8%AC%D9%88%D8%B1%DB%8C-%D8%B1%D8%B4%D8%AF-%D9%85%DB%8C-%DA%A9%D9%86%DB%8C%D9%85-dk37dg0i0suf داستان مندو سال پیش بود که به عشق HR اومدم یکتانت مصاحبه، تجربه‌ مرتبطی نداشتم و تو دانشگاهم که فوت‌های کوزه‌گری درس نمیدن!خلاصه که روز اول نشستم جلوی پیمان (VP of Engineering) و علیرضا (CEO)، برام از معیار هاشون تو جذب و استخدام گفتن. منم تند و تند نت برمیداشتم، هم فنی جذب داشتیم (Software Engineer, Data Scientist, Front-end Developer) هم بیزینسی (Campaign Manager). مهارت‌هایی که نیاز بود برای هر گروه متفاوت بود. Node.js, Python, Django, Digital Marketing و … . خیلی مشتاق بودم برای این تجربه و پر از انرژی! با سرچ گوگل شروع کردم. رزومه خوب چه جور رزومه‌ایه؟ تو مصاحبه چه سوالاتی بپرسیم. از هفته بعدشم مصاحبه رفتنام شروع شد. واقعا کارم چالشی بود. یه لحظه‌هایی که ناهماهنگی اتفاق می‌افتاد واقعا استرس زیادی می‌کشیدم. یه جاهایی خرابکاری کردم و با کمک بقیه درستشون کردم، بعضیارو ماه‌ها طول کشید درست کنم. مثلا یبار تصمیم گرفتم به همه کسایی که ریجکت میشن از مصاحبه‌های عمومی یا تخصصی، فیدبک بدم و توضیح بدم دلیل رو. نتیجه خیلی بد بود. لحن و بیان تو فیدبک دادن خیلی مهمه و متن من حس بدی منتقل کرده بود، درحالیکه نیت من این نبود. بعدتر ها دیگه به همه فیدبک نمیدادم و اگه کسی فیدبک می‌خواست متن جواب رو با بقیه چک می‌کردم.یه روزایی هم واقعا حس خوب داشتم و به خروجی کارم افتخار می‌کردم. از خروجی‌های خوب چالش‌هایی که تجربه کردم می‌تونم به جذب‌های موفقم اشاره کنم. یادمه تو یکی از مقاله‌هایی HBR خوندم که خانوما معمولا 40 دقیقه اول مصاحبه توانمندی‌هاشون رو خوب نشون نمیدن. نازنین (یکی از بهترین و کار‌راه‌بنداز‌ترین و خوش‌برخوردترین نیروهای شرکت?) که اومد مصاحبه یکم با غریبه‌ها خجالتی بود، ولی بعد یه ساعت یخ‌ش آب میشد و نشون میداد چقدر آدم مسئولیت‌پذیر و دغدغه‌مندیه. شیش ماه بعد از استخدام نازنین مدام بچه‌ها میومدن پیش من و از نازنین تعریف می‌کردن و من غرق لذت می‌شدم. هنوزم هرکی از نازنین تعریف کنه من خوشحال میشم.نازنین‌مون در کنار علیرضا عبدالهیان (علیرضا زیاد داریم)از نتیجه‌های خوب چالش‌هایی که داشتم جذب همکارای خوب تو یکتانته. اولین کسی که تو بخش مهندسی تونستم جذب کنم علی بود. علی با بازنویسی Vue.js پنل‌های یکتانت شروع کرد و الان تیم‌لید پنل‌های یکتانت هم هست. یادمه تو یکی از مصاحبه‌ها یکی علی رو معرفی کرد و گفت برنامه‌نویس خفنیه. به علی زنگ زدم و پیشنهاد همکاری دادم و علی رد کرد. دو ماه بعد کوئرا یه مسابقه فرانت برگزار کرد و من رزومه سه نفر اولشون رو خریدم. نفر اول علی بود! دوباره بهش زنگ زدم و صحبت کردیم اینبار قبول کرد که بیاد مصاحبه ✌️. با اینکه قبل از یکتانت جایی کار نکرده بود اما تخصص خوبی داشت و خیلی زود همکاری رو شروع کردیم. هفته اول پیمان منو صدا کرد و بهم گفت علی خیلیییی خوبهههه ?. هنوزم وقتایی که پیمان از علی تعریف می‌کنه کیف میکنم ?.نمیدونستم آیا درست تحلیل می‌کنم آدم‌ها رو یا نه؟ نکنه اشتباهی یکی رو ریجکت کنم؟ باز رو آوردم به سرچ کردن و با Recruitment Metrics آشنا شدم. همزمان با سرچ‌هام با اینکه قصد جابه جایی نداشتم به پیشنهاد علیرضا شروع کردم مصاحبه شرکت‌های دیگه رو رفتن ?. از مصاحبه‌ها که برمی‌گشتم شروع می‌کردم تحلیل کردن سوالایی که ازم پرسیده شده. فوق‌العاده تجربه‌های آموزنده‌ای بود علاوه بر اینکه مهارت‌های مصاحبه‌ام بهتر شد، با آدم‌های خفنی آشنا شدم.اما این موقعیت چه مزیتی برای من داشت؟من باید هم دولوپر هدهانت میکردم هم مدیر هم کارشناس هم خدماتی، تو روال عادی اگه قرار بود رشد کنم احتمالا 5 سالی طول می‌کشید که همه این تجربه‌ها رو کسب کنم و تو هر کدوم یه چیزایی یاد بگیرم. اما تو یکتانت همه رو تجربه کردم. این رشد خیلی سریع بود برام. البته الان علامه دهر نیستم، اما خیلی چیزها رو زودتر و سریع‌تر یاد گرفتم. یه سال گذشت و به خودم اومدم دیدم یکتانت از 15 نفر شده 50 نفر!سراسر حس خوبم از مشارکت داشتن تو ساخت یکتانت امروز با 155 تا همکار دوس داشتنی ...داستان سیناسینا همون پسر نایس و مهربون و دوس داشتنیه، همیشه هم آرومه. تا حالا عصبانیتش رو ندیدم. سینا نقطه عطفش تو یکتانت رو مسئولیت نجوا میدونه. پیمان بهش گفت این محصول رو باید تو دو هفته بالا ببری و بعد این مدت این تعداد subscriber داشته باشه. سینا به گفته خودش اون زمانی چیزی از محصول و لید کردن نمیدونست و حتی تو بک‌اند هم خیلی عمیق نبود. چالش بزرگی بود براش. باید از علی و امیر و علیرضا کمک می‌گرفت. اینا همه تجربه‌های جدیدی بودن. قرار بود همکاری آدما رو در قالب یه محصول دور هم جمع کنه. اون اوایل سینا تیکت‌های مشتری‌ها رو هم خودش جواب میداد. یه روزایی چالش‌ها از جنس تصمیم‌گیری بود؛ سینا ساعت 12 شب که نجوا داون شده باید تصمیم می‌گرفت با کیفیت خیلی بد موقتا راهش بندازه که تا 5 صب بره بالا و بعدا اساسی درستش کنه یا داون بمونه و دو سه روز روش کار کنه تا یه چیزی بیاد بالا که دیگه این اتفاق براش نیفته؟ اون مدت یادمه خیلی شبا پیمان و سینا تا صب شرکت میموندن. پیمان خیلی به خروجی اهمیت میده. سینا یه وقت‌های از سمت پیمان فشار رو حس می‌کرد یه وقت‌هایی هم حمایت و مشورت. تو چالش‌های فنی سینا شروع می‌کرد به سرچ اما مهارت‌‌های نرم چیزیه که فقط با تجربه بدست میاد. این تجربه چیزای زیادی به سینا یاد داد و تجربه‌های بعد از اون. سرور core یکتانت، لید کردن تیم core، لید کردن دو تا تیم با هم، و الان هم لید کردن چنتا تیم و تیم‌لید‌هاشون. سینا الان دیگه کد نمیزنه و همه چیز براش ناشناخته و جذاب و چالشیه. خیلی جاها از پیمان و بقیه مشورت می‌گیره، تجربیاتی که برا اونا جواب داده. اما لزوما برای سینا هم جواب نمیده. جواب مسئله‌اش رو خود سینا باید پیدا کنه. اونم با تجربه …سینا تو سه چهار سال رسید به اینجا که داره مدیریت 4، 5 تا تیم همزمان رو یاد می‌گیره و داستان سینا هنوز ادامه داره ...سیناها و آرمیناین‌ها دو نمونه از تجربیات ما تو یکتانت بود. مثال‌های مشابه زیادی از تجربه‌های خودم و بقیه همکارام تو یکتانت دارم. یه روزی داشتم بین مقالات مجله کسب و کار هاروارد (HBR) میچرخیدم که یه مقاله توجهم رو به خودش جلب کرد.استرچ اساینمنت (Stretch Assignment)خیلی از تیم‌لیدهای Tech یکتانت تجربه اول تیم‌لیدیشون یکتانت هستش. استرچ اساینمنت یه راه خیلی خوب برای ساختن مدیرای آینده هستش. به این مسئولیت‌هایی که باعث میشن کِش بیای و خیلی از همکارای من تجربه‌اش کردن میگن استرچ اساینمنت. (واقعا نتونستم معادل فارسی براش پیدا کنم که حق مطلب رو ادا کنه ?). استرچ اساینمنت یه مسئولیتی هستش که فرد دانش و تجربه لازم رو نداره و چالش‌های زیادی رو تجربه میکنه که اونو از ناحیه امنش خارج میکنه. در نهایت هم موجب رشد و توسعه فرد میشه.یه جایی خوندم که آمریکا تو صنایع نظامیش از استرچ اساینمنت برای رشد و توسعه استفاده میکنه (چرا هر علم جدیدی اول به جنگ و صنایع نظامی خدمت میکنه؟ ?).حالا چرا استرچ اساینمنت؟استرچ اساینمنت برام چیز چذابی بود و شروع کردم به سرچ کردن، حتی در موردش با 10 -12 نفر از مدیرای منابع انسانی استارتاپای ایرانی مشورت کردم و از تجربیات مشابه‌شون پرسیدم. چیزی که من بهش رسیدم اینه:استرچ اساینمنت باعث میشه آدما تو ماکزیمم عملکردشون قرار بگیرن (همه با نمودار رابطه استرس و عملکرد آشنا هستن دیگه)استرچ اساینمنت انگیزه و تعهد به سازمان رو خیلی بالا می‌بره (باعث میشه من عاشق یکتانت باشم با همه خوب و بدش ?)باعث میشه سریعتر و بیشتر رشد کنمحد بهینه واسه هر کسی متفاوته و خیلی مهمه قبل از تعریف همچین مسئولیت‌هایی مدیری که داره مسئولیت رو تعریف می‌کنه شرایط فرد و استعداد‌هاش رو خوب بشناسهیکی از ابزارهای خفن و کاربردی برای تقویت مهارت‌ها نرمه مثلا جناب مک‌کلی پیشنهاد میده واسه هر مهارتی چه استرچ اساینمنتی رو تعریف کنیم (مثلا گرفتن مشکلات از دیگران: اصلاح اشتباهاتی که دیگران ایجاد کردن یا قبل از قبول استرچ اساینمنت وجود داشتن، حل مسئله / تصمیم‌گیری، پشتکار و استقامت، مدیریت تغییر رو بهبود میده. مشکل با کارکنان: همکاری با همکارایی که تجربه یا شایستگی کافی ندارن یا در برابر تغییر مقاوم‌ هستن هم مواجهه با مشکلات افراد، مدیریت تعارض، متعادل‌سازی سرسختی و همدلی رو بهبود میده. شرط‌بندی سنگین: مدیریت کارهای با مهلت خیلی کم، دارای فشار از بالا، شدیداً در معرض دید یا مسئولیت تصمیم‌های حساس هم قاطعیت، مدیریت بالادست (ساده‌تر کردن کار مدیر بالاسری)، مدیریت استرس رو بهتر می‌کنه و ...)مگه داریم؟ مگه میشه یه چیزی انقدر خوب باشه؟قطعا نه! یه ملاحظاتی هست که باید حواسمون بهشون باشه. سه تا چیز خیلی مهمه! خود فرد، جایی که توش کار می‌کنه و مدیرش. مثلا مهمه که فرد مورد نظر پتانسیل‌های لازم رو داشته باشه. هر کسی یه استعدادی داره، یکی نقاش خوبیه، یکی دِوِلوپر خوبیه، یکی تو فضای منظم عالی کار میکنه، یکی تو فضای مبهم …استرچ اساینمنت برای کسی مناسبه که سرش درد میکنه واسه چالش (خودآزاری داره مث من! ?)، تو فضای ابهام خوب میتونه کار کنه، اعتماد بنفسش در سطح خوبی باشه، استرس رو خوب بتونه مدیریت کنه و …یکتانت ماتو هر سازمانی راحت نیس استرچ اساینمنت تعریف کردن، جایی میشه از استرچ اساینمنت برای رشد و توسعه استفاده کرد که فرهنگ رشد داشته باشه. فرهنگ رشد یعنی‌چی؟ یعنی یکتانت! ? جایی که ایده‌های جدیدت رو میدی و تو کار استفاده می‌کنی و ترس از اشتباه مانع خلاقیت نمیشه! جاییکه وقتی اشتباه کنی ممکنه مدیرت برای اشتباهات کوچیک بگه فدای سرت، برای اشتباهات بزرگ سرزنش‌ات کنه و یاد بگیری و رد شی اما حلق آویز نشی ?. مثلا تا حالا ندیدم تو یکتانت کسی برای اشتباهات بزرگ اخراج بشه، همواره فرصت‌های دوباره داده می‌شه.از نقش مدیر هم دیگه نگم براتون. خیلی مهمه! مهم‌ترین کاری که مدیر انجام میده دادن حس اختیار و آزادی عمل هستش (تو این مورد علیرضا خیلی آزادی میده). اون اوایل که راجع به استرچ اساینمنت نمیدونستم با خودم می‌گفتم علیرضا چرا اینجوریه؟ چرا هیچوقت دعوام نمیکنه؟ یا چرا اجازه میده هرکاری رو خودم پیش ببرم؟! اما الان میدونم که اینکارش نقش پررنگی تو رشد من داشته و باعث شد ایده‌های جدید و تازه‌ای رو تو کار بیارم که خروجی‌های خفنی داشت.یکی دیگه از نقش‌های مدیر فیدبک دادن مستمر هستش که باعث میشه تو مسیر رشد و این استرچ اساینمنت راه رو صاف و درست بریم. ما اینو راستش خیلی نداریم، فضا جدیده برامون و کسی نمیدونه کار درست چیه. اما به جاش میشه خروجی مورد انتظار رو تعریف کرد که به بیراهه نریم. تو این مورد هم علیرضا میگه خروجی رو خودت پیشنهاد بده! بابا یه ذره خشونتم خوبه‌ها ...سعی کردم خلاصه بگم و یه چیزایی رو پریدم. اگه سوالی درباره استرچ اساینمنت دارید یا دوس دارید راجع بهش بیشتر حرف بزنیم، من تو لینکداین فعالم بهم پیام بدید، خوشحال میشم گپ بزنیم.اما در نهایت خود اون فرد هستش که باعث میشه نتیجه استرچ اساینمنت بشه رشدش یا خدای ناکرده نتونه از عهده مسئولیت بربیاد. ما تو یکتانت هم خودمون از مدیرامون استرچ اساینمنت درخواست می‌کنیم و مدیرامون هم از هر فرصتی برای دادن همچین مسئولیت‌هایی بهمون استفاده می‌کنن. اگه شما هم سرتون درد می‌کنه برای چالش و دوس دارید کِش بیاید، جاتون تو یکتانت خالیه…یه سر به صفحه فرصت‌های شغلی‌مون بزنید... یکتانت | Yektanet Mahsa Mohammadi Mon, 09 Nov 2020 16:09:38 +0330 https://virgool.io/yektanet/%D9%87%D9%85%D9%87-%DA%86%DB%8C%D8%B2-%D8%AF%D8%B1-%D9%85%D9%88%D8%B1%D8%AF-%D9%85%D8%B5%D8%A7%D8%AD%D8%A8%D9%87%D9%87%D8%A7%DB%8C-%D9%85%D9%87%D9%86%D8%AF%D8%B3%DB%8C-%DB%8C%DA%A9%D8%AA%D8%A7%D9%86%D8%AA-xd1hhks5kajh سال گذشته، همین موقع‌ها بود که تصمیم گرفتیم فرایند مصاحبه‌های بخش مهندسی یکتانت رو بازبینی کنیم و بهبودش بدیم. توی این مسیر چالش‌های زیادی داشتیم و می‌خوایم این چالش‌ها و راهکارهامون رو با شما به اشتراک بذاریم. ما توی یکتانت به دنبال بهترین‌ها هستیم و معتقدیم مهم‌ترین سرمایه و دارایی ما، منابع انسانیمون هستن. روی گسترش تیممون تمرکز ویژه‌ای داریم و سعی می‌کنیم با اهمیت دادن به فرایند جذب و استخدام، بهترین‌ها رو به مجموعه اضافه کنیم.توی این پست در مورد فرایند مصاحبه‌های مهندسی یکتانت و چالش‌هایی که در مسیر ساختش داشتیم صحبت می‌کنیم. توی پست بعدی هم قراره در مورد ساختار خود مصاحبه‌ها، معیارهایی که برامون مهم هستن و … بنویسیم. اگر دنبال تدوین یا بهبود فرایند جذب ‌و استخدام شرکتتون هستین، ممکنه با چالش‌های مشابهی روبه‌رو باشین. اگر هم دوست دارین به تیم یکتانت ملحق بشین، کجا بهتر از بلاگ خودمون برای آشنایی با فرایند مصاحبه‌مون و نکاتی که برامون مهم هستن؟من ثمین هستم و از شهریور ۹۸ به عنوان دستیار پیمان، کوفاندر و وی‌پی بخش مهندسی یکتانت به مجموعه اضافه شدم. قبل از من، مهسا که قدیمی‌ترین عضو منابع انسانی یکتانته درگیر کارهای جذب‌ و استخدام مهندسی بود و بعضی وقت‌ها خاطره‌هایی تعریف می‌کنه که تصور کردن چنین مصاحبه‌هایی هم برای مایی که الان از کوچک‌ترین بی‌نظمی توی این فرایند کلی حرص می‌خوریم، سخته. برای این که بهتر بفهمین از کجا شروع کردیم، بد نیست دو تا از این خاطره‌ها رو از زبون خود مهسا بخونین.اوایل رزومه‌ها رو می‌دیدیم و هر چی بیشتر می‌گشتیم کمتر فرد مورد نظر پیدا می‌شد. به پیشنهاد پیمان قرار شد هدهانت رو شروع کنم و در کنارش در راستای برندینگ یکتانت بعضی برنامه‌نویس‌های باتجربه که تو شرکت‌های بنام کار می‌کردن رو برای گپ‌و‌گفت فنی دعوت می‌کردیم، باهاشون آشنا می‌شدیم و یکتانت و جذابیت‌هاش رو بهشون معرفی می‌کردیم. گپ‌و‌گفت‌های فنی جلسات یک‌به‌یکی بود که خیلی زمان از ما می‌گرفت، مخصوصا که افراد باتجربه رو دعوت می‌کردیم و باید حتما یکی از بچه‌های باتجربه و خوش‌صحبت رو می‌فرستادیم جلسه که تو این کیس فقط پیمان رو داشتیم. معمولا این افراد مایل بودن ۷ و ۸ شب بیان جلسه. شهریور ۹۷ بود، آفتاب ساعت ۶ و ۷ غروب می‌کرد، ما هم یه طبقه دفتر کوچک توی مرزداران داشتیم فقط. سه تا مصاحبه ست کرده بودیم، یکی ساعت ۶، یکی ساعت ۷، یکی ساعت ۸ که دوتاشون هدهانتی بودن و یکی خودش رزومه داده بود. اونی که قرار بود ۶ بیاد با یه ساعت تاخیر اومد، اونی که قرار بود ۸ بیاد یه ساعت زود رسید، ما موندیم و سه تا مصاحبه همزمان! یکی رفت تو اتاق جلسات و من مصاحبه‌اش کردم، یکی رفت تو اتاق دولوپرا که اونروز همه زود رفته بودن و یکی از بچه‌ها بدون آمادگی و هماهنگی قبلی باهاش مصاحبه کرد، سومی هم با پیمان نشستن به صحبت کردن. (با خودتون دارید فکر می‌کنید از این بدتر نمی‌شه؟ چرا می‌شه. D:) اواخر مصاحبه بودم که برقا رفت و دیگه از اون‌جا به بعد نفهمیدم چی شد. سوالامو تموم کردم و با عذرخواهی بدرقه‌اش کردم که دیدم پیمان و اون دوست عزیز هدهانتی رو مبل دارن مصاحبه رو تو تاریکی مطلق ادامه می‌دن. از قضا یه هفته بعد اون فرد شد همکارمون! الان با این که دو طبقه دفتر بزرگ‌تر توی یه ساختمون جدید داریم، دیگه از حداکثر ظرفیتمون استفاده نمی‌کنیم و سعی می‌کنیم بین مصاحبه‌ها ۲۰-۳۰ دقیقه‌ای فاصله بندازیم.یه خاطره‌ی دیگه هم دارم از پاییز همون سال. آبان ۹۷ بود که از کمبود جا و اتاق جلسات به ستوه اومده بودیم. تازه یه واحد جدید توی ساختمون اجاره کرده بودیم و هنوز هیچ دستی به سر و روش نکشیده بودیم. یه واحد خالی، با یه میز و دو تا دونه صندلی و کاغذ دیواری‌های زشت با گل و بلبل! با علیرضا مصاحبه داشتیم؛ یه پسر آروم و کم‌حرف که الان از خفن‌های تیممونه. یک ساعت از مصاحبه‌مون گذشته بود که پیمان بهش یه مینی‌پروژه داد که همون موقع بزنه و تحویل بده. همون موقع مهمون‌های جلسه‌ی بعدی پیمان رسیدن و به دلیل کمبود جا، مجبور شدم علیرضا رو ببرم واحد جدیدمون با امکانات نزدیک به صفر. همون موقع برای داکت‌کشی و ... اومدن دفتر و سر و صداها تازه شروع شد. علیرضا هم بنده‌ی خدا هیچ اعتراضی نکرد. پروژه رو زد و روی فلش ازش تحویل گرفتم و رفت. از اون موقع تا یک هفته‌ی بعدش، هر روز می‌رفتم پیش پیمان و بهش یادآوری می‌کردم که پروژه‌ش رو ببینه. آخر هم فرصت نکرد ببینه و بر مبنای همون مصاحبه به علیرضا گفتیم بیاد و کارش رو شروع کنه (احتمالاً تا قبل از خوندن این پست خودش هم نمی‌دونه که هیچ‌وقت اون پروژه رو ندیدیم). اون زمان از این اتفاق‌ها کم نمی‌افتاد و خوش‌حالم که الان مصاحبه‌هامون سر و سامون گرفته‌ان.همون‌طور که متوجه شدین ما قبلاً مشکلات زیادی توی مصاحبه‌هامون داشتیم؛ از بی‌نظمی‌هایی که توی هماهنگی‌های مصاحبه و تخصیص اتاق جلسات و ... بوده، تا نداشتن فرایند و روال مشخص برای مصاحبه‌ها و نداشتن تیم مصاحبه‌کننده‌ و سیستم ارزیابی درست و ... قطعاً الآن هم بی‌نقص یا حتی کم‌نقص نیستیم، اما تونستیم به جای نسبتاً خوبی برسیم و هر روز هم سعی می‌کنیم با گرفتن بازخورد از مصاحبه‌شونده‌ها و به‌روز کردن دانش و تجربه‌ی خودمون، فرایندمون رو بهتر کنیم.از کجا شروع کردیم؟اولین و اساسی‌ترین سوال‌هایی که باهاشون روبه‌رو بودیم این بودن که اصلاً مصاحبه‌ی خوب چیه و چه بخش‌هایی داره؟ از کجا بدونیم از چه روش‌هایی باید استفاده کنیم؟ به چه نکاتی باید توجه کنیم؟برای این بتونیم به این سوال‌ها پاسخ بدیم، در مورد فرایند مصاحبه‌ی شرکت‌های بزرگ دنیا مثل گوگل، فیس‌بوک، نتفلیکس و ... سرچ کردیم و علاوه بر مطالبی که مدیران ارشد این سازمان‌ها نوشته بودن، تجربیاتی که آدم‌ها از مصاحبه با این شرکت‌ها منتشر کرده بودن رو خوندیم؛ به طور خاص کتاب «!Work Rules» گوگل کمک زیادی بهمون کرد. توی این کتاب لازلو باک (Laszlo Bock)، سرپرست سابق بخش People Operations گوگل از فرایندهای داخلی سازمان و قوانین مدیریت افراد صحبت می‌کنه. فصل پنجم این کتاب به فرایند جذب و استخدام گوگل اختصاص داره و به نکات خوبی توش اشاره می‌شه. ما هم بعد از مطالعه‌ی منابع مختلف و آزمون‌ و خطا، به فرایند زیر برای مصاحبه‌های مهندسی یکتانت رسیدیم.فرایند و مراحل مصاحبه‌های مهندسی یکتانتخیلی وقت‌ها پیش میاد که کاندیداها بهمون اعتراض می‌کنن که چرا چندین و چند مرحله مصاحبه دارین و از روی همون رزومه هم می‌تونین ببینین مناسب هم هستیم یا نه، این همه فرایند و مصاحبه و ... نداره. خب راستش بالاخره رزومه هم مهمه و تا حدی می‌شه از روش نکاتی رو فهمید، ولی خیلی وقت‌ها هم پیش میاد که توی مصاحبه‌ها متوجه می‌شیم که توانایی و تجربه‌ی اون شخص از چیزی که نوشته و ما فکر می‌کردیم خیلی کمتره. یا برعکسش! خیلی آدم توانمند و باتجربه‌ایه، ولی رزومه‌اش رو خیلی بد نوشته و چیزی ازش در نمیاد. مثلا یکی از تجربیاتی که مهسا توی مصاحبه‌های قدیم در همین مورد داشته رو بخونین:اون زمان معمولا مصاحبه‌ها این‌طوری بود که من و یکی دو تا از بچه‌های فنی می‌رفتیم، من سوال‌های اچ‌آری می‌پرسیدم و بقیه سوالای فنی. یه بار یه رزومه‌ای اومده بود؛ یه رزومه‌ی خیلی پُر، یه کانال تلگرام با کلی فالوئر و ... برای این که بتونیم همه‌ی چیزهایی که نوشته بود رو توی مصاحبه بسنجیم، مجبور شدیم کلی آدم بریم مصاحبه.‌ به خاطر بخش‌های بک‌اندی رزومه‌اش رضا اومد، به خاطر کارهای DevOpsایش افشین، برای فرانتش علی، برای بخش دیتا سینا و منم برای مصاحبه‌ی اچ‌آری. ۵ نفر توی یه مصاحبه! انتظارم این بود که طرف استرس بگیره، اما برعکس خیلی آروم بود. توی مصاحبه مشخص شد کلا هیچ کار خاصی نکرده، همه‌ی تجربیاتش خیلی سطحی بوده یا کارهای هم‌تیمی‌هاش بوده و در کل توی هیچ کدوم عمیق نشده و تسلطی نداره. بعد این تجربه فهمیدیم که کسی که رزومه‌اش آش شله‌قلم‌کاره، احتمالا تو هیچ زمینه‌ای تخصص نداره و عمیق نشده و هر کسی می‌تونه توی یکی دو تا حوزه متخصص بشه. و البته باز هم بهمون ثابت شد که رزومه به تنهایی معیار مناسبی برای قضاوت نیست و توی بعضی از کیس‌ها لازمه که حتی بیشتر از یکی دو تا مصاحبه‌ی فنی داشته باشیم تا بتونیم ارزیابی دقیق‌تری داشته باشیم.البته پنج نفر توی یه مصاحبه هم خیلی جالب نیست و به جای برگزاری چنین جلساتی، الان سعی می‌کنیم با فرایندی که در ادامه توضیح می‌دیم بتونیم سنجش درستی از مهارت‌ها و توانایی‌های کاندیداها داشته باشیم.۱- بررسی رزومهرزومه‌ها از کانال‌های مختلف و از سایت یکتانت به دست ما می‌رسن. شاید نرخ پذیرش رزومه زیر ۲ درصد باشه، ولی نکته‌ای که مهمه اینه که نیروی خوب روی زمین نمی‌مونه! ما برای خودمون ددلاین‌هایی تعریف کردیم و سعی می‌کنیم همه‌ی رزومه‌ها رو نهایتاً تا ۲-۳ روز و در بدترین حالت تا یک هفته بعد از ارسال بررسی کنیم و نتیجه رو به کاندیدا اطلاع بدیم. بعضی وقت‌ها ممکنه کسی برای یک موقعیت شغلی رزومه فرستاده باشه، ولی با توجه به سوابقش برای موقعیت شغلی دیگه‌ای توی سازمان ما مناسب باشه. ما حتماً توی این موارد به اون فرد اطلاع می‌دیم و در صورت تمایل وارد فرایند موقعیت شغلی مناسب می‌شه. خیلی وقت‌ها هم ممکنه اون رزومه در اون زمان برای ما مناسب نباشه، اما توی بانک رزومه‌هامون ذخیره‌اش می‌کنیم تا در آینده، در صورتی که موقعیت مناسب باز شد با اون فرد تماس بگیریم.۲- مصاحبه‌ی تلفنیبعضی وقت‌ها ممکنه رزومه‌ی کاندیدا کامل نباشه یا نتونیم از روی رزومه، اطلاعات درستی از سطح دانش فنی و تجربیاتش به دست بیاریم. توی این موارد فرایند مصاحبه رو با یه گپ‌وگفت تلفنی کوتاه شروع می‌کنیم. البته این مصاحبه رو هم بچه‌های فنی انجام می‌دن و در کنار این که ما به شناخت درست‌تری از کاندیدا می‌رسیم، اون هم می‌تونه هر سوالی رو که داره مستقیم با بچه‌های تیم فنی مطرح کنه و اطلاعات و شناخت بیشتری از شرکتی که براش اپلای کرده پیدا کنه.۳- آزمون توانمندی‌های ذهنیما توی فرایند مصاحبه‌مون یه آزمون توانمندی‌های ذهنی داریم که شامل سوال‌های مختلفی در زمینه‌ی استدلال منطقی، استدلال استقرایی، توانایی پردازش و سامان‌دهی، دقت، سرعت عمل و … می‌شه. هدفمون از این آزمون، فیلتر کردن رزومه‌ها بر مبنای همین یک عامل نیست. بلکه نتیجه‌ی این آزمون رو هم در کنار بقیه‌ی دیتاها قرار می‌دیم تا بتونیم ارزیابی درست‌تری از کاندیدا داشته باشیم.جالبه بدونین در همون فصل پنجم کتاب Work Rules هم از آزمون سنجش توانایی‌های شناختی (General Cognitive Ability Test) به عنوان دومین پیش‌بینی‌کننده‌ی مناسب برای پیش‌بینی پرفورمنس یک کاندیدا در یک موقعیت شغلی یاد می‌شه.۴- مصاحبه‌ی فنیتوی این مرحله دو نفر از بچه‌های تیم فنی یکتانت در یک جلسه‌ی حضوری به بررسی تجربیات قبلی کاندیدا و ارزیابی سطح فنی اون می‌پردازن. البته الان با توجه به شرایط کرونا، بعضی از این مصاحبه‌ها به صورت آنلاین برگزار می‌شن. این جلسه‌ی مصاحبه معمولاً با بررسی رزومه‌ی فرد و صحبت از تجربیات گذشته‌ش شروع می‌شه و در ادامه به سمت مباحث فنی‌تر پیش می‌ره. نکته‌ی مهمی که ما توی این مدت سعی کردیم بهش توجه کنیم، ساختاریافته بودن این مصاحبه‌هاست. طبق تحقیقی که نتایجش به عنوان مرجع در فصل پنجم Work Rules اومده، مصاحبه‌های تیپیکال و بدون ساختاری که توی اکثر شرکت‌ها انجام می‌شه، فقط می‌تونن ۱۴ درصد پرفورمنس کاندیدا رو زمانی که در اون موقعیت شغلی مشغول به کار می‌شه، پیش‌بینی کنن (r2=0.14). تجربه‌ی ما هم همین موضوع رو تایید می‌کنه و الان به این باور رسیده‌ایم که جلسات مصاحبه باید ساختار مشخصی داشته باشن. توی پست بعدی بیشتر در مورد خود جلسات مصاحبه و معیارهامون صحبت خواهیم کرد.۵- تسک عملییکی از مهم‌ترین پیش‌بینی‌کننده‌هایی که می‌تونه بگه یک فرد در یک موقعیت شغلی چه عملکردی خواهد داشت، پروژه‌ی نمونه‌کار (Work Sample Test) هست، همون مرحله‌ای که ما بهش می‌گیم تسک عملی. این بخش معمولاً توی مراحل مصاحبه‌ی بقیه‌ی شرکت‌های خارجی و ایرانی هم وجود داره و اطلاعات خوبی از سطح توانایی‌های فنی کاندیدا بهمون می‌ده. ما برای همه‌ی موقعیت‌های شغلی تسک‌های مشخصی در سطوح مختلف طراحی کردیم و با توجه به تجربیات و سطح کاندیدا، یکی از این تسک‌ها رو براش ارسال می‌کنیم. نکته‌ای که مهمه اینه که حجم این تسک و زمانی که از فرد می‌گیره نباید به حدی باشه که از ادامه‌ی فرایند منصرف بشه یا نتونه زمان کافی بهش اختصاص بده. اون اوایل ما سخت‌گیری زیادی روی ددلاین و زمان تسک داشتیم و به همه، فارغ از سطح تجربیاتشون و این که الان شاغل هستن یا نه و … تسک می‌دادیم. بعد از یه مدت دیدیم که بعضی از کاندیداهامون رو-که احتمالاً توانمندی‌های خوبی هم داشتن-به خاطر زمان‌بر بودن این مرحله از دست می‌دیم و از اون به بعد سعی کردیم انعطاف بیشتری به خرج بدیم و در بعضی موارد به راه‌حل‌های جایگزین فکر کنیم (مثلاً این که به جای ارسال تسک ۲-۳ روزه، یک مینی‌پروژه‌ی کوچک‌تر تعریف کنیم که فرد توی همون جلسه‌ی مصاحبه انجام بده و در کنار این که ما بتونیم سنجشی که لازم داریم رو انجام بدیم، از اون فرد هم زمان کمتری گرفته بشه).۶- مصاحبه‌ی نهاییتا این‌جا بیشتر در مورد توانمندی‌های ذهنی و فنی صحبت کردیم و هیچ اشاره‌ای به فرهنگ سازمانی نداشتیم. یکی از مهم‌ترین معیارهای ما در جذب نیروهای جدید، میزان تطابق اون فرد با فرهنگ سازمانی یکتانته. فرهنگ و ارزش‌های اصلی هر سازمانی معمولاً توسط کوفاندرهای اون سازمان شکل می‌گیره و نسل‌به‌نسل به بقیه‌ی مدیران و کارمندان اون سازمان منتقل می‌شه. به همین دلیل بهترین افرادی که می‌تونن میزان تطابق یک فرد با فرهنگ سازمان رو ارزیابی کنن هم کوفاندرها و مدیران ارشد سازمان هستن. توی بخش مهندسی یکتانت، همیشه مصاحبه‌ی نهایی با پیمان، کوفاندر و وی‌پی بخش مهندسی انجام می‌شه و تمرکز اصلی روی مباحث رفتاری و تطابق فرهنگیه.چالش‌های ما در مسیر بهبود فرایند مصاحبه‌هاتا این‌جا در مورد مراحل مصاحبه صحبت کردیم. در طی ساختن این فرایند و بهبودش چالش‌های مختلفی داشتیم که توی نیمه‌ی دوم این نوشته قراره به چند مورد از این چالش‌ها بپردازیم.نظم و مستندسازیزمانی که به تیم اضافه شدم، دسترسی یک گوگل‌شیت بهم داده شد و یک برُد ترلو. گوگل‌شیت در واقع کل دیتابیس ما از کاندیداهامون بود و از ترلو هم برای مشخص کردن وضعیت هر کدوم از اون‌ها استفاده می‌کردیم. هر دوی این‌ها ابزارهای خوبی بودن، به شرط این که درست استفاده می‌شدن. تا اون موقع خیلی از داده‌ها کامل وارد نمی‌شدن، بُرد ترلو آپدیت نبود و در کل ما دیتای درست و کاملی از این که چه افرادی برامون رزومه فرستادن و توی چه مرحله‌ای هستن نداشتیم. یکی از مهم‌ترین کارهایی که ما توی این مدت انجام دادیم، منظم کردن و مستندسازی فرایند از همون لحظه‌ی اول تا نتیجه‌ی آخر بود. یکی از راهکارهایی که برای مدیریت بهتر فرایند جذب ‌و استخدام وجود داره، استفاده از نرم‌افزارهای ATS آماده هست.از چه ATS ای استفاده کنیم؟ما توی یکتانت از ATS آماده‌ی خاصی استفاده نمی‌کنیم. دلیلش هم اینه که سیستمی پیدا نکردیم که نیازهای فعلیمون رو پوشش بوده و برامون ارزش افزوده‌ای هم داشته باشه. به جاش متناسب با نیازهای خودمون یه برد ترلو برای مصاحبه‌های مهندسی ساختیم و همه‌ی مستندسازی‌ها و پیگیری‌هامون رو توی همون برد انجام می‌دیم. تقریباً همه‌ی چیزهایی که بهشون نیاز داریم رو تونستیم با اکانت معمولی ترلو هندل کنیم. از مزایای ترلو می‌تونیم به این موارد اشاره کنیم:اولین و مهم‌ترین مزیت ترلو، ساده بودنشه و شما به راحتی می‌تونین باهاش ارتباط برقرار کنین و ازش استفاده کنین.شما می‌تونین یک پایپ‌لاین متناسب با فرایند و نیازهای خودتون توی ترلو طراحی کنین و به راحتی اون رو هر زمانی که لازم بود، تغییر بدین.امکان اضافه کردن همه‌ی افراد درگیر در جذب و استخدام به بُرد، اساین کردن اون‌ها به کارت کاندیدایی که درگیر فرایند جذبش هستن، تعیین ددلاین برای مراحل مختلف و … وجود داره.امکان استفاده از لیبل‌های مختلف برای تقسیم‌بندی بهتر کارت‌ها وجود داره.امکان ضمیمه کردن فایل‌های مختلف به یک کارت وجود داره که به ما کمک می‌کنه صفر تا صد پرونده‌ی استخدام یک نفر رو، از رزومه‌اش تا گزارش‌های مصاحبه‌ها و تسک انجام‌شده توسط فرد و … توی یک کارت جمع و جور داشته باشیم.ترلو API-هایی در اختیار کاربرانش قرار می‌ده که با استفاده از اون‌ها می‌تونین با یکم برنامه‌نویسی، بخشی از کارهایی که انجام می‌دین و قاعده‌مند و اتومات کنین. البته بدون این کار هم به صورت محدود امکان تعریف Rule-هایی برای بخش‌هایی از فرایند وجود داره.توی تصویر زیر نمای کلی این بُرد رو می‌بینین.نمای کلی بُرد مصاحبه‌های مهندسیاهمیت مستندسازی- آقای ایکس دوباره برامون رزومه فرستاده. پارسال هم اومده بود مصاحبه. چرا ردش کرده بودیم؟+ راستش یادم نیست. فکر کنم تجربه‌ش کم بود.تا یک سال پیش تقریباً هیچ گزارش مکتوب و مستندی از هیچ‌یک از مراحل مصاحبه‌ی یک فرد وجود نداشت. بچه‌ها از جلسه‌ی مصاحبه می‌اومدن بیرون، پیمان ازشون می‌پرسید چطور بود؟ و اون‌ها هم در بهترین حالت توی چند جمله نظر کلیشون رو می‌گفتن و همون‌جا تصمیم در مورد ادامه‌ی روند توسط پیمان گرفته می‌شد. البته خب ممکن بود نتیجه نتیجه‌ی بدی هم نباشه، ولی خیلی به نظرات شخصی آدم‌ها وابسته بود. از طرفی هم هیچ دیتایی از اون مصاحبه برای استفاده‌های احتمالی در آینده ثبت نمی‌شد.یکی از اولین کارهایی که در راستای مستندسازی گزارش‌های مصاحبه کردیم، این بود که بردن گوشی و لپ‌تاپ رو به جلسه‌های مصاحبه ممنوع کردیم تا هم کاندیدا حس بهتری داشته باشه، هم بچه‌ها رو سوق بدیم به سمت یادداشت‌برداری. قبل از جلسه‌ی مصاحبه، یکی یک نسخه از رزومه‌ی کاندیدا برای همه‌ی مصاحبه‌گیرنده‌ها پرینت کردیم و ازشون خواستیم تا توی جلسه‌ی مصاحبه هر نکته‌ای که به نظرشون می‌رسه رو روی همون رزومه یادداشت کنن. در نهایت هم بعد از مصاحبه جمع‌بندی کلیشون رو در حد یکی دو پاراگراف روی رزومه اضافه کنن. همه‌ی این رزومه‌ها رو توی فایل‌هایی نگه می‌داشتیم تا بعداً در صورت نیاز بتونیم دوباره بهشون رجوع کنیم. البته ناگفته نماند که به لطف کرونا و دورکاری، بچه‌ها هم به صورت خودجوش عادت کردن که یا گزارش مصاحبه رو مستقیم توی ترلو تایپ کنن، یا از نوشته‌هاشون عکس بگیرن و به کارت ضمیمه‌ش کنن. در حال حاضر همه‌ی گزارش‌های مصاحبه‌مون مستقیم توی ترلو نوشته می‌شن و نیازی به نگه‌داری نسخه‌های کاغذی نداریم.از برکات کرونای ملعوناهمیت داشتن معیارهای ارزیابی مشخص«تسکش خوبه. بیاد مصاحبه. / در حد انتظارمون نیست. رده.»قدیم ارزیابی تسک‌ها هم به این شکل بود که یک نفر از بچه‌ها یا خود پیمان تسک فرد رو بررسی می‌کردن و نتیجه‌ی نهایی رو در حد قبول/رد ثبت می‌کردن. در حال حاضر معیارهای مشخصی برای ارزیابی تسک‌ها داریم و همه‌ی کسایی که یک تسک رو بررسی می‌کنن، گزارش کاملی رو از ارزیابیشون و نقاط قوت و نقاط ضعف تسک انجام‌شده روی کارت ترلو ثبت می‌کنن.خیلی وقت‌ها پیش میاد که یک نفر بعد از چند ماه دوباره برای ما رزومه می‌فرسته و با سیستم قدیم، تنها در صورتی می‌تونستیم سابقه‌ی فرد رو داشته باشیم که حافظه‌ی افراد درگیر توی مصاحبه‌ش یاری می‌کرد. الآن می‌تونیم به راحتی پرونده‌ی کامل اون فرد رو توی ترلو پیدا کنیم به همه‌ی بازخوردهایی که همه‌ی افراد درگیر در فرایند مصاحبه‌هاش داشتن، دسترسی داشته باشیم. علاوه بر اون می‌تونیم توی هر مرحله از مصاحبه بازخوردهای دقیقی به خود فرد هم ارائه بدیم.معجزه‌ی چک‌لیست!یکی از مشکلاتی که ما توی این مدت زیاد باهاش مواجه شدیم این بود که افراد مختلف توی بخش‌های مختلف فرایند یادشون می‌رفت کاری رو انجام بدن، سوالی رو بپرسن یا … مثلاً یکی از اتفاق‌هایی که زیاد تکرار می‌شد این بود که یک نفر تا مرحله‌ی آخر مصاحبه‌ها پیش می‌اومد و در نهایت سر ساعت کاری به توافق نمی‌رسیدیم، چون از اول بهش نگفته بودیم که توی بخش مهندسی یکتانت پنج‌شنبه‌ها هم هستیم (البته از ابتدای تابستون ۹۹ بچه‌هایی که فول‌تایم هستن پنج‌شنبه‌ها تعطیلن). اگه تا حالا فرایند مصاحبه‌ی شرکتی رو کامل طی کرده باشین یا خودتون دنبال جذب نیرو بوده باشین، می‌دونین این اتفاق چقدر دردناک و هزینه‌بره. یا خیلی وقت‌ها بچه‌ها بعد از جلسه‌ی مصاحبه و وقتی داشتن گزارش مصاحبه رو می‌نوشتن، یادشون می‌افتاد که توی جلسه یادشون رفته راجع به فلان مسئله سوال بپرسن. این مسئله به شکل‌های مختلف و توی مراحل مختلف تکرار می‌شد، در صورتی که یه راه حل خیلی ساده و کم‌هزینه جلوی پامون بود و ازش استفاده نمی‌کردیم: چک‌لیست!اگه به معجزه‌ی چک‌لیست اعتقاد ندارین، کافیه یک مدت امتحانش کنین. ما برای این که بتونیم همه‌ی بخش‌های این فرایند رو روی نظم پیش ببریم و نکته‌ای رو از قلم نندازیم، برای مراحل مختلف چک‌لیست‌های مختلف تهیه کردیم و در اختیار افراد درگیر قرار دادیم. هیچ چیزی رو ساده و بدیهی فرض نمی‌کنیم و به حافظه‌مون هم اتکا نمی‌کنیم. از نتیجه‌ای که گرفتیم هم به شدت راضی‌ایم.به عنوان مثال این چک‌لیستیه که برای تماس تلفنی اولیه با کاندیدا تهیه کردیم و همیشه جلوی چشممون هست تا نکته‌ای از قلم نیفته:چک‌لیست تماس تلفنی اولیه از سمت تیم منابع انسانیتشکیل کمیته‌های استخدام؛ از مهم‌ترین تغییرات ما!یکی دیگه از چالش‌های بزرگی که ما باهاش روبه‌رو بودیم این بود که خیلی وقت‌ها روی نظرات یک فرد خاص بایاس می‌شدیم. از طرفی هم با توجه به این که تیم ما تیم خیلی بزرگی نبود و افراد محدودی درگیر فرایند جذب و استخدام بودن، کم پیش نمی‌اومد که توی جلسه‌ی مصاحبه فقط یک نفر به عنوان مصاحبه‌کننده وجود داشته باشه. برای حل این مشکل، همه‌ی استخدام‌هامون رو به سمت کمیته‌ای شدن پیش بردیم. یعنی چی؟برای هر موقعیت شغلی، کمیته‌های مصاحبه‌ی حضوری و ارزیابی تسک رو تشکیل دادیم؛ یعنی مشخصه که چه افرادی مصاحبه‌ی حضوری می‌گیرن و چه افرادی تسک‌ها رو بررسی می‌کنن. برای جلوگیری از بایاس شدن، این قانون رو گذاشتیم که حداقل ۲ نفر توی مصاحبه‌های حضوری شرکت می‌کنن و ۲ الی ۳ نفر هم هر تسک رو بررسی می‌کنن. همه‌ی این افراد توی همه‌ی مراحل، مستقل از هم نظرات و ارزیابی‌هاشون رو توی ترلو ثبت می‌کنن. کمیته‌ی استخدام نهایی هر کاندیدا هم با حضور همه‌ی افرادی که توی فرایند مصاحبه به نوعی درگیر بودن (چه افرادی که مصاحبه‌ی حضوری داشتن، چه افرادی که تسک فرد رو بررسی کردن) تشکیل می‌شه و در نهایت اعضای این کمیته به صورت جمعی تصمیم به قبول یا رد کاندیدا می‌گیرن.طبیعتاً توی این روش اطلاعات بیشتری از کاندیدا به دست میاد، چرا که هر کدوم از بچه‌ها به نقاط خاصی توجه می‌کنن که ممکنه به نظر یه نفر دیگه نیومده باشه. احتمال بایاس شدن سمت نظرات یه فرد خاص و قضاوت‌های شخصی هم به شدت کمتر می‌شه.توجه به تجربه‌ی کاندیدا (Candidate Experience)ما همیشه سعی می‌کنیم بهترین تجربه رو برای کاندیداهامون بسازیم، فارغ از این که قراره در نهایت به تیممون اضافه بشن یا نه. رعایت نظم و داشتن ددلاین‌های مشخص برای هر مرحله از فرایند مصاحبه کمک زیادی به ساختن تجربه‌ی بهتری برای افراد می‌کنه. ما سعی می‌کنیم همه‌ی رزومه‌ها رو حداکثر تا یک هفته بررسی کنیم و نتیجه‌ی بررسی رو (چه قبول باشه و چه رد) به اطلاع فرد برسونیم. توی تماس اولیه توضیح کاملی از فرایند مصاحبه‌مون به فرد می‌دیم. توی باقی مراحل (مصاحبه‌های حضوری یا تسک عملی) هم حداکثر تا یک هفته نتیجه رو به اطلاع فرد می‌رسونیم. البته این حق مسلم کاندیداست که بتونه بازخورد دقیق و کافی از وضعیتش در فرایند استخدام داشته باشه و نتیجه به‌موقع بهش اطلاع‌رسانی بشه و اگر غیر از این باشه، اشتباهه.انعطاف در فرایندیکی از مهم‌ترین نکته‌هایی که ما توی این مدت بهش رسیدیم اینه که چسبیدن به یک فرایند ثابت و انعطاف نداشتن، خیلی جاها می‌تونه به ضرر خودمون و کاندیدا تموم بشه. به طور مثال مسئله‌ای که بالاتر توی مرحله‌ی تسک بهش اشاره کردم و باعث می‌شد ما تعداد قابل توجهی از کاندیداهای خوبمون رو از دست بدیم. یا یه اشتباه دیگه‌ای که داشتیم این بود که فرایند و نحوه‌ی برخوردمون با نیروهای فرش، جونیور و سینیور تقریباً مشابه هم بود و از این نکته غافل بودیم که این افراد تجربیات مختلفی دارن، انتظارات و رویکردهای مختلفی دارن و واکنش‌های مختلفی به فرایند و مصاحبه‌های ما نشون می‌دن. الان با توجه به تجربیاتی که کسب کردیم سعی می‌کنیم تا حد ممکن توی مراحل مصاحبه‌مون انعطاف به خرج بدیم و با کاندیدا راه بیایم؛ البته از یک روال و ساختار کلی هم پیروی می‌کنیم و قوانین و معیارهای مشخصی داریم.توی این پست سعی کردیم بخشی از تجربیاتی رو که طی بهبود فرایند مصاحبه‌های مهندسی یکتانت داشتیم شرح بدیم. اگه ش‍ما هم توی یکتانت مصاحبه داشتین یا در مورد فرایندی که توضیح دادیم بازخوردی دارین، خیلی خوش‌حال می‌شیم که صحبت‌هاتون رو بشنویم و بتونیم راهی که شروع کردیم رو با کمک شما جدی‌تر ادامه بدیم. توی پست بعدی قراره با چند تا از اعضای کمیته‌ی مصاحبه‌های مهندسی یکتانت صحبت کنیم و بیشتر در مورد جلسه‌های مصاحبه، نکات و معیارهایی که توی ارزیابی‌ها مهم هستن و … صحبت کنیم. بلاگ مهندسی یکتانت رو دنبال کنین تا بی‌خبر نمونین. ;)راستی اگه سرتون برای کار کردن درد می‌کنه و دنبال هم‌تیمی‌های باانگیزه و تکنولوژی‌های خفن برای کار کردن می‌گردین، جاتون توی تیم ما خالیه. می‌تونین از طریق صفحه‌ی فرصت های شغلی یکتانت از موقعیت‌های شغلی باز ما اطلاع پیدا کنین و برامون رزومه بفرستین. یکتانت | Yektanet ثمین اعتمادمقدم Sat, 29 Aug 2020 20:42:15 +0430 https://virgool.io/yektanet/%DA%86%D8%B7%D9%88%D8%B1-%D8%A8%D8%A7%DA%AF%D9%87%D8%A7%D9%85%D9%88%D9%86-%D8%B1%D9%88-%D9%87%D9%85%D9%87%D8%AC%D8%A7-%DA%AF%D8%B3%D8%AA%D8%B1%D8%B4-%D8%AF%D8%A7%D8%AF%DB%8C%D9%85-yektaui-%D8%A7%D8%B2-%D8%A8%D8%AF%D8%B9%D8%AA-%D8%AA%D8%A7-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-y95lt21mju4e احتمالا اگه اندکی با یکتانت آشنا باشین میدونید که دولوپر‌های سمت فرانت‌اند بیشتر وقتشون رو به توسعه پنل‌ها می پردازن. سال پیش یکی از همین روزا بود که فهمیدیم چقدر کد مشابه داریم که تو پنل‌های مختلف استفاده میکنیم. نمونه‌اش کامپوننت پشتیبانی(Ticketing)‌مون بود که برای هر پنل از یک کد مشابه استفاده می‌شد اما هر باگ فیکس یا افزودن فیچری بهش مستلزم این بود که به تک‌تک پنل‌ها سر زده بشه یا اطلاع‌رسانی کنیم که تو هر پنل این قسمت‌ها رو آپدیت کنید! خب این روش درست نبود. شاید دلمون میخواست هر فیچری که میزدیم رو یکبار بزنیم و بقیه جاها هم آپدیت بشن. یا اصلا دلمون می‌خواست و شوق این رو داشتیم که باگ‌هامون رو زودتر تو همه پلتفرم‌ها توسعه دهیم. چرا باید این فرآیند دیپلوی کردن یه باگ انقدر طول بکشه؟!کد تکراری، منشأ همه شرارت‌هایک اصل در معماری نرم‌افزاری هست به اسم Don't Repeat Yourself) DRY) . با این مفهوم که کد تکراری منشاء همه‌ی شرارت‌هاست. این شد که جرقه یک کیت فرانت شکل گرفت تا از ایجاد چنین کد‌هایی جلوگیری کنه و به افزایش کیفیت کد‌ها هم منجر بشه. ما اسمش رو گذاشتیم YektaUI. سعی میکنم در متن زیر به دلایل ایجاد این کیت فرانت که توسعه‌اش تا الان توسط تمام بچه‌های فرانت‌اند یکتانت انجام شده اشاره کنم، درمورد خصوصیاتش توضیح بدم و نحوه‌ی توسعه‌‌اش رو شرح بدم.Don't Repeat Yourselfداستان یکتانت و پلتفرم‌هامجموعه یکتانت تا حدود یک سال قبل، شامل پنل‌های یکتانت و نجوا می‌شد. اما یکتانت فقط به همین‌ موارد ختم نشد. از سال پیش تاکنون پنل پلتفرم‌های تریبون و جریان هم توسط یکتانت لانچ شد.تعداد پنل‌ها تا این لحظه تقریبا به هفت پنل میرسه. تمامی این پلتفرم‌ها نیاز به زیرساختی داشتند تا سرویس‌هایی مثل احراز هویت(Authentication)، پشتیبانی(تیکتینگ) و موارد مالی رو پوشش بدن. از این جهت، زیرساخت موارد ذکر شده، در یک سال اخیر ایجاد شد و تمامی پلتفرم‌ها تونستند از این زیرساخت‌ها استفاده کنند.استک و کتابخانه‌های مورد استفاده در تمامی پنل‌ها در حال حاضر موارد زیر است:SCSSBootstrap 4BootstrapVueNuxtVueاما آیا لازم بود که هر پلتفرم، فارغ از پلتفرم‌های دیگر نیازمندی‌های خودش رو پیاده‌سازی کنه؟ این مسئله باعث میشه تا وقت زیادی از توسعه‌دهندگان، صرف کدهایی بشه که قبلا توسط اعضای دیگه یکتانت زده شده. ما دنبال توسعه سریعتر و باکیفیت‌تر بودیم. این جرقه‌ی شروع کیت بود. اما چون شروع این کار ممکن بود وقت زیادی از افراد رو بگیره باید با دلایل محکم‌تری به سمتش می رفتیم.ادله کافی جهت ایجاد و توسعهاحتمالا بهترین جواب‌ها، از بهترین سوالات شروع به شکل‌گیری می‌کنند. سوال‌های ما چی بود که نتیجه‌اش شد ایجاد یک کیت فرانت اند؟ میتونم بگم این‌ها بودند:کامپوننت‌های مشترک را چطور استفاده کنیم/توسعه بدهیم؟توابع و utilityهای پراستفاده، از کجا قابل دسترسی باشند؟استایل کدهامون رو چگونه و بر چه اساس یکی کنیم؟ آیا امکان دارد همه این استایل را رعایت کنند؟چطور از دانش افراد مختلف به طور عملی استفاده کنیم؟چطور میتونیم از طریق توسعه با کمک یکدیگر، کیفیت توسعه را افزایش دهیم؟با توجه به گسترش تیم‌ها و زیاد شدن محصولات، ابزارهای داخلی را به چه صورت منتشر کنیم؟احتمالا جواب این سوالات رو میتوانستیم با توسعه YektaUI پیدا کنیم. باتوجه به موارد ذکر شده و با استناد به این مفهوم که زودتر کد رو بزنیم تا اینکه بیشتر از حد راجع به مسئله فکر کنیم، توسعه رو شروع کردیم. این توسعه چه چیزهایی رو شامل می‌شد؟۱.کامپوننت‌هادریا دریا کامپوننت. همه‌اش برای خودمون. در همه‌ی پنل‌ها به اندازه کافی کامپوننت‌های مشترک داشتیم که هرکدوم فیچر‌های خاص خودشون رو داشتند و لازم بود تا این موارد در کنار یکدیگر قرار بگیرند و پازل بزرگ ما رو شکل بدن.دریا دریا کامپوننت به روایت تصویرمهمترین کامپوننت‌ها را میتونیم به کامپوننت‌های فرم‌(form) تخصیص بدیم. صحبت در مورد توسعه این کامپوننت‌ها، خودش چندین سلسله مطلب رو میطلبه، اما از جهت بیان کلی نیازمندی‌هامون، میتونم موارد زیر رو اشاره کنم:در فرم‌ها labelها به چه صورت نمایش داده شوندخطای هر input و هر form را به چه صورت نمایش دهیمصحت و validation محتوای inputها را چطور اعتبار‌سنجی کنیمچهارچوب و layout فرم به چه نحوی باشد تا کاربر با آن ارتباط بیشتری برقرار کندتعدادی از موارد بالا توسط متخصص UX انجام میشه اما باتوجه به اینکه این پوزیشن در حال حاضر در یکتانت تعریف نشده، قسمتی از فعالیت دولوپر فرانت‌اند و مدیر محصول به تعیین چنین تصمیماتی تخصیص پیدا میکنه.سوالات بالا، سوالات خیلی خوبی بودند. اما جواب‌ها مدت زمانی حدود دو ماه را از ما گرفت تا بتونیم تعداد زیادی مقاله بخونیم و کتابخونه‌های مختلف رو بررسی کنیم تا پاسخ کاملی براش پیدا کنیم; ولی نتیجه لذتبخش بود.سری بعدی کامپوننت‌های پر استفاده برای ما، جدول‌ها(table) بودند. چندین نوع جدول مختلف در پروژه‌ها داشتیم با چندین فیچر مختص هرکدام(هنوز هم داریم. این قسمت هنوز درست نشده :دی) که هر فردی که از یه پروژه به پروژه دیگری منتقل می‌شد نیاز داشت تا با جدول‌های پروژه جدید آشنا بشه ( همونطور که گفتم هنوزم باید یاد بگیره :) )‌. تعداد زیادی کامپوننت تیکتینگ داشتیم که مشتری‌ها از طریق این قسمت‌ها میتونستند سوالاتشان رو مطرح کنند و از ما پاسخ دریافت کنند و این کامپوننت‌ها نیز بسته به پروژه، پیاده‌سازی متفاوتی داشتند ( این یکی مورد درست شده!). یک جلسه کامل از جلسات فرانت چپتر(در مورد فرانت چپتر‌مون از اینجا بخونید) رو به این اختصاص دادیم که بتونیم کامپوننت‌های مشترک رو شناسایی کنیم و نسخه کامل رو به YektaUI اضافه کنیم.از طرفی استایل‌ها و ظاهر تمامی پنل‌ها منحصر به فرد ه. پس یکی از چالش‌های تیم فرانت این بود که کامپوننت‌هایی رو ایجاد کنن که قابلیت کاستوم شدن رو داشته باشند و بتونند با تمامی پنل‌ها هماهنگ باشند. تم بوت‌استرپ (Bootstrap Theming) و استایل‌های scss آن، از جهت به کارگیری تنظیمات مختلف css ای در هر پنل، راه‌حل ما جهت شخصی‌سازی هرکدوم از پنل‌ها بود. رنگ‌بندی‌ها، سایزبندی‌ها و موارد مشابه را از طریق override کردن تم‌های اصلی به صورت پویا در هر پنل تغییر دادیم.۲.توابع مشترک و utilityهاتبدیل اعداد به حروف، نمایش اعدادی که نشان دهنده مبلغ هستند به صورت ویرگول‌گذاری شده. ارسال ریکوئست‌ها با درنظرگرفتن احزار هویت میانی مانند JWT و … مواردی بود که تقریبا در تمامی پنل‌ها از اون‌ها استفاده می‌شد. سعی کردیم این موارد رو نیز تا حد امکان به YektaUI اضافه کنیم.با این روند، به جای صرف وقت جهت پیاده‌سازی‌های متعدد، باعث شد تا وقت مورد نظر رو جهت بهینه کردن کارایی استفاده کنیم و یا برحسب نیاز تنها به افزودن فیچرهایی که موجود نیست بپردازیم.utility functions - حدف کاما و یا کاما‌گذاری مقادیر عددی۳.کد استایلEvery major open-source project has its own style guide: a set of conventions (sometimes arbitrary) about how to write code for that project. It is much easier to understand a large codebase when all the code in it is in a consistent style. -Google Style Guidesبا توجه به پویایی سازمان، و اینکه برنامه‌نویسای یکتانت پس از حل چالش‌های مربوطه در قسمتی که در اون فعالیت دارند ممکن است برحسب نیاز شرکت یا تمایل خودشون، به توسعه پروژه‌های دیگه شرکت که در حال توسعه است یا قراره توسعه‌اش شروع بشه مشغول بشن، لازم داشتیم تا یک استایل کد زدن یکسان و مناسب داشته باشیم و همچنین به این کد استایل وفادار بمونیم تا هنگام این جابه‌جایی، با مشکل و فوت وقت مواجه نشویم. در واقع عدم وجود این استایل موارد زیر رو به دنبال داشت:پایین بودن سرعت خوانایی کدعدم رعایت ثبات (consistency) استایل در بین تیم‌های مختلفمشخص نبودن سطح خطای کد (error, warning یا خطایی که disabled شده است)ابزارهایی که کمکمان می‌کردند تا به تمامی موارد بالا برسیم eslint و prettier بودند.ابزار eslint جهت مدیریت قواعد در javascript استفاده میشه. نهادها و سازمان‌های مختلفی قواعد درنظرگرفته خود را جهت استفاده توسط eslint منتشر کرده اند که میتوانید این موارد را دراین لینک بیابید.از جمله مزیت‌های eslint ایجاد قواعد و قوانین شخصی‌سازی شده یا custom است. در حین توسعه پروژه‌ها در سازمان نیاز داشتیم تا تعدادی قواعد شخصی‌سازی شده رو به این صورت به قوانین دیگه اضافه کنیم. نامگذاری کامپوننت‌ها و متغیرهای boolean از جمله مواردی است که نیاز به رعایت داشتند. این قواعد از ابتدای توسعه پروژه‌ها وجود نداشتند و با توجه به احساس نیاز و مطرح شدنش در یکی از جلسات چپتر فرانت تصمیم گرفتیم هرکدوم رو به قواعد مورد نیازمون اضافه کنیم و با مستندسازی این موارد در پلتفرم slite اون رو در بین تیم‌ها به اشتراک بذاریم.استفاده از استایل یکسان، باعث شد تا بتونیم با صرف زمان کمتری جهت درک کد،‌ به فهم نوآوری‌های استفاده شده در کد‌ها بپردازیم و کیفیت به عنوان مسئله اصلی در کدها بجای دغدغه نحوه کد زدن در اولویت قرار بگیره.مرج ریکوئست‌ها و روند تایید فیچر‌هااین پروژه در حال حاضر بر روی بستر داخلی یکتانت قرار داره و به صورت open source درنیومده. روند ایجاد تغییرات در YektaUI به صورت زیر ه:ایجاد branch و توسعه feature یا برطرف کردن bug در branch مربوطهایجاد درخواست merge requestانجام review کد توسط دو نفر از افراد دیگر فرانت و بیان بازخوردرفع نواقص و اعمال بازخوردهامرج با کد اصلی و ایجاد ورژن جدیدمرحله‌ای که در توسعه فنی شخصی افراد تاثیر جدی‌ای داشته و کیفیت کد‌ها را به مراتب چندین مرحله بهتر کرد، مرحله review کد‌ها بود. در ابتدای این امر، این کار توسط تنها یکی از اعضای فنی(علی محمدی) صورت می‌‌گرفت. اما با توجه به توسعه گسترده این کیت، تصمیم بر این شد تا reviewها به افراد مختلف واگذار شود که تاثیر به سزایی در تعامل افراد با یکدیگر با این کار صورت گرفت.دردم از یار است و درمان نیز هماحتمالا در هر سودی ضرری هم نهفته است. کلیت مزیت‌ها و مضرت(!)هایی که در توسعه این پروژه دخیل بودند رو میتونیم به موارد زیر خلاصه کنیم:مزیت‌هااشتراک‌گذاری کدهای مشترکتعامل فنی بیشتر کارمندان با یکدیگرافزایش کیفیت و کارایی خروجیتسریع در تغییرات مشترک بین پلتفرم‌های سازمانمضرت‌هانیاز به سپری شدن سلسله مراتبی از توسعه، جهت ایجاد و تایید تغییراتنیازمند صرف زمان جهت هماهنگی و ایجاد قواعد و مدیریت پروژهنیازمند صرف زمان جهت انتقال تمامی کامپوننت‌های پنل‌هاسرعت کم در تغییرات به دلیل عدم وجود تست‌ها برای کامپوننت‌هادر رابطه با سپری شدن سلسله مراتب مورد نیاز جهت ایجاد تغییر در کدها، با وجود اینکه ممکن است از سرعت توسعه در وهله اول کم بکنه، اما همین سلسله مراتب منجر به افزایش کیفیت کدها میشه. خالی از لطف نیست که بیان کنیم با گذشت زمان، سرعت انجام شدن این سلسله مراتب نیز افزایش یافته و انتظار می‌رود با صرف زمان‌های بیشتری در گسترش پروژه، زمان سپری شده توسط این سلسله مراتب نیز کاهش پیدا کنه.با توجه به اینکه یکتانت در حال رشد ه و برنامه‌های بیشتری جهت توسعه قسمت‌های مختلف پیش رو داره، زمانی که جهت هماهنگی و ایجاد قواعد این پروژه صرف میشه تنها مختص مراحل اولیه است و با تخصیص این وقت اولیه، در ادامه سهولت بیشتری رو ایجاد می‌کنه.کیت YektaUI اولین ابزاری هست که دولوپرها برای راحتی کار خودشان در یکتانت توسعه دادن و همین مورد development experience را برای دولوپرهای فرانت‌اند بالاتر برده و بعد از اون می‌تونند با دغدغه کمتری بر روی محصول یا مساله‌ی خاص خودشون وقت بذارند.با توجه به اهمیتی که در توسعه این پروژه ایجاد شد، قرار بر این شد تا افراد حاضر در یکتانت با عنوان front-end بتوانند ۲۰ درصد از زمان کاری خود را جهت توسعه این کار اختصاص بدن.در حال حاضر YektaUI در چه وضعیتی قرار دارد؟تا این لحظه که این مطلب در حال نوشته شدن است (اواسط مرداد ۹۹) YektaUI در حال توسعه داخلی در شرکت یکتانت است و تقریبا در تمامی پنل‌ها استفاده می‌شه.رهی به سوی مقصد عالی - آینده YektaUIمسیری که در جهت توسعه این کیت شروع شده احتمالا مسیر طولانی و جذابی خواهد بود. هدف نهایی ما توسعه ابزارهایی با سطح کیفیت عالی برای جامعه‌ی Vue فارسی است. اما برنامه‌ای که در برنامه‌ریزی کوتاه مدت برای توسعه این قسمت خواهیم داشت شامل موارد زیر ه:اضافه کردن استوری بوک(Storybook) و مستندسازی کامپوننت‌ها توسط آناضافه کردن تست توسط فریم ورک Jestاپن‌سورس کردن قسمت‌هایی که به تنهایی اختصاص به یکتانت نداشته باشندیکتانت - پیش به سوی بینهایت و فراتر از آناحتمالا باتوجه به مقاله با مقداری از چالش‌های سمت فرانت آشنا شده باشید اما تمرکز اصلی ما در تمامی پوزیشن‌ها، تعریف مسئله‌هایی است که در هنگام انجام تسک‌ها باهاشون برخورد میکنیم و سعی‌میکنیم به طور عمومی اون‌ها رو حل کنیم. انجام موارد با پیش‌فرض گفته شده، منجر به پیشرفت فرد و سازمان باهمدیگه میشه و به نظر خودم جذابیت رو برای هر دو طرف خواهد داشت. اگر علاقه‌مند بودی که در این حل مسئله‌ها با ما هم مسیر بشید میتونید از طریق موقعیت‌های شغلی یکتانت بیشتر از وضعیت‌های شغلی‌مون آگاه بشید. یکتانت | Yektanet علیرضا حیدری | Alireza Heydari Mon, 17 Aug 2020 01:26:55 +0430 https://virgool.io/yektanet/%DA%86%D9%BE%D8%AA%D8%B1-%D9%81%D8%B1%D8%A7%D9%86%D8%AA%D8%A7%D9%86%D8%AF-%D9%85%D8%B9%D8%B1%D9%81%DB%8C-%DA%86%D8%A7%D9%84%D8%B4%D9%87%D8%A7-%D8%AA%D8%AC%D8%B1%D8%A8%D9%87%D9%87%D8%A7-%D9%88-%D8%A7%D9%86%D8%AA%D9%82%D8%A7%D9%84-%D9%81%D8%B1%D9%87%D9%86%DA%AF-bglpkjrbeekj در استودیو یکتانت هستیم با حضور علی اسماعیلی، یکی از بهترین که نه ، تجربه خاصی هم نداره، بگیم یکی از جالب‌ترین و دوست‌داشتنی‌ترین فرانت‌اند دولوپر‌های شرکت یکتانت. به ما لطف‌کردند و توضیحاتی رو در رابطه با فعالیتشون در قسمت فرانت‌اند شرکت به خصوص در مورد «چپتر فرانت‌اند» ارائه می‌دهند که امیدواریم به کار تمامی بینندگان و شنوندگان عزیز بیاد. مصاحبه رو شروع می‌کنیم.- به نام خدا. چپتر دیگه چه کوفتیه؟:)) که بخوایم راجع به چپتر فرانت هم صحبت کنیم.فکر کنم دفعه صدم باشه که بهش اشاره می‌کنیم:دی آقا به خدا این مفهوم «چپتر» مال مدل سازمانی معرفی شده در قالب فرهنگ تیم مهندسی اسپاتیفای بوده. یعنی دفعه‌ اول اونا این حرکت رو راه انداختن و یه دفعه توی جهان خیلی بهش توجه شد و مقالاتی دربارش منتشر شد. مثلاً در ساده‌ترین حالت کتاب‌های تخصصی رو با همدیگه‌ می‌خونیم توی چپتر.(پ.ن : اسپاتیفای واقعا می‌تونه کعبه آمال یک دولوپر باشه...فکر کن اکانت رایگان اسپاتیفای میدن بهشون که پلی‌لیستا رو tune کنن. یه لحظه فک کن چقدر خوبه. آدم دوست داره رو پلی‌لیست بهترین‌های شماعی‌زاده کار کنه فقط:دی)- خب پس چپتر یعنی می‌نشینید چپتر چپتر کتاب علمی تخیلی می‌خونید دیگه؟نه عزیز من فقط کتاب خوندن نیست. بحث علمی و تخصصی هست، به نظرم شما اول پست مریم درباره چپتر پروداکت و توضیحات مقاله اسپاتیفای رو بخون یکم آشنا بشی با خود مفهوم چپتر تا من برات از چپتر فرانت‌اند بگم.توی چپتر فرانت‌اند ما مباحث مختلفی رو مطرح می‌کنیم اما اصل قضیه مفهوم چپتر فرانت‌اند اینه که توی شرکت تیم‌های مختلفی وجود داره که هر تیم نیروی فرانت‌اند خودش رو داره و خب این افراد دغدغه‌های مشترکی دارن، مسیر مشترکی دارن، نیازمندی‌های مشترکی دارن و گردهمایی این‌ها می‌تونه باعث هم‌افزایی بشه و از تکرار بیهوده (اختراع مجدد چرخ) جلوگیری کنه و چپتر فرانت‌اند مارو در ایجاد چنین فضایی کمک می‌کنه.- پس یکی فرانت‌اند کار نباشه ولی بخواد توی این مسیر یه چیزایی یاد بگیره هم‌ می‌تونه تو جلسات‌تون شرکت کنه؟خیر، ما برای عضویت و ورود به هر چپتر قوانینی داریم، قبل از اینکه چپترفرانت‌اند به وجود بیاد قوانینش بوجود اومد و قوانین چپتر فرانت‌اند میگه فردی که درخواست عضویت در چپتر رو میده باید حتماً توی شرکت موقعیت شغلی Front-end Developer داشته باشه، دوره آزمایشی‌ش توی شرکت رو طی کرده باشهدر ۶ ماه گذشته تمرکز کامل و ۱۰۰درصدی بر روی مباحث Front-end داشته باشهحتماً آینده‌ی مسیر شغلی خودش رو در همین حوزه ببینهبا این شرایط ما درخواست‌ها رو بررسی می‌کنیم و سعی می‌کنیم از تجربه افراد استفاده کنیم یا تجربه خودمون رو در اختیارشون بذاریم.- خب میشه بگی دقیقاً چیکار می‌کنین توی چپتر فرانت‌اند؟ شنیدم مثلا جاوااسکریپت می‌خونین، دیگه همه می‌دونن this یعنی "این". جلسه میذارید this رو یاد بگیرید که چی بشه؟ببین خب دانش پایه‌ای و اساسی توی خیلی از موارد بسیار ضعیفه و متاسفانه این م‍وارد رو هیچ‌کس توی هیچ مقطعی درست حسابی بهمون یاد نمیده. دانشگاه که خب اصلا به این موارد نمی‌پردازه. نیاز سازمان‌ها و شرکت‌ها هم معمولا منجر به این میشه که یک تسک رو خیلی سریع انجام بدیم، و وقت کافی داده نمی‌شه که یه مطلب رو خیلی اساسی و اصولی یاد بگیریم و ازش استفاده کنیم و منطقاً پاسخ‌گویی به نیاز بیزینس به یادگیری اصولی فرد به اجبار ترجیح داده میشه(که البته کار درستی هم هست). معمولا دولوپرها هم توی این شرایط وقتی می‌بینن یه چیزی کار میکنه سعی می‌کنن بسته به نیاز سازمان سریع ازش استفاده کنن و به اصطلاح همه چیز رو تجربی یاد می‌گیرند.این جلسات واقعا کمک می‌کنه تا مسائلی پایه‌ای مثل this رو عمیق و اصولی یاد بگیریم و اون‌ها رو در حد آکادمیک هم بلد باشیم تا برای انتقال به همدیگه و تحلیل مسائل مشکلی نداشته باشیم و برحسب حدس‌وگمان جلو نریم.- میخواین اصولی یاد بگیرین که چی بشه، کدتون رو بزنین خب.کجای دنیا این کار رو میکنن؟ببین خب فقط این مساله نیست. یکی از اهداف چپتر اینه که سطح دانش و تجربه خودمون رو ارتقا بدیم. یه بار با یکی از چپترلید‌های یک شرکت خارجی صحبت می‌کردم، ایشون داشت می‌گفت که ما اینجا بزرگترین مشکلمون اینه که افرادی که در یک سطح هستند هر کدوم به روش‌های مختلفی کارشون رو انجام می‌دن و درمورد مسائلی مثل (ساختار پروژه و فولدربندی، استراتژی‌های تست، lint و استفاده از ابزارهایی مثل typescript)هیچ استانداردی برای دنبال کردن ندارند، بعضی از دولوپرها هیچ ایده‌ای راجع به این مسائل ندارند و برخی دیگه هم به شکل و روش خودشون این کارها رو انجام میدن.وقتی دیدیم توی شرکت‌های آمریکای و اروپایی هم مشابه همین مساله هست و سطح دانش و تجربه افراد یکسان نیست و با هم‌آموزی میشه خیلی خیلی سطح دانش رو ارتقا داد و به هم نزدیک‌تر کرد، گفتیم چرا که نه، ما هم امتحانش کنیم و تست کردیم. اتفاقاً برای ما خیلی نتیجه و تاثیر خوبی هم داشت، مسائلی بودند که وقتی توی جمع یاد گرفتیم دیدیم چقدر یادگیری‌شون سریع‌تر، آسون‌تر و لذت‌بخش‌ بوده برامون. چقدر از اینکه یک مطلب رو با هم یاد گرفتیم و الان همه اون رو بلدیم احساس خوبی داریم. فارغ از این، بحث و گفتگویی که درباره حل مسائل شکل می‌گیره باعث میشه بعضاً چالش‌های جذابی داشته باشیم که فضای چپتر فرانت‌‌اند رو لذت‌بخش می‌کنه. البته توی جلسات‌مون کلا فضای جمع بی ریاست و آدمای خفن و از خودگذشته‌ای داریم که وجودشون برای هر تیم و شرکتی نعمت محسوب میشه و تمام سعی‌مون رو می‌کنیم قدردانشون باشیم.- گفتی شرکت‌های خارجی. اتفاقا من شنیدم این طرح اسپاتیفای مدل دیگه قدیمی شده، آماری ازش داری که توی جهان اصلا همچین چیزی هنوز هست یا نه؟یه چیز جالب براتون تعریف کنم از تجربه خودم.اتفاقاً من هم وقتی اول کار مشکلات چپتر رو دیدم و درباش خوندم برام سوال شد که آیا واقعا چیزی به اسم چپتر فرانت‌اند وجود خارجی هم داره؟ کی توی دنیا ازش استفاده می‌کنه و چیکار دارن می‌کنن توی چپترهاشون؟کاری که من کردم این بود، اومدم توی لینکدین و هر چی موقعیت شغلی Front-end chapter lead بود رو جستجو کردم و تقریباً به همه‌ی چپترلید‌های شرکت‌های خارجی توی لینکدین پیام دادم و ازشون خواهش کردم راجع به چپتر فرانت‌اند شون برام توضیح بدن. امیدی هم نداشتم که این کار به نتیجه برسه و خیلی بدیهی بود که وقتی ببینن من یه فرانت‌اند دولوپر از ایرانم جوابمو ندن. ولی خب تیری بود توی تاریکی، و اتفاقاً گرفت و جواب هم داد. خیلی واقعاً باید ازشون تشکر کنم که اکثرشون با خوش‌رویی جوابمو دادن و فضایی برام فراهم شد تا در مورد چپتر فرانت‌اند باهاشون گفت و گو کنم و از تجربیات‌شون استفاده کنم.این رو هم باید بگم که من سطح زبان خیلی خوبی هم ندارم:دی. حداقل هیچ مدرکی توی زبان ندارم و احتمالاً توی پیامم بهشون کلی هم خطا داشته باشم که احتمالا چون منظورم رو رسوندم لطف کردن بهم و اشکالاتم رو نادیده گرفتند. می‌خوام بگم نترسین از اینکه با آدم‌ها صحبت کنید، نترسین از اینکه اشتباه کنید. من خودم به شخصه خیلی خوش‌حال می‌شم اگه کسی علاقه داشت راجع به این مسائل توی لینکدین پیام بده یا توی کامنت‌های پست و با هم گپ بزنیم.بعد از اینکه با تجربیات شرکت‌های خارجی آشنا شدم و نکات مفیدشون رو توی چپتر فرانت‌اند‌مون بکار گرفتم، شروع کردم به دوست‌هام توی شرکت‌های مطرح ایرانی هم پیام دادم و تا جایی که تونستم باهاشون ارتباط گرفتم و صحبت کردم و اون‌ها هم خیلی بهم کمک کردند و سعی کردم از تجربیات مفیدشون در این زمینه استفاده کنم.به طور خلاصه می‌تونم بگم اکثر کارهایی که توی دنیا توی چپتر‌های فرانت‌اند انجام می‌شه به شکل زیر هست:به کارگیری استاندارد‌ها و Best Practice ها در حوزه فرانت‌انداستفاده از ابزارهایی که باعث میشه کد‌های فرانت‌اند سطح بالاتری داشته باشند و به دولوپر کمک می‌کنه تا سرعت کارش و کیفیت نهایی رو بالاتر ببرهطراحی یک Design system یا UI Kit داخلی و اختصاصی برای استفاده داخلی تیم‌های شرکتگرفتن تصمیم‌های استراتژیک در حوزه فرانت مربوط به شرکتافزایش قدرت حل مساله و اعتماد به نفس میان فرانت‌اند دولوپر‌هابرگزاری کارگاه‌های آموزشی فرانت‌اند برای افزایش دانش و بهبود عملکرد افرادهمفکری، همکاری و ایجاد محیط صمیمانه و اصولی برای استفاده تجارب مفید همدیگه- چقدر جالب. حالا یه مثال واقعی میزنی از کارهایی که شما انجام می‌دین توی چپتر فرانت‌اند؟مثلا یکی از کارهایی که کردیم اینه که شروع کردیم خیلی مدون و برنامه‌ریزی شده کتاب خوبYou Dont Know JSرو بخونیم تا عمیق‌تر و اصولی‌تر با جاوااسکریپت آشنا شیم. یادمه یه روز داشتیم یه مبحث رو می‌خوندیم و یکی از بچه‌ها همون موقع چیزی که کتاب گفته بود رو توی کنسول مرورگرش اجرا کرد و گفت آقا این جوابی که کتاب میگه نیست و خروجی من یه چیز دیگست! از اون لحظه به بعد دیگه ما همیشه همه دانش‌مون و چیزهایی که می‌خونیم رو زیر سوال می‌بریم و حواسمون هست که در محیط‌های مختلف اجرای جاوااسکریپت مثل کنسول مرورگر، اجرا توسط nodejs، اجرای کد با استفاده از polyfill babel و اینکه حالت use strict هست یا نه رو تست کنیم و خروجی‌های مختلف در محیط‌های مختلف رو ببینیم. خیلی وقت‌ها مثال‌های کتاب با خلاقیت بچه‌ها به حالت‌های پیچیده‌تر و جذاب‌تری تبدیل میشه و سعی می‌کنیم به یک منبع اکتفا نکنیم.به غیر از خوندن کتاب هر هفته یک ارائه داریم و ترندهای روز دنیای فرانت‌اند رو دنبال می‌کنیم. یا مثلا مسائلی که معمولاً کمتر پیش میاد توی پروژه‌هامون به صورت عمیق‌ براش وقت بذاریم(مثل بهبود performance در فضای وب) رو عمیق‌تر بررسی می‌کنیم.- پس سکان هدایت جلسه رو شما به دست می‌گیرید و بقیه بالشت‌شون رو میارن بخوابن دیگه؟نه اصلاً، سعی‌مون اینه که اینطوری نباشه. درسته جلسه‌اس ولی خب از این جلسات بیهوده و بی‌فایده نیست. توی جلسات ما هر فرد یک نقش رو بر عهده داره و وظایفی که بهش محول شده رو انجام میده. قرار نیست یک سخنرانی یک طرفه داشته باشیم. همه باید مشارکت کنند. توی لحظات چپتر یا داری یاد میگیری یا داری یه مطلب رو به بقیه یاد میدی. یکی از نقش‌هایی که توی چپتر وجود داره نقش چپترلید هست که واقعا به قول دوستان این نقش باید توی هر شرکت بازتعریف شه و بر اساس نیازهای شرکت بازبینی و بهینه بشه. چپترلید وظیفه داره با شناخت نیازمندی‌های شرکت، با همکاری و همفکری اعضای چپتر برای رسیدن به اهداف و پاسخ‌گویی به نیازهایی شرکت در زمینه خاص چپتر برنامه‌ریزی کنه.- تو این شرایط دورکاری هم که دیگه همدیگه رو نمی‌بینید پس جلساتم که کنسل شده. چه کاری بود خب پس. نذارید کلا دیگه.هوم؟اره...منم روز اولی که شرکت تعطیل شد به خاطر کرونا رو خوب یادمه! فرداش قرار بود چپتر فرانت‌اند داشته باشیم. خیلی غصه خوردم که خب این هم به خاطرات پیوست و دیگه رفت که رفت. اما خب بعد از یه استراحت کوتاه واقعا چپترفرانت‌اند رو دوباره از سر گرفتیم و اتفاقاً پرقدرت‌تر و با تجربه‌تر از قبل ادامه دادیم وحتی رویکرد شرکت هم عوض شد و متوجه شدیم که این جلسات می‌تونه کارایی بیشتری توی این شرایط برامون داشته باشه و قرار شد حتی وقت بیشتری صرف چپتر بکنیم. با یه برنامه‌ریزی مدون تونستیم به صورت آنلاین جمع‌ دوست‌داشتنی‌مون رو حفظ کنیم. اتفاقاً جلسات چپتر تا حالا خیلی سنگین‌تر از حالت حضوری برگزار شده و فکر می‌کنم از نظر مفید بودن و کارایی هم خیلی بهتر شده و کرونا این فرصت رو بهمون داد تا به شکل دیگه‌ای جلسات رو پیش ببریم.- خب اینجوری که این جلسات سنگینه خب معلومه من شرکت نمی‌کنم. به تسک‌های شرکت نمیرسم که. [هم جلسات را شرکت نمی‌کند، هم تسک‌های شرکت را انجام نمی‌دهد].حضور در چپتر و انجام فعالیت‌های چپتر بخشی از تسک‌های بچه‌ها توی شرکت هست و قرارمون فعلاً این هست که ۲۰ درصد زمان کاری هر یک از بچه‌های فرانت به چپتر فرانت‌اند اختصاص داده شود تا بتونیم از فایده‌های چپتر فرانت‌اند بیشتر استفاده کنیم.- ۲۰ درصد؟!! چه خبره مگه! بگو یه دفعه دیگه کار نکنن شرکت‌ها و بیان همش جلسه بذارن دیگه. اصن هزینش به فایده‌اش می ارزه؟من نگفتم همه‌ی شرکت‌ها و همه‌ی چپتر ها باید ۲۰ درصد از زمانشون رو بذارن برای چپتر. خود ما هم قبلاً این کار رو نمی‌کردیم و در وضعیت فعلی می‌خوایم تست‌اش کنیم.در مورد فایده چپتر باید بگم اگه چپتر خوب برگزار بشه واقعاً به همه‌ی هزینه‌هاش می ارزه آره.نمیشه گفت چه فایده‌هایی رو می‌توان برای چپتر متصور شد، به نظر من باید حتماً فایده چپتر رو توی وضعیت شرکت و شرایط تیم دید و براش برنامه‌ریزی کرد. هیچ نسخه درستی وجود نداره و هر شرکتی باید با توجه به نیازش از مفهومی به عنوان چپتر استفاده کنه و خب هر چقدر بهتر استفاده کنه می‌تونه بیشتر تاثیرش رو ببینه، آموزش، اشتراک تجربه و رشد و ارتقا سطح افراد موضوعاتی هست که گاهی خیلی زیاد براش هزینه میشه اما به نتیجه‌ای نمی‌رسه، ما تونستیم به وسیله چپتر نتایج خیلی خوبی ازش بگیریم.فواید چپتر هم کوتاه‌مدت هست و هم بلند مدت. و در مورد موضوعات و روش چپتر حتما باید به نیروهای شرکت، فرهنگ سازمانی شرکت و از همه مهم‌تر نیاز شرکت نگاه کرد. مثلا ً من با یکی از چپترلید‌های شرکت‌های اروپایی که صحبت می‌کردم توی توضیحاتش اشاره‌ای به آموزش نکرد و وقتی من توضیح دادم چپترهامون رو گفت خب اینجا دوره‌های خیلی خیلی با کیفیتی به راحتی در اختیار افراد هست و در ساعات بعد از ساعت کاری برگزار میشه و یک ساعته هست با مدرسانی مجرب و آموزش دیده و معمولاً برای ارتقا دانش و یادگیری توی اون‌ها شرکت می‌کنند که هم حرفه‌ای تره و هم بازدهی بیشتری داره و همچین نیازی توی اون شرکت وجود نداشته که اینطوری آموزش بذارن و البته فرهنگ دیگه‌ای داشتند و یک روز در سال رو به آموزش درون شرکتی اختصاص می‌دادند.- خب برگردیم به جلسات چپتر، اونوقت اون خفنای فرانت‌اند و افراد تازه‌کار رو تو یه جلسه قرار می‌دید؟ دوئله؟قطعا در بسیاری از موارد پیش میاد که سطح افراد حاضر در جلسه متفاوت باشه. سعی میشه که افرادی که از سطح بالاتری برخوردارند اطلاعاتشون رو دراختیار بقیه افراد قرار بدن و بتونن فاصله سطح علمی بین خودشون و افراد دیگه رو کم بکنند. این رابطه دوطرفه است و افراد تازه‌کار هم ممکنه با قسمت‌های بدیعی از تکنولوژی‌ها آشنا باشن که بتونن با افراد دیگه به اشتراک بذارند. باوجود تفاوت‌های احتمالی ولی در وضعیت فعلی چپتر‌ها افراد با هم در یک جلسه حضور دارند و به نظر تعادل افزایش اطلاعات برای هر دو گروه به خوبی رعایت شده. ممکنه در آینده با توجه به تعداد افراد و فاصله بین سطح توانایی افراد این جلسات هم به چندین چپتر مجزا تقسیم بشه.- شنیده‌ها میگن که بچه‌ها رو مجبور می‌کنید یه ریویو از کارهای هفته‌شون بگن تا اگه کم کاری کردن دهنشونو تمیز کنید. درسته؟آره یک بخش از چپتر به اشتراک تجربه و باخبر شدن از کارهای هم‌دیگه است. یکی از چالش‌هایی که توی چپتر داشتیم همین اشتراک تجربه و گزارش‌ کارهای هفته بود. واقعا از بیهوده‌ترین و کسل‌کننده‌ترین کارهایی که اوایل به اشتباه انجام می‌دادیم همین اشتراک تجربه به شکل نادرست بود. اوایل اینطوری بود که هر فرد ۱۵ دقیقه وقت داشت و باید کارها و چالش‌هاش رو در هفته گذشته توضیح می‌داد. تقریبا وقت خیلی زیادی ازمون میگرفت و جلسه‌ ۲ساعته‌مون بدون خروجی خاصی تموم می‌شد.- پس شما هم جلسات خسته‌کننده داشتین، برای این چالش چیکار کردین؟شرحش خیلی مفصله. اما باید بگم جمله اول این مقاله (Meetings suck. It’s a universally accepted truth) انقدر جذبم کرد که تا اخرشو خوندم و به شما هم توصیه می‌کنم حتما اگه جلسات کسل‌کننده دارین کامل بخونینش و روش‌تون رو عوض کنید تا جلسات بهتری داشته باشین.خلاصه شو من براتون بگم ما سعی کردیم اون مدل جلسات‌مون رو تغییر بدیم و به جای اون روش قبلی، یه برنامه ریزی جدید داشته باشیم و الان زمانبندی چپترفرانت‌اند به این صورت شده که زمان یک ساعت و نیم چپتر رو اینطوری می‌گذرونیم:۱۰ دقیقه اول مستند کردن کارهای هفته گذشته برای به اشتراک گذاری با بقیه داخل ابزار مستندسازی‌مون اسلایت.۱۰ دقیقه دوم جلسه هر کس، کارهای نوشته شده توسط بقیه رو می‌خونه و نکات جذاب یا سوالی که داره رو یادداشت می‌کنه تا بپرسه.۲۵ دقیقه بعدی(البته این زمان متغیر هست و تا ۴۰ دقیقه ممکنه طول بکشه بستگی به کارهای هر هفته‌مون داره) هر کس به سوالی یا نکته‌ای در مورد کارهای خودش یا بقیه اشاره می‌کنه و در موردش صحبت می‌کنیم.۴۵ دقیقه بعدی رو به محتوای آماده شده برای هر جلسه می‌پردازیم که ممکنه در مورد خوندن کتاب یا مقاله یا مثلاً ارائه یک مطلب آموزشی توسط بچه‌ها باشه یا ممکنه در مورد برنامه ریزی برای کارهای UI Kit فرانت‌اند شرکتمون، بررسی یک چالش فرانت در سطح پروژه‌های شرکت و تصمیم‌گیری در مورد استفاده از یک ابزار، روش، استاندارد یا چیزهایی از این دست باشه.البته باید بگم این تغییرات و پیشرفت ما قطعا با یه مقاله خوندن اصلاح نشده و نمیشه. شعاره اگه اینو بگیم.- یعنی اشتراک تجربه‌تون همه‌ش تو جلسه است؟ من یه هفته باید صبر کنم تا بیای به من نکته جدید بگی؟‌بیکارم؟ من الان میخوام بدونم خب.ببین در واقع ما اومدیم هر ابزار و نیروی کمکی که می‌شد رو به کار گرفتیم تا چپترمون رو بهتر کنیم.در جواب سوالاتت باید بگم که نه لازم نیست صبر کنی تا روز چپتر. ما یه ابزار مستندسازی داریم که همگی توی اون نکات مهم‌شون، تصمیم‌ها و دستاوردهای ارزشمندشون و آموزش‌هامون رو مستند می‌کنیم. در کنار این یه گروه تلگرامی برای چپتر فرانت داریم که در هر لحظه می‌تونی توش پیام بدیم به هم‌دیگه‌ و همکارانمون رو ببینیم که با شوق به سوالات‌مون جواب میدن و همگی به هم کمک می‌کنن تا مسائل رو حل کنیم، اشتراک دانش و آموزش‌های کوتاه داشته باشیم و خلاصه اینکه رفرنس بدیم به ابزار مستندسازی‌مون.حول صحبت‌ها و سوال‌ها توی گروه تلگرامی بحث شکل می‌گیرد و با هم مشورت می‌کنیم.به اشتراک‌گذاری تجربیاتآموزش و استاندارد کردن ساختار پروژه‌ها- “یه سوال، چرا تو چپتر با خشونت برخورد می‌کنید؟”خب باید بگم:دی “در مواقع بسیاری عصبانیت نشانه سلامتی است.“تا حدی که نکشتت قوی‌ترت می‌کنه. ما توی چپتر واقعاً جدی هستیم. دوست داریم چپترهامون واقعاً مفید باشه. درسته که فضای صمیمی‌ای حاکم هست بر جو چپتر و همه‌ی کارها رو با کمک همدیگه و نظر همه‌ی افراد انجام می‌دیم (و نظر چپترلید به تنهایی مهم نیست:دی) ولی خب یک نفر باید مسئولیت برگزاری جلسات و برنامه‌ریزی چپتر رو بر عهده بگیره و اولویت‌ها رو مشخص کنه. دوست نداریم فضای چپتر بره به سمتی که صرفا یه دورهمی ساده و راحت باشه و چالشی برامون نداشته باشه. دوست داریم به همه‌ی اهداف چپتر برسیم.- این‌همه گفتی اهداف، هدف چپتر چیه اصلا؟توی هر شرکتی بسته به نیازهای سازمان هدف‌های مختلفی برای چپتر در نظر گرفته میشه، اما فعلاً چپتر فرانت‌اند ما این اهداف رو دنبال می‌کنه:استفاده از تجربیات هم‌دیگه و جلوگیری از تکرار بیهوده برای حل کردن مسائل یکسان در پروژه‌های مختلفتولید source code ها یا کامپوننت‌های به درد بخور و قابل استفاده در سایر پروژه‌ها.ارتقا سطح دانش فنی و تخصصی افراد چپتر و به‌روز نگه داشتن افراد و دوری از ماندگاری در یک سری موضوع و چالش خاص و محدود.ایجاد محیطی برای همکاری صمیمانه، گپ و گفت تخصصی، آموزش حرفه‌ای، افزایش جنبه‌های لذت بخش کار.(بچه‌ها حال کنن:دی)- خب اگه اینطوری که می‌گین به پیشرفتتون کمک کرده و به اهداف‌تون رسیدین تا حدی، یه خروجی به ما نشون بده.ایشالا با همت بچه‌های فرانت‌اند شاهد انتشار خروجی‌ها و دستاوردهامون در بلاگ فنی یکتانت خواهیم بود(بلاگ ما رو و من رو دنبال کنین:دی) .ایشالا در ادامه یه روزی در موردUI Kit فرانت شرکتمون (Yekta-UI) هم صحبت‌ می‌کنیم و نمونه‌هایی از مستندسازی‌های مفید داخلی‌مون رو در کیفیت قابل قبول به اشتراک می‌گذاریم.- با تشکر. صحبت پایانی؟منم ممنونم از وقتی که اختصاص دادین.قطعا شرکت‌های دیگه‌ای توی ایران هم ممکنه در موضوعات مختلف جلساتی تحت عنوان چپتر داشته باشند، خیلی خوبه که اگه روش‌های متفاوتی دارند بیان راجع بهش صحبت کنند و تجربه‌شون رو به اشتراک بذارن. شما هم اگه توی شرکت‌تون چپتر فرانت‌اند دارین حتما توی نظرات بنویسین و بگین بهمون، خیلی دوست دارم راجع بهش صحبت کنیم.خب حالا که تا اینجا زحمت کشیدین خوندین یه سری منبع هم براتون معرفی کنم:رفرنس‌هایی به مقالات و بلاگ‌های شرکت های خارجی و پست‌هایی مرتبطhttps://dropbox.tech/frontendhttps://labs.spotify.com/https://medium.com/airbnb-engineeringhttps://blog.developer.atlassian.com/https://engineering.clever.com/https://blogs.dropbox.com/tech/Spotify engineering cultureHow We Kickstarted Our Frontend/JS Chapter Event SeriesThe “Spotify Model” in FavroHow to Build Your Own “Spotify Model”&amp;amp;amp;amp;lt;br/&amp;amp;amp;amp;gt; شما هم اگه منبع خوبی می‌شناسین یا بلاگ خاصی رو توی فرانت‌اند دنبال می‌کنین حتماً بهمون معرفی کنید.پایان. یکتانت | Yektanet A.E Sat, 08 Aug 2020 20:28:20 +0430 https://virgool.io/yektanet/%D9%BE%D8%A7-%D8%A8%D8%B2%D9%86-%D8%A2%D8%B4%D8%BA%D8%A7%D9%84-%DA%86%DA%AF%D9%88%D9%86%D9%87-api%D9%87%D8%A7%DB%8C-%D8%B3%D8%B1%DB%8C%D8%B9%D8%AA%D8%B1-%D8%AF%D8%B1-drf-%D8%AF%D8%A7%D8%B4%D8%AA%D9%87-%D8%A8%D8%A7%D8%B4%DB%8C%D9%85-pvptundmb8tc من تو این مقاله می‌خوام از تجربیاتی که تو بهبود پرفورمنس چند تا API داشتم بگم. این APIهایی که من درگیرشون بودم اکثرشون توسط سرویس‌های خودمون صدا زده می‌شدند و فقط یکی‌شون از طریق کلاینت(پنل تبلیغ‌کننده یکتانت) استفاده می‌شد. اکثر APIها حدود ۳ تا ۴ برابر سریع‌تر شدند.مسئله چیه؟پایتون، جنگو و جنگورست‌فریم‌ورک معمولا به اندازه‌ی کافی سریع هستند ولی وقتی محصول بزرگ‌تر می‌شه قضیه فرق می‌کنه و درگیر بهینه کردن هر کدوم از این تکنولوژی‌ها می‌شیم. به طور جزئی‌تر بخوام بگم ما در سریالایز شدن آبجکت‌ها در استفاده از ListSerializer جنگو‌رست‌فریم‌ورک مشکل داشتیم. چرا کنده؟در اکثر موارد مرسوم دلیل کند بودن دیتابیسه و خب با ایندکس گذاشتن و درست کوئری زدن خیلی از مشکلات حل می‌شه ولی مشکلی که ما داشتیم اکثرا از جنس دیتابیس نبود. من اول یه سری از مشکلات بدیهی‌تر تو جنگو که ممکنه بهش برخورد کنید رو می‌گم و بعدتر یه ذره با جنگورست‌فریم‌ورک وَر می‌رم.بنابر حجم دیتا و ساختار مدل‌ها دلیل کند بودن می‌تونه متفاوت باشه، چند تا از مشکلات مرسوم رو من لیست کردم.مشکل N+1 کوئریاولین مشکلی که معمولا بهش برمی‌خوریم مشکل N+1 کوئریه. این مشکل وقتی پیش میاد که ما تو کوئری که اول می‌زنیم آبجکت از نوع X رو می‌گیریم ولی بعدا به ازای هر آبجکت از نوع X نیاز به کوئری زدن به جدول Y داریم. در این صورت داریم N+1 کوئری می‌زنیم که می‌تونستیم با یک کوئری جوین این مشکل رو حل کنیم. راه‌حل‌هایی که جنگو واسه این مشکل داره select_related و prefetch_relatedئه. select_related یک کوئری جوین می‌سازه و دیتا رو با یک کوئری می‌گیره ولی prefetch_related این کار رو با پایتون انجام می‌ده یعنی جوین تو پایتون انجام می‌شه. select_related رو وقتی نیاز به یک آبجکت اضافه‌تر داریم استفاده می‌کنیم. یعنی استفاده‌ی مستقیم از ForeignKey و OneToOne یا استفاده‌ی برعکس از OneToOne. دلیل این کار هم اینه که وقتی مثلا ما یک جوین ManyToMany می‌زنیم آبجکت‌ها تکرار می‌شن و این تکرار هزینه‌بره. در این مواقع ما از prefetch_related باید استفاده کنیم که به جای یک کوئری جوین، یک کوئری به ازای هر رابطه می‌زنه و با این کار حواسش هست که ما آبجکت تکراری نسازیم. پس prefetch_related رو برای ManyToManyها و استفاده برعکس از ForeignKey می‌تونیم استفاده کنیم.برگردوندن کامل آبجکتممکنه آبجکت‌هایی که ما داریم خیلی بزرگ باشن و خب برگردوندن کامل‌شون هزینه‌بر باشه و خب این مشکل با استفاده از تابع only و defer می‌تونه حل بشه. متد only فیلد‌هایی که ما نیاز داریم رو بهش می‌گیم و فقط همون‌ها رو برامون میاره و متد defer فیلد‌هایی که نیاز نداریم رو برامون نمیاره. دقت کنید که این تابع‌ها یه آبجکت از کلاس رو برمی‌گردونن و اگر بخوایم به فیلدی دسترسی داشته باشیم که از قبل مشخص نکردیم، دوباره به دیتابیس کوئری می‌زنند. متد values البته از دوتای بالا‌ سریع‌تره. values یک کوئری‌ست برمیگردونه که شامل دیکشنری‌هاست که کلید‌های هر دیکشنری آرگومان‌هایی هستند که ما به متد values پاس دادیم.تبدیل کوئری به آبجکت و آبجکت به Jsonروندی که دیتا حرکت می‌کنه به این صورته که اول از دیتابیس تبدیل به آبجکت‌های مدل جنگو میشه و بعدش تبدیل به دیتا‌تایپ‌های اولیه(Primitive) می‌شه تا به عنوان خروجی برگردونده بشه. ما برای پرفرومنس بهتر می‌تونیم با استفاده از va‍lues مستقیم کوئری رو تبدیل به دیکشنری کنیم تا هزینه‌ی کمتری در این فرایند بدیم. اگه مشکل با این چیزها حل نشد شاید بد نباشه یه ذره با سریالایز‌های جنگو‌رست‌فریم بازی کنیم ببینیم چی میشه. شاید یک چاره‌: محاسبه‌ی کل دیتا در View و پاس دادن دیتا به سریالایزرما می‌تونیم دیتا رو تو View به روشی که می‌دونیم سریعه بگیریم و به سرایالایز بگیم که با این دیتایی که ما به دست آوردیم کار کن به جای اینکه خودت بری حساب کنی. استفاده از متد values برای بدست آورن دیتا هر سه تا مشکل بالا رو حل می‌کنه. یا مثلا در حالت‌های خیلی خاص می‌تونیم از Raw کوئری استفاده کنیم.برای همچین کاری نیازه که متد to_representtation کلاس ModelSerializer رو override کنیم. و در این حین می‌تونیم کارهای اضافه‌ای که جنگو‌رست‌فریم‌ورک می‌کنه و پرفورمنس رو کم می‌کنه حذف کنیم. :Dما یه کلاس جدید به اسم ContextModelSerializer می‌سازیم و از ModelSerializer ارث می‌بریم. https://gist.github.com/kamyab98/9b31773270f9018e8d1561c91fdeac1a و اینجوری ازش استفاده کنیم. https://gist.github.com/kamyab98/e90d04dd07e8afb59f06b88be82337cc https://gist.github.com/kamyab98/4d6513758f86e1afdd4a24b8aa4b9803 می‌تونیم کار‌های جالب دیگه‌ای هم بکنیم، مثلا یه بخش دیتا رو از Context سریالایزر بگیریم و بقیه‌اش رو بذاریم خود DRF هندل کنه. واسه این کار می‌تونیم به Meta کلاس‌ سریالایزمون یه فیلد context_fields اضافه کنیم و بگیم که این فیلد‌ها رو از دیتا کانتکس بخون و بقیه رو همونجوری که قبلا بدست می‌آوردی به دست بیار. https://gist.github.com/kamyab98/74b2861b52ff1cd4f86f189419484705 خیلی وقت‌ها ممکنه مدل‌های ما پیچیده‌تر باشند، مثلا یک رابطه‌ی ManyToMany داشته باشیم. در این موارد احتمالا نیاز داریم که از ساختارداده‌های مناسب هم استفاده کنیم.این مثال رو در نظر بگیرید. https://gist.github.com/kamyab98/b1ca925d5a3843e97bd6092b17e41ca0 https://gist.github.com/kamyab98/5b32e7a814d56ee4f235d9abe8660910 در مثال بالا داریم دو بار کوئری می‌زنیم. اگه کند بود برامون، می‌تونیم کمترش کنیم ولی اگه نیازی نبود پیچیده کردن کد ارزشش رو نداره به نظرم.ولی خب در نهایت با استفاده از روش بالا ما خوشحال بودیم و از این ContextModelSerializer چند بار استفاده کردیم و:چند نکته‌ی اضافه‌ترآپدیت کردن پکیج‌ها رو همیشه در نظر داشته باشید، اگه ورژنی که استفاده می‌کنید قدیمیه ممکنه با آپدیت کردن، بدون هزینه‌ی خاصی به پرفورمنس بهتری برسید. من وقتی داشتم دنبال روش‌های بهبود پرفورمنس می‌گشتم، به چند تا «چیز» رسیدم که تو ورژن‌های جدیدتر جنگو‌رست‌فریم‌ورک معتبر نبود چون اون «چیز»ها حل شده بودن.سعی کنید کوئری‌هایی که داره زده می‌شه رو به صورت Raw ببینید و بررسی کنید که جایی کار غیربهینه‌ای انجام نده. (برای این کار پراپرتی query رو روی کوئری‌ست می‌تونیم صدا بزنید.) همین‌طور مهمه که چک کنید چندبار دارید کوئری می‌زنید، برای مثال در صورتی که از django-filters و ContexModelSerializer استفاده کنید ممکنه که چند بار کوئری زده بشه که می‌تونید، یک بار بزنید و اون مقدار رو کش کنید.معمولا تمرکز رو پرفورمنس کد باعث می‌شه کد کثیف‌تر بشه اگر نیازی بهش ندارید، انجام ندید! یا به قول Donald Knuth که می‌گه :«Premature optimization is the root of all evil» و وقتی به مشکل خوردید، با علم اینکه کجا پرفورمنس بدی داره برید سراغش.راستی من کامیاب بودم، مهندس نرم‌افزار تو یکتانت. اگه خواستید می‌تونید فرصت‌های شغلی‌مون رو یه نگاه بندازید. یکتانت | Yektanet کامیاب زارع Mon, 27 Jul 2020 15:12:45 +0430 https://virgool.io/yektanet/%D8%A2%DB%8C%DB%8C%D9%86%D9%87%DB%8C-%D8%A7%D8%B3%DA%A9%D9%86%D8%AF%D8%B1-%D9%85%D9%81%D8%A7%D9%87%DB%8C%D9%85-%D9%BE%DB%8C%D8%B4%D8%B1%D9%81%D8%AA%D9%87-%D8%AF%D8%B1%D8%A8%D8%A7%D8%B1%D9%87%DB%8C-%D8%A7%D9%90%D8%B3%D8%AA%DA%A9%D9%90-%D8%A7%D9%90%D9%84%D9%8E%D8%B3%D8%AA%DB%8C%DA%A9-t5x7mrusouz0 مقدمهاگر با استک الستیک آشنایی ندارید ابتدا خوندن این پست رو بهتون توصیه می‌کنم.این نوشتار از دو بخش تشکیل شده؛ در بخش اول «تجربه‌ی ما» از معماری استک قدیمی خودمون توی یکتانت صحبت می‌کنیم،‌ چالش‌هایی که داشت رو بررسی و معماری جدید رو معرفی می‌کنیم و در بخش دوم «بایدها و نبایدها در تنظیمات ELK، فوت کوزه‌گری!» یه سری نکات کلی راجع به استک الستیک رو مورد بررسی قرار می‌دیم که موقع بالا آوردن استک باید به اون‌ها توجه بشه.تجربه‌ی ماتصور کنید که به عنوان نیروی SRE توی یک شرکت استخدام شدید و اولین وظیفه‌ای که دارین اینه که استک قبلی شرکت رو به یک استک جدید منتقل کنید و کاری کنید که قابل اتکا باشه و بشه در مقیاس بالا ازش استفاده کرد؛ واکنشتون چیه؟ واکنش من:تصویر ۱ - واکنش من به اولین وظیفه‌ام من جواد علی‌پناه هستم. مدتیه که در شرکت یکتانت به عنوان نیروی SRE مشغول به کار شدم و قراره توی این نوشتار براتون از تجربیاتم روی استک الستیک و موارد مهم راجع به تنظیمات اون بگم. اگر هم براتون سوال یا ابهامی پیش اومد خوشحال می‌شم زیر این نوشته کامنت بذارید.معماری قدیمیوقتی من وارد یکتانت شدم دیدم که بعضی از تیم‌ها از استک الستیک استفاده می‌کنن؛ باقی تیم‌ها هم وسوسه شده بودن که سمتش بیان و جوّ غالب استفاده از امکانات جذاب این تکنولوژی بود. سؤالی که وجود داشت اما این بود که آیا معماری فعلی برای استفاده همه‌ی تیم‌ها مناسبه؟ مناسب به این معنی که ۱. تیم‌ها بدون درد و خون‌ریزی و در مدت زمان خیلی کم بتونن لاگ‌هایی که داشتن رو به الستیک بفرستن و ازش استفاده کنن ۲. استک موجود کشش اضافه شدن تیم‌ها رو داشته باشه ۳. تیم‌ها بتونن لاگ‌ها رو به هر فُرمتی بفرستن و در هر زمانی این فرمت بتونه تغییر کنه.برای اینکه یه دید کلی از معماری قدیمی داشته باشید تصویر ۲ رو نگاه کنید:تصویر ۲ - معماری قدیمیهمونطور که توی تصویر می‌بینید توی این معماری روی هر سرور یک نسخه فایل‌بیت وجود داره که فایل لاگ سرویس رو می‌خونه و اون رو به لاگ‌استش Forward می‌کنه؛ لاگی که به دست لاگ‌استش می‌رسه بدون ساختار هست پس لاگ‌استش باید اون رو Parse کنه و به فرمت JSON در بیاره و بعد برای الستیک‌سرچ بفرسته. در انتها کاربر از طریق کیبانا برای داده‌ها داشبورد می‌سازه و اون‌ها رو به صورت نمودار و چارت مشاهده می‌کنه.معماری جدید ؟سوال مهمی که ابتدای کار برای ما وجود داشت این بود که آیا به معماری جدیدی نیاز داریم یا نه؟معایب معماری قدیمی:اضافه کردن تیم جدید کار زمان‌بر و پرهزینه‌ای بود؛ چون به ازای هر تیم جدید باید تنظیمات لاگ‌استش رو تغییر می‌دادیم تا لاگ‌ها رو بگیره، به فرمت مناسبی برای الستیک‌سرچ تبدیل کنه و اون‌ها رو به الستیک‌سرچ تحویل بده. یک لاگ‌استش مرکزی به عنوان Parser و Forwarder وجود داشت که هم داده‌ها رو Parse می‌کرد و هم اون‌ها رو به الستیک‌سرچ می‌فرستاد؛ همچنین با توجه به مورد قبلی تغییرات در تنظیمات اون امری متداول و اجتناب ناپذیر بود و تبدیل به یه غول بزرگ داخل استک شده بود که همه چیز به اون وابسته بود.نزدیک به ۱۰۰٪ لاگ‌ها بدون ساختار (Unstructured) بودن و تغییر در فرمت اون‌ها به وفور اتفاق می‌افتاد.تعداد شاردها و ایندکس‌های الستیک‌سرچ به سرعت در حال افزایش بود و همین کارکرد سرویس رو به شدت تحت تأثیر می‌ذاشت.به صورت آزمایشی بالا اومده بود و بعضا تنظیمات اولیه‌ی نادرست موجب کاهش عملکرد و سخت‌تر شدن فرآیند نگهداری شده بود.برای موارد ۴ و ۵ که بهشون اشاره شد راهکار مناسب بدون تغییر معماری وجود داشت ولی موارد دیگه استفاده از سیستم فعلی رو با چالش مواجه کرده بود. این شد که من و تعدادی از دوستان مأمور تحقیق و توسعه‌ی یک معماری مناسب در زمان کوتاه شدیم...معماری جدید ✅برای اینکه این نوشتار طولانی نشه از پرداختن به فرآیند تصمیم‌گیری و گزینه‌های پیش‌رو صرف‌نظر می‌کنم و فقط تصمیماتی که برای حل معایب بالا گرفتیم رو می‌گم:برای این مورد تصمیم گرفتیم که تنظیمات پایپ‌لاین‌های لاگ‌استش رو قاعده‌مند کنیم. یعنی یک قالب مشخص برای همه‌ی اون‌ها داشته باشیم و فرآیند ساخت پایپ‌لاین رو اتوماتیک کنیم. برای اینکه این تنظیمات بلافاصله برای لاگ‌استش تعریف بشن از قابلیت Reload اتوماتیک لاگ‌استش استفاده کردیم. در حال حاضر ساخت یه پایپ‌لاین آماده که ورودی رو بگیره، روش فیلتر اعمال کنه و اون رو به الستیک‌سرچ بفرسته کمتر از ۳۰ ثانیه زمان می‌بره. می‌گین چطور؟ برای اینکار باید راه‌حلی برای معایب ۲ و ۳ پیدا می‌کردیم...اصلا چرا باید تغییر در فرمت لاگ تا مرحله‌ی تنظیمات پایپ‌لاین منتشر می‌شد؟ دلیلش این بود که لاگ‌استش در معماری قدیمی بیش از حد بزرگ شده بود و هم Parser بود و هم Forwarder. چی می‌شد اگر می‌تونستیم قسمت عمده‌ی فرآیند Parse کردن رو از دل لاگ‌استش بیرون بکشیم و ببریم جایی که باید؟ یعنی همونجایی که لاگ‌ها ازش میان!برای این کار ما چندین گزینه داشتیم:گزینه‌ی اول این بود که چرا اصلا سرویس‌ها بدون ساختار لاگ کنن؟ بیاین کاری کنیم که هر سرویس در یک فرمت استاندارد و ساختارمند لاگش رو بنویسه! واکنش همه‌ی تیم‌ها:تصویر ۳ - واکنش تیم‌ها به پیشنهاد ساختارمند کردن لاگ‌هاشونکه پُرواضحه یعنی نه! :) گزینه‌ی دوم این بود که تیم‌ها با همون فرمت قبلی لاگ کنن اما ما لاگ ‌ساختارمند توی لاگ‌استش دریافت کنیم. چطوری؟ با Parser/Forwarderهای محلی (کنار خود سرویس). از بین همه‌ی گزینه‌ها ما تصمیم گرفتیم فلوئنت‌بیت رو به استک‌مون اضافه کنیم چون خیلی Lightweight و سریعه، تنظیمات راحت و سرراستی داره، میشه براش پایپ‌لاین تعریف کرد و از منابع متعدد لاگ‌های متفاوت با فرمت‌های مختلف رو پارس کرد و جدای از همه‌ی این‌ها پلاگین‌های متعددی رو هم پشتیبانی می‌کنه که دقیقا مناسب کار ما بود.ما همین گزینه رو انتخاب کردیم و با همین تصمیم به چندین دستاورد مهم رسیدیم:- بار خیلی زیادی از روی دوش لاگ‌استش برداشته می‌شد. (Parse کردن و ساختار دادن)- می‌شد فرمت مشترکی برای پایپ‌لاین‌های مختلف در آورد.- تغییر فرمت لاگ یک سرویس فقط تا فلوئنت‌بیت منتشر می‌شد و نیازی به تغییر در جاهای دیگه نداشت.۳. با تصمیمی که برای حل مشکل دوم گرفتیم این مشکل هم خودبخود حل شد و معماری جدید ما به شکل زیر در اومد:تصویر ۴ - معماری جدید سیستم مرکزی Log Managementراه‌حل‌های پیشنهادی برای موارد ۴ و ۵ توی بخش «بایدها و نبایدها در تنظیمات ELK، فوت کوزه‌گری!» اومده. سوالاتی درباره‌ی معماری جدیدآن کس که بداند و بداند که بدانداسب خرد از گنبد گردون بجهاندبا در نظر گرفتن این بیت، بهتره که همیشه تا جایی که میشه از خودمون سوال بپرسیم، به ایرادات خودمون واقف باشیم و در آینده در صدد اصلاح اونا بربیایم یا حدأقل اثر منفی اون‌ها رو کمینه کنیم.ایراداتی که به معماری جدید وارده به صورت تیتروار:چرا هنوز لاگ‌استش توی این معماری وجود داره؟ فلوئنت‌بیت می‌تونه مستقیما به الستیک‌سرچ متصل بشه. وجود لاگ‌استش با توجه به اینکه فلوئنت‌بیت تقریبا تمامی نیازهای ما رو برآورده می‌کنه فقط پیچیدگی به سیستم اضافه می‌کنه. چرا مکانیزم بافرینگ درستی دیده نشده؟ در مواقعی که بار (Load) سیستم بالاست و یا مشکلی توی استک ایجاد می‌شه ممکنه قسمتی از داده از دست بره.برای مدیریت پایپ‌لاین‌های لاگ‌استش یک API اختصاصی توسعه داده شده در حالی که می‌شد از نسخه‌ی پولی الستیک استفاده کرد که خودش APIهایی برای مدیریت پایپ‌لاین در اختیار می‌ذاره. چرا این کار انجام نشده؟چرا هنوز سیستم‌هایی وجود دارند که به فلوئنت‌بیت مهاجرت نکردن؟ چه محدودیتی وجود داشت که این پروسه برای اون‌ها هم تکرار نشد؟هیچوقت کار روی یک سیستم زیرساختی تموم نمیشه. حتی اگر در اون تغییری هم ایجاد نکنید همیشه باید حواستون به دسترس‌پذیری (Availability)، اتکاپذیر بودن و امن بودن اون باشه. ما هم با در نظر گرفتن این موارد به مرور به رفع ایرادات می‌پردازیم و اگر نکته‌ی جالب‌توجهی وجود داشت حتما در آینده پست‌های بیشتری در این باره منتشر می‌کنیم.پاسخ به این سؤالات به صورت خلاصه:سرویس‌هایی وجود دارند که هنوز به معماری جدید مهاجرت نکردن و پایپ‌لاین اختصاصی خودشون رو دارن.برای این مورد گزینه‌ی اضافه کردن کافکا به استک پیش‌بینی شده که در آینده انجام میشه.توسعه‌ی این API چندان زمان‌بر نبود ولی در صورتی که نیاز حس بشه ممکنه در آینده به سمت خرید License بریم.این سرویس‌ها از قابلیت‌هایی در لاگ‌استش استفاده می‌کردن که یا در فلوئنت‌بیت قابل انجام نیست و یا محیط اجراشون به صورتی بوده که قابلیت اضافه کردن فلوئنت‌بیت به اون محیط وجود نداشته و یا پرهزینه بوده؛ گرچه ما هنوز دنبال راه‌حلی هستیم که تمامی سرویس‌ها از فلوئنت‌بیت استفاده کنن تا معماری یکپارچه‌ای داشته باشیم.در نهایت معماری‌ای که مد نظر ماست و باید بهش برسیم مطابق تصویر ۵ خواهد بود:تصویر ۵ - معماری‌ای که می‌خوایم بهش برسیمبایدها و نبایدها در تنظیمات ELK، فوت کوزه‌گری! توی این بخش از کلی‌ترین بایدها و نبایدها شروع می‌کنم و به مرور وارد نکات جزئی توی تنظیمات ELK می‌شم. پُرواضحه که همه چیز را همگان دانند؛ فلذا اگر چیزی رو از قلم انداختم، که حتما انداختم، خوشحال می‌شم که زیر همین پست اون‌ها رو با من به اشتراک بذارید.مشکل Split Brainقبل از اینکه به توضیح این مشکل بپردازم باید بدونید که الستیک‌سرچ به صورت کلاستر استفاده می‌شه که از ۱ یا بیشتر الستیک‌سرچ تشکیل شده. این کلاستر یک مستر (Master) داره که وظایف مشخصی از قبیل ساخت و حذف ایندکس‌ها، تخصیص شارد و ... رو انجام می‌ده.مستر از طریق مکانیزم رأی‌گیری انتخاب میشه و نودهایی (Node) که واجد شرایط (master eligible) هستن می‌تونن توی فرآیند رأی‌گیری شرکت کنن و اون رو انتخاب کنن. حالا فرض کنید که دوتا نود واجد شرایط دارید: A و B؛ و A به عنوان مستر انتخاب شده. یک لحظه ارتباط بین این دوتا دچار اختلال میشه؛ توی چنین شرایطی هر نود خودش رو تنها عضو کلاستر می‌بینه و خودش رو به عنوان مستر انتخاب می‌کنه و وظایف مستر رو به عهده می‌گیره. این اتفاق باعث میشه که شما دوتا مستر داشته باشید و تمامی کارهایی که باید یک مستر مجزا انجام می‌داد در دو جا انجام می‌شن و ممکنه ناسازگاری توی کلاستر بروز کنه. برای مثال توی تصویر ۶ می‌بینید که نود B بعد از Split Brain شارد کپی (Replica) رو شارد اصلی (Primary) در نظر گرفته.تصویر ۶ - قبل و بعد از Split Brainبرای حل این مشکل چیکار میشه کرد؟خبر خوب! توی ورژن‌های جدید الستیک‌سرچ یعنی ۷ به بعد این مشکل پیش نمیاد. اینجا یه پست خیلی جالب از خود الستیک هست که توضیح داده چطور این مشکل رو رفع کردن. البته همیشه توصیه می‌شه که تعداد نودهای واجد شرایطتون فرد باشه تا تعداد رأی‌ها مساوی نشه و بشه تصمیم‌گیری کرد.اگر به هر دلیلی از ورژن‌های قبلی استفاده می‌کنید باید علاوه بر فرد بودن تعداد نودها مقدار discovery.zen.minimum_master_nodes رو برابر با e/2 + 1 بذارید که e تعداد کل نودهای واجد شرایطه. این مقدار میگه که حتما نصف بعلاوه یک از تعداد کل نودهای واجد شرایط باید حضور داشته باشن تا بشه فرآیند انتخاب مستر رو انجام داد. پس اگر کلاستر شما دو تیکه بشه، فقط توی بخش بزرگ‌تر مستر انتخاب میشه.تنظیمات حافظهزمان اجرای الستیک‌سرچ شما باید مقدار حدأقل و حدأکثر RAMی که استفاده می‌کنید رو به JVM اعلام کنید. البته این فقط مربوط به استفاده از فضای Heap مربوط به JVM هست و نود شما مقدار بیشتری رو مصرف خواهد کرد. همه جا توصیه شده که این مقادیر رو یکسان و کمتر از ۳۲ گیگابایت مقداردهی کنید؛ ولی چرا؟نکته اینجاست که الستیک‌سرچ زمان اجرا سعی می‌کنه تمامی Heapای که بهش اختصاص داده شده رو از سیستم‌عامل بگیره و اون رو قفل کنه (برای اطلاعات بیشتر راجع به قفل کردن فضای آدرس مجازی اینجا رو ببینید). اگر شما مقادیر -Xms و -Xmx که به ترتیب حدأقل و حدأکثر رو مشخص می‌کنن یکسان نذارید باعث میشه که نود شما نتونه تمامی فضای Heapش رو قفل کنه، پس بنا به شرایط تعدادی از صفحات حافظه‌اش Swap میشن، فرآیند Gorbage Collection به شدت طولانی میشه و در کل عملکرد سیستم افت می‌کنه.حالا چرا زیر ۳۲ گیگابایت؟ در واقع اگر بخوام دقیق‌تر بگم این مقدار آستانه‌ی Compressed oops روی سیستم شماست (برای اطلاعات بیشتر راجع به Compressed oops اینجا کلیک کنید). فرض کنید شما میزان RAM رو کمی بالاتر از این آستانه گذاشته باشید؛ در این حالت مقدار رم قابل استفاده برای الستیک‌سرچ کمتر از حالتیه که مقدار RAM رو کمی پایین‌تر از آستانه ست کرده باشید. جالبه نه؟ برای اطلاعات بیشتر اینجا رو ببینید.اگر سروری دارید که منابع زیادی داره، توصیه میشه که به جای یک الستیک‌سرچ با RAM خیلی زیاد چندین نود با مقدار RAMی حدود ۳۰ گیگابایت روش بالا بیارید.تعداد شارد و تعداد ایندکسفرض من اینه که مخاطب این نوشته با مفاهیم کلاستر، ایندکس و شارد توی الستیک‌سرچ آشنایی داره؛ اگر با این مفاهیم آشنایی ندارید اینجا می‌تونه نقطه‌ی شروع خوبی باشه. همینطور تصاویر ۷ و ۸ می‌تونه یک دید کلی راجع به این مفاهیم بهتون بده.تصویر ۷ - شمای کلی کلاستر الستیک‌سرچتصویر ۸ - شمای کلی یک ایندکس روی یک نود الستیک‌سرچ۱. چندتا نود داشته باشم؟۲. چندتا ایندکس توی هر نود داشته باشم؟۳. چندتا شارد به ازای هر نود داشته باشم؟این‌ها سوالاتیه که هرکسی که سعی می‌کنه الستیک‌سرچ بالا بیاره حدأقل یه بار از خودش می‌پرسه. جواب این سوالات یه جمله‌اس:بستگی داره!و واقعا هم به خیلی چیزها بستگی داره. هیچ کس نمی‌تونه هیچ نسخه‌ی از پیش تعیین شده‌ای برای همه راجع به این سوالات بده ولی راه‌هایی هست که بتونید از طریق اون‌ها برای کارکرد مدنظر خودتون جواب درستی به این سوالات بدید. یکی از متدلوژی‌هایی که می‌شه استفاده کرد توی این لینک قابل مشاهده است.برای مثال توی استفاده‌ای که ما داشتیم به نظر می‌رسه تا مدت زیادی ۳ نود الستیک‌سرچ با ۱ شارد اصلی (Primary) و ۱ الی ۲ شارد کپی (Replica) به ازای هر ایندکس کافی باشه. اما برای مقایسه نت‌فلیکس از کلاستری با ۲۵۰ نود استفاده می‌کنه. پس واقعا بستگی داره!تنها نکته‌ای که باید توجه کنید اینه که در هر نود تعداد شاردها از ۲۰تا به ازای هر گیگابایت RAMی که به الستیک‌سرچ اختصاص دادید بیشتر نشه و سایز هر ایندکس هم کمتر از چیزی حدود ۵۰گیگابایت باشه تا جستجوهای شما در زمان معقول پاسخ داده بشن. در حالت کلی شاردهای کم‌حجم با تعداد زیاد باعث کند شدن عملیات Recovery، ایندکس کردن و عملکرد کلی الستیک‌سرچ میشه و شاردهای حجیم هم به شدت روی زمان جستجوی شما تأثیر منفی می‌ذاره.اگر در کارکرد شما جستجو بیشتر اتفاق می‌افته (Read Heavy)‌ توصیه می‌شه که تعداد کپی بیشتری به ازای هر شارد داشته باشید تا عملیات جستجو سریعتر باشه ولی اگر بیشتر نوشتن و ایندکس کردن اتفاق می‌افته (Write Heavy) تعداد کپی بیشتر به معنی لود بیشتر روی استک برای پخش کردن این کپی‌ها بین نودهای شماست.سخن آخرایجاد یک سرویس امن،‌ اتکاپذیر و همیشه در دسترس کاری سخت، زمان‌بر و نیازمند دانش کافی از اون سیستم و تحقیق و توسعه‌ی مداومه. کاری که در تیم SRE یکتانت در حال انجامش هستیم و داریم یک راه طولانی، پر از چالش و جذاب رو طی می‌کنیم. اگر فکر می‌کنید که این مسائل برای شما جذابه و دوست دارید در این راه کنار ما باشید حتما به صفحه‌ی فرصت‌های شغلی ما سر بزنید. یکتانت | Yektanet javadalipanah Fri, 17 Jul 2020 19:05:31 +0430 https://virgool.io/yektanet/%D8%B5%D9%81%D8%B1-%D8%AA%D8%A7-%D8%B5%D8%AF-%D8%AA%D8%AC%D8%B1%D8%A8%D9%87-%D9%81%D8%B1%D8%A7%DB%8C%D9%86%D8%AF-%D8%AD%D8%B1%DA%A9%D8%AA-%D8%A8%D9%87-%D8%B3%D9%85%D8%AA-kpi-%DA%86%D8%A7%D9%84%D8%B4%D9%87%D8%A7%DB%8C-%D9%81%D9%86%DB%8C-yt4wcam6kt8o مقدمهما تو یکتانت خیلی به این موضوع که کار‌هامون خروجی داشته باشن اهمیت می‌دیم. به عبارت دیگه، دوست داریم کاری که انجام می‌دیم هدف‌مند باشه و درگیر کارهای بیهوده نباشیم. در همین راستا، ما یه سری KPI یا شاخص کلیدی عملکرد تعریف می‌کنیم و سعی می‌کنیم چالش‌های پیش رومون رو حل کنیم تا به اون‌ها برسیم (یا تا حد ممکن بهشون نزدیک بشیم.)شاخص‌های کلیدی عملکرد، یه سری هدف مشخص، قابل اندازه‌گیری و بلند‌پروازانه، اما قابل دسترسی هستند که در سطح نیازمندی‌های سیستم تعریف می‌شن.تو این مقاله، من قصد دارم صفر تا صد تجربیاتمون طی چند ماه گذشته، در مسیر رسیدن به KPI هایی که برای سرویس پوش نوتیفیکیشن تبلیغاتی یکتانت تعریف کردیم رو باهاتون به اشتراک بذارم.تمرکز این مقاله بیشتر روی چالش‌های مهندسی و فنیه و من سعی می‌کنم در آینده‌ی نزدیک، راجع به چالش‌هایی که بیشتر به مهارت‌های نرم، ارتباطات انسانی و نوع کسب‌و‌کار مربوط می‌شه هم بنویسم. اگه دوست داشتید، بلاگ فنی یکتانت رو دنبال کنید که مقالات بعدی رو از دست ندید.آشنایی با سرویس پوشاول از همه خوبه با سرویس پوش‌نوتیفیکیشن تبلیغاتی آشناتون کنم، ما یه تعداد تبلیغ‌کننده داریم که از طریق پنل یکتانت کمپین و نوتیف تبلیغاتی می‌سازن. از اون طرف یه سری وب‌سایت منتشر‌کننده داریم که می‌خوایم به کاربر‌هایی که تو این سایت‌ها عضو هستن اون نوتیف‌ها رو بفرستیم. ما باید سعی کنیم در سیستم‌هامون، نیاز‌های هر سه گروه(تبلیغ‌کننده‌ها، منتشر‌کننده‌ها و کاربرا) رو در نظر بگیریم که این موضوع چالش‌های فنی و غیر فنی زیادی برای ما ایجاد می‌کنه.ما با هدف سودآوری حداکثری با در نظر گرفتن محدودیت‌های هر سه گروه، در نهایت سه تا KPI تعریف کردیم.حداقل ۹۵٪ از بودجه‌ی روزانه‌ی کمپین‌هامون رو خرج کنیم.به ۹۰٪ کاربرامون پوش بفرستیممجموع درآمد وبسایت‌های مهم رو به دو برابر ظرفیت کاربراشون برسونیم.مورد اول مربوط به تبلیغ‌کننده‌ها، مورد دوم مربوط به کاربران و مورد سوم هم مربوط به منتشر‌کننده‌هاست.حدود چند ماه پیش، زمانی که شروع کردیم به بهبود این سیستم، دیتابیس کاربر‌های ما شامل چند ده میلیون کاربر بود، اما سرویس ارسال پوش در روز فقط به چند میلیون از اونها پوش ارسال می‌کرد، خرج بودجه‌ی اکثر کمپین‌هامون هم به اندازه‌ای که تبلیغ‌کننده‌ها تعیین کرده بودن نمی‌رسید. در نتیجه خیلی با ایده‌آل‌هامون فاصله داشتیم. ما طی چند ماه، با مسائل و چالش‌های مختلفی روبرو شدیم و بعد از حل کردنشون، خروجیش شد رشدی که توی نمودار زیر می‌بینید.نمودار تعداد ارسال روزانه در طول زمانچالش‌های فنی و روش‌های حل مسالهاین قسمت شامل چالش‌هایی که بهشون برخوردیم و روش‌هایی که برای حل اون‌ها تست و پیاده‌سازی کردیم می‌شه. سعی کردم به ترتیب زمان وقوعشون بنویسم که در مسیر پیشرفت پروژه قرار بگیرین.این روش‌ها لزوما بهترین راه ممکن نیستن، اما راه‌حل‌هایی بودن که ویژگی‌های مورد نظر‌ ما رو داشتن: سریع بودن، ممکن بودن و ما رو به KPI هامون نزدیک‌تر می‌کردن.کوئری‌های خوندن از Redis کند شده و چندین ثانیه طول می‌کشه! معمولا از Redis به عنوان اون دیتابیسی یاد می‌شه که برای cache کردن یا بیشتر شدن سرعت و بهبود کارایی می‌رن سراغش. اما ما تونسته بودیم کندش کنیم.ما برای اینکه به کاربرامون پشت سر هم نوتیف نفرستیم که آزاردهنده نشه، به ازای هر کاربر، یک کلید با ttl چند ساعته توی Redis نگه می‌داشتیم که بدونیم برای این کاربر الان نباید بفرستیم، کلید‌ها و مقدارشون به این شکل بود:key -> value--------------------user:1234 -> True, ttl: 3600user:1235 -> True, ttl: 7200user:1236 -> True, ttl: 3600اما چون به تعداد کاربرامون کلید داشتیم(چند ده میلیون) وقتی می‌خواستیم همه‌ی این کلید‌ها رو بخونیم خیلی طول می‌کشید، و حالا اگه می‌خواستیم به ازای هر نوتیف این کار رو بکنیم، عملا سرعت سیستم رو اونقدر پایین میاورد که غیر قابل تحمل بود.استفاده‌ی ما از این لیست کاربرا توی ردیس، در نهایت این بود که از یک مجموعه‌ی بزرگتر از کاربرها که قبلا انتخاب کرده بودیم، این مجموعه رو فیلتر کنیم، در نتیجه داده ساختار set توی Redis خیلی بدردمون می‌خورد اگر می‌تونستیم یه جوری ازش استفاده کنیم.اما مشکلمون این بود که هر کدوم از این کلید‌ها ttl داشتن و بعد از یه مدت قرار بود حذف بشن. برای اینکه بتونیم از set استفاده کنیم، تصمیم گرفتیم که فرایند ttl رو خودمون پیاده‌سازی کنیم، به این شکل که به ازای هر "ساعت استراحت به کاربرها" یک کلید تو Redis در نظر گرفتیم، که شامل یک set از کاربرامون بود، به این صورت:key -> value--------------------ttl:1 -> set(1234, 1236)ttl:2 -> set(1235)مثلا، کلید ttl:2 به معنی این بود که کاربرانی که توی این مجموعه هستن، تا دو ساعت دیگه قرار نیست بهشون نوتیفی ارسال بشه. و از طرف دیگه، با یک async task که هر ساعت اجرا می‌شد، میومدیم و کاربر‌های هر ساعت رو انتقال می‌دادیم به یک ساعت کمتر.با این کار، بجای اینکه هر بار لازم باشه چند ده میلیون کلید رو از ردیس بخونیم، کافی بود اختلاف(difference) مجموعه‌ی انتخابی کاربرامون رو با چیزی حدود ۱۰ تا مجموعه‌ توی Redis می‌گرفتیم. نتیجه اینکه پروسه‌ی فیلتر کردن کاربرها برای هر نوتیف از ده ثانیه به چیزی نزدیک به یک ثانیه رسید که بهبود قابل توجهی محسوب می‌شد.نتیجه: گاها، عموما در شرایط خاصی، ممکنه لازم بشه از یه ابزار اونطوری که عرفش هست استفاده نکنید، قبلش با scale کوچیک‌تر تست کنین و اگه به نتیجه‌ی دلخواهتون می‌رسه، ابایی از انجام این کار نداشته باشین.+ اوضاعمون چطوره؟- نمی‌دونم، باید log ارسال رو نگاه کنم. بعد از مدتی، ما با این مشکل روبرو شدیم که هیچ دیدی نداشتیم که سیستممون الان در چه وضعیتیه، پیدا کردن مشکلات سیستم سخت شده بود و ابزار درست و راحت برای مانیتور کردن سیستم نداشتیم. حجم زیادی log داشتیم که اونها رو با tail و grep و ابزار‌های دیگه‌ی ترمینال دنبال می‌کردیم تا از وضعمون باخبر بشیم.برای حل این مشکل، از ابزاری که مخصوص این کار ساخته شده استفاده کردیم، ما برای حفظ سرعت، به ساده‌ترین روشی که می‌شد ELK stack رو راه اندازی کردیم(یه مقاله در همین مورد تو بلاگمون نوشته شده که می‌تونین از اینجا بخونید) و لاگ‌هامون رو هدایت کردیم اونجا.بعد مشغول ساختن نمودار‌های مختلف توی Kibana شدیم، نمودار‌هایی مثل اینکه امروز تا الان چقدر اقدام به ارسال کردیم، فیلتر‌های مختلفی که داشتیم چطور دارن کار می‌کنن، در هر ساعت چقدر می‌فرستیم، آیا بودجه‌ی کمپین رو به صورت عادلانه بین نوتیف‌هاش تقسیم می‌کنیم و …این نمودار‌ها بهمون کمک کردن که دید خیلی بهتری نسبت به سیستم در وضعیت فعلی داشته باشیم، بتونیم روزانه سیستم رو مانیتور کنیم و اگر مشکل و یا ناهمگونی‌ای(anomaly) وجود داشت به سرعت پیداش می‌کردیم.حدود یک ماه بعد از راه‌اندازی این سیستم، با تغییر بعضی از قسمت‌های سرویس ارسال پوش و اضافه شدن قابلیت‌های جدید، نیازمون به این ابزار مانیتورینگ خیلی بیشتر و اساسی تر شد، و تصمیم گرفتیم یک Logger عمومی‌تر و گسترش‌پذیر بنویسیم که بتونیم خیلی راحت داده‌های جدید به log هامون اضافه کنیم و از این ابزار بهتر استفاده کنیم.نتیجه: اگر در هر جایی از مسیر پروژه احساس کردین که دارین کورکورانه و بر مبنای یک سری حدس و گمان تصمیم‌ به انجام کاری می‌گیرین، احتمالا به یک ابزار Visualization احتیاج دارین.نمودار سهم تخصیص‌داده شده از بودجه کمپین به نوتیف‌هانمودار نرخ مصرف بودجه نوتیف‌هانمودار میانگین نرخ موفقیت ارسال+ چقدر به KPI هامون نزدیکیم؟- ایده‌ای ندارم! مساله‌ی بعدی که بهش برخوردیم، این بود که ما نمی‌دونستیم چقدر داریم به سمت KPI هامون حرکت می‌کنیم. آیا ۹۵٪ بودجه‌ی کمپین‌ها رو خرج می‌کنیم؟ آیا به اندازه‌ی ظرفیت وبسایت‌های منتشر‌کننده‌هامون براشون درآمدزایی می‌کنیم؟خوشبختانه، در همون ایام، تیم Business Intelligence یا BI در شرکت راه افتاده بود و بچه‌ها با استفاده از Power BI داشبورد‌های مختلفی برای هر پروژه می‌ساختن. ما هم برای سرویس پوش، نمودار‌های مربوط به KPI هامون رو ساختیم و از اونجا وضعیت رو بررسی می‌کردیم.بعد از مدتی مانیتور کردن متوجه شدیم که KPI هامون دقیق نیستن و لازم بود تغییرشون بدیم، مثلا بعضی از تبلیغ‌کننده‌ها بودجه‌های نجومی برای کمپین‌هاشون می‌گذاشتن و ما اصلا تعداد کاربر کافی برای خرج کردن این بودجه رو نداشتیم، در نتیجه مجبور بودیم که ظرفیت ارسالمون رو هم برای این موارد لحاظ کنیم.نتیجه: KPI هایی که تعریف می‌کنید، وحی منزّل نیستن و ممکنه تغییر کنن.وضعیت مصرف بودجه کمپین‌ها+ فلان منتشر‌کننده خواسته این قابلیت اضافه بشه.- خب اینو بخوایم بزنیم باید کلی چیز توی کد تغییر کنه! بعد از حدود دو ماه توسعه‌ی سیستم و پیاده‌سازی قابلیت‌های مختلف و تغییرات زیاد سیستم در زمان کم، با با یه حجم زیاد از کد کثیف روبرو بودیم که تغییر دادنش یا اضافه کردن چیزی بهش سخت شده بود، بعد از این مدت توسعه، دید نسبی پیدا کرده بودیم که کجا‌ها رو می‌تونیم تمیز کنیم، و چه قسمت‌هایی رو می‌تونیم به یک سرویس جدا که قابلیت استفاده‌ی مجدد داشته باشه تبدیل کنیم. تصمیم گرفتیم وقت بذاریم و سرویس فعلیمون رو refactor کنیم تا برای ادامه‌ی توسعه کارمون ساده‌تر بشه.اینجا دوست دارم به یک نکته اشاره کنم. من بخاطر بک‌گراند فنی، دائما اصرار داشتم که از همون اولش وقت بیشتری برای طراحی بذاریم و کدی که می‌زنیم از همون اولش تمیز باشه، اما هر بار پیمان فخاریان، مدیر بخش مهندسی یکتانت، مانع می‌شد و تذکر‌ می‌داد که تمرکزمون فعلا روی توسعه‌ی سرویس باشه. در نهایت، زمانی که ما سراغ refactor رفتیم، یک سرویس داشتیم که کار می‌کرد و درآمد داشت. اگر از اولش سراغ این کار می‌رفتیم، احتمالا دیرتر به این سیستم می‌رسیدیم، و جالب‌تر اینکه احتمالا باز هم نیاز به refactor داشتیم، چرا که از اولش این دید رو نداشتیم که چه تغییراتی ممکنه به‌وجود بیاد و چه نیاز‌های جدیدی ممکنه ایجاد بشه. در واقع، همه‌ی مسائل از همون اولش برای ما شفاف نبود.نتیجه‌: با دانش ناقص در مورد مساله (دقت کنین تقریبا همیشه دانشمون در مورد مساله ناقصه)، اصرار به طراحی بی‌نقص سیستم نداشته باشیم، چرا که غیر‌منطقی و نشدنیه. عوضش با یک طراحی منطقی شروع به توسعه بکنیم، و در صورت نیاز refactor کنیم.+ چرا به اون حجم از ارسال که می‌خوایم نمی‌رسیم؟- کوئری‌ روی جدول کاربرا خیلی کنده! یکی از اساسی‌ترین مسائلی که در طول توسعه‌ی این سرویس داشتیم، این بود که برای پیدا کردن و فیلتر کردن کاربر هامون بر اساس محدودیت‌های کمپین‌ها و پیچیدگی‌های سیستم، اولا با یک جدول نسبتا بزرگ توی دیتابیس(ما از دیتابیس postgreSQL استفاده می‌کنیم) سر و کار داشتیم، دوما کوئری‌های متنوعی روی این جدول داشتیم و نمی‌تونستیم با تعریف یک یا چند تا index روی اون سرعت کوئری‌هامون رو زیاد کنیم و خوشحال باشیم.ما دائما با این موضوع درگیر بودیم که چطور کوئری‌هامون رو سریع‌تر کنیم. بعد از تلاش‌های بسیار، تحلیل کوئری‌ها با استفاده از explain و کار‌های مختلفی که کردیم (سعی می‌کنم در آینده تو یه مقاله‌ی جدا در مورد تلاش‌هامون برای بهبود سرعت و کارایی کوئری‌های دیتابیس بنویسم) در نهایت تونستیم با Cluster کردن جدول کاربر‌ها روی indexی که روی فیلد وبسایت تعریف شده بود، به سرعت مطلوب و حتی بهتر از چیزی که انتظارشو داشتیم برسیم. برای اینکه یکم حس پیدا کنین، میانگین زمان کوئری‌های سنگینی که داشتیم، از حدود ۲۰۰ ثانیه، به ۲ ثانیه رسید.لازمه به این موضوع اشاره کنم که هر جدول دیتابیس رو فقط روی یک index می‌تونید Cluster کنید، چرا که به صورت فیزیکی چینش row های جدولتون رو عوض می‌کنه. در نتیجه لازمه مطمئن بشین که اولا راه‌های دیگه رو امتحان کردید، دوما واقعا به این cluster احتیاج دارید و در حال حاضر اون index پر استفاده ترین و مهم‌ترین ایندکس جدوله.+ چرا اینهمه اخطار داریم که RAM و Disk پره؟- خب الان که سرعت ارسالمون بالا رفته به همه‌ی کاربرا می‌فرستیم و Redis پر می‌شه. بعد از همه‌ی این تغییرات، حالا تقریبا به KPI هامون رسیده بودیم. اما از اونجایی که حالا داشتیم به اکثر کاربرامون پوش ارسال می‌کردیم، حجم داده‌ای که توی Redis نگه می‌داشتیم خیلی زیاد شده بود، این اتفاق دوتا اثر منفی داشت، اول میزان مصرف ما از RAM سرور به بالای ۹۰ درصد رسید، دوم اینکه این حجم داده‌ی زیاد Redis دائم باید backup گرفته می‌شد و در بازه‌های زمانی کوتاه، Disk I/O رو هم خیلی بالا برده بود.راه‌حل ما برای این مساله، ذخیره کردن داده‌ها به صورت فشرده‌شده بود. بجای یک set از اعداد در یک کلید Redis، ما یک رشته‌‌ نگه می‌داشتیم که همون داده‌ها اما به صورت فشرده شده بود. این کار یه مقدار پیچیدگی به کد اضافه می‌کرد، چرا که ما دیگه مستقیما توی Redis ساختار داده‌ی Set نداشتیم و مجبور بودیم عملیات رو توی کد انجام بدیم، و اینکه یه wrapper بنویسیم که این تبدیل رو موقع خوندن یا نوشتن از Redis انجام بده.انتظارمون این بود که این کار مصرف RAM رو کمتر کنه، اما از اون طرف برناممون کندتر بشه، چرا که عملیات اضافه انجام می‌دادیم، اما نتیجه مقداری متفاوت بود.سرعتمون از قبل بیشتر شد، علتش هم این بود که حجم داده‌ی کمتر، زمان خوندن و نوشتن توی Redis رو هم کمتر کرده بود، و این زمان خیلی بیشتر از زمانی بود که ما برای فشرده‌ کردن داده‌ها صرف می‌کردیم. با این کار، میزان حافظه‌ی مورد استفادمون نسبت به قبل حدودا ۰.۰۰۲ برابر شد. سرعت خوندن و نوشتن هم بین ۵ تا ۱۰ برابر سریع‌تر شد.حجم ارسالمون دوباره خیلی کم شده! به مرحله‌ی نگهداری از سرویس رسیده بودیم، بعد از چند روز مانیتور کردن نمودارها تو کیبانا، دیدیم میانگین زمان کوئری به ازای هر وب‌سایت تقریبا ۵۰ برابر قبل شده بود. یعنی ما ۵۰ برابر کند‌تر شده بودیم. بعد از کمی گوگل کردن و تفکر، فهمیدیم علتش آپدیت‌های زیاد دیتابیس بعد از Cluster کردنه. اول اینکه وقتی یه جدول رو Cluster می‌کنیم، محتواش به صورت فیزیکی جاشون عوض می‌شه و سازمان‌دهی می‌شن بر اساس اون index، دوم اینکه عملیات update در دیتابیس PosgreSQL در عمل یک insert و یک delete هست. در نتیجه، جای فیزیکی یک رکورد بعد از update عوض می‌شه و این به معنی خراب شدن Cluster در صورت آپدیت زیاده.نتیجه‌ی این اتفاق رو می‌تونید توی نمودار زیر ببینید. راهکار ما برای حل این مساله، اتومات کردن فرایند Cluster کردن بود، در این مورد هنوز کم‌تجربه‌ایم، اگه راه‌کار بهتری می‌شناسین، خوشحال می‌شم توی کامنتا بگین.Cluster breakdownحرف آخرمسائلی که بالاتر گفتم، فقط مسائلی بودن که مارو به KPIهامون نزدیک‌تر می‌کردن. ما طی این پروسه، سعی و خطا‌های زیادی داشتیم و مسائل مختلفی رو حل کردیم که بعضیاشون با وجود سختی و پیچیدگی، کاملا بیهوده بودن. از مهم‌ترین چیز‌هایی که من طی این چند ماه یاد گرفتم، این بود که منحرف شدن از هدف خیلی سادست. در جایگاه مهندس نرم‌افزار، خیلی اوقات ممکنه فکر کنین مساله‌ای که حل می‌کنین مساله‌ی مهمیه و در راستای KPI هاست، اما ممکنه به حاشیه رفته باشین و مساله‌های خیلی مهمتری برای حل کردن وجود داشته باشه که تاثیر‌گذاری بیشتری داره.اولویت بندی مسائل، اینکه یه هدف مشخص داشته باشین و اون هدف و وضعیت فعلی دائم جلوی چشمتون باشه و مسیر پیشرفت رو دائما دنبال کنید، کمک می‌کنه که درست اولویت‌بندی کنید و در مسیر هدف باقی بمونین.درباره ماما در تیم مهندسی یکتانت، با مسائل متنوع و جذابی روبرو هستیم و مسائلی که حل می‌کنیم به طور مستقیم و غیر مستقیم روی تجربه‌ی میلیون‌ها کاربر در اینترنت تاثیر می‌ذاره. اگه علاقه‌مندی مسائل سخت و جذاب حل کنی، تاثیرگذاری رو دوست داری و ترجیح می‌دی محیطی که توش کار می‌کنی، به سرعت در حال رشد و پیشرفت باشه، یکتانت می‌تونه جای مناسبی برات باشه. می‌تونی به این صفحه سر بزنی تا با موقعیت‌های شغلیمون آشنا بشی.ممنون می‌شم در مورد مقاله‌ای که خوندی بهم فیدبک بدی، به این امید که مقاله‌های بعدی مفید‌تر باشن. یکتانت | Yektanet محمد گنجی | Mohammad Ganji Mon, 13 Jul 2020 00:59:57 +0430 https://virgool.io/yektanet/%D8%B1%DB%8C%DA%A9%D8%A7%D9%85%D9%86%D8%AF%D8%B1-%D8%B3%DB%8C%D8%B3%D8%AA%D9%85-%DB%8C%DA%A9%D8%AA%D8%A7%D9%86%D8%AA-%D8%A7%D9%84%DA%AF%D9%88%D8%B1%DB%8C%D8%AA%D9%85-%D9%87%D8%A7-vftgkbwfjcq4 این روزها استفاده از ریکامندر سیستم ها متداول شده. وقتی که به IMDb میریم و بهمون فیلم مورد علاقمون رو پیشنهاد میکنه یا وقتی که وارد آمازون میشیم و کالاهایی بهمون معرفی می کنه که جذابند، داریم از یک ریکامندر سیستم استفاده می کنیم.در ایران هم ریکامندر سیستم یکتانت وظیفه هدایت کاربران به صفحات مورد علاقشون رو بر عهده داره.نمونه خروجی ریکامندر سیستم یکتانتمن 7 ماه گذشته رو صرف تولید و توسعه ریکامندر سیستم یکتانت کردم و این مقاله، خلاصه ای هست از ایده های الگوریتمی که در این فرایند استفاده شده اند.بدیهیست بیشتر از 60 درصد این زمان، صرف انتقال ریکامندر به محیط محصول (Production) و اسکیل آن شده است اما تمرکز این مقاله بر ارائه ایده ها، چالش ها و الگوریتم هاست. امیدوارم مطالعه آن برای شما مفید باشد.تقسیم بندی ریکامندر سیستم هاتقسیم بندی محصولیریکامندر سیستم ها از نقطه نظر محصول به دو دسته کلی تقسیم می شوند.1. آیتم محور (Item Based)در این دسته، ریکامندیشن برای یک آیتم (صفحه وب) تولید می شود. برای مثال در یک صفحه با عنوان "انتخابات مجلس"، یک مطلب با عنوان "آخرین نتیجه شمارش آرا" پیشنهاد داده می شود.در این نوع ریکامندیشن هر کاربری که وارد صفحه "انتخابات مجلس" می شود، همان ریکامندیشن را مشاهده می کند که سایر کاربران مشاهده می کنند.2. کاربر محور (User Based)در این دسته، ریکامندیشن بر اساس سلیقه کاربر تولید می شود. مثلا من به عنوان یک برنامه نویس پایتون، زمانی که وارد یک وب سایت میشم، مطلبی تحت عنوان "آخرین کرک نرم افزار PyCharm" به من ریکامند میشود. این اتفاق ممکن هست زمانی رخ بدهد که من در حال مطالعه یک خبر سیاسی هستم.هر کدام از دو دسته می توانند به عنوان یک محصول جداگانه توسعه داده شوند.تقسیم بندی الگوریتمیریکامندر سیستم ها از نقطه نظر الگوریتم و دیتای ورودی هم به دو دسته کلی تقسیم می شوند.1. محتوا محور (Content Based)در این دسته، ریکامندر سیستم محتوای آیتم ها را آنالیز می کند و مثلا متوجه می شود که خبر "ترامپ پیروز انتخابات شد" محتوای نزدیکی به خبر "آخرین نتایج انتخابات آمریکا" دارد.2. بازدید محور (Collaborative Filtering)در این دسته، ریکامندر سیستم با صرف نظر کردن از محتوای آیتم ها، دیتای بازدید کاربران از آن ها را معیار قرار می دهد. برای مثال، در تصویر زیر، ریکامندر سیستم شباهت بین دو کاربر را با نزدیکی محصولاتی که قبلا خریداری کرده اند، درک کرده و در نتیجه نوشابه ای که کاربر اولی خریده را به دومی پیشنهاد می کند.مقایسه دو الگوریتمانتخاب الگوریتمفاکتورهای زیادی در انتخاب الگوریتم ریکامندر سیستم موثرند. در زیر به تعدادی از آن ها اشاره می شود.1. دیتادر بسیاری از سایت ها محتوای متنی وجود ندارد. مثلا در سایت یوتیوب برای هر ویدیو فقط یک تیتر وجود دارد و اگر قرار باشد از الگوریتم محتوا محور استفاده بشود، ممکن است فیلم Game of Thrones به فیلم Game of Survival ریکامند بشود. در صورتی که از روابط بازدیدی احتمالا می توان فهمید، که Game of Thrones به فیلم Vikings شبیه تر هست.2. میزان تغییرات (Turnover)الگوریتم بازدید محور نقض اساسی در وب سایت هایی دارد که میزان تغییرات (Turnover) در آن ها بالاست.زیرا در این نوع الگوریتم، مدتی زمان لازم هست تا یک آیتم یا کاربر جدید، دیتای کافی را کسب کند (Learning Rate). این مسئله در سایت های خبری مثل انتخاب به حدی است که می تواند الگوریتم رو به طور کامل بی مصرف بکند. به این مشکل Cold Start هم گفته می شود.3. تمایل به مطالب پربازدید (Trends)راه حل بازدید محور، تمایل بیشتری به پیشنهاد مطالبی دارد که پربازدیدتر هستند. در مقابل الگوریتم محتوا محور هیچ اهمیتی به میزان بازدید نمی دهد. این قاعده ممکن هست مثبت یا منفی باشد.4. پراکندگی بازدید کاربراندر سایت هایی مثل انتخاب که کاربران وفادار دارند، کاربران ممکن است مطالب متنوع مشاهده کنند. در این صورت عملکرد الگوریتم بازدید محور دچار مشکل می شود.5. شباهت بیش از حد (Overspecialization)فرض کنید به یک مطلب در مورد ویندوز 7، سه مطلب دیگر در مورد ویندوز 7 ریکامند بشود. در این صورت شانس کلیک کاربر مقداری کمتر از وقتی است که یکی از آن ها در مورد یک سیستم عامل دیگر باشد. به این مشکل شباهت بیش از حد یا Overspecialization می گویند. الگوریتم محتوا استعداد بسیار بیشتری برای درگیر شدن با این مشکل دارد. الگوریتم بازدید محور متنوع تر پیشنهاد می کند.جمع بندی انواعجدول زیر حاصل ترکیب تقسیم بندی الگوریتمی و محصولی است که 4 گروه زیر را تولید می کند.انواع ریکامندر سیستم هادر یکتانت من کار رو با گروه A شروع کردم. یعنی ریکامندیشن برای آیتم و براساس محتوا.یک ماه R&D در محیط آفلاین و چهار ماه پیاده سازی و ریزه کاری زمان برد تا ریکامندر سیستم یکتانت کاملا جا افتاد. به مرور زمان و با نتیجه دهی سیستم بود که افراد دیگه به پروژه اضافه می شدند و قسمت های مختلف اون قوی تر از قبل بازنویسی می شد. حتی برای توسعه لازم بود که سیستم های جانبی مثل سرویس استخراج دیتای وب هم بازنویسی و تقویت بشوند.در طی این پروسه کم کم مشخص شد، سه دسته دیگر ریکامندر سیستم نیز مورد نیاز هستند. چرا که در بسیاری از سایت های متقاضی (مثل سایت های دانلود موزیک یا نرم افزار) روش محتوا محور پاسخگو نبود و ریکامندیشن بر اساس کاربر نیز به اهداف مجموعه اضافه شده بود.الگوریتم های محتوا محور (Content Based)در این روش، مغز الگوریتم ریکامندر به یک تابع خلاصه می شود: تابع اِمبد کردن هر آیتم(صفحه وب) بر اساس محتوای آنتکست امبدینگ (Text Embedding)اگر بتوانیم یک متن را به یک بردار(نقطه) در عالم ریاضیات تبدیل کنیم - طبیعتا به طوری که دو مطلب مشابه در نزدیکی هم قرار بگیرند - تا حد زیادی مسئله ریکامندیشن حل میشود. به این صورت که برای تولید ریکامندیشن های هر مطلب، مطالبی را که وکتورهای نزدیکی به آن دارند، ریکامند می کنیم. این روش در واقع همان روش Nearest Neighbor در ماشین لرنینگ کلاسیک هست.آیتم های امبدشده در فضای دوبعدیهر بُعد از این فضا می تواند یک مشخصه (characteristics) از متن باشد. مثلا در حالت ساده یک بُعد می تواند نشان دهنده تعداد کلمات "ترامپ" در یک متن و یا در حالت پیشرفته نشان دهنده میزان سیاسی بودن آن متن باشد.تکست امبدینگ پایه ای (Basic Text Embedding)برای امبدینگ متن، ساده ترین روش، استفاده از فرکانس تکرار کلمات هست. به این صورت که هر بُعد از فضا برای یک کلمه در نظر گرفته می شود و تعداد بارهایی که آن کلمه در متن تکرار شده، به عنوان مقدار اون بُِعد مقداردهی می شود.وکتور متناظر عبارت "دلار گران شد"اگر یک کلمه بیشتر از یک بار در متن تکرار شود، تعداد تکرار یا همان TF (مخفف Term Frequency) در بردار قرار داده می شود. در نتیجه یک مطلب بلند که بارها از کلمه ترامپ استفاده می کند، مقدار بزرگی برای ترامپ در بردار آن لحاظ می شود. در نتیجه وقتی دو متن در مورد انتخابات آمریکا به طور مکرر از کلمات یکسانی مثل "ترامپ"، "بایدن" و "آمریکا" استفاده می کنند، امید داریم که بردارهای آن ها نزدیک شوند.اما سادگی این روش و به طبع، نارسا بودن آن در چند مثال دقیق تر محسوس می شود.1. هم معناییآ: بیماری کرونا جان هزاران نفر را گرفت.ب: صدها انسان از مریضی covid19 جان باختند.بردار مربوط به دو متن بالا کاملا متمایز است. چرا که کلمات "کرونا" و "covid19"، "صدها" و "هزاران"، "بیماری" و "مریضی" همه دو به دو متفاوت هستند.به طور خلاصه دو عبارت "کرونا" و ترامپ" همان اندازه متفاوتند که دو کلمه "کرونا" و "covid19" متفاوتند.2. عدم درک نزدیکی هاآ: فرهاد مجیدی به باشگاه استقلال پیوست.ب: لیگ برتر وارد فصل نقل و انتقالات می شود.در دو عبارات بالا، اگرچه "استقلال" و "لیگ برتر" هم معنی نیستند ولی حداقل نزدیکند. روش ابتدایی تکست امبدینگ متوجه آن نمی شود.3. تحلیل لغوی به جای معناییآ: یک سر بریده در چمدانی پیدا شدب: فروش چمدان با قیمتی ویژهممکن است دو خبر بالا به دلیل مشابهت در کلمه چمدان نزدیک هم باشند. مخصوصا اگر در متن کامل چندین بار کلمه "چمدان" استفاده شده باشد. در صورتی که یکی اقتصادی و دیگری جنایی است.4. وزن یکسان کلماتآ: رقابت ترامپ و بایدنب: رقابت جاوا و پایتوندو عبارت کلمات مشترک "رقابت"، "و" را دارند. این باعث نزدیک شدن بردار آن ها می شود در حالی که کاملا متفاوت هستند. این مشکل به آن دلیل است که کلمات "رقابت"، "و" و "ترامپ" به یک اندازه ارزش دارند. ایده اولیه حذف کلمات بی معنایی مثل "و" (اصطلاحا stop words) از پردازش هاست اما مشکل همچنان باقیست. کلمه "رقابت" همان قدر ارزش دارد که "ترامپ" دارد.5. کلمات جفتآ: حسن روحانی رئیس جمهور شد.ب: یک روحانی رئیس اداره شد.دو متن بالا بسیار نزدیکند زیرا در کلمات "روحانی" و "رئیس" اشتراک دارند. حال آن که انسان می فهمد "رئیس جمهور" و "حسن روحانی" هر کدام یک عبارت هستند. تکه کد پایتونی که نمایندگی هوش مصنوعی رو ایفا می کنه، کلمات رو با space از هم جدا میکند و این باعث شکسته شدن "رئیس جمهور" به "رئیس" و "جمهور" می شه.تکست امبدینگ پیشرفته (Advanced Text Embedding)برای تکست امبدینگ بهتر، از تکنیک های پیچیده تری استفاده می شود که در زیر مورد به مورد بیان شده است.1. امبدینگ کلمات (word2vec)در این روش سعی می کنیم به جای این کل عبارت را تبدیل به وکتور کنیم، ابتدا هر کلمه را تبدیل به وکتور کنیم و سپس وکتور کل متن را از میانگین گیری بین کلمات مختلف تولید کنیم. در این صورت می توان مکانیزم تبدیل کلمه به وکتور که همان word2vec نام دارد را طوری طراحی کرد تا کلماتی که مشابه هستند، وکتورهای نزدیک به هم داشته باشند.مثلا در شکل زیر که در دو بعد ترسیم شده است، کلمه piano نزدیک به کلمه guitar است.نمایش کلمات در فضای دو بعدبرای آموزش این مدل، حجم زیاد داده آنالیز می شود و میزان نزدیکی کلمات در فضای N بعدی، از تکرار آن ها در نزدیکی هم در متون داده شده به دست می آید.2. تحلیل معنایی به جای تحلیل لغوی (Semantic Analysis)زمانی که به تیتر خبر "سر بریده داخل چمدانی در فرودگاه پیدا شد." نگاه می کنیم، می فهمیم آن خبر جنایی است. وقتی تیتر "فروش چمدان در فرودگاه" را می بینیم، می فهمیم یک متن اقتصادی یا تبلیغاتی است. دسته بندی معنایی به ما کمک می کند که بفهمیم آن متون متفاوت هستند، هر چند که ممکن است، بردارهای نزدیک داشته باشند.تشخیص موضوعات صفحات در یکتانت توسط یک سیستم "تشخیص موضوعی" انجام می شود که خارج از توضیح این مقاله است، اگر چه که اساس تقریبا یکسانی دارد.3. تاثیر فراوانی (TF-IDF)وقتی که یک انسان متنی را بررسی می کند، کلماتی مانند "ترامپ" در تحلیل محتوای متن تاثیر بیشتری نسبت به کلماتی مانند "سلام" دارند. این ذهنیت ناشی از کمبود کلمه دومی است که باعث می شود متوجه تاثیرگذاری آن در یک متن شویم.. برای این کار از فرمول tf-idf به عنوان وزن کلمات استفاده می کنیم.در این فرمول کلماتی که مکررا استفاده می شوند مثل کلمه "گربه" وزن بسیار کوچکی می گیرند. (چرا؟) و در نتیجه کلمات کمیاب در همه متون اما پر تکرار در متن فعلی نقش بزرگ تری خواهند داشت.4. جفت های پرتکرار (Bigram)این مدل قابلیت چسباندن کلماتی که مکرر با هم تکرار شدند رو داره. برای مثال "جمهوری اسلامی" رو به "جمهوری_اسلامی" تبدیل می کنه. برای آماده سازی آن باید حجم زیادی داده خام به عنوان ورودی بهش داده بشه تا متوجه بشه چه کلماتی جفت هستند.ارزیابیارزیابی چنین سیستمی کاملا کیفی است. خبری از داده آموزش (train) و آزمون (test) نیست. مسئله کاملا unsupervised هست و هیچ متدی وجود ندارد که برای کیفیت سیستم را در یک عدد خلاصه کند.به علاوه ریکامندیشن ها تا حدی سلیقگی هستند و ممکن است از نظر یک نفر جالب باشند و از نظر نفر دیگر جذاب نباشند. همه این مسائل، کار رو برای اصلاح الگوریتم (Fine Tuning) سخت می کند. مسئله پارامترهای زیادی دارد که انتخاب آن ها بدون وجود متد ارزیابی امکان پذیر نیست.در نتیجه باید از ایده ها و روش های غیر مستقیم استفاده کنیم که دو مورد از آن ها در زیر ذکر شده اند.1. نرخ کلیک (CTR)در این روش نرخ کلیک کاربران بر روی ریکامندیشن ها به طور ساده نتیجه معیاری کیفیت ریکامندر سیستم در نظر گرفته می شود. اما در انتخاب این نوع روش باید به عوامل زیر توجه داشت.اولا، کلیک تابع پارامترهای زیادی مثل محل قرارگیری جایگاه در سایت هاست. برای همین فقط در صورتی این روش کاراست که در یک تست A/B کنترل شده با ثابت کردن همه پارامترهای دیگر انجام شود.ثانیا، بهبود ریکامندیشن ها ممکن است تاثیری در نرخ CTR نداشته باشد! (چرا؟)ثالثا، این روش بسیار محدود است و نهایتا برای انتخاب بین دو الگوریتم نهایی می توان از آن استفاده کرد. قابلیت این که در مرحله R&D و قبل از ورود به محیط عملیاتی از آن برای بهبود جز جز پارامترها استفاده شود، مطلقا وجود ندارد.رابعا، برای استفاده از این روش باید به یک سیستم مانیتورینگ درست دسترسی داشته باشیم که برای اون من استک الستیک رو استفاده کردم. اگر چنین زیرساختی وجود نداشته باشد، استفاده بسیاری چالشی و ناگویا خواهد بود. جهت اطلاع بیشتر در این مورد می تونید مقاله الستیک سرچ / کیبانا / لاگ استش - شفاف ببینیم رو مطالعه کنید.2. ارزیابی چشمیدر این روش باید ریکامندیشن ها رو ببینیم و قضاوت کنیم که چه قدر خوب هستند! اما باز هم در عین سادگی نکات خیلی ظریفی باید رعایت شوند.اولا، قبل از هر چیز یک معیار برای خوب بودن ریکامندیشن ها تعریف شود. برای مثال اگر در یک خبر ورزشی، خبر آخرین قیمت دلار ریکامند شود، ممکن است برای کاربران زیادی جذاب باشد. چنین دوگانه هایی مثل تاثیر میزان بازدید یا میزان overspecialization باید از نقطه نظر محصول تحلیل و انتخاب شوند. در یکتانت به دلیل این که مدیران سایت ها کیفیت ریکامندر سیستم را ارزیابی و در مورد استفاده از آن تصمیم می گیرند، و به این دلیل که آن ها معمولا میزان مرتبط بودن را بررسی می کنند، ترجیح بر این است که مطالب حتی الامکان مرتبط (ولو بدون بازدید و بیش از حد شبیه) باشند.داده تست باید خیلی دقیق انتخاب شود. ممکن است یک الگوریتم در یک محصول خاص جوابگو باشد. اگر داده های تست تماما از همان محصول باشند، (که با توجه به نوع نگهداری داده ها کاملا محتمل است) ممکن هست ارزیابی ها کاملا اشتباه باشند. اشتباه اصلی من در توسعه این سیستم ارزیابی و تیونینگ همه الگوریتم بر اساس یک سایت خاص بود که بعدا در استفاده الگوریتم برای سایرین به مشکل می خورد.مکانیزم ارزیابی و تحلیل چشمی نتایج بسیار خسته کننده و زمان بر است. برای همین باید در یک پلتفرم مناسب آماده شوند تا بیننده به راحتی بتواند در مورد خروجی الگوریتم های مختلف قضاوت کند.انتخاب زیر مجموعه ای از پارامترها که بر اساس آن ها تست های گوناگون گرفته می شود، بدیهی نیست. باید برنامه نویس مراحل اولیه اصلاح را دقیق انجام دهد تا نهایتا فضای داده تست را محدود به نمونه های کم تعداد بکند.انتخاب فیچر ورودی (Feature Selection)در هر صفحه وب اطلاعات دیتای وجود دارد. این شامل تیتر، متن، تصاویر، خصیصه های h1 و h2 و همچنین اطلاعاتی مثل دسته بندی هر صفحه هست. انتخاب بخشی از این دیتا که به عنوان فیچر ورودی باید وارد الگوریتم بشود، بدیهی نیست.باید این رو توجه داشت که استفاده از تمام دیتا مشکل بی معنی کردن وکتورها رو داره. مثلا اگه کل دیتای یک متن ورودی گرفته ممکنه بخشی از اون اقتصادی و بخشی سیاسی باشه و ترکیب آن ها وکتور رو به فضای متفاوتی ببرد.از طرف دیگر استفاده صِرف از تیتر مشکلاتی رو داره که قبلا بیان شده اند. مثلا تیتر صفحه ای "زبان سرخ رسانه" بود که ریکامندیشن های اون مطالب ورزشی می شدند که در تیتر کلمه "سرخ" رو داشتند مثل "جدال سرخ آبی ها".بعد از آنالیزها مشخص شد استفاده از تیتر به همراه بخشی از ابتدای متن مفیدترین روش است.گریزی به دسته D (محتوا محور/ کاربر محور)حال آن که همه آیتم ها به بردار تبدیل شده اند، پایه برای تولید ریکامندر سیسم کاربر محور هم مهیا می شود.درواقع با در اختیار داشتن همان وکتورهای قسمت پیشین، می توان فهمید علاقه هر کاربری کجاست. هر کاربر نقاطی را مشاهده می کند که بهم نزدیک هستند و در نتیجه می توان مطالبی را که در همان ناحیه ها وجود دارند به او پیشنهاد داد.برای عملیاتی تر شدن روش در یکتانت از خوشه بندی (clustering) استفاده کرده ایم.ریکامندیشن محتوی محور برای کاربر الگوریتم های بازدید محور (Collaborative Filtering)صفحاتی که کاربران در فضای وب می بینند، در دیتای یکتانت رکورد می شوند. این دیتا به فرمت زیر هست.user_i, item_j, timestampحال اگر به ایده امبدینگ برگردیم، یک روش دیگر برای اِمبدینگ آیتم ها، استفاده از بردار بازدید آن ها توسط کاربران است. در واقع برای هر آیتم یک بردار به طول تمام کاربران در نظر میگیریم که هر کاربری از آن آیتم بازدید کرده مقدار یک و سایرین مقدار صفر می گیرند. برای مثال در تصویر زیر دو ماشین سیاه مشابهند چون کاربران مشابهی آن ها را دیده اند.ماتریس بازدید 5 کاربر از صفحات مربوط به 6 ماشیندر این روش بردارها و کل ماتریس به شدت اسپارس هستند. زیرا هر آیتم توسط کاربران بسیار کمی دیده شده و هر کاربر هم آیتم های کمی دیده است. علاوه بر این همان ایرادات روش پایه ای امبدینگ متن، این جا هم با تفاوت هایی وجود دارند.در نتیجه برای امبدینگ پیشرفته تر (و کاهش ابعاد) از تجزیه ماتریس استفاده می شود.تجزیه ماتریس (Matrix Factorization)تجزیه ماتریس فرایند شکستن ماتریس های sparse به ماتریس های کوچک تر است. یکی از الگوریتم های آن که در ریکامندر سیستم یکتانت استفاده می شود، ALS نام دارد.تجزیه ماتریساگر تعداد کاربران n، تعداد آیتم ها m باشد، ماتریس بازدید کاربران از صفحات وب n x m می شود. در تجزیه ماتریس، آن ها به دو ماتریس کوچک تر k x m و m x k تبدیل می شوند که ضرب آن ها ماتریسی نزدیک به ماتریس اصلی را ایجاد می کند. k در این جا یک هایپر پارامتر است که تعداد فیچرهای در نظر گرفته شده برای هر آیتم و هر کاربر می باشد.در ماتریس آیتم ها، آن ها به بردارهای معنی داری متناظر شده اند به طوری که آیتم های مشابه بردارهای نزدیک به هم دارند. از همین بردارها می توان مسیر الگوریتم قبلی را طی کرد. برای هر آیتم، آیتم های با بردار نزدیک به آن را ریکامند می کنیم.استفاده از تجزیه ماتریس برای ریکامندیشن کاربر محور (دسته C)طرف دیگر الگوریتم تجزیه ماتریس، امبدینگ کاربران است. در ماتریس U هر کاربر به یک بردار k بعدی تبدیل شده که دو کاربر شبیه به هم بردار نزدیک دارند. علاوه بر این ضرب بردار کاربر i در آیتم j یک عدد تولید می کند که نشان دهنده میزان علاقه کاربر i به آیتم j است.در واقع پیش بینی می کند که میزان علاقه هر کاربر به هر آیتم که قبلا ندیده، چه قدر است. از این رو می توان با مرتب کردن علاقه های پیش بینی شده برای هر کاربر آیتم هایی که احتمالا از نظر او جذاب خواهند بود را به او ریکامند کرد.ملاحظات مهم در روش تجزیه ماتریسدر پایه الگوریتم تجزیه ماتریس فرض شده است که هر خانه ماتریس امتیاز یک کاربر به آیتم است. برای مثال کاربری که از آمازون خرید می کند، به هر آیتم آن فروشگاه ممکن است امتیازی بین 1 تا 5 بدهد. اما در فضای وب امتیازدهی مستقیم وجود ندارد. روش امتیاز دهی اصطلاحا غیر مستقیم (Implicit) است. هر کاربر یا از یک صفحه بازدید کرده است یا نکرده است. نه در هنگام بازدید می توانیم مطمئن بگوییم کاربر به مطلب علاقه داشته است نه در هنگام عدم بازدید متوجه می شویم که کاربر بدون علاقه به مطلب بوده است. این موضوع باید در انتخاب کتابخانه ها و الگوریتم ها به طور دقیق تر لحاظ شود.البته می توان فرض کرد که کاربری که چند بار از یک صفحه بازدید کرده، به آن علاقه بیشتری دارد.وجود بات ها - که در فضای وب که به صورت رندوم صفحات مختلف را دریافت می کنند- می تواند این الگوریتم را با چالش مواجه کند. در این مورد لازم است تا از تکنیک های متراکم کردن ماتریس استفاده شود تا سطرها و ستون های با بازدید کم حذف شوند.با توجه به سنگین بودن هزینه پردازش و میزان بالای تغییرات در صفحات وب و کاربران لازم هست تا از تکنیک های آنلاین برای اضافه کردن آیتم یا کاربر به ماتریس استفاده شود. این از طریق محاسبات ریاضی امکان پذیر است.ملاحظه ای مهم در ریکامندیشن کاربر محورهر دو الگوریتم کاربر محور به گونه ای طراحی شده اند که احتمال ریکامندکردن مطالب تکراری زیاد می شود. از نقطه نظر محصولی چنین اتفاقی نباید بیفتند چرا که ریکامندیشن تکراری نه تنها برای کاربران جذاب نیست، بلکه منزجر کننده هم خواهند بود. دوستی می گفت "دیجی کالا هر هفته search history من رو بهم ایمیل می کنه." ترکیبی از مشکل overspecialization و پیشنهاد آیتم تکراریزنگ تفریح | آینده ریکامندر سیستم کابر محورریکامندیشن کاربر محور محیط محصول و اسکیلاگرچه که این مقاله با تمرکز بر روی الگوریتم ها نوشته شد، چالش هایی در مرحله محصول (پروداکشن) هستند که تاثیر زیادی روی الگوریتم ها داشته اند. در این قسمت گزیده کوتاهی از آن ها رو بیان می کنم.همسایه یابی تقریبی (Approximate Nearest Neighbor)همسایه یابی عملیات سنگینی و غیر قابل استفاده در پروداکشن هست. برای بهینه کردن آن از روش های تقریبی استفاده می شود. ما در ریکامندر سیستم یکتانت از کتابخانه Annoy استفاده کردیم که با به کارگیری جمعی از تکنیک های الگوریتمی و فنی، روش سریع تری برای همسایه یابی استفاده می کند.معماری Fetch-Managerدر این معماری، پروژه به دو قسمت fetch و manager شکسته شد که در قسمت manager، ریکامندیشن ها تولید و در fetch صرفا پاسخگویی به fetch بدون پردازش اضافی انجام می شود. در این صورت fetch بسیار سبک و قابل توزیع روی چند سرور می شود.با چنین ایده ای و استفاده از 2 سرور 2 هسته ای اضافه، پاسخ گویی سریع تر می شود و اسکیل سیستم از حدود 100 ریکوئست بر ثانیه تا 500 ریکوئست بر ثانیه افزایش پیدا کرد.دیتابیس ردیس (Redis)برای ذخیره ریکامندیشن ها کل اطلاعات در دیتابیس داخل مموری Redis ذخیره شدند تا پاسخگویی سریعترین حالت باشد.آیندهریکامندر سیستم یکتانت جای پیشرفت زیادی دارد. می توان در بهبود الگوریتم ها از روش های ترکیبی بین بازدید محور و محتوا محور استفاده کرد چرا که بسیاری از سایت ها هم محتوا و هم بازدید دارند و بهتر است الگوریتم تصمیم بگیرد تا از کدام داده استفاده کند. به این روش ها hybrid گفته می شود که خود دسته بندی های عمیق تری دارند.به علاوه می توان آمار کلیک ها را در ریکامندیشن لحاظ کرد. بعضی باکس ها ذاتا کلیک بهتری از دیگران دارند و الگوریتم می تواند به مرور زمان با استفاده از این دانش، باکس هایی به کاربران پیشنهاد شوند که تعداد کلیک های بیشتری دارند.اگر ریکامندر سیستم، قدرت انتزاعی (abstraction) بالاتری داشته باشد - یعنی به جای ارائه یک بردار 20 بُعدی گنگ برای هر کاربر، برداری قابل فهم برای انسان (human interpretable) ارائه کند که کاربر مثلا علاقه مند به مطالب سیاسی است، به عنوان زیرساخت می تواند در اختیار سرویس های دیگر یکتانت قرار بگیرد تا در نشان دادن تبلیغات یا فرستادن پوش ها هوشمندانه عمل شود.توضیح واضحاتبدیهیست بسیاری از دانش گفته شده در کتابخانه ها و مدل هایی نهفته است که در از آن ها به عنوان black-box استفاده می شود.به علاوه با توجه به ماهیت علمی الگوریتمی و به منظور خلاصه سازی این مقاله از ارائه توضیحات در زمینه جزئیات کتابخانه ها و ابزارهای استفاده شده، زیرساخت داده ها و تکنیک های جزئی اما موثر تا حد زیادی خودداری شده است. در صورتی که علاقه مند به گرفتن اطلاعات بیشتر در این زمینه باشید و اهداف کاملا آکادمیک (آموزشی یا تحقیقاتی) داشته باشید، می تونید به لینکدین من پیام بدید.موقعیت شغلی Data Scientist در یکتانتدر یکتانت موقعیت شغلی دیتاساینتیست به طور خلاصه، به معنای حل مسائل شرکت از طریق الگوریتم های مبتنی بر داده ست. این روش میتواند مانند گفته های بالا از طریق الگوریتم های ماشین لرنینگ یا از طریق روش های ساده تر مثل if-else باشد. البته بخش اعظمی از کار انتقال محصول به محیط پروداکشن و انجام کارهای نرم افزاری آن است.اطلاعات بیشتر در مورد موقعیت های شغلی یکتانت رو از این جا می تونید بررسی کنید. در صورتی که مایل بودید می تونید از خود من در موردش بپرسید.سخن آخراین پست در بلاگ شخصی من و بلاگ مهندسی یکتانت به صورت مشترک منتشر شده است. در صورتی که محتوای این مقاله براتون جالب بود، با دنبال کردن هر دو صفحه می تونید مطالب مشابهی رو در آینده در آینده دریافت کنید.اگر سوالی داشتید حتما کامنت کنید و اگر مطلب رو مفید دانستید می تونید برای دوستانتون هم ارسال کنید.لینک پست در لینکدینمطلب قبلی: الستیک سرچ/ کیبانا / لاگ استش - شفاف ببینیمcontact:e-mail: armin.zirak97@gmail.comLinkedIn: Armin Zirak یکتانت | Yektanet آرمین زیرک | Armin Zirak Sat, 27 Jun 2020 18:34:45 +0430 https://virgool.io/yektanet/%D8%AA%D8%AD%D9%84%DB%8C%D9%84-%D8%AA%D8%B1%D8%A7%D9%81%DB%8C%DA%A9-%D8%AF%D8%B1-%D9%85%DB%8C%D8%AF%D8%A7%D9%86-%DB%8C%DA%A9%D8%AA%D8%A7%D9%86%D8%AA-ikxpipja6rky توی این مطلب می‌خوام با توضیح چند مسئله عملی واقعی که در یکتانت خودم درگیرشون بودم، استفاده از ابزارهایی برای تحلیل ترافیک شبکه رو به شما نشون بدم.هیچ وقت فکر نمی‌کردم چیزهایی که در آزمایشگاه شبکه به ما یاد می‌دادند، مثل wireshark، یه روزی توی کار به دردم بخوره. البته شاید هر جایی هم لازم نباشه که آدم با ابزارهای خاص شبکه سیستمش رو تحلیل کنه. حدس من اینه که در جاهایی که اندازه سیستم بزرگ می‌شه، بعضی وقتا، لازم می‌شه. یکتانت هم به عنوان یک بازار تبلیغاتی بزرگ مستعد اینه که با مسائلی مواجه بشه که - اقلا برای کسی مثل من که تجربه زیادی نداشتم - لازم باشه که از ابزار استفاده کنه تا بتونه مسئله رو بررسی و در نهایت حل کنه. دوستان از پشت صحنه اشاره می‌کنند که حل مسئله یکی از ارکان فرهنگ یکتانته :))یک - قله‌های تیز مشکوک در ترافیک ارگانیکمسئله‌های اول و دوم مربوط به زمان قطعی اینترنت بین‌الملل میشه که باعث شد نمایش تبلیغات ما در وبسایت‌های داخلی هم متوقف بشه. یکتانت به عنوان پلتفرم تبلیغات کلیکی، هر لحظه که یکی از سرویس‌هاش کار نکنه، به صورت خطی براش ضرر مالی مستقیم داره و مهم‌تر از اون اعتباریه که مردم برای این پلتفرم قائلند. تصویر با‌کیفیت و ایمن سیستم در صورتی که خرابی سرویس‌ها طولانی باشه خدشه دار می‌شه. پس ما سریعا تصمیم گرفتیم که با تغییر دادن توپولوژی شبکه سرویس‌رسانی، مشکل رو حل کنیم و دوباره نمایش تبلیغاتمون رو برقرار کنیم. خوش‌بختانه در زمانی که ما زندگی می‌کنیم بیزینس‌هایی بومی مثل ابر آروان وجود دارند که خدمت شبکه توزیع محتوا (CDN) و واسطه‌ی ابری رو ارائه می‌دن. یعنی چیزی مشابه خدمتی که CloudFlare ارائه می‌ده. ما برای حل مسئله لازم بود که از CloudFlare روی یک سرویس داخلی سوئیچ کنیم.بعد از این که تغییرات لازم رو انجام دادیم و از ابر آروان استفاده کردیم یک الگوی عجیب در ترافیک تبلیغاتمون مشاهده کردیم. جا داره اولین ابزار رو همین‌جا به شما معرفی کنم که در روزهای سرد و گرم زندگی در عین سادگی‌اش در کنار بچه‌های فنی یکتانت بوده. یکی از ابزارهایی که ما استفاده می‌کنیم netdata است که به محض این که روی سیستمت نصبش کنی کلی اطلاعات مفید رو برای مانیتور کردن زیرساخت در اختیارت می‌ذاره. این ابزار بود که به ما کمک کرد این مشکل رو کشف کنیم. نمودار زمانی تعداد درخواست‌های سامانه در هر ثانیه به شکل زیر در اومده بود که اصلا چیزی نیست که طبیعی باشه.نمودار تعداد درخواست بر ثانیهچیزی که در این نمودار مشاهده می‌کنید اصلا طبیعی نیست چرا که ترافیک مشاهده‌ی تبلیغات (صفحات وب فارسی) یک ترافیک کاملا ارگانیکه و توسط سیستم‌ها ایجاد نمی‌شه. و ربات‌ها هم هیچ‌وقت در حد و اندازه‌ای نیستند که در رقابت با کاربران واقعی بتونن همچین الگوی ترافیکی‌ رو ایجاد کنند. ترافیکی که طبیعی باشه و از سمت کاربر بیاد از این قله‌های تیز نداره. اگه بخواد همچین اتفاقی بیفته احتمالا باید شاهد همچین چیزی در خبر سراسری باشیم:- جناب آقای حیاتی: «خوب هموطنان عزیز با شمارش من همگی با هم صفحه‌های موبایلتون رو رفرش کنید. یک، دو، سه … حالا دوباره،‌ یک، دو، سه ...»چون بازدیدکنندگان صفحات وب با هم هماهنگ نیستند تعداد درخواست بر ثانیه، نمودار نرمی داره و فاقد قله‌های تیزه. پس در واقع ما با یک ابزار ساده و یک تحلیل ریز تونستیم مشکل رو کشف کنیم.اگر شهود کافی روی ساز و کار وب داشته باشید این الگو حاصل کش شدن صفحات وب می‌تونه باشه. چون معمولا کش‌ها عمر چند دقیقه‌ای دارند و با ورود اولین کاربر، صفحه پردازش و ذخیره می‌شه و برای مدتی از همون صفحه برای کاربرهای بعدی استفاده می‌شه. به دلایل مختلف از جمله این که سامانه رو تازه بالا آورده بودیم صفحات مختلف به صورت همگام از کش ابر آروان خارج می‌شدند و باعث‌ می‌شد این الگوی غیر طبیعی ایجاد بشه.اما چرا این اتفاق برای ما بده؟ دلیلش اینه که یکتانت به ازای هر مشاهده کاربران مقداری پردازش انجام می‌ده تا تبلیغات رو برای اون کاربر خاص تدارک ببینه و اگه درخواست‌های ما کش بشن عملا سرویس ما پردازش‌های مختص کاربران رو انجام نمی‌ده و تاثیر منفی روی احتمال مناسب بودن تبلیغات برای کاربر داره. و این یعنی احتمالا کاربران، کمتر تبلیغات رو دنبال می‌کنند و در نهایت درآمد سامانه پایین می‌آد.برای حل این مسئله به پنل ابر آروان رفتیم و کش مورد نظر رو غیر فعال کردیم. درسی هم که از این مورد می‌گیریم اینه که هر سرویس جدیدی که استفاده می‌کنید باید خیلی دقیق تنظیماتش رو انجام بدید.دو - کانکشن‌های یتیم خیلی زیاد (منظور همون کانکشن‌های orphan عه)مشکل ما تعداد غیر طبیعی و زیاد کانکشن‌های یتیم بود که باعث می‌شد منابع سرور تموم بشه و دیگه کانکشن جدید نشه زد. شاید برای شما عجیب باشه ولی کانکشن‌ها هم مثل آدم‌ها یتیم می‌شن. حتی کانکشن‌ها رفوزه هم می‌شن :) برای کسایی که کمتر آشنا هستند بگم که کانکشن وقتی یتیم می‌شه که پردازه‌ی صاحبش از بین بره ولی کانکشن باقی بمونه.همون موقعی که ما به CDN داخلی سوئیچ کردیم دیدیم که درخواست‌های دریافت عکس‌های تبلیغاتی به شکلی باعث می‌شن کانکشن‌های یتیم و در پی اون تعداد کانکشن‌های اشغال شده زیاد بشه.کسی که این واقعیت رو به ما نشون داد باز netdata بود. باید بگم که netdata کلی هشدار از پیش آماده داره که وقتی اونو روی سرورتون نصب می‌کنید معیارهای مختلف رو رصد می‌کنه و در صورتی که غیر طبیعی باشن به شما هشدار می‌ده. خلاصه ایشون به ما هشدار داد که کانکشن‌های یتیم زیاد شده‌اند.من هم برای حل این مشکل تصمیم گرفتم با ابزار wireshark که در دانشگاه ازش استفاده کرده بودم ترافیک سرور رو در لایه TCP تحلیل کنم و ببینم که چرا کانکشن‌ها یتیم می‌شن. البته wireshark برای استفاده در محیط بدون گرافیک سرور مناسب نیست و من از tshark استفاده کردم. چیزی که مشاهده کردم این بود که علی‌رغم این که CDN می‌خواست کانکشن TCP رو ببنده و دستور FIN رو ارسال می‌کرد ولی nginx که وظیفه سرو کردن عکس‌ها رو داشت دستور FIN رو نمی‌فرستاد و صبر می‌کرد. بسته‌های یکی از کانکشن‌ها رو می‌تونید در زیر ببینید:بسته‌های مربوط به یکی از کانکشن‌های یتیماگه مایلید که جزئیات بیشتر این مسئله رو ببینید می‌تونید به سوالی که در سرورفالت پرسیدم مراجعه کنید. چون تعداد ریکوئست‌ها بالا بود من یک و نیم ثانیه از ترافیک رو کپچر می‌کردم که حجمش زیاد نشه و بتونم دانلودش کنم.علت این که nginx دستور پایان کانکشن رو ارسال نمی‌کرد این بود که ابر آروان از هدر Keep-Alive در لایه HTTP استفاده می‌کرد و این باعث می‌شد که nginx در لایه TCP اش، کانکشن رو باز نگه داره تا شاید چیز دیگه‌ای برای ارسال به کاربر وجود داشته باشه. با کاهش مدت زمان کانکشن‌های Keep-Alive از ۶۰ ثانیه به ۱۵ ثانیه این مشکل حل شد.سه - دامنه که فیلتر شده باشه رفتار HTTPS چه شکلی می‌شه؟چند ماه پیش تصمیم گرفتیم پلتفرم جدیدمون یعنی جریان رو ایجاد کنیم که بستری برای تبلیغات در شبکه‌های اجتماعیه. وقتی دامنه رو راه‌اندازی کردیم خیلی عجیب بود که صفحه‌ی سامانه لود نمی‌شد. حدس زدیم که دامنه از قبل فیلتر بوده و من مامور شدم که از این حدس اطمینان حاصل کنم.باز هم wireshark رو وارد میدان کردم و صفحه رو لود کردم. جالبه که بدونید درخواست‌های HTTPS قبل از این که از حالت رمز در بیان، لازمه که مشخص باشه مربوط به کدوم وبسایت روی یک سرور هستند. حالتی رو فرض کنید که چند وب‌سایت روی یک سرور در حال سرو شدن باشند. و هر کدوم برای رمزنگاری از کلید‌های مختلف استفاده کنند. در این صورت حتما لازمه که در داده‌های غیر رمز شده‌ی HTTPS چیزی باشه که مشخص کنه درخواست مربوط به کدوم وبسایت (دامنه) می‌شه.برای همین در یکی از مراحل HTTPS بسته‌ای به عنوان ClientHello ارسال می‌شه که شامل ServerName مربوط به درخواسته. نتیجه‌گیری اخلاقی‌ای که اینجا می‌شه کرد اینه که اگه جایی هستید که ترافیکتون شنود می‌شه، شاید محتویاتتون رو با HTTPS به صورت ایمنی جابجا کنید؛ ولی اگه مثلا به سایت خاصی برید، کسی که داره ترافیکتون رو شنود می‌کنه می‌فهمه که به اون سایت رفتید؛ حتی اگه در حال استفاده از HTTPS باشید.همین موضوع کمک می‌کنه که سامانه فیلترینگ بتونه درخواست‌های HTTPS ای که برای دامنه‌های فیلترشده هستند رو قطع کنه. رفتاری که نهایتا شما مشاهده‌ خواهید کرد اینه که یک کانکشن TCP ایجاد می‌شه و HTTPS پیش می‌ره و بعد از این که نام سرور مورد نظر از سمت مرورگر ارسال می‌شه دیگه هیچ پاسخی از سمت سرور دریافت نمیشه، انگار که دیگه هیچ پاکتی در اون اتصال TCP قابلیت رفت و آمد نداشته باشه و این باعث می‌شه که سمت مرورگر یک Timeout اتفاق بیفته.راستی به دلیل این که درخواست HTTPS هست و سامانه فیلترینگ کلید سرور اصلی رو نداره نمی‌تونه به جای سرور اصلی جواب شما رو بده و شما رو به peyvandha بفرسته. به این شکل مطمئن شدم که دامنه‌مون فیلتره و بعد از اون درخواست خاصی دادیم که مشکلش رفع بشه.به عنوان مهندس نرم‌افزار در یکتانت حالا که برمی‌گردم و به این مدت نگاه می‌کنم که یکتانت بودم خیلی خوش‌حالم چون یکتانت برای من جایی بود که کلی فرصت برای گرفتن مسئولیت و تجربه‌ی چیزای جدید داشت. اتفاقی که خیلی توی یکتانت می‌افتاد این بود که باید مسئله‌ها رو صفرتاصدی حل می‌کردیم. این فرصتیه که وقتی یکتانت رو انتخاب می‌کردم توی سازمان‌های خیلی مسن‌تر اتفاق نمی‌افتاد. اگه علاقه‌مند بودید می‌تونید با فرصت‌های شغلی یکتانت بیشتر آشنا بشید. اولین بارمه که اینجا مطلب می‌نویسم و امیدوارم که این مطلب براتون قابل استفاده بوده باشه. اگه جاییش رو اشتباه گفتم یا مبهمه خیلی خیلی خوشحال می‌شم که توی کامنت‌ها مطرح کنید. اگه ببینم این کار به درد بخور بوده ایشالله در مطلبای بعدی از چالشهای دیگری که در بخش فنی یکتانت داشتیم براتون می‌نویسم. یکتانت | Yektanet Ali Asgari Thu, 18 Jun 2020 15:48:38 +0430 https://virgool.io/yektanet/%D8%A7%D9%84%D8%B3%D8%AA%DB%8C%DA%A9-%D8%B3%D8%B1%DA%86-%DA%A9%DB%8C%D8%A8%D8%A7%D9%86%D8%A7-%D9%84%D8%A7%DA%AF-%D8%A7%D8%B3%D8%AA%D8%B4-%D8%A8%D9%87%D8%AA%D8%B1-%D9%88-%D8%B4%D9%81%D8%A7%D9%81-%D8%AA%D8%B1-%D8%A8%D8%A8%DB%8C%D9%86%DB%8C%D9%85-eoxqs9apbwlt این مقاله با بررسی روند توسعه یک سیستم ریکامندر برای سایت های خبری ایرانی نشون میده که چرا استفاده از مجموعه ELK برای توسعه یک اپلیکیشن واقعی نه تنها بسیار مفید بلکه حیاتی و ضروریه…من مسئولیت توسعه یک سیستم ریکامندر رو در یکتانت دارم که به وبسایت های خبری فارسی عرضه می شه. سیستمی که در هر صفحه از یک سایت چند مطلب پیشنهادی رو به کاربران نشون می ده. مثلا در صفحه زیر از سایت انتخاب که یک خبر از کرونا نوشته سه مطلب دیگه در مورد همین اتفاق در باکس "مطالب مرتبط" نمایش داده شده اند. در مورد چگونگی کار این سیستم (الگوریتم ها، ایده ها و چالش ها) مطلبی جدا در این جا منتشر شده است، اما هدف این مقاله توضیح این هست که چرا در این سیستم وجود مجموعه ای معروف به ELK یعنی (Elasticsearch, Logstash, Kibana) نه تنها مفید بلکه لازم و حیاتی بود. اگر چه که این مقاله با تمرکز روی نیازهای سیستم ریکامندر نوشته شده ولی خوندن اون کمک می کنه که در جاهای دیگه هم موارد استفاده مجموعه رو پیدا کرد. برای آشنایی بهتر با خود سیستم ریکامند و استفاده ELK در اون دونستن این موارد کمک می کنه.1. برای بررسی کیفیت این سیستم از معیار CTR (نرخ کلیک به نمایش) استفاده می شه. درواقع ما تعداد کاربرهایی که روی مطالب این باکس کلیک کردند رو بر تعداد کل کاربرهایی که وارد صفحه ها شدند، تقسیم می کنیم. (با یک ساده سازی) حاصل هر چه قدر بیشتر باشه، یعنی بهتر عمل کردیم.2. در این سیستم بعضی مواقع صفحه ای به کاربران پیشنهاد داده نمی شه و اون باکس حذف می شه. این به کانفیگ های سیستم و عملکرد سیستم های دیگه ای که باهاشون ارتباط هست بستگی داره و ممکنه کم یا زیاد بشه.حالا مسئله این جاست که چطور می تونیم این اعداد یعنی تعداد بازدید، کلیک و میزان صفحه های بدون پیشنهاد رو محاسبه کنیم؟ محاسبه ای که فقط یک عدد نباشه بلکه نمودارهای کامل و گویا بهمون بده و بشه توی زمان های مختلف فیلترش کرد و تغییرات رو توش دید. و از همه مهم تر این که ساده به دست بیاد تا به بتونیم مرتب چکشون کنیم، خروجی های جدید پیدا کنیم و وقتمون رو بیشتر از این که صرف ساختنشون کنیم صرف تحلیلشون بکنیم. مثلا اگه بخوایم به نمودار زیر برسیم به طوری که وقت کمی صرفش کنیم، چطور این کار امکان پذیره؟ حالا فرض کنین این نمودار رو بخوایم به سادگی یک کلیک به چندتا نمودار مجزا برای هر سایت تبدیل کنیم. آمار بازدید در ساعت های مختلف روزهای مختلفبرای حفظ محرمانگی داده های سایت هایی که از سیستم ریکامندر استفاده می کنند، قسمت هایی از عکس ها blur یا حذف شده اند. به علاوه محاسبات ناقصه و در بازه های زمانی محدود انجام شده.قبل از توضیح راه حل رسیدن به چنین نقاشی زیبایی، از فوایدش بگم. این نمودارها دانش و بینش به آدم های مختلف می ده. به دولوپر دید می ده که سیستم در چه حاله. اگه داره ضعیف می شه بهبودش بده و اگه مشکلی پیدا کرده که غیر مستقیم عملکرد سیستم رو کاهش می ده، سریع متوجه اون بشه قبل از این که مشکل خسارت به بار بیاره.وجود این نمودارها، به دولوپر کمک می کنه راحت توی الگوریتمش و کانفیگ ها تغییر بده و نتایج رو ببینه. مثلا اگه نمودار کلیک رو بررسی کنه و ببینیه کاهش داشته می فهمیه تغییرات اخیر مشکل زا بودند. به مسئولای غیر فنی تر (پروداکت منیجر، ارتباط با مشتری، بیزینس و مدیرانی که از جزئیات سیستم خبر ندارند) کمک می کنه که نتایج رو در سطح بالاتر بررسی کنند، به نیازمندی های جدید برسند و مشتری ها رو راهنمایی کنند. اگه اعداد درصد CTR در دو سایت خبری و غیر خبری رو ببینیم که یکی بیشتر باشه دولوپر به دنبال نقص الگوریتمی یا کدی در سایت ضعیف تر می گرده و بیزینس می فهمه محصول رو به چه مشتری هایی تحویل بده که بهتر استفاده کنند.مهم تر از همه، برای ساختن این اعداد و نمودارها، نباید وقت و انرژی به خرج بدیم چون وقت و انرژی باعث می شه که دیگه سراغ ارزیابی ها نریم و اتفاقات مهم و تحلیل ها رو ناخواسته از دست بدیم. باید هر کسی به راحتی آمارش رو تولید و استفاده کنه. اما برگردیم به محیط دولوپ عادیمون. با یک تیکه کد پایتون یا جاوا چطور می تونیم چنین بینشی رو به دست آورد؟(زنگ تفریح) اگر فیلم See رو ندید حتما ببینید و اگه دیدید، به ارتباط دو تا عکس زیر و مقاله فکر کنین!(حاشیه) یک راه حل بد یک راه حل دم دستی اینه که ایونت ها رو در یک دیتابیس ثبت کنیم. مثلا از هر بازدید و هر کلیک یک آبجکت بسازیم و ثبت کنیم یا فیلد کانتر در یک آبجکت دیگرو تغییر بدیم. بعدا روی این آبجکت ها کوئری بزنیم و بشمریم. از عیوب نامنتهی این راه حل چند مورد بگم.1. برنامتون و خودتون رو کند می کنه. شما برای هر نوع ایونتی باید یک مدل توی دیتابیستون درست کنید و این با کوئری های اضافه همراهه. بعد باید بشینید راه حلی برای ذخیره کردن بهینه آبجکت ها پیدا کنید. مثلا از یک دیتابیس سریع استفاده کنید، داده هارو async ذخیره کنید، aggregate کنید یا ... این ها همه پیچیدگی ناخواسته به کد و نرم افزار شما ایجاد می کنه.2. هر موقعی که تصمیم بگیرید، ایونت هارو تغییر بدید (اطلاعات بیشتری بهشون اضافه کنید یا مدل دیگه ای از دانش رو ثبت کنید) باید با دیتابیس درگیر بشید. باید کدهای جدید برای مدل های مختلف بنویسید.3. باید پنل فرانت اند و API بک اند طراحی کنید! پنل فرانت به سادگی یک جدول هم کلی وقت گیره مخصوصا اگه این کار رو بلد نباشید! این ممکنه وابستگی به افرادی که فرانت بلدند توی محل کارتون ایجاد کنه و کندترتون کنه. علاوه بر اون باید بعدا هم مرتب تغییرش بدید. جدای از این که خیلی محدودیت ها ممکنه داشته باشه. حتی وجود پنل ادمین در فریم ورک هایی مثل جنگو هم دردی رو دوا نمی کنه.بسیار ساده بگم. شما به زودی بی خیال ادامه مانیتور کردن می شید. تصمیم می گیرید که به داشته های زندگی راضی باشید و مسیر رو کور ادامه بدید.پ.ن: برای موارد خیلی اساسی مثلا کلیک در سیستمی که بر اساس کلیک پول می گیره احتمال داره دیتابیس راه مطمئن تری باشه اما برای انواع و اقسام ایونت ها که در حجم بالا و با تنوع زیاد تولید می شن، این راه حل عملی نیست.راه حل خوب؟ برای ثبت اتفاقات سیستم یک روش معقول وجود داره و اون لاگ کردنه! بله. خیلی راحت هر اتفاقی افتاد انتهای یک فایل بنویسید.logger.log('an event occurred')اگه خوب کانفیگوریشن هارو انجام داده باشید همراه این مسیج، زمان، شماره خط کد، اسم تابعی که این ایونت توش بوده و اطلاعات لازم دیگه هم می تونه نوشته بشه. تهش خیلی ساده یه خط این شکلی میره ته فایل![11/04/2020 21:00:00 INFO [main.py:2] an event occurred] این هیچ لودی به سیستم اضافه نمی کنه چون داره انتهای یک فایل فقط می نویسه. به شما هم لودی وارد نمی کنه چون هر وقت که خواستید خیلی راحت عوضش می کنید یا لاگ های جدید ثبت می کنید. فایل هاتون هم بعدا با ابزارای دیگه ممکنه پاک بشن و برن و کلا مسئولیت این مسائل از سیستم جدا می شه.حالا چطوری دانش و بینش ازش خارج کنیم؟ لاگ ها قبلا هم به طور خودکار توسط خیلی سیستم ها مثل nginx تولید می شد اما تبدیل این لاگ های حجیم به یک دانش مفید مهمه. این جاست که ELK وارد میدان می شه.استک ELK ساخته شده تا به این نیاز پاسخ بده. این استک از 3 عضو Elastic search, Logstash, Kibana ساخته شده. لاگ هاتون رو وصل می کنید به این مجوعه و می رید تو کیبانا و نمودارای قشنگتون رو می کشید. (توضیح فنی تر انتهای متن)مثال 1 من موقعی که هر درخواستی از سیستمم بشه اگه از کش استفاده بشه می نویسم cache hit وگرنه می نویسم cache missed. در نتیجه با کیبانا نمودار زیر رو درست کردم که برای هر سایت میزان استفاده از کش رو نشون می ده. چرا برای سایت های مختلف فرق می کنه؟مثال 2 جدول زیر به ما نشون می ده که هر سایتی چه درصد کلیکی داره و تو چند درصد بازدیدهاش ما تونستیم جواب بدیم! با یک کلیک روی این داشبور و دیدن این که همه چی خوبه خیال ما راحت می شه. می فهمیم کدوم سایت ها خوب عمل می کنیم کدوم بد. بر اساس ستونای مختلف می شه مرتب کرد یا بر اساس فیلتر زمانی فیلتر کرد. مثلا من تفاوت کلیک دیروز با امروز رو بعد از تغییر کانفیگ رصد کردم و تو هر سایتی براساس محتواش به نتیجه متفاوتی رسیدم.جدول از آمار بازدیدها و کلیک های سایت های مختلفمثال 3 توی یک A/B testing قصد داشتم ببینم که ریکامندر در مقایسه با یک الگوریتم ساده تر (مثلا الگوریتمی که پربازدید ترین مطالب سایت (تِرِند) رو پیشنهاد می داد) چطور کار می کنه. به خاطر همین به صورت رندوم جواب رو با الگوریتم های مختلف برگردوندم و در لاگ موقع کلیک ثبت می کردم که توی چه الگوریتمی کلیک شده. نتیجه زیر نشون داد که الگوریتم ریکامندر از الگوریتم تِرِند بسیار بهتره. این کار رو می شد برای مقایسه دو الگوریتم خوب و یا دو کانفیگ مختلف از یک الگوریتم انجام داد.مثال 4من از یک سیستم پشتیبان استفاده می کنم که بعضی مواقع پاسخ گو نیست! نمودار زیر به من نشون می ده که میزان پاسخگو نبودن این سیستم در یک هفته گذشته چطور بود و کجا به اوج خودش رسیده. این طوری می تونم از مسئولش دقیق تر پیگیر مشکل بشم.یک دولوپر در حال تحلیل نمودارهانکته مهم: قابلیت و استفاده این مجموعه احتمالا فقط این جا نیست. مثلا ممکنه داده های غیر لاگ رو هم بخواید با مجموعه ELK نمایش بدید یا از دیتابیس Elasticsearch استفاده دیگه ای داشته باشید. این مقاله صرفا توضیح یک مورد استفاده این مجموعه در کنار هم هست.بخش فنیاستک ELK چه طور هست؟ این استک از سه جز اصلی الستیک سرچ، کیبانا و لاگ استش تشکیل شده که بهشون بیت ها هم می تونند اضافه بشن. الستیک سرچ (Elasticsearch)الستیک سرچ به عنوان قلب این مجموعه یک دیتابیس جست و جو بر اساس متن هست. یعنی خیلی خوب می شه توش روی متن های ذخیره شده کوئری زد.(از ایندکس لوسین استفاده می کنه)الستیک سرچ یک API به بیرون می ده که با اون می شه کوئری هایی رو داخلش زد. یک API هم می ده که ابزارهای دیگه مثل لاگ استش یا فایل بیت - که جلوتر در موردشون توضیح داده می شه - بتونند ازش استفاده کنند. در واقع کل داده های لاگ ما در داخل این دیتابیس ذخیره می شن و بعدا با کوئری زدن به نتایجی که می خوایم می رسیم.الستیک سرچ به شکل قلبالستیک سرچ به طور مجزا secure می شه و برای ارتباط با هر کدوم از ماجول های دیگه می شه آتنتیکیشن جدا آماده کرد. (خبری چند وقت پیش برای لو رفتن داده حدود 40 میلیون کاربر تلگرام منتشر شده بود که ادعا می کرد که این اطلاعات از یک دیتابیس الستیک سرچ بدون پسورد سرقت شده اند!)سوال انتقادی: در راه حل بد من ادعا کردم که استفاده از دیتابیس روش خوبی نیست و حالا در راه حل خوب نهایتا از دیتابیس Elasticsearch استفاده شد! پس چی شد؟!کیبانا (Kibana)کیبانا ابزاری هست که باهاش می شه نمودارها رو در یک پنل کاربری درست کرد و بعد خودش اون ها رو تبدیل به کوئیری الستیک سرچ می کنه. کیبانا کوئری رو از طریق API الستیک کال می کنه و نهایتا خروجی اون رو تبدیل به نمودارهای گرافیکی می کنه. مثلا در نمونه زیر به سادگی دو فیلتر روی داده انجام شده. یکی فیلتر داده های 15 دقیقه پیش و دیگری وجود لغت click در داده که نشون دهنده لاگ مربوط به کلیک هست. بعد یک piechart درست شده که بر اساس لغت پابلیشر به 4 قسمت مختلف تقسیم کرده و تعداد رو شمرده. (در اون زمان 4 وب سایت از سرویس ریکامندر استفاده می کردند.)نمونه نمودارنکته مهم: اطلاعات خود کیبانا (داشبوردها، ویژوال ها و ...) در خود الستیک سرچ ذخیره میشن.لاگ استش (Logstash)لاگ استش لاگ ها رو می گیره، پارسشون می کنه و به الستیک سرچ می فرسته. مثلا اگه توی لاگ اطلاعات زمان دارید می تونید در این مرحله از لاگ استخراج کنید تا به سری زمانی (مثال 4) برسید. علاوه بر این توی مثال بالا لغت publisher رو هم لاگ استش از توی لاگ ها استخراج کرده. می تونه IP ها رو از لاگ هایی که داخلشون این اطلاعات هست استخراج کنه و به موقعیت مکانی دقیق شامل latitude, longitude, city, country و ... تبدیل کنه. علاوه بر این می تونه مثلا اعداد رو بعد از استخراج از داخل استرینگ به عدد واقعی تبدیل کنید تا الستیک قابلیت اجرای عملیات های ریاضی مثل جمع و مدین رو روشون داشته باشه. این کارها با پیداکردن پترن توسط یک ماجول داخلی به اسم grok یا dissect انجام می شه و تبدیل ها رو فیلترهای تخصصی به نام های Date, geoip و ... انجام می دن.لاگ استش همین طور نقش مالتی پلکسر رو می تونه داشته باشه و از چندین سورس مختلف با فرمت های گوناگون دیتا بخونه و تفکیک کنه.استک ELKبیت ها (Beats)برای جمع آوری داده ها از سیستم های مختلف و انتقال اون ها از یک سری بیت می شه استفاده کرد. اصلی ترین اون ها Filebeat هست.فایل بیت کار جمع آوری داده از فایل های لاگ معمولی و انتقال اون به لاگ استش رو انجام می ده. توی حالت ساده می شه فایل لاگ رو مستقیم به خود لاگ استش وصل کرد اما مثلا وقتی فایل لاگ روی یک سرور دیگه هست و لاگ استش جای دیگه، فایل بیت به عنوان یک ماجول تخصصی مسئولیت این انتقال رو به عهده میگیره. مزایای حرفه ای تری مثل مدیریت نرخ ارسال لاگ ها به لاگ استش درمواقع سنگینی رو هم می فهمه و می شه باهاش کدگزاری های لازم برای حفظ امنیت داده هارو انجام داد. (در حالت ساده می شه هم خود فایل بیت رو به الستیک وصل کرد.)معماری سیسم به همراه بیت هاعلاوه بر اون بیت های دیگه مثل metricbeat و heartbeat کمک می کنه که وضعیت سلامتی سرور و اپلیکیشنتون رو مانیتور کنید.دیتای جمع آوری شده توسط Heartbeat در کیباناانواع بیت ها برای انواع داده هاقابلیت های کیباناکیبانا از یک سری ویژوالایزیشن های آماده تشکیل شده که لیستش در زیر نشون داده شده. در هر کدوم می تونید یک مجموعه از داده ها رو ورودی بدید و بر اساس فیلترهای مختلف (مثلا وجود کلمه های خاص در لاگ ها) می تونید محورهای مختلف نمودارهاتون رو تعیین کنید، یا نموداررو به نمودارهای کوچک تر تبدیل کنید و ... چون قاعده کار بین بیشتر اون ها یکسان هست، خیلی سریع می تونید باهاش آشنا بشید.قسمت خیلی قشنگ و راحت کیبانا دشبوردهاش هستن. هر دشبورد خیلی ساده یک مجموعه از ویژوالایزیشن های بالاست که کنار هم قرار گرفته تا راحت کار کنید. خیلی راحت می تونید هر ویژوال رو با سایز دلخواه اون جا بگذارید و بعد ذخیره کردن، با بازکردن دشبورد همه ویژوال هارو یک جا می بینید. یک نمونه دشبورد خفندر کیبانا می تونید یوزرهای مختلف با دسترسی های متفاوت درست کنید. مثلا برای هر دولوپر دسترسی به داده خودش بدید و برای قسمت های بیزینسی یا مدیریتی شرکت یوزرهایی بسازید که دسترسی مشخصی به داشبوردها و داده های مربوط به خودشون دارند. این طوری هم خیالتون از بابت اشتباهات ناخواسته آدم ها در کار با سیستم راحت می شه و هم حریم خصوصی کاربرانتون رو در نشرنکردن داده ها با افراد غیر مربوط حفظ می کنید.پنل ورود کاربر به کیبانافیچرهای کیبانا به این جا محدود نمی شه. موارد زیر هم هست که من تا الان استفاده ای برام نداشته و صرفا نام می برم.کانواس: برای درست کردن مطالب تبلیغاتی. می تونید این ها رو برای مشتری ها بفرستید. داده ها رو زنده بهتون نشون می ده.کانواسنقشه: برای تصویر سازی داده های نقشه که latitude و longitude دارند. (اگه یادتون باشه گفتم که لاگ استش IP رو می تونه تبدیل به این داده ها بکنه.) داده های پیچیده تر نقشه هم ساپورت می کنه.نقشه کیبانا لنز: برای درست کردن گرافیک های خفن تر به طور ساده تر که حتی بهتون پیشنهاد خودکار برای نمودارها میده. این قابلیت تازه اضافه شده و در نسخه بتاست!کیبانا لنز ماشین لرنینگ: کارهای ماشین لرنینگ ساده رو می شه انجام داد. مثلا وقتی که می خواید از روی یک سری زمانی آینده رو پیش بینی کنید!داده زنده لاگ: با این می تونید لاگ های جدید رو زنده ببینید و فیلتر کنید. این به جای tail کردن روی لاگ های سرور هست.به علاوه کیبانا یک سری پلاگین هم داره که به صورت اوپن سورس براش دولوپ می شه. مثل نمونه زیر که (درست نخوندم چیه ولی احتمالا) یک چراغ خطر داره که توش وضعیت سیستم رو جالب تر ویژوالایز کنید! البته بیشتر پلاگین ها تخصصی تر و مفید برای شرایط خاصند. من از پلاگین enhanced table استفاده کردم که همون جدول خود کیباناست ولی اجازه وارد کردن فیلدهای محاسبه شده رو می ده. در آخر این که توی کیبانا می تونیم وضعیت خود Elasticsearch رو مانیتور کنیم. ایندکس هاش، کلاسترهاش، منابع مصرفیش، لایسنسش و ... بیشتر تغییرات از طریق همین پنل قابل اعماله و این کار با سیستم رو راحت تر می کنه. برای جمع بندی، عکس زیر به عنوان قابلیت های کیبانا رو در یک قاب نشون می ده.همون طور که مشخصه امکانات این مجموعه زیاده و مرتب بهش اضافه می شه. این امکانات اکثرا رایگانند و به ندرت نیاز به لایسنس بالاتر دارند. وبینارها و فیلم های خیلی زیادی در موردش توی اینترنت هست. پس احتمالا تا مدت ها سرگرم کارکردن باهاش و استفاده از قابلیت های میشید.قدرت زیرساختیاین مجموعه قدرت پردازشی بالایی داره. الستیک سرچ به راحتی کانفیگور می شه تا در مدیریت حافظه و مموری بهتره عمل کنه. مثلا سیاست هایی داره که آبجکت های قدیمی رو با زمان بندی خوبی کم کم کاهش دسترسی بده و نهایتا حذف کنه. به علاوه distributedه. می شه روی چند سرور یا کلاستر همزمان اجراش کرد و با هماهنگی لاگ استش خودش پردازش هارو تقسیم و مدیریت می کنه. علاوه بر این میشه از replica استفاده کرد تا درصورتی که یک سرور سوخت یا فیل شد ریپلیکای داده ها از سرورهای دیگه استفاده بشن. البته این برای وقتیه که یا حفظ داده هاتون اهمیت بالایی داره و یا اویلبل بودن سیستم مهمه.سخن آخراین مقاله تجربه حدود 2 یا 3 ماه استفاده من با استک ELK هست که تا حد ممکن ساده توضیح داده شده. در این ساده سازی ها ممکنه نکاتی از قلم افتاده باشه. ممنون می شم که در این مورد نظرات و انتقادات خودتون رو با من به اشتراک بزارید. :) اگر امکان پذیر باشه در ادامه مطلب شماره دو رو از چالش های فنی تر مثل مدیریت منابع، امنیت داده ها، استفاده توسط تعداد بالا و روباست کردن رو می نویسم. اگه خوشتون اومد با لایک و دادن نظر می تونید مفید بودنش رو به من نشون بدید و من رو توی ادامه نوشتن این بلاگ فنی تشویق کنین.مرسیآرمینلینک پست در لینکدینمطلب بعدی: ریکامندر سیستم یکتانت | الگوریتم هاContact:armin.zirak97@gmail.comlinkedin یکتانت | Yektanet آرمین زیرک | Armin Zirak Sun, 12 Apr 2020 10:27:21 +0430