DevOps 구현이 자주 실패하는 이유 (및 해결 방법)

이 기사는 원래 데브옵스닷컴에 게시되었습니다. DevOps.com.업데이트 및 수정되었습니다.

“블록체인”, “빅 데이터”, “디지털 혁신”과 마찬가지로 “DevOps”라는 용어는 현재 대규모 조직의 IT 부서에서 떠오르는 또 다른 유행어입니다.

많은 기업들이 비즈니스 목표와 밀접하게 연계된 보다 정밀한 프로세스인 더 빠른 소프트웨어 개발 라이프사이클의 필요성을 (정확하게) 인식하고 있습니다. 이를 통해 개발 팀과 운영 기반 팀 간의 더 명확한 워크플로우와 협업이 가능합니다.DevOps는 근본적으로 “애자일” 개발이며, 모두 성장하여 현대 비즈니스의 끊임없이 혁신하고 빠르게 배포되는 요구 사항을 충족할 준비가 되어 있습니다.보안 전문가에게는 환상적인 이니셔티브입니다. 훨씬 더 일찍 프로세스에 보안을 도입하여 버그 수정 비용을 줄이고 향후 발생할 수 있는 재앙을 방지할 수 있기 때문입니다.

문제는 DevOps 구현에 진정으로 성공한 회사가 거의 없다는 것입니다. 비즈니스 전반에 걸친 적절한 지원, 육성 및 이해가 없다면 기업은 순식간에 백상아리로 전락할 수 있습니다. 아시다시피 전쟁은 말할 것도 없는 프로젝트 중 하나입니다.

그렇다면, 무엇이 문제일까요? 흥미로운 논의인데, DevOps에 접근하는 몇 가지 방법이 있으며, 이를 통해 훨씬 더 원활한 운영을 할 수 있을 것으로 생각합니다. 효과적인 프로그램은 몇 가지 멋진 새 도구, 타이틀, 팀 회의를 넘어섭니다. 항상 쉽지만은 않겠지만, 시간을 들여 잘못된 전략을 고치거나 처음부터 올바른 방법으로 구현하는 것이 장기적으로는 훨씬 덜 고통스러울 것입니다. 그리고 궁극적으로는 소프트웨어 품질이 향상되고 보안이 강화될 것입니다.

자세히 설명해 드리겠습니다.

"애자일" 에이프런 끈을 풀어주세요.

조직이 애자일과 DevOps 중 하나를 선택해야 한다는 오해가 있습니다. 한 가지 경로 또는 다른 경로를 설정하고 절대 뒤돌아보지 않아야 한다는 오해가 있습니다.

문제는 개발 프로세스가 둘 다 하나로 고려되고 구현될 때 가장 잘 작동한다는 것입니다.DevOps는 애자일 개발의 혁신이 아닙니다. 오히려 애자일 개발의 연장선입니다.프로세스가 순조로울 것으로 예상되면 바퀴가 빠지는 경향이 있습니다. 정확히 같은 애자일에서, 또는 완전히 다른 애자일에서.

애자일은 처음부터 디자이너, 테스터, 개발자를 하나로 모으고 프로젝트 전반에 걸쳐 개방형 커뮤니케이션 라인을 구축함으로써 부서 간 팀의 원칙을 뒷받침합니다. 목표는 사일로화된 전달을 중단하고 이중 처리를 줄이는 것인데, 이 두 가지 모두 DevOps 프로세스의 이점이기도 합니다.그러나 DevOps는 한 걸음 더 나아가 시스템, 보안 및 운영을 통합하여 고객에게 완전하고 기능적인 소프트웨어를 제공한다는 궁극적인 목표를 가진 강력하고 종합적인 기술을 제공합니다.

데브옵스 중심 프로세스로 전환하면서 피할 수 없는 골칫거리가 생기면 사일로화된 개발의 위험이 다시 발생할 수 있습니다. 보안 및 운영 추가 기능이 아직 제대로 구현되지 않은 상태에서 기존 애자일 팀이 함께 작업하는 경우가 많습니다. 이를 어떻게 포함시킬지, 무엇을 해야 하는지, 전반적인 목표를 정확히 아는 사람은 아무도 없습니다.

DevOps는 명확히 정의된 목표, 부서 간 온보딩, 모든 당사자와의 직접적인 커뮤니케이션 없이는 작동하지 않습니다. 물론 조정 기간에는 세심한 변경 관리가 필요하겠지만, DevOps 기능이 가져올 개선 사항을 모두가 동일한 이해를 바탕으로 업무를 수행할 수 있도록 하는 것만으로도 충분합니다.

