Топ факапов Цян

Бүгд сайн! 

Намайг Никита гэдэг, би Cian инженерийн багийн ахлагч. Тус компанид хүлээсэн үүргийнхээ нэг бол үйлдвэрлэл дэх дэд бүтэцтэй холбоотой зөрчлийн тоог XNUMX хүртэл бууруулах явдал юм.
Доор хэлэлцэх зүйл нь бидэнд маш их зовлон авчирсан бөгөөд энэ нийтлэлийн зорилго нь бусад хүмүүс бидний алдааг давтахаас урьдчилан сэргийлэх, эсвэл тэдний нөлөөллийг багасгах явдал юм. 

Оршил

Эрт дээр үед Cian нь цул хэсгүүдээс бүрдэх бөгөөд микро үйлчилгээний талаар ямар ч мэдээлэл байхгүй байхад бид 3-5 хуудсыг шалгаж нөөцийн бэлэн байдлыг хэмжсэн. 

Тэд хариулдаг - бүх зүйл зүгээр, хэрэв тэд удаан хугацаанд хариулахгүй бол сэрэмжлүүлэг. Болсон явдал гэж үзэхийн тулд хэр удаан ажилгүй байх ёстойг хүмүүс хурал дээр шийджээ. Хэргийн мөрдөн байцаалтад инженерүүдийн баг байнга оролцож байсан. Мөрдөн байцаалтын ажиллагаа дуусмагц тэд үхлийн дараах бичлэгийг бичжээ - энэ нь юу болсон, хэр удаан үргэлжилсэн, бид яг одоо юу хийсэн, ирээдүйд юу хийх вэ гэсэн форматтай цахим шуудангаар бичсэн. 

Сайтын үндсэн хуудсууд эсвэл бид доод хэсэгт хүрсэн гэдгийг хэрхэн ойлгож байна

 
Алдааны тэргүүлэх ач холбогдлыг ямар нэгэн байдлаар ойлгохын тулд бид бизнесийн үйл ажиллагаанд хамгийн чухал сайтын хуудсуудыг тодорхойлсон. Тэдгээрийг ашигласнаар бид амжилттай/амжилтгүй хүсэлт, завсарлагааны тоог тоолдог. Бид ажиллах хугацааг ингэж хэмждэг. 

Зар сурталчилгаа хайх, илгээх үндсэн үйлчилгээг хариуцдаг сайтын хэд хэдэн чухал хэсэг байдгийг бид олж мэдсэн гэж бодъё. Хэрэв бүтэлгүйтсэн хүсэлтийн тоо 1% -иас давсан бол энэ нь маш чухал үйл явдал юм. Хэрэв үндсэн цагийн үед 15 минутын дотор алдааны түвшин 0,1% -иас давсан бол энэ нь бас ноцтой осолд тооцогддог. Эдгээр шалгуурууд нь ихэнх тохиолдлуудыг хамардаг, бусад нь энэ нийтлэлийн хамрах хүрээнээс гадуур байна.

Шилдэг шилдэг тохиолдлууд Cyan

Тиймээс бид ямар нэгэн хэрэг явдал болсон гэдгийг тодорхой тогтоож сурсан. 

Одоо болсон үйл явдал бүрийг Жира туульд дэлгэрэнгүй тайлбарлаж, тусгадаг. Дашрамд хэлэхэд: үүний тулд бид FAIL гэж нэрлэгддэг тусдаа төслийг эхлүүлсэн - үүнд зөвхөн туульс бүтээх боломжтой. 

Хэрэв та сүүлийн хэдэн жилийн бүх бүтэлгүйтлүүдийг цуглуулвал удирдагчид нь: 

• mssql-тэй холбоотой тохиолдлууд;
• гадны хүчин зүйлээс үүдэлтэй осол;
• админ алдаа.

Администраторуудын алдаа, бусад сонирхолтой алдаануудыг илүү нарийвчлан авч үзье.

Тавдугаар байр - "DNS доторх зүйлийг эмх цэгцтэй болгох"

Мягмар гараг шуургатай байлаа. Бид DNS кластерт дэг журмыг сэргээхээр шийдсэн. 

