Feature flag

Feature flag คือสวิตช์ในตัวโปรแกรมที่ตัดสินว่าฟีเจอร์หนึ่งจะทำงานหรือไม่ทำงาน และเปลี่ยนค่าได้ตอนที่ระบบเปิดใช้งานอยู่จริง เอกสารของโครงการ OpenFeature ซึ่งเว็บไซต์ของโครงการระบุว่าเป็นโครงการระดับ incubating ของ Cloud Native Computing Foundation อธิบายแบบพื้นฐานที่สุดว่าให้นึกถึง feature flag เป็นคำสั่ง if/else ที่ควบคุมได้ตอน runtime และเขียนไว้ตรงๆ ว่า feature flag ทำให้เปลี่ยนพฤติกรรมของแอปพลิเคชันได้โดยไม่ต้อง deploy โค้ดชุดใหม่ ฝั่ง Microsoft เรียกแนวปฏิบัตินี้ว่า feature management และนิยามไว้ในเอกสาร Azure App Configuration ว่าเป็นวิธีทำงานที่แยกการปล่อยฟีเจอร์ออกจากการ deploy โค้ด โดยตัว feature flag เองคือตัวแปรที่มีสองสถานะคือเปิดกับปิด และสถานะนั้นเป็นตัวกำหนดว่าบล็อกโค้ดที่ผูกไว้จะทำงานหรือไม่ เอกสารหน้าเดียวกันยังบอกด้วยว่าคำนี้มีชื่อเรียกอื่นอีกคือ feature toggle และ feature switch

สิ่งที่ทำให้สวิตช์นี้มีประโยชน์มากกว่าการเปิดปิดทั้งระบบทีเดียวคือกฎที่ใช้ตัดสินว่าจะเปิดฟีเจอร์ให้ใครและตอนไหน เอกสาร Azure App Configuration เรียกกฎเหล่านี้ว่า filter นิยามไว้ว่าเป็นกฎสำหรับประเมินสถานะของ feature flag และยกตัวอย่างไว้ว่าเป็นได้ทั้งกลุ่มผู้ใช้ ชนิดของอุปกรณ์หรือ browser ตำแหน่งทางภูมิศาสตร์ และช่วงเวลา หน้าเดียวกันไล่ประโยชน์ไว้หลายข้อ เช่น flighting ที่ทยอยปล่อยของใหม่ให้ผู้ใช้โดยเล็งไปที่คนสัดส่วนเล็กๆ ก่อนแล้วค่อยเพิ่มสัดส่วนขึ้นทีละน้อย ข้อ test in production ที่เปิดให้เข้าถึงของใหม่บนระบบจริงแบบจำกัด เช่น จำกัดไว้เฉพาะคนในทีมหรือผู้ทดสอบภายใน และข้อ instant kill switch ที่เขียนว่าเปิดปิดฟีเจอร์ได้โดยไม่ต้อง deploy โค้ดใหม่ และถ้าจำเป็นก็ปิดฟีเจอร์ได้เร็วโดยไม่ต้อง build กับ deploy แอปพลิเคชันใหม่ เงื่อนไขที่เอกสารย้ำไว้คือค่าของ flag ต้องถูกย้ายออกไปเก็บนอกตัวแอปในคลังกลางแยกต่างหาก เพราะนั่นคือสิ่งที่ทำให้เปลี่ยนสถานะได้โดยไม่ต้องแก้แล้ว deploy แอปใหม่ ฝั่งงานดูแลระบบ AI หลังบ้านที่เรียกกันว่า llmops ก็ยืมวิธีคิดเดียวกันไปใช้ เอกสารของ LaunchDarkly ผู้ให้บริการเครื่องมือ feature flag เขียนว่าให้จัดการค่า model ไว้นอกโค้ดแอป เพื่อจะแก้ prompt กับ setting ตอน runtime ได้โดยไม่ต้อง deploy และเพื่อทยอยเปลี่ยนไปใช้ model version ใหม่อย่างค่อยเป็นค่อยไป

