|
|
|
|
|
 |
개발은 미래를 만드는 일이지만, 운영은 지금을 지키는 일입니다.
또 하나의 원칙은 관측 가능성입니다.
운영을 하면서 가장 허무한 순간은, 문제가 있는데 보이지 않는 때입니다.
운영에서 가장 위험한 것은 사람이 피곤한 상태에서 반복 작업을 하는 순간입니다.
저는 자동화를 무작정 늘리는 사람이 아니라, 자동화를 운영의 안전장치로 쓰는 사람입니다.
즉, 장애 대응만 잘하는 사람이 아니라 장애가 줄어드는 구조를 만드는 사람입니다.
알림설계 원칙은 세 가지입니다.
성과는 운영 런북과 초기 진단 체크리스트 구축입니다.
|
|
|
 |
인프라운영 관점에서 장애를 가장 빠르게 감지하고 확산을 막기 위한 관측 지표와 알림설계 원칙을 설명해주세요
저는 책임을 회피하지 않는 방식으로 기술을 배워온 사람입니다.
운영자는 "언젠가 고치겠다"가 아니라"지금 멈추지 않게 하겠다"를 말해야 합니다.
그리고 NHNE nterp rise를 선택한 이유는, 인프라를 상품으로 만들고 고객의 비즈니스를 떠받치는 환경에서야말로 운영자 의 실력이 가장 정직하게 드러나기 때문입니다.
내부 서비스 운영만으로도 어렵지만, 고객 환경이 섞이는 순간 변수가 늘고, 그 변수는 운영자의 기본기와 커뮤니케이션을 동시에 시험합니다.
저는 어떤 기술을 배울 때 '그 기술이 실패하는 순간'을 같이 학습합니다.
성공 사례만 보면 운영자가 되기 어렵습니다.
장애는 교과서대로 오지 않습니다.
무엇을 측정하면 "증상"이아 니라" 원인 후보"에 가까워지는지, 어떤 임계값이 실제 장애의 선행 신호인지, 어떤 대시보드가 야간 당직자의 판단을 돕는지, 이런 질문이 곧 운영설계입니다.
지표가 없으면 로그에서 단 서를 찾고, 로그도 없으면 재현 조건을 확보해 관측을 만들고, 그래도 어렵다면 범위를 줄이는 안전장치를 우선 적용합니다.
운영에서 가장 위험한 것은 사람이 피곤한 상태에서 반복 작업을 하는 순간입니다.
다만 자동화가 위험해지는 조건도 알고 있습니다.
배포 자동화에는 단계적 배포와 즉시 중단 조건이 있어야 하고, 인프라 변경 자동화에는 승인 흐름과 드리프트 감지가 있어야 합니다.
저는 자동화를 무작정 늘리는 사람이 아니라, 자동화를 운영의 안전장치로 쓰는 사람입니다.
그때 갈등이 생기는 이유는 기술 수준 차이가 아니라 언어차이입니다.
운영을 엔지니어링으로 끌어올리는 사람이 되고 싶습니다.
즉, 장애 대응만 잘하는 사람이 아니라 장애가 줄어드는 구조를 만드는 사람입니다.
그리고 문서는 만드는 것으로 끝나지 않게 하겠습니다.
실제로 장애대응 훈련이나 점검에서 문서를 사용해, 문서가 현장에 붙도록 만들겠습니다.
자동화를 운영 리스크를 줄이는 도구로 쓰겠습니다.
큰 사고를 해결해서가 아니라, 작은 일들을 정확하게 처리 하고, 반복을 줄이는 구조를 만들면 팀은 그 사람을 믿기 시작합니다.
저는 우선순위를 "핵심 경로 보호, 확산 차단, 복구가 속"순으로 둡니다.
배포와 롤백, 인증서 갱신, 백업 및 복구 검증, 계정 권한 변경, 스케일링과 리소스 조정, 점검 리포트 생성 같은 작업이 대표적입니다.
실패시 되돌릴 수 없는 작업을 무가드레일로 자동화할 때, 그리고 관측이 부족한 상태에서 자동화를 먼저 밀어붙일 때입니다.
먼저 사용 자 체감 지표와 SLI를 확인해 영향 범위를 정합니다.
그 다음 파드 레벨에서 재시작 횟수, 리소스 제한, OOMKilled, 프로브 실패를 확인합니다.
동시에 이벤트와 로그를 함께 봐서 스케줄링 실패나 이미지풀, 네트워크 플러그인 문제 같은 시스템 이슈를 배제합니다.
중요한 것은 한 번에다 보려 하지 않고, 영향이 큰 구간부터 차례로 배제해가는 절차입니다.
공격 경로가 의심되는 구간은 네트워크 차단과 격리로 확산을 막습니다. |
 |
이다, 운영, 자동화, 장애, 사람, 만들다, 지표, 원인, 인프라, 관측, 운영자, 알림, 말, 어떻다, 조치, 줄이다, 먼저, 서비스, 성, 로그 |
|
|
|
|
|
|
 |
|
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
2026.01.15
7페이지
