devops problem solving(이슈해결 역량 기르기 팁)

gpt로 대충만든거니 이해바란다 ㅎㅎ;

필자가 k8s 등 여러 클라우드 이슈들을 경험하면서 정리한 이슈 대응 방법 절차이다. 정답은 아니니 참고하면 좋겠다.

요약
1. 우선순위를 판단한다(critical, major, minor)
- 현상해결이 원인분석에 우선한다.
- 조직 내 전파가 필요한지 판단
2. 히스토리를 확인한다.
3. 각종 정보(지표 등)를 확인한다.
4. 가설을 세우고 증명하기(원인 파악하기)
5. 해결되면 생각해볼 것들
6. 미해결 이슈 공유

우선순위 판단

• Critical: 장애상황, 서비스 중단. 사용자가 바로 알아차릴수 있음
• Major: 일부 극소수 사용자가 알아차릴수 있음. 서비스는 계속 제공가능
• Minor: 사용자가 알아차리지 못함. 서비스 계속 제공가능

원인분석보다 현상해결이 우선이다. 예를 들어, 어떤 k8s 노드가 문제라서 장애라면 스케줄링 비활성하고 제거하는것이 바람직하다. 그리고나서 남겨진 정보로 원인 분석을 한다.
Critical 이슈는 조직 내 전파를 하고, 컨트롤타워 역할을 요청해야한다.

• 컨트롤타워의 역할(조직장 혹은 현재 대응할수 있는 시니어 개발자)
  • 대응팀 멤버간의 소통주재
  • 의사 결정
  • 실시간 장애 상황 정리
  • 대외 소통 담당(필요시 다른 사람에게 위임할수도 있다)

장애 선언(공지) 기준

• 다른팀의 도움이 필요
• 사용자에게 영향을 미쳤는가
• SLO 기준 이내에 해결이 안될 경우

해결 방식 결정

• Deprecation 여부
  • 오래된 버전이라면 자세한 분석보다 업그레이드를 권장하는것이 낫다.
• 재시작등을 통해서 해결해도 될것인가?
• 원인을 분석해 해결하는게 중요한가? 아니면 workaround를 통해 이슈를 해결하는게 중요한가?(더 나은가?)
  • 1회성인지 아닌지

히스토리 확인

• 기존에 회사내 알려진 장애 현상과 비슷한게 없는지 검색
• 해당 시간에 다른 인프라 작업이 있었는지 확인

지표확인

서버공통

기본적으로 시스템 메트릭 및 로그를 최대한 확보하는 것이 중요하다.

Pod

probe fail

• describe pod
  • exit: 137
    • OOM
    • CPU Throttling으로 인한 failed
• pod 로그
• 서버 CPU load
• CPU throttled

Network

• 외부 연결 안됨
  • pod에서는 필요시 proxy 셋팅을 해야한다.
  • curl로 먼저 비교 테스트를 해보자
• CNI에 대한 분석

재시작전 확보할 정보들

• 노드 위치
• 로그
• 연관 팟 로그
• describe, get
  • 생성시 문제가 없다하더라도 생성후 잘못된 스펙값으로 인해 에러가 발생할 수도 있다.

CrashBackoff

• pod spec에 다음과 같이 설정해서 일단 pod을 실행시킨 후 pod안에서 확인해볼수 있다.
• https://kubernetes.io/ko/docs/tasks/inject-data-application/define-command-argument-container/#%EC%85%B8-%EC%95%88%EC%97%90%EC%84%9C-%EC%BB%A4%EB%A7%A8%EB%93%9C-%EC%8B%A4%ED%96%89%ED%95%98%EA%B8%B0

Resource error trouble shooting

https://learnk8s.io/troubleshooting-deployments

A visual guide on troubleshooting Kubernetes deployments

Kubectl Log level

https://kubernetes.io/docs/reference/kubectl/cheatsheet/#kubectl-output-verbosity-and-debugging

Application

Java

• 컨테이너 java 버전
• 메모리 옵션
• 프록시 설정
• keepalive 옵션

Golang

• GC 정책 변경으로 인한 메모리 증가 현상이 발생할 수 있다.

사용자

• 사용자로부터 빈도, 상황에 대한 충분한 정보 확보
  • 언제부터 시작했고,
  • 빈도가 어떻게 되는지
  • 이슈 발생시 특별한 연관 액션이 있었는지
• 이슈 사전 작업들이 어떤게 있었는지(로그, 메트릭등) 면밀한 관찰 필요
• 사용이 잘 안되다가 사용되는 기능(api 등)이 있었는지 확인 필요

반응형

가설 세우기

• 추측한 원인에 따른 현상에 일관성이 있어야 한다.
  • 없다면 원인이 아니거나
  • 여러 원인이 혼합되어 있을 수 있다.
  • 또는 잘못된 현상확인이 있을 수 있다(적당한 배제가 필요)
• 편견에 사로잡히지 않아야 한다.
  • 새로운 이슈일 수 있다.
  • 자신이 아는 지식이 사실이 아닐 수 있다.
  • 다른 사람이 말한 것이 사실이 아닐 수 있다.
    • 사용자(글쓴이)의 말이 틀릴 수도 있다.
    • 블로그 내용이 항상 정확한 건 아니다.
• 잘못된 정보가 혼입되지 않도록 한다.

가설 증명하기

• 여러가지 가설을 세운 뒤 하나씩 확인하며 제거해 나간다.
• 단순화하기와 범위 좁히기
  • 시스템 계층별로 정리
    • 분할정복기법 방식으로 이슈의 범위를 좁혀본다.
    • 정상인 시스템과 비교해보기
  • 불필요한 정보를 제거하여 단순화 하기
  • 서로 다른 원인으로 추정되면 분리해 정리하기
  • 테스트를 진행하고 기록이 중요. 반복 작업을 피해야함

---

이슈 해결후 생각해볼 것들

• 자동화
  • 일회성이 아닌가?
  • 단순 반복 작업인가?
  • 새로운 기능 오픈 직후 관련된 이슈인가?
• 사용자 이해도
  • 비슷한 문의를 계속 받는가?
  • 자동화가 어려운가? → 가이드 작성
  • 양식 개선(추가 설명 등)
• 처리 담당부서가 따로 있었나?
  • 빈도가 높으면 에스컬레이션을 통해 담당부서와 개선책 마련
• 예방 여부
  • 테스트 케이스 추가
    • 유닛테스트
    • integration테스트
  • 로직 수정
  • 툴 개발
    • 이슈, 원인을 빠르게 탐지할수 있는 툴
    • 이슈를 해결할수 있는 자동화 툴
• 조직 내 공유 및 관련 히스토리 정리
  • 시간, 요약
  • 담당자
  • 시스템 환경
  • 현상
  • 재현경로
  • 발생원인
  • 근본원인
  • 해결방법
  • 관련 자료

---

미해결 이슈 조직 내 공유

• 공유 내용
  • 우선순위
  • 현상
    • 언제부터, 빈도, 기간
  • 내가 확인한 것들
  • 내가 추정한 것들
• 본인이 확인한 정보를 크로스체크할 수 있도록 한다.(내가 확인한게 사실이 아닐 수도 있다)