HighLoad++، Evgeniy Kuzovlev (EcommPay IT): څه باید وکړو کله چې د ځنډ وخت یوه دقیقه $ 100000 لګښت ولري

هرڅوک د پراختیا او ازموینې پروسې، د کارمندانو روزنې، هڅونې زیاتولو په اړه خبرې کوي، مګر دا پروسې کافي ندي کله چې د خدماتو د ځنډولو یوه دقیقه ډیره پیسې مصرف کړي. څه باید وکړئ کله چې تاسو د سخت SLA لاندې مالي معاملې ترسره کوئ؟ ستاسو د سیسټمونو اعتبار او غلطی زغم څنګه زیات کړئ، د مساوات څخه بهر پراختیا او ازموینې اخیستل؟

راتلونکی HighLoad++ کنفرانس به د اپریل په 6 او 7، 2020 په سینټ پیټرزبورګ کې ترسره شي. لپاره توضیحات او ټکټونه مخونه. د نومبر 9، 18:00. HighLoad++ مسکو 2018، ډیلي + کلکته تالار. مقالې او پریزنټشن.

Evgeniy Kuzovlev (له دې وروسته - EC): - ملګرو سلام! زما نوم Kuzovlev Evgeniy دی. زه د EcommPay شرکت څخه یم، یوه ځانګړې څانګه EcommPay IT ده، د شرکتونو ګروپ IT څانګه. او نن به موږ د ځنډ وختونو په اړه وغږیږو - د دوی د مخنیوي څرنګوالي په اړه ، د دې په اړه چې څنګه د دوی پایلې کمې کړو که چیرې مخنیوی ونشي. موضوع په لاندې ډول بیان شوې: "څه باید وکړو کله چې د ځنډ وخت یوه دقیقه $ 100 لګښت ولري"؟ مخ ته ګورو، زموږ شمیر د پرتلې وړ دی.

EcommPay IT څه کوي؟

موږ څوک یو؟ زه ولې دلته ستا مخې ته ولاړ یم؟ ولې زه حق لرم چې تاسو ته دلته یو څه ووایم؟ او موږ به دلته په تفصیل سره څه خبرې وکړو؟

د شرکتونو EcommPay ګروپ یو نړیوال اخیستونکی دی. موږ په ټوله نړۍ کې تادیات پروسس کوو - په روسیه، اروپا، سویل ختیځ آسیا کې (په ټوله نړۍ کې). موږ 9 دفترونه لرو، په ټولیز ډول 500 کارمندان، او نږدې نیمایي څخه لږ د معلوماتي ټکنالوجۍ متخصصین دي. هر څه چې کوو، هر څه چې ترې پیسې اخلو، په خپله یې ترسره کړې.

موږ خپل ټول محصولات لیکلي (او موږ یې خورا ډیر لرو - زموږ د لوی IT محصولاتو په لیکه کې موږ شاوخوا 16 مختلف برخې لرو) پخپله؛ موږ خپل ځان لیکو، موږ خپل ځان ته وده ورکوو. او دا مهال موږ په ورځ کې شاوخوا یو ملیون لیږدونه ترسره کوو (میلیونونه شاید د دې ویلو سمه لاره وي). موږ یو کافي ځوان شرکت یو - موږ یوازې شاوخوا شپږ کلن یو.

6 کاله دمخه دا داسې یو پیل و کله چې هلکان د سوداګرۍ سره راغلل. دوی د یوې مفکورې سره متحد شوي وو (د یو نظر پرته بل څه نه وو)، او موږ منډه کړه. د هر ډول پیل په څیر، موږ ګړندی منډه کړه ... زموږ لپاره، سرعت د کیفیت څخه ډیر مهم و.

په یو وخت کې موږ ودرید: موږ پوهیږو چې موږ نور نشو کولی په دې سرعت او د دې کیفیت سره ژوند وکړو او موږ اړتیا لرو لومړی په کیفیت تمرکز وکړو. پدې شیبه کې ، موږ پریکړه وکړه چې یو نوی پلیټ فارم ولیکئ چې سم ، د توزیع وړ او د باور وړ وي. دوی د دې پلیټ فارم په لیکلو پیل وکړ (دوی پانګه اچونه پیل کړه، پراختیا پراختیا، ازموینې)، مګر په ځینو وختونو کې دوی پوهیدلي چې پراختیا او ازموینې موږ ته اجازه نه راکوي چې د خدماتو کیفیت نوي کچې ته ورسیږو.

تاسو یو نوی محصول جوړ کړئ، تاسو یې تولید ته واچوئ، مګر بیا هم یو څه به چیرته غلط شي. او نن به موږ د دې په اړه وغږیږو چې څنګه د کیفیت نوي کچې ته ورسیږو (موږ دا څنګه ترسره کړل، زموږ د تجربې په اړه)، پراختیا او ازموینه د مساوات څخه بهر؛ موږ به د هغه څه په اړه وغږیږو چې د عملیاتو لپاره شتون لري - کوم عملیات پخپله ترسره کولی شي ، دا د کیفیت اغیزه کولو لپاره ازموینې ته څه وړاندیز کولی شي.

ښکته وختونه. د عملیاتو امرونه.

تل اصلي بنسټ، هغه څه چې موږ به یې په حقیقت کې نن ورځ خبرې وکړو د وخت وخت دی. یوه وحشتناکه کلمه. که موږ د ځنډ وخت ولرو، هرڅه زموږ لپاره بد دي. موږ د هغې د پورته کولو لپاره منډې وهو، اډمین سرور په لاس کې لري - خدای دې نه کوي چې رالویږي، لکه څنګه چې دوی په دې سندره کې وايي. دا هغه څه دي چې موږ به یې نن خبرې وکړو.

کله چې موږ خپل چلند بدلولو پیل وکړ، موږ 4 حکمونه جوړ کړل. ما دوی په سلایډونو کې وړاندې کړل:

دا حکمونه خورا ساده دي:

• ژر تر ژره ستونزه وپیژني.
• په چټکۍ سره له دې څخه ځان خلاص کړئ.
• د دلیل په پوهیدو کې مرسته وکړئ (وروسته، د پراختیا کونکو لپاره).
• او معیاري کړنلارې.

زه غواړم ستاسو پام د 2 نمبر ټکي ته راواړوم. موږ ستونزه له منځه یوو، نه حل کوو. پریکړه ثانوي ده. زموږ لپاره، لومړنی شی دا دی چې کاروونکي د دې ستونزې څخه خوندي دي. دا به په یو جلا چاپیریال کې شتون ولري، مګر دا چاپیریال به ورسره هیڅ اړیکه ونلري. په حقیقت کې، موږ به د دې څلورو ګروپونو ستونزو ته لاړ شو (ځینې نور په تفصیل سره، ځینې په لږ تفصیل کې)، زه به تاسو ته ووایم چې موږ څه کاروو، کوم اړونده تجربه چې موږ یې په حل کې لرو.

ستونزې حل کول: دوی کله پیښیږي او د دوی په اړه څه باید وشي؟

مګر موږ به له ترتیب څخه پیل وکړو، موږ به د نمبر 2 سره پیل وکړو - څنګه ژر تر ژره له ستونزې څخه ځان خلاص کړو؟ یوه ستونزه ده - موږ باید دا حل کړو. "موږ باید پدې اړه څه وکړو؟" - اصلي پوښتنه. او کله چې موږ د ستونزې د حل کولو څرنګوالي په اړه فکر پیل کړ، موږ د ځان لپاره ځینې اړتیاوې رامینځته کړې چې د ستونزې حل کول باید تعقیب شي.

د دې اړتیاو د جوړولو لپاره، موږ پریکړه وکړه چې له ځانه پوښتنه وکړو: "کله موږ ستونزې لرو"؟ او ستونزې، لکه څنګه چې معلومه شوه، په څلورو قضیو کې واقع کیږي:

• د هارډویر ناکامي.
• بهرني خدمتونه ناکام شول.
• د سافټویر نسخه بدلول (د ورته ځای پرځای کول).
• د چاودیدونکو توکو وده.

موږ به د لومړي دوه په اړه خبرې ونه کړو. د هارډویر نیمګړتیا په ساده ډول حل کیدی شي: تاسو باید هرڅه نقل کړئ. که دا ډیسکونه وي، ډیسکونه باید په RAID کې راټول شي؛ که دا سرور وي، سرور باید نقل شي؛ که تاسو د شبکې زیربنا لرئ، تاسو باید د شبکې زیربنا دوهمه کاپي چمتو کړئ، دا دی، تاسو یې واخلئ او نقل یې کړئ. او که یو څه ناکام شي، تاسو د بریښنا ذخیره کولو ته لاړ شئ. دلته نور څه ویل ستونزمن دي.

دوهم د بهرنیو خدماتو ناکامي ده. د ډیری لپاره، سیسټم په ټوله کې ستونزه نه ده، مګر زموږ لپاره نه. له هغه وخته چې موږ تادیات پروسس کوو، موږ یو راټولونکی یو چې د کارونکي (څوک چې د هغه کارت ډیټا ننوځي) او بانکونو، د تادیې سیسټمونو (ویزه، ماسټر کارډ، میرا، او نور) ترمنځ ولاړ یو. زموږ بهرني خدمتونه (د تادیاتو سیسټمونه، بانکونه) ناکام دي. نه موږ او نه تاسو (که تاسو داسې خدمتونه لرئ) پدې اغیزه کولی شئ.

