시스템 종속성을 추적하는 방법?

Question

소개

현재 조직에는 많은 데스크탑 및 웹 응용 프로그램이 모두 서로에게 공급됩니다. 이전 애플리케이션을 보거나 새로운 애플리케이션을 만들 때 작업을 위해 다른 시스템에 의존하는 시스템을 시도하고 기억하는 것이 매우 어려운 것으로 입증되었습니다. 나는 DLL 및 이미지와 같은 소프트웨어 의존성에 대해 이야기하는 것이 아니라 HR 시스템 등에 의존하는 금융 시스템과 같은 전체 시스템에 대해 이야기하고 있습니다.

내 질문

하나의 시스템 전체가 다른 시스템에 어떻게 의존하는지 추적하는 가장 좋은 방법은 무엇입니까?

_{답은 위의 방법, 소프트웨어 패키지 또는 문서 기술을 수행하는 방법을 제안 할 수 있습니다.}

_{내 특별한 경우, 많은 12 개의 서버에 걸쳐 20 개가 넘는 웹 및 데스크탑 응용 프로그램을 의미합니다.}

Answer 1

나는 당신의 아키텍처 설계 문서에서 그것을 명확하게 말하고 싶습니다. 이와 같은 좋은 도구가 있습니다 엔터프라이즈 아키텍트. 이 도구를 사용하면 이러한 종속성을 명확하고 시각적으로 설명하기 위해 UML 표준을 사용하여 다이어그램을 만들 수 있습니다.

Answer 2

가장 좋은 정보 소스는 일반적으로 구성 파일에서 찾을 수 있습니다. 이것은 일반적으로 연결 문자열, 웹 서비스 URL 등이있어 외부 종속성에 대한 좋은 아이디어를 제공합니다.

또 다른 기술은 프로파일 링 또는 추적 및 적용 필터를 사용하여 외부 통화를 쉽게 추적 할 수 있습니다. 대부분의 경우 종속성은 데이터베이스 계층에 있으며 링크 된 서버를 확인하고 종속성을 추적하면 많은 정보가 발굴 될 수 있습니다.

특히 시스템이 여러 플랫폼에있는 경우이 정보를 얻을 수있는 자동 방법이 있는지 확실하지 않습니다. 많은 수동 작업 이이 모든 것을 문서화하기 위해 참여할 것입니다.

Answer 3

이것은 우리가 생산하는 응용 프로그램입니다 조수 시스템, 그리고 많은 대형 조직 이이 목적으로 사용하는 것입니다. 제품을 사용하여 부동산을 발견하고 모델링 기능을 사용하여 비즈니스 앱 (일반적으로 하나 이상의 소프트웨어 및 스팬 서버로 구성)을 설명 할 수 있습니다.

최대 30 개의 서버에서 사용할 수있는 Free Community Edition of Foundation을 사용할 자격이있는 것 같습니다. 다운로드 그것을 확인하십시오. 그런 다음 당신이 생각하는 것을 알려주세요!

면책 조항 : 개발 그룹을 운영합니다 조수. 제품은 매우 멋진 IMO입니다.

Answer 4

각 기계를 하나씩 끄고 어떤 파손이 있는지 확인하십시오.; P

진지하게,이 질문에 대한 간단한 대답은 없습니다. 시스템 모음을 사용하면 기본 종속성을 보여주는 다이어그램을 만들 수 있지만 종속성이 무엇인지에 대한 아이디어가 없다면 큰 의미는 없습니다. 일반적으로 목표는 다른 시스템을 변경할 때 "재귀"에 필요한 것을 결정하는 것입니다. 그러나 이러한 종류의 정보에는 많은 세부 사항이 필요하며 처음에는 축적하기가 어렵습니다.

이 모든 것은 결국 시스템이 자동화보다 앞서있는 상황에서 끝납니다. 줄어든 래핑 된 자동화 도구를 찾지 못할 것입니다. 반면에, 워크로드의 절반 또는 3 분의 1을 처리 할 수있는 필요한 모든 것을 세부적으로 사용하는 것은 가치가 있습니다.

