계획 및 우선 순위 지정

플랫폼 엔지니어링 기능 모델을 기반으로 플랫폼 엔지니어링 작업의 목표를 식별하고, 일반적인 시나리오를 살펴보고, 성공을 측정하는 방법을 찾는 방법을 알아봅니다. 목표 범위를 비즈니스 목표에 따라 측정하여 성공을 측정합니다.

목표 및 주요 시나리오 식별

시작하려면 먼저 플랫폼 엔지니어링 기능 모델을 사용하여 조직이 현재 어디에 있는지 평가합니다. 이 모델을 사용하여 조직이 투자, 채택, 거버넌스, 프로비저닝 및 관리, 인터페이스, 측정 및 피드백 등 6가지 핵심 플랫폼 엔지니어링 기능에 걸쳐 있는 위치를 차트로 작성할 수 있습니다. 모든 조직은 다른 조직보다 일부 기능에서 더 고급입니다. 현재 조직이 어디에 있는지 알고 나면 성장하려는 기능을 선택할 수 있습니다. 자세한 내용은 모델을 사용하는 방법을 참조하세요.

시간이 지남에 따라 플랫폼 엔지니어링 목표를 지속적으로 계획하고 업데이트할 수 있습니다. 플랫폼 엔지니어링 경험에 투자하여 얻고자 하는 것을 명확히 파악하는 것은 조직 지원을 구축하는 데 큰 도움이 될 수 있습니다.

플랫폼 엔지니어링 리더로서 "나는 그것을 통해 얻을 수있는 무언가를 가질 때까지 플랫폼 엔지니어링을 위해 뭔가를하지 않습니다." - Peter, 플랫폼 엔지니어링 리드, 다국적 기술 회사

목표에 대해 생각할 때 특정 개발 팀의 세부 사항이 아닌 플랫폼 엔지니어링 노력과 관련된 비즈니스 목표로 범위를 지정합니다. 일반적인 상위 수준 플랫폼 엔지니어링 목표는 다음과 같습니다.

• 릴리스 중에 애플리케이션 품질을 높이고 버그 및 문제를 줄입니다.
• 보안을 향상시키거나, 보안 인시던트 수를 줄이거나, 프로덕션 환경에서 한 번 CVE(일반 취약성 및 노출)를 감지했습니다.
• 라이선스, 접근성, 개인 정보 보호 또는 정부 규정과 같은 영역에서 더 나은 규정 준수를 통해 위험을 줄입니다.
• 복잡성, 오버헤드를 줄이고 내부 소스 사례를 통해 코드 공유를 촉진하여 비즈니스 시간 값을 가속화합니다.
• 개발 또는 운영 비용을 줄이고 중복을 최소화하며 자동화를 개선합니다.

목표는 우선 순위 지정에 대한 생각을 구동하기 때문에 상위 목표를 선택하는 것이 중요합니다.

더 나은 아직, 당신의 리더십 및 내부 파트너와 목표 및 주요 결과 (OKR)에 동의하면 투자의 현재 단계에 대한 측정 가능한 목표를 수립할 수 있습니다. (조직에서 다른 것을 사용하는 경우 다른 계획 접근 방식에는 비슷한 개념이 있습니다.) 가장 좋은 OKR은 주관성을 제거하기 때문에 구체적인 측정값에 따라 설정할 수 있는 OKR입니다.

수행할 시나리오 및 작업

목표를 식별한 후 백로그 및 로드맵을 구동하는 주요 시나리오를 선택합니다. 예를 들어 이러한 시나리오 및 수행할 관련 작업을 참조하세요.

시나리오: 새 애플리케이션 빌드 시작

• 조직 모범 사례 및 정책 이해 및 적용
• 새 리포지토리 만들기
• 프로비전 도구
• 일반 인프라 프로비전
• 팀 구성원에게 액세스 권한 부여
• CI/CD 파이프라인 설정
• 개발 인프라 프로비전
• "파이프"를 테스트하기 위한 초기 배포

시나리오: 기존 팀에 새 멤버 추가 또는 제거

• 도구, 서비스에 대한 액세스 업데이트
• 개발자 컴퓨터 설정
• 애플리케이션에서 팀 구성원 강화
• 애플리케이션 샌드박스 환경 만들기
• 첫 번째 PR 만들기 및 검토

시나리오: 기존 애플리케이션에 대한 인프라 추가 또는 업데이트

• 조직 모범 사례, 사용 가능한 옵션 이해
• 코드 아티팩트로 인프라 업데이트/추가
• 애플리케이션 샌드박스 환경 만들기
• 업데이트 확인
• 다른 환경에 대한 변경 내용 롤아웃

