DevOps는 도대체 무엇인가?

시간의 간략한 역사

DevOps를 이해하려면 프로그래머 외에는 아무것도 없던 옛날로 시간을 거슬러 올라가야 합니다.

도가 우리에게 가르치는 것처럼:

고대의 프로그래머는 신비롭고 심오했습니다. 우리는 그들의 생각을 헤아릴 수 없으므로 우리가 하는 일은 그들의 외모를 묘사하는 것뿐입니다.

• 알아차림, 물을 건너는 여우처럼
• 전장의 장군처럼 경계하라
• 친절, 손님을 맞이하는 안주인처럼
• 조각되지 않은 나무 블록처럼 단순합니다.
• 어두운 동굴의 검은 웅덩이처럼 불투명

프로그래머는 기계어를 탄생시켰습니다. 기계어가 어셈블러를 탄생시켰습니다. 어셈블러는 컴파일러를 탄생시켰습니다. 이제 수천 개의 언어가 있습니다. 각 언어에는 비록 겸손하더라도 목적이 있습니다. 각 언어는 소프트웨어의 음과 양을 나타냅니다. 각 언어는 소프트웨어 내에서 고유한 위치를 가지고 있습니다.

당시 소프트웨어 개발실은 주로 랩(lab)이라 불렀고 프로그래머는 과학자였다. 좋은 응용 프로그램을 만들기 위해 프로그래머는 응용 프로그램이 해결하는 문제를 완전히 이해해야 했습니다. 그들은 애플리케이션이 어디에서 사용될 것이며 어떤 종류의 시스템에서 실행할 것인지를 알아야 했습니다. 본질적으로 프로그래머는 사양에서 개발, 배포 및 지원에 이르기까지 응용 프로그램에 대한 모든 것을 알고 있었습니다.

그리고 나서 인간의 본성이 시작되었고 우리는 더 많은 것을 요구하기 시작했습니다. 더 빠른 속도, 더 많은 기능, 더 많은 사용자, 더 많은 모든 것.

겸손하고 겸손하고 평화로운 생물이기 때문에 프로그래머는 항상 더 많은 것을 요구하는 궁핍한 사용자의 폭발에서 살아남을 기회가 거의 없었습니다. 승리할 수 있는 가장 좋은 기회는 다른 방향으로 진화를 시작하고 카스트를 만드는 것이었습니다. 곧 프로그래머는 개발자, 소프트웨어 엔지니어, 네트워크 관리자, 데이터베이스 개발자, 웹 개발자, 시스템 설계자, QA 엔지니어 등으로 불리는 새로운 유형의 조상으로 멸종되었습니다. 빠르게 진화하고 외부 세계의 도전에 적응하는 것은 그들의 DNA의 일부가 되었습니다. 새로운 카스트는 몇 주 안에 진화할 수 있습니다. 웹 개발자는 백엔드 개발자, 프론트엔드 개발자, PHP 개발자, Ruby 개발자, Angular 개발자가 되었습니다. 모두 지옥에 갈 것입니다.

머지 않아 그들은 모두 같은 아버지인 프로그래머에게서 왔다는 사실을 잊었습니다. 세상을 더 나은 곳으로 만들고 싶었던 단순하고 평화로운 과학자. 서로가 '프로그래머'의 진정한 후손이며, 자신의 혈통이 누구보다 순수하다고 주장하며 서로 싸우기 시작했다.

시간이 지나면서 그들은 상호작용을 최소한으로 줄이고 꼭 필요한 경우에만 서로 이야기를 나눴습니다. 그들은 먼 가족의 성공을 축하하는 것을 그만두었고 결국 때때로 엽서를 보내는 것을 중단했습니다.

자신의 감정만 살피면 프로그래머의 불꽃이 은하계에 빛나고 평화를 가져오기를 기다리는 마음 속에 있다는 것을 알게 될 것입니다.

세계를 정복하기 위한 이기적이고 자기 중심적인 경쟁에서 프로그래머의 후손들은 클라이언트를 위해 문제를 해결하는 것 자체의 목적을 잊었습니다. 클라이언트는 프로젝트가 지연되거나 너무 비싸거나 심지어 실패하는 것과 같은 행동의 고통을 느끼기 시작했습니다.

이따금 밝은 별이 빛나고 누군가는 영감을 받아 자손들 사이에 평화를 만들려고 노력할 것입니다. 그들은 폭포를 생각해 냈습니다. 서로 다른 개발자 그룹이 필요할 때만 의사 소통을 한다는 사실을 활용했기 때문에 이것은 기발한 아이디어였습니다. 한 그룹이 작업의 일부를 마치면 다음 그룹과 통신하여 프로세스를 통해 작업을 전송하고 결코 뒤돌아보지 않았습니다.

