상태 관리

초기 메커니즘 설계 및 범위 지정 중에 인프라 상태 관리 설계 결정을 간과하는 경우가 있습니다. 그러나 개발 팀 도구 및 패턴 구분과 같이 설계에 필요한 유연성을 고려하지 않으면 상당한 양의 메커니즘 후 재작업이 발생할 수 있습니다. 상태 관리 접근 방식을 평가할 때 다음 질문을 고려하세요.

• 인프라 및 애플리케이션 상태는 누가 관리하나요?

• 상태에 문제가 발생하면 어떻게 되나요?

• 상태 문제는 누가 해결하나요?

• 중앙 팀에서 문제 해결을 처리하는 경우 이러한 접근 방식으로 인해 발생 지연 및 가동 중지가 발생하나요? 이러한 중단을 최소화하려면 어떻게 해야 할까요?

예를 들어 중앙 상태 관리 솔루션을 제공하는 조직을 가정해 보겠습니다. 이렇게 하면 개발자가 각 프로젝트의 휠을 재창조할 필요가 없으므로 솔루션 출시 속도가 크게 향상됩니다. 그러나 때때로 어떤 것이든 중단될 수 있습니다. 상태는 예외가 아닙니다. 상태가 중단되면 다음 사항을 고려하세요.

• 명확한 연락 지점(POC)이 있어야 합니다.

• POC는 문제를 해결하기 위해 즉시 사용할 수 있어야 합니다. 예를 들어 상태 관리를 사후 생각으로 사용하는 전체 작업 JIRA 목록으로 POC에 부담을 주지 마세요.

• 액세스 권한이 있는 메커니즘은 이미 작동하고 문제를 해결하기 위한 메커니즘입니다.