DevOps는 프로세스의 일부로서 보안 모범 사례에 중점을 두고 있으며, 이를 통해 해당 단계를 쉽게 설명하고 보안 팀과 다른 모든 직원 간의 격차를 좁히고 있습니다. 앞서 말했듯이 개발자가 처음부터 안전하게 코딩할 수 있도록 하려면 아직 갈 길이 멀지만 DevOps 방법론의 성공적인 구현은 개발 팀 내에서 보안 기술을 구축할 수 있는 훌륭한 토대입니다.

자동화가 전부는 아니며 가장 안전한 것도 아닙니다.

DevOps 방법론의 또 다른 특징은 소프트웨어 개발 프로세스의 자동화입니다. 지속적 통합 및 지속적 전달(CI/CD) 원칙은 이 개념의 초석이며, 짐작할 수 있듯이 도구에 크게 의존합니다.

도구는 정말 훌륭합니다. 코드 리포지토리, 테스트, 유지 관리 및 스토리지 요소를 비교적 원활하게 관리하여 소프트웨어 전달 프로세스를 전례 없이 빠르게 수행할 수 있습니다.

하지만 로봇이 우리의 모든 일자리를 빼앗아 언젠가는 우리를 감옥에 가둘 수도 있겠지만, 로봇은 아직 그 자리에 있지 않습니다. 도구와 자동화에 대한 의존도가 높으면 오류가 발생할 수 있는 창구가 활짝 열려 있습니다.스캔과 테스트로는 모든 것을 확인할 수 없고, 코드가 검사되지 않을 수 있으며, 이로 인해 엄청난 품질 (보안은 말할 것도 없고) 문제가 발생할 수 있습니다. 공격자는 백도어 하나만 있으면 악용하여 데이터를 훔칠 수 있습니다. 품질 및 보안 관리에서 인적 요소를 포기하면 심각한 결과를 초래할 수 있습니다.

“행복한 매체”는 사람들의 균형을 유지하는 것입니다. 도구 . 도구는 프로젝트 목표를 달성하기 위해 신뢰할 수 있는 팀의 보조 역할을 해야 합니다. 다음을 실천해야 합니다.

• 사람들이 선택한 DevOps 툴체인에 익숙해질 수 있도록 충분한 시간을 할당하십시오.
• 효과적인 협업(및 도구가 이를 지원하는 방법)에 집중
• 기술/지식이든 도구 기반이든 관계없이 프로세스의 모든 격차를 해결하십시오.

간단히 말해서, 그냥 “도구”를 들고 최선을 다하기를 바라지 마십시오.

DevOps는 유행어가 아니라 문화입니다. 성장시키고 계신가요?

변화 관리는 기껏해야 어려운 일입니다. 미지의 것에 대한 두려움은 아무리 뛰어난 팀원이라도 기술을 연마하고 시야를 넓히는 데 방해가 될 수 있습니다.

아시다시피, 단순히 “DevOps를 해봅시다”라고 말하고 운영팀이 책상을 옮기도록 만든다고 해서 마술처럼 성공적인 프로세스가 구현되는 것은 아닙니다. 많은 사람들이 혼란스러워할 것이고, 오랫동안 근무한 팀원들은 불만을 느끼게 될 것입니다. 기대에 대한 의사소통은 매우 중요하며, “걸어가는 길”도 중요합니다. DevOps는 개발 방법론과 마찬가지로 문화적 운동이기도 합니다. 팀은 여러 부서를 넘나드는 협업적 사고방식을 가지고 살아야 합니다.

훌륭한 DevOps 문화는 어떤 모습일까요?

• 개인은 리더뿐만 아니라 프로세스에 자신의 전문 지식을 활용할 수 있습니다.
• 팀 간의 개방적이고 정직하며 존중하는 커뮤니케이션
• 각 사람은 개발 프로세스에 품질과 보안을 구축한다는 전반적인 목표를 책임집니다.
• 모든 사람이 비즈니스에서의 DevOps의 정의, 로드맵, 각 개인의 역할의 방법/대상/이유에 대해 동일한 이해를 하고 있습니다.

필자는 수년간 개발팀에 긍정적인 보안 문화를 구축하는 것이 중요하다고 강조해 왔으며, DevOps도 예외는 아닙니다.

보안 모범 사례를 달성하고, 발견된 취약점을 파악하며, 팀이 데이터 보호의 중요성을 인식할 수 있도록 하려면 올바른 도구, 지식 및 지원이 필수적입니다. DevOps를 활용하면 긍정적인 변화를 위한 문화적 토대를 마련해야 합니다. 즉, 모든 사람이 자신의 역할, 가치, 기대, 전체 프로젝트 목표 및 프로세스 단계를 이해하도록 해야 합니다.

그걸 마스터하셨나요?멋지네요.이제 관점을 바꾸고 보안 측면을 확대하여 DevSecOps를 소프트웨어 우수성을 위한 궁극적인 계획으로 만들어 보겠습니다.