แพลตฟอร์มวิศวกรรมคืออะไร? แพลตฟอร์ม, ประสบการณ์นักพัฒนา, และแนวทางควบคุม

วิศวกรรมแพลตฟอร์มคือการปฏิบัติการสร้างและดำเนินการความสามารถภายในที่ใช้ร่วมกันซึ่งช่วยให้ทีมซอฟต์แวร์ส่งมอบและรันแอปพลิเคชันผ่านกระบวนการทำงานแบบเซลฟ์เซอร์วิสที่ได้รับการสนับสนุน แพลตฟอร์มถูกมองว่าเป็นผลิตภัณฑ์ที่ผู้ใช้คือผู้พัฒนาและทีมเทคนิคอื่น ๆ

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

ประเด็นสำคัญ

• เริ่มต้นด้วยการวิจัยนักพัฒนาและความขัดแย้งที่เกิดซ้ำ ๆ ไม่ใช่สแต็กเครื่องมือที่กำหนดไว้ล่วงหน้า
• เสนอเส้นทางทองที่เป็นตัวเลือกและได้รับการสนับสนุนพร้อมเส้นทางหลบหนีที่ชัดเจนสำหรับข้อยกเว้นที่สมเหตุสมผล
• เปิดเผยความสามารถผ่าน API, แม่แบบ, ระบบอัตโนมัติ, และเอกสาร; พอร์ทัลเป็นเพียงหนึ่งในอินเทอร์เฟซ
• วัดผลลัพธ์ของผู้ใช้และการยอมรับผลิตภัณฑ์พร้อมกับการส่งมอบ, ความน่าเชื่อถือ, ความปลอดภัย, และต้นทุน

แพลตฟอร์มในฐานะผลิตภัณฑ์ภายใน

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

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

ความสามารถ, พอร์ทัล, และเส้นทางทอง

ความสามารถอาจรวมถึงที่เก็บโค้ด, สภาพแวดล้อม, CI/CD, ความลับ, ตัวตน, โครงสร้างพื้นฐาน, การสังเกต, แคตาล็อกบริการ, ค่าใช้จ่าย, และการบูรณาการเหตุการณ์ พอร์ทัลนักพัฒนาสามารถเปิดเผยความสามารถเหล่านี้ได้ แต่การจัดลำดับและบริการปฏิบัติการทำให้แพลตฟอร์มเป็นจริง

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

สถาปัตยกรรมและแนวทางควบคุม

ใช้อินเทอร์เฟซที่เสถียรและ API ที่ประกาศเพื่อให้แพลตฟอร์มสามารถพัฒนาได้เบื้องหลัง แยกแผนควบคุมออกจากงานที่ทำ, กำหนดขอบเขตของข้อมูลประจำตัว, รักษาข้อมูลเมตาของเจ้าของ, และทำให้การเปลี่ยนแปลงที่สร้างขึ้นสามารถตรวจสอบและย้อนกลับได้

ผสานการตรวจสอบ DevSecOps, นโยบาย, และแหล่งที่มาของศิลปวัตถุเข้าไปในกระบวนการทำงาน แนวทางควบคุมควรให้ข้อเสนอแนะที่รวดเร็วและการแก้ไขที่ทำได้จริง แทนการปฏิเสธโดยไม่มีเหตุผล

วัดและพัฒนา

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

ใช้แนวปฏิบัติ IT operations เพื่อติดตั้งเครื่องมือบนแพลตฟอร์มและสัมภาษณ์ผู้ใช้เป็นประจำ ถอนเส้นทางที่ไม่ได้ใช้, มาตรฐานที่ซ้ำซ้อนเมื่อมีค่าใช้จ่ายสูง, และอนุญาตความหลากหลายเมื่อสร้างคุณค่าผลิตภัณฑ์

แพลตฟอร์มนักพัฒนาภายในและเส้นทางทอง

แพลตฟอร์มนักพัฒนาภายในคือผลิตภัณฑ์ที่เปิดเผยโครงสร้างพื้นฐานและความสามารถการดำเนินงานที่ได้รับการอนุมัติผ่านอินเทอร์เฟซเซลฟ์เซอร์วิส สามารถรวมพอร์ทัล, แคตาล็อกบริการ, แม่แบบ, API, เครื่องมือบรรทัดคำสั่ง, กระบวนการปรับใช้, ความลับ, สภาพแวดล้อม, และการสังเกต แพลตฟอร์มไม่ได้แทนที่คลาวด์หรือ Kubernetes; มันจัดระเบียบให้เป็นความสามารถที่ใช้งานได้

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

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

แผนควบคุม, อินเทอร์เฟซ, และโมเดลการดำเนินงาน

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

