Smashing Podcast ตอนที่ 42 กับ Jeff Smith: DevOps คืออะไร?

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

แสดงหมายเหตุ

• เจฟฟ์บน Twitter
• หนังสือ Operations Anti-Patterns ของ Jeff, DevOps Solutions
• DevOps ที่บรรลุได้

อัพเดทประจำสัปดาห์

• เชื่อมช่องว่างระหว่างนักออกแบบและนักพัฒนา เขียนโดย Matthew Talebi
• React API ที่มีประโยชน์สำหรับการสร้างส่วนประกอบที่ยืดหยุ่นด้วย TypeScript เขียนโดย Gaurav Khanna
• โซลูชัน CSS อัจฉริยะสำหรับความท้าทาย UI ทั่วไปที่เขียนโดย Cosima Mielke
• เคล็ดลับและคำแนะนำสำหรับการประเมินนักออกแบบ UX/UI เขียนโดย Nataliya Sambir
• การแก้ปัญหา CLS ในเว็บไซต์อีคอมเมิร์ซ Next.js-Powered เขียนโดย Arijit Mondal

การถอดเสียง

Drew McLellan: เขาเป็นผู้ปฏิบัติงาน DevOps ที่มุ่งเน้นที่ระดับการใช้งาน DevOps ที่ทำได้ ไม่ว่าคุณจะอยู่ที่ไหนในการเดินทาง เขาเป็นผู้อำนวยการฝ่ายผลิตที่แพลตฟอร์มโฆษณาดิจิทัล Centro ตลอดจนเป็นวิทยากรในที่สาธารณะ แบ่งปันความรู้ DevOps ของเขากับผู้ชมทั่วโลก เขาเป็นผู้เขียนหนังสือ Operations Anti-Patterns, DevOps Solutions for Manning Publishing ซึ่งแสดงวิธีการใช้เทคนิค DevOps ในสภาพแวดล้อมที่ไม่สมบูรณ์ซึ่งนักพัฒนาส่วนใหญ่ทำงาน ดังนั้นเราจึงรู้ว่าเขาเป็นผู้เชี่ยวชาญใน DevOps แต่คุณรู้หรือไม่ George คลูนีย์ถือว่าเขาเป็นผู้ผลิตเครื่องบินกระดาษที่ดีที่สุดในรุ่น? เพื่อนยอดเยี่ยมของฉัน ยินดีต้อนรับเจฟฟ์ สมิธ สวัสดีเจฟฟ์ คุณเป็นอย่างไรบ้าง?

เจฟฟ์ สมิธ: ฉันยอดเยี่ยมมาก ดรูว์ เป็นยังไงบ้าง?

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

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

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

เจฟฟ์: แต่แล้วก็ต้องปรับปรุงงานของเราด้วย เพราะอีกครั้ง ถ้าฉันเข้าใจมุมมองของคุณ และพิจารณาสิ่งนั้นในงานของฉัน มันจะเป็นประโยชน์มากขึ้นสำหรับเราแต่ละคน และมีหลายสิ่งที่ ops สามารถเรียนรู้จากนักพัฒนาในแง่ของระบบอัตโนมัติและวิธีที่เราดำเนินการเกี่ยวกับสิ่งต่างๆ เพื่อให้พวกเขาสามารถทำซ้ำได้อย่างง่ายดาย มันคือการผสมผสานและทักษะนี้ และสิ่งที่คุณเห็นอยู่ตอนนี้คือสิ่งนี้มีผลกับการรวมกลุ่มต่างๆ ดังนั้นคุณจึงได้ยินสิ่งต่างๆ เช่น DevSecOps, DevSecFinOps, DevSecFinHROps มันจะเติบโตและเติบโตและเติบโตต่อไป ดังนั้นจึงเป็นบทเรียนที่เราสามารถแยกแยะได้ทั่วทั้งองค์กร

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

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

