บทสดุดีแด่ DevOps

แนวคิดและประวัติของ DevOps

• DevOps เป็นแนวคิดที่เริ่มนำมาใช้ราวปี 2007 โดยมีเป้าหมายเพื่อขจัดเส้นแบ่งระหว่างคนที่ดูแลฮาร์ดแวร์กับคนที่เขียนซอฟต์แวร์
• ในช่วงแรกเป็นความพยายามเลียนแบบกระบวนการและแนวคิดของ NASA เพื่อเพิ่มความปลอดภัยของการปล่อยโค้ด
• ในเวลานั้น กระบวนการ deploy ซอฟต์แวร์มีลักษณะดังนี้:
  • ทีมพัฒนาจัดเตรียมรีลีสของซอฟต์แวร์เซิร์ฟเวอร์ จากนั้นทีม QA ทดสอบก่อนนำไป deploy ให้ลูกค้า
  • ทีมปฏิบัติการจะได้รับ playbook ที่รวมรายละเอียดการเปลี่ยนแปลงของซอฟต์แวร์และวิธีรับมือเมื่อเกิดปัญหา
  • ค่อย ๆ rollout อัปเดตภายในดาต้าเซ็นเตอร์พร้อมเฝ้าติดตาม
  • กำหนดวัน deploy และติดตามหลัง deploy

ปัญหาของ DevOps

• DevOps ใช้แรงงานเข้มข้นมาก
• ต้องอาศัยความร่วมมือระหว่างทีมพัฒนา ทีม QA นักเขียนเทคนิค และทีมปฏิบัติการ
• การปล่อยฟีเจอร์ทำได้ช้า และอัปเดตสำคัญจะได้รับการจัดลำดับก่อน
• หลายองค์กรนำ DevOps มาใช้ด้วยเหตุผลต่อไปนี้:
  • ไม่สามารถหาคนเทคนิคมาทดแทนได้ง่าย
  • การจ้างงานทำได้ยากและมีต้นทุนสูง
  • ผู้ให้บริการ SaaS ช่วยลดความซับซ้อน
  • มีการเน้นย้ำข้อดีของแพลตฟอร์มคลาวด์
  • นักพัฒนาไม่พอใจกับการต้องรอนานกว่าการเปลี่ยนแปลงเล็กน้อยจะถูก deploy

ภาพความเป็นจริงของ DevOps

• DevOps มีเป้าหมายให้ทีมพัฒนาและทีมปฏิบัติการถูกรวมเป็นทีมเดียว
• ทีม QA ถูกเลิกจ้าง และช่วงเวลาทดสอบภายในลดลงผ่านการ deploy ที่รวดเร็วและการรับ feedback ที่ไวขึ้น
• DevOps มักถูกสับสนกับ SRE ของ Google แต่ SRE มีแนวทางที่เป็นระบบและเข้มงวดกว่า
• กระบวนการจริงของ DevOps มีลักษณะดังนี้:
  • นักพัฒนาสร้าง branch ใน git และเพิ่มฟีเจอร์
  • เปิด PR แล้วให้เพื่อนร่วมทีมรีวิวก่อน merge เข้า main
  • ระบบ CI/CD เริ่ม build และ push คอนเทนเนอร์ไปยัง registry
  • ระบบ CD แจ้งเซิร์ฟเวอร์ถึงรีลีสใหม่ และติดตามว่าการ deploy สำเร็จหรือไม่
  • ติดตามการเปลี่ยนแปลงหลังการ deploy ผ่าน release-awareness metrics

ปัจจัยที่ทำให้ DevOps ล้มเหลว

• นักพัฒนาทดสอบในสภาพแวดล้อม local แล้ว deploy ไปยังเซิร์ฟเวอร์ Linux ทำให้เกิดความแตกต่างเล็กน้อย
• ทีมปฏิบัติการไม่ได้เฝ้าติดตามการ deploy จึงแก้ปัญหาได้ยาก
• นักพัฒนาขาดความรู้เกี่ยวกับการเดินระบบ
• การมาของคอนเทนเนอร์ช่วยแก้บางปัญหาได้ แต่ความซับซ้อนด้านการปฏิบัติการยังคงอยู่

การมาของคอนเทนเนอร์และข้อจำกัด

• คอนเทนเนอร์ช่วยแก้ปัญหา "มันทำงานได้ดีบนเครื่องฉัน"
• ช่วยทำให้องค์ประกอบของเซิร์ฟเวอร์ Linux เรียบง่ายขึ้น
• ปัญหาที่ยังคงเหลืออยู่
  • Operate: ต้องใช้ความเชี่ยวชาญด้านการบำรุงรักษาโครงสร้างพื้นฐาน การอัปเกรด ฯลฯ
  • Observe: สร้างและดูแลระบบมอนิเตอร์ที่ซับซ้อนได้ยาก
  • Continuous feedback: การจัดการ feedback ภายในยังไม่ดีพอ
  • Discover: การแบ่งปันความรู้ระหว่างทีมยังไม่เพียงพอ
  • Plan: การวางแผนแบบรวมศูนย์ทำได้ยาก

การเกิดขึ้นของ Platform Engineering

• Platform Engineering เป็นแนวคิดถัดจาก DevOps โดยแทนที่ทีมพัฒนาจะต้องเข้าใจการดูแลแพลตฟอร์มและแก้ปัญหาเอง ทีมแพลตฟอร์มจะเข้ามารับหน้าที่นี้
• แนวทางนี้แยกความรับผิดชอบของทีมพัฒนาและการปฏิบัติการแพลตฟอร์มอย่างชัดเจน ทำให้บทบาทหน้าที่ชัดขึ้น แต่ก็ยังต้องใช้ทักษะจำนวนมากอยู่ดี
• ทั้งนักพัฒนาและทีมปฏิบัติการต่างก็ต้องทำงานมากขึ้น

