HighLoad++، Evgeniy Kuzovlev (EcommPay IT): وقتی یک دقیقه توقف 100000 دلار هزینه دارد چه باید کرد

همه در مورد فرآیندهای توسعه و آزمایش، آموزش کارکنان، افزایش انگیزه صحبت می کنند، اما این فرآیندها زمانی که یک دقیقه از کار افتادگی خدمات هزینه هنگفتی را به همراه دارد کافی نیست. هنگام انجام تراکنش های مالی تحت یک SLA سختگیرانه چه باید کرد؟ چگونه می توان قابلیت اطمینان و تحمل خطا سیستم های خود را افزایش داد و توسعه و آزمایش را از معادله خارج کرد؟

کنفرانس بعدی HighLoad++ در تاریخ 6 و 7 آوریل 2020 در سن پترزبورگ برگزار خواهد شد. جزئیات و بلیط برای پیوند. 9 نوامبر ساعت 18:00. HighLoad++ Moscow 2018، دهلی + سالن کلکته. پایان نامه ها و ارائه.

Evgeniy Kuzovlev (از این پس - EC): - دوستان، سلام! نام من Kuzovlev Evgeniy است. من از شرکت EcommPay هستم، یک بخش خاص EcommPay IT است، بخش فناوری اطلاعات گروه شرکت ها. و امروز ما در مورد زمان های خرابی صحبت خواهیم کرد - در مورد چگونگی اجتناب از آنها، در مورد چگونگی به حداقل رساندن عواقب آنها در صورت عدم اجتناب از آن. موضوع به شرح زیر است: "وقتی یک دقیقه توقف 100 دلار هزینه دارد چه باید کرد"؟ با نگاهی به آینده، اعداد ما قابل مقایسه هستند.

EcommPay IT چه می کند؟

ما که هستیم؟ چرا من اینجا جلوی تو ایستاده ام؟ چرا من حق دارم اینجا چیزی به شما بگویم؟ و در اینجا با جزئیات بیشتر در مورد چه چیزی صحبت خواهیم کرد؟

گروه شرکت های EcommPay یک خریدار بین المللی است. ما پرداخت ها را در سراسر جهان - در روسیه، اروپا، آسیای جنوب شرقی (در سراسر جهان) پردازش می کنیم. ما 9 دفتر داریم که در مجموع 500 کارمند داریم و تقریباً کمی کمتر از نیمی از آنها متخصص فناوری اطلاعات هستند. هر کاری که انجام می دهیم، هر کاری که از آن پول در می آوریم، خودمان انجام دادیم.

ما همه محصولات خود را نوشتیم (و تعداد زیادی از آنها را داریم - در خط تولیدات بزرگ فناوری اطلاعات ما حدود 16 جزء مختلف داریم) خودمان. ما خودمان می نویسیم، خودمان را توسعه می دهیم. و در حال حاضر حدود یک میلیون تراکنش در روز انجام می دهیم (میلیون ها احتمالاً راه درستی برای بیان آن است). ما یک شرکت نسبتاً جوان هستیم - ما فقط حدود شش سال سن داریم.

6 سال پیش زمانی که بچه ها با این تجارت همراه شدند، چنین استارتاپی بود. آنها با یک ایده متحد شدند (چیزی جز یک ایده وجود نداشت) و ما فرار کردیم. مثل هر استارتاپی سریعتر دویدیم... برای ما سرعت مهمتر از کیفیت بود.

در نقطه‌ای متوقف شدیم: متوجه شدیم که دیگر نمی‌توانیم با آن سرعت و کیفیت زندگی کنیم و باید ابتدا روی کیفیت تمرکز کنیم. در این لحظه، تصمیم گرفتیم یک پلتفرم جدید بنویسیم که صحیح، مقیاس پذیر و قابل اعتماد باشد. آنها شروع به نوشتن این پلت فرم کردند (آنها شروع به سرمایه گذاری، توسعه توسعه، آزمایش کردند)، اما در مقطعی متوجه شدند که توسعه و آزمایش به ما اجازه نمی دهد به سطح جدیدی از کیفیت خدمات برسیم.

شما یک محصول جدید می سازید، آن را وارد مرحله تولید می کنید، اما باز هم یک جایی مشکلی پیش می آید. و امروز در مورد چگونگی رسیدن به یک سطح کیفی جدید (چگونه این کار را انجام دادیم، در مورد تجربه خود)، خارج کردن توسعه و آزمایش از معادله صحبت خواهیم کرد. ما در مورد آنچه در دسترس است صحبت خواهیم کرد - چه عملیاتی می تواند به خودی خود انجام دهد، چه چیزی می تواند برای آزمایش به منظور تأثیرگذاری بر کیفیت ارائه دهد.

خرابی ها دستورات عملیات

همیشه سنگ بنای اصلی، چیزی که ما در واقع امروز در مورد آن صحبت خواهیم کرد، خرابی است. یک کلمه وحشتناک اگر تعطیلی داشته باشیم، همه چیز برای ما بد است. داریم می دویم بالاش، ادمین ها سرور رو نگه می دارن - خدا نکنه به قول اون آهنگ نیفتاد. این همان چیزی است که امروز در مورد آن صحبت خواهیم کرد.

وقتی شروع به تغییر رویکردهایمان کردیم، 4 فرمان را تشکیل دادیم. من آنها را در اسلایدها ارائه کرده ام:

این دستورات بسیار ساده هستند:

• به سرعت مشکل را شناسایی کنید.
• حتی سریعتر از شر آن خلاص شوید.
• به درک دلیل (بعداً برای توسعه دهندگان) کمک کنید.
• و رویکردها را استاندارد کنید.

توجه شما را به نکته شماره 2 جلب می کنم ما داریم از شر مشکل خلاص می شویم نه حل آن. تصمیم گیری ثانویه است. برای ما، نکته اصلی این است که کاربر از این مشکل محافظت شود. در یک محیط ایزوله وجود خواهد داشت، اما این محیط هیچ تماسی با آن نخواهد داشت. در واقع، ما از طریق این چهار گروه از مشکلات (بعضی با جزئیات بیشتر، برخی با جزئیات کمتر)، به شما خواهم گفت که از چه چیزی استفاده می کنیم، چه تجربه مرتبطی در راه حل ها داریم.

عیب‌یابی: چه زمانی اتفاق می‌افتند و چه باید کرد؟

اما ما بدون نظم شروع می کنیم، با نقطه شماره 2 شروع می کنیم - چگونه به سرعت از شر مشکل خلاص شویم؟ مشکلی وجود دارد - باید آن را برطرف کنیم. "در این مورد چه باید بکنیم؟" - سوال اصلی و وقتی شروع به فکر کردن در مورد چگونگی رفع مشکل کردیم، برخی از الزامات را برای خود ایجاد کردیم که عیب‌یابی باید از آنها پیروی کند.

برای تدوین این الزامات، تصمیم گرفتیم این سوال را از خود بپرسیم: "چه زمانی مشکل داریم"؟ و مشکلات، همانطور که معلوم شد، در چهار مورد رخ می دهد:

• خرابی سخت افزار.
• خدمات خارجی ناموفق بود.
• تغییر نسخه نرم افزار (همان استقرار).
• رشد بار انفجاری

ما در مورد دو مورد اول صحبت نمی کنیم. یک نقص سخت افزاری را می توان به سادگی حل کرد: شما باید همه چیز را تکرار کنید. اگر این ها دیسک هستند، دیسک ها باید در RAID مونتاژ شوند؛ اگر این سرور است، سرور باید کپی شده باشد؛ اگر زیرساخت شبکه دارید، باید یک نسخه دوم از زیرساخت شبکه را تهیه کنید، یعنی آن را بردارید و آن را کپی کنید و اگر چیزی خراب شد، به برق ذخیره می روید. گفتن چیزی بیشتر در اینجا دشوار است.

