데브옵스 (DevOps)

흐름(flow),지속적 피드백, 끊임없는 학습

저비용 고품질 목표

Small Release

Docker, 리액티브 시스템(스트리밍,실시간,경량)

 

 

 

 

 

 

 

 

[개념] 개발자와 운영자간 사이의 의사소통, 협업, 융합통해 서비서를 독립적 개발,운영 협업체계 및 개발문화

[특징] 서비스 지표공유, 반복작업 자덩화, 장애이슈 공유, 정기릴리즈

 

[개발사이클] Need 분석, 사용자 스토리, 범위,우선순위정의, 프로젝트 연관성 관리, 솔루션 평가/도입, SDLC, 실사용자 테스트, 서버배포, 보안/컴플라이언스관리, 서비스 운영 모니터링

 

[구현] 품질 - 자동화된 테스트, 프로세스 내재화

프로세스 - small release, continous integration , 사이클타임 축소, 완료시점 범위확장, CD, 릴리즈/배포분리

도구 - application 릴리즈자동화, provisioning

시스템 - MSA, 리엑티브 시스템(내부로직, 데이터플로우 관리,이벤트)

 

[필요역량] 코딩, 오픈마인드, 프로세스 재정의, 오픈소스 이해, 자동화 툴 이해, 비즈니스 이해

[정착조건] 품질관리, 빠른 개발배포, 업무프로세스 역할조율

[문제점] 개발자 일정관리, FP/LOC로 측정 어려움

테스트 부족, 보안문제발생

[성공운영조건]

1)릴리즈 낮은 실패율

2)짧은 개발배포주기

3) 빠른 복구평균시간

 

[고려사항]

1)개발/운영 통합문화 이해

2)접근방법개선

3)적합한 도구선택

4)코드보안

 

• 지속적 계획은 팀에서 소프트웨어 배포와 관련된 계획을 계속 평가하고 수정하는 전략
• 지속적 계획의 장점:
  • 계획을 자주 재평가하고 새로운 인사이트에 기반해 계획을 업데이트할 때, 소프트웨어 계획은 더 애자일해지고, 능동적일 수 있음
  • 지속적 계획을 실행하면 소프트웨어 배포 운영에서 새로운 문제에 미리 대응할 수 있음
  • 새로운 기회도 가능한 빨리 확인하고, 조치를 취할 수 있음
  • 지속적 계획은 DevOps 엔지니어, QA 팀, 소프트웨어 배포 프로세스의 다른 이해관계자가 개발 운영 상태를 서로 확인할 기회를 더 많이 제공함
    • 이를 자주 확인하면 협업을 촉진하고, 새로운 아이디어를 일상적으로 개발하는 기회도 만들 수 있음
• 지속적 계획의 단점:
  • 소프트웨어 배포 속도를 늦출 수 있음
  • 지속적인 논의와 업데이트는 팀이 실제 개발 업무에 집중하는 걸 어렵게 할 수 있음
  • 잦은 업데이트는 DevOps 엔지니어가 작업하는 코드 상당수를 무용하게 만들 수 있음
    • 만약 진행 중인 기능을 포기하기로 갑자기 결정하면, 배포되지 않을 뭔가를 열심히 작업한 개발자는 실망할 수 있음

지속적인 배포  CD(Continuous Deployment)

 

자동빌드, 자동테스트, 점증적 적용

Time to Market, 위험제거, 주도적출시

애자일 친화적

Git, Ant, Maven, Junit, Emm, PMD

DevOps, SW Visualization, Docker, PaaS

[개념] CD(Continuous Delivery)에서 진보된 상태.

모든 인수 시험(Acceptance Test)가 자동화가 되는 수준

[핵심요소] 코드이상고려, 자동화, 가시화수준향상, 모든변화추적, 통합저장소

 

 

데브옵스는 누구를 위한 것인가

데브옵스에 직접적인 영향을 받는 사람들은 다음과 같다.

- 소프트웨어 개발자 : 소프트웨어를 만들거나 조작하거나 고치는 사람

- IT 관리 운영자 : 시스템이 항상 가동될 수 있도록 유지하는 사람

- 품질 관리 담당자 : 사용자보다 먼저 제품/서비스 내 문제를 발견해야 하는 사람

 

