+− THE DAILY DIFFdev & AI news
SHIP IT

AI ໄດ້ລຶບຖານຂໍ້ມູນການຜະລິດ. ເກົ້າວິນາທີ.

ຕົວແທນການຂຽນລະຫັດ AI (Cursor ທີ່ໃຊ້ Claude Opus 4.6) ພົບຂໍ້ຜິດພາດໃນຂໍ້ມູນປະຈໍາຕົວໃນຂັ້ນຕອນການທົດສອບ ແລະ “ແກ້ໄຂ” ມັນໂດຍການໂທຫາ volumeDelete ໃນ Railway ດ້ວຍໂທເຄັນທີ່ກ່ຽວກັບບັນຊີທີ່ມັນພົບໃນໄຟລ໌ທີ່ບໍ່ກ່ຽວຂ້ອງ.

ຕົວແທນການຂຽນລະຫັດ AI (Cursor ທີ່ໃຊ້ Claude Opus 4.6) ພົບຂໍ້ຜິດພາດໃນຂໍ້ມູນປະຈໍາຕົວໃນຂັ້ນຕອນການທົດສອບ ແລະ “ແກ້ໄຂ” ມັນໂດຍການໂທຫາ volumeDelete ໃນ Railway ດ້ວຍໂທເຄັນທີ່ກ່ຽວກັບບັນຊີທີ່ມັນພົບໃນໄຟລ໌ທີ່ບໍ່ກ່ຽວຂ້ອງ. ຖານຂໍ້ມູນການຜະລິດ ແລະການສໍາຮອງຂໍ້ມູນທັງໝົດ, ຫາຍໄປພາຍໃນເກົ້າວິນາທີ. ຫຼັງເຫດການ: ເວລາ, ຄຳສັ່ງ curl ທີ່ແນ່ນອນ, ສາມຂໍ້ເທັດຈິງທາງສະຖາປັດຕະຍະກໍາທີ່ເຮັດໃຫ້ມັນເປັນໄປໄດ້ (ການສໍາຮອງຂໍ້ມູນຢູ່ໃນປະລິມານດຽວກັນ, ໂທເຄັນທີ່ມີຂອບເຂດ root, API ທີ່ບໍ່ມີຟັງຊັນຍົກເລີກ 48 ຊົ່ວໂມງຂອງແຜງຄວບຄຸມ), ແລະໃຜເປັນຜູ້ຮັບຜິດຊອບແທ້ຈິງ. ຄໍາຕັດສິນກ່ຽວກັບການແກ້ໄຂ: SHIP IT.

ອ່ານສະບັບລາຍລັກອັກສອນ (ພາສາອັງກິດ) ↗

ສິ່ງທີ່ວິດີໂອນີ້ກວມເອົາ

  • ວັນທີ 24 ເມສາ 2026: ການໂທຫາ API ຄັ້ງໜຶ່ງໄດ້ລຶບປະລິມານການຜະລິດຂອງ PocketOS ແລະຂໍ້ມູນສຳຮອງຂອງມັນ; ສຳເນົາທີ່ໃໝ່ທີ່ສຸດທີ່ຢູ່ພາຍນອກແມ່ນ 3 ເດືອນແລ້ວ
  • ໂທເຄັນຖືກສ້າງຂຶ້ນເພື່ອຈັດການໂດເມນແບບກຳນົດເອງ; ຂັ້ນຕອນຂອງ Railway ໄດ້ກຳນົດມັນເປັນຂອບເຂດບັນຊີ (ທຸກຢ່າງ)
  • ວັນທີ 27 ເມສາ: Railway ກູ້ຄືນຂໍ້ມູນຈາກການສຳຮອງຂໍ້ມູນໄພພິບັດ; ວັນທີ 29 ເມສາ ຫຼັງເຫດການ; ວັນທີ 1 ພຶດສະພາ: ການລຶບ API ຕອນນີ້ຈະລຶບແບບຊົ່ວຄາວເປັນເວລາ 48 ຊົ່ວໂມງ