시나리오: 기존 팀에 대한 도구 추가 또는 업데이트

• 조직 모범 사례, 사용 가능한 옵션 이해
• 새 도구의 사용 요청
• 도구에 대한 팀 구성원 액세스 업데이트
• (해당하는 경우) 클라이언트 또는 CI/CD 파이프라인에 도구 통합

시나리오: 기존 API, SDK 또는 서비스 찾기 또는 다시 사용

• 사용 가능한 API, SDK, 서비스 검색
• 요구 사항을 충족하는지 평가
• 모든 질문에 대해 소유 팀과 연결
• 애플리케이션 채택

시나리오: 작업 인시던트에 대응

• 문제 알림
• 앱 코드 또는 인프라가 관련되어 있는지(또는 둘 다) 평가
• prod를 미러링하는 샌드박스 환경 만들기(다른 경우)
• 변경, 테스트, 대역 외 릴리스

시나리오: 보안 인시던트를 신속하게 수정

• 문제 알림
• 문제의 폭 평가(시스템)
• 고객에게 직접적인 영향을 미치는지 이해
• prod를 미러링하는 샌드박스 환경 만들기(다른 경우)
• 변경, 테스트, 대역 외 릴리스
• 영향을 받는 모든 사용자와 통신

시나리오: 사용 중단 도구

• 도구 사용량 이해
• 사용자에게 사용 중단 알림
• (선택 사항) 새 도구로 사용자 조정 마이그레이션

시나리오: 아키텍처의 새 앱 모델 출시

• 파일럿 제안 아키텍처
• 파일럿 결과에 따라 조정
• 모범 사례 설명서 업데이트
• 템플릿 만들기, 업데이트 자동화, 정책, 거버넌스

애플리케이션 준수 감사(GDPR, 접근성, 인프라 표준)

• 현재 규정 준수 규칙 이해
• 애플리케이션이 규칙을 충족하는지 확인
• 편차 수정 기한 설정
• 변경, 테스트, 릴리스

여러 시나리오가 둘 이상의 역할에 적용됩니다. 개선을 측정하는 방법에 대한 메트릭을 생각해 보세요.

문제에서 개념으로

다음으로, 개발자 및 기타 역할이 식별한 시나리오 및 작업에 직면하는 가장 큰 문제를 이해하려고 합니다. 그것은 인식 된 격차를 채우기 위해 새로운 제품을 조사 하기 시작 유혹 수 있습니다., 하지만 이러한 제품 주요 고통 지점을 해결 하지 않는 경우, 그들은 채택 또는 감사 될 가능성이 있어.

이러한 종류의 조사를 수행하는 데 도움이 되는 몇 가지 방법이 있습니다. 하나는 가설 진행 프레임워크입니다. 가설 진행 프레임워크와 같은 공식화된 프로세스를 사용하지 않더라도 토론의 범위를 지정하기 위해 수행할 작업에 대해 개발자를 인터뷰한 다음 작업을 수행하는 데 가장 큰 문제를 식별해야 합니다. 이러한 문제가 무엇인지 잘 이해한 후에는 문제를 해결하기 위한 계획을 세우세요. 이렇게 하면 개발자가 사용하려는 기능을 빌드할 수 있습니다.

이 프로세스를 신속하게 반복하려면 내부 개발자 플랫폼 팀에서 직접 고객의 목소리를 나타낼 수 있는 사람을 식별합니다. 이 역할은 일반적으로 제품 관리자(직위가 다른 경우에도)라고 하며, 지식이 증가함에 따라 더 작은 의사 결정에 대한 결과를 정확하게 예측하고 더 많은 인터뷰를 수행해야 하는 시기를 결정할 수 있습니다. 이렇게 하면 민첩성을 유지하면서도 내부 고객에게 가치를 제공하는 데 집중할 수 있습니다.

초기 투자에 대한 사례 만들기

검증된 문제 및 개념 집합이 있으면 투자할 위치를 결정할 수 있는 좋은 위치에 있습니다. 그러나 솔루션을 평가할 때 필요한 선행 투자 및 장기 유지 관리를 고려합니다. 문제를 해결할 수 있는 가장 낮은 노력 솔루션은 시작하는 것이 옳은 경향이 있지만, 투자 성공 여부를 궁극적으로 결정하는 것은 유지 관리 작업인 경우가 많습니다.

다른 방법으로, 실제로 필요한 경우가 아니면 여정의 이후 단계를 대상으로 하는 솔루션을 만들지 마세요.

