DevOps Handbook #1: Introduction

2 min readApr 21, 2018

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

พอ Deploy เยอะ ปัญหาเยอะ Ops ยิ่งยุ่ง งานก็ต้อง priority แต่ก็ทำได้ไม่ดีอีกเพราะฝั่ง Ops มักไม่เห็นธุรกิจเห็นแต่ว่า Dev เร่ง ก็ไม่รู้ใครรีบกว่า รู้แต่ว่าใครด่าแรงสุดก้อได้งานไป ท้ายสุดภาพรวมก็ส่งมอบคุณค่างานให้กับลูกค้าได้ไม่ดี

มีการพูดถึงศัพท์คำนึง ที่รู้สึกว่าน่าสนใจแฮะ และจะใช้ต่อๆไปในหนังสือเล่มนี้ คือคำว่า “Technical Debt” ซึ่ง นิยามว่า

Technical Debt describes how decisions we make lead to problems that get increasingly more difficult to fix over time, continually reducing our available options in the future- even when taken on judiciously, we still incur interest

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

เค้าบอกว่ามันจะมี “Downward spiral” คือ ความวายป่วงของ IT operation ที่มาเป็นลำดับ 3 ขั้น

เรามี IT operation ที่ ซับซ้อนและเปราะบาง ทำให้เราต้องคอยแก้ปัญหาเฉพาะหน้า (workaround) และการแก้นี้ก็สร้างหนี้(Technical debt)ให้ต้องชดใช้ต่อไป
เมื่อต้องชดเชยความเสียหายทางธุรกิจ ก็จะมี project ด่วนที่ต้องรีบทำเพื่อกู้สถานการณ์ (เฮ่ย ชีวิตจริง!!) และความด่วนนี่ก็ทำให้เรายิ่งก่อหนี้ (Technical debt) มากขึ้นไปอีก
สุดท้าย เมื่องานยากขี้น ทุกคนก้อยุ่งขึ้น งานแต่ละงานก้อใช้เวลามากขึ้นทีละน้อย งานในคิวก้อค่อยๆยาวขึ้นๆ ก็ทำงานใช้หนี้กันไปทั้งชาติ นั่นแหละฮะท่านผู้ชม

แต่อย่างน้อยขอให้กำลังใจว่า มันไม่ได้เป็นที่เราที่เดียวนะเอ้อ.. มันเป็นกันทั้งโลกนี่แหละเธอ

อ่านถึงตรงนี้หลายๆคนเริ่มคิดว่าแล้วไอ้ IT operation ที่ว่าดีๆในสมัยใหม่นี้มันจะหน้าตาเป็นยังไง เอาฮะ เริ่มนั่งฝันกันได้เลย คงจะดีนะถ้าเรา……

มี Developers ในทีมเล็กๆ ที่สามารถทำ feature ใหม่ๆได้อย่างอิสระและคล่องตัว
เมื่อ develop แล้วสามารถตรวจสอบความถูกต้องได้ใน production-like environments คือมีที่เทสที่เหมือนจริง (คือ สำหรับ คนใน traditional IT แล้วต้องใช้จินตนาการสูงมาก แทบไม่พบเห็นกัน เพราะมันแพงมาก)
สามารถ deploy code ได้เร็วและปลอดภัย จน code deployment นั้นเป็นเรื่อง ประจำวัน (routine) และคาดการณ์ได้ (predictable)แทนที่จะต้อง deploy ตอนเที่ยงคืนวันศุกร์ก้อสามารถ deploy ได้ กลางวันแสกๆ เฮ้ย..เจ๋ง นี่เป็นครั้งแรกที่ชาว Ops จะได้ทำงานในเวลาปกติเหมือนชาวบ้านเค้า
มี feedback ที่รวดเร็วในทุกๆขั้นของ process รู้ว่าตอนนี้เป็นอะไรยังไงอยู่
ทุกๆ changes ที่ commit มี version control ให้ trace กลับได้
มี automated test ที่ทำงานได้เร็ว ทำให้ developer หาข้อผิดพลาดได้เร็ว
มีการ monitor ตรวจสอบเพื่อให้แน่ใจว่าเราพบปัญหาและแก้ได้เร็ว
ทำงานได้ผ่าน self-service platform เพื่อที่จะไม่ต้องนั่งรอคนอื่นทำให้
การทำงานก็เปลี่ยนจาก culture of fear เป็น trust and collaborative culture คือแทนที่ทุกคนจะกลัวจนไม่อยากแตะต้อง production แต่เป็นการที่ทุกคนได้รับการกระตุ้นให้ take risk ที่เหมาะสมเพื่อพาธุรกิจไปข้างหน้าได้

แล้วทำอย่างไรล่ะ จึงจะมาถึงภาพนี้ได้ เจอกัน episode หน้า เรื่อง The Three ways ฮะ

Note: อันนี้เป็นสรุปจากการอ่านหนังสือ DevOps Handbook อาจมีผิดถูกบ้าง + มีคหสตบ้างเล็กน้อย ถ้าสนใจไปซื้อหาอ่านเล่มจริงกันต่อได้

ติดตามตอนอื่นๆ

DevOps Handbook #1: Introduction

Written by Pasita T