데브옵스 성숙도의 3단계

오늘날의 소프트웨어 환경에서는 모든 조직이 모놀리스를 제거하고, 파이프라인을 자동화하며, 전체적인 작업을 감소함으로써 관행을 현대화해야 한다는 압박을 지속적으로 받고 있습니다. 현대화를 위해 대부분의 조직은 데브옵스 관행으로 전환하지만, 이러한 전환 여정을 자체적으로 완료할 수 있는 역량을 보유한 경우는 그리 흔치 않습니다.

데브옵스로 원활하게 전환을 해주는 단일한 방법은 존재하지 않습니다. 서로 고립된 상태로 운영되는 조직들을 정렬하려면 문화적, 절차적, 기술적 변화가 함께 이루어져야 합니다. 비즈니스 요구와 목표에 맞는 실용적인 접근 방식을 신중하게 사용하면, 궁극적으로 성공할 수 있습니다.

뉴렐릭도 데브옵스 여정을 거쳤습니다. 소규모 기업으로 시작해 모놀리식 Ruby 애플리케이션을 운영하고 있던 뉴렐릭은, 성장과 성공(더 많은 고객, 더 많은 데이터, 더 빠르게 기능을 제공해야 할 필요성)으로 인해, 애플리케이션 아키텍처와 소프트웨어 배포 방식을 재검토하게 되었습니다. 현재 뉴렐릭은 50여 개의 데브옵스 엔지니어링 팀들이 300개 이상의 컨테이너화된 마이크로서비스를 관리하며, 매일 20~70차례 변경 사항을 배포하고 있습니다. 

이러한 여정 동안, 데브옵스로의 성공적인 전환은 다음 세 단계로 구성된다는 사실을 알게 되었습니다.

• 준비 : 시스템에 대한 기본적인 가시성을 구축합니다.

• 활성화 : 사람과 문화에 영향을 미칩니다. 

• 최적화 : 시스템에 대한 정보를 사용해 리소스와 프로세스를 세부적으로 조율합니다.

이 eBook은 파일럿 프로젝트에 성공을 했거나 순조롭게 데브옵스로 전환하고 있든, 데브옵스로의 전환 여정에 오른 모든 기업을 위한 것입니다. 데브옵스의 성공을 향한 단계적 지침을 자세히 살펴보고, 데브옵스 여정에서 지금까지 조직이 어떤 성과를 달성했고, 현재 어느 단계에 있으며, 어떻게 앞으로 나아가야할지 확인해보시기 바랍니다.

데브옵스를 수용할 준비가 되었다면 어디서부터 시작하면 될까요? 이 단계에서는 애플리케이션에 대한 기본적인 가시성을 수립하고, 건전한 데브옵스 관행에 필요한 절차적 및 문화적 변화를 아래와 같이 준비하게 됩니다.

• 애플리케이션의 성능 목표와 기준을 정합니다.

• 정해진 기준에 기반해 선제적 알림을 설정합니다.

데브옵스 여정의 핵심 단계는 처리량 병목 현상, 트랜잭션 오류 및 유사한 문제를 진단 및 해결하는 데 도움이 되는 메트릭와 성능 통계를 수집하는 것입니다. 이는 매우 중요하며, 데브옵스 관행을 확립할 수 있는 보다 안정적인 환경을 구축하는 데 도움이 됩니다. (또한 더 나은 고객 경험으로 연결됩니다!)

무엇을 측정해야 할까요? Google의 eBook 사이트 안정성 엔지니어링: Google이 운영 시스템을 실행하는 방법에서, 저자는 다음의 4가지 황금 신호를 사용해 사용자 애플리케이션을 측정하고 개선할 것을 제안합니다.

1. 레이턴시: 애플리케이션의 응답성은 얼마나 되는가?
2. 트래픽: 얼마나 많은 요청 또는 세션이 애플리케이션으로 보내지는가?
3. 오류: 요청 또는 세션을 수행할 수 없는 트래픽은 얼마나 되는가?
4. 포화: 애플리케이션의 요구 사항을 충족하기 위해 리소스에 얼마나 많은 부담이 가해지는가?

4가지 황금 신호 같은 메트릭에 초점을 맞추면, 조직 전체에서 공유할 수 있는 측정 가능한 개선의 증거를 확보해 데브옵스 여정에서 추진력을 얻을 수 있습니다.

