SCM 관련 프레젠테이션을 많이 만들었습니다. 이제 DevOps의 후속 버전으로 "업그레이드"하려고합니다.

프리젠 테이션에서 항상하려고하는 것은 전달하려는 메시지가 포함 된 소개 슬라이드 (그리고 나머지 프리젠 테이션에서 자세히 설명)를 만들어내는 것입니다. 그렇게 할 때, 나는 "나에게 새로운 사람에게 설명하기 위해 10 ~ 20 초 (만!)가되었을 때 사용하고 싶은 1 ~ 3 개의 문구는 무엇인가?"와 같은 내 자신의 질문에 답하려고합니다. * ".

나는 DevOps가 실제로 무엇을 의미하는지, 그것이 무엇인지 알고 있다고 생각 했습니다. 그러나 DevOps의 기괴한 사용법 / 컨텍스트 ( DevOps.SE 에서도)를 보았습니다 . 어쩌면 내가 DevOps라고 생각하는 것이 완전히 잘못되었는지 궁금해합니다.

그렇다면 일반적으로 DevOps의 정의에 동의하는 것은 무엇입니까?

간단히 말해서 DevOps

에서 위키 백과 :

개발 운영팀 (A 클리핑 화합물 "의 소프트웨어 DEV의 elopment "와 " 정보 기술 영업 eration의 S는 ") 모두의 협력과 소통을 강조 관행의 집합을 참조하는 데 사용되는 용어입니다 소프트웨어 개발자 및 정보 기술 (IT) 전문가 동안 자동화 소프트웨어 제공 및 인프라 변경 프로세스

소프트웨어를 구축 , 테스트 및 릴리스 할 수 있는 문화 및 환경을 구축하는 것이 목표 입니다.

에서 개요 :

개발 (소프트웨어 엔지니어링), 운영 및 품질 보증 (QA) 의 교차점으로 DevOps를 보여주는 벤 다이어그램

DevOps를위한 단일 "도구"는 없지만 DevOps 툴체인 이라고도 불리는 일련의 도구가 있습니다 .

DevOps 툴체인의 단계를 보여주는 그림

DevOps의 삽화

다음은 DevOps.SE에 대한 몇 가지 질문에서 인용 한 것입니다. 위의 DevOps 설명 중 일부에 적합하거나 확인 된 것으로 보입니다.

• ' SRE와 DevOps의 차이점은 무엇입니까? ':

  ... DevOps는 코드 유지 관리에 관한 것입니다 ...

• ' ( 답변 )에서' 회사에 맞는 좋은 DevOps를 어떻게 고용합니까? ':

  ...“DevOps”가 회사의 역할이라는 것은 일반적인 오해입니다. 이 단어는 단순히 소프트웨어 회사의 조직 변화를 나타냅니다 ...

• ' 회사에서 Agile Soft를 채택해야합니까? 개발자 DevOps를 채택하기 전에? ':

  ... DevOps 채택에 관심이있는 소프트웨어 개발에서 Agile을 실행하지 않는 조직이 여전히 있습니다 ...

DevOps는 역할이 아닙니다

다음은 DevOps.SE에 대한 몇 가지 질문에서 인용 한 것입니다. DevOps가 역할 이 아님 을 보여줍니다 .

• (AN에서 대답 에) ' 를 Sysadmin 및 개발 운영 엔지니어의 차이점은 무엇입니까? ':

  ... DevOps는 역할이 아닙니다 (이와 같이 사용하면 실제 역할보다 더 유행어입니다).

• ' ( 답변 )에서' 회사에 맞는 좋은 DevOps를 어떻게 고용합니까? ':

  ...“DevOps”가 회사의 역할이라는 것은 일반적인 오해입니다. 이 단어는 단순히 소프트웨어 회사의 조직 변화를 나타냅니다 ...

저는 현재 직책을 맡기 전에 소프트웨어 개발, 웹 운영 및 시스템 관리에서 거의 5 년 동안 다른 고객과의 컨설턴트로 DevOps에 대해 실습 및 조언을 해왔습니다. 내 개인적인 경험에서 DevOps는 많은 맛이 있습니다.

