격차 해소: DevOps 커뮤니케이션의 중요성

DevOps 방법론이 우리와 함께한 지 꽤 오래되었지만 여전히 열띤 토론의 중심입니다. 기업은 그것을 원하지만 어떻게 접근해야 할지 확신이 서지 않습니다.

DevOps는 어디에나 있습니다. 흥미로운 추세이긴 하지만 제품에 적합해야 하며 그 반대가 되어서는 안 됩니다.

그러나 어떤 사람들은 그렇게 보지 않습니다. “Docker를 사용하기 시작해야 합니까, 아니면 Kubernetes로 바로 뛰어야 합니까?”와 같은 질문을 자주 받습니다. 그런 질문은 제품이 무엇인지도 모르면서 무의미합니다.

클라우드, Kubernetes, 컨테이너, 구성 관리, 코드로서의 인프라와 같은 멋진 용어는 모두 개선을 약속합니다. 그러나 망원경이 천문학과 마찬가지로 DevOps에도 적용됩니다. 그것들은 유용할 수 있지만 필요하지는 않습니다.

기본적으로 DevOps는 클라이언트가 주문한 것과 개발 팀이 제공한 것 사이의 격차를 줄이는 것을 목표로 합니다. 짧은 릴리스 주기, 반복적인 설계 접근 방식, 반복적인 단계의 자동화에 중점을 둡니다. 그것들을 현실로 만들기 위해 가장 중요한 것은 무엇이라고 생각합니까?

"훌륭한 의사 소통"이라고 말하면 맞습니다. 도구는 다 괜찮습니다. 그러나 그들은 의사 소통을 개선할 때 투자한 돈의 가치가 있습니다.

의사 소통의 한 측면은 작업을 완료하는 데 필요한 것이 무엇인지 아는 것입니다. 그리고 작업은 "코드가 저장소에 커밋됨"을 의미하지 않습니다. "고객이 생산의 변화를 보고 받아들였다"라고 생각하십시오.

이 첫 번째 단계가 결정되고 모든 사람이 무슨 일이 일어나야 하는지 알게 되는 즉시 그것을 기록하기에 가장 좋은 시기입니다. 어디에? 글쎄요, 저는 README.md 를 유지하는 것을 강력히 지지합니다. 팀의 각 사람은 항상 내부를 들여다보고 프로젝트의 상태를 알 수 있으며 이는 프로젝트를 처음 접하는 사람들에게 자연스러운 일입니다.

README 작성 후 다음 단계인 자동화는 선택 사항입니다. 그러나 이는 프로세스를 문서화하는 자연스러운 결과입니다. 그리고 예, 자동화는 DevOps에 대해 생각할 때 종종 생각나는 것입니다.

잠시만요... DevOps에서 자동화는 선택 사항입니까? DevOps는 배포하는 사람의 부서가 아닌가요?

사람들이 일반적으로 "DevOps 엔지니어"라는 용어로 이해하는 것은 소프트웨어 안정성 엔지니어, 플랫폼 엔지니어 또는 운영 자동화 엔지니어입니다. 이들은 모두 DevOps를 연습할 수 있는 유효한 역할이지만 "DevOps 엔지니어"라는 집합적인 용어를 사용하는 것은 다소 모호할 수 있습니다.

이제 DevOps 자체에 대해 자세히 살펴보겠습니다.

DevOps 설명

먼저 DevOps가 아닌 것을 보여드리겠습니다.

1. 단순한 직책 접두사가 아닙니다.
2. 팀이 아닙니다(그러나 "Dev"와 "Ops"는 팀입니다)
3. 그것은 기술이 아니다
4. "코딩할 수 있는 시스템 관리자"를 의미하지 않습니다.
5. "자동화"를 의미하지 않습니다.
6. "지금 운영팀이 없다"는 뜻은 아닙니다.

이 사실을 알면, 미래 경쟁력을 확보하기 위해 회사에서 단순히 "DevOps 엔지니어를 고용"하거나 "DevOps 팀을 구성"할 수 없다는 것을 알게 되었습니다. DevOps는 Agile 개발과 유사합니다. 그런 애자일 개발자를 고용하시겠습니까? 아마 아닐 것입니다. 애자일 방식으로 제품을 개발하거나 개발하지 않습니다.