가장 얇은 실행 가능한 플랫폼(TVP)(플랫폼용 MVP)을 확인했으면 피드백을 제공하려는 개발 팀 세트로 파일럿합니다. 파일럿 솔루션이 이러한 팀이 직면하고 있는 문제를 해결하는 경우 참여에 관심이 있는 사람을 찾는 데 문제가 없어야 합니다.

새 기능 또는 변경 내용을 파일럿할 때 몇 가지 주요 메트릭을 캡처해야 합니다. 따라서 개념이 출시되기 전에 성공했는지 여부를 측정할 수 있습니다.

성공 및 증명 값 측정

얼마나 성공적인지 측정하는 것은 제품 사고 방식의 중요한 부분입니다. 적당한 투자로 작은 성공을 거두더라도 더 큰 투자를 구축할 수 있는 토대를 마련할 수 있습니다.

예를 들어 비즈니스 가치를 제공하는 개발 팀에 운영세로 인식될 수 있으므로 규정 준수 노력에 대한 자금 조달 또는 구매를 확보하기 어려울 수 있습니다. 제품 사고방식은 이러한 인식을 바꿀 수 있습니다. 제품 사고방식을 통해 내부 개발자 플랫폼의 고객이 만족하고 이해 관계자의 비즈니스 목표를 충족할 수 있도록 하려고 합니다. 메트릭을 사용하면 사실을 사용하여 비즈니스 가치를 제공하고 있음을 증명할 수 있습니다. OKR을 설정하면 특히 주관적 편견을 제거하는 데 사용할 수 있는 메트릭이 있는 경우 도움이 될 수 있습니다. 현재 적용 가능한 항목을 측정하지 않더라도 학습 OKR을 설정하여 이 기준을 알고 나면 구체화할 기준을 설정할 수 있습니다.

다음은 작업 중인 팀이 빌드 중인 작업에서 가치를 얻는지 확인하기 위해 측정할 수 있는 잘 알려진 메트릭의 예입니다. 사용자와 개발 팀 고객이 목표를 달성하고 있는지 여부를 측정하는 데 도움이 되는 항목은 0입니다. 예를 들어 다음은 플랫폼이 효과적인 엔지니어링 조직에 기여하는지 여부를 평가하는 데 도움이 되는 메트릭 집합입니다.

• 속도/비즈니스 간 값: 첫 번째 끌어오기 요청(온보딩)을 완료하는 데 걸리는 평균 일수, 빌드 및 테스트 프로세스의 평균 분(예: CI), 끌어오기 요청을 병합하는 데 걸리는 평균 시간입니다.
• 소프트웨어 품질: 개발당 매월 생성된 인시던트(문제)(개발 수로 정규화된 수), MTTR(평균 수정 시간), 보안 문제를 조사하고 수정하는 평균 시간입니다.
• 플랫폼 사용 편의성: NSAT(순 사용자 만족)
• 번성하는 생태계: 설문 조사된 각 질문에 대한 평균 점수: "나는 최선을 다할 수 있는 힘이 있다", "내가 하는 일에 활력을 불어넣는 대부분의 날", "내가 하는 일은 나에게 의미가 있다."

그런 다음 조직, 팀 또는 프로젝트별로 이러한 메트릭을 분석할 수 있습니다. 시작하려면 일부 기준을 측정해야 하지만 플랫폼을 개선할 때 이러한 메트릭이 변경되는 것을 볼 수 있습니다.

귀하 또는 귀하의 스폰서가 측정하는 데 관심이 있는 다른 메트릭은 다음과 같습니다.

영역	예제 메트릭
소프트웨어 배달 성능	DevOps DORA(연구 및 평가): 리드 타임 변경, 배포 빈도, 변경 실패율, MTTR(서비스 복원 시간)
작업	DORA(MTTR), MTBF(평균 실패 간 시간), 승인 평균 시간, 최종 고객 가용성, 대기 시간, 처리량 메트릭, 팀당 비용, 배포당 비용
플랫폼 기능 채택 메트릭	시간에 따른 도구 또는 기능을 사용하는 팀 또는 개발자 수, 플랫폼을 사용하는 리포지토리의 비율, 가장 인기 있는 템플릿, 파이프라인 등

