DevOps 사전 배포 메트릭 문제

TL; DR, 개발자, 특히 배포 자동화를 어떻게 증명 하면 변경 실패율이 향상됩니까?

우리는 모두 현재 (대부분 수동) 수단을 사용하여 '배포 실패'에 대한 메트릭을 캡처하려고합니다 . 불행히도 '실패'는 거의 발생하지 않습니다. 문제가 발생하면 팀은 (일반적으로 영웅과 함께) 문제를 해결하기 위해 함께 모이기 때문에 (일반적으로 권한, 구성 누락, 드릴에 대해 알고 있음) 배포가 어떻게 진행되는지 물었을 때 대답은 "작동했습니다"입니다.

그러나 직관적으로 우리는 그것이 좋지 않다는 것을 알고 있습니다. 2017 년 Devops 상태 보고서에 따르면 31-45 %의 " 변화 실패율 "이 있다고합니다. 직관적으로 문제가 없지만 사건으로 추적됩니까? 아냐 일반적으로 유효성 검사 중에 매우 빠르게 수정되기 때문입니다. 실제로 배포를 롤백하는 것은 훨씬 드 rare니다.

따라서 고장률을 정확하게보고하려면 훈련이 필요합니다. 우리는 일을하기를 원하고 그것이 일어나기 위해 필요한 일을하기 때문에 그렇게보고하는 것에 대해 소외감을 느낍니다.

그렇다면 개발자, 특히 배포 자동화가 변경 실패율을 어떻게 향상시키는 지 어떻게 증명할 수 있습니까?

(PS는 이것을 "# devops-capability-model"로 태그하려고했습니다)

과거에 비슷한 상황에서 사용한 기술은 모든 팀원에게 이러한 규칙을 적용하는 "관리 약속"을 얻는 것입니다.

1. 대상 배포 영역 (예 : 프로덕션)에 대한 업데이트를 수행 할 수있는 액세스 권한은 선택한 자동화 시스템으로 제한되며, 관리되는 영역에 대한 모든 종류의 업데이트에 대한 적절한 감사 추적 (= 로깅)이 있습니다.

2. 어떤 이유로 든 대상 배포 영역에 대한 수동 업데이트는 더 이상 이러한 업데이트를 수행 할 수있는 권한이있는 일반적인 팀 구성원 (사용자 ID)이 더 이상 허용하지 않습니다. 대신 새 (추가) 사용자 ID가 만들어지며 필요할 때마다 이러한 수동 업데이트를 수행하는 데 필요한 모든 권한을 갖습니다. 그러나 실제로 이러한 새 사용자 ID를 사용하려면 (= 로그온을 수행) 해당 새 사용자 ID로 로그온을 수행하려는 팀 구성원은 비밀번호에 액세스하려면 "일부"추가 단계를 수행해야합니다. 그러한 새로운 사용자 ID. 이상적으로이 추가 단계는 자동화되어 있지만 (어떻게 상상해야하는지 자신의 상상력을 사용하십시오), 그러나 다른 것이 실패하는 경우 : "이 문제를 포함하여 필요한 비밀번호의 게이트 키퍼에게 연락하십시오 (= 이메일, 전화 등). 해결하기 위해 "

3. 이러한 게이트 키퍼를 제자리에 배치하는 것은 쉬운 일이 아닙니다. 그리고 가장 저항하는 것은 팀원들로부터입니다 (모든 종류의 이유로). 이전 단계에서와 같이 새 사용자 ID의 변형은 각 팀 구성원이 추가 사용자 ID (자신이 결정한 비밀번호로)를 얻지 만 추가 문자열이 첨부되어 있다는 것입니다. 실제로 그럴만한 이유가있는 경우 해당 (추가) 사용자 ID로 로그온하십시오. 그리고 그러한 로그온을 수행 할 때마다 "고정 된 문제"(질문과 유사)에 대한 보고서를 제출해야합니다.

