หลักสูตร Crash ใน Dev for Ops?

10

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

ถ้าฉันเรียนรู้วันนี้ฉันถูกย้ายไปที่ทีมพัฒนาในวันจันทร์ฉันจะอ่านอะไรในสุดสัปดาห์นี้

— สตีเฟ่นซี
แหล่งที่มา

3

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

— Pierre.Vriens

@ Pierre.Vriens ความคิดเห็นเฮฮา มั่นใจได้ว่านี่จะไม่เกิดขึ้นจริงหรือฉันกำลังยุ่งอยู่กับบัญชี LinkedIn ของฉันในตอนนี้ แต่ฉันไม่คิดว่าการย้ายแบบนี้น่าจะเป็นวันพิเศษ บางองค์กรอาจได้รับประโยชน์จริง ๆ โดยการแลกเปลี่ยนพนักงานบางคนระหว่างทีม dev และ ops และฉันแน่ใจว่าบางองค์กรทำเช่นนั้นในระหว่างไดรฟ์เพื่อ "ใช้งาน DevOps"

— สตีเฟนซี

8

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

ฉันอาจเริ่มต้นด้วย "The DevOps Handbook"; มันเป็นภาพรวมที่ดีของสิ่งต่าง ๆ ที่ควรพิจารณาโดยไม่ต้องดำน้ำลึกเกินไป

"การจัดส่งต่อเนื่อง" โดย Jez Humble ก็มักจะอ้างถึงเช่นกัน ฉันยังไม่ได้อ่านมาก แต่ครอบคลุมแนวคิดของการควบคุมแหล่งที่มาและระบบอัตโนมัติของการสร้าง

หากคุณเริ่มใช้งานแอปพลิเคชั่นในระดับ (อาจเป็นข้อสันนิษฐานที่มากเกินไป) หนังสือดีอีกเล่มหนึ่งคือ "การปฏิบัติของการบริหารระบบคลาวด์" โดย Limoncelli และคณะ

— Stuart Ainsworth
แหล่งที่มา

1

ฉันอ่านหนังสือ Limoncelli ประมาณ 60% ก่อนที่จะทำมันหาย แน่นอนมันสอนฉันมาก ฉันเพิ่งเริ่ม "The Phoenix Project" โดย Gene Kim et al. ซึ่งเป็นการอ่านที่น่าสนใจอย่างน่าประหลาดใจขณะเดียวกันก็สอนมาก ๆ

— สตีเฟ่นซี

ฉันชอบหนังสือ Google SRE ด้วย จริงๆแล้วมันเป็นแบบที่ดีกว่าสำหรับฉันในองค์กรของฉันมากกว่าบางอย่างของ DevOps แต่ตัวเล่มเองก็ไม่ปะติดปะต่อ คุณต้องอ่านมันให้เรียบร้อยหยิบบทที่คุณสนใจและอ่านส่วนที่เหลือ

— Stuart Ainsworth

7

มันไม่เกี่ยวกับ DevOps แต่ฉันคิดว่าการพัฒนาซอฟต์แวร์แบบตรง

ฉันต้องการเข้าใจวัฒนธรรมที่ดีขึ้น

สิ่งที่ยิ่งใหญ่ในการพัฒนาอย่างตรงไปตรงมา (โดยไม่มีมุม "DevOps") นั้นแน่นอนว่า "ว่องไว" นั่นคือ SCRUM ส่วนใหญ่ คุณอาจจะแย่ไปกว่าการนั่งลงและอ่าน Agile Manifesto หรือ Primer บน SCRUM หรือ Kanban สำหรับงานประจำวันมากขึ้นการแก้ไขข้อผิดพลาดและการบำรุงรักษา

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

และวิธีที่คุณแยกย่อยจำนวนไฟล์ในโครงการของคุณ

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

ในแอปพลิเคชันที่ไม่ดีนั้นแตกต่างกัน แต่จากนั้นผู้พัฒนาจะไม่ "ย่อย" สิ่งใด แต่เพียงแค่สะดุดในความตื่นเต้นตลอดทั้งวันจนกว่าเขาจะหยุดทำงาน ;)

— AnoE
แหล่งที่มา