DevOps และความสามารถในการสังเกตในปี 2020

DevOps Pulse เป็นการวิเคราะห์ประจำปีของอุตสาหกรรม DevOps ดำเนินการโดย logz.io. ข้อค้นพบจากเวอร์ชันปี 2019 เพิ่งได้รับการเผยแพร่และเราใช้โอกาสในการแบ่งปันและแสดงความคิดเห็นกับ Tomer Levy ซีอีโอของ logz.io Levy เป็นผู้ร่วมก่อตั้ง logz.io ในปี 2014 และระดมทุนได้ประมาณ 100 ล้านดอลลาร์ และสร้างทีมที่มีสมาชิก 250 คนจนถึงปัจจุบัน นำเสนอโซลูชันแบบโอเพ่นซอร์สสำหรับการจัดการบันทึก.

การสำรวจในปี 2019 มุ่งเน้นไปที่ความสามารถในการสังเกต โดยนำข้อมูลเชิงลึกของวิศวกร DevOps มาสู่ความหมายของการสร้าง ระบบที่สังเกตได้ วิธีบรรลุผลลัพธ์นั้น และวิธีที่การสังเกตมีส่วนช่วยในการเพิ่มผลิตภัณฑ์ให้สูงสุด ผลงาน. มันอาจช่วยให้มองเห็นอนาคตของการพัฒนาซอฟต์แวร์ในปี 2020 ได้เป็นอย่างดี การพัฒนาซอฟต์แวร์ครั้งแรกผสานเข้ากับการปฏิบัติงาน ทำให้เรามี DevOps แล้ว

DevOps กลายเป็นสิ่งที่ขับเคลื่อนด้วยข้อมูล. อะไรต่อไป?

DevOps คือใคร และมีปัญหาอะไรบ้าง?

ข่าวประชาสัมพันธ์ของ Logz.io เน้นย้ำถึงความนิยมที่เพิ่มขึ้นของความสามารถในการสังเกต ซึ่งเป็นบทบาทเชิงกลยุทธ์ที่ Logz.io เล่น กระบวนการ DevOps และความท้าทายที่ทำให้ทีมไม่สามารถสังเกตได้อย่างเต็มที่ ระบบ ด้วยผู้เข้าร่วมการสำรวจประมาณ 1,000 คน ซึ่งส่วนใหญ่ไม่ใช่ลูกค้าของ logz.io จึงน่าจะมีความใกล้ชิดกับการเป็นตัวแทนของอุตสาหกรรมนี้พอสมควร

สิ่งที่ทำให้เราสนใจคือความหลากหลายของบทบาท (ที่ระบุตัวตนได้) ของผู้ที่ตอบแบบสำรวจ ตั้งแต่ผู้จัดการและผู้อำนวยการไปจนถึงนักพัฒนา วิศวกร DevOps และผู้ดูแลระบบ ครั้งล่าสุดที่เราตรวจสอบ ขอบเขตและความรับผิดชอบที่แบ่งระหว่างบทบาทบางส่วนเหล่านั้นดูเหมือนจะไม่ชัดเจนนัก. ดูเหมือนว่าจะยังคงเป็นเช่นนี้

เนื่องจาก DevOps กลายเป็นกระแสหลัก ทีม R&D จึงแบ่งปันความรับผิดชอบในการสังเกตในบทบาทต่างๆ ทีม DevOps ยังคงรับผิดชอบส่วนใหญ่ในการตรวจสอบให้แน่ใจว่าสามารถสังเกตได้ แต่นักพัฒนาและการปฏิบัติการก็อยู่ไม่ไกลนัก หรืออย่างน้อยนี่คือสิ่งที่ข่าวประชาสัมพันธ์ของ logz.io ระบุไว้ ประสบการณ์ของเราแตกต่างออกไปเล็กน้อย

เราไม่ทราบว่ามีหลายองค์กรที่มีทีม DevOps, นักพัฒนา และทีมปฏิบัติการที่แตกต่างกันและไม่ทับซ้อนกัน (ในแง่ของพนักงาน) บ่อยกว่านั้นที่ผู้คนพูดว่า DevOps พวกเขาหมายถึงการฝึกฝน ไม่ใช่ทีม เพราะในหลาย ๆ องค์กรไม่มีทีม DevOps ที่ทุ่มเท Levy ชี้แจงว่าพวกเขาปล่อยให้ผู้ตอบแบบสอบถามระบุบทบาทของตนในแบบที่พวกเขาต้องการ:

“ผู้ตอบแบบสอบถามหลายคนเรียกบทบาทของตนว่า 'DevOps' แม้ว่าเราจะรู้ดีว่าสำหรับหลายๆ บริษัท DevOps หมายถึงวิธีการอย่างหนึ่ง แต่นอกเหนือจากนั้น ก็มักจะมีทีมที่ได้รับมอบหมายให้ 'เป็นเจ้าของ' มัน ใช่ จากประสบการณ์ของเรา DevOps/SREโดยปกติแล้วทีมแพลตฟอร์ม /Platform จะเป็นเจ้าของหลักของระบบความสามารถในการสังเกต เนื่องจากพวกเขาจะดูแลระบบและกำหนดแนวทาง

