티스토리 뷰
인프런에서 '입문에서 실무까지: DevOps의 이해 및 Docker Hands-on' 이라는 강의를 듣고 있다.
DevOps가 '개발 + 운영'이라는 뜻만 알고 있을뿐 자세한 내용은 알고 있지 못했는데, 강의를 통해 조금씩 이해하며, 이해한 내용을 정리하려고 한다!
DevOps는 서비스의 개발부터 배포까지의 프로세스의 속도를 높여 사용자에게 조금 더 빠른 서비스를 지원할 수 있도록 조직의 역량을 향상시키는 문화, 방식, 도구의 조합을 의미한다.
하나의 서비스를 '기획, 디자인, 개발, 리뷰, 빌드, 테스트, 배포유무 결정, 배포, 운영'을 하는 과정에서 개발자와 운영자의 업무가 명확하게 나누어졌다면 좋겠지만, 누가 해당 업무를 처리해아할지 애매한 업무들이 있다. 예를들어, 아래와 같은 5가지의 업무이다. (Dev&Ops Specialized Zone)
개발자가 개발할 수 있는 환경은 누가 만드는 것인가?!
서비스 모니터링 (트래픽 모니터링 etc ...) 은 누가하는 것인가?!
로그 분석은 누가하는 것인가?!
GIT과 같은 소스코드를 관리하는 도구는 누가 관리하고, 설치할 것인가?!
테스트, 배포 등의 업무는 누가 수행할 것인가?!
그렇다면, 이 업무들을 누가 수행해야 할까?! 전문가들이 진단, 평가해서 더 개선된 방향으로 개발해서 위 업무들의 역할을 없애야 한다. 그리고 대신에 Dev Ops 엔지니어링 역할이 생겨야 한다. 그렇다고 이 엔지어링 역할이 DevOps는 아니다. DevOps는 역할이 아니고, 문화에 더 가깝다. 그러므로 DevOps 엔지니어링 담당자만 DevOps를 하는 것이 아닌, 모든 구성원들이 해야한다. 단지, 누군가 리딩을 할 사람은 필요할 수 있다.
지금부터는 DevOps의 특징들을 보면서, 지금 내가 일하는 조직은 DevOps에 얼마나 가까운지 한번 적어보려고 한다. 저의 회사는 ... ...
Cross Functional Team
개발부터 운영까지 모두 할 수 있는 개발자로만 구성할 수 있다면야 정말 좋겠지만 ... (그럼 나는 ... 팀에 존재할 수 없다 ...)
팀에서 기획 ~ 운영까지 그리고 영업 등 서비스에 관련된 모든 업무를 수행할 수 있는 조직으로 팀을 구성하라는 것이다.
Widely Shared Metris
팀의 공통 지표, 목표가 존재해야 한다. 공통의 목표는 서비스의 상태를 평가할 수 있는 항목이 된다. 그리고 팀 전체가 목표를 통해 서비스의 상태를 인지하고 개선할 수 있게 도와준다.
Automation repetitive tasks
반복적인 업무를 자동화 해야한다. 서비스를 개발하는 과정에서 항상 반복적으로 수행하는 업무가 무엇이 있을까?! 바로 배포 구리고 테스트이다!
우리는 서비스를 사용자에게 전달하기 위해 항상 배포를 한다. 이런 반복적인 업무를 자동화 하는 것이 필요하다. 그리고 항상 등장하는 단어가 CI, CD 이다.
(다음에 정리 예정) 그리고, 테스트도 마찬가지이다. 테스트도 자동화가 필요하고, 그렇기 때문에 요즘은 TDD를 통해 또는 테스트 코드를 별도로 작성한다.
하지만, 모든 코드에 대해 테스트를 작성할 수 는 없다. 이런말을 할 때, 누군가는 말할 것이다. 그건 '니가 코드를 잘못 짠거다' 라고 ...
그런데 오랜전부터 운영하고 있는, 그리고 계속해서 개발을 덧붙이고 있는, 이러한 레거시 코드에 대해서는 테스트 코드를 작성하는 것이 쉽지 않다.
물론 신규 작성한 코드에 대해서는 작성할 수는 있겠지만 기존 코드에 대해서는 절대 작성할 수 없을 것이다.
테스트 코드를 작성하는 것도 많은 노력과 시간이 소요된다. 그리고 테스트 코드의 중요성을 알고 있는 개발자로만 이루어진 팀이라면, 해당 업무를 수행했을 때, 높은 평가를 할 수 있다. 그러나, 그렇지 않은 팀에서는 기존에 잘 동작하는 코드에 왜? 시간을 낭비하지라고 할 수 있다. 그렇기 때문에 테스트 자동화가 굉장히 중요하고 필요하지만... 쉽지는 않은거 같다.
결과적으로 DevOps에서는 사용자에게 서비스를 조금 더 빠르게 전달해야 하기 때문에 이런 반복적인 업무에 대해 자동화가 필요하다.
Post Mortems
장애가 발생했을 때, 장애에 대한 내용을 팀 전체에 공유가 필요하다. 장애에 대한 손실과 영향도에 충분히 인지를 해야 다음부터는 같은 장애가 발생하지 않도록 대비할 수 있다.
Regular release
짧은 주기의 정기 배포를 통해서 빠르게 서비스의 기능을 개선하고 사용자의 VOC를 반영해야 한다.
결과적으로 내가 일하는 조직은 별5개중 몇개일까?! 매주 금요일 Sharing time 가지고 있는데, 이때 조사를 해봐야겠다!
