<서두>
- 장애가 발생하였다. 왜 일어났을까? 어떻게 할까?
<장애 유형>
1) 하드웨어 / System / OS 등의 장애
2) Network 장애
- Transaction 장애
3) Database 장애
- PC 전원이 뽑히거나(아주 예외적인 case) server에 이상이 생겨 Database를 호출하지 못해 발생하는 장애
4) Code 장애
<태도>
- 대응보다 태도가 중요한데 Line, Kakao 말고는 태도 관련하여 언급한 이가 없어 적는다.
- 사람이 하는 일이기에 장애는 반드시 발생한다. 문제는 장애 발생시 책임을 추궁하는 문화다.
==> 누가 장애를 발생시켰는지 git log 를 샅샅이 뒤지거나, 몹시 갈구는 해악, 장애가 해결되어도 뒤끝있게 야근 종용 등. 그런 회사는 다음 날 퇴사하자. 당신의 인생에 단 1도 도움되지 않는다. 인내심은 성장하지 않으며 탈모와 수면장애가 온다.
==> 추궁 문화는 사람들이 새로운 것에 도전하는걸 막으며, 위축된 상태에서 보수적으로 운영하기에 혁신이 없다.
- Line 및 KaKao에서의 장애 대응 태도
1) 앞으로 어떻게 하면 같은 장애가 또 발생하지 않게 할까?
2) 어떻게 하면 더 빨리 감지할까?
3) 장애가 발생하더라도 그 영향 범위를 최소(min dmg)로 하려면 어떻게 해야 할까?
4) 시스템이 자동으로 복구되게 만들 수 없을까?
5) 사람이 실수하더라도 그것을 System에서 사전에 방지할 수 있는 방법은 무엇일까?
6) 새로운 사람(신입 등)이 왔을 때 같은 실수가 반복되는걸 막을 수 있는 방법은 무엇일까?
- 개인적으로 추천하는 태도
7) 애초에 System/Application을 실수하기 어렵게 만든다.
8) 장애 발생시, 3자 입장에서 사람은 반드시 배재하고 Recovery 이야기만 한다.
9) 기획 단계에서 어느 정도의 실수가 반드시 발생함을 전제로 구상한다.
10) 장애가 발생하면 바로 보고하고 share하며 서로 돕는 문화.
==> 장애 발생시 서로 돕는다는게 같이 야근하고 주말 출근해서 해결하고 그런 것만이 아니다. 관심을 가져 피드백을 주고, 고심하며 해결 및 사후 방안을 논의하고, 인재(人災) 라면 격려하거나 커피 한 잔 사주고 뭐 그런거 말이다.
11) 장애 발생시, 해당 담당자 뒤로 몰려가 병풍처럼 서서 압박감 주지 말기
<장애 처리 Process>
[장애 탐지]
- 2가지 종류의 기업 타입이 있다. Monitoring을 하거나 or 하지 않거나
- 라인, 카카오 및 B2C 서비스기업의 경우, 모니터링 도구의 알람이나 관계 부서 or Usesr의 보고를 통해 탐지.
==> Line 의 경우 자동으로 메일을 발송하는 알람 시스템, 자동으로 메시지를 전송하는 감시봇, 장애를 발견한 사내 임직원이 share 가능한 Slack 채널, 외부에서 report할 수 있도록 온라인에 준비한 LINE CS form 등이 있다.
- 성경에 맞는 다양한 채널을 구성하고, 다양한 지표를 참고로 Service 이상 징후를 탐지.
1) System. 지표 : CPU, Memory, Latency, 5xx error count 등
2) Business 지표 : service 상세 진입률, Business 관련 service 추이 (주문, 요청 등)
3) 외부 연동 System 지표 : 연동 System Request 전달 실패, 관련 외부 System 장애.
- 중소 기업이나 it서비스 기업이 아닌 경우(B2B 등) 대부분이 monitoring 하지 않다가 장애 발생시 사후처리함.
==> 그들에게 보통 장애가 발생하는 이유는 '메모리 누수', 'Code Error' 다 보니 모니터링을 통하여 즉각 확인하기 어렵다.
==> 모니터링을 하려면 인력 및 cost가 발생하므로, 대형 서비스 or 금융권 등 장애에 민감한 기업이 아니라면 모니터링을 하지 않음.
- Prometheus 를 통해 metric data 를 collection 하고, Grafana 를 통해 collection한 metiric data를 시각화하여 Monitoring.
@@ Metric data란? Resource 사용 모니터링 or Database 실행 모니터링 등 소프트웨어나 하드웨어의 상태 Monitoring 을 timestamp와 숫자값으로 표현한 이벤트. log 와 달리 일이 터질 때만 전송되는게 아니라 주기적으로 보내짐.
- Datadog 을 통해 Server, Database, Cloud Service 등을 Monitoring 한다. (대부분의 DevOps 들이 이걸 씀)
[장애 공지]
- 최초 장애 전달 시, 확인된 최소 정보만 빠르게 공지 (화재 경보기 처럼)
- 장애 전달 내용은 장애 발생, 시간, 영향 범위, 장애조치 채널, 내부적으로 정의한 장애 등급 등이 있음.
[장애 전파(Share)]
- 장애 탐지시 발생 원인 파악과 동시에 관련 부서로 장애 내용 즉각 전달.
==> 실제로 장애 발생시 자체적으로 해결하려는데 집중하여 장애 전달이 원활치 않는 경우가 있다.
==> 장애 Share만 잘 이뤄져도 해결하는 과정에서 타 부서의 도움을 받거나, 장애의 영향을 받는 쪽에서 준비된 대응을 실시해 장애 영향 range를 줄일 수 있다. 파악과 동시에 관련 부서로 장애 내용 즉각 전달!!
- 장애 range가 작으면 관련 부서에만 Share.
- 장애 range가 크면(Main Service Error 등) Slack 등 별도로 준비된 커뮤티케이션 채널을 통해 장애 내용을 광범위한 대상에게 Share.
[장애 해결]
- 하드웨어나 System, OS 등의 장애는 전용 tool을 통해 확인
- Code 장애는 test code, test server 등을 통해 확인
- Transaction 장애의 경우, 미리 Locust나 Ngrinder를 통해 Stress Test를 해보면 좋다.
- 롤백 :
==> 장애의 지속 및 확산을 빠르게 막는 방법.
==> 그러나 release된 내용에 data 스키마 변경이 포함된 경우, 롤백이 어렵거나 롤백을 하면 더 큰 문제를 초래할 수 있음. 시니어 조차도 대규모 프로젝트에서는 모든 release 내용을 파악하기 어려우므로 롤백하기 어렵다.
==> Cost가 넉넉하지만 Server를 롤백하기 어려우면, 서버 이중화(High Availibility) 를 활용하여 서버 여분을 두자.
- 장비 증설 :
==> Traffic 이 예상보다 많이 유입될 경우에 대비한 방안.
==> 이걸 쓰려면 사전에 장비 증설이 쉬운 구조로 만들어야 함. 코드나 설정 파일을 수동으로 수정해서 배포해야만 증설이 가능하도록 만들었다면, 증설 과정에서 다른 장애가 다시 발생하기도 함.
==> 그렇기에 미리 여분의 장비를 받아놓고 바로 투입 가능한 상태로 유지하면서, 증설이 필요한 경우 Drag & Drop 등의 간편한 방법으로 증설 되도록 만들어 두는게 좋음.
==> Cloud 의 Auto-Scaling 을 쓰면 편함.
- 핫픽스 배포 :
==> 롤백이나 재기동으로도 해결이 어려워, 문제를 수정한 버전으로 배포하는 것.
==> 롤백이나 재기동이 어려운 Client에서 많이 쓰이며, Server의 경우에도 롤백이 어렵다고 판단되거나 일시적 장애라 롤백까지 필요없는 경우엔 이 방법을 사용.
[장애 보고(Report)]
- 장애 대응이 어느 정도 완료되면 장애 보고서 작성.
- 각 회사 마다 보고서 작성 방식은 다름.
[장애 회고]
- 장애를 돌아보며 원인 분석 및 향후 대응책을 논의.
- 팀 내 회고 :
==> 장애를 발생시킨 직접 원인과 근본 문제를 파악하고 해결책 마련.
==> 장애 원인을 설명 시 단순히 그래프나 발생한 사건들을 나열함이 아닌, 시나리오를 만든다는 느낌으로 작성 추천. 장애 유발 원인 작업에서 부터 장애 발생까지 일련의 사건들이 어떻게 연결되어 문제를 일으켰는지 설명 필요
==> 원인 분석에 대한 해결책 :
1) Preventing Future Outages (장애가 발생하지 않도록 막는 방법)
2) Improving Outage Detection (장애 탐지 개선법)
3) Improving Outage Handling (장애 처리 개선법)
- 개발자 회고 :
==> 개발자들이 모여 장애의 전체 타임라인을 확인하며 문제를 돌아보는 시간.
==> 장애 관련 부서 뿐 아니라 관심있는 누구든 모여 장애 원인 및 해결책을 논의.
- 해결안으로 자주 논의되는 Item
1) Preventing Future Outages
* 해당 문제를 사전에 체크 가능하도록 유닛 Test or 통합(Integration) Test 추가
* 같은 문재가 발생하지 않도록 장기적으로 구조 개선 (ex. Synchronous한 부분을 asynchronous하게 개선)
* fast failure를 통해 resource 낭비 방지 (ex. Connection에 실패하면 기다리지 말고 빠르게 실패 처리)
2) Improving Outage Detection
* 알람 시스템에 알람 항목 추가 (ex. request failure count > 1000)
* log 추가
* 여러 가지 수치를 한번에 볼 수 있는 dashboard 제작
3) Improving Outage Handling
* 작업 사전 공유 (사소한 작업이라도 사전에 공유하면 장애 대응 수월)
<출처 1> https://sangwoo0727.github.io/database/Database-10_failure_recovery/
<출처 2> https://engineering.linecorp.com/ko/blog/line-failure-reporting-and-follow-up-process-culture/
<출처 3> https://techblog.woowahan.com/4886/
<출처 4>
<출처 5>
'Project > Error Management' 카테고리의 다른 글
| [Error Management] Heroku 배포 장애 : pre-receive hook declined (2) | 2022.10.08 |
|---|---|
| [Error Management] 해킹 대응 (0) | 2022.08.12 |
| [Error Management] 카카오톡 눈배경 에러 사건 (0) | 2022.07.26 |
| [Error] ATM 이중인출 Error 발생 실제 사례 (0) | 2022.05.27 |
댓글