DevOps 텍스트 교육
DevOps 배포 파이프라인을 어떻게 보호하나요?
앞에서 배운 원칙에 따라 IT 조직의 지속적 제공을 위한 배포 파이프라인을 구축하면, 본인과 DevOps 팀은 외부 승인 없이 낮은 위험으로 프로덕션에 배포할 수 있습니다. 이제 대부분의 프로덕션 배포에서 변경 승인 절차를 거치지 않아도 됩니다. 외부 권한자에게만 의존하는 대신 제대로 설계한 소프트웨어 제공 방법론, 자동화된 테스트와 모니터링, 환경의 지능형 경보를 활용하기 때문입니다. 하지만 보안과 규정 준수는 여전히 DevOps 팀의 중요한 책임입니다. 법적 요구사항을 충족할 뿐 아니라 고객을 잘 보호하기 위해서입니다. 조직의 보안 및 규정 준수 전문가에 계속 의지하고 협력하되, 조직에 적용되는 법규에 맞는 안전한 시스템을 설계하는 일을 일상 업무이자 습관으로 삼아야 합니다.
프로덕션 시스템의 변경 유형
- 표준 변경: 위험이 낮고 승인받을 필요가 없으며, 완전히 자동화되어 기록되므로 빠르게 배포합니다. 데이터베이스 조회 테이블 및 콘텐츠 업데이트, 스타일 변경, 운영체제나 데이터베이스 또는 기타 외부 구성 요소의 표준 패치가 이에 해당합니다.
- 일반 변경: 위험이 높고 변경 자문 위원회(CAB)의 승인이 필요합니다. 위원회는 변경을 평가하기 위해 변경 요청서(RFC)를 요구합니다. 위원 대부분이 변경을 평가할 지식이 부족하여 리드 타임이 깁니다. 변경을 보류했다가 결국 경험과 직감, 요청자에 대한 편견을 바탕으로 결정을 내립니다.
- 긴급 변경: 위험이 높고 고위 경영진의 승인이 필요합니다. 고객에게 영향을 미치는 심각한 프로덕션 오류, 잘못된 배포의 수정, 보안 패치, 서비스 복구 등이 이에 해당합니다.
변경 유형과 관계없이 DevOps 팀은 모든 변경을 변경 관리 및 업무 계획 시스템(Remedy, Jira 등)에 문서화하여 팀 안팎의 모든 사람이 볼 수 있게 해야 합니다.
자동 배포 성공 실적을 활용해 일반 변경을 표준 변경으로 전환하기
일반 변경보다 표준 변경의 비중을 높여야 변경 자문 위원회(CAB)의 승인을 피하고 업무 흐름을 빠르게 하며 배포 파이프라인의 품질을 높일 수 있습니다.
본인과 DevOps 팀은 성공적인 자동 배포 기록을 활용해 가능한 한 많은 일반 변경을 표준 변경으로 전환합니다. CAB에 배포 이력과 프로덕션 인시던트 목록을 보여 주고, 자동 프로덕션 배포로 인시던트가 발생하지 않거나 영향이 미미하다는 점을 입증합니다.
일반 변경의 배포 속도 높이기
일반 변경으로 남아야 하는 변경의 경우 변경 요청서(RFC) 작성 절차를 자동화하세요. 비프로덕션 시스템의 자동화 및 비자동화 테스트 결과, 해결하거나 해결하지 못한 인시던트, 모니터링 기록과 로그를 RFC에 연결합니다. 첫 번째 RFC에 CAB가 원하는 모든 정보를 제공해 위원회의 일을 간소화하고 승인 속도를 최대한 높이세요.
승인 후 클릭 한 번으로 일반 변경을 배포할 수 있게 하세요. CAB와 정기적으로 일반 변경 유형을 검토하고 어떤 요건을 충족하면 표준 변경으로 전환할 수 있을지 파악하여 명시합니다. 이렇게 하면 DevOps 조직의 변경 대부분을 자동으로 배포할 수 있습니다.
DevOps 조직의 관료적 절차와 타인에 대한 의존 줄이기
조직이 커질수록 관료적 절차가 늘기 쉽습니다. 눈에 띄지 않게 기하급수적으로 증가하고 오랫동안 지속됩니다. 자신의 업무를 승인받기 위해 한 단계 위의 권한과 통제 장치에 의존하면, 더 이상 자신에게 권한이 있고 업무 결과를 책임진다고 느끼지 않습니다. 결국 상위 승인권자도 반복적으로 실패합니다.
결국 이 승인권자도 또 다른 권한자에 의존해 감사를 받아야 합니다. 이 악순환은 회사가 다시 조직을 개편할 때까지 길어집니다. 개편 후에는 조금 다른 형태의 새 악순환이 기존 악순환을 대신할 가능성이 거의 100%입니다.
직무 분리와 팀 밖의 통제 장치에 의존하면 소프트웨어 제공 흐름이 느려지고 품질이 떨어질 뿐 아니라 조직의 보안도 약해진다는 점을 기억해야 합니다. 미국의 한 대형 금융 기관은 개발자가 ATM 소프트웨어에 넣은 백도어 때문에 ATM 사기 피해를 입었습니다. 외부 감사인, 보안 전문가, 규정 준수 담당자, CAB 승인권자 중 누구도 프로덕션에 배포된 부정한 소스 코드를 발견하지 못했습니다. 코드를 작성한 팀 내부에서 체크인 검사 및 코드 검토 같은 기본 DevOps 기법을 적용했어야 발견할 수 있었습니다.
빠르고 안전하게 제공하려면 타인에 대한 의존과 직무 분리를 줄이세요. 이런 방식은 DevOps 팀이 책임지는 일을 가로막기 때문입니다. 팀 내부에서 코드 체크인 검사, 페어 프로그래밍, 동료 검토, 자동화된 테스트 및 모니터링 등의 통제 장치를 사용하세요. 법적으로 직무 분리가 필수여도, 팀 내부의 통제는 감사인과 규정 준수 담당자가 충분한 정보를 토대로 더 나은 결정을 빨리 내릴 수 있도록 돕습니다.
결론
DevOps는 규정 준수와 정보 보안에 새롭고 역동적인 환경을 가져옵니다. 인프라가 코드로 관리되고 코드로 시스템을 생성하거나 없애며 코드가 자동 배포될 때, 감사인이 실제로 무슨 일이 일어나는지 파악하기는 쉽지 않습니다. 이는 새로운 과제인 동시에 더 간소하고 정교한 감사 및 규정 준수 장치를 마련하고 담당자를 배치할 기회입니다.
DevOps 팀에서 정보 보안, 규정 준수, 배포 파이프라인 속도 개선은 모두의 업무입니다. 규정 준수 담당자가 팀의 높은 제공 품질을 입증하는 정보, 로그, 보고서 및 지표를 셀프서비스로 이용하도록 하는 것이 중요한 목표입니다. 그러면 관료적 승인 절차를 간소화하거나 아예 없앨 수 있습니다.
