Cloud Native Notes
그런데 맛있습니다.
정기 유지보수를 작은 변경으로 나누는 이유
자동화의 목표는 빠른 변경이 아니라, 이상 징후가 보이면 안전하게 멈출 수 있는 변경 흐름을 만드는 것이다.
kuberneteskubeadmciliumbootstrapoperationsmaintenance
11분 읽기
Platform Practice
플랫폼을 제품처럼 다루며 세운 공개 가능한 운영 원칙입니다.
Reliable Operations
변경 범위를 줄이고 복구 선택지를 넓히는 운영 기록입니다.
Delivery Practice
변경의 소유권과 검토 흐름을 분명하게 만드는 배포 원칙입니다.
Observability
운영 판단에 필요한 신호를 고르고 연결하는 방법을 다룹니다.
Security Basics
내부 정보를 드러내지 않으면서도 설명 가능한 보안 원칙입니다.
Incident Notes
복구 순서와 재발 방지 판단을 공개 가능한 수준으로 정리합니다.
새 기록
최근 발행 글
Reliable Operations · 7월 20일
6분정기 유지보수를 작은 변경으로 나누는 이유
자동화의 목표는 빠른 변경이 아니라, 이상 징후가 보이면 안전하게 멈출 수 있는 변경 흐름을 만드는 것이다.
operationsmaintenancereliability
Platform Practice · 7월 19일
6분워크로드 이동성이 복구 선택지를 넓힌다
불필요한 배치 고정을 줄이면 평상시 효율뿐 아니라 장애 상황에서 선택할 수 있는 복구 경로도 늘어난다.
platformportabilityrecovery
Delivery Practice · 7월 18일
5분GitOps 이름에 변경의 소유권을 담는 법
좋은 애플리케이션 이름은 화면을 정리하는 데서 끝나지 않고 변경 단위와 책임 경계를 함께 보여 준다.
gitopsnamingownership
Incident Notes · 7월 17일
6분외부 접속 문제를 계층별로 좁히는 방법
접속 장애를 하나의 덩어리로 보지 않고 사용자 진입, 서비스 전달, 애플리케이션 상태로 나누면 복구가 빨라진다.
incidentedgerunbook
Security Basics · 7월 16일
6분시크릿 수명주기를 원본과 소비자로 나누기
비밀값을 다루는 핵심은 도구 이름이 아니라 원본, 전달, 소비, 교체의 책임을 겹치지 않게 만드는 것이다.
securitysecretslifecycle
Observability · 7월 15일
6분관측 데이터는 수집량보다 판단 가능성이 먼저다
로그와 지표를 많이 모으는 것보다 어떤 질문에 답할지 정하고 보존과 연결 기준을 세우는 일이 중요하다.
observabilitysignalsretention
Incident Notes · 7월 14일
5분운영 회고에서 공개 문서와 내부 문서를 나누는 기준
좋은 회고는 투명하지만 모든 것을 공개하지 않는다. 재사용 가능한 교훈과 공격 표면이 될 정보를 분리해야 한다.
incidentdocumentationprivacy