애플리케이션을 준비할 때, 명확하고 측정 가능한 목표도 함께 설정해야 합니다. 이를 통해 진정한 데브옵스 환경에서 팀 간에 교차 작업을 수행하는 데 필요한 기술과 동기를 구축할 수 있습니다.

서비스 수준 목표(SLO)는 성공적인 안정성이 어떤 것인지를 명확히 설명합니다. SLO는 또한 데브옵스 팀의 목표를 체계화하고, 팀이 더 빠른 속도로 작업할 수 있도록 돕는 강력한 메커니즘입니다.

SLO는 애플리케이션 내의 마이크로서비스 또는 애플리케이션의 성능을 측정하는 합의된 수단입니다. SLO는 서비스 수준 표시기(SLI)라고 하는 정해진 정량적 측정치에 대해 목표값을 정의합니다. 예를 들면:

• (SLI) = 평균 응답 시간(SLO) =  200ms 미만

• (SLI) = 요청(SLO)의 95% =  250ms 이내에 완료

• (SLI) = 서비스 가용성(SLO) = 99.99%

현대적이고 복잡한 시스템에 SLO 및 SLI를 효과적으로 설정하는 것은 다단계 프로세스로 다음 과정이 포함됩니다.

• 애플리케이션 내의 시스템 경계 식별

• 각 시스템의 기능 정의

• 성능 기준 측정

• SLI를 정의하고 각 기능에 대해 SLO를 적용한 다음, 시간이 지남에 따라 그 설정을 반복합니다.

훌륭한 데브옵스 팀은 SLI를 핵심 성과 지표 (KPI)로 사용해, 서비스가 고객의 기대치를 충족하는지 확인합니다. 또한, 서비스의 현재 상태나 애플리케이션의 안정성을 측정하면서 데브옵스의 진행 상황에 대한 명확한 가시성을 확보할 수 있습니다. 이를 통해 향후 최적화 노력을 평가할 때, 팀이 유의한 성능 차이를 해결하는 데만 집중할 수 있습니다.

선제적인 데브옵스 팀은 고객에게 영향을 미치기 전에 문제에 대응할 수 있도록 효과적인 ‘알림’ 전략을 수립합니다. 알림 설정의 좋은 시작점은 팀의 SLO입니다. 실제로 SLO를 논리적으로 그룹화하여, 서비스가 기대치를 충족하는지 여부에 대한 전반적인 부울 표시기를 제공할 수 있습니다. (예: "요청의 95%가 250ms 내에 완료되고 서비스 가용성은 99.99%") 그런 다음 그 지표를 기준으로 알림을 설정할 수 있습니다.

서비스나 애플리케이션의 정량적 성능 메트릭을 세분화함으로써, 데브옵스 팀은 각 메트릭에 가장 적합한 알림 유형을 파악할 수 있습니다. 예를 들어, 팀은 웹 트랜잭션 시간이 0.5 밀리 초를 초과하거나 오류율이 0.20%를 초과하는 경우 대응 담당자에게 공지가 가도록 알림을 설정할 수 있습니다.

간단한 알림 프레임워크의 경우, 다음 표를 고려하십시오.

[질문] 

• 비즈니스가 운영되고 있는가?
• 기저 인프라는 어떤 상태인가?
• 애플리케이션의 상태는 어떤가?
• 애플리케이션의 전반적인 품질은 어떤가?
• 고객 상태는 어떤가?
• 비즈니스 상태는 전반적으로 어떤가?

• 애플리케이션 성능 모니터링 툴이 사이트 가용성에 대한 알림을 제공하도록 설정합니다.
• 주요 하드웨어, 네트워크 및 스토리지 구성 요소에 대한 KPI를 설정합니다.
• JVM 성능, 대기열, 캐싱 및 유사한 종속성에 대한 메트릭을 추적합니다.
• Apdex 점수를 사용해 애플리케이션의 품질을 빠르게 평가합니다.
• 실제 엔드유저 메트릭, 합성 사용자 및 Apdex 점수를 고려합니다.
• 애플리케이션 내의 주요 트랜잭션에 초점을 맞추고, 예상되는 비즈니스 결과와 연계시켜 애플리케이션 및 비즈니스 성과 간의 상관 관계를 수립합니다.