ทีมวิศวกรต่างๆ ที่พัฒนาฟีเจอร์และความสามารถมักจะใช้สิ่งเหล่านี้เพื่อให้มองเห็นไมโครบริการ/แอปของตนได้ แต่ไม่ได้เป็นเจ้าของ KPI ความพร้อมใช้งานโดยรวม

ทีมปฏิบัติการมักจะเน้นที่ 'ผู้ดูแลระบบ' มากกว่าและมักจะเป็นส่วนหนึ่งของไอที ​​(ไม่เสมอไป) ดังนั้น เมื่อสถาปัตยกรรมกลายเป็นโปรแกรมมากขึ้นด้วยเครื่องมืออย่าง Terraform และแนวทางปฏิบัติเช่น SRE ความจำเป็นในการดำเนินการด้วยตนเองจึงน้อยลง นอกจากนี้ยังทำให้เกิดความขัดแย้งระหว่างวิศวกรรมและไอที หากฝ่ายปฏิบัติการมักไม่ได้เป็นส่วนหนึ่งของไอที ​​และ SRE/DevOps ก็เป็นส่วนหนึ่งของวิศวกรรม สิ่งนี้จะเพิ่มการเป็นศูนย์กลางของนักพัฒนาที่ฝึกฝน DevOps"

แต่ไม่ว่าใครเป็นคนทำ สิ่งที่เกิดขึ้นจริงใน DevOps ทุกวันนี้คืออะไร? เนื่องจากสภาพแวดล้อมการผลิตมีการกระจายตัวมากขึ้นและเกิดขึ้นชั่วคราว ทีมวิศวกรจะเข้าใจความพร้อมใช้งานและประสิทธิภาพของระบบได้ยากขึ้น Asaf Yigal รองประธานฝ่ายผลิตภัณฑ์ของ Logz.io กล่าว แม้จะมีเครื่องมือตรวจสอบเพิ่มมากขึ้น แต่การมองเห็นระบบการผลิตแบบเรียลไทม์ก็ไม่เคยเป็นเรื่องที่ท้าทายเท่านี้มาก่อน ต่อไปนี้เป็นประเด็นสำคัญบางส่วนจากรายงานที่สนับสนุนมุมมองนี้:

• การแผ่ขยายของเครื่องมือเป็นปัญหาสำคัญและแพร่หลายสำหรับวิศวกรซอฟต์แวร์ หกสิบสามเปอร์เซ็นต์ของผู้ตอบแบบสอบถาม DevOps Pulse รายงานว่าใช้เครื่องมือสังเกตมากกว่าหนึ่งเครื่องมือ ในขณะที่เกือบ 14% ใช้ห้าเครื่องมือขึ้นไป
• การบันทึกเป็นสิ่งสำคัญสำหรับการสังเกต มากกว่า 73% รายงานโดยใช้เครื่องมือการจัดการบันทึกและการวิเคราะห์เพื่อให้สามารถสังเกตได้ การติดตามและแจ้งเตือนโครงสร้างพื้นฐานเกิดขึ้นเป็นอันดับสอง ทั้งสองเรื่องมีประมาณ 40%
• การติดตามแบบกระจายยังไม่ถูกนำมาใช้อย่างสมบูรณ์ หกสิบหกเปอร์เซ็นต์ของผู้ตอบแบบสอบถาม DevOps Pulse ไม่ได้ใช้เครื่องมือติดตามแบบกระจาย แต่ Jaeger เป็นเครื่องมือที่ได้รับความนิยมมากที่สุดในบรรดาผู้ที่นำเทคโนโลยีนี้มาใช้

DevOps ในยุคคลาวด์และการเรียนรู้ของเครื่อง

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

ดูเหมือนว่าจะเป็นการพรรณนาภูมิทัศน์ในปัจจุบันได้ค่อนข้างแม่นยำ แล้วพรุ่งนี้ล่ะ? แมชชีนเลิร์นนิงและระบบคลาวด์เป็นสองเทรนด์ที่สำคัญที่สุดสำหรับปี 2020และใช่ คุณเดาถูกแล้ว พวกมันทิ้งร่องรอยไว้ที่ความสามารถในการสังเกตเช่นกัน

แมชชีนเลิร์นนิงกำลังได้รับแรงผลักดันในฐานะโซลูชันความสามารถในการสังเกต ผู้เข้าร่วม DevOps Pulse เกือบ 40% ใช้หรือกำลังพิจารณาโซลูชันการเรียนรู้ของเครื่องเพื่อปรับปรุงความสามารถในการสังเกต แนวคิดนี้ไม่ใช่เรื่องใหม่ เราได้เห็นมันเป็น ใช้ในการผลิตโดยผู้จำหน่ายอิสระเป็นเวลาอย่างน้อยสองถึงสามปีที่ผ่านมา.

Googles, Microsofts และ Amazons ทั่วโลกทำสิ่งนี้มานานกว่ามากแล้ว แต่ 40% ของผู้ชมกระแสหลักเป็นสัญญาณที่แน่ชัด ไม่ใช่แค่กลุ่มใหญ่บนคลาวด์และกลุ่มผู้ใช้งานในช่วงแรกๆ อีกต่อไป แต่ Machine Learning ก็เข้ามาแทนที่ DevOps ด้วยเช่นกัน

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

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