ບົດບັນທຶກທີ່ແປແລ້ວ

ແປຈາກຄຳບັນຍາຍຕົ້ນສະບັບພາສາອັງກິດ. ສຽງ ແລະ ຄຳບັນຍາຍທີ່ມີໃຫ້ແມ່ນຄວບຄຸມໂດຍ YouTube.

0:00 ຕົວແທນການຂຽນລະຫັດ AI ພົບລະຫັດຜ່ານຜິດໃນຂັ້ນຕອນການທົດສອບ, ແລະແກ້ໄຂມັນໂດຍການລຶບ ຖານຂໍ້ມູນການຜະລິດ ແລະການສຳຮອງຂໍ້ມູນທັງໝົດໃນການໂທ API ຄັ້ງດຽວ. ເກົ້າວິນາທີ, ເຊິ່ງຍັງໄວກວ່າການຣີເຊັດລະຫັດຜ່ານ. ບໍລິສັດຄື PocketOS, ຊອບແວໃຫ້ເຊົ່າລົດ. ຕົວແທນຄື Cursor ທີ່ໃຊ້ Claude Opus 4.6, ເປັນຕົວແບບທີ່ມີລາຄາແພງທີ່ສຸດໃນ ເມນູ, ແລະແພລະຕະຟອມຄື Railway. ຜູ້ກໍ່ຕັ້ງຂຽນລົງໃນ X, ເຈັດລ້ານຄົນໄດ້ອ່ານມັນ, ແລະສີ່ມື້ຕໍ່ມາ Railway ໄດ້ເຜີຍແຜ່ບົດຫຼັງເຫດການຂອງຕົນເອງ.

0:27 ທຸກຄົນເຫັນດີກ່ຽວກັບສິ່ງທີ່ເກີດຂຶ້ນ; ບໍ່ມີໃຜເຫັນດີວ່າໃຜເປັນຜູ້ຜິດ. ມັນເກີດຂຶ້ນແນວໃດ, ເປັນຫຍັງມັນຈຶ່ງເປັນໄປໄດ້, ແລະໃຜເປັນຜູ້ຮັບຜິດຊອບແທ້ຈິງ. ນີ້ແມ່ນ The Daily Diff, ຫຼັງເຫດການ. ວັນສຸກຕອນບ່າຍ, ວັນທີ 24 ເມສາ. ຕົວແທນກໍາລັງເຮັດວຽກປົກກະຕິໃນຂັ້ນຕອນການທົດສອບ, ພົບຂໍ້ຜິດພາດໃນຂໍ້ມູນປະຈໍາຕົວ, ແລະຕັດສິນໃຈວ່າການແກ້ໄຂຄືການລຶບປະລິມານ Railway. ມັນຕ້ອງການໂທເຄັນ, ໄປຊອກຫາ, ແລະພົບອັນໜຶ່ງໃນໄຟລ໌ທີ່ບໍ່ກ່ຽວຂ້ອງ: ໂທເຄັນ CLI ທີ່ຖືກສ້າງຂຶ້ນຫຼາຍເດືອນກ່ອນໜ້ານີ້ເພື່ອຈັດການໂດເມນແບບກຳນົດເອງ.

0:55 ຫຼັງຈາກນັ້ນມັນກໍດໍາເນີນການນີ້. Curl ອັນໜຶ່ງ: POST ໄປຫາຈຸດເຊື່ອມຕໍ່ GraphQL ຂອງ Railway, ໂທເຄັນ bearer, ການປ່ຽນແປງທີ່ເອີ້ນວ່າ volumeDelete. ບໍ່ມີການຢືນຢັນ, ບໍ່ມີການພິມຊື່ປະລິມານ, ບໍ່ມີການກວດສອບສະພາບແວດລ້ອມ. ປະລິມານທີ່ມັນສົມມຸດວ່າເປັນຂັ້ນຕອນການທົດສອບຄືການຜະລິດ, ແລະຂໍ້ມູນສຳຮອງກໍຢູ່ໃນນັ້ນ. ພາຍໃນສິບນາທີ ຜູ້ກໍ່ຕັ້ງໄດ້ແທັກ CEO ຂອງ Railway ໃນ X, ຜູ້ທີ່ຕອບວ່າອັນນີ້ໜຶ່ງພັນເປີເຊັນບໍ່ຄວນເປັນໄປໄດ້. ສາມສິບຊົ່ວໂມງຕໍ່ມາ, ຍັງບໍ່ມີຄໍາຕອບການກູ້ຄືນ, ດັ່ງນັ້ນຜູ້ກໍ່ຕັ້ງຈຶ່ງເຜີຍແຜ່

