ภาพรวมของการประชุม DevOpsDays Moscow: ข้อมูลเชิงลึกจากรายงาน 6 ฉบับ

การประชุมครั้งที่สามจัดขึ้นในวันที่ 7 ธันวาคม DevOpsDays มอสโกซึ่งจัดโดยชุมชน Moscow DevOps โดยได้รับการสนับสนุนจาก Mail.ru Cloud Solutions นอกเหนือจากการนำเสนอโดยผู้ปฏิบัติงาน DevOps ชั้นนำแล้ว ผู้เข้าร่วมยังสามารถเข้าร่วม Lightning Talks สั้นๆ ที่สร้างแรงบันดาลใจ เวิร์กช็อป และการสื่อสารในพื้นที่เปิดโล่ง

เรารวบรวมข้อมูลเชิงลึกที่สำคัญจากการกล่าวสุนทรพจน์ทั้ง XNUMX ครั้ง และทำการสัมภาษณ์วิทยากรหลายคนเพื่อค้นหาว่ามีอะไรหลงเหลืออยู่เบื้องหลังรายงานนี้

ข้างใน:

1. Baruch Sadogursky, JFrog: “ปล่อยให้ซอฟต์แวร์ไหลจากผู้จำหน่ายไปยังผู้ใช้เหมือนของเหลว”
2. Pavel Selivanov จาก Southbridge: “Dev และ Ops มีงานเดียวที่เหมือนกัน นั่นคือการสร้างผลิตภัณฑ์ที่ใช้งานได้จริง”
3. Vladimir Utratenko, X5 Retail Group: “DevOps ในองค์กรมีการพัฒนาโดยปราศจากความเจ็บปวดและไฟไหม้”
4. Sergey Puzyrev, Facebook: “วิศวกรฝ่ายผลิตให้ความสำคัญกับบริการโดยรวม เพื่อให้ทั้งผู้ใช้และนักพัฒนามีช่วงเวลาที่ดี”
5. Mikhail Chinkov, AMBOSS: “แผนกเดียวไม่สามารถเดินตามเส้นทาง DevOps ได้ ทั้งบริษัทต้องเดินตาม”
6. ผู้ที่ชื่นชอบ DevOps ของ Rosbank: “1000 วันในการใช้งาน DevOps ในองค์กรที่นองเลือด”

1. Baruch Sadogursky, JFrog: “ปล่อยให้ซอฟต์แวร์ไหลจากผู้จำหน่ายไปยังผู้ใช้ราวกับเป็นของเหลว”

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

Baruch พูดถึงรูปแบบของการอัปเดตอย่างต่อเนื่องของ DevOps ซึ่งจะช่วยหลีกเลี่ยงความล้มเหลวและความเกลียดชังของผู้ใช้:

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

ผ่านการอัพเดททางอากาศ - ต่อเนื่องได้ดีขึ้น มิฉะนั้นก็จะเหมือนกับนักพัฒนา Jaguar: เนื่องจากข้อบกพร่องในระบบเบรกซึ่งไม่สามารถอัปเดตทางอากาศได้ รถยนต์จึงต้องถูกเรียกคืนจากการขาย มันเจ็บปวดและมีราคาแพง

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

การปรับใช้อัตโนมัติ - แทนที่ผู้คนด้วยเครื่องจักร เนื่องจากผู้คนกระทำกิจวัตรประจำวันได้ไม่ดี

Частыеобновления - ช่วยให้คุณพัฒนานิสัยและกำจัดความกลัว การอัปเดตที่หายากจะกลายเป็นเหตุการณ์ฉุกเฉิน

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

ปล่อยนกขมิ้น — เปิดตัวการอัปเดตให้กับผู้ใช้จำนวนน้อยและสังเกต ซึ่งจะช่วยลดความเสียหายหากมีข้อผิดพลาดเกิดขึ้น

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

เราได้พูดคุยกับ Baruch Sadogursky เกี่ยวกับมุมมองของ DevOps ในด้านไอทีของรัสเซียและตะวันตก ดูว่า Cloud จะดำเนินการทุกอย่างให้เราในเร็วๆ นี้หรือไม่ และบริการซอฟต์แวร์ทั้งหมดจะเข้าสู่โครงการ aaS หรือไม่ - ดูการสัมภาษณ์:

2. Pavel Selivanov จาก Southbridge: “Dev และ Ops มีงานเดียวที่เหมือนกัน นั่นคือการสร้างผลิตภัณฑ์ที่ใช้งานได้จริง”