이러한 절차를 마련한 후 남은 것은 이러한 특정 사용자 ID를 사용해야하는 각 보고서 / 이유를 정기적으로 검토하고 " 이를 자동화하기 위해 수행 할 수있는 조치가 있습니까? " 라는 질문 을하는 것입니다. 그런 특별한 로그인의 필요성을 더욱 줄이겠습니까? ".

업데이트 :

이 답변 아래의 추가 의견에서 인용하십시오.

배포 문제를 해결하기 위해 인공 장벽을 추가하는 것은 비생산적이라고 생각합니다.

사실 그것은 추가적인 장벽을 추가하지만 그것이 "인공적"이라고 확신하지는 않습니다. 이것이 내가 아는 한, 다음과 같은 이유로 팀원이 달리 말하지 않은 것들을 알 수있는 유일한 방법이기 때문입니다.

• 고용 안정.
• 그들이 숨기는 것을 선호하는 나쁜 일 / 사례.
• 그들은 느슨하게하고 싶지 않은 힘.

2017 년 개발 상태 보고서에 따르면 "변화 실패율"은 약 31-45 %입니다. 그것은 직관적으로 옳은 것처럼 들리지만 사건으로 추적됩니까? 아냐 일반적으로 유효성 검사 중에 매우 빠르게 수정되기 때문입니다.

빠르게 해결되는 문제는 여전히 문제입니다. 이와 같이보고하지 않으면 문제가됩니다.

따라서 고장률을 정확하게보고하려면 훈련이 필요합니다. 우리는 일을하기를 원하고 그것이 일어나기 위해 필요한 일을하기 때문에 그렇게보고하는 것에 대해 소외감을 느낍니다.

실제로 목표를 달성하는 것이 목표라면 실패에 대해 정직해야 향후 장애를 예방할 수 있습니다. 여기서 팀이 일을하는 것처럼 보이기 때문에 실패에 대해 거짓말을하는 것 같습니다 .

이것들은 다른 것입니다. 예를 들어, QA가 버그를 생성한다는 오래된 농담을 해보세요. "QA가이를 알기 전까지는 코드가 문제가되지 않았습니다." 버그는 모두 함께 있었지만 개발자는 모르고있었습니다. 운영 팀의 목표는 실제 안정성 이어야하며 관리 부서에서 인센티브를 받아야합니다. 즉, 새로운 문제를 발견 할 수있는 더 많은 모니터링을 실시 할 경우 이후의 신뢰성 지표 하락에 대해 페널티를받지 않고 보상을 받아야합니다.

TL; DR, 개발자, 특히 배포 자동화를 어떻게 증명하면 변경 실패율이 향상됩니까?

조직의 변화에 ​​동기를 부여하려는 경우 아무 것도 증명하려고하지 말고 다른 조직이 자신의 전환에 대해 말한 증거를 제공해야합니다. 이미 존재하는 프로세스를 측정하고 계속 존재하는지 정당화하려는 경우 평균 복구 시간 (MTTR)과 같은 표준 신뢰성 메트릭을 추적해야합니다.

그러나 devops 원칙은 단순히 신뢰성 향상에 관한 것이 아닙니다. 사이트 안정성 엔지니어링조차도 단순히 안정성을 높이는 것이 아닙니다. 오히려 적절한 수준의 안정성 에 도달하려고 합니다. 비즈니스에는 도움이되지만 개발에는 방해가되지 않습니다. 그리고 그것은 변화 에 힘 을 실어주는 실무자들에게 진정한 동기를 부여합니다 . 허용 가능한 범위 내에서 개발자 마찰을 줄이고 배포 속도를 높이고 수동 프로세스를 자동화하는 등의 일로 인해 비즈니스가 시장 자극에보다 신속하게 대응할 수 있기를 원합니다. 즉, 신뢰성을 측정해야하지만 속도를 측정해야합니다. 목표는 전자를 상대적으로 정적으로 유지하면서 후자를 증가시키는 것이기 때문입니다.