Platform Engineering แบบครบทุกมิติ: ทำไมจึงจำเป็น สร้างอย่างไร และความสำเร็จมีหน้าตาแบบไหน

 (lucavall.in)
12 คะแนน โดย GN⁺ 6 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในฐานะ ระเบียบวินัยระดับองค์กรที่สร้างและดำเนินงานผลิตภัณฑ์ภายใน โดยมีวิศวกรภายในเป็นผู้ใช้ นี่คือขอบเขตงานที่ต่างออกไปโดยพื้นฐานจากการรีแบรนด์ DevOps หรือการดูแล Kubernetes cluster แบบเรียบง่าย
  • ตามรายงาน DORA ปี 2025 องค์กร 90% ได้นำ internal platform อย่างน้อยหนึ่งอย่างมาใช้แล้ว และ คุณภาพของแพลตฟอร์มกำลังก้าวขึ้นมาเป็นตัวชี้วัดที่ทำนายได้โดยตรงว่าเครื่องมือ AI จะสร้างคุณค่าได้หรือไม่
  • เมื่อคลาวด์และโอเพนซอร์สมอบ primitive ได้อย่างไม่จำกัด การแก้ปัญหา "หล่มของการทำให้เป็นทั่วไปมากเกินไป (over-general swamp)" ที่แต่ละทีมต่างสร้าง pipeline ของตนเองขึ้นมา คือเหตุผลหลักที่แพลตฟอร์มนี้ต้องมีอยู่
  • การปฏิบัติต่อแพลตฟอร์มเหมือนเป็นผลิตภัณฑ์จริง และการมี software abstraction, metadata registry และ SLO ด้านปฏิบัติการสำหรับนักพัฒนากลุ่มค่ามัธยฐาน คือเงื่อนไขเชิงโครงสร้างของความสำเร็จ
  • แพลตฟอร์มที่ดีจะทำงานได้เป็นธรรมชาติจนแทบทำให้นักพัฒนาลืมไปว่ามันมีอยู่ ขณะที่ แพลตฟอร์มที่แย่จะทำให้เครื่องมือ AI ขยายความสับสน แต่แพลตฟอร์มที่ดีจะขยาย throughput

เหตุผลที่ Platform Engineering มีอยู่

  • หล่มของการทำให้เป็นทั่วไปมากเกินไป (Over-General Swamp)

    • เมื่อคลาวด์และ OSS มอบ primitive อย่างไม่จำกัด เช่น queue, object store, database, CI runner, service mesh แต่ละทีมแอปพลิเคชันจึงลงเอยด้วยการเลือกคนละแบบ
    • ผ่านไป 1 ปี ทุกบริการจะกลายสภาพเป็น หล่มของ glue code ที่มีทั้ง deployment pipeline ของตัวเอง, retry logic, แนวปฏิบัติด้าน monitoring และ IAM binding ที่ผิดแบบละเอียดอ่อน
    • ต้นเหตุสองอย่างของหล่มนี้คือการระเบิดของตัวเลือก และความคาดหวังด้านปฏิบัติการที่สูงขึ้น (เปิดใช้งาน 24/7, ความปลอดภัย, compliance, การจัดการต้นทุน)
    • ในโปรเจกต์ landing zone จริง เคยมีกรณีที่ 20 ทีม ประดิษฐ์ Terraform module ที่แทบเหมือนกันขึ้นมาใหม่คนละชุด สำหรับ VPC, IAM และ budget alert โดยแต่ละชุดมีบั๊กคนละแบบ

  • สิ่งที่ Platform Engineering ทำจริง ๆ มีสี่อย่าง

    • จำกัด primitive ที่นักพัฒนามองเห็น เพื่อชี้นำให้ใช้งานในรูปแบบที่ผ่านการคัดสรรแล้วเท่านั้น
    • ดูดซับงาน plumbing ที่ต้องทำซ้ำเข้าไปเป็น shared service เพื่อ ลด glue code เฉพาะแอปพลิเคชัน
    • เมื่อ primitive พื้นฐานเปลี่ยนไป ทีมแพลตฟอร์มจัดการเพียงครั้งเดียวเพื่อ รวมศูนย์ต้นทุนการย้ายระบบ
    • ช่วยให้นักพัฒนา ดูแลสิ่งที่ตัวเองสร้างได้โดยตรง โดยไม่ต้องกลายเป็นผู้เชี่ยวชาญ Linux kernel
    • DevOps คือ "ให้นักพัฒนาเป็นเจ้าของงานปฏิบัติการ" ส่วน Platform Engineering คือ "เราจะมอบเครื่องมือที่ดีสำหรับงานปฏิบัติการนั้นในฐานะ ผลิตภัณฑ์จริง"
    • แม้แต่ในหน้าความสามารถ DORA 2025 ก็ยังนิยามสิ่งนี้ว่าเป็น ระเบียบวินัยเชิงสังคมเทคนิค (sociotechnical) ไม่ใช่หมวดหมู่ของเครื่องมือ

