ฉันสร้างผลิตภัณฑ์ด้วย AI—จะปรับปรุงอย่างไรโดยไม่ทำลายสิ่งที่ใช้งานได้ดีอยู่แล้ว

อ่านเพิ่มเติมเกี่ยวกับการทำงานกับโมเดลได้ในเอกสารประกอบ Ailoot

ทำไมงานที่มีค่าใช้จ่ายสูงที่สุดจึงเริ่มหลังเปิดตัว?#

คุณสร้างแอปในคืนเดียว เผยแพร่ลิงก์ และส่งให้เพื่อน ๆ มันใช้งานได้ แล้วหนึ่งสัปดาห์ต่อมา ผู้ใช้จริงคนแรกก็เข้ามา คลิกอะไรบางอย่างผิดวิธี แล้วฟีเจอร์ครึ่งหนึ่งก็หยุดทำงาน คุณขอให้ Claude แก้ให้—มันแก้เรื่องหนึ่ง แต่ทำอีกเรื่องพัง ฟังดูคุ้นไหม?

และนี่คือจุดที่คำถามหลักเกิดขึ้น: หลังเปิดตัวผลิตภัณฑ์แล้วต้องทำอย่างไร เมื่อความตื่นเต้นจากต้นแบบแรกที่ใช้งานได้ผ่านไป และคุณยังต้องหาทางดูแลมันต่อไป คุณอาจเรียกสิ่งนี้ว่า vibe coding สำหรับผู้ใหญ่ การสร้างคือความตื่นเต้นและความรวดเร็ว ส่วนการบำรุงรักษาต้องใช้สติและความใจเย็น: คุณเข้าใจสิ่งที่กำลังเปลี่ยน และควบคุมมันได้ คนส่วนใหญ่พลาดในขั้นตอนที่สอง เพราะไม่มีใครเตรียมพวกเขาให้พร้อม

การศึกษาในอุตสาหกรรมชิ้นหนึ่งวิเคราะห์การเปลี่ยนแปลงโค้ดมากกว่าหนึ่งล้านรายการจาก 2,444 ทีม และคำนวณว่าเงินที่ใช้ในการพัฒนาด้วย AI ไปอยู่ที่ไหนบ้าง ภาพรวมเป็นดังนี้:

คู่มือ “ต้นทุนแฝงของ vibe coding” อธิบายตัวเลขเหล่านี้อย่างละเอียดกว่าเดิม ที่นั่นคำถามคือคุณกำลังจ่ายเงินไปกับอะไร ส่วนที่นี่คำถามต่างออกไป: เงินทุกดอลลาร์ 44 เซนต์ถูกใช้ไปกับการแก้บั๊ก—และบทความนี้ทั้งบทว่าด้วยการป้องกันไม่ให้สัดส่วนนี้เพิ่มขึ้น งานที่ทำให้ควบคุมเรื่องนี้ได้เรียกว่าการบำรุงรักษา

ความแตกต่างระหว่างคนที่ทำ vibe coding แบบผู้ใหญ่กับคนที่คอยเฝ้า neural net ปรากฏให้เห็นหลังเปิดตัว คนกลุ่มแรกทำให้ codebase เติบโต ปรับปรุงสิ่งต่าง ๆ และไม่มีอะไรพัง หนึ่งเดือนต่อมา ผลิตภัณฑ์ของคนกลุ่มที่สองกลับกลายเป็นของพัง ๆ ที่รั่วไปหมดและเจ้าตัวไม่กล้าแตะ ต่อไปฉันจะอธิบายว่าจะทำอย่างไรให้ไปอยู่กลุ่มแรก

อะไรพังจริง ๆ: 5 ภัยพิบัติหลังเปิดตัว#

นี่คือรายงานหลังเกิดเหตุที่เปิดเผยต่อสาธารณะเกี่ยวกับผลิตภัณฑ์จริงที่สร้างด้วย AI มีทั้งตัวเลขและวันที่ คิดเสียว่าเป็นแผนที่สนามทุ่นระเบิด—ทุ่นแต่ละลูกเคยระเบิดใส่ใครบางคนมาแล้ว และรู้วิธีหลบเลี่ยงมัน

