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

ปัญหาที่นโยบายการเก็บรักษาจริงๆ แก้ไข

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

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

นโยบายการเก็บรักษาเชิงปฏิบัติบาลานซ์การปฏิบัติงาน ข้อพิสูจน์ และการปกป้องลูกค้า:

• การปฏิบัติงาน: ผู้คนยังทำงานได้ตามปกติ
• ข้อพิสูจน์: คุณอธิบายการทำธุรกรรมย้อนหลังได้
• ลูกค้า: คุณไม่เก็บข้อมูลส่วนบุคคลนานเกินความจำเป็น

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

นโยบายคือส่วนหนึ่งเป็นกฎ ส่วนหนึ่งเป็นเวิร์กโฟลว์ และส่วนหนึ่งเป็นเครื่องมือ กฎอาจบอกว่า “เก็บตั๋วซัพพอร์ต 2 ปี” เวิร์กโฟลว์กำหนดความหมายเชิงปฏิบัติ: ย้ายตั๋วเก่าลงอาร์ไคฟ์ ทำให้ฟิลด์ลูกค้าไม่ระบุตัวตน และบันทึกสิ่งที่เกิดขึ้น เครื่องมือทำให้มันทำซ้ำได้และตรวจสอบได้

ถ้าคุณสร้างแอพบน AppMaster ให้มองการเก็บรักษาเป็นพฤติกรรมของผลิตภัณฑ์ ไม่ใช่การทำความสะอาดครั้งเดียว Scheduled Business Processes สามารถอาร์ไคฟ์ ลบ หรือทำให้ไม่ระบุตัวตนข้อมูลในแบบเดิมทุกครั้ง ทำให้การรายงานคงที่และผู้คนเชื่อถือข้อมูลได้

ข้อจำกัดที่ต้องเคลียร์ก่อนเลือกหน้าต่างเวลา

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

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

ข้อกำหนดยังเปลี่ยนตามประเทศและอุตสาหกรรม พอร์ทัลซัพพอร์ตของผู้ให้บริการด้านสุขภาพมีข้อจำกัดต่างจากเครื่องมือแอดมิน B2B แม้ในบริษัทเดียวกัน ผู้ใช้จากหลายประเทศก็อาจมีข้อกำหนดต่างกันสำหรับประเภทเร็กคอร์ดเดียวกัน

เขียนการตัดสินใจด้วยภาษาธรรมดาและมอบเจ้าของ “เก็บตั๋ว 24 เดือน” โดยเปล่าๆ ไม่พอ ระบุให้ชัดว่าจะรวมอะไร ยกเว้นอะไร และเกิดอะไรเมื่อหน้าต่างสิ้นสุด (อาร์ไคฟ์ ทำให้ไม่ระบุตัวตน ลบ) ตั้งคนหรือทีมรับผิดชอบเพื่อการอัปเดตไม่สะดุดเมื่อผลิตภัณฑ์หรือกฎหมายเปลี่ยน

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

ตัวอย่าง: เก็บบันทึกการเรียกเก็บเงิน 7 ปี เก็บตั๋ว 2 ปี และทำให้ฟิลด์โปรไฟล์ผู้ใช้ไม่ระบุตัวตนหลังปิดบัญชีโดยยังเก็บเมตริกรวมไว้ ใน AppMaster กฎที่เขียนเหล่านี้แมปได้ตรงกับกระบวนการตามตารางเวลาและการเข้าถึงตามบทบาท โดยลดการคาดเดาในภายหลัง

แม็ปข้อมูลตามประเภท ความอ่อนไหว และที่อยู่ของมัน

นโยบายการเก็บรักษามักล้มเหลวเมื่อทีมพูดว่า "เก็บ 2 ปี" โดยไม่รู้ว่า "มัน" คืออะไร สร้างแผนที่ข้อมูลง่ายๆ ที่คุณมี อย่าไล่หาความสมบูรณ์แบบ ตั้งเป้าให้หัวหน้าซัพพอร์ตและหัวหน้าการเงินเข้าใจตรงกัน