เสาหลักทั้งห้า (Pillars)

  • แนวทางแบบผลิตภัณฑ์ที่ผ่านการคัดสรร (Curated Product Approach)

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

  • การทำ abstraction ด้วยซอฟต์แวร์ (Software-Based Abstractions)

    • แพลตฟอร์มคือ ซอฟต์แวร์ ไม่ใช่วิกิ และอินเทอร์เฟซก็คือ API, CLI, SDK
    • นักพัฒนาควรสามารถ provision บริการระดับ production ได้เพียงแค่เขียน ไฟล์เชิงประกาศขนาดเล็ก
    • โครงการ Score ภายใต้ CNCF เป็นตัวอย่างเด่น โดยใช้ workload spec เพียงชุดเดียวเพื่อ provision ฐานข้อมูล, topic, service account และ deployment โดยอัตโนมัติ
      • นักพัฒนาไม่จำเป็นต้องรู้ว่าข้างในใช้ Cloud SQL, Pub/Sub หรือ Cloud Run

  • การปรับแต่ง OSS และ metadata registry

    • ไม่ได้ใช้ Argo CD หรือ Backstage แบบ vanilla ตรง ๆ แต่ใช้งานโดยใส่ ปลั๊กอิน นโยบายตั้งต้น และการเชื่อมต่อที่เหมาะกับองค์กร
    • หากไม่มี metadata registry (service catalog) ก็จะ ไม่สามารถรู้ได้ ว่าใครเป็นเจ้าของอะไร มีความสัมพันธ์การพึ่งพาแบบไหน และจริง ๆ แล้วมีอะไรที่กำลังรันอยู่
    • Backstage คือเฟรมเวิร์ก OSS มาตรฐานโดยพฤตินัยของเลเยอร์นี้ โดยมีมากกว่า 270 องค์กรใช้งานจริงใน production
      • CNCF ได้เปิดตัวใบรับรอง Certified Backstage Associate และ Certified Cloud Native Platform Engineering Associate
      • ไม่ว่าจะใช้ Backstage, Port, Cortex หรืออะไร ก็ต้องมี single source of truth สำหรับ "มีบริการอะไรอยู่ ใครเป็นเจ้าของ และมีความสัมพันธ์การพึ่งพาอย่างไร"

  • การให้บริการแก่ฐานผู้ใช้วงกว้าง

    • internal platform มักมีลูกค้าจำนวนน้อยแต่เสียงดังมาก ทว่าเป้าหมายคือการรองรับ งานแบบค่ามัธยฐานของนักพัฒนาแบบค่ามัธยฐาน ให้ดี
    • ถ้าสร้างเพื่อผู้ใช้ระดับหัวกะทิเท่านั้น ทีมที่เหลือจะเลี่ยงแพลตฟอร์มและทำให้เกิด shadow platform

  • ปฏิบัติการในฐานะรากฐาน

    • หากแพลตฟอร์มล่ม บริษัทก็ล่มด้วย จึงต้องมี on-call 24/7, SLO จริง, change management จริง และภาระการซัพพอร์ตจริง
    • มันไม่ได้ทำหน้าที่เป็น "เครื่องมือ" แต่เป็น "พื้น (floor)" ซึ่งทุกสิ่งที่สร้างอยู่ข้างบนต่างสมมติว่าพื้นนี้จะรับน้ำหนักไหว