ทั้งห้าเหตุการณ์มีสาเหตุรากเดียวกัน โดยค่าเริ่มต้น AI จะทำให้สิ่งต่าง ๆ ใช้งานได้ในตอนนี้ ไม่ใช่ทำให้ปลอดภัยในอีกหนึ่งเดือนข้างหน้าภายใต้โหลดที่สูง คุณมองไม่เห็นความแตกต่างตอนพัฒนาบนคอมพิวเตอร์ของตัวเอง แต่จะเห็นชัดเมื่อคนแปลกหน้าที่มีเจตนาร้ายปรากฏตัวขึ้น

ปัญหาไม่ใช่การไม่ได้เขียนโค้ดด้วยตัวเอง—มีคนทำงานแบบนี้มากมาย ปัญหาคือการไม่ได้ถามว่า “ฐานข้อมูลปลอดภัยหรือยัง?” ต่อไปฉันจะแสดงพรอมป์ต์ที่ช่วยถามคำถามนี้ให้คุณ

ตาข่ายนิรภัยชั้นแรกคือ git และการย้อนกลับไป “เหมือนเมื่อวาน”#

เมื่อ Claude ทำอะไรพัง คุณต้องมีปุ่ม “คืนสภาพให้เหมือนเมื่อวาน” ในทางเทคนิค ปุ่มนั้นเรียกว่า git และใช้ง่ายกว่าที่คิด

คำศัพท์สามคำที่คนไม่ใช่โปรแกรมเมอร์ควรเข้าใจ:

1. Repository — โฟลเดอร์โปรเจกต์ที่บันทึกไว้บนคลาวด์ (โดยปกติอยู่บน GitHub) เป็นสำเนาโค้ดทั้งหมดของคุณที่ไม่ได้อยู่แค่ในคอมพิวเตอร์เครื่องเดียว
2. Commit — จุดย้อนกลับ คุณกำลังบอกโค้ดว่า “บันทึกไว้ในสถานะนี้” แต่ละ commit เป็นหมุดหมายที่คุณย้อนกลับไปได้
3. Deploy — การย้าย โค้ดเคยอยู่ในเครื่องคอมพิวเตอร์และทำงานได้แค่กับคุณ การ deploy จะส่งโค้ดไปยังเซิร์ฟเวอร์ภายนอกเพื่อให้ทุกคนใช้งานได้

ตราบใดที่คุณมีจุด commit ล่าสุด คุณก็ย้อนกลับจากความเสียหายใด ๆ ได้ด้วยประโยคเดียว จริง ๆ นะ

มีบางอย่างพัง—เมื่อวานทุกอย่างยังทำงานได้ แต่วันนี้กลับใช้ไม่ได้แล้ว ค้นหา commit ล่าสุดที่ทุกอย่างยังปกติดี แสดงให้ฉันเห็นว่ามีอะไรเปลี่ยนไปบ้างตั้งแต่นั้น และย้อนโปรเจกต์กลับไปยังสถานะนั้น

ควรตั้งกฎสองข้อนี้ทันที ก่อนที่คนอื่นจะเห็นผลิตภัณฑ์:

• repository ต้องเป็น private ไม่ใช่ public มิฉะนั้นใคร ๆ ก็อ่านโค้ดของคุณและทุกอย่างที่อยู่ในนั้นได้
• ใส่ไฟล์ secrets ไว้ในรายการ ignore key รหัสผ่าน และข้อมูลรับรองสำหรับเข้าถึงฐานข้อมูลจะอยู่ในไฟล์แยกต่างหาก (ปกติคือ .env) และไฟล์นั้นจะไม่เข้าไปอยู่ใน repository เพิ่มบรรทัดสำหรับ .env ใน .gitignore แล้ว secrets จะยังอยู่กับคุณ

มีคู่มือแยกเกี่ยวกับการย้อนกลับการเปลี่ยนแปลงอย่างปลอดภัยใน Claude Code: วิธีย้อนกลับการเปลี่ยนแปลงใน Claude Code หากไม่มีจุดย้อนกลับ คุณก็เหมือนเดินบนเชือกโดยไม่มีตาข่ายนิรภัย และไม่ช้าก็เร็วคุณจะตกลงมา

/rewind ย้อนกลับอะไรได้ และย้อนกลับอะไรไม่ได้?#

Claude Code ถ่าย snapshot ของสถานะก่อนเปลี่ยนแปลงทุกครั้ง คำสั่ง /rewind (หรือกด Esc สองครั้ง) จะย้อนทั้งไฟล์และบทสนทนากลับไปยังจุดที่เลือก สะดวกมาก: หากคุณทำฟีเจอร์พังเมื่อห้านาทีก่อน ก็ย้อนกลับไปห้านาทีที่แล้วได้

