우리는 이해할 수 있는 언어로 DevOps에 대해 이야기합니다.

DevOps에 관해 이야기할 때 요점을 파악하기가 어렵나요? 우리는 비전문가라도 요점을 파악하는 데 도움이 될 생생한 비유, 인상적인 공식, 전문가의 조언을 수집했습니다. 결국 보너스는 Red Hat 직원의 자체 DevOps입니다.

DevOps라는 용어는 10년 전에 시작되었으며 Twitter 해시태그에서 IT 세계의 강력한 문화 운동으로 발전했습니다. 이는 개발자가 작업을 더 빠르게 완료하고, 실험하고, 앞으로 반복하도록 장려하는 진정한 철학입니다. DevOps는 디지털 혁신의 개념과 불가분의 관계가 되었습니다. 그러나 IT 용어에서 흔히 발생하는 것처럼 지난 XNUMX년 동안 DevOps는 자체에 대한 많은 정의, 해석 및 오해를 얻었습니다.

따라서 DevOps에 대해 "Agile과 동일한가요?"와 같은 질문을 자주 들을 수 있습니다. 아니면 특별한 방법론인가요? 아니면 "협업"이라는 단어의 또 다른 동의어일까요?

DevOps에는 다양한 개념(지속적 전달, 지속적인 통합, 자동화 등)이 포함되어 있으므로 특히 해당 주제에 열정이 있는 경우 중요한 것을 추출하는 것이 어려울 수 있습니다. 그러나 이 기술은 자신의 아이디어를 상사에게 전달하려고 하거나 단순히 가족이나 친구 중 누군가에게 자신의 작업에 대해 이야기하려는 경우에도 매우 유용합니다. 따라서 지금은 DevOps의 용어적 뉘앙스를 제쳐두고 큰 그림에 집중하겠습니다.

DevOps란 무엇입니까: 6가지 정의 및 비유

우리는 전문가들에게 DevOps의 본질을 가능한 한 간단하고 간략하게 설명하여 기술 지식 수준에 관계없이 독자들에게 DevOps의 가치가 명확하게 전달되도록 요청했습니다. 이러한 대화의 결과를 바탕으로 DevOps에 대한 스토리를 구축하는 데 도움이 될 가장 눈에 띄는 비유와 눈에 띄는 공식을 선택했습니다.

1. DevOps는 문화적 운동입니다

"DevOps는 양 당사자(소프트웨어 개발자와 IT 시스템 운영 전문가)가 누군가가 소프트웨어를 사용하기 전까지는 소프트웨어가 실질적인 이점을 가져오지 않는다는 점을 인식하는 문화적 운동입니다. 핵심은 고객, 클라이언트, 직원이 아니라"라고 수석 연구원인 Eveline Oehrlich는 말합니다. DevOps Institute의 분석가입니다. "따라서 양 당사자는 공동으로 신속하고 고품질의 소프트웨어 제공을 보장합니다."

2. DevOps는 개발자에게 권한을 부여하는 것입니다.

“DevOps는 개발자가 애플리케이션을 소유하고 실행하며 처음부터 끝까지 제공을 관리할 수 있도록 지원합니다.”

보험 회사인 Liberty Mutual의 DevOps 플랫폼 이사인 Jai Schniepp은 "일반적으로 DevOps는 자동화된 프로세스를 구축하고 구현하여 프로덕션에 애플리케이션을 제공하는 속도를 높이는 방법으로 이야기됩니다."라고 말합니다. "하지만 나에게 있어서 그것은 훨씬 더 근본적인 것입니다." DevOps는 개발자가 애플리케이션이나 특정 소프트웨어를 소유하고 실행하며 처음부터 끝까지 제공을 관리할 수 있도록 지원합니다. DevOps는 책임 혼란을 없애고 자동화된 개발자 중심 인프라 구축에 관련된 모든 사람을 안내합니다."

3. DevOps는 애플리케이션 생성 및 제공에 있어 협업에 관한 것입니다.

BMC의 디지털 비즈니스 자동화 부문 사장 겸 책임자인 Gur Staf는 "간단히 말하면 DevOps는 모두가 함께 작업하는 소프트웨어 생산 및 제공에 대한 접근 방식입니다."라고 말합니다.

4. DevOps는 파이프라인입니다

"컨베이어 조립은 모든 부품이 서로 맞아야 가능합니다."