ช่วงเวลาและวิธีเริ่มต้น

  • อย่าสร้างทีมแพลตฟอร์มเร็วเกินไป

    • ในองค์กรที่มีวิศวกรราว 10 คน สิ่งที่ต้องการไม่ใช่ทีมแพลตฟอร์ม แต่คือ ความร่วมมือ (cooperation)
      • ให้คนหนึ่งดูแล deployment script อีกคนดูแล Terraform และตกลงร่วมกันเรื่องแนวปฏิบัติก็เพียงพอ
    • ถ้าตั้งทีมเร็วเกินไปด้วยคน 1–2 คน พวกเขาจะกลายเป็น ticket queue และคนอื่นในองค์กรจะกลายเป็นฝ่ายตั้งรับแบบเฉื่อยชา
    • โดยทั่วไปหลังมีวิศวกร เกิน 50 คน, มีเป้าหมายการ deploy หลายแบบ และไม่มีใครรู้คำตอบที่ชัดเจนสำหรับ "วิธี deploy บริการใหม่" เมื่อนั้นจึงเหมาะจะตั้งทีม

  • การเปลี่ยนผ่านจากองค์กรโครงสร้างพื้นฐานเดิม

    • เมื่อต้องเปลี่ยนทีม infra/SRE ให้เป็นองค์กรแพลตฟอร์ม ส่วนที่ยากที่สุดไม่ใช่เทคโนโลยี แต่คือ วัฒนธรรม
    • ผู้ดูแลโครงสร้างพื้นฐานคุ้นกับบทบาท gatekeeper ที่คอยบอกว่า "ทำไม่ได้" แต่ผู้ดูแลแพลตฟอร์มต้องกลายเป็น "คนที่ทำให้การตอบว่าใช่เป็นเรื่องง่าย"
      • คุยกับลูกค้าให้มาก
      • จ้างและพัฒนาคนที่เป็น software engineer ที่สนุกกับการสร้างเครื่องมือ ไม่ใช่แค่ operator
      • ปรับ ระบบการให้รางวัล ให้การทำให้ "200 ทีมทำงานได้เร็วขึ้น 5%" ได้รับการยอมรับมากกว่าการ "deploy cluster ใหม่"
    • โหมดล้มเหลวที่พบบ่อยที่สุดคือโรย PM ลงไปแล้วคิดว่าจบ ซึ่งจะสร้าง ละคร (theater) ไม่ใช่แพลตฟอร์ม