1:19 ທຸກຢ່າງ, ລວມທັງການສາລະພາບ. ສາມຂໍ້ເທັດຈິງເຮັດໃຫ້ສິ່ງນີ້ເປັນໄປໄດ້, ບໍ່ມີອັນໃດກ່ຽວກັບຕົວແບບ. ໜຶ່ງ: Railway ເກັບຂໍ້ມູນສຳຮອງປະລິມານຢູ່ໃນປະລິມານນັ້ນເອງ. ເອກະສານກ່າວໄວ້ໃນຫ້າຄຳ: ການລຶບປະລິມານຈະລຶບຂໍ້ມູນສຳຮອງທັງໝົດ. ນັ້ນຄືສຳເນົາຢູ່ໃນພື້ນທີ່ສ່ຽງດຽວກັນ; ສຳເນົາທີ່ໃໝ່ທີ່ສຸດບ່ອນອື່ນແມ່ນສາມ ເດືອນແລ້ວ. ສອງ: ໂທເຄັນຄື ຂອບເຂດບັນຊີ, ເປັນຂອບເຂດທີ່ກວ້າງທີ່ສຸດທີ່ Railway ຂາຍ. ມີຂອບເຂດທີ່ແຄບກວ່າ, ແຕ່ຂັ້ນຕອນການສ້າງໄດ້ເຊື່ອງພວກມັນໄວ້,

1:40 ດັ່ງນັ້ນໂທເຄັນສຳລັບບັນທຶກ DNS ສາມາດລຶບຖານຂໍ້ມູນໄດ້, ແລະບໍ່ມີໃຜຮູ້ຈົນກວ່າ ບາງສິ່ງບາງຢ່າງຈະເກີດຂຶ້ນ. ສາມ: ແຜງຄວບຄຸມມີຟັງຊັນຍົກເລີກການລຶບເປັນເວລາສີ່ສິບແປດຊົ່ວໂມງ ມາຫຼາຍປີແລ້ວ; ຈຸດເຊື່ອມຕໍ່ API ທີ່ຕົວແທນໂທຫານັ້ນຄືເສັ້ນທາງເກົ່າ, ແລະມັນລຶບທັນທີ. ທຸກອຸປະກອນປ້ອງກັນທີ່ Railway ສ້າງແມ່ນຢູ່ໃນບ່ອນທີ່ມະນຸດຄລິກ, ແລະຕົວແທນໃຊ້ປະຕູໜຶ່ງທີ່ພວກເຂົາລືມໄປ. ເມື່ອຖືກຖາມວ່າເປັນຫຍັງ, Opus ຂຽນວ່າ: ຂ້ອຍຄິດວ່າການລຶບປະລິມານການທົດສອບຈະມີຂອບເຂດ ພຽງແຕ່ການທົດສອບເທົ່ານັ້ນ; ຂ້ອຍບໍ່ໄດ້ກວດສອບ.

