이슈 관리를 위한 공동작업 프로세스 빌드

Last reviewed 2023-08-08 UTC

Google Cloud 아키텍처 프레임워크의 이 문서에서는 서비스를 관리하고 이슈 대응 프로세스를 정의하기 위한 권장사항을 제공합니다. 이슈는 모든 서비스에서 발생하므로, 이러한 이슈에 효율적으로 대응하고 완화하기 위해 잘 기술된 프로세스가 필요합니다.

이슈 관리 개요

잘 설계된 시스템도 결국에는 SLO를 충족하는 데 실패하게 됩니다. SLO가 없는 경우에도 고객은 자체적으로 과거 경험을 토대로 허용 가능한 서비스 수준을 대략적으로 정의합니다. 그런 후 SLA 내용과 관계없이 기술 지원 또는 유사한 그룹으로 에스컬레이션합니다.

고객에게 적절한 서비스를 제공하려면 이슈 관리 계획을 수립하고 정기적으로 테스트해야 합니다. 이러한 계획은 10개 정도의 항목이 포함된 한 페이지짜리 체크리스트일 수 있습니다. 팀은 이러한 프로세스를 통해 감지 시간(TTD)과 완화 시간(TTM)을 줄일 수 있습니다.

TTR과 달리 TTM이 선호됩니다. 여기서 R은 복구를 나타내며 종종 전체 수정과 완화의 의미를 비교하는 데 사용됩니다. TTM은 서비스 중단에 따른 고객 영향을 빠르게 끝낸 후 문제를 완벽하게 해결하도록 종종 훨씬 더 긴 프로세스를 시작하기 위해 빠른 완화를 강조합니다.

운영 우수성이 검증된 잘 설계된 시스템의 경우 장애 간 시간(TBF)이 길어집니다. 즉, 우수한 사고 관리 등 안정성을 위한 운영 원칙은 장애 발생 빈도를 줄이는 것을 목표로 합니다.

안정적인 서비스를 실행하기 위해서는 이슈 관리 프로세스에 다음과 같은 권장사항을 적용하세요.

명확한 서비스 소유권 할당

모든 서비스 및 핵심 종속 항목에는 SLO 준수 책임을 위해 소유자가 명확하게 지정되어 있어야 합니다. 조직 또는 팀 규모가 축소될 경우 엔지니어링 리드는 필요한 문서 기록 및 학습 절차와 함께 소유권이 새 팀으로 명확하게 이관되는지 확인해야 합니다. 다른 팀에서 서비스 소유자를 쉽게 확인할 수 있어야 합니다.

미세 조정 알림으로 감지 시간(TTD) 단축

TTD를 줄이려면 먼저 아키텍처 프레임워크 안정성 카테고리의 인프라 및 애플리케이션에 대한 관측 가능성 빌드 및 안정성 목표 정의 섹션에 설명된 권장사항을 검토하고 구현해야 합니다. 예를 들어 애플리케이션 이슈와 기본적인 클라우드 이슈 사이의 모호함을 없애야 합니다.

여러 SLI를 적절히 조정하면 과도한 알림 없이 적시에 팀에 알림이 전송됩니다. 자세한 내용은 아키텍처 프레임워크 안정성 카테고리의 효율적인 알림 빌드 섹션이나 SLI 측정항목 개선: CRE 주기 강의를 참조하세요.

사고 관리 계획 및 학습을 통해 완화 시간(TTM) 단축

TTM을 줄이려면 문서화되고 충분한 연습을 거친 사고 관리 계획을 정의해야 합니다. 해당 환경의 변경사항에 대한 데이터를 바로 사용할 수 있도록 준비해야 합니다. 팀은 TTM을 최소화하기 위해 신속하게 적용할 수 있는 일반적인 완화를 알고 있어야 합니다. 이러한 완화 기술에는 드레이닝, 변경사항 롤백, 리소스 늘리기, 서비스 품질 낮추기가 포함됩니다.

다른 아키텍처 프레임워크 안정성 카테고리 문서에 설명된 것처럼 변경사항에 대한 안전 및 빠른 롤백을 지원하도록 안정적인 운영 프로세스 및 도구를 만듭니다.

TTM이 최소화되도록 대시보드 레이아웃 및 콘텐츠 설계

운영자가 서비스와 중요한 모든 종속 항목이 실행되는지 여부를 1~2분 내에 확인할 수 있도록 서비스 대시보드 레이아웃 및 탐색을 구성합니다. 잠재적인 문제 원인을 빠르고 정확하게 확인하기 위해서는 운영자가 대시보드에서 모든 차트를 스캔하여 알림 시점에 크게 변경된 그래프를 빠르게 찾을 수 있어야 합니다.

