กระบวนการหรือเครื่องมือใดที่เปิดใช้งานการแยกหน้าที่เมื่อวิศวกรทั้งปรับใช้และเรียกใช้รหัส

ในสภาพแวดล้อมที่มีการควบคุมอย่างเข้มงวดเช่นภาคบริการทางการเงินการแยกหน้าที่เป็นกลไกสำคัญในการหลีกเลี่ยงการปะทะกันระหว่างบุคคลที่มีความรับผิดชอบในการพัฒนาและสิทธิพิเศษในการผลิต

ตามเนื้อผ้าสิ่งนี้ได้หมายความว่านักพัฒนาพัฒนารหัสแล้วมอบมันให้กับฝ่ายปฏิบัติการอย่างไรก็ตามในหลาย ๆ รูปแบบการปฏิบัติการ DevOps การแยกระหว่างการพัฒนาและการปฏิบัติการคืออย่างน้อยเบลอ:

• ในวิศวกรรมความน่าเชื่อถือของไซต์หรือ SRE ของ Google ให้ฝึกปฏิบัติงานที่มีฟังก์ชั่น SRE แยกต่างหากภายใน Google อย่างไรก็ตามนักพัฒนาจะถูกนำมาใช้เพื่อหนุนหลัง SREs ในเวลาที่มีภาระงานสูง

• ในรูปแบบ"คุณสร้างมันคุณเรียกใช้"ไม่มีฟังก์ชั่นการทำงานแยกต่างหาก

หลังจากใช้เวลาหลายเดือนเจาะลึกลงไปถึงสาเหตุของการแบ่งแยกหน้าที่กลไกดูเหมือนว่ามันมีอยู่เป็นส่วนใหญ่ที่จะสนองSarbanes Oxley มาตรา 404 : การประเมินการจัดการการควบคุมภายใน:

(a) กฎที่จำเป็น คณะกรรมการจะกำหนดกฎระเบียบที่กำหนดให้รายงานประจำปีแต่ละรายการตามมาตรา 13 (a) หรือ 15 (d) ของพระราชบัญญัติหลักทรัพย์และตลาดหลักทรัพย์ปี 2477 เพื่อให้มีรายงานการควบคุมภายในซึ่งจะ -

(1) ระบุความรับผิดชอบของฝ่ายบริหารในการจัดตั้งและบำรุงรักษาโครงสร้างการควบคุมภายในและขั้นตอนการรายงานทางการเงินอย่างเพียงพอ และ

(2) มีการประเมิน ณ สิ้นปีบัญชีล่าสุดของผู้ออกหลักทรัพย์เกี่ยวกับประสิทธิภาพของโครงสร้างการควบคุมภายในและกระบวนการของผู้ออกหลักทรัพย์สำหรับการรายงานทางการเงิน

(b) การประเมินและการรายงานการควบคุมภายใน ในการประเมินการควบคุมภายในที่กำหนดโดยส่วนย่อย (a) แต่ละ บริษัท บัญชีสาธารณะที่ลงทะเบียนที่จัดทำหรือออกรายงานการตรวจสอบสำหรับผู้ออกจะต้องยืนยันและรายงานเกี่ยวกับการประเมินโดยการจัดการของผู้ออก การยืนยันที่ทำภายใต้ส่วนนี้จะต้องทำตามมาตรฐานสำหรับภารกิจการรับรองที่ออกหรือรับรองโดยคณะกรรมการ การยืนยันใด ๆ ดังกล่าวจะไม่เป็นเรื่องของการมีส่วนร่วมแยกต่างหาก

จากความคิดเห็นเป็นสิ่งสำคัญที่จะเรียกสมมติฐานสองข้อที่ฉันกำลังทำอยู่:

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

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

Sarbanes Oxley 404 เป็นที่พึงพอใจโดยผ่านการประเมินความเสี่ยงจากบนลงล่างซึ่งเป็นส่วนหนึ่งที่จะประเมินความเสี่ยงของการสมรู้ร่วมคิดและวางกลยุทธ์การลดความเสี่ยง

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

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

