DevOps 생활 기술: 조달 프로세스 이해 및 관리

이전 블로그 에서는 애플리케이션 제공에 '시스템적 사고' 접근 방식을 적용하는 것이 중요한 이유에 대해 말씀드렸습니다. 이는 효율적인 가치 제공을 위해 최적화된 잘 조정된 공장처럼 운영되는 것을 의미합니다. 목표에 도달하려면 사용하는 도구를 평가하고 도구를 선택하고 조달하는 프로세스도 평가해야 합니다. 효율성을 높이려면 가능한 한 재사용 가능한 패턴을 우선시하고, 여러 팀과 환경에서 일관된 도구와 프로세스를 선택해야 합니다. 이는 이론적으로는 대부분의 사람들에게 이해가 됩니다. 특히 해당 도구가 인프라나 보안과 관련이 있고 애플리케이션 기능에 미치는 영향이 최소인 경우 더욱 그렇습니다. 그러나 이러한 패턴을 구축하는 데 있어 과소평가된 장벽이 종종 방해가 됩니다. 공급업체 및 조달 프로세스.

현재 DevOps 엔지니어가 클라우드 기반 도구, 오픈 소스 솔루션 또는 상당한 투자나 조달 팀과의 상호 작용이 필요하지 않은 기타 유형의 저렴한(또는 무료) 리소스를 사용하는 것은 드문 일이 아닙니다. 하지만 앱의 보안과 성능을 개선하고 필요한 효율성을 높이기 위해 보다 풍부한 IT 투자를 옹호해야 하는 경우는 어떻게 해야 할까요? 

IT 투자에 대한 사례 제시

조달 프로세스의 미지의 영역을 탐색할 때 DevOps 전문가가 염두에 두어야 할 몇 가지 사항은 다음과 같습니다.

1. 가치에 집중하다

   이 블로그를 읽고 있다면 여러분은 필요한 기술적 역량에 초점을 맞추고, 하루 종일 API에 대해 이야기하고, 최적화에 집착하는 것을 선호할 가능성이 높습니다. 하지만 생각해 보세요. 큰 수표에 서명하는 일을 맡은 동료들은 아마도 그런 것에 전혀 관심이 없을 겁니다. 따라서 새로운 도구나 리소스의 구매를 지원하기 위해 할 수 있는 가장 중요한 일은 해당 도구나 리소스가 가져올 사업적 가치를 그들의 용어로 명확히 설명하는 것입니다.

   많은 경우, 이는 현재 무엇이 부족하거나 누락되었는지 파악하는 것부터 시작됩니다. 새로운 도구가 출시되었다는 이유만으로 구매를 요청하는 것은 심각한 결함이나 책임을 강조하고, 해당 결함이 어떻게 문제를 일으키는지(생산 속도를 늦추거나 취약점을 노출시키는 등) 설명한 다음, 이 모든 문제를 해결할 새로운 도구를 제안하는 것만큼 설득력이 없습니다.

   집중해야 할 세 가지 핵심 요소는 비용, 가치, 위험입니다. 이러한 문제를 비즈니스 용어로 설명하는 것이 중요합니다. 즉, 특정 솔루션이 다음과 같은 문제를 어떻게 해결하는지 설명하는 것입니다.

   • 단기, 중기 또는 장기 기간 동안 비용 절감
   • 기업이 민첩성을 높이고, 출시 시간을 단축하고, 새로운 고객을 유치할 수 있는 방법
   • 규제 준수 개선, 공격 위험 감소 또는 경쟁 노출 감소를 통해 비즈니스 위험이 어떻게 감소되는지

   이 모든 것에서 각각을 최대한 잘 달성할 수 있도록 정량화하는 것이 매우 중요합니다. 순전히 질적인 의견을 원하는 사람은 없습니다. 구체적인 데이터는 중요합니다.

   구매팀(그리고 더 광범위하게는 재무팀)의 동료에게 모든 것에는 비용과 가치가 있습니다. 여기에는 알려진 문제가 있는데도 아무것도 하지 않는 데 드는 비용과 근로자를 그러한 문제로부터 해방시키는 데 드는 가치가 포함됩니다. NetOps가 지루한 작업을 없애는 데 가치를 두는 반면, 재무 팀은 동일한 엔지니어가 수익 창출을 위한 전략적인 이니셔티브에 집중할 수 있도록 하는 데 가치를 둔다는 점을 알아두십시오.

   F5의 기술 솔루션 관리자인 Will Marken은 " 문제 해결자로서의 입지를 굳건히 하세요. 가치 제공에 집중하면서 제안된 솔루션을 기업의 열망과 연결하세요. 이렇게 하면 경영진과 그들의 조건에 맞춰 상호작용하고 그들의 요구 사항에 맞게 말할 수 있다는 것을 보여줍니다. "라고 제안합니다.