그렇다면 DevOps는 어떻게 설명될 수 있습니까? 방법론입니다. 아니면 문화일 수도 있습니다. 어쩌면 영혼일 수도 있습니다. DevOps 원칙에 따라 제품을 만든다는 것은 개발자, 운영 엔지니어, 제품 관리자 등 모든 사람이 공통의 비전을 공유하고 커뮤니케이션을 통해 이를 유지한다는 것을 의미합니다. 정도는 덜하지만 모든 사람이 동일한 도구를 사용한다는 의미이기도 합니다. 이러한 도구는 단일 그룹의 사람들을 돕기 위한 것이 아닙니다. 그들은 제품을 앞으로 밀기위한 것입니다.

이 개념을 사용하려면 심각한 사고 방식의 변화가 필요하며 이것이 주요 장애물입니다. 왜 그런 겁니까? 사람들이 자신의 안락함에서 벗어나 다른 역량을 가진 사람들과 협업을 시작해야 하기 때문입니다. 개발자는 갑자기 클라우드가 어떻게 작동하는지 배우고 자신의 코드를 배포하기 시작해야 합니다. 운영 담당자는 수동 설정을 포기하고 코딩을 시작해야 합니다. 모든 사람은 새로운 개념을 배워야 합니다. 모든 사람에게는 새로운 책임 이 있습니다.

쉽지는 않지만 좋은 의사 소통과 공동의 목표가 있다면 충분히 달성할 수 있습니다. 이 커뮤니케이션에는 문화 확립, 간단한 프로세스 설정, 적절한 문서 유지 관리가 포함됩니다.

DevOps 자동화는 문서화입니다

당신은 아마 그런 식으로 생각한 적이 없습니다. 그러나 일반적으로 DevOps와 관련된 대부분의 도구는 문서 도구 입니다.

• 가독성을 위해 작성된 빌드 스크립트 는 빌드 프로세스를 문서화하는 데 사용됩니다.
• 지속적인 통합 파이프라인 은 단일 부품 구축에서 전체 제품에 이르는 통합 프로세스를 문서화합니다.
• 클라이언트가 사용할 수 있는 제품을 배포하는 방법을 문서화하여 지속적 배포 파이프라인 을 확장합니다.
• 구성 관리 파일 은 설치 및 구성 프로세스를 문서화합니다.
• 코드로서의 인프라 사양 은 필요한 인프라를 문서화합니다(사실상 매우 형식적입니다!)
• 컨테이너에는 주어진 마이크로서비스를 구축하고 구성하는 방법을 문서화하는 자체 Dockerfile 과 함께 제공됩니다.

이 모든 멋진 개념은 기본적으로 한 가지 역할을 합니다. 프로세스를 문서화하여 팀 구성원이 더 잘 의사 소통할 수 있도록 도와줍니다. 그런 다음 이러한 프로세스를 수동으로 실행하거나 자동화할 수 있습니다. 중요한 것은 프로젝트의 모든 이해 관계자가 그들을 따를 수 있다는 것입니다.

프로세스를 코드로 문서화하면 일반적인 사용 설명서보다 한 가지 큰 이점이 있습니다. 코드를 확인하고 예측할 수 있습니다. 동일한 입력이 주어지면 동일한 출력을 생성합니다.

서면 지침을 사용하면 독자 수만큼 다양한 해석을 할 수 있습니다. 모호하거나 모호한 문서를 작성하면 읽는 사람이 그 공백을 채울 것입니다. 요점은 빈틈에 들어가는 것을 통제할 수 없다는 것입니다.

코드를 사용하면 훨씬 간단합니다. 구체적인 단계가 없으면 프로그램 실행이 중지됩니다. 이러한 구체적인 단계는 DevOps 커뮤니케이션의 주요 측면 중 하나입니다.

DevOps 커뮤니케이션: 개발과 운영 간의 격차를 해소하는 유일한 방법

The Phoenix Project라는 책에서 우리는 최근에 승진한 한 관리자가 큰 프로젝트를 수행하는 임무를 맡은 문제를 목격합니다. 무슨 일이 일어나고 있는지 아무도 모르기 때문에 모두가 별 진전 없이 화재와 싸우고 있습니다. 책 부제에는 DevOps의 이야기라고 나와 있습니다. 나는 그것에 동의합니다.

그러나 흥미로운 점은 이 책이 진행되는 동안 새로운 도구가 하나도 소개되지 않는다는 것입니다. 커뮤니케이션만 개선하면 DevOps 상태를 달성할 수 있습니까? 책의 주인공들이 해냈으니 여러분에게도 희망이 있습니다!

주인공의 접근 방식이 "구식"(적절한 버그 추적 시스템 대신 실제 종이 카드 사용)으로 간주될 수 있지만 모든 관련 당사자가 서로 이야기하기 시작하면 상황이 더 좋게 바뀌기 시작합니다.

