요약하자면.
SRE 팀은 다음 사항에 중점을 둡니다.
- 미션 레인 개발자를 위한 표준화된 헬름 차트 만들기
- 자동화된 분산 추적 관리
- 초당 500,000개의 로그와 추적을 처리하는 관찰 가능한 기술 스택 만들기
- 사용 장벽을 크게 낮추기 위해 애플리케이션 자동화를 위한 Canary 릴리스를 처리합니다.
- 종속성 자동 업데이트 관리
- 유용한 서비스 카탈로그 만들기
SRE 팀은 또한 자매 팀 및 개발보안운영(DSO)과 협력하여 개발자가 아이디어에서 프로덕션에 이르는 프로세스를 완료하기 위해 PR을 세 번만 제출하면 되는 거의 완벽한 셀프 서비스 개발 플랫폼을 만들었습니다(그리고 이름 지정에 대한 약간의 논의도 필요했습니다).
성공적인 SRE 팀을 구축하는 데 참여한 것은 이번이 두 번째인데, 성공적인 SRE 조직을 구축하는 데 도움이 될 수 있는 네 가지 교훈을 소개합니다.
- 개발자 교육 전문
- 올바른 추상화에 집중
- 셀프 서비스에 집중
- 자동화로 업무 대체하기
개발자 교육 전문
특정 기술이나 플랫폼에 하루 종일 몰두하다 보면 그 분야의 전문가가 됩니다. 그리고 특정 기술 분야의 전문가가 되면 플랫폼의 특징, 문제, 엣지 케이스에 익숙해집니다. 또한, 곧 고급 사용자 문제에 직면하게 되고 가능한 한 많은 사용자 지정 작업을 수행하고자 하는 욕구가 생깁니다. 사용 가능한 기능, 시스템 작동 방식/연결 방식을 정확히 파악하고, 작동 방식에 대한 좋은 정신적 모델을 가지고 있어야 합니다.
하지만 SRE의 고객은 개발 서비스를 통해 비즈니스 가치를 제공하는 데 집중하는 개발자입니다. 개발팀은 엔지니어링 성숙도가 각기 다르기 때문에 직접적인 비즈니스 요구 사항보다는 안정성, 툴링 등에 집중할 수 있는 역량을 갖추고 있습니다. 개발팀은 보안, 안정성 또는 확장성을 손상시키지 않으면서 가능한 한 빠르고 쉽게 가치를 제공할 수 있어야 합니다. 그렇기 때문에 개발자 교육이 중요합니다.
미션 레인에는 약 20개의 제품 팀과 약 250개의 마이크로서비스를 지원하는 중앙 집중식 SRE 팀이 있습니다. 매 분기마다 2~4개의 제품 팀을 선정하여 한 달 동안 SRE가 해당 팀에 배치됩니다. 한 달 동안 SRE는 목표에 집중하기 위해 프로젝트 상태 체크리스트에 집중해야 하지만, 주된 목표는 개발자가 플랫폼과 상호 작용하는 방법을 교육하고, 개발자가 직면하는 모든 사소한 문제에 대해 배우고, 낚시하는 방법을 가르쳐서 작업을 더 쉽게 만드는 데 도움을 주는 것입니다. 다음은 SRE가 도움을 줄 수 있는 몇 가지 문제입니다.
- 일부 중요하지 않은 특정 엔드포인트에서 작동하지 않는 추적 수정
- Flagger 이스티오를 사용하여 카나리아 버전이 어떻게 작동하는지 개발자의 이해 돕기
- 개발자가 대시보드를 추가하고, 경고를 만들고, 지저분한 알람을 조정하거나 억제할 수 있도록 지원합니다.
- 개발자가 개발 클러스터에 로컬로 배포할 수 있도록 지원
이 프로젝트는 SRE 팀을 구성한 지 1년 후에 시작된 매우 성공적인 프로젝트였습니다. 개발자들은 SRE와의 짧고 집중적인 상호 작용을 즐겼습니다. SRE는 제품 팀과의 연결 고리를 구축하고, 개발자들이 직면한 다양한 문제나 우려 사항을 보여주었으며, 엔지니어링 조직에 대한 전반적인 지식을 쌓는 데 도움을 주었습니다.
올바른 추상화에 집중
데브옵스 문화 혁신은 주로 '왼쪽으로 이동'에 초점을 맞춰 왔습니다. 조직이 성숙해짐에 따라 아래로 이동해야 한다는 것을 깨달았습니다. 팀이 더 적은 자원으로 더 많은 일을 할 수 있도록 올바른 추상화를 작성해야 합니다.
미션 레인 초창기에는 Kubernetes 클러스터에 추상화가 없었습니다. 그 당시에는 ArgoCD, GKE 및 CNRM 기반으로 하는 매우 강력한 GitOps 파이프라인이 있었습니다. 그러나 개발자는 수동으로 k8s 매니페스트를 작성한 다음 ArgoCD를 통해 k8s 클러스터에 적용해야 했습니다. 이로 인해 중복되는 YAML이 많이 발생하지만, 진짜 문제는 대규모 업데이트를 적용해야 할 때입니다. 모든 배포에 대해 보안 컨텍스트를 설정해야 하나요? 새로운 인그레스가 필요하신가요? 환경 변수나 주석을 적용하고 싶으신가요? 수백 개의 yaml 파일을 편집해야 하는 경우. 이 중 일부는 프로그래밍 언어를 통해 자동화할 수 있지만 커뮤니티에서 이 문제를 해결했습니다.
SRE 팀이 구성된 지 약 9개월 후, ML 서비스 헬름 차트 1.0.0 버전이 출시되었습니다. 이 차트는 결국 Mission Lane의 서비스 중 95%에서 사용되었고 수백 개의 버전이 등장했습니다. 이 차트를 통해 팀은 클러스터에서 안정적이고 안전하게 시작하고 실행할 수 있었으며, 극한의 사용자 지정이 가능하고, 대부분의 경우 k8s API 사양을 따르고, 모든 설정을 완전히 재정의할 수 있는 동시에 동일한 기본값을 제공하여 애플리케이션 상태와 관행을 개선할 수 있었습니다.
이 헬름 차트를 사용하면 조직 전체의 문제를 해결할 수 있습니다. 설정을 추가해야 하는 것이 발견되면 엄격한 "사용자 공간 침해 금지 " 원칙에 따라 광범위한 테스트와 비규격 API 변경에 대한 자동 관리를 통해 전체 조직을 위해 업데이트된 구성이 포함된 새 버전의 헬름 차트를 배포할 수 있습니다.
왼쪽이 아닌 아래로 내려가는 패러다임은 도구, 추상적인 표현, 개발자에 대해 이야기하는 방식에 나타납니다. 개발자를 해당 분야의 전문가로 생각하고, 자신이 해당 분야의 전문가가 아닐 수도 있음을 인정하며, 개발자가 스스로 성공할 수 있도록 도울 수 있는 방법을 찾아보세요.
셀프 서비스에 집중
SRE 팀은 엔지니어링 조직을 위한 포스 멀티플라이어가 될 수 있어야 합니다. 모든 제품 팀에 SRE를 고용해야 한다면 실패를 의미할 수 있습니다. 개발자가 스스로 결정을 내리고 문제가 발생했을 때만 도움을 요청할 수 있도록 하는 데 초점을 맞추면 포스 멀티플라이어가 될 수 있습니다. Amazon과 Google은 서비스를 켜고 싶을 때마다 기술 지원팀과 소통하거나 새 제품을 출시할 때 엔지니어와 소통하도록 강요하지 않습니다. 대신 API와 UI를 통해 셀프 서비스를 활성화하고 문제를 해결할 수 없을 때만 기술 지원팀과 대화합니다. 잘 문서화되고 직관적인 프로세스/API가 있다면 수많은 개발자가 일일이 소통할 필요 없이 도움을 받을 수 있습니다.
이러한 철학은 SRE 팀이 처음 만들어질 때부터 미션 레인에 존재했습니다. SRE가 만들어질 당시 기본 GKE 클러스터와 자동화 도구는 훌륭했으며, 이는 CPE 팀의 공로입니다. 하지만 셀프 서비스에 집중함으로써 개발자가 일주일에 한 번씩 와서 질문할 수 있는 근무 시간 모델을 구현할 수 있었고, 그 외에는 개발자가 질문하고 답변을 얻을 수 있는 슬랙 지원 채널을 확보할 수 있었습니다.
개발자가 클러스터 및 서비스와 안전하게 상호작용할 수 있는 도구를 사용하면 옵션을 제한하지 않고도 프로세스가 잘못 구성되지 않도록 할 수 있습니다. 문제가 발생하면 프로세스나 도구를 평가하여 개선할 수 있는 부분을 찾아보세요. 개발자를 믿으세요. 개발자는 사용자와 마찬가지로 일부러 잘못하는 경우는 거의 없으며, 문제가 발생했을 때 단지 xy 될 수 있습니다.
같은 위치에서 빠른 피드백을 제공하는 도구를 사용하세요. CPE는 초기에 PR을 모든 피드백의 중심으로 삼기로 결정했습니다. 메인라인 개발 모델을 사용하고 모든 도구가 PR과 상호 작용하도록 함으로써 일관된 멘탈 모델이 있었고 팀은 코드 소유자와 리뷰만을 통해 셀프 서비스를 제공할 수 있었습니다. 플랫폼 팀에서 도입한 거의 모든 도구는 PR을 인터페이스 메커니즘으로 사용하여 개발자의 속도와 피드백을 크게 향상시켰습니다.
자동화로 업무 대체하기
것은 SRE의 핵심 요소이며, 이 업무의 근간이자 철학을 뒷받침합니다. 같은 작업을 반복해서 수행하거나, 매번 같은 문제를 수정하거나, 심지어 것은 노력의 중복을 충분히 제거하지 못하고 있음을 보여줍니다. 기계가 승인을 제공해서는 안 되지만, 그 외의 거의 모든 작업은 자동화할 수 있습니다. 특정 PR을 열고, 리포지토리와 파일을 템플릿으로 만들고, 특정 오류에 대응하는 작업도 자동화할 수 있습니다.
성공적인 SRE 팀을 구축하는 것은 어렵습니다. 올바른 문제에 집중하는 방법을 알고 뛰어난 의사소통 능력을 갖춘 훌륭한 엔지니어가 필요합니다. 하지만 결국에는 그만한 가치가 있으며, SRE 팀은 조직 전체의 역량을 배가시켜 돌발 상황을 줄이고 개발자 경험을 개선하며 코드 품질을 높이는 데 도움이 될 것입니다. 기억하세요.
- 개발자 교육에 집중하세요. 개발자의 지식과 기대치를 높이면 큰 도움이 될 것입니다.
- 올바른 추상화에 집중하세요. 왼쪽이 아닌 아래로 이동하세요. 고객에게 중요하지 않은 것은 추상화하세요.
- 셀프 서비스에 집중하세요. 개발자는 표준 작업을 위해 SRE와 대화할 필요 없이 완전히 자율적으로 플랫폼과 상호 작용할 수 있어야 합니다.
- 자동화를 통해 수고를 덜어보세요. 현재에 안주하지 말고 계속 노력하세요. 새롭고 흥미로운 일을 할 수 있도록 자동화를 계속 개선해 나가세요!
안녕하세요, 저는 Motorola에서 R&D를 담당했고 지금은 Mavenir에서 기술 업무를 수행하고 있습니다. 저는 항상 통신, 네트워크, 백엔드 아키텍처, 클라우드 네이티브, DevOps, CICD, 블록 체인, AI 및 기타 기술에 관심이 있으며 평소 독서와 생각을 좋아하고 지속적인 학습과 평생 성장을 믿기 때문에 함께 소통하고 배우는 것을 환영합니다. 처음에 기사를 쉽게 볼 수 있도록 공개 번호 "DeepNoMind"에주의를 기울이고 별표를 설정하고 하나의 키 트리플을 할 수 있다면 더 많은 지원과 동기를 부여하고 계속 글을 쓰도록 동기를 부여하고 우리는 함께 성장하고 발전 할 것입니다!
이 기사는 mdnice 멀티플랫폼에 의해 게시되었습니다.