이슈 문제 해결을 돕기 위해 대시보드에 다음과 같은 예시 그래프 목록이 표시될 수 있습니다. 이슈 대응 전문가가 단일 뷰에서 한 눈에 빨리 확인할 수 있어야 합니다.

  • 서비스 수준 지표(예: 성공한 요청을 총 유효 요청으로 나눈 값)
  • 구성 및 바이너리 출시
  • 시스템에 대한 초당 요청 수
  • 시스템의 초당 오류 응답 수
  • 시스템에서 종속 항목으로 전송되는 초당 요청 수
  • 종속 항목에서 시스템으로 전송되는 초당 오류 응답 수

문제 해결을 도와주는 다른 일반적인 그래프에는 지연 시간, 포화도, 요청 크기, 응답 크기, 쿼리 비용, 스레드 풀 사용률, 자바 가상 머신(JVM) 측정항목(해당하는 경우)이 포함됩니다. 포화도는 할당량 또는 시스템 메모리 크기와 같은 일부 제한에 따라 가득찬 정도를 나타냅니다. 스레드 풀 사용률은 풀 소진으로 인한 회귀를 찾습니다.

가장 중요한 그래프가 위쪽에 표시되고 그래프 순서가 표준 진단 워크플로와 일치하도록 몇 가지 중단 시나리오에 따라 이러한 그래프의 배치를 테스트합니다. 또한 머신러닝 및 통계적 이상 감지를 적용하여 이러한 그래프의 적합한 하위 집합을 드러낼 수 있습니다.

알려진 중단 시나리오에 대한 진단 절차 및 완화 기술

플레이북을 작성하고 알림 고지 항목에 연결합니다. 알림 고지로부터 이러한 문서에 액세스할 수 있으면 운영자가 문제 해결 및 완화에 필요한 정보를 빠르게 얻을 수 있습니다.

비난 없는 사후 분석을 통해 서비스 중단으로부터 배우고 재발 방지

비난 없는 사후 분석 환경과 이슈 검토 프로세스를 수립합니다. 비난 없는이란 해당 팀에서 누군가를 비난할 필요 없이 객관적인 방식으로 잘못된 것을 평가하고 문서로 기록하는 것을 의미합니다.

실수는 비난의 대상이 아닌 발전할 수 있는 기회입니다. 항상 시스템의 복원력을 향상시켜 사람의 실수로부터 신속하게 복구하거나 훨씬 더 효과적으로 사람의 실수를 감지하고 예방하는 것을 목표로 해야 합니다. 서비스 중단 발행 빈도가 줄어들도록 각 사후 조사에서 최대한 많은 학습을 추출하고 각 사후 작업 항목에 대해 지속적으로 후속 조치를 취합니다. 그러면 TBF가 증가합니다.

이슈 관리 계획 예시

알림이나 호출 또는 에스컬레이션 과정을 통해 프로덕션 이슈가 있음이 내게 확인되었습니다.

  • 다른 사람에게 위임해야 할까요?
    • 예. 본인과 팀이 문제를 해결할 수 없다면 위임해야 합니다.
  • 개인 정보 보호 또는 보안 침해 문제인가요?
    • 그렇다면 개인 정보 보호 또는 보안팀에 위임하세요.
  • 응급상황 이슈이거나 SLO가 위반될 수 있는 이슈인가요?
    • 확실하지 않으면 응급상황으로 처리해야 합니다.
  • 더 많은 사람이 참여해야 하나요?
    • 영향을 받는 고객 비중이 X% 이상이거나 문제 해결을 위해 Y분 이상 걸린다면 참여 인원을 늘려야 합니다. 확실하지 않다면, 특히 영업 시간 중이라면 항상 더 많은 인원을 투입하세요.
  • 기본 커뮤니케이션 채널(예: IRC, 행아웃 채팅, Slack)을 정의합니다.
  • 다음과 같이 이전에 정의된 역할을 위임합니다.
    • 전체 조정을 담당하는 이슈 책임자
    • 내부 및 외부 커뮤니케이션을 담당하는 커뮤니케이션 책임자
    • 이슈 완화 업무를 책임지는 운영 책임자
  • 이슈가 종료되는 시점을 정의합니다. 이 결정을 위해서는 지원 담당자 또는 기타 유사한 팀의 확인이 필요할 수 있습니다.
  • 비난 없는 사후 분석을 위해 공동 작업을 수행합니다.
  • 사후 분석 이슈 검토 회의에 참여하여 담당자가 수행할 작업에 대해 논의합니다.

권장사항

아키텍처 프레임워크의 안내 사항을 사용자의 고유 환경에 적용하려면 다음 권장사항을 따르세요.

다음 단계

다음 리소스를 사용하여 이슈 관리를 위한 공동작업 프로세스를 빌드하는 방법을 자세히 알아보세요.

시스템 설계, 운영 우수성, 보안, 개인 정보 보호, 규정 준수 등 아키텍처 프레임워크의 다른 카테고리를 살펴봅니다.