주요글: 도커 시작하기
반응형


이 글은 DevOps Handbook 책을 읽고 몇 가지 핵심 실천법을 정리한 것이다. (원서 링크, 번역서 링크)


*주의: 요약 글에 오류/오역이 존재할 수 있고 더 중요한 내용을 누락했을 수도 있으니 애매한 부분은 반드시 원문을 참고하기 바란다.


데브옵스 시작하기

밸류스트림 선택

  • 데브옵스 전환을 시도할 밸류 스트림은 신중히 선택할 것: 성공해야 확대 기회 생김
  • 동조 잘하고 혁신적인 그룹과 시작하기: 보수적인 그룹은 처음부터 설득하지 말고 충분히 성공한 뒤에 해결
밸류 스트림 이해, 팀 구성, 계획
  • 밸류 스트림 맵 작성: 모든 구성원 식별, 빠른 가치 제공을 위협하는 영역 이해
  • 개선할 메트릭을 선택하고 목표와 일정 결정
  • 전용 전환 팀 구성
  • 목표를 합의하고 공유: 측정 가능한 목표, 6개월~2년 사이의 명확한 기한, 어렵지만 달성 가능한 목표, 조직과 고객에 가치 있음, 책임자가 목표에 동의, 목표를 조직 전체 공유
  • 개선 계획은 짧게: 2-3주 안에 측정 가능한 개선이나 이용 가능한 데이터를 만들어야 함, 빠른 개선으로 일상 업무에서 차이를 만들어 내고, 빠른 증명으로 프로젝트를 유지
  • 모두가 작업 상태를 알 수 있도록 최신 상태 공개
조직 구성
  • 시장 지향 팀 구성
  • 밸류 스트림에 관여하는 모두가 고객 목표와 조직 목표 공유
  • 제너럴리스트: 배움을 장려, 호기심/용기/솔직함을 가진 사람 채용
  • 프로젝트가 아닌 서비스와 제품에 투자
  • 콘웨이 법칙에 따라 팀 경계 설계
  • 팀을 작게 유지
운영을 개발 환경에 통합
  • 운영 역량을 개발 팀에 통합: 운영과 개발의 효율과 생산성을 높이고 시장 지향 결과를 더 잘 만들어 낼 수 있도록 함
  • 운영도 개발 활동에 참여: 운영 엔지니어를 서비스 팀에 포함시키거나 운영 담당자를 서비스 팀에 할당해서 제품 관련 작업을 운영 계획에 반영하고 제품 팀에 운영 지식 전파
  • 제품과 관련된 운영 작업을 공유 칸반 보드에 공개: 운영도 밸류 스트림의 일부

흐름(Flow) 개선

배포 파이프라인 기반

  • 필요할 때 개발, 테스트, 제품 환경을 생성할 수 있어야 함: 모든 환경을 만들 수 있는 빌드 장치, 환경 구성에 필요한 것을 체계화/자동화, 이를 통해 일관된 환경 생성 프로세스 구축, 수작업 감소
  • 단일 리포지토리: 환경도 버전 컨트롤로 관리, 빠르게 롤백할 수 있는 방법 제공
  • 반복가능한 환경 구축 시스템으로 인프라도 빠르게 재구축할 수 있게 함
  • 조기에 환경을 코드와 통합하고 배포를 연습해서 릴리즈와 관련된 위험을 줄임
빠르고 신뢰할 수 있는 자동화된 테스트
  • 자동화된 테스트 스위트 작성: 배포 파이프라인으로 커밋한 모든 코드를 자동으로 빌드하고 테스트
  • 자동화된 빌드/테스트 프로세스를 실행하는 전용 환경 구축
  • UAT, 보안 테스트 환경을 셀프 서비스로 생성 가능
  • 테스트 커버리지를 이용해서 테스트 작성 유도
  • 성능 테스트, 비기능 요구사항 테스트를 배포 파이프라인에 통합
  • 배포 파이프라인이 깨지면 작업을 멈추고 즉시 해결: 문제 해결에 조기에 발견할 수 있는 테스트 케이스를 추가
지속적 통합(CI)
  • 작은 배치로 개발
  • 트렁크에 자주 커밋, 일일 커밋
저위험 출시
  • 배포 프로세스 단순화, 자동화: 소요 시간이 긴 단계를 제거하기 위해 아키텍처 개선, 소요 시간과 이관 횟수를 줄이기 위한 노력
  • 모든 환경에 대해 동일한 방법으로 배포
  • 자동화된 배포 셀프 서비스로 개발자가 직접 배포: 자동화된 테스트, 자동화된 배포, 코드 리뷰 등 위험 감소 장치 필요
  • CI로 배포 가능 패키지 생성, 제품 환경 준비 조회, 특정 버전 패키지를 배포할 수 있는 버튼, 감사 기록, 스모크 테스트 실행, 배포 성공 여부를 빠르게 피드백을 제공하는 배포 자동화
  • 배포와 릴리즈 분리: 블루-그린 배포, 카나리아 릴리즈, 기능 토글, 다크 론치 등으로 릴리즈 위험 감소
  • CD(Delivery): 트렁크에서 작은 크기로 작업 또는 짧은 피처 브랜치, 트렁크는 항상 릴리즈 가능 상태로 유지, 업무 시간에 필요할 때 푸시 버튼으로 릴리즈 가능
  • CD(Deployment): Delivery + 정기적으로 빌드를 제품에 배포


