یک داستان موفق!

این نوشتار ترجمه‌ای است از مقاله‌ای با عنوان "ساختن اپلیکیشن تردز" به قلم Gergely Orosz که سپتامبر امسال و مدتی بعد از لانچ تردز منتشر شده‌است.

اپلیکیشن تردز (از شرکت متا مالک فیسبوک) در هفته‌ای که در دسترس عموم قرار گرفت بیش از یکصد میلیون بار نصب شد و تقریبا به همان تعداد کاربر پیدا کرد. چگونه تیم مهندسان این اپلیکیشن را ساختند و این استقبال دور از انتظار را مدیریت کردند؟ به شیوه‌ای منحصر به فرد!

در ژوئیه 2023، شرکت متا جدیدترین اپلیکیشن موبایل خود، با نام Threads را راه اندازی کرد که یک سرویس میکروبلاگینگ و رقیب جدیدی برای X (یا همان توییتر سابق) بود. در پنج روز اول پس از راه اندازی، این برنامه به 100 میلیون دانلود دست یافت که یک رکورد جدید برای شرکت با اختلاف بسیار زیاد است. رکورد قبلی متا برای نصب اپلیکیشن‌های جدید در پنج روز اول پس از انتشار عمومی، یک میلیون نصب بود. شکل بالا منحنی رشد تعداد کاربران تردز را نشان می‌دهد.

این ارقام و اعداد رکورد قابل ملاحظه‌ای برای یک اپلیکیشن جدید هستند، حتی با در نظر گرفتن اینکه به بیش از 2 میلیارد کاربر فعال ماهانه اینستاگرام پروموشنی برای نصب ساده آن داده شده باشد. وقتی از این آمار مطلع شدم، اولین فکرم این بود که چگونه تیم مهندسی این انتشار را انجام دادند، ظاهراً بدون هیچ مساله بزرگی در هنگام انتشار. به‌ویژه وقتی در نظر می‌گیریم که تیم Threads از راه‌اندازی هم بالاتر رفت، خصوصا پس از آنکه توییتر کاربران رایگان را به تماشای 600 پست در روز محدود کرد؛ و این تصمیم یک فرصت عالی را برای یک رقیب بالقوه برای توییتر ایجاد کرد. کل ماجرا در عرض چند روز پس از محدود کردن نرخ مشاهده پست ها در توییتر به وقوع پیوست و به نظر می‌رسد که تردز از موقعیت پیش آمده به خوبی استفاده کرده است.

اما از درون قضیه کار برای مهندسان سازنده اپلیکیشن چگونه پیش رفت؟ برای یافتن پاسخ این پرسش، با افرادی از تیم مهندسی Threads (که برای به اشتراک گذاشتن جزئیات پشت صحنه مشتاق و مجاز بودند) تماس گرفتم. جسی چن (Engineering Manager) و زاهان ملکانی (Server Engineer Lead) داستان چگونگی ساخت Threads را برای من تعریف کردند. جزئیاتی که آنها به اشتراک گذاشتند به خوبی با مجموعه چالش‌های مهندسان در دنیای واقعی مطابقت دارد.

این لیستی از مطالبی هست که در این نوشتار راجع به آنها صحبت خواهم کرد:

1. نحوه ساخت اپلیکیشن تردز

2. گزینه‌های تکنولوژی و روش‌های مهندسی

3. برنامه‌ریزی برای لانچ

4. دروس آموخته و گام‌های بعدی

در این مقاله سئوالات من (Gergely Oorsz) با فونت مورب آمده و پاسخ های تیم مهندسی Threads با فونت معمولی هستند. به این ترتیب، در واقع جسی و زاهان هستند که درباره نحوه ساخت اپلیکیشن صحبت می‌کنند.

نحوه ساخت تردز

پرسش: تردز به عنوان یک پروژه نرم‌افزاری چقدر «معمولی» بود؟ در مقایسه با سایر اپلیکیشن‌های راه‌اندازی شده؟

تردز با اکثر لانچ‌ها متفاوت بود. معمولاً وقتی یک اولویت جدید و هیجان‌انگیز از بالا به پایین در سازمان ما وجود دارد، ما به فرهنگ باز داخل تیم خود اتکا می‌کنیم تا افراد شرکت را حول ابتکار عمل جمع کنیم و تیم را برای پیوستن و راه‌اندازی خودانگیخته هیجان‌زده کنیم.