จัดประเภทตามประเภทและความอ่อนไหว

ชุดเริ่มต้นเชิงปฏิบัติได้แก่:

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

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

แม็ปว่ามันอยู่ที่ไหนและใครพึ่งพามัน

"อยู่ที่ไหน" มักมากกว่าแค่ฐานข้อมูลหลัก ให้จดตำแหน่งชัดเจน: ตารางฐานข้อมูล ที่เก็บไฟล์ บันทึกอีเมล/SMS เครื่องมือวิเคราะห์ หรือคลังข้อมูล และใครพึ่งพาชุดข้อมูลแต่ละชุด (ซัพพอร์ต เซลส์ การเงิน ผู้บริหาร) และความถี่การใช้งาน นั่นจะบอกว่าการลบกระทบอะไรบ้าง

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

ถ้าคุณสร้างด้วย AppMaster คุณสามารถจับสิ่งนี้ให้ตรงกับสิ่งที่ปรับใช้อยู่จริงโดยตรวจสอบโมเดลใน Data Designer การจัดการไฟล์ และการเชื่อมต่อที่เปิดใช้งาน

เมื่อแผนที่มีอยู่ การเก็บรักษากลายเป็นชุดการตัดสินใจเล็กๆ ชัดเจน แทนการเดาครั้งใหญ่

วิธีตั้งหน้าต่างการเก็บรักษาที่คนปฏิบัติตามได้

หน้าต่างใช้ได้ก็ต่อเมื่อมันอธิบายง่ายและใช้ได้ง่าย หลายทีมทำได้ดีด้วยชั้นง่ายๆ ที่ตรงกับการใช้งาน: ร้อน (ใช้ทุกวัน), อุ่น (ใช้เป็นครั้งคราว), เย็น (เก็บเป็นหลักฐาน) แล้วค่อยลบหรือทำให้ไม่ระบุตัวตน ชั้นเหล่านี้เปลี่ยนนโยบายเป็นกิจวัตร

ตั้งหน้าต่างตามหมวด ไม่ใช่ตัวเลขรวมหนึ่งค่า ใบแจ้งหนี้มักต้องเก็บนานเพื่อตรวจสอบภาษี ส่วนบทสนทนาซัพพอร์ตมักหมดคุณค่าเร็ว

ยังต้องตัดสินใจว่าจุดเริ่มนับคืออะไร "เก็บ 2 ปี" จะไม่มีความหมายถ้าไม่กำหนดว่า "2 ปีนับจากอะไร" เลือกทริกเกอร์หนึ่งอย่างต่อหมวด เช่น วันที่สร้าง กิจกรรมสุดท้าย วันที่ปิดตั๋ว หรือการปิดบัญชี ถ้าทริกเกอร์ต่างกันโดยไม่มีกฎชัด ทีมจะเดาและการเก็บจะเบี่ยงเบน

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

เก็บกฎสุดท้ายสั้นและทดสอบได้:

• บทสนทนาซัพพอร์ต: ทำให้ไม่ระบุตัวตน 6 เดือนหลังข้อความสุดท้าย เว้นแต่จะอยู่ใน legal hold
• ลีดการตลาด: ลบ 12 เดือนหลังการเคลื่อนไหวครั้งสุดท้ายถ้าไม่มีสัญญา
• บัญชีลูกค้า: ลบ 30 วันหลังปิดบัญชี; เก็บใบแจ้งหนี้ 7 ปี
• บันทึกความปลอดภัย: เก็บร้อน 90 วัน เก็บเย็น 12 เดือนเพื่อสืบสวน
• เร็กคอร์ดใด ๆ ที่ถูกตั้งค่า legal_hold=true: ห้ามลบจนกว่าจะยกเลิก

กลยุทธ์อาร์ไคฟ์ที่ทำให้ข้อมูลยังใช้ได้และถูกลง

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

แอพส่วนใหญ่ต้องการทั้งคู่ แบ็กอัพถี่และครอบคลุม ในขณะที่อาร์ไคฟ์เลือกเฉพาะและควบคุม และปกติจะเรียกคืนเฉพาะสิ่งที่ต้องการจริงๆ

