2020.03.09

애자일팀이 사고 관리를 지원하는 방법

Isaac Sacolick | InfoWorld
애플리케이션 신뢰성 또는 성능에 문제를 일으키는 중대 사고 때문에 한밤중이나 주말에 출근하고 싶은 사람은 아무도 없다. 실제로 애플리케이션이 다운되어 비즈니스 운영에 영향을 미치고, 그 때문에 경영진의 압박을 받고 싶은 사람도 없을 것이다. 애자일 개발자는 스프린트 약속에 집중하고 중대 사고의 근본 원인 조사에 가능한 적은 시간을 투자해야 한다. 하지만 중대 사고에 대응하고 문제 해결을 지원하고 근본 원인 분석에 참여하는 것은 모두가 할 일이다.
 
ⓒ GettyImagesBank

가장 좋은 환경이라면, 운영팀에 문제를 감지, 경고, 해결하는 모니터링 시스템이 있다. 운영 환경은 보안 침입, 주요 클라우드 서비스 중단, 서드파티 서비스 문제, 운영을 저해하는 주요 인프라 고장 등 누구도 통제할 수 없는 문제가 발생할 수 있는 것이 현실이다. 아무리 탄탄한 애자일 프로세스, 소프트웨어 개발 라이프사이클, 데브옵스 베스트 프랙티스라도 애플리케이션에 위험이 없고 100% 신뢰할 수 있다고 보장할 수는 없다.  

운영 및 사이트 신뢰성 엔지니어는 개발팀에 영향을 미치지 않고 보편적인 문제를 해결할 수 있다. 일반적인 문제는 자동화나 해결 방법을 설명한 실행서를 통해 해결할 수 있다. 하지만 개발자는 더욱 복잡하거나 잘 생기지 않는 사고를 해결하는 데 도움을 줘야 할 가능성이 크며, 처음부터 운영 문제가 발생하지 않도록 방지하는 데 도움이 되는 많은 방법이 있다.

사고 관리는 중요한 비즈니스 프로세스이다.
오늘날 많은 기업이 고객 응대용 제품이나 비즈니스 서비스를 지원하는 고객 경험, 또는 직원이 업무를 수행할 수 있도록 하는 워크플로우의 일환으로 소프트웨어 애플리케이션을 개발한다. 이런 애플리케이션 고장 나거나 성과를 내지 못할 때 매출 손실, 예산에 편성되지 않은 비용, 브랜드 평판에 대한 악영향, 프로젝트 지연, 직원 사기 저하 등 비즈니스에 큰 악영향을 미칠 수 있다.

애플리케이션이 자주 또는 오랫동안 중단되거나 부실한 성능, 예상치 못한 오류가 발생하는 경우, 애플리케이션 소프트웨어 개발팀에도 불리하게 작용한다. 직원을 대상으로 설문조사를 진행하고 고객 만족도를 측정하는 IT 부서는 신뢰할 수 없는 애플리케이션이 업무에 영향을 미치는 경우 높은 점수를 받기 어렵다. 또한 소프트웨어 개발팀이 새로운 기능을 신뢰성 있게 배포할 수 없다는 평가를 받는다면, IT 관리를 위한 예산 증액, 교육, 추가적인 보상 등의 혜택을 누릴 수도 없다.

따라서 개발팀은 선제 조치를 통해 문제를 방지하고 사고 중 지원을 제공하며, 근본 원인 분석에 참여하고 중대 결함 해결에 우선순위로 부여해야 한다.

이런 책임을 좀 더 자세히 살펴보자.
 

애플리케이션을 개발 및 배포할 때 품질을 우선시하라

애자일 개발팀은 새로운 기능 개발 및 배포, 사용자 경험 개선, 기술적 부채 해결에 집중하는 경우가 많다. 지속적 통합/지속적 제공(CI/CD) 파이프라인 등의 데브옵스 활동을 도입하는 팀은 테스트 프랙티스를 최대한 일찍 수행하고(Shift Left Testing), 대부분 테스트를 자동화해 새로운 코드가 소프트웨어 빌드를 망가뜨리지 않고 자동화된 테스트를 모두 통과하도록 해야 한다.

개발자와 QA 테스트 담당자는 보안 테스트 역시 최대한 초기에 진행하고 코딩 활동을 실시하여 애플리케이션 신뢰성을 확보해야 한다. 개발팀은 또한 운영팀과 인프라 구성, 자동화, 모니터링을 위해 협력해야 한다. 베스트 프랙티스를 살펴보자.
 
  • 애플리케이션 로깅과 예외 처리를 표준화하고 중앙집중화하여 애플리케이션 문제를 추적할 수 있도록 한다.
  • 특히, 무거운 부하에서 병목을 유발할 수 있는 애플리케이션 및 데이터베이스 잠금을 최소화한다.
  • 애플리케이션, 서비스, 데이터베이스의 신뢰성이 높도록 구성하고 여러 클라우드 영역에서 로드밸런싱을 추구한다.
  • 모니터링 및 경보를 중앙에 집중하고 선제적으로 종적 성능 격차를 찾는다.
  • 수요에 따라 서비스를 재시작, 확장, 종료하는 절차를 자동화한다.