이것은 잠시 동안 효과가 있었지만 평소와 같이 인간(클라이언트)은 다시 더 많은 것을 원했습니다. 그들은 소프트웨어를 만드는 전 과정에 더 적극적으로 참여하고, 더 자주 의견을 제시하고, 너무 늦더라도 변경을 요청하기를 원했습니다.

소프트웨어 프로젝트는 실패하기 쉽기 때문에 산업 표준으로 받아들여졌습니다. 통계에 따르면 프로젝트의 50% 이상이 실패하고 있으며 이에 대해 할 수 있는 조치가 없는 것 같습니다(ZDNet, CNet).

모든 세대에는 이러한 모든 개발자 그룹이 클라이언트가 가능한 최상의 솔루션을 받을 수 있도록 함께 작업하고 의사 소통하고 유연하게 대처할 수 있는 방법을 찾아야 한다는 것을 알고 있는 열린 마음을 가진 소수의 개인이 있었습니다. 이러한 시도의 흔적은 이미 1957년에 위대한 John Von Neumann의 동료들에 의해 이루어졌습니다. 그러나 우리는 혁명을 시작하기 위해 2001년 초까지 기다려야 했습니다. 더러운 수십 명이 Agile Manifesto를 만들었습니다.

Agile Manifesto는 12가지 원칙을 기반으로 합니다.

1. 가치 있는 소프트웨어를 조기에 지속적으로 제공하여 고객 만족
2. 개발 후반에도 변화하는 요구 사항 환영
3. 작업 소프트웨어가 자주 제공됨(몇 개월이 아닌 몇 주)
4. 비즈니스 사람과 개발자 간의 긴밀하고 일상적인 협력
5. 프로젝트는 신뢰할 수 있는 동기 부여된 개인을 중심으로 구축됩니다.
6. 면대면 대화가 최고의 커뮤니케이션 수단(코로케이션)
7. 작동하는 소프트웨어는 진보의 주요 척도입니다
8. 지속 가능한 발전, 일정한 속도를 유지할 수 있음
9. 기술적 우수성과 좋은 디자인에 대한 지속적인 관심
10. 하지 않은 일의 양을 최대화하는 기술인 단순성은 필수적입니다.
11. 자기 조직화 팀
12. 변화하는 상황에 대한 정기적인 적응

애자일 선언문은 은하계에 평화를 가져오고 포스에 균형을 회복하는 첫 번째 큰 단계였습니다. 아주 오랜 시간 동안 소프트웨어 개발 과정에서 모든 이해 관계자를 연결하는 것은 절차적이고 기계적인 방식뿐 아니라 문화적이고 "인간적인" 방식을 기반으로 했습니다. 사람들은 서로 이야기하기 시작했고 정기적으로 만나 항상 아이디어와 의견을 교환했습니다. 그들은 그들이 생각했던 것보다 훨씬 더 많은 공통점이 있다는 것을 깨달았고, 고객은 단순히 돈을 보내고 질문을 하지 않는 외부 요인이 아니라 팀의 일부가 되었습니다.

아직 넘어야 할 산이 많지만 앞날은 그 어느 때보다 밝았다. 민첩하다는 것은 개방적이고 끊임없는 변화에 기꺼이 적응하는 것을 의미합니다. 그러나 너무 많은 변화로 인해 궁극적인 목표와 전달에 집중하기가 어렵습니다. 이것이 린 소프트웨어 개발이 실현된 방법입니다.

LSD(말장난 의도)에 빠져 추방당하고 추방될 위험을 무릅쓰고 일부 후손은 자신의 카스트 및 소프트웨어 산업 외부에서 솔루션을 찾았습니다. 그들은 주요 자동차 제조업체의 작업에서 구원을 찾았습니다. 도요타 생산 시스템은 단순하다는 점에서 놀랍고 린 제조 방식이 소프트웨어 개발에 쉽게 적용될 수 있다는 것이 너무도 명백했습니다.

린에는 7가지 원칙이 있습니다.

1. 낭비 제거
2. 품질 구축
3. 지식 생성(학습 확대)
4. 약속 연기(가능한 한 늦게 결정)
5. 최대한 빨리 전달
6. 사람 존중(팀 역량 강화)
7. 전체 최적화

애자일 위에 추가된 린(Lean) 원칙은 사고 방식과 올바른 일을 하는 데 집중하는 동시에 전체 프로세스 동안 유연하게 지원합니다.

소프트웨어 개발 팀에서 Agile과 Lean을 채택한 후 전체 원칙 집합을 IT 전체에 적용하는 데 한 단계만 더 거치면 마침내 DevOps가 탄생했습니다!