اما در این مورد، تیم را عمدا کوچک و محرمانه نگه داشتیم. ما برای کار روی این موضوع از قوی‌ترین مهندسان، مدیران محصول و طراحان خود در اینستاگرام استفاده کردیم و با آدام موسری، مدیر ارشد اینستاگرام، مرورهای منظمی داشتیم. ما می دانستیم که time to market در این مورد اولویت اصلی است، و می خواستیم تیم را از سر و صدا و حواس‌پرتی محافظت کنیم.

تیم انتشار

پرسش: تیم اولیه چقدر بزرگ بود و چه بخشی از آن را مهندسان و افراد فنی تشکیل دادند؟

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

ما بر این باور بودیم که یک سازماندهی کم تعداد و Flat می‌تواند به ما کمک کند تا محصولات با کیفیت بالاتر را سریع‌تر بسازیم، و درستی این فرضیه هم در پایان به اثبات رسید. ما با یک تیم بسیار کوچک (در مجموع حدود دوازده نفر) شروع کردیم و اکثریت قریب به اتفاق اعضای تیم از اینستاگرام آمدند. هر فردی که به ساختمان Threads برای راه‌اندازی پیوست از یک انتقال داخلی به آنجا آمد و آنها پیش از پروژه کارکنان متا بودند.

پیک کاری این تیم یک هفته قبل از انتشار تردز بود و در این زمان تیم از این افراد تشکیل می‌شد:

1. سه نفر مدیر محصول

2. سه نفر دیزاینر

3. حدود 60 نفر مهندس و فنی

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

نحوه برنامه‌ریزی و کار با بقیه تیم‌های متا

پرسش: برنامه‌ریزی کردن به جای مستقیما رفتن به دنبال نمونه‌سازی/کدنویسی چقدر رسمی یا غیررسمی بود؟

در ابتدا پلنینگ‌های سطح بالایی وجود داشت، زیرا ما در مورد میزان استفاده مجدد از کدهای اینستاگرام بحث می‌کردیم. با این حال، در بیشتر موارد، ما مستقیماً به سراغ نمونه‌سازی و کدنویسی رفتیم.

ما در این پروژه یکی از اصول اولیه متا را یادآوری کردیم، "کد همیشه بهتر از جر و بحث است". ما به شدت با این اصل هماهنگ بودیم. حتی قبل از اینکه برای شروع کار چراغ سبز رسمی را دریافت کنیم، مهندسان از قبل ایده آوردن یک فید متنی را برای فاز امکان‌سنجی نمونه‌سازی کرده بودند!

پرسش: چقدر با سایر تیم‌های داخلی متا - مانند تیم‌های زیرساخت، پلتفرم یا محصول، کار و به آنها اعتماد کردید؟

یکی از همکاری‌های منحصربه‌فرد ما یک برنامه «Bug Bounty» بود که در آن از محققان امنیتی دعوت کردیم تا قبل از لانچ اپلیکیشن را برای وجود اشکالات احتمالی بررسی کنند. هدف این برنامه کمک به محافظت از داده‌های افراد و کشف هر گونه اشکال امنیتی یا حریم خصوصی بود که ممکن است در اوایل کار داشته باشیم. به لطف این برنامه چندین باگ قابل توجه را قبل از لانچ پیدا کردیم.

ما در واقع مخفیانه کار می‌کردیم. قبل از انتشار، تیم مهندسان اصلی از بقیه سازمان فنی اینستاگرام جدا شد. ما به شیوه‌ای محتاطانه کدهای خود را به کدبیس مشترک اضافه می‌کردیم و تنها زمانی که با مشکلاتی مواجه شدیم که به تخصص آنها نیاز داشت، با تیم‌های مربوطه برای رفع مسائل وارد تعامل شدیم. با این حال، ما نمی‌توانستیم این اپلیکیشن را در تمام مدت زمانی که برای آماده شدنش طول کشید، با کار به صورت منزوی نهایی کنیم. با اینکه ما قویا به ابزارها و چارچوب‌های داخلی خود متکی بودیم اما در چندین مورد مانند فریم‌ورک‌های واسط کاربری؛ سرویس‌ها، احراز هویت، امنیت، محرمانگی، زیرساخت سرورها و یکپارچه‌سازی از سایر تیم های متا کمک گرفتیم.

