https://virgool.io/feed/@underflow fa 2026-04-15 05:58:46 https://files.virgool.io/upload/users/22785/avatar/MJzl61.jpg?height=120&width=120 https://virgool.io/@underflow https://experience.basalam.com/تجربه-ی-بازسازی-باسلام-پس-از-تعدیل-drcqaa972vpq تیم باسلام ۱۴۰۱[این نوشته در پاییز ۱۴۰۲ در مجله‌ی تجربه‌ی باسلام منتشر شده است.]در اردی‌بهشت ۱۴۰۱ تجربه‌ی پایان همکاری با ۵۸ نفر از اعضای تیم (۲۳.۵٪ از جمعیت شرکت) را متاسفانه داشتیم. باسلام برخلاف برنامه‌ریزی و پیش‌بینی، به رشد هدف‌گذاری شده نرسیده بود، شرایط عمومی اقتصاد در دوره‌ی کرونا سخت شده بود و سرمایه‌گذاران باسلام نیز متاثر از این شرایط در تامین مالی دچار مشکل شدند. این دو مشکل هم‌افزا شدند و گزینه‌ای جز کاهش هزینه برای بقا پیش روی باسلام باقی نماند. این تصمیم دشوار با وجود همه‌ی جنبه‌های منفی‌ای که داشت، «تنها» گزینه‌ی پیش روی باسلام بود. هر چند به ایده‌های مختلفی برای کاهش هزینه فکر کردیم، مثلا کاهش حقوق همه و آمادگی برای پایان همکاری‌های داوطلبانه، ولی در نهایت تعدیل تنها گزینه‌ای بود که برای‌مان ماند.نقطه‌ی غیرقابل پیش‌بینی این اتفاق برای ما این بود که برخلاف تبعاتی که معمولا در پی یک تعدیل دیده می‌شود، واکنش‌های داخلی و بیرونی، ضمن هم‌دلی و احترام، مثبت بود یا دست کم منفی نبود. اتفاق غافل‌گیرکننده‌ای که به حساب کنش‌های هم‌دلانه و رفتار صبورانه و حرفه‌ای دوستانی که از باسلام رفتند باید نوشت.در این نوشته روایتی از تجربه‌ی طراحی و اجرای این تعدیل، نتایج اولیه‌ی آن و باسلامِ پس از تعدیل را می‌خوانید. امیدواریم اشتراک این تجربه بتواند به هر نحو برای تیم‌ها مفید باشد.طراحیانتخاب اعضادو ماه از شروع سال جدید و تقدیم قراردادهای همکاری نگذشته بود. اما همان‌طور که گفتیم، ناچار به این تصمیم شدیم. تا آن روز، در عمر ۶ ساله‌ی باسلام چنین اقدامی انجام نداده بودیم و طبیعتا با جزئیات چنین تصمیمی و نحوه‌ی انجام‌اش آشنا نبودیم. متاسفانه لازم بود از تیم ۲۴۳ نفره‌مان، حدود ۷۰ نفر کاهش داشته باشیم. از معاونت‌های مختلف خواستیم افرادی را از زیرمجموعه‌ی خودشان برای پایان همکاری انتخاب کنند. معاونین این کار را با کمک مدیران‌شان انجام دادند. کار ساده‌ای نبود. باید از بین اعضای تیم‌مان، کسانی که در کمتر از دو ماه قبل تصمیم گرفته بودیم با آن‌ها همکاری کنیم، کسانی را برای بازپس‌گرفتن این تصمیم انتخاب می‌کردیم. کار تلخی بود. بسیاری از مدیران و معاونان خودشان را در لیست تعدیل گذاشتند. طبیعتا مدیرعامل و معاونان نظر بسیاری از این دوستان را تغییر دادند چرا که برای دوران سخت پیش رو به حضور ایشان نیاز داشتیم. در نهایت به لیستی شامل ۵۸ نفر از همکاران و دوستان خوب‌مان رسیدم.تعهدات باسلامدوست داشتیم تا جایی که می‌توانیم برای کاهش بار این تصمیم، نقشی برای دوستانی که می‌روند ایفا کنیم. وظیفه‌ی خودمان دانستیم که حقوق ۲ ماه پس از پایان همکاری را تقدیم کنیم، تا با ایجاد یک ضربه‌گیر، ریسک پیش روی دوستان‌مان را تا قرار گرفتن در شغل بعدی کاهش دهیم. علاوه بر این، تصمیم گرفتیم انرژی زیادی بگذاریم برای معرفی دوستان‌مان به شرکت‌های دیگر. تا شاید به این ترتیب تلخی این تغییر، رقیق شود.شیوه‌ی بیان تصمیمبه این جمع‌بندی رسیدیم که در یک جلسه‌ی حضوری موضوع را به تیم اعلام کنیم؛ در این جلسه مدیرعامل، معاون مالی و معاون آدم‌ها با تیم صحبت کنند و در پایان جلسه، اعضایی که انتخاب شده‌اند، از طریق ایمیلی که از قبل آماده شده مطلع شوند.اجراروز تعدیلآن زمان باسلام دو ساختمان داشت. همه‌ی اعضا را به ساختمان بزرگ‌تر دعوت کردیم. ساختمانی که یک سوله‌ی بزرگ در دانشگاه شهاب دانش بود. فضای جلسه سنگین بود. محمدرضا آقایا، مدیرعامل جلسه را آغاز کرد. شرایط شرکت و تصمیم را با لحنی که گویای عمق ناراحتی‌اش بود شرح داد. او از لحاظ نگرشی شخصا با این تصمیم هم‌دل نبود. درباره‌ی آینده‌ی باسلام و کار سخت‌تر کسانی که می‌مانند صحبت کرد و از تیم باسلام بابت این تصمیم عذرخواهی کرد.بعد از آن احمد عادلی، معاون مالی صحبتی درباره‌ی علت و جزئیات این تصمیم کرد و از زاویه‌ی مالی به شرح موضوع پرداخت.در پایان من هم متاثر از تلخی این تصمیم با تیم عزیز باسلام صحبت کردم و توصیف کردم که این روز سخت‌ترین روزی است که در باسلام تجربه کرده‌ام. روزی که ناچاریم مسیرمان را با گروهی از افرادی که هر کدام‌شان آدم‌های بسیار ارزشمندی هستند جدا کنیم. فرآیند انتخاب افراد و تعهدات باسلام را شرح دادم و جلسه را با اعلام اینکه افرادی پس از جلسه ایمیل پایان همکاری دریافت خواهند کرد، به پایان بردم. پرسش و پاسخ کوتاهی هم شکل گرفت و در حدود ۴۰ دقیقه این گردهم‌آیی تمام شد. هیچ‌گاه تا پیش از آن در باسلام جلسه‌ای به این بزرگی که این‌قدر زود به پایان برسد نداشتیم.ایمیلی از قبل توسط تیم تجربه‌ی آدم‌ها طراحی شده بود که دقایقی بعد از پایان جلسه برای دوستان‌مان ارسال شد. مضمون ایمیل شرح خلاصه‌ای از ناگزیری شرکت از این تصمیم، ابراز تاسف، شرح تعهدات باسلام، شرح تلاشی که برای کاهش تبعات این تصمیم به عهده‌ی خودمان می‌دانستیم و درخواست پذیرش عذر بود. در پایان ایمیل نیز خواسته بودیم دوستانی که مایل‌اند رزمه‌های‌شان را در اختیار شرکت‌های دیگر قرار دهیم، اعلام کنند.آن روز هر طور که بود تمام شد. بعضی از دوستان‌مان به گرمی خداحافظی کردند و رفتند، بعضی از دوستان‌مان با پذیرش تلخی این تغییر ماندند و دوستان رفتنی را بدرقه کردند.تعهداتی که پس از تعدیل دنبال کردیمبخشی از انرژی تیم تجربه‌ی آدم‌ها را در یک ماه پس از تعدیل گذاشتیم روی دنبال کردن معرفی دوستان‌مان -آن‌هایی که داوطلب بودند- به تیم‌ها و شرکت‌های دیگر. به دوستان‌مان برای بازنویسی رزومه‌های‌شان کمک کردیم و رزومه‌های دوستانی که داوطلب بودند را با چنین پیامی در اختیار بیش از ۵۰ شرکت و تیم گذاشتیم:«ما ناگزیر به پایان همکاری با عزیزانی شدیم که هر کدام‌شان برای‌مان نه تنها یک همکارِ متخصص، که دوستان خوب‌مان بودند و هستند. دلیل این قطع همکاری، ضعف دانش و تخصص نبود. چرا که پیش از این، برای ۱۴۰۱ با خبره‌ترین اعضای‌مان تصمیم همکاری را گرفته بودیم. از آنجا که پیگیر رسیدن دوستان‌مان به شغل بعدی‌شان هستیم، ممنون می‌شویم اگر هر کدام از این عزیزان در مجموعه شما مشغول به کار شدند، به ما اطلاع دهید.اردی‌بهشت ۱۴۰۱»از ۴۹ نفر از دوستان‌مان که داوطلب حضور در لیست فوق بودند، در روزهای پس از تعدیل، یکی یکی خبر می‌رسید که در شرکت‌های جدیدی مشغول به کار شده‌اند. تا این که طی ماه اول بیش از ۸۰٪ دوستان ما در مسئولیت جدیدی در جایی مشغول به کار شدند و در ماه دوم این عدد به بالای ۹۰٪ رسید.تعهدی که برای پرداخت دو ماه حقوق داشتیم را نیز طی دو ماه پس از تعدیل انجام دادیم.از ۵۸ نفر از دوستانی که رفتند، ۲۱ نفر از پشتیبانی، ۸ نفر مهندس نرم‌افزار، ۷ نفر مدیر محصول و دستیار محصول، ۵ نفر مهندس داده، ۴ نفر کارشناس بازاریابی، ۳ نفر کارشناس تجربه‌ی آدم‌ها (آنچه که عموما hr گفته می‌شود)، ۲ نفر طراح تجربه کاربری، ۲ نفر طراح گرافیک و ۶ نفر دیگر از بخش‌های حقوقی، مالی، تولید محتوا، محیط و IT بودند.میانه‌ی مدت همکاری با دوستان‌مان ۱۳.۵ ماه بود، کمترین مدت ۲.۵ ماه و بیشترین، ۴ سال.امروز -آبان ۱۴۰۲- ۱۰ نفر از آن دوستان دوباره در باسلام حضور دارند، بعضی از آن‌ها کسب و کار خودشان را ایجاد کرده‌اند و گروهی دیگر در شرکت‌های دیگر مشغول به کار‌ند.واکنش‌های برخلاف انتظارما تصور می‌کردیم شاید از میان این جمع ۵۸ نفره، مثلا یک یا دو نفر این تصمیم را قانونا برنتابند، اما برخلاف تخمین‌مان چنین اتفاقی نیفتاد. علاوه بر این واکنش‌هایی که در شبکه‌های اجتماعی شکل گرفت نیز برخلاف انتظارمان بود. قریب به اتفاق دوستانی که ماندند و رفتند در لینکدین و توییتر از این تصمیم حمایت کردند، برای معرفی افراد به شرکت‌های جدید کمک کردند و این فضای محترمانه و هم‌دلانه برای کسانی که باسلام را نمی‌شناختند تعجب‌برانگیز بود.بعد از این تجربه، بسیاری از دوستان جویا بودند که چرا این تعدیل تبعات رسانه‌ای منفی نداشت؟نمی‌توانیم با قطعیت در مورد سهم علت‌های شکل گرفتن این جریان مثبت حرف بزنیم، اما پررنگ‌ترین علت آن، پذیرش، همراهی و رفتار بزرگ‌منشانه‌ و حرفه‌ای افرادی بود که از باسلام رفتند. از این عامل که بگذریم می‌توانیم درباره‌ی فرهنگ اهمیت به آدم‌ها، به عنوان یک عامل ریشه‌ای صحبت کنیم. نگاهی که از ابتدای باسلام به آدم‌ها وجود داشت، نگاه ابزاری نبود، بلکه همیشه خود آدم‌ها، کیفیت روابط، حمایت‌ها، کار جمعی و پاس گل‌ها -به جای رقابت- مهم بود. علاوه بر این، اساسا ذات باسلام پیرامون اهمیت به آدم‌ها و موضوع شکوفایی شکل گرفته بود و این ذات زیربنای درست شکل گرفتن خیلی چیزهای دیگر بود. تصور می‌کنیم اصل احترام و اهمیت به آدم‌ها، یک علت ریشه‌ای شکل گرفتن این جریان مثبت بود. مجموعه‌ی طراحی و اجرای این تعدیل، دانه‌هایی بودند، در ادامه‌ی دانه‌های دیگری که نخ تسبیح همه‌شان همان اصل احترام بود. این تجربه‌ی متفاوت، نتیجه یک روند ریشه‌دار بود، نه یک طراحی و اجرای چند روزه داد.به بهانه‌ی این توضیحات، دوست دارم یک بار دیگر از همه‌ی دوستانی که آن روز رفتند و همه‌ی دوستانی که در ساختن فرهنگ باسلام نقش مثبت داشته‌اند، صمیمانه قدرشناسی کنم.باسلام پس از تعدیلروزهای بعد از آنهمه چیز را با منطق نمی‌شود پیش برد؛ احساسات و روحیه کار خودشان را می‌کنند. مخصوصا وقتی که بخش عمده‌ای از تیم بسیار جوان باشد. فضای باسلام در روزهای پس از تعدیل، رنگ و بوی ترس، ناراحتی و ناامیدی داشت. فضا با سرعتی که نیاز داشتیم به سمت انسجام و یکپارچگی میل نمی‌کرد. ترس از این که شرایط از این سخت‌تر بشود، ناراحتی بابت رفتن بخشی از تیم و ناامیدی از این که باسلام دوباره ایام رشد سریع را تجربه کند در بخشی از تیم وجود داشت. برای تغییر این جو، قرار شد مدیرعامل ایمیلی به تیم بزند که بخشی از آن را در ادامه می‌خوانید:«… تصمیم تعدیل برای بنده کلنجار باوری زیادی داشت. متفرق کردن تیمی که قصد جنگیدن داشت، با باورهایم سازگاری نداشت. هنوز نمی‌توانم بفهمم که درست‌ترین تصمیم بود یا نه. اما به‌هرحال آن تصمیم را گرفتم و مسئولیتش را به‌عهده گرفتم. پناه به خدایی که پناهی جز او نیست.و اما بعدِ ۱؛دوستانی که ایمیل را دریافت می‌کنید، شما جزو افرادی هستید که دعوتتان کرد‌ه‌ایم بمانید. دلایل این انتخاب را این‌طور می‌شمارم. ۱. به تخصص و شور و اشتیاق شما باور داشتیم. ۲. به کمکِ جنگی‌تان برای موفق‌ کردنِ آرمانِ باسلام نیاز داریم. اما نمی‌خواهم توی رودرواسی با بنده یا دعوت‌کنندگان باشید. دوست دارم شما هم یک‌بارِ دیگر به باسلام و همراهی‌ش در این مسیرِ سخت فکر کنید و دوباره انتخاب‌ش کنید. می‌فهمم که ممکن است ماموریت باسلام را خیلی دوست و باور داشته باشید، اما این حقِ شما است که نخواهید با شرکتی که دچار دست‌اندازهای مالی شده ادامه دهید.یک سناریوی مالی انقباضی برای تامین تا پایان سال و برای رسیدن به نقطه‌ی سربه‌سریِ شرکت طراحی کردیم و روی آن توافقاتی کردیم و به‌‌فضلِ خدا دنبال می‌کنیم تا محقق شود و ان‌شاء الله می‌شود. اما وظیفه دارم بگویم مسیر پیش‌رو دست‌انداز دارد. لذا از شما می‌خواهم اگر این شرایط باسلام را که با شرمندگی بسیار در حالِ بیان آن هستم، می‌پذیرید، به‌هم یک‌بار دیگر دست دهیم و بمانید. و اگر فکر می‌کنید نمی‌توانید با این وضعیتِ باسلام زندگی‌تان را مدیریت کنید لطفا راحت باشید و تا آخرِ امشب روی همین ایمیل به بنده و PX ایمیل بزنید و انصراف‌تان را از این مسیر اعلام کنید.می‌دانم درخواستم نابهنجار است. اما نیاز دارم بدانم با چه‌افرادی این مسیر را به امید خدا ادامه می‌دهیم …»بعد از آن هم دو بار بخش بزرگی از تیم را دور هم جمع کردیم و مدیرعامل با اعضا گفتگو کرد و ایشان را به داشتن یک نگاه متفاوت، تلاش بیش‌تر و امید دعوت کرد. این پیام‌ها و گفتگوها تاثیرگذار بود. بخش خوبی از تیم این پیام را چه در روز تعدیل چه در جلسات بعدی گرفته بودند و با تمام توان در تلاش برای بازسازی باسلام بودند. این‌ها امید داشتند، از یکدیگر حمایت می‌کردند، و در ماه‌های آینده که گاهی حقوق‌ها با تاخیر پرداخت شد به هم قرض می‌دادند.ماه‌های بعد از آناما به هر حال تعدادی از اعضا به هر دلیلی روحیه‌ی ادامه دادن نداشتند. این گروه از دوستان عزیزمان یا تصمیم گرفتند که استعفا بدهند یا در یک ناراحتی ناخودآگاه با انرژی کم در حال ادامه دادن بودند. تلاشی که ما برای هر کدام از این دوستان می‌کردیم، تلاش و دعوت به امید بود، ولی گاهی به این اطمینان می‌رسیدیم که دیگر در این برهه، این دعوت‌ها برای این دوستان کار نمی‌کند و مهم‌تر از تلاش برای ایجاد امید در چند نفر، حفظ روحیه‌ی اکثریت تیم و جلوگیری از نشر رخوت است. به همین خاطر دوستانی که در چنین وضعیت روحی‌ای بودند را به تصمیم به کار کردن در محیطی که حال‌شان خوب باشد دعوت می‌کردیم، هرچند دعوت زیبایی نبود. به همین ترتیب تا اسفند ماه ۱۴۰۱، ۲۴ نفر از اعضا تصمیم گرفتند که بروند و باسلام قدری کوچک‌تر هم شد.در هر صورت عمده‌ی کسانی که ماندن را انتخاب کرده بودند در بازسازی باسلام نقش خوبی ایفا کردند. شرکت هم برای افزایش بهره‌وری، برنامه‌ی observability کارها را طراحی کرد و فرهنگ و بازدهی کار در باسلام نسبت به سال‌های قبل متحول شد.در زمستان همین سال تعدیل، خوشبختانه از نقطه‌ی سربه‌سری عملیاتی (مثبت شدن تراز درآمد خالص ماهانه به هزینه‌های ماهانه) نیز عبور کردیم و شرکت به پایداری مالی رسید. این خبری بود که در QBR4 به تیم اعلام کردیم.تعدیل تاثیر پررنگ و بزرگی روی همه‌ی اعضای تیم، شیوه‌های تصمیم‌گیری، فرهنگ کار و شرایط اقتصادی شرکت گذاشت. به طوری که قبل و بعد از آن را به دو بخش کاملا متفاوت از تاریخ باسلام می‌شود تفکیک کرد.قدرشناسیبعد از گذشتن بیش از ۲۰ ماه از آن روز، باز هم نوشتن این مطلب سخت بود و بارها از ادامه‌ی نوشتن‌اش منصرف شدم. متن را با تشکر از آدم‌ها به پایان می‌برم و امیدوارم این تجربه برای تیم‌ها و شرکت‌ها اتفاق نیفتد.از دوستانی که هم در حضورشان و هم در رفتن‌شان، تیم باسلام را حمایت کردند و کار را برای کسانی که ماندند آسان‌تر کردند تشکر می‌کنیم.از کسانی که نه ما آن‌ها را می‌شناختیم نه آن‌ها ما را، اما در شبکه‌های اجتماعی هم‌دلی کردند، حمایت کردند، نظرات مثبت و امیدبخش فرستادند و دوستانی که open to work کرده بودند را برای معرفی به شرکت‌ها به یکدیگر معرفی کردند، تشکر می‌کنیم.از دوستانی که ماندند و برای بازسازی باسلام تلاش کردند، تشکر می‌کنیم. علی محمدقاسمی علی محمدقاسمی Mon, 02 Sep 2024 16:36:33 +0330 https://experience.basalam.com/چطور-نرم-افزار-باسلام-را-برای-تبلیغات-تلویزیونی-مقیاس-پذیر-کردیم-ryxyixsw2bez باسلام در سال ۱۴۰۱ وارد یک کمپین تبلیغاتی تلویزیونی بلند مدت شد. در این مقاله خواهید خواند که تیم مهندسی باسلام، پیش از آغاز این کمپین چطور زیرساخت و نرم‌افزار این پلتفرم را برای ترافیک تبلیغات تلویزیونی آماده کرد تا به مقیاس پذیری بالا برسد. در این مقاله درباره‌ی ۲ بخش این پازل شامل طراحی و اجرا که طی ۴۵ روز انجام شد، خواهید خواند. اگر مهندس نرم‌افزار یا مدیر مهندسی (Engineering manager) -چه در حوزه نرم‌افزار و چه غیر از آن- هستید، ممکن است خواندن این مقاله -که ۹ دقیقه زمان می‌برد- برای شما جالب باشد.۴۵ روز تا کمپین تلویزیونیقرارداد اجرای کمپین، بعد از چندین ماه فراز و فرود در تصمیم‌گیری و توافق، ۱ آذر ۱۴۰۰ بسته شد و آژانس تبلیغاتی اعلام کرد فاصله‌ی کمی داریم تا روزی که باید روی آنتن باشیم. ما باید ظرف یک و نیم ماه زیرساخت و نرم‌افزار را آماده‌ی این کمپین می‌کردیم؛ یعنی باسلام هم بتواند زیر ترافیک بیشتر تاب بیاورد و پایدار (Stable) بماند، هم سرعت پاسخگویی نرم‌افزار (Response time) افت نکند بلکه بهبود یابد، و هم با توجه به افزایش توجهات، ضریب اطمینان از امنیت نرم‌افزار بالاتر برود.می‌دانستیم که تلویزیون یعنی ترافیک بیشتر، ولی چقدر بیشتر؟ معلوم نبود؛ هیچ تخمین و اطلاعات نسبتا مفیدی قابل دسترسی نبود. نه مشاوران آژانس تبلیغاتی در این مورد می‌توانستند عدد و رقمی بگویند و نه از تجربه‌ی استارتاپ‌های مشابه -مثل ازکی که آن روزها روی آنتن بود- می‌توانستیم به تخمین نسبتا دقیقی برای باسلام برسیم. از یک سو می‌شنیدیم که تبلیغات تلویزیونی traffic peak (ترافیک لحظه‌ای زیاد) ایجاد می‌کند و از سویی می‌شنیدیم که این خبرها هم نخواهد بود. به هر حال بسته به جذابیت تیزرها، حجم و ساعت پخش، میزان ارتباط گرفتن کاربر با محتوا و پارامترهای دیگر، شرایط ما شرایط منحصر به فرد خودمان خواهد بود. در هر صورت تصمیم گرفتیم برای مقیاسی به مراتب بزرگ‌تر خودمان را آماده کنیم. چه تبلیغات آن ترافیک را برای ما ایجاد می‌کرد چه نمی‌کرد، در هر صورت این هدف، نرم‌افزار باسلام را از جهات مختلف بهتر می‌کرد.آمادگی برای ترافیک ۶۰ برابریابتدا به آمادگی برای ترافیک ۱۰۰ برابری فکر کردیم، اما برای جلوگیری از ایجاد اضطراب غیرضروری در تیم، به ۶۰ تقلیل دادیم. ضمن این که می‌توانستیم بعد از رسیدن به مقیاس ۶۰ برابری، در صورت نیاز به ۱۰۰ برابر و بیشتر هم برسیم، با آرامش بیشتر. در آذر ۱۴۰۰ ۱۵۰۰ RPS داشتیم و باید برای ۹۰,۰۰۰ RPS آماده می‌شدیم. شدنی بود؟ برای کل نرم‌افزار باسلام، تقریبا نه، اما برای بخشی از آن، چرا.استراتژی آمادگی برای مقیاس پذیریتقریبا مثل هر نرم‌افزار مشابهی، دیتاسنتر، شبکه، load balancerها، سرورهای فیزیکی، زیرساخت Orchestration، وب‌سرورها، دیتابیس‌ها، Message broker ها، کش‌ها، اپلیکیشن‌ها یا میکروسرویس‌ها و سرویس‌های شخص ثالث، اجزای اصلی نرم‌افزار باسلام هستند. برای مقیاس‌پذیری پایدار، یک استراتژی طراحی کردیم که پنج بخش داشت:تضمین حیات قابلیت‌های حیاتیحذف نقاط حساسپردازش کمترپردازش بهینه‌ترامنیت بیشتربرای این‌که بتوانیم این ۵ کار را به نتیجه برسانیم، نیاز داشتیم خودبسنده باشیم تا تصمیمات سریع بگیریم و حتی یک ساعت را هم از دست ندهیم. خودبسندگی را به عنوان یکی از اصول در نظر گرفته بودیم.و اما شرح پنج بخش این استراتژی:۱. تضمین حیات قابلیت‌های حیاتیخوب حل کردن صدها مساله در یک زمان کوتاه تقریبا نشدنی است، اما خوب حل کردن ده مساله در زمان کوتاه شدنی است. نیاز نبود کل باسلام را مقیاس‌پذیر کنیم. بنابرین به سرعت لیست Feature های حیاتی از ده‌ها قابلیت باسلام را نوشتیم. احتمالا هم کسر کوچکی از نرم‌افزار، کسر بزرگی از ارزش باسلام را تشکیل می‌داد.صفحه اولسیستم احراز هویتموتور جستجوصفحه محصولکل فرآیند خریدچتهم‌زمان از بچه‌های محصول خواستیم که چنین لیستی را به ما بدهند، اما ما کار را طبق لیست خودمان شروع کرده بودیم و زمانی برای از دست دادن نداشتیم. چندین روز بعد که لیست مورد نظر محصول را دریافت کردیم، بسیار منطبق با تشخیص خودمان بود و ما به لطف خودبسندگی، زمانی را در انتظار از دست نداده بودیم. حسن لیست جدید این بود که تمام قابلیت‌های باسلام را به ترتیب اولویت مشخص کرده بود و ما می‌توانستیم در شرایط بار یا load بالا، به ترتیب از انتهای لیست قابلیت‌های باسلام را خاموش کنیم.برای این که بتوانیم کنترل روشن و خاموش کردن قابلیت‌ها را در دست داشته باشیم، نیاز بود سرویس Feature flag را در سراسر محصول بگنجانیم و پایداری خود این سرویس را هم تضمین کنیم.همه‌ی این اولویت‌بندی و تصمیم‌گیری مصداقی است از Graceful degradation در مهندسی نرم‌افزار. وقتی نرم‌افزار زیر فشاری بیش از حد تحمل‌اش قرار می‌گیرد، برازنده است که به طور کلی پایین نیاید و صرفا قابلیت‌هایش تقلیل یابد یا به بخشی از کاربران سرویس دهد. در یکی از جلساتی که با موضوع مقیاس‌پذیری (Scalability) با یکی از مهندسان ارشد گوگل داشتیم، شیوه‌ی Graceful degradation مان را معرفی کردیم، ایشان علاوه بر تایید راهکار، اشاره کرد که در سرویس‌های Ads گوگل، به طور خودکار و با استفاده از مدل‌های هوش مصنوعی این کار -که آنجا به Degraded processing شناخته می‌شود- انجام می‌شود.۲. حذف نقاط حساسدو عامل رایج در Collapse کردن نرم‌افزارها، Bottleneck (گلوگاه)ها و SPoF (Single Point of Failures) ها هستند.گاهی یک Query، یک کد غیر بهینه یا یک راهکار بد (مثلا پردازش غیرضروری) در ترافیک بالا تبدیل به گلوگاه می‌شود و کل سرعت نرم‌افزار را پایین می‌آورد؛ این حالت خوش‌بینانه است. در حالت بدبینانه آن گلوگاه تاب نمی‌آورد، Crash می‌کند و بسته به معماری نرم‌افزار حتی می‌تواند باعث Cascading failure شود و کل نرم‌افزار را پایین بیاورد. پس سعی کردیم تمام گلوگاه‌ها را با تست فشار (Load test) ها شناسایی کنیم و به شیوه‌های مختلف آن‌ها را رفع یا حذف کنیم.در مورد SPoFها هم همین کار را باید می‌کردیم. در میکروسرویس‌های باسلام و زیرساخت نرم‌افزاری هیچ SPoFای نداشتیم. زیرساخت باسلام را ۶۰ Device (سرور، سوییچ، Firewall -که بعدا اضافه شد- و غیره) تشکیل می‌دادند و SPoFای در آن‌ها نبود، اما در سرویس‌های شخص ثالث از جمله سرویس پیامک، اتکا به ۲ سرویسی که داشتیم ریسکی بود. تنها SPoFای که تقریبا نمی‌توانستیم برایش کاری بکنیم خود دیتاسنتر بود. بسنده کردیم به جلساتی که با مدیران دیتاسنتر گذاشتیم و سطح اهمیت برنامه‌ی پیش رو و انتظارات و SLA را هم‌رسانی کردیم.درگاه‌های پرداخت هم با این که متعدد بودند، اما در ساعات مختلف عملکردهای مختلفی در Conversation rate و Tech performance نشان می‌دادند. یکی از کارهایی که در برنامه‌ گذاشتیم این بود که نرم‌افزار به صورت خودکار این‌ها را تشخیص بدهد و سوییچ کند.۳. پردازش کمترمعماری‌های پر پیچ و خم نرم‌افزار معمولا در تیم‌های جوان پیدا می‌شوند و ما هم از این وضعیت مستثنی نبودیم. معماری‌هایی که در ابتدا با هدف نظم‌بخشی به کد و تضمین حفظ سرعت توسعه نرم‌افزار ایجاد می‌شوند، اما به مرور زمان نه تنها این خاصیت را از دست می‌دهند بلکه دقیقا عکس آن هدف عمل می‌کنند. علاوه بر آن، این معماری‌های پر پیچ و خم وقتی روی نرم‌افزارهایی که به شیوه‌ی Interpretation کار می‌کنند اعمال می‌شوند، بحران می‌آفرینند. در آن زمان بخشی از پروداکشن باسلام هنوز مبتنی بر PHP و یک معماری Over-designed بود و دقیقا همین معماری پیچیده گلوگاه بود. پردازش ده‌ها فایل و صدها Function call برای اجرای یک کوئری ساده و پاسخ به کاربر، ضرورتی نداشت. وقتی با ابزار Flame Graph هزینه‌ی اجرای یک درخواست را تماشا می‌کردیم، می‌دیدیم چه ظرفیت بزرگی برای بهبود داریم. بنابرین «پردازش کمتر» یکی از کارهایی بود که باید می‌کردیم.خوشبختانه در میکروسرویس‌های جدید باسلام این Over-engineering را نداشتیم اما به هر حال بخشی از پروداکشن روی معماری‌‌های قدیمی بود. پس تصمیم گرفتیم با تغییراتی، به جای حل مساله، صورت مساله را حذف کنیم. ما در سرویس‌های قدیمی هر جا که می‌توانستیم در سطح Web server از کش استفاده کردیم. یا اگر شدنی نبود در همان اولین خطوط پردازش درخواست (Request) کاربر در نرم‌افزار، او را به Cache حواله کردیم. اینطور به «پردازش کمتر» رسیدیم و CPU از شر پردازش‌های بیهوده در امان می‌ماند.ما برای پردازش کمتر روی منابعی غیر از منابع خودمان هم می‌توانستیم حساب کنیم: CDN. ما آن زمان از «CDN ستون» استفاده می‌کردیم و بار تصاویر را -که IO را بالا می‌برند- به دوش آن گذاشته بودیم. اما علاوه بر تصاویر چیزهای دیگری هم بود که می‌توانستیم با تنظیماتی ساده به CDN بسپریم: صفحات وب. البته لازم بود تغییراتی در ساختار صفحات بدهیم که بخش‌های Dynamic -مثل سبد خرید و قیمت و موجودی- را تفکیک کنیم، و کردیم. باز هم چیزهای بیشتری برای سپردن به CDN وجود داشت: بسیاری از Endpoint های بک‌اند که از نوع Read بودند. استفاده‌کننده‌اش هم Client های اندرویدی بودند و هم برخی صفحات وب. با این تنظیمات اپلیکیشن روی کاغذ می‌توانست تا هزاران برابر بار را تحمل کند و منابعش را فقط به Manipulation (Create, Update) اختصاص بدهد! ولی خب موضوع روی کاغذ بود و در Load test های ما گاهی CDN آن انتظاری که داشتیم را تامین نمی‌کرد.۴. پردازش بهینه‌تراز لحاظ موضوعی خیلی بین پردازش کمتر و پردازش بهینه‌تر تفکیک نمی‌شود قائل شد؛ یک طیف هستند ولی منظورم از پردازش بهینه‌تر این است که پردازش‌های غیرقابل حذف را دست‌کم بهینه‌تر انجام بدهیم. مثلا کوئری‌های دیتابیس. این یک جمله‌ی طلایی است که «همیشه باید بدانیم درون یک سیستم چطور کار می‌کند.» در این صورت می‌توانیم درست از آن استفاده کنیم.به یک مثال از پردازش بهینه‌تر کوئری‌های دیتابیس اشاره می‌کنم. مثل هر کار دیگری که فرصت‌های بهبود را بر اساس بزرگی مرتب می‌کنیم. دیتابیس‌های رابطه‌ای باسلام PostgreSQL هستند و ما از PgHero برای تحلیل بهره‌وری آن‌ها استفاده می‌کردیم. این ابزار ساده، تحلیل به درد بخوری از تعداد تکرار، مدت اجرا و در مجموع CPU Time ای که هر گروه کوئری می‌گیرد، ارائه می‌کند. فرضا شما متوجه می‌شوید کوئری نمایش سبد خرید پرتکرارترین کوئری است و هر بار اجرای آن میانگین ۴۷ms طول می‌کشد و مثلا ۱۰٪ پردازش دیتابیس را به خودش اختصاص داده. پس اگر شما این عدد را به ۱۰ms برسانید توانسته‌اید حدود ۸٪ کل پردازش‌های دیتابیس را کاهش بدید که عدد بسیار بزرگی است. به همین ترتیب با یک کار یک روزه به راحتی ممکن است چند ده درصد از بار دیتابیس کم شود. طبیعتا هر چه جلوتر برویم این بهینه‌سازی‌ها سخت‌تر می‌شود.برای بهینه‌سازی کوئری‌های دیتابیس دم‌دستی‌ترین کار آنالیز کردن کوئری است. با تحلیل مسیری که دیتابیس دارد داده‌ها را فراخوانی می‌کند، معمولا ایده‌های خوبی برای تعریف و استفاده از Index های درست، به دست می‌آید. یک قدم مهم‌تر این است که مطمئن شویم کوئری دارد در هر گام واکشی اطلاعات، تنها اطلاعات ضروری را فرا می‌خواند (چون این اشتباه رایجی است که کوئری‌ها را درگیر fetch کردن رکوردها غیرضروری می‌کنیم). از این بهتر و سخت‌تر هم این است که جداول از ابتدا با یک نگاه همه‌جانبه -که Performance را هم در نظر داشته باشد- طراحی شده باشد یا با یک نگاه همه جانبه بازطراحی شود.در مقیاس بالا دیتابیسی که بدون یک نگاه همه جانبه طراحی شده باشد می‌تواند پرهزینه و گلوگاه نرم‌افزار شود. ORMها پتانسیل ساختن کوئری‌های غیربهینه دارند. Triggerها و Foreign Key ها می‌توانند پردازش‌های غیرضروری ایجاد کنند. Index های بلااستفاده یا غیرضروری یا تکراری می‌توانند حجم و پردازش اضافه بار کنند. دخالت در مدیریت Lock های دیتابیس می‌تواند Dead-lock ایجاد کند. تعریف توابع و استفاده از آن‌ها حساسیت‌هایی دارد. نداشتن استراتژی درست یا دستکاری ناآگاهانه‌ی مدیریت Dead tuple ها در جداولی که تغییرات داده‌های‌شان بسیار پربسامد است Bloat می‌سازد و نگهداری را سخت می‌کند. این‌ها چند نمونه از مراقبت‌های کلی‌ای است که معمولا این نوع دیتابیس‌ها نیاز دارند و ما خوشبختانه بدهی زیادی در اینجا نداشتیم، چرا که در طول زمان معمولا این نکات را مورد توجه قرار می‌دادیم. اما به هر حال فرصت‌های بهبودی بود و انجام دادیم.در یکی از مشورت‌هایی که می‌گرفتیم ایده‌ی User-based partitioning دیتابیس برای‌مان جالب بود. موضوع این است که دیتابیس‌ها در هر صورت حجیم می‌شوند و علاوه بر Partitioning هایی که معمولا دیتابیس‌ها ارائه می‌دهند، یک Partitioning کاربر محور در سطح اپلیکیشن می‌تواند ایده‌ی درخشان و بسیار مفیدی باشد. البته که این ایده پیچیدگی‌های زیادی داشت و گذاشتیم برای آینده.۵. امنیت بیشترما ریسک‌های امنیتی شناخته شده‌ای با اهمیت پایین داشتیم که آن‌ها را برای حل شدن لیست کرده بودیم. رفع این‌ها را اولویت دادیم. علاوه بر این با دو شرکت امنیتی برای آزمون نفوذ جعبه سیاه روی زیرساخت، Back-end و Client های باسلام قرارداد بستیم. ابزارهایی برای تست‌های اتومیشن هم داشتیم که به صورت توزیع شده هر تیمی مسئولیت استفاده از خروجی‌های آن‌ها و رفع مشکلات را داشت.یکی از کارهای مربوط به امنیت، Bypass کردن Firewall دیتاسنتر و استفاده از راهکار سخت‌افزاری و نرم‌افزاری خودمان بود.از قضا در همین روزهای آماده شدن برای تلویزیون، تجربه‌ی یک حمله‌ی امنیتی کوچک داشتیم. دو اشتباه دست به دست هم داد و این آسیب‌پذیری رقم خورد: یک اشتباه در بازنویسی یکی از میکروسرویس‌ها و از کار افتادن Throttling Policy، و یک اشتباه بسیار قدیمی در Password Policy و وجود مجموعه‌ای از پسوردهای ساده برای گروهی از غرفه‌داران. هکر کلاه سیاه با استفاده از این شرایط، اسکریپتی را اجرا کرد و از طریق چت باسلام، پیام‌هایی برای غرفه‌داران و مشتریان فرستاد. تجربه‌ی این حمله‌ی کوچک، بسیار ارزشمند بود و منجر به ارتقای ذهنیت تیم از اهمیت همه‌ی روتین‌های امنیتی و تقویت این روال‌ها شد.چطور این کارها را انجام دادیم؟۳ ویژگی می‌توانست شانس موفقیت این برنامه را کم کند.تعدد پروداکت‌ها (ده‌ها میکروسرویس)زمان کمتعدد تیم‌ها و طول و عرض ساختار سازمانی (نزدیک به ده تیم پروداکتی که هر تیم یک EM داشت، در ۳ دامین مختلف که هر دامین یک EMD داشت و آن‌ها به VP گزارش می‌دادند.)مشکل اول را که با کوچک کردن مساله حل کردیم. اما مشکل زمان و ساختار پابرجا بود؛ اگر می‌خواستیم این برنامه را به شکلی که همیشه -در شرایط عادی- تفویض مسئولیت می‌شود به تیم‌ها بسپاریم، زمان زیادی برای شکل گرفتن هم‌ذهنی سپری می‌شد. بنابرین به یک طراحی متفاوت نیاز داشتیم.برای هم‌ذهنی سریع، جلسه‌ای با همه‌ی EMDها و EMها گذاشتیم، شرایط جدید را بیان کردیم، محدودیت زمان و اهمیت هر ساعت را گفتیم، روی اصل خودبسندگی تاکید کردیم و به طبع توقف برنامه‌های قبلی که با برنامه‌ی جدید همپوشان نیستند را اعلام کردیم (مگر این که افراد امکانی برای مشارکت در برنامه‌ی جدید نداشته باشند. برای مثال کسی که مشغول توسعه‌ی مدل‌های هوش مصنوعی است، ممکن است نقش خاصی نتواند برای این برنامه ایفا کند). بعد از این هم‌ذهنی، استراتژی کلی برای آمادگی را شرح دادیم و در یک دیالوگ جمعی، شروع به طراحی جزئیات استراتژی و جزئیات اجرایی کردیم.یکی از مهم‌ترین بخش‌های شیوه‌ی اجرای این کار این بود که جلسات Daily تنظیم کردیم و هر روز خیلی کوتاه همه‌ی EMD ها دور هم جمع می‌شدند و گزارش پیشرفت کارها را می‌دادند، اگر مشکلی بود با هم حل می‌کردند و اگر به ایده و مشورتی نیاز داشتند، اشتراک تجربه می‌کردند. برای مثال در همین جلسات راهکار Load Test سرویس‌ها از طریق پروداکت چندمنظوره‌ی KDP باسلام (که بعدها درباره‌ی آن خواهید شنید) بین افراد به اشتراک گذاشته شد و روی تجربه‌های Scale کردن یک میکروسرویس نکات ریز و درشت زیادی رد و بدل شد که به تسریع این برنامه کمک بسیار خوبی می‌کرد. بعدها که هم‌ذهنی تیم بیشتر شد، این جلسات به یک روز در میان و کمتر کاهش پیدا کرد.به این صورت کل این کار به صورت توزیع شده با موفقیت در شرکت اجرا شد.نتایجتیم مهندسی باسلام با استراتژی ۵ بخشی‌ای که داشت و با تکرار Load Test ها در نهایت به این نتایج رسید:ظرفیت تحمل بار ۲۰ تا ۱۰۰ برابری -و بیشتر- در میکروسرویس‌های مختلفبهبود ۲.۶ برابری شاخص LCP (از ۷.۶ ثانیه به ۲ ثانیه)رفع SPoFهاتوان حفظ پایداری نرم‌افزار در ترافیک بالا با مدیریت Degradationارتقای امنیت باسلامتبلیغات تلویزیونی باسلام بدون کوچک‌ترین مشکلی در پایداری نرم‌افزار اجرا شد. بعد از این کمپین تلویزیونی، میانگین ترافیک باسلام بیش از ده برابر شد؛ کمتر از چیزی بود که فکر می‌کردیم ولی تلاش برای این آمادگی، نگرش تیم مهندسی و حتی محصول را ارتقا داد؛ «نگرش و فرهنگ کیفیت‌گرایی مفید، اما نه چندان گران قیمت در نرم‌افزار». ارتقای کیفیت نرم‌افزار به طور ضمنی روی SEO باسلام نیز تاثیرات درخشانی گذاشت.سپاس از دوستانی که نقش داشتندعلاوه بر همه‌ی مهندسان باسلام که با هم‌آهنگی در اجرای مجموعه‌ی این صدها تغییر، نقش‌آفرین بودند، از تجربه‌ی چند مشاور عزیز هم استفاده کردیم و نکات ارزشمندی یاد گرفتیم که به این بهانه، بدون ترتیب خاصی از این دوستان بابت اشتراک دانش‌شان بسیار تشکر می‌کنیم؛ سید جمال پیشوایی مدیر فنی شرکت اعوان، کیانوش مختاریان مهندس ارشد Google Ads، مجید گلشادی مدیر مهندسی Delivery Hero، طه جهانگیر مدیر فنی شرکت سبز سیستم، سید مهران خلدی مدیر فنی شرکت همروش.۲ شهریور ۱۴۰۲ علی محمدقاسمی علی محمدقاسمی Sun, 09 Jun 2024 14:32:01 +0330