DevOps 구현이 실패한 경우가 많습니다(그리고 이를 해결할 수 있는 방법)

이 문서는 원래 DevOps.com 에 게시되었습니다. 업데이트 및 수정되었습니다.

"블록체인", "빅 데이터" 및 "디지털 중단"과 마찬가지로 "DevOps"라는 용어는 현재 대규모 조직의 IT 부서를 중심으로 제기되고 있는 또 다른 유행어입니다.

많은 사람들이 더 빠른 소프트웨어 개발 수명 주기의 필요성을 정확하게 파악했습니다. 비즈니스 목표와 긴밀하게 일치하는 보다 정밀한 프로세스를 통해 개발 및 운영 기반 팀 간의 보다 명확한 워크플로우와 협업을 수행할 수 있습니다. DevOps는 본질적으로 "민첩한" 개발이며, 모두 성장하고 현대 비즈니스의 끊임없이 혁신하고 빠르게 배포할 준비가 되어 있습니다. 보안 전문가의 경우, 그것은 환상적인 이니셔티브: 우리는 훨씬 더 일찍 프로세스에 보안을 주입할 수 있습니다., 버그를 해결 하 고 트랙 아래로 잠재적인 재앙을 피하기의 비용을 감소.

문제는 DevOps 구현에 성공한 기업은 거의 없습니다. 올바른 지원, 육성 및 비즈니스 전반에 걸쳐 이해가 없다면 신속하게 흰 코끼리가 될 수 있습니다... 알다시피, 그 중 하나는 "전쟁을 언급하지 않는다"프로젝트.

그래서, 문제는 무엇입니까? 그것은 흥미로운 토론, 그리고 내가 훨씬 부드러운 항해를 만들 것입니다 믿는 DevOps에 접근하는 몇 가지 방법이 있다. 효과적인 프로그램은 몇 가지 멋진 새로운 도구, 타이틀 및 팀 회의를 넘어섭습니다. 항상 쉬운 일은 아니지만, 깨진 전략을 고치는 데 시간을 할애하는 것이 장기적으로는 훨씬 덜 고통스러울 것입니다. 그리고 궁극적으로, 그것은 더 높은 품질과 더 안전한 소프트웨어가 될 것입니다.

그것을 분해해 봅시다.

"민첩한" 앞치마 문자열을 놓습니다.

조직이 Agile 또는 DevOps 중에서 선택해야 한다는 오해가 다소 있습니다.

문제는 개발 프로세스가 둘 다 고려되고 구현될 때 가장 잘 작동한다는 것입니다. DevOps는 민첩한 개발의 재창조가 아닙니다. 오히려, 그것은 그것의 확장. 프로세스가 민첩한 것과 똑같거나 애자일과 완전히 다를 것이라는 기대가 있을 때 바퀴가 떨어지는 경향이 있습니다.

Agile은 처음부터 디자이너, 테스터 및 개발자를 한데 모으고 프로젝트 전반에 걸쳐 통신 라인을 열기 위해 최선을 다하고 있습니다. 그것의 목표는 사일로 배달을 중지 하 고 이중 처리를 줄이기 위해, 둘 다 DevOps 프로세스의 혜택뿐만 아니라. 그러나 DevOps는 한 단계 더 나아가 시스템, 보안 및 작업을 믹스에 도입하여 고객에게 완전하고 기능적인 소프트웨어 전송의 궁극적인 목표를 가지고 있는 강력하고 엔드 투 엔드 기술 집합을 제공합니다.

더 DevOps 중심 프로세스로 이동의 피할 수없는 통증 지점 동안, 사일로 개발의 위험은 다시 자르기 수 있습니다. 원래 Agile 팀이 함께 작업할 수 있으며 보안 및 운영 추가가 여전히 컴퓨터에서 길을 찾는 경우가 많습니다. 아무도 그들을 포함 하는 방법을 확실히 확실 하다, 그들은 해야 하는 무엇 그리고 그들의 전반적인 목표.

DevOps는 명확하게 정의된 목표, 상호 기능 온보딩 및 모든 당사자와의 직접 통신 없이는 작동하지 않습니다. 신중한 변경 관리가 필요한 조정 기간이 있을 것이지만, DevOps 기능이 가져올 향상된 기능을 통해 모든 사람을 동일한 페이지에 가져오는 것은 전투의 절반입니다.