เลือกที่เก็บที่ถูกกว่า แต่ยังค้นหาได้

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

ก่อนเลือกฟอร์แมต ให้กำหนดความหมาย "ค้นหาได้" ในธุรกิจของคุณ ซัพพอร์ตอาจต้องค้นจากอีเมลหรือรหัสตั๋ว การเงินอาจต้องรวมตามเดือน การตรวจสอบอาจต้องติดตามตามรหัสคำสั่ง

ตัดสินใจว่าจะอาร์ไคฟ์อะไร: เร็กคอร์ดเต็มหรือสรุป

เร็กคอร์ดเต็มเก็บรายละเอียดแต่ราคาแพงและเพิ่มความเสี่ยงด้านความเป็นส่วนตัว สรุป (ยอดรวมต่อเดือน จำนวน เหตุการณ์สำคัญ) ถูกกว่าและมักเพียงพอสำหรับรายงาน

แนวทางปฏิบัติ:

• อาร์ไคฟ์เร็กคอร์ดเต็มสำหรับออบเจ็กต์ที่สำคัญต่อการตรวจสอบ (ใบแจ้งหนี้ คืนเงิน บันทึกการเข้าใช้)
• อาร์ไคฟ์สรุปสำหรับเหตุการณ์ปริมาณมาก (คลิก การดูหน้า พิงก์เซนเซอร์)
• เก็บชิ้นอ้างอิงเล็กๆ ในสตอเรจร้อน (มัก 30–90 วันล่าสุด)

วางแผนฟิลด์ดัชนีล่วงหน้า เช่น รหัสหลัก รหัสผู้ใช้/ลูกค้า บักเก็ตวันที่ (เดือน) ภูมิภาค และสถานะ หากไม่มีฟิลด์เหล่านี้ ข้อมูลอาร์ไคฟ์อยู่แต่เรียกคืนยาก

กำหนดกฎการเรียกคืนด้วย: ใครขอ restore ใครอนุมัติ ที่ไหนจะวางข้อมูลที่คืน และเวลาที่คาดหวัง การคืนอาจช้าโดยตั้งใจถ้านั่นลดความเสี่ยง แต่ต้องทำนายได้

การลบกับการทำให้ไม่ระบุตัวตน: เลือกแนวทางที่เหมาะสม

นโยบายการเก็บมักบังคับให้เลือก: ลบเร็กคอร์ด หรือเก็บไว้แต่เอารายละเอียดส่วนบุคคลออก ทั้งสองมีเหตุผลและแก้ปัญหาต่างกัน

การลบแบบ hard delete เอาเร็กคอร์ดออกจริง เหมาะเมื่อไม่มีเหตุผลทางกฎหมายหรือธุรกิจที่จะเก็บและการเก็บทำให้เกิดความเสี่ยง เช่น บทสนทนาเก่าที่มีรายละเอียดอ่อนไหว

การลบแบบ soft delete เก็บแถวไว้แต่ทำเครื่องหมายว่าลบ (มักมี deleted_at) และซ่อนจากหน้าจอและ API ปกติ เหมาะเมื่อผู้ใช้คาดว่าจะกู้คืน หรือระบบดาวน์สตรีมอาจยังอ้างอิง เร็กคอร์ด soft-deleted ยังคงอยู่ กินพื้นที่ และอาจหลุดผ่านการส่งออกถ้าไม่ระวัง

การทำให้ไม่ระบุตัวตนเก็บเหตุการณ์หรือการทำธุรกรรมไว้แต่เอาหรือแทนที่ค่าส่วนบุคคล วิธีที่ทำถูกต้องไม่สามารถย้อนกลับได้ ส่วน pseudonymization คือแทนตัวระบุด้วยโทเค็นและเก็บแผนผังแยกต่างหาก ซึ่งช่วยสืบสวนแต่ไม่เท่าการไม่ระบุตัวตนจริงๆ

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

