DevOps?

요거 하나 만큼은 꼭 외우자!

1.소프트웨어 개발 방법론 중 하나.

 

So, 앱,웹 같은 서비스를 빠른 속도로=애자일하게=기민하게 제공할 수 있도록 하는 모든 것.

보통은 프레임워크와 같은 도구 그 자체. 넓게는 조직문화까지도 그 의미가 확대되고 있다.

 

Development + Operation

개발과 운영의 앞글자만 쏙쏙 따온것인데

 

DevOps 엔지니어 직군은 개발과 운영을 둘다 한다는 의미일까?

no no no-.

앱이나 웹 서비스의 개발과 운영의 과정을 최적화를 해서 보다 빠르게 출시하는데에 초점을 두고 있다.

 

git branch를 만들어 커밋하고 merge요청> 코드 검토 > merge > 베타브랜치에서 테스트 > 릴리즈 > 버그발견 > 핫픽스

개발부터 운영까지 아울러 모든 단계에서 생기는 요청과 처리를 빠르고 가볍고 팬시하게 처리하는 일인 것이다.

물론 규모가 작은회사는 개발팀은 개발을 애자일하게 운영팀은 운영을 애자일하게 각자 최적화를 하고 있지만 결국 개발운영팀 단에서 애자일하게 최적화하는 것에 차이가 있다.

 

DevOps가 없는 경우

Operation 팀과 개발팀이 서로 분리되어 있으며, 의사소통이나 협업에도 어려움을 겪고 있다.

한 팀의 작업방식은 리소스파일들을 git에 커밋하고나서 총 4개의 서버에 FTP로 수동 업로드를 하는 방식을 채택하고 있다. 그런데, CSS 한줄 수정해도 이 모든 과정을 되풀이 해야 해서 굉장히 비효율적이라고 느꼈는데, 이것을 개선해보고자 자동 FTP 업로드 라이브러리를 찾아서 적용해보려고 하던 찰나에, 총4대의 서버중 2대의 서버는 터미널 로그인이 가능하지만 나머지 2대의 서버는 그렇지 못했다.

이걸 가능하게 하려면 직접 그 팀의 높은 권한을 가진분께 수정 요청을 해야하는데 신입이 그렇게 요청하기가 굉장히 부담스럽고 요청을 한다고해서 받아들여질것 같지 않은 조직분위기.

만약에 하나의 팀에서 운영조직과 개발조직이 같이 묶여있었다면 이런 요청을 하기가 덜 부담스러웠을것이고, 좀 더 다양한 시도들을 하는것이 가능했을것이라고 생각한다..

우리 회사의 발전과 함께 개인의 성장을 위해서 이런 개발 문화가 좀 더 잘 정착되었으면 좋겠다.

 

 

Line DevOps엔지니어의 사례

 

https://engineering.linecorp.com/ko/blog/build-a-continuous-cicd-environment-based-on-data/

데이터 기반으로 지속적인 CI/CD 개선 환경 만들기

 

개발은 웹 포트폴리오 사이트를 만드는 것. 또는 어떤 서비스의 기능을 개발하고 구현하는 것으로 이미 친숙한 개념인데 운영은 무슨 일이지? 모호해서 뱅크샐러드 운영직의 공고를 유심히 읽어보았다.

---

사업개발팀 Business Operation 인턴십 (사업개발팀)

대외활동 공모전 대학생 인턴 채용 | 링커리어

---

 

이를보니, 웹 포트폴리오 사이트의 오류나 응답속도 개선과 같은 개선사항을 발견하기, 다른 웹 포트폴리오 리서치 및 고도화, 반복되는 업무 최적화, 정량적인 데이터를 관리하고 가공해 커뮤니케이션을 위한 리포트 작성 등이 이에 속하는 것 같다.

git 공부하다가 멀리 온 것 같았지만 실무자의 경험을 토대로 운영적인 요구능력이 무엇인지 협업하게 될 포지션들의 업무를 이번 기회에 확실히 알게 되었다.

 

 

참고해보면 좋을 것들. 

 

 

CI/CD

https://seosh817.tistory.com/104

[CI/CD] CI/CD란? - 지속적 통합(Continuous Integration)/지속적 배포(Continuous Deployment) 기본개념