การสร้างทีมแพลตฟอร์ม

  • บทบาทสี่แบบ

    • Software Engineer: สร้าง product surface ของแพลตฟอร์ม เช่น API, SDK, portal
    • Systems Engineer: เชี่ยวชาญ primitive พื้นฐาน เช่น Kubernetes, Linux, networking, cloud control plane
    • Reliability Engineer: โฟกัสที่คุณภาพการปฏิบัติการ, on-call, SLO และ observability
    • Systems Specialist: ผู้เชี่ยวชาญเชิงลึกเฉพาะด้าน เช่น database, security, networking
    • หากให้น้ำหนักฝั่งซอฟต์แวร์มากเกินไป portal ที่สวยงามก็จะพังเมื่อเจอโหลดจริง แต่หากให้น้ำหนักฝั่งระบบมากเกินไปก็จะได้ cluster ที่แข็งแกร่งแต่ไม่มีใครใช้ได้หากไม่เปิดตั๋ว

  • การจ้างงาน

    • ต้องให้ความสำคัญสูงสุดกับ customer empathy ในการจ้าง
    • วิศวกรที่คุยกับนักพัฒนาแอปที่กำลังหงุดหงิดแล้วไม่สามารถออกมาพร้อมความเข้าใจปัญหาอย่างชัดเจนได้ ไม่ใช่คนที่เหมาะ
    • ความเป็นเลิศทางเทคนิคที่ไร้ empathy จะสร้าง แพลตฟอร์มที่ถูกต้องแต่ไม่มีใครใช้
    • สำหรับบทบาทซอฟต์แวร์ให้ใช้ level matrix เดียวกันได้ แต่สำหรับ system specialist ควรอนุญาตให้ใช้ ตำแหน่งงานที่ยืดหยุ่น เพราะมูลค่าตลาดและทักษะไม่ได้แมปเข้ากับสายอาชีพ software engineer ได้อย่างพอดีเสมอไป

  • ผู้จัดการและบทบาทอื่น ๆ

    • ผู้จัดการ Platform Engineering ที่ยอดเยี่ยมมีลักษณะร่วมกันสามอย่าง: ประสบการณ์ดูแลแพลตฟอร์มจริง, ประสบการณ์ส่งมอบโครงการระยะยาวหลายไตรมาส และ ความหมกมุ่นกับรายละเอียด
      • แพลตฟอร์มให้รางวัลกับรายละเอียด และเคส 1% ที่ดูเหมือนเกิดไม่บ่อยมักกินเวลาซัพพอร์ตถึง 80%
    • PM, technical writer, developer advocate และ support engineer ล้วนสำคัญ แต่ควรจ้าง หลังจากทีมวิศวกรรมมีความพร้อมพอสมควรแล้ว
    • PM ที่ถูกใส่เข้ามาเร็วเกินไปในทีมแพลตฟอร์ม 4 คน จะเป็นได้แค่ เก้าอี้ทรง roadmap เท่านั้น

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

  • ลูกค้าภายในยากกว่า

    • ลูกค้าภายในคือ ผู้ใช้แบบ captive ที่ย้ายออกได้ยาก และมักมีความเห็นแรงแต่มีเซนส์ด้านผลิตภัณฑ์ไม่มาก
    • พวกเขาพูดถึงสิ่งที่อยากได้ (want) แต่บ่อยครั้งไม่ตรงกับสิ่งที่จำเป็นจริง ๆ (need)
    • พวกเขามักคาดหวังให้แพลตฟอร์มทำงานแทนตน ไม่ใช่ต้องการเครื่องมือที่จะช่วยให้ทำงานได้ดีขึ้น
    • สิ่งที่เป็น backlog จริงคือการนั่งข้างพวกเขาและสังเกตว่าในการ deploy การเปลี่ยนแปลงหนึ่งครั้ง ต้อง สลับบริบทกี่ครั้ง

  • Discovery, roadmap และ failure mode

    • การทำ platform discovery ควรทำด้วย pilot ไม่ใช่ A/B test โดยทำกับทีมที่เป็นมิตร และวัดการลดลงของ lead time หลัง deploy จริง
    • ขอบฟ้าเวลาทั้งสี่ของ roadmap
      • Vision (หลายปี): ทิศทางของแพลตฟอร์ม
      • Strategy (รายปี): สิ่งที่เดิมพันในปีนี้
      • Goals and Metrics (รายไตรมาส~รายปี): นิยามของความสำเร็จ
      • Milestones (รายไตรมาส): สิ่งที่จะส่งมอบจริง
    • failure mode ที่ทำให้ทีมพังบ่อย
      • ประเมินต้นทุน migration ต่ำเกินไป (มักมากกว่าที่คาดเสมอ 2~3 เท่า)
      • ประเมิน budget สำหรับการเปลี่ยนแปลงของผู้ใช้สูงเกินไป ต่อฟีเจอร์ใหม่
      • ทั้งที่ปัญหาจริงคือความเสถียร แต่กลับไปโฟกัสที่ การเพิ่มฟีเจอร์
      • มี PM มากเกินไป เมื่อเทียบกับขนาดทีมวิศวกรรม (ถ้ามีวิศวกร 5 คนแต่ PM 2 คน ถือว่ามีปัญหา)

