DevOps 관점에서 기술 부채를 판매하는 방법은 무엇입니까?

기술적 부채를 만들지 않는 것이 더 낫다는 극적이고 한심한 주장이 종종 제기됩니다. 예, 물론 없는 것이 더 좋습니다. 그러나 결과는 여전히 제거될 수 있습니다.

나는 모든 변경 및 개선, 인프라 수정 및 프로세스 변경, 격차 제거를 목표로 하는 팀 구조 변경(제품 출시 프레임워크 내에서 의식적이든 아니든), 시간이 지남에 따라 크게 방해가 되는 기능을 기술 부채라고 부릅니다.

그리고 이러한 문제는 생산 및 운영 부서의 확고하고 자신감 있는 팀플레이 없이는 해결될 수 없기 때문에 이 이야기는 바로 DevOps에 관한 것입니다.

기술 부채 - 누구의 것입니까?

하지만 먼저 문제의 근본 원인인 기술 부채에 대해 이야기하는 이유는 무엇일까요? 사업이 시간을 할당하지 않는다는 사실이 매우 불쾌하기 때문입니다. 이 빨간색 스레드는 모든 보고서, 모임, 개발자와 운영 간의 커뮤니케이션을 통해 실행됩니다.

사악하고 나쁘고 끔찍한 사업은 기술 부채를 처리하는 데 시간을 할당하지 않습니다. "품질이 전혀 필요하지 않습니까?"라는 의로운 질문도 제기됩니다. 앞으로는 "아무도 품질이 필요하지 않습니다. "라고 말할 것입니다. 하지만 이 생각은 조금 후에 공개하겠습니다.

이 상황을 분석하기 위해 기업이 우리에게 왜 이런 일을 하는지 생각해 봅시다. 그리고 답을 얻으려면 누구의 기술부채인지 생각해 볼 필요가 있습니다. 책임은 누구에게 있나요?

몇 년 동안 참여하고 난 후에 나는 우리가 모든 사람에게 반지를 제안한 프로도와 같다는 것을 깨달았습니다. 마치 "이 짐을 지게 도와주세요!" 우리는 기업이 기술 부채를 처리하기를 원하기를 기다리고 있습니다. 그러나 비즈니스에 대한 우리의 상호 오해의 근본 원인은 결코 원하지 않을 것이라는 것입니다.

우리에게 이는 엔지니어링 과제이자 제품 우수성을 개선하는 방법이거나 심지어 제품에 대한 자부심을 높이는 메커니즘이기도 합니다. 하지만 비즈니스에 있어 시간을 투자해야 하는 것은 언제나 귀찮은 일, 필요악(또는 필수)입니다.

택시를 탔는데 운전자가 "세차장에 들러도 될까요?"라고 묻는다고 상상해 보세요.

이 상황에서 비즈니스는 클라이언트이고 개발자는 택시 운전사입니다.

• 업체는 분개합니다. "왜요? 제가 이동 시간 비용을 지불하고 있는데 당신은 세차장에 가시나요?"

• 이에 택시 운전사는 "좋은 냄새가 나는 깨끗한 차를 타고 싶지 않으세요?"라고 합리적으로 대답합니다.

• 업체는 다음과 같이 대답합니다. "물론 그렇죠! 하지만 저는 기본적으로 그런 일을 기대하고 있고, 그 일 때문에 지금은 세차장에 들를 준비가 되어 있지 않습니다!"

이것이 기업이 기술 부채를 처리하는 방법입니다. 세차장에 들르라는 제안과 같습니다. 나는 깨끗하거나 고급스러운 살롱을 갖기 위해 택시를 주문할 때 적절한 카테고리를 선택합니다. 주문 단계에서는 투자할 의향이 있지만 세차장에 들르는 것은 그렇지 않습니다.

앞서 말했듯이 누구도 품질을 원하지 않기 때문입니다. 그러나 이는 기본적으로 예상됩니다.