แต่มีหลุมพรางที่ทำให้มือใหม่สูญเสียข้อมูล /rewind ย้อนกลับทุกอย่างไม่ได้:

Anthropic อธิบายไว้อย่างตรงไปตรงมา: snapshot คือปุ่ม “undo” ในเครื่อง ส่วน git คือประวัติถาวร Snapshot ช่วยเสริมการควบคุมเวอร์ชัน แต่ใช้แทนกันไม่ได้

ข้อสรุปในทางปฏิบัติสำหรับคนที่ไม่ใช่โปรแกรมเมอร์คือ /rewind ช่วยคุณจากสถานการณ์ “Claude เพิ่งทำฟีเจอร์พัง” ได้ แต่ถ้ามันลบแถวในฐานข้อมูลหรืออัปโหลดโค้ดขึ้นคลาวด์ไปแล้ว มีเพียง git และข้อมูลสำรองฐานข้อมูลเท่านั้นที่กู้คืนได้ ดังนั้นควรมีทั้งสองชั้น: snapshot สำหรับย้อนกลับอย่างรวดเร็ว และ commit สำหรับเก็บประวัติถาวรของโปรเจกต์

จะปรับปรุงโดยไม่ทำลายสิ่งที่ใช้งานได้ดีอยู่แล้วได้อย่างไร?#

ทุก ๆ สองคนจะมีคนหนึ่งติดอยู่ในวงจรนี้ คุณขอให้ AI แก้บั๊กเล็ก ๆ มันเสนอการเปลี่ยนแปลงที่ฟังดูสมเหตุสมผล การเปลี่ยนแปลงนั้นทำให้อีกอย่างพัง คุณขอให้มันแก้ปัญหาใหม่ แล้วปัญหาอีกสองอย่างก็ปรากฏขึ้น วนไปเรื่อย ๆ

วงจรนี้เกิดขึ้นเพราะ vibe coding ไม่ได้ให้ผลลัพธ์แบบกำหนดแน่นอน พรอมป์ต์เดียวกันอาจให้โค้ดต่างกันในแต่ละครั้ง ดังนั้นการแก้ไขแต่ละครั้งจึงอาจเปลี่ยนตรรกะรอบข้างอย่างเงียบ ๆ: เกณฑ์ส่วนลดขยับจาก 10 เป็น 12 เปอร์เซ็นต์ หรือกฎตรวจสอบเปลี่ยนพฤติกรรม—โดยที่คุณไม่ได้ตรวจสอบและไม่มีคำเตือนแม้แต่ข้อเดียว สิ่งนี้เรียกว่าการเบี่ยงเบนของตรรกะ และมันค่อย ๆ ทำลายสิ่งที่สร้างรายได้โดยตรง ได้แก่ ราคา การเข้าถึง และการชำระเงิน

มีกฎข้อเดียวที่ช่วยป้องกันการเบี่ยงเบน ซึ่งง่ายพอที่จะนำไปติดไว้บนผนัง: อย่า commit โค้ดที่คุณอธิบายให้คนอื่นฟังแบบคำต่อคำไม่ได้

ในทางปฏิบัติ กฎนี้กลายเป็นกรอบคำสั่งสำเร็จรูปที่ใช้ได้ก่อนเปลี่ยนโค้ดที่ทำงานอยู่ทุกครั้ง มันบังคับให้ AI ทำทีละขั้นเล็ก ๆ และแสดงให้คุณเห็นอย่างชัดเจนว่ามีอะไรเปลี่ยนไป

ก่อนเปลี่ยนโค้ด ให้ทำสิ่งต่อไปนี้:

บันทึกสถานะปัจจุบันที่ยังทำงานได้ไว้เป็นจุดย้อนกลับแยกต่างหาก (commit)

อธิบายเป็นคำพูดให้ชัดเจนว่าคุณวางแผนจะแก้ไขอะไรและในไฟล์ใดบ้าง

เปลี่ยนแปลงให้น้อยที่สุดเท่าที่ทำได้—ทำเฉพาะสิ่งที่แก้โจทย์ของฉันได้เท่านั้น อย่าทำอย่างอื่นเพิ่ม