อินเทอร์เฟซอาจรวมถึงพอร์ทัลเว็บ, API, การกำหนดค่าจาก Git, CLI, และส่วนประกอบของสายงานที่ใช้ซ้ำได้ อินเทอร์เฟซที่ดีที่สุดขึ้นอยู่กับความถี่ของงานและกระบวนการทำงานของผู้ใช้ ทุกอินเทอร์เฟซต้องมีการรับรองตัวตน, การให้สิทธิ์, การตรวจสอบความถูกต้อง, ประวัติการตรวจสอบ, คำอธิบายข้อผิดพลาด, และการเวอร์ชัน การเซลฟ์เซอร์วิสโดยไม่มีการจัดการวงจรชีวิตทำให้เกิดทรัพยากรที่ถูกละทิ้งและการกระจายการกำหนดค่า

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

การวัดคุณค่าและหลีกเลี่ยงความล้มเหลวของแพลตฟอร์ม

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

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

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

ตัวอย่างการทำงาน: เส้นทางเซลฟ์เซอร์วิสสำหรับ API ใหม่

นักพัฒนาตรวจสอบแม่แบบ API ที่ได้รับการอนุมัติและระบุชื่อบริการ, เจ้าของ, การจัดประเภทข้อมูล, ภาษา, และระดับความน่าเชื่อถือ แพลตฟอร์มจะสร้างที่เก็บโค้ด, นโยบายการพึ่งพา, สายงาน CI, สภาพแวดล้อมทดสอบ, การกำหนดค่าการปรับใช้, รายการแคตาล็อกบริการ, แดชบอร์ด, การแจ้งเตือน, และคู่มือเริ่มต้น นโยบายจะตรวจสอบชื่อ, ภูมิภาค, สิทธิ์, และการเปิดเผยเครือข่ายก่อนการจัดสรร ในขณะที่ศิลปวัตถุที่สร้างขึ้นยังคงตรวจสอบได้และเป็นของทีม

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

วัดเวลาตั้งแต่การสร้างที่เก็บโค้ดจนถึงการปรับใช้ผลิตภัณฑ์ที่มีสุขภาพดี, ความพยายามของนักพัฒนา, ความต้องการสนับสนุน, การล้มเหลวของการเปลี่ยนแปลง, การฟื้นฟู, การปฏิบัติตามนโยบาย, และการยอมรับตามประเภทงาน สัมภาษณ์ผู้ใช้ที่ละทิ้งเส้นทางและตรวจสอบจุดที่พวกเขารอหรือหลบหนีจากการสรุป ทีมแพลตฟอร์มควรให้ความสำคัญกับความขัดแย้งที่ซ้ำซ้อนมากที่สุด, เผยแพร่ความน่าเชื่อถือและแผนงาน, และถอนความสามารถที่ไม่ได้ใช้ แคตาล็อกที่ขัดเกลาดีไม่ใช่แพลตฟอร์มหากทีมยังต้องใช้ตั๋วสำหรับทุกการดำเนินการที่มีความหมาย

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

รายการตรวจสอบการนำไปใช้เชิงปฏิบัติ

เปลี่ยนแนวคิดให้เป็นกระบวนการทำงานที่จำกัดและทดสอบได้: วิจัยผู้ใช้ → ออกแบบเส้นทาง → สร้าง → เซลฟ์เซอร์วิส → ดำเนินการ → ปรับปรุง ตั้งชื่อเจ้าของที่รับผิดชอบ, บันทึกข้อมูลและการพึ่งพา, สร้างฐานข้อมูลพื้นฐานง่าย ๆ, กำหนดเกณฑ์การยอมรับและการหยุด, ทดสอบความล้มเหลวที่เป็นตัวแทน, และกำหนดการเฝ้าติดตาม, การย้อนกลับ, และการตรวจสอบก่อนขยายขอบเขต บันทึกเวอร์ชันและสมมติฐานเพื่อให้ทีมอื่นสามารถทำซ้ำผลลัพธ์และเข้าใจการเปลี่ยนแปลง

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

• PRODUCT: ผู้ใช้, แผนงาน, ข้อเสนอแนะ, และการสนับสนุน.
• CAPABILITIES: API, ระบบอัตโนมัติ, บริการ, และนโยบาย.
• OUTCOMES: การไหล, ความน่าเชื่อถือ, ความปลอดภัย, และต้นทุน.

คำถามที่พบบ่อย

วิศวกรรมแพลตฟอร์มกำลังแทนที่ DevOps หรือไม่?

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

พอร์ทัลนักพัฒนาภายในคือแพลตฟอร์มหรือไม่?

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

แหล่งอ้างอิงหลัก

• CNCF: เอกสารขาว Platforms
• CNCF: โมเดลความพร้อมของวิศวกรรมแพลตฟอร์ม
• DORA: โปรแกรมวิจัย