Human Error แหก แหวก ผ่าทะลุกฏเกณฑ์

วันนี้ได้ไป Stand by เพื่อเอา Program ขึ้น Production โดยก่อนที่จะมาถึงด่านนี้ได้ ก็ต้องผ่าน

• การ Test อย่างหนักหน่วงจาก User
• การทดสอบ Package ของระบบงาน
• การทดสอบ Script DB บน AIX ซึ่งเป็น Environment ที่ใกล้เคียงกับ Production มากที่สุด
• การ Upgrade ทำโดย IT ของ Site ลูกค้า ไม่ให้บริษัทมายุ่ง กันข้อมูลของธนาคารรั่วไหล

ทั้งหมดนี้ดูดีครับ แต่ใช้งานจริงหละ

เมื่อถึงวันจริง ระหว่างที่ผมนั่งช่วย User Map หัว GL เพื่อส่งออกไปยังระบบ SAP ในวันรุ่งขึ้น แต่น้องที่ Stand by อยู่ โทรมาแจ้งว่า

แย่แล้วววว รัน Script ผิด Version

ฝ่าย IT ของ Site ลูกค้า

หยิบแผ่น 8.4.0.6 มารัน แทนที่จะเป็น 8.4.1.6

ซวยครับ แพลนที่จะกลับบ้านเร็วๆ หมดกัลลล (รอบก่อน IT ของ Site ลูกค้า ใส่ Password ผิดจนระบบ Lock) ผมรีบกลับมาดูความเสียหายครับ โดยพวกว่ามี 4 ส่วนที่โดนครับ

• GL-SAP
• BOT DMS
• พวก Lookup ของระบบ
• Master Company ครับ

สำหรับการแก้ปัญหานั้น ผมใช่วิธี ซ่อม Data ครับ เนื่องจาก

• User ที่ใช้ระบบ ก็ไม่คาดฝันว่าจะเกิดเหตุการณ์นี้ขึ้น เลยไม่ได้ออกรายงานเก็บไว้
• IT ของ Site ลูกค้า ไม่อยาก Restore DB เอง จากตัว Backup ทั้งๆ ที่หยิบแผ่นผิดเอง
• เท่าที่ผมสำรวจความเสียหายไม่เยอะครับ บาง Module ยังไม่ใช้งานจริงครับ ใช้วันรุ่งขึ้น ฮ่าๆ

สิ่งที่อยากเตือน สำหรับการจัดการ Script ขึ้นระบบ Production

• PK (Primary Key) สำคัญมากๆทุก Table ต้องมี เวลารัน Script INSERT ซ้ำ มันจะได้แจ้ง Error
• คำสั่ง Update ID ที่เคยรันไปแล้วใน Production ไม่จำเป็น อย่าไปเปลี่ยน ID ใหม่ครับ
• คำสั่ง Update ข้อมูล ไม่จำเป็นอย่าใช้ พยายามเลี่ยงเป็น Delete และ Insert ใหม่แทน (แต่อย่าไปยุ่งกับ Transaction นะครับ)
• เก็บ log การรัน Script
• สำหรับ DB2 ที่มีทำ HADR ไว้ เวลาแก้อะไร ใช้คำสั่งที่มีการเก็บ Transaction Log นะครับ อย่างการซ่อมข้อมูล Mapping ผมใช้จาก DB UAT db2Move Import ยัดเข้าไปเลยครับ ห้ามใช้คำสั่ง Load นะครับ
• และ มีสติ

ท้ายสุดแล้ว

Policy ดี | ระบบ ดี แต่ Human Error มันแหกได้ทุกข้อจำกัดครับ

ตั้งสติก่อน Start ครับ ^___^