데브옵스 팀이 성숙해지면서 배포 속도와 속도는 꾸준히 증가합니다. 결과적으로, 프로세스에 대한 팀의 가시성을 향상시키는 것이 더 중요해집니다.  

이 단계에서 팀은 :

• 작업에 대한 인사이트를 공유하는 대시보드를 생성합니다.

• 변경 사항이 애플리케이션과 인프라의 상태와 성능에 미치는 영향을 추적합니다.

• 인시던트 대응 프로세스를 구축하고 인시던트로부터 교훈을 얻습니다.

• 코드를 빠르고 안정적으로 전달하기 위한 측정치를 설정합니다.

중요한 데브옵스 원칙은 어떤 작업이 언제, 어디서, 일어나고 있는지에 대한 이해를 공유하며 팀들 간에 협업을 하는 것입니다. 대시보드는 팀이 비즈니스 목표에 정렬되도록 지원하고, 애플리케이션의 성능이 전체 비즈니스에 미치는 영향에 대한 인사이트를 팀에 제공함으로써, 효과적인 협업을 가능하게 해줍니다.

문제가 발생하면, 데브옵스 팀은 대시보드를 사용해 관리 가능한 엔드포인트와 서비스 계층에 문제 해결 노력을 집중하여, 감지 또는 해결 시간을 단축할 수 있습니다. 또한, 팀 대시보드는 데브옵스 팀에게 애플리케이션의 SLI 및 KPI를 시각화한 단일한 뷰를 제공합니다.

이러한 방식으로 협업을 촉진하면 마찰 위험도 완화됩니다. 예를 들어, 팀은 오전 미팅 중에 대시보드를 사용해 하루 일정을 공지할 수 있습니다. 또한, 비즈니스 성과 대시보드를 단일 정보 소스로 사용해, 전체 비즈니스를 포괄적으로 관찰할 수 있습니다.

대시보드는 릴리스 및 유지 관리 프로세스가 더욱 예측 가능해지도록 만들어 주며, 데브옵스 팀이 더 빠르게, 더 자주 배포할 수 있다는 확신을 가지게 합니다. 일례로, 대시보드는 구성 요소의 상태 업데이트에 대한 정보를 공유할 수 있는 단일 소스를 제공합니다.

데브옵스는 팀들이 더 빈번하게, 하지만 덜 위험하게 코드와 인프라를 변경할 수 있게 되는 문화적 변화입니다. 애플리케이션을 올바르게 계측하면, 개발 프로세스 측정(팀 대시보드를 통해)을 배포 마커와 인프라 모니터링과 통합하여, 변경 사항의 영향을 즉시 표시하고 서비스 저하 문제를 해결하는 데 필요한 노력을 최소화할 수 있습니다. 각 변경 전후에 가시적이고 측정 가능한 메트릭을 캡처하면, 고립된 변경 사항을 최적화하고 변경 사항이 다른 진행 중인 작업에 영향을 미칠 위험을 줄이며, 제품의 기능 주기를 단축하는 동시에 인프라의 민첩성을 높일 수 있습니다.

이러한 목표를 지원하는 몇 가지 메트릭은 다음과 같습니다.

• 평균 해결 시간(MTTR): 조직이 평균적으로 문제에서 얼마나 빨리 복구하는지를 알려줍니다. 너무 많은 인시던트가 너무 오래 지속되면 비즈니스가 위협을 받을 수 있기 때문에, 인시던트를 더 빨리 해결해야 한다는 부담이 항상 존재합니다. 높은 MTTR 수치를 안정성 문제를 검토할 필요가 있다는 트리거로 사용하되, ‘평균 시간’을 측정하는 데 너무 큰 중요성을 부여하면 도움이 되지 않는 행동에 동기가 부여되어, 성공을 저해할 수 있습니다.

효과적인 인시던트 해결을 위한 모범 사례를 통해, 올바른 방법으로 MTTR을 줄이는 방법을 보다 자세히 알아보십시오.

