DevOps 및 업무 분리

이 질문은 고객에게 DevOps의 문화를 제시 할 때 거의 항상 발생합니다. 자체 애플리케이션을 설계, 개발, 빌드, 배포 및 실행하는 역할을 담당하는 교차 기능 DevOps 팀에 대해 이야기 한 후 그들은 항상 "개발자가 프로덕션에 액세스 할 수있을 때 업무 분리를 어떻게 구현합니까?"라고 묻습니다. 고객은 개발자에게 그 정도의 힘을 제공한다는 생각에 멈 춥니 다. 나는 그들을 비난하지 않는다. 당신은 테스트되지 않은 코드를 프로덕션에 푸시하는 것보다 더 이상 적절한 점검과 균형없이 코드를 프로덕션으로 푸시하는 팀원을 가져서는 안된다. (… 당신은 그렇게하지 않습니까?)

자동화 된 CI / CD (Continuous Integration and Continuous Delivery) 파이프 라인을 통해 테스트를 실행하고 취약성을 스캔하고 누가 요청하는지에 관계없이 프로덕션에 도달하기 전에 통과해야하는 다른 게이트를 추가 할 수있는 기회를 제공합니다. 문제는 이러한 자동화 게이트 중 어느 것도 감지 할 수 있다는 것입니다 악의적 인 코드를. 이를 위해서는 더 똑똑한 무언가가 필요합니다. 그리고이를 감지 할 수있는 AI가 생기기 전까지는 인간이 참여해야합니다.

직무 분리는 실제로 무엇을 의미합니까?

업무 분리는 개발자가 프로덕션에 액세스하지 못하도록하는 것과 관련이 없습니다. 업무 분리는 생산에 들어가는 모든 것을 주시하여 단일 개인이 시스템을 방해 할 수 없도록 두 번째 세트를 얻는 것입니다. 이것이 핵 미사일을 발사하기위한 두 개의 물리적 열쇠가 있고 열쇠 구멍이 인체가 도달 할 수있는 것보다 더 멀리 떨어져있는 이유입니다. 그것은 적어도 두 사람이 대륙간 발사체 미사일을 발사하고 열 핵전쟁을 위험에 빠뜨리는 것이 좋은 생각이라는 데 동의 함을 보장합니다. (… 잠시 동안 가라 앉게하십시오)

기존 솔루션은 너무 제한적입니다.

많은 회사에서 가장 먼저하는 일은 "의무"가 "직무"와 같다고 가정하여 운영 담당자 만 액세스를 허용하는 개발자의 프로덕션 액세스를 제한합니다. 그러나 이것은 단지 일을 느리게합니다. 일부는 개발자가 CI / CD 파이프 라인을 사용하여 프로덕션에 배포하도록 허용 한 다음 추가 예방 조치로 개발자가 파이프 라인 정의를 수정하지 못하도록 제한 할 수 있습니다.

두 명의 운영 직원이 시스템을 방해하기로 결정할 때까지 작동합니다. 그리고 뭐? 어쩌면 우리는 운영 직원에게 핵 키와 같은 암호의 절반 만 제공하여 두 사람이 무언가를 변경해야 할 수도 있습니다. 물론 농담입니다.하지만 직업이 나쁜 배우의 위험을 제한하는 것과는 아무런 관련이 없다는 생각이 들었습니다.

Dev vs. Ops가 아닙니다. 요청자 vs. 승인자입니다.

직무 분리의“의무”는 직함이 아니어도됩니다. 다른 배우 가되어야합니다 . 무언가를 요청하는 사람은 그 행동을 승인하는 사람이 될 수 없습니다. 정말 간단합니다.

이를 수행하는 한 가지 방법은 다음 세 가지 간단한 규칙에 따라 "GitOps"와 같은 관행을 채택하는 것입니다.

1. GitHub에 체크인하지 않으면 프로덕션에서 아무것도 변경되지 않습니다.
2. 풀 요청 없이는 GitHub의 트렁크 브랜치에 병합되지 않습니다.
3. Pull Request는 생성 한 사람이 승인 할 수 없습니다.

결론

이 워크 플로를 사용하면 변경 사항이 교차 기능 DevOps 팀, 전담 개발 팀 또는 전담 운영 팀에서 오는 것인지는 중요하지 않으며 모든 변경 사항은 승인되기 전에 다른 사람이 검토합니다. Voilà… DevOps로 업무 분리!