การใช้ Kubernetes ไม่ได้ช่วยให้ DevOps บรรลุผล แต่ในทางกลับกัน ก็สามารถทำลายทุกสิ่งได้ พาเวลอธิบายว่าทำไมเทคโนโลยี (แม้จะเจ๋งที่สุด) ไม่สามารถแก้ปัญหาทั้งหมดของคุณได้:

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

นักพัฒนาไม่ต้องการการเปลี่ยนแปลงหลังจากใช้งาน DevOps. เป็นผลให้เวิร์กโฟลว์กับ Kubernetes ยังคงดูเหมือนเป็นการโยนงานจาก Dev ไปยัง Ops ข้ามกำแพง ไม่ใช่แค่การเปรียบเทียบเท่านั้น - Git กลายเป็นกำแพงเช่นนี้ นักพัฒนาวางโค้ดไว้ที่นั่นและทำงานเหมือนเดิม และผู้ดูแลระบบก็มี Kubernetes, CI/CD และอื่นๆ อีกมากมาย

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

หากไม่มีการเปลี่ยนแปลงใด ๆ สำหรับนักพัฒนา พวกเขาไม่ทราบว่าการทำงานของแอปพลิเคชันเป็นความรับผิดชอบของพวกเขา - เทคนิคทางเทคนิคต่างๆ จะไม่ทำงาน

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

Pavel Selivanov พูดถึงสิ่งที่จะเกิดขึ้นกับ Kubernetes ในอีก 5 ปี และสิ่งที่สตาร์ทอัพยุคใหม่ควรสร้างสแต็คเทคโนโลยี - ดูการสัมภาษณ์:

3. Vladimir Utratenko, X5 Retail Group: “DevOps ใน Enterprise ได้รับการพัฒนาโดยปราศจากความเจ็บปวดและอุปสรรค”

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

วลาดิมีร์อธิบายว่าสิ่งนี้เกิดขึ้นได้อย่างไรและสิ่งที่จับได้คืออะไร:

1. ประการแรก บริษัทต่างๆ จ้างวิศวกร DevOps นี่คือผู้ดูแลระบบอาวุโส เขามีส่วนร่วมในการปรับใช้รุ่นสู่การใช้งานจริง สร้างมาตรฐานสภาพแวดล้อมการพัฒนา การตั้งค่าโครงสร้างพื้นฐาน การตรวจจับและแก้ไขปัญหาต่างๆ ทำให้กระบวนการอัตโนมัติและงานทางเทคนิคอื่นๆ
2. วิศวกร DevOps คนเดียวก็ไม่เพียงพออีกต่อไป และบริษัทก็จ้างทีม DevOps นี่คือศูนย์ความสามารถที่จัดระเบียบความพยายามของวิศวกรที่แตกต่างกันและช่วยให้พวกเขามีสมาธิไปในทิศทางเดียว
3. ในความเป็นจริง วิศวกร DevOps และทีม DevOps เป็นรูปแบบการต่อต้านการเปลี่ยนแปลง DevOps เนื่องจาก DevOps เป็นเรื่องเกี่ยวกับแนวปฏิบัติและวัฒนธรรม นอกจากนี้ยังมีการนำ DevOps ไปใช้งานในบริษัทเทคโนโลยี (SRE, วิศวกรรมการผลิต)

จะทำอย่างไร? จ้างทีม DevOps ชั่วคราวซึ่งจะช่วยดำเนินการเปลี่ยนแปลง DevOps ดำเนินการแนวปฏิบัติ ปลูกฝังวัฒนธรรมการพัฒนาและวัฒนธรรมทางเทคโนโลยี

เมื่อธุรกิจเข้ามามีบทบาทและลงทุนใน DevOps มีหลายสถานการณ์ที่เป็นไปได้: ทุกอย่างจะพังทลายเมื่อเริ่มบิน จะยังคงเป็น SRE/วิศวกรรมการผลิตหรือปฏิบัติการแบบฝังตัว จะย้ายไปที่ BizOps เมื่อกระบวนการขึ้นอยู่กับการวัดทางธุรกิจ

Vladimir Utratenko บอกเราว่า DevOps ที่ "นองเลือด" ในองค์กรเป็นอย่างไร และวิธีปฏิบัติในการค้าปลีกขนาดใหญ่ - ดูการสัมภาษณ์:

4. Sergey Puzyrev จาก Facebook: “วิศวกรฝ่ายผลิตให้ความสำคัญกับบริการโดยรวม เพื่อให้ทั้งผู้ใช้และนักพัฒนามีช่วงเวลาที่ดี”

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

