การนำไปใช้ (หรือตัวอย่าง) เป็นไปได้ของหลักการสี่ตาคืออะไร?

Michael Grünewaldเพิ่งโพสต์ความคิดเห็นนี้ :

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

แก้ไขฉันถ้าฉันผิด แต่ฉันได้รับการสอนว่า"หลักการสี่ตา"เป็นเรื่องเกี่ยวกับสิ่งที่ "อนุมัติให้เกิดขึ้น" หลังจากมนุษย์อย่างน้อย 2 คน (และ / หรือกระบวนการอัตโนมัติ) ให้พรก่อนหน้า หรือเพื่อใช้ถ้อยคำ (แก้ไขเล็กน้อย) เกี่ยวกับกฎ "man สอง (wo) man"จากWikipedia :

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

ภาระหน้าที่ด้านกฎระเบียบนั้นค่อนข้างแน่ใจอยู่นอกหัวข้อที่นี่ แต่ในบริบทของ "การป้องกันที่ปลอดภัย" การใช้แนวคิดที่เป็นไปได้ของหลักการสี่ตานี้มีความเป็นไปได้อย่างไรซึ่งอาจนำไปใช้กับแพลตฟอร์ม / OS / ฮาร์ดแวร์ใด ๆ

หนึ่งในการนำไปใช้กับโค้ดคือโมเดล Pull Request (PR) ที่ได้รับความนิยมโดย GitHub

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

วิธีนี้ช่วยให้สามารถทดสอบการผสานจากรหัสรีลีสจริง (master) ด้วยโค้ดใน PR ในวิธีอัตโนมัติ (เทรวิสเป็นที่นิยมมากที่สุดสำหรับโครงการสาธารณะจริง ๆ ) และให้ฟีดแรกกับคุณภาพของโค้ด Travis CI (ตัวอย่าง) สามารถทำงานกับผลลัพธ์ของต้นแบบจริงด้วยรหัสจากคำขอดึงที่ผสานเข้าไปดังนั้นจะล้มเหลวหากการผสานเป็นไปไม่ได้หรือถ้าคำสั่งที่กำหนดไว้ใน travisci.yml กลับไม่ใช่ทางออกศูนย์ รหัส

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

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

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

รีวิวรหัส

นี่เป็นเรื่องเกี่ยวกับการมีคนอย่างน้อย 1 คนดูรหัสที่เขียนโดยใครบางคนเช่นประเมินว่าเป็นไปตามเกณฑ์ที่กำหนดไว้ล่วงหน้าเช่น:

• มาตรฐานการเข้ารหัส (เยื้อง ฯลฯ )
• เอกสารประกอบแบบอินไลน์
• การบำรุงรักษารหัส
• การจัดการข้อผิดพลาด
• ครบถ้วน (เช่นif/then/elseหรือcase/whenสร้างครอบคลุมทุกกรณีที่เป็นไปได้)

การอนุมัติเพื่ออัพเดตสภาพแวดล้อมเป้าหมายบางอย่าง

นี่คือการยืนยันอย่างน้อย 2 ครั้งจากบุคคลบางคนและ / หรือระบบอัตโนมัติก่อนที่จะได้รับอนุญาตให้อัปเดตสภาพแวดล้อมเป้าหมายบางอย่าง (ซึ่งอาจมีชีวิตอยู่หรืออาจเป็นอะไรที่คล้ายกับไฟล์ต้นแบบ / ไลบรารีพื้นฐาน) ตัวอย่างบางส่วนคือ:

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

นี่คือกลยุทธ์ / รูปแบบที่ฉันนึกได้:

แยกหน้าที่

อย่างน้อย DevOps ของฉันไม่ได้หมายถึงการรวบรวมทั้ง dev และ ops ในบุคคลเดียว ดังนั้นจึงยังคงเป็นไปได้ที่จะแยกหน้าที่เช่นเดียวกับที่เขียนรหัส (dev) ไม่ใช่ผู้ดำเนินการ (ops)

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

ปรับใช้ทริกเกอร์

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

เมื่อเรียกใช้แล้วระบบอัตโนมัติสามารถดำเนินการต่อไปเพื่อดำเนินการปรับใช้

การเขียนโปรแกรมคู่

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

ไอ้เวรตะไล

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