Drew: ในฐานะนักพัฒนามืออาชีพ คุณคิดว่าการเข้าใจ DevOps คืออะไรและนำไปใช้หมายความว่าอย่างไร

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

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

Drew: ฉันเห็นความคล้ายคลึงกันมากมายกับวิธีที่คุณกำลังพูดเกี่ยวกับความสัมพันธ์ระหว่าง dev และ ops ตามที่เรามีระหว่างการออกแบบและ dev ซึ่งคุณมีนักออกแบบที่ทำงานเกี่ยวกับอินเทอร์เฟซ หน้าตา และความเข้าใจที่ดี ว่าจะสร้างขึ้นจริงได้อย่างไรในบทบาทการพัฒนา และการนำนักพัฒนาเข้ามาปรึกษาสามารถปรับปรุงโซลูชันโดยรวมได้อย่างแท้จริง เพียงแค่มีการสื่อสารที่ชัดเจนและความเข้าใจในสิ่งที่กันและกันทำ ดูเหมือนว่าจะเป็นหลักการเดียวกันกับที่ใช้กับ DevOps ซึ่งฟังดูดีมากจริงๆ

Drew: เมื่อฉันนึกถึงสิ่งที่ฉันได้ยินเกี่ยวกับ DevOps ฉันได้ยินคำศัพท์เช่น Kubernetes, Docker, Jenkins, CircleCI ฉันเคยได้ยินเกี่ยวกับ Kubernetes มาหลายปีแล้ว ฉันยังไม่รู้ว่ามันคืออะไร แต่จากสิ่งที่คุณพูด ดูเหมือนว่า DevOps ไม่ใช่แค่เกี่ยวกับ … เราไม่ได้แค่พูดถึงเครื่องมือใช่ไหม แต่เพิ่มเติมเกี่ยวกับกระบวนการและวิธีการสื่อสารในเวิร์กโฟลว์ ใช่ไหม

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

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

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

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

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

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

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

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

Drew: … ความสำเร็จในการใช้งาน DevOps ภายในองค์กร

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

เจฟฟ์: แต่มีองค์กรอื่นๆ ที่เป็นบาปที่สำคัญ ใช่ไหม. ถ้าทำแล้วจะประมาณว่า “อ้าว บ้าเหรอ? คุณกำลังทำอะไรอยู่? ไม่มีกรณีทดสอบที่นี่” ใช่ไหม. นั่นคือวัฒนธรรมแม้ว่า นั่นคือวัฒนธรรมที่บังคับให้บรรทัดฐานนั้นพูดว่า "นี่ไม่ใช่สิ่งที่เราทำ"

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

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

เจฟฟ์: ฉันคิดว่าเราทุกคนเคยอยู่ในบริษัทเหล่านั้นมาแล้วแบบว่า “ก็เป็นแบบนี้แหละ และไม่มีใครเปลี่ยนแปลงสิ่งนั้น” ใช่ไหม. คุณไม่ต้องการสิ่งนั้นเพราะโลกเปลี่ยนแปลงตลอดเวลา นั่นเป็นเหตุผลที่เราวางวัฒนธรรมไว้ด้านหน้าและตรงกลาง เพราะพฤติกรรมมากมายภายในองค์กรมีอยู่เพราะวัฒนธรรมที่มีอยู่

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

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

เจฟฟ์: คุณสามารถเปลี่ยนแปลงวัฒนธรรมเหล่านี้ได้ในฐานะผู้มีส่วนร่วมส่วนบุคคล เพียงแค่แสดงความคิดเหล่านี้และพฤติกรรมเหล่านี้ออกมาดังๆ แล้วพูดว่า "นี่คือประโยชน์ที่เราได้รับจากสิ่งนี้" นั่นเป็นเหตุผลที่ฉันคิดว่าวัฒนธรรมต้องมาก่อนเพราะคุณต้องให้ทุกคนเข้ามามีส่วนร่วมในแนวคิดนี้ และพวกเขาต้องเข้าใจว่าในฐานะองค์กร มันจะคุ้มค่าและสนับสนุนมัน

