Deploy ระบบขึ้น production ไม่ให้ล่มกลางวัน: blue-green, canary และ rollback

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

บทความนี้พูดถึง change management ด้าน IT คือการปล่อยงานประจำบนระบบที่มีคนใช้อยู่ทุกวัน เช่น แก้บั๊กหรือปรับ configuration ไม่ใช่การเปลี่ยนระบบทั้งระบบ ถ้าคุณกำลังย้ายข้อมูลจากระบบเก่าไประบบใหม่ เรื่องนั้นมีขั้นตอนเฉพาะของมัน ซึ่งเราเขียนไว้แยกในบทความเรื่อง validate และ cutover ตอนเปลี่ยนระบบ

การปล่อยงานขึ้น production ไม่มีครั้งไหนที่เสี่ยงต่ำ

แนวทาง Safe deployment practices ใน Azure Well-Architected Framework ของ Microsoft เขียนไว้ตรง ๆ ว่าไม่มีการ deploy ขึ้น production ครั้งไหนที่เสี่ยงต่ำ ไม่ว่าจะเป็นโค้ดแอปพลิเคชัน infrastructure as code, feature flag หรือ configuration ทุกอย่างนำความเสี่ยงเข้ามาในระบบ เอกสารเดียวกันแนะนำให้ทุกการ deploy ใช้รูปแบบมาตรฐานเดียวกัน และจัดการความเสี่ยงในระดับเดียวกันทุกครั้ง

หนังสือ Site Reliability Engineering ของ Google ในบท Release Engineering ก็ระบุว่าการเปลี่ยน configuration อาจเป็นต้นเหตุของความไม่เสถียร เราเห็นว่าประโยคนี้สำคัญกับองค์กรที่แยกการแก้ configuration ออกไปทำนอกขั้นตอนปกติ เพราะคิดว่า "ไม่ได้แก้โค้ด" การเปลี่ยนค่าเชื่อมต่อฐานข้อมูลหรือเปิดปิดฟีเจอร์ผ่านหน้า admin ทำให้ระบบล่มได้ไม่ต่างจากโค้ดใหม่

อีกข้อที่ Microsoft แนะนำคือ deploy ครั้งละน้อยแต่บ่อย ดีกว่า deploy ครั้งละมากแต่นาน ๆ ครั้ง เพราะการเปลี่ยนแปลงขนาดเล็กแก้ได้ง่ายกว่าเมื่อเกิดปัญหา ข้อนี้มีผลโดยตรงกับการออกแบบขั้นตอนอนุมัติ ซึ่งเราจะกลับมาพูดในหัวข้อข้อโต้แย้ง

Staging ต้องเหมือน production แค่ไหน ถึงจะเชื่อผลทดสอบได้

แนวทางของ Azure ระบุให้ deploy การเปลี่ยนแปลงไปที่ staging ที่สะท้อน production ก่อนขึ้นระบบจริง ในทางปฏิบัติ staging ที่เหมือน production ทุกจุดมีต้นทุนสูง และองค์กรอาจเลือกไม่จ่ายส่วนนั้น การตัดสินใจแบบนั้นรับได้ ถ้าทุกคนรู้ว่า staging ต่างจากของจริงตรงไหน

ผลทดสอบบอกได้เท่าที่ staging เหมือนของจริง

ความต่างที่เราตรวจเป็นอันดับแรกมีสี่กลุ่ม กลุ่มแรกคือเวอร์ชันของ runtime, ระบบปฏิบัติการ และฐานข้อมูล กลุ่มที่สองคือ configuration และสถานะของ feature flag ที่เปิดอยู่จริง กลุ่มที่สามคือการเชื่อมต่อกับระบบภายนอก ซึ่งบน staging อาจต่อกับ sandbox ของผู้ให้บริการแทนของจริง กลุ่มสุดท้ายคือปริมาณข้อมูล เพราะคำสั่งที่เร็วบนตารางหนึ่งหมื่นแถว อาจล็อกตารางนานหลายนาทีเมื่อเจอข้อมูลหลายล้านแถว

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

ใครอนุมัติ และอนุมัติจากหลักฐานอะไร