แสดงให้ฉันเห็นว่ามีอะไรเปลี่ยนไปบ้าง และอธิบายการเปลี่ยนแปลงแต่ละอย่าง เพื่อให้ฉันอธิบายต่อให้คนอื่นฟังได้
อย่าแตะต้องตรรกะเรื่องราคา การเข้าถึง หรือการชำระเงิน เว้นแต่ฉันจะขอให้ทำ

อีกหลักการหนึ่งที่ช่วยประหยัดเวลาได้หลายสัปดาห์คือการมีวินัยเรื่องขอบเขตงาน แก้ปัญหาหนึ่งจุด ทำการเปลี่ยนแปลงหนึ่งอย่าง และลงมืออย่างรวดเร็ว อย่าขอให้ AI เขียนโค้ดครึ่งโปรเจกต์ใหม่ในพรอมป์ต์เดียว นักพัฒนามืออาชีพบางครั้งเริ่มสร้าง Uber ทั้งระบบ ทั้งที่ต้องการแค่ปุ่มเดียว—แล้วลากงานนั้นออกไปหลายเดือน คุณไม่จำเป็นต้องทำแบบนั้น

ทุกอย่างที่ฉันอธิบายตั้งอยู่บนสิ่งเดียว: การจัดการบริบท เพื่อไม่ให้ AI ทำลายตรรกะที่อยู่ข้างเคียง มันต้องจำกฎของโปรเจกต์ได้

จะตรวจสอบการเปลี่ยนแปลงก่อนเผยแพร่ได้อย่างไร?#

ระหว่าง “ใช้ได้บนคอมพิวเตอร์ของฉัน” กับ “ใช้ได้สำหรับทุกคน” มีขั้นตอนกลางที่มือใหม่มักข้ามไป นั่นคือสำเนาทดสอบ ซึ่งเป็น snapshot แยกต่างหากของสภาพแวดล้อม production ที่ใช้ตรวจสอบการเปลี่ยนแปลงก่อนที่คนจริงจะเห็น วงจรการทำงานเป็นดังนี้:

1. สร้างและตรวจสอบการเปลี่ยนแปลงด้วยตัวเอง (development)
2. deploy ไปยัง staging—สำเนาของ production ที่ไม่มีผู้ใช้จริง
3. ทดลองสถานการณ์สำคัญและตรวจสอบว่าไม่มีอะไรเปลี่ยนแปลง
4. จากนั้นจึง deploy ไปยัง production

เหตุใดเรื่องนี้จึงสำคัญหลังเปิดตัว: การเผยแพร่แต่ละครั้งมีความเสี่ยง การเปลี่ยนโค้ดเล็กน้อยอาจทำให้การเข้าสู่ระบบพัง การตั้งค่าที่ขาดไปเพียงรายการเดียวอาจทำให้ผลิตภัณฑ์ทั้งหมดหยุดทำงาน Staging ช่วยจับปัญหาเหล่านี้ได้โดยไม่มีผลกระทบ แต่ถ้าเกิดใน production คุณจะเสียลูกค้า

เพื่อไม่ต้องตรวจสอบทุกอย่างด้วยตัวเองทุกครั้ง ให้พรอมป์ต์ AI เปรียบเทียบการทำงานของเวอร์ชันใหม่กับเวอร์ชันเก่าในจุดสำคัญ

ฉันกำลังจะ deploy การเปลี่ยนแปลง ให้ตรวจสอบสถานการณ์หลักของผลิตภัณฑ์ตามลำดับ และดูว่าแต่ละอย่างยังทำงานเหมือนเดิมหรือไม่:

การลงทะเบียนและเข้าสู่ระบบของผู้ใช้ใหม่

การชำระเงินและการให้สิทธิ์เข้าถึงหลังชำระเงิน

สิทธิ์การเข้าถึง—ผู้ใช้ทั่วไปต้องดูข้อมูลของคนอื่นหรือส่วนผู้ดูแลระบบไม่ได้

ตัวเลขสำคัญในตรรกะทางธุรกิจ (ราคา ส่วนลด ขีดจำกัด) ไม่เปลี่ยนแปลง
หากมีสิ่งใดทำงานต่างจากเวอร์ชันก่อน ให้หยุดและแสดงให้ฉันเห็นอย่างชัดเจนว่าเปลี่ยนอะไรไป