조직 패턴

DevOps 반 패턴 :

• NoOps 와 NoDevs – 가장 엄격한 의미의 DevOps는 아니지만 개발팀 과 개발팀을 구분하지 않고 소프트웨어를 구축하고 운영합니다. 이 팀의 과제는 성숙 단계에 이르며 개발 팀은 전문 소프트웨어 개발자 일 수 있지만 초보자는 물론 비자도 마찬가지입니다.

• 데브 옵스 브리지 (DevOps Bridge) – 하나 이상의 팀이 개발 팀에서 작업을 수행하고 이를 운영 할 수 있도록 " 제작 "할 책임이 있습니다. 이제는 개발 → DevOps 및 DevOps → 운영이라는 두 가지 방법이 있습니다.

• DevOps 팀 -팀이 DevOps 지원 운영 모델을 지원하는 도구를 작성해야 할 책임이있는 경우에는이 작업이 가능하지만 "도구 팀"또는 "플랫폼 팀"이라고합니다.

DevOps 패턴 :

• 임베디드 데브 옵스 (Embedded DevOps) -보다 일반적으로 플랫폼 엔지니어링이라고하며, 팀 내 에서 솔루션 프로비저닝 및 배포를위한 자동화, 도구 및 인프라를 제공 할 책임이 있지만 때로는 소프트웨어 운영을 포함하여 책임 을 지지 않는 사람이 있습니다. 실제로 DevOps를 대표하는 것은 후자입니다.

• Institutionalized DevOps- 프로젝트 팀이 공동 소유 및 긍정적 인 피드백 루프를 구축하는 소프트웨어 패키지의 개발 및 운영을 공동으로 책임지는 곳.

실습

DevOps의 실제 사례는 다음과 같은 몇 가지 다른 사례 위에 구축됩니다.

• 민첩한 배달
• 지속적인 통합
• 지속적인 배달
• 지속적인 배포

위의 각 관행은 다른 관행을 기반으로 하며 관행을 따르지 않을 수도 있지만 중요한 피드백주기가 누락되어 "기회 기회가 없음"을 나타낼 수 있습니다. 다른 방법과 DevOps를 따르는 것의 주요 차이점은 프로덕션 환경에서의 소프트웨어 작동입니다 .

세 가지 방법

에서 피닉스 프로젝트 유전자 김과 그의 공동 저자 기술 개발 운영 팀의 세 가지 방법 :

시스템 사고

첫 번째 방법은 특정 사일로 또는 부서의 성능과 달리 전체 시스템의 성능을 강조합니다. 이는 규모가 큰 부서 (예 : 개발 또는 IT 운영) 또는 개별 기고자 (예 : 소규모) 일 수 있습니다. , 개발자, 시스템 관리자).

필자의 경험에 따르면 개발자가 운영 관련 문제 및 비 기능 요구 사항을 고려하게되면이 목표를 달성 할 수 있습니다. 이것은 DevOps 의 문화 측면의 많은 부분입니다 .

피드백 루프 증폭

두 번째 방법은 오른쪽에서 왼쪽으로 피드백 루프를 만드는 것입니다. 거의 모든 프로세스 개선 이니셔티브의 목표는 피드백 루프를 단축 및 증폭하여 필요한 수정을 지속적으로 수행하는 것입니다.

나는 일반적으로 Continuous Integration / Delivery / Deployment와 공유 모니터링 및 경고를 통해이를 달성하므로 DevOps 의 도구 구성 요소에 매우 적합 합니다.

지속적인 실험과 학습의 문화

세 번째 방법은 두 가지를 육성하는 문화를 만드는 것입니다. 지속적인 실험, 위험 감수 및 실패로부터의 학습; 그리고 반복과 연습이 숙달의 전제 조건이라는 것을 이해해야합니다.

이것은 문화가 성장할 수 있도록 도구와 프로세스에 크게 의존하지만 문화 공간 에 매우 적합 합니다.

DevOps에 대한 많은 정의가 많이 들었습니다. 그들은 다음을 포함합니다 :