2020.03.09

애자일팀이 사고 관리를 지원하는 방법

Isaac Sacolick | InfoWorld
애플리케이션 신뢰성 또는 성능에 문제를 일으키는 중대 사고 때문에 한밤중이나 주말에 출근하고 싶은 사람은 아무도 없다. 실제로 애플리케이션이 다운되어 비즈니스 운영에 영향을 미치고, 그 때문에 경영진의 압박을 받고 싶은 사람도 없을 것이다. 애자일 개발자는 스프린트 약속에 집중하고 중대 사고의 근본 원인 조사에 가능한 적은 시간을 투자해야 한다. 하지만 중대 사고에 대응하고 문제 해결을 지원하고 근본 원인 분석에 참여하는 것은 모두가 할 일이다.
 
ⓒ GettyImagesBank

가장 좋은 환경이라면, 운영팀에 문제를 감지, 경고, 해결하는 모니터링 시스템이 있다. 운영 환경은 보안 침입, 주요 클라우드 서비스 중단, 서드파티 서비스 문제, 운영을 저해하는 주요 인프라 고장 등 누구도 통제할 수 없는 문제가 발생할 수 있는 것이 현실이다. 아무리 탄탄한 애자일 프로세스, 소프트웨어 개발 라이프사이클, 데브옵스 베스트 프랙티스라도 애플리케이션에 위험이 없고 100% 신뢰할 수 있다고 보장할 수는 없다.  

운영 및 사이트 신뢰성 엔지니어는 개발팀에 영향을 미치지 않고 보편적인 문제를 해결할 수 있다. 일반적인 문제는 자동화나 해결 방법을 설명한 실행서를 통해 해결할 수 있다. 하지만 개발자는 더욱 복잡하거나 잘 생기지 않는 사고를 해결하는 데 도움을 줘야 할 가능성이 크며, 처음부터 운영 문제가 발생하지 않도록 방지하는 데 도움이 되는 많은 방법이 있다.

사고 관리는 중요한 비즈니스 프로세스이다.
오늘날 많은 기업이 고객 응대용 제품이나 비즈니스 서비스를 지원하는 고객 경험, 또는 직원이 업무를 수행할 수 있도록 하는 워크플로우의 일환으로 소프트웨어 애플리케이션을 개발한다. 이런 애플리케이션 고장 나거나 성과를 내지 못할 때 매출 손실, 예산에 편성되지 않은 비용, 브랜드 평판에 대한 악영향, 프로젝트 지연, 직원 사기 저하 등 비즈니스에 큰 악영향을 미칠 수 있다.

애플리케이션이 자주 또는 오랫동안 중단되거나 부실한 성능, 예상치 못한 오류가 발생하는 경우, 애플리케이션 소프트웨어 개발팀에도 불리하게 작용한다. 직원을 대상으로 설문조사를 진행하고 고객 만족도를 측정하는 IT 부서는 신뢰할 수 없는 애플리케이션이 업무에 영향을 미치는 경우 높은 점수를 받기 어렵다. 또한 소프트웨어 개발팀이 새로운 기능을 신뢰성 있게 배포할 수 없다는 평가를 받는다면, IT 관리를 위한 예산 증액, 교육, 추가적인 보상 등의 혜택을 누릴 수도 없다.

따라서 개발팀은 선제 조치를 통해 문제를 방지하고 사고 중 지원을 제공하며, 근본 원인 분석에 참여하고 중대 결함 해결에 우선순위로 부여해야 한다.

이런 책임을 좀 더 자세히 살펴보자.
 

애플리케이션을 개발 및 배포할 때 품질을 우선시하라

애자일 개발팀은 새로운 기능 개발 및 배포, 사용자 경험 개선, 기술적 부채 해결에 집중하는 경우가 많다. 지속적 통합/지속적 제공(CI/CD) 파이프라인 등의 데브옵스 활동을 도입하는 팀은 테스트 프랙티스를 최대한 일찍 수행하고(Shift Left Testing), 대부분 테스트를 자동화해 새로운 코드가 소프트웨어 빌드를 망가뜨리지 않고 자동화된 테스트를 모두 통과하도록 해야 한다.

개발자와 QA 테스트 담당자는 보안 테스트 역시 최대한 초기에 진행하고 코딩 활동을 실시하여 애플리케이션 신뢰성을 확보해야 한다. 개발팀은 또한 운영팀과 인프라 구성, 자동화, 모니터링을 위해 협력해야 한다. 베스트 프랙티스를 살펴보자.
 
  • 애플리케이션 로깅과 예외 처리를 표준화하고 중앙집중화하여 애플리케이션 문제를 추적할 수 있도록 한다.
  • 특히, 무거운 부하에서 병목을 유발할 수 있는 애플리케이션 및 데이터베이스 잠금을 최소화한다.
  • 애플리케이션, 서비스, 데이터베이스의 신뢰성이 높도록 구성하고 여러 클라우드 영역에서 로드밸런싱을 추구한다.
  • 모니터링 및 경보를 중앙에 집중하고 선제적으로 종적 성능 격차를 찾는다.
  • 수요에 따라 서비스를 재시작, 확장, 종료하는 절차를 자동화한다.


X