คุณยังต้องมีหลักฐานว่าการลบเกิดขึ้น เก็บใบเสร็จการลบง่ายๆ: อะไรถูกลบ/ทำให้ไม่ระบุตัวตน เมื่อไหร่ โฟลว์ไหนรัน และสำเร็จหรือไม่ ใน AppMaster สิ่งนี้อาจเป็น Business Process ที่เขียนบันทึกตรวจสอบเมื่องานเสร็จ

รักษาค่าการรายงานขณะเอาข้อมูลส่วนบุคคลออก

รายงานพังเมื่อคุณลบหรือทำให้ไม่ระบุตัวตนเร็กคอร์ดที่แดชบอร์ดคาดว่าจะ join ข้ามเวลา ก่อนเปลี่ยนอะไร ให้จดเมตริกที่ต้องคงเทียบเดือนไปเดือนไว้ มิฉะนั้นคุณจะมานั่งดีบั๊กว่า "ทำไมกราฟปีที่แล้วเปลี่ยนไป?" ทีหลัง

เริ่มด้วยรายการเมตริกสั้นๆ ที่ต้องเที่ยงตรง:

• รายได้และการคืนเงินตามวัน/สัปดาห์/เดือน
• การใช้งานผลิตภัณฑ์: ผู้ใช้งานแอคทีฟ เหตุการณ์ที่นับ การรับเอาฟีเจอร์
• เมตริก SLA: เวลาในการตอบ เวลาแก้ไข ความพร้อมให้บริการ
• อัตราเฟันเนลและการแปลง
• ปริมาณซัพพอร์ต: ตั๋ว หมวดหมู่ อายุคงค้าง

จากนั้นออกแบบสิ่งที่จะเก็บเพื่อรายงานโดยไม่ต้องใช้ตัวระบุส่วนบุคคล วิธีที่ปลอดภัยคือการทำการรวม (aggregation) แทนการเก็บแถวดิบตลอดไป เก็บยอดรวมรายวัน โคฮอร์ตรายสัปดาห์ และการนับที่ไม่สามารถสืบกลับเป็นบุคคลได้ ตัวอย่าง: เก็บ "ตั๋วที่สร้างต่อวันต่อหมวด" และ "ค่าเฉลี่ยเวลาตอบครั้งแรกต่อสัปดาห์" แม้จะลบเนื้อหาเดิมก็ยังได้ข้อมูลแนวโน้ม

เก็บคีย์วิเคราะห์ที่คงที่โดยไม่เก็บตัวตน

รายงานบางอย่างยังต้องมีวิธีกลุ่มพฤติกรรมข้ามเวลา ใช้คีย์วิเคราะห์สำรองที่ไม่สามารถระบุตัวตนได้โดยตรง (เช่น UUID แบบสุ่มใช้เฉพาะวิเคราะห์) และเอาการแมปกับรหัสผู้ใช้จริงออกหรือล็อกไว้เมื่อหน้าต่างสิ้นสุด

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

ระบุว่าจะเปลี่ยนอะไรหลังทำให้ไม่ระบุตัวตน

การทำให้ไม่ระบุตัวตนมีผลตามมา จดสิ่งที่จะเปลี่ยนเพื่อทีมจะไม่ประหลาดใจ:

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

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

ทีละขั้นตอน: นำ policy ไปสู่เวิร์กโฟลว์จริง

นโยบายการเก็บรักษาทำงานได้เมื่อมันกลายเป็นพฤติกรรมซอฟต์แวร์ ปฏิบัติเหมือนฟีเจอร์อื่น: กำหนดอินพุต กำหนดการกระทำ และทำให้ผลมองเห็นได้

เริ่มด้วยเมทริกซ์หน้าเดียว สำหรับแต่ละประเภทข้อมูล จดหน้าต่างการเก็บ ทริกเกอร์ และสิ่งที่จะเกิดขึ้นต่อไป (เก็บ อาร์ไคฟ์ ลบ ทำให้ไม่ระบุตัวตน) ถ้าคนอธิบายไม่ได้ในหนึ่งนาที มันจะไม่ถูกปฏิบัติ