Gur Staff는 “DevOps를 자동차 조립 라인에 비유하겠습니다.”라고 덧붙였습니다. – 개별 조정 없이 조립할 수 있도록 모든 부품을 미리 설계하고 제작하는 것이 아이디어입니다. 컨베이어 조립은 모든 부품이 서로 맞아야 가능합니다. 엔진을 설계하고 제작하는 사람들은 엔진을 차체나 프레임에 장착하는 방법을 고려해야 합니다. 브레이크를 만드는 사람은 바퀴 등을 생각해야 합니다. 소프트웨어에서도 마찬가지입니다.

비즈니스 로직이나 사용자 인터페이스를 만드는 개발자는 고객 정보를 저장하는 데이터베이스, 사용자 데이터를 보호하기 위한 보안 조치, 그리고 서비스가 수백만 달러 규모의 대규모 사용자 대상에게 서비스를 제공하기 시작할 때 이 모든 것이 어떻게 작동할지 생각해야 합니다. ."

“사람들이 자신의 업무에만 집중하기보다 다른 사람들이 하고 있는 일에 대해 협력하고 생각하게 하는 것이 가장 큰 장애물입니다. 이렇게 할 수 있다면 디지털 혁신의 훌륭한 기회를 갖게 됩니다.”라고 Gur Staff는 덧붙입니다.

5. DevOps는 사람, 프로세스, 자동화의 올바른 조합입니다.

DevOps Institute의 전무이사인 Jayne Groll은 DevOps를 설명하기 위해 훌륭한 비유를 제시했습니다. 그녀의 말에 따르면, “DevOps는 사람, 프로세스, 자동화라는 세 가지 주요 구성요소 범주로 구성된 레시피와 같습니다. 이러한 요소의 대부분은 Lean, Agile, SRE, CI/CD, ITIL, 리더십, 문화, 도구 등 다른 영역 및 소스에서 가져올 수 있습니다. 다른 좋은 레시피와 마찬가지로 DevOps의 비결은 올바른 비율을 얻고 이러한 요소를 혼합하여 애플리케이션 생성 및 출시의 속도와 효율성을 높이는 방법입니다.”

6. DevOps는 프로그래머가 Formula 1 팀처럼 일하는 것입니다.

"경주는 처음부터 끝까지 계획된 것이 아니라 반대로 끝까지 계획되어 있습니다."

Red Hat의 클라우드 플랫폼 마케팅 수석 관리자이자 DevOps 관련 뉴스레터 발행자인 Chris Short는 "DevOps 이니셔티브에서 기대할 수 있는 사항에 대해 이야기할 때 NASCAR 또는 Formula 1 레이싱 팀을 예로 듭니다."라고 말합니다. – 그러한 팀의 리더에게는 한 가지 목표가 있습니다. 팀이 사용할 수 있는 자원과 팀에 닥친 어려움을 고려하여 레이스가 끝날 때 가능한 가장 높은 자리를 차지하는 것입니다. 이 경우 경주는 처음부터 끝까지 계획되지 않고 반대로 결승부터 시작까지 계획됩니다. 먼저, 야심찬 목표를 설정하고 이를 달성하기 위한 방법을 결정합니다. 그런 다음 하위 작업으로 분류되어 팀원에게 위임됩니다.”

“팀은 레이스가 시작되기 일주일 전부터 피트 스톱을 완성하는 데 시간을 보냅니다. 그는 힘든 경기일에 대비해 몸매를 유지하기 위해 근력 운동과 심장강화 운동을 합니다. 경주 중 발생할 수 있는 문제를 해결하기 위해 함께 노력하는 연습입니다. 마찬가지로 개발팀도 새 버전을 자주 출시하는 기술을 훈련해야 합니다. 이러한 기술과 제대로 작동하는 보안 시스템이 있으면 새 버전이 프로덕션에 출시되는 경우도 더 자주 발생합니다. 이러한 세계관에서는 속도가 빨라지면 안전성도 높아집니다.”라고 Short는 말합니다.

Short는 이렇게 덧붙였습니다. “'올바른 일'을 하는 것이 아닙니다. 원하는 결과를 방해하는 요소를 최대한 제거하는 것입니다. 실시간으로 받는 피드백을 기반으로 협업하고 적응하세요. 이상 현상에 대비하고 품질을 개선하여 목표 달성에 미치는 영향을 최소화하십시오. 이것이 DevOps 세계에서 우리를 기다리고 있는 것입니다.”

DevOps 확장 방법: 전문가가 전하는 10가지 팁