DevOps 진입 - 3차선 고속도로

소프트웨어 개발 팀에 대한 구식 관점에는 비즈니스 분석가, 시스템 설계자, 프론트엔드 개발자, 백엔드 개발자, 테스터 등이 포함됩니다. 애자일 및 린 원칙을 포함하여 소프트웨어 개발 프로세스를 최적화하는 데 주로 중점을 두었습니다. 애플리케이션이 "프로덕션 준비"되면 시스템 엔지니어, 릴리스 엔지니어, DBA, 네트워크 엔지니어, 보안 전문가 등을 포함하는 "운영"으로 전달되었습니다. DevOps 와 Ops 사이의 장벽을 제거하는 것이 DevOps 의 주요 원동력입니다.

DevOps는 전체 IT 가치 흐름에 린 원칙을 구현한 결과입니다. IT 가치 흐름은 원래 프로그래머의 후손인 모든 '먼 친척'을 결합하여 개발을 프로덕션으로 확장합니다.

DevOps 솔루션에 대한 가장 좋은 설명은 Gene Kim이 제공하며, Phoenix Project 를 읽지 않았다면 시간을 내어 읽어보는 것이 좋습니다.

DevOps 엔지니어를 고용해서는 안 되며 DevOps는 IT의 새로운 부서가 되어서는 안 됩니다. DevOps는 문화이자 사고 방식이며 IT 전체의 일부입니다. IT를 DevOps 조직 으로 만드는 도구는 없으며 자동화 수준도 팀이 고객에게 최대 가치를 제공할 수 있도록 지원하지 않습니다.

DevOps는 보통 3가지 방법이라고 하는데, 저는 그것들을 같은 고속도로의 3차선으로 봅니다. 1차선에서 출발하여 속도를 높이고 2차선으로 바꾸면 결국 3차선에서 과속하게 됩니다.

• 1차선 - 전체 시스템의 성능이 주요 초점이며 시스템의 개별 요소 성능보다 강조됩니다.

• 레인 2 - 업스트림으로 전송된 일정한 피드백 루프가 있는지 확인하고 무시되지 않습니다.

• 3차선 - 실험을 육성하고, 지속적으로 개선하고, 빨리 실패합니다.

1차선 - 속도 향상

전체 시스템의 중요성을 이해하고 작업 항목의 우선 순위를 적절하게 지정하는 것은 IT 조직이 DevOps 원칙을 채택할 때 배워야 하는 첫 번째 사항입니다. IT 가치 흐름의 그 누구도 병목 현상을 만들고 작업 흐름을 줄이는 것이 허용되지 않습니다.

중단 없는 워크플로를 보장하는 것은 프로세스에 포함된 모든 사람의 궁극적인 목표입니다. 개인이나 팀의 역할에 관계없이 시스템에 대한 깊은 이해를 얻으려는 노력은 필수적입니다. 이러한 사고 방식을 채택하면 병목 현상을 일으킬 수 있으므로 결함이 스트림으로 전송되지 않으므로 품질에 직접적인 영향을 미칩니다.

작업이 지연되지 않는지 확인하는 것만으로는 충분하지 않습니다. 생산적인 조직은 항상 흐름을 증가시키기 위해 노력해야 합니다. 흐름을 증가시키는 수많은 방법론이 있습니다. 제약 조건 이론, 식스 시그마, 린 또는 도요타 생산 시스템에서 솔루션을 찾을 수 있습니다. 이 중 하나를 선택하거나, 직접 만들거나, 결합하십시오.

DevOps 원칙은 귀하가 시스템 설계자, DBA, QA 또는 네트워크 관리자인 경우 어떤 팀에 속하는지 상관하지 않습니다. 동일한 규칙이 모든 사람에게 적용되며 모든 사람은 두 가지 간단한 원칙을 따라야 합니다.

• 시스템 흐름을 중단 없이 유지
• 항상 워크플로를 늘리고 최적화합니다.

레인 2 - 기어 업

중단 없는 시스템 흐름은 단방향이며 개발에서 운영으로 이동할 것으로 예상됩니다. 이상적인 세계에서 이것은 소프트웨어가 고품질로 신속하게 생성되고 프로덕션에 배포되며 고객에게 가치를 제공한다는 것을 의미합니다.

그러나 DevOps는 Utopia가 아니며 단방향 전달이 가능하다면 폭포수 방식으로 충분할 것입니다. 결과물을 평가하고 흐름을 전달하는 것은 품질을 보장하는 데 매우 중요합니다. 구현해야 하는 첫 번째 "업스트림" 통신 채널은 Ops to Dev입니다.

