วิศวกรรม

วิศวกรรม

เราสร้างและดูแล Mythex อย่างไร รวมถึงอะไรที่พังและเราแก้ไขอย่างไร

• การ Republish ที่ล้มเหลวจะไม่ลบ Backend ที่ยังทำงานอยู่ — การ republish ที่ล้มเหลวอาจลบ API ที่ใช้งานอยู่ของแอป หรือปล่อยเวอร์ชันใหม่ที่พังทิ้งไว้ สามการแก้ไขวิธียกเลิก publish ที่ผิดพลาดใน Mythex
• การแจ้งเตือนที่ส่งครั้งเดียว ไม่ใช่ครั้งเดียวต่อเซิร์ฟเวอร์ — การแจ้งเตือนรายวันมาถึงเรายี่สิบเอ็ดครั้งในบ่ายเดียว เหตุผลที่การกันซ้ำในหน่วยความจำพังเมื่อมีสองเซิร์ฟเวอร์และการ deploy และการแก้ด้วยสถานะที่ใช้ร่วมกัน
• การย้ายไปยัง workspace ที่ใหญ่ขึ้นโดยไม่ทำให้ใครต้องรอ — หนึ่งในสี่ของ workspace ยังติดอยู่ที่ 1 GB หลังเราย้ายไปใช้ 2 GB การแก้ครั้งแรกทำให้คนหนึ่งต้องรอเจ็ดนาที สิ่งที่เราเปลี่ยนและเปลี่ยนอีกครั้ง
• คิดค่าฐานข้อมูลตามสิ่งที่ใช้จริง — เคยประมาณค่าฐานข้อมูลของแต่ละแอป และการประมาณนั้นผิดได้ทั้งสองทาง ตอนนี้ทุกฐานข้อมูลถูกคิดเงินจากการใช้งานที่วัดได้ ชั่วโมงต่อชั่วโมง
• การจับแอปที่ขัดข้องทันทีหลัง publish — การ publish สามครั้งผ่าน health check ของเรา ขณะที่ API ของพวกมันขัดข้องไม่กี่วินาทีหลังบูตทุกครั้ง สาเหตุคือการนับการขัดข้องในรายการที่จำกัดไว้ห้ารายการ
• ทำให้รอบการทำงานของเอเจนต์ที่มีรูปจำนวนมากอยู่ในหน่วยความจำ — รอบการทำงานของเอเจนต์ที่ดูสแกนแคตตาล็อกซ้ำ ๆ หน่วยความจำหมดที่ 952 MB มีสาเหตุแยกกันสามอย่างที่เก็บรูปไว้นานเกินไป และนี่คือวิธีที่เราแก้
• ทำให้รอบงานยาวของเอเจนต์อยู่ในหน้าต่างบริบท — เอเจนต์ย่อยของเราเติบโตจนโมเดลปฏิเสธ หยุดก่อนเวลาเพื่อประหยัดพื้นที่ หรือนับโทเค็นภาษารัสเซียผิด สามการแก้ไขที่ทำให้งาน AI ที่ยาวเสร็จได้
• ทำให้แชทยังทำงานเมื่อโทรศัพท์หลับ — โทรศัพท์หลับ สลับแท็บ และเครือข่ายหลุดระหว่างการสร้าง บั๊กสองตัวทำให้แชทของ Mythex ค้างหรือแสดงคำตอบเพียงครึ่งเดียวหลังจากนั้น และนี่คือวิธีที่เราหาและแก้ทั้งสองตัว
• แชทเดียวที่หนักอาจทำให้ API ของเราล่มได้อย่างไร — วันที่ 28 กันยายน เซิร์ฟเวอร์ API ทั้งสองตัวหน่วยความจำหมดพร้อมกัน การแก้ไขแรกคือเพิ่มหน่วยความจำ ส่วนการแก้จริงคือโหลดประวัติแชทตามขนาด ไม่ใช่จำนวน
• กดเผยแพร่สองครั้งตอนนี้เผยแพร่เพียงครั้งเดียว — คำขอเผยแพร่สามรายการของแอปเดียวมาถึงห่างกัน 84 มิลลิวินาที และรันการดีพลอยซ้ำกัน นี่คือวิธีที่ฐานข้อมูลตัดสินว่าใครเผยแพร่ และบอกรายการอื่นตามความจริง
• บทเรียน SEO จากการแก้ไขเว็บไซต์ของเราเอง — FAQ markup ที่ซ้ำกัน รูปภาพผิดที่ Google ใช้เป็น thumbnail หน้า template ที่ไม่มีใครคลิก และเส้นทางที่ edge ของเราปฏิเสธ นี่คือสิ่งที่เราพบบน mythex.ai และแก้ไขแล้ว
• เว็บไซต์ Static ยังออนไลน์อยู่ระหว่างการเผยแพร่ซ้ำ — การเผยแพร่เว็บ static ซ้ำเคยลบไฟล์ที่ใช้งานอยู่ก่อนอัปโหลด build ใหม่ ตอนนี้เว็บเก่ายังให้บริการจนกว่าเว็บใหม่จะขึ้นระบบ และการเปลี่ยนแปลงแสดงภายในไม่กี่วินาที
• ข้อผิดพลาดหน่วยความจำหมดที่ซ่อนอยู่ในป้ายสถานะความคืบหน้า — Agent AI ของเราหน่วยความจำหมดระหว่างเขียนไฟล์ขนาดใหญ่หนึ่งไฟล์ สาเหตุไม่ใช่โมเดลหรือ sub-agent ที่ทำงานพร้อมกัน แต่เป็นป้ายสถานะที่ถูกส่งซ้ำ 41,000 ครั้ง
• ไฟล์ swap ที่หายไปซึ่งทำให้เซิร์ฟเวอร์ของเราค้าง — เซิร์ฟเวอร์ production หยุดตอบสนองโดยไม่ล่ม ไม่มีการฆ่าเพราะหน่วยความจำหมด เพียงแค่ page cache ทำงานหนักบนเครื่องที่ไม่มี swap เกิดอะไรขึ้นและเราเปลี่ยนอะไรบ้าง
• ปลุกฐานข้อมูลโดยไม่ให้การเชื่อมต่อที่ตายแล้วค้างอยู่ — แอปที่เผยแพร่แล้วที่ตื่นจากโหมดหลับ ต้องรอคำขอแรกนาน 10–12 วินาที เพราะการเชื่อมต่อฐานข้อมูลที่ตายไประหว่างหลับ เราลดเหลือ 2.3 วินาทีได้อย่างไร
• เรากำลังจำกัดอัตราการเรียกของบริการของเราเอง — ขีดจำกัดอัตราต่อที่อยู่ของ API ของเราปฏิบัติกับบริการของเราเองเหมือนผู้ใช้คนเดียวที่ยุ่ง และในโปรดักชันบริการเหล่านั้นเริ่มได้รับ 429 วิธีที่เราพบและแก้ไข
• ทำไมเราย้ายเซิร์ฟเวอร์ของ Mythex ไปใช้ ARM — เมื่องานหนักถูกย้ายไปอยู่ใน sandbox ของแต่ละโปรเจกต์ เซิร์ฟเวอร์ของเราใช้หน่วยความจำเพียงหนึ่งในสาม อินสแตนซ์ ARM ที่เล็กลงช่วยลดต้นทุนราว 30% นี่คือวิธีการ
• เราทำให้ deploy เหลือข้อผิดพลาด 502 เป็นศูนย์ได้อย่างไร — watchdog ที่แข่งกับการ deploy และ load balancer ที่รู้ตัวช้าเกินไป วิธีที่เราพบทั้งสองอย่าง แก้ไข และวัดผลจาก 10 ข้อผิดพลาด 502 เหลือศูนย์