การปฏิบัติการแพลตฟอร์ม

  • On-call ไม่ใช่ทางเลือก

    • เพราะทำหน้าที่เป็นรากฐาน จึงต้องมี การดูแลครอบคลุม 24/7 แบบต่อรองไม่ได้
    • แนวคิด "you build it, you run it" ใช้ได้ที่นี่เช่นกัน และนี่ไม่ใช่การลงโทษ แต่เป็น feedback loop
    • ถ้าวิศวกรคนหนึ่งถูก page มากกว่าสัปดาห์ละหลายครั้ง ต้อง แก้ระบบ ไม่ใช่แก้ตารางเวร
    • วิศวกรแพลตฟอร์มที่หมดไฟจะปล่อยแพลตฟอร์มที่แย่

  • การซัพพอร์ต: ครึ่งหนึ่งของงานที่ถูกซ่อนอยู่

    • เป็นเรื่องที่แทบไม่ถูกพูดถึงในคอนเฟอเรนซ์ แต่เป็น ครึ่งสำคัญ ของ platform engineering
    • กรอบการทำงาน 4 ขั้น
      • ขั้นที่ 1: ทำระดับการซัพพอร์ตให้เป็นทางการ (เช่น P0 vs P3, เวลาในการตอบสนอง)
      • ขั้นที่ 2: แยกการซัพพอร์ตที่ไม่สำคัญออกจาก on-call เพื่อไม่ให้คำถามอย่าง "จะเพิ่ม CronJob อย่างไร" ปลุกใครบางคนกลางดึก
      • ขั้นที่ 3: เมื่อปริมาณงานมากพอ จ้าง support specialist โดยเฉพาะ
      • ขั้นที่ 4: สร้าง องค์กร engineering support ที่เหมาะกับขนาด
    • ถ้าข้ามขั้นที่ 1 วิศวกรจะใช้เวลาครึ่งหนึ่งไปกับ ตอบ Slack DM และอีกครึ่งหนึ่งไปกับ การบ่น

  • Feedback ด้านปฏิบัติการ

    • SLO และ SLA เป็นสิ่งจำเป็น ส่วน error budget มีประโยชน์แต่เป็นตัวเลือก
    • Synthetic monitoring ช่วยจับ failure mode ได้ก่อนที่ผู้ใช้จะส่ง ticket
    • การทำ operational review ไม่ใช่แค่เหลือบมอง dashboard สีเขียว แต่ต้อง บังคับให้มีการทบทวนข้อมูลจริง
    • จากข้อมูล DORA 2025 ความสามารถของแพลตฟอร์มที่สัมพันธ์กับประสบการณ์ผู้ใช้สูงที่สุดคือ feedback ที่ชัดเจนต่อผลลัพธ์ของงาน — เมื่อเกิดความล้มเหลว ผู้ใช้ต้องรู้ให้ชัดว่าอะไรล้มเหลว และควรทำอย่างไร

การวางแผนและการส่งมอบ

  • โปรเจกต์ระยะยาวต้องมีข้อเสนอเป็นเอกสาร

    • โปรเจกต์แพลตฟอร์มอย่าง migration, re-architecture, control plane ใหม่ ใช้เวลาเป็น ระดับไตรมาส
    • องค์ประกอบจำเป็นของข้อเสนอที่ดี: ปัญหาที่ต้องการแก้, ผู้ที่จะได้ประโยชน์, ขอบเขต, สิ่งที่อยู่นอกขอบเขตอย่างชัดเจน, นิยามของความสำเร็จ
    • เขียนเอกสารก่อนเขียนโค้ด รับการรีวิวก่อน แล้วค่อยเปลี่ยนเป็น แผนปฏิบัติการที่มี milestone ชัดเจน
    • failure mode แบบ "long slog" — โปรเจกต์ยืดเยื้อหลายปีจนไม่มีใครจำได้แล้วว่าทำไปเพื่ออะไร — แทบจะเป็นผลจากการข้ามขั้นตอนนี้เสมอ

  • การวางแผน roadmap แบบ bottom-up

    • งานสี่ประเภทใน roadmap ของแพลตฟอร์ม: KTLO (keep-the-lights-on), คำสั่งจากผู้นำ, การปรับปรุงระบบที่ทีมตัดสินใจเอง, คำขอจากลูกค้าโดยตรง
    • จะจัดลำดับด้วยความต้องการของลูกค้าอย่างเดียวไม่ได้ โดย KTLO ต้องมาก่อนเป็นอันดับ 1 และคำสั่งเป็นอันดับ 2 ส่วนที่เหลือต้องคุยอย่างตรงไปตรงมากับผู้มีส่วนได้ส่วนเสีย

  • ผลงานและความท้าทายรายสองสัปดาห์ (Biweekly Wins and Challenges)

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