2:04 ຄໍາສາລະພາບທີ່ດີຫຼາຍຈາກຕົວແບບທີ່ຈື່ຫຍັງບໍ່ໄດ້ ແລະກໍາລັງສ້າງ ຄໍາຂໍໂທດທີ່ເປັນໄປໄດ້ທີ່ສຸດ. git blame: ຄວາມບໍ່ກົງກັນຂອງຂໍ້ມູນປະຈໍາຕົວຖືກຖືວ່າເປັນສິ່ງທີ່ຕ້ອງແກ້ໄຂຫຼາຍກວ່າ ສິ່ງທີ່ຕ້ອງຢຸດເຊົາ, ແລະປຸ່ມຍົກເລີກຢູ່ໃນ UI ໃນຂະນະທີ່ API ຕອບ ການລຶບທີ່ໄດ້ຮັບການຢັ້ງຢືນທຸກຄັ້ງດ້ວຍຄໍາວ່າແມ່ນ. ບໍ່ແມ່ນຜູ້ກໍ່ຕັ້ງ, ບໍ່ແມ່ນຕົວແບບ. ຄ່າເລີ່ມຕົ້ນ. ພື້ນທີ່ສ່ຽງ: ເກົ້າວິນາທີເພື່ອລຶບ, ສາມເດືອນຂອງການຈອງ ຫາຍໄປ, ຕູ້ເຊົ່າໃນເຊົ້າວັນເສົາທີ່ບໍ່ມີບັນທຶກວ່າໃຜຢືນຢູ່ບ່ອນນັ້ນ,

2:31 ແລະປະມານສອງວັນເຄິ່ງຈົນກວ່າ CEO ຂອງ Railway ຈະ DM ວ່າຂໍ້ມູນ ກັບຄືນມາ, ຈາກການສໍາຮອງຂໍ້ມູນໄພພິບັດພາຍນອກທີ່ການລຶບໄດ້ເຮັດໃຫ້ມັນເບິ່ງຄືວ່າຫາຍໄປ. ຄໍາຕອບທີ່ມັກທີ່ສຸດ: ຕົວແທນທີ່ເຈົ້າກໍາລັງໃຊ້ໄດ້ລຶບບາງຢ່າງ, ແລະເຈົ້າຕໍານິທຸກຄົນຍົກເວັ້ນຕົວເຈົ້າເອງ. ຍຸດຕິທຳ. Railway ຍັງໄດ້ເປີດຕົວເຊີບເວີ MCP ຂອງຕົນສຳລັບຕົວແທນໃນອາທິດກ່ອນໜ້ານີ້, ດ້ວຍໂທເຄັນດຽວກັນ. ຍຸດຕິທຳເຊັ່ນກັນ. ຄໍາຕັດສິນ, ຫຼັງເຫດການ: ship it, ກ່ຽວກັບການແກ້ໄຂ. Railway ໄດ້ເຜີຍແຜ່ບົດຫຼັງເຫດການທີ່ສັດຊື່ໃນສີ່ວັນ, ແລະຮອດວັນທີໜຶ່ງພຶດສະພາ API

3:00 ລຶບແບບຊົ່ວຄາວເປັນເວລາສີ່ສິບແປດຊົ່ວໂມງຄືກັບແຜງຄວບຄຸມ. ການກະທໍາໃນວັນຈັນ: ລາຍຊື່ທຸກໂທເຄັນທີ່ຕົວແທນຂອງເຈົ້າສາມາດເຂົ້າເຖິງໄດ້, ແລະຖືວ່າແຕ່ລະອັນເປັນ root ຈົນກວ່າຈະພິສູດໄດ້ເປັນຢ່າງອື່ນ. ສົ່ງເຫດການທີ່ເຈົ້າຍັງບໍ່ໄດ້ຮັບອະນຸຍາດໃຫ້ເວົ້າເຖິງມາໃຫ້ຂ້ອຍ, ໃນຄໍາຄິດເຫັນ, ຫຼືທີ່ the daily diff dot dev. ແລະນັ້ນຄື diff ສໍາລັບມື້ນີ້. ຂ້ອຍຄື Niko ຈາກ Axrisi. ລວມເຂົ້າກັນຢ່າງມີຄວາມຮັບຜິດຊອບ.