• 배포 상태: 배포 상태를 보여줍니다. 일반적인 데브옵스 성능 지표는 정해진 시간 내 배포 수입니다. 여기에는 배포가 많을수록 변경 사항이 적고 위험이 감소하며 실험할 기회는 많아진다는 사실이 반영됩니다. 그러나 배포 상태 역시 중요합니다. 대부분의 배포가 실패한다면, 배포를 더 많이 한다고 해서 더 나아지지는 않을 것이기 때문입니다.

• 단위 테스트: 코드베이스의 상태를 알려주고, 개발 팀이 빠르게 성공을 거둘 수 있도록 합니다.

데브옵스 조직은 모든 엔지니어링 팀 및 부서들이 공유할 수 있는 잘 정의된 인시던트 대응 프로세스가 필요합니다. 데브옵스 팀이 인시던트에 보다 효율적으로 대응하고, 인시던트가 전체 비즈니스에 미치는 영향을 최소화할 수 있도록 예측 가능한 프레임 워크와 프로세스가 필요합니다.

데브옵스 모델을 도입하는 것 외에, 인시던트 대응의 몇 가지 모범 사례는 다음과 같습니다.

• 자율성과 책임의 균형: 성공적인 대응 프로세스는 팀의 구성, 관리하는 서비스 및 서비스에 대한 팀의 집단 지식에 따라 달라집니다. 여기가 바로 팀의 자율성이 필요한 부분입니다. 예를 들어, 각 팀이 자체적인 요구 사항과 기능을 반영해 자체적인 대응 시스템을 만들 수 있습니다.

• 대응 실적 추적 및 측정: 각 엔지니어, 팀 및 그룹 수준에서 대응 팀의 메트릭을 추적하면 유용합니다. 예: 엔지니어 당 총 호출 수, 엔지니어가 호출된 시간, 업무 시간(정상 업무 시간 외) 외 호출 수

• 인시던트의 심각도를 평가하기 위한 시스템 개발: 효과적인 인시던트 대응은 보통 고객 영향의 측면에서 측정되는 심각도에 따라 인시던트의 순위를 매기는 체계에서 시작됩니다. 각 인시던트 수준에서 대응을 관리하고 내부 및 외부 고객과 소통할 수 있도록 정해진 규칙이 있어야 합니다.

• 대응 팀의 역할 정의 및 할당: 효과적인 인시던트 대응 팀에는 인시던트 지휘관, 기술 책임자, 커뮤니케이션 책임자 등이 포함되어야 하며, 각각의 권한과 의무가 명확하게 정의되어 있어야 합니다.

인시던트 대응 프로세스와 프레임워크는 명확하고 일관적이며 반복 가능해야 합니다. 성공적인 인시던트 대응 프로세스는 인시던트로 인해 고객 경험이 저하 될 위험을 줄여주는 것은 물론, 알림 피로를 감소시키고 데브옵스 팀의 사기를 진작시키는데도 도움이 됩니다.

자세히 보기: 대기 및 인시던트 대응: 성공을 위한 교훈, 뉴렐릭의 방식

모든 인시던트는 동일한 문제를 회피할 수 있도록 팀에게 학습, 개선 및 성장할 수 있는 기회를 제공합니다.

예를 들어, 인시던트는 종종 시스템의 중요한 취약성을 식별하여, 안정성을 향상하기 위한 노력의 출발점이 됩니다. 인시던트로부터 교훈을 얻을 수 있는 프로세스를 만들어 팀이 기존 KPI 및 인시던트 대응 패턴을 개선하고 새로운 문제에 쉽게 대처할 수 있도록 해야 합니다. 목표는 먼저 학습을 한 다음, 문제를 해결하는 것입니다.

인시던트를 해결한 후, 주요 이해 관계자와 관련자들은 인시던트를 정확하고 철저하게 문서화해야 합니다. 이를 위한, 바람직한 방법은 처벌이나 비난이 아니라 건설적인 학습과 개선에 중점을 두는 '책임을 묻지 않는 회고' 세션을 여는 것입니다.

회고하는 동안, 다음을 포함해 논의 내용을 완전하게 문서화합니다.

• 인시던트에 기여한 모든 요인 분석

• 성공 여부에 관계 없이 문제 해결 단계와 결과 기록 및 요약

• 가능한 경우, 사용자 경험과 경제적 손실의 측면에서 비즈니스에 미친 영향 측정

• 재발 방지를 위한 시스템 또는 기능 개선에 대한 권장 사항 도출