ในบท Release Engineering ของ Google SRE อธิบายว่าการปล่อยงานมีการควบคุมสิทธิ์หลายชั้น ซึ่งกำหนดว่าใครทำขั้นตอนไหนได้ ขั้นตอนที่ต้องผ่านการควบคุมรวมถึงการอนุมัติการแก้ซอร์สโค้ดและการ deploy release ใหม่ ระบบ release อัตโนมัติของ Google ยังสร้างรายงานการเปลี่ยนแปลงทั้งหมดใน release นั้น แล้วเก็บไว้คู่กับไฟล์ build เพื่อให้ทีมไล่หาสาเหตุได้เร็วขึ้นเมื่อ release มีปัญหา

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

• release นี้เปลี่ยนอะไรบ้าง และแต่ละรายการมาจากคำขอหรือ ticket ไหน

• ผลทดสอบบน staging เป็นอย่างไร และมีอะไรที่ staging พิสูจน์ไม่ได้

• มีการเปลี่ยนโครงสร้างฐานข้อมูลหรือไม่ ถ้ามี ถอยกลับได้แค่ไหน

• ถ้าหลังปล่อยมีปัญหา จะถอยด้วยวิธีไหน และใครเป็นคนตัดสินใจถอย

• ผู้ใช้กลุ่มไหนได้รับผลกระทบ และแจ้งไปแล้วหรือยัง

• ใครเฝ้าระบบหลังปล่อย และจะดูสัญญาณอะไรเพื่อบอกว่าปกติ

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

ข้อสุดท้ายนี้ Azure Well-Architected ก็แนะนำไว้ ให้กำหนดล่วงหน้าว่าใครอนุมัติการเร่งขั้นตอนในกรณีฉุกเฉินได้ และต้องเข้าเงื่อนไขอะไรบ้าง ถ้าไม่กำหนดไว้ วันที่ฉุกเฉินจริง คนที่บังเอิญอยู่หน้าจอตอนนั้นจะเป็นคนตัดสินใจเอง

ช่วงเวลาปล่อยงาน และช่วงที่ไม่ควรแตะระบบ

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

ช่วง freeze คือช่วงที่ตกลงกันว่าจะไม่ปล่อยงานใหม่ ยกเว้นงานฉุกเฉิน ตัวอย่างช่วงที่ควรพิจารณาคือช่วงปิดปีงบประมาณ วันปิดงบสิ้นเดือน วันจ่ายเงินเดือน และวันเปิดรับลงทะเบียนที่ประกาศไว้ล่วงหน้า ปฏิทินนี้ควรทำร่วมกับฝ่ายธุรกิจตั้งแต่ต้นปี เพราะทีมไอทีไม่ได้รู้ทุกวันที่สำคัญของหน่วยงานอื่น

freeze มีต้นทุนของมันเอง แนวทางของ Azure เตือนว่าการไม่ deploy อัปเดตเป็นประจำก็สร้างความเสี่ยงอีกแบบ เช่น ช่องโหว่ด้านความปลอดภัยที่ต้องแก้ด้วยการ deploy ปฏิทิน freeze จึงต้องมาพร้อมเส้นทางฉุกเฉินที่ระบุชื่อคนอนุมัติไว้ชัด อีกความเสี่ยงที่ควรวางแผนไว้คือสัปดาห์ก่อนเริ่ม freeze อาจกลายเป็นช่วงที่หลายทีมรีบนำงานขึ้นระบบพร้อมกัน ซึ่งเสี่ยงกว่าวันปกติ

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

ทางถอยของแต่ละ release: feature flag, blue-green หรือ canary

ทางถอยควรเลือกทีละ release ไม่ใช่เลือกครั้งเดียวแล้วใช้กับทุกงาน แนวทางของ Azure แบ่งการกู้คืนเมื่อ deploy มีปัญหาเป็นสามแบบ คือ rollback กลับไปยัง configuration ล่าสุดที่ใช้งานได้ roll forward ด้วยการแก้ปัญหากลางทางเช่นออก hotfix และสร้าง infrastructure ใหม่จาก configuration ล่าสุดที่ใช้งานได้ แต่ละเทคนิคด้านล่างทำให้ทางใดทางหนึ่งเร็วขึ้น และมีราคาที่ต้องจ่ายต่างกัน