그것은 필수입니다. 기업은 세차장에 가지 않겠다고 체념할 수 없으며, 기업은 자신의 시간을 희생하면서 세차장에 갈 수도 없습니다. 그럼 우리는 무엇을 합니까? 사업은 기관차이다. 기능, 판매 및 고객이 필요합니다. 우리의 '원한다', '원한다'를 통해 기술부채를 기업에 매각하는 것은 불가능하다. 그러나 다른 방식으로 비즈니스에 동기를 부여하는 것도 가능합니다.

여행 과정에서 저는 기술 부채를 "구매"하기 위한 세 가지 범주의 비즈니스 동기를 형성했습니다.

• "뚱뚱한" 무관심. 부유한 투자자가 있으면 CEO는 이상한 괴짜들로 구성된 개발팀을 감당할 수 있습니다. 그것은 마치 "글쎄요, 그들이 하게 놔두세요! 가장 중요한 것은 제품을 완성하는 것입니다. 그리고 팀 정신은 와우입니다. 모든 것이 멋지고 우리는 세계 최고의 사무실이 될 것입니다."와 같습니다.

  
  

  내 생각에는 기술적 부채에는 실용주의가 필요하기 때문에 종종 재앙으로 이어지는 멋진 프리스타일입니다. 우리가 그것을 실용적으로 하지 않을 때, 우리는 유사-멋진 건축의 리바이어던을 창조하게 됩니다.

• 두려움. 이는 기술 부채에 대한 가장 효과적이고 광범위하며 효율적인 모델 중 하나입니다. 무섭다면 여기서는 어떤 '원함'에 대해 이야기할 수 있을까요? 클라이언트가 장애나 해킹으로 인해 떠나는 등의 일이 발생했을 때의 이야기입니다. 그리고 그것은 모두 낮은 품질, 브레이크 또는 기타 때문입니다. 하지만 두려움 때문에 무뚝뚝하게 파는 것도 나쁘다. 두려움을 가지고 추측하는 것은 신뢰에 어긋납니다. 최대한 신중하고 정직하게 판매해야 합니다.

• 신뢰하다. 기업이 기술 부채를 처리하는 데 필요한 만큼의 시간을 제공하는 경우입니다. 신뢰는 전체 몫에 비해 신중하게 작은 부분을 차지하고 이 시간을 최대한 실용적으로 사용할 때만 작동하고 유지됩니다. 그렇지 않으면 신뢰가 파괴됩니다. 게다가 누적되지도 않습니다. 끊임없는 과정이 파도처럼 진행됩니다. 신뢰는 증가했다가 사라집니다.

다음으로, 내 경험과 나와 내 멋진 팀에 도움이 되는 것이 무엇인지 논의하겠습니다.

기술 부채의 토끼굴은 얼마나 깊습니까?

3년 전 새 회사에 입사했을 때 나는 이 기술 부채가 얼마나 되는지 알아야 했다. 기업, 파트너 등의 요청 통계를 통해 존재한다는 것을 알았습니다. 나는 일반적으로 내가 다루고 있는 것이 무엇인지 파악해야 했습니다.

이는 기술 부채 작업의 정상적이고 의무적인 첫 번째 단계입니다. 가장 먼저 찾은 일을 서두르지 마십시오. 상황을 전체적으로 분석해야 합니다.

그때 본 내용을 바탕으로 근본적인 문제 중 하나가 대규모 코드 결합이라는 가정을 갖게 되었습니다. 지금은 이 프로세스에 참여하는 사람이 줄어들었지만 당시에는 애플리케이션 제품군에서 강조하고 싶은 레이어를 수정하기 위해 전체 프로덕션 팀을 모았습니다.

우리 애플리케이션에는 최소 80개의 서로 다른 구성 요소(설치가 아닌 배포판)가 있었습니다. 상황을 파악한 후 처리해야했습니다.

1단계. 가상 팀