DevOps와 대량 DevOps는 완전히 다른 것입니다. XNUMX차에서 XNUMX차로 넘어가는 과정에서 어떻게 장애물을 극복하는지 알려드리겠습니다.

많은 조직에서 DevOps로의 여정은 쉽고 즐겁게 시작됩니다. 열정적인 소규모 팀이 만들어지고 오래된 프로세스가 새로운 프로세스로 대체되며 첫 번째 성공은 머지않아 이루어집니다.

아쉽게도 이것은 단지 잘못된 현란함일 뿐이며 발전에 대한 환상일 뿐이라고 컨설팅 회사인 North Highland의 전무 겸 디지털 책임자인 Ben Grinnell은 말합니다. 초기 성공은 확실히 고무적이지만 조직 전체에 DevOps를 광범위하게 채택한다는 궁극적인 목표를 달성하는 데 도움이 되지 않습니다.

그 결과는 '우리'와 '그들' 사이의 분열 문화임을 쉽게 알 수 있다.

Ben Grinnell은 “조직에서는 다른 사람들이 해당 경로를 따를 수 있는지 또는 따를 의지가 있는지 고려하지 않고 주류 DevOps의 길을 닦을 것이라고 생각하면서 이러한 선구적인 프로젝트를 시작하는 경우가 많습니다.”라고 설명합니다. – 이러한 프로젝트를 실행하기 위한 팀은 일반적으로 다른 곳에서 비슷한 일을 이미 수행했지만 조직에는 처음인 자신감 넘치는 "Varangians"로부터 모집됩니다. 동시에, 그들은 다른 모든 사람에게 구속력이 있는 규칙을 깨고 파괴하도록 권장됩니다. 그 결과는 지식과 기술의 전달을 방해하는 '우리'와 '그들'의 문화라는 것을 쉽게 알 수 있습니다.”

“이 문화적 문제는 DevOps의 확장이 어려운 이유 중 하나일 뿐입니다. DevOps 팀은 빠르게 성장하는 IT 우선 기업에서 흔히 볼 수 있는 증가하는 기술적 과제에 직면해 있습니다.”라고 Scalyr의 창립자이자 회장인 Steve Newman은 말했습니다.

“현대 사회에서는 필요가 발생하자마자 서비스가 변경됩니다. 새로운 기능을 지속적으로 구현하고 구현하는 것은 좋지만 이 프로세스를 조정하고 발생하는 문제를 제거하는 것은 정말 골치 아픈 일이라고 Steve Newman은 덧붙입니다. – 매우 빠르게 성장하는 조직에서 다기능 팀의 엔지니어는 변화에 대한 가시성과 이로 인해 발생하는 종속성 수준의 계단식 효과를 유지하는 데 어려움을 겪습니다. 더욱이 엔지니어들은 이러한 기회를 빼앗기면 기뻐하지 않으며, 결과적으로 발생하는 문제의 본질을 이해하기가 더욱 어려워집니다.”

위에 설명된 이러한 과제를 극복하고 대규모 조직에서 DevOps를 대량 채택하는 방법은 무엇입니까? 전문가들은 최종 목표가 소프트웨어 개발 주기와 비즈니스 프로세스 속도를 높이는 것이라고 하더라도 인내심을 가질 것을 촉구합니다.

1. 문화 변화에는 시간이 걸린다는 점을 기억하십시오.

Jayne Groll, DevOps Institute 전무이사: “제 생각에는 DevOps의 확장은 애자일 개발만큼 점진적이고 반복적이어야 합니다(그리고 문화에도 똑같이 영향을 미침). Agile과 DevOps는 소규모 팀을 강조합니다. 그러나 이러한 팀의 수와 통합이 증가함에 따라 결국 더 많은 사람들이 새로운 작업 방식을 채택하게 되고 결과적으로 엄청난 문화적 변화가 발생하게 됩니다."

2. 플랫폼을 계획하고 선택하는 데 충분한 시간을 투자하세요

Eran Kinsbruner, Perfecto의 수석 기술 전도사: “확장이 제대로 작동하려면 DevOps 팀은 먼저 기존 프로세스, 도구 및 기술을 결합한 다음 DevOps의 각 개별 단계를 천천히 육성하고 안정화하는 방법을 배워야 합니다. 모든 작업은 사용자 스토리와 가치 흐름을 신중하게 계획하는 것부터 시작하여 트렁크 기반 개발 또는 코드 분기 및 병합에 가장 적합한 기타 접근 방식을 사용하여 소프트웨어 및 버전 제어를 작성하는 것부터 시작됩니다.”