Re-architecture และ migration

  • Re-architecture แทน v2

    • เมื่อแพลตฟอร์มเริ่มเก่า สัญชาตญาณที่ว่า "มาสร้าง v2 กัน" แทบจะผิดเสมอ
    • เหตุผลที่โปรเจกต์ v2 ล้มเหลว: การลงทุนกับ v1 ถูกแช่แข็ง, ใช้เวลานานกว่าที่คาด, และต้นทุน migration ไป v2 สูงกว่าต้นทุน re-architecture ที่พยายามเลี่ยง
    • ควรทำ re-architecture ภายในแพลตฟอร์มเดิม รักษา ความเข้ากันได้ ให้มากที่สุด และใช้ environment ระดับล่าง, rollout แบบช้า ๆ, และ migration แบบ tranche
    • สี่ขั้นของการวางแผน
      • คิดภาพเป้าหมาย architecture สุดท้ายแบบ ให้ใหญ่เข้าไว้
      • คำนึงถึงต้นทุน migration (มากกว่าคาดเสมอ 2~3 เท่า)
      • ระบุ ผลงานหลักใน 12 เดือน ที่จะช่วยให้การลงทุนต่อเนื่องมีเหตุผล
      • ขอความเห็นชอบจากผู้นำ และเตรียมพร้อมที่จะรอ

  • ความปลอดภัยเป็นเรื่องของสถาปัตยกรรม

    • เป็นไปไม่ได้ที่จะมาเติมความปลอดภัยหลังสร้างเสร็จ สถาปัตยกรรมต้องบังคับใช้ least privilege, isolation, traceability ตั้งแต่ตอนออกแบบ
    • ถ้าเป็นแพลตฟอร์มที่ทุกทีมต้องจำ IAM binding ที่ถูกต้องเอง แปลว่าไม่ใช่ทีมที่มีปัญหา แต่คือ แพลตฟอร์มมีบั๊ก

  • Migration: ปัญหายากที่มักถูกประเมินต่ำ

    • anti-pattern ที่พบบ่อยที่สุด
      • แจก clipboard กับ deadline ให้ทุกทีม แล้ว บอกให้ย้ายกันเอง
      • ออกแต่คำสั่ง โดยไม่มี on-ramp และ off-ramp ที่ชัดเจน
      • ประเมิน long tail ต่ำเกินไป ของ use case ที่แปลกเฉพาะทาง
    • วิธีทำ migration engineering ให้ง่ายขึ้น
      • ติดตาม usage metadata เพื่อ รู้ให้ชัดว่าใครยังใช้เวอร์ชันเก่าอยู่
      • ถ้ามี 200 ทีมต้อง migration ให้ ทีมแพลตฟอร์มเขียนสคริปต์ ไม่ใช่โยนให้ทีมแอป
      • ออกแบบสถาปัตยกรรม migration แบบโปร่งใส ที่ระบบใหม่ยังใช้ API เก่า
      • ทำเอกสาร on-ramp ให้ชัดเจนพอที่ทีมใหม่จะ self-service ได้
    • คำสั่งบังคับ (mandate) ได้ผลแค่ครั้งหรือสองครั้ง หลังจากนั้นจะกลายเป็นเสียงรบกวน
    • ในกรณีส่วนใหญ่ ทางที่ดีที่สุดคือทำให้เส้นทางใหม่ดีพอจน เส้นทางเก่าค่อย ๆ เหี่ยวเฉาไปเอง

  • การยุติบริการ (Sunsetting)

    • อย่ากลัวการเลิกผลิตภัณฑ์
    • การมีระบบ deploy ที่แข็งแรง 1 ระบบ ดีกว่ามีระบบ deploy แบบรองรับครึ่ง ๆ กลาง ๆ 7 ระบบ และการยุติบริการคือสัญญาณของทีมที่เป็นผู้ใหญ่