서비스 수준 계약이나 사고 백로그와 같은 더 나은 인터페이스를 만들어 개발과 운영 간의 협업을 개선하는 것이 가능하다고 생각할 수도 있습니다. 그러나 그 반대가 사실입니다. 인터페이스를 허물고 공감과 공동의 원인을 소개함으로써 공동의 목표를 향해 일하는 팀을 갖게 될 것입니다.

DevOps 팀 구조: 팀에는 누가 있습니까?

이상적으로는 각 제품에는 제품 팀이라는 하나의 팀만 있어야 합니다.

나는 한때 다른 팀과의 공통 목표가 없는 개발 팀에 있었습니다. 개발 팀은 가능한 한 많은 변경 사항을 푸시하기를 원했습니다. 검증 팀은 결함 도입을 방지하는 임무를 맡았습니다. 그들은 다른 관리자가 있었고 개별적으로 평가되었습니다.

결과? 개발 및 검증은 결함 보고서와 핑퐁 게임을 했습니다. Validation이 통과하지 못하는 테스트를 발견했을 때 Development는 버그가 없는 자체 코드를 만드는 것보다 테스트 코드 자체에서 결함을 찾는 데 더 관심이 있었습니다.

물론 보고서, 반대 보고서 등을 적절하게 채우는 데 필요한 막대한 오버헤드가 있었기 때문에 릴리스 주기가 급증했습니다. 대부분이 인식하지 못하는 것처럼 보이는 것은 제품 측면에서 두 팀이 공통의 목표를 공유하고 이를 달성하기 위해 협력해야 한다는 것이었습니다. 그러나 적절한 협력과 고립된 사고방식의 부족으로 인해 알아차리기가 매우 어려웠습니다.

폐기물 퇴치를 위한 공동 노력

Manifesto for Agile Software Development(이를 통해 DevOps를 소개함)에 영감을 준 린 프로덕션 사고방식은 낭비와 싸우는 것이었습니다. 낭비란 고객이 주문한 것과 직접 관련이 없는 모든 것을 의미합니다. 쌓인 작업은 낭비입니다. 명확하게 방출로 이어지지 않는 프로세스의 모든 단계는 낭비입니다.

그러나 폐기물은 높은 수준에서만 볼 수 있습니다. 한 팀의 범위에서는 일부 절차가 필수적으로 보일 수 있습니다. 하지만 제품의 관점에서 보면 쓸모가 없을 수도 있습니다.

어떤 노력이 낭비되었는지 파악하려면 힘을 모아 배송된 제품의 수명 주기를 고려해야 합니다. 또한 고객의 입장에서 생각해야 합니다. 이 기능이 클라이언트가 원했던 것입니까? 그렇지 않은 경우 이 단계를 건너뛸 수도 있습니다. 프로세스가 간단하고 간결합니까? 특히 팀 경계를 넘는 사람들을 자세히 살펴보십시오.

제품 개발이 가능한 한 효율적인지 확인하고 싶습니까? 외부인을 초대하여 작업 방식을 확인하십시오. 팀에 속하지 않은 사람이 통찰력 있는 질문을 하고 개선할 새로운 영역을 찾아낼 수 있습니다.

DevOps 원칙: CALM 유지

CALMS는 DevOps를 실행하는 방법에 대한 매우 정확한 설명입니다.

• 문화
• 자동화
• 린
• 측정
• 에스 해링

샌드위치처럼 생겼습니다. 세 가지 중간 값은 더 기술적인 반면 외부 값은 소프트 스킬과 관련이 있습니다. 그러나 모든 문화의 기초는 의사소통입니다. 우리는 행동 방식에 대한 합의에 도달할 때까지 다른 팀원들과 우리의 가치와 신념을 교환합니다.

나눔도 마찬가지입니다. 음식과 같은 기본적인 것을 공유하는 데는 의사소통이 필요하지 않습니다. 그러나 제스처 자체는 의사 소통의 행위로도 볼 수 있습니다. "나는 당신을 돌보고 있으므로 당신과 공유합니다." 우리는 언어 커뮤니케이션에만 그 범위를 제한하고 싶지 않습니다.

그러나 아이디어와 도구를 공유하려면 의사 소통이 필요합니다. 어떻게 공유해야 할까요? 우리는 그것들을 어디에 둘 것인가? 팀의 모든 사람에게 유용한가요? 아니면 소규모 그룹에만 유용한가요?

