CheckOps의 실제 활용 모습
Teams can run CheckOps directly in Compass. Compass offers teams a single place where they can easily see metrics and goals and write down actions they plan to take.
메트릭, 알림, 계획된 작업이 포함된 주간 CheckOps 보고서 샘플입니다.
Trello에서도 주간 CheckOps 보고서를 실행할 수 있습니다.
필요한 것
대면
Compass의 CheckOps 보고서 템플릿
화이트보드
마커
스티커 메모
타이머
선택적 템플릿
Atlassian 템플릿
이 플레이는 Compass의 CheckOps 기능과 함께 사용할 때 가장 효과적입니다(팀이 CheckOps를 시작하는 방법 참조). Compass를 아직 시작하지 않았더라도 지금 바로 Trello에서 팀 상태 추적을 시작할 수 있습니다.
플레이 실행 안내
이 플레이는 소프트웨어를 개발, 제공, 실행하는 팀을 위한 플레이입니다.
1. 연습 준비 30분
DevOps 팀 목표 설정
The entire team will set goals together.
- Compass에 로그인해서 CheckOps 기능으로 이동하거나 목표를 추적할 다른 방법을 준비합니다.
- 개발 또는 운영 관행에서 변경하거나 개선하고 싶은 점을 식별합니다.
비즈니스 요구 사항에 따라 운영 목표를 세울 수 있습니다.
- 고객에게 최대한 빠른 서비스를 제공해야 합니까, 아니면 연중무휴 24시간 이용할 수 있어야 합니까? 대기 시간, 처리량 또는 가용성에 대한 DevOps 목표를 설정합니다.
팀에서도 운영 목표를 세울 수 있습니다.
- 팀이 처리할 수 없는 인시던트 및 알람으로 인해 새벽에 깨는 데 지쳐 있습니까? 인시던트 및 처리할 수 없는 알림의 수를 최소화하는 목표를 설정하세요.
- 풀리퀘스트가 검토되기까지 너무 오래 기다리고 있습니까? 풀리퀘스트를 열어 두는 기간에 대한 운영 목표를 설정하세요.
소수의 DevOps 목표부터 시작하세요. 목표를 단순하게 유지하고 진행 상황을 추적하는 데 적합한 정보를 수집하고 있는지 확인하세요. 가능한 경우 모든 서비스에 대해 같은 목표를 가지고 시작하세요. 그러면 팀이 각 미팅에서 검토할 데이터에 더 쉽게 집중할 수 있습니다.
DevOps 목표가 측정 가능한지 확인
목표 달성 여부를 확실히 알 수 있도록 측정 가능한 방식으로 목표를 정의하세요.
- 서비스의 운영 메트릭을 사용하면 좋습니다. 관찰 도구(예: Splunk Observability, DataDog, Grafana 등)를 사용하고 영향을 주려는 메트릭을 명시적으로 설명하세요.
- 리포지토리에 대한 개발 메트릭도 중요합니다. 이 메트릭은 Jira Software 또는 Compass를 사용하여 가장 효과적으로 추적할 수 있습니다.
이 연습을 하다 보면 실제로 개선하고자 하는 목표를 측정하고 있지 않다는 사실을 깨닫게 될 수도 있습니다. 그래도 괜찮습니다! 첫 번째 CheckOps 미팅의 실행 항목 중 하나가 관련 DevOps 메트릭을 추가하는 것일 수 있기 때문입니다. 메트릭이 추가되면 향후 미팅에서 해당 메트릭이 표면화될 수 있습니다.
DevOps 목표 작성
설정한 목표에 팀이 착수한 후에는 해당 목표를 작성하여 모든 팀원과 공유하세요. 이 목표는 선언한 운영 목표입니다. 그런 다음, 쉽게 접근할 수 있고 눈에 잘 띄는 기본 Confluence 문서를 설정하고 거기에 DevOps 목표를 저장하세요. Compass를 사용하는 경우 성과 기록표에 목표를 설정할 수 있습니다.
DevOps 목표는 시간이 지남에 따라 바뀔 수 있으며 실제로 바뀝니다. 더 많은 정보를 수집할수록 목표에 대해 더 많은 정보에 입각한 결정을 내릴 수 있게 됩니다. 또한 비즈니스 또는 운영 목표가 변화하는 것을 발견할 수도 있습니다. 하지만 한 번에 너무 많은 목표 및 DevOps 메트릭을 추가하지 않도록 주의하세요. 팀이 집중하는 바가 희미해져 원하는 결과를 달성하지 못하게 될 수도 있습니다. 3~6개월의 기간 내에 목표를 최대 3개까지 설정하는 것이 좋습니다.
팀이 선택할 수 있는 목표의 예는 다음과 같습니다.
- 풀리퀘스트 또는 총 사이클 타임(TCT) 늘리기: 팀이 마감 날짜를 자주 놓칠 때 유용합니다.
- 팀이 매주 처리하는 알림 또는 인시던트 수 줄이기: 팀 업무가 너무 자주 중단될 때 유용합니다.
- 배포 빈도 늦추기: 팀에서 인시던트를 너무 많이 받을 때 유용합니다.
팀의 상태가 좋아질수록 준비 단계가 짧아질 수 있습니다.
2: 데이터 수집 15분
After the team sets goals, the presenter will need to gather data. Keep in mind, though you may not need to run step one every week, you will need to gather data each week.
로그 유지
다음번 CheckOps 미팅을 할 때까지 도구로는 캡처할 수 없는 주목할 만한 이벤트가 발생할 것입니다. 사람의 기억에는 오류가 있을 수 있으므로, 다음 미팅에서 다룰 수 있도록 세부 사항을 적어 두는 것이 좋습니다.
원격 팀에 있는 경우 주목할 만한 이벤트를 기록할 수 있는 새 CheckOps 보고서를 매주 만든 다음 적절한 팀원과 공유하세요. Atlassian의 DevEx 플랫폼인 Compass를 사용하는 경우 상태 세부 정보 페이지에서 쉽고 빠르게 CheckOps 연습을 시작할 수 있습니다.
- 대기 중 담당자가 호출을 받았는데 알림이 오탐이었습니까? 이 상황은 분명히 팀의 개발자 경험에 영향을 줍니다. 앞으로 개선할 수 있도록 기록하고 그룹과 공유하세요.
- 인시던트, 실패한 배포 이벤트, 병합하는 데 너무 오래 걸린 풀리퀘스트가 있었습니까? 한 주 전반에 대해 간단히 기록해 두면 팀이 나중에 기억에만 의존하여 이벤트를 재구성할 필요가 없습니다.
검토 준비
As the on-call rotation ends (or right afterwards), the presenter should prepare the CheckOps report for that rotation. At its simplest, the report should include:
- CheckOps를 실행하려는 서비스/컴포넌트의 목록.
- 각 컴포넌트의 (목표 대비) 측정값.
- 목표 달성 여부에 대해 체크 또는 X(십자) 표시.
- A mitigation plan for any unmet goals, as well as notes from the presenter about why the goal wasn't met.
- 후속 조치를 캡처하는 섹션.
- 기타 이벤트 또는 이상의 요약.
CheckOps 보고서에 후속 조치를 캡처하는 것이 중요합니다. 그렇지 않으면 개선을 유도하는 피드백 루프를 원할 때 상태 보고서를 받게 됩니다.
3: CheckOps 검토 미팅 실행 30분
모두가 각자의 역할을 수행
Keep it interactive! Everyone on your DevOps team who takes a turn being on-call should attend this meeting, and everyone should have a job:
- 발표자: 대기 중 담당자 교대를 방금 마친 사람은 CheckOps 보고서 및 그 결과를 발표해야 합니다. 팀에 대기 중 담당자가 없는 경우 한 주 동안 일어나는 이벤트에 대해 기록하고 찾은 결과를 플레이 중에 발표할 사람을 지명하세요.
- 다음 대기 중 담당자: 이 담당자는 지금까지 확인한 이슈 또는 다음 대기 중 담당자 교대에서 재발할 수 있는 잠재적인 위험 영역을 포함하여 발표자가 관찰한 내용에 세심한 주의를 기울여야 합니다.
- Leader: The leader is the person (or people) who can help the team prioritize actions and ensure followup. When an action requiring follow up arises, the leader should help make sure the right person (or people) owns the action and will be able to see it through to resolution.
- Other on-call team members and component owners: These are the people who are also in the on-call rotation and/or are intimately familiar with the services or components that are being operated.
결과 공유 및 토론
발표자는 팀에게 각 서비스/컴포넌트를 안내하고 목표를 달성했는지 여부와 그 이유를 설명합니다. 또한 해당 서비스에서 발생한 운영 관련 이벤트 또는 이상에 대해 논의하고 관찰한 내용 및 분석을 공유합니다. 팀이 해야 할 일은 질문하고 후속 조치를 위한 제안을 제공하는 것입니다.
함께 협력하여 모든 DevOps 팀의 서비스/컴포넌트가 각각의 목표를 충족하도록 보장하는 방법을 찾으세요. 팀 전체가 함께 하는 활동입니다.
각 팀원이 해야 할 작업을 작성하고 미팅 중에 백로그에 티켓을 만드세요.
팁: 대응이 아닌 행동에 나서세요
팀이 운영 목표 또는 개발 목표를 달성할 책임이 있다면 대응적인 태도를 취하는 함정에 빠지기 쉽습니다. 신뢰성에서부터 제공 속도, 코드 품질에 이르기까지, CheckOps가 장려하는 데이터 기반 접근법을 통해 팀이 DevOps 목표를 달성하고 개발자 경험을 향상하며 지속적으로 개선할 수 있어야 합니다.
후속 조치
반복
CheckOps 플레이를 매주 실행하고 팀의 대기 중 담당자 일정 인계에 맞게 정렬하는 것이 좋습니다. 2단계와 3단계는 매주 반복하고, 1단계는 매주 실행할 필요가 없을 수도 있습니다. 계속해서 플레이를 연습하면 1단계와 2단계에 소요되는 시간이 짧아질 것입니다. 팀이 CheckOps 플레이를 몇 주 동안 실행하면, 다른 중점 영역도 포함하도록 관행을 확장하고 발전시킬 기회를 얻을 수도 있습니다. 예를 들어 코드 범위와 같은 품질 메트릭, 특정 기능의 주간 활성 사용자와 같은 비즈니스 메트릭 또는 팀의 상태를 개선하는 모든 메트릭을 측정할 수 있습니다.
운영 목표 재평가
Over time, the original DevOps goals you set may no longer meet your team's needs. Maybe the business needs changed, or the targets became more or less aggressive. If so, run step one, update your stated operational objectives, and continue your practice. You can also expand the scope of your CheckOps practice, if necessary, to cover more services or components or other aspects of your operations practice.
보고 자동화
범위가 확장되면 분석에 들이는 시간은 늘리고 보고에 들이는 시간은 줄이고 싶어질 것입니다. 주요 메트릭 수집 및 CheckOps 보고서 생성을 자동화하는 방법을 찾아보세요. 그러면 더 많은 보고 작업이 자동화되면서 팀의 생산성 및 개발자 경험이 모두 개선될 것입니다.
자동화를 추가하는 경우 수집하는 데이터를 분석하는 데 시간을 들이고 CheckOps 미팅을 준비하고 있는지 확인하세요. Atlassian팀은 이를 위해 Compass의 메트릭을 사용하고 있으며, 고객도 똑같이 지원하기 위해 제품에 CheckOps 환경을 통합했습니다.
운영 목표 예시
돌아보기
팀이 책임에 따라 CheckOps 관행을 구조화할 수 있도록 다음의 운영 목표 예시를 활용해 보세요.
Delivery types | Possible objectives |
|---|---|
Microservice |
|
On-call team |
|
Software delivery |
|
Mobile application |
|
팀에서 팀으로
월간 뉴스레터를 통해 최신 플레이, 유용한 정보와 팁에 관한 최신 소식을 받으세요.