---

1. สถาปัตยกรรม

---

นี่คือไฮไลท์ของวิธีที่ฉันจะตอบคำถามของคุณ:

• รหัสทั้งหมด (และสิ่งประดิษฐ์ที่เกี่ยวข้องเช่น executables ฯลฯ ) ถูกเก็บไว้ในไฟล์ที่มารวมกันทั้งหมดคือสิ่งที่เราเรียกโครงสร้างห้องสมุด
• สำหรับแต่ละสภาพแวดล้อมในแต่ละระบบเป้าหมาย (อาจเป็นระยะไกล) จะมีเซิร์ฟเวอร์ ("งานเริ่มต้น" ในเมนเฟรมพูด) ซึ่งดูแล ALL (ซ้ำ: ALL) อัปเดตทุกอย่างในโครงสร้างไลบรารี มีข้อยกเว้นบางประการ (เช่นผู้รักษาความปลอดภัยหรือทีมจัดการพื้นที่) แต่นอกเหนือจากนั้นไม่มีใคร (ซ้ำ: ไม่มีใคร) มีสิทธิ์ในการใช้การอัปเดตไฟล์ใด ๆ ภายในโครงสร้างไลบรารีนั้น ในคำอื่น ๆ : เซิร์ฟเวอร์ที่ได้รับการปรับปรุงอำนาจพิเศษให้กับโครงสร้างห้องสมุดทั้งหมด ข้อควรระวัง: OPS- ผู้คนจะเป็นบ้าถ้าคุณเดินเข้ามาเพื่อ จำกัด การเข้าถึงของพวกเขา (ในตอนแรกพวกเขาจะต่อต้าน ... ) ดังนั้นให้แน่ใจว่าคุณได้รับการคุ้มครองจากผู้บริหารระดับสูง (CxO) เพื่อกำหนดกฎการเข้าถึงเหล่านั้น ...
• ซอฟต์แวร์ที่เกิดขึ้นจริงการเปลี่ยนแปลงของฉันประกอบด้วยองค์ประกอบเดียว (แก้ไขรหัสเล็ก ๆ ในกลางดึก ... ) หรือมันอาจจะเป็นหลายร้อยหรือหลายพันแหล่งที่มาปฏิบัติการหรือสิ่งประดิษฐ์อื่น ๆ (ในช่วงสุดสัปดาห์ที่วางจำหน่าย) เพื่อให้พวกเขาสามารถจัดการกับสิ่งที่ควรจะย้าย (มากหรือน้อย) ร่วมกันในเวลาเดียวกันมีการรวมเข้าด้วยกันในสิ่งที่เรียกว่าแพคเกจการเปลี่ยนแปลงซอฟแวร์

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

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

---

2. บทบาทและการอนุญาต

---

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

ขั้นตอนที่ 1: กำหนดค่าการอนุญาต (ในระบบความปลอดภัย)

• กำหนดเอนทิตีความปลอดภัยในระบบความปลอดภัยของคุณด้วยชื่อที่กำหนดไว้อย่างดีสำหรับเอนทิตีเหล่านั้น ตัวอย่างไม่กี่ (เพิ่มเป็นคนที่คล้ายกันมากเพื่อให้เหมาะกับความต้องการของคุณ):

  • PrmUnitที่ใช้สำหรับการได้รับสิทธิ์ในการขอให้มีการส่งเสริมที่จะบอกว่าหน่วย -testing
  • PrmQAใช้สำหรับการขออนุญาตเพื่อขอโปรโมตเพื่อบอกQa - การทดสอบ (สมมติว่านี่เป็นระดับสูงสุดของการทดสอบ)
  • PrdEnduserใช้โดยผู้ใช้ปลายทางที่เกี่ยวข้องกับการทดสอบในระดับหนึ่งเพื่อระบุว่าพวกเขาพอใจกับผลลัพธ์ที่ได้จากการทดสอบบางประเภท และด้วยเหตุนี้ผู้ใช้ปลายทางจึงเห็นด้วยกับการเปลี่ยนแปลงที่ก้าวไปข้างหน้าในโครงสร้างห้องสมุด
  • PrdRelmgntใช้โดยผู้จัดการรีลีสเพื่ออนุญาตการเปิดใช้งานในการผลิต (= ระดับสุดท้าย / สูงสุดในโครงสร้างไลบรารี)