• 절차 및 커뮤니케이션 개선을 위한 권장 사항 도출

사후 보고서는 공유 드라이브 폴더나 wiki처럼 쉽게 볼 수 있고 검색 가능한 저장소에 저장해야 합니다.

데브옵스의 또 다른 핵심 원칙은 품질에 영향을 미치거나 개발 주기에 위험을 추가하지 않고, 빌드 및 테스트 프로세스를 통해, 하루에 수십 개의 코드 커밋을 소스 코드 저장소에서 운영 환경 배포로 이동할 수 있는 프로세스를 구축하는 것입니다.

높은 성과를 내는 데브옵스 팀은 이 방식으로 계측을 사용해, 변경 사항을 더 자주, 적은 위험으로 운영 환경에 적용합니다. 

다음은 팀의 코드 파이프라인을 측정하기 위한 네 가지 모범 사례입니다.

• 소스 코드 관리로 시작합니다. 파이프라인에서 타임 스탬프가 찍힌 상태 변경을 캡처하는 것은 파이프라인의 성능을 분석하는 데, 특히 소스 코드의 오류 문제를 해결하는 데 중요합니다.

• 기록된 상태 변화는 프로세스 개선에 유용한 지표입니다. 변경 사항을 푸시할 때, 상태를 캡처해야 합니다. 성공했는가? 실패했다면 왜 실패했는가? 이러한 데이터는 종종 데브옵스 팀이 내부 목표를 추적하고 프로세스를 평가할 수 있는 메트릭을 제공합니다. 이를 통해, 배포 빈도나 빌드 품질을 높일 수 있습니다.

• 단위 테스트의 결과를 보고한 다음에는 보다 세부적으로 살펴봅니다. 단위 테스트 결과는 분명히 뉴렐릭의 훌륭한 타깃 출력 소스입니다. 합격/불합격 결과는 파이프라인의 실시간 성능을 평가할 수 있는 기회를 제공하며, 장기적으로는 개발 팀의 성장 및 진행 상황을 평가하고 개선하는 데 유용한 도구가 됩니다.

• 실패한 배포가 아니라 성공한 배포로부터 학습을 합니다. 애플리케이션 성능 데이터와 함께 배포 마커를 사용하면, 배포 마커를 사용해 어떤 변경 사항이 성능 저하를 유발했는지 추적할 수 있으며, 팀은 이러한 상관 관계가 발생할 때 실시간 공지가 전송되도록 알림을 설정할 수도 있습니다.

코드 파이프라인을 계측 할 때, 데브옵스 팀은 잦은 배포 실패 또는 테스트 범위에 간극이 있는 서비스를 식별해 안정화 작업의 우선순위를 정하여, 품질을 희생하지 않고 속도를 향상할 수 있습니다.

이 시점에서, 데브옵스 전환의 처음 두 단계가 완료되어 팀은 성공을 경험하기 시작했습니다. 이제 나머지 엔지니어링 조직의 수준을 높여, 데브옵스 운영 모델이 제공하는 전체 비즈니스 가치를 입증하고 제공할 때입니다.

이 마지막 단계에서는 다음과 같이 데브옵스 팀을 최적화하는 데 집중합니다.

• 애플리케이션 내에서 종속성 위험을 해결합니다.

• 고객 경험을 측정하고 반복합니다.

• 인프라 리소스 할당을 개선합니다.

• 계측을 자동화합니다.

• 교차 기능 운영을 검토하여, 성공을 추적하고 개선 영역을 파악합니다.

엔지니어링 조직 전체에서 데브옵스 관행을 성공적으로 확장하려면, 애플리케이션 팀 및 관련 서비스 간의 종속성을 철저하게 이해할 필요가 있습니다. 예를 들어, 마이크로서비스 아키텍처에는 서로 요청을 보내는 서비스가 수백 개까지는 아니더라도 수십 개가 포함될 가능성이 있습니다. 데브옵스 팀은 이러한 복잡한 환경에서 위험한 업/다운스트림의 종속성을 완화하는 방법을 알아야 합니다.

중요한 종속성에 대한 가시성을 구축하면, 팀 간의 협업이 향상되어 운영이 중단되는 상황이 줄어들고, 보다 일관된 성능을 지원할 수 있습니다.