ความลับของคุณอยู่ที่ไหน? ช่องโหว่ใหญ่ที่สุดสำหรับมือใหม่#

ฉันจะอธิบายกับดักที่ใหญ่ที่สุดนี้อย่างละเอียด เพราะมันทำให้ผลิตภัณฑ์พังมากกว่ากับดักอื่น เมื่อ AI เขียนโค้ด วิธีที่ง่ายที่สุดคือใส่ key ไว้ในจุดที่ทำให้ใช้งานได้ทันที—ตรง ๆ ในโค้ดของหน้าเว็บที่เปิดในเบราว์เซอร์ คุณจะไม่เห็นความแตกต่างตอนพัฒนา แต่ใครก็อ่านทุกอย่างที่ส่งไปถึงเบราว์เซอร์ได้ เพียงเปิดเครื่องมือสำหรับนักพัฒนา

ผู้ก่อตั้งที่ลูกค้าถูกเรียกเก็บเงิน $87,500 กล่าวภายหลังว่าพรอมป์ต์เดียวอาจป้องกันเรื่องนี้ได้ ในที่สุดก็คืนเงินที่เรียกเก็บไป แต่ค่าธรรมเนียมที่ขอคืนไม่ได้และความสบายใจที่เสียไปยังคงอยู่ นี่คือพรอมป์ต์นั้น

ตรวจสอบทั้งโปรเจกต์และยืนยันว่าไม่มี secret key ใดไปอยู่ในเบราว์เซอร์:

ค้นหา key ทั้งหมดของฐานข้อมูล ระบบชำระเงิน และบริการภายนอก

ตรวจสอบว่าแต่ละ key จัดเก็บอยู่บนเซิร์ฟเวอร์เท่านั้น ใน environment variables และไม่ได้อยู่ในโค้ดของหน้าเว็บ

ตรวจสอบประวัติโปรเจกต์—ก่อนหน้านี้มี key ใดหลุดเข้าไปโดยไม่ตั้งใจหรือไม่
แสดงรายการทุกจุดที่พบความลับและสิ่งที่ต้องทำกับแต่ละจุด

กับดักใกล้เคียงอีกอย่างคือการตรวจสอบสิทธิ์การเข้าถึงเฉพาะฝั่งเบราว์เซอร์ หากผลิตภัณฑ์ตัดสินใจในโค้ดหน้าเว็บว่าจะ “แสดงส่วนผู้ดูแลระบบ” หรือไม่ ใคร ๆ ก็ข้ามการตัดสินใจนั้นได้ ต้องตรวจสอบสิทธิ์การเข้าถึงบนเซิร์ฟเวอร์เสมอ ฐานข้อมูลต้องส่งข้อมูลกลับเฉพาะผู้ที่มีสิทธิ์เท่านั้น—นี่คือจุดประสงค์ของ row-level security (RLS) และต้องเปิดใช้ในทุกตาราง

ก่อนขายสิทธิ์การเข้าถึงหรือเปิดให้คนอื่นเข้ามา ให้ตรวจสอบความปลอดภัยของผลิตภัณฑ์โดยรวม

ตรวจดูโปรเจกต์ในมุมมองของผู้โจมตีและค้นหาช่องโหว่ด้านความปลอดภัย:

มี secret key ใดจัดเก็บอยู่ในโค้ดที่ส่งไปยังเบราว์เซอร์หรือในประวัติโปรเจกต์หรือไม่

เปิดใช้ row-level security (RLS) ในทุกตารางฐานข้อมูลแล้วหรือยัง และมีการตรวจสอบสิทธิ์การเข้าถึงบนเซิร์ฟเวอร์ แทนที่จะตรวจแค่ในเบราว์เซอร์หรือไม่

กำหนดค่าการสำรองข้อมูลฐานข้อมูลอัตโนมัติไว้หรือยัง และฉันเคยตรวจสอบหรือไม่ว่าสามารถกู้คืนจากข้อมูลสำรองได้

ฐานข้อมูล production แยกจากสภาพแวดล้อมที่เอเจนต์ AI ทำงานอยู่หรือไม่
สำหรับแต่ละข้อ บอกฉันว่าทุกอย่างเรียบร้อยดีหรือมีอะไรที่ต้องแก้ไขโดยเฉพาะ

