DevOps 텍스트 교육
더 안전한 프로덕션 배포를 위해 왜 피드백을 활성화해야 하나요?
경쟁이 치열한 시장에서 고객에게 신속히 서비스를 제공하고 요구를 계속 충족하려면 품질 보증과 운영 부서를 개발팀과 분리한 구조를 받아들이기 어렵습니다. 하지만 많은 개발자가 조직의 관료적 절차에 불만을 표시하면서도, 자기 팀에서 품질 보증 및 운영 전문가와 협력할 기회가 생겼을 때 감독 없이 프로덕션에 배포하기를 두려워합니다. 더 안전한 프로덕션 배포를 위해 적용해야 할 기법과 조치를 살펴봅시다.
DevOps에서 업무가 지속적으로 흐르게 하는 방법
원활하고 지속적인 흐름을 유지하는 성공적인 DevOps 조직 대부분은 프로덕션에 작은 배치로 변경을 자주 배포합니다. 그러면 DevOps 팀의 모든 사람이 변경사항을 평가하고 이해하며, 필요하면 수정할 수 있습니다.
자동화된 배포 파이프라인을 구축하는 것만으로는 충분하지 않습니다. 프로덕션과 사전 프로덕션에서 변경이 어떤 결과를 냈는지 빠르게 피드백을 받으려면 운영 텔레메트리를 배포 파이프라인에 통합해야 합니다. 또한 전체 가치 흐름과 배포 파이프라인이 정상적으로 지속되도록 하는 것이 모든 DevOps 팀원의 책임이라는 공통의 문화를 만들어야 합니다.
텔레메트리를 활용해 더 안전하게 배포하기
설계하고 코딩한 목적대로 작동한다는 것을 입증하기 전에는 변경과 배포를 ‘완료’로 표시하지 않습니다. 배포 후에는 바뀐 모듈의 지표, 새로 만든 지표가 있다면 그 지표, 그리고 변경에 영향을 받을 수 있는 다른 구성 요소의 지표를 면밀히 모니터링합니다.
사전 프로덕션에서 자동화된 테스트를 실행하고 텔레메트리로 테스트 대상 시스템을 모니터링하더라도 프로덕션 문제는 발생합니다. 모든 문제를 막을 수는 없지만 발생 시 바로잡을 준비는 충분히 할 수 있습니다. 변경으로 배포 파이프라인이 중단되면, 문제를 되돌리고 파이프라인을 정상화하는 데 필요한 모든 분야의 전문가를 모으세요. 문제 해결에 자주 쓰는 방법 세 가지는 다음과 같습니다.
- 기능 끄기: 문제를 해결하는 가장 쉬운 방법입니다. 긴급히 코드를 배포할 필요 없이 기능 토글로 기능을 끕니다. 배포한 내용의 잘못된 부분을 서둘러 수정할 필요가 없어, DevOps 팀이 시간을 들여 근본 원인을 제대로 파악하고 기법을 개선하여 비슷한 문제가 재발할 가능성을 줄일 수 있습니다.
- 새 변경으로 문제 수정하기: 문제를 해결할 새 코드를 배포합니다. 전통적 IT 조직에서 새 변경으로 프로덕션 문제를 수정하는 것은 위험합니다. 그러나 DevOps 조직에서 테스트 자동화, 자동 배포, 포괄적인 프로덕션 텔레메트리를 갖추었다면 매우 효과적이고 효율적이며 안전하게 사용할 수 있습니다.
- 변경 롤백하기: 잘못된 코드를 제거합니다. 그러면 문제가 사라지기를 기대할 수 있습니다.
개발자가 실제 운영에서 피드백을 받게 하기
DevOps 팀원을 순환 배치하여 운영팀의 책임을 맡고 운영 인시던트에 대응하게 하세요. 이렇게 하면 가치 흐름의 모든 사람이 후속 작업 단계의 과제와 책임을 체감합니다. 개발자, 테스터, 아키텍트, 설계자, 관리자와 책임자도 비정기 운영 당직에 배치하여 새벽 3시에 인시던트 경보 전화를 받게 합니다. 가치 흐름의 모든 사람이 일상 업무에서 내리는 결정에 어떤 결과가 따르는지 분명히 알게 됩니다.
이런 순환 배치는 운영 전문가가 소외되거나 혼자라는 느낌을 줄이는 데 도움이 됩니다. DevOps 팀의 모든 사람이 프로덕션 인시던트 해결, 기술 부채 감소, 새 기능 개발 사이에 적절한 균형을 맞추는 데 기여합니다. 새벽 3시에 아키텍트와 개발자를 깨우면 인시던트는 어느 때보다 빨리 해결됩니다.
개발자가 고객이 소프트웨어를 사용하는 모습을 관찰하면 무엇을 곧바로 개선해야 할지 깨닫는 순간이 많습니다. 아키텍트, 설계자, 개발자와 테스터가 엔지니어링 수명 주기의 다른 후속 작업 단계를 내부에서 관찰할 때도 마찬가지입니다. 자신이 한 일이 후속 단계에 미치는 영향을 이해하면 새로운 관점에서 품질을 높이고 산출물을 다듬어 후속 단계가 더 잘 일하도록 도울 수 있습니다. 모든 팀원이 비기능 운영 요구사항을 백로그에 담아 일상 업무의 일부로 맡기 시작합니다. DevOps 조직에 빠르고 지속적인 피드백 루프가 있어야 가능한 일입니다.
개발자가 직접 시스템을 운영하게 하기
실제 프로덕션 시스템에서 얻은 학습 경험을 개발팀에 전달하기는 매우 어렵습니다. 그래서 Google과 같은 선도적 DevOps 조직은 제품의 초기 출시 기간과 그 이후에 개발팀이 소프트웨어 운영을 맡게 합니다. 개발자가 제품을 관리하는 동안 운영 엔지니어는 자문을 제공합니다. 약 6개월 동안 프로덕션에서 충분히 안정적임이 입증되면 운영팀에 인계합니다. 프로덕션의 제품이 과거와 현재의 결함, 텔레메트리 적용 범위, 업무 시간 외 인시던트, 느슨하게 결합된 아키텍처 설계, 변경과 배포의 안전성 등 여러 점검 항목을 충족해야 인계할 수 있습니다.
운영팀이 관리하는 동안 알려지지 않았던 심각한 설계 및 코딩 문제가 드러나면 개발자에게 다시 인계할 수 있습니다. 개발자가 관리하는 단계에서 개발팀은 소프트웨어를 안정화할 책임을 맡고 운영 엔지니어는 자문 역할을 합니다.
결론
이 장에서는 DevOps 조직의 배포 파이프라인이 원활하고 더 안전하게 흐르게 하는 여러 기법을 살펴봤습니다.
이 기법은 DevOps 팀에서 개발자와 운영 엔지니어가 서로 존중하고 협업하는 모범을 보여 줍니다.