ดริว : ครับ มันคงเป็นวิถีชีวิตฉันเดา

เจฟฟ์: ถูกต้อง

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

Drew: ในการใช้แนวทาง DevOps คุณต้องการทำให้เป็นอัตโนมัติภายในเวิร์กโฟลว์ของคุณประเภทใด และคุณคาดหวังอะไรจากการทำสิ่งต่างๆ ด้วยตนเองให้เสร็จลุล่วง

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

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

เจฟฟ์: แล้วระบุสิ่งเหล่านั้นที่เหมือนกับว่า “เอาล่ะ อะไรคือผลไม้ห้อยต่ำที่เราเพิ่งจะกำจัดได้ ถ้าเราทำให้มันเป็นอัตโนมัติ เราจะทำอะไรได้บ้างเพื่อลดความซับซ้อนของสิ่งนี้” และเกณฑ์บางอย่างก็เป็นความเสี่ยงของกระบวนการ ใช่ไหม. ความล้มเหลวของฐานข้อมูลอัตโนมัตินั้นค่อนข้างน่ากลัวเพราะคุณไม่ได้ทำบ่อยขนาดนั้น และการเปลี่ยนแปลงโครงสร้างพื้นฐาน ใช่ไหม. เราพูดว่า “เราทำสิ่งนี้บ่อยแค่ไหน?” หากเราทำปีละครั้ง ระบบอัตโนมัติอาจไม่คุ้มเลย เพราะมันมีค่าน้อยมาก แต่ถ้าเป็นหนึ่งในสิ่งที่เราได้รับเดือนละ 2-3 ครั้ง โอเค ลองพิจารณาดู ไม่เป็นไร.

เจฟฟ์: ทีนี้ อะไรที่เราสามารถทำได้เพื่อเร่งความเร็วให้เร็วขึ้น? และประเด็นก็คือ เมื่อเราพูดถึงระบบอัตโนมัติ เรากระโดดทันทีว่า “ฉันจะคลิกปุ่ม และทำสิ่งนี้ให้สำเร็จอย่างอัศจรรย์” ใช่ไหม. แต่มีขั้นตอนต่างๆ มากมายที่คุณสามารถทำได้ในระบบอัตโนมัติหากคุณรู้สึกไม่สบายใจ ใช่ไหม. ตัวอย่างเช่น สมมติว่าคุณมี 10 ขั้นตอนกับ 10 คำสั่ง CLI ที่แตกต่างกันซึ่งปกติแล้วคุณจะเรียกใช้ ขั้นตอนแรกของระบบอัตโนมัติของคุณอาจทำได้ง่ายๆ เช่น รันคำสั่งนั้น หรืออย่างน้อยก็แสดงคำสั่งนั้น ใช่ไหม. พูดว่า “เฮ้ นี่คือสิ่งที่ฉันกำลังจะทำ คิดว่าโอเคมั้ย?” "ใช่." "ตกลง. นี่คือผลลัพธ์ที่ฉันได้รับ ให้ฉันไปต่อดีไหม?” "ใช่." "ตกลง. นี่คือผลลัพธ์ที่ฉันได้รับ” ใช่ไหม.

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

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

เจฟฟ์: อีกสิ่งหนึ่งที่เราพิจารณาในแง่ของการพูดถึงระบบอัตโนมัติ แต่คุณค่าอะไรที่เราเพิ่มให้กับกระบวนการเฉพาะ? และนี่เป็นสิ่งสำคัญอย่างยิ่งสำหรับปฏิบัติการ เพราะหลายครั้งที่เจ้าหน้าที่ทำหน้าที่เป็นคนกลางสำหรับกระบวนการ การมีส่วนร่วมของพวกเขาก็ไม่มีอะไรมากไปกว่าการเข้าถึง ใช่ไหม. มันเหมือนกับว่า ops ต้องทำเพราะ ops เป็นคนเดียวที่เข้าถึงได้

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