มีคู่มือฉบับเต็มแยกต่างหากเกี่ยวกับความปลอดภัยของ vibe coding: วิธีรักษาความปลอดภัยให้แอปที่สร้างด้วย vibe coding กฎนั้นเรียบง่าย: ให้ถือว่าสิ่งที่ AI ทำไว้ยังไม่ปลอดภัยเป็นค่าเริ่มต้น จนกว่าคุณจะตรวจสอบแล้วว่าไม่เป็นเช่นนั้น

จะโฮสต์ผลิตภัณฑ์ไว้ที่ไหน: ขั้นบันไดการโฮสต์#

คุณไม่จำเป็นต้องเช่าเซิร์ฟเวอร์ของตัวเองและตั้งค่าด้วยตนเองทันที—ตอนเริ่มต้นนี่เป็นงานที่ซับซ้อนและจะกินเวลาของคุณ มีขั้นบันไดที่ไต่ขึ้นไปได้เมื่อผลิตภัณฑ์เติบโต:

1. โฮสติ้งฟรี (เช่น Vercel)—สำหรับตัวคุณเอง การทดสอบ และโปรเจกต์ขนาดเล็ก ใช้ได้หากแพลตฟอร์มเข้าถึงได้สำหรับกลุ่มเป้าหมายของคุณ และคุณไม่ได้เก็บข้อมูลส่วนบุคคลของใคร
2. แพลตฟอร์มที่ deploy ได้ด้วยคำสั่งเดียว (Railway)—เมื่อคุณมี backend และฐานข้อมูล คุณ deploy ได้ด้วยคำสั่งเดียวโดยไม่ต้องตั้งค่าเซิร์ฟเวอร์ อุปสรรคในการเริ่มใช้งานมีน้อยมาก
3. เซิร์ฟเวอร์เฉพาะของตัวเอง—เมื่อโหลดสูงและคุณต้องการควบคุมทุกอย่าง ย้ายไปใช้ตัวเลือกนี้ทีหลัง เมื่อคุณชนขีดจำกัดของแพลตฟอร์ม

สำหรับคนที่ไม่ใช่โปรแกรมเมอร์และเพิ่งเปิดตัว ตัวเลือกที่ง่ายที่สุดคือแพลตฟอร์มที่ deploy ได้ด้วยคำสั่งเดียว โดยไม่ต้องตั้งค่าเซิร์ฟเวอร์เอง ค่อยย้ายไปใช้เซิร์ฟเวอร์ของตัวเองภายหลัง หากอยากทำตามแนวทางนี้โดยดูตัวอย่างจริง โปรดอ่านคู่มือเรื่องการ deploy โปรเจกต์ที่สร้างด้วย vibe coding ไปยังเซิร์ฟเวอร์ของตัวเองด้วย Coolify

เมื่อไรจึงควรแยกแอป ฐานข้อมูล และข้อมูลสำรองออกจากกัน?#

มีสามสิ่งที่ไม่ควรเก็บไว้ในตะกร้าใบเดียวกัน: แอป ฐานข้อมูล และข้อมูลสำรอง เมื่อมีผู้ใช้น้อย ทุกอย่างอยู่รวมกันก็ไม่เป็นไร แต่มีสัญญาณชัดเจนว่าถึงเวลาแยกแล้ว

• ย้ายแอปและฐานข้อมูลไปไว้คนละเครื่อง สัญญาณคือในช่วงโหลดสูงสุด CPU และหน่วยความจำใช้งานเกิน 70–80 เปอร์เซ็นต์ต่อเนื่อง คำขอเริ่มช้าลง และแอปกับฐานข้อมูลแย่งใช้ทรัพยากรเดียวกัน หลังแยกกันแล้ว คุณสามารถเพิ่มประสิทธิภาพฐานข้อมูลโดยไม่แตะแอป และในทางกลับกัน
• ทำตามกฎการสำรองข้อมูล 3-2-1 สำเนาข้อมูลสามชุด บนสื่อสองประเภทที่ต่างกัน โดยหนึ่งชุดอยู่นอกสถานที่ วิธีนี้ช่วยป้องกันความเสียหายจากฮาร์ดแวร์และ ransomware สิ่งสำคัญคือการสำรองข้อมูลต้องทำโดยอัตโนมัติ