• 운영 작업을 처리하는 개발자
• 한 사람이 같은 시간에 두 배의 일을한다
• 서로 협력하는 개발자 및 운영 팀
• "Web Ops"의 맥락에서 개발자 툴링 작업
• 개발자 도구를 작성하고 유지 관리하는 사람을위한 직함
• 운영에서 자동화 사용
• 운영에 퍼블릭 클라우드 사용
• 운영, 개발 및 품질 보증 측면을 결합한 작업
• 개발팀과 운영팀이 함께 일할 수 있도록 도와주는 직업
• 팀 간의 장벽을 무너 뜨리는 철학
• 인프라를 코드로 취급
• 전 소프트웨어 엔지니어가 운영으로 전환 할 때 얻는 것
• 완전히 의미없는 유행어

실제로 개발 운영 팀에 어떤에는 국민적 합의가 없다 됩니다 . 몇 년 전 우리는 "Agile"과 비슷한 문제를 겪었고, 그 정의는 서면으로되어 있습니다 .

새로운 이민자에게 당신의 개념을 소개 할 때, 나는 레이블을 적용하는 대신 개념을 소개하는 데 중점을 둘 것입니다. 예를 들어 코드로 인프라 에 대해 이야기하려는 경우 인프라 에 대해 코드 로 이야기하고 있다고 말하십시오. 합의 된 정의로도 대부분의 회사는 철학의 특정 부분에 더 집중합니다.

이 상황에서 항상 사용하는 정의는 다음과 같습니다.

“소프트웨어 개발 프로세스와 인프라 변경을 자동화하면서 소프트웨어 개발 및 운영 팀 간의 커뮤니케이션 및 협업을 강조하는 소프트웨어 제작 문화. DevOps의 목표는 소프트웨어 빌드, 테스트 및 배포 프로세스를 가능한 한 자주, 빠르고, 가능하게하는 것입니다.”

그러나 정의와 함께 DevOps 가 필요한 이유를 이해하는 것도 중요합니다 . DevOps는 소프트웨어 결함을 더 빠르게 완화하고 더 나은 자원 관리, 인적 오류 감소, 더 나은 버전 제어, 안정적인 운영 환경 등을 가능하게합니다.

DevOps 란 무엇인가?라는이 질문을 정확하게 탐구하기 위해 다음 과학 연구 논문에서 DevOps의 제안 된 파생 정의는 다음과 같습니다.

DevOps는 개발 (Dev)과 운영 (Ops) 간의 격차를 해소하고 일련의 개발 방식을 활용하여 자동화 된 배포를 통해 커뮤니케이션 및 협업, 지속적인 통합, 품질 보증 및 제공을 강조하는 개발 방법론입니다.

[Jabbari et al.] "DevOps 란? : 정의 및 실무에 대한 체계적인 매핑 연구"(2016)

Devops는 비즈니스 도메인 이 운영 인 응용 프로그램을 작성하는 개발 관행입니다 . 대부분의 응용 프로그램 개발이 금융 또는 건강 관리 또는 물류 또는 고양이 비디오를 수행하는 응용 프로그램을 작성하는 데 중점을 두는 경우, 빌드, 배포, 모니터링 및 메트릭 수집을 가능하게하는 응용 프로그램에 중점을 둡니다.

가장 중요한 목표는 항상 의사 결정자 가 의사 결정자 가 될 수 있도록하는 것이어야합니다 . 은행의 모바일 애플리케이션을 상상해보십시오. 전송을 요청하면 버튼을 누를 때 발생합니다. 당신은 만든 후, 결정을 했다 결정. 작업과 동일합니다. 적절한 사람이 일부 작업을 프로덕션에 배포 할 준비가되면 버튼과 "Right Things Happen"을 누르십시오. 마찬가지로 올바른 비즈니스 결정을 내리는 데 필요한 모든 정보가 있어야합니다.

비즈니스 직원에게 서버에 대한 쉘 액세스 권한을 부여하는 것이 아니라 구현과 혼동되는 목적입니다. 의사 결정자가 의사 결정자가 될 수 있도록 올바른 정보 와 올바른 보호 레일 을 올바른 사람에게 올바른 손잡이와 레버에 제공하는 것 입니다.