امروزه، سرویس Bitrix24 صدها گیگابیت ترافیک ندارد و همچنین ناوگان عظیمی از سرورها ندارد (اگرچه، البته تعداد کمی از سرورهای موجود وجود دارد). اما برای بسیاری از مشتریان، این ابزار اصلی برای کار در شرکت است؛ این یک برنامه کاربردی واقعی برای تجارت است. بنابراین، هیچ راهی برای سقوط وجود ندارد. اگر خرابی اتفاق می افتاد، اما سرویس آنقدر سریع "بازیابی" می شد که هیچ کس متوجه چیزی نشد چه؟ و چگونه می توان Failover را بدون از دست دادن کیفیت کار و تعداد مشتریان پیاده سازی کرد؟ الکساندر دمیدوف، مدیر خدمات ابری در Bitrix24، برای وبلاگ ما در مورد چگونگی تکامل سیستم رزرو در طول 7 سال از وجود محصول صحبت کرد.
ما Bitrix24 را به عنوان SaaS 7 سال پیش راه اندازی کردیم. مشکل اصلی احتمالاً موارد زیر بود: قبل از اینکه به صورت عمومی به عنوان SaaS راه اندازی شود، این محصول به سادگی در قالب یک راه حل جعبه ای وجود داشت. مشتریان آن را از ما خریدند، آن را روی سرورهای خود میزبانی کردند، یک پورتال شرکتی راه اندازی کردند - یک راه حل کلی برای ارتباطات کارکنان، ذخیره سازی فایل، مدیریت کار، CRM، این همه. و تا سال 2012، ما تصمیم گرفتیم که می خواهیم آن را به عنوان SaaS راه اندازی کنیم و خودمان آن را مدیریت کنیم و از تحمل خطا و قابلیت اطمینان اطمینان حاصل کنیم. ما در طول مسیر تجربه به دست آوردیم، زیرا تا آن زمان به سادگی آن را نداشتیم - ما فقط تولید کنندگان نرم افزار بودیم، نه ارائه دهندگان خدمات.
هنگام راه‌اندازی سرویس، متوجه شدیم که مهم‌ترین چیز این است که از تحمل خطا، قابلیت اطمینان و در دسترس بودن مداوم سرویس اطمینان حاصل کنیم، زیرا اگر یک وب‌سایت معمولی ساده، مثلاً یک فروشگاه دارید، روی شما بیفتد و آنجا بنشیند. یک ساعت، فقط شما رنج می برید، سفارشات را از دست می دهید، مشتریان خود را از دست می دهید، اما برای خود مشتری شما، این برای او خیلی مهم نیست. او البته ناراحت بود اما رفت و از سایت دیگری خرید. و اگر این برنامه ای است که تمام کارهای درون شرکت، ارتباطات، تصمیم گیری ها بر روی آن گره خورده است، مهم ترین چیز جلب اعتماد کاربران است، یعنی ناامید نشوید و سقوط نکنید. زیرا اگر چیزی در داخل کار نکند، همه کارها می توانند متوقف شوند.
Bitrix.24 به عنوان SaaS
ما اولین نمونه اولیه را یک سال قبل از عرضه عمومی، در سال 2011، مونتاژ کردیم. ما آن را در حدود یک هفته مونتاژ کردیم، به آن نگاه کردیم، آن را چرخاندیم - حتی کار می کرد. یعنی می توانستید وارد فرم شوید، نام پورتال را در آنجا وارد کنید، یک پورتال جدید باز شود و یک پایگاه کاربری ایجاد شود. ما به آن نگاه کردیم، محصول را به طور اصولی ارزیابی کردیم، آن را از بین بردیم و یک سال کامل به پالایش آن ادامه دادیم. از آنجا که ما یک وظیفه بزرگ داشتیم: ما نمی‌خواستیم دو پایه کد متفاوت بسازیم، نمی‌خواستیم از یک محصول بسته‌بندی شده جداگانه، راه‌حل‌های ابری جداگانه پشتیبانی کنیم - می‌خواستیم همه این کارها را در یک کد انجام دهیم.
یک برنامه وب معمولی در آن زمان یک سرور بود که برخی از کدهای PHP روی آن اجرا می شد، یک پایگاه داده mysql، فایل ها آپلود می شوند، اسناد، تصاویر در پوشه آپلود قرار می گیرند - خوب، همه اینها کار می کند. افسوس، راه اندازی یک سرویس وب بسیار پایدار با استفاده از این غیرممکن است. در آنجا، کش توزیع شده پشتیبانی نمی شود، همانندسازی پایگاه داده پشتیبانی نمی شود.
ما الزامات را فرموله کردیم: این توانایی قرار گرفتن در مکان‌های مختلف، پشتیبانی از تکرار، و در حالت ایده‌آل قرار گرفتن در مراکز داده‌های مختلف جغرافیایی توزیع شده است. منطق محصول و در واقع ذخیره سازی داده ها را از هم جدا کنید. قادر به مقیاس دینامیکی با توجه به بار باشد و استاتیک را به طور کلی تحمل کند. از این ملاحظات، در واقع، الزامات مورد نیاز برای محصول پدیدار شد که در طول سال آنها را اصلاح کردیم. در طی این مدت، در پلتفرمی که معلوم شد یکپارچه شده است - برای راه حل های جعبه ای، برای خدمات خودمان - ما از چیزهایی که نیاز داشتیم پشتیبانی کردیم. پشتیبانی از تکرار mysql در سطح خود محصول: یعنی توسعه دهنده ای که کد را می نویسد به نحوه توزیع درخواست هایش فکر نمی کند، او از api ما استفاده می کند و ما می دانیم که چگونه درخواست های نوشتن و خواندن را به درستی بین مسترها توزیع کنیم. و بردگان
ما در سطح محصول از ذخیره‌سازی‌های مختلف اشیاء ابری پشتیبانی کرده‌ایم: google storage، amazon s3، به‌علاوه پشتیبانی از open stack swift. بنابراین، این هم برای ما به‌عنوان یک سرویس و هم برای توسعه‌دهندگانی که با یک راه‌حل بسته‌بندی شده کار می‌کنند راحت بود: اگر آنها فقط از API ما برای کار استفاده کنند، به این فکر نمی‌کنند که فایل در نهایت کجا ذخیره شود، به صورت محلی در سیستم فایل یا در ذخیره سازی فایل شی .
در نتیجه، بلافاصله تصمیم گرفتیم که در سطح کل مرکز داده رزرو کنیم. در سال 2012، ما به طور کامل در آمازون AWS راه اندازی شدیم زیرا قبلاً با این پلتفرم تجربه داشتیم - وب سایت خودمان در آنجا میزبانی می شد. ما با این واقعیت جذب شدیم که در هر منطقه آمازون چندین منطقه در دسترس دارد - در واقع، (در اصطلاح آنها) چندین مرکز داده که کم و بیش مستقل از یکدیگر هستند و به ما اجازه می دهند در سطح کل مرکز داده رزرو کنیم: اگر به طور ناگهانی از کار بیفتد، پایگاه‌های داده Master-Master تکرار می‌شوند، از سرورهای برنامه وب پشتیبان‌گیری می‌شود و داده‌های استاتیک به ذخیره‌سازی شی s3 منتقل می‌شوند. بار متعادل است - در آن زمان توسط آمازون elb ، اما کمی بعد به بار متعادل کننده های خود رسیدیم ، زیرا به منطق پیچیده تری نیاز داشتیم.
چیزی که آنها می خواستند همان چیزی بود که به دست آوردند ...
همه چیزهای اساسی که می خواستیم اطمینان حاصل کنیم - تحمل خطای خود سرورها، برنامه های کاربردی وب، پایگاه های داده - همه چیز به خوبی کار می کرد. ساده ترین سناریو: اگر یکی از برنامه های وب ما خراب شود، همه چیز ساده است - آنها از تعادل خاموش می شوند.
متعادل کننده (در آن زمان elb آمازون بود) ماشین هایی را که از کار افتاده بودند به عنوان ناسالم علامت گذاری کرد و توزیع بار روی آنها را خاموش کرد. مقیاس خودکار آمازون کار کرد: وقتی بار افزایش یافت، ماشین‌های جدید به گروه مقیاس خودکار اضافه شدند، بار در ماشین‌های جدید توزیع شد - همه چیز خوب بود. با متعادل کننده های ما، منطق تقریباً یکسان است: اگر اتفاقی برای سرور برنامه بیفتد، درخواست ها را از آن حذف می کنیم، این ماشین ها را بیرون می اندازیم، ماشین های جدید را راه اندازی می کنیم و به کار ادامه می دهیم. این طرح در طول سال ها کمی تغییر کرده است، اما به کار خود ادامه می دهد: ساده، قابل درک است و هیچ مشکلی با آن وجود ندارد.
ما در سرتاسر جهان کار می کنیم، اوج بار مشتری کاملاً متفاوت است، و به شیوه ای دوستانه، باید بتوانیم خدمات خاصی را در هر زمانی روی هر یک از اجزای سیستم خود انجام دهیم - بدون توجه مشتریان. بنابراین، ما این فرصت را داریم که پایگاه داده را از کار خارج کنیم و بار را به مرکز داده دوم توزیع کنیم.
چطور کار میکند؟ - ما ترافیک را به یک مرکز داده در حال کار تغییر می دهیم - اگر در مرکز داده حادثه ای رخ دهد، به طور کامل، اگر این کار برنامه ریزی شده ما با یک پایگاه داده باشد، بخشی از ترافیک ارائه شده به این مشتریان را به یک مرکز داده دوم تغییر می دهیم و به حالت تعلیق در می آییم. تکثیر آن اگر به ماشین‌های جدیدی برای برنامه‌های تحت وب نیاز باشد، زیرا بار روی مرکز داده دوم افزایش یافته است، به طور خودکار شروع به کار خواهند کرد. کار را تمام می کنیم، Replication بازیابی می شود و کل بار را برمی گردانیم. اگر ما نیاز به آینه کاری در DC دوم داشته باشیم، مثلاً به‌روزرسانی‌های سیستم را نصب کنیم یا تنظیمات را در پایگاه داده دوم تغییر دهیم، به طور کلی، همان کار را فقط در جهت دیگر تکرار می‌کنیم. و اگر این یک تصادف است، پس ما همه چیز را پیش پا افتاده انجام می دهیم: از مکانیزم کنترل کننده رویداد در سیستم نظارت استفاده می کنیم. اگر چندین بررسی فعال شود و وضعیت به بحرانی برسد، این کنترلر را اجرا می کنیم، کنترل کننده ای که می تواند این یا آن منطق را انجام دهد. برای هر پایگاه داده، ما مشخص می کنیم که کدام سرور برای آن failover باشد و در صورت در دسترس نبودن ترافیک باید کجا تغییر کند. از لحاظ تاریخی، ما از nagios یا برخی از چنگال‌های آن به هر شکلی استفاده می‌کنیم. در اصل، مکانیسم‌های مشابهی تقریباً در هر سیستم نظارتی وجود دارد؛ ما هنوز از چیز پیچیده‌تری استفاده نمی‌کنیم، اما شاید روزی از آن استفاده کنیم. اکنون نظارت به دلیل در دسترس نبودن فعال می شود و توانایی تغییر چیزی را دارد.
آیا همه چیز را رزرو کرده ایم؟
ما مشتریان زیادی از ایالات متحده آمریکا، مشتریان زیادی از اروپا، مشتریان زیادی که به شرق نزدیکتر هستند - ژاپن، سنگاپور و غیره داریم. البته سهم زیادی از مشتریان در روسیه هستند. یعنی کار در یک منطقه نیست. کاربران خواهان پاسخ سریع هستند، الزاماتی برای رعایت قوانین محلی مختلف وجود دارد، و در هر منطقه ما دو مرکز داده را رزرو می کنیم، به علاوه برخی خدمات اضافی وجود دارد که باز هم، قرار دادن آنها در یک منطقه راحت است - برای مشتریانی که در این منطقه در حال کار هستند. کنترل‌کننده‌های REST، سرورهای مجوز، آنها برای عملکرد کلاینت به‌عنوان یک کل اهمیت کمتری دارند، می‌توانید با تأخیر قابل قبول کوچکی از طریق آنها جابه‌جا شوید، اما نمی‌خواهید چرخه نحوه نظارت بر آنها و کارهایی که باید انجام دهید را دوباره اختراع کنید. با آنها. بنابراین، ما به جای توسعه نوعی شایستگی در محصولات اضافی، سعی می کنیم از راه حل های موجود حداکثر استفاده کنیم. و در جایی از سوئیچینگ در سطح DNS استفاده می کنیم و زنده بودن سرویس را با همان DNS تعیین می کنیم. آمازون یک سرویس Route 53 دارد، اما این فقط یک DNS نیست که بتوانید در آن وارد شوید و بس - بسیار انعطاف‌پذیرتر و راحت‌تر است. از طریق آن می‌توانید سرویس‌های توزیع‌شده جغرافیایی را با موقعیت‌های جغرافیایی بسازید، زمانی که از آن برای تعیین اینکه مشتری از کجا آمده است استفاده می‌کنید و سوابق خاصی به او می‌دهید - با کمک آن می‌توانید معماری‌های failover بسازید. همان بررسی های سلامت در خود مسیر 53 پیکربندی شده است، شما نقاط پایانی را تنظیم می کنید که نظارت می شوند، معیارها را تنظیم می کنید، تعیین می کنید کدام پروتکل ها "زندگی" سرویس را تعیین می کنند - tcp، http، https. تعداد دفعات بررسی را تنظیم کنید که تعیین می کند آیا سرویس زنده است یا خیر. و در خود DNS مشخص می‌کنید که چه چیزی اولیه باشد، چه چیزی ثانویه باشد، اگر بررسی سلامت در مسیر 53 راه‌اندازی شود، کجا باید جابجا شود. همه اینها را می‌توان با برخی ابزارهای دیگر انجام داد، اما چرا راحت است - ما آن را تنظیم می‌کنیم. یک بار و سپس اصلاً به این فکر نکنید که چگونه چک می کنیم، چگونه تغییر می دهیم: همه چیز خود به خود کار می کند.
اولین "اما": خود مسیر 53 را چگونه و با چه چیزی رزرو کنیم؟ چه کسی می داند اگر اتفاقی برای او بیفتد چه می شود؟ خوشبختانه ما هرگز روی این چنگک نگذاشتیم، اما باز هم داستانی خواهم داشت که چرا فکر می‌کردیم هنوز نیاز به رزرو داریم. در اینجا ما از قبل برای خود نی ریختیم. روزانه چندین بار از تمام زون هایی که در مسیر 53 داریم تخلیه کامل می کنیم. API آمازون به شما این امکان را می دهد که آنها را به راحتی در JSON ارسال کنید، و ما چندین سرور پشتیبان داریم که آن را تبدیل می کنیم، آن را به شکل تنظیمات آپلود می کنیم و به طور کلی، یک پیکربندی پشتیبان داریم. اگر اتفاقی بیفتد، می‌توانیم به سرعت آن را بدون از دست دادن داده‌های تنظیمات DNS به صورت دستی اجرا کنیم.
دوم "اما": چه چیزی در این تصویر هنوز رزرو نشده است؟ خود متعادل کننده! توزیع مشتریان ما بر اساس منطقه بسیار ساده است. ما دامنه های bitrix24.ru، bitrix24.com، .de را داریم - اکنون 13 دامنه مختلف وجود دارد که در مناطق مختلف فعالیت می کنند. ما به موارد زیر رسیدیم: هر منطقه متعادل کننده های خود را دارد. این امر توزیع آن را در مناطق مختلف، بسته به جایی که اوج بار در شبکه است، راحت‌تر میکند. اگر این یک شکست در سطح یک متعادل کننده واحد باشد، به سادگی از سرویس خارج می شود و از dns حذف می شود. اگر با گروهی از متعادل کننده ها مشکلی وجود داشته باشد، در سایت های دیگر از آنها بک آپ گرفته می شود و جابجایی بین آنها با استفاده از همان مسیر انجام می شود. .
سوم "اما": چه چیزی هنوز رزرو نشده است؟ S3، درست است. وقتی فایل‌هایی را که برای کاربران ذخیره می‌کنیم در s3 قرار دادیم، صادقانه معتقد بودیم که زره‌دار است و نیازی به رزرو چیزی در آنجا نیست. اما تاریخ نشان می دهد که اتفاقات متفاوت است. به طور کلی، آمازون S3 را به عنوان یک سرویس اساسی توصیف می کند، زیرا خود آمازون از S3 برای ذخیره تصاویر ماشین، تنظیمات، تصاویر AMI، عکس های فوری ... و اگر s3 خراب شود، همانطور که یک بار در این 7 سال اتفاق افتاده است، تا زمانی که ما از آن استفاده کرده ایم. bitrix24، آن را مانند یک طرفدار دنبال می کند، چیزهای زیادی وجود دارد - ناتوانی در راه اندازی ماشین های مجازی، خرابی api و غیره.
و S3 می تواند سقوط کند - این یک بار اتفاق افتاد. بنابراین، ما به طرح زیر رسیدیم: چند سال پیش در روسیه تأسیسات ذخیره سازی اشیاء عمومی جدی وجود نداشت و ما این گزینه را در نظر گرفتیم که کاری از خودمان انجام دهیم... خوشبختانه، ما این کار را شروع نکردیم، زیرا ما این کار را انجام خواهیم داد. تخصص‌هایی را که نداریم و احتمالاً به هم می‌ریزیم، کشف کرده‌ایم. اکنون Mail.ru دارای فضای ذخیره سازی سازگار با s3، Yandex و تعدادی از ارائه دهندگان دیگر آن را دارند. در نهایت به این ایده رسیدیم که می‌خواهیم اولاً پشتیبان‌گیری داشته باشیم و ثانیاً توانایی کار با نسخه‌های محلی را داشته باشیم. برای منطقه روسیه به طور خاص، ما از سرویس Mail.ru Hotbox استفاده می کنیم که API سازگار با s3 است. ما نیازی به هیچ تغییر عمده ای در کد داخل برنامه نداشتیم و مکانیسم زیر را انجام دادیم: در s3 تریگرهایی وجود دارد که باعث ایجاد/حذف اشیا می شود، آمازون سرویسی به نام Lambda دارد - این یک راه اندازی کد بدون سرور است. که درست زمانی اجرا می شود که تریگرهای خاصی فعال شوند.
ما این کار را خیلی ساده انجام دادیم: اگر تریگر ما فعال شود، کدی را اجرا می کنیم که شی را در فضای ذخیره سازی Mail.ru کپی می کنیم. برای راه‌اندازی کامل کار با نسخه‌های محلی داده‌ها، ما همچنین به همگام‌سازی معکوس نیاز داریم تا مشتریانی که در بخش روسی هستند بتوانند با ذخیره‌سازی نزدیکتر به آنها کار کنند. Mail در حال تکمیل محرک‌های ذخیره‌سازی خود است - امکان همگام‌سازی معکوس در سطح زیرساخت وجود دارد، اما در حال حاضر ما این کار را در سطح کد خود انجام می‌دهیم. اگر دیدیم که یک کلاینت فایلی را ارسال کرده است، در سطح کد رویداد را در یک صف قرار می دهیم، آن را پردازش می کنیم و Reverse Replication را انجام می دهیم. چرا بد است: اگر ما با اشیاء خود در خارج از محصول خود کار کنیم، یعنی از طریق برخی ابزارهای خارجی، آن را در نظر نخواهیم گرفت. بنابراین، تا پایان زمانی که تریگرها در سطح ذخیره سازی ظاهر می شوند، صبر می کنیم تا مهم نیست که کد را از کجا اجرا می کنیم، شیئی که برای ما آمده است در جهت دیگر کپی می شود.
در سطح کد، ما هر دو ذخیره‌سازی را برای هر مشتری ثبت می‌کنیم: یکی اصلی در نظر گرفته می‌شود، دیگری پشتیبان در نظر گرفته می‌شود. اگر همه چیز خوب باشد، ما با فضای ذخیره‌سازی نزدیکتر کار می‌کنیم: یعنی مشتریان ما که در آمازون هستند، با S3 کار می‌کنند و کسانی که در روسیه کار می‌کنند، با Hotbox کار می‌کنند. اگر پرچم راه‌اندازی شود، باید failover متصل شود و کلاینت‌ها را به فضای ذخیره‌سازی دیگری تغییر دهیم. ما می‌توانیم این کادر را به‌طور مستقل بر اساس منطقه بررسی کنیم و می‌توانیم آنها را به عقب و جلو تغییر دهیم. ما هنوز در عمل از آن استفاده نکرده‌ایم، اما این مکانیسم را فراهم کرده‌ایم و فکر می‌کنیم که روزی به همین سوئیچ نیاز خواهیم داشت و به کارمان می‌آید. این قبلا یک بار اتفاق افتاده است.
اوه و آمازون فرار کرد...
آوریل امسال سالگرد آغاز مسدودسازی تلگرام در روسیه است. متاثرترین ارائه دهنده ای که تحت این امر قرار گرفت آمازون است. و متأسفانه شرکت‌های روسی که برای کل دنیا کار می‌کردند بیشتر آسیب دیدند.
اگر این شرکت جهانی است و روسیه برای آن بخش بسیار کوچکی است، 3-5٪ - خوب، به هر طریقی، می توانید آنها را قربانی کنید.
اگر این یک شرکت کاملاً روسی است - من مطمئن هستم که باید در محلی واقع شود - خوب، برای خود کاربران راحت خواهد بود، راحت است و خطرات کمتری وجود خواهد داشت.
اگر این شرکتی است که در سطح جهانی فعالیت می کند و تقریباً تعداد مساوی مشتری از روسیه و سایر نقاط جهان دارد؟ اتصال سگمنت ها مهم است و آنها باید به طریقی با یکدیگر کار کنند.
در پایان مارس 2018، Roskomnadzor نامه ای به بزرگترین اپراتورها ارسال کرد که در آن اعلام کرد که قصد دارند چندین میلیون IP آمازون را به منظور مسدود کردن پیام رسان Zello مسدود کنند. با تشکر از همین ارائه دهندگان - آنها با موفقیت نامه را به همه فاش کردند و این درک وجود داشت که ارتباط با آمازون ممکن است از بین برود. جمعه بود، ما با وحشت به همکاران خود از servers.ru دویدیم و گفتیم: "دوستان، ما به چندین سرور نیاز داریم که نه در روسیه، نه در آمازون، بلکه به عنوان مثال، در جایی در آمستردام واقع شوند." برای اینکه بتوانیم حداقل به نحوی VPN و پروکسی خودمان را برای برخی از نقاط پایانی که نمی توانیم به هیچ وجه روی آنها تأثیر بگذاریم نصب کنیم، به عنوان مثال endpont های همان s3 - نمی توانیم سعی کنیم یک سرویس جدید را بالا ببریم و یک ip متفاوت دریافت کنیم. ما هنوز باید به آنجا برسید فقط در چند روز، ما این سرورها را راه اندازی کردیم، آنها را راه اندازی کردیم و به طور کلی برای لحظه شروع مسدودسازی آماده شدیم. کنجکاو است که RKN، با نگاه کردن به هیاهو و وحشت، گفت: "نه، ما در حال حاضر چیزی را مسدود نمی کنیم." (اما این دقیقاً تا لحظه‌ای است که تلگرام شروع به مسدود شدن کرد.) با راه‌اندازی قابلیت‌های بای‌پس و فهمیدن اینکه مسدودسازی معرفی نشده است، اما شروع به حل کردن کل موضوع نکردیم. بله، برای هر موردی.
و در سال 2019، ما هنوز در شرایط مسدود شدن زندگی می کنیم. دیشب نگاه کردم: حدود یک میلیون IP همچنان مسدود است. درسته آمازون تقریباً کاملاً رفع انسداد شده بود، در اوج به 20 میلیون آدرس رسید... در کل واقعیت این است که ممکن است انسجام وجود نداشته باشد، انسجام خوب. ناگهان. ممکن است به دلایل فنی وجود نداشته باشد - آتش سوزی، بیل مکانیکی، همه اینها. یا همانطور که دیدیم کاملاً فنی نیست. بنابراین، یک فرد بزرگ و بزرگ، با AS خود، احتمالا می تواند این را به روش های دیگری مدیریت کند - اتصال مستقیم و چیزهای دیگر در حال حاضر در سطح l2 هستند. اما در یک نسخه ساده، مانند ما یا حتی کوچکتر، می توانید، فقط در صورت نیاز، افزونگی در سطح سرورهایی که در جای دیگری افزایش یافته است، از قبل vpn، پروکسی پیکربندی شده است، با قابلیت تغییر سریع پیکربندی به آنها در آن ها بخش هایی که برای اتصال شما حیاتی هستند. این بیش از یک بار برای ما مفید بود، زمانی که مسدود کردن آمازون شروع شد؛ در بدترین حالت، ما فقط به S3 اجازه عبور از آنها را دادیم، اما به تدریج همه اینها حل شد.
چگونه می توان یک ارائه دهنده کامل را رزرو کرد؟
در حال حاضر سناریویی برای از بین رفتن کل آمازون نداریم. سناریوی مشابهی برای روسیه داریم. در روسیه، ما توسط یک ارائه دهنده میزبانی شدیم که از بین او چندین سایت را انتخاب کردیم. و یک سال پیش با مشکلی مواجه شدیم: حتی اگر این دو مرکز داده هستند، ممکن است مشکلاتی در سطح پیکربندی شبکه ارائه دهنده وجود داشته باشد که همچنان بر هر دو مرکز داده تأثیر می گذارد. و ممکن است در هر دو سایت در دسترس نباشیم. البته این اتفاق افتاد. ما در نهایت به تجدید نظر در معماری داخل رسیدیم. خیلی تغییر نکرده است، اما برای روسیه اکنون دو سایت داریم که از یک ارائه دهنده نیستند، بلکه از دو سایت متفاوت هستند. اگر یکی ناموفق باشد، می توانیم به دیگری سوئیچ کنیم.
به طور فرضی، برای آمازون ما در حال بررسی امکان رزرو در سطح ارائه دهنده دیگری هستیم. شاید گوگل، شاید شخص دیگری... اما تاکنون در عمل مشاهده کرده ایم که در حالی که آمازون تصادفاتی در سطح یک منطقه در دسترس دارد، تصادفات در سطح کل منطقه بسیار نادر است. بنابراین، ما از نظر تئوری این ایده را داریم که ممکن است رزرو «آمازون آمازون نیست» را انجام دهیم، اما در عمل هنوز اینطور نیست.
چند کلمه در مورد اتوماسیون
آیا اتوماسیون همیشه لازم است؟ در اینجا مناسب است که اثر دانینگ-کروگر را یادآوری کنیم. در محور "x" دانش و تجربه ما است که به دست می آوریم و در محور "y" اعتماد به اعمالمان است. در ابتدا چیزی نمی دانیم و اصلاً مطمئن نیستیم. سپس کمی می دانیم و اعتماد به نفس بالایی پیدا می کنیم - این به اصطلاح "اوج حماقت" است که با تصویر "زوال عقل و شجاعت" به خوبی نشان داده شده است. سپس کمی آموخته ایم و آماده رفتن به جنگ هستیم. سپس بر روی برخی اشتباهات بزرگ قدم می گذاریم و خود را در دره ای از ناامیدی می یابیم، زمانی که به نظر می رسد چیزی را می دانیم، اما در واقع چیز زیادی نمی دانیم. سپس با کسب تجربه، اعتماد به نفس بیشتری پیدا می کنیم.
منطق ما در مورد سوئیچ های خودکار مختلف برای حوادث خاص به خوبی در این نمودار توضیح داده شده است. ما شروع کردیم - نمی دانستیم چگونه کاری انجام دهیم، تقریباً تمام کارها با دست انجام شد. سپس متوجه شدیم که می‌توانیم اتوماسیون را به همه چیز متصل کنیم و مثلاً با آرامش بخوابیم. و ناگهان روی یک مگا ریک قدم می گذاریم: یک مثبت کاذب ایجاد می شود، و زمانی که به طرز خوب، نباید این کار را می کردیم، ترافیک را به عقب و جلو تغییر می دهیم. در نتیجه، همانندسازی از بین می‌رود یا چیز دیگری - این همان وادی ناامیدی است. و سپس به این درک می رسیم که باید عاقلانه به همه چیز نزدیک شویم. یعنی منطقی است که بر اتوماسیون تکیه کنیم و امکان هشدارهای نادرست را فراهم کنیم. ولی! اگر عواقب آن می تواند ویرانگر باشد، پس بهتر است کار را به شیفت وظیفه بسپاریم، به مهندسان کشیک، که مطمئن می شوند و نظارت می کنند که واقعاً حادثه ای وجود دارد و اقدامات لازم را به صورت دستی انجام می دهند ...
نتیجه
در طول 7 سال، ما از این واقعیت که وقتی چیزی سقوط کرد، وحشت و هراس به وجود آمد، به این درک رسیدیم که مشکلات وجود ندارند، فقط وظایف هستند، آنها باید - و می توانند - حل شوند. هنگامی که در حال ساخت یک سرویس هستید، از بالا به آن نگاه کنید، تمام خطراتی را که ممکن است رخ دهد ارزیابی کنید. اگر فوراً آنها را مشاهده کردید، از قبل افزونگی و امکان ایجاد زیرساخت مقاوم در برابر خطا را فراهم کنید، زیرا هر نقطه ای که ممکن است از کار بیفتد و منجر به عدم کارکرد سرویس شود، قطعاً این کار را انجام می دهد. و حتی اگر به نظر شما می رسد که برخی از عناصر زیرساخت قطعاً شکست نخواهند خورد - مانند s3، همچنان به خاطر داشته باشید که آنها می توانند. و حداقل در تئوری، ایده ای داشته باشید که اگر اتفاقی بیفتد، با آنها چه خواهید کرد. یک برنامه مدیریت ریسک داشته باشید. وقتی به انجام همه کارها به صورت خودکار یا دستی فکر می کنید، خطرات را ارزیابی کنید: اگر اتوماسیون شروع به تغییر همه چیز کند چه اتفاقی می افتد - آیا این منجر به وضعیت بدتر در مقایسه با تصادف نمی شود؟ شاید در جایی لازم باشد از یک مصالحه معقول بین استفاده از اتوماسیون و واکنش مهندس در حال کار استفاده شود، که تصویر واقعی را ارزیابی می کند و می فهمد که آیا چیزی باید در محل تغییر کند یا "بله، اما نه اکنون".
یک سازش معقول بین کمال گرایی و تلاش واقعی، زمان، پولی که می توانید برای طرحی که در نهایت خواهید داشت خرج کنید.
این متن نسخه به روز شده و توسعه یافته گزارش الکساندر دمیدوف در کنفرانس است .
منبع: www.habr.com