دوم شکست خدمات خارجی است. برای اکثر افراد، سیستم اصلاً مشکلی ندارد، اما برای ما مشکلی نیست. از آنجایی که ما پرداخت‌ها را پردازش می‌کنیم، جمع‌کننده‌ای هستیم که بین کاربر (که اطلاعات کارت خود را وارد می‌کند) و بانک‌ها، سیستم‌های پرداخت (ویزا، مسترکارت، میرا و غیره) قرار می‌گیریم. خدمات خارجی ما (سیستم های پرداخت، بانک ها) تمایل به شکست دارند. نه ما و نه شما (اگر چنین خدماتی دارید) نمی توانیم بر این موضوع تأثیر بگذاریم.

آن وقت چه باید کرد؟ در اینجا دو گزینه وجود دارد. اول، اگر می توانید، باید این سرویس را به نحوی کپی کنید. به عنوان مثال، اگر بتوانیم، ترافیک را از یک سرویس به سرویس دیگر منتقل می کنیم: به عنوان مثال، کارت ها از طریق Sberbank پردازش شدند، Sberbank مشکل دارد - ما ترافیک را [مشروط] به Raiffeisen منتقل می کنیم. دومین کاری که می توانیم انجام دهیم این است که خیلی سریع متوجه خرابی سرویس های خارجی شویم و بنابراین در قسمت بعدی گزارش در مورد سرعت پاسخگویی صحبت خواهیم کرد.

در واقع، از این چهار، ما می توانیم به طور خاص بر تغییر نسخه های نرم افزار تأثیر بگذاریم - اقداماتی انجام دهیم که منجر به بهبود وضعیت در زمینه استقرار و در زمینه رشد انفجاری بار شود. در واقع، این کاری است که ما انجام دادیم. در اینجا دوباره یک یادداشت کوچک ...

از این چهار مشکل، اگر ابری داشته باشید، چندین مشکل بلافاصله حل می شود. اگر در Microsoft Azhur، ابرهای Ozone هستید یا از ابرهای ما از Yandex یا Mail استفاده می کنید، حداقل یک نقص سخت افزاری مشکل آنها می شود و همه چیز بلافاصله در زمینه یک نقص سخت افزاری برای شما خوب می شود.

ما یک شرکت کمی غیر متعارف هستیم. در اینجا همه در مورد "Kubernets"، در مورد ابرها صحبت می کنند - ما نه "Kubernets" داریم و نه ابر. اما ما در بسیاری از مراکز داده قفسه‌های سخت‌افزاری داریم و مجبوریم با این سخت‌افزار زندگی کنیم، مجبوریم مسئول همه آن باشیم. بنابراین، ما در این زمینه صحبت خواهیم کرد. بنابراین، در مورد مشکلات. دو مورد اول از پرانتز خارج شدند.

تغییر نسخه نرم افزار پایه ها

توسعه دهندگان ما به تولید دسترسی ندارند. چرا اینطور است؟ فقط این است که ما دارای گواهینامه PCI DSS هستیم و توسعه دهندگان ما به سادگی حق ورود به "محصول" را ندارند. همین، دوره. اصلا بنابراین، مسئولیت توسعه دقیقاً در لحظه ای پایان می یابد که توسعه، بیلد را برای انتشار ارسال می کند.

مبنای دوم ما که به ما کمک زیادی می کند، نبود دانش غیرمستند منحصر به فرد است. امیدوارم برای شما هم همینطور باشد. چون اگر اینطور نباشد دچار مشکل خواهید شد. مشکلات زمانی به وجود می آیند که این دانش منحصر به فرد و غیرمستند در زمان مناسب در مکان مناسب وجود نداشته باشد. فرض کنید شما یک نفر دارید که می داند چگونه یک جزء خاص را به کار ببندد - آن شخص آنجا نیست، در تعطیلات است یا بیمار است - همین است، شما مشکل دارید.

و پایه سومی که به آن رسیده ایم. ما از طریق درد، خون، اشک به آن رسیدیم - به این نتیجه رسیدیم که هر یک از ساخت های ما دارای خطا است، حتی اگر بدون خطا باشد. ما این را برای خودمان تصمیم گرفتیم: وقتی چیزی را مستقر می کنیم، وقتی چیزی را وارد تولید می کنیم، یک ساخت با خطا داریم. ما الزاماتی را شکل داده ایم که سیستم ما باید آنها را برآورده کند.

الزامات تغییر نسخه نرم افزار

سه الزام وجود دارد:

• ما باید به سرعت استقرار را به عقب برگردانیم.
• ما باید تأثیر یک استقرار ناموفق را به حداقل برسانیم.
• و ما باید بتوانیم به سرعت به صورت موازی مستقر شویم.
  دقیقا به همین ترتیب! چرا؟ زیرا اول از همه، هنگام استقرار یک نسخه جدید، سرعت مهم نیست، اما برای شما مهم است که اگر مشکلی پیش آمد، سریع به عقب برگردید و کمترین تأثیر را داشته باشید. اما اگر مجموعه‌ای از نسخه‌ها را در حال تولید دارید، که مشخص می‌شود خطایی وجود دارد (خارج از استقرار، اما خطا وجود دارد) - سرعت استقرار بعدی برای شما مهم است. برای پاسخگویی به این مطالبات چه کرده ایم؟ ما به روش زیر متوسل شدیم:

  
  
  کاملاً شناخته شده است، ما هرگز آن را اختراع نکرده ایم - این استقرار آبی/سبز است. آن چیست؟ شما باید برای هر گروه از سرورهایی که برنامه های شما روی آنها نصب شده اند، یک کپی داشته باشید. کپی "گرم" است: هیچ ترافیکی روی آن وجود ندارد، اما در هر لحظه می توان این ترافیک را به این نسخه ارسال کرد. این نسخه حاوی نسخه قبلی است. و در زمان استقرار، کد را در یک کپی غیرفعال قرار می دهید. سپس بخشی از ترافیک (یا همه) را به نسخه جدید تغییر می دهید. بنابراین، برای تغییر جریان ترافیک از نسخه قدیمی به نسخه جدید، شما باید تنها یک اقدام را انجام دهید: باید متعادل کننده را در بالادست تغییر دهید، جهت را تغییر دهید - از یک بالادست به دیگری. این بسیار راحت است و مشکل تعویض سریع و برگشت سریع را حل می کند.

  در اینجا راه حل سوال دوم به حداقل رساندن است: شما می توانید تنها بخشی از ترافیک خود را به یک خط جدید ارسال کنید، به یک خط با یک کد جدید (به عنوان مثال، 2٪). و این 2% 100% نیستند! اگر 100٪ از ترافیک خود را به دلیل استقرار ناموفق از دست بدهید، ترسناک است؛ اگر 2٪ از ترافیک خود را از دست بدهید، ناخوشایند است، اما ترسناک نیست. علاوه بر این، کاربران به احتمال زیاد حتی متوجه این موضوع نخواهند شد، زیرا در برخی موارد (نه در همه موارد) همان کاربر با فشار دادن F5 به نسخه کارآمد دیگری منتقل می شود.

  آبی/سبز استقرار. مسیریابی

  با این حال، همه چیز به این سادگی نیست "Blue/Green Deploy"... همه اجزای ما را می توان به سه گروه تقسیم کرد:

  • این قسمت جلویی (صفحات پرداختی که مشتریان ما می بینند) است.
  • هسته پردازشی؛
  • آداپتور برای کار با سیستم های پرداخت (بانک ها، مسترکارت، ویزا...).

  و یک تفاوت ظریف در اینجا وجود دارد - تفاوت ظریف در مسیریابی بین خطوط نهفته است. اگر فقط 100% ترافیک را تغییر دهید، این مشکلات را ندارید. اما اگر بخواهید 2% را تغییر دهید، شروع به پرسیدن سوال می کنید: "چگونه این کار را انجام دهیم؟" ساده‌ترین چیز مستقیم است: شما می‌توانید Round Robin را با انتخاب تصادفی در nginx راه‌اندازی کنید و 2% در سمت چپ و 98% در سمت راست دارید. اما این همیشه مناسب نیست.

  به عنوان مثال، در مورد ما، یک کاربر با بیش از یک درخواست با سیستم تعامل دارد. این طبیعی است: 2، 3، 4، 5 درخواست - سیستم شما ممکن است یکسان باشد. و اگر برای شما مهم است که تمام درخواست‌های کاربر به همان خطی برسند که درخواست اول روی آن آمده است یا (نقطه دوم) همه درخواست‌های کاربر پس از سوئیچ به خط جدید بیایند (او می‌توانست زودتر با سیستم، قبل از سوئیچ)، - پس این توزیع تصادفی برای شما مناسب نیست. سپس گزینه های زیر وجود دارد:

  
  
  اولین گزینه، ساده ترین، بر اساس پارامترهای اساسی مشتری (IP Hash) است. شما یک IP دارید و آن را از راست به چپ بر اساس آدرس IP تقسیم می کنید. سپس مورد دومی که توضیح دادم برای شما کار خواهد کرد، هنگامی که استقرار رخ داد، کاربر می تواند از قبل با سیستم شما شروع به کار کند و از لحظه استقرار همه درخواست ها به یک خط جدید (مثلاً به همان خط) می روند.

  اگر به دلایلی این مورد برای شما مناسب نیست و باید درخواست‌ها را به خطی که درخواست اولیه و اولیه کاربر ارسال شده است ارسال کنید، دو گزینه دارید...
  گزینه اول: می توانید nginx+ پولی بخرید. مکانیزم Sticky sessions وجود دارد که بنا به درخواست اولیه کاربر، یک جلسه را به کاربر اختصاص می‌دهد و آن را به یک یا آن بالادست متصل می‌کند. تمام درخواست‌های بعدی کاربر در طول عمر جلسه به همان بالادستی که جلسه پست شده ارسال می‌شود.

  این برای ما مناسب نبود زیرا قبلاً nginx معمولی داشتیم. تغییر به +nginx به این معنا نیست که گران است، فقط این است که برای ما تا حدودی دردناک بود و خیلی هم درست نبود. برای مثال، «Sticks Sessions» برای ما کار نمی‌کند، به این دلیل ساده که «Sticks Sessions» اجازه مسیریابی بر اساس «یا-یا» را نمی‌دهد. در آنجا می‌توانید مشخص کنید که ما «Sticks Sessions» چه کاری انجام می‌دهیم، به‌عنوان مثال، با آدرس IP یا آدرس IP و کوکی‌ها یا با پارامترهای پسا، اما «یا-یا» در آنجا پیچیده‌تر است.

  بنابراین به گزینه چهارم رسیدیم. ما nginx را روی استروئیدها مصرف کردیم (این openresty است) - این همان nginx است که علاوه بر این از گنجاندن آخرین اسکریپت ها پشتیبانی می کند. شما می توانید آخرین اسکریپت را بنویسید، به آن استراحت دهید و این آخرین اسکریپت زمانی که درخواست کاربر آمد اجرا می شود.

  و ما در واقع چنین اسکریپتی را نوشتیم، خود را "openresti" تنظیم کردیم و در این اسکریپت 6 پارامتر مختلف را با الحاق "Or" مرتب می کنیم. بسته به وجود یک یا آن پارامتر، می دانیم که کاربر به یک صفحه یا آن صفحه، یک خط یا خط دیگر آمده است.

  آبی/سبز استقرار. مزایا و معایب

  البته شاید بتوان آن را کمی ساده‌تر کرد (از همان «Sticky Sessions» استفاده کنید)، اما ما نیز چنین تفاوت ظریفی داریم که نه تنها کاربر در چارچوب یک پردازش یک تراکنش با ما تعامل می‌کند... اما سیستم های پرداخت نیز با ما تعامل دارند: پس از پردازش تراکنش (با ارسال درخواست به سیستم پرداخت)، یک کول بک دریافت می کنیم.
  و فرض کنید، اگر در داخل مدار خود بتوانیم آدرس IP کاربر را در همه درخواست‌ها فوروارد کنیم و کاربران را بر اساس آدرس IP تقسیم کنیم، آنگاه به همان "ویزا" نخواهیم گفت: "رفیق، ما یک شرکت قدیمی هستیم، به نظر می رسد. بین المللی بودن (در وب سایت و روسیه)... لطفاً آدرس IP کاربر را در یک قسمت اضافی در اختیار ما قرار دهید، پروتکل شما استاندارد شده است»! معلوم است که موافق نیستند.

  
  
  بنابراین، این برای ما کار نکرد - ما openresty را انجام دادیم. بر این اساس، با مسیریابی چیزی شبیه به این دریافت کردیم:

  بر این اساس، استقرار آبی/سبز دارای مزایا و معایبی است که ذکر کردم.

  دو عیب:

  • شما باید با مسیریابی زحمت بکشید.
  • دومین نقطه ضعف اصلی هزینه است.

  شما به دو برابر بیشتر سرور نیاز دارید، به دو برابر منابع عملیاتی نیاز دارید، باید دو برابر بیشتر تلاش کنید تا کل این باغ وحش را نگهداری کنید.

  ضمناً در بین مزایا یک چیز دیگر وجود دارد که قبلاً به آن اشاره نکرده ام: در صورت افزایش بار ذخیره دارید. اگر رشد انفجاری در بار دارید، تعداد کاربران زیادی دارید، سپس به سادگی خط دوم را در توزیع 50 تا 50 قرار می دهید - و بلافاصله سرورهای x2 را در خوشه خود خواهید داشت تا زمانی که مشکل داشتن سرورهای بیشتر را حل کنید.

  چگونه یک استقرار سریع انجام دهیم؟

  ما در مورد چگونگی حل مشکل کمینه سازی و بازگشت سریع صحبت کردیم، اما این سوال باقی می ماند: "چگونه سریع مستقر شویم؟"

  
  
  اینجا کوتاه و ساده است.

  • شما باید یک سیستم CD (تحویل مداوم) داشته باشید - بدون آن نمی توانید زندگی کنید. اگر یک سرور دارید، می توانید به صورت دستی مستقر کنید. ما حدود یک و نیم هزار سرور و یک و نیم هزار دستگیره داریم، البته - می‌توانیم یک بخش به اندازه این اتاق را فقط برای استقرار ایجاد کنیم.
  • استقرار باید موازی باشد. اگر استقرار شما متوالی است، پس همه چیز بد است. یک سرور طبیعی است، شما یک و نیم هزار سرور را در تمام روز مستقر خواهید کرد.
  • باز هم، برای شتاب، این احتمالا دیگر ضروری نیست. در طول استقرار، پروژه معمولا ساخته می شود. شما یک پروژه وب دارید، یک بخش front-end وجود دارد (شما یک بسته وب را در آنجا انجام می دهید، npm را کامپایل می کنید - چیزی شبیه به آن)، و این روند، در اصل، کوتاه مدت است - 5 دقیقه، اما این 5 دقیقه می تواند انتقادی باشد به همین دلیل است که، برای مثال، ما این کار را انجام نمی دهیم: ما این 5 دقیقه را حذف کردیم، مصنوعات را مستقر می کنیم.

    مصنوع چیست؟ مصنوع یک ساختمان مونتاژ شده است که در آن تمام قطعات مونتاژ قبلاً تکمیل شده است. ما این مصنوع را در انبار مصنوعات ذخیره می کنیم. زمانی ما از دو نوع ذخیره‌سازی استفاده می‌کردیم - Nexus و اکنون jFrog Artifactory) ما در ابتدا از "Nexus" استفاده کردیم زیرا شروع به تمرین این رویکرد در برنامه‌های جاوا کردیم (به خوبی با آن سازگار بود). سپس برخی از برنامه های کاربردی نوشته شده با PHP را در آنجا قرار دادند. و "Nexus" دیگر مناسب نبود و بنابراین ما jFrog Artefactory را انتخاب کردیم که می تواند تقریباً همه چیز را مصنوعی کند. ما حتی به این نقطه رسیده ایم که در این مخزن مصنوع، بسته های باینری خود را که برای سرورها جمع آوری می کنیم، ذخیره می کنیم.

  رشد بار انفجاری

  در مورد تغییر نسخه نرم افزار صحبت کردیم. مورد بعدی که داریم افزایش انفجاری بار است. در اینجا، احتمالاً منظور من از رشد انفجاری بار، چیز درستی نیست...

  ما یک سیستم جدید نوشتیم - سرویس گرا، مد روز، زیبا، کارگران همه جا، صف در همه جا، ناهمزمان در همه جا. و در چنین سیستم هایی، داده ها می توانند از طریق جریان های مختلف جریان داشته باشند. برای اولین تراکنش، می توان از کارگر 1، 3، 10 استفاده کرد، برای معامله دوم - 2، 4، 5. و امروز، بیایید بگوییم، صبح شما یک جریان داده دارید که از سه کارگر اول استفاده می کند، و در عصر به طرز چشمگیری تغییر می کند، و همه چیز از سه کارگر دیگر استفاده می کند.

  و در اینجا معلوم می شود که شما باید به نحوی کارگران را مقیاس بندی کنید، باید به نحوی خدمات خود را مقیاس بندی کنید، اما در عین حال از نفخ منابع جلوگیری کنید.

  
  
  ما الزامات خود را مشخص کرده ایم. این الزامات بسیار ساده هستند: کشف خدمات، پارامترسازی - همه چیز برای ساخت چنین سیستم های مقیاس پذیر استاندارد است، به جز یک نقطه - استهلاک منابع. گفتیم حاضر نیستیم منابع را استهلاک کنیم تا سرورها هوا را گرم کنند. «کنسول» را گرفتیم، «نوماد» را گرفتیم که کارگران ما را مدیریت می کند.

  چرا این برای ما مشکل دارد؟ بیایید کمی به عقب برگردیم. ما اکنون حدود 70 سیستم پرداخت را پشت سر داریم. صبح، ترافیک از طریق Sberbank می گذرد، سپس Sberbank به عنوان مثال سقوط کرد و ما آن را به سیستم پرداخت دیگری تغییر می دهیم. ما قبل از Sberbank 100 کارگر داشتیم و پس از آن باید 100 کارگر را برای یک سیستم پرداخت دیگر افزایش دهیم. و مطلوب است که همه اینها بدون مشارکت انسان اتفاق بیفتد. زیرا اگر مشارکت انسانی وجود داشته باشد، باید یک مهندس 24 ساعته در آنجا بنشیند که فقط باید این کار را انجام دهد، زیرا این گونه خرابی ها وقتی 7 سیستم پشت شما هستند، مرتباً اتفاق می افتد.

  بنابراین، ما به Nomad که یک IP باز دارد نگاه کردیم و چیز خودمان را نوشتیم، Scale-Nomad - ScaleNo، که تقریباً کارهای زیر را انجام می دهد: رشد صف را نظارت می کند و بسته به دینامیک تعداد کارگران را کاهش یا افزایش می دهد. از صف وقتی این کار را انجام دادیم، فکر کردیم: "شاید بتوانیم آن را منبع باز کنیم؟" سپس به او نگاه کردند - او به اندازه دو کوپک ساده بود.

  تا کنون ما آن را منبع باز نکرده ایم، اما اگر ناگهان پس از گزارش، پس از اینکه متوجه شدید به چنین چیزی نیاز دارید، به آن نیاز دارید، مخاطبین من در اسلاید آخر هستند - لطفا برای من بنویسید. اگر حداقل 3-5 نفر باشند اسپانسر می کنیم.

  
  
  چگونه کار می کند؟ بیایید نگاهی بیندازیم! نگاه به آینده: در سمت چپ بخشی از نظارت ما وجود دارد: این یک خط است، در بالا زمان پردازش رویداد، در وسط تعداد تراکنش ها، در پایین تعداد کارگران است.

  اگر نگاه کنید، یک اشکال در این تصویر وجود دارد. در نمودار بالا، یکی از نمودارها در 45 ثانیه خراب شد - یکی از سیستم های پرداخت از کار افتاد. بلافاصله، ترافیک در 2 دقیقه وارد شد و صف شروع به رشد کرد در یک سیستم پرداخت دیگر، جایی که کارگری وجود نداشت (ما از منابع استفاده نکردیم - برعکس، منابع را به درستی دفع کردیم). ما نمی خواستیم گرم کنیم - حداقل تعداد کارگران وجود داشت، حدود 5-10 کارگر، اما آنها نتوانستند کنار بیایند.

  نمودار آخر یک "قوز" را نشان می دهد، که فقط به این معنی است که "Skaleno" این مقدار را دو برابر کرده است. و سپس، هنگامی که نمودار کمی کاهش یافت، او آن را کمی کاهش داد - تعداد کارگران به طور خودکار تغییر کرد. اینجوری کار میکنه ما در مورد نقطه شماره 2 صحبت کردیم - "چگونه به سرعت از شر دلایل خلاص شویم."

  نظارت بر. چگونه به سرعت مشکل را شناسایی کنیم؟

  اکنون اولین نکته این است که "چگونه مشکل را سریع شناسایی کنیم؟" نظارت بر! ما باید بعضی چیزها را سریع بفهمیم. چه چیزهایی را باید سریع بفهمیم؟

  
  
  سه چیز!

  • ما باید عملکرد منابع خود را به سرعت درک و درک کنیم.
  • ما باید به سرعت خرابی ها را درک کنیم و عملکرد سیستم هایی را که خارج از ما هستند نظارت کنیم.
  • نکته سوم شناسایی خطاهای منطقی است. این زمانی است که سیستم برای شما کار می کند، همه چیز طبق همه شاخص ها عادی است، اما مشکلی پیش می آید.

  من احتمالاً در اینجا چیز جالبی به شما نمی گویم. من کاپیتان آشکار خواهم بود. ما به دنبال آنچه در بازار بود گشتیم. ما یک "باغ وحش سرگرم کننده" داریم. این همان باغ وحشی است که اکنون داریم:

  
  
  ما از Zabbix برای نظارت بر سخت افزار، برای نظارت بر شاخص های اصلی سرورها استفاده می کنیم. ما از Okmeter برای پایگاه داده استفاده می کنیم. ما از «Grafana» و «Prometheus» برای همه شاخص‌های دیگر استفاده می‌کنیم که با دو شاخص اول مطابقت ندارند، برخی با «Grafana» و «Prometheus» و برخی با «Grafana» با «Influx» و Telegraf.

  یک سال پیش می خواستیم از New Relic استفاده کنیم. چیز جالبی است، همه چیز را می تواند انجام دهد. اما تا آنجا که او می تواند همه چیز را انجام دهد، او بسیار گران است. وقتی حجم ما به 1,5 هزار سرور رسید، فروشنده ای به ما مراجعه کرد و گفت: بیایید برای سال آینده قرارداد ببندیم. ما به قیمت نگاه کردیم و گفتیم نه، ما این کار را نمی کنیم. اکنون ما New Relic را رها می کنیم، حدود 15 سرور تحت نظارت New Relic باقی مانده است. قیمت کاملاً وحشیانه معلوم شد.

  و یک ابزار وجود دارد که ما خودمان آن را پیاده سازی کردیم - این Debugger است. ابتدا اسمش را «باگر» گذاشتیم، اما بعد یک معلم انگلیسی از آنجا رد شد، وحشیانه خندید و اسمش را «دیباگر» گذاشت. آن چیست؟ این ابزاری است که در واقع در 15 تا 30 ثانیه بر روی هر جزء، مانند یک "جعبه سیاه" سیستم، آزمایش هایی را روی عملکرد کلی قطعه انجام می دهد.

  به عنوان مثال، اگر یک صفحه خارجی (صفحه پرداخت) وجود داشته باشد، به سادگی آن را باز می کند و نگاه می کند که چگونه باید به نظر برسد. اگر این در حال پردازش است، او یک "معامله" آزمایشی ارسال می کند و مطمئن می شود که این "تراکنش" می رسد. اگر این ارتباط با سیستم‌های پرداخت است، ما یک درخواست آزمایشی را بر اساس آن، در جایی که می‌توانیم، ارسال می‌کنیم و می‌بینیم که همه چیز با ما خوب است.

  چه شاخص هایی برای نظارت مهم هستند؟

  ما عمدتاً چه چیزی را نظارت می کنیم؟ چه شاخص هایی برای ما مهم است؟

  
  

  • زمان پاسخ / RPS در جلو یک شاخص بسیار مهم است. او بلافاصله پاسخ می دهد که چیزی با شما اشتباه است.
  • تعداد پیام های پردازش شده در تمام صف ها.
  • تعداد کارگران.
  • معیارهای صحت اولیه

  آخرین نکته متریک "کسب و کار"، "کسب و کار" است. اگر می خواهید بر همین موضوع نظارت داشته باشید، باید یک یا دو معیار را تعریف کنید که شاخص های اصلی برای شما هستند. متریک ما توان عملیاتی است (این نسبت تعداد تراکنش های موفق به کل جریان تراکنش است). اگر چیزی در آن با فاصله 5-10-15 دقیقه تغییر کند، به این معنی است که ما مشکل داریم (اگر تغییر اساسی کند).

  آنچه برای ما به نظر می رسد نمونه ای از یکی از تابلوهای ما است:

  
  
  در سمت چپ 6 نمودار وجود دارد، این مطابق با خطوط است - تعداد کارگران و تعداد پیام ها در صف ها. در سمت راست - RPS، RTS. در زیر همان معیار «کسب و کار» آمده است. و در متریک «کسب و کار» می‌توانیم بلافاصله ببینیم که مشکلی در دو نمودار میانی رخ داده است... این فقط سیستم دیگری است که پشت سر ما ایستاده و سقوط کرده است.

  دومین کاری که ما باید انجام می‌دادیم، نظارت بر سقوط سیستم‌های پرداخت خارجی بود. در اینجا ما OpenTracing را انتخاب کردیم - مکانیزم، استاندارد، پارادایم که به شما امکان می دهد سیستم های توزیع شده را ردیابی کنید. و کمی تغییر کرد پارادایم استاندارد OpenTracing می گوید که ما برای هر درخواست فردی یک ردیابی می سازیم. ما به این نیاز نداشتیم، و آن را در یک خلاصه، ردیابی تجمعی قرار دادیم. ما ابزاری ساختیم که به ما امکان می دهد سرعت سیستم های پشت سرمان را ردیابی کنیم.

  
  
  نمودار به ما نشان می دهد که یکی از سیستم های پرداخت در 3 ثانیه شروع به پاسخ دادن کرد - ما مشکل داریم. علاوه بر این، هنگامی که مشکلات شروع می شود، این چیز در فاصله 20-30 ثانیه واکنش نشان می دهد.

  و دسته سوم از خطاهای نظارتی که وجود دارد، نظارت منطقی است.

  صادقانه بگویم، نمی‌دانستم چه چیزی را روی این اسلاید بکشم، زیرا مدت‌ها بود که در بازار به دنبال چیزی بودیم که مناسب ما باشد. ما چیزی پیدا نکردیم، پس مجبور شدیم خودمان این کار را انجام دهیم.

  
  
  منظور من از نظارت منطقی چیست؟ خوب، تصور کنید: شما برای خود یک سیستم می سازید (مثلاً یک کلون Tinder). شما آن را ساختید، راه اندازی کردید. مدیر موفق واسیا پوپکین آن را روی تلفن خود گذاشت ، دختری را آنجا می بیند ، او را دوست دارد ... و مانند آن به دختر نمی رسد - مانند آن به نگهبان امنیتی Mikhalych از همان مرکز تجاری می رود. مدیر به طبقه پایین می رود و بعد با تعجب می پرسد: "چرا این نگهبان میخالیچ اینقدر به او لبخند می زند؟"

  در چنین شرایطی... برای ما این وضعیت کمی متفاوت به نظر می رسد، زیرا (نوشتم) این یک ضرر آبرویی است که به طور غیر مستقیم منجر به ضرر مالی می شود. وضعیت ما برعکس است: ممکن است متحمل ضررهای مالی مستقیم شویم - برای مثال، اگر معامله ای را به عنوان موفقیت آمیز انجام دهیم، اما ناموفق بوده است (یا برعکس). مجبور شدم ابزار خودم را بنویسم که تعداد تراکنش های موفق را در طول زمان با استفاده از شاخص های تجاری ردیابی کند. چیزی در بازار پیدا نکردم! این دقیقا همان ایده ای است که می خواستم منتقل کنم. هیچ چیزی در بازار برای حل این نوع مشکل وجود ندارد.

  این در مورد چگونگی شناسایی سریع مشکل بود.

  چگونه دلایل استقرار را تعیین کنیم

  دسته سوم مشکلاتی که ما حل می کنیم این است که بعد از شناسایی مشکل، پس از خلاص شدن از شر آن، خوب است دلیل توسعه، آزمایش را بفهمیم و کاری در مورد آن انجام دهیم. بر این اساس، ما نیاز به بررسی داریم، باید سیاهههای مربوط را بالا ببریم.

  
  
  اگر در مورد لاگ ها صحبت می کنیم (دلیل اصلی لاگ ها هستند)، بخش عمده ای از لاگ های ما در ELK Stack هستند - تقریباً همه افراد مشابهی دارند. برای برخی ممکن است به ELK نباشد، اما اگر لاگ را با گیگابایت بنویسید، دیر یا زود به ELK خواهید رسید. ما آنها را در ترابایت می نویسیم.

  
  
  اینجا یه مشکلی هست ما آن را برطرف کردیم، خطا را برای کاربر تصحیح کردیم، شروع کردیم به حفاری آنچه در آنجا بود، وارد کیبانا شدیم، شناسه تراکنش را در آنجا وارد کردیم و یک پارچه پا مانند این گرفتیم (خیلی چیزها را نشان می دهد). و مطلقاً هیچ چیز در این پاپوش مشخص نیست. چرا؟ بله، چون معلوم نیست کدام قسمت متعلق به کدام کارگر است، کدام قسمت متعلق به کدام جزء است. و در آن لحظه متوجه شدیم که به ردیابی نیاز داریم - همان OpenTracing که من در مورد آن صحبت کردم.

  ما یک سال پیش به این فکر کردیم، توجه خود را به سمت بازار معطوف کردیم و دو ابزار در آنجا وجود داشت - "Zipkin" و "Jaeger". «جاگر» در واقع چنین وارث ایدئولوژیک، جانشین ایدئولوژیک «زیپکین» است. همه چیز در Zipkin خوب است، به جز اینکه نمی داند چگونه جمع کند، نمی داند چگونه لاگ ها را در ردیابی قرار دهد، فقط ردیابی زمانی. و "جاگر" از این موضوع حمایت کرد.

  ما به "Jager" نگاه کردیم: شما می توانید برنامه های کاربردی را ابزار کنید، می توانید در Api بنویسید (استاندارد Api برای PHP در آن زمان تایید نشده بود - این یک سال پیش بود، اما اکنون قبلا تایید شده است)، اما در آنجا وجود دارد. مطلقا مشتری نبود "باشه" فکر کردیم و مشتری خودمان را نوشتیم. چه چیزی به دست آوردیم؟ این تقریباً به نظر می رسد:

  
  
  در Jaeger، دهانه ها برای هر پیام ایجاد می شوند. یعنی وقتی کاربر سیستم را باز می کند، برای هر درخواست ورودی یک یا دو بلوک می بیند (1-2-3 - تعداد درخواست های دریافتی کاربر، تعداد بلاک ها). برای آسان‌تر کردن کار برای کاربران، برچسب‌ها را به گزارش‌ها و ردیابی‌های زمانی اضافه کردیم. بر این اساس، در صورت بروز خطا، اپلیکیشن ما لاگ را با تگ Error مناسب علامت گذاری می کند. شما می توانید بر اساس برچسب خطا فیلتر کنید و تنها گستره هایی که حاوی این بلوک با خطا هستند نمایش داده می شوند. اگر دامنه را گسترش دهیم به این شکل به نظر می رسد:

  
  
  در داخل دهانه مجموعه ای از آثار وجود دارد. در این مورد، اینها سه ردیابی آزمایشی هستند و ردیابی سوم به ما می گوید که خطایی رخ داده است. در همان زمان، در اینجا ما یک ردیابی زمانی را می بینیم: ما یک مقیاس زمانی در بالا داریم، و می بینیم که در چه بازه زمانی این یا آن گزارش ثبت شده است.

  بر این اساس همه چیز برای ما خوب پیش رفت. ما برنامه افزودنی خودمان را نوشتیم و آن را منبع باز کردیم. اگر می خواهید با ردیابی کار کنید، اگر می خواهید با "Jager" در PHP کار کنید، پسوند ما وجود دارد، خوش آمدید از آن استفاده کنید، همانطور که می گویند:

  
  
  ما این پسوند را داریم - این یک کلاینت برای OpenTracing Api است، به صورت php-extence ساخته شده است، یعنی باید آن را مونتاژ کرده و روی سیستم نصب کنید. یک سال پیش هیچ چیز متفاوتی نبود. اکنون کلاینت های دیگری هستند که مانند کامپوننت هستند. در اینجا بستگی به شما دارد: یا اجزاء را با یک آهنگساز پمپ می کنید، یا از افزونه استفاده می کنید.

  استانداردهای شرکتی

  ما در مورد سه فرمان صحبت کردیم. فرمان چهارم استانداردسازی رویکردها است. این در مورد چیست؟ در مورد این است:

  
  
  چرا کلمه "شرکتی" در اینجا آمده است؟ نه به این دلیل که ما یک شرکت بزرگ یا بروکراتیک هستیم، نه! من می خواستم در اینجا از کلمه "شرکتی" در این زمینه استفاده کنم که هر شرکت، هر محصول باید استانداردهای خاص خود را داشته باشد، از جمله شما. چه استانداردهایی داریم؟

  
  

  • ما مقررات استقرار داریم. ما بدون او هیچ جا حرکت نمی کنیم، نمی توانیم. ما حدود 60 بار در هفته مستقر می شویم، یعنی تقریباً دائماً مستقر می شویم. در عین حال، ما برای مثال در آیین نامه استقرار یک تابو در مورد استقرار در روز جمعه داریم - اصولاً ما اعزام نمی کنیم.
  • ما به مستندات نیاز داریم اگر هیچ مستندی برای آن وجود نداشته باشد، حتی اگر زیر قلم متخصصان RnD ما متولد شده باشد، حتی یک جزء جدید وارد تولید نمی شود. ما از آنها دستورالعمل‌های استقرار، یک نقشه نظارتی و یک توضیح تقریبی (خوب، همانطور که برنامه‌نویسان می‌توانند بنویسند) از نحوه کار این مؤلفه، نحوه عیب‌یابی آن می‌خواهیم.
  • ما نه علت مشکل، بلکه مشکل را حل می کنیم - آنچه قبلاً گفتم. برای ما مهم است که کاربر را از مشکلات محافظت کنیم.
  • ما مجوز داریم به عنوان مثال، اگر در عرض دو دقیقه 2 درصد از ترافیک را از دست بدهیم، زمان توقف را در نظر نمی گیریم. این اساساً در آمار ما لحاظ نشده است. اگر از نظر درصدی بیشتر یا موقتی باشد، از قبل حساب می کنیم.
  • و ما همیشه پس از مرگ می نویسیم. هر اتفاقی که برای ما بیفتد، هر موقعیتی که فردی در تولید رفتار غیرعادی داشته باشد، در پس از مرگ منعکس خواهد شد. پس از مرگ سندی است که در آن می نویسید چه اتفاقی برای شما افتاده است، زمان بندی دقیق، کارهایی که برای اصلاح آن انجام داده اید و (این یک بلوک اجباری است!) برای جلوگیری از این اتفاق در آینده چه کاری انجام خواهید داد. این امر برای تجزیه و تحلیل بعدی الزامی و ضروری است.

  چه چیزی از کار افتادگی در نظر گرفته می شود؟

  
  
  همه اینها به چه چیزی منجر شد؟

  این امر منجر به این واقعیت شد که (ما مشکلات خاصی با ثبات داشتیم، این برای مشتریان و ما مناسب نبود) در 6 ماه گذشته شاخص ثبات ما 99,97 بود. می توان گفت که این خیلی زیاد نیست. بله، ما چیزی برای تلاش داریم. از این شاخص، تقریباً نیمی از پایداری است، به عنوان مثال، نه ما، بلکه فایروال برنامه وب ما، که در مقابل ما قرار دارد و به عنوان یک سرویس استفاده می شود، اما مشتریان به این موضوع اهمیت نمی دهند.

  یاد گرفتیم شب بخوابیم. سرانجام! شش ماه پیش نتوانستیم. و در این یادداشت با نتایج، من می خواهم یک یادداشت کنم. دیشب گزارش فوق العاده ای در مورد سیستم کنترل یک راکتور هسته ای منتشر شد. اگر افرادی که این سیستم را نوشته اند می توانند صدای من را بشنوند، لطفاً آنچه را که در مورد "2٪ از کار افتادگی نیست" گفتم را فراموش کنید. برای شما، 2٪ زمان توقف است، حتی اگر برای دو دقیقه!

  همین! سوالات شما.

  
  

  درباره متعادل کننده ها و مهاجرت پایگاه داده

  سوال از حضار (از این پس – ب): – عصر بخیر. از شما برای چنین گزارش مدیری بسیار متشکرم! یک سوال کوتاه در مورد متعادل کننده های شما. گفتی که WAF داری یعنی اینطور که من فهمیدم از نوعی متعادل کننده خارجی استفاده میکنی...

  EK: – خیر، ما از خدمات خود به عنوان متعادل کننده استفاده می کنیم. در این مورد، WAF منحصراً یک ابزار حفاظتی DDoS برای ما است.

  که در: - می توانید چند کلمه در مورد متعادل کننده ها بگویید؟

  EK: - همانطور که قبلاً گفتم، این یک گروه از سرورها در openresty است. ما اکنون 5 گروه ذخیره داریم که به طور انحصاری پاسخ می دهند ... یعنی سروری که منحصرا openresty را اجرا می کند ، فقط ترافیک را پراکسی می کند. بر این اساس، برای اینکه بفهمیم چقدر نگه داریم: اکنون یک جریان ترافیک منظم چند صد مگابیت داریم. آنها کنار می آیند، احساس خوبی دارند، حتی به خودشان فشار نمی آورند.

  که در: - همچنین یک سوال ساده. اینجا استقرار آبی/سبز است. مثلاً با انتقال پایگاه داده چه می کنید؟

  EK: - سؤال خوبی بود! نگاه کنید، در استقرار آبی/سبز، ما صف های جداگانه ای برای هر خط داریم. یعنی اگر در مورد صف های رویداد صحبت می کنیم که از کارگر به کارگر منتقل می شود، صف های جداگانه برای خط آبی و برای خط سبز وجود دارد. اگر در مورد خود پایگاه داده صحبت می کنیم، پس ما عمداً آن را تا آنجا که می توانستیم محدود کردیم، عملاً همه چیز را به صف ها منتقل کردیم؛ در پایگاه داده ما فقط یک پشته از تراکنش ها را ذخیره می کنیم. و پشته تراکنش ما برای همه خطوط یکسان است. با پایگاه داده در این زمینه: ما آن را به آبی و سبز تقسیم نمی کنیم، زیرا هر دو نسخه کد باید بدانند که با تراکنش چه اتفاقی می افتد.

  دوستان، من همچنین یک جایزه کوچک برای تشویق شما دارم - یک کتاب. و برای بهترین سوال باید جایزه بگیرم.

  که در: - سلام. با تشکر از گزارش سوال این است. شما بر پرداخت ها نظارت می کنید، خدماتی را که با آن ها ارتباط برقرار می کنید نظارت می کنید... اما چگونه نظارت می کنید که شخصی به نوعی به صفحه پرداخت شما آمده، پرداختی را انجام داده و پروژه به او پول اعتبار داده است؟ یعنی چگونه نظارت می کنید که مارشال در دسترس است و تماس شما را پذیرفته است؟

  EK: – «تاجر» برای ما در این مورد دقیقاً همان سرویس خارجی سیستم پرداخت است. ما بر سرعت پاسخ تاجر نظارت می کنیم.

  درباره رمزگذاری پایگاه داده

  که در: - سلام. من یک سوال کمی مرتبط دارم. شما داده های حساس PCI DSS دارید. می خواستم بدانم چگونه PAN ها را در صف هایی که باید به آن ها منتقل کنید ذخیره می کنید؟ آیا از رمزگذاری استفاده می کنید؟ و این منجر به سوال دوم می شود: طبق PCI DSS، در صورت تغییرات (اخراج مدیران و غیره) لازم است به طور دوره ای پایگاه داده رمزگذاری مجدد شود - در این مورد برای دسترسی چه اتفاقی می افتد؟

  
  
  EK: - سوال جالبیه! اولا، ما PAN ها را در صف ذخیره نمی کنیم. ما اصولاً حق ذخیره PAN را در جایی به شکل واضح نداریم ، بنابراین از یک سرویس ویژه استفاده می کنیم (ما آن را "Kademon" می نامیم) - این سرویسی است که فقط یک کار را انجام می دهد: پیامی را به عنوان ورودی دریافت می کند و ارسال می کند. ارسال یک پیام رمزگذاری شده و ما همه چیز را با این پیام رمزگذاری شده ذخیره می کنیم. بر این اساس، طول کلید ما زیر یک کیلوبایت است، به طوری که این جدی و قابل اعتماد است.

  که در: - الان به 2 کیلوبایت نیاز دارید؟

  EK: – انگار همین دیروز 256 بود... خب دیگه کجا؟!

  بر این اساس، این اولین است. و ثانیا، راه حلی که وجود دارد، از روش رمزگذاری مجدد پشتیبانی می کند - دو جفت "keks" (کلید) وجود دارد که "عرشه" را رمزگذاری می کند (کلیدها کلیدها هستند، dek مشتقات کلیدهایی هستند که رمزگذاری می کنند) . و اگر این روش شروع شود (به طور منظم، از 3 ماه تا ± چند ماه اتفاق می افتد)، یک جفت "کیک" جدید را دانلود می کنیم و داده ها را دوباره رمزگذاری می کنیم. ما سرویس‌های جداگانه‌ای داریم که همه داده‌ها را پاره کرده و به روشی جدید رمزگذاری می‌کنند. داده ها در کنار شناسه کلیدی که با آن رمزگذاری شده است ذخیره می شود. بر این اساس، به محض اینکه داده ها را با کلیدهای جدید رمزگذاری می کنیم، کلید قدیمی را حذف می کنیم.

  گاهی اوقات باید پرداخت ها به صورت دستی انجام شود ...

  که در: – یعنی اگر برای عملیاتی بازپرداخت شده باشد، آیا باز هم آن را با کلید قدیمی رمزگشایی خواهید کرد؟

  EK: - آره.

  که در: - سپس یک سوال کوچک دیگر. هنگامی که نوعی شکست، سقوط یا حادثه رخ می دهد، لازم است تراکنش را به صورت دستی انجام دهید. چنین وضعیتی وجود دارد.

  EK: - بله گاهی اوقات.

  که در: - این داده ها را از کجا می آورید؟ یا خودتان به این انبار می روید؟

  EK: - نه، خوب، البته، ما نوعی سیستم پشتیبان داریم که دارای یک رابط برای پشتیبانی ما است. اگر ندانیم که تراکنش در چه وضعیتی است (مثلاً تا زمانی که سیستم پرداخت با وقفه پاسخ داده شود)، پیشینی نمی دانیم، یعنی فقط با اطمینان کامل وضعیت نهایی را تعیین می کنیم. در این حالت، تراکنش را به وضعیت ویژه ای برای پردازش دستی اختصاص می دهیم. صبح روز بعد، به محض اینکه پشتیبانی اطلاعاتی مبنی بر باقی ماندن فلان تراکنش در سیستم پرداخت دریافت می کند، آنها را به صورت دستی در این رابط پردازش می کند.

  
  
  که در: - من چند سئوال دارم. یکی از آنها ادامه منطقه PCI DSS است: چگونه مدار آنها را ثبت می کنید؟ این سوال به این دلیل است که توسعه دهنده می تواند هر چیزی را در گزارش ها قرار دهد! سوال دوم: چگونه رفع‌های فوری را راه‌اندازی می‌کنید؟ استفاده از دسته‌ها در پایگاه داده یکی از گزینه‌ها است، اما ممکن است رفع‌های داغ رایگان وجود داشته باشد - رویه در آنجا چیست؟ و سوال سوم احتمالا مربوط به RTO، RPO است. در دسترس بودن شما 99,97 بود، تقریباً چهار نه، اما همانطور که من متوجه شدم، شما یک مرکز داده دوم، یک مرکز داده سوم، و یک مرکز داده پنجم دارید... چگونه آنها را همگام سازی کنید، آنها را تکرار کنید، و هر چیز دیگری؟

  EK: - از اولی شروع کنیم. اولین سوال در مورد لاگ بود؟ وقتی لاگ می نویسیم، لایه ای داریم که تمام داده های حساس را پنهان می کند. او به ماسک و زمینه های اضافی نگاه می کند. بر این اساس، لاگ های ما با داده های از قبل پوشانده شده و یک مدار PCI DSS بیرون می آیند. این یکی از وظایف معمولی است که به بخش آزمون محول می شود. آنها باید هر کار را بررسی کنند، از جمله گزارش هایی که می نویسند، و این یکی از کارهای معمولی در طول بررسی کد است، تا کنترل کنند که توسعه دهنده چیزی را یادداشت نکرده است. بررسی‌های بعدی این امر به طور منظم توسط بخش امنیت اطلاعات تقریباً هفته‌ای یک‌بار انجام می‌شود: گزارش‌های مربوط به روز آخر به طور انتخابی گرفته می‌شوند و از طریق یک تحلیلگر اسکنر ویژه از سرورهای آزمایشی برای بررسی همه چیز اجرا می‌شوند.
  درباره رفع مشکل این در مقررات استقرار ما گنجانده شده است. ما یک بند جداگانه در مورد رفع فوری داریم. ما بر این باوریم که در صورت نیاز، رفع‌های فوری را به صورت شبانه‌روزی اجرا می‌کنیم. به محض اینکه نسخه مونتاژ شد، به محض اجرا، به محض اینکه مصنوع داشتیم، یک مدیر سیستم در حال انجام وظیفه داریم که از پشتیبانی پشتیبانی می کند و او در لحظه ای که لازم باشد آن را مستقر می کند.

  در مورد "چهار نه". رقمی که اکنون داریم واقعاً به دست آمده است و ما در مرکز داده دیگری برای آن تلاش کردیم. اکنون ما یک مرکز داده دوم داریم و شروع به مسیریابی بین آنها می کنیم و موضوع تکرار مرکز داده های متقاطع واقعاً یک سؤال بی اهمیت است. ما سعی کردیم در یک زمان آن را با استفاده از ابزارهای مختلف حل کنیم: سعی کردیم از همان "رتیل" استفاده کنیم - برای ما کار نکرد، فوراً به شما می گویم. به همین دلیل است که ما در نهایت "حس" را به صورت دستی سفارش دادیم. در واقع، هر برنامه در سیستم ما همگام سازی "تغییر - انجام شده" لازم را بین مراکز داده به صورت ناهمزمان اجرا می کند.

  که در: - اگر دومی گرفتی، چرا سومی نگرفتی؟ چون هنوز هیچ کس مغزش تقسیم نشده...

  EK: - اما ما Split Brain نداریم. با توجه به اینکه هر برنامه توسط یک مولتی مستر هدایت می شود، برای ما مهم نیست که درخواست به کدام مرکز رسیده است. ما برای این واقعیت آماده ایم که اگر یکی از مراکز داده ما از کار بیفتد (ما به این متکی هستیم) و در میانه درخواست کاربر به مرکز داده دوم سوئیچ شود، در واقع آماده هستیم که این کاربر را از دست دهیم. اما اینها واحدها، واحدهای مطلق خواهند بود.

  که در: - عصر بخیر. با تشکر از گزارش شما در مورد دیباگر خود صحبت کردید که برخی از تراکنش های آزمایشی را در تولید اجرا می کند. اما در مورد معاملات آزمایشی به ما بگویید! چقدر عمیق می شود؟

  EK: - چرخه کامل کل جزء را طی می کند. برای یک جزء، هیچ تفاوتی بین یک معامله آزمایشی و یک معامله تولیدی وجود ندارد. اما از نقطه نظر منطقی، این به سادگی یک پروژه جداگانه در سیستم است که فقط تراکنش های آزمایشی روی آن اجرا می شود.

  که در: -از کجا قطعش میکنی؟ اینجا Core ارسال کرد...

  EK: – ما در این مورد برای تراکنش های آزمایشی پشت «Kor» هستیم... چیزی به عنوان مسیریابی داریم: «Kor» می داند که به کدام سیستم پرداخت ارسال کند - ما به یک سیستم پرداخت جعلی ارسال می کنیم که به سادگی یک سیگنال http می دهد و این همه است.

  که در: - لطفاً به من بگویید، آیا برنامه شما در یک مونولیت بزرگ نوشته شده است یا آن را به برخی از خدمات یا حتی میکروسرویس ها تقسیم کرده اید؟

  EK: - ما یکپارچه نداریم، البته، ما یک برنامه سرویس گرا داریم. ما به شوخی می گوییم که سرویس ما از یکپارچه ساخته شده است - آنها واقعاً بسیار بزرگ هستند. سخت است که آن را میکروسرویس بنامیم، اما اینها خدماتی هستند که کارگران ماشین های توزیع شده در آنها کار می کنند.

  اگر سرویس روی سرور به خطر بیفتد ...

  که در: - پس من سوال بعدی را دارم. حتی اگر یکپارچه باشد، باز هم گفتید که بسیاری از این سرورهای فوری را دارید، همه آنها اساساً داده ها را پردازش می کنند، و سؤال این است: "در صورت به خطر افتادن یکی از سرورهای فوری یا یک برنامه، هر پیوند فردی ، آیا آنها نوعی کنترل دسترسی دارند؟ کدام یک از آنها می تواند چه کاری انجام دهد؟ برای چه اطلاعاتی باید با چه کسی تماس بگیرم؟

  
  
  EK: - بله قطعا. الزامات امنیتی کاملاً جدی است. اولا، ما حرکات داده باز داریم و پورت ها فقط آنهایی هستند که از قبل حرکت ترافیک را از طریق آنها پیش بینی می کنیم. اگر مؤلفه ای از طریق 5-4-3-2 با پایگاه داده (مثلاً با Muskul) ارتباط برقرار کند، فقط 5-4-3-2 برای آن باز می شود و سایر پورت ها و سایر مسیرهای ترافیکی در دسترس نخواهند بود. علاوه بر این، باید بدانید که در تولید ما حدود 10 حلقه امنیتی مختلف وجود دارد. و حتی اگر برنامه به نوعی به خطر بیفتد، خدای ناکرده، مهاجم نمی تواند به کنسول مدیریت سرور دسترسی پیدا کند، زیرا این یک منطقه امنیتی شبکه متفاوت است.

  که در: – و در این زمینه، چیزی که برای من جالب تر است این است که شما قراردادهای خاصی با خدمات دارید - آنها چه کاری می توانند انجام دهند، از طریق چه "اقداماتی" می توانند با یکدیگر تماس بگیرند ... و در یک جریان عادی، برخی از خدمات خاص برخی از خدمات را درخواست می کنند. ردیف، لیستی از "اقدامات" در سمت دیگر. به نظر نمی رسد آنها در شرایط عادی به دیگران روی بیاورند و مسئولیت های دیگری نیز دارند. اگر یکی از آنها به خطر بیفتد، آیا می تواند "اقدامات" آن سرویس را مختل کند؟

  EK: - من میفهمم. اگر در شرایط عادی با سرور دیگری اصلاً امکان برقراری ارتباط وجود داشت، بله. طبق قرارداد SLA، ما نظارت نمی کنیم که شما فقط اجازه 3 "اقدام" را دارید، و شما مجاز به 4 "عمل" نیستید. این احتمالاً برای ما زائد است، زیرا ما در حال حاضر یک سیستم حفاظتی 4 سطحی، در اصل، برای مدارها داریم. ما ترجیح می‌دهیم از خودمان با خطوط دفاع کنیم تا در سطح درونی.

  ویزا، مسترکارت و اسبربانک چگونه کار می کنند

  که در: - من می خواهم یک نکته را در مورد تغییر یک کاربر از یک مرکز داده به مرکز داده دیگر روشن کنم. تا آنجا که من می دانم، ویزا و مسترکارت با استفاده از پروتکل سنکرون باینری 8583 کار می کنند و ترکیباتی در آنجا وجود دارد. و می خواستم بدانم، اکنون منظور ما تغییر است - آیا مستقیماً "Visa" و "MasterCard" است یا قبل از سیستم های پرداخت، قبل از پردازش؟

  EK: - این قبل از میکس است. مخلوط های ما در همان مرکز داده قرار دارند.

  که در: - به طور کلی، آیا یک نقطه اتصال دارید؟

  EK: - "Visa" و "MasterCard" - بله. صرفاً به این دلیل که ویزا و مسترکارت به سرمایه‌گذاری‌های کاملاً جدی در زیرساخت نیاز دارند تا برای مثال، برای به دست آوردن یک جفت ترکیب دوم، قراردادهای جداگانه منعقد کنند. آنها در یک مرکز داده رزرو شده اند، اما اگر خدای ناکرده مرکز داده ما که در آن میکس هایی برای اتصال به ویزا و مستر کارت وجود دارد، بمیرد، آنگاه ارتباط ما با ویزا و مسترکارت قطع می شود...

  که در: - چگونه می توان آنها را رزرو کرد؟ میدونم که ویزا اصولا فقط یک کانکشن رو میده!

  EK: - تجهیزات را خودشان تهیه می کنند. در هر صورت تجهیزاتی دریافت کردیم که در داخل کاملاً زائد است.

  که در: - پس پایه از Connects Orange آنهاست؟..

  EK: - آره.

  که در: - اما در مورد این مورد چطور: اگر مرکز داده شما ناپدید شود، چگونه می توانید به استفاده از آن ادامه دهید؟ یا ترافیک فقط متوقف می شود؟

  EK: - نه در این صورت ما به سادگی ترافیک را به کانال دیگری تغییر می دهیم که طبیعتاً برای ما گرانتر و برای مشتریان ما گرانتر خواهد بود. اما ترافیک از طریق اتصال مستقیم ما به Visa، MasterCard انجام نمی شود، بلکه از طریق Sberbank مشروط (بسیار اغراق آمیز) انجام می شود.

  اگر به کارمندان Sberbank توهین کردم به شدت عذرخواهی می کنم. اما طبق آمار ما، در بین بانک های روسیه، Sberbank اغلب سقوط می کند. یک ماه نمی گذرد که چیزی در Sberbank سقوط نکند.

  
  
  

  چند تبلیغ 🙂

  از اینکه با ما ماندید متشکرم آیا مقالات ما را دوست دارید؟ آیا می خواهید مطالب جالب تری ببینید؟ با ثبت سفارش یا معرفی به دوستان از ما حمایت کنید ابر VPS برای توسعه دهندگان از 4.99 دلار, یک آنالوگ منحصر به فرد از سرورهای سطح ورودی که توسط ما برای شما اختراع شده است: تمام حقیقت در مورد VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps از 19 دلار یا چگونه سرور را به اشتراک بگذاریم؟ (در دسترس با RAID1 و RAID10، حداکثر 24 هسته و حداکثر 40 گیگابایت DDR4).

  Dell R730xd 2 برابر ارزان تر در مرکز داده Equinix Tier IV در آمستردام؟ فقط اینجا 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV از 199 دلار در هلند! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - از 99 دلار! در مورد بخوانید نحوه ساخت شرکت زیرساخت کلاس با استفاده از سرورهای Dell R730xd E5-2650 v4 به ارزش 9000 یورو برای یک پنی؟

منبع: www.habr.com