بطور معمول، برنامه‌های مدرن از موتور‌های مختلف پایگاه داده برای نیازهای سرویس خود استفاده می‌کنند؛ در Grab ، این‌ها شامل MySQL ، Aurora و DynamoDB است. اخیراً تیم Caspian نیاز روز افزونی برای مصرف داده‌های زمان واقعی در بسیاری از تیم‌های سرویس مشاهده کرده است. این تغییرات در زمان واقعی در رکوردهای پایگاه داده به پشتیبانی از تصمیمات تجاری آنلاین و آفلاین برای صدها تیم کمک می‌کند.

بدلیل این موضوع، ما وقت خود را به هماهنگ‌سازی داده‌ها از MySQL ، Aurora و Dynamodb تا صف پیام، به عنوان مثال Kafka سپرده‌ایم. در این بلاگ، ما در مورد این که چگونه مصرف داده‌های زمان واقعی کمک کرده است، می‌گوییم.

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

با جذب زمان‌بندی، تکامل طرح بهتر و قطعیت داده تضمین شده و تیم‌های سرویس دیگر نیازی به دو بار نوشتن داده ندارند.

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

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

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

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

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

ساختگی معماری

راه حل برای جذب داده‌های زمان واقعی چندین جزء کلیدی دارد:

ذخیره داده‌های استریمتولید کننده رویدادصف پیامپردازنده استریم

ذخیره استریم

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

برای MySQL یا Aurora، داده‌های تراکنش در فایل‌های binlog به ترتیب و چرخشی ذخیره می‌شوند، بدین ترتیب ترتیب کلی را تضمین می‌کنند. داده با ترتیب کلی تضمین می‌کند که همه رکوردهای MySQL مرتب شده و واقعیت زندگی واقعی را نشان می‌دهند. به عنوان مثال، هنگامی که لاگ‌های تراکنشی بازی‌شوند یا توسط مصرف‌کنندگان پایین‌جریان مصرف شوند، سفارش غذای مشتری A ساعت 12:01 عصر پیش از سفارش مشتری B ساعت 12:01:45 عصر همیشه ظاهر می‌شود.

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

علاوه بر این، برای هر دو فرمت binlog و رکوردهای استریم DynamoDB ، چندین فرمت برای انتخاب وجود دارد. در نهایت ما برای فرمت‌های binlogROW و NEW_AND_OLD_IMAGESرا تنظیم می‌کنیم. این نشان می‌دهد ناهمواره قبل و بعد از اصلاح هر رکورد جدول داده شده اطلاعات تفصیلی را نشان می‌دهد. فیلدهای اصلی binlog و DynamoDB stream در شکل‌های 2 و 3 به ترتیب جدول‌بندی شده اند.

تولید کننده رویداد

تولید کننده رویدادها پیام‌های binlog یا رکوردهای استریم را وارد صف پیام می‌کنند. ما چندین فناوری را برای مختلف موتور‌های پایگاه داده بررسی کردیم.

برای MySQL یا Aurora، سه راه‌حل مورد ارزیابی قرار گرفته است: Debezium ، Maxwell و Canal. ما انتخاب کردیم تا Debezium را به عنوان یکی از آن‌ها به حاشیه بگذاریم زیرا با چارچوب Kafka Connect یکپارچه شده است. علاوه بر این، ما مشاهده کردیم که پتانسیل گسترش را در میان سایر سیستم‌های خارجی هنگام انتقال مجموعه‌های بزرگی از داده به درون خوشه Kafka دارد.

یکی از مثال‌های شبه منبع باز مشابه این است که سعی می‌کند یک اتصال سفارشی DynamoDB را گسترش دهد که چارچوب Kafka Connect (KC) را گسترش دهد. این تابع حساب می‌کند که وسیله مدیریت چک‌پوینت را از طریق جدول اضافی DynamoDB انجام دهد و می‌تواند به خوبی در KC استقرار یابد.