Би дотоод DNS серверүүдийг bind-ээс powerdns руу шилжүүлэхийг хүссэн бөгөөд үүнд DNS-ээс өөр юу ч байхгүй тусдаа серверүүдийг хуваарилахыг хүссэн. 

Бид DC-ийн байршил бүрт нэг DNS сервер байрлуулсан бөгөөд бүсүүдийг bind-ээс powerdns руу шилжүүлж, дэд бүтцийг шинэ серверүүд рүү шилжүүлэх мөч ирлээ. 

Шилжилтийн үеэр бүх серверүүд дээрх локал кэшийн холболтод заасан бүх серверүүдээс зөвхөн нэг нь л үлдсэн бөгөөд энэ нь Санкт-Петербург дахь мэдээллийн төвд байсан. Энэ DC нь анх бидний хувьд чухал биш гэж зарласан боловч гэнэт нэг л бүтэлгүйтлийн цэг болсон.
Нүүлгэн шилжүүлэлтийн энэ үед Москва, Санкт-Петербургийн хоорондох суваг нурсан. Бид үнэндээ таван минутын турш DNS-гүй үлдэж, хост асуудлыг засахад буцаж боссон. 

Дүгнэлт:

Өмнө нь бид ажилд бэлтгэхдээ гадны хүчин зүйлсийг үл тоомсорлодог байсан бол одоо тэд бас бидний бэлтгэж буй зүйлийн жагсаалтад багтсан болно. Одоо бид бүх бүрэлдэхүүн хэсгүүдийг n-2 байлгахыг хичээж байгаа бөгөөд ажлын явцад бид энэ түвшинг n-1 хүртэл бууруулж чадна.

• Үйл ажиллагааны төлөвлөгөө гаргахдаа үйлчилгээ бүтэлгүйтэж болзошгүй цэгүүдийг тэмдэглэж, бүх зүйл "муугаас улам дордох" хувилбарыг урьдчилан бодож үзээрэй.
• Дотоод DNS серверүүдийг өөр өөр газарзүйн байршил/өгөгдлийн төв/өлгүүр/свич/оролтоор түгээх.
• Сервер бүр дээр хүсэлтийг үндсэн DNS серверүүд рүү чиглүүлдэг локал кэш DNS серверийг суулгаж, хэрэв боломжгүй бол кэшээс хариу өгөх болно. 

Дөрөвдүгээр байр - "Nginx-д зүйлийг эмх цэгцтэй болгох"

Нэгэн сайхан өдөр манай баг "бидэнд хангалттай байсан" гэж шийдсэнээр nginx тохиргоог дахин засварлах үйл явц эхэлсэн. Гол зорилго нь тохиргоог ойлгомжтой бүтэцтэй болгох явдал юм. Өмнө нь бүх зүйл "түүхэнд тогтсон" бөгөөд ямар ч логикгүй байсан. Одоо server_name бүрийг ижил нэртэй файл руу зөөж, бүх тохиргоог хавтас руу тараасан. Дашрамд хэлэхэд тохиргоо нь 253949 мөр буюу 7836520 тэмдэгт агуулсан бөгөөд бараг 7 мегабайт эзэлдэг. Бүтцийн дээд түвшин: 

Nginx бүтэц

├── access
│   ├── allow.list
...
│   └── whitelist.conf
├── geobase
│   ├── exclude.conf
...
│   └── geo_ip_to_region_id.conf
├── geodb
│   ├── GeoIP.dat
│   ├── GeoIP2-Country.mmdb
│   └── GeoLiteCity.dat
├── inc
│   ├── error.inc
...
│   └── proxy.inc
├── lists.d
│   ├── bot.conf
...
│   ├── dynamic
│   └── geo.conf
├── lua
│   ├── cookie.lua
│   ├── log
│   │   └── log.lua
│   ├── logics
│   │   ├── include.lua
│   │   ├── ...
│   │   └── utils.lua
│   └── prom
│       ├── stats.lua
│       └── stats_prometheus.lua
├── map.d
│   ├── access.conf
│   ├── .. 
│   └── zones.conf
├── nginx.conf
├── robots.txt
├── server.d
│   ├── cian.ru
│   │   ├── cian.ru.conf
│   │   ├── ...
│   │   └── my.cian.ru.conf
├── service.d
│   ├── ...
│   └── status.conf
└── upstream.d
    ├── cian-mcs.conf
    ├── ...
    └── wafserver.conf