프런트엔드 및 백엔드 서비스 모두에서 작업을 하려면, 먼저 종속성 위험을 줄이고 SLO를 달성하기 위한 실행 계획을 세워야 합니다. 이를 위해서는 다음 네 가지 원칙을 염두에 두어야 합니다.

• 위험 허용 범위를 이해해야 합니다. 위험에 대한 내성을 명확하게 파악하는 것이 도움이 되며, 이상적으로는 SLO로 내성 수준을 알 수 있습니다. 알림 정책을 사용해 SLO 달성과 높은 관계가 있다고 판단되는 종속성을 모니터링합니다.

• 종속성을 최소화해야 합니다. 불필요한 복잡성을 제거하는 것은 고객의 기대를 충족하고 유지관리가 가능한 시스템을 확보하는 중요한 방법입니다.

• 종속성의 범위를 제한합니다. 팀이 코드를 작성할 때, 가능하면 서로 의존하는 함수를 함께 패키징하도록 권장해야 합니다.

• 종속성을 안정화합니다. 종속성을 피할 수 없는 경우, 종속성이 변경될 가능성이 가장 낮거나 대체하기 쉬운 모듈을 가리키도록 하여 위험을 완화합니다.

실행 계획을 완료한 후에는 결과를 모니터링해야 합니다. SLO는 종속성 위험을 해결하려는 노력이 성과가 있었는지 여부를 알려야 합니다.

효율적이고 생산적인 데브옵스 문화는 조직이 제품을 빨리, 더 자주 출시하고 변경할 수 있도록 지원합니다. 또한 이러한 환경은 팀이 고객 서비스, 지원, 영업 및 마케팅 팀 등 다른 이해 관계자와 고객 경험에 대한 데이터를 공유할 수 있게 합니다. 

대시보드 같은 단일 참조 지점은 성과 데이터와 비즈니스 수준 정보를 함께 가져다가 팀 간에 쉽게 공유할 수 있도록 합니다. 대시보드를 공유하는 방법이나 공유 대상을 고려할 때, 다음 질문을 고려해야 합니다.

엔드유저의 상호 작용 수준이 높은 애플리케이션을 누가 담당하는가?

이 정보를 통해, 어떤 비 엔지니어링 팀이 혜택을 받을 수 있을까? a. 고객 지원: 고객 이슈를 더 빨리 해결할 수 있는가? b. 제품/엔지니어링: 제품이 정보에 입각해 로드맵 결정을 내릴 수 있는가? c. 고객 성공: 이 데이터를 사용해 고객이 성공할 수 있도록 지원할 수 있는가? d. 성능 메트릭이 포함된 엔드유저 분석을 통해, 어떤 다른 팀이 혜택을 볼 수 있는가?

성공적인 고객 경험을 창출하는 요소를 명확하게 이해하면, 업무의 효율성을 높혀 생산성을 높이는 데도 도움이 됩니다.

애플리케이션 성능을 저하시키지 않고 더 효율적으로 운영할 수 있도록 인프라 리소스를 최적화해야 비로소 데브옵스로의 전환이 완료되었다고 할 수 있습니다. 클라우드에 있든, 온프레미스에 있든, 모든 곳의 리소스를 더 잘 활용하는 것이 중요합니다. 확장 역량이 필요하긴 하지만, 필요하지 않은 리소스에 비용을 지불해선 안됩니다. 

이는 종종 리소스를 축소하느냐 아니면 통합하느냐 사이의 결정으로 귀결됩니다. 대부분의 경우, 일반적으로 호스트 수를 줄이고, 작은 호스트에서 적은 수의 애플리케이션을 실행하는 것보다, 더 큰 호스트에 애플리케이션들을 통합하는 것이 더 비용 효율적입니다.

컨테이너화는 또한 대부분의 데브옵스 팀의 최적화 노력에서 매우 두드러지게 나타납니다. 쿠버네티스와 Amazon Elastic Container Service(ECS)같은 컨테이너 오케스트레이션 플랫폼은 컴퓨팅 리소스를 관리하기 위한 효율적인 수단을 제공하며, 호스트 클러스터 내에서 가용 용량에 기반해 컨테이너 인스턴스의 배포를 처리합니다.