بیا څه وکړي؟ دلته دوه اختیارونه شتون لري. لومړی، که تاسو کولی شئ، تاسو باید دا خدمت په یو ډول نقل کړئ. د مثال په توګه، که موږ کولی شو، موږ ټرافيک له یو خدمت څخه بل ته لیږدوو: د بیلګې په توګه، کارتونه د سبربینک له لارې پروسس شوي، سبربینک ستونزې لري - موږ ټرافیک [په مشروط ډول] رایفیسین ته لیږدوو. دوهم شی چې موږ یې کولی شو د بهرني خدماتو ناکامي په چټکۍ سره خبر کړو، او له همدې امله موږ به د راپور په راتلونکې برخه کې د غبرګون سرعت په اړه وغږیږو.

په حقیقت کې، له دې څلورو څخه، موږ کولی شو په ځانګړي ډول د سافټویر نسخو بدلون باندې اغیزه وکړو - داسې اقدامات ترسره کړو چې د ځای په ځای کولو او په بار کې د چاودیدونکي ودې په شرایطو کې د وضعیت د ښه والي لامل شي. په حقیقت کې، دا هغه څه دي چې موږ یې وکړل. دلته یو ځل بیا یو کوچنی یادونه ...

د دې څلورو ستونزو څخه، ډیری یې سمدلاسه حل کیږي که تاسو بادل ولرئ. که تاسو د مایکروسافټ ازور ، اوزون بادل کې یاست ، یا زموږ بادلونه د Yandex یا میل څخه کاروئ ، نو لږترلږه د هارډویر خرابوالی د دوی ستونزه کیږي او هرڅه سمدلاسه ستاسو لپاره د هارډویر خرابوالي په شرایطو کې سم کیږي.

موږ یو څه غیر دودیز شرکت یو. دلته هرڅوک د "Kubernets" په اړه خبرې کوي، د ورېځو په اړه - موږ نه "Kubernets" لرو او نه وريځې. مګر موږ په ډیری ډیټا مرکزونو کې د هارډویر ریکونه لرو ، او موږ مجبور یو چې په دې هارډویر کې ژوند وکړو ، موږ مجبور یو چې د دې ټولو مسؤلیت ولرو. له همدې کبله، موږ به په دې برخه کې خبرې وکړو. نو، د ستونزو په اړه. لومړی دوه د قوسونو څخه ایستل شوي.

د سافټویر نسخه بدلول. اډې

زموږ پراختیا کونکي تولید ته لاسرسی نلري. ولې دغه دی؟ دا یوازې دا دی چې موږ د PCI DSS تصدیق شوي یو، او زموږ پراختیا کونکي په ساده ډول د "محصول" ته د رسیدو حق نلري. دا دی، دوره. هیڅکله. له همدې امله، د پراختیا مسؤلیت په عین وخت کې پای ته رسیږي کله چې پراختیا د خوشې کولو لپاره جوړونه وړاندې کوي.

زموږ دوهم اساس چې موږ یې لرو، کوم چې زموږ سره ډیره مرسته کوي، د ځانګړي غیر مستند پوهې نشتوالی دی. زه هیله لرم چې دا ستاسو لپاره ورته وي. ځکه چې که داسې نه وي، تاسو به ستونزې ولرئ. ستونزې به رامینځته شي کله چې دا بې ساري ، بې سنده پوهه په سم وخت کې په سم ځای کې شتون ونلري. راځئ چې ووایو تاسو یو څوک لرئ چې پوهیږي چې څنګه یو ځانګړي برخې ځای په ځای کړي - هغه سړی شتون نلري ، هغه په ​​رخصتۍ یا ناروغ دی - دا دی ، تاسو ستونزې لرئ.

او دریم اساس چې موږ ته راغلي یو. موږ دې ته د درد، وینې، اوښکو له لارې راغلي یو - موږ دې پایلې ته ورسیدو چې زموږ په جوړښت کې هر ډول غلطی شتون لري، حتی که دا له خطا پاک وي. موږ دا د ځان لپاره پریکړه وکړه: کله چې موږ یو څه ځای په ځای کوو، کله چې موږ یو څه تولید ته واړوو، موږ د غلطیو سره جوړ یو. موږ هغه اړتیاوې جوړې کړې چې زموږ سیسټم باید پوره کړي.

د سافټویر نسخه بدلولو لپاره اړتیاوې

درې اړتیاوې شتون لري:

• موږ باید ژر تر ژره د ګمارنې مخه ونیسو.
• موږ باید د ناکامې ګمارنې اغیزې کمې کړو.
• او موږ باید وړتیا ولرو چې ژر تر ژره موازي ځای په ځای کړو.
  بالکل په همدې ترتیب! ولې؟ ځکه، لومړی، کله چې نوې نسخه ځای پرځای کول، سرعت مهم نه دی، مګر دا ستاسو لپاره مهم دی، که چیرې یو څه غلط شي، په چټکۍ سره بیرته راګرځول او لږترلږه اغیزه ولري. مګر که تاسو په تولید کې د نسخو سیټ لرئ، د کوم لپاره چې دا معلومه شوه چې یوه تېروتنه شتون لري (له نیلي څخه بهر، هیڅ ځای پرځای کول شتون نلري، مګر یوه تېروتنه شتون لري) - د راتلونکي ګمارلو سرعت ستاسو لپاره مهم دی. د دغو غوښتنو د پوره کولو لپاره مو څه کړي دي؟ موږ لاندې میتودولوژي ته لاره هواره کړه:

  
  
  دا خورا ښه پیژندل شوی، موږ هیڅکله دا اختراع نه ده کړې - دا نیلي / شنه ځای پرځای کول دي. دا څه شی دی؟ تاسو باید د سرورونو د هرې ډلې لپاره یوه کاپي ولرئ په کوم کې چې ستاسو غوښتنلیکونه نصب شوي. کاپي "ګرم" ده: پدې کې هیڅ ترافیک شتون نلري ، مګر په هر وخت کې دا ترافیک دې کاپي ته لیږل کیدی شي. دا کاپي پخوانۍ نسخه لري. او د ګمارلو په وخت کې، تاسو کوډ غیر فعاله کاپي ته واړوئ. بیا تاسو د ټرافیک یوه برخه (یا ټول) نوي نسخه ته واړوئ. پدې توګه ، د زاړه نسخې څخه نوي ته د ترافیک جریان بدلولو لپاره ، تاسو اړتیا لرئ یوازې یو عمل ترسره کړئ: تاسو اړتیا لرئ په پورته جریان کې بیلانس بدل کړئ ، سمت بدل کړئ - له یو پورته څخه بل ته. دا خورا اسانه دی او د ګړندي سویچ کولو او ګړندي رول بیک ستونزه حل کوي.

  دلته د دویمې پوښتنې حل کمول دي: تاسو کولی شئ د خپل ټرافیک یوازې یوه برخه نوي لیکې ته واستوئ، د نوي کوډ سره کرښه ته (دا پریږدئ، د بیلګې په توګه، 2٪). او دا 2٪ 100٪ نه دي! که تاسو د ناکامې ګمارنې له امله خپل 100٪ ترافیک له لاسه ورکړی، دا ویره ده؛ که تاسو د خپل ټرافیک 2٪ له لاسه ورکړی، دا ناخوښ دی، مګر دا ویره نلري. سربیره پردې ، کارونکي به ډیری احتمال حتی دې ته پام ونه کړي ، ځکه چې په ځینو حاالتو کې (په ټولو کې نه) ورته کارونکي ، د F5 فشارولو سره به بلې ، کاري نسخې ته وړل کیږي.

  نیلي / شین ځای پرځای کول. روټینګ

  په هرصورت، هرڅه دومره ساده ندي "نیلي / شنه ځای پرځای کول" ... زموږ ټولې برخې په دریو ډلو ویشل کیدی شي:

  • دا مخکنی پای دی (د تادیاتو پاڼې چې زموږ پیرودونکي یې ګوري)؛
  • د پروسس کور؛
  • د تادیې سیسټمونو سره کار کولو لپاره اډاپټر (بانکونه، ماسټر کارډ، ویزه ...).

  او دلته یو نزاکت شتون لري - نزاکت د لینونو ترمینځ په لاره کې پروت دی. که تاسو یوازې د ټرافیک 100٪ بدل کړئ، تاسو دا ستونزې نلرئ. مګر که تاسو غواړئ 2٪ بدل کړئ، تاسو پوښتنې پیل کړئ: "دا څنګه وکړو؟" ترټولو ساده شی مستقیم مخ ته دی: تاسو کولی شئ په تصادفي انتخاب سره په نګینکس کې رانډ رابین تنظیم کړئ ، او تاسو 2٪ کیڼ اړخ ته ، 98٪ ښیې ته لرئ. مګر دا تل مناسب نه دی.

  د مثال په توګه، زموږ په قضیه کې، یو کاروونکي د سیسټم سره د ډیرو غوښتنو سره اړیکه لري. دا نورمال دی: 2، 3، 4، 5 غوښتنې - ستاسو سیسټمونه ممکن ورته وي. او که دا ستاسو لپاره مهم وي چې د کارونکي ټولې غوښتنې ورته کرښه ته راځي چې لومړۍ غوښتنه یې کړې وه، یا (دوهم ټکي) د کارونکي ټولې غوښتنې د سویچ وروسته نوي کرښې ته راځي (هغه کولی شي دمخه کار پیل کړي. سیسټم، د سویچ څخه مخکې) - بیا دا تصادفي ویش ستاسو لپاره مناسب نه دی. بیا لاندې اختیارونه شتون لري:

  
  
  لومړی اختیار، ترټولو ساده، د پیرودونکي (IP Hash) د بنسټیزو پیرامیټونو پر بنسټ والړ دی. تاسو یو IP لرئ، او تاسو یې د IP پتې له مخې له ښیې څخه کیڼ اړخ ته ویشئ. بیا دوهم قضیه چې ما تشریح کړې به ستاسو لپاره کار وکړي ، کله چې ګمارل کیږي ، کارونکي کولی شي دمخه ستاسو د سیسټم سره کار پیل کړي ، او د پلي کیدو له شیبې څخه به ټولې غوښتنې نوې کرښې ته لاړ شي (ورته ورته ووایه).

  که د کوم دلیل لپاره دا ستاسو سره مناسب نه وي او تاسو باید هغه کرښې ته غوښتنې واستوئ چیرې چې د کارونکي لومړنۍ ، لومړنۍ غوښتنه راغلې وه ، نو تاسو دوه اختیارونه لرئ ...
  لومړی اختیار: تاسو کولی شئ تادیه شوي nginx + وپیرئ. د سټیکي سیشن میکانیزم شتون لري ، کوم چې د کارونکي لومړنۍ غوښتنې سره سم کارونکي ته سیشن ګماري او دا په یو یا بل اپ سټریم پورې تړلي. د ناستې د ژوند په اوږدو کې د کارونکي ټولې راتلونکي غوښتنې به ورته اپ سټریم ته واستول شي چیرې چې ناسته ځړول شوې وه.

  دا موږ ته مناسب نه و ځکه چې موږ دمخه منظم نګینکس درلود. نګینکس + ته بدلول دا ندي چې دا ګران دي ، دا یوازې دا دي چې دا زموږ لپاره یو څه دردناک و او خورا سم نه و. د مثال په توګه، "سټیکس سیشنونه" زموږ لپاره د ساده دلیل لپاره کار نه کوي چې "سټیکس سیشنونه" د "یا یا یا" پر بنسټ روټینګ ته اجازه نه ورکوي. هلته تاسو کولی شئ مشخص کړئ چې موږ "سټیکس سیشن" څه کوو، د بیلګې په توګه، د IP پتې یا IP پتې او کوکیز یا د پوسټ پیرامیټر په واسطه، مګر "یا یا" هلته ډیر پیچلي دي.

  له همدې امله، موږ څلورم انتخاب ته راغلو. موږ نګینکس په سټرایډونو اخیستی (دا خلاص دی) - دا ورته نګینکس دی ، کوم چې سربیره پردې د وروستي سکریپټونو شاملولو ملاتړ کوي. تاسو کولی شئ وروستی سکریپټ ولیکئ، دا "خلاص آرام" ورکړئ، او دا وروستی سکریپټ به اجرا شي کله چې د کاروونکي غوښتنه راشي.

  او موږ په حقیقت کې دا ډول سکریپټ لیکلی و، خپل ځان ته "openresti" ټاکلی او په دې سکریپټ کې موږ د "یا" په واسطه د 6 مختلف پیرامیټونو له لارې ترتیب کوو. د یو یا بل پیرامیټر شتون پورې اړه لري، موږ پوهیږو چې کارن یو مخ یا بل، یو کرښه یا بل ته راغلی.

  نیلي / شین ځای پرځای کول. ګټې او زیانونه

  البته، دا شاید ممکنه وه چې دا یو څه ساده کړئ (د ورته "چپکې ناستې" څخه کار واخلئ)، مګر موږ داسې یو اړخ هم لرو چې نه یوازې کاروونکي زموږ سره د یوې معاملې د پروسس کولو په چوکاټ کې اړیکه نیسي ... مګر د تادیې سیسټمونه هم زموږ سره اړیکه لري: وروسته له دې چې موږ معامله پروسس کوو (د تادیې سیسټم ته د غوښتنې لیږلو سره) ، موږ کول بیک ترلاسه کوو.
  او راځئ چې ووایو ، که زموږ په سرکټ کې دننه موږ کولی شو د کارونکي IP پته په ټولو غوښتنو کې وړاندې کړو او د IP پتې پراساس کارونکي تقسیم کړو ، نو موږ به ورته "ویزا" ونه وایو: "یار ، موږ داسې یو ریټرو شرکت یو ، موږ داسې ښکاري. د نړیوال کیدو لپاره (په ویب پاڼه او روسیه کې)... مهرباني وکړئ موږ ته په اضافي ساحه کې د کارونکي IP پته راکړئ، ستاسو پروتوکول معیاري دی"! دا څرګنده ده چې دوی به موافق نه وي.

  
  
  له همدې امله، دا زموږ لپاره کار نه دی کړی - موږ خلاص کار وکړ. په دې اساس، د روټینګ سره موږ داسې یو څه ترلاسه کړل:

  نیلي / شین ځای په ځای کول هغه ګټې لري چې ما یې یادونه وکړه او زیانونه یې.

  دوه زیانونه:

  • تاسو اړتیا لرئ د روټینګ سره زحمت وکړئ؛
  • دوهم اصلي زیان لګښت دی.

  تاسو دوه چنده ډیری سرورونو ته اړتیا لرئ، تاسو دوه چنده ډیری عملیاتي سرچینو ته اړتیا لرئ، تاسو اړتیا لرئ چې د دې ټول ژوبڼ ساتلو لپاره دوه چنده ډیرې هڅې مصرف کړئ.

  په هرصورت ، د ګټو په مینځ کې یو بل شی شتون لري چې ما مخکې نه دی یادونه کړې: تاسو د بار ودې په صورت کې زیرمه لرئ. که تاسو په بار کې چاودیدونکي وده لرئ، تاسو د کاروونکو لوی شمیر لرئ، نو تاسو په ساده ډول د 50 څخه تر 50 ویشلو کې دویمه کرښه شامل کړئ - او تاسو سمدلاسه په خپل کلستر کې x2 سرورونه لرئ تر هغه چې تاسو د ډیرو سرورونو ستونزه حل نه کړئ.

  څنګه چټک ځای پرځای کول؟

  موږ د کمولو او ګړندي رول بیک ستونزې حل کولو څرنګوالي په اړه خبرې وکړې ، مګر پوښتنه پاتې ده: "څنګه ګړندي ځای په ځای کول؟"

  
  
  دلته لنډ او ساده دی.

  • تاسو باید د CD سیسټم ولرئ (دوامداره تحویلي) - تاسو پرته له دې ژوند نشئ کولی. که تاسو یو سرور لرئ، تاسو کولی شئ په لاسي ډول ځای په ځای کړئ. موږ شاوخوا یو نیم زره سرورونه او یو نیم زره لاسي لرو، البته - موږ کولی شو یوازې د ځای په ځای کولو لپاره د دې خونې اندازه یو څانګه جوړه کړو.
  • ګمارنه باید موازي وي. که ستاسو ګمارنه په ترتیب سره وي، نو هرڅه خراب دي. یو سرور نورمال دی ، تاسو به ټوله ورځ یو نیم زره سرورونه ځای په ځای کړئ.
  • بیا بیا، د سرعت لپاره، دا شاید نور اړین نه وي. د ګمارنې په جریان کې، پروژه معمولا جوړه شوې ده. تاسو یوه ویب پروژه لرئ، د مخکینۍ پای برخه شتون لري (تاسو هلته ویب بسته کوئ، تاسو npm ترتیب کړئ - داسې یو څه)، او دا پروسه، په اصل کې، لنډمهاله ده - 5 دقیقې، مګر دا 5 دقیقې کولی شي. انتقادي اوسئ له همدې امله، د مثال په توګه، موږ دا نه کوو: موږ دا 5 دقیقې لیرې کړې، موږ اثار ځای په ځای کوو.

    اثار څه شی دی؟ یو هنري اثار یو راټول شوی جوړښت دی چې د مجلس ټولې برخې لا دمخه بشپړې شوې وي. موږ دا اثار د هنري اثارو په ذخیره کې ساتو. په یو وخت کې موږ دوه دا ډول ذخیرې کارولې - دا Nexus او اوس jFrog هنري فابریکه وه. موږ په پیل کې "Nexus" کاروو ځکه چې موږ دا طریقه په جاوا غوښتنلیکونو کې عملي کول پیل کړل (دا ښه مناسبه وه). بیا دوی په پی ایچ پی کې لیکل شوي ځینې غوښتنلیکونه هلته کېښودل؛ او "Nexus" نور مناسب نه و، او له همدې امله موږ د jFrog Artfactory غوره کړه، کوم چې کولی شي نږدې هرڅه هنري کړي. موږ حتی دې ټکي ته رسیدلي یو چې پدې هنري ذخیره کې موږ خپل بائنری کڅوړې ذخیره کوو چې موږ یې د سرورونو لپاره راټولوو.

  د چاودیدونکو توکو وده

  موږ د سافټویر نسخه بدلولو په اړه خبرې وکړې. بل شی چې موږ یې لرو په بار کې چاودیدونکي زیاتوالی دی. دلته، زما مطلب شاید د بار د چاودیدونکي ودې څخه وي چې سم شی نه دی ...

  موږ یو نوی سیسټم لیکلی - دا د خدمت پر بنسټ، فیشن، ښکلی، کارګران هر ځای، هر ځای کتارونه، هرچیرې غیر متناسب. او په داسې سیسټمونو کې، ډاټا کولی شي د مختلفو جریانونو له لارې تیریږي. د لومړۍ معاملې لپاره، د لومړۍ، دریمې، لسمې کارکونکي کارول کیدی شي، د دویمې معاملې لپاره - دوهم، څلورم، پنځم. او نن ورځ ، راځئ چې ووایو ، په سهار کې تاسو د معلوماتو جریان لرئ چې لومړی درې کارګران کاروي ، او په ماښام کې دا په ډراماتیک ډول بدلیږي ، او هرڅه نور درې کارګران کاروي.

  او دلته دا په ګوته کیږي چې تاسو اړتیا لرئ په یو ډول کارګران اندازه کړئ ، تاسو اړتیا لرئ په یو ډول خپل خدمات اندازه کړئ ، مګر په ورته وخت کې د سرچینو د غوړیدو مخه ونیسئ.

  
  
  موږ خپلې اړتیاوې تعریف کړې. دا اړتیاوې خورا ساده دي: د خدماتو کشف، پیرامیټریزیشن - هرڅه د داسې پیمانه وړ سیسټمونو جوړولو لپاره معیاري دي، پرته له یوې نقطې - د سرچینو ضایع کول. موږ وویل چې موږ چمتو نه یو چې سرچینې کمې کړو ترڅو سرورونه هوا تودوخه کړي. موږ "قونسل" واخیست، موږ "کوماد" واخیست چې زموږ کارګران اداره کوي.

  ولې دا زموږ لپاره ستونزه ده؟ راځئ چې لږ شاته شو. موږ اوس شاوخوا 70 د تادیې سیسټمونه لرو. په سهار کې، ترافیک د سبربینک له لارې تیریږي، بیا سبربینک راټیټ شو، د بیلګې په توګه، او موږ یې د تادیې بل سیسټم ته واړوو. موږ د سبربینک څخه دمخه 100 کارګران درلودل، او له هغه وروسته موږ اړتیا لرو چې د بل تادیاتو سیسټم لپاره 100 کارګران په چټکۍ سره زیات کړو. او دا د ټولو لپاره د منلو وړ ده چې د انسان له ګډون پرته ترسره شي. ځکه چې که چیرې د انسان ګډون شتون ولري، هلته باید یو انجینر 24/7 ناست وي، څوک باید یوازې دا کار وکړي، ځکه چې دا ډول ناکامۍ، کله چې 70 سیسټمونه ستاسو تر شا وي، په منظمه توګه پیښیږي.

  له همدې امله، موږ نوماد ته وکتل، کوم چې یو خلاص IP لري، او خپل شی یې لیکلی، Scale-Nomad - ScaleNo، کوم چې نږدې لاندې کار کوي: دا د قطار وده څاري او د متحرکاتو پر بنسټ د کارمندانو شمیر کموي یا زیاتوي. د کتار څخه کله چې موږ دا وکړل، موږ فکر وکړ: "شاید موږ کولی شو سرچینه خلاص کړو؟" بیا دوی هغې ته وکتل - هغه د دوه کوپیکونو په څیر ساده وه.

  تر دې دمه موږ خلاص سرچینه نه ده اخیستې ، مګر که ناڅاپه د راپور وروسته ، وروسته له دې چې پوه شو چې تاسو ورته اړتیا لرئ ، تاسو ورته اړتیا لرئ ، زما اړیکې په وروستي سلایډ کې دي - مهرباني وکړئ ما ته ولیکئ. که لږترلږه 3-5 کسان وي، موږ به یې سپانسر کړو.

  
  
  څنګه کار کوي؟ راځئ چې یو نظر ترلاسه کړو! مخ ته کتل: په ښي خوا کې زموږ د څارنې یوه برخه ده: دا یوه کرښه ده، په پورتنۍ برخه کې د پیښې پروسس کولو وخت دی، په مینځ کې د معاملو شمیر دی، په ښکته کې د کارمندانو شمیر دی.

  که تاسو وګورئ، په دې انځور کې یو خنډ شتون لري. په پورتنۍ چارټ کې، یو چارټ په 45 ثانیو کې راښکته شو - یو د تادیې سیسټم ښکته شو. سمدلاسه ، ترافیک په 2 دقیقو کې راوړل شو او کتار د تادیې په بل سیسټم کې وده پیل کړه ، چیرې چې کارګران شتون نلري (موږ سرچینې نه دي کارولې - برعکس ، موږ سرچینې په سمه توګه ضایع کړې). موږ نه غوښتل چې تودوخه وکړو - لږترلږه شمیره وه، شاوخوا 5-10 کارګران، مګر دوی نشو کولی.

  وروستی ګراف یو "همپ" ښیي، چې یوازې دا معنی لري چې "سکلینو" دا اندازه دوه برابره کړې. او بیا، کله چې ګراف یو څه راټیټ شو، هغه یو څه کم کړ - د کارګرانو شمیر په اوتومات ډول بدل شو. دا څنګه کار کوي. موږ د ټکي نمبر 2 په اړه خبرې وکړې - "څنګه ژر له دلیلونو څخه ځان خلاص کړو."

  څارنه. څنګه ژر تر ژره ستونزه وپیژنو؟

  اوس لومړی ټکی دا دی چې "څنګه ژر ستونزه وپیژنو؟" څارنه! موږ باید په ځینو شیانو ژر پوه شو. کوم شیان باید ژر پوه شو؟

  
  
  درې شیان!

  • موږ باید ژر تر ژره د خپلو سرچینو په فعالیت پوه او پوه شو.
  • موږ باید ژر تر ژره په ناکامیو پوه شو او د سیسټمونو فعالیت وڅیړو چې زموږ لپاره بهرني دي.
  • دریم ټکی د منطقي غلطیو پیژندل دي. دا هغه وخت دی چې سیسټم ستاسو لپاره کار کوي، هرڅه د ټولو شاخصونو سره سم عادي دي، مګر یو څه غلط کیږي.

  زه شاید تاسو ته دلته هیڅ ښه نه وایم. زه به کیپتان اوبیا یم. موږ په بازار کې د هغه څه په لټه کې یو. موږ یو "د ساتیرۍ ژوبڼ" لرو. دا هغه ډول ژوبڼ دی چې موږ یې اوس لرو:

  
  
  موږ د هارډویر څارلو لپاره زبیبکس کاروو، د سرورونو اصلي شاخصونو نظارت کولو لپاره. موږ د ډیټابیس لپاره Okmeter کاروو. موږ د نورو ټولو شاخصونو لپاره "Grafana" او "Prometheus" کاروو چې په لومړیو دوو کې مناسب نه دي، ځینې یې د "Grafana" او "Prometheus" سره، او ځینې یې د "Grafana" سره د "Influx" او Telegraf سره.

  یو کال دمخه موږ غوښتل نوي ریلیک وکاروو. ښه شی، دا هرڅه کولی شي. خو څومره چې هغه هر څه کولای شي، هومره ګرانه ده. کله چې موږ د 1,5 زرو سرورونو حجم ته وده ورکړه، یو پلورونکی موږ ته راغی او ویې ویل: "راځئ چې د راتلونکي کال لپاره یو تړون پای ته ورسوو." موږ نرخ ته وکتل او ویې ویل چې نه، موږ به دا کار ونه کړو. اوس موږ نوی ریلیک پریږدو، موږ د نوي ریلیک تر څارنې لاندې شاوخوا 15 سرورونه لرو. نرخ په بشپړ ډول وحشي وګرځید.

  او دلته یو وسیله شتون لري چې موږ پخپله پلي کوو - دا ډیبګر دی. په لومړي سر کې موږ ورته "بیګر" وویل، مګر بیا د انګلیسي ښوونکي له خوا تیر شو، په وحشي توګه یې وخندل، او د "ډیباګر" نوم یې بدل کړ. دا څه شی دی؟ دا یوه وسیله ده چې په حقیقت کې، په هره برخه کې په 15-30 ثانیو کې، د سیسټم د "تور بکس" په څیر، د برخې په عمومي فعالیت باندې ازموینې ترسره کوي.

  د مثال په توګه، که چیرې بهرنۍ پاڼه (د تادیاتو پاڼه) وي، هغه په ​​ساده ډول دا خلاصوي او ګوري چې دا باید څنګه ښکاري. که دا پروسس کوي، هغه یو ازموینه "معامله" لیږي او ډاډ ترلاسه کوي چې دا "معامله" راځي. که دا د تادیې سیسټمونو سره اړیکه وي، موږ د هغې مطابق د ازموینې غوښتنه کوو، چیرته چې موږ کولی شو، او وګورو چې هرڅه زموږ سره سم دي.

  کوم شاخصونه د څارنې لپاره مهم دي؟

  موږ په عمده توګه څه څارنه کوو؟ کوم شاخصونه زموږ لپاره مهم دي؟

  
  

  • په محاذونو کې د غبرګون وخت / RPS یو خورا مهم شاخص دی. هغه سمدستي ځواب ورکوي چې ستاسو سره یو څه غلط دی.
  • په ټولو کتارونو کې د پروسس شوي پیغامونو شمیر.
  • د کارکونکو شمیر.
  • د سموالي اساسي میترونه.

  وروستی ټکی د "سوداګرۍ"، "سوداګرۍ" میټریک دی. که تاسو غواړئ ورته شی وڅارئ، تاسو اړتیا لرئ یو یا دوه میټریکونه تعریف کړئ چې ستاسو لپاره اصلي شاخصونه دي. زموږ میټریک له لارې پټ دی (دا د ټولو لیږد جریان ته د بریالي لیږدونو شمیر تناسب دی). که چیرې یو څه د 5-10-15 دقیقو په وقفه کې بدلون ومومي، دا پدې مانا ده چې موږ ستونزې لرو (که دا په بنسټیز ډول بدلون ومومي).

  هغه څه چې زموږ لپاره ورته ښکاري زموږ د بورډونو څخه یوه بیلګه ده:

  
  
  په ښي خوا کې 6 ګرافونه شتون لري، دا د لینونو سره سم دي - د کارمندانو شمیر او په کتارونو کې د پیغامونو شمیر. په ښي خوا کې - RPS، RTS. لاندې ورته "سوداګرۍ" میټریک دی. او په "سوداګرۍ" میټریک کې موږ سمدلاسه لیدلی شو چې په دوه مینځني ګرافونو کې یو څه غلط شوي ... دا یوازې یو بل سیسټم دی چې زموږ تر شا ولاړ دی چې سقوط شوی.

  دوهم شی چې موږ یې باید ترسره کړو د بهرنیو تادیاتو سیسټمونو د سقوط څارنه وه. دلته موږ OpenTracing واخیست - یو میکانیزم، معیاري، تمثیل چې تاسو ته اجازه درکوي ویشل شوي سیسټمونه تعقیب کړئ؛ او دا یو څه بدل شو. معیاري OpenTracing تمثیل وايي چې موږ د هرې انفرادي غوښتنې لپاره ټریس جوړوو. موږ دې ته اړتیا نه درلوده، او موږ یې په لنډیز، د راټولولو ټریس کې وتړلو. موږ یوه وسیله جوړه کړې چې موږ ته اجازه راکوي چې زموږ تر شا د سیسټمونو سرعت تعقیب کړو.

  
  
  ګراف موږ ته ښیې چې د تادیې سیسټمونو څخه یو په 3 ثانیو کې ځواب ویل پیل کړل - موږ ستونزې لرو. سربیره پردې ، دا شی به عکس العمل څرګند کړي کله چې ستونزې پیل شي ، د 20-30 ثانیو په وقفه کې.

  او د څارنې د تېروتنې دریمه طبقه چې شتون لري منطقي څارنه ده.

  د ریښتیني کیدو لپاره ، زه نه پوهیدم چې پدې سلایډ کې څه راښکاره کړم ، ځکه چې موږ له ډیرې مودې راهیسې په بازار کې د هغه څه په لټه کې یو چې زموږ سره مناسب وي. موږ هیڅ ونه موندل، نو موږ باید دا پخپله وکړو.

  
  
  زه د منطقي څارنې څخه څه معنی لرم؟ ښه، تصور وکړئ: تاسو خپل ځان یو سیسټم جوړ کړئ (د مثال په توګه، د ټینډر کلون)؛ تاسو یې جوړ کړی، پیل یې کړی. بریالي مدیر واسیا پوپکن دا په خپل تلیفون کې واچاوه، هلته یوه نجلۍ ګوري، هغه یې خوښوي ... او ورته ورته نجلۍ ته نه ځي - د ورته سوداګریز مرکز څخه امنیتي ساتونکي میخالیچ ته ځي. مدیر ښکته ځي او بیا په حیرانتیا سره وايي: "ولې دا امنیتي ساتونکی میخالیچ ورته په زړه پورې مسکا کوي؟"

  په داسې شرایطو کې ... زموږ لپاره، دا وضعیت یو څه توپیر لري، ځکه چې (ما لیکلي) دا د شهرت زیان دی چې په غیر مستقیم ډول د مالي زیان لامل کیږي. زموږ وضعیت برعکس دی: موږ ممکن مستقیم مالي زیان سره مخ شو - د بیلګې په توګه، که موږ د بریالیتوب په توګه معامله ترسره کړه، مګر دا ناکامه وه (یا برعکس). زه باید خپل وسیله ولیکم چې د سوداګرۍ شاخصونو په کارولو سره د وخت په تیریدو سره د بریالي لیږدونو شمیر تعقیب کړي. په بازار کې مو څه ونه موندل! دا دقیقا هغه نظر دی چې ما غوښتل بیان کړم. په بازار کې د دې ډول ستونزې حل کولو لپاره هیڅ شی شتون نلري.

  دا د دې په اړه و چې څنګه ژر تر ژره ستونزه وپیژني.

  څنګه د ځای پرځای کولو لاملونه وټاکئ

  د ستونزو دریمه ډله چې موږ یې حل کوو دا ده چې موږ د ستونزې پیژندلو وروسته، وروسته له هغې چې موږ یې له منځه یوسو، نو دا به ښه وي چې د پرمختګ لامل وپیژندل شي، د ازموینې لپاره، او په اړه یې یو څه وکړي. په دې اساس، موږ باید پلټنه وکړو، موږ د لوګو پورته کولو ته اړتیا لرو.

  
  
  که موږ د لاګونو په اړه وغږیږو (اصلي دلیل لاګونه دي)، زموږ د لاګونو لویه برخه په ELK سټیک کې دي - نږدې هرڅوک ورته لري. د ځینو لپاره، دا ممکن په ELK کې نه وي، مګر که تاسو په ګیګابایټ کې لاګونه ولیکئ، نو ژر یا وروسته به تاسو ELK ته راشئ. موږ یې په ټیرابایټ کې لیکو.

  
  
  دلته یوه ستونزه ده. موږ یې حل کړ، د کارونکي لپاره یې تېروتنه سمه کړه، د هغه څه په کیندلو یې پیل وکړ چې هلته وو، کبانا ته ورسېدو، هلته د راکړې ورکړې ID ته ننوت او د دې په څیر یو فوټ کلاټ مو ترلاسه کړ (ډیر ښیې). او په دې جامو کې بالکل هیڅ شی روښانه ندي. ولې؟ هو، ځکه چې دا څرګنده نه ده چې کومه برخه د کوم کارګر پورې اړه لري، کومه برخه د کومې برخې پورې اړه لري. او په دې شیبه کې موږ پوه شو چې موږ تعقیب ته اړتیا لرو - ورته OpenTracing چې ما یې په اړه خبرې وکړې.

  موږ یو کال دمخه دا فکر وکړ، بازار ته مو پام واړوه، او هلته دوه وسیلې شتون درلود - "زیپکن" او "جیجر". "جاجر" په حقیقت کې دا ډول ایډیالوژیکي وارث دی، د "زیپکن" ایډیالوژیکي جانشین. په زپکین کې هرڅه ښه دي، پرته له دې چې دا نه پوهیږي چې څنګه راټول شي، دا نه پوهیږي چې څنګه په ټریس کې لوګو شامل کړي، یوازې د وخت ټریس. او "جاجر" د دې ملاتړ وکړ.

  موږ "جاجر" ته وکتل: تاسو غوښتنلیکونه وسیله کولی شئ، تاسو کولی شئ په Api کې ولیکئ (په هغه وخت کې د PHP لپاره د Api معیار، که څه هم، تصویب شوی نه و - دا یو کال دمخه و، مګر اوس دا لا دمخه تصویب شوی)، مګر هلته په بشپړه توګه هیڅ پیرودونکي نه وو. "ښه،" موږ فکر وکړ، او خپل پیرودونکي یې لیکلي. موږ څه ترلاسه کړل؟ دا تقریبا هغه څه دي چې داسې ښکاري:

  
  
  په جیجر کې، د هر پیغام لپاره سپینونه جوړ شوي. دا دی، کله چې یو کاروونکي سیسټم پرانیزي، هغه د هرې راتلونکې غوښتنې لپاره یو یا دوه بلاکونه ګوري (1-2-3 - د کارونکي څخه د راتلونکو غوښتنو شمیر، د بلاکونو شمیر). د کاروونکو لپاره د اسانه کولو لپاره، موږ په لاګونو او وختونو کې ټګونه اضافه کړل. په دې اساس، د یوې تېروتنې په صورت کې، زموږ غوښتنلیک به د مناسبې تېروتنې ټګ سره نښه نښه کړي. تاسو کولی شئ د تېروتنې ټګ لخوا فلټر کړئ او یوازې هغه سپانونه چې دا بلاک لري د خطا سره به ښودل شي. دا هغه څه دي چې داسې ښکاري که موږ دوره پراخه کړو:

  
  
  د دورې دننه د نښو سیټ شتون لري. پدې حالت کې، دا د ازموینې درې نښې دي، او دریم ټریس موږ ته وایي چې یوه تېروتنه رامنځته شوې. په ورته وخت کې، دلته موږ د وخت نښه وینو: موږ په سر کې د وخت پیمانه لرو، او موږ ګورو چې په کوم وخت کې دا یا هغه لاګ ثبت شوی.

  په دې اساس، شیان زموږ لپاره ښه روان وو. موږ خپل توسیع لیکلی او موږ یې خلاص کړی. که تاسو غواړئ د ټریسینګ سره کار وکړئ ، که تاسو غواړئ په PHP کې د "جاجر" سره کار وکړئ ، زموږ توسیع شتون لري ، کارولو ته ښه راغلاست ، لکه څنګه چې دوی وايي:

  
  
  موږ دا توسیع لرو - دا د OpenTracing Api لپاره پیرودونکی دی، دا د php-extention په توګه جوړ شوی، دا دی، تاسو اړتیا لرئ چې دا راټول کړئ او په سیسټم کې یې نصب کړئ. یو کال دمخه هیڅ توپیر نه درلود. اوس نور پیرودونکي شتون لري چې د اجزاوو په څیر دي. دلته دا په تاسو پورې اړه لري: یا تاسو د کمپوزر سره اجزا پمپ کړئ ، یا تاسو تر تاسو پورې توسیع وکاروئ.

  د کارپوریټ معیارونه

  موږ د دریو حکمونو په اړه خبرې وکړې. څلورم حکم د تګلارو معیاري کول دي. دا د څه په اړه ده؟ دا پدې اړه ده:

  
  
  ولې دلته د "کارپوریټ" کلمه ده؟ نه دا چې موږ لوی یا بیوروکراټیک شرکت یو، نه! ما غوښتل دلته د "کارپوریټ" کلمه په دې شرایطو کې وکاروم چې هر شرکت، هر محصول باید خپل معیارونه ولري، ستاسو په ګډون. موږ کوم معیارونه لرو؟

  
  

  • موږ د ګمارنې مقررات لرو. موږ د هغه پرته هیڅ ځای نه حرکت کوو، موږ نشو کولی. موږ په اونۍ کې شاوخوا 60 ځله ځای په ځای کوو ، دا دی ، موږ نږدې په دوامداره توګه ځای په ځای کوو. په ورته وخت کې، موږ لرو، د بیلګې په توګه، د ګمارنې په مقرراتو کې د جمعې په ورځ د ګمارنې په اړه ممنوع - په اصولو کې، موږ نه ګمارو.
  • موږ اسنادو ته اړتیا لرو. هیڅ یوه نوې برخه تولید ته نه راځي که چیرې د دې لپاره اسناد شتون نلري، حتی که دا زموږ د RnD متخصصینو قلم لاندې زیږیدلی وي. موږ له دوی څخه د ګمارنې لارښوونې، د څارنې نقشه او یو دقیق توضیح (ښه، لکه څنګه چې پروګرام کونکي لیکلی شي) ته اړتیا لرو چې دا برخه څنګه کار کوي، څنګه یې ستونزې حل کړي.
  • موږ د ستونزې لامل نه حل کوو، مګر ستونزه - هغه څه چې ما مخکې وویل. دا زموږ لپاره مهمه ده چې کاروونکي له ستونزو څخه وژغورو.
  • موږ تصفیې لرو. د مثال په توګه، موږ دا د ځنډ وخت په پام کې نه نیسو که چیرې موږ په دوه دقیقو کې 2٪ ترافیک له لاسه ورکړو. دا اساسا زموږ په احصایو کې شامل ندي. که دا د فیصدي شرایطو یا لنډمهاله کې ډیر وي ، موږ دمخه حساب کوو.
  • او موږ تل پوسټ مارټم لیکو. هر هغه څه چې زموږ سره پیښیږي، هر هغه حالت چې یو څوک په تولید کې غیر معمولي چلند کوي د پوسټ مارټم کې منعکس کیږي. پوسټ مارټم یو سند دی چې تاسو په کې لیکئ چې تاسو سره څه پیښ شوي ، یو تفصیلي وخت ، تاسو د سمولو لپاره څه کړي او (دا لازمي بلاک دی!) تاسو به په راتلونکي کې د دې پیښې مخنیوي لپاره څه وکړئ. دا لازمي او د راتلونکي تحلیل لپاره اړین دی.

  د ځنډ وخت څه شی ګڼل کیږي؟

  
  
  دا ټول څه لامل شول؟

  دا د دې حقیقت لامل شو چې (موږ د ثبات سره ځینې ستونزې درلودې، دا د پیرودونکو یا موږ سره مناسب ندي) په تیرو 6 میاشتو کې زموږ د ثبات شاخص 99,97 و. موږ کولی شو ووایو چې دا خورا ډیر ندی. هو، موږ یو څه لرو چې هڅه وکړو. د دې شاخص شاوخوا نیمایي ثبات دی، لکه څنګه چې دا زموږ نه، بلکې زموږ د ویب اپلیکیشن فایروال دی، کوم چې زموږ په وړاندې ولاړ دی او د خدمت په توګه کارول کیږي، مګر پیرودونکي دې ته پام نه کوي.

  موږ د شپې خوب کول زده کړل. په پای کې! شپږ میاشتې مخکې موږ نشو کولی. او د پایلې سره په دې یادښت کې، زه غواړم یو یادښت جوړ کړم. تیره شپه د اټومي ریکټور لپاره د کنټرول سیسټم په اړه په زړه پوري راپور شتون درلود. که هغه خلک چې دا سیسټم یې لیکلی وي ما اوریدلی شي، مهرباني وکړئ د هغه څه په اړه هیر کړئ چې ما یې په اړه وویل "2٪ د ځنډ وخت نه دی." ستاسو لپاره، 2٪ د ځنډ وخت دی، حتی که د دوو دقیقو لپاره!

  بس نور څه نه! ستاسو پوښتنې.

  
  

  د بیلانس او ​​ډیټابیس مهاجرت په اړه

  د اورېدونکو پوښتنه (له دې وروسته - ب): - ماښام مو پخیر. د داسې اداري راپور لپاره ډیره مننه! ستاسو د بیلانس په اړه یوه لنډه پوښتنه. تاسو یادونه وکړه چې تاسو WAF لرئ، دا دی، لکه څنګه چې زه پوهیږم، تاسو یو ډول بهرنی توازن کاروئ ...

  EK: - نه، موږ خپل خدمات د توازن په توګه کاروو. پدې حالت کې، WAF په ځانګړې توګه زموږ لپاره د DDoS محافظت وسیله ده.

  په: - ایا تاسو کولی شئ د بیلانس په اړه یو څو کلمې ووایاست؟

  EK: - لکه څنګه چې ما مخکې وویل، دا په خلاصون کې د سرورونو یوه ډله ده. موږ اوس 5 ریزرو ګروپونه لرو چې په ځانګړي ډول ځواب ووایی ... دا دی، یو سرور چې په ځانګړې توګه پرانیستې پرمخ ځي، دا یوازې ټرافيکي پراکسي کوي. په دې اساس، د دې پوهیدلو لپاره چې موږ څومره ساتو: موږ اوس د څو سوه میګابایټ منظم ترافیک جریان لرو. دوی مقابله کوي، دوی ښه احساس کوي، دوی حتی خپل ځان نه ځوروي.

  په: - هم یوه ساده پوښتنه. دلته نیلي / شین ځای پرځای کول دي. تاسو څه کوئ، د بیلګې په توګه، د ډیټابیس مهاجرت سره؟

  EK: - ښه پوښتنه! وګورئ، په نیلي / شین ځای پرځای کولو کې موږ د هرې کرښې لپاره جلا کتارونه لرو. دا دی، که موږ د پیښو کتارونو په اړه وغږیږو چې د کارګر څخه کارګر ته لیږدول کیږي، د نیلي کرښې او شنه کرښې لپاره جلا کتارونه شتون لري. که موږ پخپله د ډیټابیس په اړه وغږیږو ، نو موږ په قصدي ډول دا څومره چې کولی شو محدود کړو ، هرڅه په عملي ډول په کتارونو کې واړوو؛ په ډیټابیس کې موږ یوازې د معاملو ذخیره کوو. او زموږ د لیږد سټیک د ټولو لینونو لپاره یو شان دی. پدې شرایطو کې د ډیټابیس سره: موږ دا په نیلي او شنه کې نه ویشو، ځکه چې د کوډ دواړه نسخې باید پوه شي چې د لیږد سره څه پیښیږي.

  ملګرو، زه هم یو کوچنی انعام لرم چې تاسو ته یې وهڅوئ - یو کتاب. او زه باید دا د غوره پوښتنې لپاره ورکړل شي.

  په: - سلام. د راپور لپاره مننه. پوښتنه دا ده. تاسو د تادیاتو څارنه کوئ، تاسو د هغه خدماتو څارنه کوئ چې تاسو ورسره اړیکه لرئ ... مګر تاسو څنګه څارنه کوئ چې یو کس ستاسو د تادیې پاڼې ته راشي، پیسې ورکړي، او پروژې هغه ته پیسې ورکړي؟ دا دی، تاسو څنګه څارنه کوئ چې مارچنټ شتون لري او ستاسو کال بیک یې منلی دی؟

  EK: - پدې حالت کې زموږ لپاره "سوداګر" د تادیې سیسټم په څیر ورته بهرني خدمت دی. موږ د سوداګر د غبرګون سرعت څارو.

  د ډیټابیس کوډ کولو په اړه

  په: - سلام. زه یو څه اړونده پوښتنه لرم. تاسو د PCI DSS حساس معلومات لرئ. ما غوښتل پوه شم چې تاسو PANs څنګه په کتارونو کې ذخیره کوئ چې تاسو ورته لیږدولو ته اړتیا لرئ؟ ایا تاسو کوم کوډ کاروئ؟ او دا د دویمې پوښتنې لامل کیږي: د PCI DSS په وینا، دا اړینه ده چې په دوره توګه د بدلونونو په صورت کې ډیټابیس بیا کوډ کړئ (د مدیرانو ګوښه کول، او نور) - پدې حالت کې د لاسرسي لپاره څه پیښیږي؟

  
  
  EK: - په زړه پورې پوښتنه! لومړی، موږ په کتارونو کې PANs نه ذخیره کوو. موږ حق نلرو چې PAN په هر ځای کې په واضح شکل کې ذخیره کړو، په اصولو کې، نو موږ یو ځانګړی خدمت کاروو (موږ ورته "کاډیمون" وایو) - دا یو خدمت دی چې یوازې یو کار کوي: دا د ننوتلو په توګه پیغام ترلاسه کوي او لیږي. یو کوډ شوی پیغام خپور کړئ. او موږ هرڅه د دې کوډ شوي پیغام سره ذخیره کوو. په دې اساس، زموږ د کلیدي اوږدوالی د یو کیلوبایټ لاندې دی، نو دا جدي او د باور وړ دی.

  په: - ایا تاسو اوس 2 کیلوبایټ ته اړتیا لرئ؟

  EK: - داسې ښکاري چې پرون 256 وه ... ښه، بل چیرته؟!

  په دې اساس، دا لومړی دی. او دوهم ، هغه حل چې شتون لري ، دا د بیا کوډ کولو پروسې ملاتړ کوي - دلته دوه جوړه "کیکس" (کیلي) شتون لري ، کوم چې "ډیک" ورکوي چې کوډ کوي (کیلي کیلي دي ، ډیک د کیلي مشتق دي چې کوډ کوي) . او که چیرې کړنلاره پیل شي (دا په منظمه توګه پیښیږي، له 3 میاشتو څخه ± ځینې پورې)، موږ د "کیک" نوې جوړه ډاونلوډ کوو، او موږ ډاټا بیا کوډ کوو. موږ جلا خدمتونه لرو چې ټول معلومات له مینځه وړي او په نوي ډول یې کوډ کوي؛ ډاټا د هغه کیلي پیژندونکي سره نږدې زیرمه کیږي چې ورسره کوډ شوی وي. په دې اساس، هرڅومره ژر چې موږ د نوي کیلي سره ډاټا کوډ کړو، موږ زاړه کیلي حذف کوو.

  ځینې ​​​​وختونه تادیات باید په لاسي ډول ترسره شي ...

  په: - دا دی، که د یو څه عملیاتو لپاره بیرته راستنیدنه راشي، ایا تاسو به بیا هم د زاړه کیلي سره ډیکریټ کړئ؟

  EK: - هو.

  په: - بیا یوه بله کوچنۍ پوښتنه. کله چې یو ډول ناکامي ، سقوط یا پیښه پیښیږي ، نو اړینه ده چې د لیږد له لارې په لاسي ډول فشار ورکړئ. داسې حالت شته.

  EK: - هو، ځینې وختونه.

  په: - تاسو دا معلومات له کوم ځای څخه ترلاسه کوئ؟ یا تاسو پخپله دې ذخیره کولو ځای ته ځئ؟

  EK: - نه، ښه، البته، موږ یو ډول د بیک دفتر سیسټم لرو چې زموږ د ملاتړ لپاره انٹرفیس لري. که موږ نه پوهیږو چې راکړه ورکړه په کوم حالت کې ده (د مثال په توګه، تر هغه چې د تادیې سیسټم د وخت پای ته رسیدو سره ځواب ووایی)، موږ یو لومړیتوب نه پوهیږو، دا دی، موږ وروستی حالت یوازې په بشپړ باور سره وړاندې کوو. پدې حالت کې، موږ لیږد د لاسي پروسس کولو لپاره ځانګړي حالت ته وړاندې کوو. په سهار کې، بله ورځ، هرڅومره ژر چې مالتړ معلومات ترلاسه کړي چې دا ډول لیږدونه د تادیې سیسټم کې پاتې دي، دوی په لاسي ډول په دې انٹرفیس کې پروسس کوي.

  
  
  په: - زه یو څو پوښتنې لرم. یو له دوی څخه د PCI DSS زون دوام دی: تاسو د دوی سرکټ څنګه لاګ کوئ؟ دا پوښتنه ځکه ده چې پراختیا کونکي کولی شي په لاګونو کې هرڅه واچوي! دویمه پوښتنه: تاسو څنګه هټ فکسونه راوباسئ؟ په ډیټابیس کې د لاسونو کارول یو اختیار دی، مګر ممکن وړیا ګرم فکسونه شتون ولري - هلته کړنلاره څه ده؟ او دریمه پوښتنه شاید د RTO، RPO پورې اړه ولري. ستاسو شتون 99,97 و، نږدې څلور نهه، مګر لکه څنګه چې زه پوهیږم، تاسو دویم ډیټا سنټر، دریم ډیټا سنټر، او پنځم ډیټا سنټر لرئ ... تاسو دوی څنګه همغږي کوئ، دوی یې نقل کړئ، او نور هرڅه؟

  EK: - راځئ چې له لومړي سره پیل وکړو. د لوګو په اړه لومړۍ پوښتنه وه؟ کله چې موږ لاګونه لیکو، موږ یو پرت لرو چې ټول حساس معلومات ماسکوي. هغه ماسک او اضافي برخو ته ګوري. په دې اساس، زموږ لاګونه د مخکینۍ ماسک شوي ډیټا او د PCI DSS سرکټ سره راځي. دا یو له منظمو دندو څخه دی چې د ازموینې څانګې ته ګمارل شوي. دوی اړ دي چې هره دنده وګوري ، پشمول د هغه لاګونو په شمول چې دوی یې لیکي ، او دا د کوډ بیاکتنې پرمهال یو له منظمو کارونو څخه دی ، ترڅو کنټرول کړي چې پراختیا کونکي یو څه ندي لیکلي. د دې تعقیبي معاینات په اونۍ کې یو ځل د معلوماتو امنیت څانګې لخوا په منظم ډول ترسره کیږي: د تیرې ورځې لاګونه په غوره توګه اخیستل کیږي او دوی د ازموینې سرورونو څخه د ځانګړي سکینر تحلیل کونکي لخوا پرمخ وړل کیږي ترڅو هرڅه وګوري.
  د ګرمو فکسونو په اړه. دا زموږ د ګمارنې په مقرراتو کې شامل دي. موږ د هاټ فکسونو په اړه جلا ماده لرو. موږ باور لرو چې موږ د ساعت په شاوخوا کې ګرم فکسونه ځای په ځای کوو کله چې موږ ورته اړتیا لرو. هرڅومره ژر چې نسخه راټولیږي ، هرڅومره ژر چې دا چلیږي ، هرڅومره ژر چې موږ یو هنري اثار ولرو ، موږ د سیسټم مدیر د ملاتړ څخه په زنګ وهلو کې دنده لرو ، او هغه په ​​​​هغه وخت کې ځای په ځای کوي کله چې اړین وي.

  د "څلور نو" په اړه. هغه ارقام چې موږ یې اوس په ریښتیا ترلاسه شوي، او موږ د دې لپاره په بل ډیټا مرکز کې هڅه کړې. اوس موږ دوهم ډیټا مرکز لرو ، او موږ د دوی ترمینځ لاره پیل کوو ، او د کراس ډیټا مرکز نقل کولو مسله واقعیا یوه غیر معمولي پوښتنه ده. موږ هڅه وکړه چې دا په یو وخت کې د مختلفو وسیلو په کارولو سره حل کړو: موږ د ورته "ټرانټولا" کارولو هڅه وکړه - دا زموږ لپاره کار نه کوي، زه به تاسو ته سمدلاسه ووایم. له همدې امله موږ په لاسي ډول د "حواس" امر کول پای ته ورسوو. په حقیقت کې، زموږ په سیسټم کې هر غوښتنلیک د ډیټا مرکزونو ترمنځ په غیر متناسب ډول اړین "بدلون - ترسره شوی" همغږي پرمخ وړي.

  په: - که تاسو دوهم ترلاسه کړی، ولې تاسو دریم ترلاسه نه کړی؟ ځکه چې تر اوسه د هیچا دماغ نه دی ویشل شوی ...

  EK: - مګر موږ سپلیټ دماغ نلرو. د دې حقیقت له امله چې هر غوښتنلیک د ملټي ماسټر لخوا پرمخ وړل کیږي، دا موږ ته مهمه نده چې غوښتنه کوم مرکز ته راغلې. موږ د دې حقیقت لپاره چمتو یو چې که زموږ د معلوماتو مرکزونه ناکام شي (موږ په دې تکیه کوو) او د کارونکي غوښتنې په مینځ کې دوهم ډیټا مرکز ته واړوو ، موږ چمتو یو چې دا کارونکي له لاسه ورکړو ، په حقیقت کې؛ مګر دا به واحدونه وي، مطلق واحدونه.

  په: - ماښام مو پخیر. د راپور لپاره مننه. تاسو د خپل ډیبګر په اړه خبرې وکړې، کوم چې په تولید کې ځینې ازموینې لیږدونه پرمخ وړي. مګر موږ ته د ازموینې لیږد په اړه ووایاست! څومره ژور دی؟

  EK: - دا د ټولې برخې بشپړ دورې څخه تیریږي. د یوې برخې لپاره، د ازموینې لیږد او تولید ترمنځ هیڅ توپیر شتون نلري. مګر د منطقي نظر څخه، دا په ساده ډول په سیسټم کې یوه جلا پروژه ده، په کوم کې چې یوازې د ازموینې معاملې پرمخ وړل کیږي.

  په: - چیرته یې پرې کړه؟ دلته کور لیږل شوی ...

  EK: - موږ په دې قضیه کې د ازموینې لیږد لپاره د "کور" تر شا یو ... موږ د روټینګ په څیر یو شی لرو: "کور" پوهیږي چې د تادیې کوم سیسټم ته لیږل کیږي - موږ د تادیې جعلي سیسټم ته لیږو، کوم چې په ساده ډول د HTTP سیګنال ورکوي او بس نور څه نه.

  په: - مهرباني وکړئ ما ته ووایاست، ایا ستاسو غوښتنلیک په یو لوی واحد کې لیکل شوی، یا تاسو دا په ځینو خدماتو یا حتی مایکرو خدماتو کې پرې کړی؟

  EK: - موږ یو واحد نلرو، البته، موږ د خدمت پر بنسټ غوښتنلیک لرو. موږ ټوکې کوو چې زموږ خدمت د monoliths څخه جوړ شوی دی - دوی واقعیا خورا لوی دي. دا سخته ده چې دې ته مایکرو خدمتونه ووایاست، مګر دا هغه خدمتونه دي چې د ویشل شوي ماشینونو کارګران کار کوي.

  که په سرور کې خدمت جوړجاړی شوی وي ...

  په: - بیا زه بله پوښتنه لرم. حتی که دا یو واحد و ، تاسو بیا هم وویل چې تاسو ډیری دا فوري سرورونه لرئ ، دوی ټول اساسا ډیټا پروسس کوي ، او پوښتنه دا ده: "د فوري سرور یا غوښتنلیک څخه د جوړجاړي په صورت کې ، کوم انفرادي لینک. ، ایا دوی د لاسرسي کنټرول لري؟ د دوی څخه څوک کولی شي څه وکړي؟ زه باید د کومو معلوماتو لپاره له چا سره اړیکه ونیسم؟

  
  
  EK: - هو، حتماً. امنیتي اړتیاوې خورا جدي دي. لومړی ، موږ د ډیټا خلاص حرکتونه لرو ، او بندرونه یوازې هغه دي چې له لارې یې موږ دمخه د ترافیک حرکت اټکل کوو. که چیرې یوه برخه د ډیټابیس سره د 5-4-3-2 له لارې اړیکه ونیسي (ووایه، د مسکول سره)، یوازې 5-4-3-2 به د هغې لپاره خلاص وي، او نور بندرونه او نور ټرافيکي لارښوونې به شتون ونلري. سربیره پردې ، تاسو اړتیا لرئ پوه شئ چې زموږ په تولید کې شاوخوا 10 مختلف امنیتي لوپونه شتون لري. او حتی که غوښتنلیک یو څه جوړ شوی وي ، خدای مه کړه ، برید کونکی به د سرور مدیریت کنسول ته لاسرسی ونلري ، ځکه چې دا د شبکې مختلف امنیت زون دی.

  په: - او په دې برخه کې، زما لپاره خورا په زړه پورې خبره دا ده چې تاسو د خدماتو سره ځانګړي قراردادونه لرئ - دوی څه کولی شي، د کوم "عمل" له لارې دوی کولی شي یو بل سره اړیکه ونیسي ... او په نورمال جریان کې، ځینې ځانګړي خدمتونه د ځینو غوښتنه کوي. قطار، په بل اړخ کې د "عملونو" لیست. دوی داسې نه بریښي چې په نورمال حالت کې نورو ته مخه کړي ، او دوی د مسؤلیت نورې ساحې لري. که یو له دوی سره جوړجاړی وي، ایا دا به وکولی شي د دې خدمت "عمل" ګډوډ کړي؟ ...

  EK: - زه پوهیږم. که په نورمال حالت کې د بل سرور سره مخابراتو ته اجازه ورکړل شوې وه ، بیا هو. د SLA تړون له مخې، موږ دا نه څارو چې تاسو ته یوازې د لومړي 3 "عملونو" اجازه درکول کیږي، او تاسو د 4 "عملونو" اجازه نه لرئ. دا شاید زموږ لپاره بې ځایه وي ، ځکه چې موږ دمخه د 4 کچې محافظت سیسټم لرو ، په اصولو کې ، د سرکیټونو لپاره. موږ غوره ګڼو چې د خپل ځان څخه دفاع وکړو، نه د داخلي سطحو په پرتله.

  ویزه، ماسټر کارډ او سبربینک څنګه کار کوي

  په: - زه غواړم د یو ډیټا مرکز څخه بل ته د کارونکي بدلولو په اړه یو ټکی روښانه کړم. تر هغه ځایه چې زه پوهیږم، ویزه او ماسټر کارډ د 8583 بائنری سنکرونس پروتوکول په کارولو سره کار کوي، او هلته مخلوط شتون لري. او ما غوښتل چې پوه شم، اوس موږ د سویچ کولو معنی لرو - ایا دا مستقیم "ویزه" او "ماسټر کارډ" یا د تادیې سیسټمونو څخه مخکې، د پروسس کولو دمخه؟

  EK: - دا د مخلوط څخه مخکې دی. زموږ مکسونه په ورته ډیټا مرکز کې موقعیت لري.

  په: - په لنډه توګه، ایا تاسو د ارتباط یوه نقطه لرئ؟

  EK: - "ویزه" او "ماسټر کارډ" - هو. په ساده ډول ځکه چې ویزه او ماسټر کارډ په زیربنا کې خورا جدي پانګوونې ته اړتیا لري ترڅو جلا قراردادونه پای ته ورسوي ترڅو دوهم جوړه مخلوط ترلاسه کړي ، د مثال په توګه. دوی په یوه ډیټا مرکز کې ساتل شوي، مګر که خدای مه کړه، زموږ د معلوماتو مرکز، چیرې چې د ویزې او ماسټر کارډ سره د نښلولو لپاره مخلوط شتون لري، مړ شي، نو بیا به موږ د ویزې او ماسټر کارډ سره اړیکه له لاسه ورکړو ...

  په: - دوی څنګه ساتل کیدی شي؟ زه پوهیږم چې ویزه په اصولو کې یوازې یوې اړیکې ته اجازه ورکوي!

  EK: - دوی پخپله تجهیزات چمتو کوي. په هر حالت کې ، موږ تجهیزات ترلاسه کړل چې دننه په بشپړ ډول بې ځایه دي.

  په: - نو موقف د دوی د نښلونکي نارنج څخه دی؟

  EK: - هو.

  په: - مګر د دې قضیې په اړه څه: که ستاسو د معلوماتو مرکز ورک شي، تاسو څنګه کولی شئ د هغې کارولو ته دوام ورکړئ؟ یا ترافیک یوازې ودریږي؟

  EK: - نه. پدې حالت کې ، موږ به په ساده ډول ترافیک بل چینل ته واړوو ، کوم چې په طبیعي ډول به زموږ لپاره خورا ګران او زموږ د پیرودونکو لپاره خورا ګران وي. مګر ټرافیک به زموږ د مستقیم ارتباط له لارې ویزې، ماسټر کارډ ته نه ځي، مګر د مشروط سبربینک له لارې (ډیر مبالغه شوی).

  زه په وحشي توګه بخښنه غواړم که ما د سبربینک کارمندانو ته زیان رسولی وي. مګر زموږ د احصایو له مخې، د روسیې د بانکونو په منځ کې، سبربینک ډیری وختونه راټیټیږي. یوه میاشت هم نه تیریږي پرته له دې چې په سبربینک کې یو څه راښکته شي.

  
  
  

  ځینې ​​اعلانونه 🙂

  له موږ سره د پاتې کیدو لپاره مننه. ایا تاسو زموږ مقالې خوښوي؟ غواړئ نور په زړه پورې مینځپانګه وګورئ؟ د امر په ورکولو یا ملګرو ته وړاندیز کولو سره زموږ ملاتړ وکړئ ، کلاوډ VPS د پراختیا کونکو لپاره له $ 4.99 څخه, د ننوتلو کچې سرورونو یو ځانګړی انلاګ ، کوم چې زموږ لخوا ستاسو لپاره اختراع شوی و: د VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps په اړه بشپړ حقیقت له $ 19 څخه یا څنګه سرور شریک کړئ؟ (د RAID1 او RAID10 سره شتون لري، تر 24 کور پورې او تر 40GB DDR4 پورې).

  ډیل R730xd په امستردام کې د Equinix Tier IV ډیټا مرکز کې 2 ځله ارزانه؟ یوازې دلته 2x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 تلویزیون له $199 څخه په هالنډ کې! ډیل R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - له $ 99 څخه! په اړه ولولئ د زیربنا شرکت جوړولو څرنګوالی د ډیل R730xd E5-2650 v4 سرورونو کارولو سره ټولګي د یوې پیسي لپاره د 9000 یورو ارزښت لري؟

سرچینه: www.habr.com