เจฟฟ์: ตัวอย่างเช่น เรามีกระบวนการที่ผู้คนจำเป็นต้องเรียกใช้สคริปต์เฉพาะกิจ Ruby ในการผลิต ไม่ว่าจะด้วยเหตุผลใดก็ตาม ใช่ไหม. ต้องการล้างข้อมูล ต้องแก้ไขบันทึกที่ไม่ดี อะไรก็ตาม และนั่นจะมาจากทีมของฉันเสมอ และเหมือนกับว่า เราไม่ได้เพิ่มมูลค่าใดๆ ให้กับสิ่งนี้ เพราะฉันไม่สามารถอนุมัติตั๋วนี้ได้ ใช่ไหม. ฉันไม่รู้. คุณเขียนซอฟต์แวร์ขึ้นมา แล้วฉันจะนั่งทับไหล่คุณแล้วพูดว่า "ฉันว่ามันปลอดภัยดีไหม" ใช่ไหม. ฉันไม่ได้เพิ่มคุณค่าใด ๆ ให้กับการพิมพ์เพราะฉันแค่พิมพ์ตามที่คุณบอกให้พิมพ์เท่านั้น ใช่ไหม.

เจฟฟ์: และกรณีที่เลวร้ายที่สุด และท้ายที่สุด ฉันเป็นเพียงสิ่งกีดขวางบนถนนสำหรับคุณ เพราะคุณกำลังส่งตั๋ว แล้วคุณก็รอให้ฉันกลับจากมื้อเที่ยง ฉันกลับมาจากมื้อเที่ยงแล้ว แต่ฉันยังมีอย่างอื่นที่ต้องทำ เรากล่าวว่า "เราจะทำให้สิ่งนี้เป็นอัตโนมัติได้อย่างไร เพื่อให้เราสามารถส่งมอบสิ่งนี้ในมือของนักพัฒนา ในขณะเดียวกันก็จัดการกับข้อกังวลด้านการตรวจสอบที่เราอาจมี"

เจฟ: เราใส่ไว้ในเวิร์กโฟลว์ของ JIRA โดยที่เรามีบอทที่จะสั่งการอัตโนมัติตามที่ระบุไว้ในตั๋ว JIRA จากนั้นเราสามารถระบุในตั๋ว JIRA ได้ว่าต้องได้รับการอนุมัติจากหนึ่งในวิศวกรอาวุโสหลายคน ใช่ไหม.

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

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

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

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

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

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

เจฟฟ์: นั่นเป็นการทรงตัวที่ยาก ใช่ไหม. และฉันมักจะพูดเป็นกรณีไป และเหตุผลที่ฉันพูดอย่างนั้นก็คือ มนต์อย่างหนึ่งใน DevOps ก็คือหากมีอะไรที่เจ็บปวด ให้ทำบ่อยขึ้น ใช่ไหม. เพราะยิ่งทำบ่อยเท่าไหร่ ความจำของกล้ามเนื้อก็จะยิ่งมากขึ้นเท่านั้น และคุณจะได้ออกกำลังกายและขจัดปัญหาเหล่านั้น

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

Drew: แล้วคุณมีปัญหาสองข้อ

เจฟฟ์: ถูกต้อง ใช่ไหม. อย่างแน่นอน. อย่างแน่นอน. และคุณก็แบบว่า “ฉันพิมพ์ผิดเหรอ? หรือนี่คือ? ไม่สิ สิ่งนี้มันพังไปแล้วจริงๆ” ดังนั้น-

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

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

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

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

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

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

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

Drew: So while sort of monitoring and using metrics as a decision-making tool for the businesses is one aspect of it, it sounds like the primary aspect is having the system monitor itself, perhaps, and to respond maybe with some of these automations as the system as a whole gives itself feedback on onto what's happening.