แต่ด้วยการนำแนวคิดเรื่องเซิร์ฟเวอร์ออกไป และเปลี่ยนโค้ดไปเป็นคอลเลกชันที่หลวมของฟังก์ชันลอยตัวแบบอิสระ Serverless ยังได้นำโครงสร้างและความสามารถในการสังเกตออกไปอีกด้วย Serverless เป็นอุปสรรคทางเทคนิคที่ใหญ่ที่สุดต่อความสามารถในการสังเกต แม้ว่าผู้ตอบแบบสำรวจมากกว่า 40% หันมาใช้ระบบไร้เซิร์ฟเวอร์ แต่ 47% อ้างว่าเทคโนโลยีไร้เซิร์ฟเวอร์ถือเป็นความท้าทายมากที่สุดในการได้รับความสามารถในการสังเกต เลวีเห็นพ้องด้วย:

“ใช่ เราเห็นด้วยว่าการไร้เซิร์ฟเวอร์ทำให้การมองเห็นเป็นเรื่องที่ท้าทาย แม้ว่าเราจะแปลกใจกับขนาดของมันก็ตาม เราประเมินว่าสาเหตุหลักที่การไร้เซิร์ฟเวอร์เป็นเรื่องยากนั้นก็เนื่องมาจากการที่เซิร์ฟเวอร์มีการกระจายตัวอย่างมาก หากคุณคิดถึงไมโครเซอร์วิส คุณอาจมี 20, 50 หรือแม้แต่ 200 เมื่อใช้ Serverless คุณอาจมีฟังก์ชันต่างๆ หลายร้อยฟังก์ชันซึ่งทำให้การเชื่อมต่อจุดต่างๆ ยากยิ่งขึ้น"

มันคือโลก AWS เราแค่อาศัยอยู่ในนั้น

แล้วคน DevOps ต้องทำอะไรบ้าง? บางทีพวกเขาไม่ควรใช้เทคโนโลยีที่ไม่สามารถสังเกตการณ์ได้? เป็นโอเพ่นซอร์สเพื่อช่วยเหลืออีกครั้ง โอเพ่นซอร์สเป็นทางออกที่ดีสำหรับการแก้ไขปัญหาเหล่านี้ Levy กล่าว:

“เมื่ออาศัยตัวเชื่อมต่อโอเพ่นซอร์ส ตัวแยกวิเคราะห์ และแดชบอร์ด ชุมชนนักพัฒนาจะสามารถปรับแต่งความสามารถในการสังเกตสำหรับบริการ AWS ใหม่ทั้งหมดได้อย่างรวดเร็ว ตัวอย่างเช่น หาก AWS เพิ่งเปิดตัวบริการและคุณสมบัติใหม่ประมาณ 200 รายการในช่วงไม่กี่เดือนที่ผ่านมา ไม่มีผู้จำหน่ายรายใดที่สามารถปรับตัวเข้ากับสิ่งนี้ได้เร็วขนาดนี้ ดังนั้นหากฉันเป็นนักพัฒนาและต้องการใช้บริการ AWS ใหม่ในการผลิต ก็เหมาะอย่างยิ่งที่จะสร้างแดชบอร์ด Grafana และ Kibana เพื่อให้มองเห็นบริการเหล่านี้ได้

ที่ Logz.io เราได้สร้างตัวเชื่อมต่อโอเพ่นซอร์สเหล่านี้จำนวนมากและได้รวมตัวแยกวิเคราะห์ที่ผู้ใช้สร้างขึ้นจำนวนมากเพื่อให้ง่ายต่อการสังเกตบริการใหม่ ๆ นอกจากนี้ แอป ELK ของเรายังช่วยให้ผู้ใช้ของเรามีส่วนร่วมและดาวน์โหลดแดชบอร์ดจากชุมชนผู้ใช้ในวงกว้างได้"

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

ยังมีโอกาสที่ดีให้ ปรัชญาการพัฒนาผลิตภัณฑ์ของ AWS และประวัติในการจัดส่งผลิตภัณฑ์ที่เชื่อมต่ออย่างหลวมๆว่าปัญหาเหล่านั้นจะไม่ได้รับการแก้ไขไปสักระยะหนึ่ง ดังนั้นสิ่งที่เกิดขึ้นตอนนี้ก็คือ แทนที่จะรอให้ AWS ทำสิ่งนี้ ชุมชนทำมันฟรี และทุกคนรวมถึง AWS ก็จะได้รับสิทธิประโยชน์

เราไม่รู้จริงๆว่าชุมชนจะมีความสุขกว่านี้หรือไม่ สิ่งที่เรารู้ก็คือ มันเป็นโมเดลธุรกิจที่สะดวกมากสำหรับ AWS ไม่น่าแปลกใจเลยที่ AWS เรียกใช้ช็อตใน DevOps เช่นกัน มันคือโลก AWS เราแค่อาศัยอยู่ในนั้น