เพิ่มสถานะวงจรชีวิตชัดเจนเพื่อเร็กคอร์ดจะไม่ "หายไปอย่างลึกลับ" แอพส่วนใหญ่ใช้สามสถานะ: active, archived, pending delete เก็บสถานะบนเร็กคอร์ดเอง ไม่ใช่แค่ในสเปรดชีต

ลำดับการใช้งานเชิงปฏิบัติ:

1. สร้างเมทริกซ์การเก็บรักษาและเก็บไว้ที่เข้าถึงได้สำหรับผลิตภัณฑ์ กฎหมาย และปฏิบัติการ
2. เพิ่มฟิลด์วงจรชีวิต (สถานะและวันที่เช่น archived_at และ delete_after) และอัปเดตหน้าจอ/API ให้เคารพฟิลด์เหล่านี้
3. ทำงานตามตารางเวลา (รันประจำวันเป็นเรื่องปกติ): งานหนึ่งอาร์ไคฟ์ อีกงานลบหรือทำให้ไม่ระบุตัวตนเมื่อถึงกำหนด
4. เพิ่มเส้นทางข้อยกเว้น: ใครหยุดการลบ ได้กี่วัน และเหตุผลต้องบันทึก
5. ทดสอบบนสำเนาที่คล้ายจริง แล้วเปรียบเทียบรายงานสำคัญ (การนับ ยอดรวม เฟันเนล) ก่อนและหลัง

ตัวอย่าง: ตั๋วซัพพอร์ตอาจอยู่ active 90 วัน จากนั้นย้ายไป archived 18 เดือน แล้วทำให้ไม่ระบุตัวตน เวิร์กโฟลว์ทำเครื่องหมายว่าอาร์ไคฟ์ ย้ายไฟล์แนบขนาดใหญ่ไปที่ที่เก็บถูกลง เก็บ ID และ timestamps ของตั๋ว และแทนชื่อ/อีเมลด้วยค่าที่ไม่ระบุตัวตน

ใน AppMaster สถานะวงจรชีวิตสามารถอยู่ใน Data Designer และตรรกะอาร์ไคฟ์/ลบรันเป็น Scheduled Business Processes เป้าหมายคือการรันซ้ำได้พร้อมบันทึกชัดเจนที่ตรวจสอบได้ง่าย

ความผิดพลาดทั่วไปที่ทำให้ข้อมูลหายหรือรายงานพัง

ความล้มเหลวส่วนใหญ่ไม่ได้มาจากการตั้งหน้าต่างผิด แต่เกิดเมื่อการลบแตะตารางผิด พลาดไม่ลบไฟล์ที่เกี่ยวข้อง หรือเปลี่ยนคีย์ที่รายงานพึ่งพา

สถานการณ์ทั่วไป: ทีมซัพพอร์ตลบ "ตั๋วเก่า" แต่ลืมไฟล์แนบที่เก็บในตารางหรือสโตเรจแยก ต่อมา ผู้ตรวจสอบขอหลักฐานการคืนเงิน ข้อความตั๋วยังอยู่ แต่สกรีนช็อตหาย

กับดักอื่นๆ:

• ลบเร็กคอร์ดหลักแต่ทิ้งตารางข้างเคียง (ไฟล์แนบ ความเห็น บันทึกตรวจสอบ) ให้เป็นเด็กเสมือนไร้พ่อ
• ลบเหตุการณ์ดิบที่การเงิน ความปลอดภัย หรือการปฏิบัติตามกฎยังต้องใช้ในการกระทบยอด
• พึ่งพา soft delete ไปเรื่อยๆ ทำให้ฐานข้อมูลโตและข้อมูลที่คิดว่าลบยังปรากฏในการส่งออก
• เปลี่ยนตัวระบุระหว่างการทำให้ไม่ระบุตัวตน (เช่น user_id) โดยไม่อัปเดตแดชบอร์ด join และคิวรีที่บันทึกไว้
• ไม่มีเจ้าของข้อยกเว้นและ legal hold ทำให้คนข้ามกฎได้ไม่เป็นระบบ

