نن ورځ، د Bitrix24 خدمت په سلګونو ګیګابایټ ټرافیک نلري، او نه هم د سرورونو لویه بیړۍ لري (که څه هم، البته، یو څو شتون لري). مګر د ډیری پیرودونکو لپاره دا په شرکت کې د کار کولو اصلي وسیله ده؛ دا یو ریښتینی سوداګریز - مهم غوښتنلیک دی. له همدې امله، د سقوط لاره نشته. څه شی که حادثه پیښه شوې وي، مګر خدمت دومره ژر "رغیدلی" چې هیڅوک هیڅ شی نه ګوري؟ او دا څنګه ممکنه ده چې د کار کیفیت او د پیرودونکو شمیر له لاسه ورکولو پرته د ناکامۍ پلي کول؟ الکساندر ډیمیدوف، په Bitrix24 کې د بادل خدماتو رییس، زموږ د بلاګ لپاره خبرې وکړې چې څنګه د محصول د شتون په 7 کلونو کې د ریزرویشن سیسټم وده کړې.
"موږ 24 کاله دمخه Bitrix7 د SaaS په توګه پیل کړ. اصلي ستونزه شاید لاندې وه: مخکې له دې چې په عامه توګه د SaaS په توګه پیل شي، دا محصول په ساده ډول د بکس شوي حل په بڼه شتون درلود. پیرودونکو دا له موږ څخه اخیستي ، په سرورونو کې یې کوربه توب کړی ، د کارپوریټ پورټل رامینځته کړی - د کارمندانو مخابراتو لپاره عمومي حل ، د فایل ذخیره کول ، د دندې مدیریت ، CRM ، دا ټول دي. او په 2012 کې، موږ پریکړه وکړه چې موږ غواړو دا د SaaS په توګه پیل کړو، دا پخپله اداره کړو، د غلطۍ زغم او اعتبار ډاډمن کړو. موږ په لاره کې تجربه ترلاسه کړه، ځکه چې تر هغه وخته پورې موږ په ساده ډول دا نه درلودل - موږ یوازې د سافټویر جوړونکي وو، نه د خدماتو چمتو کونکي.
کله چې د خدمت پیل کول، موږ پوهیږو چې ترټولو مهم شی د غلطۍ زغم، اعتبار او د خدماتو دوامداره شتون ډاډمن کول دي، ځکه چې که تاسو ساده عادي ویب پاڼه لرئ، د بیلګې په توګه، یو پلورنځی، او دا تاسو ته راځي او هلته ناست وي. یو ساعت ، یوازې تاسو رنځ کوئ ، تاسو امرونه له لاسه ورکوئ ، تاسو پیرودونکي له لاسه ورکوئ ، مګر پخپله ستاسو د پیرودونکي لپاره ، دا د هغه لپاره خورا مهم ندي. هغه خپه و، البته، مګر هغه لاړ او په بل سایټ کې یې واخیست. او که دا یو غوښتنلیک وي چې په شرکت کې ټول کار، مخابراتو، پریکړې تړلې وي، نو بیا ترټولو مهم شی د کاروونکو باور ترلاسه کول دي، دا دا دی چې نه پریږدي او نه پریږدي. ځکه چې ټول کار کولی شي ودریږي که دننه یو څه کار ونه کړي.
Bitrix.24 د SaaS په توګه
موږ لومړی پروټوټایپ د عامه لانچ څخه یو کال دمخه په 2011 کې راټول کړ. موږ دا شاوخوا یوه اونۍ کې راټول کړل، ورته یې وکتل، وګرځول - دا حتی کار کوي. دا دی، تاسو کولی شئ فورمه ته لاړ شئ، هلته د پورټل نوم دننه کړئ، یو نوی پورټل به خلاص شي، او د کاروونکي اساس به رامینځته شي. موږ دې ته وکتل، په اصولو کې مو محصول و ارزاوه، ټوټه ټوټه کړه، او د ټول کال لپاره یې پاکولو ته دوام ورکړ. ځکه چې موږ لوی دنده درلوده: موږ نه غوښتل دوه مختلف کوډ اډې جوړې کړو، موږ نه غوښتل د جلا بسته شوي محصول مالتړ وکړو، جلا بادل حلونه - موږ غوښتل دا ټول په یو کوډ کې ترسره کړو.
په هغه وخت کې یو عام ویب اپلیکیشن یو سرور و چې په هغه کې د پی ایچ پی کوډ چلیږي، د مای ایس کیو ایل ډیټابیس، فایلونه اپلوډ شوي، اسناد، انځورونه د اپلوډ فولډر کې ایښودل شوي - ښه، دا ټول کار کوي. افسوس، د دې په کارولو سره د جدي مستحکم ویب خدمت پیل کول ناممکن دي. هلته، توزیع شوي کیچ نه ملاتړ کیږي، د ډیټابیس نقل ملاتړ نه کیږي.
موږ اړتیاوې جوړې کړې: دا وړتیا ده چې په مختلفو ځایونو کې موقعیت ولري، د نقل ملاتړ کوي، او په مثالي توګه په مختلفو جغرافیه ویشل شوي ډیټا مرکزونو کې موقعیت لري. د محصول منطق جلا کړئ او په حقیقت کې د معلوماتو ذخیره کول. د بار سره سم په متحرک ډول اندازه کولو وړ اوسئ ، او په بشپړ ډول احصایې برداشت کړئ. د دې ملاحظاتو څخه ، په حقیقت کې ، د محصول اړتیاوې راڅرګندې شوې ، کوم چې موږ د کال په اوږدو کې اصلاح کړې. د دې وخت په جریان کې ، په پلیټ فارم کې ، کوم چې متحد شو - د بکس شوي حلونو لپاره ، زموږ د خپل خدمت لپاره - موږ د هغه شیانو ملاتړ وکړ چې موږ ورته اړتیا لرو. پخپله د محصول په کچه د mysql نقل لپاره ملاتړ: دا دی چې پراختیا کونکی چې کوډ لیکي پدې اړه فکر نه کوي چې غوښتنې به یې څنګه توزیع شي ، هغه زموږ api کاروي ، او موږ پوهیږو چې څنګه د ماسټرانو ترمینځ د لیکلو او لوستلو غوښتنې په سمه توګه توزیع کړو. او غلامان.
موږ د مختلف کلاوډ څیز ذخیره کولو لپاره د محصول په کچه ملاتړ کړی دی: د ګوګل ذخیره ، ایمیزون s3 ، او د خلاص سټیک سویفټ لپاره ملاتړ. له همدې امله، دا زموږ لپاره د خدمت په توګه او د پراختیا کونکو لپاره چې د بسته شوي حل سره کار کوي مناسب و: که دوی یوازې د کار لپاره زموږ API کاروي، دوی فکر نه کوي چې فایل به په پای کې چیرته خوندي شي، په ځایی توګه د فایل سیسټم یا د اعتراض فایل ذخیره کې.
د پایلې په توګه، موږ سمدلاسه پریکړه وکړه چې موږ به د ټول ډیټا مرکز په کچه ذخیره کړو. په 2012 کې، موږ په بشپړ ډول په ایمیزون AWS کې پیل کړ ځکه چې موږ دمخه د دې پلیټ فارم سره تجربه درلوده - زموږ خپله ویب پاڼه هلته کوربه وه. موږ د دې حقیقت لخوا متوجه شوي یو چې په هره سیمه کې ایمیزون د شتون ډیری زونونه لري - په حقیقت کې (د دوی په اصطلاح کې) ډیری ډیټا مرکزونه چې له یو بل څخه لږ یا لږ خپلواک دي او موږ ته اجازه راکوي چې د بشپړ ډیټا مرکز په کچه ذخیره کړو: که دا ناڅاپه ناکام شي، ډیټابیسونه د ماسټر ماسټر نقل شوي، د ویب غوښتنلیک سرورونه بیک اپ شوي، او جامد ډاټا د s3 اعتراض ذخیره ته لیږدول کیږي. بار متوازن دی - په هغه وخت کې د ایمیزون ایلب لخوا، مګر یو څه وروسته موږ خپل د بار توازن ته راغلو، ځکه چې موږ ډیر پیچلي منطق ته اړتیا درلوده.
هغه څه چې دوی غوښتل هغه یې ترلاسه کړل ...
ټول هغه لومړني شیان چې موږ یې غوښتل ډاډ ترلاسه کړو - پخپله د سرورونو غلطي زغم، ویب غوښتنلیکونه، ډیټابیسونه - هرڅه ښه کار کوي. ترټولو ساده سناریو: که زموږ د ویب غوښتنلیکونو څخه یو ناکام شي، نو هرڅه ساده دي - دوی د توازن څخه تیر شوي.
بیلانسر (په هغه وخت کې دا د ایمیزون ایلب و) هغه ماشینونه په نښه کړل چې له ترتیب څخه بهر وو د غیر صحي په توګه او په دوی باندې یې د بار توزیع بند کړ. د ایمیزون آټوسکلینګ کار وکړ: کله چې بار لوړ شو ، نوي ماشینونه د آٹو سکیلینګ ګروپ کې اضافه شول ، بار نوي ماشینونو ته توزیع شو - هرڅه سم وو. زموږ د بیلانسرانو سره، منطق تقریبا ورته دی: که د غوښتنلیک سرور ته یو څه پیښ شي، موږ له هغې څخه غوښتنې لیرې کوو، دا ماشینونه یې وغورځوو، نوي پیل کړئ او کار ته دوام ورکړئ. دا سکیم د کلونو په اوږدو کې یو څه بدلون موندلی، مګر کار ته دوام ورکوي: دا ساده، د پوهیدو وړ دی، او هیڅ ډول ستونزې شتون نلري.
موږ په ټوله نړۍ کې کار کوو، د پیرودونکي بار په بشپړ ډول توپیر لري، او په دوستانه ډول، موږ باید د دې وړتیا ولرو چې زموږ د سیسټم هرې برخې ته په هر وخت کې د ځانګړو خدماتو کار ترسره کړو - د پیرودونکو لخوا د پام وړ نه وي. له همدې امله ، موږ فرصت لرو چې ډیټابیس له عملیاتو څخه بند کړو ، د دوهم ډیټا مرکز ته بار بیا توزیع کړو.
دا ټول څنګه کار کوي؟ - موږ ترافیک د کاري ډیټا مرکز ته واړوو - که چیرې د ډیټا مرکز کې کومه حادثه شتون ولري ، نو بیا په بشپړ ډول ، که دا زموږ د یو ډیټابیس سره پلان شوی کار وي ، نو بیا موږ د ټرافیک یوه برخه د دې پیرودونکو خدمت کولو لپاره دوهم ډیټا مرکز ته واړوو ، ځنډول. دا نقل. که د ویب غوښتنلیکونو لپاره نوي ماشینونو ته اړتیا وي ځکه چې د دویم ډیټا مرکز بار ډیر شوی ، دوی به په اوتومات ډول پیل شي. موږ کار پای ته ورسوو، نقل بیا رغول شوی، او موږ ټول بار بیرته راګرځوو. که موږ اړتیا لرو په دوهم DC کې یو څه کار منعکس کړو ، د مثال په توګه ، د سیسټم تازه معلومات نصب کړئ یا په دوهم ډیټابیس کې تنظیمات بدل کړئ ، نو په عموم کې ، موږ ورته شی تکرار کوو ، یوازې په بل لوري. او که دا یوه حادثه وي، نو بیا موږ هر څه په وړوکي ډول ترسره کوو: موږ د څارنې سیسټم کې د پیښو سمبالونکي میکانیزم کاروو. که چیرې څو چکونه پیل شي او حالت نازک ته لاړ شي، نو موږ دا هینډلر چلوو، یو سمبالونکی چې کولی شي دا یا هغه منطق اجرا کړي. د هر ډیټابیس لپاره، موږ مشخص کوو چې کوم سرور د دې لپاره ناکام دی، او چیرې چې ټرافیک باید بدل شي که چیرې شتون نلري. په تاریخي توګه، موږ ناګیوس یا د هغې ځینې فورکس په یوه بڼه یا بل ډول کاروو. په اصولو کې، د څارنې په هر سیسټم کې ورته میکانیزمونه شتون لري؛ موږ لا تر اوسه ډیر پیچلي څه نه کاروو، مګر شاید یوه ورځ به یې وکړو. اوس نظارت د نه شتون له امله رامینځته شوی او د یو څه بدلولو وړتیا لري.
ایا موږ هرڅه خوندي کړي؟
موږ د متحده ایالاتو څخه ډیری پیرودونکي لرو ، ډیری پیرودونکي له اروپا څخه ، ډیری پیرودونکي چې ختیځ ته نږدې دي - جاپان ، سینګاپور او داسې نور. البته، د پیرودونکو لویه برخه په روسیه کې ده. یعنی کار په یوه سیمه کی نه دی. کاروونکي ګړندي ځواب غواړي ، د مختلف سیمه ایزو قوانینو سره موافقت لپاره اړتیاوې شتون لري ، او په هره سیمه کې موږ دوه ډیټا مرکزونه خوندي کوو ، سربیره پردې ځینې اضافي خدمات شتون لري ، کوم چې بیا په یوه سیمه کې ځای په ځای کول اسانه دي - د پیرودونکو لپاره چې په سیمه کې دي. دا سیمه کار کوي. REST هینډلرونه، د واک ورکولو سرورونه، دوی په ټولیز ډول د مراجعینو د عملیاتو لپاره لږ مهم دي، تاسو کولی شئ د لږ منلو وړ ځنډ سره د دوی له لارې تیر کړئ، مګر تاسو نه غواړئ د دوی د څارنې څرنګوالی او څه وکړي. د هغوی سره. له همدې امله ، موږ هڅه کوو چې په اضافي محصولاتو کې د یو ډول وړتیا رامینځته کولو پرځای ، اعظمي ته موجوده حلونه وکاروو. او په کوم ځای کې چې موږ د DNS په کچه د سویچ کولو څخه کار اخلو، او موږ د ورته DNS لخوا د خدماتو ژوندیتوب ټاکو. ایمیزون د روټ 53 خدمت لري، مګر دا یوازې یو DNS نه دی چې تاسو یې دننه کولی شئ او دا دی - دا خورا ډیر انعطاف وړ او اسانه دی. د دې له لارې تاسو کولی شئ د جیو - توزیع شوي خدمتونه د جیو ځایونو سره رامینځته کړئ ، کله چې تاسو دا وکاروئ ترڅو معلومه کړئ چې پیرودونکي له کوم ځای څخه راغلی او هغه ته ځانګړي ریکارډونه ورکړئ - د دې په مرسته تاسو کولی شئ د ناکامۍ معمارۍ رامینځته کړئ. ورته روغتیایی معاینات پخپله په 53 روټ کې تنظیم شوي ، تاسو پای ټکي تنظیم کړئ چې نظارت کیږي ، میټریکونه تنظیم کړئ ، کوم پروتوکولونه تنظیم کړئ چې د خدماتو "ژوندیتوب" مشخص کړي - tcp, http, https; د چکونو فریکونسۍ تنظیم کړئ چې معلومه کړي چې ایا خدمت ژوندی دی که نه. او پخپله په DNS کې تاسو مشخص کوئ چې کوم به لومړني وي ، کوم به ثانوي وي ، چیرې به بدل شي که چیرې د روغتیا معاینه د لارې 53 دننه پیل شي. یو ځل پورته او بیا د دې په اړه فکر مه کوئ چې موږ څنګه چک کوو، څنګه موږ بدلوو: هر څه پخپله کار کوي.
لومړی "مګر": څنګه او له څه شی سره د 53 لار ځان ته خوندي کړو؟ څوک پوهیږي، که څه ورته پیښ شي؟ خوشبختانه ، موږ هیڅکله پدې ریک باندې ګام نه دی اخیستی ، مګر یوځل بیا ، زه به مخکې یوه کیسه ولرم چې ولې موږ فکر کاوه چې موږ لاهم ریزرویشن ته اړتیا لرو. دلته موږ مخکې له مخکې د ځان لپاره ډډونه ایښودل. په ورځ کې څو ځله موږ د ټولو زونونو بشپړ انډول کوو چې موږ یې په 53 لار کې لرو. د ایمیزون API تاسو ته اجازه درکوي چې دوی په اسانۍ سره په JSON کې واستوي، او موږ ډیری بیک اپ سرورونه لرو چیرې چې موږ یې بدلوو، د تشکیلاتو په بڼه یې اپلوډ کوو او تقریبا خبرې کول، د بیک اپ ترتیب لري. که یو څه پیښ شي، موږ کولی شو په چټکۍ سره د DNS ترتیباتو ډاټا له لاسه ورکولو پرته په لاسي ډول ځای په ځای کړو.
دوهم "مګر": په دې انځور کې څه شی تر اوسه نه دی ساتل شوی؟ پخپله توازن کونکی! د سیمې له مخې زموږ د پیرودونکو ویش خورا ساده شوی. موږ bitrix24.ru، bitrix24.com، .de ډومینونه لرو - اوس دلته 13 مختلف دي، کوم چې په مختلفو زونونو کې کار کوي. موږ لاندې ته راغلو: هره سیمه خپل بیلانسران لري. دا په ټولو سیمو کې د توزیع کولو لپاره خورا اسانه کوي، پدې پورې اړه لري چې په شبکه کې د لوړ بار بار دی. که دا د یو واحد بیلانس په کچه ناکامي وي، نو دا په ساده ډول د خدمت څخه ایستل کیږي او د DNS څخه لرې کیږي. که چیرې د بیلانس ګروپ سره کومه ستونزه وي، نو بیا دوی په نورو سایټونو کې بیک اپ کیږي، او د دوی تر منځ سویچ کول د ورته لارې په کارولو سره ترسره کیږي53، ځکه چې د لنډ TTL له امله، سویچ کول په اعظمي حد کې 2، 3، 5 دقیقو کې واقع کیږي. .
دریم "مګر": هغه څه چې تر اوسه خوندي نه دي؟ S3، سمه ده. کله چې موږ هغه فایلونه ځای په ځای کړل چې موږ یې د کاروونکو لپاره په s3 کې ذخیره کوو، موږ په صادقانه توګه باور درلود چې دا د زغره سوري وه او هلته هیڅ شی ذخیره کولو ته اړتیا نشته. مګر تاریخ ښیې چې شیان په بل ډول پیښیږي. په عموم کې، ایمیزون S3 د یو بنسټیز خدمت په توګه تشریح کوي، ځکه چې ایمیزون پخپله S3 کاروي ترڅو د ماشین عکسونو، ترتیبونو، AMI انځورونو، سنیپ شاټونو ذخیره کولو لپاره ... او که s3 حادثه شي، لکه څنګه چې په دې 7 کلونو کې یو ځل پیښ شوي، تر هغه چې موږ یې کاروو. bitrix24، دا د فین په څیر تعقیبوي دلته د شیانو ټوله ډله شتون لري چې راځي - د مجازی ماشینونو پیل کولو کې پاتې راتلل، د API ناکامي، او داسې نور.
او S3 کولی شي سقوط وکړي - دا یو ځل پیښ شو. له همدې امله ، موږ لاندې سکیم ته راغلو: څو کاله دمخه په روسیه کې د عامه شیانو ذخیره کولو هیڅ جدي اسانتیاوې شتون نلري ، او موږ د خپل ځان د یو څه کولو اختیار په پام کې نیولی و ... خوشبختانه ، موږ دا کار پیل نه کړ ، ځکه چې موږ به هغه مهارت ته چې موږ یې نه لرو، په ګوته کړي او شاید ګډوډ کړي. اوس Mail.ru د s3 سره مطابقت لرونکی ذخیره لري، Yandex دا لري، او یو شمیر نور چمتو کونکي لري. موږ په نهایت کې دې نظر ته ورسیدو چې موږ غواړو لومړی ، بیک اپ او دوهم ، د ځایی کاپي سره د کار کولو وړتیا ولرو. په ځانګړې توګه د روسیې سیمې لپاره، موږ د Mail.ru Hotbox خدمت کاروو، کوم چې د s3 سره مطابقت لري. موږ د اپلیکیشن دننه کوډ کې کوم لوی بدلون ته اړتیا نه درلوده، او موږ لاندې میکانیزم جوړ کړ: په s3 کې داسې محرکونه شتون لري چې د شیانو رامینځته کول / حذف کوي، ایمیزون د لامبډا په نوم یو خدمت لري - دا د کوډ بې سروره لانچ دی. دا به یوازې هغه وخت اجرا شي کله چې ځانګړي محرکات پیل شي.
موږ دا په ساده ډول ترسره کړل: که زموږ محرک ډزې وکړي، موږ کوډ اجرا کوو چې اعتراض به د Mail.ru ذخیره کې کاپي کړي. د ډیټا د ځایی کاپيونو سره په بشپړ ډول د کار پیل کولو لپاره، موږ د برعکس همغږي کولو ته اړتیا لرو ترڅو هغه پیرودونکي چې د روسیې په برخه کې دي کولی شي د ذخیره کولو سره کار وکړي چې دوی ته نږدې وي. میل په خپل ذخیره کې د محرکاتو بشپړولو په حال کې دی - دا به ممکنه وي چې د زیربنا په کچه د ریورس ترکیب ترسره کړئ ، مګر د اوس لپاره موږ دا د خپل کوډ په کچه کوو. که موږ وګورو چې پیرودونکي یو فایل پوسټ کړی ، نو د کوډ په کچه موږ پیښه په کتار کې ځای په ځای کوو ، پروسس کوو او بیا تکرار کوو. ولې دا بد دی: که موږ د خپل محصول څخه بهر زموږ د شیانو سره یو ډول کار وکړو ، دا د ځینې بهرني وسیلو له لارې ، موږ به یې په پام کې ونه نیسو. له همدې امله ، موږ تر پای پورې انتظار کوو ، کله چې محرکات د ذخیره کولو په کچه څرګندیږي ، نو مهمه نده چې موږ له کوم ځای څخه کوډ اجرا کړو ، هغه شی چې موږ ته راغلی په بل لوري کاپي کیږي.
د کوډ په کچه، موږ د هر پیرودونکي لپاره دواړه ذخیره ثبت کوو: یو یې اصلي ګڼل کیږي، بل یې بیک اپ ګڼل کیږي. که هرڅه سم وي، موږ د هغه ذخیره کولو سره کار کوو چې موږ ته نږدې دي: دا زموږ پیرودونکي چې په ایمیزون کې دي، دوی د S3 سره کار کوي، او هغه څوک چې په روسیه کې کار کوي، دوی د Hotbox سره کار کوي. که بیرغ پیل شي، نو ناکامي باید وصل شي، او موږ پیرودونکي بل ذخیره ته واړوو. موږ کولی شو دا بکس په خپلواکه توګه د سیمې له مخې چیک کړو او کولی شو دوی شا او خوا بدل کړو. موږ دا تر اوسه په عمل کې نه دی کارولی، مګر موږ د دې میکانیزم لپاره چمتو کړی او موږ فکر کوو چې یوه ورځ به موږ دې سویچ ته اړتیا ولرو او په کار کې به راشي. دا دمخه یو ځل پیښ شوی.
او ایمیزون وتښتید ...
دا اپریل په روسیه کې د ټیلیګرام بلاک کولو پیل کلیزه نښه کوي. ترټولو اغیزمن چمتو کونکی چې د دې لاندې راغلی ایمیزون دی. او، له بده مرغه، د روسیې شرکتونو چې د ټولې نړۍ لپاره کار کاوه ډیر زیانمن شوي.
که چیرې شرکت نړیوال وي او روسیه د هغې لپاره خورا کوچنۍ برخه وي، 3-5٪ - ښه، یوه لاره یا بل، تاسو کولی شئ دوی قرباني کړئ.
که دا یو خالص روسی شرکت وي - زه ډاډه یم چې دا باید په محلي توګه موقعیت ولري - ښه، دا به په ساده ډول د کاروونکو لپاره اسانه وي، آرام وي، او لږ خطرونه به وي.
څه که دا یو شرکت وي چې په نړیواله کچه فعالیت کوي او د روسیې او د نړۍ له کوم ځای څخه نږدې مساوي شمیر پیرودونکي لري؟ د برخو نښلول مهم دي، او دوی باید د یو بل سره یو له بل سره کار وکړي.
د مارچ 2018 په پای کې، Roskomnadzor لوی آپریټرانو ته یو لیک واستاوه چې پکې ویل شوي چې دوی پلان لري څو ملیون ایمیزون IPs بلاک کړي ترڅو د زیلو میسنجر بلاک کړي. د دې ورته چمتو کونکو څخه مننه - دوی په بریالیتوب سره ټولو ته لیک لیک کړ ، او داسې پوهه شتون درلود چې د ایمیزون سره اړیکه جلا کیدی شي. دا د جمعې ورځ وه، موږ د سرور.ru څخه خپلو همکارانو ته په ویره کې ورغلو، ویې ویل: "ملګرو، موږ ډیری سرورونو ته اړتیا لرو چې په روسیه کې نه وي، نه په ایمیزون کې، مګر، د بیلګې په توګه، په امستردام کې یو ځای" په ترتیب سره. د دې لپاره چې لږ تر لږه وکولی شو خپل VPN او پراکسي هلته د ځینې پایونو لپاره نصب کړو چې موږ نشو کولی په هیڅ ډول اغیزه وکړو، د بیلګې په توګه د ورته s3 پای پایټونه - موږ نشو کولی هڅه وکړو چې یو نوی خدمت پورته کړو او یو بل ip ترلاسه کړو، موږ تاسو لاهم اړتیا لرئ هلته ورسیږو. یوازې په څو ورځو کې، موږ دا سرورونه تنظیم کړل، دوی یې پورته او روان کړل، او په عموم کې، د هغه شیبې لپاره چمتو شو چې بلاک کول پیل شوي. دا په زړه پورې ده چې RKN، د ګډوډۍ او ویره په لټه کې، وویل: "نه، موږ به اوس هیڅ شی بند نه کړو." (مګر دا دقیقا تر هغه وخته پورې ده چې د ټیلیګرام بلاک کول پیل شوي.) د بای پاس وړتیاو رامینځته کولو او پوهیدو سره چې بلاک کول ندي معرفي شوي ، په هرصورت ، موږ د ټولې مسلې حل کول پیل نه کړل. هو، یوازې په قضیه کې.
او په 2019 کې، موږ لاهم د بلاک کولو شرایطو کې ژوند کوو. ما تیره شپه ولیدل: شاوخوا یو ملیون IPs بلاک کیدو ته دوام ورکوي. ریښتیا، ایمیزون تقریبا په بشپړ ډول غیر بلاک شوی و، په خپل اوج کې دا 20 ملیون پتې ته رسیدلی ... په عموم کې، حقیقت دا دی چې ممکن همغږي، ښه همغږي نه وي. ناڅاپه. دا ممکن د تخنیکي دلیلونو لپاره شتون ونلري - اور، کیندونکي، دا ټول. یا، لکه څنګه چې موږ ولیدل، په بشپړه توګه تخنیکي نه. له همدې امله، یو څوک لوی او لوی، د خپل AS سره، شاید دا په نورو لارو اداره کړي - مستقیم اړیکه او نور شیان لا دمخه د l2 په کچه دي. مګر په یوه ساده نسخه کې، زموږ په څیر یا حتی کوچني، تاسو کولی شئ، یوازې په هغه صورت کې چې د سرورونو په کچه کې بل ځای ته پورته شوي، د مخکینۍ vpn، پراکسي ترتیب شوي، په دې برخو کې دوی ته د ګړندۍ ترتیباتو بدلولو وړتیا سره. چې ستاسو د ارتباط لپاره مهم دي. دا زموږ لپاره د یو ځل څخه ډیر په کار کې راغلی، کله چې د ایمیزون بلاک کول پیل شول؛ په بدترین حالت کې، موږ یوازې د دوی له لارې د S3 ټرافیک ته اجازه ورکړه، مګر په تدریجي توګه دا ټول حل شول.
څنګه ذخیره کول ... یو بشپړ چمتو کونکی؟
همدا اوس موږ داسې سناریو نلرو که چیرې ټول ایمیزون ښکته شي. موږ د روسیې لپاره ورته سناریو لرو. په روسیه کې، موږ د یو چمتو کونکي لخوا کوربه شوي، له هغه څخه چې موږ ډیری سایټونه غوره کړل. او یو کال دمخه موږ له یوې ستونزې سره مخ شو: که څه هم دا دوه ډیټا مرکزونه دي ، ممکن دمخه د چمتو کونکي شبکې ترتیب په کچه ستونزې شتون ولري چې لاهم به دواړه ډیټا مرکزونه اغیزه وکړي. او موږ ممکن په دواړو سایټونو کې شتون ونلرو. البته دا هغه څه دي. موږ دننه د معمارۍ بیاکتنه پای ته ورسوله. دا ډیر نه دی بدل شوی، مګر د روسیې لپاره موږ اوس دوه سایټونه لرو، کوم چې د ورته برابرونکي څخه ندي، مګر د دوو مختلفو څخه. که یو ناکام شو، موږ کولی شو بل ته لاړ شو.
په فرضي ډول، د ایمیزون لپاره موږ د بل چمتو کونکي په کچه د ریزرویشن امکان په پام کې نیسو؛ شاید ګوګل، شاید بل څوک ... مګر تر دې دمه موږ په عمل کې لیدلي چې پداسې حال کې چې ایمیزون د یو شتون زون په کچه حادثې لري، د ټولې سیمې په کچه حادثې خورا لږ دي. له همدې امله، موږ په تیوریکي توګه دا نظر لرو چې موږ ممکن د "ایمیزون ایمیزون نه دی" ریزرویشن جوړ کړو، مګر په عمل کې دا لاهم قضیه نده.
د اتومات په اړه یو څو خبرې
ایا اتومات تل اړین دی؟ دلته دا مناسبه ده چې د Dunning-Kruger اثر یادونه وکړو. په "x" محور کې زموږ پوهه او تجربه ده چې موږ یې ترلاسه کوو، او په "y" محور کې زموږ په کړنو باور دی. په لومړي سر کې موږ هیڅ نه پوهیږو او په بشپړ ډول ډاډه نه یو. بیا موږ یو څه پوهیږو او لوی باوري شو - دا د "احمقۍ چوکۍ" په نوم یادیږي ، د "ډیمینشیا او زړورتیا" انځور لخوا ښه توضیح شوی. بیا موږ لږ څه زده کړل او جګړې ته چمتو یو. بیا موږ په ځینو لویو - جدي غلطیو باندې ګام اخلو او ځان د نا امیدۍ په دره کې ګورو، کله چې موږ یو څه پوهیږو، مګر په حقیقت کې موږ ډیر نه پوهیږو. بیا، لکه څنګه چې موږ تجربه ترلاسه کوو، موږ ډیر باوري شو.
د ځانګړو حادثو لپاره د مختلف اتوماتیک سویچونو په اړه زموږ منطق د دې ګراف لخوا خورا ښه تشریح شوی. موږ پیل وکړ - موږ نه پوهیږو چې څه وکړو، نږدې ټول کار په لاس کې و. بیا موږ پوهیږو چې موږ کولی شو اتوماتیک هرڅه سره ضمیمه کړو او لکه په آرامۍ سره خوب وکړو. او ناڅاپه موږ په میګا ریک باندې ګام اخلو: یو غلط مثبت رامینځته کیږي، او موږ ټرافیک شا او خوا بدلوو کله چې، په ښه توګه، موږ باید دا کار نه وای کړی. په پایله کې، نقل ماتیږي یا بل څه - دا د نا امیدۍ ډیره دره ده. او بیا موږ پوهیږو چې موږ باید هرڅه په هوښیارۍ سره وکړو. دا دی، دا معنی لري چې په اتوماتیک تکیه وکړي، د غلط الارمونو احتمال چمتو کوي. خو! که پایلې یې ویجاړونکي وي، نو دا به غوره وي چې دا د وظیفې لیږد ته پریږدو، په دنده کې انجینرانو ته، څوک به ډاډ ترلاسه کړي او څارنه وکړي چې واقعا کومه پیښه ده، او اړین اقدامات به په لاسي ډول ترسره کړي ...
پایلې
د 7 کلونو په جریان کې، موږ د دې حقیقت څخه تیر شو چې کله یو څه راښکته کیږي، ویره - ویره وه، پدې پوهیدلو کې چې ستونزې شتون نلري، یوازې دندې شتون لري، دوی باید حل شي. کله چې تاسو یو خدمت جوړوئ، له پورته څخه یې وګورئ، ټول هغه خطرونه ارزوئ چې ممکن پیښ شي. که تاسو دوی سمدلاسه وګورئ، نو مخکې له مخکې د بې ځایه کیدو او د غلطۍ زغمونکي زیربنا رامینځته کولو امکان چمتو کړئ، ځکه چې هر هغه ټکی چې ناکام شي او د خدماتو غیر فعال کیدو لامل شي، یقینا دا کار کوي. او حتی که تاسو ته داسې ښکاري چې د زیربنا ځینې عناصر به یقینا ناکام نشي - د ورته s3 په څیر، بیا هم په پام کې ونیسئ چې دوی کولی شي. او لږترلږه په تیوري کې، یو نظر ولرئ چې تاسو به د دوی سره څه وکړئ که چیرې یو څه پیښ شي. د خطر مدیریت پلان ولرئ. کله چې تاسو د هر څه په اوتومات ډول یا په لاسي ډول د ترسره کولو په اړه فکر کوئ، د خطرونو ارزونه وکړئ: څه به پیښ شي که چیرې اتومات هر څه بدل کړي - ایا دا به د حادثې په پرتله خورا بد حالت رامینځته نه کړي؟ شاید په کوم ځای کې دا اړینه وي چې د اتومات کارولو او په دنده کې د انجینر عکس العمل تر مینځ مناسب جوړجاړی وکاروئ ، څوک به ریښتیني عکس و ارزوي او پوه شي چې ایا یو څه باید په ځای بدل شي یا "هو ، مګر اوس نه."
د بشپړتیا او ریښتیني هڅې ، وخت ، پیسو ترمینځ مناسب جوړجاړی چې تاسو کولی شئ په هغه سکیم کې مصرف کړئ چې تاسو به یې په پای کې ولرئ.
دا متن په کنفرانس کې د الکساندر دیمیدوف د راپور تازه او پراخ شوی نسخه ده .
سرچینه: www.habr.com