황소와 버즈 분리: 자동화하지 말아야 할 것

당신이 DevOps 리드, 사이트 안정성 엔지니어, IT 관리자 또는 CTO인지 여부에 관계없이 자동화 는 당신이 하는 일에 거의 뿌리를 내리고 있습니다.

여러 면에서 자동화와 DevOps라는 용어는 동의어입니다. 그리고 최근 몇 년 동안 무언가를 자동화하는 것을 목표로 하는 솔루션에는 거의 끝이 없기 때문에 용어가 점령된 것처럼 느껴집니다.

Red Hat의 최근 보고서에 따르면 기업은 클라우드 운영의 평균 36%를 자동화했습니다. 비즈니스가 설립된 기간이 길수록 수동 프로세스가 자동화된 워크플로우로 대체되었습니다.

자동화 인기가 높아지는 데는 여러 가지 이유가 있습니다.

• 회사는 미션 크리티컬 작업에 초점을 맞춘 개발 작업을 원합니다.
• 출시 일정을 단축하려는 욕구
• 리더는 팀의 더 많은 민첩성과 협업을 원합니다.
• 수동 시스템은 인적 오류가 발생하기 쉬운 것으로 악명이 높습니다.
• IT, SRE 및 DevOps 역할에 대한 수요가 이를 채울 사람보다 더 많습니다.

자동화 – 유행어 이상?

Rewind는 최근 자동화 경험, 자동화가 팀의 목표에 어떻게 부합하는지, 의사 결정을 위해 사용하는 프레임워크에 대해 다양한 소프트웨어 개발 리더와 함께 자리를 잡았습니다.

One Trust의 Tugboat Logic의 CTO인 Scott Sturgeon은 회의적입니다. “제 관점에서 자동화는 유행어가 되었습니다. 모든 것이 정상적인 방식으로 자동화될 수는 없습니다. 모든 것이 그런 것은 아닙니다. 반복적이고 시간이 많이 걸리는 일에 집중하는 경향이 있습니다. 요즘 듣는 대부분의 자동화는 CI/CD(지속적인 통합, 지속적인 배포)로 귀결됩니다. 프로덕션 인스턴스를 자동으로 업데이트할 수 있는 매우 복잡한 파이프라인을 구축할 수 있습니다. 제대로 설정했다면 훌륭합니다.”

“자동화는 매우 일반적인 용어이며 실제로 무엇을 하려는지 더 구체적으로 설명해야 합니다. Puppet의 Field CTO인 Nigel Kersten은 설명합니다. 자동화를 위해 자동화하는 것이 아니라 결과를 얻기 위해 자동화하는 것입니다. 또한 '로봇이 하게 만들 수 있다'고 생각하는 현장 사람들에게 공감을 주기 때문에 좋은 마케팅 유행어라고 생각합니다. 따라서 그 단어를 어떻게 사용하는지에 대해 신중해야 합니다.”

이 주의 사항을 염두에 두고 자주 과도하게 자동화되거나 자동화로 인해 불필요하게 복잡해지는 몇 가지 주요 작업이 있습니다.

자동화 하지 말아야 할 것

대부분의 작업을 자동화할 수 있지만 자동화해야 한다는 의미는 아닙니다. 다음은 자동화 대상 목록에서 제거할 수 있는 항목에 대한 몇 가지 빠른 팁입니다.

• 필요한 노력이 큰 수익을 내지 못하는 투자 수익이 낮은 작업
• 사용자 경험 테스트 또는 주관적인 결과가 있는 모든 것
• 매우 높은 수준의 예측 불가능성이 있는 작업
• 반복성이 낮은 작업
• 잘 정의된 절차/패턴이 없는 작업

“컴퓨터가 잘 할 수 없는 일을 자동화하면 안 됩니다. 예를 들어 많은 회사에서 코드 검토를 자동화하려고 시도하고 있습니다.”라고 Scott은 설명합니다. “구문이나 이상한 순환 종속성을 따르는 작업에 적합합니다. 컴퓨터는 그 내용을 알아낼 수 있습니다. 그러나 코드 조각의 논리와 그것이 제대로 수행되었는지 여부를 보는 것은 컴퓨터가 잘할 수 있는 일이 아닙니다. 내 생각에 코드 리뷰는 여전히 사람이 봐야 합니다.”