• กำหนดกลุ่มผู้ใช้ในระบบความปลอดภัยของคุณ ตัวอย่างไม่กี่ (เพิ่มเป็นคนที่คล้ายกันมากเพื่อให้เหมาะกับความต้องการของคุณ):

  • GrpDevsซึ่ง (พูด) ตรงกับนักพัฒนาของคุณ (อาจมากกว่า 1)
  • GrpEnduserซึ่ง (พูด) นั้นสอดคล้องกับผู้ใช้ปลายทางของคุณ (อย่างน้อย 1 คนควรมีผู้ใช้ที่คล้ายกันมากกว่า)
  • GrpRelMgntซึ่ง (พูด) ตรงกับผู้จัดการการปล่อยของคุณ (อย่างน้อย 1 คนโดยเฉพาะอย่างยิ่งผู้ใช้อีกไม่กี่คน)

• ให้สิทธิ์นอกจากนี้ยังใช้ระบบรักษาความปลอดภัยของคุณเพื่ออนุญาตการเข้าถึง " เอนทิตีความปลอดภัย " ที่เลือกสำหรับ " กลุ่มผู้ใช้ " ที่เลือก เพื่อดำเนินการตามตัวอย่างด้านบนนี่คือสิ่งที่เหมาะสม (ปรับให้เหมาะกับความต้องการของคุณ):

  • กลุ่มGrpDevsได้รับการเข้าถึง (เท่านั้น!) PrmUnitนิติบุคคลที่การรักษาความปลอดภัย
  • กลุ่มGrpEnduserได้รับการเข้าถึง (เท่านั้น!) PrdEnduserนิติบุคคลที่การรักษาความปลอดภัย
  • กลุ่มGrpRelMgntได้รับการเข้าถึง (ทั้งสอง!) นิติบุคคลที่การรักษาความปลอดภัย และPrmQAPrdRelmgnt

ขั้นตอนที่ 2: กำหนดค่าเวิร์กโฟลว์ (ในระบบ SCM)

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

นี่คือตัวอย่างของวิธีที่คุณกำหนดค่าระบบ SCM ของคุณเพื่อให้เกิดเวทมนตร์:

• หากผู้ใช้มีการเข้าถึงPrmUnitแล้วผู้ที่ได้รับอนุญาตดังกล่าวเพื่อขอส่งเสริมการหน่วย -testing เห็นได้ชัดว่าผู้ใช้ในกลุ่มGrpDevsเป็นผู้ใช้ที่ได้รับอนุญาตสำหรับเรื่องนี้ (หมายเหตุ: ไม่เช่นผู้ใช้ในกลุ่มGrpRelMgnt)
• หากผู้ใช้มีการเข้าถึงPrmQAแล้วผู้ที่ได้รับอนุญาตดังกล่าวเพื่อขอส่งเสริมการควบคุมคุณภาพ -testing เห็นได้ชัดว่าผู้ใช้ในกลุ่มGrpRelMgntเป็นผู้ใช้ที่ได้รับอนุญาตนี้ (หมายเหตุ: ไม่เช่นผู้ใช้ในกลุ่มGrpDevsหรือในกลุ่มGrpEnduser)
• หากผู้ใช้มีการเข้าถึงPrdEnduserผู้ใช้ดังกล่าวจะได้รับอนุญาตให้อนุญาตการเปลี่ยนแปลงที่กำลังดำเนินการไปข้างหน้าในโครงสร้างไลบรารี (ซึ่งโดยทั่วไปจะเป็นข้อกำหนดเบื้องต้นสำหรับผู้ใช้ในกลุ่มGrpRelMgntเพื่อให้สามารถตรวจสอบการเปลี่ยนแปลงได้) เห็นได้ชัดว่าผู้ใช้ในกลุ่มGrpEnduserเป็นผู้ใช้ (เท่านั้น) ที่ได้รับอนุญาตสำหรับสิ่งนี้
• หากผู้ใช้มีการเข้าถึงPrdRelmgntผู้ใช้ดังกล่าวจะได้รับอนุญาตให้อนุญาตการเปิดใช้งานในการผลิต (= ระดับสุดท้าย / สูงสุดในโครงสร้างไลบรารี)

