DevOps 텍스트 교육

DevOps는 IT 문제를 어떻게 해결하나요?

지속적으로 배포합니다

막 시작한 스타트업부터 Fortune 100 기업에 이르기까지, 다양한 규모와 소프트웨어 제품 및 서비스 포트폴리오를 가진 기업이 이미 다음을 입증했습니다. DevOps를 도입하면 독립적이고 자립할 수 있는 소규모 팀이 매일 수십 건의 프로덕션 배포를 수행합니다. 프로덕션과 유사한 환경에서 설계하고 빌드하고 제공하고 테스트합니다. 3개월에 한 번, 모두가 잠든 자정 이후에 프로덕션 시스템에 코드를 릴리스하는 방식은 이제 필요하지 않습니다. 하루에도 여러 번, 무엇보다 정상 업무 시간에 코드를 릴리스하면서도 고객과 시장은 소프트웨어를 계속 이용하고 혜택을 누립니다.

DevOps로 작은 기능을 자주 제공할 수 있을 뿐 아니라, 다크 론치 기법으로 규모가 큰 기능의 작은 조각을 프로덕션에 자주 제공할 수 있습니다. 구성 설정으로 큰 기능을 켤 때까지 이 조각은 프로덕션에서 비활성 상태로 대기합니다. 이 작은 기법만으로도 코드를 한꺼번에 배포해 기존 프로덕션 시스템에 예측할 수 없는 부작용이 생기거나, 조직에 혼란과 책임 전가가 발생하는 일을 피할 수 있습니다. 팀의 삶의 질도 크게 나아집니다.

사명을 중심으로 팀을 구성합니다

경쟁사보다 큰 사명을 품고 시장에 서비스를 제공하기 위해 내부 또는 외부 고객을 위한 제품, 서비스, 역량, 마이크로서비스를 중심으로 IT 부서에 장기 팀을 구성합니다. 프로젝트가 끝나는 즉시, 또는 끝나기도 전에 해체되는 임시 프로젝트 팀을 구성하는 방식에서 벗어납니다.

임시 프로젝트 팀에서는 구성원이 자신의 프로젝트가 조직의 큰 사명에서 어디에 위치하는지 거의 모르기 때문에 자기 기여에 충분히 책임지기 어렵고, 업무에 대한 적절한 피드백도 받지 못합니다. 데이터베이스 개발, 프런트엔드 설계, 번역 등 각자의 전문 분야에 해당하는 일이 여러 프로젝트에서 끊임없이 밀려와 계속 방해를 받습니다.

장기 팀 모델에서는 팀이 자신의 업무와 그 산출로 가능해진 IT 및 비즈니스 성과에 기꺼이 책임을 집니다. 자신들의 기여가 조직의 큰 사명에서 어떤 위치를 차지하며 얼마나 중요한지 잘 알고 있습니다.

비즈니스 목표를 달성할 시스템을 구축합니다

본인과 팀은 고객에게 서비스를 제공하고 조직의 사명을 이루기 위해 급여를 받는다는 점을 잘 알고 있습니다. 그래서 조직과 고객의 모든 사람의 시간과 자원을 존중합니다. 장기 프로젝트에 전념하기 전에 IT 솔루션에서 기대하는 비즈니스 가치를 시험하고 검증합니다. 만들고자 하는 것의 모델, 프로토타입, 여러 A/B 변형 또는 경량 버전을 고객에게 보여 줍니다. 이후 반응과 피드백을 측정하고 기록하여 제품과 서비스를 어떻게 다듬을지, 고객이 좋아하기는 하는지 파악합니다.

단지 느낌이 좋다는 이유로 제품에 기능을 추가하지 않습니다. 아이디어를 시험하여 조직의 자원을 들여 만드는 것이 수익에 기여하고 경쟁사와의 긍정적인 차별점을 만들 가능성이 매우 높다는 것을 보여 줄 구체적이고 시연 가능하며 재현 가능한 증거를 확보합니다.

품질과 모니터링을 내장합니다

소프트웨어 제공 및 운영 수명 주기의 모든 단계에 빠르고 안정적이며 충분한 피드백 루프를 마련합니다. 품질은 특정 팀만의 일이 아니므로 모두가 품질을 내장하려고 노력합니다. 자신의 업무를 제대로 수행했는지 확인하기 위해 다른 팀의 피드백을 기다리거나, 프로덕션에 코드를 배포할 때 다른 사람의 허락을 구할 필요가 없습니다. 설계, 코드, 테스트, 인프라에 대한 동료 검토를 팀에 맡기고 신뢰합니다.