ما تا جایی که می‌توانستیم از کدهای خود استفاده مجدد کردیم تا در سریع‌ترین زمان ممکن حرکت کنیم. سرعت توسعه و پایداری سریع ما در حین انتشار اولین نسخه، گواه این است که سازمان مهندسی ما چقدر عالی عمل کرده‌است. تیم‌های پلتفرم/زیرساخت ما وقتی به سرعت Scale می‌کنیم و محصولات جدید می‌سازیم و روی شانه‌های آنها می‌ایستیم، کار را آسان می‌کنند.

تایم لاین پروژه

ما اولین خط کد را برای این اپلیکیشن به صورت مستقل در اواخر ژانویه 2023 نوشتیم و اولین نسخه قابل ریلیز را در ژوئن 2023 به اپ استور ارسال کردیم. مهندسی و ساخت این اپلیکیشن از آغاز تا اولین لانچ 5 ماه طول کشید.

انتخاب‌های فناوری و رویکردهای مهندسی

پرسش: کدام فناوری‌ها را برای بک اند و اپلیکیشن‌های موبایل انتخاب کردید؟

بک اند در استک اینستاگرام (Django همراه با REST API های سفارشی شده) اجرا می‌شود. ما همچنین بک اند مونولتیک بزرگ متا را روی GraphQL (یک ماشین مجازی HHVM برای اجرای برنامه‌های نوشته شده در Hack و PHP) فراخوانی کردیم.

اپلیکیشن‌ها عمدتاً Native هستند و از ترکیبی از Swift در iOS (و کمی Objective C) و Jetpack Compose در Android (با زبان های Kotlin و Java) استفاده می کنند. تعدادی صفحات نمایشی رندر شده برای برخی از تجربیات ساده وجود دارد، اما کد زدن Native جزو طبیعت سیستم است.

استفاده مجدد از استک داخلی

پرسش: برای استفاده مجدد از کدهای موجود در استک مانند کتابخانه‌های برنامه‌نویسی و فریم‌ورک‌ها در مقایسه با ساختن همه قسمت‌ها با کدهای خودتان، چه انتخاب‌هایی انجام دادید؟

از آنجایی که Time to Market برای ما در اولویت بود، تا جایی که امکان داشت از استک فنی اینستاگرام استفاده کردیم. اینستاگرام خود بر اساس کتابخانه ها و فریم‌ورک‌های مختلفی ساخته شده که بسیاری از آنها داخلی و ساخت تیم‌های اینستاگرام هستند.

ما از فرصت ایجاد شده برای آزمودن فناوری‌هایی در هنگام Scaleکردن استفاده کردیم که قبلاً فرصت آن را نداشتیم. در iOS، تمام بخش‌های جدید برنامه با سوئیفت ساخته شدند و در اندروید تا حد زیادی از Jetpack Compose استفاده کردیم. ما به توسعه زبان جدید (Swift) و گزینه‌های فریم‌ورک Jetpack Compose کمک می‌کنیم تا به همان سرعتی که انجام دادیم در ادامه کار هم حرکت کنیم.

ما تصمیم گرفتیم قویا از استک فناوری‌های موجود در اینستاگرام استفاده کنیم، که بر اساس زیرساخت متا ساخته شده اند. این کار که کمک زیادی به سرعت برنامه‌نویسی ما کرد و یک مشکل اساسی نهفته در این پرسش را حل کرد: چگونه یک شبکه اجتماعی جدید مبتنی بر متن از ابتدا ایجاد کنیم؟ یا این پرسش بسیار متمرکز تر به موضوع: چگونه از بلوک های سازنده فید اینستاگرام برای پست‌هایی که بیشتر مبتنی بر متن هستند استفاده کنیم؟

پرسش: تردز خیلی ضربتی انتشار خودش را انجام داد. چقدر پرفورمنس سمت مشتریان را در اولویت قرار دادید، و اگر این کار را انجام دادید، چگونه آن را اندازه‌گیری یا تست کردید؟

عملیات لانچ به اندازه کافی سریع نبود! ما یک سری ابزارهای داخلی داریم که زمان مصرف شده در جاهای مختلف را رکورد می‌کنند و نمایش می‌دهند و مجبور شدیم در هنگام لانچ به شکل گسترده‌ای از آن‌ها استفاده کنیم. زمانی که محبوب‌ترین پست‌ها به‌طور جداگانه شروع به ایجاد انگیجمنت در کاربران کردند، ما اصلا انتظار نداشتیم که دستیابی به کل شبکه در روز لانچ شدنی باشد.