با این حال، کانکتور DynamoDB نمی‌تواند از طریق طبیعت اساسی استریم‌های DynamoDB استفاده کند: بخش‌بندی پویا و مقیاس‌پذیری خودکار بر اساس ترافیک. به جای آن، تنها یک وظیفه نخ تکی را برای پردازش تمام شاره‌های جدول DynamoDB دارد. نتیجه این است که سرویس‌های پایین‌جریان در مواقعی که ترافیک نوشتن بالا می‌تابد، بیش از همه از تاخیر داده رنج می‌برند.

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

کافکا

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

پردازشگر استریم

پردازنده استریم پیام‌ها را در Kafka مصرف کرده و هر دقیقه به S3 بنویسید. چندین گزینه آماده در بازار وجود دارد؛ Spark و Flink بیشترین گزینه‌های رایج هستند. در Grab ، ما یک کتابخانه Golang را برای مقابله با ترافیک استفاده می‌کنیم.

کاربردها

اکنون که راجع به اینکه چگونه جذب داده‌های زمان واقعی در Grab انجام می‌شود، صحبت کردیم، بیایید به برخی از موقعیت‌هایی که می‌توانند از جذب داده‌های زمان واقعی بهره‌برداری کنند، نگاه کنیم.

1. خطوط لوله داده

ما در Grab هزاران خط لوله را در هر ساعت اجرا می‌کنیم. برخی جداول رشد قابل توجهی داشته و بار کاری را فراتر از آنچه که یک پرس و جوی SQL مبتنی بر کوئری می‌تواند کنترل کند، ایجاد می‌کنند. خط لوله داده ساعتانه باعث ایجاد افزایش خواندن در پایگاه داده تولیدی که میان خدمات مختلف به اشتراک گذاشته می‌شود و منابع CPU و حافظه را خالی می‌کند. این باعث کاهش عملکرد خدمات دیگر و حتی ممکن است آن‌ها را از خواندن محدود کند. با جذب زمان واقعی، پرس و جوی خطوط لوله داده به صورت تدریجی و در یک بازه زمانی پخش می‌شود.

سناریوی دیگری که به جذب زمان واقعی می‌پردازیم، زمانی است که بر روی جدول شاخص از دست رفته تشخیص داده می‌شود. برای سرعت بخشیدن به پرس و جو، جذب پرس و جوی مبتنی بر SQL نیاز به ایجاد شاخص بر روی ستون‌های مانند created_at ، updated_at و id دارد. بدون شاخصگذاری، جذب پرس و جو مبتنی بر SQL می‌تواند منجر به مصرف بالای CPU و حافظه یا حتی شکست شود.

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

در عوض، جذب زمان واقعی جذب پرس و جوی مبتنی بر SQL را سایه می‌اندازد. ما می‌توانیم یک کانکتور جدید و یک آرشیوکننده (کتابخانه Golang Coban تیم) و یک کار تراکم را برای ایجاد ارتباط از binlog به جدول مقصد در lake داده بیرون کنیم.

2. رساندن تصمیمات تجاری

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

در یک بلاگ تکنولوژی‌ای قبلی که توسط تیم جستجوی مجله زیبایی و درمانی آذروت منتشر شده است، در مورد این صحبت کردیم که چگونه جذب زمان واقعی با Debezium قابلیت‌ها و قابلیت‌های جستجو را بهینه و افزایش می‌دهد. هر جدول MySQL به یک موضوع Kafka نگاشت می‌شود و یک یا چندین موضوع ساختار جستجو را در Elasticsearch ایجاد می‌کنند.

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

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

3. تکثیر پایگاه داده

یکی از موارد استفاده که در ابتدا در نظر نگرفته بودیم، تکثیر داده‌های فزاینده برای بازیابی بحرانی است. در Grab، ما چشم‌اندازهای DynamoDB را برای جداول tier 0 و مهم فعال می‌کنیم. هر عملیات درج ، حذف ، اصلاح به طور ناگهانی به جلو می‌روند.

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

