배포 대시보드 만들어보기 - 대시보드와 통계 기능의 필요성

대시보드에서 필요한 기능

• Real-time status updates: ( 실시간 배포 현황 )

The dashboard should provide real-time updates on the status of the deployment process, including the current stage, time remaining, and any issues that arise.

 

 

• Interactive deployment timeline: ( 상호작용 가능한 배포 타임라인 ) 

A visual representation of the deployment timeline that allows developers and operators to track the progress of the deployment and see any bottlenecks.

 

• Version control integration: ( 버전 관리 도구와의 통합 ) 

Integration with version control systems like Git can allow developers to easily deploy specific versions of their code and ensure consistency across environments.

 

• Deployment history: ( 배포 히스토리 ) 

A history of all past deployments, including the version deployed, the deployment time, and any issues encountered, can help operators identify patterns and make improvements to the deployment process.

 

• Notification system: ( 알림 기능 ) 

A notification system that alerts stakeholders to the status of the deployment can help ensure that everyone is informed and can take appropriate action if needed.

 

여기까지는 보통 대시보드를 만들면 기본적으로 들어가는 내용이다. 이제부터는 다른 부분에 대해 이야기 해보려고 한다.

 

운영자에게 필요한 기능

 

• 배포 담당자 별 배포 건 수

 

개인이 혼자 서비스를 하는 것이 아닌 이상, 실적은 중요하다. 크게 보면 서비스/조직 별로도 필요한데, 배포 운영자의 입장에 서보니 운영자에게는 조금 다른 방식의 통계가 필요하다는 걸 알게됐다. 특정 서비스를 개발하거나, 고객을 상대로 서비스(운영)를 하지 않는 배포 운영자는 과연 어떻게 평가해야 할까 ? 어떻게 평가하면 그나마 객관적인 평가가 되는걸까 ? 

 

사람마다 배포 건수를 균등하게 나눠주는 시스템이 없는 이상, 배포 건수가 객관적인 평가의 기준(중 하나)이 될 수 밖에 없다. 단순 반복작업을 정말 즐기고, 하루에 똑같은 말을 하는 작업을 좋아하는 사람들로만 이루어져 있는 팀이라면 이럴 필요가 없을 수도 있다. 하지만 커뮤니케이션을 하다보면 감정적으로 지치기도 하고, 반복 작업을 하면 지치는 평범한 사람들로 이루어져 있는 팀이라면 이런식으로라도 보상을 줘야 한다. 

 

예를 들어 전 회사에서는 운영은 우리의 평가 기준이 아니었고, 얼마나 기능을 개선하고 새로 만드느냐가 평가 기준이었다. 그러다보니 문의 사항이라던가, 이슈 등 운영 업무의 우선순위는 뒤로 밀리고, 대부분이 기피하는 그런 업무가 됐다. 하지만 현 회사에서는 운영(대응 건 수)도 평가 기준에 들어간다. 운영 업무의 우선순위가 매우 높고, 경쟁률도 치열하다.(개인적으로는 마음에 들지 않지만, 회사의 입장에서 보면 아주 좋은 평가 방식이라고 생각한다.)

 

*사람마다 배포 건수를 균등하게 나눠주는 시스템에 대해서는 여기서 언급하지 않겠다. 이건 대시보드에서 할 이야기가 아닌 거 같고, 자동화 시스템에 대한 글을 쓸 때 내 생각을 풀어보겠다. 

 

• 배포 요청 시각과 배포 시작 시간의 차이

이건 전 회사에서도 있었던 문제고, 현 회사에서도 있는 문제다. 예를 들어 1월 1일 00시에 배포를 하자고 해놓고, 거기에 맞춰서 운영팀이 스케줄 조정을 다 해놓으면 1월 1일 2시에 배포 요청을 한다던가 당겨서 요청을 한다던가 한다. 전 회사에서는 별 문제를 못느꼈다. 만들다보면 미뤄질 수도 있지라는 생각이었다. 나는 개발팀의 입장이었기 때문이다. 운영팀의 입장이 되어보니 이건 꽤나 문제가 되는 부분이었다. 

대기 하는 시간에 맞춰 시간외근무를 보통 올려놓기 때문에, 그 시간에 주구장창 대기만 하게 되면 회사 입장에서 리소스 낭비(시간외 근무 수당)이다. 그리고 운영자 그 개인적으로는 정신적인 피로감도 쌓인다. 보통 어딜 가나 비즈니스에 직접적으로 기여하는 쪽이 힘이 강해서, 문제 제기만 하고 넘어간다거나 문제 제기도 못하고 참는 경우가 많은 것 같다. 

그러면 운영 팀에서 정말 할 수 있는게 없을까? 언제나 할 수 있는 건 있다. 증적을 만드는 거다. 배포 요청 시각과 배포 시작 시간의 차이를 통계로 꾸준히 남겨두고, 특정 서비스는 유난히 일정을 못맞춘다던지, 매번 미뤄지는데다가 장애까지 발생해서 롤백까지 한다던지를 한 눈에 볼 수 있게 하면 그건 중요한 데이터가 될 수 있다. 왜냐면 이건 운영팀의 피로도 문제(우선순위 하)가 아니고, 개발 팀이 일정 산정을 잘못하고, 테스트도 제대로 되지 않아 서비스의 장애률을 높이는 문제(우선순위 상)가 되기 때문이다. 

 

제공하면 좋은 통계 수치들 

 

• Deployment success rate: ( 배포 성공률 ) 

The percentage of deployments that are successful, which can help identify areas for improvement in the deployment process.

 

• Deployment frequency: ( 배포 빈도 )

The rate at which deployments are made, which can help ensure that the deployment process is efficient and not overly burdensome.

 

• Time to deployment: ( 배포 소요 시간 ) 

The time it takes to deploy new code, which can help identify bottlenecks and opportunities for automation.

 

• Error rate: ( 에러 발생 비율 ) 

The percentage of deployments that encounter errors, which can help identify areas for improvement in the testing and deployment process.

 

• Rollback rate: ( 롤백 발생 비율 ) 

The percentage of deployments that require a rollback, which can help identify issues that may have been missed in testing or deployment planning.

 

• Resource utilization: ( 리소스 사용량 ) 

Monitoring resource utilization during deployment can help ensure that the system is not overloaded and can handle the increased load during deployment.