Answer 5

이것은 좋은 질문입니다. 우리는 매번 이것으로 어려움을 겪고 있습니다.

우리가 작년에 시도한 것은 두 가지에 대해 "무자비한"것입니다.

1. 자동화 - 자동화하고 자주 빌드/배포하면 자동화 프로세스는 대부분의 시간을 제대로 얻는 경향이 있습니다 (구성 설정 등).

2. Wiki, Wiki, Wiki- 우리는 팀과 프로젝트 Wiki를 최신 상태로 유지하는 데 하드 코어가 되려고 노력합니다.

다른 응답을보고 궁금합니다.

Answer 6

가능한 한 자동화되는 기업 발견을위한 직업처럼 들립니다. 조직의 규모와 환경에 따라 다른 솔루션이 있습니다. 큰 환경의 경우 CMDB (구성 관리 데이터베이스)가 필요합니다. 제품과 같은 제품 HP 범용 CMDB 대규모 환경에서 의존성을 발견하고 추적 할 수 있습니다.

예를 들어 SAP 시스템과 관련 데이터베이스와 분산 시스템이 실행중인 호스트 간의 관계를 발견하고 종속성을 표시 할 수 있습니다. 더 중요한 것은 실제 환경에 대한 일부 무단 변경이 수행 될 경우 경고 할 수 있습니다.

따라서 대답은 당신이 '많은 것'으로 간주하는 것에 달려 있습니다.

Answer 7

관련된 두 가지 문제 :

a.) 각 구성 요소의 종속성을 결정하는 방법을 알고 싶은 사람들을 위해

b.) 구성 요소 시스템에서 상호 의존성과 우선 순위를 추적하려는 사람들. (어떤 구성 요소가 테스트 환경에 먼저 설치되는지와 마찬가지로 ...)

당신이 가지고있는 것이 일련의 구성 요소이고, 각각 의존성을 알고 있고 전체 구성 요소 목록에 대한 종속성 순서를 원한다면, algorithm :: 종속성 :: value로 주문할 수 있습니다. . 구성 요소 등의 데이터베이스 레코드 또는 간단한 파일 레코드와 함께 작동 할 수있는 다른 관련 모듈이 있습니다. 그러나 경고 : 나는 이것을 작동시키는 데 문제가있었습니다.

또는 그래프 도구가 가치가있을 수 있습니다.

Answer 8

이것은 "구성 관리"그룹의 기능입니다. 시작하려면 회사의 "전문가"와 대화하고 응용 프로그램의지도/그래프를 만들어야합니다. GraphViz/DOT를 사용하여 다이어그램을 생성하면 예쁘지는 않지만 종속성을 시각적으로 표현할 수 있습니다.

예는 다음과 같습니다.

digraph g {
 rankdir=LR;
 app1->app2->db1;
 app1->app3;
}

도움이 되었기를 바랍니다,

Answer 9

시스템 의존성 매핑은 한 가지입니다. 진정한 환경 설정, UID, 암호, 사칭 설정, 데이터베이스 이름 및 개발에서 QA, UAT로의 생산으로 변경되는 기타 데이터는 실제 과제입니다.

누가 그들 모두를 저장/기억합니까?

개발자는 애플리케이션이 어떤 제작 서버에 상주할지 모릅니다. 그는 자신의 개발 데이터베이스, UID, PWD의 이름 만 기록하고 데이터베이스 테이블, 연결 문자열 등을 설명합니다.

코드 리포지토리에 체크인하고 QA 환경으로 마이그레이션되면 해당 구성 파일을 적절한 값으로 업데이트하는 데 필요한 데이터의 보관 인 사람은 누구입니까?

다시 QA와 UAT로 마이그레이션했을 때 누가?

다음 마이그레이션 그룹에 변경해야 할 사항을 알리는 것은 누구의 책임입니까?

