서로의 관계를 포함하여 IT 기술 스택을 그래프 데이터베이스에 문서화하기 위해 권장되는 것은 무엇입니까?


12

500 명 이상의 IT 직원과 1,000 명 이상의 서버를 보유한 대기업에서 각 서버가 자체 비즈니스 응용 프로그램을 실행하면 어느 IT 직원이 어느 서버에 연락해야하는지 파악하는 데 엄청난 정보와 조정 문제가 있습니다. 조정 문제는 다른 IT 직원이 IT 계층의 여러 계층을 책임지고 있기 때문에 더욱 복잡해집니다. 예를 들어 하드웨어, 가상화, 운영 체제, 응용 프로그램 서버 및 응용 프로그램 자체를 담당하는 여러 팀이 있습니다.

이러한 과제를 고려하여 DevOps에는 IT 환경 내에서 다양한 기술 스택을 구성하는 모든 구성 요소를 정의하고 문서화해야합니다. 전통적으로 이것은 적절한 CMDB 솔루션으로 수행되었을 수 있습니다.

이 목적을 위해 BMC Atrium 및 기타 와 같은 일반적인 CMDB 솔루션을 조사 했지만 문제는 ITIL 프레임 워크에 따라 IT 자산 자체를 높은 수준으로 문서화하는 수준에서 멈추지 만 문서를 다루지 않는다는 것입니다 IT 기술 스택의 세부 사항. 또한 Puppet , AnsibleSalt 와 같은 도구를 조사 했지만 이러한 도구는 소프트웨어 배포 및 구성에 중점을두고 소프트웨어 관련 인력 조정에 중점을 두지 않습니다.

예를 들어, 실행 가능한 솔루션은 이러한 개념에 중요한 주요 속성과 함께 다양한 개념을 정의합니다.

  • 하드웨어
  • 가상화
  • 운영체제
  • 응용 프로그램 서버
  • 응용

그런 다음 이러한 개념은 솔루션을 형성하기 위해 관계 측면에서 서로 연관됩니다. 예를 들어, 응용 프로그램은 운영 체제 등에 의존하는 응용 프로그램 서버에 의존합니다. 함께이 솔루션은 "금융 시스템"에서 정의됩니다. 시스템을 정의하면, 스택 내의 각 계층에 대한 조정을 용이하게하기 위해 이들 시스템과 관련된 모든 메타 데이터가 캡처 될 것이다. 즉, 각 계층에 대한 기술 지원 직원의 조정입니다.

이러한 솔루션의 목적은 다음과 같은 기술 스택에 대해 다양한 쿼리를 수행하는 것입니다.

  • 누가 어떤 구성 요소를 지원하는지 확인하려면
  • 오래된 구성 요소
  • 패치해야 할 구성 요소

이를 염두에두고 Neo4J와 같은 그래프 데이터베이스에서 IT 기술 스택의 모든 구성 요소 (서로의 관계 포함)를 정의하기 위해 어떤 오픈 소스 도구가 있습니까?


시스템, 인력, 팀 등의 관점에서 조직의 규모는 얼마입니까?
030

1
폐쇄 이유에 대한 더 많은 통찰력을 얻으려면 여기에 너무 많은 질문이 있으며 그중 일부는 CMDB에 관한 것이고 다른 요점은 감사 및 준수에 관한 것입니다. 이것에 대한은 총알은 없으며 이것은 실제 환경과 사용중인 것에 크게 의존합니다. 구성 관리자를 사용합니까? 주위를 둘러보고 필요에 맞는 도구를 찾지 못했습니까? 이 질문은 조언에 대한 설문 조사이므로 모든 사람들이 선호하는 솔루션을 갖게 될 것입니다.이 사이트에는 적합하지 않으며 기존 도구를 살펴보고 한 번 더 구체적인 것을 요청하십시오.
Tensibai

이것은 이상하게 들릴 수 있지만 더 일반적이지만 사용자 정의 가능한 엔터프라이즈웨어 하우징 솔루션도 가능합니까?
피터 Muryshkin

편집 해 주셔서 감사하고 축하합니다. 이제 훨씬 더 대답하기 쉬운 질문입니다. 나는 여전히 그 밑에 그래프 데이터베이스를 가지고 싶은 충동을 얻지 못하지만 (필요하지는 않음) 정답이 있으면 생략 할 수 있다고 가정합니다.
Tensibai