매우 영리하게, 나는 모든 사람이 시간을 갖고 있는 척하고 각 구성 요소를 중심으로 가상 팀을 구성한다는 아이디어를 생각해 냈습니다. "얘들아, 누가 어떤 구성 요소를 맡을 것인가? 그것을 개선할 방법에 대한 제안을 작성해 보라." 하지만 집중을 유지하기 위해 우리는 모두 함께 첫 번째 단계를 최적화하기 위한 기준을 공식화했습니다.

• 느슨한 결합
• 비용 효율적인 확장성
• 새로운 개발자의 손쉬운 연결(간단하고 명확한 원칙: 이 구성 요소에서 정확히 수행할 수 있는 작업과 수행할 수 없는 작업, 그리고 모든 사람이 "만질" 수 없는 코드 격리)
• 필요한 곳에 외부 API를 사용하는 기능
• 제안된 기술 스택의 접근성
• 현재 솔루션의 QuickWin 최적화
• 모니터링 및 문제 해결 용이성
• 감사 + 라이센스 순수성 원칙
• 버전 관리 및 노후화 원칙

물론 이는 초점이 아니라 소프트웨어 개발의 거의 모든 측면에 대한 일련의 기준이었습니다. 전체 목록은 "모든 것을 수정하세요"라는 문구로 대체될 수 있습니다.

이 단계는 아무 일도 일어나지 않았다는 의미에서 대실패로 끝났습니다. 공유 백로그를 통해 계획을 세우려고 했기 때문에 일부 항목을 구현하는 데 거의 진전이 없었습니다. 작업을 이해할 수 없었습니다. 그들은 수동으로 작업에 투입되었습니다. 나는 그것이 나와 팀 모두에게 힘든 일이고 갈등과 논쟁이 끊임없이 커지고 있다는 것을 빨리 깨달았습니다.

그래서 2단계로 넘어갔습니다.

2단계. 기술 부채는 나의 것

1단계에서 저는 백로그 할당량을 도입하기로 회사 CEO와 합의했습니다. 우리는 비즈니스 문제에 70%, 결함 제거에 15%, 기술 부채에 15%를 지출합니다.

둘째, 이전 단계에서 나는 모든 사람이 문제에 책임이 있다면 그 누구도 그 문제에 책임이 없다는 것을 깨달았습니다. 이것은 전혀 청록색 진술이 아닙니다. 나는 그것을 좋아하지 않습니다. 그러나 그 반대에는 매우 높은 수준의 성숙함과 팀워크가 필요합니다. 그래서 나는 기술 리더 시스템을 구성하기로 결정했습니다.

하지만 나는 단지 한 사람을 부품의 기술 리더로 임명한 것이 아닙니다. 나는 가능한 한 기대치를 제시하고 개발 경로를 정의하며 생산 상황에 대한 책임을지게했습니다. 구성 요소가 생산에 문제가 있어도 OPS 전문가는 깨어 있지 않습니다. 상황을 해결하려고 노력하는 것은 바로 당신입니다.

그래서 우리는 출발했습니다. 기술리더(담당자)가 있고 기술부채 할당량은 15%(시간 있음)가 있습니다. 그러나 결국 현실은 어떻게 되었습니까?

우리가 가장 먼저 접한 것은 핀테크, 규정 준수, 업무 분리, 즉 나와 개발이 생산에 접근할 수 없고 정의상 가질 수도 없다는 것이었습니다. 그런데도 나는 "얘들아, 생산상황은 너희 책임이야!"라고 말한다.

사람들에게 로그를 주세요!

사람들에게 책임을 줄 때 그들의 손에 도구를 쥐어주십시오. 이것이 바로 우리가 OPS 전문가와 함께 수행한 첫 번째 작업으로, 기술자가 구성 요소의 로그를 볼 수 있도록 로그를 제공했습니다.

그리고 우리는 정말 협력적인 노력을 기울였습니다. 이는 운영과 개발이 함께 이루어지는 DevOps를 향한 첫 걸음이었습니다. 공격은 로그 전송(Kibana 등)을 설정하는 반면, 개발에서는 로그에 민감한 정보(개인 데이터 등)가 포함되지 않았는지 확인해야 했습니다.

