장애에 대한 생각

개요

최근 잦은 장애 발생

고장에 대해 독특한 이론과 최선의 실천을 고려했다

이미 체계화된 이론이 있다.
대상 정의
목표를 장애와 관련된 상업적 피해를 최소화하는 것으로 정했다.
장애에 대한 이야기,
모니터링, 이중화, 측정, 로그, 상태 점검
왜 이런 화제가 생겼는지는 장애와 관련된 비즈니스에 대한 피해를 최소화하기를 바라기 때문이다.
목표와 각종 요소의 관계
나는 장애가 될지 안 될지 고려했다.
외란 발생(통제 불가)
-> 외부 간섭으로 인해 시스템이 손상됨(이중과 같은 제어 영향으로 수신 가능)
->손상 관측(경보 등)
->손상 검사(로그, 메트릭 등)
->피해 감소(대응 등)
->피해 거리 초과
-> 장애 발생
관계를 써 보았다.

관측 시스템 위에 감시 시스템과 묶어서 보면
아래와 같다.

감시 시스템에는 피드백 루프가 포함된다는 얘기다.
예를 들어, 이 모델에서
좋은 시스템은 적당한 가정의 외란과 차인 비용으로 고장 발생률을 최소화하는 것이다.
그렇게 정의할 수 있을지도 몰라요.
어디에 투자해야 합니까?
어떤 외란이 일어날지, 어디에 투자하는 것이 가장 적절한지에 따라 변화가 생길 수 있다.
예상 외란

하드웨어 장애

인프라 결함

어플리케이션의 버그

리소스

과다 액세스

미시적
예를 들어 http의 건강 검사는 메모리 부족, 하드웨어 고장 없음, 네트워크 설정에 오류가 없음 등 여러 가지 상황을 동시에 확인할 수 있다.
한편으로는 전조를 잡을 수도 없다.(메모리 증가 등)
검사 방법마다 성질이 다르다.

전조를 보충할 수 있습니까?

동시 검사 가능 범위

자동 또는 모니터링
하드웨어 고장은 자동으로 처리할 수 있다
프로그램의 오류가 자동으로 대응할 수 없습니다.
자동 조작에 비용이 들 것 같으면 감시로 처리하면 되지 않겠는가?
나는 최강의 최선의 실천이라고 생각한다
0. 사용자의 반응
기본적으로 사용자의 반응을 식별하는 감시가 들어왔습니다.
1. 최대한 많이 감시
예를 들어 자판기라면 돈을 써서 물건을 사서 맛있는 주스를 마실 수 있습니까?정기적으로 감시하다.
이렇게 하면 2 이후의 감시가 완비되지 않은 것을 보충할 수 있다.
이외에도 일반적인 감시(자원감시, http상태감시 등)(보편적인 감시는 대중의 외부 간섭 분포를 반영하여 제작된 것이기 때문)도 가입할 수 있다.
2. 0 또는 1로 고장 보완 시 재발 방지
과거에 일어난 일은 장래에도 발생할 가능성이 높기 때문에 재발을 방지해야 한다.
재발 방지 방법은 3 이하.
3. 감시는 전조를 보완한다
수정 후
만약 수정이 완비되지 않은 부분이 있다면 감시를 통해 보충할 수도 있다.
메모리 부족으로 고장이 나면 메모리 부족 원인을 수정한 후 메모리 부족 여부를 감시한다.
왜 두 겹으로 하는 게 좋다고 생각하는지 설명을 잘 못하겠지만 그런 느낌이 자꾸 든다.
2배의 원가로 수정이 완비되지 않을 확률을^2로 바꿀 수 있습니다.
4. 전조가 없는 것은 전조가 있어야 한다
예컨대
하드웨어 고장은 전조를 잡기 어렵다
군더더기를 통해 일부 고장은 장애가 아니라 장애의 전조이다.
프로그램 논리라면 오류가 발생하기 전에 경고하고 오류가 발생하더라도 되도록 괜찮다.
구체론
자기가 조사한 물건의 노트.
ELK
측량, 가시화, 경보를 할 수 있는 장치
elastic search, 키바나.
유통되는 docker-compose가 잘 돌아가지 않아 시도하지 않았다.
Grafana + prometheus + cadvisor + node exporter
측량, 가시화, 경보를 할 수 있는 장치
잘 됐다.
rails 이것도 괜찮아요.
https://github.com/discourse/prometheus_exporter

Grafana: 각종 데이터 원본의 데이터(prometheus의 데이터 등)를 시각화하는 도구입니다.경보도 날아오를 수 있다

prometheus: 도량을 읽고 저장할 수 있는 서버입니다.

cadvisor:prometheus가 docker 도량을 보낸 녀석

node exporter:proometheus에 기계의 도량을 보내는 녀석

prometheus_prometheus에 rails 도량을 보낸 녀석

https://app.bugsnag.com
rails의 오류 로그를 무료로 수집하여 쉽게 볼 수 있습니다.
경보도 날아갈 거야.
rails에서 API를 직접 보내는 방법입니다.
flumentd 같은 게 등장하지 않아서 포인트가 쉬워요.
https://uptimerobot.com/
무료로 건강을 검사했다.경보도 날 수 있어.
잡감
나는 이 방법 자체가 알고리즘이라고 생각한다.
미지의 외란 분포 상태에서 어떻게 온라인 알고리즘으로 낮은 로컬로 외란을 막는 강력한 시스템을 구축합니까?이런 문제.
원래는 핸드메이드 감각이 가득한 운용 절차였는데 고장이 날 줄 알고 쿠베르네츠 같은 걸 찾아봤지만 기억하는 게 너무 많아 포기했다.
어떻게 해야만 전체 운용 절차를 바꾸지 않고 최소 원가로 고장 발생률을 낮출 수 있습니까?나는 이 보도를 고려했다.
감시를 통해 피드백 회로를 형성하고 최선의 실천은 자신에게 새로운 발견이다.