Configuration Drift เมื่อค่าที่ใช้อยู่ไม่ตรงกับเอกสาร
เว็บยังทำงาน แต่ค่าบนเครื่องไม่ตรงกับไฟล์ที่เก็บไว้ ชวนทีมเล็กเทียบส่วนต่าง หาที่มาของการแก้ และตัดสินใจว่าจะเก็บหรือย้อนกลับ ก่อน deploy ทับของที่จำเป็น
ระบบที่ยังเปิดใช้งานได้ อาจตั้งค่าไม่เหมือนวันที่เราบันทึกคู่มือไว้แล้วครับ ความต่างที่ค่อย ๆ สะสมนี้เรียกว่า Configuration Drift เช่น มีคนแก้ค่าบนเครื่องระหว่างแก้ปัญหา แต่ไฟล์ที่ใช้ติดตั้งรอบถัดไปยังเป็นชุดเก่า พอ deploy ใหม่ การแก้ที่ทำให้ระบบใช้งานได้ก็หายไปด้วย
เรื่องนี้ทำให้ทีมเล็กต้องตัดสินใจว่าค่าที่ต่างควรเก็บไว้หรือย้อนกลับ การทำให้ทุกอย่างตรงกับเอกสารทันทีอาจพาปัญหาเดิมกลับมา ส่วนการแก้เอกสารตามหน้าจอทั้งหมดก็อาจรับค่าที่ไม่มีใครตรวจมาเป็นมาตรฐาน ผมจึงจะเริ่มจากเก็บหลักฐานของค่าที่ใช้อยู่ แล้วเทียบเฉพาะส่วนที่กระทบงานสำคัญก่อน สิ่งที่อยากได้คือรู้ว่าระบบควรอยู่ในสภาพไหน และเปลี่ยนไปถึงสภาพนั้นได้โดยมีทางกลับ
ลองนึกถึงเว็บที่ลูกค้าใช้ส่งไฟล์งาน มีตัวกลางรับการเชื่อมต่อก่อนส่งเข้าแอป หรือ reverse proxy และมีไฟล์ตั้งค่าที่ทีมเก็บไว้ สมมติว่าระหว่างแก้ปัญหาอัปโหลดไฟล์ มีการเพิ่มขนาดไฟล์ที่รับได้บนตัวกลาง แต่ไม่ได้บันทึกกลับลงไฟล์อ้างอิง ตัวอย่างนี้ใช้ประกอบการคิด ไม่ได้หมายความว่าเคยเกิดกับลูกค้าของผม คำถามที่จะตามต่อคือควรเก็บค่าใหม่ที่ลูกค้าใช้งานได้แล้ว หรือกลับไปใช้ค่าเดิมในเอกสาร
ชุดอ้างอิงต้องมีคนยืนยันก่อน
ก่อนเปิดโปรแกรมหาความต่าง ผมอยากรู้ว่าไฟล์ไหนเป็นชุดที่ทีมตกลงใช้จริง ชื่ออย่าง final, final-new หรือ final-จริง ๆ ไม่ได้ช่วยเท่าไรถ้าไม่มีใครตอบว่ามันมาจากระบบไหน เก็บเมื่อไร และใครตรวจแล้ว ไฟล์ที่เพิ่ง export จากเครื่องบอกสภาพที่พบได้ดี แต่ยังไม่ได้บอกว่าสภาพนั้นเป็นสิ่งที่เราต้องการ
ชุดค่าที่ผ่านการตรวจและตกลงให้ใช้อ้างอิงเรียกว่า baseline ตาม นิยามของ NIST มันเป็นฐานสำหรับการสร้างหรือเปลี่ยนระบบต่อไป สำหรับทีมเล็ก ผมจะไม่เริ่มด้วยการซื้อเครื่องมือใหม่เพื่อให้ได้คำนี้ แต่เลือกบริการเดียว ระบุชุดค่า วันที่ตรวจ และคนที่มีอำนาจตัดสินใจว่าค่านี้เหมาะกับงานที่รองรับหรือไม่
เว็บรับไฟล์ตัวอย่างควรมีขอบเขตที่มองเห็นได้ เช่น ค่ารับไฟล์ของตัวกลางกับของแอป รุ่นซอฟต์แวร์ที่ใช้ตีความค่า และแหล่งที่ deploy ดึงไฟล์ไป ถ้าตรวจเฉพาะตัวกลางแล้วแอปรับไฟล์ใหญ่ไม่ได้ ปัญหาก็ยังอยู่ การเลือกขอบเขตจึงเริ่มจากเส้นทางส่งไฟล์จริง ไม่ใช่เลือกเฉพาะไฟล์ที่ export ง่าย
รายละเอียดของ credential หรือ token อาจติดมากับไฟล์ตั้งค่าได้ ผมจะเก็บชุดเต็มในพื้นที่ที่จำกัดสิทธิ์ ส่วนบันทึกที่ใช้คุยกันแสดงชื่อรายการและส่วนต่างที่ปิดข้อมูลลับแล้ว การนำ config ไปเก็บใน Git ช่วยเห็นประวัติ แต่ไม่ควรใส่ secret ลงไปเพื่อให้ประวัติ “ครบ” และการมีประวัติก็ยังไม่ยืนยันว่าค่านั้นถูกนำไปใช้บนเครื่องจริง
ส่วนต่างหนึ่งบรรทัดอาจมีเหตุผลหลายแบบ
เมื่อมีชุดอ้างอิงแล้ว จึงค่อยเก็บค่าปัจจุบันพร้อมแหล่งกับเวลาที่ตรวจ เปรียบเทียบสิ่งเดียวกันในสภาพแวดล้อมเดียวกัน ถ้าเอาค่าของเครื่องทดสอบมาเทียบ production หรือเทียบไฟล์ก่อนระบบแทนค่าจาก environment กับค่าที่ใช้งานหลังแทนแล้ว เราอาจสร้างงานแก้จากความต่างที่ตั้งใจให้มีอยู่ตั้งแต่แรก
ในเว็บตัวอย่าง การเพิ่มขนาดไฟล์อาจเป็นการแก้ที่จำเป็นต่อธุรกิจ อาจเป็นการทดลองที่ลืมถอน หรืออาจเป็นค่าที่เปลี่ยนโดยไม่มีสิทธิ์ก็ได้ ผมจะยังไม่สรุปจากส่วนต่างบรรทัดเดียวว่าเป็นการโจมตี ย้อนดูงานแจ้งปัญหา ประวัติ deploy และบันทึกการแก้ก่อน หากหลักฐานไม่พอ ก็เขียนว่าไม่ทราบที่มา แล้วจัดการความไม่แน่ใจนั้นตามผลกระทบของค่า
สิ่งที่ต้องแยกอีกอย่างคือค่าในไฟล์กับค่าที่โปรแกรมกำลังใช้ บางระบบต้อง reload หรือ restart จึงจะอ่านค่าใหม่ บางค่าถูกทับจากที่อื่น ภาพหน้าจอว่าแก้ไฟล์แล้วจึงอาจบอกได้เพียงว่าไฟล์เปลี่ยน ผมอยากตรวจวิธีดูค่าที่มีผลจริงของระบบนั้นด้วย โดยไม่รีบ restart production เพียงเพื่อพิสูจน์ข้อสงสัย
การเปรียบเทียบอัตโนมัติช่วยลดเวลาหา แต่ผลที่ได้ยังต้องมีคนอ่าน ถ้าแจ้งทุก timestamp หรือค่าที่ระบบสร้างใหม่ทุกครั้ง ทีมอาจเริ่มปิดแจ้งเตือน ผมจะเลือกค่าที่เกี่ยวกับการรับไฟล์และการเข้าถึงบริการก่อน พร้อมเก็บเหตุผลว่ารายการใดถูกเว้นจากการเทียบ เพื่อไม่ให้การลดเสียงรบกวนกลายเป็นการมองไม่เห็นสิ่งสำคัญ
จะเก็บค่าใหม่ ต้องแก้ทางที่ส่งค่าลงเครื่องด้วย
ถ้าลูกค้าจำเป็นต้องส่งไฟล์ขนาดที่เพิ่มขึ้นจริง ผมจะดูผลต่อพื้นที่เก็บ ภาระบริการ และข้อจำกัดของแอปก่อนยอมรับค่าใหม่ ไม่เลือกตัวเลขสูงที่สุดเพื่อจบปัญหาอัปโหลด เพราะความสะดวกตรงนี้อาจย้ายต้นทุนไปอยู่ที่อื่น คนดูแลเทคนิคกับคนรับผิดชอบงานลูกค้าควรตกลงขนาดที่รองรับและวิธีจัดการไฟล์ที่เกินขอบเขตนั้นร่วมกัน
เมื่อเลือกเก็บแล้ว งานยังไม่จบที่แก้คู่มือ ต้องปรับแหล่งที่ deploy ใช้ ส่งการเปลี่ยนผ่านขั้นตอนที่ทีมตรวจได้ และยืนยันว่ารอบถัดไปจะไม่ทับกลับ ค่าที่แก้บนเครื่องเพียงแห่งเดียวอาจอยู่รอดจนถึงวันที่สร้างเครื่องใหม่ ซึ่งเป็นวันที่เราอยากให้ทุกอย่างง่ายขึ้นที่สุด แต่กลับต้องมานั่งจำว่าเคยกดอะไรไว้บ้าง
ถ้าการเพิ่มเป็นเพียงทางแก้ชั่วคราวที่ยังมีความเสี่ยง ผมจะเก็บเป็นข้อยกเว้นที่มีเหตุผล คนรับผิดชอบ และวันที่กลับมาทบทวน วันที่นั้นเป็นจุดให้ตัดสินใจต่อ ไม่ใช่ให้ระบบลดค่าเองแล้วทำให้ลูกค้าส่งไฟล์ไม่ได้โดยไม่มีใครเตรียมไว้ ทางเลือกนี้ยอมรับงานติดตามเพิ่ม เพื่อแลกกับเวลาหาทางส่งไฟล์ที่เหมาะกว่า
แต่ถ้าค่านั้นไม่มีเหตุผลรองรับและเปิดความเสี่ยงที่ยอมรับไม่ได้ ก็ต้องวางแผนย้อนกลับหรือจำกัดผลกระทบตามความเร่งด่วน หากพบสัญญาณว่ามีการเข้าถึงโดยไม่ได้รับอนุญาต งานจะเปลี่ยนจากการเก็บเอกสารเป็นการรับมือเหตุ ต้องรักษาหลักฐานและให้ผู้รับผิดชอบประเมินก่อน การทำให้ไฟล์ตรงกันไม่ทดแทนการตรวจว่าใครเข้ามาและทำอะไรไปแล้ว
วิธีเก็บส่วนต่างของทีมเล็กอาจเป็นบันทึกสั้น ๆ ที่มีค่าเดิม ค่าที่พบ เหตุผลเท่าที่รู้ งานที่ได้รับผล และคำตัดสินพร้อมผู้รับผิดชอบ อยากให้คนมาอ่านต่อรู้ว่าค่านี้ถูกยอมรับ ถูกกำหนดให้ย้อน หรือยังรอตรวจ มากกว่าเห็นเพียงคำว่า “แก้แล้ว” โดยไม่รู้ว่าแก้อะไร
ทางกลับควรพิสูจน์กับงานที่เคยติด
ผมจะระวังคำว่า rollback ที่หมายถึงมีไฟล์เก่าวางอยู่ การมีไฟล์เป็นจุดเริ่มต้น แต่ยังต้องรู้ว่ามันใช้กับรุ่นซอฟต์แวร์ปัจจุบันได้ไหม ต้องเปลี่ยนส่วนไหนพร้อมกัน และถ้าบริการไม่ขึ้นจะกลับเข้าระบบทางใด ถ้ามีการย้ายข้อมูลหรือเปลี่ยนรูปแบบฐานข้อมูลร่วมด้วย การคืน config อย่างเดียวอาจไม่พอ
สำหรับเว็บรับไฟล์ ผมจะลองในสภาพแวดล้อมแยกที่ใกล้เคียงเท่าที่ทีมทำได้ ใช้ไฟล์ทดสอบที่ไม่มีข้อมูลลูกค้า ตรวจว่าไฟล์ภายในขนาดที่ตกลงส่งได้ ส่วนไฟล์ที่เกินถูกปฏิเสธในแบบที่ผู้ใช้เข้าใจ และงานปกติยังเดินต่อ ถ้าต้อง deploy ชุดที่เก็บไว้ใหม่ ก็ควรตรวจพฤติกรรมเหล่านี้หลัง deploy ด้วย เครื่องทดสอบไม่ได้พิสูจน์ทุกอย่างใน production แต่ช่วยลดการเดาจากชื่อไฟล์ครับ
การตรวจเป็นระยะควรผูกกับจังหวะงานด้วย บริการที่เปลี่ยนบ่อยควรมีการเทียบหลังเปลี่ยนและหลังแก้ฉุกเฉิน ส่วนการตรวจตามรอบช่วยหาเรื่องที่ไม่มีบันทึก ความถี่ต้องพอดีกับผลกระทบและเวลาที่ทีมรับไหว ไม่จำเป็นต้องใช้รอบเดียวกันกับทุกเครื่อง NIST SP 800-128 วางหลักเรื่องการจัดการและติดตาม configuration ควบคู่กับการรองรับงานขององค์กร ข้อเสนอที่ย่อให้ทีมเล็กในบทความนี้เป็นวิธีประยุกต์หลักคิด ไม่ใช่รายการรับรองว่าทำตามข้อกำหนดครบแล้ว
สำหรับเว็บตัวอย่าง ถ้าค่าใหม่ผ่านการตรวจและควรใช้ต่อ ผมยอมเสียเวลาแก้แหล่ง deploy และบันทึกเหตุผลตอนนี้ ดีกว่าปล่อยให้ความสามารถรับไฟล์ขึ้นอยู่กับว่าเครื่องไหนยังไม่ถูกสร้างใหม่ วันที่เปิดคู่มือแล้วมันพาเราสร้างบริการที่ทำงานตามที่ตกลงได้ ถึงค่อยมั่นใจได้มากกว่าการเห็นหน้าจอเขียวอยู่เครื่องเดียว
อ่านต่อที่เกี่ยวข้อง
- Change Management สำหรับทีมเล็ก สำหรับเก็บการเปลี่ยนโดยไม่เพิ่มขั้นตอนจนคนเลี่ยง
- Recovery Dependency Map สำหรับดูส่วนที่ต้องพร้อมก่อนกู้บริการ