측정하고 테스트할 수 있는 모든 기능에 테스트 자동화와 모니터링(텔레메트리)을 구축합니다. 코딩하고 제공할 가치가 있는 기능은 자동화된 테스트를 통해 지속적이고 안정적이며 빠르고 일관되게 검사할 가치도 있습니다. 또한 이 기능에서 얻은 결과가 애초에 만든 목적과 일치하는지 확인하기 위해 지속적인 모니터링과 내장 분석 기능이 필요합니다. 프로덕션과 비프로덕션을 포함한 모든 환경에 해당합니다.

코드 저장소에 체크인할 때마다 운영 환경을 자동으로 조정하거나 재구성하며, 필요하면 다시 구축합니다. 영향을 받는 애플리케이션도 자동으로 다시 빌드하고 모든 자동화된 테스트를 실행해 기존 기능과 최신 체크인의 목적을 검증합니다. 검증에 성공하면 같은 변경을 프로덕션에도 자동 적용합니다.

애플리케이션의 내장 분석 기능과 텔레메트리가 소프트웨어 및 운영 환경의 주요 이벤트를 계속 모니터링하고 기록합니다. 주문 수, 로그인 수, CPU 사용률, RAM 사용량, CPU 부하, 오류 수, 데이터베이스 쿼리 소요 시간 등 주요 지표가 지속적으로 기록되어 실시간으로 표시됩니다. 팀은 배포의 부정적인 영향을 몇 분, 빠르면 몇 초 안에 알아차릴 수 있습니다. 그래서 빠른 피드백 루프가 신속한 작업에 필수적입니다.

오류에서 배우고 가르칩니다

오류가 발생하면 침착하고 자신 있게 해결합니다. 자동화된 테스트와 텔레메트리에서 확보한 과학적 증거를 바탕으로 인시던트의 근본 원인을 찾습니다. 문제를 해결한 뒤 빠진 테스트 케이스나 텔레메트리를 발견하면 수정 사항과 함께 코드 저장소에 추가합니다.

복잡한 시스템에서는 한 사람이 모든 것을 알거나 예견할 수 없습니다. 따라서 조직은 오류를 뜻밖의 나쁜 일로만 보지 않고, 제품과 서비스가 성숙하는 과정의 일부로 봅니다. 오류는 배우고 성장할 기회입니다. 개인과 조직이 새롭게 배울 수 있는 계기로 받아들입니다.

책임을 묻지 않는 사후 검토를 하면 인시던트의 근본 원인을 더 잘 파악하고, 같은 오류나 비슷한 오류를 피할 방법을 찾을 수 있습니다. 팀과 소프트웨어에서 얻은 국지적 교훈을 조직 전체에 도움이 되는 지식으로 전환합니다.

본인과 팀은 오류 때문에 처벌받지 않습니다. 인시던트에서 배우고 교훈을 나눈 공로를 인정받습니다. 그 기여 덕분에 조직의 여러 팀이 비슷한 인시던트를 피하는 법을 알게 됩니다.

비즈니스가 성장할수록 팀을 더 잘 확장합니다

개발자 1명에서 1,000명으로 성장하는 일반적인 조직을 생각해 보세요. 조직이 작을 때는 개발자가 코드를 계속 빌드하고 프로덕션에 배포합니다. 조직이 커지면 조직 및 관료 체계가 훨씬 복잡해지고 실수를 더 두려워하게 됩니다. 프로덕션에 코드를 배포하는 데 더 많은 조율과 의사소통이 필요합니다. 그 결과 조직이 성장할수록 개발자 한 명의 하루 평균 코드 배포 횟수는 보통 감소하고, 잘해야 그대로 유지됩니다.

고성과 DevOps 조직은 개발자가 늘어날수록 개발자 한 명의 하루 평균 코드 배포 횟수를 늘립니다. Google, Amazon, Facebook, Netflix, Apple은 적합한 소프트웨어 아키텍처, 팀, 사명, 리더십, 문화가 있으면 가능하다는 점을 이미 입증했습니다. 여러분의 조직이 다음 고성과 DevOps 조직이 될 수 있습니다.

원본 차트는 팀 규모가 커짐에 따라 개발자 1인당 일일 배포 횟수가 얼마나 늘어나는지 비교합니다.

원본 다이어그램 보기 ↗

결론

고성과 DevOps 조직은 다음 측면에서 경쟁사를 앞섭니다.

• 코드 배포 빈도 46배.
• 커밋부터 배포까지 걸리는 리드 타임 1/440.
• 가동 중단 후 평균 복구 시간 1/96.
• 변경 실패율 1/5. 즉, 변경이 실패할 가능성이 5분의 1입니다.
• 생산성과 처리량 향상.
• 코드 및 운영의 신뢰성 향상.
• 조직 성과와 고객 만족도 개선.
• 조직의 시장 침투율, 시장 점유율, 수익성 향상(달성 가능성 2배).
• 시가총액 성장 개선.

배포 빈도, 리드 타임, 복구 시간, 변경 실패율을 비교합니다.

원본 다이어그램 보기 ↗