ما فریم‌ورک‌های داخلی داریم که به ما امکان می‌دهند انواع متریک‌هایی عملکردی حیاتی را اندازه گیری کنیم. در اینجا چند نمونه آورده شده است:

• "زمان لازم برای شروع محتوای جدید" برای دیدن محتوا در فید
• عملکرد اسکرول از طریق مشاهده پایین آمدن در فریم

رویکرد تست برای تردز

پرسش: چگونه مرحله تست را انجام دادید (یا انجام ندادید) و به طور خاص در مورد تست‌های اتوماتیک چه کردید؟ در اینجا دو مکتب فکری وجود دارد:

• محصول را بسازید و بازخورد سریع دریافت کنید و ملاحظاتی برای تست‌های خودکار در صورت وجود تناسب محصول با بازار (PMF) داشته باشید.
• محصول را از ابتدا با فرض یک PMF بسازید و تست‌هایی را برای نگهداری و نظایر آن در نظر بگیرید.

ما دیدگاه اول را جلو رفتیم و در آن ملاحظاتی برای تست‌های اتوماتیک بعد از PMF برای تست قسمت‌های frontend/UI داشتیم. به دلیل اهمیت Time to Market، ما در مورد کنار گذاشتن چیزهایی که به ما در رسیدن به آن هدف کمک نمی‌کردند، با دیسیپلین و و به طور سیستماتیک عمل کردیم.

برای اطمینان از عملکرد سیستم، تست‌های اتوماتیک قطعا مهم هستند. با این حال، نوشتن تست برای رابط کاربری که دائما در حال تغییر است، ارزشی ندارد. در این کانتکست، برخی از فلوها قبل از اینکه به چیزی که دوست داشتیم برسیم، بیش از 3 طراحی مجدد داشتند!

تست‌های اتوماتیک به محصولی که PMF نکرده کمکی نمی‌کنند. به جای آن، ما به طور گسترده به DogFooding (روشی که در آن افراد فنی به طور مداوم از محصول خود استفاده می‌کنند تا ببینند چقدر خوب کار می‌کند و در کجا می‌توان بهینه‌سازی انجام داد) و QA متکی بودیم. Dogfooder ها نسخه‌های بیلد شده روی برنچ کاری master (که هر چند ساعت یک‌بار با آخرین تغییرات به‌روزرسانی می‌شوند) را دانلود و استفاده می‌کردند. حلقه بازخورد سریع به ما این امکان را می‌دهد که ظرف چند ساعت از ماک‌آپ‌های figma به یک بیلد اصلی روی تلفن شما برویم.

با این حال، لاجیک کسب‌وکاری بک اند از روش TDD پیروی می‌کرد که از طریق بررسی توسط افراد pair تشویق شد. ما فریم‌ورک‌های تست داخلی عالی داریم که به شما امکان می‌دهد وضعیت مورد تست و منطق کسب‌وکار واقعی را به راحتی، بدون دست زدن به پایگاه‌های داده عملیاتی تنظیم کنید. این به تیم پشتیبان امکان داد سریع‌تر حرکت کند، زیرا می‌توانستیم با اطمینان تغییرات را ایجاد کنیم، بدون اینکه نیازی به تست سرتاسری (End-to-End) به ازای هر تغییر تازه باشد.

برنامه ریزی برای انتشار

پرسش: بزرگترین چالش‌های لودینگ که برای Threads پیش بینی می‌کردید کدام موارد بودند؟

ویژگی خاصی که می‌دانستیم قرار است چالش‌هایی در Scale ایجاد کند، این بود که به کاربران این امکان را می‌داد تا به گراف خودشان از اینستاگرام متصل و وارد بشوند.

یکی از بخش‌های دشوار راه‌اندازی یک شبکه اجتماعی جدید، «Cold Start» است که کاربران با آن مواجه هستند. هر یک از کاربران جدید شما نیاز دارند افرادی را که به آنها علاقه‌مند هستند را در پلتفرم پیدا کند و انتخاب کند که آنها را دنبال نمایند و یا دوست بشوند. در مورد ما، ما می‌خواستیم با ارائه یک حرکت یک ضربتی برای «فالو کردن همه افرادی که قبلاً در اینستاگرام دنبال می‌کنید» این کار را برای ایشان آسان‌تر کنیم.

