ไม่มีวิศวกร DevOps ใครมีอยู่จริงและจะทำอย่างไรกับมัน?

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

ในโพสต์นี้ ฉันอยากจะพูดคุยเล็กน้อยว่าเรามาถึงจุดนี้ได้อย่างไร จริงๆ แล้ว DevOps คืออะไร และจะทำอย่างไรกับมันในตอนนี้

ตำแหน่งงานว่างดังกล่าวสามารถประณามได้ในทุกวิถีทางที่เป็นไปได้ แต่ความจริงยังคงอยู่: มีตำแหน่งงานว่างมากมาย และนี่คือวิธีการทำงานของตลาดในขณะนี้ เราจัดการประชุม Devops และประกาศอย่างเปิดเผย: “Devอุ๊ปส์ - ไม่ใช่สำหรับวิศวกร DevOps” สิ่งนี้อาจดูแปลกและดุร้ายสำหรับหลาย ๆ คน: ทำไมคนที่ทำกิจกรรมเชิงพาณิชย์โดยสิ้นเชิงจึงขัดแย้งกับตลาด ตอนนี้เราจะอธิบายทุกอย่าง

เกี่ยวกับวัฒนธรรมและกระบวนการ

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

ตัวอย่างเช่น อธิบายความแตกต่างระหว่างผู้ดูแลระบบและแนวทาง SRE ในการจัดการบริการ Google SRE Book อันโด่งดังเริ่มต้นขึ้นแล้ว. มีการศึกษาที่น่าสนใจภายใน แบบสำรวจของดอร่า — เห็นได้ชัดว่านักพัฒนาที่เก่งที่สุดจัดการปรับใช้การเปลี่ยนแปลงใหม่กับการผลิตได้เร็วกว่าชั่วโมงละครั้ง พวกเขาทดสอบด้วยมือไม่เกิน 10% (ดูได้จาก DORA ปีที่แล้ว). พวกเขาทำเช่นนี้ได้อย่างไร? “Excel or die” กล่าวไว้ในหัวข้อรายงาน สำหรับการอภิปรายโดยละเอียดเกี่ยวกับสถิติเหล่านี้ในบริบทของการทดสอบ คุณสามารถดูประเด็นสำคัญของ Baruch Sadogursky “เรามี DevOps เรามายิงผู้ทดสอบทั้งหมดกันเถอะ” ในการประชุม Heisenbug อีกงานหนึ่งของเรา

“เมื่อสหายไม่ตกลงกัน
สิ่งต่างๆ จะไม่เป็นไปด้วยดีสำหรับพวกเขา
และจะไม่มีอะไรออกมาจากนั้น มีแต่ความทรมานเท่านั้น
กาลครั้งหนึ่ง หงส์ กั้ง และหอก..."

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

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

วงจรอุบาทว์

วินัยของ “วิศวกรรมเทโวส์” มาจากไหน? เรามีเวอร์ชั่น! แนวคิด DevOps นั้นดี—ดีมากจนพวกเขากลายเป็นเหยื่อของความสำเร็จของพวกเขาเอง นายหน้าและผู้ค้ามนุษย์ที่ร่มรื่นบางคนซึ่งมีบรรยากาศเป็นของตัวเองเริ่มที่จะหมุนวนไปรอบ ๆ หัวข้อทั้งหมดนี้

ลองนึกภาพ: เมื่อวานคุณกำลังทำ Shawarma ที่ Khimki และวันนี้คุณเป็นชายร่างใหญ่และเป็นนายหน้าอาวุโสแล้ว มีกระบวนการค้นหาและคัดเลือกผู้สมัครทั้งหมดไม่ใช่เรื่องง่ายคุณต้องเข้าใจ สมมติว่าหัวหน้าแผนกพูดว่า: ค้นหาผู้เชี่ยวชาญใน X เรากำหนดคำว่า "วิศวกร" ให้กับ X เท่านี้เราก็เสร็จแล้ว ต้องการลินุกซ์ใช่ไหม? นี่คือวิศวกร Linux แน่นอน หากคุณต้องการ DevOps ก็เป็นวิศวกร DevOps ตำแหน่งที่ว่างไม่เพียงประกอบด้วยชื่อเรื่องเท่านั้น แต่ยังต้องป้อนข้อความบางส่วนไว้ด้านในด้วย วิธีที่ง่ายที่สุดคือการป้อนชุดคำหลักจาก Google ขึ้นอยู่กับจินตนาการของคุณ DevOps ประกอบด้วยคำสองคำ - “Dev” และ “Ops” ซึ่งหมายความว่าเราจำเป็นต้องรวมคำหลักที่เกี่ยวข้องกับนักพัฒนาและผู้ดูแลระบบเข้าด้วยกันทั้งหมดไว้ในกองเดียว นี่คือลักษณะที่ตำแหน่งงานว่างปรากฏขึ้นเกี่ยวกับความสามารถในการเขียนโปรแกรม 42 ภาษาและ 20 ปีของการใช้ Kubernetes และ Swarm พร้อมกัน แผนภาพการทำงาน

