په اوړي کې، دواړه د پیرود فعالیت او د ویب پروژو زیربنا کې د بدلون شدت په دودیز ډول کم شوی، کپتان اوبیوس موږ ته وایي. په ساده ډول ځکه چې حتی د معلوماتي ټکنالوجۍ متخصصین ځینې وختونه په رخصتۍ ځي. او CTO هم. دا د هغو کسانو لپاره خورا ستونزمن دی چې په دفتر کې پاتې کیږي، مګر دا اوس ټکی نه دی: شاید له همدې امله اوړي د اوسني ریزرویشن سکیم په اړه ورو ورو فکر کولو لپاره غوره دوره ده او د هغې د ښه کولو لپاره پالن جوړ کړئ. او د Yegor Andreev تجربه ، چې هغه په کنفرانس کې خبرې وکړې .
دلته ډیری نیمګړتیاوې شتون لري چې تاسو یې د بیک اپ سایټونو جوړولو په وخت کې راګیر شئ. او په دوی کې نیول بالکل ناممکن دي. او هغه څه چې موږ په دې ټولو کې خرابوي، لکه د نورو ډیرو شیانو په څیر، بشپړتیا او سستي ده. موږ هڅه کوو چې هرڅه، هرڅه، هرڅه په بشپړ ډول ترسره کړو، مګر موږ اړتیا نلرو چې دا په بشپړ ډول ترسره کړو! تاسو یوازې ځینې شیان ترسره کولو ته اړتیا لرئ، مګر دوی په سمه توګه ترسره کړئ، بشپړ کړئ ترڅو دوی په سمه توګه کار وکړي.
ناکامي یو ډول تفریح نه ده، تفریح شی؛ دا یو شی دی چې باید دقیقا یو کار وکړي - د ځنډ وخت کم کړئ ترڅو خدمت ، شرکت لږې پیسې له لاسه ورکړي. او د ریزرویشن ټولو میتودونو کې، زه په لاندې شرایطو کې د فکر کولو وړاندیز کوم: پیسې چیرته دي؟
لومړی جال: کله چې موږ لوی، د اعتماد وړ سیسټمونه جوړ کړو او په بې ځایه کیدو کې ښکیل شو، موږ د پیښو شمیر کموو. دا یو لوی غلط فهم دی. کله چې موږ په بې ځایه کیدو کې ښکیل شو، موږ احتمال لرو چې د پیښو شمیر زیات کړو. او که موږ هرڅه سم ترسره کړو، نو په ټولیز ډول به موږ د ځنډ وخت کم کړو. ډیر حادثې به وي، مګر دوی به په ټیټ لګښتونو کې واقع شي. ریزرویشن څه شی دی؟ - دا د سیسټم پیچلتیا ده. هر ډول پیچلتیا خرابه ده: موږ ډیر کوګونه، ډیر ګیرونه، په یوه کلمه کې، ډیر عناصر لرو - او له همدې امله، د ماتیدو لوړ چانس. او دوی به واقعیا مات کړي. او دوی به ډیر ځله مات شي. یو ساده مثال: راځئ چې ووایو چې موږ د PHP او MySQL سره ویب پاڼه لرو. او دا په سمدستي توګه خوندي کولو ته اړتیا لري.
شتوش (ج) موږ دوهم سایټ اخلو، یو ورته سیسټم جوړوو ... پیچلتیا دوه چنده لوی کیږي - موږ دوه ادارې لرو. موږ د یو سایټ څخه بل ته د ډیټا لیږدولو لپاره یو ځانګړی منطق هم رامینځته کوو - دا د ډیټا نقل کول ، د جامد ډیټا کاپي کول او داسې نور. نو، د نقل کولو منطق معمولا خورا پیچلی وي، او له همدې امله، د سیسټم ټول پیچلتیا کیدای شي 2 نه وي، مګر 3، 5، 10 ځله ډیر وي.
دوهم جال: کله چې موږ واقعیا لوی پیچلي سیسټمونه جوړوو، موږ د هغه څه په اړه تصور کوو چې موږ یې په پای کې ترلاسه کول غواړو. Voila: موږ غواړو یو عالي باوري سیسټم ترلاسه کړو چې پرته له کوم ځنډ څخه کار کوي ، په نیمه ثانیه کې بدلیږي (یا تر دې غوره ، سمدستي) ، او موږ د خوبونو ریښتیني کولو پیل کوو. مګر دلته یو اهمیت هم شتون لري: د مطلوب سویچنګ وخت لنډ ، د سیسټم منطق خورا پیچلی کیږي. هرڅومره چې موږ دا منطق جوړ کړو ، په هماغه اندازه به سیسټم مات شي. او تاسو کولی شئ په خورا ناخوښ حالت کې پای ته ورسیږئ: موږ په خپل ټول توان سره هڅه کوو چې د ځنډ وخت کم کړو، مګر په حقیقت کې موږ هرڅه ډیر پیچلي کوو، او کله چې یو څه غلط شي، د ځنډ وخت به اوږد شي. دلته تاسو ډیری وختونه خپل ځان فکر کوئ: ښه ... دا به غوره وي چې ریزرویشن ونه کړئ. دا به غوره وي که دا یوازې کار وکړي او د پوهیدو وړ وخت سره.
تاسو څنګه کولی شئ د دې سره مبارزه وکړئ؟ موږ اړتیا لرو چې له ځان سره دروغ ووایو ، د ځان خوشاله کولو مخه ونیسو چې موږ اوس دلته یو فضایی بیړۍ جوړوو ، مګر په کافي اندازه پوهیږو چې پروژه څومره دروغ کولی شي. او د دې اعظمي وخت لپاره ، موږ به هغه میتودونه غوره کړو چې موږ به واقعیا زموږ د سیسټم اعتبار ډیرولو لپاره وکاروو.
البته د ژوند څخه د کیسې د ویلو وخت دی.
بېلګه نمبر XNUMX
په N ښار کې د پایپ رولینګ پلانټ نمبر 1 لپاره د سوداګرۍ کارت ویب پا inې تصور وکړئ. دا په لویو لیکو کې وايي - د پایپ رولینګ پلانټ نمبر 1. یوازې لاندې شعار دی: "زموږ پایپونه په N کې ترټولو ګرد پایپونه دي." او لاندې د CEO د تلیفون شمیره او د هغه نوم دی. موږ پوهیږو چې تاسو اړتیا لرئ ریزرویشن وکړئ - دا خورا مهم شی دی! راځئ چې معلومه کړو چې دا څه شی لري. Html-statics - دا یو څو عکسونه دي چیرې چې عمومي مدیر په حقیقت کې د خپل ملګري سره د حمام په میز کې د راتلونکي معاملې په اړه بحث کوي. موږ د کم وخت په اړه فکر پیل کوو. دا په ذهن کې راځي: تاسو اړتیا لرئ د پنځو دقیقو لپاره هلته پروت شئ، نور نه. او بیا پوښتنه راپورته کیږي: په عموم کې زموږ د دې سایټ څخه څومره پلور شتون درلود؟ څومره - څومره؟ "صفر" څه معنی لري؟ او دا پدې مانا ده: ځکه چې جنرال تیر کال ټول څلور معاملې په ورته میز کې کړې ، د ورته خلکو سره چې دوی حمام ته ځي او په میز کې ناست دي. او موږ پوهیږو چې حتی که سایټ د یوې ورځې لپاره ناست وي، هیڅ شی به نه وي.
د لومړنیو معلوماتو پر بنسټ، د دې کیسې د پورته کولو لپاره یوه ورځ ده. راځئ چې د بې ځایه کیدو سکیم په اړه فکر وکړو. او موږ د دې مثال لپاره ترټولو غوره بې ځایه سکیم غوره کوو: موږ بې ځایه نه کاروو. دا ټول شی د سګرټ ماتولو سره په نیم ساعت کې د هر مدیر لخوا پورته کیدی شي. یو ویب سرور نصب کړئ، فایلونه اضافه کړئ - بس. دا به کار وکړي. تاسو اړتیا نلرئ چې هر څه ته پام وکړئ، تاسو اړتیا نلرئ چې کوم شی ته ځانګړې پاملرنه وکړئ. دا د بیلګې په توګه د لومړۍ شمیرې پایله خورا څرګنده ده: هغه خدمتونه چې اړتیا نلري ساتل کیږي خوندي کولو ته اړتیا نلري.
دوېمه بېلګه
د شرکت بلاګ: ځانګړي روزل شوي خلک هلته خبرونه لیکي، موږ په داسې یو نندارتون کې برخه اخیستې، مګر موږ یو بل نوی محصول خپور کړ، او داسې نور. راځئ چې ووایو دا د ورڈپریس سره معیاري پی ایچ پی دی، یو کوچنی ډیټابیس او یو څه جامد. البته، دا یو ځل بیا په ذهن کې راځي چې تاسو باید په هیڅ حالت کې ودریږئ - "له پنځو دقیقو څخه زیات نه!" بس. مګر راځئ چې نور فکر وکړو. دا بلاګ څه کوي؟ خلک هلته د Yandex څخه راځي، د ګوګل څخه د ځینو پوښتنو پر بنسټ، په منظم ډول. غوره. ایا پلور له دې سره هیڅ تړاو لري؟ Epiphany: واقعا نه. د اعلاناتو ترافیک اصلي سایټ ته ځي، کوم چې په مختلف ماشین کې دی. راځئ چې د بکینګ سکیم په اړه فکر وکړو. په ښه توګه، دا باید په څو ساعتونو کې پورته شي، او د دې لپاره چمتو کول به ښه وي. دا به مناسب وي چې د بل ډیټا مرکز څخه ماشین واخلئ، چاپیریال په هغې باندې وګرځوئ، دا یو ویب سرور، PHP، WordPress، MySQL، او هلته یې پریږدئ. په اوس وخت کې چې موږ پوهیږو چې هرڅه مات شوي، موږ باید دوه شیان ترسره کړو - د mysql ډمپ 50 متره راوباسئ، دا به په یوه دقیقه کې هلته الوتنه وکړي، او هلته د بیک اپ څخه یو ټاکلی شمیر عکسونه راوباسي. دا هم نه ده خدای خبر تر څو به. په دې توګه، په نیم ساعت کې ټول شیان پورته کیږي. هیڅ نقل نه، یا خدای ما معاف کړه، اتوماتیک ناکامي. پایله: هغه څه چې موږ کولی شو ژر تر ژره د بیک اپ څخه راوګرځوو د بیک اپ کولو ته اړتیا نلري.
دریمه بیلګه، ډیر پیچلی
آنلاین پلورنځي. پی ایچ پی د خلاص زړه سره یو څه ټیک شوی ، mysql د قوي بیس سره. خورا ډیر جامد (په هرصورت ، آنلاین پلورنځي ښکلي HD عکسونه او ټول هغه توکي لري) ، د ناستې لپاره ریډیس او د لټون لپاره Elasticsearch. موږ د کم وخت په اړه فکر پیل کوو. او دلته، البته، دا څرګنده ده چې آنلاین پلورنځي نشي کولی د یوې ورځې لپاره بې درده دروغ وي. په هرصورت، څومره چې دا دروغ وي، هغومره ډیرې پیسې چې موږ له لاسه ورکوو. دا د چټکتیا ارزښت لري. څومره؟ زه فکر کوم که موږ د یو ساعت لپاره ویده شو، هیڅوک به لیونی نه شي. هو، موږ به یو څه له لاسه ورکړو، مګر که موږ سخت کار پیل کړو، دا به یوازې خراب شي. موږ په هر ساعت کې اجازه ورکړل شوي د کم وخت سکیم تعریف کوو.
دا ټول څنګه ساتل کیدی شي؟ تاسو په هر حالت کې موټر ته اړتیا لرئ: یو ساعت وخت خورا لږ دی. Mysql: دلته موږ دمخه نقل ته اړتیا لرو ، ژوندی نقل ، ځکه چې په یو ساعت کې 100 GB به ډیری احتمال ډمپ ته اضافه نشي. احصایې، انځورونه: بیا، په یو ساعت کې 500 GB ممکن د اضافه کولو وخت ونه لري. له همدې امله، دا غوره ده چې عکسونه سمدلاسه کاپي کړئ. ریډیس: دا هغه ځای دی چې شیان په زړه پوري کیږي. په ریډیس کې ، ناستې زیرمه شوي - موږ نشو کولی یوازې دا واخلو او ښخ کړو. ځکه چې دا به ډیر ښه نه وي: ټول کاروونکي به لاګ آوټ شي، د دوی باسکیټونه به خالي شي، او داسې نور. خلک به مجبور شي چې خپل کارن-نوم او پاسورډ بیا دننه کړي، او ډیری خلک به مات شي او پیرود بشپړ نه کړي. یوځل بیا ، تبادلې به راټیټ شي. له بلې خوا، ریډیس مستقیم تازه دی، د وروستي ننوتلو کاروونکو سره شاید هم اړتیا نه وي. او یو ښه جوړجاړی دا دی چې ریډیس واخلئ او له پرون څخه یې له بیک اپ څخه بیرته راوباسئ ، یا که تاسو دا هر ساعت وکړئ ، یو ساعت دمخه. خوشبختانه ، د بیک اپ څخه د دې بحال کول پدې معنی دي چې د یوې فایل کاپي کول. او تر ټولو په زړه پورې کیسه Elasticsearch ده. چا کله هم د MySQL نقل غوره کړی؟ چا کله هم د Elasticsearch نقل غوره کړی؟ او د چا لپاره یې وروسته په عادي توګه کار وکړ؟ زما مطلب دا دی چې موږ په خپل سیسټم کې یو ځانګړی وجود ګورو. داسې ښکاري چې ګټور وي - مګر دا پیچلې ده.
په دې معنی چې زموږ ملګري انجینران د دې سره کار کولو تجربه نلري. یا یو منفي تجربه شتون لري. یا موږ پوهیږو چې دا لاهم د نزاکتونو یا خامۍ سره کافي نوې ټیکنالوژي ده. موږ فکر کوو ... لعنت، لچک هم صحي دی، دا د بیک اپ څخه بیرته راګرځولو لپاره ډیر وخت نیسي، زه باید څه وکړم؟ موږ پوهیږو چې زموږ په قضیه کې لچکدار د لټون لپاره کارول کیږي. زموږ آنلاین پلورنځي څنګه پلوري؟ موږ بازارمندانو ته ځو او پوښتنه کوو چې خلک له کوم ځای څخه راځي. دوی ځواب ورکوي: "د Yandex بازار څخه 90٪ مستقیم د محصول کارت ته راځي." او یا دوی یې اخلي یا یې نه کوي. له همدې امله، د 10٪ کاروونکو لخوا لټون ته اړتیا ده. او د لچک لرونکي نقل ساتل ، په ځانګړي توګه په مختلف زونونو کې د مختلف ډیټا مرکزونو ترمینځ ، واقعیا ډیری باریکي لري. کومه وتل؟ موږ له خوندي ځای څخه لچک لرونکي اخلو او د هغې سره هیڅ نه کوو. که دا مسله نوره هم اوږده شي، موږ به شاید یوه ورځ دا پورته کړو، مګر دا ډاډه نه ده. په حقیقت کې، پایله یو شان ده، جمع یا منفي: موږ بیا بیا، هغه خدمتونه نه ساتو چې پیسې اغیزه نه کوي. د ډیاګرام ساده ساتلو لپاره.
د مثال څلورمه، حتی ډیر ستونزمن
ادغام کوونکی: د ګلانو پلورل، ټکسي ویل، د توکو پلورل، په عمومي توګه، هر څه. یو جدي شی چې د لوی شمیر کاروونکو لپاره 24/7 کار کوي. د بشپړ په زړه پورې سټیک سره ، چیرې چې په زړه پوري اډې شتون لري ، حلونه ، لوړ بار او خورا مهم ، دا د 5 دقیقو څخه ډیر په ویده کیدو کې درد کوي. نه یوازې او دومره نه چې خلک به یې نه اخلي، مګر دا چې خلک به وګوري چې دا کار کار نه کوي، دوی به خپه شي او ممکن بیرته راشي.
سمه ده. پنځه دقیقې. موږ په دې اړه څه کوو؟ په دې حالت کې، موږ، د لویانو په څیر، د ریښتینې بیک اپ سایټ جوړولو لپاره ټولې پیسې کاروو، د هر څه په نقل سره، او حتی حتی د امکان تر حده دې سایټ ته اتوماتیک بدلول. او د دې سربیره، تاسو اړتیا لرئ چې یو مهم شی په یاد ولرئ: په حقیقت کې، د بدلولو مقررات ولیکئ. مقررات، حتی که تاسو هرڅه اتومات لرئ، کیدی شي خورا ساده وي. د لړۍ څخه "داسې او داسې ځواب ورکوونکي سکریپټ چلول"، "په 53 لار کې داسې او داسې چیک باکس کلیک وکړئ" او داسې نور - مګر دا باید د عملونو دقیق لیست وي.
او هرڅه روښانه ښکاري. د نقل بدلول یو کوچنی کار دی، یا دا به پخپله بدل شي. په DNS کې د ډومین نوم بیا لیکل د ورته لړۍ څخه دی. ستونزه دا ده چې کله دا ډول پروژه ناکامه شي، ویره پیل کیږي، او حتی قوي، ږیره لرونکي مدیران د دې لپاره حساس کیدی شي. پرته له واضح لارښوونو "ترمینل خلاص کړئ، دلته راشئ، زموږ د سرور پته لاهم همداسې ده،" د بیا ژوندي کولو لپاره د ټاکل شوي 5 دقیقو وخت محدودیت پوره کول ستونزمن دي. ښه، برسیره پردې، کله چې موږ دا مقررات کاروو، نو دا اسانه ده چې په زیربنا کې ځینې بدلونونه ثبت کړئ، د بیلګې په توګه، او د دې مطابق مقررات بدل کړئ.
ښه، که د ریزرویشن سیسټم خورا پیچلی وي او په یو وخت کې موږ تېروتنه کړې، نو موږ کولی شو خپل بیک اپ سایټ ویجاړ کړو، او سربیره پردې ډاټا په دواړو سایټونو کې کدو ته واړوو - دا به په بشپړه توګه غمجن وي.
د مثال نمبر پنځم، بشپړ هارډکور
یو نړیوال خدمت چې په ټوله نړۍ کې د سلګونو ملیون کاروونکو سره. ټول وخت زونونه شتون لري ، په اعظمي سرعت کې لوړ بار ، تاسو نشئ کولی په کلکه ودریږئ. یوه دقیقه - او دا به غمجن وي. چې څه کول پکار دي؟ ریزرو، بیا، د بشپړ پروګرام سره سم. موږ هرڅه وکړل چې ما په تیرو مثال کې خبرې وکړې، او یو څه نور. یو مثالی نړۍ، او زموږ زیربنا د IaaC devops د ټولو مفکورو مطابق ده. دا ، هرڅه په ګیټ کې دي ، او تاسو یوازې تڼۍ فشاروئ.
څه شی ورک دی؟ یو - تمرینونه. د دوی پرته دا ناشونې ده. داسې ښکاري چې هرڅه زموږ سره سم دي، موږ عموما هرڅه د کنټرول لاندې لرو. موږ تڼۍ فشاروو، هرڅه پیښیږي. حتی که دا داسې وي - او موږ پوهیږو چې دا په دې ډول نه کیږي - زموږ سیسټم د ځینو نورو سیسټمونو سره اړیکه لري. د مثال په توګه، دا د روټ 53 څخه dns دی، د s3 ذخیره، د ځینې api سره ادغام. موږ به په دې قیاس تجربه کې د هرڅه وړاندوینه ونه کړو. او تر هغه چې موږ واقعیا سویچ راوباسئ ، موږ به نه پوهیږو چې دا به کار وکړي یا نه.
دا شاید ټول وي. سست یا ډیر مه کوئ. او ممکن وخت ستاسو سره وي!
سرچینه: www.habr.com