Нийтлэлтийн дараа шууд унадаг аппуудыг илрүүлэх нь

9-р сарын 25-нд гурван нийтлэлт амжилттай гэж тэмдэглэгдсэн ч аппуудын API эхлэх бүрт секундын дотор унадаг байсан. Тэд "амжилттай" болсон тул буцаалт ажиллаагүй; хэдхэн минутын дараа фоны шалгалт тэдгээрийг бүтэлгүйтэж, бүх сайт 404 болсон. Эрүүл мэндийн шалгалт унасан тоог хостингийн платформын үйл явдлын жагсаалтаас тоолж байсан — тэр нь машин бүрт сүүлийн таван үйл явдлыг л хадгалдаг, тиймээс унах давталт жагсаалтыг дүүргэж, тоо хэзээ ч өсдөггүй. Одоо тэр оронд хамгийн сүүлийн унасан цагийг харьцуулдаг, мөн унах давталттай нийтлэлт бүтэлгүйтэж, өмнөх хувилбарыг сэргээдэг.

Нийтлэлт юу хүлээдэг вэ

Бэкэндтэй аппыг Mythex дээр нийтлэхэд шинэ хувилбар манай хостингийн платформын машинуудад суулгагдаж, эрүүл мэндийн шалгалт нийтлэлт идэвхтэй болсон эсвэл бүтэлгүйтсэнийг шийдэнэ. Бүтэлгүйтвэл буцаалт өмнөх хувилбарыг сэргээнэ.

Хамгийн хэцүү зүйл нь "эхэлсэн" гэдэг нь "үйлчилж байгаа" гэдэгтэй адил биш. Платформ машин дээр эхэлсэн гэж тайлагнадаг, харин секундын дотор унадаг апп тэр даруй дахин эхэлж, хэсэг хугацааны дараа дахин "эхэлсэн" гэж харагддаг. Тиймээс эрүүл мэндийн шалгалт цаг хугацааны явцад хэд хэдэн давхарга нэмэгдсэн:

1. Хоёр удаа харна. Машин эхэлсэн гэж харагдсаны дараа бага зэрэг хүлээгээд дахин харна. Эхлэх үеийн унасан нь ихэвчлэн хоёр дахь харалтад амжилтгүй болдог.
2. Унах давталтыг хянана. Хэрэв платформ машин олон удаа унасан гэж мэдээлж, дахин эхлүүлэхээ больсон бол бүтэлгүйтэнэ.
3. Нийтлэлт эхэлснээс хойш унасан тоог тоолно. Хоёр харалт дахин эхлэлтийг хооронд нь хамарч магадгүй. Тиймээс нийтлэлт эхэлснээс хойш ямар нэгэн унасан зүйл байвал гурав дахь удаа харна; гурав дахь харалтад өмнөх харалтаас илүү унасан байвал апп тогтвортой ажиллахгүй гэсэн үг.

Гурав дахь шалгалт энд бүтэлгүйтсэн нь.

Яагаад тоо өсөхгүй байсан бэ

Унасан мэдээлэл машин бүрийн үйл явдлын жагсаалтаас ирдэг: эхлэлт, зогсолт, дахин эхлэлт. Платформ машин бүрт сүүлийн таван үйл явдлыг л хадгалдаг.

Эхлэх бүрт 2.5 секундын дараа унадаг аппыг төсөөлөөд үз, нэг нь яг ийм байсан. Мөчлөг бүр нэг унасан, нэг эхэлсэн үйл явдал нэмнэ. Хэдхэн мөчлөгийн дараа жагсаалт дүүрнэ. Тэр цагаас хойш шинэ үйл явдал бүр хуучныг гадагш нь түлхэнэ. Жагсаалт урагшаа гулсах ч ихэвчлэн ижил холимог агуулдаг: хэдхэн унасан, хэдхэн эхэлсэн.

Тиймээс "нийтлэлт эхэлснээс хойш хэд унасан бэ" гэдэг нь харалт бүрт ижил тоо буцаадаг. Хоёр дахь харалт жишээлбэл хоёр унасан гэж харсан. Гурав дахь харалт бас хоёрыг харсан — өөр унасан боловч ижил тоо. Шалгалт унасан нь зогссон гэж дүгнэж нийтлэлтийг өнгөрүүлсэн.

Энэ 9-р сарын 25-нд гурван удаа, хоёр аппад тохиолдсон. Удаа бүр:

• нийтлэлт идэвхтэй гэж тэмдэглэгдсэн,
• буцаалт ажиллаагүй, учир нь юу ч бүтэлгүйтээгүй,
• бидний reconciler, нийтлэлтийн дараа deployment-уудыг шалгадаг фоны ажил, хэдхэн минутын дараа deployment-ийг бүтэлгүйтүүлсэн,
• бүх сайт 404 буцаасан.

Цаг дээр нь бүтэлгүйтсэн нийтлэлт сэргээгдэх боломжтой: буцаалт өмнөх хувилбарыг сэргээнэ. Амжилттай гэж зарласны дараа хэдхэн минутын дараа бүтэлгүйтсэн нийтлэлт аль хэдийн буцаалтаа алгасчихсан байдаг.

Бид яаж олсон бэ

Бид орон нутагт дахин гаргасан: ажилладаг API авч, унтуулаад, дараа нь эхлэх үед унадаг өөрчлөлттэй дахин нийтэлсэн. Эрүүл мэндийн шалгалт үүнийг идэвхтэй гэж тэмдэглэсэн.

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

Засвар: шинэ унасныг харьцуул, тоог биш

Тоолохын оронд шалгалт одоо нийтлэлт эхэлснээс хойших хамгийн сүүлийн унасан цаг-ийг харна.

Хоёр дахь харалтад нийтлэлт эхэлснээс хойш ямар нэг унасан байвал шалгалт гурав дахь удаа харна. Гурав дахь харалтын хамгийн сүүлийн унасан цаг хоёр дахьынхаас хожуу байвал машин хооронд нь дахин унасан гэсэн үг. Тэр тогтвортой биш, нийтлэлт бүтэлгүйтэж, машин нийтлэлтээс хойш олон удаа унасан бөгөөд дахин эхлэж байна гэсэн мессежтэй.

Энэ нь үйл явдлын жагсаалт ямар богино байснаас үл хамаарна. Таван үйл явдлын цонх олон унасныг нууж чадах ч шинэ унасан зүйл болсныг нууж чадахгүй — хамгийн сүүлийн үйл явдал үргэлж хадгалагддаг.

Энэ өөрчлөлттэй орон нутгийн давталт зөв ажилладаг: нийтлэлт бүтэлгүйтэж, өмнөх image сэргээгддэг. Платформын зан төлөвийг дуурайдаг тест бас бий — харалт бүр унасан нэг, эхлэлт нэг нэмж, жагсаалтыг таван хүртэл тайрдаг — мөн шийдвэр нь тэнцсэн биш, бүтэлгүйтэл гэдгийг шалгадаг.

Бидний сурсан зүйл

• Тоолж буй өгөгдлийнхөө хэлбэрийг мэдэж бай. Дээд хэмжээтэй жагсаалтын тоолол жагсаалт дүүрмэгц утгаа алдана. Хязгаар нууцлагдаагүй байсан; бид шалгалтаа үүнтэй зохицуулж төлөвлөөгүй байсан.
• "Шинэ зүйл болсон уу?" гэдгийг "хэд болсон бэ?" гэдгээс илүү сонго. Хамгийн сүүлийн цагийн тэмдэг таслагдсаны дараа ч үлддэг. Нийт тоо үлддэггүй.
• Хожуу бүтэлгүйтэл нь эрт бүтэлгүйтлээс муу. Ижил эвдэрсэн бүтээц нийтлэлт бүтэлгүйтэж буцаах үед хор хөнөөлгүй, харин эхлээд амжилттай гэж зарлагдвал сайтыг унагадаг.
• Жинхэнэ нөхцөлөөр туршаарай. Алдаа гарахын тулд машин үйл явдлын жагсаалтаа дүүргэх хангалттай удаа унасан байх шаардлагатай байсан. Тестэд нэг хурдан унах нь үүнийг харуулахгүй байсан.

Энэ засвар өдрийн нэг өөр засвартай хосолдог: буцаалт устгахгүй, хуучин хувилбарыг буцааж тавьдаг болгосон — амжилтгүй дахин нийтлэлт ажиллаж буй backend-ийг хэзээ ч устгахгүй. Хэрэв таны апп эхлэхдээ унадаг учраас нийтлэгдэхгүй байвал, нийтлэлтийн алдааг шийдэх docs болон AI-ээр бүтээсэн аппыг дибаг хийх гарын авлага эхлэхэд сайн газар.