@제이. Doe 엔터프라이즈웨어 하우징 솔루션은 작동 할 수 있지만 이러한 문제점을 해결하는 오픈 소스 솔루션이 있습니다. 믿거 나 말거나, 많은 도구가 있지만 실제로이 문제를 해결할 수있는 도구는 없습니다. 서버 관리 측면에서 우리는 BMC ADDM을 사용하지만이 도구의 주요 단점은 응용 프로그램 중심이 아니라 서버 중심이라는 점입니다. 결과적으로 하나의 서버가 많은 응용 프로그램을 호스팅 할 때 서버 수준의 연결 만 제공되므로 여러 응용 프로그램 소유자를 쉽게 연결할 수있는 방법이 없습니다.
Grant Durr

답변:


5

첫 번째 단락을 고려할 때 설명하는 조직은 매우 사소한 조직이며 DevOps 조직이 피하는 경향이 있습니다.

이러한 과제를 고려하여 DevOps에는 IT 환경 내에서 다양한 기술 스택을 구성하는 모든 구성 요소를 정의하고 문서화해야합니다. 전통적으로 이것은 적절한 CMDB 솔루션으로 수행되었을 수 있습니다.

관리 시스템이 필요한 문서입니다 ITIL,하고 당신은의주의 사항과 모든 개발 문서에 돌아 오기 등 같은 개발 운영 팀은 일반적으로 코드로서 기본 레이어를 정의 할 사실과 혼합 할 수 당신이 여기에 설명하고 코드 민첩한 개발 방법론을 위해 스크럼 방법론에서 종종 볼 수있는 문서 입니다 (반복이 끝날 때 최소한의 작업 솔루션을 목표로하는 신속하고 짧은 반복)

이 답변의 나머지 부분에 대한 면책 ​​조항 : 나는 요리사와 inspec에 대해 더 많이 알고 있으므로 여기에서 예시로 사용합니다. 그러나 그것들은 시장에 존재하는 유일한 도구는 아니지만, 더 좋은 도구는 더 편한 도구이므로 이에 대한 토론을 열지 않을 것입니다.

따라서 나머지 질문은 약간 편향되어 있으며 개인적으로 코드 및 구성 관리 시스템 코드 문서로 인프라보다 더 많은 계층 관계를 설명하는 조직을 발견하지 못했습니다. (다시 말해서, 아무도 그것을하지 않는다는 것을 의미하지는 않습니다.
요리사 환경에서 우리 회사를 설명하기 위해 응용 프로그램 요리 책은 의존성 (tomcat, jboss, nginx / php 및 어떤 OS, 일부 공유 데이터에 대한 마운트 포인트가 필요하고 대부분의 DB 스키마 이름이 필요함)을 선언하고 서비스 URI를 요리사가 다른 응용 프로그램 구성을 위해 소비합니다. 이는 '금융 시스템'을 정의하는 것과 같 으며이 응용 프로그램 요리 책 README에있는 문서와 실제로 필요한 경우 더 많은 파일이 있습니다.

구성 관리 시스템에는 일반적으로 중앙보고 장소, 데이터를위한 "chef-server"가 있으며 요리사 세계에서 프레젠테이션을위한 "UI 관리", "anible tower"는 두 가지 이름을 지정할 수 있지만 일반적으로 종속성을 그래프로 표시하는 것보다 전체 관리 시스템

즉, chef의 경우, chef-server는 다양한 도구 (HTTP 요청에서 JSON 데이터를 리턴 함)로 쿼리 할 수있는 CMDB 역할을하며, 애플리케이션 간 종속성을 다양한 방식으로 표현할 수 있으며 '출시'가 없습니다. 방법을 사용하면 각 회사는 구성 목적으로 시스템에서 선언 할 수있는 고유 한 방법을 가지므로이를 활용하여 그래프를 작성할 수는 있지만 이는 귀하의 몫입니다.

코드 관점의 인프라에서 인프라 요구 사항은 응용 프로그램과 함께 유지 될 것입니다. 미들웨어, 필요한 OS, 로캘, 기타 서비스 종속성 및 서비스에 따라 필요한 사항을 여전히 알고있는 응용 프로그램입니다. 이 응용 프로그램 제공).

문서에 대한 종속성을 관리하려는 경우 마지막으로 생각할 수 있는 것은 주로 CMDB 및 발권 시스템 인 glpi 와 같은 도구 이며, 자산을 열 때 영향을 미치는 내용을 알 수 있도록 자산과 관련성을 문서화합니다. 응용 프로그램이 다운되었다는 티켓. ng-inventory와 결합하면 시스템 상태를 쿼리 할 수 ​​있으며 패치 요구에 대한 쿼리를 수행 할 수 있지만 다음 단계는 요리사 실행 내에서 통합을 검사 할 수있는 것과 같은 감사 시스템 작업입니다. 오래된 시스템을 업데이트 / 패치하여 수정해야합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.