ความถี่ในการสำรองข้อมูลขึ้นอยู่กับว่าการสูญเสียข้อมูลหลายชั่วโมงมีต้นทุนสูงเพียงใด สำหรับบริการสมาชิกออนไลน์ที่ยอมเสียบันทึกชำระเงินหนึ่งชั่วโมงไม่ได้ ต้องสำรองถี่กว่าหนึ่งชั่วโมง หรือมี transaction logs และ point-in-time recovery (PITR) ที่ตรวจแล้ว กำหนดช่วงตามข้อมูลสูงสุดที่ยอมเสียได้ และทดสอบเวลาในการกู้บริการแยกด้วย ส่วนบล็อกสำรองวันละครั้งก็เพียงพอ หลักคิดง่าย ๆ คือ ตัดสินใจว่าคุณยอมเสียข้อมูลได้มากแค่ไหน แล้วตั้งค่าการสำรองข้อมูลให้เหมาะสม

ช่วยฉันตัดสินใจว่าถึงเวลาย้ายผลิตภัณฑ์ไปใช้โครงสร้างพื้นฐานที่จริงจังขึ้นหรือยัง ตรวจสอบและถามฉันเกี่ยวกับแต่ละข้อ:

ที่ช่วงโหลดสูงสุด CPU และหน่วยความจำมีการใช้งานเท่าไร—การใช้งานอยู่สูงกว่า 70–80 เปอร์เซ็นต์ต่อเนื่องหรือไม่

ฐานข้อมูลกับแอปอยู่ในเครื่องเดียวกันหรือคนละเครื่อง

กำหนดค่าการสำรองข้อมูลฐานข้อมูลอัตโนมัติไว้หรือยัง และฉันทดสอบการกู้คืนจากข้อมูลสำรองแล้วหรือไม่

มีสำเนาสภาพแวดล้อมแยกต่างหาก (staging) สำหรับตรวจสอบก่อน deploy หรือไม่
จากผลที่ได้ ให้คำแนะนำที่ชัดเจนว่าอะไรควรปล่อยไว้ตามเดิม ควรแยกอะไรออกก่อน และเพราะเหตุใด

ยังมีอีกคำถามหนึ่ง: ใช้ฐานข้อมูลที่มีผู้ดูแลจัดการให้ หรือดูแลเอง สำหรับทีมเล็ก ๆ ฐานข้อมูลที่มีผู้ดูแลจัดการให้มักเป็นตัวเลือกที่ดีกว่าเสมอ ฐานข้อมูลของตัวเองมีต้นทุนฮาร์ดแวร์ต่ำกว่า แต่กินเวลาหลายชั่วโมงไปกับการบำรุงรักษา หากคุณทำงานคนเดียวและผลิตภัณฑ์ของคุณไม่ใช่โครงสร้างพื้นฐาน เวลาที่เสียไปมีต้นทุนสูงกว่าส่วนต่างของราคาเซิร์ฟเวอร์

จะทำให้การบำรุงรักษาทำงานอัตโนมัติได้อย่างไร?#

การบำรุงรักษาด้วยมือทำให้เหนื่อยล้า คุณสามารถลดภาระลงได้สองวิธี: การตรวจสอบระบบและเอเจนต์ตรวจตรา

การตรวจสอบระบบใช้เครื่องมือสองชนิดที่ทำหน้าที่คนละอย่าง:

1. “เว็บไซต์ออนไลน์อยู่หรือไม่?”—เครื่องมือตรวจสอบ uptime (เช่น UptimeRobot) เครื่องมือนี้จะ ping ผลิตภัณฑ์ทุกสองสามนาที และส่งการแจ้งเตือนหากระบบล่ม มีแพ็กเกจฟรี
2. “อะไรพังโดยเฉพาะ?”—เครื่องมือติดตามข้อผิดพลาด (เช่น Sentry) เครื่องมือนี้รวบรวมข้อผิดพลาดภายในแอปและแสดงว่ามีอะไรล้มเหลวที่ไหนและเพราะเหตุใด

เครื่องมือแรกตรวจพบว่าผลิตภัณฑ์ล่ม ส่วนเครื่องมือที่สองบอกว่าฟีเจอร์ใดล้มเหลวและเพราะอะไร ทั้งสองอย่างตอบคำถามว่า “ฉันจะรู้เรื่องระบบขัดข้องก่อนที่ลูกค้าจะเขียนมาหาฝ่ายสนับสนุนหรือไม่?”

