https://virgool.io/feed/@amirreza.dadfarnia Senior technical team lead - Tapsi fa 2026-06-19 20:19:16 https://files.virgool.io/upload/users/41829/avatar/avatar.png?height=120&width=120 https://virgool.io/@amirreza.dadfarnia https://virgool.io/@amirreza.dadfarnia/%DA%86%D8%B7%D9%88%D8%B1-%D8%A8%D8%A7-%D8%A7%D8%A8%D8%B2%D8%A7%D8%B1-%D9%87%D9%88%D8%B4-%D9%85%D8%B5%D9%86%D9%88%D8%B9%DB%8C-%DB%8C%DA%A9-%DA%A9%D8%A7%D8%B1-%DB%B7-%D8%B3%D8%A7%D8%B9%D8%AA%D9%87-%D8%B1%D9%88-%D8%AF%D8%B1-%DB%B1%DB%B5-%D8%B3%D8%A7%D8%B9%D8%AA-%D8%AA%D8%A8%D8%AF%DB%8C%D9%84-%D8%B4%D8%AF-fuxmdd4sh7ga هفته‌ی پیش بعد از انجام دادن یکی از تسک‌هام به این فکر کردم که اگر این کار رو می‌خواستم ۳ سال پیش با زبان برنامه‌نویسی‌ای که تسلط بسیار بیشتری (از زبان پروژه‌ی الان) داشتم انجام بدم، چقد بدون ابزارهای امروز کار سخت و پیچیده می‌شد. کاری که در گذشته حتماً بیشتر از یک روز طول می‌کشید، الان در کمتر از ۲ ساعت انجام شد. البته این نکته بسیار مهمه که داشتن ترکیب مناسبی از ابزار درست، معماری مناسب، و آماده بودن کد برای استفاده از ابزار AI و آشنایی با نحوه‌ی پرامپت نوشتن تأثیر خیلی زیادی در میزان کمک هوش مصنوعی به یک برنامه‌نویس دارد. حتماً روز اول وصل کردن یک پروژه‌ی بزرگ به یک ابزار AI نباید انتظار چنین خروجی‌ای داشت. شاید این مطلب بیشتر برای کسانی جالب باشد که برنامه‌نویس نیستند و می‌خواهند بدانند ابزارهای هوش مصنوعی چه تأثیری روی روند کاری یک برنامه‌نویس دارد. یک مثال واقعیدیروز یک تسک داشتم که باید قبل از ارسال عکس‌ها به یک پنل، آن‌ها را ریسایز کرده و واترمارک اضافه کنم. برای انجام این کار باید تصمیمات زیر را می‌گرفتم:انتخاب سرویس‌ها و کتابخانه‌های مناسب برای ریسایز و واترمارک.بررسی اینکه آیا لینک عکس‌های جدید باید ذخیره شود یا خیر.انتخاب سریع‌ترین و بهینه‌ترین ابزارها.مدیریت آپلود چندین عکس به‌صورت موازی (async و parallel tasks).چالش مهم برای من این بود که این تسک باید در یک پروژه‌ی کاتلین انجام می‌شد، در حالی که تجربه‌ی من با این زبان خیلی کم بود.پیش‌نیاز‌ها برای خروجی مناسب از هوش مصنوعی، عملاً در صورت نبود هرکدام از این موارد امکان استفاده با سرعت زیاد از AI در یک پروژه‌ی بزرگ از بین می‌رود. ۱- معماری مناسب و قابل فهم برای هوش مصنوعی که بتواند از ساختار کد پیروی کند.۲- وجود ruleهای مناسب نوشته‌شده توسط برنامه‌نویس‌ها (در واقع همون cursor rules)۳- نوشتن پرامپت‌های مناسب با شناخت کامل از ساختار کد و نیازمندی‌های پیاده‌سازی، همچنین شناخت خوب از خروجی‌های AI در شرایط مختلف. (حتماً روز اول استفاده از AI به این نتیجه نمی‌رسید و نیاز به کسب تجربه، شناخت پرامپت‌نویسی و آشنایی با مشکلات احتمالی دارد.)برآورد زمان و نقش AI در این تسک۱. تصمیم‌گیری معماری و انتخاب APIهامیزان استفاده از AI: صفرزمان با AI: ۳۰ دقیقه (با جلسه با یکی از همکاران)زمان بدون AI: تقریباً مشابهتوضیح: به دلیل نیاز به دانش دامین و شناخت کاربران، این بخش را خودم انجام دادم و AI کمکی نمی‌توانست بکند.۲. یافتن ابزار مناسب برای واترمارک و ریسایزمیزان استفاده از AI: ۹۰٪زمان با AI: ۱۰ دقیقهزمان بدون AI: ۱ ساعتتوضیح: با پرسش از AI و بررسی پیشنهادات، سریع‌ترین و مناسب‌ترین ابزارها را پیدا کردم.۳. پیاده‌سازی واترمارک و ریسایزمیزان استفاده از AI: ۹۵٪زمان با AI: ۱۵ دقیقهزمان بدون AI: ۳ تا ۴ ساعتتوضیح: تمام کد با کمک ابزار Cursor نوشته شد و تنها نیاز به ریفکتور جزئی داشت. وجود cursor ruleهایی که در طول زمان بهبود پیدا کرده بودن به شدت به کیفیت کد و رعایت conventionهای موجود در کد کمک می‌کرد. ۴. مدیریت آپلود موازیمیزان استفاده از AI: ۹۵٪زمان با AI: ۲۰ دقیقهزمان بدون AI: ۱ تا ۲ ساعتتوضیح: به کمک AI مفاهیم کوروتین‌ها و scope را سریع‌تر یاد گرفتم و روش درست را تست و استفاده کردم.۵. تست و دیباگ کدمیزان استفاده از AI: صفرزمان با AI: ۱۵ دقیقهزمان بدون AI: ۱ ساعتتوضیح: کدی که AI نوشت، باگ‌های کمتری داشت و تنها تست سناریوها کافی بود.در مجموع با این ابزارها و استفاده‌ی درست ازشون کاری که حتماً در گذشته بیشتر از یک روز طول می‌کشید، در کمتر از دو ساعت انجام شد. امیررضا دادفرنیا امیررضا دادفرنیا Mon, 28 Jul 2025 17:32:17 +0330 https://virgool.io/@amirreza.dadfarnia/%DA%86%D8%B1%D8%A7-%DA%AF%D8%B1%D9%81%D8%AA%D9%86-%D9%86%D8%B8%D8%B1%D8%A7%D8%AA-%D8%AA%DB%8C%D9%85-%D8%AD%D8%AA%DB%8C-%D8%AF%D8%B1-%D8%B4%D8%B1%D8%A7%DB%8C%D8%B7%DB%8C-%DA%A9%D9%87-%D8%A7%D8%B1%D8%B2%D8%B4-%D8%A7%D9%81%D8%B2%D9%88%D8%AF%D9%87-%DB%8C-%D9%81%D9%88%D8%B1%DB%8C-%D8%AD%D8%B3-%D9%86%D9%85%DB%8C-%DA%A9%D9%86%DB%8C%D8%AF-%D8%B6%D8%B1%D9%88%D8%B1%DB%8C-%D8%A7%D8%B3%D8%AA-e80kulyugark در مدیریت تیم‌های بزرگ‌تر، به‌خصوص وقتی تعداد اعضای تیم از ۶ یا ۷ نفر بیشتر می‌شود، یکی از نکات بسیار مهم و ضروری دریافت نظرات و اینپوت از اعضای تیم در موقعیت‌های مختلف است. بسیاری از مدیران به دلیل اینکه فکر می‌کنند نظرات اعضای تیم در برخی مسائل ارزش زیادی ندارد، از این کار صرف‌نظر می‌کنند و تصمیم‌گیری را به خودشان یا تعداد محدودی از افراد محدود می‌کنند. اما گرفتن نظرات از اعضای تیم حتی در مواردی که به نظر می‌رسد تأثیر زیادی نداشته باشد، می‌تواند نتایج مثبتی به همراه داشته باشد. در ادامه به چند مزیت مهم این رویکرد اشاره می‌کنم:رشد و توسعه افراد: در موضوعات پیچیده که اعضای تیم تجربه کمتری دارند، دریافت نظرات می‌تواند به عنوان تمرینی برای تفکر درباره مسائل پیچیده عمل کند. اگر افرادی در تیم شما هستند که در آینده نیاز به تصمیم‌گیری در این زمینه دارند، یا در‌مقیاس کوچکتر با مسائل مشابه روبرو می‌شوند، این بهترین فرصت است تا به آنها کمک کنید با چالش‌های مشابه آشنا شوند و برای مواجهه با این نوع مسائل آمادگی بیشتری پیدا کنند. فکر‌ کردن به موضوع و صحبت با افراد با تجربه حتی در حد ده دقیقه به شدت آمادگی ذهنی خوبی براق مواجهه آینده در افراد ایجاد می‌کند. ایجاد اعتماد به نفس و امنیت در بیان نظرات: با درخواست فعالانه‌ی نظرات از اعضای تیم، نه تنها خودتان را برای دریافت بازخورد آماده می‌کنید، بلکه به تیم هم اطمینان می‌دهید که می‌توانند بدون ترس نظرات خود را بیان کنند. این کار به افزایش اعتماد به نفس اعضای تیم کمک می‌کند و همچنین نشان‌دهنده احترام شما به آنهاست.ایجاد احساس مشارکت و مفید بودن: وقتی از افراد در موضوعات مختلف نظرسنجی می‌کنید، آنها احساس می‌کنند که در تصمیم‌گیری‌ها مشارکت دارند و این حس مفید بودن می‌تواند باعث افزایش رضایت شغلی و انگیزه آنها شود.تقویت حمایت تیم در شرایط سخت: زمانی که نظرات اعضای تیم را در فرایند تصمیم‌گیری جویا می‌شوید و آنها را از روند پیشرفت تصمیمات مطلع می‌کنید، در شرایط دشوار این حمایت و اعتماد متقابل به شما کمک می‌کند. وقتی افراد تیم در فرآیند تصمیم‌گیری مشارکت داشته باشند، در زمان مواجهه با مشکلات، احساس مسئولیت بیشتری می‌کنند و برای بهبود اوضاع تلاش بیشتری خواهند کرد. مثال‌هایی از عدم حمایت تیم در شرایط سخت یا اختلاف نظر در ذهنم دارم که تقریبا همه‌ی آن‌ها از حذف شدن افرادی که انتظار مشارکت در تصمیم یا فرآیند داشتند ناشی شده است.کاهش سوگیری‌ها و بهبود کیفیت تصمیمات: حتی اگر فکر می‌کنید نظرات اعضای تیم تأثیر زیادی بر نتیجه نهایی نخواهد داشت، دریافت نظرات می‌تواند به کاهش سوگیری‌های شخصی شما کمک کند و در نهایت منجر به تصمیمات بهتری شود.آیا لزوماً نظر گرفتن از تیم به معنی اجرای تمام نظرات آنهاست؟ خیر، در بسیاری از موارد ممکن است نتوانید همه نظرات را در تصمیم‌گیری نهایی اعمال کنید. اما مهم این است که اعضای تیم بدانند شما نظراتشان را شنیده‌اید و در بعضی تصمیمات به آنها توجه کرده‌اید. این مسئله به ایجاد اعتماد و تعامل بیشتر در تیم کمک می‌کند.آیا باید همیشه از تمام اعضای تیم نظر بپرسیم؟ نه، لزومی ندارد همه افراد همیشه درگیر تصمیم‌گیری‌ها باشند، اما مهم است که در بازه‌های زمانی مختلف به اعضای مختلف این فرصت را بدهید تا نظراتشان را بیان کنند.بیان‌ یک تجربه‌به عنوان یک مثال ساده از این رویکرد در عمل، یکی از فعالیت‌هایی که در محیط کاری گذشته انجام می‌دادیم، برنامه‌ریزی فنی تیم‌هاست. هر تیم، برنامه‌های فنی خود را در قالبی مشخص آماده می‌کند که شامل بدهی‌های فنی، نیاز به مقیاس‌پذیری و سایر نیازمندی‌های غیرعملکردی می‌شود. سپس این برنامه‌ها در زمان‌بندی تعیین شده اجرا می‌شوند.برای اطمینان از اینکه برنامه‌ها جامع و دقیق هستند و نیازمندی‌های مشترک میان تیم‌ها به خوبی دیده شده‌اند، این برنامه‌ها در جلسه‌ای با حضور لیدهای تیم‌ها مرور می‌شوند. نحوه‌ برگزاری این جلسه و ساختار آن شاید گزینه‌های زیادی نداشته باشد و چندین بار در تپسی تجربه شده باشد، اما تجربه من نشان داد که حتی در چنین شرایطی مشورت با اعضای تیم‌ها قبل از جلسه می‌تواند تأثیر بزرگی داشته باشد.در یکی از این جلسات، پیش از آغاز جلسه، تنها ده دقیقه زمان صرف صحبت با ۲-۳ نفر از اعضای حاضر در جلسه کردم. این کار باعث شد تا تمام جنبه‌های مختلف و نیازمندی‌های تیم‌ها به خوبی پوشش داده شود و جلسه‌ای مؤثرتر و جامع‌تر داشته باشیم. این تجربه نشان می‌دهد که حتی در شرایطی که فکر می‌کنیم همه چیز کاملاً مشخص است، گرفتن نظرات کوتاه و ساده از اعضای تیم می‌تواند به بهبود کلی فرآیند کمک کند. این متن بیشتر از تجربیات شخصی من نوشته شده بود ولی منابعی که به موضوع نگاه مشابهی داشتند رو در ادامه آوردم که اگر‌ به این موضوع علاقه‌مند بودید این منابع مفید خواهد بود: Participative leadership: Better UpEmployee participation in the workplace:The effects of inclusive leadership and teampsychological safetyPsychological safety and the critical role of leadership development: McKinsey امیررضا دادفرنیا امیررضا دادفرنیا Sat, 24 Aug 2024 09:08:57 +0330 https://virgool.io/@amirreza.dadfarnia/tapsi-high-load-hyw9azonhicd توی این مقاله تجربه‌ای را به اشتراک می‌گذاریم که در تپسی در مدت دو ماه برای تعدادِ درخواست درحدود ۱۰ برابر حالت عادی (در برخی از بخش‌ها تا ۱۷ برابر) آمادگی کسب کردیم. در این مقاله در ابتدا تعریف صورت مسئله و چالش‌های آن را مرور می‌کنیم، و بعد از آن به نحوه‌ی انجام لودتست و همچنین گرفتن بازخورد در بخش‌های مختلف آن خواهیم پرداخت. این مقاله به جزئیات فنی نمی‌پردازیم و مسیر حل مسئله را با هم مرور می‌کنیم، در آینده در مقاله‌های دیگر به جزئیات بیشتری خواهیم پرداخت. چرا لود ده‌برابری؟داستان از این قرار بود که در یک برنامه‌ی تلویزیونی از بینندگان خواسته می‌شد که اگر همان‌لحظه اپلیکیشن را باز کنند، کد تخفیف می‌گیرند یا در قرعه‌کشی می‌توانند شرکت کنند یا در نقشه به دنبال کد تخفیف بگردند و مواردی شبیه این. تجربه‌ی سال‌های گذشته این برنامه به ما نشون داد که باید برای تعداد درخواست در ثانیه‌ی (TPS) بیشتر از ۷ برابر در باز شدن اپلیکیشن (نسبت به بیشترین حجم درخواستی که در گذشته براش آماده بودیم) و تعداد ثبت‌نام بیشتر از ۱۵ برابر بیشترین ثبت‌نام آماده می‌شدیم.پیچیدگی‌ها؟۱- عدم اطلاع دقیق از تعداد درخواست: ما با توجه به اعداد برنامه در سال‌های گذشته در مورد نرخ درخواست‌ها تخمین داشتیم ولی تخمین بود و اطلاعی از نرخ دقیق نداشتیم و باید برای بیشترین چیزی که تصورش رو می‌کردیم آماده می‌شدیم، برای همین باید به صورت کاملاً بدبینانه (البته خوش‌بینانه از نظر تعداد کاربر) آماده می‌شدیم.۲- تغییر در رفتار کاربر: رفتار کاربر با اپلیکیشن به طور کامل در بازه‌ی برنامه تغییر پیدا می‌کرد، و برای مثال اگر در یک مایکروسرویس درخواست A در گذشته بیشترین تعداد بود، در این برنامه ممکن بود درخواست B که تعدادش کم بوده بیشتر شود. مثلاً وارد کردن کد تخفیف درخواستی‌ست که در زمان‌های پربار سیستم خیلی تحت تأثیر قرار نمی‌گرفت ولی در این برنامه نیاز بود که عملکرد خیلی خوبی داشته باشد. در نتیجه شناخت کامل محصول، رفتار کاربر و رفتار احتمالی کاربر از مواردی بود که پیش از هرکاری لازم بود انجام شود.۳- افزایش ضربه‌ای تعداد درخواست: نرخ درخواست‌ها به صورت ضربه‌ای افزایش پیدا می‌کرد، و ابزارهای scaling که در کوبرنتیس مورد استفاده‌ی ما بودند، به طور خاص در این مورد پاسخگوی نیازهای ما نبودند و باید برای این موضوع هم فکری می‌کردیم.۴- عدم اطلاع از زمان دقیق برنامه: با توجه به تغییرات در برنامه‌ها، زمان دقیق برنامه و افزایش تعداد درخواست مشخص نبود.۵- تلاش برای کاهش هزینه‌ها: یکی از اهداف ما این بود که با اضافه کردن کمترین سخت‌افزار ممکن و با استفاده‌ از منابع قبلی برای این برنامه آماده بشیم.۶- مدیریت پروژه در بین تیم‌های مختلف: در این پروژه تیم‌های مختلفی درگیر بودند، ۴ تیم بکندی، ۲ تیم از وب و تیم زیرساخت، ایجاد هماهنگی بین این تیم‌ها و بررسی خروجی کامل این کارها در کنار یکدیگر هم از چالش‌های این پروژه بود.مراحل انجام کار۱- شناسایی نیازمندی‌ها، محصولات تحت تأثیر و رفتار کاربران:در ابتدا تیم فنی با همکاری تیم محصول، تمامی مسیرهایی که کاربران در طول برنامه به آن با احتمال (conversion) بیشتری مراجعه می‌کردند را استخراج کردند، بعد از تیم فنی APIها و مایکروسرویس‌هایی که در این فانل شناسایی کردند و بررسی دقیق پرفورمنس این سرویس‌ها به تیم‌های مربوطه واگذار شد.اهمیت این شناخت بسیار بالا است، در دو ماه اجرای برنامه به طور کلی ۳ دقیقه داون‌تایم رو تجربه کردیم، دلیل این داون‌تایم فیچری بود که به صورت دقیقه ۹۰ی ۲۴ ساعت قبل از پخش برنامه بدون هماهنگی کامل در برنامه قرار گرفته بود و باعث لود بسیار بالا در بخش نقشه می‌شد، و عدم آمادگی ما برای این فیچر باعث شد که نتوانیم آمادگی کامل را برای این بخش داشته باشیم. ۲- بررسی فیچرهایی که در زمان برنامه مورد نیاز نیست (degraded mode):با هدف کاهش مصرف منابع، در کنار شناسایی فیچرهای پرکاربرد در بازه‌ی زمانی برنامه، در جهت کاهش هزینه و منابع تصمیم گرفتیم تا بخش‌هایی از سیستم که در طول برنامه نیاز به آن وجود ندارد، یا در تجربه‌ی کاربری در آن زمان تأثیر قابل توجهی ندارد خاموش شود و ریسورس‌های این فیچرها در اختیار سناریوهای مهم قرار بگیرد. برای مثال فیچرهایی برای بالا بردن دقت مچینگ (انتخاب راننده‌ی مناسب برای مسافر) وجود دارد که در زمان برنامه با توجه به این کاربران درخواست سفر نمی‌دهند اهمیت بالایی ندارد، و می‌تواند خاموش شود. این فیچرها و میزان مصرف ریسورس در آن‌ها مشخص و اولویت خاموش کردن فیچرها نیز با کمک تیم محصول مشخص شدند. این کار را با استفاده از feature flagها در بخش‌های مختلف سیستم انجام دادیم. فیچر‌فلگ در تپسی مدت‌هاست برای خاموش و روشن کردن و همچنین اجرای‌ A/B Testها مورد استفاده قرار می‌گیرد و فیچرهای مختلف اپلیکیشن از سمت سرور قابل کنترل هستند. این ابزار همچنین برای کنترل فیچرهایی که در اپلیکیشن تأثیر مستقیم ندارند و در بکند تأثیرگذار هستند، نیز استفاده می‌شوند. ۳- بررسی محصولات تحت تأثیر و بهبود نقاط قابل بهبود شناسایی‌شده:پس از انجام مرحله‌ی ۱، تیم‌های مربوطه با بررسی ابزارهای در دسترس، مانیتورینگ‌ها و ابزار profiling به صورت آفلاین تلاش خود را برای بهبود نقاط قابل شناسایی هر مایکروسرویس انجام دادند. در این بررسی‌ها، بهبود الگوریتم، کاهش تعداد i/o، موازی کردن بخش‌هایی از سرویس‌ها و استفاده‌ی بهتر از دیتابیس (ایندکس‌ مناسب، کوئری‌های بهتر و یا بهبود کشینگ) اقداماتی بود که برای بهبود بخش‌های مختلف انجام شد.۴- پیاده‌سازی زیرساختی لودتست (Load test tool):انجام اقدامات بالا به تنهایی به ما اطمینان کامل برای میزان تحمل لود سیستم را نمی‌داد، لازم بود که در تمامی بخش‌های تپسی از بهبود عدد دقیق پاسخگویی سیستم و تحمل آن را داشته باشیم.یکی از مهم‌ترین مراحل انجام کار انجام لودتست برای شناسایی نقاط شکست سیستم و همچنین شناخت بهتر از ظرفیت کلی سیستم بود.انجام لودتست به روش‌های مختلف قابل انجام بود:لودتست هر مایکروسرویس به صورت تنها در محیط تستبا توجه به تفاوت‌های محیط تست و محیط پروداکشن، از نظر میزان ریسورس، حجم دیتا و همچنین اثر مایکروسرویس‌های در مایکروسرویس مورد تست، این نوع تست نمی‌تواند ما را به عدد دقیق tps یک سرویس و ریسپانس‌تایم آن در محیط پروداکشن برساند.بیشترین کاربرد این نوع تست، مقایسه‌ی وضعیت یک مایکروسرویس قبل و بعد از ایجاد تغییرات است. پس از انجام هر تغییر که انتظار افزایش throughput و یا بهبود ریسپانس‌تایم وجود دارد، انجام لودتست به صورت ایزوله می‌تواند از میزان اثرگذاری آن به ما اطمینان دهد. همچنین انجام پروفایلینگ در زمان لودتست ایزوله یک سرویس به ما امکان پیدا کردن باتل‌نک‌های سیستم را می‌داد.لودتست با سناریوی کامل سیستم در محیط تستاین نوع تست، می‌تواند اثر مایکروسرویس‌های دیگر که در روش قبل قابل دسترسی نبود را برطرف کند. همچنین در صورت این که لودتست با لود کاملاً واقعی انجام می‌شود می‌تواند تخمینی از میزان ریسورس مورد نیاز را به ما بدهد. اما به دلیل این که میزان ریسورس مورد استفاده در محیط پروداکشن بسیار بیشتر از محیط تست است، هزینه‌ی انجام این تست بسیار زیادتر است. با توجه به این که ما در زیرساخت از سرویس‌های ابری خارجی استفاده نمی‌کنیم و اضافه کردن سخت‌افزار یا اضافه کردن سرویس‌های ابری هزینه‌ی مالی و زمانی زیادی ایجاد می‌کرد از این نوع تست صرف‌نظر کردیم.لودتست کامل سیستم در محیط پروداکشن [1]همان‌طور که از عنوان این نوع تست مشخص است، قرار هست که لود غیرواقعی‌ای در پروداکشن ایجاد کنیم. انجام چنین کاری ریسک‌های متفاوتی دارد که باید مورد ارزیابی قرار گیرد.۱- ایجاد دیتای غیرواقعی در دیتابیس‌ها و اثرات جانبی این داده‌ها (مثلاً افزایش تعداد درخواست ممکن است در قیمت‌گذاری تأثیرگذار باشد): با لیبل زدن درخواست‌هایی که از طریق لودتست ایجاد می‌شود و مشخص بودن کاربرهای تستی و حذف آن‌ها از الگوریتم‌ها و دیتابیس پس از انجام تست نگرانی این مورد و مورد بعد را حذف کردیم.۲- تحت تأثیر قرار گرفتن داده‌های تحلیلی (analytical) در بازه‌ی انجام تست۳- امکان خرابی سیستم در زمان تست:در عین این که ریسک خرابی سیستم را در این مورد پذیرفتیم و همچنین افراد ذینفع را در مورد این ریسک آگاه کردیم، با افزایش تدریجی لود در پروداکشن این ریسک را تا جای ممکن کاهش دادیم.۴- برخی سناریوها مانند پرداخت قابل تست نیستند: سناریوهای اصلی که مورد نظر ما بودند با پوشش ۸۰درصدی با این روش قابل تست بودند و اطمینان خوبی به ما می‌دادند.در برنامه‌ریزی اولیه، زمان‌های انجام لودتست کامل در محیط پروداکشن مشخص شد و این کار را ۵ بار قبل از رسیدن به ددلاین نهایی انجام دادیم، در هر تست تعدادی باتل‌نک در سرویس‌های مختلف شناسایی شد و با بهبود آن‌ها به تدریج به نتایج دلخواه رسیدیم، در نهایت توانستیم ۳۰ درصد لود بیشتر از لود تخمینی در برنامه را در لودتست تحمل کنیم و این نتیجه برای ما دلچسب بود.همچنین این لودتست به ما کمک کرد که میزان اسکیل هر سرویس در زمان برنامه‌ را به طور کامل آگاهی داشته باشیم.۵- پیاده‌سازی ابزار اسکیلینگ (auto/manual scaling tool):همان‌طور که در ابتدا گفته شد با توجه به ضربه‌ای بودن افزایش لود (۱۰ برابر شدن لود کلی در کمتر از دو دقیقه)، ابزارهای autoscalingی که استفاده می‌کردیم برای ما سرعت پاسخگویی کافی را نداشتند و امکان چند برابر شدن تعداد instanceهای مایکروسرویس‌های مختلف در دو دقیقه وجود نداشت.با توجه به این که برنامه در ساعت نسبتاً مشخصی پخش می‌شد، با ایجاد یک ابزار دستی، هر روز ۱۰ دقیقه قبل از برنامه اسکیل کلیه‌ی مایکروسرویس‌ها که با توجه به خروجی لودتست مشخص شده بود تعیین می‌شد و پس از برنامه به حالت قبلی برمی‌گشت.۶- آمادگی برای شرایط اضطراری:با وجود تمامی اقدامات بالا، با توجه به ناشناخته بودن حجم درخواست و نوع آن در اجراهای ابتدایی، لازم بود خودمون رو برای شرایط خاص آماده کنیم. در هرکدام از بخش‌های سرویس‌ها، مسئول سرویس راه‌حل‌های اضطراری را از دو نوع آماده‌ی اجرا بودند. حذف فیچرهایی که از نظر تجربه‌ی کاربری مورد نیاز بودند و همچنین دراپ کردن درخواست‌های یک سرویس در شرایطی که تعداد درخواست بسیار بیشتر از پیش‌بینی ما بودند. در اجراهای ابتدایی برنامه و در زمان‌هایی که انتظار تغییر رفتار کاربر رو داشتیم تیم آنکال مسئولیت مشاهده و مانیتور سیستم و رفتن به شرایط اضطرار (با کمک فیچرفلگ‌ها) را داشتند.[۲] در نهایت با انجام فرآیند‌های ذکرشده، به صورت متناوب و بازبینی شرایط باعث شد به جز یک مورد که در بالا ذکر شد، کاملاً شرایط تحت کنترل باشد و بتوانیم تعداد درخواست ۱۰ برابری را با موفقیت و با کیفیت سرویس مورد انتظار انجام دهیم. منابع:[1] https://www.artillery.io/blog/load-testing-in-production https://sre.google/sre-book/testing-reliability/[2] https://sre.google/sre-book/reliable-product-launches/ https://sre.google/sre-book/handling-overload/ امیررضا دادفرنیا امیررضا دادفرنیا Fri, 23 Jun 2023 11:59:29 +0330 https://virgool.io/@amirreza.dadfarnia/%D9%85%D9%87%D9%86%D8%AF%D8%B3%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D8%AF%D8%B1-%DA%AF%D9%88%DA%AF%D9%84-%D9%81%D8%B5%D9%84-%D9%BE%D9%86%D8%AC%D9%85-%DA%86%DA%AF%D9%88%D9%86%D9%87-%DB%8C%DA%A9-%D8%AA%DB%8C%D9%85-%D8%B1%D8%A7-%D8%B1%D8%A7%D9%87%D8%A8%D8%B1%DB%8C-%DA%A9%D9%86%DB%8C%D9%85-hifvvu9cqcil در این مقاله خلاصه‌ای از فصل پنج کتاب «مهندسی نرم‌افزار در گوگل» را مرور می‌کنیم. فصل «چگونه یک تیم را راهبری کنیم»، در مواردی به بخش‌های قبلی ارجاع داده شده، در این خلاصه سعی کردم موارد مهم این کتاب را بیان کنم. این خلاصه در به سه بخش زیر تقسیم می‌شود. ۱- تفاوت‌ها و مسئولیت‌های مدیر تیم و راهبر فنی تیم۲- ضد الگوها (الگوهای نامناسب) در مدیریت تیم۳- الگوهای مثبت در مدیریت تیمهیچ تیمی بدون یک راهبر نمی‌تواند عملکرد خوبی داشته باشد، که تولید نرم‌افزار و مهندسی هم یک کار تیمی هست از این قاعده مستثنی نیست. به طور کلی دو نقش مدیریتی در تیم‌ها نظر گرفته می‌شود، مدیر (Manager) تیم، که رهبری افراد تیم را بر عهده دارد و راهبر فنی (Tech Lead) تیم که مسئولیت فنی تیم را برعهده دارد. هرچند این دو نقش از نظر مهارت‌های برنامه‌ریزی (Planning) شباهت‌های زیادی دارند، اما مهارت‌های مدیریتی متفاوتی نیاز دارند. مدیر مهندسی (Engineering Manager): در خیلی از شرکت‌ها از افرادی که دانش نرم‌افزاری ندارند یا دانش کمی دارند برای عنوان مدیریت انسانی (Human management) تیم استفاده می‌شود، اما در گوگل معمولاً مدیران انسانی تیم‌ها افرادی هستند که در گذشته تجربه‌ی کار نرم‌افزاری داشته‌اند. به طور کلی یک مدیر مهندسی مسئولیت نظارت، مدیریت عملکرد و کارآیی تیم و خوشحالی اعضای تیم (شامل راهبر فنی) را دارد. همیشه نیازهای افراد تیم با نیازهای محصول در یک راستا نیستند، مدیر تیم مسئولیت مدیریت این تضادها را هم برعهده دارد. راهبر فنی تیم (Tech Lead): مسئولیت جنبه‌های فنی تیم مانند تصمیم‌های فنی، معماری، اولویت‌ها، سرعت تیم و مدیریت پروژه‌ها را برعهده دارد. (در تیم‌های بزرگ‌تر مدیر پروژه (Program manager) می‌تواند وجود داشته باشد و در این زمینه به راهبر فنی تیم کمک کند). راهبر فنی تیم با مدیر مهندسی تیم باید با همکاری بالایی با یکدیگر کار کنند. راهبرهای فنی، معمولاً در گذشته به صورت فردی در تیم همکاری می‌کردند و یکی از چالش‌های راهبر فنی انتخاب بین این که خودش کاری را با سرعت بالا انجام دهد یا این کار را به افراد تیم واگذار کند هرچند سرعت انجام آن پایین‌تر باشد. معمولاً انتخاب دوم انتخاب درست‌تری خواهد بود. مدیر و راهبر فنی تیم (Tech Lead Manager):در تیم‌های کوچک معمولاً یک نفر مسئولیت مدیریت انسانی تیم و راهبری فنی تیم را برعهده دارد. در گوگل در تیم‌هایی که به بلوغ رسیده‌اند برای این دو نقش دو فرد متفاوت مشخص می‌شود. این دو نقش نقش‌هایی تخصصی هستند که به طور همزمان انجام دادن آن‌ها چالش‌های زیادی از جمله برقرار تعادل بین کار فردی، واگذاری کار به افراد و مدیریت انسانی تیم خواهد داشت. خیلی از افراد تمایلی به مدیر شدن در یک تیم را ندارند که این دلایل متفاوتی می‌تواند داشته باشد. یکی از چالش‌هایی که برای مدیران تیم‌ها وجود دارد، مشاهده‌ی خروجی کار است. کسی که بیشتر زمان کاری خود را به کد زدن می‌گذرانده وقتی به عنوان یک مدیر فعالیت خود را شروع می‌کند، با وجود این که روز شلوغی داشته، پایان روز خروجی قابل لمسی (مثل کد) برای کار خود نمی‌بیند. محاسبه میزان کار مدیریتی انجام شده خیلی سخت‌تر از محاسبه‌ی تعداد خط کد یا تعداد فیچر پیاده‌سازی شده است. میزان خروجی کار یک مدیر، با سرعت و کیفیت کارهای کل تیم بهتر است سنجیده شود، همچنین این مورد هم باید در نظر گرفته شود که خیلی از کارهای مدیریتی اثری بلندمدت دارد و در کوتاه‌مدت قابل مشاهده نخواهد بود. اصل پیتر: کارمندان در مسیر پیشرفت، تمایل دارند ارتقا پیدا کنند، در مسیر این ارتقا به موقعیتی می‌رسند که در آن کفایت لازم را ندارند. خیلی از افراد به خاطر مشاهده‌ی افراد توانمندی که پس از ارتقا به مدیریت یک تیم کیفیت کار مناسبی نداشته‌اند از مدیر شدن خوددادری می‌کنند. در شرکت گوگل برای جلوگیری از این مشکل، افراد در صورتی که در یک بازه‌ی زمانی مشخصی فراتر از انتظار موقعیت خود فعالیت کنند ارتقا پیدا می‌کنند. به عنوان راهبر یک تیم مهم‌ترین کاری که باید انجام شود، خدمت کردن یا به عبارتی مهیا کردن شرایط مناسب برای تیم است. ایجاد فضای اعتماد و احترام، برداشتن موانع، کمک کردن به اعضای تیم برای رسیدن به اجماع در تصمیم‌گیری‌ها، یا حتی مهمان کردن تیمی که بیشتر از انتظار کار کرده از کارهایی است که از مدیر تیم انتظار می‌رود به موقع انجام دهد. در این مسیر، مدیر تیم برای برداشتن موانع سر راه تیم لازم است کارهای گل را انجام دهد و از انجام این کارها هراسی نداشته باشد. مدیران سنتی، دغدغه‌ی چگونگی انجام کار را داشتند در حالی که مدیران خوب دغدفعه‌ی انجام شدن کارها را دارند و برای این کار به تیم برای انتخاب مسیر انجام آن اعتماد می‌کنند. شکست به عنوان یک انتخابشکست می‌تواند به عنوان یک فرصت برای یادگیری در نظر گرفته شود (در مقابل این که شکست عامل سرزنش افراد باشد). در مواردی که شکست خوردن در یک کار، اثرات جانبی کمی داشته باشد و همچنین شکست خیلی سریع مشخص شود، پذیرفتن ریسک این شکست می‌تواند برای افراد آموزنده باشد. در مواردی که ریسک شکست کم ارزیابی شود (هرچند ارزیابی ریسک کار سختی می‌تواند باشد)، بهتر است این فرصت به افراد تیم داده شود. ضد الگوها در مدیریت تیم:۱- استخدام افراد با کیفیت کم: برخی مدیران، با این تفکر که در صورت استخدام افراد با کیفیت و هوش بالا، ممکن است جایگاه خود را از دست بدهند، افرادی با کفایت پایین‌تری را استخدام می‌کنند. در حالی که افراد باکفایت هم به تیم برای پیشرفت کمک می‌کنند هم فرصت را برای مدیران فراهم می‌کنند که بتوانند کارها را به آن‌ها بسپارند و خودشان پیشرفت کنند. ۲- چشم‌پوشی از افراد کم‌کار (عملکرد ضعیف): ادامه دادن همکاری با افرادی که در تیم عملکرد ضعیفی دارند، هم باعث می‌شود شما فرصت جذب افراد با عملکرد بالا را از دست بدهید هم باعث می‌شود زمان اعضای تیم و شما صرف جبران اشتباهات یا کمک به آن فرد شود. در مواجهه با افراد با عملکرد ضعیف باید همچنان با اعتماد، احترام و تواضع رفتار شود، همیشه در این مواقع لازم است به طور موقت این افراد به صورت ریز مدیریت شوند. باید انتظار از فرد به صورت هدف‌های کاملاً مشخص و واضح در یک بازه‌ی زمانی مشخص (مثلاً دو ماه) تعیین شود. بهتر است این هدف‌ها به صورت کوچک، قابل اندازه‌گیری و مرحله به مرحله مشخص شود و هفته به هفته پیشرفت در این مسیر مشاهده شود. ۳- چشم‌پوشی از مشکلات انسانی۴- دوست بودن با تمام افراد: لازم نیست با همه‌ی افراد تیم دوست نزدیک بود تا بتوان تیم را راهبری کرد، همچنان که مدیر یک فرد بودن باعث از بین رفتن دوستی بین افراد نشود. این که روابط دوستانه از روابط کاری به طور جدا در نظر گرفته شوند اهمیت بالایی دارند. ۵- پایین آوردن حد انتظار در استخدام: در مواردی با توجه به افراد متقاضی کار ممکن است استانداردها را برای جذب افراد پایین بیاورید، برای مثال اگر ۴۰ متقاضی وجود دارد و شما به ۵ نفر نیاز دارید، در نهایت ۵ نفر اول این ۴۰ متقاضی حتی اگر پایین‌تر از استانداردهای شما هستند جذب کنید. هزینه‌ی جذب افراد با کیفیت مناسب، در مقایسه با هزینه‌ای که با جذب افراد پایین‌تر از استاندارد باید بپردازید به مراتب کم‌تر خواهد بود. هزینه‌ی پایین آمدن سرعت و کیفیت تیم، زمانی که برا یک فرد صرف می‌شود، هزینه‌ و استرس لازم برای پایان همکاری برای یک فرد، این موارد قابل چشم‌پوشی نخواهد بود. الگوهای مثبت: ۱- تواضع؛ نگاه بالا به پایین نداشتن: (شاید ترجمه‌ی مناسبی برای Losing the ego نباشه ولی مفهوم یکسانی رو می‌رسونه) این که نگاه بالا به پایین نداشتن و تواضع داشتن با داشتن اعتماد به نفس تناقضی ندارد. خیلی از افراد وقتی به عنوان راهبر یک تیم فعالیت می‌کنند، فکر می‌کنند که باید پاسخ تمامی سؤالات را به درستی بدانند در حالی که این لازم نیست. این رفتار باعث می‌شود این که افراد تیم از راهبر تیم کمتر سؤال بپرسند و نقد سازنده کمتری در تیم صورت گیرد. یکی دیگر از نکات مهم در این بخش، عذرخواهی کردن در صورت بروز اشتباه است. عذرخواهی کردن در صورت بروز اشتباه باعث افزایش اعتماد، احترام و تواضع در تیم می‌شود. ۲- حفظ آرامش و تمرکزتیم در شرایط مختلف (جلسات، اتفاقات و غیره)، به صورت آگاهانه و ناخودآگاه، به رفتار و واکنش‌های مدیر توجه می‌کند، این که مدیر تیم در شرایط مختلف آرامش خود را حفظ کند و با تمرکز به کار ادامه دهد اهمیت بالایی دارد. ۳- حذف موانع: موانع تکنیکال یا سازمانی یا می‌توانند مانع پیشرفت تیم یا پیشرفت پروژه‌ها شوند، موانعی که احتمالاً رفع آن‌ها برای اعضای تیم ممکن نباشد یا کند انجام شود. مدیر تیم باید در رفع این موانع به تیم کند، خیلی از مواقع رجوع به فرد درست برای رفع مانع کاری است که مدیر می‌تواند به راحتی به تیم کمک کند. ۴- معلم بودنخیلی وقت‌ها مدیرها نقش منتور یا معلم بودن خود را فراموش می‌کنند. فرآیند‌ها، تکنولوژی‌ها و مواردی از این دست باید با توضیح کافی و مناسب به اعضای تیم آموزش داده شود. ۵- مشخص کردن اهداف واضح: برای این که تیم در یک مسیر حرکت کند و هر فردی تیم را به یک سمت نکشد، لازم است افراد تیم و خود تیم هدف مشخصی داشته باشد تا زمان از اعضای تیم هدر نرود. ۶- راست‌گو بودن: این به این معنی نیست که شما به تیم خود دروغ می‌گویید، ممکن است زمان‌ها یا صحبت‌هایی باشد که نخواهید به اعضای تیم بگویید بهتر است در این موارد رک و راست برخورد کنید و بگویید به دلایلی بیشتر نمی‌توانم توضیح دهم. این بهتر از دروغ گفتن یا نگفتن حقیقت است. یکی از موارد رک و راست بودن در دادن بازخورد به افراد است، بعضاً افراد برای دادن بازخورد و نقد به اعضای تیم آن‌ را در چندین لایه مخفی کرده و غیرمستقیم حرف را می‌زنند، این باعث می‌شود بازخورد به درستی منتقل نشود. البته بازخورد همچنان باید با احترام داده شود. برای مثال در دادن بازخورد این که کد تمیزی توسط فرد زده نمی‌شود اگر به این صورت بیان شود باعث می‌شود فرد پیام بازخورد را به درستی دریافت نکند.«تو یکی از بهترین اعضای تیم و یکی از باهوش‌ترین مهندسان نرم‌افزاری هستی که می‌شناسم، خوبه این هم در نظر بگیری که کدهایی که می‌زنی پیچیده هستند و خیلی قابل فهمیدن نیستند. امام همچنان تو یکی از بهترین نیروها هستی و در مسیر پیشرفت قرار داری» ۷- نگاه کردن خوشحالی اعضای تیم:بهترین راهبران تیم‌هایی، همیشه روانشناس‌های آماتوری هم به شمار می‌روند چرا که همواره حواسشان به حال تیم و موارد خوشحال‌کننده و ناراحت‌کننده تیم است. یکی از راه‌های بررسی خوشحالی اعضای تیم پرسیدن این سؤال است که «به چه چیزی نیازی داری؟» چند نکته‌ی دیگر هم در این کتاب آورده شده که من سعی می‌کنم به صورت خلاصه به آن‌ها اشاره کنم.- واگذار کردن کارها به اعضای تیم در عین دست به کد بودن و فاصله نگرفتن از کار. - همواره دنبال افرادی که بتوانند جایگزین مدیر باشند باش- محافظت کردن تیم از بی‌نظمی‌های خارج از تیم. - بازخورد مثبت واضح به تیم دادن در مواردی که تیم به خوبی کاری را انجام داده- و مورد آخر، این که در مواردی که یکی از اعضای تیم درخواستی دارد برای مثال می‌خواد از یک کتابخانه یا تکنولوژی جدید استفاده کند، در صورتی که ریسک کمی دارد و امکان بازگشتن سریع به مسیر اصلی در صورت اشتباه بودن تصمیم وجود دارد این فرصت را به اعضای تیم بدهیم. امیررضا دادفرنیا امیررضا دادفرنیا Thu, 21 Jan 2021 19:34:04 +0330