자동화, 린(Lean), 측정(Measurement)과 같은 보다 기술적인 측면에만 집중한다면 DevOps의 핵심을 놓치고 있는 것입니다. 작성자 외에는 아무도 사용하지 않는 자동화된 배포 스크립트를 사용하는 것이 좋은 점은 무엇입니까? 스크립트가 시간을 절약해준다면 정당화될 수 있습니다. 그러나 모든 사람이 이 스크립트를 공유한다면 얼마나 많은 시간을 절약할 수 있을지 상상해 보십시오. 이것은 폐기물과 싸우는 것에 대해 말합니다!

DevOps는 비즈니스를 개발에 더 가깝게 만듭니다.

어떤 사람들은 DevOps가 운영을 개발에 더 가깝게 만든다고 말합니다. 이것은 사실이지만 전체 진실은 아닙니다. 제대로 완료되면 DevOps는 모든 단위를 더 가깝게 만듭니다. 이를 통해 비즈니스와 고객은 거의 실시간으로 개발 작업을 볼 수 있습니다.

이 짧은 피드백 루프는 모든 이해 관계자에게 이익이 됩니다. 작업은 일반적으로 더 눈에 잘 띄며 개발자도 클라이언트가 생성한 코드를 사용하는 방법을 쉽게 볼 수 있습니다. 기존 배포를 사용하면 누군가가 버그나 누락된 요구 사항을 알아차리기까지 몇 개월을 기다릴 수 있습니다. 지속적인 배포를 통해 모든 사람이 문제가 발생하는 즉시 대응할 수 있습니다. 개발자, 운영, 비즈니스 및 클라이언트는 한 방에 앉아서 현재 요구 사항에 따라 작업 응용 프로그램을 수정할 수 있습니다.

DevOps 도구가 먼저입니까? 다시 생각 해봐

물론 이를 가능하게 하려면 모든 도구가 필요합니다.

그러나 아무리 많은 도구도 회사 내에서 원활한 의사소통과 공감을 대신할 수 없습니다. 빌드 프로세스는 한 팀이 소유하고 제공된 코드는 다른 팀이 소유하는 제품을 본 적이 있습니다.

빌드 시스템의 문제는 일반적이었습니다. 개발자들은 그것을 사용하는 방법을 확신하지 못했습니다. 표준 도구를 기반으로 했지만 웹에서 사용할 수 있는 모든 문서가 무용지물이 될 정도로 맞춤화되었습니다.

모두가 상황을 개선하고 싶었지만 두 팀 사이에 이해가 없었습니다. 이는 양측이 상대방과 상의하지 않고 새로운 도구를 도입했음을 의미합니다. 이것은 간격을 좁히는 대신 간격을 넓힐 뿐입니다.

조직 내에서 DevOps 변환을 시작하려면 먼저 커뮤니케이션 방식을 개선하세요. 단순히 해결책을 가정하지 마십시오. 먼저 열린 마음으로 브레인스토밍하십시오. 그런 다음 예를 들어 도구 지원이 귀하의 요구에 충분하지 않다는 것을 알 수 있습니다. 그 때 현재 도구를 조정하거나 새로운 도구를 도입하는 것을 고려할 수 있습니다. 그렇지 않으면 원래 문제에 추가될 가능성이 높습니다.

DevOps를 구축하는 가장 빠른 방법은 무엇입니까? 더 나은 커뮤니케이션!

도입부에서 클라이언트가 종종 나에게 묻는 질문에 대해 언급했습니다. "Docker를 사용해야 합니까 아니면 Kubernetes로 바로 이동해야 하나요?" 이 기사를 읽고 나면 DevOps 사고 방식으로 몇 가지 준비 작업을 수행한 후에 그러한 질문에 가장 잘 답할 수 있다는 것을 알 수 있습니다.

제품 팀이 자체 및 클라이언트를 위한 DevOps의 이점을 이해하고 있다는 것을 안다면 팀과 클라이언트는 기대치를 설정하는 것으로 시작할 수 있습니다. 그런 다음 엔지니어는 개발 및 배포 모델을 파악할 수 있습니다. 마지막으로 어떤 도구가 필요한지 결정할 수 있습니다.

모든 요구 사항이 문서화되면 기술 선택이 훨씬 쉬워집니다.

저는 우리의 작업을 더 쉽고 관리하기 쉽게 만드는 모든 훌륭한 DevOps 자동화 도구를 지지합니다. 그러나 우리의 일상 업무는 사람들 과 함께 일하는 것입니다. 다른 기술 인증서를 받는 것보다 DevOps 모범 사례의 이 측면을 개선하는 데 시간을 투자합시다.