Rewind의 CTO인 James Ciesielski는 개발 자동화에 대한 위험 기반 접근 방식을 확장합니다. “무엇을 자동화할지 결정할 때 우리는 프로세스 유지 관리에 사람을 참여시키는 위험을 평가합니다. 사람들이 개발 팀에 신과 같은 권한을 부여받은 개발 환경을 보았습니다. 종종 이것은 고객에게 서비스를 제공한다는 명목으로 이루어지지만 사람들은 의도적이든 의도하지 않든 오류를 범합니다.”

자동화가 필요한 항목을 결정하는 방법

현실은 많은 기업이 제품이나 서비스에 직간접적으로 영향을 미치는 것들을 자동화해야 한다는 것입니다. 특히 시장 경쟁이 치열해지고 더 많은 SaaS 회사가 온라인에 진출하고 로드맵이 더 야심차게 되면 모든 환경에서 고유한 사용 사례가 발생할 수 있습니다. 그러나 지구상의 모든 개발 팀이 말하듯이 할 일 목록은 엄청나게 깁니다. 팀으로서 다음에 처리할 작업의 우선순위를 어떻게 정하고 합의합니까?

결정에 대한 천편일률적인 접근 방식은 없지만 IT 전문가가 프로세스가 자동화에 적합한지 여부를 평가하는 데 사용하는 몇 가지 신호는 다음과 같습니다.

• 수동 : 작업을 자동화하는 스크립트를 수동으로 실행하는 것과 같습니다. 각 수동 단계를 실제로 실행하는 것보다 스크립트가 더 빠를 수 있지만 스크립트를 실행하는 데 걸리는 시간은 여전히 ​​다른 곳에서 사용할 수 있는 시간입니다. 다시 말해 버튼을 계속 눌러야 한다면 결국 그 버튼을 누르는 데 모든 시간을 허비하게 될 수도 있습니다.
• 반복 : 동일한 작업을 두 번 정도 수행한 후에는 자동화가 필요할 수 있습니다. 새로운 문제를 해결하는 것은 중요하지 않습니다.
• 자동화 가능 : 기계가 사람처럼 같은 일을 할 수 있다면 수고로 간주할 수 있습니다. 작업에 실제로 사물에 대해 생각하기 위해 사람이 필요한 경우 좋은 후보가 아닐 수 있습니다.
• 전술적 : 무언가가 계속 팀을 방해하고 "반응" 모드에 빠지게 하는 경우 이러한 방해 요소를 최소화하는 것이 해결해야 할 사항이 될 수 있습니다.
• 지속적인 가치 없음: 작업을 수행했는데 제품이나 서비스가 동일하게 유지된다면 아마도 수고에 기여하고 있을 것입니다.
• 운영 규모가 커짐에 따라 작업도 늘어남: 서비스 크기, 트래픽 양 또는 사용자 수에 따라 작업 규모가 커지면 문제일 가능성이 높습니다.

결국 좋은 시작점은 자주 수행하고 사람에게 의존하는 프로세스(가치를 추가하는)를 찾는 것입니다. 사람들이 관련되면 오류 가능성이 기하급수적으로 높아집니다.

OwnBackups의 DevOps 팀 리더인 Lena Feygin은 ': automatic_all_the_things: .'에 대한 욕구에 대해 주의와 신중함을 강조합니다. 그녀의 조언? "결국 실제로 문제를 일으키는 문제만 자동화하면 되고 존재하지 않는 문제는 수정하지 않아도 됩니다."

DevOps 전문가의 자동화에 대한 전문적인 조언을 찾고 계십니까? 개발 작업의 자동화에 대한 전체 가이드를 다운로드하세요. 완전 무료입니다.