점점 더 (선하심에 감사함), DevOps는 프로세스의 일환으로 보안 모범 사례에 중점을 두고 있으며, 그 단계를 신비화하고 보안 팀과 다른 모든 사람들 사이의 격차를 해소하고 있습니다. 앞서 말하듯이 개발자가 처음부터 안전하게 코딩할 수 있도록 힘을 실어줄 길이 멀지만 DevOps 방법론을 성공적으로 구현하는 것은 개발 팀 내에서 보안 기술을 구축할 수 있는 훌륭한 토대입니다.

자동화가 전부가 아닙니다(그리고 가장 안전하지는 않습니다).

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

도구는 굉장합니다, 그들은 정말입니다. 소프트웨어 전송 프로세스에 전례 없는 속도를 가져와 코드 리포지토리, 테스트, 유지 관리 및 스토리지 요소를 비교적 원활하게 관리할 수 있습니다.

그러나 로봇은 우리의 모든 직업을 취하고 언젠가 우리를 감옥에 가두는 동안, 그들은 아직 거기에 있지 않습니다. 도구와 자동화에 대한 의존도가 크게 향상되어 오류가 발생하면 창이 활짝 열려 있습니다. 스캔 및 테스트는 모든 것을 선택하지 않을 수 있으며, 코드는 선택되지 않을 수 있으며, 트랙 아래로 엄청난 품질(보안) 문제를 제공합니다. 공격자는 데이터를 도용하기 위해 하나의 백도어만 필요하며 품질 및 보안 관리에서 인간의 요소를 위조하면 비참한 결과를 초래할 수 있습니다.

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

• 사람들이 선택한 DevOps 도구 체인에 익숙해질 수 있는 충분한 시간을 할당합니다.
• 효과적인 협업에 집중(그리고 도구가 이를 지원하는 방법)
• 기술/지식 또는 도구 기반 여부에 관계없이 프로세스의 간격을 해결합니다.

요컨대, 그냥 "도구 업"하지 말고 최고에 대한 희망.

DevOps는 유행어가 아니라 문화입니다. 당신은 당신을 성장하고 있습니까?

변경 관리는 가장 좋은 시기에 힘든 시기입니다. 미지의 두려움에 대한 두려움은 가장 뛰어난 팀원들조차도 자신의 기술을 키우고 시야를 넓히고 는 것을 막을 수 있습니다.

"DevOps를 수행하자"고 말하고 운영 팀이 책상을 이동하게 하는 것만으로는 성공적인 프로세스를 마술처럼 구현하지 않을 것입니다. 많은 사람들이 혼란스러워할 것이고, 팀의 오랜 서빙 멤버들은 불만을 느끼게 될 것입니다. "걷기"와 마찬가지로 기대의 의사 소통이 중요합니다. DevOps는 개발 방법론만큼이나 문화적 운동을 나타내며, 팀은 상호 기능적이고 협력적인 사고 방식을 살고 호흡해야 합니다.

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

• 개인은 지도자뿐만 아니라 프로세스에 자신의 전문 지식을 빌려 줄 수있는 권한을 부여받습니다.
• 팀 간의 개방적이고 정직하며 존중받는 의사 소통
• 각 사람은 개발 프로세스에 품질과 보안을 구축하는 전반적인 목표에 대한 책임을 집니다.
• 모든 사람은 비즈니스, 로드맵 및 각 사람의 역할의 방법 / 무엇을 / 왜의 정의와 같은 페이지에 있습니다.

수년 동안 저는 개발 팀에서 긍정적인 보안 문화를 구축하는 것의 중요성을 강조해 왔으며, DevOps도 마찬가지입니다.

올바른 도구, 지식 및 지원은 보안 모범 사례를 달성하고, 발견된 취약점의 침체를 보고, 데이터 보호의 중요성에 대한 팀의 눈을 열어야 합니다. DevOps를 사용하면 모든 사람이 자신의 역할, 가치 및 기대, 전체 프로젝트 목표 및 프로세스의 단계를 이해하도록 보장합니다.

당신은 그것을 마스터 했습니까? 대. 이제 바늘을 바꾸고 보안 측면을 누르고 DevSecOps를 소프트웨어 우수성에 대한 궁극적 인 계획으로 만들어 봅시다.