จากการพูดคุยสนทนา
เมื่อเร็ว ๆ นี้ การต่อสู้ที่แท้จริงได้ปะทุขึ้นเหนือคำจำกัดความของ DevOps และ SRE
แม้ว่าการอภิปรายในหัวข้อนี้ในหลาย ๆ ด้านจะทำให้ฉันรู้สึกไม่สู้ดี รวมทั้งตัวฉันเองด้วย แต่ฉันตัดสินใจที่จะนำเสนอมุมมองของฉันในหัวข้อนี้ต่อศาลของชุมชน Habra สำหรับผู้ที่สนใจยินดีต้อนรับสู่แมว และปล่อยให้ทุกอย่างเริ่มต้นใหม่!
ประวัติศาสตร์
ดังนั้น ในสมัยโบราณ ทีมนักพัฒนาซอฟต์แวร์และผู้ดูแลเซิร์ฟเวอร์จึงอาศัยอยู่แยกกัน คนแรกเขียนโค้ดได้สำเร็จ ครั้งที่สองใช้คำพูดที่อบอุ่นและน่ารักต่าง ๆ ที่จ่าหน้าถึงคนแรก ตั้งค่าเซิร์ฟเวอร์ มาหานักพัฒนาเป็นระยะ ๆ และได้รับคำตอบที่ครอบคลุม "ทุกอย่างทำงานบนเครื่องของฉัน" ธุรกิจกำลังรอซอฟต์แวร์ ทุกอย่างไม่ได้ใช้งาน พังเป็นระยะ ทุกคนกังวลใจ โดยเฉพาะคนที่ชดใช้เรื่องยุ่งวุ่นวายทั้งหมดนี้ ยุคโคมไฟอันรุ่งโรจน์ คุณรู้อยู่แล้วว่า DevOps มาจากไหน
การกำเนิดของแนวปฏิบัติ DevOps
แล้วคนจริงจังก็เข้ามาบอกว่า - นี่ไม่ใช่อุตสาหกรรมคุณไม่สามารถทำงานแบบนั้นได้ และพวกเขาก็นำแบบจำลองวงจรชีวิตเข้ามา ตัวอย่างเช่น นี่คือรุ่น V
แล้วเราเห็นอะไร? ธุรกิจมาพร้อมกับแนวคิด สถาปนิกออกแบบโซลูชัน นักพัฒนาเขียนโค้ด แล้วก็ล้มเหลว มีคนทดสอบผลิตภัณฑ์ มีคนส่งผลิตภัณฑ์ให้กับผู้ใช้ และบางแห่งที่ผลลัพธ์ของโมเดลมหัศจรรย์นี้มีลูกค้าธุรกิจที่โดดเดี่ยวกำลังรอสภาพอากาศที่สัญญาไว้ริมทะเล เราได้ข้อสรุปว่าเราต้องการวิธีการที่จะช่วยให้เราสร้างกระบวนการนี้ได้ และเราตัดสินใจที่จะสร้างแนวทางปฏิบัติที่จะนำไปปฏิบัติ
การพูดนอกเรื่องโคลงสั้น ๆ ในเรื่องของการปฏิบัติคืออะไร
ในทางปฏิบัติ ฉันหมายถึงการผสมผสานระหว่างเทคโนโลยีและวินัย ตัวอย่างคือการฝึกอธิบายโครงสร้างพื้นฐานโดยใช้โค้ด Terraform ระเบียบวินัยคือการอธิบายโครงสร้างพื้นฐานด้วยโค้ดอย่างไร มันอยู่ในหัวของนักพัฒนา และเทคโนโลยีก็เป็น Terraform นั่นเอง
และพวกเขาตัดสินใจเรียกสิ่งเหล่านี้ว่าแนวปฏิบัติของ DevOps ฉันคิดว่ามันหมายถึงตั้งแต่การพัฒนาไปจนถึงการปฏิบัติการ เราคิดค้นสิ่งที่ชาญฉลาดต่างๆ ขึ้นมา เช่น แนวทางปฏิบัติ CI/CD แนวทางปฏิบัติตามหลักการ IaC นับพันรายการ และทันทีที่นักพัฒนาเขียนโค้ด วิศวกร DevOps เปลี่ยนคำอธิบายของระบบในรูปแบบของโค้ดให้เป็นระบบการทำงาน (ใช่แล้ว โค้ดเป็นเพียงคำอธิบาย แต่ไม่ใช่ศูนย์รวมของระบบ) การส่งมอบยังคงดำเนินต่อไป และอื่น ๆ ผู้ดูแลระบบเมื่อวานนี้ซึ่งเชี่ยวชาญแนวทางปฏิบัติใหม่ ได้รับการฝึกอบรมใหม่อย่างภาคภูมิใจในฐานะวิศวกร DevOps และทุกอย่างก็ดำเนินไปจากจุดนั้น มีเวลาเย็นและเวลาเช้า... ขออภัยไม่ได้มาจากที่นั่น
ทุกอย่างมันไม่ดีอีกแล้ว ขอบคุณพระเจ้า
ทันทีที่ทุกอย่างสงบลง และ “นักวิธีวิทยา” ผู้เจ้าเล่ห์หลายคนเริ่มเขียนหนังสือหนาๆ เกี่ยวกับแนวทางปฏิบัติของ DevOps ข้อพิพาทก็ปะทุขึ้นอย่างเงียบๆ ว่าใครเป็นวิศวกร DevOps ที่โด่งดัง และ DevOps เป็นวัฒนธรรมการผลิต ความไม่พอใจก็เกิดขึ้นอีกครั้ง ทันใดนั้นปรากฎว่าการส่งมอบซอฟต์แวร์เป็นงานที่ไม่สำคัญอย่างยิ่ง โครงสร้างพื้นฐานการพัฒนาแต่ละรายการมีสแต็กของตัวเอง บางแห่งที่คุณต้องประกอบ บางแห่งที่คุณต้องปรับใช้สภาพแวดล้อม ที่นี่คุณต้องใช้ Tomcat ที่นี่คุณต้องมีวิธีที่ชาญฉลาดและซับซ้อนในการเปิดใช้งาน - โดยทั่วไปแล้ว คุณปวดหัวหนักมาก และปัญหาที่น่าแปลกก็คือปัญหาอยู่ที่การจัดกระบวนการเป็นหลัก - ฟังก์ชันการจัดส่งนี้เริ่มบล็อกกระบวนการเช่นเดียวกับคอขวด นอกจากนี้ ยังไม่มีใครยกเลิกปฏิบัติการ มองไม่เห็นในรุ่น V แต่ยังมีวงจรชีวิตทั้งหมดทางด้านขวา ด้วยเหตุนี้ จึงจำเป็นต้องบำรุงรักษาโครงสร้างพื้นฐาน ติดตามตรวจสอบ แก้ไขเหตุการณ์ และจัดการกับการส่งมอบด้วย เหล่านั้น. นั่งด้วยเท้าข้างเดียวทั้งในด้านการพัฒนาและการปฏิบัติการ - และทันใดนั้นมันก็กลายเป็นการพัฒนาและการปฏิบัติการ จากนั้นก็มีกระแสฮือฮาทั่วไปเกี่ยวกับไมโครเซอร์วิส และด้วยเหตุนี้ การพัฒนาจากเครื่องจักรในพื้นที่จึงเริ่มย้ายไปยังระบบคลาวด์ - พยายามแก้ไขข้อบกพร่องบางอย่างในเครื่อง หากมีไมโครเซอร์วิสหลายสิบหรือหลายร้อยรายการ การส่งมอบอย่างต่อเนื่องจะกลายเป็นหนทางแห่งความอยู่รอด สำหรับ “บริษัทเล็กๆ เล็กๆ” ก็โอเคนะ แต่ยังไงล่ะ? แล้วกูเกิ้ลล่ะ?
SRE โดย Google
Google มากินกระบองเพชรที่ใหญ่ที่สุดแล้วตัดสินใจว่าเราไม่ต้องการสิ่งนี้ แต่เราต้องการความน่าเชื่อถือ และต้องมีการจัดการความน่าเชื่อถือ และฉันตัดสินใจว่าเราต้องการผู้เชี่ยวชาญที่จะจัดการความน่าเชื่อถือ ฉันเรียกพวกเขาว่าวิศวกร SR และบอกว่า นั่นก็เพื่อคุณ ทำมันให้ดีเหมือนเคย นี่คือ SLI นี่คือ SLO นี่คือการตรวจสอบ และเขาก็แหย่จมูกของเขาเข้าผ่าตัด และเขาเรียก SRE ว่า "DevOps ที่เชื่อถือได้" ดูเหมือนทุกอย่างจะเรียบร้อยดี แต่มีแฮ็กสกปรกอย่างหนึ่งที่ Google สามารถจ่ายได้ - สำหรับตำแหน่งวิศวกร SR จ้างคนที่เป็นนักพัฒนาที่มีคุณสมบัติเหมาะสมและทำการบ้านเล็กน้อยและเข้าใจการทำงานของระบบการทำงาน ยิ่งไปกว่านั้น Google เองก็มีปัญหาในการจ้างคนประเภทนี้ - ส่วนใหญ่เป็นเพราะที่นี่แข่งขันกับตัวเอง - จำเป็นต้องอธิบายตรรกะทางธุรกิจให้ใครบางคนฟัง การส่งมอบได้รับมอบหมายให้ปล่อยวิศวกร วิศวกร SR จัดการความน่าเชื่อถือ (แน่นอนว่าไม่ใช่โดยตรง แต่โดยการมีอิทธิพลต่อโครงสร้างพื้นฐาน การเปลี่ยนแปลงสถาปัตยกรรม การติดตามการเปลี่ยนแปลงและตัวชี้วัด การจัดการกับเหตุการณ์) เยี่ยมเลย คุณทำได้ . แต่ถ้าคุณไม่ใช่ Google แต่ความน่าเชื่อถือยังคงเป็นปัญหาอยู่ล่ะ?
การพัฒนาแนวคิด DevOps
ทันใดนั้น Docker ก็มาถึง ซึ่งเติบโตมาจาก lxc และจากนั้นระบบการประสานต่างๆ เช่น Docker Swarm และ Kubernetes และวิศวกร DevOps ก็หายใจออก - การผสมผสานแนวทางปฏิบัติทำให้การส่งมอบง่ายขึ้น มันทำให้ง่ายขึ้นจนถึงระดับที่แม้แต่การจ้างบุคคลภายนอกในการส่งมอบให้กับนักพัฒนา - Deployment.yaml คืออะไร การบรรจุหีบห่อช่วยแก้ปัญหาได้ และความสมบูรณ์ของระบบ CI/CD นั้นอยู่ที่ระดับของการเขียนไฟล์เดียวแล้ว นักพัฒนาสามารถจัดการมันเองได้ จากนั้นเราก็เริ่มพูดถึงวิธีที่เราสามารถสร้าง SRE ของเราเองกับ... หรืออย่างน้อยก็กับใครสักคน
SRE ไม่ได้อยู่ใน Google
โอเค เราส่งสินค้าไปแล้ว ดูเหมือนว่าเราจะหายใจออก กลับสู่วันเก่าๆ ที่ดีได้ เมื่อผู้ดูแลระบบเฝ้าดูโหลดของโปรเซสเซอร์ ปรับระบบ และจิบสิ่งที่ไม่อาจเข้าใจจากแก้วอย่างเงียบๆ... หยุดก่อน นี่ไม่ใช่เหตุผลที่เราเริ่มต้นทุกอย่าง (ซึ่งน่าเสียดาย!) ทันใดนั้นปรากฎว่าในแนวทางของ Google เราสามารถนำแนวทางปฏิบัติที่ยอดเยี่ยมมาใช้ได้อย่างง่ายดาย - ไม่ใช่ภาระของตัวประมวลผลที่สำคัญ และไม่ใช่ความถี่ที่เราเปลี่ยนดิสก์ที่นั่น หรือปรับต้นทุนให้เหมาะสมในระบบคลาวด์ แต่ตัวชี้วัดทางธุรกิจก็มีชื่อเสียงเหมือนกัน SLx. และไม่มีใครลบการจัดการโครงสร้างพื้นฐานออกจากพวกเขา และพวกเขาจำเป็นต้องแก้ไขเหตุการณ์ และปฏิบัติหน้าที่เป็นระยะ และโดยทั่วไปจะคอยติดตามกระบวนการทางธุรกิจ เอาล่ะ เริ่มเขียนโปรแกรมทีละน้อยในระดับที่ดี Google กำลังรอคุณอยู่
เพื่อสรุป ทันใดนั้น แต่คุณเบื่อที่จะอ่านแล้วและแทบรอไม่ไหวที่จะถ่มน้ำลายและเขียนถึงผู้เขียนในความคิดเห็นในบทความ DevOps เป็นวิธีปฏิบัติในการส่งมอบมาโดยตลอดและจะเป็นเช่นนี้ และมันจะไม่ไปไหน SRE ซึ่งเป็นชุดของแนวทางปฏิบัติในการปฏิบัติงานทำให้การส่งมอบนี้ประสบความสำเร็จอย่างมาก
ที่มา: will.com