Jeff: Absolutely. Feedback loops are a key part of any real system design, right, and understanding the state of the system at any one time. So while it's easy in the world where everything is working fine, the minute something goes bad, those sorts of dashboards and metrics are invaluable to have, and you'll quickly be able to identify things that you have not instrumented appropriately. ใช่ไหม. So one of the things that we always talk about in incident management is what questions did you have for the system that couldn't be answered, right. So what is it, or you're like, “Oh man, if we only knew how many queries per second were going on right now.” ใช่ไหม.

Jeff: Well, okay. How do we get that for next time? How do we make sure that that's radiated somewhere? And a lot of times it's hard when you're thinking green field to sit down and think of all the data that you might want at any one time. But when you have an incident, it becomes readily apparent what data you wish you had. So it's important to sort of leverage those incidents and failures and get a better understanding of information that's missing so that you can improve your incident management process and your metrics and dashboarding.

Drew: One of the problems we sometimes face in development is that teammate members, individual team members hold a lot of knowledge about how a system works and if they leave the company or if they're out sick or on vacation, that knowledge isn't accessible to the rest of the team. It seems like the sort of DevOps approach to things is good at capturing a lot of that operational knowledge and building it into systems. So that sort of scenario where an individual has got all the information in their head that doesn't happen so much. เป็นการประเมินที่ยุติธรรมหรือไม่?

Jeff: It is. I think we've probably, I think as an industry we might have overstated its efficacy. And the only reason I say that is when our systems are getting so complicated, right? Gone are the days where someone has the entire system in their head and can understand it from beginning to end. Typically, there's two insidious parts of it. One, people typically focus on one specific area and someone doesn't have the whole picture, but what's even more insidious is that we think we understand how the system works. ใช่ไหม. And it's not until an incident happens that the mental model that we have of the system and the reality of the system come into conflict. And we realize that there's a divergence, right? So I think it's important that we continuously share knowledge in whatever form is efficient for folks, whether it be lunch and learns, documentation, I don't know, presentations, anything like that to sort of share and radiate that knowledge.

Jeff: But we also have to prepare and we have to prepare and define a reality where people may not completely understand how the system works. ใช่ไหม. And the reason I think it's important that we acknowledge that is because you can make a lot of bad decisions thinking you know how the system behaves and being 100% wrong. ใช่ไหม. So having the wherewithal to understand, okay, we think this is how the system works. We should take an extra second to verify that somehow. ใช่ไหม. I think that's super important in these complicated environments in these sprawling complex microservice environments. Whereas it can be very, it's easy to be cavalier if you think, oh yeah, this is definitely how it works. And I'm going to go ahead and shut the service down because everything's going to be fine. And then everything topples over. So just even being aware of the idea that, you know what, we may not know a hundred percent how this thing works.

Jeff: So let's take that into account with every decision that we make. I think that's key. And I think it's important for management to understand the reality of that as well because for management, it's easy for us to sit down and say, “Why didn't we know exactly how this thing was going to fail?” And it's like, because it's complicated, right, because there's 500 touch points, right, where these things are interacting. And if you change one of them, it changes the entire communication pattern. So it's hard and it's not getting any easier because we're getting excited about things like microservices. We're getting excited about things like Kubernetes. We're giving people more autonomy and these are just creating more and more complicated interfaces into these systems that we're managing. And it's becoming harder and harder for anyone to truly understand them in their entirety.

Drew: We've talked a lot about a professional context, big organizations and small organizations too. But I know many of us work on smaller side projects or maybe we volunteer on projects and maybe you're helping out someone in the community or a church or those sorts of things. Can a DevOps approach benefit those smaller projects or is it just really best left to big organizations to implement?

Jeff: I think DevOps can absolutely benefit those smaller projects. And specifically, because I think sort of some of the benefits that we've talked about get amplified in those smaller projects. ใช่ไหม? So exporting of expertise with automation is a big one, right? If I am… Take your church example, I think is a great one, right? If I can build a bunch of automated tests suites to verify that a change to some HTML doesn't break the entire website, right, I can export that expertise so that I can give it to a content creator who has no technical knowledge whatsoever. ใช่ไหม. They're a theologian or whatever, and they just want to update a new Bible verse or something, right. But I can export that expertise so that they know that I know when I make this content change, I'm supposed to run this build button.

