Хүн бүр хөгжүүлэлт, туршилт, боловсон хүчнийг сургах, урам зоригийг нэмэгдүүлэх үйл явцын талаар ярьдаг боловч үйлчилгээний нэг минут зогсолт нь асар их мөнгө шаарддаг үед эдгээр үйл явц хангалтгүй юм. Та хатуу SLA-ийн дагуу санхүүгийн гүйлгээ хийхдээ юу хийх вэ? Хэрхэн хөгжүүлэлт, туршилтыг тэгшитгэлээс гаргаж, системийнхээ найдвартай байдал, алдааг тэсвэрлэх чадварыг нэмэгдүүлэх вэ?
Дараагийн HighLoad++ бага хурал 6 оны 7-р сарын 2020, XNUMX-ны өдрүүдэд Санкт-Петербург хотод болно. Дэлгэрэнгүй мэдээлэл, тасалбар . 9 сарын 18 00:2018. HighLoad++ Москва XNUMX, Дели + Колката танхим. Дипломууд болон .
Евгений Кузовлев (цаашид - EC): - Найзууд аа, сайн уу! Намайг Кузовлев Евгений гэдэг. Би EcommPay компаниас ирсэн бөгөөд тодорхой хэлтэс нь EcommPay IT, компаниудын бүлгийн мэдээллийн технологийн хэлтэс юм. Өнөөдөр бид сул зогсолтын тухай ярих болно - үүнээс хэрхэн зайлсхийх, зайлсхийх боломжгүй бол үр дагаврыг нь хэрхэн бууруулах талаар. Сэдвийг дараах байдлаар тодорхойлсон: "Нэг минут зогсолт нь 100 долларын үнэтэй үед юу хийх вэ?" Цаашаа харахад бидний тоо харьцуулж болохоор байна.
EcommPay IT юу хийдэг вэ?
Бид хэн бэ? Би яагаад энд чиний өмнө зогсож байгаа юм бэ? Би яагаад энд нэг юм хэлэх эрхтэй юм бэ? Энд бид юуны талаар илүү дэлгэрэнгүй ярих вэ?
EcommPay компаниудын групп нь олон улсын худалдан авагч юм. Бид дэлхий даяар төлбөр тооцоо хийдэг - Орос, Европ, Зүүн Өмнөд Ази (Дэлхий даяар). Манайх 9 оффистой, нийт 500 гаруй ажилтантай, тэдний талаас арай бага хувь нь мэдээллийн технологийн мэргэжилтнүүд байдаг. Бидний хийдэг бүх зүйл, мөнгө олдог бүх зүйлээ бид өөрсдөө хийсэн.
Бид бүх бүтээгдэхүүнээ өөрсдөө бичсэн (мөн бидэнд маш олон байдаг - манай томоохон мэдээллийн технологийн бүтээгдэхүүний шугамд 16 орчим өөр бүрэлдэхүүн хэсэг байдаг) өөрсдөө; Бид өөрсдөө бичдэг, өөрсдийгөө хөгжүүлдэг. Одоогийн байдлаар бид өдөрт нэг сая орчим гүйлгээ хийдэг (сая гэж хэлэх нь зөв байх). Бид бол нэлээд залуу компани - бид дөнгөж зургаахан настай.
6 жилийн өмнө залуус бизнестэй хамт ирэхэд ийм гарааны бизнес байсан. Тэднийг нэг санаа (санаас өөр зүйл байгаагүй) нэгтгэж, бид гүйсэн. Аливаа гарааны бизнестэй адил бид илүү хурдан гүйдэг байсан... Бидний хувьд чанараас илүү хурд чухал байсан.
Хэзээ нэгэн цагт бид зогссон: бид ямар нэгэн байдлаар ийм хурдтай, ийм чанартай амьдарч чадахгүй гэдгээ ойлгосон бөгөөд бид эхлээд чанарт анхаарлаа хандуулах хэрэгтэй болсон. Энэ мөчид бид зөв, өргөтгөх боломжтой, найдвартай шинэ платформ бичихээр шийдсэн. Тэд энэ платформыг бичиж эхэлсэн (тэд хөрөнгө оруулалт хийж, хөгжүүлэлт хийж, туршилт хийж эхэлсэн), гэхдээ хэзээ нэгэн цагт хөгжүүлэлт, туршилт нь үйлчилгээний чанарын шинэ түвшинд хүрэх боломжийг бидэнд олгохгүй гэдгийг ойлгосон.
Та шинэ бүтээгдэхүүн үйлдвэрлэж, үйлдвэрлэлд нэвтрүүлсэн ч хаа нэгтээ ямар нэг зүйл буруугаар эргэх болно. Өнөөдөр бид чанарын шинэ түвшинд хэрхэн хүрэх талаар ярих болно (бид үүнийг хэрхэн хийсэн, бидний туршлагын талаар), хөгжүүлэлт, туршилтыг тэгшитгэлээс гаргах; Бид ажиллах боломжтой юу - ямар ажиллагаа өөрөө хийж чадах, чанарт нөлөөлөхийн тулд туршилтанд юу санал болгож болох талаар ярилцах болно.
Сул зогсолт. Үйл ажиллагааны тушаалууд.
Үргэлж тулгын гол чулуу, өнөөдөр бидний ярих зүйл бол сул зогсолт юм. Аймшигтай үг. Хэрэв бид сул зогсолттой байвал бүх зүйл бидний хувьд муу болно. Бид үүнийг өсгөх гэж гүйж байна, админууд нь серверийг барьж байна - тэр дуунд хэлсэнчлэн энэ нь унахгүй байх болтугай. Энэ бол өнөөдөр бидний ярих зүйл юм.
Бид арга барилаа өөрчилж эхлэхдээ 4 зарлигийг бий болгосон. Би тэдгээрийг слайд дээр үзүүлэв:
Эдгээр зарлигууд нь маш энгийн:
- Асуудлыг хурдан тодорхойлох.
- Үүнээс илүү хурдан сал.
- Үүний шалтгааныг ойлгоход тусална уу (дараа нь хөгжүүлэгчдэд).
- Мөн хандлагыг стандартчилах.
2-р зүйлд анхаарлаа хандуулмаар байна.Бид асуудлаас ангижирч байгаа болохоос шийдэхгүй байна. Шийдвэрлэх нь хоёрдогч юм. Бидний хувьд хамгийн чухал зүйл бол хэрэглэгч энэ асуудлаас хамгаалагдсан байх явдал юм. Энэ нь тусгаарлагдсан орчинд байх боловч энэ орчин түүнтэй ямар ч холбоогүй болно. Үнэндээ бид эдгээр дөрвөн бүлгийн асуудлыг (зарим нь илүү дэлгэрэнгүй, зарим нь бага зэрэг) авч үзэх болно, би юу ашигладаг, шийдэлд ямар туршлагатай болохыг танд хэлэх болно.
Алдааг олж засварлах: Тэд хэзээ тохиолддог, юу хийх вэ?
Гэхдээ бид эмх цэгцгүй эхлэх болно, бид 2-р цэгээс эхэлнэ - асуудлыг хэрхэн хурдан арилгах вэ? Асуудал байна - бид үүнийг засах хэрэгтэй. "Бид энэ талаар юу хийх ёстой вэ?" - гол асуулт. Асуудлыг хэрхэн засах талаар бодож эхлэхэд бид алдааг олж засварлахад дагаж мөрдөх ёстой зарим шаардлагыг өөрсдөдөө зориулж боловсруулсан.
Эдгээр шаардлагыг боловсруулахын тулд бид өөрөөсөө "Бидэнд хэзээ асуудал гардаг вэ?" гэсэн асуултыг асуухаар шийдсэн. Асуудал нь дөрвөн тохиолдолд тохиолддог.
- Техник хангамжийн алдаа.
- Гадаад үйлчилгээ амжилтгүй боллоо.
- Програм хангамжийн хувилбарыг өөрчлөх (ижил байршуулалт).
- Тэсрэх ачааллын өсөлт.
Бид эхний хоёрын талаар ярихгүй. Тоног төхөөрөмжийн эвдрэлийг маш энгийнээр шийдэж болно: та бүх зүйлийг давхардсан байх ёстой. Хэрэв эдгээр нь диск бол дискүүдийг RAID-д угсарсан байх ёстой; хэрэв энэ нь сервер бол серверийг хуулбарласан байх ёстой; хэрэв танд сүлжээний дэд бүтэц байгаа бол сүлжээний дэд бүтцийн хоёр дахь хуулбарыг нийлүүлэх ёстой, өөрөөр хэлбэл та үүнийг авах ёстой. хуулбарлах. Хэрэв ямар нэг зүйл бүтэлгүйтвэл та нөөц хүч рүү шилжинэ. Энд өөр зүйл хэлэхэд хэцүү байна.
Хоёр дахь нь гадны үйлчилгээний доголдол юм. Ихэнх хүмүүсийн хувьд систем нь асуудал биш боловч бидний хувьд тийм биш юм. Бид төлбөр тооцоог боловсруулдаг тул хэрэглэгч (картынхаа мэдээллийг оруулдаг) болон банкууд, төлбөрийн системүүд (Visa, MasterCard, Mira гэх мэт) хооронд байрладаг нэгтгэгч юм. Манай гадаад үйлчилгээ (төлбөрийн систем, банк) бүтэлгүйтэх хандлагатай байдаг. Бид ч, та ч (хэрэв танд ийм үйлчилгээ байгаа бол) үүнд нөлөөлж чадахгүй.
Тэгвэл яах вэ? Энд хоёр сонголт байна. Нэгдүгээрт, хэрэв боломжтой бол энэ үйлчилгээг ямар нэгэн байдлаар хуулбарлах хэрэгтэй. Жишээлбэл, хэрэв боломжтой бол бид траффикийг нэг үйлчилгээнээс нөгөө үйлчилгээ рүү шилжүүлдэг: жишээлбэл, картуудыг Сбербанкаар дамжуулан боловсруулсан, Сбербанк асуудалтай тулгараад байна - бид урсгалыг [болзолтоор] Raiffeisen руу шилжүүлдэг. Бидний хийж чадах хоёрдахь зүйл бол гадны үйлчилгээний доголдлыг маш хурдан анзаарах явдал бөгөөд бид тайлангийн дараагийн хэсэгт хариу өгөх хурдны талаар ярих болно.
Үнэн хэрэгтээ эдгээр дөрвөөс бид програм хангамжийн хувилбаруудыг өөрчлөхөд онцгойлон нөлөөлж чадна - байршуулах болон ачааллын тэсрэлттэй өсөлтийн нөхцөлд нөхцөл байдлыг сайжруулахад хүргэх арга хэмжээ авах. Үнэндээ бид ийм зүйл хийсэн. Энд дахиад нэг жижиг тэмдэглэл байна ...
Эдгээр дөрвөн асуудлын хэд нь үүлтэй бол шууд шийдэгддэг. Хэрэв та Microsoft Azhur, Ozone үүлэнд байгаа эсвэл Yandex эсвэл Mail-аас манай үүл ашиглаж байгаа бол ядаж тоног төхөөрөмжийн эвдрэл нь тэдний асуудал болж, техник хангамжийн эвдрэлийн нөхцөлд бүх зүйл тэр даруй хэвийн болно.
Бид арай уламжлалт бус компани юм. Энд бүгд "Кубернец", үүлний тухай ярьж байна - бидэнд "Кубернет" ч, үүл ч байхгүй. Гэхдээ бид олон дата төвүүдэд техник хангамжийн тавиуруудтай бөгөөд бид энэ техник хангамж дээр амьдрахаас өөр аргагүйд хүрч, энэ бүхний хариуцлагыг хүлээхээс өөр аргагүйд хүрч байна. Тиймээс энэ хүрээнд ярилцана. Тиймээс, асуудлын талаар. Эхний хоёрыг хаалтнаас гаргаж авсан.
Програм хангамжийн хувилбарыг өөрчлөх. Суурь
Манай хөгжүүлэгчид үйлдвэрлэлд нэвтрэх эрхгүй. Яагаад тэр вэ? Бид зүгээр л PCI DSS сертификаттай бөгөөд манай хөгжүүлэгчид "бүтээгдэхүүн"-д нэвтрэх эрхгүй. Ингээд л болоо. Бүх. Тиймээс хөгжүүлэлт нь уг бүтээлийг гаргахаар илгээх тэр мөчид хөгжлийн хариуцлага дуусдаг.
Бидний хоёр дахь үндэс нь бидэнд маш их тусалдаг зүйл бол баримтжуулаагүй өвөрмөц мэдлэггүй байх явдал юм. Чамд ч мөн адил байгаасай гэж найдаж байна. Яагаад гэвэл энэ нь тийм биш бол танд асуудал гарах болно. Энэхүү өвөрмөц, баримтжуулаагүй мэдлэг зөв цагт, зөв газартаа байхгүй бол асуудал үүснэ. Танд тодорхой бүрэлдэхүүн хэсгийг хэрхэн байрлуулахаа мэддэг нэг хүн байна гэж бодъё - тэр хүн тэнд байхгүй, тэр амралтаараа эсвэл өвчтэй байна - тэгээд л танд асуудал байна.
Мөн бидний ирсэн гурав дахь үндэс. Өвдөлт, цус, нулимсаар дамжуулан бид үүнд хүрсэн - бидний аливаа бүтээн байгуулалт алдаагүй байсан ч алдаатай байдаг гэсэн дүгнэлтэд хүрсэн. Бид өөрсдөө үүнийг шийдсэн: бид ямар нэг зүйлийг байрлуулах, үйлдвэрлэлд оруулах үед алдаатай бүтэцтэй байдаг. Манай систем хангах ёстой шаардлагыг бид бүрдүүлсэн.
Програм хангамжийн хувилбарыг өөрчлөхөд тавигдах шаардлага
Гурван шаардлага байна:
- Бид байршуулалтыг хурдан буцаах ёстой.
- Бид амжилтгүй байршуулалтын нөлөөллийг багасгах ёстой.
- Мөн бид хурдан зэрэгцээ байршуулах чадвартай байх ёстой.
Яг ийм дарааллаар! Яагаад? Учир нь юуны түрүүнд шинэ хувилбарыг суулгахад хурд чухал биш, гэхдээ ямар нэг зүйл буруу болвол хурдан буцаж, хамгийн бага нөлөө үзүүлэх нь чухал юм. Гэхдээ хэрэв танд үйлдвэрлэлд байгаа олон тооны хувилбарууд байгаа бол алдаа гарсан (цэнхэрээс, байршуулалт хийгээгүй, гэхдээ алдаа гарсан) - дараагийн байршуулалтын хурд нь танд чухал юм. Эдгээр шаардлагыг хангахын тулд бид юу хийсэн бэ? Бид дараахь аргачлалыг ашигласан.
Энэ нь маш сайн мэддэг, бид үүнийг хэзээ ч зохион бүтээгээгүй - энэ бол Цэнхэр/Ногоон байршуулалт юм. Энэ юу вэ? Та өөрийн програмуудыг суулгасан серверийн бүлэг тус бүрийн хуулбартай байх ёстой. Хуулбар нь "дулаан" байна: үүн дээр ачаалал байхгүй, гэхдээ энэ траффикийг хүссэн үедээ энэ хуулбар руу илгээж болно. Энэ хуулбар нь өмнөх хувилбарыг агуулна. Мөн байршуулах үед та кодыг идэвхгүй хуулбар болгон гаргадаг. Дараа нь та замын хөдөлгөөний нэг хэсгийг (эсвэл бүгдийг) шинэ хувилбар руу шилжүүлнэ. Тиймээс, замын хөдөлгөөний урсгалыг хуучин хувилбараас шинэ хувилбар руу өөрчлөхийн тулд та зөвхөн нэг үйлдэл хийх хэрэгтэй: та дээд урсгал дахь тэнцвэржүүлэгчийг өөрчлөх, чиглэлийг өөрчлөх - нэгээс нөгөө рүү шилжих хэрэгтэй. Энэ нь маш тохиромжтой бөгөөд хурдан шилжих, хурдан буцаах асуудлыг шийддэг.Хоёрдахь асуултын шийдэл бол багасгах явдал юм: та траффикийнхээ зөвхөн нэг хэсгийг шинэ шугам руу, шинэ код бүхий мөрөнд илгээх боломжтой (жишээлбэл, 2%). Мөн эдгээр 2% нь 100% биш юм! Хэрэв та амжилтгүй байршуулсны улмаас замын хөдөлгөөний 100% алдсан бол энэ нь аймшигтай, хэрвээ та замын хөдөлгөөний 2% алдсан бол энэ нь тааламжгүй, гэхдээ аймшигтай биш юм. Түүгээр ч барахгүй хэрэглэгчид үүнийг анзаарахгүй байх магадлалтай, учир нь зарим тохиолдолд (бүгд биш) ижил хэрэглэгч F5 дарснаар өөр, ажиллаж байгаа хувилбар руу шилжих болно.
Цэнхэр/Ногоон байрлуулах. Чиглүүлэлт
Гэсэн хэдий ч бүх зүйл тийм ч энгийн биш "Цэнхэр/Ногоон байршуулалт" ... Манай бүх бүрэлдэхүүн хэсгүүдийг гурван бүлэгт хувааж болно:
- энэ бол нүүр хуудас (манай үйлчлүүлэгчдийн харж буй төлбөрийн хуудас);
- боловсруулах цөм;
- төлбөрийн системтэй ажиллах адаптер (банк, MasterCard, Visa...).
Энд нэг нюанс бий - нюанс нь шугамын хоорондох чиглүүлэлтэд оршдог. Хэрэв та замын хөдөлгөөнийг 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-ийг стероидууд дээр авсан (энэ бол нээлттэй байдал юм) - энэ бол ижил nginx бөгөөд сүүлийн скриптүүдийг оруулахыг дэмждэг. Та сүүлчийн скрипт бичиж, түүнд "нээлттэй амралт" өгөх боломжтой бөгөөд хэрэглэгчийн хүсэлт ирэх үед энэ сүүлчийн скриптийг гүйцэтгэх болно.
Тэгээд бид үнэндээ ийм скрипт бичиж, өөрсдийгөө "openresti" гэж тохируулсан бөгөөд энэ скрипт дээр бид "Эсвэл" гэсэн холбоосоор 6 өөр параметрийг эрэмбэлдэг. Нэг буюу өөр параметр байгаа эсэхээс хамааран хэрэглэгч нэг эсвэл өөр хуудсанд, нэг мөрөнд эсвэл өөр хуудсанд ирснийг бид мэднэ.
Цэнхэр/Ногоон байрлуулах. Давуу болон сул талууд
Мэдээжийн хэрэг, үүнийг арай хялбар болгох боломжтой байсан (ижил "Наалттай сесс"-ийг ашигла), гэхдээ бид нэг гүйлгээний нэг боловсруулалтын хүрээнд зөвхөн хэрэглэгч бидэнтэй харьцдаг тийм нарийн мэдрэмжтэй байдаг ... Гэхдээ төлбөрийн системүүд бидэнтэй харилцдаг: Гүйлгээг боловсруулсны дараа (төлбөрийн системд хүсэлт илгээснээр) бид буцаан авах болно.
Хэрэв бид бүх хүсэлтэд хэрэглэгчийн IP хаягийг дамжуулж, хэрэглэгчдийг IP хаягаар нь хувааж чадвал бид ижил "Виз"-д хэлэхгүй: "Хөөе, бид ийм чимэг компани юм. олон улсын байх (вэбсайт болон ОХУ-д)... Нэмэлт талбарт хэрэглэгчийн IP хаягийг оруулна уу, таны протокол стандартчилагдсан байна”! Тэд санал нийлэхгүй нь ойлгомжтой.
Тиймээс, энэ нь бидэнд тус болсонгүй - бид нээлттэй байдлыг хийсэн. Үүний дагуу чиглүүлэлтийн тусламжтайгаар бид дараах зүйлийг олж авлаа.Blue/Green Deployment нь миний дурдсан давуу болон сул талуудтай.
Хоёр сул тал:
- та чиглүүлэлтийн талаар санаа зовох хэрэгтэй;
- хоёр дахь гол сул тал бол зардал юм.
Танд хоёр дахин олон сервер хэрэгтэй, танд хоёр дахин их үйл ажиллагааны нөөц хэрэгтэй, энэ амьтны хүрээлэнг бүхэлд нь хадгалахын тулд хоёр дахин их хүчин чармайлт гаргах хэрэгтэй.
Дашрамд хэлэхэд, давуу талуудын дунд би өмнө нь дурдаагүй өөр нэг зүйл бий: ачаалал нэмэгдэх тохиолдолд танд нөөц бий. Хэрэв та ачаалал ихтэй байгаа бол та олон тооны хэрэглэгчидтэй бол 50-50 түгээлтийн хоёр дахь мөрийг оруулаад, илүү олон сервертэй болох асуудлыг шийдэх хүртэл та кластертаа x2 сервертэй болно.
Хэрхэн хурдан байршуулах вэ?
Бид багасгах, хурдан буцаах асуудлыг хэрхэн шийдвэрлэх талаар ярилцсан боловч "Хэрхэн хурдан байрлуулах вэ?" Гэсэн асуулт хэвээр байна.
Энд товч бөгөөд энгийн.- Та CD системтэй байх ёстой (Тасралтгүй хүргэлт) - та үүнгүйгээр амьдарч чадахгүй. Хэрэв танд нэг сервер байгаа бол гараар байрлуулж болно. Бидэнд нэг хагас мянга орчим сервер, нэг хагас мянган бариул байгаа нь мэдээжийн хэрэг - бид зөвхөн байрлуулахын тулд энэ өрөөний хэмжээтэй тасаг тарьж болно.
- Байрлуулалт нь зэрэгцээ байх ёстой. Хэрэв таны байршуулалт дараалсан бол бүх зүйл муу байна. Нэг сервер хэвийн, та өдөржингөө нэг хагас мянган сервер байршуулах болно.
- Дахин хэлэхэд, хурдатгалын хувьд энэ нь шаардлагагүй болсон байх. Байршуулах явцад төсөл нь ихэвчлэн баригдсан байдаг. Танд вэб төсөл байгаа, урд талын хэсэг байдаг (та тэнд вэб багц хийдэг, та npm-ийг хөрвүүлдэг - нэг иймэрхүү) бөгөөд энэ процесс нь зарчмын хувьд богино хугацаанд үргэлжилдэг - 5 минут, гэхдээ эдгээр 5 минут нь шүүмжлэлтэй хандах. Тийм ч учраас бид жишээлбэл, бид үүнийг хийдэггүй: бид эдгээр 5 минутыг устгаж, олдворуудыг байрлуулдаг.
Олдвор гэж юу вэ? Олдвор гэдэг нь угсралтын бүх хэсгүүдийг аль хэдийн хийж дууссан угсарсан барилга юм. Бид энэ олдворыг олдворын агуулахад хадгалдаг. Нэгэн цагт бид хоёр ийм хадгалах санг ашигладаг байсан - энэ нь Nexus байсан бөгөөд одоо jFrog Artifactory байсан. Бид анх "Nexus"-ийг ашиглаж байсан, учир нь бид java програмууд дээр энэ аргыг ашиглаж эхэлсэн (энэ нь маш тохиромжтой). Дараа нь тэд PHP дээр бичигдсэн зарим програмуудыг тэнд байрлуулсан; "Nexus" нь тохиромжгүй болсон тул бид jFrog Artefactory-ийг сонгосон бөгөөд энэ нь бараг бүх зүйлийг бүтээх боломжтой юм. Бид энэ олдворын агуулахад серверт зориулж цуглуулдаг өөрсдийн хоёртын багцуудаа хадгалдаг болсон.
Тэсрэх ачааллын өсөлт
Бид програм хангамжийн хувилбарыг өөрчлөх талаар ярилцсан. Бидэнд байгаа дараагийн зүйл бол ачаалал их хэмжээгээр нэмэгдэх явдал юм. Энд би ачааллын огцом өсөлтийг тийм ч зөв биш гэж хэлж байгаа байх...
Бид шинэ систем бичсэн - энэ нь үйлчилгээнд чиглэсэн, загварлаг, үзэсгэлэнтэй, хаа сайгүй ажилчид, хаа сайгүй дараалал, хаа сайгүй асинхрон юм. Ийм системд өгөгдөл өөр өөр урсгалаар урсаж болно. Эхний гүйлгээний хувьд 1, 3, 10 дахь ажилчдыг, хоёр дахь гүйлгээнд 2, 4, 5 дахь ажилчдыг ашиглаж болно. Өнөөдөр өглөө та эхний гурван ажилчдыг ашигладаг мэдээллийн урсгалтай, орой нь эрс өөрчлөгдөж, бусад гурван ажилчдыг ашигладаг гэж бодъё.
Эндээс харахад та ямар нэгэн байдлаар ажилчдыг өргөжүүлэх хэрэгтэй, та ямар нэгэн байдлаар үйлчилгээгээ өргөжүүлэх хэрэгтэй, гэхдээ нэгэн зэрэг нөөцийн бөөгнөрөлөөс урьдчилан сэргийлэх хэрэгтэй.
Бид шаардлагаа тодорхойлсон. Эдгээр шаардлагууд нь маш энгийн: Үйлчилгээг илрүүлэх, параметржүүлэх - нэг цэгээс бусад бүх зүйл ийм өргөтгөх боломжтой системийг бий болгоход стандарт байдаг - нөөцийн элэгдлээс. Бид серверүүд агаар халаахын тулд нөөцийг хорогдуулахад бэлэн биш байна гэж хэлсэн. “Консул” авлаа, ажилчдаа удирддаг “Номад”-ыг авлаа.Энэ яагаад бидний хувьд асуудал болоод байна вэ? Жаахан ухрая. Одоо бидний ард 70 орчим төлбөрийн систем бий. Өглөө нь урсгал Сбербанкаар дамждаг, дараа нь Сбербанк унасан, жишээлбэл, бид үүнийг өөр төлбөрийн системд шилжүүлдэг. Бид Сбербанкны өмнө 100 ажилчинтай байсан бөгөөд үүний дараа бид өөр төлбөрийн системд 100 ажилчдыг огцом нэмэгдүүлэх шаардлагатай байна. Мөн энэ бүхэн хүний оролцоогүйгээр явагдах нь зүйтэй юм. Яагаад гэвэл хүний оролцоо байгаа бол 24 систем ард байхад ийм доголдол байнга гардаг учраас 7/70 сууж, зөвхөн үүнийг хийх ёстой инженер байх ёстой.
Тиймээс бид нээлттэй IP-тэй Номадыг үзээд Scale-Nomad - ScaleNo гэсэн өөрийн гэсэн зүйлийг бичсэн бөгөөд энэ нь ойролцоогоор дараахь зүйлийг хийдэг: дарааллын өсөлтийг хянаж, динамикаас хамааран ажилчдын тоог бууруулж эсвэл нэмэгдүүлдэг. дарааллын. Үүнийг хийхдээ бид "Магадгүй бид үүнийг нээж болох уу?" гэж бодсон. Дараа нь тэд түүн рүү харав - тэр хоёр копейк шиг энгийн байв.
Одоогоор бид үүнийг нээлттэй эх сурвалжтай болоогүй байгаа, гэхдээ гэнэт тайлангийн дараа танд ийм зүйл хэрэгтэй байгааг мэдээд танд хэрэгтэй бол миний холбоо барих хаягууд сүүлийн слайд дээр байгаа бол надад бичнэ үү. Ядаж 3-5 хүн байвал ивээн тэтгэнэ.
Хэрхэн ажилладаг? Ингээд харцгаая! Урагшаа харахад: зүүн талд бидний мониторингийн хэсэг байна: энэ нь нэг мөр, дээд талд нь үйл явдлыг боловсруулах цаг, дунд нь гүйлгээний тоо, доод талд ажилчдын тоо байна.Хэрэв та харвал энэ зурган дээр алдаа байна. Дээд график дээр графикуудын нэг нь 45 секундын дотор унасан - төлбөрийн системийн нэг нь уналтад орсон. Тэр даруй 2 минутын дотор замын хөдөлгөөн орж ирсэн бөгөөд ажилчид байхгүй өөр төлбөрийн систем дээр дараалал нэмэгдэж эхлэв (бид нөөцөө ашиглаагүй - эсрэгээр бид нөөцийг зөв устгасан). Бид халаахыг хүсээгүй - хамгийн бага тоо, 5-10 орчим ажилчин байсан ч тэд даван туулж чадсангүй.
Сүүлчийн график нь "овойлт"-ыг харуулсан бөгөөд энэ нь "Скалено" энэ хэмжээг хоёр дахин нэмэгдүүлсэн гэсэн үг юм. Дараа нь график бага зэрэг буурахад тэр үүнийг бага зэрэг бууруулсан - ажилчдын тоо автоматаар өөрчлөгдсөн. Энэ зүйл ингэж л ажилладаг. Бид "Шалтгааныг хэрхэн хурдан арилгах вэ" гэсэн 2-р цэгийн талаар ярилцлаа.
Хяналт. Асуудлыг хэрхэн хурдан тодорхойлох вэ?
Одоо хамгийн эхний зүйл бол "Асуудлыг хэрхэн хурдан тодорхойлох вэ?" Хяналт! Бид зарим зүйлийг хурдан ойлгох ёстой. Бид юуг хурдан ойлгох ёстой вэ?
Гурван зүйл!- Бид өөрсдийн нөөцийн гүйцэтгэлийг хурдан ойлгож, ойлгох ёстой.
- Бид бүтэлгүйтлийг хурдан ойлгож, гаднах системийн гүйцэтгэлийг хянах ёстой.
- Гурав дахь зүйл бол логик алдааг тодорхойлох явдал юм. Энэ нь систем таны төлөө ажиллаж байгаа үед бүх үзүүлэлтийн дагуу бүх зүйл хэвийн, гэхдээ ямар нэг зүйл буруу болсон.
Би энд тийм сайхан зүйл хэлэхгүй байх. Би ахмад Обвиус болно. Бид зах зээл дээр байгаа зүйлийг хайж байсан. Бидэнд "хөгжилтэй амьтны хүрээлэн" бий. Энэ бол одоо бидэнд байгаа амьтны хүрээлэнгийн төрөл юм:
Бид Zabbix-ийг техник хангамжийг хянах, серверийн үндсэн үзүүлэлтүүдийг хянах зорилгоор ашигладаг. Бид мэдээллийн санд Okmeter ашигладаг. Бид "Графана" ба "Прометей"-ийг эхний хоёрт тохирохгүй бусад бүх үзүүлэлтэд ашигладаг, зарим нь "Графана" ба "Прометей", зарим нь "Графана" -ыг "Хүн амын шилжилт хөдөлгөөн" ба Телеграфтай.Жилийн өмнө бид New Relic ашиглахыг хүссэн. Гайхалтай, тэр бүгдийг хийж чадна. Гэхдээ тэр бүх зүйлийг хийж чадахын хэрээр тэр маш үнэтэй байдаг. Биднийг 1,5 мянган сервертэй болоход нэг худалдагч ирээд "Ирэх жилийн гэрээ байгуулъя" гэж хэлсэн. Бид үнийг хараад үгүй, бид үүнийг хийхгүй гэж хэлсэн. Одоо бид New Relic-ээс татгалзаж байна, бидэнд New Relic-ийн хяналтан дор 15 орчим сервер үлдсэн байна. Үнэ нь үнэхээр зэрлэг болж хувирав.
Бидний өөрсдөө хэрэгжүүлсэн нэг хэрэгсэл байдаг - энэ бол Debugger юм. Эхлээд бид үүнийг "Баггер" гэж нэрлэдэг байсан ч дараа нь нэг англи хэлний багш өнгөрч, инээж, "Debagger" гэж нэрлэв. Энэ юу вэ? Энэ нь системийн "хар хайрцаг" шиг бүрэлдэхүүн хэсэг бүр дээр 15-30 секундын дотор бүрэлдэхүүн хэсгийн ерөнхий гүйцэтгэлийн туршилтыг явуулдаг хэрэгсэл юм.
Жишээлбэл, хэрэв гадаад хуудас (төлбөрийн хуудас) байгаа бол тэр зүгээр л нээж, энэ нь хэрхэн харагдах ёстойг хардаг. Хэрэв үүнийг боловсруулж байгаа бол тэрээр туршилтын "гүйлгээ" илгээж, энэ "гүйлгээ" ирсэн эсэхийг шалгана. Хэрэв энэ нь төлбөрийн системтэй холбоотой бол бид туршилтын хүсэлтийг зохих газарт илгээж, бүх зүйл хэвийн байгаа эсэхийг хардаг.
Хяналт хийхэд ямар үзүүлэлт чухал вэ?
Бид юуг голчлон хянадаг вэ? Бидний хувьд ямар үзүүлэлт чухал вэ?
- Урд талын хариу өгөх хугацаа / RPS нь маш чухал үзүүлэлт юм. Тэр танд ямар нэг зүйл буруу байна гэж тэр даруй хариулдаг.
- Бүх дараалалд боловсруулсан мессежийн тоо.
- Ажилчдын тоо.
- Зөв байдлын үндсэн үзүүлэлтүүд.
Сүүлийн цэг нь "бизнес", "бизнес" хэмжигдэхүүн юм. Хэрэв та ижил зүйлийг хянахыг хүсч байгаа бол таны хувьд гол үзүүлэлт болох нэг эсвэл хоёр хэмжигдэхүүнийг тодорхойлох хэрэгтэй. Бидний хэмжигдэхүүн бол дамжуулах чадвар (энэ нь амжилттай гүйлгээний тоог нийт гүйлгээний урсгалд харьцуулсан харьцаа юм). Хэрэв 5-10-15 минутын зайтай ямар нэг зүйл өөрчлөгдвөл энэ нь бидэнд асуудал байна гэсэн үг (хэрэв энэ нь эрс өөрчлөгдвөл).
Энэ нь бидний хувьд нэг самбарын жишээ юм:
Зүүн талд 6 график байгаа бөгөөд энэ нь шугамын дагуу - ажилчдын тоо, дараалалд байгаа мессежийн тоо юм. Баруун талд - RPS, RTS. Доорх нь ижил "бизнес" хэмжигдэхүүн юм. Мөн "бизнес" хэмжигдэхүүн дээр бид хоёр дунд график дээр ямар нэг зүйл буруу болсныг шууд харж болно ... Энэ бол бидний ард зогссон бас нэгэн систем унасан.Бидний хийх ёстой хоёр дахь зүйл бол гадаад төлбөрийн системийн уналтыг хянах явдал байв. Энд бид OpenTracing-ийг авсан - тархсан системийг хянах боломжийг олгодог механизм, стандарт, парадигм; бас бага зэрэг өөрчлөгдсөн. Стандарт OpenTracing парадигм нь бид хүсэлт бүрийн хувьд ул мөр үүсгэдэг гэж хэлдэг. Бидэнд энэ хэрэггүй байсан бөгөөд бид үүнийг нэгтгэн нэгтгэсэн ул мөр болгон оруулсан. Бид ард байгаа системийн хурдыг хянах боломжийг олгодог хэрэгсэл хийсэн.
Графикаас харахад төлбөрийн системүүдийн нэг нь 3 секундын дотор хариу үйлдэл үзүүлж эхэлсэн - бидэнд асуудал байна. Түүнээс гадна, асуудал эхлэхэд энэ зүйл 20-30 секундын зайтай хариу үйлдэл үзүүлэх болно.Гурав дахь ангиллын хяналтын алдаа бол логик хяналт юм.
Үнэнийг хэлэхэд, би энэ слайд дээр юу зурахаа мэдэхгүй байсан, учир нь бид зах зээл дээр өөрт тохирох зүйлийг удаан хугацаанд хайж байсан. Бид юу ч олоогүй тул бид өөрсдөө хийх ёстой байсан.
Логик хяналт гэж би юу гэсэн үг вэ? За, төсөөлөөд үз дээ: та өөрийгөө систем (жишээлбэл, Tinder клон) хийдэг; Та үүнийг хийсэн, эхлүүлсэн. Амжилттай менежер Вася Пупкин утсан дээрээ тавиад, тэнд нэг охиныг хараад, түүнд таалагдаж байна ... мөн үүнтэй төстэй зүйл охинд очдоггүй - ижил бизнесийн төвийн хамгаалалтын ажилтан Михалич руу явдаг. Менежер доошоо бууж, дараа нь гайхаж: "Энэ хамгаалалтын ажилтан Михалич яагаад түүн рүү ийм сайхан инээмсэглэв?"Ийм нөхцөлд... Бидний хувьд энэ байдал арай өөр сонсогдож байна, учир нь (би бичсэн) энэ бол шууд бусаар санхүүгийн алдагдалд хүргэдэг нэр хүндийн алдагдал юм. Бидний нөхцөл байдал эсрэгээрээ: бид шууд санхүүгийн алдагдалд орж болзошгүй - жишээлбэл, хэрэв бид амжилттай гүйлгээ хийсэн боловч амжилтгүй болсон (эсвэл эсрэгээр). Би бизнесийн үзүүлэлтүүдийг ашиглан цаг хугацааны явцад амжилттай хийгдсэн гүйлгээний тоог хянадаг өөрийн хэрэгслийг бичих шаардлагатай болсон. Зах зээл дээр юу ч олсонгүй! Яг энэ санааг би хэлэхийг хүссэн юм. Энэ төрлийн асуудлыг шийдэх зах зээл дээр юу ч байхгүй.
Энэ нь асуудлыг хэрхэн хурдан тодорхойлох тухай байв.
Байршуулах шалтгааныг хэрхэн тодорхойлох вэ
Гурав дахь бүлэг асуудал бол бид асуудлаа тодорхойлсны дараа, түүнээс ангижруулсны дараа хөгжүүлж, туршиж үзэхийн тулд ямар нэг зүйл хийх ёстой гэдгийг ойлгох хэрэгтэй. Үүний дагуу бид шалгах хэрэгтэй, бид гуалин босгох хэрэгтэй.
Хэрэв бид логуудын тухай ярьж байгаа бол (гол шалтгаан нь лог), бидний логуудын дийлэнх нь ELK Stack-д байдаг - бараг бүх хүн ижил байдаг. Зарим хүмүүсийн хувьд энэ нь ELK-д байхгүй байж болох ч хэрэв та гигабайтаар лог бичвэл эрт орой хэзээ нэгэн цагт ELK дээр ирэх болно. Бид тэдгээрийг терабайтаар бичдэг.
Энд асуудал байна. Бид үүнийг засч, хэрэглэгчийн алдааг засч, тэнд юу байгааг ухаж, Кибана руу авирч, гүйлгээний ID-г оруулаад ийм хөлийн даавуу авлаа (маш их харагдаж байна). Мөн энэ хөлийн даавуунд юу ч тодорхойгүй байна. Яагаад? Тийм ээ, аль хэсэг нь аль ажилчин, аль хэсэг нь аль бүрэлдэхүүнд хамаарах нь тодорхойгүй учраас. Яг тэр мөчид бид мөшгих хэрэгтэйг ойлгосон - миний ярьсан ижил OpenTracing.Жилийн өмнө бид үүнийг бодож, зах зээлд анхаарлаа хандуулж, тэнд "Зипкин" ба "Жэйгер" гэсэн хоёр хэрэгсэл байсан. "Жагер" бол үнэндээ ийм үзэл суртлын өв залгамжлагч, "Зипкин"-ийн үзэл суртлын залгамжлагч юм. Zipkin-д бүх зүйл сайн байна, гэхдээ энэ нь хэрхэн нэгтгэхийг мэдэхгүй, логуудыг ул мөрд хэрхэн оруулахаа мэддэггүй, зөвхөн цаг хугацааны ул мөр. "Жагер" үүнийг дэмжсэн.
Бид "Жагер" -ийг харлаа: та програмуудыг ашиглаж болно, та Api дээр бичиж болно (тэр үед PHP-д зориулсан Api стандартыг зөвшөөрөөгүй байсан - энэ нь жилийн өмнө байсан, гэхдээ одоо аль хэдийн батлагдсан), гэхдээ тэнд үнэхээр үйлчлүүлэгч байгаагүй. "За" гэж бид бодож, өөрийн үйлчлүүлэгчээ бичсэн. Бид юу авсан бэ? Энэ нь ойролцоогоор иймэрхүү харагдаж байна:
Jaeger-д зурвас тус бүрийн хувьд зай үүсгэсэн. Өөрөөр хэлбэл, хэрэглэгч системийг нээх үед ирж буй хүсэлт бүрт нэг эсвэл хоёр блок хардаг (1-2-3 - хэрэглэгчийн ирж буй хүсэлтийн тоо, блокуудын тоо). Хэрэглэгчдэд илүү хялбар болгохын тулд бид бүртгэлүүд болон цаг хугацааны тэмдэглэгээнд шошго нэмсэн. Үүний дагуу, алдаа гарсан тохиолдолд манай програм логыг зохих Алдааны шошгоор тэмдэглэнэ. Та Алдааны шошгоор шүүж болох ба зөвхөн алдаатай энэ блокыг агуулсан хүрээг харуулах болно. Хэрэв бид хүрээг өргөжүүлбэл иймэрхүү харагдах болно:
Дотор нь олон тооны ул мөр байдаг. Энэ тохиолдолд эдгээр нь гурван туршилтын ул мөр бөгөөд гурав дахь ул мөр нь алдаа гарсан гэдгийг бидэнд хэлдэг. Үүний зэрэгцээ, энд бид цаг хугацааны ул мөрийг харж байна: бид дээд хэсэгт цагийн хуваарьтай бөгөөд энэ эсвэл тэр бүртгэлийг ямар хугацааны интервалаар бүртгэсэн болохыг бид харж байна.Үүний дагуу бидний хувьд бүх зүйл сайхан болсон. Бид өөрсдийн өргөтгөлийг бичсэн бөгөөд бид үүнийг нээлттэй эх сурвалжтай болгосон. Хэрэв та мөрийн программ дээр ажиллахыг хүсвэл, хэрэв та PHP дээр "Jager" -тэй ажиллахыг хүсч байвал манай өргөтгөл байдаг бөгөөд тэдний хэлснээр ашиглахыг урьж байна.
Бидэнд ийм өргөтгөл байгаа - энэ нь OpenTracing Api-ийн үйлчлүүлэгч бөгөөд үүнийг php-өргөтгөл хэлбэрээр хийсэн, өөрөөр хэлбэл та үүнийг угсарч систем дээр суулгах шаардлагатай болно. Жилийн өмнө өөр зүйл байгаагүй. Одоо бүрэлдэхүүн хэсэг шиг өөр үйлчлүүлэгчид бий. Энэ нь танаас хамаарна: та бүрэлдэхүүн хэсгүүдийг хөгжмийн зохиолчоор шахах эсвэл өөрт тохирсон өргөтгөлийг ашиглах боломжтой.Корпорацийн стандартууд
Бид гурван зарлигийн талаар ярилцсан. Дөрөв дэх тушаал бол арга барилыг стандартчилах явдал юм. Энэ юуны тухай вэ? Энэ тухай:
Энд яагаад "корпораци" гэсэн үг байдаг вэ? Бид том, хүнд сурталтай компани учраас биш, үгүй! Компани, бүтээгдэхүүн бүр өөрийн гэсэн стандарттай байх ёстой, тэр дундаа та бүхэн ч гэсэн өөрийн гэсэн стандарттай байх ёстой гэдэг утгаар энд “корпораци” гэдэг үгийг хэлмээр санагдлаа. Бидэнд ямар стандарт байдаг вэ?
- Бид байршуулах журамтай. Түүнгүйгээр бид хаашаа ч нүүхгүй, чадахгүй. Бид долоо хоногт 60 орчим удаа байрлуулдаг, өөрөөр хэлбэл бид бараг байнга байрлуулдаг. Үүний зэрэгцээ, бид жишээлбэл, байршуулах журамд Баасан гарагт байрлуулахыг хориглосон байдаг - зарчмын хувьд бид байршуулдаггүй.
- Бид бичиг баримт шаарддаг. Манай RnD-ийн мэргэжилтнүүдийн харааны дор төрсөн байсан ч гэсэн ямар ч бичиг баримтгүй бол нэг ч шинэ бүрэлдэхүүн хэсэг үйлдвэрлэлд ордоггүй. Бид тэднээс байршуулах заавар, хяналтын газрын зураг, энэ бүрэлдэхүүн хэсэг хэрхэн ажилладаг, хэрхэн алдааг олж засварлах талаар бүдүүлэг тайлбарыг (програмистууд бичиж болно) шаарддаг.
- Бид асуудлын шалтгааныг биш харин асуудлыг шийддэг - миний хэлсэн зүйл. Хэрэглэгчийг асуудлаас хамгаалах нь бидний хувьд чухал юм.
- Бидэнд зөвшөөрөл байгаа. Жишээлбэл, бид хоёр минутын дотор замын хөдөлгөөний 2 хувийг алдсан тохиолдолд зогсолтыг тооцохгүй. Энэ нь үндсэндээ манай статистикт ороогүй. Хэрэв энэ нь илүү хувиар эсвэл түр зуурынх бол бид аль хэдийн тооцдог.
- Тэгээд бид үргэлж үхлийн дараах бичдэг. Бидэнд юу ч тохиолдсон, хэн нэгэн үйлдвэрлэлд хэвийн бус авир гаргасан аливаа нөхцөл байдал үхлийн дараах шинжилгээнд тусгагдана. Үхлийн дараах нь танд юу тохиолдсон, нарийвчилсан цаг хугацаа, үүнийг засахын тулд юу хийсэн, (энэ нь заавал байх ёстой блок!) ирээдүйд ийм зүйл тохиолдохгүйн тулд юу хийхээ бичсэн баримт бичиг юм. Энэ нь зайлшгүй шаардлагатай бөгөөд дараагийн шинжилгээнд зайлшгүй шаардлагатай.
Сул зогсолт гэж юу вэ?
Энэ бүхэн юунд хүргэв?Энэ нь (бид тогтвортой байдалд тодорхой асуудал тулгарсан, энэ нь үйлчлүүлэгчид ч, бидэнд ч тохирохгүй байсан) сүүлийн 6 сарын хугацаанд манай тогтвортой байдлын үзүүлэлт 99,97 байсан. Энэ нь тийм ч их биш гэж бид хэлж чадна. Тийм ээ, бидэнд тэмүүлэх зүйл бий. Энэ үзүүлэлтийн тал орчим хувь нь биднийх биш, харин бидний өмнө зогсож, үйлчилгээ болгон ашигладаг вэб програмын галт ханын тогтвортой байдал юм, гэхдээ үйлчлүүлэгчид үүнийг огт тоодоггүй.
Бид шөнө унтаж сурсан. Эцэст нь! Зургаан сарын өмнө бид чадахгүй байсан. Үр дүн бүхий энэ тэмдэглэл дээр би нэг тэмдэглэл хийхийг хүсч байна. Өчигдөр орой цөмийн реакторын удирдлагын системийн тухай гайхалтай мэдээ гарсан. Хэрэв энэ системийг бичсэн хүмүүс намайг сонсож чадвал “2% нь сул зогсолт биш” гэж хэлснийг минь мартаарай. Таны хувьд 2% нь хоёр минут ч гэсэн сул зогсолт юм!
Тэгээд л болоо! Таны асуултууд.
Тэнцвэржүүлэгч болон мэдээллийн сангийн шилжилтийн тухай
Үзэгчдийн асуулт (цаашид – Б): – Оройн мэнд. Ийм админ тайлан гаргасанд маш их баярлалаа! Таны тэнцвэржүүлэгчийн талаар товч асуулт. Та WAF-тай гэж хэлсэн, өөрөөр хэлбэл миний ойлгосноор та ямар нэгэн гадаад тэнцвэржүүлэгч ашигладаг ...
EK: – Үгүй ээ, бид үйлчилгээгээ тэнцвэржүүлэгчийн хувьд ашигладаг. Энэ тохиолдолд WAF нь зөвхөн DDoS хамгаалах хэрэгсэл юм.
Дотор нь: – Тэнцвэржүүлэгчийн талаар хэдэн үг хэлэхгүй юу?
EK: – Миний хэлсэнчлэн энэ бол нээлттэй серверүүдийн бүлэг юм. Бидэнд зөвхөн хариу үйлдэл үзүүлэх 5 нөөц бүлгүүд байна... өөрөөр хэлбэл, зөвхөн нээлттэй горимоор ажилладаг сервер, зөвхөн траффикийг дамжуулдаг. Үүний дагуу бид хэр их хэмжээгээр агуулагдаж байгааг ойлгохын тулд: одоо бид хэдэн зуун мегабитийн тогтмол хөдөлгөөний урсгалтай болсон. Тэд үүнийг даван туулж, сайхан мэдрэмж төрж, өөрсдийгөө ядраадаггүй.
Дотор нь: - Бас энгийн асуулт. Энд Цэнхэр/Ногоон байршуулалт байна. Жишээлбэл, мэдээллийн сангийн шилжилтийн талаар та юу хийдэг вэ?
EK: - Сайн асуулт! Хараач, Цэнхэр/Ногоон байршуулалтад бид мөр бүрт тусдаа дараалалтай байдаг. Өөрөөр хэлбэл, хэрэв бид ажилчнаас ажилчин руу дамждаг үйл явдлын дарааллын талаар ярьж байгаа бол цэнхэр шугам, ногоон шугамын хувьд тусдаа дараалал байдаг. Хэрэв бид мэдээллийн сангийн тухай ярьж байгаа бол бид үүнийг аль болох зориудаар нарийсгаж, бүх зүйлийг дараалалд шилжүүлсэн; мэдээллийн санд бид зөвхөн гүйлгээний стекийг хадгалдаг. Мөн бидний гүйлгээний стек бүх шугамын хувьд ижил байна. Энэ хүрээнд мэдээллийн баазтай бол: бид үүнийг цэнхэр, ногоон гэж хуваадаггүй, учир нь кодын хоёр хувилбар нь гүйлгээнд юу болж байгааг мэдэж байх ёстой.
Найзууд аа, надад бас таныг урамшуулах бяцхан шагнал байна - ном. Тэгээд би хамгийн сайн асуултанд шагнал өгөх ёстой.
Дотор нь: - Сайн уу. Мэдээлэл өгсөнд баярлалаа. Асуулт нь ийм байна. Та төлбөр тооцоогоо хянадаг, харилцаж буй үйлчилгээгээ хянадаг ... Гэхдээ ямар нэгэн байдлаар хүн таны төлбөрийн хуудас руу орж, төлбөр тооцоо хийж, төсөл түүнд мөнгө оруулахыг хэрхэн хянах вэ? Өөрөөр хэлбэл, жагсагч бэлэн байгаа бөгөөд таны дуудлагыг хүлээн авсан эсэхийг хэрхэн хянах вэ?
EK: - Энэ тохиолдолд бидний хувьд "Худалдаачин" нь төлбөрийн системтэй яг адилхан гадаад үйлчилгээ юм. Бид худалдаачны хариу үйлдлийн хурдыг хянадаг.
Өгөгдлийн сангийн шифрлэлтийн тухай
Дотор нь: - Сайн уу. Надад бага зэрэг холбоотой асуулт байна. Танд PCI DSS мэдрэмтгий өгөгдөл байна. Шилжүүлэх шаардлагатай дараалалд PAN-г хэрхэн хадгалдагийг би мэдэхийг хүссэн бэ? Та ямар нэгэн шифрлэлт ашигладаг уу? Энэ нь хоёр дахь асуултад хүргэдэг: PCI DSS-ийн дагуу, өөрчлөлт гарсан тохиолдолд (администраторуудыг халах гэх мэт) мэдээллийн санг үе үе дахин шифрлэх шаардлагатай байдаг - энэ тохиолдолд хүртээмжтэй байдалд юу тохиолдох вэ?
EK: - Гайхалтай асуулт! Нэгдүгээрт, бид PAN-уудыг дараалалд хадгалдаггүй. Бид PAN-г хаана ч тодорхой хэлбэрээр хадгалах эрхгүй тул бид тусгай үйлчилгээг ашигладаг (бид үүнийг "Кадемон" гэж нэрлэдэг) - энэ нь зөвхөн нэг л зүйлийг хийдэг үйлчилгээ юм: энэ нь мессежийг оролтын хэлбэрээр хүлээн авч, илгээдэг. шифрлэгдсэн мессежийг гаргана. Мөн бид энэ шифрлэгдсэн мессежээр бүх зүйлийг хадгалдаг. Үүний дагуу бидний түлхүүрийн урт нь килобайтаас бага байдаг тул энэ нь ноцтой бөгөөд найдвартай юм.Дотор нь: – Одоо танд 2 килобайт хэрэгтэй байна уу?
EK: – Өчигдөр л 256 байсан юм шиг байна... За, өөр хаана байна?!
Үүний дагуу энэ нь анхных юм. Хоёрдугаарт, одоо байгаа шийдэл нь дахин шифрлэх процедурыг дэмждэг - хоёр хос "keks" (түлхүүр) байдаг бөгөөд тэдгээр нь шифрлэх "давцан" өгдөг (түлхүүр нь түлхүүрүүд, дек нь шифрлэдэг түлхүүрүүдийн деривативууд юм) . Хэрэв процедурыг эхлүүлсэн бол (энэ нь 3 сараас ± зарим үед тогтмол тохиолддог) бид шинэ хос "бялуу" татаж аваад өгөгдлийг дахин шифрлэдэг. Бид бүх өгөгдлийг задалж, шинэ аргаар шифрлэдэг тусдаа үйлчилгээтэй; Өгөгдөл нь шифрлэгдсэн түлхүүрийн танигчийн хажууд хадгалагдана. Үүний дагуу бид өгөгдлийг шинэ түлхүүрээр шифрлэмэгц хуучин түлхүүрээ устгадаг.
Заримдаа төлбөрийг гараар хийх шаардлагатай болдог...
Дотор нь: – Өөрөөр хэлбэл, хэрэв ямар нэгэн үйл ажиллагааны буцаан олголт ирсэн бол та үүнийг хуучин түлхүүрээр тайлсан хэвээр байх уу?
EK: - Тийм ээ.
Дотор нь: - Дараа нь дахиад нэг жижиг асуулт. Ямар нэгэн бүтэлгүйтэл, уналт, осол гарсан тохиолдолд гүйлгээг гараар хийх шаардлагатай болдог. Ийм нөхцөл байдал бий.
EK: - Тиймээ заримдаа.
Дотор нь: -Та энэ мэдээллийг хаанаас авдаг вэ? Эсвэл та өөрөө энэ агуулах руу явдаг уу?
EK: – Үгүй ээ, мэдээжийн хэрэг, бидэнд дэмжлэг үзүүлэх интерфейсийг агуулсан арын албаны систем бий. Хэрэв бид гүйлгээ ямар статустай байгааг мэдэхгүй бол (жишээлбэл, төлбөрийн систем хугацаа хэтэрсэн тохиолдолд хариу өгөх хүртэл) бид априори мэдэхгүй, өөрөөр хэлбэл бид эцсийн статусыг зөвхөн бүрэн итгэлтэйгээр өгдөг. Энэ тохиолдолд бид гүйлгээг гар аргаар боловсруулах тусгай статусыг өгдөг. Өглөө нь, маргааш нь, ийм болон ийм гүйлгээ нь төлбөрийн системд үлддэг гэсэн мэдээллийг хүлээн авмагц тэд үүнийг энэ интерфейс дээр гараар боловсруулдаг.
Дотор нь: -Надад хоёр асуулт байна. Тэдний нэг нь PCI DSS бүсийн үргэлжлэл юм: та тэдгээрийн хэлхээг хэрхэн бүртгэх вэ? Энэ асуулт нь хөгжүүлэгч ямар ч зүйлийг бүртгэлд оруулах боломжтой байсантай холбоотой юм! Хоёрдахь асуулт: засваруудыг хэрхэн яаж гаргах вэ? Мэдээллийн санд бариулыг ашиглах нь нэг сонголт боловч үнэгүй засварууд байж болно - тэнд ямар журам байдаг вэ? Гурав дахь асуулт нь RTO, RPO-тэй холбоотой байх. Таны хүртээмж 99,97, бараг дөрвөн ес байсан, гэхдээ миний ойлгосноор та хоёр дахь дата төвтэй, гурав дахь дата төвтэй, тав дахь дата төвтэй ... Та тэдгээрийг хэрхэн синхрончлох, хуулбарлах, бусад бүх зүйлийг хийх вэ?EK: -Эхнийхээс эхэлье. Эхний асуулт нь логуудын тухай байсан уу? Бид бүртгэл бичихдээ бүх эмзэг өгөгдлийг далдлах давхаргатай байдаг. Тэр маск болон нэмэлт талбаруудыг хардаг. Үүний дагуу манай бүртгэлүүд аль хэдийн далдлагдсан өгөгдөл болон PCI DSS хэлхээтэй гарч ирдэг. Энэ бол шалгалтын хэлтэст өгдөг байнгын ажлын нэг юм. Тэд даалгавар бүрийг, түүний дотор бичсэн логуудаа шалгах шаардлагатай бөгөөд энэ нь хөгжүүлэгч ямар нэг зүйл бичээгүй эсэхийг хянахын тулд кодыг шалгах явцад хийдэг тогтмол ажлуудын нэг юм. Үүний дараагийн шалгалтыг мэдээллийн аюулгүй байдлын алба долоо хоногт нэг удаа тогтмол хийдэг: сүүлийн өдрийн бүртгэлийг сонгон авч, бүх зүйлийг шалгахын тулд тестийн серверүүдээс тусгай сканнер анализатороор ажиллуулдаг.
Халуун засварын тухай. Үүнийг манай байршуулах журамд тусгасан болно. Бид засварын талаар тусдаа заалттай. Бид хэрэгцээтэй үед засвар үйлчилгээ хийдэг гэдэгт бид итгэдэг. Хувилбарыг угсармагц, ажиллуулангуут, олдвортой болмогц бид системийн администраторыг дэмжлэгийн дуудлагаар ажиллуулж, шаардлагатай үед нь ажиллуулдаг."Дөрвөн ес" орчим. Бидний одоо байгаа үзүүлэлт үнэхээр хүрч, бид өөр дата төвд үүнийг хийхийг хичээсэн. Одоо бид хоёр дахь дата төвтэй болсон бөгөөд бид тэдгээрийн хооронд чиглүүлж эхэлж байгаа бөгөөд өгөгдлийн төв хоорондын хуулбарын асуудал нь үнэхээр чухал биш асуулт юм. Бид нэгэн зэрэг янз бүрийн арга хэрэгслээр үүнийг шийдэх гэж оролдсон: бид ижил "Тарантула" ашиглахыг оролдсон - энэ нь бидэнд тус болсонгүй, би танд шууд хэлье. Тиймээс бид "сенс"-ийг гараар захиалж дуусгасан. Үнэн хэрэгтээ манай системийн программ бүр өгөгдлийн төвүүдийн хооронд шаардлагатай "өөрчлөгдсөн - хийгдсэн" синхрончлолыг асинхроноор гүйцэтгэдэг.
Дотор нь: – Хэрэв танд хоёр дахь нь байгаа бол яагаад гурав дахь нь аваагүй юм бэ? Учир нь хэн ч тархи хуваагдаагүй байна ...
EK: - Гэхдээ бидэнд хуваагдсан тархи байхгүй. Програм бүрийг мультимастер удирддаг тул хүсэлт аль төвд ирсэн нь бидэнд хамаагүй. Хэрэв манай мэдээллийн төвүүдийн аль нэг нь бүтэлгүйтвэл (бид үүнд найдаж байна) хэрэглэгчийн хүсэлтийн дундуур хоёр дахь дата төв рүү шилжвэл бид энэ хэрэглэгчээ алдахад бэлэн байна; гэхдээ эдгээр нь нэгж, үнэмлэхүй нэгж байх болно.
Дотор нь: - Оройн мэнд. Мэдээлэл өгсөнд баярлалаа. Та үйлдвэрлэлд туршилтын гүйлгээг явуулдаг өөрийн дибаглагчийн талаар ярьсан. Гэхдээ туршилтын гүйлгээний талаар бидэнд хэлээрэй! Энэ нь хэр гүнд ордог вэ?
EK: – Энэ нь бүхэл бүтэн бүрэлдэхүүн хэсгийн бүрэн мөчлөгийг дамждаг. Бүрэлдэхүүн хэсгийн хувьд туршилтын гүйлгээ болон үйлдвэрлэлийн хооронд ямар ч ялгаа байхгүй. Гэхдээ логикийн үүднээс авч үзвэл энэ нь систем дэх тусдаа төсөл бөгөөд зөвхөн туршилтын гүйлгээг явуулдаг.
Дотор нь: -Хаана нь тасалдаг юм бэ? Энд Core илгээсэн...
EK: – Бид туршилтын гүйлгээний хувьд энэ тохиолдолд “Кор”-ын ард байна... Бидэнд чиглүүлэлт гэх зүйл бий: “Кор” аль төлбөрийн систем рүү илгээхээ мэддэг - бид хуурамч төлбөрийн систем рүү илгээдэг бөгөөд энэ нь зүгээр л http дохио өгдөг. Тэгээд л болоо.
Дотор нь: – Надад хэлээч, таны өргөдлийг нэг том цул хэлбэрээр бичсэн үү, эсвэл зарим үйлчилгээ, бүр микро үйлчилгээ болгон хуваасан уу?
EK: – Манайд нэг цул байхгүй, мэдээжийн хэрэг үйлчилгээнд чиглэсэн хэрэглээ бий. Манай үйлчилгээг цул чулуугаар хийсэн гэж бид хошигнодог - тэдгээр нь үнэхээр том юм. Үүнийг бичил үйлчилгээ гэж нэрлэхэд хэцүү ч эдгээр нь хуваарилагдсан машинуудын ажилчдын ажилладаг үйлчилгээ юм.
Хэрэв сервер дээрх үйлчилгээ эвдэрсэн бол...
Дотор нь: -Тэгвэл надад дараагийн асуулт байна. Хэдийгээр энэ нь цул байсан ч гэсэн та эдгээр олон шуурхай серверүүдтэй гэж хэлсэн, тэд бүгд үндсэндээ өгөгдлийг боловсруулдаг бөгөөд асуулт нь: "Шуурхай сервер эсвэл програмын аль нэг нь эвдэрсэн тохиолдолд аливаа бие даасан холбоос , тэд ямар нэг хандалтын хяналттай юу? Тэдний хэн нь юу хийж чадах вэ? Би хэнтэй холбогдож ямар мэдээлэл авах ёстой вэ?
EK: - Тийм ээ, гарцаагүй. Аюулгүй байдлын шаардлага нь нэлээд ноцтой юм. Нэгдүгээрт, бид нээлттэй мэдээллийн хөдөлгөөнтэй бөгөөд портууд нь зөвхөн замын хөдөлгөөний хөдөлгөөнийг урьдчилан таамаглах портууд юм. Хэрэв бүрэлдэхүүн хэсэг нь өгөгдлийн сантай (Мускултай гэх мэт) 5-4-3-2-оор холбогдвол зөвхөн 5-4-3-2 нь нээлттэй байх ба бусад портууд болон хөдөлгөөний бусад чиглэлүүд боломжгүй болно. Үүнээс гадна манай үйлдвэрлэлд 10 орчим төрлийн хамгаалалтын гогцоо байдаг гэдгийг та ойлгох хэрэгтэй. Аппликешн ямар нэгэн байдлаар эвдэрсэн байсан ч, Бурхан хориглохоос халдагчид серверийн удирдлагын консол руу нэвтрэх боломжгүй болно, учир нь энэ нь өөр сүлжээний аюулгүй байдлын бүс юм.Дотор нь: – Мөн энэ хүрээнд миний хувьд илүү сонирхолтой зүйл бол та үйлчилгээнүүдтэй тодорхой гэрээтэй байдаг - тэд юу хийж чадах, ямар "үйл ажиллагаа"-аар тэд бие биетэйгээ холбогдож чадах вэ... Мөн ердийн урсгалд зарим тодорхой үйлчилгээнүүд зарим үйлчилгээг авахыг хүсдэг. эгнээ, нөгөө талд нь "үйлдэл"-ийн жагсаалт. Тэд ердийн нөхцөлд бусдад ханддаггүй бололтой, өөр хариуцлага хүлээх ёстой. Аль нэг нь халдлагад өртвөл тэр үйлчилгээний “үйлдэл”-ийг тасалдуулж чадах болов уу?..
EK: - Би ойлгож байна. Хэрэв ердийн нөхцөлд өөр сервертэй холбоо тогтоохыг зөвшөөрсөн бол тийм ээ. SLA гэрээний дагуу бид танд зөвхөн эхний 3 "үйлдэл"-ийг хийхийг зөвшөөрөхгүй бөгөөд танд 4 "үйлдэл"-ийг зөвшөөрөхгүй. Энэ нь бидний хувьд илүүц байж магадгүй, учир нь бид хэлхээнүүдийн хувьд зарчмын хувьд 4 түвшний хамгаалалтын системтэй болсон. Дотор талын түвшинд биш харин контураар өөрсдийгөө хамгаалахыг илүүд үздэг.
Visa, MasterCard, Sberbank хэрхэн ажилладаг
Дотор нь: – Хэрэглэгчийг нэг дата төвөөс нөгөөд шилжүүлэх тухай нэг зүйлийг тодруулмаар байна. Миний мэдэж байгаагаар Visa болон MasterCard нь 8583 хоёртын синхрон протоколыг ашиглан ажилладаг бөгөөд тэнд холимог байдаг. Би мэдэхийг хүссэн, одоо бид солих гэсэн үг юм - энэ нь шууд "Visa" болон "MasterCard" эсвэл төлбөрийн системээс өмнө, боловсруулахаас өмнө уу?
EK: - Энэ бол хольцын өмнө юм. Манай холимогууд нэг дата төвд байрладаг.
Дотор нь: – Товчхондоо та нэг холболтын цэгтэй юу?
EK: – “Visa” ба “MasterCard” - тийм ээ. Жишээлбэл, Visa болон MasterCard нь хоёр дахь хос хольцыг авахын тулд тусдаа гэрээ байгуулахын тулд дэд бүтцэд нэлээд ноцтой хөрөнгө оруулалт шаарддаг. Тэдгээр нь нэг дата төвд хадгалагдсан байдаг, гэвч бурхан өршөөж, Visa болон MasterCard-тай холбогдох боломжтой манай дата төв үхвэл бид Visa болон MasterCard-тай холболт тасрах болно...
Дотор нь: -Тэднийг яаж нөөцлөх вэ? Виза зарчмын хувьд зөвхөн нэг холболтыг зөвшөөрдөг гэдгийг би мэднэ!
EK: – Тоног төхөөрөмжөө өөрсдөө нийлүүлдэг. Ямар ч байсан дотроо бүрэн илүүдэлтэй тоног төхөөрөмж хүлээж авсан.
Дотор нь: -Тэгэхээр уг стенд нь тэдний Connects Orange компани юм уу?..
EK: - Тийм ээ.
Дотор нь: – Гэхдээ энэ тохиолдолд яах вэ: Хэрэв таны дата төв алга болвол яаж үргэлжлүүлэн ашиглах вэ? Эсвэл замын хөдөлгөөн зогсох уу?
EK: - Үгүй. Энэ тохиолдолд бид зүгээр л урсгалыг өөр суваг руу шилжүүлэх бөгөөд энэ нь мэдээжийн хэрэг бидний хувьд илүү үнэтэй бөгөөд манай үйлчлүүлэгчдэд илүү үнэтэй байх болно. Гэхдээ траффик нь бидний Visa, MasterCard-тэй шууд холболтоор дамжихгүй, харин нөхцөлт Сбербанкаар (маш хэтрүүлсэн).
Хэрэв би Сбербанкны ажилчдыг гомдоосон бол уучлалт гуйж байна. Гэхдээ манай статистик мэдээллээр Оросын банкуудын дунд Сбербанк хамгийн их унадаг. Сбербанканд ямар нэг зүйл унахгүй сар өнгөрөхгүй.
Зарим зар 🙂
Бидэнтэй хамт байсанд баярлалаа. Манай нийтлэл танд таалагдаж байна уу? Илүү сонирхолтой контент үзэхийг хүсч байна уу? Захиалга өгөх эсвэл найзууддаа санал болгох замаар биднийг дэмжээрэй, , Бидний танд зориулж бүтээсэн анхны түвшний серверүүдийн өвөрмөц аналоги: (RAID1 болон RAID10, 24 хүртэлх цөм, 40 ГБ хүртэл DDR4-тэй байх боломжтой).
Амстердам дахь Equinix Tier IV дата төвд Dell R730xd 2 дахин хямд байна уу? Зөвхөн энд Нидерландад! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 доллараас! тухай уншина уу
Эх сурвалж: www.habr.com