Өнөөдөр Bitrix24 үйлчилгээ нь хэдэн зуун гигабит траффикгүй, асар их серверийн флотгүй (хэдийгээр мэдээжийн хэрэг одоо байгаа хэд хэдэн үйлчилгээ байдаг). Гэхдээ олон үйлчлүүлэгчдийн хувьд энэ нь компанид ажиллах гол хэрэгсэл бөгөөд энэ нь бизнесийн чухал програм юм. Тиймээс унах арга байхгүй. Хэрэв осол гарсан ч үйлчилгээ маш хурдан "сэргэсэн" бол хэн ч юу ч анзаараагүй бол яах вэ? Ажлын чанар, үйлчлүүлэгчдийн тоог алдагдуулахгүйгээр дампууралтыг хэрхэн хэрэгжүүлэх боломжтой вэ? Bitrix24-ийн үүлэн үйлчилгээний захирал Александр Демидов манай блогт зориулж бүтээгдэхүүн оршин тогтносноос хойш 7 жилийн хугацаанд захиалгын систем хэрхэн өөрчлөгдсөн талаар ярьсан.
“Бид Bitrix24-ийг 7 жилийн өмнө SaaS хэлбэрээр эхлүүлсэн. Хамгийн гол бэрхшээл нь дараах байдалтай байсан байж магадгүй: энэ бүтээгдэхүүн нь SaaS хэлбэрээр олон нийтэд цацагдахаас өмнө хайрцагласан шийдэл хэлбэрээр байсан. Үйлчлүүлэгчид үүнийг биднээс худалдаж авч, сервер дээрээ байршуулж, корпорацийн портал байгуулжээ - ажилчдын харилцаа холбоо, файл хадгалах, даалгаврын менежмент, CRM гэх мэт ерөнхий шийдэл. Мөн 2012 он гэхэд бид үүнийг SaaS хэлбэрээр эхлүүлэхээр шийдсэн бөгөөд үүнийг өөрсдөө удирдаж, алдааг тэсвэрлэх чадвар, найдвартай байдлыг баталгаажуулсан. Бид энэ замд туршлага хуримтлуулсан, учир нь тэр болтол бидэнд ийм зүйл байгаагүй - бид үйлчилгээ үзүүлэгч биш зөвхөн програм хангамж үйлдвэрлэгч байсан.
Үйлчилгээг эхлүүлэхдээ бид хамгийн чухал зүйл бол алдааг тэсвэрлэх чадвар, найдвартай байдал, үйлчилгээний байнгын хүртээмжийг хангах явдал гэдгийг ойлгосон, учир нь хэрэв танд энгийн энгийн вэбсайт, дэлгүүр байгаа бол энэ нь таны дээр унаж, тэндээ суудаг. нэг цагийн дотор зөвхөн чи зовж шаналж, захиалгаа алдаж, үйлчлүүлэгчээ алддаг, гэхдээ таны үйлчлүүлэгчийн хувьд энэ нь түүний хувьд тийм ч чухал биш юм. Тэр мэдээж бухимдсан ч өөр сайтаас очоод худалдаж авсан. Хэрэв энэ нь компани доторх бүх ажил, харилцаа холбоо, шийдвэрүүд холбогдсон програм юм бол хамгийн чухал зүйл бол хэрэглэгчдийн итгэлийг олж авах, өөрөөр хэлбэл тэднийг унагахгүй, унахгүй байх явдал юм. Учир нь доторх ямар нэг зүйл ажиллахгүй бол бүх ажил зогсдог.
SaaS хэлбэрээр Bitrix.24
Бид анхны прототипийг олон нийтэд танилцуулахаас нэг жилийн өмнө буюу 2011 онд угсарсан. Бид үүнийг долоо хоногийн дотор угсарч, харж, эргүүлсэн - бүр ажиллаж байсан. Өөрөөр хэлбэл, та маягт руу орж, тэнд порталын нэрийг оруулаад шинэ портал нээгдэж, хэрэглэгчийн бааз бий болно. Бид үүнийг харж, зарчмын хувьд бүтээгдэхүүнээ үнэлж, хасаж, бүтэн жилийн турш үргэлжлүүлэн сайжруулсан. Учир нь бидэнд том даалгавар байсан: бид хоёр өөр кодын бааз хийхийг хүсээгүй, тусдаа багцалсан бүтээгдэхүүн, тусдаа үүлэн шийдлүүдийг дэмжихийг хүсээгүй - бид бүгдийг нэг код дотор хийхийг хүссэн.
Тухайн үеийн ердийн вэб програм бол зарим PHP код ажилладаг сервер, mysql мэдээллийн сан, файлуудыг байршуулж, баримт бичиг, зургийг байршуулах хавтсанд хийдэг байсан - энэ бүгд ажилладаг. Харамсалтай нь, үүнийг ашиглан маш тогтвортой вэб үйлчилгээг эхлүүлэх боломжгүй юм. Тэнд тархсан кэшийг дэмждэггүй, мэдээллийн баазын хуулбарыг дэмждэггүй.
Бид шаардлагуудыг томъёолсон: энэ нь өөр өөр байршилд байрлах, хуулбарлахыг дэмжих, газарзүйн хувьд өөр өөр мэдээллийн төвүүдэд байрлуулах чадвар юм. Бүтээгдэхүүний логик, үнэн хэрэгтээ мэдээллийн хадгалалтыг салга. Ачааллын дагуу динамикаар хэмжиж, статикийг бүхэлд нь тэсвэрлэх чадвартай байх. Эдгээрээс харахад тухайн бүтээгдэхүүнд тавигдах шаардлагууд гарч ирсэн бөгөөд бид жилийн туршид сайжруулсан. Энэ хугацаанд нэгдмэл болсон платформ дээр хайрцагласан шийдэл, өөрсдийн үйлчилгээнд зориулж бид хэрэгцээтэй зүйлүүдэд дэмжлэг үзүүлсэн. Бүтээгдэхүүний түвшинд MySQL хуулбарлах дэмжлэг: өөрөөр хэлбэл код бичдэг хөгжүүлэгч өөрийн хүсэлтийг хэрхэн хуваарилах талаар боддоггүй, тэр манай api-г ашигладаг бөгөөд бид мастеруудын хооронд бичих, унших хүсэлтийг хэрхэн зөв хуваарилахаа мэддэг. болон боолууд.
Бид янз бүрийн клоуд объект хадгалахад зориулсан бүтээгдэхүүний түвшинд дэмжлэг үзүүлсэн: google хадгалах сан, amazon s3, мөн нээлттэй стек swift-ийн дэмжлэг. Тиймээс энэ нь үйлчилгээний хувьд бидэнд ч, багц шийдэлтэй ажилладаг хөгжүүлэгчдэд ч тохиромжтой байсан: хэрэв тэд зүгээр л ажилдаа манай API-г ашигладаг бол файлыг хаана, файлын систем эсвэл дотооддоо хадгалах талаар боддоггүй. объектын файлын сан дахь .
Үүний үр дүнд бид бүх мэдээллийн төвийн түвшинд нөөцлөхөөр шийдсэн. 2012 онд бид Amazon AWS-ийг бүхэлд нь эхлүүлсэн, учир нь бид энэ платформ дээр ажиллаж байсан туршлагатай - манай вэбсайт тэнд байрладаг. Бүс нутаг бүрт Amazon хэд хэдэн хүртээмжтэй бүсүүдтэй байдаг нь бидний анхаарлыг татсан бөгөөд үнэндээ (тэдгээрийн нэр томъёогоор) бие биенээсээ бага эсвэл бага бие даасан хэд хэдэн дата төвүүд байдаг бөгөөд бидэнд бүхэл бүтэн мэдээллийн төвийн түвшинд нөөцлөх боломжийг олгодог. Хэрэв гэнэт бүтэлгүйтвэл өгөгдлийн сангууд master-master хэлбэрээр хуулбарлагдаж, вэб програмын серверүүд нөөцлогдож, статик өгөгдлийг s3 объектын санах ой руу шилжүүлдэг. Ачаалал тэнцвэртэй байсан - тэр үед Амазон элбээр, гэхдээ хэсэг хугацааны дараа бид илүү төвөгтэй логик хэрэгтэй байсан тул бид өөрсдийн ачааллын тэнцвэржүүлэгчид ирсэн.
Тэдний хүссэн зүйл бол олж авсан зүйл юм ...
Бидний баталгаажуулахыг хүссэн бүх үндсэн зүйл - серверүүд өөрсдийн алдааг тэсвэрлэх чадвар, вэб програмууд, мэдээллийн сан - бүх зүйл сайн ажилласан. Хамгийн энгийн хувилбар: хэрэв манай вэб програмуудын аль нэг нь бүтэлгүйтвэл бүх зүйл энгийн байдаг - тэдгээрийг тэнцвэржүүлэхээс хасдаг.
Тэнцвэржүүлэгч (тухайн үед Амазоны тохой байсан) ажиллагаагүй болсон машинуудыг эрүүл бус гэж тэмдэглэж, ачааллын хуваарилалтыг унтраажээ. Amazon autoscaling ажилласан: ачаалал нэмэгдэхэд шинэ машинууд автомат масштабын бүлэгт нэмэгдэж, ачааллыг шинэ машинуудад хуваарилсан - бүх зүйл хэвийн байсан. Манай тэнцвэржүүлэгчийн хувьд логик нь ойролцоогоор ижил байдаг: хэрэв програмын серверт ямар нэг зүйл тохиолдвол бид түүнээс хүсэлтийг устгаж, эдгээр машинуудыг хаяж, шинээр эхлүүлж, үргэлжлүүлэн ажиллана. Энэ схем нь олон жилийн туршид бага зэрэг өөрчлөгдсөн боловч үргэлжлүүлэн ажилласаар байна: энэ нь энгийн, ойлгомжтой, үүнтэй холбоотой ямар ч бэрхшээл байхгүй.
Бид дэлхийн өнцөг булан бүрт ажилладаг, үйлчлүүлэгчдийн ачааллын оргил үе нь огт өөр бөгөөд эв найрамдалтай байдлаар бид системийнхээ аль ч бүрэлдэхүүн хэсэг дээр ямар ч үед тодорхой үйлчилгээний ажлыг гүйцэтгэх боломжтой байх ёстой. Тиймээс бид мэдээллийн санг үйл ажиллагаанаас нь унтрааж, ачааллыг хоёр дахь дата төв рүү дахин хуваарилах боломж байна.
Энэ бүхэн хэрхэн ажилладаг вэ? — Бид траффикийг ажиллаж байгаа дата төв рүү шилжүүлдэг - хэрэв дата төв дээр осол гарвал бүрэн, хэрэв энэ нь бидний нэг мэдээллийн сантай хийхээр төлөвлөж байгаа ажил бол бид эдгээр үйлчлүүлэгчдэд үйлчлэх хөдөлгөөний нэг хэсгийг хоёр дахь дата төв рүү шилжүүлж, түр зогсоодог. түүний хуулбар. Хоёрдахь дата төвийн ачаалал нэмэгдсэн тул вэб програмуудад шинэ машин шаардлагатай бол автоматаар эхлэх болно. Бид ажлыг дуусгаж, хуулбарыг сэргээж, бүх ачааллыг буцааж өгнө. Хэрэв бид хоёр дахь DC-д зарим ажлыг толин тусгал хийх шаардлагатай бол, жишээлбэл, системийн шинэчлэлтүүдийг суулгах эсвэл хоёр дахь мэдээллийн санд тохиргоог өөрчлөх шаардлагатай бол ерөнхийдөө бид ижил зүйлийг өөр чиглэлд давтана. Хэрэв энэ нь осол бол бид бүх зүйлийг өчүүхэн байдлаар хийдэг: бид хяналтын систем дэх үйл явдлыг зохицуулах механизмыг ашигладаг. Хэрэв хэд хэдэн шалгалт хийгдэж, статус нь ноцтой болвол бид энэ зохицуулагчийг ажиллуулж, энэ эсвэл өөр логикийг гүйцэтгэх боломжтой. Өгөгдлийн сан бүрийн хувьд бид аль сервер нь түүнийг шилжүүлэн суулгах, боломжгүй бол траффикийг хаана солих шаардлагатайг зааж өгдөг. Түүхийн хувьд бид нагиос эсвэл түүний зарим сэрээг нэг эсвэл өөр хэлбэрээр ашигладаг. Зарчмын хувьд үүнтэй төстэй механизмууд бараг бүх хяналтын системд байдаг; бид үүнээс илүү төвөгтэй зүйлийг хараахан ашиглаагүй байгаа ч хэзээ нэгэн цагт бид үүнийг ашиглах болно. Одоо хяналтыг ашиглах боломжгүй байгаа үед эхлүүлж, ямар нэг зүйлийг өөрчлөх боломжтой болсон.
Бид бүгдийг захиалсан уу?
Бидэнд АНУ-аас олон үйлчлүүлэгчид, Европоос олон үйлчлүүлэгчид, Дорнод руу ойр байдаг Япон, Сингапур гэх мэт олон үйлчлүүлэгчид байдаг. Мэдээжийн хэрэг, үйлчлүүлэгчдийн асар их хувь нь Орос улсад байдаг. Энэ нь ажил нэг бүс нутагт биш юм. Хэрэглэгчид хурдан хариу өгөхийг хүсч байна, орон нутгийн янз бүрийн хууль тогтоомжийг дагаж мөрдөх шаардлагууд байдаг бөгөөд бид бүс бүрт хоёр дата төвийг нөөцөлж байгаа бөгөөд үүнээс гадна зарим нэмэлт үйлчилгээнүүд байдаг бөгөөд эдгээрийг нэг бүс нутагт байрлуулахад тохиромжтой байдаг. энэ бүс ажиллаж байна. REST зохицуулагчид, зөвшөөрлийн серверүүд нь үйлчлүүлэгчийн үйл ажиллагаанд тийм ч чухал биш тул та тэдгээрийг бага зэрэг сааталтайгаар сольж болно, гэхдээ та тэдгээрийг хэрхэн хянах, юу хийх талаар дугуйг шинээр зохион бүтээхийг хүсэхгүй байна. тэдэнтэй хамт. Тиймээс бид нэмэлт бүтээгдэхүүн үйлдвэрлэхэд ямар нэгэн ур чадварыг хөгжүүлэхийн оронд одоо байгаа шийдлүүдийг дээд зэргээр ашиглахыг хичээж байна. Мөн хаа нэгтээ бид DNS түвшинд шилжихийг өчүүхэн ашигладаг бөгөөд бид ижил DNS-ээр үйлчилгээний амьд байдлыг тодорхойлдог. Амазон нь Route 53 үйлчилгээтэй, гэхдээ энэ нь зөвхөн DNS-д нэвтрэх боломжтой биш бөгөөд энэ нь илүү уян хатан бөгөөд тохиромжтой юм. Түүгээр дамжуулан та үйлчлүүлэгч хаанаас ирснийг тодорхойлж, түүнд тодорхой бүртгэл өгөхөд ашиглахдаа гео байршилтай газарзүйн хуваарилагдсан үйлчилгээг бий болгож чадна - үүний тусламжтайгаар та бүтэлгүйтлийн архитектурыг бий болгож чадна. Үүнтэй ижил эрүүл мэндийн шалгалтыг 53-р замд өөрөө тохируулсан бөгөөд та хянагддаг төгсгөлийн цэгүүдийг тохируулж, хэмжигдэхүүнийг тогтоож, үйлчилгээний "амьдрал" -ыг тодорхойлох протоколуудыг тохируулна - tcp, http, https; үйлчилгээ амьд байгаа эсэхийг тодорхойлох шалгалтын давтамжийг тохируулах. Мөн DNS дотроос та юуг анхдагч, юу нь хоёрдогч байх, 53-р маршрутын дотор эрүүл мэндийн үзлэг хийгдэж байгаа бол хаашаа шилжихийг зааж өгнө. Энэ бүгдийг бусад хэрэгслээр хийж болно, гэхдээ яагаад тохиромжтой вэ - бид үүнийг тохируулсан. Нэг удаа босч, дараа нь бид хэрхэн шалгах, хэрхэн солих талаар огт бодох хэрэггүй: бүх зүйл өөрөө ажилладаг.
Эхний "гэхдээ": 53 дугаарыг өөрөө яаж, юугаар нөөцлөх вэ? Түүнд ямар нэгэн зүйл тохиолдвол хэн мэдэх вэ? Аз болоход бид энэ тармуур дээр хэзээ ч гишгэж байгаагүй, гэхдээ бид яагаад захиалга өгөх шаардлагатай гэж бодсон тухай түүхийг дахин хэлэх болно. Энд бид өөрсдөдөө зориулж сүрэл бэлтгэсэн. Өдөрт хэд хэдэн удаа бид 53-р чиглэлд байгаа бүх бүсийг бүрэн буулгах ажлыг хийдэг. Amazon-ийн API нь танд тэдгээрийг JSON-д хялбархан илгээх боломжийг олгодог бөгөөд бид үүнийг хөрвүүлж, тохиргоо хэлбэрээр байршуулж, ойролцоогоор хэлэхэд нөөц тохиргоотой хэд хэдэн нөөц сервертэй. Хэрэв ямар нэг зүйл тохиолдвол бид DNS тохиргооны өгөгдлийг алдалгүйгээр гараар хурдан байрлуулж болно.
Хоёр дахь "гэхдээ": Энэ зурган дээрх юуг хараахан хадгалаагүй байна вэ? Тэнцвэржүүлэгч өөрөө! Манай үйлчлүүлэгчдийг бүс нутгаар хуваарилах нь маш энгийн. Бидэнд bitrix24.ru, bitrix24.com, .de домайнууд бий - одоо 13 өөр домэйн байдаг бөгөөд тэдгээр нь янз бүрийн бүсэд ажилладаг. Бид дараахь зүйлд хүрсэн: бүс бүр өөрийн тэнцвэржүүлэгчтэй байдаг. Энэ нь сүлжээний хамгийн их ачаалал хаана байгаагаас хамааран бүс нутгуудад түгээхэд илүү тохиромжтой болгодог. Хэрэв энэ нь нэг тэнцвэржүүлэгчийн түвшинд бүтэлгүйтсэн бол үүнийг зүгээр л үйлчилгээнээс хасч, dns-ээс устгана. Бүлэг тэнцвэржүүлэгчид ямар нэгэн асуудал гарвал тэдгээрийг өөр сайтууд дээр нөөцөлж, тэдгээрийн хооронд шилжих нь ижил маршрутыг ашиглан хийгддэг53, учир нь богино TTL-ийн улмаас сэлгэх нь дээд тал нь 2, 3, 5 минутын дотор явагддаг. .
Гурав дахь "гэхдээ": Юуг хараахан захиалаагүй байна вэ? S3, зөв. Бид хэрэглэгчдэд зориулж хадгалдаг файлуудаа s3-д байрлуулахдаа энэ нь хуяг цоолж байгаа бөгөөд тэнд юу ч нөөцлөх шаардлагагүй гэж чин сэтгэлээсээ итгэсэн. Гэвч бүх зүйл өөрөөр болдог гэдгийг түүх гэрчилдэг. Ерөнхийдөө Amazon нь S3-ийг үндсэн үйлчилгээ гэж тодорхойлдог, учир нь Амазон өөрөө S3-ийг машины зураг, тохиргоо, AMI зураг, хормын хувилбаруудыг хадгалахад ашигладаг... Мөн хэрэв s3 гацсан бол энэ 7 жилийн хугацаанд нэг удаа тохиолдсон шиг, бидний ашиглаж байгаа хугацаанд. bitrix24, үүнийг сэнс шиг дагадаг. Виртуал машиныг эхлүүлэх боломжгүй, api алдаа гэх мэт олон зүйл гарч ирдэг.
Мөн S3 унаж болно - энэ нь нэг удаа тохиолдсон. Тиймээс бид дараах схемд ирсэн: хэдэн жилийн өмнө Орос улсад нийтийн эзэмшлийн объектын ноцтой агуулах байхгүй байсан бөгөөд бид өөрсдөө ямар нэгэн зүйл хийх хувилбарыг авч үзсэн ... Аз болоход бид үүнийг хийж эхлээгүй, учир нь бид Бидэнд байхгүй мэргэжлийг ухаж төнхөж магадгүй юм. Одоо Mail.ru нь s3-тэй нийцтэй санах ойтой, Yandex-д, мөн бусад олон үйлчилгээ үзүүлэгчид байдаг. Эцэст нь бид нэгдүгээрт, нөөцлөлт, хоёрдугаарт, орон нутгийн хуулбартай ажиллах чадвартай байхыг хүсч байна гэсэн санаад хүрсэн. ОХУ-ын бүс нутгийн хувьд бид Mail.ru Hotbox үйлчилгээг ашигладаг бөгөөд энэ нь API s3-тай нийцдэг. Аппликешн доторх кодод томоохон өөрчлөлт оруулах шаардлагагүй байсан бөгөөд бид дараах механизмыг хийсэн: s3-д объект үүсгэх/устгахыг өдөөдөг триггерүүд байдаг, Amazon нь Lambda хэмээх үйлчилгээтэй - энэ бол сервергүй кодыг эхлүүлэх явдал юм. Энэ нь тодорхой өдөөгч идэвхжсэн үед л хийгдэх болно.
Бид үүнийг маш энгийнээр хийсэн: хэрэв бидний гох асаалттай бол бид объектыг Mail.ru хадгалах сан руу хуулах кодыг ажиллуулдаг. Орон нутгийн мэдээллийн хуулбартай ажиллах ажлыг бүрэн эхлүүлэхийн тулд бид урвуу синхрончлол хийх шаардлагатай бөгөөд ингэснээр Оросын сегментэд байгаа үйлчлүүлэгчид өөрт ойр байгаа хадгалах сантай ажиллах боломжтой болно. Мэйл нь хадгалах сандаа триггерүүдийг дуусгах гэж байна - энэ нь дэд бүтцийн түвшинд урвуу синхрончлолыг хийх боломжтой байх болно, гэхдээ одоогоор бид үүнийг өөрийн кодын түвшинд хийж байна. Хэрэв бид үйлчлүүлэгч файл байршуулсан гэж үзвэл кодын түвшинд бид үйл явдлыг дараалалд байрлуулж, боловсруулж, урвуу хуулбарыг хийдэг. Энэ нь яагаад муу вэ: хэрэв бид бүтээгдэхүүнээсээ гадуур, өөрөөр хэлбэл гадны ямар нэгэн аргаар объектуудтай ямар нэгэн ажил хийвэл бид үүнийг анхаарч үзэхгүй. Тиймээс бид хадгалах түвшинд триггер гарч ирэхийг дуустал хүлээдэг бөгөөд ингэснээр бид хаанаас кодыг ажиллуулахаас үл хамааран бидэнд ирсэн объектыг нөгөө чиглэлд хуулж авдаг.
Кодын түвшинд бид үйлчлүүлэгч бүрийн хувьд хоёр хадгалах санг бүртгэдэг: нэгийг нь үндсэн, нөгөөг нь нөөц гэж үздэг. Хэрэв бүх зүйл хэвийн байвал бид өөрт ойр байгаа хадгалах сантай ажилладаг: Амазон дахь манай үйлчлүүлэгчид S3-тэй, Орост ажилладаг хүмүүс Hotbox-той ажилладаг. Хэрэв туг идэвхжсэн бол шилжүүлэлт холбогдсон байх ёстой бөгөөд бид үйлчлүүлэгчдийг өөр санах ой руу шилжүүлдэг. Бид энэ нүдийг бүс тус бүрээр нь шалгах боломжтой бөгөөд тэдгээрийг хооронд нь сольж болно. Бид үүнийг практикт хараахан ашиглаагүй байгаа, гэхдээ бид энэ механизмыг хангасан бөгөөд хэзээ нэгэн цагт энэ шилжүүлэгч хэрэгтэй болно гэж бодож байна. Энэ нь аль хэдийн нэг удаа тохиолдсон.
Амазон зугтсан ...
Энэ дөрөвдүгээр сард Орост Telegram-ыг хааж эхэлсний ой тохиож байна. Үүнд хамгийн их өртсөн үйлчилгээ үзүүлэгч бол Amazon юм. Харамсалтай нь дэлхий даяар ажиллаж байсан Оросын компаниуд илүү их хохирол амссан.
Хэрэв компани нь дэлхийн хэмжээнд байгаа бөгөөд Орос бол түүний хувьд маш жижиг сегмент бол 3-5% - ямар нэг байдлаар та тэднийг золиослох боломжтой.
Хэрэв энэ нь цэвэр Оросын компани бол - үүнийг орон нутагт байрлуулах шаардлагатай гэдэгт би итгэлтэй байна - энэ нь зүгээр л хэрэглэгчдэд тохиромжтой, тав тухтай байх болно, эрсдэл бага байх болно.
Хэрэв энэ компани дэлхийн хэмжээнд үйл ажиллагаа явуулдаг, Орос болон дэлхийн өнцөг булан бүрээс ойролцоогоор ижил тооны үйлчлүүлэгчидтэй компани бол яах вэ? Сегментүүдийн холболт чухал бөгөөд тэдгээр нь хоорондоо ямар нэг байдлаар ажиллах ёстой.
2018 оны 3-р сарын сүүлчээр Роскомнадзор хамгийн том операторуудад захидал илгээж, тэд Zello мессенжерийг хаахын тулд хэдэн сая Amazon IP хаягийг хаахаар төлөвлөж байна гэж мэдэгджээ. Эдгээр үйлчилгээ үзүүлэгчдийн ачаар тэд захидлыг хүн бүрт амжилттай дамжуулж, Амазонтой холбоо тасарч магадгүй гэсэн ойлголттой болсон. Баасан гарагт бид servers.ru сайтын хамт олон руу сандран гүйж: "Найзууд аа, бидэнд Орост ч биш, Амазонд ч биш, жишээ нь Амстердамд хаа нэгтээ байрлах хэд хэдэн сервер хэрэгтэй байна" гэж хэлэв. Бид ямар нэгэн байдлаар нөлөөлж чадахгүй байгаа зарим төгсгөлийн цэгүүдэд, жишээлбэл ижил sXNUMX-ийн төгсгөлийн цэгүүдэд өөрсдийн VPN болон прокси-г ямар нэгэн байдлаар суулгаж өгөхийн тулд бид шинэ үйлчилгээ босгож, өөр IP авахыг оролдож чадахгүй, Бид та тэнд очих хэрэгтэй хэвээр байна. Хэдхэн хоногийн дотор бид эдгээр серверүүдийг суулгаж, ажиллуулж, ерөнхийдөө блоклох үйл явц эхлэхэд бэлдсэн. RKN үймээн самууныг хараад "Үгүй ээ, бид одоо юу ч хаахгүй" гэж хэлсэн нь сонин байна. (Гэхдээ энэ нь Telegram-ыг хааж эхлэх хүртэл яг ийм зүйл юм.) Тойрох боломжуудыг тохируулж, хаах ажиллагааг нэвтрүүлээгүй гэдгийг ойлгосон ч бид бүх асуудлыг шийдэж эхлээгүй. Тиймээ, ямар ч тохиолдолд.
Мөн 2019 онд бид түгжигдсэн нөхцөлд амьдарсаар байна. Би өнгөрсөн шөнө харлаа: сая орчим IP хаагдсан хэвээр байна. Үнэн, Амазон бараг бүхэлдээ хаагдсан, оргил үедээ 20 сая хаягт хүрсэн ... Ер нь бодит байдал бол уялдаа холбоо, сайн уялдаа холбоо байхгүй байж магадгүй юм. Гэнэт. Энэ нь техникийн шалтгааны улмаас байхгүй байж магадгүй юм - гал түймэр, экскаватор гэх мэт. Эсвэл бидний харж байгаагаар бүхэлдээ техникийн биш. Тиймээс, өөрийн гэсэн AS-тай том, том хэн нэгэн үүнийг өөр аргаар удирдаж магадгүй юм - шууд холболт болон бусад зүйлс аль хэдийн l2 түвшинд байна. Гэхдээ манайх шиг эсвэл бүр жижиг хувилбарт та өөр газар суулгасан, урьдчилан тохируулсан vpn, прокси серверүүдийн түвшинд нөөцөлж, тэдгээр сегментүүдэд тохиргоог хурдан солих боломжтой. Эдгээр нь таны холболтод чухал ач холбогдолтой. Амазоныг хааж эхлэхэд энэ нь бидэнд нэг бус удаа хэрэг болсон; хамгийн муу тохиолдолд бид зөвхөн S3 урсгалыг тэднээр дамжуулан хийхийг зөвшөөрсөн боловч аажмаар энэ бүхэн шийдэгдсэн.
Бүх үйлчилгээ үзүүлэгчийг хэрхэн нөөцлөх вэ?
Яг одоо бидэнд Амазон бүхэлдээ уналтад орох хувилбар алга. Бид Оросын хувьд ижил төстэй хувилбартай. Орос улсад биднийг нэг үйлчилгээ үзүүлэгч ажиллуулж байсан бөгөөд тэднээс хэд хэдэн сайттай болохыг сонгосон. Жилийн өмнө бид нэг асуудалтай тулгарсан: эдгээр нь хоёр дата төв байсан ч үйлчилгээ үзүүлэгчийн сүлжээний тохиргооны түвшинд аль хэдийн асуудал үүсч магадгүй бөгөөд энэ нь хоёр дата төвд нөлөөлсөн хэвээр байх болно. Мөн бид хоёр сайт дээр ажиллах боломжгүй болж магадгүй. Мэдээж ийм зүйл болсон. Бид доторх архитектурыг дахин авч үзсэн. Энэ нь тийм ч их өөрчлөгдөөгүй, гэхдээ Оросын хувьд бид нэг үйлчилгээ үзүүлэгчээс биш, хоёр өөр сайтаас хоёр сайттай болсон. Хэрэв нэг нь амжилтгүй болвол бид нөгөө рүү шилжиж болно.
Таамаглалаар Amazon-ийн хувьд бид өөр үйлчилгээ үзүүлэгчийн түвшинд захиалга өгөх боломжийг авч үзэж байна; магадгүй Google, магадгүй өөр хэн нэгэн... Гэхдээ одоог хүртэл бид практик дээр Амазон нэг хүртээмжийн бүсийн түвшинд осол гардаг бол бүхэл бүтэн бүс нутгийн түвшинд осол аваар гарах нь маш ховор байдгийг бид ажигласан. Тиймээс бид онолын хувьд "Амазон бол Амазон биш" гэсэн захиалга хийж магадгүй гэсэн санаатай байгаа ч бодит байдал дээр энэ нь хараахан болоогүй байна.
Автоматжуулалтын талаар хэдэн үг хэлье
Автоматжуулалт үргэлж шаардлагатай байдаг уу? Энд Даннинг-Крюгерийн эффектийг эргэн санах нь зүйтэй. "X" тэнхлэгт бидний олж авсан мэдлэг, туршлага, "y" тэнхлэгт бидний үйл ажиллагаанд итгэх итгэл байдаг. Эхлээд бид юу ч мэдэхгүй, огтхон ч итгэлтэй биш байна. Дараа нь бид бага зэрэг мэдэж, өөртөө итгэлтэй болдог - энэ бол "тэнэг байдлын оргил" гэж нэрлэгддэг "сэтгэлийн хямрал ба эр зориг" зургаар сайн дүрслэгдсэн байдаг. Дараа нь бид бага зэрэг сурсан тул тулалдаанд ороход бэлэн байна. Дараа нь бид маш ноцтой алдаанууд дээр гишгэж, ямар нэг зүйлийг мэдэж байгаа мэт боловч үнэндээ бид тийм ч ихийг мэдэхгүй цөхрөлийн хөндийд ордог. Дараа нь бид туршлага хуримтлуулахын хэрээр өөртөө итгэлтэй болдог.
Зарим осолд автоматаар шилжих тухай бидний логикийг энэ графикаар маш сайн дүрсэлсэн болно. Бид эхэлсэн - бид юу ч хийхээ мэдэхгүй байсан, бараг бүх ажлыг гараар хийсэн. Дараа нь бид бүх зүйлд автоматжуулалтыг холбож, тайван унтаж чадна гэдгийг ойлгосон. Гэнэт бид мега тармуур дээр гишгэдэг: худал эерэг үр дүн гарч, бид үүнийг хийх ёсгүй байсан бол замын хөдөлгөөнийг нааш цааш сольдог. Үүний үр дүнд хуулбарлах нь эвдэрдэг эсвэл өөр ямар нэгэн зүйл - энэ бол цөхрөлийн хөндий юм. Тэгээд бид бүх зүйлд ухаалгаар хандах ёстой гэсэн ойлголттой болдог. Өөрөөр хэлбэл, хуурамч дохиолол өгөх боломжийг хангаж, автоматжуулалтад найдах нь утга учиртай юм. Гэхдээ! Хэрэв үр дагавар нь сүйрлийн үр дагаварт хүргэж болзошгүй бол жижүүрийн ээлж, жижүүрийн инженерүүд үнэхээр осол гарсан эсэхийг шалгаж, хянаж, шаардлагатай арга хэмжээг гараар хийх нь дээр ...
дүгнэлт
7 жилийн хугацаанд бид ямар нэг зүйл унах үед сандрах, сандрах, асуудал гэж байдаггүй, зөвхөн даалгавар байдаг, тэдгээрийг шийдвэрлэх ёстой, мөн шийдэх боломжтой гэсэн ойлголт руу шилжсэн. Үйлчилгээг барьж байгуулахдаа дээрээс нь харж, учирч болох бүх эрсдлийг үнэл. Хэрэв та тэдгээрийг даруй олж харвал цомхотголыг урьдчилан хангаж, доголдолд тэсвэртэй дэд бүтцийг бий болгох боломжийг олгох хэрэгтэй, учир нь бүтэлгүйтэж, үйлчилгээний боломжгүй байдалд хүргэж болзошгүй аливаа цэг үүнийг хийх нь гарцаагүй. Хэдийгээр s3 гэх мэт зарим дэд бүтцийн элементүүд бүтэлгүйтэх нь дамжиггүй юм шиг санагдаж байсан ч тэд боломжтой гэдгийг санаарай. Наад зах нь онолын хувьд ямар нэг зүйл тохиолдвол тэдэнтэй юу хийх талаар санаа аваарай. Эрсдэлийн удирдлагын төлөвлөгөөтэй байх. Та бүх зүйлийг автоматаар эсвэл гараар хийх талаар бодож байгаа бол эрсдлийг үнэлээрэй: автоматжуулалт бүх зүйлийг сольж эхэлбэл юу болох вэ - энэ нь осолтой харьцуулахад бүр дордохгүй гэж үү? Магадгүй хаа нэгтээ автоматжуулалтыг ашиглах, жижүүрийн инженерийн хариу үйлдэл хоёрын хооронд боломжийн буулт хийх шаардлагатай байж магадгүй, тэр бодит дүр зургийг үнэлж, ямар нэг зүйлийг газар дээр нь солих шаардлагатай юу эсвэл "тийм, гэхдээ одоо биш" гэдгийг ойлгох болно.
Төгс төгөлдөр байдал ба бодит хүчин чармайлт, цаг хугацаа, мөнгө, цаг хугацаа, мөнгө хоёрын хооронд боломжийн буулт хийх.
Энэхүү текст нь Александр Демидовын бага хурлын илтгэлийн шинэчилсэн, өргөтгөсөн хувилбар юм .
Эх сурвалж: www.habr.com