이러한 인프라 변경 외에도, 데브옵스 팀은 사전 알림 및 팀 대시보드를 사용해, 인프라 리소스를 효율적으로 활용하고 고객 경험에 미치는 영향을 신속하게 감지할 수 있습니다.

데브옵스에서 빠르게 이동한다는 것은 수고를 줄인다는 것을 의미합니다. 가시성은 데브옵스 팀에게 기본적인 기능이며, 부담이 되어서는 안됩니다. 팀의 애플리케이션이 확장되면, 코드 배포부터 빌드 및 배포, 알림까지 전체 소프트웨어의 수명주기를 효과적으로 모니터링하는 것이 점점 더 중요해지고 복잡해집니다.

데브옵스 팀은 가능한 모든 경우에서 CLI로 작업을 자동화하고, 개발 에코시스템이 성장함에 따라 수동 계측을 자동화된 설정으로 대체하여 작업 부담을 덜어야 합니다.

데브옵스의 궁극적인 목표는 팀들이 고객의 기대에 부합하는 안정적인 서비스를 적시에 제공하는 것입니다. 데브옵스 팀이 이 목표를 지속적으로 달성할 수 있도록, 교차 기능 팀을 구성해 정기적으로 운영을 검토해야 합니다. 최고의 교차 기능 팀은 다양한 팀을 대표하는 다음과 같은 팀원으로 구성되어야 합니다.

• 제품 소유자, 엔지니어링 관리자 및 기술 책임자

• 애플리케이션을 개발하고, 서비스 제공을 담당하며, 에코시스템을 유지관리하는 데브옵스 팀의 개별 기여자

• 비즈니스 운영, 마케팅 및 지원 담당자

교차 기능 팀과 함께해, 서비스 제공 프로세스가 고객의 기대치와 매치되도록 만듭니다. 매주 또는 격주로 검토를 하고, 기술적 개선 사항이 어떻게, 또 어디에서 고객의 기대를 충족시키는지 파악하고, 이를 보장해줄 새로운 방법을 찾습니다. (이상적으로는 데브옵스 팀이 설정한 SLO 대비 서비스 기록을 추적해야 합니다.) 대시보드는 기간이나 메트릭을 조율할 수 있는 좋은 장소이며, 서비스 제공 목표를 충족하는지 또는 개선을 위해 특정 조치를 취해야 하는지에 대한 정량화된 이해를 얻을 수 있는 곳입니다.

이 ebook에 설명된 것처럼, 현대적인 소프트웨어 관행은 팀이 더 빠르게 기능을 배포하고, 인시던트를 감소하며, 더 많이 실험할 수 있도록 합니다. 데브옵스 운영 모델로 도약한 미래 지향적인 조직은 이미 이러한 혜택을 활용하여 경쟁에서 앞서가고 있습니다. 이러한 조직은 사일로를 제거하고, tool과 프로세스를 간소화했으며, 커뮤니케이션 채널을 개선하고, 데브옵스 도입의 장벽을 허물었습니다.

귀사는 데브옵스 관행을 최대로 활용할 준비가 되어 있습니까? 뉴렐릭이 시작하는 방법과 성공할 수 있는 방법을 알려드립니다.

뉴렐릭의 솔루션 엔지니어 및 데브옵스 전문가가 작성한 데브옵스 성공 측정 가이드는 각 단계(준비, 활성화 및 최적화)를 안내해주고, 뉴렐릭을 사용해 모든 단계를 추적하고 신중하게 의사결정을 하며 데브옵스의 성공률을 높이는 방법을 자세히 설명합니다.

• 가치 실현 가속화  >>  준비 >> 측정 및 기준 설정
• 성공 기반 >> 활성화 >> 모든 변경 사항의 영향 이해 및 신속한 피드백 확보
• 장기적인 혜택 확보 >> 최적화 >> 지속적인 자동화, 커뮤니케이션 및 개선

뉴렐릭의 솔루션은 각 조직의 성숙도와 고유한 요구 사항에 따라 유연하게 맞춤화가 가능합니다. 성장의 모든 단계에서 데이터를 수집하면, 데브옵스 노력이 모든 단계에서 전체 비즈니스에 어떤 영향을 미치는지 더 잘 이해할 수 있는 귀중한 기준을 확보할 수 있습니다.