Jeff: And if it's green, then I'm okay. And if it's red, then I know I screwed something up. ใช่ไหม. So you could be doing any manner of testing in there that is extremely complicated. ใช่ไหม. It might even be something as simple as like, hey, there's a new version of this plugin. And when you deploy, it's going to break this thing. ใช่ไหม. So it has nothing to do with the content, but it's at least a red mark for this content creator to say “Oh, something bad happened. I shouldn't continue. ใช่ไหม. Let me get Drew on the phone and see what's going on.” ใช่ไหม. And Drew can say, “Oh right. This plugin is upgraded, but it's not compatible with our current version of WordPress or whatever.” ใช่ไหม. So that's the sort of value that we can add with some of these DevOps practices, even in a small context, I would say specifically around automation and specifically around some of the cultural aspects too.

Jeff: Right? So I've been impressed with the number of organizations that are not technical that are using get to make changes to everything. ใช่ไหม. And they don't really know what they're doing. They just know, well, this is what we do. This is the culture. And I add this really detailed commit message here. And then I push it. They are no better than us developers. They know three get commands, but it's the ones they use over and over and over again. But it's been embedded culturally and that's how things are done. So everyone sort of rallies around that and the people that are technical can take that pattern.

Jeff: … around that and the people that are technical can take that pattern and leverage it into more beneficial things that might even be behind the scenes that they don't necessarily see. So I think there's some value, definitely. It's a matter of how deep you want to go, even with the operations piece, right? Like being able to recreate a WordPress environment locally very easily, with something like Docker. They may not understand the technology or anything, but if they run Docker Compose Up or whatever, and suddenly they're working on their local environment, that's hugely beneficial for them and they don't really need to understand all the stuff behind it. In that case, it's worthwhile, because again, you're exporting that expertise.

Drew: We mentioned right at the beginning, sort of putting off as much sort of DevOps as possible. You mentioned using tools like Heroku. And I guess that sort of approach would really apply here on getting started with, with a small project. What sort things can platforms like Heroku offer? I mean, obviously, I know you're not a Heroku expert or representative or anything, but those sorts of platforms, what sort of tools are they offering that would help in this context?

Jeff: So for one, they're basically taking that operational context for you and they're really boiling it down into a handful of knobs and levers, right? So I think what it offers is one, it offers a very clear set of what we call the yellow brick road path, where it's like, “If you go this route, all of this stuff is going to be handled for you and it's going to make your life easier. If you want to go another route, you can, but then you got to solve for all this stuff yourself.” So following the yellow brick road route helps because one, they're probably identifying a bunch of things that you hadn't even thought of. So if you're using their database container or technology, guess what? You're going to get a bunch of their metrics for free. You're going to get a lot of their alerting for free. You didn't do anything. You didn't think anything. It's just when you need it, it's there. And it's like, “Oh wow, that's super are helpful.”

Jeff: Two, when it comes to performance sizing and flexibility, this becomes very easy to sort of manage because the goal is, you're a startup that's going to become wildly successful. You're going to have hockey stick growth. And the last thing you necessarily really want to be doing is figuring out how to optimize your code for performance, while at the same time delivering new features. So maybe you spend your way out of it. You say, “Well, we're going to go up to the next tier. I could optimize my query code, but it's much more efficient for me to be spending time building this next feature that's going to bring in this new batch of users, so let's just go up to the next tier,” and you click button and you move on.

Jeff: So being able to sort of spend your way out of certain problems, I think it's hugely beneficial because tech debt gets a bad rap, but tech debt is no different than any debt. It's the trade off of acquiring something now and dealing with the pain later. And that's a strategic decision that you have to make in every organization. So unchecked tech debt is bad, right? But tech debt generally, I think, is a business choice and Heroku and platforms like that enable you to make that choice when it comes to infrastructure and performance.