ความสัมพันธ์กับผู้มีส่วนได้ส่วนเสีย

  • Power-Interest Grid

    • ทำแผนที่ผู้มีส่วนได้ส่วนเสียด้วยสองแกนคือ อำนาจ (power) และความสนใจ (interest)
      • อำนาจสูง·ความสนใจสูง: อัปเดตสม่ำเสมอและหารือร่วมกัน
      • อำนาจต่ำ·ความสนใจต่ำ: มีหน้า status page ก็เพียงพอ
    • อย่าเสียเวลาทีมไปกับการส่งข้อมูล Kubernetes upgrade ให้ VP ที่ไม่ได้สนใจมาก

  • สื่อสารอย่างโปร่งใสโดยไม่มากเกินไป

    • โปร่งใสได้แต่ไม่ต้องลงรายละเอียดเกินไป — ผู้บริหารระดับสูงควรรู้ว่า milestone ไปถึงหรือไม่ และมีความเสี่ยงอะไร ไม่ใช่การถกกันเรื่องกลยุทธ์ gRPC retry ทั้งสามแบบ
    • ใช้การประชุม 1:1 อย่างระมัดระวัง และติดตามความคาดหวังกับคำมั่นสัญญาไว้ ในที่ที่มองเห็นได้

  • ปฏิเสธโดยไม่ทำลายความสัมพันธ์

    • ทำ ผลกระทบทางธุรกิจให้ชัดเจน เช่น "ถ้าเพิ่มฟีเจอร์นี้ migration จะเลื่อนออกไปอีกหนึ่งไตรมาส และทำให้บริษัทเสียต้นทุน $X"
    • การ "ตอบรับแบบมีเงื่อนไข", "ปฏิเสธแต่เสนอทางเลือก", และบางครั้งการ ยอมให้มี shadow platform อาจคุ้มกว่าต้นทุนของการสู้กัน
    • ในฤดูกาลจัดงบประมาณ ควรเสนอเป็น ระดับทีมและความสามารถ ไม่ใช่ระดับรายคน และต้องมีจุดยืนชัดเจนว่าจะลดอะไรและรักษาอะไรไว้ — ไม่เช่นนั้น ฝ่ายการเงินจะตัดสินใจแทน และจะตัดสินใจผิด

ภาพของความสำเร็จ

  • แพลตฟอร์มที่สอดประสานกัน (Aligned)

    • ต้องมีการจัดแนวของเป้าหมาย (ทำไมจึงมีอยู่), การจัดแนวของกลยุทธ์ (การเดิมพันสอดคล้องกันระหว่างทีม), และ การจัดแนวของแผนงาน (ไม่มี milestone ชนกัน)
    • เมื่อทุกทีมด้าน runtime ต้องการ Kubernetes และทีม observability พยายามรองรับทุกเฟรมเวิร์ก จะเกิด ความไม่สอดประสานกัน
      • สิ่งนี้จะแสดงออกมาเป็นคู่มือสำหรับลูกค้าที่ขัดแย้งกัน งานซ้ำซ้อน และนักพัฒนาที่ติดอยู่ตรงกลางจนหงุดหงิด
      • แก้ด้วย ภาวะผู้นำที่มีหลักการ ไม่ใช่การหาฉันทามติ (consensus)

  • แพลตฟอร์มที่ได้รับความไว้วางใจ (Trusted)

    • ความไว้วางใจค่อยๆ สะสม แต่ อาจสูญหายจากการย้ายระบบที่แย่เพียงครั้งเดียว
    • ความไว้วางใจเกิดจากวิธีการปฏิบัติการ (การสื่อสารเมื่อเกิดเหตุขัดข้อง, การทำตามที่สัญญาไว้), วิธีการลงทุน (นำการเดิมพันใหญ่ที่ขายไว้ไป deploy จริง), และ ลำดับความสำคัญในการส่งมอบ
    • กรณีของ "แพลตฟอร์มที่ coupled กันแน่นเกินไป (overcoupled platform)": ใส่ custom logic มากเกินไปลงในแพลตฟอร์มจนทุกการเปลี่ยนแปลงใช้เวลาหลายเดือน — ทางแก้ไม่ใช่วิศวกรรมเพิ่ม แต่คือ ท้าทายสมมติฐานเรื่องขอบเขต
      • บางครั้งปัญหาความไว้วางใจไม่ได้เกิดจากทำน้อยเกินไป แต่เกิดจาก ทำมากเกินไป

  • แพลตฟอร์มที่จัดการความซับซ้อนได้

    • ความซับซ้อนของซอฟต์แวร์เป็นสิ่งหลีกเลี่ยงไม่ได้ แต่ ความซับซ้อนโดยบังเอิญ (accidental complexity) ไม่ใช่
    • ต้องแยกให้ออกระหว่างความซับซ้อนของปัญหาที่ลดทอนไม่ได้ กับ ความซับซ้อนโดยบังเอิญ ที่เกิดจากการประสานงานของมนุษย์ที่ล้มเหลว, shadow platform ที่แก้ปัญหาเดิมซ้ำสองครั้ง, และการเติบโตแบบไร้ขีดจำกัด
    • มีคันโยกเชิงปฏิบัติ 3 อย่าง
      • ควบคุมการเติบโต: แพลตฟอร์มที่พยายามรองรับทุกอย่าง จะรองรับอะไรได้ไม่ดีสักอย่าง ต้องระบุขอบเขตให้ชัด
      • ใช้ product discovery ไม่ใช่แค่เพื่อดูว่าจะเพิ่มอะไร แต่เพื่อดูด้วยว่า จะหยุดอะไร
      • จัดการ shadow platform: ถ้าทีมสร้างโซลูชันคู่ขนาน นั่นเป็นสัญญาณว่าแพลตฟอร์มขาดบางอย่างจริง หรือมีใครกำลังขยายอาณาเขตอยู่ — ทั้งสองแบบต้องรับมือ

  • แพลตฟอร์มที่ผู้ใช้รัก (Loved)

    • มีอยู่ 3 รูปแบบ
      • ความรักแบบ "มันใช้งานได้เลย": ผู้ใช้ส่วนใหญ่แทบไม่รู้ตัวว่ามีแพลตฟอร์มอยู่, deploy ได้, CI ผ่าน — ความน่าเบื่อนี่แหละคือคำชมที่ดีที่สุด
      • ความรักแบบ "เหมือนแฮ็ก": ความสุขเล็กๆ อย่างคำสั่ง CLI ที่ทำสิ่งที่ถูกต้องอย่างชัดเจนโดยไม่ต้องอธิบายเพิ่ม
      • ความรักแบบ "เห็นได้ชัด": คะแนนแบบสำรวจ, retention, การยอมรับใช้งานแบบ organic, และการแนะนำแพลตฟอร์มให้ทีมอื่น
    • เมื่อแพลตฟอร์มเป็นที่รัก เวลาไปขอ budget จะมีคน ช่วยสู้แทนคุณ แต่ถ้าแค่พอทนได้ ก็เสี่ยงจะ ถูกแทนที่จาก incident แย่ๆ เพียงครั้งเดียว

