데브옵스 스터디 - 1~2장

소개

• 악순환의 3단계

  • 1단계: IT 운영
    복잡하고 문서화 안된 애플리케이션, 인프라로 기술 부채 증대
  • 2단계: 고객 보상
    고객 유치, 관리 등 여유를 벗어난 약속을 하게 됨.
  • 3단계: 느려지는 개발 & 배포
    촉박한 일정에 의해 퀄리티는 떨어지고 실패율이 올라가 모두의 사기가 저하된다.

• 데브옵스 윤리학

  더 나은 방법이 존재한다.

  의견: 올바른 방법으로 더 작은 단위로, 시각화하여 빠르게 치고 나가자?

1부

데브 옵스의 가치

• 흐름 을 만들어 작업을 가속화한다.
• 작업에 대한 명확한 피드백
• 위험 부담을 감수하며 높은 신뢰를 바탕으로 한 지속적인 학습 및 실험

1장

배포 리드타임에 집중

• 배포 임에도 기능의 설계/개발을 포함 한다는 것을 알게 됨.
• 리드 타임을 줄이기 위해 서로 의존하는 두 가지 작업이 병행되어야 한다는 점이 어렵게 느껴짐.
  1. 테스트 및 운영 => 테스트는 QA? 개발자 자체 테스트?
  2. 디자인 및 개발
     개발자 기준이라면 이는 TDD 와 유사한 부분이 있는지 궁금함.
     TDD -> 테스트로 명세 작성 => 개발하면서 테스트 통과시키도록 병행함.

데브 옵스를 뒷받침하는 세 가지 원칙

• 두 번째 방법 - 빠르고 지속적인 피드백
  • 운영 배포 전 발견되지 않았다면 운영 과정에서도 발견되지 않을수도 있는건 아닌지?
  • 치명적인 오류가 발생하기 훨씬 전에 문제를 찾는게 보편적인 것인지 궁금함.

2장

흐름의 시각화

• 칸반 보드, 스프린트 보드 등을 활용해 이슈가 배포되기 까지의 과정을 시각화
• 보다 직관적이고 효율적인 운영이 가능하다고 함.
• 두레이 칸반 보드 를 활용해 볼 수 있을지?

진행 중 작업(WIP) 제한하기

• 팀의 맨먼스를 고려하여 총량을 제한
• 작업을 온전히 처리하지만 긴급 건에 대한 대처가 느릴 수 있음.
• 이상적이지만 현실성은 있는지..?

배치 작업의 크기 줄이기

• 작업의 단위를 줄여 최종적으로 배포를 소규모로 진행되도록 함.
• 상시 배포가 익숙해졌을 때, 적용하면 좋을거 같다고 생각함.