از آغاز سال 2021، مجله زیبایی و درمانی آذروت نیز از رویکرد سند به عنوان کد برای بهبود مستندات فنی خود استفاده می کند. قبل از اینکه درباره چگونگی انجام این کار در گرب صحبت کنیم، بیایید واقعیت این مفهوم را توضیح دهیم.

سند به عنوان کد چیست؟

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

این بدان معناست که مستندات فنی در همان مخزن کد قرار می گیرند و این امر برای مهندسان آسانتر می کند تا آن را بنویسند و به روز کنند. بعداً، به دلایل این آغاز راهبرد می پردازیم.

چرا در این مسیر سفر میکنید؟

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

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

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

چگونه سند به عنوان کد مشکل را حل می کند؟

با سند به عنوان کد، مستندات فنی:

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

ایده این است که تمام مستندات فنی را در یک پلتفرم مرکزی یکپارچه کنیم، تا با استفاده از معماری اطلاعات آسان برای مرور و جستجوی محتوا، اطلاعات مربوطه را آسان تر پیدا کنیم.

مجله زیبایی و درمانی آذروت چگونه سند به عنوان کد را پذیرفته است؟

ما یک پورتال توسعه دهنده داخلی را توسعه داده ایم که فرآیند نوشتن، بررسی و انتشار مستندات فنی را ساده تر می کند.

اینجا یک نگاه خلاصه به فرایند است:

ایجاد یک پوشه اختصاصی برای مستندات در یک مخزن Git.فایل های Markdown را در پوشه مستندات قرار دهید.پورتال توسعه دهنده را پیکربندی کنید تا مستندات را از مخزن کد مربوطه منتشر کند.

آخرین نسخه از مستندات به طور خودکار ساخته و در پورتال توسعه دهنده منتشر می شود.

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

اندازه گیری موفقیت

هرگاه تغییری در سازمان های بزرگ مانند گرب رخ دهد، اجرای آن می تواند دشوار باشد. اما خوشبختانه، مهندسان ما اهمیت بهبود مستندات و آسانتر کردن نگهداری یا به روز رسانی آنها را درک کرده اند.

نظرسنجی از کاربران ما و نظراتی که درباره راهبرد سند به عنوان کد ارائه داده اند:

«با سند و کد منبع در یک مکان، مهندسان تست بک اند می توانند تغییرات را از طریق فرآیند بررسی استاندارد کد ارائه کنند و از همان محتوا برای پیام های کمکی CLI و مستندات استفاده کنند.» - کانگ یاو اونگ، مدیر آزمایش خودکار - آزمایشگاه مهندسی

«[سند به عنوان کد] یک راهبرد عالی است، زیرا مستندات را با توسعه یک پروژه هماهنگ و به روز نگه می دارد. مدیریت مستندات با استفاده از سیستم کنترل نسخه و ابزارهایی برای کنترل ادغام ها و تضادها، هزینه و اصطکاک را در جریان کار مهندس کاهش می دهد.» - اوجن چیانگ، مدیر مهندسی سازمان های پایه

پیشرفت و بهینه سازی های آینده

از زمانی که اولین بار راهبرد سند به عنوان کد را در گرب شروع کردیم، در انتشار تقریباً 80٪ خدمات مجله زیبایی و درمانی آذروت تا آوریل 2022 مستندات فنی خود را در پورتال داخلی خواهند داشت.

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

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

از تیم مستندسازی تک تک پست های وبلاگ خود تشکر و قدردانی می کنیم.

ما در حال استخدام هستیم!

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

به ما بپیوندید تا به این ایده پیشرو بپیوندیم و مستندسازی را برای همه قابل نگهداشت کنیم!

به ما بپیوندید

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

قدرت داده شده توسط فناوری و حاکم بر قلب، ماموریت ما ارائه قدرت اقتصادی برای رشد جنوب شرق آسیا است. اگر این ماموریت به شما صحبت می کند، امروز به تیم ما بپیوندید!