นี่คือวิธีที่ภาพลักษณ์ที่ไร้ความหมายและไร้ความปราณีของซูเปอร์ฮีโร่ "devops" บางตัวหยั่งรากลึกในจิตใจของผู้คนซึ่งจะกำหนดให้ทุกคนปรับใช้กับเจนกินส์และความสุขก็จะมาถึง โอ้ถ้าทุกอย่างเรียบง่ายขนาดนี้ “และนี่คือวิธีที่คุณสามารถค้นหาผู้ดูแลระบบ” HR คิด “เป็นคำที่ทันสมัย ​​คำหลักเหมือนกัน พวกเขาควรตกเป็นเหยื่อ”

อุปสงค์ทำให้เกิดอุปทาน และตำแหน่งงานว่างที่ว่างเปล่าเหล่านี้เต็มไปด้วยผู้ดูแลระบบจำนวนมากที่ตระหนักว่า คุณสามารถทำทุกอย่างได้เหมือนเดิม แต่ได้รับมากขึ้นหลายเท่าด้วยการเรียกตัวเองว่า "devops" เช่นเดียวกับที่คุณกำหนดค่าเซิร์ฟเวอร์ผ่าน SSH ด้วยตนเองทีละรายการ คุณจะกำหนดค่าเซิร์ฟเวอร์ต่อไป แต่ตอนนี้นี่เป็นแนวทางปฏิบัติของ Devops นี่เป็นปรากฏการณ์ที่ซับซ้อน ส่วนหนึ่งเกี่ยวข้องกับการประเมินผู้ดูแลระบบแบบคลาสสิกต่ำเกินไปและกระแสเกินจริงเกี่ยวกับ DevOps แต่โดยทั่วไปแล้ว เกิดอะไรขึ้น เกิดขึ้น

ดังนั้นเราจึงมีอุปสงค์และอุปทาน วงจรอุบาทว์ที่กลืนกินตัวมันเอง นี่คือสิ่งที่เรากำลังต่อสู้ (รวมถึงการสร้างการประชุม DevOops)

แน่นอนว่า นอกจากผู้ดูแลระบบที่เปลี่ยนชื่อตัวเองว่า "devops" แล้ว ยังมีผู้เข้าร่วมอื่นๆ อีก เช่น SRE มืออาชีพหรือนักพัฒนาโครงสร้างพื้นฐานตามโค้ด

สิ่งที่ผู้คนทำใน DevOps (จริงๆ)

ดังนั้นคุณจึงต้องการเรียนรู้และประยุกต์ใช้แนวปฏิบัติ DevOps ล่วงหน้า แต่จะทำอย่างไรต้องมองไปในทิศทางใด? แน่นอนว่าคุณไม่ควรพึ่งพาคำหลักยอดนิยมแบบสุ่มสี่สุ่มห้า

ถ้ามีงานก็ต้องมีคนทำ เรารู้แล้วว่าคนเหล่านี้ไม่ใช่ "วิศวกร devops" แล้วใครล่ะ? ดูเหมือนจะถูกต้องมากกว่าที่จะกำหนดสิ่งนี้ไม่ใช่ในแง่ของตำแหน่ง แต่ในแง่ของพื้นที่เฉพาะของงาน

ประการแรก คุณสามารถระบุถึงหัวใจของ DevOps—กระบวนการและวัฒนธรรมได้ วัฒนธรรมเป็นธุรกิจที่ช้าและยาก และถึงแม้ตามธรรมเนียมแล้วจะเป็นความรับผิดชอบของผู้จัดการ แต่ทุกคนก็มีส่วนร่วมไม่ทางใดก็ทางหนึ่ง ตั้งแต่โปรแกรมเมอร์ไปจนถึงผู้ดูแลระบบ สองสามเดือนที่ผ่านมา Tim Lister กล่าวในการให้สัมภาษณ์:

“วัฒนธรรมถูกกำหนดโดยค่านิยมหลักขององค์กร โดยปกติแล้วผู้คนจะไม่สังเกตเห็นสิ่งนี้ แต่เมื่อทำงานด้านการให้คำปรึกษามาหลายปี เราก็มักจะสังเกตเห็นสิ่งนี้ คุณเข้าสู่บริษัทและภายในไม่กี่นาทีคุณก็เริ่มรู้สึกถึงสิ่งที่เกิดขึ้น เราเรียกสิ่งนี้ว่า "รสชาติ" บางครั้งกลิ่นนี้ก็เป็นสิ่งที่ดีจริงๆ บางครั้งก็ทำให้เกิดอาการคลื่นไส้ (...) คุณไม่สามารถเปลี่ยนวัฒนธรรมได้จนกว่าจะเข้าใจถึงคุณค่าและความเชื่อเบื้องหลังการกระทำที่เฉพาะเจาะจง พฤติกรรมสังเกตได้ง่าย แต่การค้นหาความเชื่อนั้นยาก DevOps เป็นเพียงตัวอย่างที่ดีของการที่สิ่งต่างๆ มีความซับซ้อนมากขึ้นเรื่อยๆ”

แน่นอนว่ายังมีส่วนทางเทคนิคของปัญหาด้วย หากโค้ดใหม่ของคุณได้รับการทดสอบในหนึ่งเดือน แต่เปิดตัวเพียงหนึ่งปีต่อมา และเป็นไปไม่ได้จริงที่จะเร่งความเร็วทั้งหมด คุณอาจไม่ปฏิบัติตามแนวปฏิบัติที่ดี แนวปฏิบัติที่ดีได้รับการสนับสนุนจากเครื่องมือที่ดี ตัวอย่างเช่น ด้วยแนวคิดเรื่อง Infrastructure-as-Code ในใจ คุณสามารถใช้อะไรก็ได้ตั้งแต่ AWS CloudFormation และ Terraform ไปจนถึง Chef-Ansible-Puppet คุณจำเป็นต้องรู้และสามารถทำทุกอย่างนี้ได้ และนี่ก็เป็นวินัยทางวิศวกรรมที่ค่อนข้างดีอยู่แล้ว สิ่งสำคัญคืออย่าสับสนระหว่างเหตุกับผล ขั้นแรกคุณต้องทำงานตามหลักการของ SRE จากนั้นจึงนำหลักการเหล่านี้ไปใช้ในรูปแบบของวิธีแก้ปัญหาทางเทคนิคเฉพาะบางประการเท่านั้น ในเวลาเดียวกัน SRE เป็นวิธีการที่ครอบคลุมมากซึ่งไม่ได้บอกวิธีการตั้งค่า Jenkins แต่บอกเกี่ยวกับหลักการพื้นฐานห้าประการ:

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

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

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

ในทางกลับกัน โซลูชัน Cloud Native ก็ได้รับความนิยมอย่างมาก ตามที่กำหนดโดย Cloud Native Computing Foundation ในปัจจุบัน เทคโนโลยี Cloud Native ช่วยให้องค์กรต่างๆ สามารถพัฒนาและรันแอปพลิเคชันที่ปรับขนาดได้ในสภาพแวดล้อมแบบไดนามิกในปัจจุบัน เช่น คลาวด์สาธารณะ ส่วนตัว และไฮบริด ตัวอย่าง ได้แก่ คอนเทนเนอร์ เซอร์วิสเมช ไมโครเซอร์วิส โครงสร้างพื้นฐานที่ไม่เปลี่ยนรูป และ API ที่ประกาศ เทคนิคทั้งหมดนี้ช่วยให้ระบบที่เชื่อมต่ออย่างหลวมๆ ยังคงยืดหยุ่น จัดการได้ และสังเกตได้สูง ระบบอัตโนมัติที่ดีช่วยให้วิศวกรทำการเปลี่ยนแปลงครั้งใหญ่ได้บ่อยครั้งและให้ผลลัพธ์ที่คาดการณ์ได้โดยไม่ทำให้งานน่าเบื่อ ทั้งหมดนี้ได้รับการสนับสนุนโดยกลุ่มเครื่องมือที่มีชื่อเสียง เช่น Docker และ Kubernetes