ลำดับความสำคัญในภาคปฏิบัติ

  • ลำดับคร่าวๆ เมื่อต้องเริ่มจากศูนย์หรือสร้างใหม่
    • อันดับ 1: ตัดสินใจเรื่องขอบเขตการรองรับ แล้ว บันทึกเป็นเอกสารและปกป้องมัน
    • อันดับ 2: ลงทุนใน software abstraction ไม่ใช่ wiki (ซอฟต์แวร์ที่มี API จริง เช่น Score, Crossplane, SDK ภายในองค์กร)
    • อันดับ 3: สร้าง metadata registry (ใช้ Backstage เป็นต้น เพื่อให้รู้ว่าอะไรทำงานอยู่ที่ไหนและใครเป็นเจ้าของ)
    • อันดับ 4: สร้างเพื่อ ทีมระดับกลางค่อนไปทางทั่วไป ไม่ใช่ทีมที่เสียงดังที่สุด
    • อันดับ 5: ปฏิบัติต่อ operations ให้เป็นความสามารถระดับ first-class เช่น SLO, on-call, support tier
    • อันดับ 6: จ้างคนโดยดู ความสามารถในการเอาใจเขามาใส่ใจเรา พอๆ กับความสามารถด้านระบบ
    • อันดับ 7: สื่อสารอย่างเข้มข้นไร้ปรานี เช่น อัปเดตผลงานและความท้าทายทุกสองสัปดาห์, roadmap ที่โปร่งใส, และการบริหารผู้มีส่วนได้ส่วนเสียอย่างตรงไปตรงมา
    • อันดับ 8: ยุติ, รวม, และปฏิเสธ สิ่งที่ไม่จำเป็น
  • สอดคล้องกับข้อมูล DORA คุณภาพของแพลตฟอร์มคือ ตัวคูณของทุกสิ่ง รวมถึงการนำ AI มาใช้ — แพลตฟอร์มที่แย่จะทำให้เครื่องมือ AI ขยายความสับสน ส่วนแพลตฟอร์มที่ดีจะขยาย throughput
  • ต้องสร้างพื้นก่อน แล้วค่อยสร้างจรวด

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
kalista22 51 분 전

ผมคิดว่าการสื่อสารภายในสำคัญที่สุด