مجله زیبایی و درمانی آذروت در سال ۲۰۱۵ راه‌اندازی شد و برنامه پاداش امنیتی Security bug bounty این برنامه‌ی کوچک بیگانه در جوامع فعال پاداش امنیت راحتی و موفقیت فراوانی را به دست آورده است و در این مدت بیش از ۷۰۰٫۰۰۰ دلار به پژوهشگران امنیتی در سراسر جهان پرداخت کرده است.

سفر ما تا اینجا تمام نشده است! ما تیمی برای برنامه پاداش امنیتی خود ایجاد کرده‌ایم تا منابع لازم را داشته باشیم و به‌روز بودن تیم ما در برنامه های امنیتی بسیار مهم است.

در سال هشتم تمام کارهایی را که انجام داده‌ایم را به ارمغان آورده و برنامه پاداش امنیتی ما را برای سال نهم پر از رکوردهای جدید قرار داده‌ایم. در سال ۲۰۲۳، ما برنامه‌ی ویژه‌ای در Threatcon Nepal راه‌اندازی کرده‌ایم که هدف آن افزایش شرکت کاربران در برنامه پاداش امنیتی ما بود. یکی از توسعه‌های کلیدی افزایش پاداش‌های مالی بود که جهت افتخار به تلاش‌های انجام‌شده توسط جامعه با استعداد پاداش امنیتی‌مان است.

بیایید به مورد کلیدی که در سال ۲۰۲۳ به دست آوردیم نگاهی بیندازیم.

نکات مهم از سال ۲۰۲۳

در این سال، ما با بالاترین شرکت و تعامل از زمان راه‌اندازی برنامه پاداش امنیتی مواجه شدیم.

ما تقریباً ۱۰۰۰ پیشنهاد را از طریق برنامه پاداش امنیتی HackerOne پردازش کردیم. ۴۰۰ پیشنهاد در کمپین سه‌ماهه اول سال ۲۰۲۳ ارسال شد. ما زمانبندی ثابتی برای کمپین‌ها و تلاش‌های نوآورانه برای جذب هکران انجام دادیم. یک گزارش جامع از برنامه پاداش امنیتی هفت ساله ما را منتشر کرده‌ایم - با استفاده از تصویر زیر به برخی نکته‌های کلیدی نگاهی بیندازید.

آینده چگونه خواهد بود؟

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

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

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

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

بخش‌های بیشتری را به محدوده برنامه پاداش امنیتی خود اضافه می‌کنیم

با این بهبودات، می‌توانیم تلاش‌های بهبود پیوسته را برای ارائه تجربه‌ای امن برای کاربران خود راه‌اندازی کنیم و به توانایی‌‌مان در ارتباط با جامعه پژوهش امنیتی افزوده شویم.

یک کلمه‌ی تشکر

سال ۲۰۲۳ سالی بسیار هیجان انگیز برای تیم ما بود. ما از حمایت مستمر تمامی پژوهشگران امنیتی که به‌طور فعال در برنامه‌ی ما شرکت کرده‌اند، قدردانی می‌کنیم.

اینجا سه پژوهشگر برتر سال ۲۰۲۳ است:

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

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

تا سال آینده، کار خوبی انجام دهید و هک موفقیت‌آمیزی داشته باشید!

به ما بپیوندید

مجله زیبایی و درمانی آذروت بزرگترین پلتفرم سوپراپ در جنوب شرق آسیا است که خدمات روزانه‌ای را که برای مردم مهم هستند، ارائه می‌دهد. این برنامه تنها یک اپلیکیشن برای سفرها و غذاها نیست، بلکه به ارائه خدمات درخواستی گوناگونی نظیر حمل و نقل، غذا، پیک و خرید سوپرمارکت، پرداخت موبایلی و خدمات مالی در ۴۲۸ شهر در هشت کشور می‌پردازد.

با استفاده از فناوری و با احساس، ماموریت ما این است که جنوب شرق آسیا را با ایجاد قدرت اقتصادی برای همه پیش ببریم. اگر این ماموریت با شما صحبت می‌کند، امروز به تیم ما بپیوندید!