44 คะแนน โดย GN⁺ 2026-01-26 | 8 ความคิดเห็น | แชร์ทาง WhatsApp
  • แม้ในยุคของ agentic coding ความต้องการวิศวกรซอฟต์แวร์กลับมีแนวโน้มเพิ่มขึ้น โดยหัวใจสำคัญอยู่ที่ ความสามารถในการปฏิบัติการและดูแลบริการ ไม่ใช่การเขียนโค้ด
  • การเขียนโค้ดเป็นส่วนที่ ง่ายกว่าเสมอ และสิ่งที่ยากจริงคือ การดูแลให้ระบบทำงานได้อย่างเสถียรในระยะยาว
  • เช่นเดียวกับกรณีของ no-code และสเปรดชีต แม้คนที่ไม่ใช่มืออาชีพก็สร้างเครื่องมือได้ แต่ ภาระของการบำรุงรักษาและการปฏิบัติการ สุดท้ายก็ยังต้องพึ่งพาวิศวกรรมระดับมืออาชีพ
  • ผู้ใช้ไม่ได้ซื้อซอฟต์แวร์ แต่ซื้อ บริการ และซอฟต์แวร์ที่ดีควรทำงานได้โดยแทบไม่รู้สึกถึงการมีอยู่
  • ความเป็นเลิศด้านการปฏิบัติการ (operational excellence) เช่น uptime, อัตราความบกพร่อง, ความเร็วในการกู้คืน, การอัปเดตความปลอดภัย คือหัวใจของความสามารถในการแข่งขันในอนาคต
  • ด้วยเหตุนี้ SRE จึงกำลังขยับมาเป็นศูนย์กลางของวิศวกรรมซอฟต์แวร์

SRE มีแนวโน้มจะกลายเป็นสายงานที่มีการจ้างมากที่สุด

  • เมื่อโค้ดมีต้นทุนถูกลง โครงสร้างการแข่งขันจะเป็นแบบที่ ความเป็นเลิศด้านการปฏิบัติการ เป็นฝ่ายชนะ
  • ใคร ๆ ก็สร้าง greenfield demo ได้ แต่การเดินระบบบริการให้เสถียรต้องอาศัย ขีดความสามารถทางวิศวกรรม
  • "ทุกคนอยากเขียน greenfield demo แต่ไม่มีใครอยากดูแลบริการ"
  • วิศวกรรมซอฟต์แวร์ไม่ใช่แค่การเขียนโปรแกรม แต่คือ การจัดการระบบที่เปลี่ยนแปลงไปตามเวลา

บทเรียนจากยุค no-code และสเปรดชีต

  • Joe ฝ่ายบัญชีลดเวลางานซ้ำ ๆ ที่เคยใช้ 10 ชั่วโมงต่อสัปดาห์ลงเหลือ 1 ชั่วโมง ด้วยเครื่องมือ no-code และแมโครในสเปรดชีต
  • ในช่วงแรกผลลัพธ์ชัดเจนมาก แต่เมื่อเวลาผ่านไป ความซับซ้อนก็เพิ่มขึ้นอย่างรวดเร็ว
    • การเปลี่ยนแปลงของสภาพแวดล้อมธุรกิจ การเปลี่ยนกฎทางบัญชี รวมถึงปัญหาเรื่องไทม์โซนและเวลาออมแสงที่สะสมขึ้น
    • มี edge case ใหม่โผล่ขึ้นมาทุกสัปดาห์ ทำให้ต้อง คอยปรับแต่งและแก้ไขอย่างต่อเนื่อง
  • สุดท้าย Joe ก็กลายเป็นคนที่ ถูกผูกติดกับระบบ ที่ตัวเองสร้างขึ้น
    • แม้ตอนลาพักร้อนก็ยังต้องกังวลเรื่องระบบ และยากที่จะส่งต่อการดูแลให้คนอื่น
    • แค่การรันโค้ดและตรวจผลลัพธ์ก็กลายเป็นสิ่งที่สร้าง ความกังวลและความตึงเครียด

โรคคอมพิวเตอร์ (The Computer Disease)

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