---

3. คาดหวังสิ่งที่คาดไม่ถึงและเตรียมพร้อมสำหรับมัน

---

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

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

เกิดอะไรขึ้นเมื่อใดและเพราะเหตุใดและผู้ใช้ที่ได้รับอนุญาตรายใดได้อนุมัติแล้ว ... ล่วงหน้า?

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

---

PS: ฉันปล่อยให้การตัดสินใจของทุกคนถ้าคำตอบของฉันคือใช่หรือไม่สอดคล้องกับ DevOps

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

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

สิ่งนี้ไม่สามารถใช้ได้กับผลิตภัณฑ์ทั้งหมด ณ เวลาที่เขียนเป็นลายลักษณ์อักษรในฝรั่งเศส บริษัท ใด ๆ ที่อนุญาตให้ปล่อยเงิน (ส่วนใหญ่เป็นธนาคาร) จะต้องตรวจสอบให้แน่ใจว่าการทำธุรกรรมทุกครั้งจะถูกบันทึกไว้และดังนั้นจึงไม่เสี่ยงต่อการทำธุรกรรม
ในทางกลับกันพวกเขาไม่มีข้อผูกมัดทางกฎหมายในการติดตามข้อเสนอเชิงพาณิชย์หรือการประเมินความเสี่ยงเมื่อมีคนขอสินเชื่อและดังนั้นผลิตภัณฑ์ที่จัดการกับลูกค้าที่เลือกนี้และคำนวณค่าธรรมเนียมซึ่งจะอยู่ในข้อเสนอนั้นง่ายกว่า - ปล่อยรูปแบบการตรวจสอบ

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

ทรัพยากรที่เกี่ยวข้องคือมาตรฐานISO27001

IMHO ผู้พัฒนาและการดำเนินงานสามารถแสดงได้โดยไม่มีอะไรมากไปกว่าเพียงแค่ที่เก็บ git สองแห่งสำหรับ codebase เดียวกันโดยมีรูปแบบการอนุญาตที่แตกต่างกันไปดังนั้นทีมจะไม่แทรกแซงการทำงานของกันและกัน

ลองเรียกพวกเขาว่าDev.mygithub.co & ops.mygithub.coเช่นเดียวกับตัวอย่าง

ความคิดคือการที่นักพัฒนามีอิสระในการสร้าง / สาขา / ผสานกับเนื้อหาหัวใจของพวกเขา -git จะให้ตรวจสอบย้อนกลับเต็มและนั่นคือสิ่งที่สำคัญ here- ขณะเดียวกันในช่วงเวลาที่กรอบการกำกับดูแลหมายถึงความพยายามรีวิวขอดึงสามารถยกสำหรับ การรวมที่เกิดขึ้นในลักษณะที่ควบคุม

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

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

NB แบบจำลองที่อธิบายข้างต้นอาจถูกติดตามแม้ว่า Ops & Dev จะทับซ้อนกันโดยสิ้นเชิง!

สูงกว่ามีราคาแพงกว่า:

• dev และไซต์ ops ที่แตกต่างกันและวิธีการในการดำเนินงานจากที่หนึ่งไปยังอีก
• dev และ ops ระบบที่แตกต่างกันและวิธีการดังกล่าวข้างต้น
• dev และ ops git / vcs repositories & วิธีที่เกี่ยวข้องที่แตกต่างกัน
• dev ที่แตกต่างกันและ ops git / vcs branch (ป้องกัน) และวิธีการที่เกี่ยวข้อง

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

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