5%는 행운으로 간주됩니다...

현실은 15% 할당량에도 불구하고 "파트너가 지금 필요로 하지 않으면 떠날 것"이기 때문에 매 스프린트마다 비즈니스 위기와 긴급 주입이 있다는 것입니다. 물론, 이 기술적 부채는 스프린트에서 먼저 밀려납니다. 결과적으로 우리는 0%의 스프린트를 가졌습니다.

15%의 스프린트도 있었지만 평균적으로 기술 부채가 5~8%에 불과했습니다. 프로그래머는 구현에 얼마나 많은 시간이 걸릴지 알 수 없기 때문에 이는 큰 문제입니다.

저는 모든 팀 위로 끊임없이 연을 날려 이러한 상황을 도우려고 노력했습니다. 우리는 각 스프린트에 대한 자세한 지표를 수집하는 방법을 배웠고, 마지막에 스프린트를 살펴보았습니다.

스프린트 해킹은 기술 부채 할당량을 체계적으로 위반하는 경우입니다. 한 스프린트에서 할당량이 충족되지 않는다고 해서 모든 것이 나쁘다는 의미는 아닙니다. 실제로 상황은 다양하므로 유연성이 필요합니다.

그런데 그것이 체계적으로 반복되자 제작 전문가들을 모아 논쟁을 벌이고, 할당량이 합의되었기 때문에 얼마나 중요하고 용납할 수 없는 일인지 설명했습니다. 그 모델에서 프로세스를 옮기는 것이 나의 일상 업무였습니다.

그리고 그것은 움직였지만 이제는 이 접근 방식에 심각한 단점이 있다고 생각합니다.

접근 방식의 한계

제품 소유자는 백로그가 모두 자신의 것이고 모든 작업이 제품 소유자에 의해 조정된다는 사실에 익숙합니다. "할당량은 좋지만 이 기술 부채 할당량에서 팀이 무엇을 할 것인지 결정하는 것은 우리뿐입니다!"

그리고 개발자가 리팩토링, 상용구 제거 등과 같은 작업(강력한 연결성을 기억)을 생각해냈을 때 그들은 논리적인 반응을 얻었습니다. "뭐?! 무슨 상용구? 우리가 무슨 얘기를 하는 거야?!"

결과적으로 작업은 기술 부채라고 할 수 있지만 조건부로 공급업체에 이익이 되는 작업으로 대체되었습니다. 그렇기 때문에 저는 "기술적 부채는 내 것입니다! 그리고 각 스프린트의 기술 부채 할당량에 각 제품 팀의 기술 부채에 포함될 것이라고 주장합니다."라고 강경한 입장을 취할 수밖에 없었습니다.

그것이 우리가 살았던 방식입니다. 평범하게 살고 일했지만 불신은 더욱 커졌습니다. 우리가 어떤 일을 하고 그것이 무엇인지 아무에게도 말하지 않고, 비즈니스 업무에 시간을 쓰지 않을 때, 우리가 어떤 결과를 가져오는지는 모든 사람에게 불분명합니다.

기술 부채 할당량 활용 통계가 급증하면서 대규모 프로젝트를 수행할 수 없다는 현실에 직면했습니다. 또한 대규모 프로젝트에는 여러 팀이 필요한 경우가 많습니다. 각 제품팀이 제품에 집중하고 현실에 충실하기 때문에 이는 불가능한 일이기도 했습니다. 복잡한 주제에 연결하는 것은 불가능합니다.

또한 스프린트에는 아무도 작업을 포함하지 않았습니다. 생산과 같은 스프린트와 백로그가 없습니다. 생산과 관련된 업무로 꽉 차 있지만 전체 계획에는 포함되지 않았습니다. 그리고 개발이 이러한 작은 기술 부채 내에서 수행되어 프로덕션으로 출시되면 꽤 오랫동안 OPS의 요청에 머물 수 있습니다.