บทสรุป

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

ความเห็นของ GN⁺

1. วิวัฒนาการของ DevOps และสถานการณ์ปัจจุบันเป็นกรณีศึกษาที่สะท้อนการเปลี่ยนแปลงของเทรนด์ในอุตสาหกรรมเทคโนโลยีได้อย่างดี กระบวนการรับรู้ช่องว่างระหว่างอุดมคติในช่วงแรกกับความเป็นจริง แล้วค่อย ๆ หาแนวทางที่ใช้งานได้จริงนั้นน่าสนใจ

2. การเปลี่ยนผ่านไปสู่ Platform Engineering ดูเป็นความพยายามที่จะยอมรับข้อจำกัดของ DevOps และมองหาทางออกใหม่ อย่างไรก็ตาม สิ่งนี้ก็ไม่ใช่คำตอบที่สมบูรณ์แบบเช่นกัน และน่าจะต้องใช้แนวทางที่ปรับให้เหมาะกับขนาดและลักษณะของแต่ละองค์กร

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

4. การเปลี่ยนแปลงของ DevOps และ Platform Engineering เน้นย้ำความสำคัญของการเรียนรู้และการปรับตัวอย่างต่อเนื่องในงานพัฒนาและปฏิบัติการซอฟต์แวร์ ผู้เชี่ยวชาญด้านเทคนิคไม่เพียงต้องเรียนรู้เครื่องมือและวิธีการใหม่ ๆ แต่ยังต้องพัฒนาความสามารถในการสร้างสมดุลระหว่างความต้องการทางธุรกิจกับความซับซ้อนทางเทคนิคด้วย

5. คาดว่าแนวทางการพัฒนาและปฏิบัติการซอฟต์แวร์ในอนาคตจะยืดหยุ่นและเหมาะกับบริบทมากยิ่งขึ้น แทนที่องค์กรขนาดใหญ่และสตาร์ตอัปขนาดเล็กจะใช้วิธีเดียวกัน แนวโน้มในการเลือกกระบวนการและเครื่องมือที่เหมาะสมที่สุดกับสถานการณ์ของตนจะยิ่งชัดเจนขึ้น

[kaydash]

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

[GN⁺]

ความคิดเห็นบน Hacker News

• ประเด็นสำคัญคือการโฟกัสที่ "build, test, deploy" ในไดอะแกรม "devops cycle"

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

• เป็นความเห็นที่อิงจากปัญหาที่ทีม devops เผชิญ

  • ควรสามารถเพิ่มบริการใหม่และจัดการอินฟราสตรักเจอร์ได้อย่างปลอดภัย
  • devops กลายเป็นมาตรฐานแล้ว และไม่จำเป็นต้องมีงานผู้ดูแลระบบแบบแมนนวล

• คำวิจารณ์ต่อ Kubernetes นั้นไม่ถูกต้อง

  • Kubernetes เป็นตัวอย่างของวิศวกรรมซอฟต์แวร์ที่ยอดเยี่ยม รองรับดี และรันได้ทุกที่
  • ควรเรียนรู้ Kubernetes แทนการใช้ bash script แบบสุ่ม

• devops คือการลดอุปสรรคเพื่อให้การปล่อยซอฟต์แวร์ง่ายขึ้น

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

• devops เป็นปรัชญา ไม่ใช่วิธีวิทยา

  • จุดประสงค์คือการบูรณาการงานปฏิบัติการเข้ากับ SDLC
  • คลาวด์ทำให้เรื่องนี้ง่ายขึ้น
  • การเกิดขึ้นของทีม "DevOps" ทำให้ปรัชญาดั้งเดิมบิดเบือนไป

• การ "ทลายไซโล" ของฝ่ายผู้นำแทบเป็นเพียงพิธีการ

  • อำนาจที่ไม่มีความรับผิดชอบย่อมไม่เกิดผล
  • คนเก่งด้าน devops ที่ดีที่สุดชอบแทนที่ตัวเองด้วยโค้ด
  • เครื่องมือ devops มีความสมบูรณ์และมีเอกสารที่ดี
  • นักพัฒนาที่ไม่เรียนรู้ Kubernetes ก็เหมือนนักพัฒนาที่ไม่รู้คำสั่ง Linux

• ถ้าผู้ใช้สามารถเป็นผู้ทดสอบได้ ก็ควรทำเช่นนั้น

  • มีแค่ประเด็นด้านเศรษฐศาสตร์เท่านั้น
  • ถ้ามีลูกค้าจำนวนมาก ก็ให้ผู้ใช้ช่วยทดสอบ; ถ้ามีลูกค้าน้อย ก็ต้องทดสอบเอง

• ทีมแพลตฟอร์มเป็นไปได้เฉพาะในองค์กรขนาดใหญ่

  • บริษัทขนาดกลางและเล็กขาดแคลนบุคลากร devops จึงต้องยอมรับความเครียดและความเสี่ยง
  • การไม่มีทีมแพลตฟอร์มก่อให้เกิดปัญหามากมาย

• devops เป็นปรัชญา ไม่ใช่วิธีวิทยา

  • ประสบการณ์ในทีมแบบไซโลพิสูจน์ให้เห็นถึงความจำเป็นของ devops
  • devops ทำให้ทีมเข้าใจโครงการอย่างครบถ้วนและสามารถ deploy ได้

• devops มีเจตนาที่ดี

  • วงจร feedback ที่รวดเร็วมีความสำคัญต่อความเร็วในการพัฒนา
  • ต้องหาทางออกที่เหมาะสมที่สุดกับองค์กรและผลิตภัณฑ์