วันนี้ที่ Southbridge เราได้พูดคุยเกี่ยวกับการจัดการสีเขียวขุ่นในการประชุมการวางแผน
มีคนเสนอให้ย้ายจากบนลงล่าง จากแนวคิดไปสู่การปฏิบัติ เช่น ลองใช้ปรัชญาการจัดการแบบเทอร์ควอยซ์: ค้นหามาตรฐาน ตัดสินใจว่าควรแบ่งบทบาทอย่างไร ควรสร้างการสื่อสารอย่างไร และเริ่มก้าวไปตามเส้นทางนี้
มีผู้คนเหล่านั้น (รวมตัวฉันเองด้วย) ที่ต้องการย้ายจากล่างขึ้นบน จากการปฏิบัติไปสู่แนวคิด เรามีงานเฉพาะและปัญหาเฉพาะ มาแก้ปัญหาโดยใช้เครื่องมือเทอร์ควอยซ์ แล้วการจัดการเทอร์ควอยซ์จะพัฒนาขึ้นเอง
หากคุณเปรียบเทียบการจัดการกับการพัฒนา เส้นทางจากบนลงล่างคือการสร้างเสาหิน และเส้นทางจากล่างขึ้นบนคือสถาปัตยกรรมไมโครเซอร์วิส ในตอนนี้ ในการจัดการ "ไมโครเซอร์วิส" ของเรา เราสามารถสร้างวงจรการจัดการใหม่ได้วันละสองครั้ง และ "เริ่มใช้งานจริง" ได้ทันที
และโปรแกรม สร้างขึ้นสำหรับผู้ที่ต้องการย้ายจากล่างขึ้นบน
เราจะไม่หารือเกี่ยวกับปรัชญา DevOps ไม่ใช่เพราะมันไม่มีความหมาย หรือเราไม่รู้ หรือเราไม่ชอบโฮลิวาร์ (และเราไม่ชอบ) เพียงแต่ว่าปรัชญา DevOps ตกผลึกอยู่ในสถาปนิกและวิศวกร DevOps ทุกคนตลอดระยะเวลาหลายปีของการฝึกฝน ไม่ใช่ใน 3 วันของการฝึกอบรมอย่างเข้มข้น
เราจะหารือเกี่ยวกับเครื่องมือเฉพาะ สิ่งที่สามารถนำไปใช้ได้ทันทีโดยไม่ต้องมีการสนทนาเชิงปรัชญาและการปรับโครงสร้างการจัดการในระดับงานประจำวัน เขียนคำแนะนำในการทำงานเป็นทีมด้วย Git เขียน Playbook สำหรับการปรับใช้เซิร์ฟเวอร์ ตั้งค่าตัวรวบรวมบันทึก
ผลที่ได้คืองานจะง่ายขึ้นและง่ายขึ้น และคุณสามารถสร้าง DevOps ขึ้นมาเป็นพื้นฐานได้
เพื่อให้ก้าวไปไกลกว่าแนวทางปฏิบัติของ Southbridge เราได้เชิญวิทยากรภายนอกในบางหัวข้อ
Artem Galonsky, STO "สำนักงานสำนัก"
12 ปีขึ้นไปในการพัฒนาเชิงพาณิชย์
หัวหน้าทีม / หัวหน้าฝ่ายพัฒนาตั้งแต่ปี 2011
ผู้อำนวยการฝ่ายเทคนิคตั้งแต่ปี 2016
เราจะร่วมกันพิจารณาหาวิธีทำให้แอปพลิเคชันที่เคยใช้ก่อนหน้านี้ใช้งานได้โดยอัตโนมัติ เรามาหารือเกี่ยวกับการก่อสร้างไปป์ไลน์ที่ทันสมัยและเครื่องมือทั่วไปบางอย่าง เรามาดูรายละเอียดเกี่ยวกับเครื่องมือและความสามารถของ GitLab CI/CD กันดีกว่า ฉันจัดโครงสร้างการฝึกปฏิบัติในหัวข้อของฉัน (ความรู้เบื้องต้นเกี่ยวกับระบบอัตโนมัติและการทำงานกับ Gitlab) เพื่อให้นักเรียนได้รู้สึกว่าวิธี CI/CD สมัยใหม่ถูกนำมาใช้อย่างไรและเพราะเหตุใด ทฤษฎีนี้จะเป็นค่าขั้นต่ำที่จำเป็นตามวัตถุประสงค์
Alexey Stepanenko วิศวกรแพลตฟอร์มคลาวด์ของ Selectel
การจัดการกับงานด้านโครงสร้างพื้นฐานสำหรับการบำรุงรักษาระบบคลาวด์ OpenStack: การตรวจสอบ CI/CD และการจัดการการกำหนดค่า
ก่อนอื่น เราจะพูดถึงโมเดลและวิธีการจัดการโครงสร้างพื้นฐาน (แนวทางจากการเขียนโปรแกรมเข้ามาสู่การบริหารอย่างไร) และเราจะทำความคุ้นเคยกับในทางปฏิบัติกับเครื่องมือ DevOps ของ HashiCorp (Packer และ Terraform) สำหรับการจัดการโครงสร้างพื้นฐานที่เปิดเผย
เมื่อเสร็จสิ้นบล็อก คุณจะสามารถอธิบายโครงสร้างพื้นฐานของคุณ สร้างสภาพแวดล้อมการทดสอบและการใช้งานจริงโดยอัตโนมัติ ปรับขนาดแอปพลิเคชันของคุณ และสร้างโซลูชัน High Availability โดยใช้โหลดบาลานเซอร์
Eduard Medvedev, CTO ของ Tungsten Labs (เยอรมนี)
ทำงานเป็นวิศวกรที่ StackStorm ซึ่งรับผิดชอบการทำงานของ ChatOps ของแพลตฟอร์ม พัฒนาและใช้งาน ChatOps สำหรับระบบอัตโนมัติของศูนย์ข้อมูล วิทยากรในการประชุมรัสเซียและนานาชาติ
ที่ Slurm ฉันจะพูดถึงวิธีทำให้การสื่อสารภายในทีม DevOps และการโต้ตอบกับไปป์ไลน์ CI/CD มีประสิทธิภาพมากขึ้นโดยใช้การผสานรวมแบบสองทางกับแชทบอท
อีวาน ครูลอฟ ผู้พัฒนาหลักของ Booking.com
นับตั้งแต่ร่วมงานกับ Booking.com ในปี 2013 เขาทำงานในโครงการโครงสร้างพื้นฐาน เช่น การส่งข้อความและการประมวลผลแบบกระจาย BigData และเว็บสแต็ก การค้นหา
ขณะนี้กำลังแก้ไขปัญหาเกี่ยวกับการสร้างคลาวด์ภายในและ Service Mesh
ในส่วนสุดท้ายของ Slerm เราจะทำความคุ้นเคยกับแนวคิดหลักทางอุดมการณ์และองค์กรของ SRE และพิจารณาวิธีปฏิบัติในการใช้งานโดยใช้ตัวอย่างสดจากประสบการณ์ของฉัน นอกจากนี้ เราจะดูที่ด้านเทคนิคของ SRE ได้แก่ เทคนิคใดบ้างที่สามารถใช้เพื่อให้บริการมีความน่าเชื่อถือมากขึ้น
เมื่อจบหลักสูตร ฉันจะพยายามตอบคำถามสำคัญสองข้อ:
- SRE ให้อะไรกับผู้ดูแลระบบหรือโปรแกรมเมอร์?
- เหตุใดเจ้าของธุรกิจหรือผลิตภัณฑ์จึงจำเป็นต้องนำ SRE ไปใช้
ดังนั้น DevOps Slurm นี้จะมีเอกลักษณ์เฉพาะตัว: ถ้าเราทำซ้ำโปรแกรม มันจะมีองค์ประกอบที่แตกต่างออกไป
สำหรับผู้ที่ใส่ใจยังคงมีส่วนลด 15% เมื่อใช้โค้ดส่งเสริมการขาย habrapost
เกี่ยวกับโปรแกรม DevOps ของ Slurm - .
วันที่:
ที่มา: will.com