คำจำกัดความที่ค่อนข้างซับซ้อนและกว้างๆ นี้เกิดจากการที่พื้นที่นั้นค่อนข้างซับซ้อนเช่นกัน ในแง่หนึ่ง เป็นที่ถกเถียงกันอยู่ว่าควรเพิ่มการเปลี่ยนแปลงใหม่ในระบบนี้ค่อนข้างง่าย ในทางกลับกัน หากต้องการทราบวิธีสร้างสภาพแวดล้อมแบบคอนเทนเนอร์ซึ่งมีบริการควบคู่อย่างหลวมๆ อยู่บนโครงสร้างพื้นฐานที่กำหนดโดยซอฟต์แวร์ และส่งมอบที่นั่นโดยใช้ CI/CD ต่อเนื่อง และสร้างแนวทางปฏิบัติ DevOps ทั้งหมดนี้ ทั้งหมดนี้ต้องการข้อมูลเพิ่มเติม มากกว่าหนึ่งคนกินสุนัข

จะทำอย่างไรกับทั้งหมดนี้

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

เรากำลังจัดสัมมนา DevOops 2020 มอสโกซึ่งให้โอกาสในการเจาะลึกสิ่งที่เราเพิ่งพูดถึง มีรายงานหลายกลุ่มสำหรับสิ่งนี้:

• กระบวนการและวัฒนธรรม
• วิศวกรรมความน่าเชื่อถือของไซต์;
• คลาวด์เนทิฟ;

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

แน่นอนว่าในการประชุมคุณไม่สามารถไปสามแทร็กพร้อมกันได้ ดังนั้นเราจึงจัดโปรแกรมในลักษณะที่แต่ละช่วงเวลามีหัวข้อสำหรับทุกรสนิยม

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

• นักพัฒนาที่ทำงานเกี่ยวกับโครงสร้างพื้นฐาน กลุ่มรายงานเกี่ยวกับ SRE และ Cloud Native เหมาะสมที่สุดสำหรับคุณ
• ผู้ดูแลระบบ มันซับซ้อนกว่าที่นี่ DevOops ไม่ได้เกี่ยวกับการบริหารระบบ โชคดีที่มีการประชุม หนังสือ บทความ วิดีโอบนอินเทอร์เน็ต ฯลฯ มากมายในหัวข้อการบริหารระบบ ในทางกลับกัน หากคุณสนใจที่จะพัฒนาตัวเองในแง่ของการทำความเข้าใจวัฒนธรรมและกระบวนการ เรียนรู้เกี่ยวกับเทคโนโลยีคลาวด์ และรายละเอียดการใช้ชีวิตกับ Cloud Native เรายินดีเป็นอย่างยิ่งที่ได้พบคุณ! ลองคิดดู: คุณกำลังทำหน้าที่บริหาร แล้วคุณจะทำอย่างไร? เพื่อหลีกเลี่ยงไม่ให้พบว่าตัวเองตกอยู่ในสถานการณ์ที่ไม่พึงประสงค์อย่างกะทันหัน คุณควรเรียนรู้ตั้งแต่ตอนนี้

มีอีกทางเลือกหนึ่ง: คุณยืนกรานและอ้างว่าคุณเป็นเช่นนั้นต่อไป โดยเฉพาะวิศวกร DevOps และไม่มีอะไรอื่น ไม่ว่ามันจะหมายถึงอะไรก็ตาม ถ้าอย่างนั้นเราคงต้องทำให้คุณผิดหวัง DevOops ไม่ใช่การประชุมสำหรับวิศวกร DevOps!

เลื่อนจาก รายงานโดยคอนสแตนติน ไดเนอร์ ในมิวนิก

DevOops 2020 Moscow จะจัดขึ้นในวันที่ 29-30 เมษายน ที่กรุงมอสโก บัตรมีจำหน่ายแล้ว ซื้อบนเว็บไซต์อย่างเป็นทางการ.

หรือคุณสามารถ ส่งรายงานของคุณ จนถึงวันที่ 8 กุมภาพันธ์ โปรดทราบว่าเมื่อกรอกแบบฟอร์ม คุณต้องเลือกกลุ่มเป้าหมายที่จะได้รับประโยชน์สูงสุดจากรายงานของคุณ (มีเรื่องเซอร์ไพรส์ฝังอยู่ในรายการ).

ที่มา: will.com