메트릭을 수집하려면 시간과 노력이 필요하므로 식별한 핵심 목표, 특히 OKR을 구동하는 핵심 목표에 대한 중요한 메트릭에 집중하는 것이 중요합니다. Application Insights와 같은 OpenTelemetry 기반 제품이 도움이 될 수 있습니다. 그럼에도 불구하고 플랫폼 사용 편의성을 측정하고 정기적으로 번성하는 에코시스템을 가지고 있는지 조사해야 합니다. 이러한 메트릭은 종종 내부 시스템에 대해 누락되며 참여 참여가 성공에 중요하기 때문에 보다 광범위한 비즈니스 목표를 충족하는지에 대한 선행 지표입니다. 또한 다음에 어디로 가야 할지 이해하기 위해 추가 고객 개발을 수행할 때인지 여부를 알 수 있습니다.

기타 팁

시작하는 방법에 관계없이 변경을 계획하고, 파일럿을 위한 새 애플리케이션으로 시작하고, 기존 사용자 환경을 개선하는 데 집중하고, 최소 권한 원칙을 채택하고, 제어된 실험을 계획하고, 사용자 지정을 최소화해야 합니다.

변경 계획

대상 애플리케이션 플랫폼은 시간이 지남에 따라 진화하며 기존 투자를 한 번에 모두 마이그레이션하지 못할 수 있습니다. 시간이 지남에 따라 둘 이상의 변형을 지원하고 변화를 계획할 수 있는 방법을 생각해 보세요.

최신 애플리케이션을 사용하여 아이디어 유효성 검사

새 플랫폼 또는 플랫폼 기능을 파일럿할 때 적절한 크기의 새 애플리케이션으로 시작합니다. 이렇게 하면 플랫폼을 제품으로 관리하는 환경도 제공됩니다. 진행하면서 학습하므로 프로젝트를 다시 배포하는 것을 피해야 하며, 대규모 기존 애플리케이션에는 플랫폼 재설정 노력 자체 중에만 드러나는 고유한 요구 사항이 있는 경우가 많습니다. 따라서 이러한 유형의 노력과 성공을 결합하면 기대 불일치 또는 늦게 발생하는 문제가 발생할 수 있습니다. 새로운 것부터 시작하여 제공하는 가치에 대한 확신을 가질 수 있습니다. 이렇게하면 이러한 더 큰 노력을 해결할 위험이 줄어듭니다. 다른 방법으로, 사람들이 올바르게 시작하고 올바르게 유지할 수 있다고 확신한다면 경험에서 배운 것을 사용하여 올바른 캠페인을 진행하는 것이 더 쉬워집니다. 이 방법을 사용할 수 없는 경우 모든 항목을 한 번에 변경하는 대신 신중한 분석을 수행하고, 기대치를 설정하고, 증분 방식으로 한 단계씩 들어가야 합니다.

새 환경을 만들기 전에 사용자 환경을 위한 기존 무게 중심 집중에 집중

개발자는 이미 좋아하고 사용하는 기능으로 표시될 때 새로운 기능을 채택하고 고수할 가능성이 더 높습니다. 새로운 기능을 제공하기 위해 개념을 평가할 때 기존 "무게 중심"을 확장하는 옵션을 조사해야 합니다. 예를 들어 편집기/IDE(Visual Studio, VS Code), DevOps 제품군(GitHub, Azure DevOps), 기존 CLI 또는 기존 내부 포털은 완전히 새로운 포털 또는 다른 UX보다 더 효과적일 수 있습니다. 자세한 내용은 사용자 환경을 참조하세요.

최소 권한 원칙 가정

개발자가 인프라 프로비전과 같은 항목에 대해 다운스트림 시스템에 대한 액세스가 제한된다고 가정합니다. 셀프 서비스 환경에 대해 이 액세스를 사용하도록 설정하는 제어된 방법이 필요합니다.

제어된 실험 계획

주요 변경 내용 또는 위험한 변경 내용을 롤아웃하기 전에 실험합니다. 시작하기 위해 모든 것을 완전히 자동화해야 하는 것은 아닙니다. 자동으로 트리거되는 수동 워크플로는 아이디어를 파일럿하는 좋은 방법이 될 수 있습니다.

App Platform 사용자 지정 최소화

소프트웨어 공급업체가 시간이 지남에 따라 릴리스하는 기능에 의해 가려질 수 있는 사용자 지정 빌드 애플리케이션 플랫폼 기능을 방지합니다. 예를 들어 런타임 호스팅, 서비스 메시, ID 시스템 등이 있습니다. 이와 같이 의심되는 영역에서 긴급한 요구가 있는 경우 장기 유지 관리로 인해 시간이 지남에 따라 전환할 수 있는 여러 구현 옵션을 계획합니다.

소프트웨어 엔지니어링 시스템 적용