정말 시간이 없었고, 추가 작업에 눌려 일을 할 수 없었기 때문입니다.

그러나 이러한 접근 방식의 부정적인 측면에도 불구하고 우리는 상당한 성과를 거두었습니다.

이 접근 방식을 통해 우리는 무엇을 달성했습니까?

첫째, 우리는 자동 테스트의 근육량을 구축했습니다. 전체 CI 프로세스를 대폭 재설계하여 부끄럽지 않은 문명화된 프로세스로 만들었습니다.

둘째, 우리는 많은 구성 요소에서 스파게티 코드와의 싸움을 성공적으로 구현했습니다.

우리는 모듈화하고 상용구를 줄였습니다. 이러한 작업은 두려움에도 불구하고 비즈니스에 팔 수 없습니다. 제품의 기술 격차에 이러한 문제가 포함되어 있고 이를 수정해야 하는 경우(있을 경우 먼저 해결해야 함) 해당 제품을 판매할 필요조차 없습니다. 이는 "기술 부채 - 내 것" 모델을 통해서만 할당량을 통해서만 수행할 수 있습니다.

나는 많은 시도를 보았고 첫 번째 단계에서는 스스로 다르게 시도했습니다. 그것은 효과가 없었습니다.

실제로 이 모드에서의 작업은 오랫동안 지속될 수 없습니다. 이는 경영진이 귀하를 CTO이자 팀 리더로 신뢰하여 제공하는 제한된 전권입니다.

3단계. 합법적인 프로젝트

그런 다음 기술 부채를 해결하기 위한 "합법적인" 프로젝트인 3단계를 시작했습니다. 우리는 폐쇄된 할당량에서 벗어나 공통 제품 백로그를 통해 계획을 세우고(즉, 제품 소유자가 이러한 프로젝트를 완료해야 한다고 인정함) 완전 판매에 들어간다고 가정했습니다. 이를 실현하기 위해 우리는 두 가지 작업을 수행했습니다.

• 나는 이 프로젝트의 틀 내에서 우리가 시작한 작업 범위를 최대한 좁혔습니다.

• 나는 우리가 생산에서 무엇을 위해 싸울 것인지에 대한 구체적인 기대를 형성했습니다. 우리의 업무는 비즈니스 관점에서 최대한 실용적이고 이해 가능하며 서비스에 유용해야 하기 때문에 이상주의를 완전히 거부한 것입니다.

중요한 점은 거의 불가능하지만 기술 부채의 비즈니스 가치를 계산하려고 한다는 환상을 가지고 있다는 것입니다. 그리고 여전히 계산이 가능하다면 우리는 악몽 같은 기술적 부채를 갖게 됩니다!

긍정적인 가치는 부정적인 가치보다 비즈니스에 더 효과적입니다. "이 손님은 떠날 거야. 돈을 너무 많이 가져오니까"라고 말하면 그가 떠날 때까지 작동하지 않습니다. 이는 비즈니스 가치가 아닙니다. 더욱이 위험을 감수하고 일하는 문화는 아직 그다지 높지 않기 때문에 "그들이 떠날 때까지 손실이 없다"는 모드입니다.

또한 비즈니스 가치를 보여줄 필요도 없습니다. 보여줄 수 있지만 기술적 가치를 보여줄 수 있는 곳은 오직 계산되어야 합니다.

기술 부채 판매 방법 안내

기술 부채 판매를 위한 이 단계의 전체 작업 흐름은 다음과 같습니다.

초점 영역 선택(단 하나)

이것은 두려움을 통해 판매되는 것이므로 귀하의 비즈니스에 실제로 영향을 미치는 영역을 선택하십시오. 가용성, 재작업 속도, A/B 테스트 및 실험의 안전성, 재작업 비용 등 영역이 다를 수 있습니다. 엄청난 수의 영역과 주제가 있습니다.