Feature flag ใช้เปิดหรือปิดฟีเจอร์ใน production แบบเลือกได้ Microsoft ระบุว่าช่วยควบคุมการเปิดโค้ดใหม่ และ rollback ได้เร็วเมื่อเกิดปัญหา ราคาที่เราเห็นคือทุก flag เป็นทางแยกในโค้ดที่ต้องกลับมาลบภายหลัง ถ้าไม่ลบ จำนวนชุดค่า flag ที่เป็นไปได้จะมากเกินกว่าจะทดสอบครบ และ flag ช่วยอะไรไม่ได้เลยถ้าสิ่งที่เปลี่ยนคือโครงสร้างฐานข้อมูลหรือ infrastructure

Blue-green ตามคำอธิบายของ Azure คือการมี infrastructure สองชุดที่เหมือนกัน และทั้งสองชุดรับโหลด production ได้เต็ม ชุดหนึ่งรันเวอร์ชันปัจจุบัน อีกชุดรันเวอร์ชันใหม่ แล้วค่อย ๆ ย้าย traffic ไป ราคาที่ต้องจ่ายตรง ๆ คือค่า infrastructure ขนาดเต็มสองชุด ส่วนราคาที่มองไม่เห็นคือ ถ้าทั้งสองชุดใช้ฐานข้อมูลเดียวกัน การสลับกลับจะเร็วได้ก็ต่อเมื่อฐานข้อมูลยังใช้งานได้กับทั้งสองเวอร์ชัน

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

ทุกวิธีข้างต้นต้องอาศัยการรู้ว่าเมื่อไหร่ควรหยุด Azure แนะนำให้หยุดการปล่อยงานทันทีเมื่อตรวจพบปัญหา คำถามว่าสัญญาณไหนควรทำให้หยุดและควรปลุกคน เราเขียนไว้แยกในบทความเรื่องการตั้ง monitoring และ alert

การเปลี่ยน schema ฐานข้อมูล ส่วนที่ถอยกลับไม่ได้ง่าย ๆ

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

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

บริการฐานข้อมูลหลายตัวบน Azure มี point-in-time restore ซึ่ง Microsoft ระบุว่าช่วยในการ rollback ได้ เราเห็นว่าควรมองมันเป็นทางสุดท้าย เพราะการ restore พาทั้งฐานข้อมูลกลับไปยังจุดเวลาหนึ่ง ข้อมูลที่เขียนหลังจากนั้นต้องมีคนตามกลับมาเอง

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

การลบคือขั้นที่ย้อนไม่ได้ ในส่วนการปลดระบบ Azure แนะนำให้ถือว่าการลบทุกครั้งย้อนกลับไม่ได้ และให้เก็บ snapshot หรือ backup ก่อนลบ เราใช้หลักเดียวกันกับการลบคอลัมน์และตาราง และให้คำขออนุมัติของ release ประเภทนี้ระบุชัดว่าเป็นขั้นที่ไม่มีทางถอย

แจ้งผู้ใช้ก่อนเปลี่ยน ไม่ใช่หลังระบบมีปัญหา

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

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

เมื่อไหร่ไม่ต้องทำขนาดนี้

ขั้นตอนทั้งหมดข้างต้นมีต้นทุน และไม่ใช่ทุกระบบที่คุ้ม ถ้าระบบของคุณเป็นระบบภายในที่มีผู้ใช้ไม่กี่สิบคน หยุดใช้งานช่วงสั้น ๆ ได้โดยแจ้งล่วงหน้า และไม่มีงานที่ต้องเสร็จตามเวลา การทำ blue-green ที่ต้องจ่ายค่า infrastructure สองชุดไม่คุ้ม canary ก็แทบไม่มีความหมาย เพราะกลุ่มผู้ใช้เล็กเกินกว่าจะเห็นสัญญาณอะไร สำหรับระบบแบบนี้ เราแนะนำแค่ checklist สั้น ๆ, backup ก่อนปล่อยงานที่ทดสอบ restore แล้ว และช่วงเวลาที่แจ้งผู้ใช้ไว้ ข้อเดียวที่เราไม่ลดคือการแยกขั้นเมื่อเปลี่ยน schema เพราะปัญหาข้อมูลหายไม่ได้เล็กลงตามขนาดระบบ

