นโยบายการเก็บรักษาข้อมูลสำหรับแอพธุรกิจ: หน้าต่างและเวิร์กโฟลว์

ปัญหาที่นโยบายการเก็บรักษาจริงๆ แก้ไข\n\nนโยบายการเก็บรักษาคือชุดกฎชัดเจนที่แอพของคุณปฏิบัติตามเกี่ยวกับข้อมูล: เก็บอะไร เก็บนานเท่าไร อยู่ที่ไหน และจะเกิดอะไรเมื่อหมดเวลา เป้าหมายไม่ใช่ "ลบทุกอย่าง" แต่คือเก็บสิ่งที่ต้องใช้ในการดำเนินงานและอธิบายเหตุการณ์ในอดีต ขณะเดียวกันก็กำจัดสิ่งที่ไม่จำเป็น\n\nถ้าไม่มีแผน สามปัญหาจะโผล่มาเร็ว: พื้นที่เก็บข้อมูลโตขึ้นจนเริ่มมีค่าใช้จ่ายจริง ความเสี่ยงด้านความเป็นส่วนตัวและความปลอดภัยเพิ่มกับสำเนาข้อมูลส่วนบุคคลทุกชิ้น และรายงานจะไม่น่าเชื่อถือเมื่อเร็กคอร์ดเก่าไม่ตรงกับตรรกะปัจจุบันหรือคนลบข้อมูลไม่เป็นระบบแล้วแดชบอร์ดเปลี่ยนทันที\n\nนโยบายการเก็บรักษาเชิงปฏิบัติบาลานซ์การปฏิบัติงาน ข้อพิสูจน์ และการปกป้องลูกค้า:\n\n- การปฏิบัติงาน: ผู้คนยังทำงานได้ตามปกติ\n- ข้อพิสูจน์: คุณอธิบายการทำธุรกรรมย้อนหลังได้\n- ลูกค้า: คุณไม่เก็บข้อมูลส่วนบุคคลนานเกินความจำเป็น\n\nแอพธุรกิจส่วนใหญ่มีพื้นที่ข้อมูลกว้างๆ เหมือนกัน แม้จะเรียกชื่อไม่เหมือนกัน: โปรไฟล์ผู้ใช้ ธุรกรรม บันทึกตรวจสอบ ข้อความ และไฟล์อัปโหลด\n\nนโยบายคือส่วนหนึ่งเป็นกฎ ส่วนหนึ่งเป็นเวิร์กโฟลว์ และส่วนหนึ่งเป็นเครื่องมือ กฎอาจบอกว่า “เก็บตั๋วซัพพอร์ต 2 ปี” เวิร์กโฟลว์กำหนดความหมายเชิงปฏิบัติ: ย้ายตั๋วเก่าลงอาร์ไคฟ์ ทำให้ฟิลด์ลูกค้าไม่ระบุตัวตน และบันทึกสิ่งที่เกิดขึ้น เครื่องมือทำให้มันทำซ้ำได้และตรวจสอบได้\n\nถ้าคุณสร้างแอพบน AppMaster ให้มองการเก็บรักษาเป็นพฤติกรรมของผลิตภัณฑ์ ไม่ใช่การทำความสะอาดครั้งเดียว Scheduled Business Processes สามารถอาร์ไคฟ์ ลบ หรือทำให้ไม่ระบุตัวตนข้อมูลในแบบเดิมทุกครั้ง ทำให้การรายงานคงที่และผู้คนเชื่อถือข้อมูลได้\n\n## ข้อจำกัดที่ต้องเคลียร์ก่อนเลือกหน้าต่างเวลา\n\nก่อนตั้งวันที่ ต้องชัดเจนว่าทำไมต้องเก็บข้อมูล การตัดสินใจเรื่องการเก็บมักถูกกำหนดโดยกฎหมายความเป็นส่วนตัว สัญญากับลูกค้า และกฎการตรวจสอบหรือภาษี ข้ามขั้นตอนนี้แล้วคุณจะเก็บมากเกินไป (เพิ่มความเสี่ยงและค่าใช้จ่าย) หรือลบสิ่งที่จำเป็นในภายหลัง\n\nเริ่มแยก "ต้องเก็บ" กับ "เก็บไว้ก็ได้" ข้อมูลที่ต้องเก็บมักรวมใบแจ้งหนี้ รายการบัญชี และบันทึกการตรวจสอบที่ต้องใช้พิสูจน์ว่าคนทำอะไรเมื่อไร ส่วนที่เก็บไว้ก็ได้อาจเป็นบทสนทนาเก่า ประวัติการคลิกละเอียด หรือบันทึกเหตุการณ์ดิบที่ใช้แค่บางครั้ง\n\nข้อกำหนดยังเปลี่ยนตามประเทศและอุตสาหกรรม พอร์ทัลซัพพอร์ตของผู้ให้บริการด้านสุขภาพมีข้อจำกัดต่างจากเครื่องมือแอดมิน B2B แม้ในบริษัทเดียวกัน ผู้ใช้จากหลายประเทศก็อาจมีข้อกำหนดต่างกันสำหรับประเภทเร็กคอร์ดเดียวกัน\n\nเขียนการตัดสินใจด้วยภาษาธรรมดาและมอบเจ้าของ “เก็บตั๋ว 24 เดือน” โดยเปล่าๆ ไม่พอ ระบุให้ชัดว่าจะรวมอะไร ยกเว้นอะไร และเกิดอะไรเมื่อหน้าต่างสิ้นสุด (อาร์ไคฟ์ ทำให้ไม่ระบุตัวตน ลบ) ตั้งคนหรือทีมรับผิดชอบเพื่อการอัปเดตไม่สะดุดเมื่อผลิตภัณฑ์หรือกฎหมายเปลี่ยน\n\nขออนุมัติโดยเร็ว ก่อนวิศวกรเริ่มสร้าง กฎหมายยืนยันขั้นต่ำและภาระหน้าที่การลบ ความปลอดภัยประเมินความเสี่ยง การเข้าถึง และการบันทึก ผลิตภัณฑ์ยืนยันสิ่งที่ผู้ใช้ยังต้องเห็น การเงินยืนยันความต้องการการเก็บบันทึก\n\nตัวอย่าง: เก็บบันทึกการเรียกเก็บเงิน 7 ปี เก็บตั๋ว 2 ปี และทำให้ฟิลด์โปรไฟล์ผู้ใช้ไม่ระบุตัวตนหลังปิดบัญชีโดยยังเก็บเมตริกรวมไว้ ใน AppMaster กฎที่เขียนเหล่านี้แมปได้ตรงกับกระบวนการตามตารางเวลาและการเข้าถึงตามบทบาท โดยลดการคาดเดาในภายหลัง\n\n## แม็ปข้อมูลตามประเภท ความอ่อนไหว และที่อยู่ของมัน\n\nนโยบายการเก็บรักษามักล้มเหลวเมื่อทีมพูดว่า "เก็บ 2 ปี" โดยไม่รู้ว่า "มัน" คืออะไร สร้างแผนที่ข้อมูลง่ายๆ ที่คุณมี อย่าไล่หาความสมบูรณ์แบบ ตั้งเป้าให้หัวหน้าซัพพอร์ตและหัวหน้าการเงินเข้าใจตรงกัน\n\n### จัดประเภทตามประเภทและความอ่อนไหว\n\nชุดเริ่มต้นเชิงปฏิบัติได้แก่:\n\n- ข้อมูลลูกค้า: โปรไฟล์ ตั๋ว คำสั่งซื้อ ข้อความ\n- ข้อมูลพนักงาน: บันทึก HR บันทึกการเข้าถึง ข้อมูลอุปกรณ์\n- ข้อมูลปฏิบัติการ: เวิร์กโฟลว์ เหตุการณ์ระบบ บันทึกตรวจสอบ\n- ข้อมูลการเงิน: ใบแจ้งหนี้ การจ่ายเงิน ฟิลด์ภาษี\n- เนื้อหาและไฟล์: ไฟล์อัปโหลด การส่งออก เอกสารแนบ\n\nจากนั้นระบุความอ่อนไหวด้วยคำง่ายๆ: ข้อมูลส่วนบุคคล (ชื่อ อีเมล) ทางการเงิน (ข้อมูลธนาคาร โทเค็นการชำระเงิน) รหัสประจำตัว (แฮชพาสเวิร์ด คีย์ API) หรือข้อมูลที่ถูกกำกับดูแล (เช่น ข้อมูลสุขภาพ) ถ้าไม่แน่ใจ ให้ติดป้ายว่า "อาจอ่อนไหว" แล้วถือว่าเป็นกรณีอ่อนไหวจนยืนยันได้\n\n### แม็ปว่ามันอยู่ที่ไหนและใครพึ่งพามัน\n\n"อยู่ที่ไหน" มักมากกว่าแค่ฐานข้อมูลหลัก ให้จดตำแหน่งชัดเจน: ตารางฐานข้อมูล ที่เก็บไฟล์ บันทึกอีเมล/SMS เครื่องมือวิเคราะห์ หรือคลังข้อมูล และใครพึ่งพาชุดข้อมูลแต่ละชุด (ซัพพอร์ต เซลส์ การเงิน ผู้บริหาร) และความถี่การใช้งาน นั่นจะบอกว่าการลบกระทบอะไรบ้าง\n\nนิสัยที่เป็นประโยชน์: อธิบายจุดประสงค์ของแต่ละชุดข้อมูลเป็นประโยคเดียว ตัวอย่าง: "ตั๋วซัพพอร์ตเก็บไว้เพื่อแก้ข้อพิพาทและติดตามแนวโน้มเวลาตอบกลับ"\n\nถ้าคุณสร้างด้วย AppMaster คุณสามารถจับสิ่งนี้ให้ตรงกับสิ่งที่ปรับใช้อยู่จริงโดยตรวจสอบโมเดลใน Data Designer การจัดการไฟล์ และการเชื่อมต่อที่เปิดใช้งาน\n\nเมื่อแผนที่มีอยู่ การเก็บรักษากลายเป็นชุดการตัดสินใจเล็กๆ ชัดเจน แทนการเดาครั้งใหญ่\n\n## วิธีตั้งหน้าต่างการเก็บรักษาที่คนปฏิบัติตามได้\n\nหน้าต่างใช้ได้ก็ต่อเมื่อมันอธิบายง่ายและใช้ได้ง่าย หลายทีมทำได้ดีด้วยชั้นง่ายๆ ที่ตรงกับการใช้งาน: ร้อน (ใช้ทุกวัน), อุ่น (ใช้เป็นครั้งคราว), เย็น (เก็บเป็นหลักฐาน) แล้วค่อยลบหรือทำให้ไม่ระบุตัวตน ชั้นเหล่านี้เปลี่ยนนโยบายเป็นกิจวัตร\n\nตั้งหน้าต่างตามหมวด ไม่ใช่ตัวเลขรวมหนึ่งค่า ใบแจ้งหนี้มักต้องเก็บนานเพื่อตรวจสอบภาษี ส่วนบทสนทนาซัพพอร์ตมักหมดคุณค่าเร็ว\n\nยังต้องตัดสินใจว่าจุดเริ่มนับคืออะไร "เก็บ 2 ปี" จะไม่มีความหมายถ้าไม่กำหนดว่า "2 ปีนับจากอะไร" เลือกทริกเกอร์หนึ่งอย่างต่อหมวด เช่น วันที่สร้าง กิจกรรมสุดท้าย วันที่ปิดตั๋ว หรือการปิดบัญชี ถ้าทริกเกอร์ต่างกันโดยไม่มีกฎชัด ทีมจะเดาและการเก็บจะเบี่ยงเบน\n\nเขียนข้อยกเว้นล่วงหน้าเพื่อทีมจะไม่ประดิษฐ์ขึ้นภายหลัง ข้อยกเว้นทั่วไปได้แก่ การกดหยุดทางกฎหมาย การเรียกเงินคืน และการสืบสวนการฉ้อโกง เหล่านี้ควรหยุดการลบ แต่ไม่ควรทำให้เกิดสำเนาลับ\n\nเก็บกฎสุดท้ายสั้นและทดสอบได้:\n\n- บทสนทนาซัพพอร์ต: ทำให้ไม่ระบุตัวตน 6 เดือนหลังข้อความสุดท้าย เว้นแต่จะอยู่ใน legal hold\n- ลีดการตลาด: ลบ 12 เดือนหลังการเคลื่อนไหวครั้งสุดท้ายถ้าไม่มีสัญญา\n- บัญชีลูกค้า: ลบ 30 วันหลังปิดบัญชี; เก็บใบแจ้งหนี้ 7 ปี\n- บันทึกความปลอดภัย: เก็บร้อน 90 วัน เก็บเย็น 12 เดือนเพื่อสืบสวน\n- เร็กคอร์ดใด ๆ ที่ถูกตั้งค่า legal_hold=true: ห้ามลบจนกว่าจะยกเลิก\n\n## กลยุทธ์อาร์ไคฟ์ที่ทำให้ข้อมูลยังใช้ได้และถูกลง\n\nอาร์ไคฟ์ไม่ใช่แบ็กอัพ แบ็กอัพเพื่อกู้คืนหลังความผิดพลาดหรือการล้มเหลว อาร์ไคฟ์เป็นการตั้งใจ: ข้อมูลเก่าออกจากตารางร้อนไปที่ที่เก็บถูกลง แต่ยังสามารถเรียกคืนได้เพื่อการตรวจสอบ ข้อพิพาท และคำถามประวัติศาสตร์\n\nแอพส่วนใหญ่ต้องการทั้งคู่ แบ็กอัพถี่และครอบคลุม ในขณะที่อาร์ไคฟ์เลือกเฉพาะและควบคุม และปกติจะเรียกคืนเฉพาะสิ่งที่ต้องการจริงๆ\n\n### เลือกที่เก็บที่ถูกกว่า แต่ยังค้นหาได้\n\nที่เก็บถูกลงมีประโยชน์ก็ต่อเมื่อคนยังหาสิ่งที่ต้องการเจอได้ หลายทีมใช้ฐานข้อมูลหรือสกีม่าแยกที่ปรับสำหรับการอ่านมาก หรือนำออกเป็นไฟล์พร้อมตารางดัชนีสำหรับการค้นหา ถ้าแอพของคุณแบบ PostgreSQL (รวมถึงใน AppMaster) สร้างสกีม่าอาร์ไคฟ์หรือฐานข้อมูลแยกเพื่อให้ตารางโปรดักชันเร็วและยังอนุญาตการรายงานผ่านข้อมูลอาร์ไคฟ์ได้ตามสิทธิ์\n\nก่อนเลือกฟอร์แมต ให้กำหนดความหมาย "ค้นหาได้" ในธุรกิจของคุณ ซัพพอร์ตอาจต้องค้นจากอีเมลหรือรหัสตั๋ว การเงินอาจต้องรวมตามเดือน การตรวจสอบอาจต้องติดตามตามรหัสคำสั่ง\n\n### ตัดสินใจว่าจะอาร์ไคฟ์อะไร: เร็กคอร์ดเต็มหรือสรุป\n\nเร็กคอร์ดเต็มเก็บรายละเอียดแต่ราคาแพงและเพิ่มความเสี่ยงด้านความเป็นส่วนตัว สรุป (ยอดรวมต่อเดือน จำนวน เหตุการณ์สำคัญ) ถูกกว่าและมักเพียงพอสำหรับรายงาน\n\nแนวทางปฏิบัติ:\n\n- อาร์ไคฟ์เร็กคอร์ดเต็มสำหรับออบเจ็กต์ที่สำคัญต่อการตรวจสอบ (ใบแจ้งหนี้ คืนเงิน บันทึกการเข้าใช้)\n- อาร์ไคฟ์สรุปสำหรับเหตุการณ์ปริมาณมาก (คลิก การดูหน้า พิงก์เซนเซอร์)\n- เก็บชิ้นอ้างอิงเล็กๆ ในสตอเรจร้อน (มัก 30–90 วันล่าสุด)\n\nวางแผนฟิลด์ดัชนีล่วงหน้า เช่น รหัสหลัก รหัสผู้ใช้/ลูกค้า บักเก็ตวันที่ (เดือน) ภูมิภาค และสถานะ หากไม่มีฟิลด์เหล่านี้ ข้อมูลอาร์ไคฟ์อยู่แต่เรียกคืนยาก\n\nกำหนดกฎการเรียกคืนด้วย: ใครขอ restore ใครอนุมัติ ที่ไหนจะวางข้อมูลที่คืน และเวลาที่คาดหวัง การคืนอาจช้าโดยตั้งใจถ้านั่นลดความเสี่ยง แต่ต้องทำนายได้\n\n## การลบกับการทำให้ไม่ระบุตัวตน: เลือกแนวทางที่เหมาะสม\n\nนโยบายการเก็บมักบังคับให้เลือก: ลบเร็กคอร์ด หรือเก็บไว้แต่เอารายละเอียดส่วนบุคคลออก ทั้งสองมีเหตุผลและแก้ปัญหาต่างกัน\n\nการลบแบบ hard delete เอาเร็กคอร์ดออกจริง เหมาะเมื่อไม่มีเหตุผลทางกฎหมายหรือธุรกิจที่จะเก็บและการเก็บทำให้เกิดความเสี่ยง เช่น บทสนทนาเก่าที่มีรายละเอียดอ่อนไหว\n\nการลบแบบ soft delete เก็บแถวไว้แต่ทำเครื่องหมายว่าลบ (มักมี deleted_at) และซ่อนจากหน้าจอและ API ปกติ เหมาะเมื่อผู้ใช้คาดว่าจะกู้คืน หรือระบบดาวน์สตรีมอาจยังอ้างอิง เร็กคอร์ด soft-deleted ยังคงอยู่ กินพื้นที่ และอาจหลุดผ่านการส่งออกถ้าไม่ระวัง\n\nการทำให้ไม่ระบุตัวตนเก็บเหตุการณ์หรือการทำธุรกรรมไว้แต่เอาหรือแทนที่ค่าส่วนบุคคล วิธีที่ทำถูกต้องไม่สามารถย้อนกลับได้ ส่วน pseudonymization คือแทนตัวระบุด้วยโทเค็นและเก็บแผนผังแยกต่างหาก ซึ่งช่วยสืบสวนแต่ไม่เท่าการไม่ระบุตัวตนจริงๆ\n\nต้องชัดเจนเรื่องข้อมูลที่เกี่ยวข้อง เพราะตรงนี้นโยบายล้มเหลวบ่อย การลบเร็กคอร์ดแต่ปล่อยไฟล์แนบ ธัมบ์เนล แคช ดัชนีการค้นหา หรือสำเนาการวิเคราะห์ จะทำลายนโยบายเงียบๆ\n\nคุณยังต้องมีหลักฐานว่าการลบเกิดขึ้น เก็บใบเสร็จการลบง่ายๆ: อะไรถูกลบ/ทำให้ไม่ระบุตัวตน เมื่อไหร่ โฟลว์ไหนรัน และสำเร็จหรือไม่ ใน AppMaster สิ่งนี้อาจเป็น Business Process ที่เขียนบันทึกตรวจสอบเมื่องานเสร็จ\n\n## รักษาค่าการรายงานขณะเอาข้อมูลส่วนบุคคลออก\n\nรายงานพังเมื่อคุณลบหรือทำให้ไม่ระบุตัวตนเร็กคอร์ดที่แดชบอร์ดคาดว่าจะ join ข้ามเวลา ก่อนเปลี่ยนอะไร ให้จดเมตริกที่ต้องคงเทียบเดือนไปเดือนไว้ มิฉะนั้นคุณจะมานั่งดีบั๊กว่า "ทำไมกราฟปีที่แล้วเปลี่ยนไป?" ทีหลัง\n\nเริ่มด้วยรายการเมตริกสั้นๆ ที่ต้องเที่ยงตรง:\n\n- รายได้และการคืนเงินตามวัน/สัปดาห์/เดือน\n- การใช้งานผลิตภัณฑ์: ผู้ใช้งานแอคทีฟ เหตุการณ์ที่นับ การรับเอาฟีเจอร์\n- เมตริก SLA: เวลาในการตอบ เวลาแก้ไข ความพร้อมให้บริการ\n- อัตราเฟันเนลและการแปลง\n- ปริมาณซัพพอร์ต: ตั๋ว หมวดหมู่ อายุคงค้าง\n\nจากนั้นออกแบบสิ่งที่จะเก็บเพื่อรายงานโดยไม่ต้องใช้ตัวระบุส่วนบุคคล วิธีที่ปลอดภัยคือการทำการรวม (aggregation) แทนการเก็บแถวดิบตลอดไป เก็บยอดรวมรายวัน โคฮอร์ตรายสัปดาห์ และการนับที่ไม่สามารถสืบกลับเป็นบุคคลได้ ตัวอย่าง: เก็บ "ตั๋วที่สร้างต่อวันต่อหมวด" และ "ค่าเฉลี่ยเวลาตอบครั้งแรกต่อสัปดาห์" แม้จะลบเนื้อหาเดิมก็ยังได้ข้อมูลแนวโน้ม\n\n### เก็บคีย์วิเคราะห์ที่คงที่โดยไม่เก็บตัวตน\n\nรายงานบางอย่างยังต้องมีวิธีกลุ่มพฤติกรรมข้ามเวลา ใช้คีย์วิเคราะห์สำรองที่ไม่สามารถระบุตัวตนได้โดยตรง (เช่น UUID แบบสุ่มใช้เฉพาะวิเคราะห์) และเอาการแมปกับรหัสผู้ใช้จริงออกหรือล็อกไว้เมื่อหน้าต่างสิ้นสุด\n\nแยกตารางปฏิบัติการออกจากตารางรายงานเมื่อทำได้ ข้อมูลปฏิบัติการเปลี่ยนแปลงและถูกลบ ตารางรายงานควรเป็นสแน็ปชอตเพิ่มอย่างเดียวหรือค่ารวม\n\n### ระบุว่าจะเปลี่ยนอะไรหลังทำให้ไม่ระบุตัวตน\n\nการทำให้ไม่ระบุตัวตนมีผลตามมา จดสิ่งที่จะเปลี่ยนเพื่อทีมจะไม่ประหลาดใจ:\n\n- การขุดลงระดับผู้ใช้จะหยุดหลังวันที่กำหนด\n- เซ็กเมนต์ประวัติอาจกลายเป็น "ไม่ทราบ" หากลบแอตทริบิวต์\n- การลบซ้ำอาจเปลี่ยนถ้าลบอีเมลหรือโทรศัพท์\n- บางการตรวจสอบยังต้องการเวลาจับเวลาและไอดีที่ไม่ระบุบุคคล\n\nถ้าคุณสร้างใน AppMaster ให้ถือการทำให้ไม่ระบุตัวตนเป็นเวิร์กโฟลว์: เขียนค่ารวมก่อน ยืนยันผลรายงาน แล้วจึงทำการแทนค่าฟิลด์ในเร็กคอร์ดต้นทาง\n\n## ทีละขั้นตอน: นำ policy ไปสู่เวิร์กโฟลว์จริง\n\nนโยบายการเก็บรักษาทำงานได้เมื่อมันกลายเป็นพฤติกรรมซอฟต์แวร์ ปฏิบัติเหมือนฟีเจอร์อื่น: กำหนดอินพุต กำหนดการกระทำ และทำให้ผลมองเห็นได้\n\nเริ่มด้วยเมทริกซ์หน้าเดียว สำหรับแต่ละประเภทข้อมูล จดหน้าต่างการเก็บ ทริกเกอร์ และสิ่งที่จะเกิดขึ้นต่อไป (เก็บ อาร์ไคฟ์ ลบ ทำให้ไม่ระบุตัวตน) ถ้าคนอธิบายไม่ได้ในหนึ่งนาที มันจะไม่ถูกปฏิบัติ\n\nเพิ่มสถานะวงจรชีวิตชัดเจนเพื่อเร็กคอร์ดจะไม่ "หายไปอย่างลึกลับ" แอพส่วนใหญ่ใช้สามสถานะ: active, archived, pending delete เก็บสถานะบนเร็กคอร์ดเอง ไม่ใช่แค่ในสเปรดชีต\n\nลำดับการใช้งานเชิงปฏิบัติ:\n\n1. สร้างเมทริกซ์การเก็บรักษาและเก็บไว้ที่เข้าถึงได้สำหรับผลิตภัณฑ์ กฎหมาย และปฏิบัติการ\n2. เพิ่มฟิลด์วงจรชีวิต (สถานะและวันที่เช่น archived_at และ delete_after) และอัปเดตหน้าจอ/API ให้เคารพฟิลด์เหล่านี้\n3. ทำงานตามตารางเวลา (รันประจำวันเป็นเรื่องปกติ): งานหนึ่งอาร์ไคฟ์ อีกงานลบหรือทำให้ไม่ระบุตัวตนเมื่อถึงกำหนด\n4. เพิ่มเส้นทางข้อยกเว้น: ใครหยุดการลบ ได้กี่วัน และเหตุผลต้องบันทึก\n5. ทดสอบบนสำเนาที่คล้ายจริง แล้วเปรียบเทียบรายงานสำคัญ (การนับ ยอดรวม เฟันเนล) ก่อนและหลัง\n\nตัวอย่าง: ตั๋วซัพพอร์ตอาจอยู่ active 90 วัน จากนั้นย้ายไป archived 18 เดือน แล้วทำให้ไม่ระบุตัวตน เวิร์กโฟลว์ทำเครื่องหมายว่าอาร์ไคฟ์ ย้ายไฟล์แนบขนาดใหญ่ไปที่ที่เก็บถูกลง เก็บ ID และ timestamps ของตั๋ว และแทนชื่อ/อีเมลด้วยค่าที่ไม่ระบุตัวตน\n\nใน AppMaster สถานะวงจรชีวิตสามารถอยู่ใน Data Designer และตรรกะอาร์ไคฟ์/ลบรันเป็น Scheduled Business Processes เป้าหมายคือการรันซ้ำได้พร้อมบันทึกชัดเจนที่ตรวจสอบได้ง่าย\n\n## ความผิดพลาดทั่วไปที่ทำให้ข้อมูลหายหรือรายงานพัง\n\nความล้มเหลวส่วนใหญ่ไม่ได้มาจากการตั้งหน้าต่างผิด แต่เกิดเมื่อการลบแตะตารางผิด พลาดไม่ลบไฟล์ที่เกี่ยวข้อง หรือเปลี่ยนคีย์ที่รายงานพึ่งพา\n\nสถานการณ์ทั่วไป: ทีมซัพพอร์ตลบ "ตั๋วเก่า" แต่ลืมไฟล์แนบที่เก็บในตารางหรือสโตเรจแยก ต่อมา ผู้ตรวจสอบขอหลักฐานการคืนเงิน ข้อความตั๋วยังอยู่ แต่สกรีนช็อตหาย\n\nกับดักอื่นๆ:\n\n- ลบเร็กคอร์ดหลักแต่ทิ้งตารางข้างเคียง (ไฟล์แนบ ความเห็น บันทึกตรวจสอบ) ให้เป็นเด็กเสมือนไร้พ่อ\n- ลบเหตุการณ์ดิบที่การเงิน ความปลอดภัย หรือการปฏิบัติตามกฎยังต้องใช้ในการกระทบยอด\n- พึ่งพา soft delete ไปเรื่อยๆ ทำให้ฐานข้อมูลโตและข้อมูลที่คิดว่าลบยังปรากฏในการส่งออก\n- เปลี่ยนตัวระบุระหว่างการทำให้ไม่ระบุตัวตน (เช่น user_id) โดยไม่อัปเดตแดชบอร์ด join และคิวรีที่บันทึกไว้\n- ไม่มีเจ้าของข้อยกเว้นและ legal hold ทำให้คนข้ามกฎได้ไม่เป็นระบบ\n\nการแก้สองอย่างช่วยทีมส่วนใหญ่ ก่อนอื่น กำหนดคีย์การรายงานที่ไม่เปลี่ยน (เช่น internal account ID) และแยกจากฟิลด์ส่วนบุคคลที่อาจถูกทำให้ไม่ระบุตัวตนหรือถูกลบ ประการที่สอง ทำการลบเป็นเวิร์กโฟลว์ครบถ้วนที่เดินผ่านข้อมูลที่เกี่ยวข้องทั้งหมด รวมไฟล์และล็อก ใน AppMaster มักแมปกับ Business Process ที่เริ่มจากผู้ใช้หรือบัญชี รวบรวมการพึ่งพา แล้วลบหรือทำให้ไม่ระบุตัวตนตามลำดับปลอดภัย\n\nสุดท้าย ตัดสินใจว่าใครหยุดการลบเพราะ legal hold และบันทึกการหยุดอย่างไร ถ้าไม่มีเจ้าของข้อยกเว้น นโยบายจะถูกใช้ไม่สม่ำเสมอ\n\n## การตรวจสอบด่วนก่อนเปิดใช้งานใดๆ\n\nก่อนรันงานลบหรืออาร์ไคฟ์ ให้ทำเช็คลิสต์ความจริง ธรรมดาส่วนใหญ่ล้มเหลวเพราะไม่มีใครรู้ว่าใครเป็นเจ้าของข้อมูล อยู่ที่ไหน หรือรายงานพึ่งพาอย่างไร\n\nนโยบายการเก็บรักษาต้องมีความรับผิดชอบชัดเจนและแผนที่ทดสอบได้ ไม่ใช่แค่เอกสาร\n\n### เช็คลิสต์ก่อนเปิดใช้งาน\n\n- มอบเจ้าของให้แต่ละชุดข้อมูล (คนที่อนุมัติการเปลี่ยนแปลงและตอบคำถาม)\n- ยืนยันแต่ละหมวดมีหน้าต่างการเก็บและทริกเกอร์ (ตัวอย่าง: "90 วันหลังตั๋วปิด" หรือ "2 ปีหลังการล็อกอินล่าสุด")\n- พิสูจน์ว่าสามารถหาตัวเร็กคอร์ดเดียวกันได้ทุกที่ที่มันปรากฏ: ฐานข้อมูล ที่เก็บไฟล์ เอ็กซ์พอร์ต ล็อก คัดลอกวิเคราะห์ และแบ็กอัพ\n- ยืนยันว่าอาร์ไคฟ์ยังใช้ได้: เก็บฟิลด์ขั้นต่ำสำหรับการค้นหาและการ join (ID วันที่ สถานะ) และจดสิ่งที่จะทิ้ง\n- แน่ใจว่าคุณสามารถให้หลักฐานได้: อะไรถูกลบ/ทำให้ไม่ระบุตัวตน เมื่อไหร่ และกฎอะไรที่ใช้งาน\n\nวิธีตรวจสอบง่ายๆ คือ dry run: เอาชุดเล็กๆ (เช่น เคสลูกค้าหนึ่งราย) รันเวิร์กโฟลว์ในสภาพแวดล้อมทดสอบ แล้วเปรียบเทียบรายงานสำคัญก่อนและหลัง\n\n### รูปแบบ "หลักฐาน" ควรเป็นอย่างไร\n\nเก็บหลักฐานโดยไม่กลับคืนข้อมูลส่วนบุคคล:\n\n- บันทึกการรันงานพร้อมเวลาประทับ ชื่อกฎ และจำนวนเร็กคอร์ด\n- ตารางตรวจสอบคงอยู่ที่ไม่เปลี่ยนแปลงพร้อม ID เร็กคอร์ดและการกระทำที่ทำ (ลบหรือทำให้ไม่ระบุตัวตน)\n- รายการข้อยกเว้นสั้นๆ สำหรับสิ่งที่อยู่ใน legal hold\n- สแน็ปชอตรายงานที่แสดงเมตริกที่คุณคาดว่าจะคงที่\n\nถ้าคุณสร้างบน AppMaster การตรวจสอบเหล่านี้แมปตรงกับการใช้งาน: ฟิลด์การเก็บรักษาใน Data Designer งานตามตารางเวลาใน Business Process Editor และเอาต์พุตตรวจสอบที่ชัดเจน\n\n## ตัวอย่าง: แผนการเก็บรักษาสำหรับพอร์ทัลลูกค้าที่รายงานยังดี\n\nนึกภาพพอร์ทัลลูกค้าที่เก็บตั๋วซัพพอร์ต ใบแจ้งหนี้และการคืนเงิน และบันทึกกิจกรรมดิบ (ล็อกอิน การดูหน้า การเรียก API) เป้าหมายคือ ลดความเสี่ยงและค่าใช้จ่ายพื้นที่โดยไม่ทำให้การเรียกเก็บเงิน การตรวจสอบ หรือการรายงานแนวโน้มเสีย\n\nเริ่มด้วยการแยกข้อมูลที่ต้องเก็บกับข้อมูลที่ใช้แค่วันต่อวัน\n\nตารางการเก็บตัวอย่างที่ง่าย:\n\n- ตั๋วซัพพอร์ต: เก็บเนื้อหาเต็ม 18 เดือนหลังตั๋วปิด\n- ใบแจ้งหนี้และบันทึกการชำระ: เก็บ 7 ปี\n- บันทึกกิจกรรมดิบ: เก็บ 30 วัน\n- เหตุการณ์ตรวจสอบความปลอดภัย (การเปลี่ยนแปลงแอดมิน การอัปเดตสิทธิ): เก็บ 12 เดือน\n\nเพิ่มขั้นตอนอาร์ไคฟ์สำหรับตั๋วเก่า แทนที่จะเก็บทุกข้อความในตารางหลักตลอดไป ให้ย้ายตั๋วปิดที่เก่ากว่า 18 เดือนไปยังพื้นที่อาร์ไคฟ์พร้อมสรุปเล็กๆ ที่ค้นหาได้: รหัสตั๋ว วันที่ พื้นที่สินค้า แท็ก รหัสผลการแก้ปัญหา และตอนสั้นๆ ของบันทึกตัวแทน นั่นให้บริบทโดยไม่เก็บรายละเอียดส่วนบุคคลทั้งหมด\n\nสำหรับบัญชีที่ปิดแล้ว ให้เลือกทำให้ไม่ระบุตัวตนแทนการลบเมื่อคุณยังต้องการแนวโน้ม แทนที่ตัวระบุส่วนบุคคล (ชื่อ อีเมล ที่อยู่) ด้วยโทเค็นสุ่ม แต่ยังเก็บฟิลด์ที่ไม่ระบุตัวตน เช่น ประเภทแผนและยอดรวมรายเดือน เก็บเมตริกการใช้งานรวม (ผู้ใช้แอคทีฟต่อวัน ตั๋วต่อเดือน รายได้ต่อเดือน) ในตารางรายงานแยกต่างหากที่ไม่เก็บข้อมูลส่วนบุคคลเลย\n\nรายงานรายเดือนจะเปลี่ยน แต่ไม่ควรแย่ลงถ้าคุณวางแผนไว้:\n\n- แนวโน้มปริมาณตั๋วยังคงเพราะมาจากแท็กและรหัสการแก้ปัญหา ไม่ใช่ข้อความเต็ม\n- การรายงานรายได้คงที่เพราะใบแจ้งหนี้ยังอยู่\n- แนวโน้มการใช้งานระยะยาวมาจากค่ารวม ไม่ใช่บันทึกดิบ\n- โคฮอร์ตอาจย้ายจากการระบุตัวตนเป็นโทเค็นระดับบัญชี\n\nใน AppMaster ขั้นตอนอาร์ไคฟ์และการทำให้ไม่ระบุตัวตนสามารถรันเป็น Scheduled Business Processes เพื่อให้นโยบายทำงานแบบเดียวกันทุกครั้ง\n\n## ขั้นตอนถัดไป: เปลี่ยนนโยบายให้เป็นอัตโนมัติที่ทำซ้ำได้\n\nนโยบายการเก็บรักษาทำงานเมื่อคนปฏิบัติตามและระบบบังคับใช้มันสม่ำเสมอ เริ่มด้วยเมทริกซ์การเก็บรักษาง่ายๆ: แต่ละชุดข้อมูล เจ้าของ หน้าต่าง ทริกเกอร์ การกระทำถัดไป (อาร์ไคฟ์ ลบ ทำให้ไม่ระบุตัวตน) และการลงนามอนุมัติ ทบทวนกับกฎหมาย ความปลอดภัย การเงิน และทีมซัพพอร์ต\n\nอย่าอัตโนมัติทั้งหมดพร้อมกัน เลือกชุดข้อมูลหนึ่งแบบ end-to-end เช่น ตั๋วซัพพอร์ตหรือบันทึกล็อกอิน ทำเวิร์กโฟลว์ให้จริง รันสัปดาห์หนึ่ง แล้วยืนยันว่าการรายงานตรงตามที่ธุรกิจคาดหวัง จากนั้นขยายไปยังชุดข้อมูลถัดไปโดยใช้รูปแบบเดียวกัน\n\nทำให้อัตโนมัติสามารถสังเกตได้ การมอนิเตอร์พื้นฐานควรครอบคลุม:\n\n- ความล้มเหลวของงาน (อาร์ไคฟ์หรือลบรันและเสร็จหรือไม่)\n- การเติบโตของอาร์ไคฟ์ (แนวโน้มพื้นที่จัดเก็บ)\n- ค้างการลบ (รายการที่มีสิทธิ์แต่ยังไม่ถูกประมวลผล)\n- การเบนรายงาน (เมตริกสำคัญเปลี่ยนหลังการรัน)\n\nวางแผนส่วนที่ปรากฏต่อผู้ใช้ด้วย ตัดสินใจว่าผู้ใช้ขออะไรได้ (เอ็กซ์พอร์ต ลบ แก้ไข) ใครอนุมัติ และระบบทำอะไร ให้ซัพพอร์ตมีสคริปต์สั้นภายใน: ข้อมูลใดได้รับผล กระทั่งใช้เวลากี่วัน และอะไรกู้คืนไม่ได้หลังลบ\n\nถ้าต้องการทำโดยไม่เขียนโค้ดเอง AppMaster (appmaster.io) เหมาะสำหรับการอัตโนมัติการเก็บรักษาเพราะคุณสามารถโมเดลฟิลด์วงจรชีวิตใน Data Designer และรัน Scheduled Business Processes สำหรับการอาร์ไคฟ์และการทำให้ไม่ระบุตัวตนพร้อมบันทึกตรวจสอบ เริ่มจากชุดข้อมูลหนึ่ง ทำให้มันน่าเบื่อและเชื่อถือได้ แล้วทำซ้ำกับส่วนอื่นของแอพ