Энэ нь хамаагүй сайжирсан боловч тохиргооны нэрийг өөрчлөх, түгээх явцад тэдгээрийн зарим нь буруу өргөтгөлтэй байсан тул include *.conf зааварт ороогүй болно. Үүний үр дүнд зарим хостууд боломжгүй болж, 301-ийг үндсэн хуудас руу буцаасан. Хариулах код нь 5xx/4xx биш байсан тул тэр даруй анзаараагүй, зөвхөн өглөө. Үүний дараа бид дэд бүтцийн бүрэлдэхүүн хэсгүүдийг шалгах тест бичиж эхэлсэн.

Дүгнэлт: 

• Тохиргоогоо зөв зохион байгуулж (зөвхөн nginx биш) төслийн эхний шатанд бүтцийг сайтар бодож үзээрэй. Ингэснээр та тэднийг багт илүү ойлгомжтой болгох бөгөөд энэ нь эргээд TTM-ийг багасгах болно.
• Дэд бүтцийн зарим бүрэлдэхүүн хэсгүүдийн тест бичих. Жишээ нь: бүх түлхүүр серверийн нэрс нь зөв статус + хариултын хэсгийг өгч байгаа эсэхийг шалгах. Өглөөний 3 цагт өөр юу шалгах хэрэгтэйг санахгүй байхын тулд бүрэлдэхүүн хэсгийн үндсэн функцийг шалгах цөөн хэдэн скрипт байхад л хангалттай. 

Гуравдугаар байр - "Кассандрагийн орон зай гэнэт дууслаа"

Өгөгдөл тогтвортой өсч, Кассандра кластерт нягтаршил нь ажиллах боломжгүй байсан тул том хайрцагны засвар бүтэлгүйтэх хүртэл бүх зүйл хэвийн байсан. 

Нэг шуургатай өдөр кластер бараг хулуу болж хувирав, тухайлбал:

• кластерт үлдсэн нийт зайны 20 орчим хувь нь үлдсэн;
• Зангилааг бүрэн нэмэх боломжгүй, учир нь хуваалтууд дээр зай байхгүйн улмаас зангилаа нэмсний дараа цэвэрлэгээ хийгддэггүй;
• нягтрал нь ажиллахгүй байгаа тул бүтээмж аажмаар буурч байна; 
• Кластер яаралтай тусламжийн горимд байна.

Гарах - бид цэвэрлэхгүйгээр дахин 5 зангилаа нэмсэн бөгөөд үүний дараа бид тэдгээрийг кластераас системтэйгээр устгаж, зайгүй болсон хоосон зангилаа шиг дахин оруулж эхэлсэн. Бидний хүссэнээс хамаагүй их цаг зарцуулсан. Кластерийг хэсэгчлэн эсвэл бүрэн ашиглах боломжгүй болох эрсдэлтэй байсан. 

Дүгнэлт:

• Бүх кассандра серверүүд дээр хуваалт бүрийн зайны 60% -иас илүүгүй байх ёстой. 
• Тэдгээрийг 50% -иас ихгүй CPU-ээр ачаалах ёстой.
• Та хүчин чадлын төлөвлөлтийн талаар мартаж болохгүй бөгөөд бүрэлдэхүүн хэсэг тус бүрийн онцлогт үндэслэн сайтар бодож үзэх хэрэгтэй.
• Кластерт илүү олон зангилаа байх тусмаа сайн. Бага хэмжээний өгөгдөл агуулсан серверүүд илүү хурдан ачаалагддаг бөгөөд ийм кластерийг сэргээхэд хялбар байдаг. 

Хоёрдугаар байр - "Консулын түлхүүр-утга хадгалах сангаас мэдээлэл алга болсон"

