คำถาม “วิธีใช้งาน Devops” มีมานานหลายปีแล้ว แต่ไม่มีสื่อที่ดีมากนัก บางครั้งคุณอาจตกเป็นเหยื่อของโฆษณาจากที่ปรึกษาที่ไม่ฉลาดนักซึ่งจำเป็นต้องขายเวลาไม่ว่าจะด้วยวิธีใดก็ตาม บางครั้งคำเหล่านี้เป็นคำที่คลุมเครือและเป็นคำทั่วไปอย่างยิ่งเกี่ยวกับวิธีการที่เรือของบริษัทขนาดใหญ่ต่างๆ ไถนาไปในจักรวาลอันกว้างใหญ่ คำถามเกิดขึ้น: สิ่งนี้สำคัญสำหรับเราอย่างไร? เรียนผู้เขียน คุณสามารถกำหนดแนวคิดของคุณในรายการอย่างชัดเจนได้หรือไม่?
ทั้งหมดนี้เกิดจากการที่ไม่มีการฝึกฝนและความเข้าใจอย่างแท้จริงเกี่ยวกับผลลัพธ์ของการเปลี่ยนแปลงวัฒนธรรมของบริษัทมากนัก การเปลี่ยนแปลงในวัฒนธรรมเป็นสิ่งที่เกิดขึ้นในระยะยาว ซึ่งผลลัพธ์จะไม่ปรากฏในหนึ่งสัปดาห์หรือหนึ่งเดือน เราต้องการคนที่อายุมากพอที่จะได้เห็นว่าบริษัทต่างๆ ถูกสร้างขึ้นและล้มเหลวอย่างไรในช่วงหลายปีที่ผ่านมา
จอห์น วิลลิส - หนึ่งในบิดาแห่ง DevOps จอห์นมีประสบการณ์หลายทศวรรษในการทำงานร่วมกับบริษัทจำนวนมาก เมื่อเร็วๆ นี้ จอห์นเริ่มสังเกตเห็นรูปแบบเฉพาะที่เกิดขึ้นเมื่อทำงานกับแต่ละรูปแบบ การใช้ต้นแบบเหล่านี้ John แนะนำบริษัทต่างๆ บนเส้นทางที่แท้จริงของการเปลี่ยนแปลง DevOps อ่านเพิ่มเติมเกี่ยวกับต้นแบบเหล่านี้ในการแปลรายงานของเขาจากการประชุม DevOops 2018
เกี่ยวกับวิทยากร:
มีประสบการณ์มากกว่า 35 ปีในการจัดการไอที ซึ่งมีส่วนร่วมในการสร้าง OpenCloud รุ่นก่อนที่ Canonical มีส่วนร่วมในสตาร์ทอัพ 10 แห่ง โดยสองแห่งขายให้กับ Dell และ Docker ปัจจุบันเขาเป็นรองประธานฝ่าย DevOps และ Digital Practices ที่ SJ Technologies
ต่อไปเป็นเรื่องราวจากมุมมองของจอห์น
ฉันชื่อ John Willis และที่ที่ง่ายที่สุดในการค้นหาฉันคือบน Twitter . ฉันมีนามแฝงเดียวกันบน Gmail และ GitHub ก คุณสามารถค้นหาวิดีโอบันทึกรายงานและการนำเสนอของฉันได้
ฉันมีการประชุมกับ CIO ของบริษัทขนาดใหญ่หลายแห่งหลายครั้ง พวกเขามักจะบ่นว่าพวกเขาไม่เข้าใจว่า DevOps คืออะไร และทุกคนที่พยายามอธิบายให้พวกเขากำลังพูดถึงสิ่งที่แตกต่างออกไป ข้อร้องเรียนทั่วไปอีกประการหนึ่งคือ DevOps ใช้งานไม่ได้ แม้ว่าดูเหมือนว่าผู้กำกับกำลังทำทุกอย่างตามที่อธิบายให้พวกเขาฟังก็ตาม เรากำลังพูดถึงบริษัทขนาดใหญ่ที่มีอายุมากกว่าร้อยปี หลังจากพูดคุยกับพวกเขา ฉันก็ได้ข้อสรุปว่าสำหรับปัญหาต่างๆ มากมาย ไม่ใช่เทคโนโลยีชั้นสูงที่เหมาะสมที่สุด แต่เป็นวิธีแก้ปัญหาที่ค่อนข้างเทคโนโลยีต่ำ ฉันเพิ่งพูดคุยกับผู้คนจากแผนกต่างๆ เป็นเวลาหลายสัปดาห์ สิ่งที่คุณเห็นในภาพแรกในโพสต์คือโปรเจ็กต์สุดท้ายของฉัน นี่คือหน้าตาห้องหลังจากทำงานมาสามวัน
DevOps คืออะไร?
แท้จริงแล้ว ถ้าคุณถามคน 10 คน พวกเขาจะตอบต่างกัน 10 คน แต่สิ่งที่น่าสนใจคือ คำตอบทั้ง 10 ข้อนี้จะถูกต้อง ไม่มีคำตอบที่ผิดที่นี่ ฉันค่อนข้างสนใจ DevOps มาประมาณ XNUMX ปีแล้ว และเป็นชาวอเมริกันคนแรกในงาน DevOpsDay ครั้งแรก ฉันจะไม่บอกว่าฉันฉลาดกว่าทุกคนที่เกี่ยวข้องกับ DevOps แต่แทบไม่มีใครที่ทุ่มเทกับมันมากเท่านี้ ฉันเชื่อว่า DevOps เกิดขึ้นเมื่อทุนมนุษย์และเทคโนโลยีมารวมกัน เรามักจะลืมมิติของมนุษย์ แม้ว่าเราจะพูดถึงวัฒนธรรมทุกประเภทมากมายก็ตาม
ตอนนี้เรามีข้อมูลมากมาย ห้าปีของการวิจัยทางวิชาการ การทดสอบทฤษฎีในระดับอุตสาหกรรม สิ่งที่การศึกษาเหล่านี้บอกเราก็คือ หากคุณรวมรูปแบบพฤติกรรมบางอย่างเข้ากับวัฒนธรรมองค์กร คุณจะเร่งความเร็วได้ 2000 เท่า การเร่งความเร็วนี้สอดคล้องกับการปรับปรุงเสถียรภาพที่เท่าเทียมกัน นี่คือการวัดเชิงปริมาณของผลประโยชน์ที่ DevOps สามารถมอบให้กับบริษัทใดก็ได้ สองสามปีที่แล้ว ฉันกำลังพูดถึง DevOps กับ CEO ของบริษัทที่ติดอันดับ Fortune 5000 ตอนที่ฉันกำลังเตรียมการนำเสนอ ฉันกังวลมาก เพราะฉันต้องสรุปประสบการณ์หลายปีใน 5 นาที
ในที่สุดฉันก็ให้สิ่งต่อไปนี้ คำจำกัดความของ DevOps: เป็นชุดของแนวปฏิบัติและรูปแบบที่ช่วยให้สามารถเปลี่ยนแปลงทุนมนุษย์ให้เป็นทุนองค์กรที่มีประสิทธิภาพสูง ตัวอย่างคือแนวทางการดำเนินงานของโตโยต้าในช่วง 50 หรือ 60 ปีที่ผ่านมา
(ต่อไปนี้ แผนภาพดังกล่าวไม่ได้จัดทำขึ้นเพื่อใช้เป็นข้อมูลอ้างอิง แต่เป็นภาพประกอบ เนื้อหาจะแตกต่างกันไปในแต่ละบริษัทใหม่ อย่างไรก็ตาม สามารถดูรูปภาพแยกกันและขยายใหญ่ได้
แนวทางปฏิบัติดังกล่าวประสบความสำเร็จอย่างหนึ่งคือ การทำแผนที่สายธารคุณค่า. มีการเขียนหนังสือดีๆ หลายเล่มเกี่ยวกับเรื่องนี้ ซึ่งเล่มที่ประสบความสำเร็จมากที่สุดคือของคาเรน มาร์ติน แต่ในปีที่ผ่านมา ฉันได้ข้อสรุปว่าแม้แต่แนวทางนี้ก็ไฮเทคเกินไป แน่นอนว่ามันมีข้อดีมากมายและฉันก็ใช้มันบ่อยมาก แต่เมื่อซีอีโอถามคุณว่าทำไมบริษัทของเขาถึงเปลี่ยนมาใช้รางใหม่ไม่ได้ ยังเร็วเกินไปที่จะพูดถึงแผนผังสายธารคุณค่า มีคำถามพื้นฐานอีกมากมายที่ต้องตอบก่อน
ฉันคิดว่าข้อผิดพลาดที่เพื่อนร่วมงานหลายคนทำคือพวกเขาให้คำแนะนำห้าข้อแก่บริษัท แล้วกลับมาอีกหกเดือนต่อมาและดูว่าเกิดอะไรขึ้น แม้แต่โครงการที่ดี เช่น การทำแผนที่สายธารคุณค่า ก็ยังมีจุดบอด หลังจากการสัมภาษณ์กรรมการของบริษัทต่างๆ หลายร้อยครั้ง ฉันได้พัฒนารูปแบบบางอย่างที่ช่วยให้เราสามารถแยกปัญหาออกเป็นส่วนประกอบได้ และตอนนี้เราจะหารือเกี่ยวกับองค์ประกอบแต่ละส่วนตามลำดับ ก่อนที่จะใช้โซลูชันทางเทคโนโลยีใด ๆ ฉันใช้รูปแบบนี้และด้วยเหตุนี้ผนังทั้งหมดของฉันจึงถูกปกคลุมไปด้วยไดอะแกรม ล่าสุดผมทำงานกับกองทุนรวมและได้โครงการดังกล่าวมาประมาณ 100-150 โครงการ
วัฒนธรรมที่ไม่ดีกินแนวทางที่ดีสำหรับอาหารเช้า
แนวคิดหลักคือ: ไม่มี Lean, Agile, SAFE และ DevOps จำนวนเท่าใดที่จะช่วยได้หากวัฒนธรรมขององค์กรไม่ดี เหมือนกับการดำน้ำลึกโดยไม่ต้องใช้อุปกรณ์ดำน้ำหรือปฏิบัติการโดยไม่ต้องเอ็กซเรย์ กล่าวอีกนัยหนึ่ง เพื่อถอดความ Drucker และ Deming: วัฒนธรรมองค์กรที่ไม่ดีจะกลืนกินระบบที่ดีใดๆ โดยไม่ทำให้ระบบนั้นติดขัด
เพื่อแก้ไขปัญหาหลักนี้ คุณต้องทำตามขั้นตอนต่อไปนี้:
- ทำให้มองเห็นงานทั้งหมดได้: คุณต้องทำให้งานทั้งหมดมองเห็นได้ ไม่ใช่ในแง่ที่ว่าจะต้องแสดงบนหน้าจอใดหน้าจอหนึ่ง แต่ในแง่ที่ว่าจะต้องสังเกตได้
- ระบบการจัดการงานแบบรวม: จำเป็นต้องรวมระบบการจัดการเข้าด้วยกัน ในปัญหาความรู้ “ชนเผ่า” และความรู้เชิงสถาบัน พบปัญหาคอขวด 9 ใน 10 กรณีคือคน ในหนังสือ ปัญหาอยู่ที่คนคนเดียวคือเบรนต์ซึ่งทำให้โครงการล่าช้ากว่ากำหนดสามปี และฉันก็เจอ "Brents" เหล่านี้ทุกที่ เพื่อแก้ไขปัญหาคอขวดเหล่านี้ ฉันจึงใช้สองรายการถัดไปในรายการของเรา
- ทฤษฎีวิธีการจำกัด: ทฤษฎีข้อจำกัด
- แฮ็กการทำงานร่วมกัน: แฮ็กการทำงานร่วมกัน
- โตโยต้า กะตะ (): ฉันจะไม่พูดมากเกี่ยวกับโตโยต้ากะตะ หากสนใจบน GitHub ของฉัน ในเกือบทุกหัวข้อเหล่านี้
- องค์กรที่มุ่งเน้นตลาด: องค์กรที่มุ่งเน้นตลาด
- ผู้ตรวจสอบบัญชีกะซ้าย: การตรวจสอบในช่วงแรกของรอบ
ฉันเริ่มทำงานกับองค์กรง่ายๆ: ฉันไปที่บริษัทและพูดคุยกับพนักงาน อย่างที่คุณเห็นไม่มีเทคโนโลยีขั้นสูง สิ่งที่คุณต้องมีคือเขียนอะไรลงไป ฉันรวบรวมหลายทีมไว้ในห้องเดียว และวิเคราะห์สิ่งที่พวกเขาบอกฉันจากมุมมองของต้นแบบทั้ง 7 ของฉัน จากนั้นฉันก็ให้เครื่องหมายกับพวกเขาและขอให้พวกเขาจดทุกสิ่งที่พวกเขาพูดออกมาดังๆ ไว้บนกระดาน โดยปกติแล้วในการประชุมประเภทนี้จะมีคนคนหนึ่งที่จดทุกอย่างไว้ และอย่างดีที่สุดเขาสามารถเขียนการสนทนาได้ 10% ด้วยวิธีของฉัน ตัวเลขนี้สามารถเพิ่มขึ้นได้ประมาณ 40%
(ภาพประกอบนี้สามารถดูแยกกันได้ )
แนวทางของฉันอิงตามผลงานของ William Schneider ). แนวทางนี้มีพื้นฐานมาจากแนวคิดที่ว่าองค์กรใดก็ตามสามารถแบ่งออกเป็นสี่ช่องได้ แผนงานนี้สำหรับฉันมักจะเป็นผลมาจากการทำงานร่วมกับแผนงานอื่นๆ นับร้อยที่เกิดขึ้นเมื่อวิเคราะห์องค์กร สมมติว่าเรามีองค์กรที่มีการควบคุมระดับสูงแต่มีความสามารถต่ำ นี่เป็นตัวเลือกที่ไม่พึงประสงค์อย่างยิ่ง: เมื่อทุกคนเข้าแถว แต่ไม่มีใครรู้ว่าต้องทำอย่างไร
ตัวเลือกที่ดีกว่าเล็กน้อยคือตัวเลือกที่มีทั้งการควบคุมและความสามารถในระดับสูง หากบริษัทดังกล่าวมีผลกำไร ก็อาจไม่จำเป็นต้องมี DevOps สิ่งที่น่าสนใจที่สุดในการทำงานร่วมกับบริษัทที่มีการควบคุมในระดับสูง ความสามารถและความร่วมมือต่ำ แต่ในขณะเดียวกันก็มีวัฒนธรรม (การเพาะปลูกในระดับสูง) ซึ่งหมายความว่าบริษัทมีคนจำนวนมากที่ชอบทำงานที่นั่นและมีอัตราการหมุนเวียนแรงงานต่ำ
(ภาพประกอบนี้สามารถดูแยกกันได้ )
สำหรับฉันดูเหมือนว่าวิธีการที่มีหลักเกณฑ์ที่เข้มงวดจะขัดขวางการบรรลุความจริง โดยเฉพาะอย่างยิ่งในการทำแผนที่สายธารคุณค่า มีกฎหลายข้อเกี่ยวกับวิธีการจัดโครงสร้างข้อมูล ในช่วงแรกของการทำงาน ซึ่งฉันกำลังพูดถึงตอนนี้ ไม่มีใครต้องการกฎเหล่านี้ หากบุคคลที่มีเครื่องหมายอยู่ในมือบรรยายถึงสถานการณ์จริงในบริษัทบนกระดาน นี่เป็นวิธีที่ดีที่สุดในการทำความเข้าใจสถานการณ์ ข้อมูลดังกล่าวไม่ส่งถึงกรรมการ ในขณะนี้มันเป็นเรื่องโง่ที่จะขัดจังหวะบุคคลนั้นและบอกว่าเขาวาดลูกศรผิดประเภท ในขั้นตอนนี้ จะดีกว่าถ้าใช้กฎง่ายๆ เช่น: สามารถสร้างนามธรรมหลายระดับได้ง่ายๆ โดยใช้มาร์กเกอร์หลากสี
ย้ำว่าไม่มีเทคโนโลยีชั้นสูง เครื่องหมายสีดำแสดงถึงความเป็นจริงตามวัตถุประสงค์ของการทำงานของทุกสิ่ง ด้วยเครื่องหมายสีแดง ผู้คนจะทำเครื่องหมายสิ่งที่พวกเขาไม่ชอบเกี่ยวกับสถานการณ์ปัจจุบัน สิ่งสำคัญคือพวกเขาเขียนสิ่งนี้ ไม่ใช่ฉัน เมื่อฉันไปพบ CIO หลังการประชุม ฉันไม่ได้เสนอรายการ 10 สิ่งที่ต้องแก้ไข ฉันมุ่งมั่นที่จะค้นหาความเชื่อมโยงระหว่างสิ่งที่ผู้คนในบริษัทพูดถึงกับรูปแบบที่ได้รับการพิสูจน์แล้วที่มีอยู่ สุดท้าย เครื่องหมายสีน้ำเงินจะแนะนำวิธีแก้ไขปัญหาที่เป็นไปได้
(ภาพประกอบนี้สามารถดูแยกกันได้ )
ตัวอย่างของแนวทางนี้แสดงไว้ข้างต้นแล้ว เมื่อต้นปีนี้ฉันทำงานกับธนาคารแห่งหนึ่ง เจ้าหน้าที่รักษาความปลอดภัยที่นั่นมั่นใจว่าพวกเขาไม่ควรมาออกแบบและกำหนดให้มีการตรวจสอบ
(ภาพประกอบนี้สามารถดูแยกกันได้ )
จากนั้นเราก็พูดคุยกับคนจากแผนกอื่นๆ และปรากฎว่าเมื่อประมาณ 8 ปีที่แล้ว นักพัฒนาซอฟต์แวร์ไล่พนักงานรักษาความปลอดภัยออก เพราะพวกเขาทำให้งานช้าลง แล้วมันก็กลายเป็นการห้ามซึ่งถูกละเลย แม้ว่าในความเป็นจริงจะไม่มีการห้ามก็ตาม
การประชุมของเราดำเนินไปในลักษณะที่สับสนอย่างมาก: เป็นเวลาประมาณสามชั่วโมง ทีมที่แตกต่างกันห้าทีมไม่สามารถอธิบายให้ฉันฟังได้ว่าเกิดอะไรขึ้นระหว่างโค้ดและแอสเซมบลี และนี่จะดูเหมือนเป็นสิ่งที่ง่ายที่สุด ที่ปรึกษา DevOps ส่วนใหญ่สันนิษฐานล่วงหน้าว่าทุกคนรู้เรื่องนี้อยู่แล้ว
จากนั้นบุคคลที่รับผิดชอบด้านกำกับดูแลด้านไอทีซึ่งเงียบไปเป็นเวลาสี่ชั่วโมง ก็มีชีวิตขึ้นมาทันทีเมื่อเราไปถึงหัวข้อของเขา และครอบงำเราเป็นเวลานานมาก ในตอนท้ายฉันถามเขาว่าเขาคิดอย่างไรเกี่ยวกับการประชุม และฉันจะไม่มีวันลืมคำตอบของเขา เขากล่าวว่า: “ฉันเคยคิดว่าธนาคารของเรามีวิธีส่งมอบซอฟต์แวร์เพียงสองวิธี แต่ตอนนี้ฉันรู้ว่ามีห้าวิธี และฉันไม่รู้ด้วยซ้ำถึงสามวิธี”
(ภาพประกอบนี้สามารถดูแยกกันได้ )
การประชุมครั้งล่าสุดที่ธนาคารแห่งนี้คือการประชุมร่วมกับทีมซอฟต์แวร์การลงทุน อยู่กับเธอที่ปรากฎว่าการเขียนไดอะแกรมด้วยปากกามาร์กเกอร์บนกระดาษดีกว่าบนกระดานและดีกว่าบนสมาร์ทบอร์ดด้วยซ้ำ
ภาพถ่ายที่คุณเห็นคือห้องประชุมของโรงแรมในวันที่สี่ของการประชุมของเรา และเราใช้โครงร่างเหล่านี้เพื่อค้นหารูปแบบ ซึ่งก็คือต้นแบบ
ดังนั้นฉันจึงถามคำถามคนงาน พวกเขาเขียนคำตอบด้วยเครื่องหมายสามสี (ดำ แดง และน้ำเงิน) ฉันวิเคราะห์คำตอบของพวกเขาสำหรับต้นแบบ ตอนนี้เรามาพูดถึงต้นแบบทั้งหมดตามลำดับ
1. ทำให้งานทั้งหมดมองเห็นได้: ทำให้งานมองเห็นได้
บริษัทส่วนใหญ่ที่ฉันทำงานด้วยมีงานที่ไม่รู้จักในเปอร์เซ็นต์ที่สูงมาก ตัวอย่างเช่น นี่คือเวลาที่พนักงานคนหนึ่งมาหาอีกคนหนึ่งและขอทำอะไรบางอย่าง ในองค์กรขนาดใหญ่ อาจมีงานที่ไม่ได้วางแผนไว้ 60% และมากถึง 40% ของงานไม่ได้รับการบันทึกไว้ แต่อย่างใด ถ้าเป็นโบอิ้ง ฉันจะไม่ขึ้นเครื่องบินของพวกเขาอีกเลยในชีวิต หากมีการบันทึกงานเพียงครึ่งหนึ่งก็ไม่ทราบว่างานนี้ทำถูกต้องหรือไม่ วิธีการอื่น ๆ ทั้งหมดกลายเป็นไร้ประโยชน์ - ไม่มีประเด็นที่จะพยายามทำอะไรให้เป็นอัตโนมัติเพราะ 50% ที่ทราบอาจเป็นส่วนที่สอดคล้องและชัดเจนที่สุดของงานระบบอัตโนมัติซึ่งจะไม่ให้ผลลัพธ์ที่ยอดเยี่ยมและแย่ที่สุด สิ่งต่าง ๆ อยู่ในครึ่งที่มองไม่เห็น หากไม่มีเอกสารประกอบ ก็เป็นไปไม่ได้ที่จะค้นหาแฮ็กและงานที่ซ่อนอยู่ทุกประเภท ไม่พบปัญหาคอขวด หรือ "Brents" เหล่านั้นที่ฉันเคยพูดถึงไปแล้ว มีหนังสือที่ยอดเยี่ยมเล่มหนึ่งโดย Dominica DeGrandis . เธอเปิดเผย "การรั่วไหลของเวลา" ห้าแบบที่แตกต่างกัน (โจรแห่งกาลเวลา):
- งานระหว่างดำเนินการมากเกินไป (WIP)
- การพึ่งพาที่ไม่รู้จัก
- การทำงานที่ไม่ได้วางแผนไว้
- ลำดับความสำคัญที่ขัดแย้งกัน
- งานที่ละเลย
นี่เป็นการวิเคราะห์ที่มีคุณค่ามากและหนังสือเล่มนี้ก็เยี่ยมยอด แต่คำแนะนำทั้งหมดนี้ไม่มีประโยชน์หากมองเห็นข้อมูลได้เพียง 50% เท่านั้น สามารถใช้วิธีการที่เสนอโดยโดมินิกาได้หากมีความแม่นยำมากกว่า 90% ฉันกำลังพูดถึงสถานการณ์ที่เจ้านายมอบหมายงานให้ลูกน้องทำงาน 15 นาที แต่เขาใช้เวลาสามวัน แต่เจ้านายไม่รู้จริงๆ ว่าลูกน้องคนนี้ต้องพึ่งพาคนอื่นอีกสี่หรือห้าคน
The Phoenix Project เป็นเรื่องราวที่ยอดเยี่ยมเกี่ยวกับโปรเจ็กต์ที่สายเกินไปสามปี ตัวละครตัวหนึ่งต้องเผชิญกับการเลิกจ้างด้วยเหตุนี้ และเขาได้พบกับตัวละครอีกตัวหนึ่งที่ถูกนำเสนอว่าเป็นโสกราตีสประเภทหนึ่ง เขาช่วยค้นหาว่าเกิดอะไรขึ้นกันแน่ ปรากฎว่า บริษัท มีผู้ดูแลระบบคนหนึ่งชื่อเบรนต์และงานทั้งหมดต้องผ่านเขาไป ในการประชุมครั้งหนึ่ง ลูกน้องคนหนึ่งถูกถามว่าทำไมงานครึ่งชั่วโมงแต่ละงานจึงใช้เวลาหนึ่งสัปดาห์ คำตอบคือการนำเสนอทฤษฎีการเข้าคิวและกฎของลิตเติ้ลที่เรียบง่ายมาก และในการนำเสนอนี้ปรากฎว่าเมื่อมีผู้เข้าพัก 90% งานแต่ละชั่วโมงจะใช้เวลา 9 ชั่วโมง แต่ละงานจะต้องถูกส่งไปให้คนอื่นอีกเจ็ดคน ดังนั้นชั่วโมงนั้นจึงกลายเป็น 63 ชั่วโมง 7 คูณ 9 สิ่งที่ฉันพูดคือเพื่อที่จะใช้กฎของลิตเติ้ลหรือทฤษฎีการเข้าคิวที่ซับซ้อน อย่างน้อยคุณจำเป็นต้องมีข้อมูล
ดังนั้น เมื่อฉันพูดถึงการมองเห็น ฉันไม่ได้หมายความว่าทุกอย่างอยู่บนหน้าจอ แต่อย่างน้อยคุณก็ยังมีข้อมูล เมื่อพวกเขาทำเช่นนั้น มักจะปรากฏว่ามีงานที่ไม่ได้วางแผนไว้จำนวนมากซึ่งถูกส่งไปยัง Brent เมื่อไม่จำเป็น และเบรนต์เป็นผู้ชายที่ยอดเยี่ยม เขาจะไม่มีวันปฏิเสธ แต่เขาจะไม่บอกใครว่าเขาทำงานของเขาอย่างไร
เมื่อมองเห็นงานได้ ข้อมูลก็สามารถจัดประเภทได้อย่างเรียบร้อย (นั่นคือสิ่งที่ Dominique กำลังทำอยู่ในรูปภาพ) นำนามธรรมของการรั่วไหลครั้งที่ห้าไปใช้ และระบบอัตโนมัติสามารถนำมาใช้ได้
2. บูรณาการระบบการจัดการงาน: การจัดการงาน
ต้นแบบที่ฉันกำลังพูดถึงนั้นเป็นปิรามิดชนิดหนึ่ง หากอันแรกทำถูกต้อง อันที่สองก็เป็นส่วนเสริมอยู่แล้ว สิ่งเหล่านี้จำนวนมากใช้ไม่ได้กับสตาร์ทอัพ แต่จำเป็นต้องคำนึงถึงบริษัทขนาดใหญ่อย่าง Fortune 5000 บริษัทสุดท้ายที่ฉันทำงานด้วยมีระบบจองตั๋ว 10 ระบบ ทีมหนึ่งมีระบบ Remedy อีกทีมเขียนระบบของตัวเอง ทีมที่สามใช้ Jira และบางทีมใช้อีเมล ปัญหาเดียวกันนี้จะเกิดขึ้นหากบริษัทมีไปป์ไลน์ที่แตกต่างกัน 30 แห่ง แต่ฉันไม่มีเวลาพูดคุยเกี่ยวกับกรณีดังกล่าวทั้งหมด
ฉันพูดคุยกับผู้คนอย่างชัดเจนถึงวิธีการสร้างตั๋ว อะไรจะเกิดขึ้นกับพวกเขาต่อไป และวิธีที่พวกเขาหลีกเลี่ยง สิ่งที่น่าสนใจที่สุดคือผู้คนในที่ประชุมของเราพูดจาค่อนข้างจริงใจ ฉันถามว่ามีกี่คนที่ใส่คำว่า "เล็กน้อย / ไม่มีผลกระทบ" กับตั๋วที่ควรได้รับ "ผลกระทบหลัก" จริงๆ ปรากฎว่าเกือบทุกคนทำเช่นนี้ ฉันไม่มีส่วนร่วมในการบอกเลิกและพยายามทุกวิถีทางที่จะไม่ระบุตัวตนของผู้คน เมื่อพวกเขาสารภาพบางอย่างกับฉันอย่างจริงใจ ฉันก็จะไม่ปล่อยเขาไป แต่เมื่อเกือบทุกคนเลี่ยงผ่านระบบ นั่นหมายความว่าการรักษาความปลอดภัยทั้งหมดนั้นโดยพื้นฐานแล้วก็คือการตกแต่งหน้าต่าง ดังนั้นจึงไม่สามารถสรุปได้จากข้อมูลของระบบนี้
ในการแก้ปัญหาตั๋ว คุณต้องเลือกระบบหลักเพียงระบบเดียว ถ้าใช้จิระก็เก็บจิระไว้ หากมีทางเลือกอื่นก็ให้เป็นเพียงสิ่งเดียวเท่านั้น สิ่งที่สำคัญที่สุดคือตั๋วควรถูกมองว่าเป็นอีกขั้นตอนหนึ่งในกระบวนการพัฒนา ทุกการกระทำจะต้องมีตั๋ว ซึ่งจะต้องไหลผ่านขั้นตอนการพัฒนา ตั๋วจะถูกส่งไปยังทีมงาน ซึ่งจะโพสต์ไว้บนกระดานเรื่องราว จากนั้นจะรับผิดชอบตั๋วเหล่านั้น
สิ่งนี้ใช้ได้กับทุกแผนก รวมถึงโครงสร้างพื้นฐานและการปฏิบัติการ ในกรณีนี้ อย่างน้อยก็สามารถสร้างแนวคิดที่น่าเชื่อถือเกี่ยวกับสถานการณ์ได้ เมื่อกระบวนการนี้เกิดขึ้น การระบุผู้รับผิดชอบแต่ละแอปพลิเคชันก็จะกลายเป็นเรื่องง่ายทันที เพราะตอนนี้เราไม่ได้รับบริการใหม่ 50% แต่ 98% หากกระบวนการหลักนี้ใช้งานได้ ความแม่นยำก็จะดีขึ้นทั่วทั้งระบบ
ไปป์ไลน์บริการ
สิ่งนี้ใช้ได้กับองค์กรขนาดใหญ่เท่านั้น หากคุณเป็นบริษัทใหม่ในสาขาใหม่ พับแขนเสื้อและทำงานร่วมกับ Travis CI หรือ CircleCI ของคุณ เมื่อพูดถึงบริษัทใน Fortune 5000 กรณีที่เกิดขึ้นที่ธนาคารที่ฉันทำงานอยู่ Google มาหาพวกเขาและได้แสดงไดอะแกรมของระบบ IBM เก่า พวกจาก Google ถามด้วยความสับสน - ซอร์สโค้ดของสิ่งนี้อยู่ที่ไหน? แต่ไม่มีซอร์สโค้ด ไม่มีแม้แต่ GUI นี่คือความจริงที่องค์กรขนาดใหญ่ต้องรับมือ: บันทึกทางธนาคารอายุ 40 ปีบนเมนเฟรมโบราณ ลูกค้ารายหนึ่งของฉันใช้คอนเทนเนอร์ Kubernetes ที่มีรูปแบบ Circuit Breaker รวมถึง Chaos Monkey ทั้งหมดนี้สำหรับแอปพลิเคชัน KeyBank แต่ท้ายที่สุดแล้วคอนเทนเนอร์เหล่านี้จะเชื่อมต่อกับแอปพลิเคชัน COBOL
คนจาก Google มั่นใจอย่างยิ่งว่าพวกเขาจะแก้ปัญหาทั้งหมดของลูกค้าของฉันได้ จากนั้นพวกเขาก็เริ่มถามคำถามว่า IBM datapipe คืออะไร พวกเขาบอกว่า: นี่คือตัวเชื่อมต่อ มันเชื่อมต่อกับอะไร? ไปจนถึงระบบสเปอร์รี่ และนั่นคืออะไร? และอื่นๆ เมื่อมองแวบแรกดูเหมือนว่า DevOps ประเภทใดที่สามารถมีได้? แต่ในความเป็นจริงมันเป็นไปได้ มีระบบจัดส่งที่ให้คุณส่งมอบขั้นตอนการทำงานให้กับทีมจัดส่งได้
3. ทฤษฎีข้อจำกัด: ทฤษฎีข้อจำกัด
มาดูต้นแบบที่สามกัน: ความรู้เชิงสถาบัน/"ชนเผ่า" ตามกฎแล้วในองค์กรใดก็ตาม มีคนหลายคนที่รู้ทุกอย่างและจัดการทุกอย่าง คนเหล่านี้คือคนที่อยู่ในองค์กรมายาวนานที่สุดและรู้วิธีแก้ปัญหาทั้งหมด
เมื่อสิ่งนี้ปรากฏบนแผนภาพ ฉันจะวงกลมคนเหล่านั้นด้วยเครื่องหมายโดยเฉพาะ เช่น ปรากฎว่ามีลูอยู่ในการประชุมทุกครั้ง และชัดเจนสำหรับฉัน: นี่คือเบรนต์ในพื้นที่ เมื่อ CIO เลือกระหว่างฉันในเสื้อยืดและรองเท้าผ้าใบ กับผู้ชายจาก IBM ในชุดสูท ฉันได้รับเลือกเพราะฉันสามารถบอกผู้กำกับในสิ่งที่อีกคนไม่ยอมบอก และผู้กำกับอาจไม่ชอบฟัง . ฉันบอกพวกเขาว่าปัญหาคอขวดในบริษัทของพวกเขาคือคนที่ชื่อเฟรดและคนที่ชื่อลู คอขวดนี้จะต้องได้รับการแก้ไขความรู้ของพวกเขาจะต้องได้รับจากพวกเขาไม่ทางใดก็ทางหนึ่ง
เพื่อแก้ไขปัญหาประเภทนี้ ฉันสามารถแนะนำให้ใช้ Slack เป็นต้น ผู้กำกับที่ฉลาดจะถามว่าทำไม? โดยทั่วไปแล้ว ในกรณีเช่นนี้ ที่ปรึกษา DevOps ตอบว่า เพราะทุกคนต่างก็ทำสิ่งนั้น ถ้าผู้กำกับฉลาดจริงๆ เขาจะพูดว่า แล้วไงล่ะ และนี่คือจุดที่บทสนทนาสิ้นสุดลง และคำตอบของฉันคือ เนื่องจากบริษัทมีปัญหาคอขวดอยู่สี่จุด ได้แก่ เฟรด ลู ซูซี่ และเจน หากต้องการจัดวางความรู้เป็นสถาบัน เราต้องแนะนำ Slack ก่อน วิกิทั้งหมดของคุณไร้สาระโดยสิ้นเชิงเพราะไม่มีใครรู้เกี่ยวกับการมีอยู่ของมัน หากทีมวิศวกรมีส่วนร่วมในการพัฒนาส่วนหน้าและส่วนหลัง และทุกคนจำเป็นต้องรู้ว่าพวกเขาสามารถติดต่อกับทีมพัฒนาส่วนหน้าหรือทีมโครงสร้างพื้นฐานหากมีคำถาม นั่นคือเวลาที่ Lou หรือ Fred น่าจะมีเวลาเข้าร่วมวิกิ จากนั้นใน Slack บางคนอาจถามว่าทำไม เช่น ขั้นตอนที่ 5 ไม่ทำงาน จากนั้น Lou หรือ Fred จะแก้ไขคำแนะนำในวิกิ หากคุณสร้างกระบวนการนี้ขึ้นมา สิ่งต่างๆ มากมายก็จะเข้าที่เข้าทางด้วยตัวเอง
นี่คือประเด็นหลักของฉัน: ในการที่จะแนะนำเทคโนโลยีชั้นสูงใดๆ คุณต้องวางรากฐานสำหรับเทคโนโลยีเหล่านั้นตามลำดับก่อน และสามารถทำได้ด้วยโซลูชันเทคโนโลยีต่ำที่อธิบายไว้ หากคุณเริ่มต้นด้วยเทคโนโลยีชั้นสูงและไม่ได้อธิบายว่าทำไมจึงมีความจำเป็น ตามกฎแล้วสิ่งนี้จะไม่จบลงด้วยดี ลูกค้ารายหนึ่งของเราใช้ Azure ML ซึ่งเป็นโซลูชันที่เรียบง่ายและราคาถูกมาก ประมาณ 30% ของคำถามของพวกเขาได้รับการตอบโดยเครื่องเรียนรู้ด้วยตนเอง และสิ่งนี้เขียนโดยผู้ปฏิบัติงานที่ไม่เกี่ยวข้องกับวิทยาศาสตร์ข้อมูล สถิติ หรือคณิตศาสตร์ นี่เป็นสิ่งสำคัญ ต้นทุนของโซลูชันดังกล่าวมีเพียงเล็กน้อย
4. แฮ็กการทำงานร่วมกัน: แฮ็กการทำงานร่วมกัน
ต้นแบบที่สี่คือความจำเป็นในการต่อสู้กับความโดดเดี่ยว คนส่วนใหญ่รู้เรื่องนี้อยู่แล้ว: ความโดดเดี่ยวทำให้เกิดความเกลียดชัง หากแต่ละแผนกอยู่ในชั้นของตัวเองและผู้คนไม่ได้ติดต่อกัน แต่อย่างใดยกเว้นในลิฟต์ ความเกลียดชังระหว่างพวกเขาจะเกิดขึ้นได้อย่างง่ายดาย แต่ในทางกลับกัน ถ้าคนอยู่ห้องเดียวกันเธอก็จากไปทันที เมื่อมีคนโยนข้อกล่าวหาทั่วไปออกไป เช่น อินเทอร์เฟซดังกล่าวใช้งานไม่ได้ ไม่มีอะไรง่ายไปกว่านี้ในการแยกแยะข้อกล่าวหาดังกล่าว โปรแกรมเมอร์ที่เขียนอินเทอร์เฟซเพียงแค่ต้องเริ่มถามคำถามที่เฉพาะเจาะจง และในไม่ช้าก็จะเห็นได้ชัดว่าผู้ใช้ใช้เครื่องมืออย่างไม่ถูกต้อง
มีหลายวิธีในการเอาชนะความโดดเดี่ยว ครั้งหนึ่งฉันเคยถูกขอให้ปรึกษากับธนาคารแห่งหนึ่งในออสเตรเลีย แต่ฉันปฏิเสธที่จะทำเพราะฉันมีลูกสองคนและภรรยาหนึ่งคน สิ่งที่ฉันทำได้เพื่อช่วยพวกเขาคือแนะนำการเล่าเรื่องแบบกราฟิก นี่คือสิ่งที่ได้รับการพิสูจน์แล้วว่าได้ผล อีกวิธีที่น่าสนใจคือการประชุมกาแฟแบบลีน ในองค์กรขนาดใหญ่ นี่เป็นทางเลือกที่ดีในการเผยแพร่ความรู้ นอกจากนี้ คุณยังสามารถดำเนินการ Devopsdays ภายใน, Hackathons และอื่นๆ ได้
5. การฝึกสอนกะตะ
ตามที่ผมเตือนไว้ตั้งแต่ต้น วันนี้ผมจะไม่พูดถึงเรื่องนี้ หากสนใจสามารถเข้าไปดูได้ .
นอกจากนี้ยังมีการพูดคุยที่ดีในหัวข้อนี้จาก Mike Rother:
6. Market Oriented: องค์กรที่มุ่งเน้นตลาด
มีปัญหาที่แตกต่างกันที่นี่ ตัวอย่างเช่น คน "ฉัน" คน "T" และคน "E" คน “ฉัน” คือคนที่ทำสิ่งเดียวเท่านั้น โดยทั่วไปแล้วจะอยู่ในองค์กรที่มีแผนกแยกกัน "T" คือเมื่อบุคคลเก่งในเรื่องหนึ่งแต่ยังเก่งอีกเรื่องหนึ่งด้วย "E" หรือแม้แต่ "หวี" คือเมื่อบุคคลมีทักษะหลายอย่าง
กฎหมายของคอนเวย์ใช้ได้ที่นี่ () ซึ่งในรูปแบบที่ง่ายที่สุดสามารถระบุได้ดังนี้: หากสามทีมทำงานกับคอมไพเลอร์ผลลัพธ์ที่ได้จะเป็นคอมไพเลอร์สามส่วน ดังนั้น หากมีการแยกตัวในระดับสูงภายในองค์กร แม้แต่ Kubernetes, Circuit breaker, ความสามารถในการขยาย API และสิ่งแฟนซีอื่น ๆ ในองค์กรนี้ก็จะถูกจัดเรียงในลักษณะเดียวกับองค์กรเอง ปฏิบัติตามคอนเวย์อย่างเคร่งครัด และเพื่อเกลียดชังพวกเด็ก ๆ ทั้งหลาย
มีการอธิบายวิธีแก้ไขปัญหานี้หลายครั้ง มี ตัวอย่างเช่น ต้นแบบองค์กรที่อธิบายโดยเฟอร์นันโด เฟอร์นันเดซ สถาปัตยกรรมที่เป็นปัญหาที่ผมเพิ่งพูดถึงไปนั้น เป็นสถาปัตยกรรมที่เน้นฟังก์ชันเป็นหลัก ประเภทที่สองคือสถาปัตยกรรมเมทริกซ์ที่แย่ที่สุด ซึ่งยุ่งวุ่นวายกับอีกสองสถาปัตยกรรม อย่างที่สามคือสิ่งที่เห็นได้ในสตาร์ทอัพส่วนใหญ่ และบริษัทขนาดใหญ่ก็พยายามที่จะจับคู่ประเภทนี้เช่นกัน เป็นองค์กรที่มุ่งเน้นตลาด ที่นี่เราเพิ่มประสิทธิภาพเพื่อให้สามารถตอบสนองคำขอของลูกค้าได้เร็วที่สุด บางครั้งเรียกว่าองค์กรแบบเรียบ
หลายคนอธิบายโครงสร้างนี้ด้วยวิธีต่างๆ กัน ฉันชอบถ้อยคำนี้ สร้าง/รันทีมที่อเมซอนเขาเรียกมันว่า พิซซ่าสองทีม. ในโครงสร้างนี้ คนประเภท "I" ทั้งหมดจะถูกจัดกลุ่มเป็นบริการเดียว และพวกเขาจะค่อยๆ เข้าใกล้ประเภท "T" มากขึ้น และหากมีการจัดการที่เหมาะสม พวกเขาก็สามารถกลายเป็น "E" ได้ ข้อโต้แย้งประการแรกที่นี่คือโครงสร้างดังกล่าวมีองค์ประกอบที่ไม่จำเป็น เหตุใดคุณจึงต้องมีผู้ทดสอบในแต่ละแผนก ในหากคุณมีแผนกผู้ทดสอบพิเศษได้ ที่ฉันตอบ: ค่าใช้จ่ายเพิ่มเติมในกรณีนี้คือราคาที่ทั้งองค์กรจะกลายเป็นประเภท "E" ในอนาคต ในโครงสร้างนี้ ผู้ทดสอบจะค่อยๆ เรียนรู้เกี่ยวกับเครือข่าย สถาปัตยกรรม การออกแบบ ฯลฯ เป็นผลให้ผู้เข้าร่วมทุกคนในองค์กรตระหนักดีถึงทุกสิ่งที่เกิดขึ้นในองค์กร หากคุณต้องการทราบว่าโครงการนี้ทำงานอย่างไรในอุตสาหกรรม โปรดอ่าน .
7. ผู้ตรวจสอบบัญชี Shift-left: ตรวจสอบตั้งแต่เนิ่นๆ ในรอบ การปฏิบัติตามกฎความปลอดภัยบนจอแสดงผล
กล่าวคือเมื่อการกระทำของคุณไม่ผ่านการทดสอบกลิ่น คนที่ทำงานให้คุณไม่ใช่คนโง่ ดังตัวอย่างข้างต้น หากพวกเขาสร้างผลกระทบเล็กน้อย/ไม่มีเลยในทุกที่ ซึ่งกินเวลานานถึงสามปี และไม่มีใครสังเกตเห็นสิ่งใดเลย ทุกคนก็รู้ดีว่าระบบไม่ทำงาน หรืออีกตัวอย่างหนึ่ง - คณะกรรมการที่ปรึกษาการเปลี่ยนแปลง ซึ่งต้องส่งรายงานทุกวันพุธ มีกลุ่มคนทำงานอยู่ที่นั่น (แต่รายได้ไม่ค่อยดีนัก) ซึ่งในทางทฤษฎีแล้ว ควรรู้ว่าระบบโดยรวมทำงานอย่างไร และในช่วงห้าปีที่ผ่านมา คุณอาจสังเกตเห็นว่าระบบของเราซับซ้อนอย่างไม่น่าเชื่อ และห้าหรือหกคนต้องตัดสินใจเกี่ยวกับการเปลี่ยนแปลงที่พวกเขาไม่ได้ทำและสิ่งที่พวกเขาไม่รู้อะไรเลย
แน่นอนว่าวิธีนี้ใช้ไม่ได้ผล ฉันต้องกำจัดสิ่งเหล่านี้ออกไปเพราะคนเหล่านี้ไม่ได้ปกป้องระบบ การตัดสินใจจะต้องตัดสินใจโดยทีมเองเพราะทีมจะต้องรับผิดชอบ มิฉะนั้น สถานการณ์ที่ขัดแย้งกันเกิดขึ้นเมื่อผู้จัดการที่ไม่เคยเขียนโค้ดมาก่อนในชีวิตบอกโปรแกรมเมอร์ว่าควรใช้เวลานานเท่าใดในการเขียนโค้ด บริษัทหนึ่งที่ฉันทำงานด้วยมีบอร์ด 7 แบบที่แตกต่างกันซึ่งจะตรวจสอบทุกการเปลี่ยนแปลง รวมถึงบอร์ดสถาปัตยกรรม บอร์ดผลิตภัณฑ์ ฯลฯ มีแม้กระทั่งช่วงระยะเวลารอคอยที่บังคับ แม้ว่าพนักงานคนหนึ่งจะบอกฉันว่าตลอดการทำงานสิบปี ไม่มีใครปฏิเสธการเปลี่ยนแปลงที่ทำโดยบุคคลนี้ในช่วงเวลาบังคับนี้
ผู้ตรวจสอบบัญชีต้องได้รับเชิญให้เข้าร่วมกับเรา และอย่ากำจัดพวกเขาออกไป บอกพวกเขาว่าคุณเขียนไบนารีคอนเทนเนอร์ที่ไม่เปลี่ยนรูป ซึ่งหากผ่านการทดสอบทั้งหมดแล้ว ก็จะยังคงไม่เปลี่ยนรูปตลอดไป บอกพวกเขาว่าคุณมีไปป์ไลน์เป็นโค้ดและอธิบายว่านั่นหมายความว่าอย่างไร แสดงโครงร่างต่อไปนี้: ไบนารี่แบบอ่านอย่างเดียวที่ไม่เปลี่ยนรูปในคอนเทนเนอร์ที่ผ่านการทดสอบช่องโหว่ทั้งหมด และไม่เพียงแต่ไม่มีใครแตะต้องมัน พวกเขาไม่ได้แตะระบบที่สร้างไปป์ไลน์ด้วยซ้ำ เนื่องจากมันถูกสร้างขึ้นแบบไดนามิกเช่นกัน ฉันมีลูกค้า Capital One ที่ใช้ห้องนิรภัยเพื่อสร้างบางอย่างเช่นบล็อกเชน ผู้ตรวจสอบไม่จำเป็นต้องแสดง "สูตรอาหาร" จากเชฟ การแสดง blockchain ก็เพียงพอแล้ว ซึ่งชัดเจนว่าเกิดอะไรขึ้นกับตั๋ว Jira ในการผลิตและใครเป็นผู้รับผิดชอบ
ตามที่ สร้างขึ้นในปี 2018 โดย Sonatype มีคำขอดาวน์โหลด OSS 2017 พันล้านครั้งในปี 87
ความสูญเสียที่เกิดขึ้นเนื่องจากช่องโหว่เป็นสิ่งต้องห้าม นอกจากนี้ ตัวเลขที่คุณเห็นด้านบนนี้ยังไม่รวมต้นทุนเสียโอกาสอีกด้วย สรุป DevSecOps คืออะไร? ให้ฉันพูดทันทีว่าฉันไม่สนใจที่จะพูดถึงความสำเร็จของชื่อนี้ ประเด็นก็คือเนื่องจาก DevOps ประสบความสำเร็จมาก เราควรพยายามเพิ่มความปลอดภัยให้กับไปป์ไลน์นั้น
ตัวอย่างของลำดับนี้:
นี่ไม่ใช่คำแนะนำสำหรับผลิตภัณฑ์เฉพาะเจาะจง แม้ว่าฉันจะชอบทั้งหมดก็ตาม ฉันยกตัวอย่างเพื่อแสดงให้เห็นว่า DevOps ซึ่งเริ่มแรกมีพื้นฐานมาจากกระบวนทัศน์องค์กรในอุตสาหกรรม ช่วยให้คุณสามารถทำให้ทุกขั้นตอนของผลิตภัณฑ์เป็นอัตโนมัติได้
และไม่มีเหตุผลใดที่เราไม่สามารถใช้วิธีการเดียวกันในการรักษาความปลอดภัยได้
ทั้งหมด
โดยสรุป ฉันจะให้คำแนะนำสำหรับ DevSecOps คุณต้องรวมผู้ตรวจสอบไว้ในกระบวนการสร้างระบบของคุณและใช้เวลาให้ความรู้แก่พวกเขา คุณต้องให้ความร่วมมือกับผู้ตรวจสอบบัญชี ต่อไป คุณจะต้องต่อสู้กับผลบวกลวงอย่างโหดเหี้ยม แม้ว่าจะมีเครื่องมือสแกนช่องโหว่ที่มีราคาแพงที่สุด แต่คุณก็สามารถสร้างพฤติกรรมที่แย่มากในหมู่นักพัฒนาของคุณได้ หากคุณไม่รู้ว่าอัตราส่วนสัญญาณต่อเสียงรบกวนของคุณคือเท่าใด นักพัฒนาจะเต็มไปด้วยกิจกรรมและจะลบกิจกรรมเหล่านั้นทิ้งไป หากคุณได้ยินเกี่ยวกับเรื่องราวของ Equifax นั่นคือสิ่งที่เกิดขึ้นที่นั่น โดยที่ระดับการแจ้งเตือนสูงสุดถูกละเลย นอกจากนี้ จำเป็นต้องอธิบายช่องโหว่ในลักษณะที่ทำให้ชัดเจนว่าช่องโหว่เหล่านี้ส่งผลกระทบต่อธุรกิจอย่างไร ตัวอย่างเช่น คุณสามารถพูดได้ว่านี่เป็นช่องโหว่แบบเดียวกับในเรื่องราวของ Equifax ช่องโหว่ด้านความปลอดภัยควรได้รับการปฏิบัติเช่นเดียวกับปัญหาซอฟต์แวร์อื่นๆ กล่าวคือ ควรรวมไว้ในกระบวนการ DevOps โดยรวม คุณต้องทำงานร่วมกับพวกเขาผ่าน Jira, Kanban ฯลฯ นักพัฒนาไม่ควรคิดว่าคนอื่นจะทำสิ่งนี้ - ในทางกลับกัน ทุกคนควรทำสิ่งนี้ สุดท้ายคุณต้องใช้พลังงานในการฝึกอบรมผู้คน
ลิงค์ที่มีประโยชน์
ต่อไปนี้เป็นคำพูดบางส่วนจากการประชุม DevOops ที่คุณอาจพบว่ามีประโยชน์:
- Sergey Berdnikov, Artyom Kalichkin - เรื่องราวความสำเร็จ หรือ “Dev+DevOps+Ops” (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps ในระดับ: โศกนาฏกรรมของชาวกรีกในสามองก์ (, )
- อเล็กซานเดอร์ ติตอฟ, คิริลล์ โทลคาเชฟ -
- ทิโมธี ลิสเตอร์-
มองเข้าไปใน DevOops 2020 มอสโก — ยังมีสิ่งที่น่าสนใจอีกมากมายที่นั่น
ที่มา: will.com