“그런 다음 자동화를 위한 확장 가능한 플랫폼이 이미 필요한 통합 및 테스트 단계가 옵니다. DevOps 팀이 기술 수준과 프로젝트의 최종 목표에 맞는 올바른 플랫폼을 선택하는 것이 중요한 곳입니다.

다음 단계는 프로덕션 배포이며, 이는 오케스트레이션 도구와 컨테이너를 사용하여 완전히 자동화되어야 합니다. DevOps의 모든 단계(프로덕션 시뮬레이터, QA 환경, 프로덕션 환경)에서 가상화된 환경을 보유하고 항상 최신 데이터만 테스트에 사용하여 관련 결론을 얻는 것이 중요합니다. 분석은 스마트해야 하며 빠르고 실행 가능한 피드백을 통해 빅데이터를 처리할 수 있어야 합니다.”

3. 책임에서 죄책감을 없애십시오.

Gordon Haff, RedHat 전도사: “실험을 허용하고 장려하는 시스템과 분위기를 조성하면 애자일 소프트웨어 개발에서 성공적인 실패가 가능해집니다. 이는 실패에 대해 다른 사람이 책임을 지지 않는다는 의미는 아닙니다. 실제로 "책임을 진다"는 것이 더 이상 "사고를 일으킨다"는 의미가 아니기 때문에 책임이 있는 사람을 식별하는 것이 훨씬 더 쉬워집니다. 즉, 책임의 본질이 질적으로 변하는 것이다. 혼란의 정도, 접근 방식, 생산 프로세스 및 인센티브라는 네 가지 요소가 중요해집니다.” (Gordon Huff의 기사 "DevOps 수업: 건전한 실험의 4가지 측면"에서 이러한 요소에 대해 자세히 알아볼 수 있습니다.)

4. 앞으로 나아갈 길을 비워라

컨설팅 회사 North Highland의 전무이사 겸 디지털 책임자인 Ben Grinnell은 다음과 같이 말했습니다. “규모를 확장하려면 선구적인 프로젝트와 함께 '경로 개척' 프로그램을 시작하는 것이 좋습니다. 이 프로그램의 목표는 오래된 규칙 등 DevOps 개척자들이 남긴 쓰레기를 정리하여 앞으로 나아갈 길을 명확하게 유지하는 것입니다.”

“새로운 작업 방식의 성공을 널리 축하함으로써 선구적인 그룹을 뛰어넘는 의사소통을 통해 사람들에게 조직적 지원과 추진력을 제공하십시오. 차세대 DevOps 프로젝트에 참여하고 처음으로 DevOps를 사용하는 것에 대해 긴장하는 사람들을 지도하세요. 그리고 이 사람들은 개척자들과 매우 다르다는 것을 기억하세요.”

5. 도구 민주화

Scalyr의 창립자이자 회장인 Steve Newman은 다음과 같이 말했습니다. “도구는 사람들에게 숨겨져서는 안 되며, 시간을 투자하려는 사람이라면 누구나 비교적 쉽게 배울 수 있어야 합니다. 로그 쿼리 기능이 도구 사용에 대해 "인증된" XNUMX명으로 제한되는 경우 컴퓨팅 환경이 매우 큰 경우에도 문제를 처리할 수 있는 사람은 항상 최대 XNUMX명입니다. 즉, 여기에는 심각한 (비즈니스) 결과를 초래할 수 있는 병목 현상이 존재합니다.”

6. 팀워크를 위한 이상적인 조건 조성

ITV의 공통 플랫폼 책임자인 Tom Clark: “무엇이든 할 수 있지만 한꺼번에 모든 것을 할 수는 없습니다. 따라서 큰 목표를 설정하고 작게 시작하여 빠른 반복을 통해 앞으로 나아가십시오. 시간이 지남에 따라 당신은 일을 완수한다는 평판을 얻게 될 것이고, 그래서 다른 사람들도 당신의 방법을 사용하고 싶어하게 될 것입니다. 그리고 매우 효과적인 팀을 구성하는 것에 대해 걱정하지 마십시오. 대신 사람들에게 이상적인 근무 조건을 제공하면 효율성이 따라옵니다.”

7. 콘웨이의 법칙과 칸반 보드를 잊지 마세요