با این حال، یک مشکل Scaling عمده در اینجا وجود دارد! به حساب‌های پرطرفدارتری فکر کنید که به Threads ملحق می‌شوند و به این ترتیب میلیون‌ها مخاطب از قبل برای دنبال کردن آنها در صف ایستاده‌اند. ما نیاز داشتیم که چنین حساب‌های کاربری بزرگی را در زمان مناسبی پردازش کنیم. پس از راه اندازی، متوجه شدیم که مقیاسی که با آن سروکار داریم بسیار فراتر از انتظارات ما است. از زمان راه‌اندازی به بعد، ما باید این سیستم را با مجموعه‌ای از فرضیات کاملاً متفاوت طراحی کنیم.

انجام Dogfooding (به عنوان بخشی از تست آلفا)

پرسش: درThreads برای چه مدت Dogfooding انجام شد، و تقریباً توسط چند نفر؟ تیم چگونه به جمع آوری بازخورد و رسیدگی به آنها پرداخت؟

این برنامه از ابتدا در آزمایش مداوم بود، اما ما عمداً گروه بازخورد را کوچک نگه داشتیم. هدف ما دریافت سیگنال‌های قوی بازخورد بدون ایجاد حواس‌پرتی برای تیم با گزارشات باگ‌ها بود. ما به آرامی Dogfooding را از تیم اصلی به تمام اینستاگرام گسترش دادیم. با جمعیت کوچک‌تر، مهندسان مستقیماً با همکاران خود انگیجمنت پیدا کردند و اشکال زدایی صورت پذیرفت، که منجر به یک حلقه بازخورد بسته در داخل سازمان شد.

تست‌های Load (یا بدون Load Test)

پرسش: چگونه برای لانچ محصول آماده شدید و لود اولیه را تحمل کردید؟ به عنوان مثال، آیا تست‌های لود را از قبل انجام داده‌اید یا تست‌های دیگری را امتحان کردید؟

انجام تست‌های گسترده مطمئناً جزو برنامه ما بود. با این حال، به دلیل شرایط خارجی (احتمالا منظور ایشان محدودیت اعمال شده توسط توئیتر در تعداد فیدهای قابل خواندن توسط کاربران که فرصت خوبی برای لانچ سریع محصول به نظر می‌رسید - مترجم)، ما انتشار محصول خود را زودتر از زمان برنامه‌ریزی شده انجام دادیم.

ما باید ظرفیت خود را افزایش می‌دادیم و از لانچ در حین ادامه توسعه پشتیبانی می‌کردیم. این به دلیل انتشار زودتر از برنامه‌ریزی ما بود و به دلیل این تغییر جدول زمانی، ما نتوانستیم تست‌های لود را از قبل انجام دهیم. این یکی از شدیدترین و سریع‌ترین لانچ‌هایی بود که در آن شرکت داشتیم!

پرسش: چقدر مطمئن یا نامطمئن بودید که می‌توانید یک لود بزرگ بالقوه را هنگام انتشار تحمل کنید؟ من انجام یک لانچ به صورت جهانی (البته به استثنای کاربران اروپایی به دلیل مسائل حقوقی بین متا و اتحادیه اروپا - مترجم) بدون محدودیتی برای ثبت نام و یا لیست انتظار را شاهد بودم، همانطور که شما انجامش دادید.

ما می‌دانستیم که تخصص اینستاگرام و متا را پشت سر داریم، بنابراین برای لانچ نسبتاً مطمئن بودیم. و البته ما در ابتدا فکر می‌کردیم که در مقیاسی کوچکتر از کل کاربران متا باشیم. حقیقتا ورود تعداد زیادی کاربر، به این سرعت، در متا بی‌سابقه بود. با این حال یک دهه سرمایه گذاری در زیرساخت‌های قابل اعتماد و کارآمد در متا واقعا کمک کرد. زمینه‌هایی مانند:

• پایگاه‌های داده (Datebases)
• سیستم‌های نمایه‌سازی مبتنی بر گراف (Graph indexing systems)
• سیستم‌های رتبه بندی (Ranking systems)
• سیستم‌های یکپارچگی (Integrity systems)
• سیستم‌های اطلاع رسانی (Notification systems)

این سیستم‌ها همه به طور هماهنگ کار می‌کردند تا لود وارد شده را بدون هیچ گونه مشکل جدی‌ای جذب و مدیریت کنند.

انتشار تردز