Drew: You've written a book, Operations, Anti-Patterns, DevOps Solutions, for Manning. I can tell it's packed with years of hard-earned experience. The knowledge sort of just leaps out from the page. And I can tell it's been a real labor of love. It's packed full of information. Who's your sort of intended audience for that book? Is it mostly those who are already working in DevOps, or is it got a broader-

Jeff: It's got a broader… So one of the motivations for the book was that there were plenty of books for people that we're already doing DevOps. คุณรู้ว่าฉันหมายถึงอะไร? So we were kind of talking to ourselves and high-fiving each other, like, “Yeah, we're so advanced. Awesome.” But what I really wanted to write the book for were people that were sort of stuck in these organizations. I don't want to use the term stuck. That's unfair, but are in these organizations that maybe aren't adopting DevOps practices or aren't at the forefront of technology, or aren't necessarily cavalier about blowing up the way they do work today, and changing things.

เจฟฟ์: ฉันต้องการเขียนถึงพวกเขา ส่วนใหญ่เป็นผู้ร่วมให้ข้อมูลและผู้จัดการระดับกลางเพื่อพูดว่า "คุณไม่จำเป็นต้องเป็น CTO เพื่อที่จะทำการเปลี่ยนแปลงที่เพิ่มขึ้นเหล่านี้ และคุณไม่จำเป็นต้องมีสิ่งนี้ การปฏิวัติการขายทั้งหมดเพื่อให้ได้รับประโยชน์จาก DevOps” ดังนั้นจึงเป็นจดหมายรักที่พวกเขาพูดว่า “เฮ้ คุณสามารถทำเป็นชิ้น ๆ ได้ คุณสามารถทำได้ด้วยตัวเอง และมีทุกสิ่งเหล่านี้ที่คุณอาจไม่คิดว่าเกี่ยวข้องกับ DevOps เพราะคุณคิดว่ามันเป็นเครื่องมือและ Kubernetes” ไม่ใช่ทุกองค์กร... ถ้าคุณอยู่ในรัฐนิวยอร์กแห่งนี้ เช่นเดียวกับรัฐบาลของรัฐ คุณจะไม่เพียงแค่เข้ามาใช้ Kubernetes ในชั่วข้ามคืน ใช่ไหม? แต่คุณสามารถใช้วิธีที่ทีมพูดคุยกัน วิธีการทำงานร่วมกัน วิธีที่เราเข้าใจปัญหาของกันและกัน และวิธีที่เราจะจัดการกับปัญหาเหล่านั้นผ่านระบบอัตโนมัติ สิ่งเหล่านี้คือสิ่งที่อยู่ในขอบเขตอิทธิพลของคุณที่สามารถปรับปรุงชีวิตประจำวันของคุณได้

เจฟฟ์: นั่นเป็นจดหมายถึงคนพวกนั้นจริงๆ แต่ฉันคิดว่ามีข้อมูลเพียงพอในนั้นและข้อมูลเพียงพอสำหรับคนที่อยู่ในองค์กร DevOps ที่จะรวบรวมและพูดว่า "นี่ยังมีประโยชน์สำหรับเราอยู่ ” และหลายคน ฉันคิดว่าสามารถระบุได้อย่างรวดเร็วโดยการอ่านหนังสือ ว่าพวกเขาไม่ได้อยู่ในองค์กร DevOps พวกเขาเพิ่งมีการเปลี่ยนชื่องาน และนั่นก็เกิดขึ้นไม่น้อย ดังนั้นพวกเขาจึงพูดว่า "เฮ้ เราเป็นวิศวกร DevOps แล้ว แต่เราไม่ได้ทำแนวปฏิบัติที่พูดถึงในหนังสือเล่มนี้แล้วเราจะไปที่นั่นได้อย่างไร"