ข้อโต้แย้งที่ได้ยินบ่อย

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

วิธีรู้ว่าขั้นตอนช่วยจริงหรือแค่ทำให้ช้า คือวัดทั้งสองด้าน DORA นิยาม deployment frequency ว่าจำนวนครั้งที่ deploy ในช่วงเวลาหนึ่ง หรือระยะห่างระหว่างการ deploy แต่ละครั้ง นิยาม change fail rate ว่าสัดส่วนของการ deploy ที่ต้องเข้าไปแก้ไขทันทีหลัง deploy ซึ่งมีแนวโน้มจบด้วยการ rollback หรือ hotfix และนิยาม failed deployment recovery time ว่าเวลาที่ใช้ฟื้นจาก deployment ที่ล้มเหลวและต้องเข้าแก้ไขทันที ถ้าขั้นตอนใหม่ทำให้ความถี่ลดลงโดยที่ change fail rate ไม่ดีขึ้น แปลว่าขั้นตอนนั้นเพิ่มแค่เวลารอ

ข้อโต้แย้งที่สองคือ มี backup ทุกคืนอยู่แล้ว ถ้าพังก็ restore ได้ คำตอบอยู่ในหัวข้อ schema ข้างบน backup ช่วยให้ข้อมูลไม่หายทั้งหมด แต่ไม่ได้พาข้อมูลที่ผู้ใช้บันทึกหลังจุด backup กลับมา การมี backup จึงไม่ใช่ทางถอยของ release แต่เป็นตาข่ายชั้นสุดท้ายเมื่อทางถอยอื่นใช้ไม่ได้

จะเริ่มตรงไหน

1. เขียนรายการความต่างระหว่าง staging กับ production ที่มีอยู่จริงวันนี้ แล้วแนบไปกับคำขออนุมัติทุกครั้ง

2. ตกลงแบบฟอร์มคำขออนุมัติที่ตอบคำถามหกข้อในหัวข้อการอนุมัติ และกำหนดว่าคนอนุมัติต้องไม่ใช่คนเขียนการเปลี่ยนแปลง

3. ทำปฏิทิน freeze ร่วมกับฝ่ายธุรกิจ พร้อมเส้นทางฉุกเฉินที่ระบุชื่อคนอนุมัติ

4. ให้ทุก release ระบุทางถอยและคนตัดสินใจถอยก่อนขออนุมัติ

5. แยก release ที่เปลี่ยน schema ออกเป็นขั้น และให้การลบข้อมูลหรือโครงสร้างเป็น release แยกเสมอ

6. เริ่มนับ deployment frequency, change fail rate และ failed deployment recovery time จากการปล่อยงานครั้งถัดไป

ถ้าระบบของคุณดูแลโดยผู้พัฒนาภายนอก ขั้นตอนเหล่านี้ควรเขียนไว้ในสัญญาหรือ TOR ตั้งแต่ต้น ไม่ใช่มาตกลงกันหลังปล่อยงานพังครั้งแรก เราเขียนเรื่องเงื่อนไขที่ควรอยู่ใน TOR ไว้ในบทความเรื่องเขียน TOR ให้ได้ระบบที่ดูแลต่อได้

สรุป

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

หากต้องการคุยเรื่องขั้นตอนปล่อยงานของระบบที่ใช้งานอยู่ ติดต่อเราได้ที่ 088-983-9386 หรืออีเมล [email protected] สำนักงานของเราอยู่ที่บางกะปิ กรุงเทพฯ ถ้าคุยแล้วพบว่าขั้นตอนที่องค์กรของคุณมีอยู่เพียงพอกับระบบนั้นแล้ว เราจะบอกตรง ๆ และไม่เสนองานที่ไม่จำเป็น ข้อมูลเกี่ยวกับทีมและแพลตฟอร์มที่เราทำงานด้วยอยู่ที่หน้าแรกของ Superdev