Sergey เล่าถึงสิ่งที่วิศวกรฝ่ายผลิตทำบน Facebook:

1. วิศวกรฝ่ายผลิตเขียนโค้ดเป็นจำนวนมาก เขาต้องมีความรู้เกี่ยวกับระบบ เช่น ระบบปฏิบัติการ ระบบไฟล์ ฐานข้อมูล เครือข่าย และอื่นๆ ต้องมีประสบการณ์การทำงานกับระบบแบบกระจายและ Reliability Engineering คือ การสนับสนุนความน่าเชื่อถือของผลิตภัณฑ์ ต้องเป็นแบบ on-call คือสามารถโทรได้ตลอดเวลา
2. Production Engineer แตกต่างจาก Software Engineer ตรงที่มีทักษะขั้นสูงในการดำเนินงาน แต่จริงๆ แล้วเป็นประเภทย่อยของ Software Engineer วิศวกรซอฟต์แวร์เขียนโค้ดมากขึ้น พวกเขาอาจมีทักษะเพิ่มเติมที่เกี่ยวข้องกับการประมวลผลข้อมูล เช่น บน Facebook ผู้เชี่ยวชาญดังกล่าวจะต้องพร้อมรับสายด้วย ซึ่งเป็นเรื่องที่น่าประหลาดใจสำหรับหลาย ๆ คน
3. พีระมิดแห่งความต้องการของวิศวกรฝ่ายผลิตในบริษัทเริ่มต้นด้วยการตรวจสอบเซิร์ฟเวอร์และวงจรการใช้งาน ซึ่งก็คือ การจัดหาฮาร์ดแวร์ใหม่ การตั้งค่า และการใช้งาน ระดับถัดไปจะเหมือนกันในระดับบริการ: บริการตรวจสอบและวงจรชีวิตของพวกเขา จากนั้นก็มาถึงการปรับขนาดที่ราบรื่นและการตรวจสอบขั้นสูง โดยจะเปลี่ยนไปใช้การปรับขนาดอัตโนมัติหลังจากวงจรอายุการใช้งานเป็นแบบอัตโนมัติ และท้ายที่สุด จำเป็นต้องทำการปรับแต่งเพื่อให้การปรับขนาดมีประสิทธิภาพ และบริษัทประหยัดเงินและทรัพยากร

5. Mikhail Chinkov, AMBOSS: “แผนกเดียวไม่สามารถเดินตามเส้นทาง DevOps ได้ ทั้งบริษัทต้องเดินตาม”

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

ความแตกต่างในการทำความเข้าใจ DevOps. Canonical Devops ดังที่ผู้เผยแพร่ศาสนาเห็นนั้น วางอยู่บนเสาหลัก 5 ประการ:

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

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

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

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

ขั้นตอนของการพัฒนา DevOps ในบริษัท:

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

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

หลังจากปิดวัฒนธรรมและเทคนิคทั้งหมดแล้ว การเปลี่ยนแปลง DevOps ของบริษัทจะคำนึงถึงผลตอบรับจากตัวชี้วัดทางธุรกิจและแพลตฟอร์ม

6. ผู้ที่ชื่นชอบ DevOps ของ Rosbank: “1000 วันในการใช้งาน DevOps ในองค์กรที่นองเลือด”

Yuri Bulich, Dina Maltseva, Evgeny Pankov จาก Rosbank เล่าว่าพวกเขามาที่ DevOps ได้อย่างไรในรอบสามปี มีสองเป้าหมาย: เพื่อแก้ไขปัญหาเฉพาะในทีมเฉพาะและการใช้เครื่องมือแบบรวมศูนย์

ผลลัพธ์ที่ได้มีดังนี้:

ผลลัพธ์สำหรับทีมผลิตภัณฑ์: ประกอบเร็วขึ้น 30 เท่า ติดตั้งเร็วขึ้น 6 เท่า ประหยัดทั้งรอบสูงสุดถึง 30% ขณะนี้เรามีความสามารถในการกดปุ่มเพื่อไปสู่ประสิทธิภาพการทำงาน

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

แล้วจะนำแนวทางปฏิบัติ DevOps ไปใช้ในองค์กรนองเลือดได้อย่างไร?

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