데브옵스와 이 세 부류는 어떤 관계에 있는 걸까? 먼저 전통의 체제 아래서 이 세 부류는 각기 독자적으로 주어진 임무를 완수해냈다는 걸 기억해야 한다. 소프트웨어 만드는 사람 따로, 시스템을 관리하는 사람 따로, 품질 관리하는 사람이 따로였다는 것이다. 데브옵스는 개발자가 보다 혁신적인 걸 만들어내도록 하고, IT 팀이 원하는 안정성을 보장하면서, 품질 관리자가 오류를 계속해서 찾아낼 수 있도록 하는 역할을 한다. 즉 기존에 따로따로이던 걸 하나로 합쳐놓는 것이 데브옵스의 목적이라는 것이다.

 

그러나 이것이 말처럼 쉽지가 않다. 자기가 애써 만들어 놓은 ‘혁신성 높은’ 제품에서 결함을 발견해내는 사람이 고와 보이지 않고, 안정성을 보장해야만 하는 IT 관리자는 혁신이랍시고 새로운 걸 시도하는 개발자가 마뜩잖게 보일 수 있기 때문이다. 실제로 이 셋은 보통의 기업 환경에서 그리 친하지 않다(인간적으로는 친할 수 있지만). 데브옵스가 문화의 변화와 관련이 있다는 건 바로 이 지점 때문이다. 함께 일 하는 법을 새롭게 모두가 익혀야 한다.

 

데브옵스의 문화 확장하기

예리한 독자라면 눈치 챘겠지만, 사실 데브옵스가 저 세 부류에만 국한된 것이라면 ‘기업 문화’라는 거창한 개념까지 언급하지 않아도 된다. 데브옵스의 영향을 받는 사람은 훨씬 더 많다. 조직 환경에 따라 다를 수 있지만 고객 지원 센터 부서, 제품 관리 부서, 임원진들까지도 데브옵스와 연결되어 있다고 볼 수 있다.

 

먼저 고객 지원 센터 관련자들이 데브옵스에 포함되어야 하는 이유는 간단하다. 새로운 기능이나 오류에 대한 항의 전화가 왔을 때 깜짝 놀라 허둥대지 않게 하기 위해서다. 사업 진행 상 제품이나 서비스에 여러 변화를 시도했는데, 이걸 고객 관리 팀에서는 전혀 모르고 있어 상담이 엉망진창이 되는 경우는 셀 수 없이 많다. 개발과 오류 수정의 모든 과정에 고객 지원 담당자들이 참여하면, 이런 상황을 미연에 방지할 수 있다. 이는 제품 관리 부서 사람들도 해당되는 얘기다. 그러나 아무래도 개발에 직접적인 관여를 하지 않는 사람들이다보니, 이 경우에 요구되는 건 ‘같이 일하는 방법’을 익히게 하는 것보다 ‘소통 문화’의 변화라고 볼 수 있다.

 

임원진들은 어떨까? 기존의, ‘위에서 아래로’ 결정사항들이 전달되고 이행되는 방식에는 그 나름의 가치가 있다. 임원진들은 이를 잘 이해하고 있는 사람들이다. 데브옵스는 이와 정확히 대치되는 작업 방식으로, 임원진들이 적응하기 쉽지 않을 수 있다. 그러나 회사의 모든 운영 방식을 데브옵스처럼 바꾸라는 건 아니다. 다만 회사 내 데브옵스가 도입되었다면, 분명 일정 부분에서는 전통에 위배되는 일들이 일어나고 있다는 건데, 이에 대한 이해 없이 ‘위에서 아래로’ 방식만 고집한다면 임원진이라도 도태되기 쉽다는 것이다. 즉, 내가 관리하는 조직 내에서 어떤 일들이 일어나고 있는지 정확히 파악하라는 의미에서 임원진들도 데브옵스에 참여해야 한다.

 

지속적인 문화적 향상

그렇다면 데브옵스 도입 전이든 후든, 정확히 어떤 문화의 면모를 바꿔야 한다는 것일까? 몇 가지를 선정해보았다. 하지만 이들 모두 ‘한 번에’ 되는 것이 아님을 기억하는 것이 중요하다. 말 그대로 ‘문화 개혁’이고, 그러므로 사람의 변화를 뜻한다. 사람은 좀처럼 바뀌지 않는다는 걸 기억하고 조급해하지 말자.

 