Logan Daigle, CollabNetVersionOne의 소프트웨어 제공 및 DevOps 전략 이사: “콘웨이 법칙의 결과를 이해하는 것이 중요합니다. 제가 간단히 표현하면 이 법은 DevOps를 포함하여 우리가 만드는 제품과 그렇게 하기 위해 사용하는 프로세스가 우리 조직과 동일한 방식으로 구성된다는 점을 명시하고 있습니다.”

“조직에 사일로가 많고 소프트웨어를 계획, 구축 및 출시할 때 제어권이 여러 번 바뀌면 확장 효과가 없거나 단명할 것입니다. 조직이 시장에 초점을 맞춰 자금을 지원받는 제품을 중심으로 다기능 팀을 구성하면 성공 가능성이 극적으로 높아집니다.”

“확장의 또 다른 중요한 측면은 진행 중인 모든 작업(WIP, 진행 중인 작업)을 Kanban 보드에 표시하는 것입니다. 조직에 사람들이 이러한 것들을 볼 수 있는 장소가 있으면 협업이 크게 장려되고 이는 확장에 긍정적인 영향을 미칩니다.”

8. 오래된 상처를 찾아보세요

Manuel Pais, DevOps 컨설턴트이자 Team Topologies의 공동 저자: “Dev 및 Ops 자체를 넘어서 DevOps 방식을 취하고 이를 다른 기능에 적용하려고 시도하는 것은 최적의 접근 방식이 아닙니다. 이는 확실히 어느 정도 영향을 미칠 것입니다(예: 수동 제어 자동화). 그러나 전달 및 피드백 프로세스를 이해하는 것부터 시작하면 훨씬 더 많은 것을 달성할 수 있습니다.”

“조직의 IT 시스템에 과거 사고의 결과로 구현되었지만 (제품, 기술 또는 프로세스의 변경으로 인해) 관련성을 잃은 절차 및 관리 메커니즘과 같은 오래된 상처가 있는 경우 반드시 제거해야 합니다. 비효율적이거나 불필요한 프로세스를 자동화하는 것이 아니라 원활하게 처리합니다.”

9. DevOps 옵션을 늘리지 마세요

Anthony Edwards, Eggplant 운영 이사: “DevOps는 매우 모호한 용어이므로 각 팀은 자체 DevOps 버전을 갖게 됩니다. 그리고 조직에 갑자기 서로 잘 어울리지 않는 20가지 종류의 DevOps가 있다고 해도 더 나쁜 것은 없습니다. 세 개발팀 각각이 개발과 제품 관리 사이에 고유한 특수 인터페이스를 갖는 것은 불가능합니다. 제품이 생산 시뮬레이터로 전송될 때 피드백 처리에 대한 고유한 기대치를 가져서는 안 됩니다. 그렇지 않으면 DevOps를 확장할 수 없습니다.”

10. DevOps의 비즈니스 가치를 전파하세요

Scalyr의 창립자이자 회장인 Steve Newman은 다음과 같이 말했습니다. “DevOps의 가치를 인식하기 위해 노력하세요. 당신이 하는 일의 이점에 대해 배우고 자유롭게 이야기하십시오. DevOps는 시간과 비용을 엄청나게 절약해 줍니다(생각해 보세요: 다운타임 감소, 평균 복구 시간 단축). DevOps 팀은 비즈니스 성공을 위한 이러한 이니셔티브의 중요성을 끊임없이 강조하고 전파해야 합니다. 이렇게 하면 지지자의 범위를 확장하고 조직에서 DevOps의 영향력을 높일 수 있습니다.”

보너스

에 Red Hat 포럼 러시아 자체 DevOps는 13월 XNUMX일에 출시됩니다. 예, 소프트웨어 제조업체인 Red Hat은 자체 DevOps 팀과 업무 방식을 보유하고 있습니다.

조직 전체의 다른 그룹을 위한 내부 자동화 서비스를 개발하는 엔지니어 Mark Birger는 Red Hat DevOps 팀이 Ansible에서 관리하는 Hat Virtualization 가상 환경의 애플리케이션을 본격적인 컨테이너 형식으로 마이그레이션한 방법에 대해 순수 러시아어로 설명합니다. 오픈시프트 플랫폼.

하지만 그게 다가 아닙니다.

조직이 워크로드를 컨테이너로 이동하면 기존 애플리케이션 모니터링 방법이 작동하지 않을 수 있습니다. 두 번째 강연에서는 로깅 방식을 변경하게 된 동기를 설명하고 최신 로깅 및 모니터링 방법으로 이어진 경로의 연속성을 보여줄 것입니다.

출처 : habr.com