2. 전문 용어를 알아보세요: CapEx 대 구독

귀사의 팀은 구독 모델을 통해 솔루션을 구매하기로 결정했지만, 조직이 대규모 CapEx 지출에 맞춰져 있고 구독 기반으로 IT 투자를 자금 조달하는 프로세스가 부족하다는 사실을 깨닫게 될 수도 있습니다. 그런 경우에는 추가적으로 해야 할 일이 있습니다. 자본지출 예산 요청(예: 시간이 지남에 따라 상각되는 단일 대규모 구매)으로 전환하는 것이 더 쉬울 수도 있습니다. 반면, 구독 모델을 받아들이는 데 느렸던 회사들조차도 구독 모델을 지원하는 방법을 알아내는 데 어려움을 겪고 있습니다. 재무 부서의 동료들이 조직 프로세스의 과제를 해결하는 동안 약간의 여유 시간을 두는 것이 필요할 수도 있습니다.

3. 끈기있게 노력하세요

진부하게 들릴지 몰라도, 이건 목적지가 아니라 여정 그 자체가 중요한 경우 중 하나입니다. 대량 구매를 정당화하려면 종종 여러 번 시도해야 합니다. 사실, 귀하의 요청은 2~3회의 예산 주기를 거쳐 논의되고, 그 과정에서 초점을 맞추고 지지를 모으는 다른 요청과 경쟁하고 있을 수도 있습니다. "아니오"라는 대답을 들었을 때 포기하지 마세요. 대신, 이에 대한 계획을 세우고, 상황이 오면 받아들이고, 거기서부터 조정을 시작하세요.

Agile 워크플로에서 다른 작업을 수행하는 것과 마찬가지로 조달 작업을 처리하세요. 문제를 식별하고, 하나씩 해결하고, 반복하고, 반복하세요.

4. 그것을 덩어리로 나누세요

예산이 큰 경우, 프로젝트를 더 이해하기 쉬운 여러 부분으로 나누는 것이 도움이 됩니다. 이것은 두 가지 이유에서 유용합니다. a) 집중력이 강할수록 실현 가능한 POC(개념 증명)를 만들고 실제 가치를 파악하기가 더 쉽습니다. b) 담당자가 더 작은 요청을 승인하기가 더 쉽습니다.

5. 팀을 구성하다

조직 내 다른 사람에게 도움을 요청하는 것이 좋은 데에는 여러 가지 이유가 있습니다. 우선, 귀하의 직접 또는 팀 간 동료는 일반적인 조달 프로세스와 특히 F5 솔루션의 가치에 대해 더 잘 알고 있을 수 있으므로 요청을 구성하는 데 도움을 줄 수 있습니다(알려진 위험을 피하는 데도 도움이 될 수 있음). 제안된 솔루션이 여러 부서에 어떻게 긍정적인 영향을 미칠지 보여줌으로써 인식된 위험을 줄일 수도 있습니다. 마지막으로, 다른 그룹이 이미 여러분의 요청과 유사한 요청을 시도한 적이 있는 경우(이 경우 여러분은 그들로부터 배울 수 있음) 또는 심지어 유사한 솔루션을 구현하기 시작했을 수도 있는 경우(이 경우 여러분은 그들과 협력할 수 있음)를 발견하는 것은 드문 일이 아닙니다(특히 대규모 조직의 경우).   

구조에 대한 참고 사항

예산 요청을 작성할 때는 백서와 데이터시트 등 해당 분야의 일반적인 문서를 작성하는 데 사용하는 것과 동일한 전략을 많이 사용할 수 있습니다. 이는 관리자가 익숙한 다른 요청과 비슷하게 보이고 읽힐 수 있도록 적절한 템플릿을 찾는 것부터 시작됩니다. 또한 프로세스 전반에 걸쳐 여러 동료에게 의견과 피드백을 구하는 작업도 포함됩니다. F5의 제품 개발 관리자인 존 그로스는 " 데이터시트와 백서와 마찬가지로 성공은 종종 설명이나 서두에 달려 있다"고 덧붙였습니다. 그는 " 실제 데이터 포인트로 구현 로드맵을 강화할 수 있는 기존 참조 아키텍처와 사용 사례를 찾아보세요. "라고 제안합니다.