Инженерчлэл

Инженерчлэл

Mythex хэрхэн бүтээгдэж, ажилладаг вэ — юу эвдэрч, хэрхэн зассаныг оролцуулаад.

• Амжилтгүй дахин нийтлэлт ажиллаж буй backend-ийг хэзээ ч устгахгүй — Амжилтгүй дахин нийтлэлт аппынхаа ажиллаж буй API-г устгаж болзошгүй байсан. Mythex буцаалтыг хэрхэн зассан тухай гурван засвар.
• Сервер бүрт биш, нэг удаа ажилладаг сануулга — Өдөрт нэг удаа явах ёстой сануулга нэг үдээс хойш таван удаа ирсэн. Хоёр сервер болон deploy-тэй үед ой санамжийн dedupe яагаад эвддэг, хуваалцсан төлөв яаж зассан.
• Хүмүүсийг хүлээлгүйгээр илүү том workspace руу шилжих нь — Манай workspace-ийн дөрөвний нэг нь 2 GB руу шилжсний дараа ч 1 GB дээр үлдсэн. Эхний засвар нэг хүнийг долоон минут хүлээлгэсэн. Юуг өөрчилсөн, дахин юуг өөрчилсөн.
• Өгөгдлийн сангуудыг жинхэнэ хэрэглээгээр нь төлбөрт оруулах нь — Бид аппын өгөгдлийн сангийн зардлыг тооцдог байсан бөгөөд тооцоо хоёр талд буруу байсан. Одоо өгөгдлийн сан бүр цаг цагаараа хэмжигдсэн хэрэглээгээр төлбөр бодогддог.
• Нийтлэлтийн дараа шууд унадаг аппуудыг илрүүлэх нь — Гурван нийтлэлт эрүүл мэндийн шалгалтаа давсан ч тэдгээрийн API эхлэх бүрт секундын дотор унасан. Шалтгаан: сүүлийн таван оруулгад хязгаарлагдсан жагсаалтад унасан тоолох.
• Зургаар дүүрсэн агентын эргэлтийг санах ойд багтаах нь — Каталогийн скануудыг үргэлж харж байсан агентын эргэлт 952 МБ дээр санах ой дуусав. Зургууд хэт удаан барьж байсан гурван өөр шалтгаан, мөн тэдгээрийг яаж засав.
• Урт агентын эргэлтийг context window-д багтаах нь — Дэд агентууд загвар татгалзах хүртэл ургаж, өрөө хэмнэхийн тулд эрт зогсож, Орос хэл дээр токеныг буруу тоолж байв. Урт AI ажлыг дуусгах гурван засвар.
• Утас унтах үед чатыг амьд байлгах нь — Утас унтдаг, таб солидог, сүлжээ тасрагддаг барилгын дунд. Хоёр алдаа чатыг зогсоож, дараа нь хагас хариулт харуулдаг байсан. Хэрхэн олж, засав.
• Нэг хүнд чат манай API-г унагаж болох нь — 9-р сарын 28-нд бидний API хоёр сервер нэгэн зэрэг санах ой дууссан. Эхний засвар нь илүү санах ой байв; жинхэнэ нь чат түүхийг тоо биш хэмжээгээр ачаалах явдал байв.
• Publish-ийг хоёр удаа дарахад одоо нэг л удаа нийтэлнэ — Нэг аппын гурван publish хүсэлт 84 мс-ийн зайтай ирж, тус бүр бүтэн deploy хийсэн. Аль нь нийтлэхийг өгөгдлийн сан шийдэж, бусдад үнэнийг хэлдэг болсон.
• Өөрсдийн сайтыг засахаас авсан SEO сургамжууд — Давхар FAQ маркап, Google-д буруу зураг, хэн ч дарааагүй загварын хуудсууд, edge-ийн татгалзсан зам: mythex.ai дээр олсон зүйл, засварласан арга.
• Статик сайтууд дахин нийтлэгдэх явцад ажилласаар байдаг — Статик сайтыг дахин нийтлэхэд хуучныг нь эхлээд устгадаг байсан. Одоо шинэ build орох хүртэл хуучин сайт ажиллаж, өөрчлөлт секундэд харагдана.
• Ахицын шошгон дахь санах ойн алдагдал, out-of-memory ослын шалтгаан — AI агент нэг том файл бичихэд санах ой дүүрч унасан. Шалтгаан нь загвар эсвэл дэд агентууд биш — төлөвийн шошгыг 41,000 удаа дахин илгээсэн байв.
• Серверүүдийг царцаасан дутуу swap файл — Үйлдвэрлэлийн сервер хариулахаа больсон боловч унаагүй — swap-гүй машин дээр page cache-ийн thrashing. Юу болсон, бид юуг өөрчилсөн.
• Үхсэн холболтгүйгээр өгөгдлийн сангуудыг сэрээх нь — Нийтлэгдсэн апп сэрэхдээ эхний хүсэлтийг 10–12 секунд барьдаг байв, үхсэн өгөгдлийн сангийн холболтууд дээр. Бид үүнийг 2.3 секунд болгосон.
• Бид өөрсдийн үйлчилгээгээ хязгаарлаж байсан — API-ийн хаягаар хязгаарлалт бидний үйлчилгээг нэг завгүй хүн мэт үзэж, үйлдвэрлэлд 429 авч эхэлсэн. Яаж олж, засав.
• Яагаад Mythex-ийн серверүүдийг ARM руу шилжүүлсэн бэ — Хүнд ажлыг sandbox руу шилжүүлсний дараа серверүүд санах ойн гуравны нэгийг ашигласан. Жижиг ARM instance-ууд сарын зардлыг 30 орчим хувиар бууруулсан.
• Deploy-ийн 502 алдааг нуля болгосон нь яаж вэ — Deploy-тэй зууралдсан watchdog ба сервер сонсохоо больсны дараа л трафикаа зогсоосон load balancer. Хоёуланг нь засаад deploy бүрт 10 502-оос 0 болгосон.