제 경우에는 접근성이 비즈니스의 주목을 받고 우리 서비스에 어느 정도 영향을 미쳤기 때문에 접근성을 선택했습니다. 너무 자신을 얕잡아 보지 않고 하나의 주제만 선택하는 것이 중요합니다.

통합 분석 수행

한 해 동안의 가용성과 사고 통계를 분석하고, 한 해 동안 발생한 모든 상황에 대해 모든 사후 분석을 자세히 분석했습니다. 그 후, 저는 기술적으로 가능한 한 많은 작업을 수행해야 하지만 다시 한번 실질적으로 작업해야 할 사항에 대해 최상위 수준의 이해를 형성했습니다.

가용성의 첫 번째 규칙은 항상 사용 가능한 시스템을 구축하려고 시도하는 것이 아니라 사고 발생 시 준비되어 있는 시스템을 구축하는 것입니다. 그것이 우리가 보장해야 할 것입니다.

두 번째 문제이자 가용성의 기본 규칙은 성능 저하 합의입니다. 언젠가는 어떤 일이 일어나게 되어 있으며, 제공하는 일부 기능을 포기하는 대가를 치르더라도 서비스를 보존할 준비가 되어 있어야 합니다. 이 계약은 프로그램 수준을 포함하여 유지되어야 합니다.

세 번째 문제는 모니터링 및 관찰 가능성에 관한 것입니다. 이는 사고 원인과 대응 감지 시간의 신속한 현지화입니다. 불안정한 테스트가 많으면 모니터링을 신뢰하는 것을 중단해야 합니다. 생산 테스트에 "5분 후에도 문제가 없으면 전화해 주세요"와 같은 서비스 데스크 반응에 대한 지침이 있는 경우 생산 상황을 모니터링하고 있는 것이 아닙니다. 테스트는 가능한 한 명확해야 합니다. "표시됩니다. 어딘가에 문제가 있다는 의미입니다. 가자!"

구성요소별 분석 수행

이를 위해 우리는 각 방향과 구성요소에 대해 정확히 무엇을 할 것인지를 정했습니다. 우리는 서비스 메시를 어디에 끌어들일 것인지, 모니터링을 어떻게 변화시킬 것인지, 그리고 무엇을 기반으로 할 것인지를 의미합니다. 여기에는 15% 정도를 나열했는데, 실제로는 프로그램 개선이 많이 이루어졌습니다.

우리는 모든 것을 준비했지만 아직 시장성이 없습니다. 지금 공개적으로 보여주기 위해 우리는 이 단계의 각 프로젝트에 대해 다음을 수행했습니다.

실질적이고 정량적인 지표를 공식화

우리는 정량적 지표를 매우 두려워합니다. 정량적 지표에서 개발자 작업의 품질을 어떻게 측정할 수 있습니까? 우리는 정량적 지표에 대해 많은 논쟁을 벌이고 있지만 이를 정면으로 받아들여서는 안 됩니다.

가치를 비즈니스 가치로만 받아들여서는 안 됩니다. 예를 들어 "X개의 거짓 긍정(false positives)"을 초과할 수 없습니다.

카나리아 릴리스를 제공하거나 패치 롤백을 보장하는 기능을 제공하는 데 중요한 특정 구성 요소 세트를 나열할 수 있습니다. 물론 전반적인 가용성은 정량적 지표가 되어야 합니다. 그것은 필수입니다.

프로젝트 방어

가능한 한 명확한 지표와 우리가 달성해야 하는 결과를 통해 이러한 실용적인 프로젝트 세트를 통해 저는 이렇게 말했습니다. "여러분, 기술 부채 할당량이 필요합니다. 이러한 프로젝트를 풀에 포함시켜 가속화해야 합니다. 비즈니스 목표와 함께 완전히 법적 근거를 바탕으로 전반적인 계획을 수립합니다."