피드백

문제 확인과 해결 위한 텔레메트리

  • 중앙 집중화된 텔레메트리 인프라
  • 어플리케이션 메트릭을 충분하게 생성
  • 텔레메트리를 사용해서 문제 해결에 과학적으로 접근
  • 어플리케이션 메트릭, 비즈니스 메트릭, 인프라 메트릭을 함께 표시
  • 유지보수, 백업, 배포 등 배포/운영 활동도 메트릭에 표시

예측을 더 잘하고 목표를 달성하기 위한 텔레메트리 분석

  • 평균, 표준 편차, 비정상 탐지 기법(데이터 스무딩, 콜모고로프-스마르노프 검정 등)을 사용해서 잠재적인 문제 발견
  • 장애를 예측할 수 있는 메트릭을 찾아 모니터링 시스템에 추가
안전한 배포를 위한 피드백
  • 기능이 정상임을 확인할 수 있는 충분한 텔레메트리
  • 배포와 변경 이벤트를 메트릭 그래프에 함께 표시: 배포 파이프라인에서 놓친 제품 에러를 텔레메트리 이용해서 발견 가능
  • 모두가 전체 밸류 스트림의 건강 상태를 책임지는 문화
  • 론치 가이드, 론치 요구사항: 모든 개발이 전체 조직의 누적된 경험을 활용
가설 검증 통합
  • 목표를 달성했는지 검증할 수 있는 실험을 실시
  • A/B 테스트를 프로세스에 통합
리뷰와 조율 프로세스
  • 결합도를 낮춰 소통과 조율 필요성을 감소: 위험 완화 위해 변경을 공지하고 충돌 발견, 고위험 영역의 변경은 기술적 조치
  • 변경 승인 프로세스를 리뷰로 대체: 짝 프로그래밍, 코드 리뷰, 작은 배치 크기로 원활한 리뷰
  • 긴 변경 승인 프로세스 제거

지속적 배움과 실험

일상 업무에서의 배움
  • 저스트 컬처: 배움 관점에서 실수와 에러 접근. 휴먼 에러는 주어진 도구의 피할 수 없는 설계 문제에서 기인함, 탓하지 않느 사후 분석 미팅
  • 사후 미팅 결과를 전사에 공유해 조직이 배울 수 있도록 함
  • 혁신을 위한 위험 감수 문화: 리더의 노력 필요
  • 회복성 엔지니어링으로 회복성 향상
로컬 발견을 조직 전체의 개선으로
  • 업무 프로세스에 챗룸을 활용해서 지식 전파를 빠르게 함
  • 소프트웨어 표준 프로세스를 자동화: 문서나 프로세스를 실행 가능한 형태로 변환해서 리포지토리에 추가
  • 비기능 요구사항을 체계화
  • 재사용가능한 운영 유저 스토리를 개발에 구축: 반복되는 IT 운영 작업을 개발 작업에 함께 표시
  • 조직 목표 달성 위한 기술 선택: 운영이 지원하는 기술 목록 지정
배움, 개선 위한 시간 확보
  • 기술 부채를 감소하기 위한 활동을 일정을 잡아 진행
  • 가르치고 배우는 문화: 내부 세미나, 코드 리뷰, 컨퍼런스, 내부 컨설팅/코칭

보안, 규제, 변경 관리

보안

  • 보안을 개발 이터레이션 시연에 통합: 인포섹을 초기부터 참여시킴
  • 보안도 결함 추적과 사후 작업에 통합
  • 공유 리포지토리, 공유 서비스에 보안 예방 수단 통합: 보안 관련 라이브러리나 서비스에 대한 교육 제공, 안전한 빌드 이미지나 쿡북 제작
  • 배포 파이프라인에 보안 테스트 통합
  • SW 공급 체인 보안 검토
  • 환경에 대한 보안 관련 모니터링 추가
  • 보안 관련 텔레메트리 추가
규제, 변경 관리
  • 보안/규제를 변경 승인 프로세스에 통합
  • 효과적인 변경 관리 정책 구축
    • 표준 변경: 저위험 변경으로 자동 승인, 사전 승인 가능
    • 일반 변경: 리뷰나 승인이 필요한 위험한 변경
    • 긴급 변경: 긴급한 고위험 변경으로 즉시 반영
  • 저위험 변경을 표준 변경으로 재분류
  • 일반 변경을 표준으로 바꾸는 노력 필요
  • 감사 조직을 위한 문서와 근거 자료 생성: 텔레메트리 활용


+ Recent posts