ในธนาคารและองค์กรอื่นๆ จำเป็นต้องหารือเกี่ยวกับข้อจำกัดล่วงหน้ากับทีมรักษาความปลอดภัยข้อมูล และค้นหาแนวทางแก้ไขที่จะอนุญาตให้นำการเปลี่ยนแปลงไปใช้

หลังจากโครงการนำร่องแล้ว โซลูชันที่ประสบความสำเร็จจะต้องได้รับการขยายขนาด.

1. สิ่งสำคัญคือต้อง "ยืด" ไปป์ไลน์ให้มากที่สุดเท่าที่จะเป็นไปได้ โดยกำจัดลิงก์ที่ไม่จำเป็นออกไป เน้นผู้ให้บริการที่มีมูลค่า และลบส่วนประกอบที่เหลือออก ตัวกลางเป็นสิ่งที่ต่อต้านรูปแบบ ตัวอย่างเช่น ที่ Rosbank หลายทีมไม่ได้พัฒนาการพัฒนาภายใน เหลือเพียงการพัฒนาภายนอกเท่านั้น สิ่งนี้นำไปสู่การเกิดขึ้นของทีม DevOps โดยเฉพาะ ซึ่งรับประกันการโอนโค้ดจากนักพัฒนาภายนอกไปยังภายใน ปัญหาได้รับการแก้ไขโดยการรวมการพัฒนาภายนอกเข้ากับ CI/CD เพื่อที่พวกเขาจะไม่เพียงแค่โอนรหัสจากพวกเขาไปยังธนาคารเท่านั้น แต่ยังต้องรับผิดชอบต่อความสำเร็จอีกด้วย
2. โมเดลการเติบโตประกอบด้วยองค์ประกอบของแนวทางปฏิบัติ DevOps รายการเครื่องมือ และคำนึงถึงคุณลักษณะของการทำงานร่วมกับซัพพลายเออร์ภายนอก ซึ่งในอนาคตจะช่วยลดงานที่ค้างอยู่ได้อย่างรวดเร็วเมื่อนำไปใช้ในทีมใหม่
3. เราต้องการการกำกับดูแลในรูปแบบของการควบคุมแบบนุ่มนวลและคำแนะนำ คู่มือ DevOps ที่ทำงานได้ดีคือชุดคุณลักษณะขององค์กรและเครื่องมือที่ช่วยให้ทีมใช้แพลตฟอร์มได้อย่างถูกต้อง
4. คุณควรใส่ใจกับวัฒนธรรมทันที จากนั้นการเปลี่ยนแปลงหลายอย่างจะเกิดขึ้นเร็วและง่ายขึ้น ขยายชุมชนภายในของคุณ จัดมีตติ้ง เวิร์กช็อปด้านเทคนิค การฝึกอบรม และกิจกรรมที่สนุกสนาน สิ่งนี้เกิดผล: ผู้คนแบ่งปันแนวทางปฏิบัติ ดูว่าใครทำอะไร รู้ว่าจะต้องหันไปทางไหน มีกระแสฮือฮาและการแข่งขันที่ดีภายในบริษัท
5. ไม่มีประโยชน์ที่จะทำงานร่วมกับผู้ที่ไม่เกี่ยวข้องกับกระบวนการนี้ กับทีมที่ยังไม่โตเต็มที่ เป็นการดีกว่าที่จะลงทุนในทีมที่สนใจและผู้ภักดี
6. โซลูชันที่เลือกจะต้องสะดวกสำหรับวิศวกรที่ใช้งาน
7. การพัฒนาภายนอกไม่ใช่ตัวขัดขวาง สามารถนำไปปฏิบัติที่นั่นได้สิ่งสำคัญคือทีมเองก็มีความปรารถนา

ประโยชน์อีกสักหน่อย

รายชื่อหนังสือที่น่าอ่านสำหรับผู้ที่อยู่ใน DevOps จาก Alexander Chistyakov, vdsina.ru:

1. Irina Yakutenko “เจตจำนงและการควบคุมตนเอง”
2. Daniel Kahneman "การคิด เร็วและช้า"
3. บาร์บารา โอ๊คลีย์ "ใจเพื่อตัวเลข"
4. Maxim Dorofeev "เทคนิคของเจได"
5. Viktor Frankl "การค้นหาความหมายของมนุษย์"

คอยติดตาม

เราก็รัก DevOps เช่นกัน ติดตามประกาศซีรีส์ @DevOps และ @Kubernetes รวมถึงกิจกรรม Mail.ru Cloud Solutions อื่นๆ ในช่อง Telegram ของเรา: t.me/k8s_mail

ที่มา: will.com