สวัสดีครับ Blog ตอนนี้น่าจะ Publish หลังจากที่ผ่านการตรวจรับจริงๆมาประมาณ 5-6 เดือนแล้วครับ ขอบันทึกอะไรเล็กน้อยๆ นิดนึงครับ
กรรมการตรวจรับ ?
- แล้วแต่องค์กรเลยครับ แต่ที่ผมเจอส่วนใหญ่จะคละกันหลายหน่วยงานครับ เช่น IT เจ้าของระบบ / IT กลาง / User ที่ใช้ระบบ
- User ที่ใช้ระบบ ดูเครื่อง Server ไม่เป็นต้องมาร่วมตรวจรับครับ เพื่อให้ถ่วงดุล
เตรียมตัวอย่างไร ?
- ทำเอกสาร Mapping กับแต่ละข้อของ TOR ให้เรียบร้อย
- เตรียมข้อมูลที่จำเป็นด้วย เพื่อให้การตรวจสะดวก และรวดเร็วครับ อาทิ เช่น วิธีการตรวจ หรือ ข้อมูล Capture มาจากเว็บ Console ของ Server แล้วครับ
- Data Sheet พกไปด้วยนะครับ ทำ Index และ Highlight ไว้ด้วยครับ
- เอาจอไปด้วยครับ เครื่อง Server บางตัวมันไม่มี Console หน้าเครื่องครับ ถ้าจะไปให้มุงๆด้วยกันหน้าเครื่องน่าจะลำบากครับ ถ้าเอาสาย Jump ตรงแล้ว แล้วต่อออกจอน่าจะดีกว่าครับ
เจออะไรแปลกไหม ?
- เจอครับ แอบไปถามเพื่อน ป.โท มาเค้าบอกว่า กฏหมายใหม่ในการตรวจรับมีผลตลอดชีวิต แม้ว่าจะลาออกไปแล้วก็ตามครับ
- พวกอะไรที่เป็น Hot Swap หมดเลย ทั้ง Power Supply หรือ แม้แต่ตัว SSD โดนบังคับให้ดึงออกมาครับ โดยให้ User ลองเปิดระบบค้างไว้ครับ
- Power Supply - ดึงออกมาได้ครับ รอดไม่มีปัญหา
- SSD - ดึงออกมาแล้วลุ้นเหมือนกันครับ ว่า Server Build Raid ใหม่สำเร็จไหมครับ แต่รอดมาได้ครับ (รอบหน้า ผมว่าจะสั่ง HDD เผื่อตรวจรับเลยครับ 555)
- บาง Feature ที่ทดสอบไม่ได้ เช่น พวก Switch กรรมการมีถามเหมือนกัน ว่าจะเปิด Feature นี้อย่างไร เอา Data Sheet ยันแล้ว แต่มีจะให้ลอง Config ตอนนั้นชี้แจงกันยาวครับ ว่ากระทบกับระบบหลักของลูกค้าเลยรอดมาได้
TOR กำกวม ตีความได้หลายแบบ หรือ ไม่มีใน TOR แต่ไม่มั่นใจ ?
- ปัญหาใหญ่เลยครับ เพราะ TOR มันเขียนวิธีปฏิบัติจริงเข้าไปตรงๆไม่ได้ เพื่อน ป.โท ที่ดูด้านนี้ บอกว่ามันเป็นศิลปะอย่างนึงเลยครับ T___T
- ตัวอย่างแรก มี Physical Server ที่ DC และ DR อย่างละ 1 เครื่อง และ Software X ต้องครอบคลุมการใช้งานทั้ง DC / DR มันมีคำถามว่าต้อง 1 (DC หรือ DR) หรือ 2 License (ทั้ง DC / DR) เพราะ เขียนคำว่าครอบคลุมครับ และตัว Software X เนี่ยมันมีความสามารถจัดการ Physical Server ได้ 1000 เครื่อง ++ อยู่แล้ว
- อธิบายไป อธิบายมาสุดท้ายบอกว่า อ้างอิงจากระบบอื่น โครงการอื่น เป็นวิธีการปฏิบัติจริง มันก็มีข้อดี และข้อเสียครับ
- ข้อดี ไม่ต้องคิดเยอะ เป็น Pattern ดี แต่ควรเขียนลงใน TOR ด้วย ไม่ใช่ลืม แล้วเอาแนวปฏิบัติมาอ้างอิงแทน
- ข้อเสีย องค์กรเสียเงินซื้อเพิ่ม ทั้งๆที่สามารถประหยัดงบประมาณได้ และจัดการได้สะดวกด้วย
- ตัวอย่างสอง ใน TOR ไม่ได้เขียน แต่บริษัทเป็นห่วงเลยซื้อ Support เพิ่มให้ แต่ด้วย Process ข้างในขององค์กรลูกค้านั้นล่าช้า ทำให้ Support ขาดไป 1 เดือน
- อธิบายไปว่าไม่มีใน TOR สุดท้าย กรรมการบอกไม่ยอมเซ็นรับ อ้าวววววววว ขอให้ซื้อ MA เพิ่มซะงั้น ช๊อคเลยครับ พอเข้าใจแล้ว ทำไมงานที่มี TOR มันต้องบวกอะไรพิเศษเยอะพอสมควรเลย เพราะ TOR ของราชการส่วนใหญ่เอาจริงๆ เขียนให้ผู้จ้างได้เปรียบมากๆ บางเรื่องเลยการเป็นอารมณ์ของกรรมการตรวจรับแทน ไม่นับเรื่องใต้โต๊ะนะครับ
- สุดท้าย ตัดสินใจซื้อเพิ่มครับ จะได้ตรวจรับผ่าน เพราะ เสียเวลากับ Process ข้างในพอสมควรแล้ว ถ้าโดนดึงตรงนี้อีกไม่คุ้มค่าปรับ (มันมีผลกับความน่าเชื่อถือองค์กร) ตรงนี้ต้องฝากคนเขียน TOR ครับ เขียนให้ชัด อย่างไรกี่ License ระบุจำนวน หรือ ขั้นต่ำก็ได้ครับ ถ้านับได้ หรือ ถ้ามีวิธีการปฏิบัติอะไร ควรเอา Policy ให้ผู้ประมูลร่วมตรวจสอบด้วยครับ สุดท้ายแล้วตัวลูกค้าเองจะได้ของที่ไม่จำเป็น หรือ แพงกว่าปกติครับ