그 말을 듣고 우리는 해냈고 효과가 있었습니다. 부엉이를 그리는 방법에 대한 비디오 "타원과 대시 두 개 그리기"와 같은 것 같아요. 결국 - 마술 - 당신은 올빼미를 얻습니다! 그러나 모든 마법은 이 전체 프로젝트를 마무리하고 끝까지 완료해야 한다는 것입니다.

단지 이 방향으로 몇 가지 일을 하는 것이 아니라 결과를 가져오는 것입니다. 즉, 명시된 정량적 지표에 도달하여 이를 보여주는 것입니다. 이 심연은 95%의 경우 뛰어넘을 수 없습니다. 완전히 점프해야 합니다.

접근 방식의 장점

그래서 우리는 (심연 위로) 점프하기 시작했습니다. 우리는 그것을 성공적으로 수행하고 있습니다. 이제 우리는 이 프로젝트의 두 번째 라운드를 진행하고 있습니다. 즉, 첫 번째 프로젝트 풀을 끌고 두 번째 프로젝트 풀에 동의했습니다. 무엇이 바뀌었나요?

신뢰도 높이기

실제적이고 정량화 가능한 측정항목을 표시하면 개방성을 통해 신뢰가 강력하게 높아집니다. 그러나 사실은 기술 부채 매각이 두려움을 통해 이루어진다는 것입니다. 이 단계는 피할 수 없습니다. 하지만 두려워하거나 부끄러워할 필요도 없습니다. 가장 중요한 것은 두려움에 대해 추측하는 것이 아니라 실제로 여러 단계(통합 분석, 구성 요소별 분석)에서 설명한 것처럼 두려움을 분석하는 것입니다.

대규모 프로젝트 수행

이제 이러한 프로젝트는 합법화되었으므로 팀 전체를 동기화하고 매우 큰 프로젝트를 수행할 수 있습니다. 일부 프로젝트는 스프린트마다 순차적으로 수행되었습니다. 우리는 기술 팀 구성에 따라 해당 프로젝트 내에서 정기적으로(주 1회) 추적을 받고 누가 어디에(어떤 단계에) 있는지 이해합니다.

이 정보는 최대한 공개적이고 투명합니다. 프로젝트 진행 상황과 현재 상태가 게시되어 제품 소유자(및 이를 보고 싶어하는 모든 사람)가 사용할 수 있습니다.

프로젝트의 OPS'ers

가장 중요한 것은 인프라와 롤아웃 프로세스를 재설계해야 할 것이 많다는 점을 깨달았다는 것입니다. OPS'ers는 이 프로젝트에 명시적으로 포함되었습니다.

내 생각에는 OPS 담당자가 개발자와 구성 요소의 아키텍처를 변경하는 방법을 논의하고 개발자가 OPS 담당자와 인프라를 변경하는 최선의 방법을 논의할 때 이는 Kubernetes 및 Docker보다 DevOps에 가깝습니다.

나는 왜 즉시 하지 않았는가?

여기서 우리는 2단계가 끝날 때 제가 이야기했던 내용으로 돌아갑니다. 이전에는 작동하지 않았을 것입니다. 2단계에서 수행한 작업(재설계한 스파게티 코드, 테스트의 강화, CI 프로세스 재설계)은 측정 가능한 지표와 관련하여 비즈니스에 판매하는 것이 불가능했기 때문입니다.

그 상황은 어떤 특정한 두려움과 연관되지 않았으며, 우리의 표준 주장인 "스파게티 코드 때문에 코딩하는 데 오랜 시간이 걸립니다." - 비즈니스 담당자 중 누구도 귀를 기울이지 않습니다. 따라서 우리는 그러한 접근 방식을 끌어낼 수 없었을 것입니다.

내 관점에서는 이렇게 심층적인 인프라 재작업이 필요한 기술 플랫폼이 있다면 2단계를 피할 수 없다.

노력해야 하지만 늘 연처럼 펄럭일 뿐만 아니라, 사업에 대한 신뢰를 잃지 않을 만큼 빨리 이 가게를 문을 닫을 준비도 되어 있어야 합니다.