پرسش: از بیرون، لانچ محصول به طرز شگفت‌آوری روان به نظر می‌رسید و شاید نهایتا چند ضربه کوتاه در هفته اول وجود داشت. از داخل سازمان چطور پیش رفت؟

این یک وضعیت "همه دست به کار باشید" برای تیم بود، از هفته قبل از راه‌اندازی و برای هفته‌های پس از آن. ما تماس‌های ویدیویی منظمی را میزبانی می‌کردیم تا درباره مشکلات به صورت زنده صحبت کنیم، و اکثریت تیم شبانه‌روز برای حل مشکلات مختلف کار می‌کردند.

نکته دلگرم کننده این بود که قطعاً این یک تلاش فقط از سوی تیم Threads نبود. بخش عمده‌ای از پشتیبانی راه‌اندازی از سوی تیم‌های همکار ما در اینستاگرام و در سراسر متا انجام شد. توسعه دهندگانی که روی اجزای زیرساختی کار می‌کردند با مهندسان و افراد فنی که سیستم‌ها را فعال نگه می‌داشتند، و مهندسان محصول برای رفع اشکال ویژگی‌های آنها کار می‌کردند، همکاری خوبی نشان دادند.

لانچ تردز فرصتی برای مشاهده مزایای داشتن یک فرهنگ باز در سازمان است. یک پایگاه کد باز که واقعاً سودمند است، زیرا افراد جدید می توانند به سرعت به کار ملحق شده و ارزش ارائه کنند، حتی اگر موضوع کاملا جدید باشد.

اندازه گیری چگونه پیش رفتن نحوه انتشار محصول

پرسش: برای اطمینان از اینکه تردز همانطور که انتظار می‌رفت کار می‌کند، روی کدام KPI های مهندسی یا اندازه‌گیری‌ها تمرکز کردید؟

ما از ابزارهای نظارتی مانند موارد زیر استفاده کردیم:

• سیستم ODS - یک ماشین ذخیره سازی سری زمانی با کارایی بالا - و Scuba - یک سیستم مدیریت داده که ما برای تجزیه و تحلیل بلادرنگ (Real-Time) استفاده می‌کنیم. این ابزارها به پیگیری لود و موارد مشابه در زمان واقعی کمک می‌کنند.
• یک اکوسیستم ETL تکامل یافته که متریک‌های کلیدی محصول را به صورت ساعتی به ما ارائه می‌دهد.

ما به شدت از ابزارهای PREQ (عملکرد، قابلیت اطمینان، کارایی، کیفیت) استفاده کردیم. تیم ما بر تجربه فوق‌العاده متا در پشتیبانی از ابزارهای PREQ که در اپلیکیشن سمت کلاینت ساخته و در فریم‌ورک‌های سمت سرویس‌دهنده ما ادغام شده‌اند، تکیه کرده‌اند. متریک‌هایی که ما به آنها توجه داشتیم عبارتند از:

• عملکرد و لود سمت سرور (Performance and server-side load)
• "زمان لازم برای محتوای جدید" - متریک Cold Start ما در اپلیکیشن
• شاخص QPS / نرخ موفقیت در نقاط پایانی کلیدی ما (success rate on our key endpoints)
• طول صف در کارهای ناهمگام همراه با پردازش‌های سنگین (async jobs handling heavy lifting)
• ردپای کلی ما در مونولیت اصلی بک اند اینستاگرام (Instagram backend monolith)

در صورتی که مقیاس را هم به درستی در نظر نگرفته باشیم، هشدارهای همگانی در سطح نقاط پایانی نیز هنگامی که چیزها برای نقاط پایانی خاصی می روند، به ما اطلاع می‌دهند.

آمار و ارقام لانچ

رکورد قبلی سریعترین رشد اپلیکشن در متا، 1 میلیون کاربر در 5 روز بود. Threads اما اینگونه رشد کرد:

• 1 میلیون کاربر در 1 ساعت اول
• 30 میلیون کاربر در روز اول
• 70 میلیون کاربر در روز دوم
• 100 میلیون کاربر در روز پنجم

دروس آموخته و گام‌های بعدی

پرسش: چالش سختی که پیش آمد چه بود؟

ایجاد یک فید جذاب برای Threads بزرگترین چالش بود. در یک سایت میکروبلاگینگ (مانند توئیتر)، مواردی در حال حاضر به وقوع می‌پیوندند اهمیت بیشتری دارند. باید آنچه که همه در مورد آن صحبت می‌کنند، ثبت و ضبط شود و انتخاب‌هایی را ارائه کند که کاربران در آن مکالمه‌ها غوطه‌ور شوند و انتشار مطلب را ادامه دهند.

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