Drew: ดูเหมือนว่าหนังสือของคุณเป็นหนึ่งในนั้น แต่มีแหล่งข้อมูลอื่นๆ ที่ผู้คนต้องการเริ่มต้นใช้งาน DevOps หันไปหาไหม มีสถานที่ที่ดีในการเรียนรู้สิ่งนี้หรือไม่?

เจฟฟ์: ครับ ฉันคิดว่า DevOps For Dummies โดย Emily Freeman เป็นจุดเริ่มต้นที่ดี มันทำงานได้ดีมากในการจัดวางแนวคิดและแนวคิดหลักบางอย่าง และสิ่งที่เราพยายามทำเพื่ออะไร นั่นจะเป็นจุดเริ่มต้นที่ดี เพียงเพื่อหาที่ดินผืนหนึ่ง ฉันคิดว่าโครงการฟีนิกซ์เป็นแหล่งที่ดีอีกแหล่งหนึ่งโดยยีน คิม และนั่นก็เยี่ยมมาก ประเภทของปัญหาที่ไม่ได้อยู่ในสภาพแวดล้อม DevOps สามารถสร้างได้ และเป็นการเน้นย้ำรูปแบบและบุคลิกภาพเหล่านี้ที่เราเห็นในองค์กรทุกประเภทครั้งแล้วครั้งเล่าได้เป็นอย่างดี ฉันคิดว่ามันทำได้ดีมากในการเน้นย้ำสิ่งเหล่านั้น และถ้าคุณอ่านหนังสือเล่มนั้น ฉันคิดว่าคุณจะต้องกรีดร้องที่หน้าเพจว่า “ใช่ ใช่ นี้. นี้." นั่นเป็นอีกสถานที่ที่ยอดเยี่ยม

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

Drew: ดังนั้น ฉันได้เรียนรู้ทุกอย่างเกี่ยวกับ DevOps แล้ว คุณได้เรียนรู้อะไรเมื่อเร็ว ๆ นี้เจฟฟ์?

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

เจฟฟ์: มันซับซ้อนอย่างไม่น่าเชื่อ และมันเป็นชิ้นใหญ่ที่จะกัดออก อยากรู้ว่า Deploy หน้าตาเป็นอย่างไร? เราจะใช้ประโยชน์จากโอเปอเรเตอร์เหล่านี้ภายใน Kubernetes ได้อย่างไร CICD มีลักษณะอย่างไรในโลกใหม่นี้? มีการอ่านจำนวนมาก แต่ในสาขานี้ คุณเรียนรู้อย่างต่อเนื่องใช่ไหม ไม่สำคัญหรอกว่าคุณอยู่ในนั้นมานานแค่ไหน นานแค่ไหนที่คุณทำมัน คุณเป็นคนงี่เง่าในบางแง่มุมของสาขานี้ ดังนั้น มันเป็นแค่บางอย่างที่คุณปรับตัวเข้ากับมันได้

Drew: อย่างที่ฉันพูด แม้ว่าจะผ่านไปหลายปีแล้ว แม้ว่าฉันจะเข้าใจว่ามันอยู่ตรงไหนในกองซ้อน แต่ฉันก็ยังไม่รู้ว่า Kubernetes กำลังทำอะไรอยู่

เจฟฟ์: ฉันรู้สึกคล้ายกันในบางครั้ง รู้สึกเหมือนทำทุกอย่างนิดหน่อยใช่ไหม? เป็น DNS แห่งศตวรรษที่ 21

ดรูว์: หากคุณผู้ฟังต้องการฟังเรื่องราวเพิ่มเติมจากเจฟฟ์ คุณสามารถพบเขาบน Twitter ซึ่งเขาดูมืดมนและเนิร์ด และค้นหาหนังสือของเขาและลิงก์ไปยังงานนำเสนอที่ผ่านมาและโพสต์บนบล็อกที่ไซต์ของเขาที่ attainabledevops.com ขอบคุณที่เข้าร่วมกับเราในวันนี้ เจฟ คุณมีคำพรากจากกันบ้างไหม?

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