지금 내 상태는 깃으로 내 레파지토리에 커밋&푸쉬하면 깃허브 도메인 덕분에 따로 배포에 대한 생각을 고민하지 않아서 CI/CD가 왜 필요한건지는 몸소 느껴본적이 없다. 파일질라를 통해 닷홈 도메인을 통해 배포 했을때는 폴더를 매번 드래그앤 드롭을 해줬는데 그 마저도 불편하다고는 느끼지 못했고. 오히려, 3개월마다 무료 호스팅 기간을 연장해줘야되는 불편했다.

 

 하지만, 큰 프로젝트 팀원이 많은 경우 복잡해져 충돌이 생기기 쉽고 기허브 도메인으로 배포를 하진 않아서 많이 번거로워서  CircleCI, Jenkins, Github Actions를 사용한다고 한다.

 

아직은 애자일한 개발과 배포보다는 Html, CSS, JS를 더 공부해야 돼서 여기서 그치고, 다음에 실무를 하다가 필요해 질 때 이 포스팅을 보충하겠다!

 

 

 

 

 

 

 

 

 

 

데브옵스 툴체인

1. 계획 - 목적을 수행하기 앞서 방법이나 절차 등을 미리 생각하여 계획.
2. 코드 - 코드 개발 및 검토, 버전 관리 도구, 코드 병합
3. 빌드 - 지속적 통합(CI) 도구, 빌드 상태
4. 테스트 - 테스트 및 결과가 성능을 결정
5. 패키지 - 애플리케이션 디플로이 이전 단계
6. 릴리스 - 변경사항 관리, 릴리스 승인, 릴리스 자동화
7. 구성 - 인프라스트럭처 구성 및 관리, IaC(Infrastructure as Code) 도구
8. 모니터링 - 애플리케이션 성능 모니터링, 최종 사용자 경험.

DevOps

회사에서 개발을 하다보면 개발만 한다고 되는것이아니다. 프로젝트를 빌드하고 배포하고 테스트하는 운영 업무도 같이 해야 한다. 보통 회사에서는 이 두개의 일을 하는 조직을 나눠서 관리하게 된다. 그런데 하나의 서비스를 두개의 팀에서 관리하다보면 비효율적인 부분들도 많고 서로 의사소통하기에도 좋지 않다.

개발자는 계속해서 새로운것을 도입하고 싶어하지만, Ops들은 안정성을 최우선으로 여긴다. 그래서 등장한것이 DevOps이다. 이 DevOps라는 개념은 소프트웨어 개발 방법론 중 하나이다.

개발자들과 Ops들을 서로 잘 융합시키고 의사소통이 원할하게 하기 위한 개발 방법론이다.

DevOps의 특징들

Cross Functional Team

하나의 팀에 개발 부터 운영까지 모두 할 수 있는 사람들로 채우라는뜻이 아니라, 각 프로세스의(개발 ~ 배포 및 테스트까지) 담당자들을 하나의 팀으로 모으라는 뜻이다. 서비스 기획부터 개발 운영 테스트 배포등 모든 제품 개발 프로세스를 하나의 팀에서 할 수 있도록 해야 한다는것이 Cross Functional Team이다.

Widely Shared Metrics

한마디로, 팀원 모두가 알고있는 하나의 공유된 지표가 필요하다는것이다.

서비스를 개발만 하는게 아니라 서비스가 운영에서 잘 돌아가고 있는지, 사용자의 반응은 어떤지를 측정할 수 있는 기준이 필요하다는것이다. 그리고 이 지표를 기준으로 팀원들이 아 우리 서비스가 이정도로 잘돌아가고있구나, 아니면 아 이부분은 좀 부족하구나라는걸 인지할 수 있도록 해야한다.

Automating repetitive tasks

반복적인 일들은 자동화 하라는것이다. CI/CD를 이용해서 빌드-배포-테스트 프로세스를 자동화 해야한다. 반복작업에 투입되는 시간을 줄여야 좀 더 생산적으로 일할수 있고 좀 더 고도화된 서비스를 만들 여유와 시간을 벌 수 있을것이다. 고급인력들을 데려다 놓고 반복작업에 시간을 쏟게 하는것은 개인적으로나 회사 전체로보나 손해이다. 그리고 자동화 툴을 만드는 과정에서 시스템 전체에 대한 이해가 높아진다. 여러모로 장점이 많다.

Post Mortems

직역하자면 후처리라고 할 수 있다. 장애나 이슈가 있을때 그걸 혼자만 알지 말고 팀원들과 공유를 해야한다. 서비스를 운영만 하다보면 어떤 이슈가 있을때 이 이슈가 얼마나 큰 이슈인지를 파악하지 못할떄가 많다.

Regular Release

짧은 주기의 정기 배포를 통해서 빠르게 서비스의 기능을 개선하고 고객들의 VoC를 반영해 나가야한다.