Үйлчилгээний нээлтийн хувьд бид олон хүмүүсийн адил консулыг ашигладаг. Гэхдээ бид түүний түлхүүр утгыг цулын цэнхэр ногоон зохион байгуулалтад ашигладаг. Энэ нь байршуулах явцад байраа өөрчилдөг идэвхтэй болон идэвхгүй дээд урсгалын талаарх мэдээллийг хадгалдаг. Энэ зорилгоор KV-тэй харьцдаг байршуулах үйлчилгээг бичсэн. Хэзээ нэгэн цагт KV-ийн өгөгдөл алга болсон. Санах ойноос сэргээсэн боловч хэд хэдэн алдаатай. Үүний үр дүнд, байршуулах явцад дээд талын ачаалал жигд бус хуваарилагдсан бөгөөд арын хэсгүүд нь CPU дээр хэт ачаалалтай байснаас бид олон 502 алдаа хүлээн авсан. Үүний үр дүнд бид консул КВ-ээс постгрес руу нүүсэн бөгөөд тэндээс тэдгээрийг арилгах нь тийм ч хялбар биш болсон.  

Дүгнэлт:

• Ямар ч зөвшөөрөлгүй үйлчилгээ нь сайтын үйл ажиллагаанд чухал ач холбогдолтой мэдээллийг агуулж болохгүй. Жишээлбэл, хэрэв танд ES-д зөвшөөрөл байхгүй бол шаардлагагүй газраас сүлжээний түвшинд хандахаас татгалзаж, зөвхөн шаардлагатайг нь үлдээж, мөн action.destructive_requires_name: true тохируулсан нь дээр.
• Нөөцлөх болон сэргээх механизмаа урьдчилан дадлагажуул. Жишээлбэл, нөөцлөх, сэргээх боломжтой скриптийг урьдчилан (жишээлбэл, python дээр) хий.

Тэргүүн байр - "Ахмад үл мэдэгдэх" 

Хэзээ нэгэн цагт бид арын хэсэгт 10+ сервер байсан тохиолдолд nginx-ийн дээд урсгал дээр ачааллын жигд бус хуваарилалтыг анзаарсан. Round-robin нь хүсэлтийг 1-ээс сүүлчийн дээд урсгал руу дарааллаар нь илгээж, nginx дахин ачаалах бүрийг дахин эхлүүлдэг тул эхний дээд урсгалууд бусадтай харьцуулахад илүү их хүсэлтийг хүлээн авдаг. Үүний үр дүнд тэд удааширч, сайт бүхэлдээ хохирсон. Замын хөдөлгөөний хэмжээ нэмэгдэхийн хэрээр энэ нь улам бүр мэдэгдэхүйц болсон. Санамсаргүй горимыг идэвхжүүлэхийн тулд зүгээр л nginx-г шинэчлэх нь бүтэлгүйтсэн - бид 1.15 хувилбар дээр ашиглагдаагүй олон тооны lua кодыг дахин хийх шаардлагатай байна (тэр үед). Бид nginx 1.14.2-г нөхөж, санамсаргүй дэмжлэгийг оруулах шаардлагатай болсон. Ингэснээр асуудлыг шийдсэн. Энэ алдаа нь "Ахмад үл ойлгогдох байдал" ангилалд түрүүлсэн.

Дүгнэлт:

Энэ алдааг судлах нь маш сонирхолтой бөгөөд сэтгэл хөдөлгөм байсан). 

• Ийм хэлбэлзлийг хурдан олоход туслах үүднээс хяналтаа зохион байгуул. Жишээлбэл, та ELK-ийг ашиглан дээд урсгал бүрийн арын хэсэг бүрийн rps-ийг хянах, тэдний хариу өгөх хугацааг nginx-ийн үүднээс хянах боломжтой. Энэ тохиолдолд энэ нь бидэнд асуудлыг тодорхойлоход тусалсан. 

Үүний үр дүнд таны хийж буй зүйлд илүү болгоомжтой хандах замаар ихэнх бүтэлгүйтлээс зайлсхийх боломжтой байсан. Бид Мерфигийн хуулийг үргэлж санаж байх ёстой. Буруу болж болох аливаа зүйл буруу болно, түүн дээр тулгуурлан бүрэлдэхүүн хэсгүүдийг бүтээх. 

Эх сурвалж: www.habr.com