سلام، هابر! موږ په تیرو څو میاشتو کې له یوې ډیرې په زړه پورې وضعیت څخه تیر یو، او زه غواړم د خپل زیربنا د کچې د لوړولو کیسه شریکه کړم. پدې موده کې، د سبر مارکیټ امرونه څلور چنده شول او موږ په ۱۷ نویو ښارونو کې خدمت پیل کړ. د خوراکي توکو د رسولو لپاره د تقاضا په لوړېدو سره موږ اړ شو چې خپل زیربنا پراخه کړو. د خورا په زړه پورې او ګټورو موندنو لپاره ولولئ.
زما نوم دیما بوبیلیوف دی، او زه د سبر مارکیټ CTO یم. څرنګه چې دا زموږ په بلاګ کې لومړۍ پوسټ دی، زه به د ځان او شرکت په اړه یو څو خبرې ووایم. تیر مني کې، ما د ځوانو RuNet مشرانو سیالۍ کې برخه اخیستې وه. د سیالۍ لپاره، زه ما په SberMarket کې د خپل داخلي کلتور او د خدماتو پراختیا ته د تګلارې په اړه بحث وکړ. که څه هم ما سیالي ونه ګټله، ما د معلوماتي ټکنالوژۍ ایکوسیستم د پراختیا لپاره مهم اصول رامینځته کړل.
کله چې د ټیم اداره کول، نو دا مهمه ده چې د سوداګرۍ اړتیاوې د انفرادي پراختیا کونکي اړتیاو سره درک او متوازن کړئ. SberMarket اوس مهال په کال کې ۱۳ ځله وده کوي، او دا په محصول اغیزه کوي، چې د پراختیا حجم او سرعت کې دوامداره زیاتوالي ته اړتیا لري. سره له دې، موږ پراختیا کونکو ته د لومړني تحلیل او لوړ کیفیت کوډ لیکلو لپاره کافي وخت وقف کوو. دا تاسیس شوی چلند نه یوازې د کار کولو محصول په جوړولو کې مرسته کوي بلکه د هغې په راتلونکي پیمانه کولو او پراختیا کې هم مرسته کوي. د دې ودې په پایله کې، SberMarket دمخه د خوراکي توکو رسولو خدماتو کې مخکښ شوی دی: موږ هره ورځ نږدې ۱۸،۰۰۰ امرونه وړاندې کوو، چې د فبروري په لومړیو کې شاوخوا ۳،۵۰۰ وو.
یوه ورځ، یو پیرودونکي د سبر مارکیټ له یوه کوریر څخه وغوښتل چې د هغه خوراکي توکي پرته له تماس څخه - مستقیم د هغه بالکوني ته ورسوي.
خو راځئ چې مشخصاتو ته راشو. په تیرو څو میاشتو کې، موږ په فعاله توګه د خپل شرکت زیربنا اندازه کوو. دا اړتیا د بهرنیو او داخلي دواړو عواملو له امله وه. زموږ د پراخیدونکي مراجعینو اساس سره سره، د تړلو پلورنځیو شمیر د کال په پیل کې له 90 څخه د می تر نیمایي پورې 200 ته لوړ شو. البته، موږ چمتووالی نیولی و، د اصلي زیربنا ملاتړ یې کاوه، او د Yandex کلاوډ کې کوربه شوي ټولو مجازی ماشینونو د پورته او ښکته کولو وړتیا باندې حساب کاوه. په هرصورت، تجربې ښودلې چې "هر هغه څه چې غلط کیدی شي، غلط به شي." نن، زه غواړم ځینې خورا په زړه پورې حالتونه شریک کړم چې په تیرو څو اونیو کې پیښ شوي. زه هیله لرم چې تاسو زموږ تجربه ګټوره ومومئ.
غلام په بشپړ ډول جنګي چمتووالی لري
حتی د وبا څخه دمخه، موږ خپلو بیک انډ سرورونو ته د غوښتنو زیاتوالی تجربه کاوه. د کور تحویلۍ لپاره د خوراکي توکو امر کولو رجحان په چټکۍ سره وده کوله، او د لومړي COVID-19 لاک ډاون اقداماتو معرفي کولو سره، بار په ټوله ورځ کې په ډراماتیک ډول زیات شو. اړتیا رامینځته شوه چې د لومړني ډیټابیس ماسټر سرورونو باندې بار ژر تر ژره کم شي او ځینې لوستل شوي غوښتنې نقل سرورونو (غلامانو) ته ولیږدول شي.
موږ د دې ګام لپاره دمخه چمتووالی نیولی و، او د دې مانور لپاره دوه غلام سرورونه لا دمخه پیل شوي وو. دوی په عمده توګه د شریکانو سره د معلوماتو تبادلې لپاره د معلوماتو فیډونو رامینځته کولو لپاره د ډله ایزو دندو ترسره کول. دې پروسو غیر ضروري کاري بار رامینځته کړ او په سمه توګه څو میاشتې دمخه له پامه وغورځول شول.
څرنګه چې په غلام باندې نقل رامنځته شو، موږ دې مفکورې ته غاړه کیښوده چې غوښتنلیکونه کولی شي د دوی سره یوازې د لوستلو حالت کې کار وکړي. د ناورین د بیا رغونې پلان فرض کړ چې د ناورین په صورت کې، موږ کولی شو په ساده ډول د ماسټر پر ځای غلام نصب کړو او د لوستلو او لیکلو ټولې غوښتنې غلام ته واړوو. په هرصورت، موږ دا هم غوښتل چې د تحلیل څانګې لپاره نقلونه وکاروو، نو سرورونه په بشپړ ډول یوازې د لوستلو لپاره تنظیم شوي نه وو. هر کوربه د کاروونکو خپل سیټ درلود، ځینې یې د لیکلو لاسرسی سره د منځمهاله محاسبې پایلې خوندي کولو لپاره.
تر یوې ټاکلې کچې پورې، موږ د HTTP غوښتنو لیکلو او لوستلو لپاره کافي سرچینې درلودې. د مارچ په نیمایي کې، لکه څنګه چې سبرمارکیټ پریکړه وکړه چې په بشپړ ډول لیرې لاړ شي، موږ په RPS کې ډراماتیک زیاتوالی تجربه کړ. زموږ ډیر او ډیر پیرودونکي ځان جلا کول یا له کوره کار کول، کوم چې زموږ د بار شاخصونو اغیزه وکړه.
د ماسټر فعالیت نور کافي نه و، نو موږ د ځینو درنو لوستلو غوښتنو نقل ته ډاونلوډ کول پیل کړل. د لیکلو غوښتنې ماسټر ته په شفاف ډول لیږدولو او غلام ته د لوستلو غوښتنې، موږ د روبي قیمتي ډبره وکاروله ""موږ د لیکلو اجازې پرته د _readonly پوسټ فکس سره یو ځانګړی کاروونکی جوړ کړ. په هرصورت، په یوه کوربه کې د ترتیب کولو غلطۍ له امله، ځینې لیکلو غوښتنې د کارونکي نوم لاندې غلام سرور ته لیږل شوي، کوم چې مناسب اجازې درلودې.
ستونزه سمدلاسه څرګنده نه شوه، ځکه چې د بار زیاتوالي د غلامانو ځنډ زیات کړ. د معلوماتو ناانډولي په سهار کې وموندل شوه، کله چې د شپې له وارداتو وروسته، غلامان د ماسټر سره "نیولو" کې پاتې راغلل. موږ دا پخپله د خدماتو لوړ بار او د نوي پلورنځیو د پیل سره تړلي وارداتو ته منسوب کړ. په هرصورت، د څو ساعتونو ځنډ سره د معلوماتو وړاندې کول د منلو وړ نه وو، نو موږ پروسې دوهم تحلیلي غلام ته واړولې، لکه څنګه چې دا وه.оډیرې سرچینې وې او د لوستلو غوښتنو سره ډکې نه وې (دا هغه څه دي چې موږ ځان ته د نقل کولو ځنډ نشتوالی تشریح کړ).
کله چې موږ د لومړني غلام د "کریپ" لاملونه وموندل، تحلیلي سرور لا دمخه د ورته دلیل لپاره ناکام شوی و. سره له دې چې دوه اضافي سرورونه درلودل چې موږ یې د ماسټر د ناکامۍ په صورت کې د بار لیږدولو پلان درلود، یوه بدبخته تېروتنه پدې معنی وه چې په مهم وخت کې، هیڅ یو شتون نه درلود.
خو څرنګه چې موږ نه یوازې ډیټابیس له منځه یوړ (په هغه وخت کې بیا رغونه شاوخوا 5 ساعته وخت ونیو) بلکې د ماسټر سرور سنیپ شاټ یې هم واخیست، موږ وکولای شو چې نقل په 2 ساعتونو کې پیل کړو. په هرصورت، له هغې وروسته، موږ د نقل کولو د اوږدې لاګ جوړونې سره مخ شو (ځکه چې پروسه یو واحد تار لري، مګر دا یوه بشپړه بله کیسه ده).
پایله: له دې پېښې وروسته، دا څرګنده شوه چې موږ باید د کاروونکو لپاره د لیکلو لاسرسي محدودولو عمل پریږدو او ټول سرور یوازې لوستلو اعلان کړو. دا طریقه ډاډ ورکوي چې نقلونه به په مهمو شیبو کې شتون ولري.
حتی د یوې درنې پوښتنې اصلاح کول کولی شي ډیټابیس بیرته ژوندی کړي.
که څه هم موږ په دوامداره توګه د ویب پاڼې کتلاګ تازه کول، هغه پوښتنې چې موږ یې د غلام سرورونو ته لیږو د ماسټر څخه یو څه وروسته وې. هغه وخت چې موږ د غلامانو د ناڅاپه له خدماتو څخه د وتلو سره د ستونزې کشف او حل کولو لپاره واخیست د "رواني خنډ" څخه ډیر اوږد و (د نرخ تازه معلومات پدې وخت کې پیښ کیدی شي، او پیرودونکو به زاړه معلومات لیدلي وي)، او موږ اړ شو چې ټولې پوښتنې اصلي ډیټابیس سرور ته واړوو. په پایله کې، ویب پاڼه ورو روانه وه ... مګر لږترلږه دا کار کاوه. او پداسې حال کې چې د غلام سرور بیرته راګرځیده، موږ د اصلاح کولو پرته بله چاره نه درلوده.
پداسې حال کې چې د غلام سرورونه بیرته راګرځېدل، دقیقې یې تېرې شوې، ماسټر سرور ډیر بار پاتې شو، او موږ خپلې ټولې هڅې د پارټو اصل سره سم د فعالو دندو په غوره کولو تمرکز وکړ: موږ د بار ډیری برخه محاسبه کولو لپاره غوره پوښتنې غوره کړې او ټونینګ یې پیل کړ. دا په الوتنه کې ترسره شو.
یوه په زړه پورې پایله دا وه چې په بشپړ ډول بار شوي MySQL مثال حتی د پروسې کوچني پرمختګونو ته ځواب ورکړ. د یو څو پوښتنو اصلاح کول چې د ټول بار یوازې 5٪ لپاره حساب شوي دمخه د CPU بار کې د پام وړ کمښت ښودلی. په پایله کې، موږ وکولی شو د ماسټر ډیټابیس لپاره د منلو وړ سرچینې زیرمه ډاډمن کړو او د نقلونو بیا رغولو لپاره اړین وخت ترلاسه کړو.
پایله: حتی کوچني اصلاح کول موږ ته اجازه راکوي چې د څو ساعتونو لپاره د ډیر بار څخه ژوندي پاتې شو. دا زموږ لپاره کافي وو چې زموږ د نقل سرورونه بیرته ترلاسه کړو. په تصادفي توګه، موږ به په راتلونکي پوسټ کې د پوښتنې اصلاح کولو تخنیکي اړخونو په اړه بحث وکړو. نو زموږ بلاګ کې ګډون وکړئ که تاسو دا ګټور ومومئ.
د شریکو خدماتو د فعالیت څارنه تنظیم کړئ
موږ د پیرودونکو امرونه پروسس کوو، نو زموږ خدمات په دوامداره توګه د دریمې ډلې APIs سره اړیکه لري — د SMS دروازې، د تادیې پلیټ فارمونه، د روټینګ سیسټمونه، جیوکوډرونه، د فدرالي مالیې خدمت، او ډیری نور سیسټمونه. او کله چې بار په چټکۍ سره وده پیل کړه، موږ د خپلو شریک خدماتو API محدودیتونو سره مخ شو چې موږ یې مخکې هم په پام کې نه وو نیولي.
په ناڅاپي ډول د شریک خدماتو کوټې څخه ډیریدل ستاسو د خپل وخت د ځنډ لامل کیدی شي. ډیری APIs هغه مراجعین بندوي چې د دوی حد څخه تیریږي، او په ځینو مواردو کې، اضافي غوښتنې کولی شي د ملګري تولید سیسټم مغلوب کړي.
د مثال په توګه، کله چې د تحویلۍ حجم زیات شو، ملګري خدمات د دوی د ویشلو او لارو ټاکلو دندې نشي ترسره کولی. په پایله کې، امرونه ورکړل شول، مګر د لارې جوړولو خدمت بند شو. دا باید وویل شي چې زموږ د لوژستیک ټیم د دې شرایطو لاندې نږدې ناممکن کار ترسره کړ، او د ټیم روښانه اړیکو د لنډمهاله خدماتو بندیدو لپاره د جبران سره مرسته وکړه. په هرصورت، دا ناممکنه ده چې د امرونو دومره مقدار په دوامداره توګه په لاسي ډول پروسس شي، او یو څه وخت وروسته، موږ به د امرونو او د دوی د بشپړولو ترمنځ د نه منلو وړ واټن سره مخ شو.
یو شمیر سازماني اقدامات پلي شول، او د ټیم همغږي کار موږ سره د نوي شرایطو په اړه د خبرو اترو په وخت کې د وخت په ترلاسه کولو کې مرسته وکړه او د ځینو شریکانو انتظار یې کاوه چې خپل خدمات لوړ کړي. نور APIs شتون لري چې غوره انعطاف لري او د لوړ ترافیک لپاره خورا لوړ نرخونه وړاندې کوي. د مثال په توګه، په پیل کې، موږ د تحویلي نقطې پته ټاکلو لپاره د نقشې کولو یو مشهور API وکاراوه. مګر د میاشتې په پای کې، موږ د نږدې 2 ملیون روبلو لوی بل ترلاسه کړ. له هغې وروسته، موږ پریکړه وکړه چې ژر تر ژره یې بدل کړو. زه به اعلان ونه کړم، مګر زه به ووایم چې زموږ لګښتونه د پام وړ کم شوي دي.
پایله: دا اړینه ده چې د ټولو شریکو خدماتو شرایط او مقررات وڅارل شي او په ذهن کې یې وساتل شي. حتی که دوی نن ورځ "په پراخه کچه قیمت لرونکي" ښکاري، دا پدې معنی ندي چې دوی به سبا د ودې لپاره خنډ نه شي. او البته، دا غوره ده چې د خدماتو د زیاتوالي غوښتنې لپاره مخکې له مخکې د مالي شرایطو په اړه خبرې اترې وشي.
کله ناکله دا معلومه شي چې "" (ج) مرسته نه کوي
موږ په اصلي ډیټابیس یا اپلیکېشن سرورونو کې له خنډونو سره عادت شوي یو، خو کله چې اندازه کول، ستونزې هلته راپورته کیدی شي چې تاسو یې لږ تمه لرئ. موږ په خپله ویب پاڼه کې د بشپړ متن لټون لپاره د اپاچي سولر انجن کاروو. لکه څنګه چې بار زیات شو، موږ د غبرګون وخت کې کمښت ولید، او د سرور CPU کارول 100٪ ته ورسیدل. څه ساده کیدی شي؟ موږ یوازې د سولر کانټینر ته ډیرې سرچینې ورکوو.
د متوقع فعالیت د زیاتوالي پر ځای، سرور په ساده ډول مړ شو. دا سمدلاسه په 100٪ کې پورته شو او حتی ورو یې ځواب ورکړ. په پیل کې، موږ دوه کورونه او 2 GB RAM درلود. موږ پریکړه وکړه چې هغه څه وکړو چې معمولا کار کوي - سرور اتو کورونو او 32 GB ته لوړ کړئ. شیان ډیر خراب شول (موږ به په سمه توګه تشریح کړو چې څنګه او ولې په جلا پوسټ کې).
په څو ورځو کې، موږ د دې مسلې پیچلتیاوې وموندلې او د 8 کورونو او 32 GB حافظې سره غوره فعالیت ترلاسه کړ. دا ترتیب موږ ته اجازه راکوي چې د بار زیاتولو ته دوام ورکړو، کوم چې خورا مهم دی ځکه چې وده نه یوازې د پیرودونکو له پلوه بلکې د وصل شوي پلورنځیو په شمیر کې هم ده - د دوی شمیر په دوو میاشتو کې دوه چنده شوی.
پایله: معیاري میتودونه لکه "ډیر هارډویر اضافه کول" تل کار نه کوي. نو، کله چې کوم خدمت اندازه کوئ، تاسو اړتیا لرئ په بشپړه توګه پوه شئ چې دا څنګه سرچینې کاروي او د نوي شرایطو لاندې یې فعالیت دمخه ازموینه وکړئ.
بې حالته حالت د اسانه افقي پیمانه کولو کیلي ده
زموږ ټیم عموما یو مشهور چلند تعقیبوي: خدمات باید بې حالته وي او د چلولو وخت چاپیریال څخه خپلواک وي. دې موږ ته اجازه راکړه چې په افقي ډول د اندازې کولو له لارې د زیات شوي بار سره مقابله وکړو. په هرصورت، موږ یو استثنا درلوده: د اوږدې مودې شالید کاري اداره کونکی. دا د بریښنالیک او SMS لیږلو، د پیښو پروسس کولو، د فیډ تولید، قیمت او سټاک واردول، او د عکس پروسس کولو اداره کوله. دا داسې پیښ شو چې دا په محلي فایل ذخیره پورې اړه لري او یو واحد مثال و.
کله چې د پروسس کولو په کتار کې د دندو شمیر زیات شو (کوم چې په طبیعي ډول د امرونو د زیاتوالي سره پیښ شو)، د پروسسر او فایل ذخیره کولو کوربه توب فعالیت محدود شو. په پایله کې، د موجودیت او قیمت تازه معلومات، د کارونکي خبرتیاوې، او ډیری نور مهم فعالیتونه د بیکلاګ له امله ودرول شول. د عملیاتو ټیم په چټکۍ سره د فایل ذخیره د S3 په څیر شبکې ذخیره ته لیږدوله، موږ ته اجازه راکړه چې د شالید پروسس اندازه کولو لپاره ډیری پیاوړي ماشینونه ځای په ځای کړو.
پایله: د بې وطنه قانون باید د ټولو برخو لپاره پرته له استثنا څخه تعقیب شي، حتی که داسې ښکاري چې موږ به خپل حد ته ونه رسیږو. دا غوره ده چې د ټولو سیسټمونو په سمه توګه کار کولو لپاره لږ وخت مصرف کړئ د دې په پرتله چې د کوډ بیا لیکلو او د ډیر بار شوي خدمت حل کولو کې بیړه وکړئ.
د ژورې ودې لپاره ۷ اصول
سره له دې چې د اضافي ظرفیت شتون شتون لري، موږ د ودې په حال کې له څو ننګونو سره مخ شوي یو. پدې موده کې، د فرمایشونو شمیر له څلور چنده زیات شوی دی. موږ اوس مهال په ۶۲ ښارونو کې هره ورځ له ۱۷۰۰۰ څخه ډیر فرمایشونه وړاندې کوو او پلان لرو چې خپل جغرافیایي لاسرسی نور هم پراخ کړو - موږ تمه لرو چې د ۲۰۲۰ کال په لومړۍ نیمایي کې په ټوله روسیه کې خپل خدمت پیل کړو. د مخ په زیاتیدونکي کاري بار او هغو ننګونو سره د مقابلې لپاره چې موږ دمخه ورسره مخ یو، موږ د دوامداره ودې په شرایطو کې د خپلو عملیاتو اداره کولو لپاره اوه کلیدي اصول رامینځته کړي دي:
- د پیښو مدیریتموږ د جیرا بورډ جوړ کړی دی چیرې چې هره پیښه د ټکټ په توګه ثبت کیږي. دا به موږ سره د پیښې پورې اړوند دندو لومړیتوب ورکولو او بشپړولو کې مرسته وکړي. بالاخره، دا په حقیقت کې د غلطۍ کولو په اړه ندي - دا د ورته غلطۍ دوه ځله کولو په اړه دي. د هغو قضیو لپاره چیرې چې پیښې د اصلي لامل له حل کیدو دمخه تکرار کیږي، موږ اړتیا لرو چې د عمل وړ ګامونه پورته کړو، ځکه چې د لوړ کاري بار په وخت کې، دا خورا مهمه ده چې ژر تر ژره ځواب ووایو.
- څارنه دا د ټولو زیربناوو عناصرو لپاره پرته له استثنا څخه اړین دی. دا په سمه توګه د دې له امله ده چې موږ وکولی شو د بار وده وړاندوینه وکړو او په سمه توګه د حل لومړیتوب ورکولو لپاره خنډونه وپیژنو. احتمال شته چې د لوړ بار لاندې، هر هغه څه چې تاسو یې هیڅکله فکر نه کاوه مات شي یا ورو شي. له همدې امله، دا غوره ده چې د لومړیو پیښو له رامینځته کیدو وروسته سمدلاسه نوي خبرتیاوې رامینځته کړئ، ترڅو د دوی څارنه او وړاندوینه وکړئ.
- سم خبرتیاوې دا د ناڅاپي زیاتوالي په وخت کې اړین دي. لومړی، دوی باید په روښانه توګه په ګوته کړي چې څه مات شوي دي. دوهم، باید ډیر خبرتیاوې نه وي، ځکه چې ډیر غیر مهم خبرتیاوې د ټولو خبرتیاو له پامه غورځولو لامل کیږي.
- غوښتنلیکونه باید بې تابعیته وي. موږ په دې قانع شوي یو چې د دې قاعدې لپاره باید هیڅ استثنا نه وي. د رن ټایم چاپیریال څخه بشپړ خپلواکي اړینه ده. د دې ترلاسه کولو لپاره، تاسو کولی شئ شریک شوي معلومات په ډیټابیس کې یا د مثال په توګه، مستقیم په S3 کې ذخیره کړئ. لا ښه، قواعد تعقیب کړئ.د وخت د ناڅاپي زیاتوالي په جریان کې، د کوډ د اصلاح کولو لپاره هیڅ وخت نشته، او بار باید په مستقیم ډول د کمپیوټري سرچینو زیاتولو او په افقي ډول اندازه کولو سره اداره شي.
- د بهرنیو خدماتو کوټې او فعالیت. د چټکې ودې سره، ستونزې نه یوازې ستاسو په زیربنا کې بلکې په بهرنیو خدماتو کې هم رامینځته کیدی شي. تر ټولو مایوسه کوونکې خبره دا ده کله چې دا د ناکامۍ له امله نه وي، بلکې د کوټې یا محدودیتونو ته رسیدو له امله پیښیږي. له همدې امله، بهرني خدمات باید ستاسو په څیر ښه اندازه شي.
- پروسې او کتارونه جلا کړئ. دا ډېره ګټوره ده کله چې یوه دروازه له خنډ سره مخ وي. که د SMS بشپړ قطارونه د معلوماتو سیسټمونو ترمنځ د خبرتیاوو تبادلې کې مداخله نه وای کړې، موږ به د معلوماتو لیږد ځنډ تجربه نه کړی وای. سربیره پردې، که چیرې دوی په جلا توګه کار کاوه، د کارګرانو شمیر به ډیرول اسانه وای.
- مالي واقعیتونه. کله چې د معلوماتو جریان ډیریږي، نو د تعرفو او ګډون په اړه د اندیښنې لپاره هیڅ وخت نشته. مګر دا مهم دي چې په ذهن کې وساتئ، په ځانګړي توګه که تاسو یو کوچنی شرکت یاست. د هر API مالک، او همدارنګه ستاسو د کوربه توب چمتو کونکی، کولی شي له تاسو څخه یو دروند بل واخلي. نو، خپل قراردادونه په دقت سره ولولئ.
پایلې
له زیانونو پرته نه، خو موږ له دې مرحلې څخه ژوندي پاتې شو، او نن ورځ موږ هڅه کوو چې د ټولو هغو اصولو سره سم عمل وکړو چې موږ کشف کړي، او هر ماشین د دې وړتیا لري چې په اسانۍ سره تولید زیات کړي x4 ترڅو د هر ډول ناڅاپي پیښو سره مقابله وکړي.
په راتلونکو پوسټونو کې، موږ به د اپاچي سولر کې د فعالیت کمیدو په اړه خپله تجربه شریکه کړو، د پوښتنو اصلاح کولو په اړه بحث وکړو، او بحث وکړو چې څنګه د فدرالي مالیې خدماتو سره کار کول شرکت سره د پیسو خوندي کولو کې مرسته کوي. زموږ بلاګ کې ګډون وکړئ ترڅو تازه پاتې شئ، او که تاسو د زیاتوالي ترافیک پرمهال ورته ستونزو سره مخ شوي یاست نو موږ ته په نظرونو کې خبر راکړئ.
یوازې راجستر شوي کاروونکي کولی شي په سروې کې برخه واخلي. مهرباني وکړئ
آیا تاسو کله هم د ناڅاپي زیاتوالي له امله د خدماتو سستوالی/کمښت تجربه کړی دی چې له امله یې:
۸۵٪د کمپیوټري سرچینو په چټکۍ سره اضافه کولو کې ناتواني ۱۰
۸۵٪د کوربه توب چمتو کونکي زیربنا محدودیتونه 3
۸۵٪د دریمې ډلې API محدودیتونه 6
۸۵٪د دوی د غوښتنلیکونو د بې دولته اصولو سرغړونه 5
۸۵٪د خپلو خدماتو د کوډ غیر غوره والی ۱۶
18 کاروونکو رایه ورکړه. 6 کاروونکي منع شوي.
سرچینه: www.habr.com