เหตุใดความเป็นเลิศด้านการปฏิบัติการจึงเป็นอนาคต

  • ผู้คนไม่ได้ซื้อซอฟต์แวร์ แต่เป็นการ จ้างบริการที่ช่วยแก้ปัญหาให้
  • ไม่มีใครสนใจกลไกภายในของ iCloud แต่อยากให้รูปภาพ ซิงก์ข้ามอุปกรณ์โดยอัตโนมัติตลอดเวลา
  • ไม่สำคัญว่า Word, Notion, gDocs ถูกสร้างขึ้นอย่างไร สิ่งสำคัญคือ ประสบการณ์ของการเขียนและแชร์ความคิด
  • เมื่อเทียบกับโครงสร้างของเครือข่ายการชำระเงิน สิ่งที่สำคัญกว่าคือ ลาเต้มัทฉะราคา 7 ดอลลาร์จ่ายเงินได้โดยไม่มีปัญหา
  • ซอฟต์แวร์ที่ดีคือซอฟต์แวร์ที่ มองไม่เห็น (ทำงานได้อย่าง เป็นธรรมชาติและไร้แรงเสียดทาน)

โจทย์วิศวกรรมที่ยากจริง

  • 90% แรก ของการสร้างเดโมที่ใช้งานได้เป็นส่วนที่ง่าย ส่วน 190% ที่เหลือ ต่างหากที่สำคัญจริง
  • คำถามที่ต้องตอบจากมุมมองการปฏิบัติการ:
    • uptime เท่าไร
    • อัตราการเกิดข้อบกพร่อง อยู่ในระดับไหน
    • เมื่อเกิดเหตุขัดข้อง ใช้เวลาฟื้นฟูระบบนานแค่ไหน
    • ตรวจพบปัญหาได้ก่อนที่ผู้ใช้จะสังเกตเห็นหรือไม่
    • จัดการ upstream dependency ได้หรือไม่
    • เมื่อผู้ให้บริการภายนอกมีปัญหา ตรวจพบได้ก่อนที่ผู้ใช้จะร้องเรียนหรือไม่
    • ใช้เวลา นานแค่ไหน ในการนำไอเดียที่ผู้ใช้เสนอไปใช้งานจริง
    • ป้องกันไม่ให้วิศวกรทำระบบของกันและกันพังได้หรือไม่
    • มีระบบที่ทำให้วิศวกรเดินหน้าต่อได้โดยที่แอปไม่กลายเป็น ก้อนความยุ่งเหยิง หรือไม่
    • รับมือกับซอฟต์แวร์ที่มีขนาด เกินกว่าที่คนคนเดียวจะเข้าใจทั้งหมดได้ หรือไม่
    • หากเกิดปัญหาใหญ่ในไทม์โซนที่ห่างกัน 12 ชั่วโมงขณะที่วิศวกรกำลังนอนหลับ จะแก้ได้ก่อนที่ผู้ใช้จะยอมแพ้หรือไม่
    • สามารถ กู้คืน จากทั้งเหตุขัดข้องภายในและปัญหาจาก upstream ได้หรือไม่ และข้อมูลสำคัญจะสูญหายหรือไม่
    • มีการทำ อัปเดตความปลอดภัย อย่างสม่ำเสมอหรือไม่
    • ข้อมูลผู้ใช้จะไม่ รั่วไหล ใช่หรือไม่
    • เชื่อถือได้ หรือไม่
    • พึ่งพาได้ หรือไม่
    • มีหลักฐานรองรับความน่าเชื่อถือนั้นหรือไม่
    • สามารถลงนามรับประกันที่มี ผลผูกพันทางกฎหมาย ได้หรือไม่ ว่าซอฟต์แวร์จะทำงานเมื่อจำเป็น
  • สิ่งเหล่านี้ต่างหากคือโจทย์วิศวกรรมที่ยากจริง และ การเขียนโค้ดเป็นเพียงส่วนที่ง่ายกว่า

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

 
pseudojo 2026-01-27

ปฏิกิริยาในคอมเมนต์นี่ 55555 เหมือนคัดแต่งเอาเฉพาะสิ่งที่จำเป็นจากเนื้อหาต้นฉบับมาเลยนะครับ~ อ่านเพลินดีครับ

 
bsh998 2026-01-27

ผลการวิเคราะห์โดย AI ปิ๊บปิ๊บบี๊บ.. มีโอกาส 95% ว่าเป็นบล็อก AI

 
alfenmage 2026-01-27

555 90 190 555

 
roxie 2026-02-03

555555555555

 
sudosudo 2026-01-27

พูดเรื่องอะไรเนี่ย

 
[ความคิดเห็นนี้ถูกซ่อน]
 
[ความคิดเห็นนี้ถูกซ่อน]
 
skageektp 2026-01-26

น่าจะดีกว่านี้ถ้ามีคำอธิบายด้วยว่า SRE คืออะไร