การแก้สองอย่างช่วยทีมส่วนใหญ่ ก่อนอื่น กำหนดคีย์การรายงานที่ไม่เปลี่ยน (เช่น internal account ID) และแยกจากฟิลด์ส่วนบุคคลที่อาจถูกทำให้ไม่ระบุตัวตนหรือถูกลบ ประการที่สอง ทำการลบเป็นเวิร์กโฟลว์ครบถ้วนที่เดินผ่านข้อมูลที่เกี่ยวข้องทั้งหมด รวมไฟล์และล็อก ใน AppMaster มักแมปกับ Business Process ที่เริ่มจากผู้ใช้หรือบัญชี รวบรวมการพึ่งพา แล้วลบหรือทำให้ไม่ระบุตัวตนตามลำดับปลอดภัย

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

การตรวจสอบด่วนก่อนเปิดใช้งานใดๆ

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

นโยบายการเก็บรักษาต้องมีความรับผิดชอบชัดเจนและแผนที่ทดสอบได้ ไม่ใช่แค่เอกสาร

เช็คลิสต์ก่อนเปิดใช้งาน

• มอบเจ้าของให้แต่ละชุดข้อมูล (คนที่อนุมัติการเปลี่ยนแปลงและตอบคำถาม)
• ยืนยันแต่ละหมวดมีหน้าต่างการเก็บและทริกเกอร์ (ตัวอย่าง: "90 วันหลังตั๋วปิด" หรือ "2 ปีหลังการล็อกอินล่าสุด")
• พิสูจน์ว่าสามารถหาตัวเร็กคอร์ดเดียวกันได้ทุกที่ที่มันปรากฏ: ฐานข้อมูล ที่เก็บไฟล์ เอ็กซ์พอร์ต ล็อก คัดลอกวิเคราะห์ และแบ็กอัพ
• ยืนยันว่าอาร์ไคฟ์ยังใช้ได้: เก็บฟิลด์ขั้นต่ำสำหรับการค้นหาและการ join (ID วันที่ สถานะ) และจดสิ่งที่จะทิ้ง
• แน่ใจว่าคุณสามารถให้หลักฐานได้: อะไรถูกลบ/ทำให้ไม่ระบุตัวตน เมื่อไหร่ และกฎอะไรที่ใช้งาน

วิธีตรวจสอบง่ายๆ คือ dry run: เอาชุดเล็กๆ (เช่น เคสลูกค้าหนึ่งราย) รันเวิร์กโฟลว์ในสภาพแวดล้อมทดสอบ แล้วเปรียบเทียบรายงานสำคัญก่อนและหลัง

รูปแบบ "หลักฐาน" ควรเป็นอย่างไร

เก็บหลักฐานโดยไม่กลับคืนข้อมูลส่วนบุคคล:

• บันทึกการรันงานพร้อมเวลาประทับ ชื่อกฎ และจำนวนเร็กคอร์ด
• ตารางตรวจสอบคงอยู่ที่ไม่เปลี่ยนแปลงพร้อม ID เร็กคอร์ดและการกระทำที่ทำ (ลบหรือทำให้ไม่ระบุตัวตน)
• รายการข้อยกเว้นสั้นๆ สำหรับสิ่งที่อยู่ใน legal hold
• สแน็ปชอตรายงานที่แสดงเมตริกที่คุณคาดว่าจะคงที่

ถ้าคุณสร้างบน AppMaster การตรวจสอบเหล่านี้แมปตรงกับการใช้งาน: ฟิลด์การเก็บรักษาใน Data Designer งานตามตารางเวลาใน Business Process Editor และเอาต์พุตตรวจสอบที่ชัดเจน

ตัวอย่าง: แผนการเก็บรักษาสำหรับพอร์ทัลลูกค้าที่รายงานยังดี