자신에게 하이파이브를 하는 것은 쉽지만 피드백을 요청하고 피드백을 제공하는 것이 실제 그림을 보는 방법입니다. 각각의 작은 다운스트림 단계 뒤에는 즉각적인 업스트림 확인이 따라야 합니다.

피드백 루프를 설정하는 방법은 중요하지 않습니다. 개발자를 지원 팀 회의에 초대하거나 네트워크 관리자를 주간 스프린트 계획에 초대할 수 있습니다. 피드백이 준비되고 의견이 선택되고 처리되는 한 조직은 DevOps 고속도로를 가속화하고 있습니다.

레인 3 - 워프 10

DevOps 빠른 차선은 마음이 약한 사람들을 위한 것이 아닙니다. DevOps 패스트 레인에 진입하려면 조직이 충분히 성숙해야 합니다. 위험을 감수하고 실패로부터 배우고, 지속적으로 실험하고, 반복과 연습이 숙달의 전제 조건이라는 것을 받아들이는 것입니다. 꽤 자주 Kata라는 말을 듣게 되는데, 여기에는 이유가 있습니다. 지속적인 훈련과 반복은 복잡한 동작을 일상으로 만들기 때문에 숙달로 이어집니다.

그러나 움직임을 결합하기 시작하기 전에 먼저 각 개별 단계를 마스터하는 것이 중요합니다.

“스승에게 합당한 것은 수련자에게 합당하지 않다. 구조를 초월하기 전에 도를 이해해야 합니다.”

DevOps Third Way/Fast Lane에는 매일 지속적인 실험을 위한 시간 할당, 위험을 감수하는 팀에 지속적으로 보상, 시스템에 결함을 도입하여 탄력성을 높이는 것이 포함됩니다.

이러한 종류의 조치를 구현할 때 조직이 붕괴되지 않도록 하려면 모든 병목 현상이 명확하고 시스템 흐름이 중단되지 않는지 확인하면서 모든 팀 간에 빈번한 피드백 루프를 생성해야 합니다.

이러한 조치를 구현하면 조직이 항상 경고를 받고 문제에 빠르고 효과적으로 대응할 수 있습니다.

요약 - DevOps 조직 체크리스트

다음은 IT 조직에서 DevOps를 지원 하는 방법을 검증하는 데 사용할 수 있는 체크리스트입니다. 기사에 자유롭게 댓글을 달고 자신의 요점을 추가하십시오.

• 개발팀과 운영팀 사이에는 벽이 없습니다. 둘 다 동일한 프로세스의 일부입니다.
• 한 팀에서 다른 팀으로 전달되는 작업은 항상 검증되고 최고 품질입니다.
• 작업의 "겹침"이 없으며 모든 병목 현상이 처리됩니다.
• 배포 및 유지 관리가 동일한 시간 상자의 일부이기 때문에 개발 팀은 활동에 운영 시간을 사용하지 않습니다.
• 개발 팀은 금요일 오후 5시에 배포용 코드를 제공하지 않으며, 주말 동안 작업을 정리해야 합니다.
• 개발 환경이 표준화되고 운영이 쉽게 재현하고 프로덕션으로 확장할 수 있습니다.
• 개발 팀은 적절하다고 판단되면 새 버전을 제공할 수 있고 운영팀에서 이를 프로덕션에 쉽게 배포할 수 있습니다.
• 모든 팀 간에 명확한 커뮤니케이션 라인이 있습니다.
• 모든 팀원은 시스템 개선을 위해 실험하고 작업하는 시간을 가집니다.
• 결함은 정기적으로 시스템에서 도입(또는 시뮬레이션)되고 처리됩니다. 각 실험에서 얻은 교훈은 문서화되어 모든 관련 사람들과 공유됩니다. 사고 처리는 일상적이며 대부분 알려진 방식으로 처리됩니다.

결론

Chef, Docker, Ansible, Packer, Troposphere, Consul, Jenkins, SonarQube, AWS 등과 같은 최신 DevOps 도구 를 사용한다고 해서 DevOps 원칙을 적용하는 것은 아닙니다. DevOps는 사고 방식입니다. 우리는 모두 같은 프로세스의 일부이며 같은 시간을 공유하고 함께 가치를 전달합니다. 소프트웨어 제공 프로세스에 참여하는 모든 사람은 전체 시스템의 속도를 높이거나 낮출 수 있습니다. 개발 중에 생성된 버그로 인해 시스템이 다운되고 잘못된 방화벽 구성이 발생할 수 있습니다.

모든 사람이 DevOps의 일부이며 조직이 이를 이해하면 관리에 도움이 되는 도구와 기술 스택이 마술처럼 나타날 것입니다.