사안 원칙의 가능한 구현 (또는 예)은 무엇입니까?

Michael Grünewald는 최근 이 의견을 게시 했습니다 .

언급하지 않은 매우 중요한 방법은 금융에서 규제 의무 또는 안전 보호 수단으로 사용되는 "4 가지 원칙"입니다. 소프트웨어 산업에서는 코드 검토와 같이 다양한 방식으로 구현되지만 라이브 시스템에 영향을주는 명령을 검증하는 데에도 사용할 수 있습니다.

내가 틀렸다면 저를 바로 잡으십시오. 그러나 "4 개의 눈 원리" 는 적어도 2 명의 인간 (및 / 또는 자동화 된 과정)이 이전의 축복을 준 후에 "발생하도록 승인 된"것에 관한 것입니다. 또는 대한 (약간 수정) 표현 사용 "두살 (WO) 매뉴얼 규칙" 에서 위키 백과 :

2 인 규칙은 특히 중요한 재료 또는 작업에 대해 높은 수준의 보안을 달성하도록 설계된 제어 메커니즘입니다. 이 규칙에 따라 모든 액세스 및 조치에는 항상 두 명의 승인 된 사람이 있어야합니다.

규제 의무는 확실히 여기서는 다루지 않지만 "안전 보호"와 관련하여이 네 눈 원칙의 가능한 개념적 구현은 무엇이며 어떤 플랫폼 / OS / 하드웨어에 적용될 수 있습니까?

configuration four-eyes

— Pierre.Vriens
소스

답변:

코드 구현 중 하나는 GitHub가 대중화 한 풀 요청 모델 (PR)입니다.

주요 이유는 제품의 소규모 관리자 만 코드를 릴리스 브랜치에 병합 할 수 있다는 것입니다. 모든 새로운 기능 / 버그 수정은 새 브랜치에서 발생하며 완료되면 풀 요청으로 정의됩니다.

이를 통해 실제 릴리스 (마스터) 코드와 PR의 코드를 자동으로 (트래비스가 실제로 공개 프로젝트에 가장 많이 사용되는) 코드와의 병합을 테스트하고 코드 품질에 대한 첫 번째 피드백을 제공 할 수 있습니다. Travis CI (예 : Travis CI)는 끌어 오기 요청의 코드가 병합 된 실제 마스터 결과에서 실행될 수 있으므로 병합이 불가능하거나 travisci.yml에 정의 된 명령이 0이 아닌 종료를 반환하면 실패합니다 암호

4 가지 눈 원칙에 대해 자동 테스트가 통과 된 후에도 변경 가능한 내용을 검토하고 승인하려면 최소한 한 사람 (PR 작성자가 아닌 사람)이 4 명의 눈을 검토하도록 변경하기 전에 변경을 검토하고 승인해야합니다. 변화.

검토 자 쿼럼이 충족되면 자동으로 병합하거나 관리자가 수동으로 병합해야하는 다양한 옵션이 있습니다.

검토 및 병합 권한을 분리하여 더 많은 사람들이 병합 상태를 "투표"할 수있는 권한을 부여하면서 실제로 병합을 수행 할 수있는 사람을 제한 할 수 있습니다.

— 텐시 바이
소스

답변의 사소한 수정 내용 (오타 사항)을 확인하십시오. 마음에 들지 않으면 롤백하거나 다시 편집하십시오. 또한, 나는 이러한 PR에 대해 생각하지 않았으므로 매우 적용 가능하다고 생각합니다. 나는이 대답을 받아 들인 것으로 표시 할 것입니다 (물론 내가 알고있는 것 자체에서 답을 얻었습니다). 미래에 보장 할 수는 없지만 더 나은 답변을 게시하려면 마음을 바꿀 수 있습니다. 정보 : "실제 릴리스 (마스터) 코드와 PR의 코드를 자동으로 병합하여 테스트 할 수 있습니다."새로운 질문을 게시해야합니까?

— Pierre.Vriens

@pierre 당신은 당신이 원하는대로 마음을 자유롭게 바꿀 수 있습니다 :) 제안 된 코드를 테스트하기 위해 Travis CI (예를 들어)는 풀 마스터 코드가 병합 된 실제 마스터의 결과에서 실행될 수 있습니다. 병합이 불가능하거나 travisci.yml에 정의 된 명령이 0이 아닌 종료 코드를 리턴하면 실패합니다. FWIW, 인터넷 검색 소리가 가장 좋은 방법 IMHO, 주제는 크다

— Tensibai