การทำงานอัตโนมัติขั้นที่สองคือเอเจนต์ตรวจตรา ลองนึกถึงบริษัทอสังหาริมทรัพย์แห่งหนึ่ง: ตอนเจ็ดโมงเช้า เอเจนต์ AI อ่านคำถามจากเว็บไซต์ พบว่าแบบฟอร์มจองเสีย หาสาเหตุในโค้ด แล้วนำวิธีแก้ที่พร้อมใช้พร้อมคำอธิบายมาให้คุณ คุณตรวจสอบแล้วตอบว่า “ตกลง”—จากนั้นจึง deploy ลำดับนี้สำคัญ: แก้ปัญหาของผู้ใช้ก่อน (ให้สิทธิ์เข้าถึง กล่าวขอโทษ) แล้วค่อยสืบหาสาเหตุและเรื่องเงิน

อีกกฎหนึ่งเกี่ยวกับการให้ AI เข้าถึงฐานข้อมูล production: ให้บัญชีผู้ใช้ที่อ่านได้อย่างเดียว และซ่อนข้อมูลส่วนบุคคลไว้หลังชั้นตัวกลาง เพื่อให้เอเจนต์เห็น “ชื่อ” แทนชื่อจริงของบุคคล จากนั้น แม้เอเจนต์จะทำผิดพลาด มันก็ไม่มีทางลบหรือทำให้ข้อมูล production เสียหายได้ เหตุการณ์ในตารางด้านบนที่เอเจนต์ล้างฐานข้อมูล production เป็นตัวอย่างตรง ๆ ของการไม่มีข้อจำกัดนี้ คู่มือ ควรทำอย่างไรหาก AI ลบฐานข้อมูลของคุณ อธิบายว่าต้องทำอย่างไรหากภัยพิบัติเกิดขึ้นแล้ว

เมื่อไรจึงถึงเวลาปิดผลิตภัณฑ์?#

สิ่งที่ถูกมองข้ามมากที่สุดในการบำรุงรักษาคือการรู้ว่าเมื่อไรควรหยุดบำรุงรักษา ทุกคนที่สร้างโปรเจกต์จำนวนมากย่อมมีสุสานของโปรเจกต์: สร้างขึ้นมาหนึ่งอย่าง ลองเล่นกับมัน แล้วก็ทิ้งไป นั่นเป็นเรื่องปกติและไม่ใช่ความล้มเหลว ความล้มเหลวคือการฝืนลากสิ่งที่ไม่มีใครใช้ต่อไปหลายเดือน เพราะเสียดายเวลาที่ใช้ไป

เกณฑ์เวลาที่ใช้ประกอบการตัดสินใจได้:

1. สองสัปดาห์—นานพอที่จะเห็นว่าแนวคิดใช้ได้หรือไม่ หากผู้ใช้จริงกลุ่มแรกกลับมา ก็ทำต่อ ความเงียบคือคำตอบ
2. สามเดือน—เพดานสูงสุด หากไม่ประสบความสำเร็จภายในสามเดือน ก็ปิดมัน ด้วยความเร็วของ vibe coding การใช้เวลาหกเดือนทดสอบแนวคิดเดียวถือว่านานเกินไป

การปิดโปรเจกต์เป็นเรื่องยากทางจิตใจ ดังนั้นให้มองว่าเป็นการตัดสินใจ ไม่ใช่อารมณ์ การปล่อยมือจากโปรเจกต์ที่คุณลงทุนไปแล้วก็เหมือนการไล่พนักงานที่ทำงานไม่ได้ออก: เป็นเรื่องไม่น่ายินดี แต่การเก็บเขาไว้มีต้นทุนสูงกว่าการปล่อยไป

การบำรุงรักษาคืองานที่ทำเพื่อให้ผลิตภัณฑ์ยังมีชีวิตและเป็นประโยชน์ต่อผู้คน ส่วนอย่างอื่น—git, การสำรองข้อมูล, การตรวจสอบระบบ—เป็นเพียงเครื่องมือที่ช่วยให้คุณไปถึงจุดที่ผลิตภัณฑ์เริ่มทำงานให้คุณทุกวัน

การสร้างผลิตภัณฑ์ด้วย AI ในคืนเดียวเป็นเพียงครึ่งหนึ่งของงาน การทำให้ผลิตภัณฑ์มีชีวิตและปลอดภัยขณะที่เติบโต—นี่คือความหมายของ vibe coding สำหรับผู้ใหญ่

ขั้นต่อไปของคุณคือ Ailoot.