ແຫຼ່ງຂໍ້ມູນ

  1. Jer Crane (founder, PocketOS), "An AI Agent Just Destroyed Our Production Data. It Confessed in Writing."x.com
  2. Railway, "Your AI wants to nuke your database. Guardrails fix that." (Apr 29, 2026)blog.railway.com
  3. Railway changelog #0288, "Undoable volume deletes" (May 1, 2026)railway.com
  4. Railway docs, Backups ("Wiping a volume deletes all backups.")docs.railway.com
  5. Jake Cooper (Railway CEO), "The AI Engineer: A New Breed"x.com
  6. Recovery confirmedx.com
  7. Hacker News (860 points, 1,032 comments)news.ycombinator.com
  8. The Registerwww.theregister.com
  9. The New Stackthenewstack.io

ວິດີໂອທີ່ກ່ຽວຂ້ອງ

postmortem · lo · 10 ກ.ຍ. 2026

ວິສະວະກອນລຶບຖານຂໍ້ມູນການຜະລິດຂອງ GitLab. 300 ກິກກະໄບ.

ວັນທີ 31 ມັງກອນ 2017, ເວລາ 23:27 UTC: ວິສະວະກອນຂອງ GitLab, ໃນຂະນະທີ່ກຳລັງແກ້ໄຂບັນຫາແບບຈຳລອງທີ່ເສຍຫາຍໃນຕອນທ້າຍຂອງຄືນ, ໄດ້ລຶບໄດເລກະທໍລີຂໍ້ມູນ PostgreSQL ໃນ db1 ແທນທີ່ຈະເປັນ db2. db1 ແມ່ນຖານຂໍ້ມູນຫຼັກ. ປ

2:53 ↗
postmortem · lo · 25 ກ.ຍ. 2026

ຂໍ້ຜິດພາດໜຶ່ງມິນລິວິນາທີ ໄດ້ຢຸດຕິການຈະລາຈອນທາງອາກາດຂອງອັງກິດ. ຫົກຊົ່ວໂມງ.

ເວລາ 10:00 ໂມງ ຂອງວັນອັງຄານທີ 8 ກັນຍາ, ການຮ້ອງຂໍລະຫັດ squawk ປົກກະຕິອັນໜຶ່ງພາຍໃນລະບົບນ່ານຟ້າແຫ່ງຊາດ (NAS) ຂອງ NATS ຖືກຂັດຂວາງໂດຍຂໍ້ຄວາມທີ່ມີຄວາມສຳຄັນສູງກວ່າໃນຂະນະທີ່ມັນກຳລັງອັບເດດຄ່າໜຶ່ງຢູ່. ໄລຍະເວລາສ

3:06 ↗
postmortem · lo · 22 ກ.ຍ. 2026

ການຣີບູດເຮັດໃຫ້ Telstra ກັບຄືນສູ່ປີ 2006. ໂທລະສັບເກົ້າລ້ານເຄື່ອງ.

ວິສະວະກອນຢູ່ Melbourne ເປີດເຄື່ອງຈັບເວລາຄືນໃໝ່ໃນເວລາ 2:50 ໂມງເຊົ້າ, ແລະເມື່ອຮອດຕອນເຊົ້າເຄືອຂ່າຍໂທລະສັບມືຖືທີ່ໃຫຍ່ທີ່ສຸດຂອງອົດສະຕາລີກໍຕົກລົງວ່າມັນແມ່ນເດືອນພະຈິກ 2006. ວັນທີ 8 ກໍລະກົດ 2026: ບັດ GPS ໃນເຄ

3:15 ↗
postmortem · lo · 19 ກ.ຍ. 2026

Google Cloud ຂັດຂ້ອງໃນພື້ນທີ່ຫວ່າງເປົ່າ. ສາມຊົ່ວໂມງ.

ແຖວນະໂຍບາຍທີ່ມີຊ່ອງຫວ່າງເປົ່າສອງສາມຊ່ອງພົບຕົວຊີ້ null, ແລະ Google Cloud ຂັດຂ້ອງພ້ອມກັນໃນທຸກພາກພື້ນ – ຈາກນັ້ນ Cloudflare ກໍລົ້ມລົງໄປພ້ອມກັນ. ວັນທີ 12 ມິຖຸນາ 2025, 17:49 UTC: Service Control, ໄບນາຣີທີ່ອ

2:57 ↗