@pierre와 편집의 경우, 한 가지 점, 4 개의 눈 원칙은 검토 할 사람이 1 명 이상 있어야한다는 것입니다. 즉, 2 명의 사람이 변경 사항을 보지 못했음을 의미합니다 (작가는 검토하지 않았습니다). 그것은 오직 하나 일 수 있고, 프랑스어에서는 아마도 단 하나 일 수 있습니다 : p). 내가 할 할 것 같은 유창한 영어로 아니지만, 나는 잠시 내가 :) 편향 될 수있는 첫 번째 지점이 유효 (, 그것을 하나의 리뷰를 만드는이 한보기 2 개 독자를) 생각

— Tensibai

아하, 그것은 당신이 의미하는 바입니다. 이제 나는 그것을 얻습니다. BTW : 예 mple (EN)에, 아니 전 전자 mple (FR에서와 같이) ...

— Pierre.Vriens

@ Pierre.Vriens는 이중 언어로 자동 수정을 비난합니다 :)

— Tensibai

코드 리뷰

이것은 적어도 한 사람이 누군가가 작성한 코드를 보도록하는 것입니다. 예를 들어 다음과 같은 사전 정의 된 기준을 충족하는지 평가합니다.

코딩 표준 (들여 쓰기 등).
인라인 문서.
코드의 유지 보수성.
오류 처리.
완전성 (예 if/then/else또는 case/when구조는 가능한 모든 경우를 포함).

일부 대상 환경을 업데이트하기위한 승인

이것은 어떤 대상 환경 (라이브되거나 마스터 파일 / 기준 라이브러리와 같은 것일 수 있음)을 업데이트하기 전에 개인 및 / 또는 자동화 시스템으로부터 적어도 2 번 확인을받는 것입니다. 몇 가지 예는 다음과 같습니다.

실행 가능한 구성 요소에서 소스 구성 요소를 변환 (빌드) 할 때 제한된 경고 집합 만 허용됩니다.
일부 자동화 된 테스트 세트는 프로브없이 완료되어야합니다.
일부 인간은 사전 승인을 표시해야합니다 (그렇지 않으면 대상 환경을 업데이트하려는 시도가 자동으로 실패 함).

— Pierre.Vriens
소스

이들은 내가 생각할 수있는 전략 / 패턴입니다 :

의무 분리

필자의 견해에 따르면 DevOps는 한 사람에게 dev와 ops를 모두 구현한다는 의미는 아닙니다. 따라서 코드를 작성하는 사람 (dev)이 코드를 실행하는 사람 (ops)이 아닌 의무를 분리하는 것이 여전히 가능합니다.

예를 들어, 실제 환경에서 SQL 문을 실행하려는 경우 하나는 SQL을 작성하고 다른 하나는 SQL 문을 실행합니다. 이 가정은 실행뿐만 아니라 실행뿐만 아니라 SQL에 대한 이해가 필요하다는 것입니다.

배포 트리거

지속적으로 배포 할 가치가있는 동안. 규제가 엄격한 산업의 팀은 다른 (별도의) 당사자를 지정하여 자동 배포 대신 배포를 트리거 할 수 있습니다. 체크리스트, 자동 테스트, 체크섬은 배포를 트리거하기 전에 가능한 점검입니다.

일단 트리거되면 자동화를 진행하여 배치를 실행할 수 있습니다.

페어 프로그래밍

개인적으로 저는이 기술을 감사 및 점검 및 균형 원칙을 만족시키는 방법으로 인용하지 않았습니다. 그러나 잠재적 인 전략이라고 생각합니다.

MFA

나는 이것으로 조금 스트레칭 할 수도 있지만, 어떤 이유로 시스템에 일방적 인 입력을 원하지 않는 경우 누군가 누군가가 암호를 보유하고 다른 사람이 한 번의 코드로 토큰이나 장치를 보유 할 수 있습니다. 따라서 시스템을 평가하려면 2 명이 참석해야합니다.

— 켄슈
소스

이 흥미로운 변형에 대한 감사합니다! 전에는 "페어 프로그래밍"에 대해 들어 본 적이 없습니다. "4 손"으로 피아노를 연주하는 변형과 같습니다.

— Pierre.Vriens

최근에 내가 본 것 중 가장 집중적 인 페어 프로그래밍을 수행하는 회사와 인터뷰를했습니다. 그들은 각각 하나의 전용 모니터와 하나의 공유 모니터가있는 두 대의 컴퓨터로 "포드"설정을했습니다. 모든 개발은 쌍으로 이루어졌다. 모든 사람을위한 것은 아니지만 모든 보고서에 따르면 잘 작동합니다.

— Dave Swersky