นึกภาพพอร์ทัลลูกค้าที่เก็บตั๋วซัพพอร์ต ใบแจ้งหนี้และการคืนเงิน และบันทึกกิจกรรมดิบ (ล็อกอิน การดูหน้า การเรียก API) เป้าหมายคือ ลดความเสี่ยงและค่าใช้จ่ายพื้นที่โดยไม่ทำให้การเรียกเก็บเงิน การตรวจสอบ หรือการรายงานแนวโน้มเสีย

เริ่มด้วยการแยกข้อมูลที่ต้องเก็บกับข้อมูลที่ใช้แค่วันต่อวัน

ตารางการเก็บตัวอย่างที่ง่าย:

• ตั๋วซัพพอร์ต: เก็บเนื้อหาเต็ม 18 เดือนหลังตั๋วปิด
• ใบแจ้งหนี้และบันทึกการชำระ: เก็บ 7 ปี
• บันทึกกิจกรรมดิบ: เก็บ 30 วัน
• เหตุการณ์ตรวจสอบความปลอดภัย (การเปลี่ยนแปลงแอดมิน การอัปเดตสิทธิ): เก็บ 12 เดือน

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

สำหรับบัญชีที่ปิดแล้ว ให้เลือกทำให้ไม่ระบุตัวตนแทนการลบเมื่อคุณยังต้องการแนวโน้ม แทนที่ตัวระบุส่วนบุคคล (ชื่อ อีเมล ที่อยู่) ด้วยโทเค็นสุ่ม แต่ยังเก็บฟิลด์ที่ไม่ระบุตัวตน เช่น ประเภทแผนและยอดรวมรายเดือน เก็บเมตริกการใช้งานรวม (ผู้ใช้แอคทีฟต่อวัน ตั๋วต่อเดือน รายได้ต่อเดือน) ในตารางรายงานแยกต่างหากที่ไม่เก็บข้อมูลส่วนบุคคลเลย

รายงานรายเดือนจะเปลี่ยน แต่ไม่ควรแย่ลงถ้าคุณวางแผนไว้:

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

ใน AppMaster ขั้นตอนอาร์ไคฟ์และการทำให้ไม่ระบุตัวตนสามารถรันเป็น Scheduled Business Processes เพื่อให้นโยบายทำงานแบบเดียวกันทุกครั้ง

ขั้นตอนถัดไป: เปลี่ยนนโยบายให้เป็นอัตโนมัติที่ทำซ้ำได้

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

อย่าอัตโนมัติทั้งหมดพร้อมกัน เลือกชุดข้อมูลหนึ่งแบบ end-to-end เช่น ตั๋วซัพพอร์ตหรือบันทึกล็อกอิน ทำเวิร์กโฟลว์ให้จริง รันสัปดาห์หนึ่ง แล้วยืนยันว่าการรายงานตรงตามที่ธุรกิจคาดหวัง จากนั้นขยายไปยังชุดข้อมูลถัดไปโดยใช้รูปแบบเดียวกัน

ทำให้อัตโนมัติสามารถสังเกตได้ การมอนิเตอร์พื้นฐานควรครอบคลุม:

• ความล้มเหลวของงาน (อาร์ไคฟ์หรือลบรันและเสร็จหรือไม่)
• การเติบโตของอาร์ไคฟ์ (แนวโน้มพื้นที่จัดเก็บ)
• ค้างการลบ (รายการที่มีสิทธิ์แต่ยังไม่ถูกประมวลผล)
• การเบนรายงาน (เมตริกสำคัญเปลี่ยนหลังการรัน)

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

ถ้าต้องการทำโดยไม่เขียนโค้ดเอง AppMaster (appmaster.io) เหมาะสำหรับการอัตโนมัติการเก็บรักษาเพราะคุณสามารถโมเดลฟิลด์วงจรชีวิตใน Data Designer และรัน Scheduled Business Processes สำหรับการอาร์ไคฟ์และการทำให้ไม่ระบุตัวตนพร้อมบันทึกตรวจสอบ เริ่มจากชุดข้อมูลหนึ่ง ทำให้มันน่าเบื่อและเชื่อถือได้ แล้วทำซ้ำกับส่วนอื่นของแอพ