성공적으로 DevOps로 전환하는 방법에 대한 케빈 존스(Kevin Jones) 조언
목표 설정
“무엇을 달성하려고 하는가? 애플리케이션을 현대화하려는 것인가? 인프라를 혁신해 애자일 (Agile) 개발을 달성하고자 하는 것인가?”
케빈은 DevOps로의 전환과 관련해 기업들은 이러한 질문을 해야 하며, 분명한 목표를 제시하는 것이 확신을 갖지 못한 조직의 첫 걸음이라고 강조했습니다. 또한, 그는 기술적인 측면에서 조직이 실제로 지향하는 바를 파악하는 것이 중요하다고 생각하지만, 이는 비즈니스 측면에서 추구하는 것과 일치되도록 해야 한다고 우버(Uber)의 예를 들으면서 설명했습니다. 케빈은 ‘귀사가 우버(Uber)라면 이미 어느 정도 알아냈을 것입니다. 하지만, 항상 로드맵은 있고, 도달하려는 어떤 곳이 있기 마련입니다’라고 말했습니다.
적절한 DevOps 툴 선택
DevOps 전환 과정에서 조직들이 해야 하는 첫 번째 의사 결정 중 하나는 새로운 운영 프레임워크를 위해 어떤 툴을 채택하느냐 하는 것입니다. 이 단계에서 많은 조직들은 어떤 제품 또는 디바이스를 도입할 것인지 검토하는 것으로 시작합니다. 오늘날 IT 팀들이 이용할 수 있는 툴들은 거의 무한하기 때문에 기업은 자체 활용 사례에 가장 적합한 툴을 결정하는 것이 중요합니다.
핵심은 선택한 툴이 여러분이 가진 목표와 관련한 문제를 해결할 수 있도록 해야 한다는 것입니다
케빈 존스(Kevin Jones)
새로운 툴이나 플랫폼을 구입하기 앞서 해야 하는 일이 있는데요, 과연 무엇일까요? 바로 각 옵션들을 매우 세심하게 테스트하는 등 선제적으로 대응하는 것입니다. 예를 들어, 모니터링이 중요한 기능으로 지목된 경우, 선택한 툴이 여러분이 중요하게 평가하는 모든 요소들– 응답 시간, 메모리 사용량, 초당 응답 등 – 에 대해 보고하도록 해야 합니다. 시간을 갖고 새로운 툴의 성공 가능성에 대해 이러한 질문을 함으로써 채택한 디바이스들에 대해 보다 현명한 의사 결정을 할 수 있습니다.
부서 간 커뮤니케이션 활성화
DevOps로 전환할 때 대부분 조직들이 직면하게 되는 가장 까다로운 장애물은 비즈니스 부문과 기술 부문 간의 커뮤니케이션을 활성화하는 것입니다. 기업들은 빈번하게 DevOps 프로세스를 채택하지만, 업무 팀 간의 효과적인 협업에 필요한 non-siloed(사일로) 조직 구조를 채택하지 않는 경우가 흔히 발생합니다. 케빈은 한쪽에는 비즈니스 담당자들이 그리고 다른 쪽에는 인프라 및 기술 인력들이 있기 때문에 많은 조직에서 DevOps 팀들이 현재 진행되고 있는 일들에 대해 많은 부분을 통제할 필요는 없다고 이야기합니다. 이보다 조직 내 비즈니스 부문과 기술 부문 간의 커뮤니케이션을 활성화하는 것이 DevOps 철학의 핵심입니다.
한 부서 또는 담당자가 특정 툴을 채택하기를 원하는 경우 DevOps 팀이 참여해 인프라에 가치를 추가하고 불필요한 복잡성을 가중시키지 않으면서, 환경을 향상시킬 수 있는지를 판단하도록 지원해야 합니다. 채택할 수 있는 많은 툴들이 나와 있지만, 이들 팀들은 하나의 공동체로서 전반적인 목적을 달성하기 위한 현명한 의사 결정을 내릴 수 있습니다
케빈 존스(Kevin Jones)
프로덕션 이관, 티켓 백로그 및 변경 관리 계획으로 인한 막대한 워크로드로 인해 대부분 DevOps 팀에게 내부 커뮤니케이션은 물론, 팀 간의 커뮤니케이션은 어려운 과제가 되고 있지만, 케빈은 이것이 백시트(backseat) 접근을 위한 변명이 될 수 없다고 지적했습니다. 그는 DevOps 팀들은 일반적으로 매우 바쁘지만, 이러한 유형의 논의에 시간을 내서 해당 업무에 가능한 참여해야 한다고 강조했습니다. 여러 부서 간의 대화는 운영상 변화는 물론, 문화적 변화를 이끌어 냅니다.
DevOps의 성공 측정
다른 운영 방법론과 마찬가지로 DevOps도 결과에 대한 것입니다. 성공과 실패를 식별하는 능력은 새로운 프로세스를 개발할 때 피드백을 수집하는 데 있어 필수적입니다. 하지만, 많은 기업들은 DevOps와 같은 새로운 프로세스를 효과적으로 측정하는 것이 어렵다는 것을 깨닫고 있습니다.
케빈의 관점에서 비용, 현대화 및 성능 등 3가지 주요 측정 지표 예가 있습니다. 그는 “여러 다양한 유형의 결과가 있다고 생각합니다. 경제적인 결과에 대해 이야기할 수 있습니다. 재정적 관점에서 달성하려는 목표는 무엇입니까? 아마도 이는 돈과는 전혀 관련이 없을 수도 있습니다. 레거시 애플리케이션이나 레거시 인프라의 사용에서 보다 현대적인 인프라로의 마이그레이션을 추적하는 것일 수도 있습니다.”라고 덧붙였습니다.
시간 경과에 따른 애플리케이션 성능도 성공에 대한 측정 기준입니다. 이와 관련해 그는 몇 가지 기본적인 질문을 미리 해보도록 제안했습니다. “애플리케이션이 지난 달 또는 지난 주보다 우수한 성능으로 실행됩니까? 또한, 최종 사용자의 경험은 어떻습니까?”
목표를 성공적으로 달성하는지 여부는 비즈니스 부문과 기술 부문 간의 개방적인 의사 소통과 결속력에 달려 있습니다. 추구하는 결과와 이를 실현하는 데 사용하려고 계획한 툴을 결정하기 위해서는 협업이 필요합니다. 비즈니스 팀과의 정기적인 논의를 통해 DevOps 팀은 전환 과정의 전반에 대한 전문가적 지침을 제공할 수 있습니다.
DevOps가 귀사에서 효율적으로 운영되도록 하기 위해서는 명확한 최종 목표를 염두에 두고 시작해야 합니다. 추구할 목표가 있다면, 올바른 질문을 하도록 돕는 기준을 갖게 됩니다.
DevOps가 문화적인 측면이 강하며,가능한 모든 단계에서 참여해야 합니다
케빈 존스(Kevin Jones)
원문 : https://www.nginx.com/blog/transitioning-to-devops-advice-from-nginx-expert/
Docker. 컨테이너 관리 (0) | 2020.03.02 |
---|---|
Docker. 이미지 관리 (0) | 2020.03.02 |
Docker. Installation on CentOS (Amazon Linux) (0) | 2020.03.02 |
Docker. 특징 및 기능 (0) | 2020.03.02 |
Docker. Install (for CentOS) (0) | 2020.02.03 |