실제 사용자 피드백 받기 : 굉장히 의외의 면일 수도 있는데 많은 기업들이 실제 고객이 누군지도 모르거나, 그들의 의견을 전혀 듣지 않고 사업을 진행한다. 진짜다. 나 자신도 이런 회사들을 수없이 봐왔고, 심지어 그런 곳들에서 근무하기도 했었다. 돈만 벌면 된다고들 생각하지만, 사실 내가 만든 제품으로 인해 누군가 긍정적인 영향을 받는다는 걸 보는 것만큼 동기부여가 되는 일도 없다. 왜 직원들에게 이런 기회를 제공하지 않는지 모르겠다. 쓴 소리 듣기 싫어서? 그 쓴 소리가 약이 된다는 것도 이용할 필요가 있다.

 

팀 빌딩 : 팀 빌딩이란 단순히 인사이동으로 팀을 만들라는 게 아니라, 팀과 팀 사이의 협업 능력과 신뢰를 구축하는 걸 말한다. 일이 터졌을 때 손가락질 하지 않고, 각각의 능력이 최대한의 시너지를 발휘하도록 하는 것이 팀 빌딩의 핵심이다. 친한 사람들 간 협업이 더 활발하게 이뤄진다는 단순한 사실을 극대화하는 것을 고민하는 것이 중요하다.

 

협업의 분명한 자리를 마련할 것 : 많은 기업이 사내 메신저 설치해놓고 협업 플랫폼을 마련했다고 착각한다. 진짜 협업을 이루게 하려면 팀 빌딩부터 전제되어야 하며, 팀 빌딩을 해놓고도 계속해서 협업할 일 거리를 던져주고, 회의 시간을 더 갖게 하고, 필요하다면 비공식적인 일정도 추진해 조금이라도 서로를 잘 알도록 해야 한다. 그저 위에서 시켰기 때문에 조용히 자기 기능만 첨가해주는 걸 모아봤자, 아무런 도움이 되지 않는다. 서로 불만을 나누고 격려도 할 줄 알고 자체적으로 북돋을 수 있는 팀이 살아있는 팀이다.

 

역할 분담 : 자기만의 고유 분야가 아주 명확하게 정해져 대체 불가능한 상황이 아니라면 ‘역할극’을 시켜보는 것도 괜찮은 방법이다. 예를 들어 개발자에게 IT 관리자 업무 일부를 맡겨본다거나 반대로 IT 관리자에게 소프트웨어 개발에 참여토록 하는 식으로 말이다. 물론 코딩 할 줄 모르는 사람이 개발에 다짜고짜 참여할 수는 없다. 하지만 자기의 위치에서만 제공할 수 있는 새로운 시각을 제시하는 건 가능하다. 이렇게 서로의 역할에 대해 점점 더 알아갈수록 업무의 병목현상이 사라지고, 구성원들은 더 높은 자존감을 갖게 된다.

 

항시 실험이 가능한 설계 : 앞서 밝혔다시피 품질 보증 담당자가 개발의 전 과정에 포함되어 있다는 걸 반드시 기억하고 기획을 해야 한다. 설계 중이니까, 작업 중이니까, 구축 중이니까 조금 있다가 실험하자는 말이 안 통하도록 해야 하는 게 데브옵스라는 것이다. 솔직히 실험을 자꾸만 미루는 이유는, 적어도 실험을 위해 제출할 만큼 자신 있지 않아서다.

 

자율성의 문화와 ‘장인’ 문화 : 데브옵스의 중요한 지점은 서로에 대한 의존성이 엷어지고, 각자의 자율성이 높아진다는 것이다. 이는 높은 동기부여로 이어질 수도 있지만, 반대로 무책임한 이들의 행태를 부각시키기도 한다. 그래서 필요한 게 각자의 ‘장인정신’이다. 자기가 할 수 있는 한 최대한의 기능을 발휘해야 한다는 것이다. 이는 길게 봐야 하는 것인데, 또 억지로 되지 않는 것이 문제이기도 하다. 내 할 일에 최선을 다했다는 것에 보상받을 수 있도록 방법을 마련해야 한다.

 