우리 회사에서 이것이 우리에게 가장 두통이되는 원인입니다. 내부 변경 제어 프로세스에 의해 승인되고 응용 프로그램을 생산 환경으로 마이그레이션하기 위해 마이그레이션 요청이 생성 될 때까지 전체 구현을 망치기 위해 잊어 버리는 하나의 구성 설정 만 있으면 항상 발생합니다. 명확한 책임 선은 (내 불투명에) 그려지지 않습니다.

책임 외에는이 정보의 중심 저장소라고 생각합니다.

즉. 모든 프로젝트/애플리케이션에 대한 모든 구성 설정을 저장하는 시스템 및 "역할"을 기반으로 실제 값을 볼 수 없습니다.

개발자는 빌드를 완료하고 "시스템"에서 마이그레이션 요청을 만듭니다. QA 담당자는 Build ###이 준비되어 있다는 알림을받습니다. QA 사람은 "시스템"에 로그인하여 마이그레이션 지침을 검색합니다. 이제 그들은해야 할 일을 분명히 알고 코드 확인 및 마이그레이션 프로세스를 간청합니다.

UAT를 반복하고 궁극적으로 prod.

누군가 가이 마이그레이션 시스템을 구축하면 많은 사람들이 도움이 될 것이기 때문에 알려줍니다.

어쩌면 나는 그것을 직접 만들 것입니다 ... 누가 저를 계약하고 싶은가?

Answer 10

나는 직업을 처음 접했고, 시스템 종속성을 식별하는 첫 번째 작업으로 제안되었습니다. 내 상사가 의미하는 바는 사람들과 이야기하는 것이 었습니다. 그렇게하면 누가 누구인지 배울 것입니다. 나는 상사가 컴퓨터 프로그램을 작성하기를 원한다고 생각했다. 그래서 나는했다. 내 가정은 프로그램이 다른 프로그램 (서비스 또는 서버)의 클라이언트라면 netstat -pant 그리고 netstat -panu 그러면 Grep에 대한 Grep은 당신에게 그것을 줄 것입니다. 청취를 위해 출력을 막아 서비스를 식별 할 수 있습니다.

이것은 부분 솔루션 일뿐입니다. 예, 어떤 응용 프로그램이 어떤 응용 프로그램에 대해 이야기하는지 알려주지 만 다른 종속성이 있습니다. 예를 들어 일부 응용 프로그램은 DNS를 사용하여 서버를 찾는 반면 다른 응용 프로그램은 하드 코딩 또는 구성 파일에 있습니다. TCP 또는 UDP를 사용하는 것은 IP에 따라 다릅니다. 대부분의 장소에서 IP는 ARP 및 이더넷 또는 WiFi에 따라 다릅니다. 다른 LAN의 서비스에 의존하는 것은 하나 이상의 라우터에 의존합니다.

로드 밸런서 또는 일종의 클러스터가 있으면 문제가 더 흥미로워집니다. 로드 밸런서에서 나오는 서비스와 방화벽 뒤의 "실제"서버가 다운되면 서비스가 저하되지만 여전히 상승합니다.

서비스 (프로그램)가 서버 (하드웨어)에 의존하기 때문에 더욱 흥미로워집니다. 서버는 전력 및 에어컨에 의존합니다.

내 생각이 통제 불능 상태가되면서 상황이 더욱 복잡해졌으며, 이러한 모든 종속성을 포착하기 위해 도메인 별 언어 (DSL)를 만드는 것에 대해 생각했습니다. 예를 들어 Server_1, Server_3 및 Server_5는 Power Phase 1에 있다고 생각했습니다. Server_2, Server_4 및 Server_6은 전원 단계 2에 있습니다. Server_1, Server_3 및 Server_5는 거의 동시에 실패합니다. 아마 1 단계가 실패했을 것입니다. 나는 아직도 그것을 알지 못했다. 분명히, 상황은 지시 된 그래프로 표현 될 수 있습니다. 나는 단지 세부 사항을 해결하지 못했습니다.