ما در تیم Threads صحبت کرده‌ایم که چگونه می‌خواهیم اتکای خود را به کاربرانی که به صورت دستی گراف دنبال‌کنندگان را تنظیم می‌کنند کاهش دهیم. با این حال، برای کاهش اتکا به آن، باید بدانید که این پست‌ها در مورد چی هستند، و بدانید که در دنیا چه می‌گذرد – که حداقل می‌توان گفت هر دو چالش برانگیز هستند!

دروس آموخته برای تیم فنی

پرسش: چه چیزی از نظر فنی و مهندسی در این پروژه و لانچ آن خوب پیش رفت؟

این دو مورد برجسته هستند:

• سرعتی که با آن توانستیم یک محصول صیقل خورده آماده عرضه بسازیم.
• اندازه نسبتاً کوچک تیمی که به این موفقیت دست یافت، هم از نظر درون‌سازمانی و هم از نظر بیرون آن مطلوب بود.

قبل از راه اندازی این برنامه، علاقه زیادی در بازار وجود داشت، که به مردم دلیل خوبی برای دانلود برنامه و امتحان کردن آن را داد. وظیفه ما به عنوان مهندس این بود که موانع فنی را از سر راه برداریم و به آنها اجازه دهیم این کار را انجام دهند. این یک دستاورد بزرگ است که ما توانستیم این کار را به شکلی روان و خوب انجام دهیم.

پرسش: چه آموخته‌های ارزشمندی برای تیم فنی و مهندسان وجود دارد ؟

تمرکز: تمایز اصلی بین محصولاتی است که برای یافتن محصول متناسب با بازار تنظیم شده اند و آنها که اینگونه نیستند. تمرکز ضروری است، اگرچه به خودی خود کافی نیست. تلاش در Threads این بود که بتوانیم با کوچک کردن اسکوپ تجربه محصول به شکلی تهاجمی، بر روی اصول اولیه تمرکز کنیم. در اوایل تصمیم گرفتیم اجرا را روی Milestone های درون سازمانی متمرکز کنیم. هر کدام از این Milestone ها یک اپلیکیشن کاملاً صیقل خورده و shippable بود که با عملکردهای کمتری ساخته شده بود. این Milestone های درونی، شفافیت را در مورد آنچه که ما برای ساختن آن نیاز داشتیم، فورس می‌کرد، زیرا اصلا زمانی برای بازگشت به عقب و بررسی چیزهای دیگر وجود نداشت.

پرسش: به عنوان یک مهندس و فردی فنی، جالب ترین بخش این پروژه چه بود؟

درک وسعت کدبیس‌های اینستاگرام. تصمیم فنی برای به اشتراک گذاشتن بسیاری از استک فناوری با اینستاگرام به این معنی بود که ساخت این اپلیکیشن به تمرینی برای ایجاد تغییر از طریق کدبیس‌های اینستاگرام تبدیل شد، و ما توانستیم آنها را به شکلی هدفمند برای پشتیبانی از کارهای خود مورد استفاده قرار دهیم.

به ندرت می‌توان همزمان که به جزئیات پیاده‌سازی در زیرسیستم‌های مهم اینستاگرام میپردازیم بهانه‌ای هم برای درک اینستاگرام در چنین سطح بالایی به دست آورد! تقریباً شبیه یک پازل بود: ما باید در می‌یافتیم که در کدام سیستم‌های اینستاگرام هدفمندترین تغییرات را ایجاد کنیم که بیشترین دستاورد و در عین حال کمترین ریسک را داشته باشد. این چالش در نهایت جالب ترین بخش پروژه بود.

گام‌های بعدی

پرسش: راه اندازی Threads چه تاثیری بر نحوه ساخت اپلیکیشن‌ها در متا می‌تواند داشته باشد؟

افراد زیادی بوده اند که در داخل به Threads به عنوان یک مطالعه موردی برای بررسی شیوه عرضه محصولات در آینده نگاه می‌کنند. سرعت بالای ارسال اولین نسخه Threads چیزی است که این راه‌اندازی را متمایز می‌کند – در حالی که کار روی این برنامه از اوایل همین سال آغاز شده است!