계속되는 지식 습득과 기술 공유 : 위의 ‘장인 문화’와 같은 맥락에 있는 것으로, 자율적으로 자기 일을 잘 해내려면 지식을 습득하고 기술을 서로서로 공유하도록 해야 한다. 특히 정보보안처럼 변화가 극심한 곳에 있어서는 자격증 재발급, 사내 재교육과 같은 문화가 필수적이다. CISSP처럼 세계적인 정보보안 자격증 같은 경우 최초 취득 1회로 자격증 유지가 되지 않으며, 매년 갱신을 해야 하는데 이에 대한 회사 차원의 지원과 요구를 하는 것도 조직 전체적으로 도움이 된다. 최초 입사 시에만 자격증 확인을 하는 것이 ‘문화’로 남아있다면, 이 역시 데브옵스 도입과 함께 반드시 수정해야 할 부분이다.

 

<데브옵스(DevOps) 구성 평면도. 한컴MDS 제공>

(http://www.etnews.com/20180928000141

줄어든 근로시간에 데브옵스·RPA 등 SW 활용 주목

 

데브옵스는 애플리케이션과 서비스를 빠른 속도로 제공할 수 있도록 조직의 역량을 향상시키는 문화 철학, 방식 및 도구의 조합입니다. 기존의 소프트웨어 개발 및 인프라 관리 프로세스를 사용하는 조직보다 제품을 더 빠르게 혁신하고 개선할 수 있습니다. 이러한 빠른 속도를 통해 조직은 고객을 더 잘 지원하고 시장에서 좀 더 효과적으로 경쟁할 수 있습니다.

 

(https://aws.amazon.com/ko/devops/what-is-devops/

DevOps란 무엇인가요? - DevOps 모델 설명 - Amazon Web Services(AWS)

 

(http://www.comworld.co.kr/news/articleView.html?idxno=49187

[커버스토리] 데브옵스와 마이크로서비스 - 컴퓨터월드

 

데브옵스와 반대되는 개발 방식은 워터폴(waterfall)이라고 불린다. 이번 소나타입의 연구에는 워터폴 개발 환경에서의 취약점 관리 행태도 포함되었다. 이 중 오픈소스에 관한 거버넌스 및 정책을 보유하고 있다는 기업은 58%뿐이었다. 게다가 48%는 그나마 있는 보안 정책도 잘 지키지 않는다고 답했다. 워터폴 방식을 고수하는 기업들의 보안이라고 그다지 탄탄하지 않다는 것이다. 데브옵스 방식을 유지하고 있는 업체의 77%는 오픈소스와 관련된 보안 정책이 있고, 이를 무시한다는 응답자는 24%였다.

(http://m.boannews.com/html/detail.html?idx=68522

데브옵스 개발 환경, 오픈소스를 잡아야 안전해진다

 

 

evOps의 문제점

• DevOps는 매우 노동 집약적이었음
• 개발팀, QA 팀, 기술 작가, 운영팀 간의 협력이 필요했음
• 기능 배포가 느렸고, 중요한 업데이트가 우선시되었음
• 많은 조직들이 DevOps를 도입한 이유는 다음과 같았음:
  • 기술 인력을 쉽게 대체할 수 없었음
  • 채용이 어렵고 비용이 많이 들었음
  • SaaS 벤더들이 복잡성을 줄여주었음
  • 클라우드 플랫폼의 장점을 강조했음
  • 개발자들이 작은 변경 사항이 배포되기까지 오랜 시간이 걸리는 것에 불만을 가졌음

DevOps의 실제 모습

• DevOps는 개발팀과 운영팀이 하나의 팀으로 통합되는 것을 목표로 함
• QA 팀이 해고되고, 빠른 배포와 피드백을 통해 내부 테스트 기간이 줄어듦
• DevOps는 Google의 SRE와 혼동되기도 하지만, SRE는 더 구조적이고 엄격한 접근 방식을 가짐
• DevOps의 실제 프로세스는 다음과 같음:
  • 개발자가 git에서 브랜치를 만들고 기능을 추가
  • PR을 열고 팀원이 검토 후 main에 병합
  • CI/CD 시스템이 빌드를 시작하고, 컨테이너를 레지스트리에 푸시
  • CD 시스템이 서버에 새로운 릴리스를 알리고, 배포 성공 여부를 모니터링
  • 릴리스 인식 메트릭스를 통해 배포 후 변화를 모니터링

DevOps의 실패 요인

• 개발자들이 로컬 환경에서 테스트하고, Linux 서버에 배포하면서 작은 차이점이 발생
• 운영팀이 배포를 모니터링하지 않아 문제 해결이 어려웠음
• 개발자들이 시스템 운영에 대한 지식이 부족했음
• 컨테이너의 도입으로 일부 문제는 해결되었지만, 운영의 복잡성은 여전히 존재했음

컨테이너의 도입과 한계

• 컨테이너는 "내 컴퓨터에서는 잘 작동했는데" 문제를 해결했음
• Linux 서버 구성 요소를 단순화했음
• 여전히 남은 문제들
  • 운영(Operate): 인프라 유지보수, 업그레이드 등 전문성 요구
  • 관찰(Observe): 복잡한 모니터링 시스템 구축 및 관리의 어려움
  • 지속적 피드백: 내부 피드백 처리의 미흡
  • 발견(Discover): 팀 간 지식 공유 부족
  • 계획(Plan): 중앙화된 계획 수립의 어려움

 

https://github.com/kamranahmedse/developer-roadmap

GitHub - kamranahmedse/developer-roadmap: Interactive roadmaps, guides and other educational content to help developers grow in

 

■ 크로스플랫폼과 IoT

■ '데브섹옵스(DevSecOps)'

■ 데브옵스와 애자일

■ 빈번한 신제품 출시와 더 빠른 업데이트 '고객을 위해'

■ 인공지능과 머신러닝은 데브옵스에 충격을 주기 시작할 것

(http://m.zdnet.co.kr/news_view.asp?article_id=20180103152649#imadnews

데브옵스, 2018년의 '빅딜' 될까

 

위키백과에서는 데브옵스를 “소프트웨어 개발과 운영의 합성어로서 소프트웨어 개발자와 IT 전문가 간의 소통과 협업, 통합을 강조하는 개발 환경이나 문화”라고 정의하면서 “소프트웨어 개발 조직과 운영 조직 간의 상호 의존적 대응이며 조직이 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을 목적으로 한다”고 명시하고 있다.

 

그럼에도 불구하고 데브옵스를 둘러싸고 의견이 분분한 이유 중 하나는 이것이 방법론인지, 문화인지조차 정확히 판단할 수 없기 때문이다. 개발 환경인지, 그러한 관점을 지칭하는 것인지 경계가 흐릿하다.

(http://www.boannews.com/media/view.asp?idx=58554&kind=0

[기획] ‘데브옵스’라는 유령의 뒤를 쫓다

 

 

예전에는 ‘데브(Dev, 개발팀)’가 개발하면 ‘옵스(Ops, 운영팀)’가 운영했다. 이런 단계를 밟아 일을 처리하면 몇 주에서 몇 달까지 걸리는 게 다반사였으며, 도중에 뭔가 하나라도 잘못되면 각 부서에서 누가 잘못했는지 증명하려고 추궁부터 하곤 했다. 데브옵스라는 새로운 길은 부서들을 통합시킨다. 문제 해결조차 전체 프로세스의 일부분으로 포함하는 것이다. 이제 반복은 줄어들었고, 모든 직원이 제품에 실제로 어떤 일이 일어나는지 확인할 수 있는 툴을 갖게 됐다. 만약 문제가 있다면, 문제 있는 사람을 지목하는 것이 아니라 문제 있는 데이터를 지목할 수 있다. 결정을 내릴 때까지의 소통과 협업, 그리고 제품 데이터의 사용에 집중하는 것은 데브옵스 세계에서 보안이 작동하게 만드는 핵심 열쇠다.

 

 

https://www.techtarget.com/searchsoftwarequality/tip/Is-a-continuous-planning-process-in-DevOps-worth-it

Is a continuous planning process in DevOps worth it? | TechTarget

https://news.hada.io/topic?id=15604

DevOps에 대한 추도사 | GeekNews