DevOps Colleague

원문: https://playerzero.ai/resources/what-is-agentic-sre-the-next-evolution-of-reliability-engineering Agentic SRE란? 신뢰성 엔지니어링의 다음 단계 현대 소프트웨어는 수백 개 서비스로 쪼개져 있고, 클라우드 네이티브 환경에서 돌아가며, 매일같이 코드가 배포됩니다. 이 속도는 고객이 요구하는 신뢰성을 유지하면서도 더 빠른 전달을 요구하기 때문에, SRE 팀에게 큰 압박으로 돌아옵니다. 그 결과 알림 피로(alert fatigue)는 심해지고, 엔지니어는 혁신보다 “불 끄기”에 더 많은 시간을 쓰게 됩니다. 원문은 이런 한계를 배경으로 Agentic SRE를 “기존의 사후 대응(reactive)을 넘어, 사전 예방..

Toil 줄이기 전략 5가지전략설명1. 관측 가능성 향상 (Observability First)알람, 로그, 지표, 분산 추적 등을 먼저 체계화해 장애 원인 분석을 쉽게 만듦2. 작업 표준화 → 자동화반복 작업을 문서화하고, 스크립트나 워크플로로 전환3. 셀프 서비스화티켓 기반 수동 작업을 개발자/운영자가 직접 처리할 수 있는 포털이나 CLI 제공4. GitOps 도입인프라/설정 변경을 코드 기반으로 관리하여 수동 운영 제거5. Toil 계량 및 주간 점검각 작업 시간을 기록하고, 일정 비율 이상 Toil일 경우 리팩터링 계획 수립 실무 자동화 사례1. 서비스 배포 자동화BeforeAfterJenkins에서 수동 빌드 + 수동 승인 후 배포Git push → CI/CD 파이프라인 → 배포 자동 진행운영자..

Toil은 반복적이고 수동적이며, 자동화되지 않았고, 사용자 가치에 직접적으로 기여하지 않으며, 시스템이 성장할수록 증가하는 작업입니다.— Google SRE Book 정의 Toil의 대표적인 예시유형예시수동 운영서버 재시작, 로그 수집, 알람 확인 후 수작업 대응반복 작업매일/매주 수동 배포, 모니터링 구성 갱신기계적 대응장애 대응 시 매번 문서 보며 동일한 조치 수행티켓 처리수동 계정 생성 요청, DNS 레코드 수정 요청 등 Toil의 조건 (Google SRE 기준)Toil은 다음 조건 중 여러 개를 만족해야 합니다:조건설명수동적사람의 개입이 필요함반복적같은 작업을 자주 반복함자동화 가능기술적으로 자동화가 가능함비가치 창출고객에게 직접적인 가치를 주지 않음확장성 없음시스템 규모가 커질수록 업무량..

SLO란 무엇인가?SLO(Service Level Objective)는 서비스의 신뢰성에 대한 구체적이고 측정 가능한 목표치를 의미합니다. 이는 서비스 수준 지표(SLI)를 기반으로 하며, 사용자 경험을 중심으로 설정됩니다. 예를 들어, "HTTP 요청의 97%는 성공적으로 처리되어야 한다"와 같은 목표가 SLO에 해당합니다.SLO의 필요성엔지니어링 자원은 한정되어 있으므로, 어떤 작업에 우선순위를 둘지 결정하는 것이 중요합니다. SLO는 이러한 결정을 데이터 기반으로 지원하며, 기능 개발과 신뢰성 확보 간의 균형을 유지하는 데 도움을 줍니다. 또한, SLO를 통해 오류 예산(Error Budget)을 정의하고, 이를 기반으로 릴리스 속도 조절이나 안정성 향상 작업의 필요성을 판단할 수 있습니다.SLO ..

개발자 생산성과 운영 효율성을 동시에 챙기기 위한 새로운 접근 방식으로 Platform Engineering이 주목받고 있습니다. Platform Engineering이란?Platform Engineering은 개발자들이 소프트웨어를 더 쉽고, 빠르고, 안정적으로 배포할 수 있도록 돕는 내부 개발 플랫폼(Internal Developer Platform, IDP)을 설계하고 운영하는 역할을 말합니다.핵심 개념은 이거예요:“개발자가 인프라나 배포 과정을 몰라도, 셀프서비스로 빠르게 개발에 집중할 수 있는 환경을 제공하자.”주요 특징:자동화된 셀프서비스 도구 제공→ 개발자가 버튼 하나로 배포하고, 로그 보고, 테스트 환경 만드는 식내부 플랫폼 팀 운영→ 인프라, CI/CD, 보안, 모니터링 등을 하나로 묶어..

Kubernetes의 AdmissionReview는 Admission Webhook과 API 서버 사이의 통신에 사용되는 요청/응답 포맷입니다. 간단히 말하면, "Kubernetes가 webhook에게 묻는 질문과 webhook이 보내는 대답"이라고 생각하면 됩니다. AdmissionReview란?AdmissionReview는 Kubernetes API 서버가 외부 Webhook 서버에 리소스 생성/변경 요청을 검사해 달라고 보낼 때 사용하는 구조체입니다.Webhook 서버는 이 요청을 분석하고, 허용할지 거부할지 결정한 후 응답합니다.구성요소:AdmissionReview.Request: API 서버가 보내는 요청 정보AdmissionReview.Response: Webhook 서버가 응답하는 승인/거부..

CRD에 대한 Webhook은 보통 다음 두 가지 용도로 사용됩니다:Validation Webhook – 리소스의 생성/수정 요청이 유효한지 검사Mutation Webhook – 리소스를 자동으로 수정(default 값 설정 등) 왜 Webhook Validation을 사용할까?기본적으로 CRD의 유효성 검증은 OpenAPI v3 Schema로 처리할 수 있지만,복잡한 조건 (예: 필드 간 종속성, 외부 리소스 검사 등)은 Webhook을 통해 동적으로 처리할 수 있습니다.예를 들어:spec.replicas는 1 이상이어야 한다spec.env 값이 prod일 때는 spec.logging이 필수다특정 필드가 UUID 형식인지 검사이런 복잡한 로직은 오직 Validation Webhook으로만 가능합니다. ..

Kubernetes는 분산 환경에서 여러 클라이언트가 동시에 리소스를 수정할 수 있기 때문에, 충돌 관리가 중요합니다. 이를 해결하기 위해 Kubernetes는 Optimistic Concurrency Control(OCC) 방식을 사용합니다.이 글에서는 CRD(Custom Resource Definition) 리소스에서도 OCC를 어떻게 구현하고 사용하는지, 그리고 실제 Go 코드로 어떻게 처리하는지 알아보겠습니다. OCC란?OCC(낙관적 동시성 제어)는 "충돌이 자주 일어나지 않을 것"이라고 가정하고,리소스를 수정할 때마다 현재 버전(resourceVersion)을 확인하여 충돌 여부를 판단하는 방식입니다.최신 버전일 경우 → 정상 업데이트버전 불일치 시 → 409 Conflict 오류 발생 → 재시..