این یک تغییر فرهنگی قابل توجه است که یک تیم فنی کوچک اما سینیور یک اپلیکیشن مستقل با این نوع استقبال عمومی را فقط در طی پنج ماه، حتی در متا بسازد و لانچ کند. از اینکه می‌بینم دیگران دارند الهام می‌گیرند و تیم‌های سریعتر و تهاجمی‌تری می‌سازند، هیجان زده هستم!

پرسش: اولویت‌های بعدی تیم و برنامه‌های رشد آن چیست؟

در خصوص اولویت‌ها، جدا از فیکس و بهبود تمام گپ‌ها و حفره‌های محصول اصلی که کاربران ما آنها را به صورت فیدبک فریاد می‌زنند، ما همچنین سرمایه‌گذاری هنگفتی در ارتقاء زیرساخت لازم برای قوی‌تر کردن Threads انجام می‌دهیم.

تعداد لانچ‌های واقعی ما بسیار فراتر از پیش بینی‌ها بود. لیدرهای ما نسبت به مسیر برنامه خوشبین هستند و در نتیجه، ما روی رشد تیم فنی و مهندسی سرمایه گذاری می‌کنیم.

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

پرسش: تیم فنی و مهندسی با نگاه به آینده از چه چیزهایی هیجان زده است؟

ما روی ارائه ویژگی‌های جدید تردز در سریع‌ترین زمان ممکن کار کرده‌ایم. یکی از این ویژگی‌ها، نسخه تحت وب لاگین شده است که بسیار درخواست شده بود و ماه گذشته آن را ارسال کردیم. نسخه دیگر، گسترش تست جستجوی محتوای کلمه کلیدی ما برای کاربران بیشتری در کانادا، ایالات متحده، هند و بریتانیا است - که امروز (7 سپتامبر 2023) آن را لانچ می‌کنیم.

من برای تیم ما برای حفظ ویژگی‌های shipping که تجربه افراد را در Threadsبهبود می بخشد، هیجان زده هستم. من همچنین از تعهدمان برای پیوستن به Fediverse و پشتیبانی از پروتکل ActivityPub هیجان‌زده هستم. در مقیاس ما، این یک چالش فنی و نظارتی فوق العاده هیجان انگیز است. پیوستن به Fediverse و ایجاد قابلیت همکاری با سایر شبکه‌ها برای ایجاد یک اکوسیستم گفتگوی عمومی متنوع‌تر و پر رونق، چیزی است که ما همچنان متعهد به تلاش برای آن هستیم.

نکات Takeaways

من (Gergely) به عنوان نویسنده این مقاله از Jesse، Zahan و تیم مهندسی Threads برای به اشتراک گذاشتن جزئیات در مورد نحوه ساخت و راه اندازی برنامه بسیار سپاسگزارم. برای ما مخاطبان جالب بود بدانیم که این تیم چگونه این شاهکار را به دست آورد و چگونه رویکردهای آن‌ها با آنچه در مورد فرهنگ مهندسی متا می‌دانیم مطابقت دارد.

آخرین سوالی که باید از تیم Threads بپرسم، برنامه آنها برای لانچ در اتحادیه اروپا است. این برنامه در سطح جهانی در دسترس است - به جز اتحادیه اروپا، به دلیل نگرانی‌های قوانین و مقررات آنجا. این چیزی است که تیم در مورد برنامه های خود به من گفت:

ما در حال کار بر روی انتشار Threads در کشورهای بیشتری هستیم و به ارزیابی اینکه آیا در اتحادیه اروپا هم لانچ کنیم یا خیر، ادامه خواهیم داد، اما موضوع قوانین و مقررات اتحادیه اروپا در تصمیم ما برای عدم لانچ آن در حال حاضر نقش داشته است. اروپا همچنان یک بازار فوق العاده مهم برای متا است و ما امیدواریم در آینده محصولات جدیدی را در اینجا در دسترس قرار دهیم.

جالب است بدانیم که آیا متا لانچ تردز در اتحادیه اروپا را به تعویق می اندازد؟ یا اینکه می‌توانیم انتظار داشته باشیم اپلیکیشن‌ها و سرویس‌های جدیدی که توسط شرکت‌های بزرگتر راه اندازی شده‌اند، به دلیل پیامدهای اضافی حفظ حریم خصوصی که قوانین سختگیرانه اروپایی نیاز دارد از استراتژی «آخر از همه در اتحادیه اروپا!» پیروی کنند.

مشاهده نسخه انگلیسی مقاله: