SRE 3

[활용사례] DevOps 엔지니어가 주목하는 MCP 생태계와 kt cloud PLATFORM 적용기

kt cloud Platform엔지니어링팀 이지은 님 📝 요약 SUMMARY 이 글에서는 MCP를 활용해 Kubernetes·GitHub·ArgoCD·Slack 등 DevOps 시스템을 AI와 연결하고, kt cloud PLATFORM 환경에 적용하기 위한 구조와 보안 원칙을 다룹니다.운영 데이터 연계와 트러블슈팅 자동화를 위한 MCP 활용 방향을 정리합니다.#MCP #DevOps #Kubernetes #GitHubActions #ArgoCD1. AI와 인프라의 결합: 과거의 한계와 MCP의 패러다임 전환기존의 대규모 언어 모델(LLM)은 뛰어난 추론 능력을 갖추었음에도 불구하고 ‘인프라와의 물리적 격리’라는 명확한 한계를 지니고 있었습니다.과거 (Isolating Chatbot): 엔지니어가 터..

[구축사례] kt cloud PLATFORM Observability Alert 플랫폼 구축하기

Tech-Frontier.md kt cloud$ whoami --team❯ kt cloud Data플랫폼팀 유지연 님 📋 요약TL;DR이 글에서는 KCP 클라우드 환경에서 Observability Alert 플랫폼을 구축하고조직별 Alert 격리, 통합관제 연동, 이력 관리 체계를 설계한 과정을 다룹니다.안정적인 클라우드 운영을 위해 Alert를 단순 알림이 아닌 운영 정책으로 관리해야 하는 이유를 정리합니다.#Observability #Alert플랫폼 #LGTM스택 #통합관제 #멀티테넌트1. 왜 Observability Alert 플랫폼을 직접 만들었나 — 문제의 출발점클라우드 플랫폼을 운영하다 보면 자연스럽게 모니터링과 알림 체계가 고도화됩니다. 가상 서버, 네트워크, 컨테이너 플랫폼 각각을 감시하..

[기술리포트] 클라우드 네이티브 3편 : 장애 도메인과 격리 설계 - 가용성·복원력 강화 전략

[ kt cloud Cloud컨설팅팀 심대섭 님 ] 📋 요약 이 글에서는 클라우드 네이티브 환경에서 멀티 리전 구성 시 장애 도메인과 격리 설계를 통해가용성과 복원력을 강화하는 아키텍처 전략을 다룹니다.리전 분리만으로는 장애 전파를 막을 수 없으며,공유 지점 최소화와 독립 운영 단위 설계가 실제 장애 국지화의 핵심임을 정리합니다. #클라우드네이티브 #장애도메인 #멀티리전 #고가용성 #DR #share-nothing멀티 리전을 썼는데도 서비스가 같이 멈추는 구조적 원인클라우드 네이티브 가용성을 이야기할 때 가장 흔한 기대는 “리전을 두 개 이상 쓰면 고가용성이 된다”입니다. 그런데 운영 현장에서는 리전과 가용 영역(AZ)을 분리했는데도 장애가 전면 확산되는 케이스가 반복됩니다. 멀티 리전..