คนทำงานในองค์กรมักเจอหลักการนี้ตอนที่ฝ่าย IT ทยอยเปิด AI ให้ทีละกลุ่ม แทนที่จะเปิดพร้อมกันทั้งบริษัท ตัวอย่างที่มีเอกสารรองรับคือ staged rollout ของ connector ใน microsoft-copilot ที่เอกสารอธิบายว่าใช้ค่อยๆ ปล่อย connector ให้ผู้ใช้กลุ่มที่เลือกไว้บนระบบจริง เพื่อดูผลแล้วปรับ setting ตามที่เห็น และขยายหรือหดขอบเขตของ rollout เมื่อไหร่ก็ได้ ตัวเลขที่เอกสารระบุคือใส่ได้ไม่เกิน 100 users และ 15 Microsoft 365 groups ต้องเป็น AI administrator ถึงจะเข้าถึงฟีเจอร์นี้ได้ และมีข้อจำกัดกำกับไว้ว่าค่าที่ตั้งใน staged rollout ตอนนี้มีผลกับประสบการณ์ Search และ Copilot เท่านั้น พอเลิก staged rollout เอกสารบอกว่าผลลัพธ์จาก connection จะเริ่มโผล่ให้ผู้ใช้ทุกคนในองค์กรที่มีสิทธิ์เข้าถึงเห็น อีกแบบหนึ่งคือการเปิดปิดระดับผู้ดูแลระบบ หน้าช่วยเหลือของ Google Workspace เรื่องเปิดปิดแอป gemini เขียนว่า setting ระดับ group จะทับ setting ระดับ organizational unit และเตือนว่าการเปลี่ยนค่าอาจใช้เวลาถึง 24 ชั่วโมงกว่าจะมีผล แม้ปกติจะเกิดขึ้นเร็วกว่านั้น ส่วน setting เรื่องประวัติการสนทนาระบุไว้นานกว่าคือถึง 72 ชั่วโมง สิ่งที่ต้องระวังจึงมีสองเรื่อง เรื่องแรกคือช่วงที่สวิตช์ยังเปิดไม่ครบ เพื่อนร่วมงานคนละกลุ่มจะเห็นหน้าจอไม่เหมือนกัน คำถามแบบทำไมเครื่องผมไม่มีปุ่มนี้จึงเป็นเรื่องปกติของช่วงทยอยเปิด ไม่ใช่ความผิดพลาด ทีมที่ทำ proof-of-concept จึงควรบอกล่วงหน้าว่าใครอยู่ในกลุ่มแรกและกลุ่มถัดไปจะถึงคิวเมื่อไหร่ เรื่องที่สองคือการปิดกลับไม่ได้แปลว่าทุกคนหยุดเห็นพร้อมกันในวินาทีเดียวเสมอไป อย่างกรณี Google ที่ระบุกรอบเวลาไว้ชัดเจนข้างต้น การทำงานแบบนี้จึงเป็นงาน change-management พอๆ กับงานเทคนิค คือต้องมี ai-policy บอกว่ากลุ่มไหนได้ใช้อะไรด้วยเหตุผลอะไร และต้องมี observability คอยดูว่าหลังเปิดให้กลุ่มแรกแล้วเกิดอะไรขึ้นบ้าง ก่อนจะกดขยายไปกลุ่มถัดไป

ตัวอย่างจากบทสนทนาจริง

ฝ่ายบุคคล: พี่คะ ทีมการตลาดบอกว่าเขามีปุ่มสรุปประชุมใน Copilot แล้ว แต่เครื่องหนูยังไม่มีเลย เครื่องหนูมีปัญหาหรือเปล่าคะ

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

ฝ่ายบุคคล: แล้วถ้าปิดกลับ งานที่ทีมการตลาดทำค้างไว้จะหายไหมคะ

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

ระวังสับสนกับ

• kill-switch : kill-switch คือการใช้สวิตช์แบบนี้ในสถานการณ์ฉุกเฉิน เพื่อดับฟีเจอร์หรือระบบที่กำลังมีปัญหาให้เร็วที่สุด ส่วน feature flag คือกลไกทั่วไปที่ใช้ทั้งตอนทยอยเปิดและตอนปิด เอกสาร Azure App Configuration ถึงกับนับความสามารถปิดฉุกเฉินนี้เป็นประโยชน์ข้อหนึ่งของ feature flag
• a-b-testing : a-b-testing คือการเปรียบเทียบสองทางเลือกด้วยตัวเลขเพื่อตัดสินว่าแบบไหนได้ผลกว่ากัน ส่วน feature flag คือสวิตช์ที่พาผู้ใช้แต่ละกลุ่มไปเจอทางเลือกนั้น จะเปิดสวิตช์ให้คนกลุ่มเล็กโดยไม่ได้ตั้งใจวัดผลเปรียบเทียบอะไรเลยก็ทำได้
• rbac : rbac ตัดสินว่าใครมีสิทธิ์เข้าถึงอะไรตามบทบาทในองค์กร เป็นเรื่องความปลอดภัยและการกำกับดูแล ส่วน feature flag ตัดสินว่าฟีเจอร์นั้นถูกเปิดใช้อยู่หรือไม่ ณ ตอนนั้น คนที่มีสิทธิ์ตามบทบาทครบแล้วก็ยังไม่เห็นฟีเจอร์ได้ ถ้าสวิตช์ยังปิดอยู่