데이터 자산 시스템을 구축할 수 없는 SRE는 좋은 유지 관리 담당자가 아닙니다.

1. 데이터 자산의 이해

1. 데이터 자산 - 기업 IT 가치

그림

그림과 같이 데이터 자산화가 이루어지지 않은 상태에서는 데이터가 분리된 상태일 수 있으며, 및 소비 균일성이 없으면 데이터 섬이 발생하거나 혜택이 전혀 발생하지 않기 쉽습니다.

데이터 자산화를 구축한 후 다양한 채널의 데이터를 통합하고 통일된 데이터 소스를 구성하거나 데이터 수집, 저장 및 분석을 위한 링크를 처리한 다음 해당 데이터 구조, 데이터 관계 및 소비 출구를 통합합니다.

운영 데이터를 수집하고 정리한 후에는 자체 의사 결정 및 비즈니스 프로세스를 제공할 수 있습니다.

2. 데이터 자산 - 운영 및 유지 관리 시나리오를 예로 들었습니다

사진

위 그림은 데이터 자산의 분류를 소개하기 위해 시나리오를 예로 들었습니다. 데이터 자산을 이해하려면 데이터 자산의 세 가지 요소, 즉 데이터 유형, 데이터 형식 및 데이터 매체 간의 대응 관계를 이해해야 합니다.

• 데이터 유형: 운영 및 유지 관리 특성에 대한 정보 설명

비즈니스 지표 수준에서 SRE는 운영 소프트웨어 수준에서 거래 시간, 거래 주문량 및 기타 정보에 중점을 두고 있으며 SRE는 사용자 IP, 인터페이스 호출 상태에 중점을 두고 있습니다. 인프라 수준의 기타 정보. 그런 다음 해당 네트워크 패킷 손실률, 메모리 사용량 또는 CPU 사용량 및 기타 정보에 중점을 두고 SRE는 변경 이벤트, 파일럿 릴리스 횟수 또는 긴급 변경과 같은 데이터에 더 많은 주의를 기울입니다. .

• 데이터 형식: 데이터가 데이터 매체에 저장되는 형식

관계형 데이터베이스, 지속성 데이터베이스, 메시지 큐 등 로그, 관계형 및 모니터링 데이터의 다양한 표현 형식을 기반으로 해당 저장 방법을 선택합니다. 또는 로그 파일 등

• 데이터 캐리어: 운영 및 유지 관리 데이터에 대한 저장 방법 제공

3. 데이터 자산 - SRE의 가치 향상

사진

획득한 운영 및 유지 관리 데이터를 기반으로 먼저 자산을 구축합니다. 애프터 서비스와 같은 기반 플랫폼 기사에 언급된 CMDB. 이러한 플랫폼을 사용하여 소비 시나리오에 따라 대량의 운영 및 유지 관리 데이터를 분해 및 관리함으로써 자산화를 실현합니다.

또한 디지털 자산 플랫폼을 활용하면 SLO, 용량 관리 플랫폼 등 SRE 안정성과 관련된 플랫폼을 빠르게 구축하고 개선할 수 있습니다. 플랫폼이 성공적으로 구축되면 데이터의 잠재적 가치를 지속적으로 탐색하고 SRE가 중점을 두는 안정성을 향상시킬 것입니다.

2. 데이터 거버넌스 - 방법론

1. 운영 및 유지 관리 데이터 표준이 직면한 문제

Pictures

운영 및 유지 관리 데이터 표준화에서 직면한 문제는 빅데이터 시나리오의 데이터 품질 문제와 유사하며, 주로 데이터 섬을 포함하며, 데이터 품질이 높지 않고, 데이터가 불가지론적이며, 데이터 서비스가 부족하고, 데이터 획득 개발에 오랜 시간이 걸리는 등의 문제가 있습니다.

이러한 문제로 인해 데이터 소비 시나리오를 신속하게 반복하고 비즈니스 요구 사항을 충족하기가 어렵습니다. 인력, 서버 자원, 미들웨어 자원 등이 부족할 경우 데이터 표준화 구축은 치명적인 영향을 미치게 됩니다.

운영 및 유지 관리 데이터는 본질적으로 비표준입니다. 예를 들어 로그와 로그 모니터링의 데이터 저장 방법이 다릅니다. 그리고 제한된 자원 하에서 정교화를 극대화하고 표준화를 완료해야 합니다.

DataOps, AIOps 및 기타 모델이나 시나리오와 같이 업계에서 최근 인기 있는 개념의 경우 아직 성숙하고 포괄적인 데이터 모델링 방법론이 부족합니다.

2. 운영 및 유지 관리 데이터 거버넌스 모델 구축

운영 및 유지 관리 데이터를 데이터 자산으로 승격하려면 거버넌스 방법, 거버넌스 프로세스 및 기술 플랫폼의 세 부분에 중점을 두어야 합니다.

Pictures

1) 거버넌스 방법

• 마스터 데이터 관리: SRE가 중점을 두는 데이터를 정의하고 분할합니다. 예를 들어, 호스트, CLP 등의 데이터를 마스터 데이터로 활용하고 이에 대한 라이프사이클 관리를 수행합니다.
• 일반화된 메타데이터 관리: 이러한 데이터는 일반화된 메타데이터 관리인 폐쇄 루프 보고 프로세스에서 CMDB에 입력됩니다. CMDB 모델로 표현되며 해당 데이터 지원은 상위 수준에 제공됩니다.
• 핵심 거버넌스 링크: 데이터 표준, 거버넌스 품질, 보안 기준의 세 가지 차원을 기반으로 전체 변경에 대한 전체 거버넌스 링크, 즉 데이터 표준, 품질 목표, 기준 요구 사항을 정리합니다.

2) 거버넌스 프로세스

거버넌스 프로세스에는 전략, 구축, 운영이 포함됩니다. 전반적인 구축 측면에서는 자체 운영을 지원하는 플랫폼과 도구를 구축하는 것이 필요합니다.

3) 기술 플랫폼

기술 플랫폼 구축의 주요 목적은 도구를 통해 기존 및 증분 데이터를 지원하는 것입니다.

3. 데이터 거버넌스의 핵심 요소에 집중

데이터 거버넌스의 핵심 요소는 주로 조직 보장, 시스템 구축, 프로젝트 구현 및 플랫폼 지원의 네 가지 측면에 중점을 둡니다.

• 조직 보장: 인적 자원 문제를 해결하기 위해 구성원의 역할과 책임 분담을 명확히 합니다. 전담 데이터 거버넌스팀은 제품, 운영, R&D의 세 가지 역할로 구성됩니다.
• 시스템 구축: 리소스 액세스, 리소스 개발, 리소스 데이터 모델 및 기타 사양과 같은 표준화된 프로세스를 구축하고 질서 있는 구현을 보장하는 것이 필요합니다.
• 프로젝트 구현: 전반적인 특별 관리를 시작하세요. 데이터 거버넌스는 단순한 캠페인이 아닌 장기적인 프로세스입니다. 데이터 품질이 심각하게 표준에 미치지 못하는 경우, 우리는 특별 팀을 구성하고 모바일 접근 방식을 채택하여 데이터 품질 문제를 긴급하게 복구할 것입니다. 그러나 장기적인 거버넌스 구축이란 데이터 제품을 기반으로 해당 거버넌스 방법론을 출력하는 것을 의미하며, 이를 제품화된 플랫폼으로 구현하는 것은 데이터 책임자가 데이터 거버넌스를 수행하도록 유도하는 것을 의미합니다.
• 플랫폼 지원: 플랫폼 구축은 주로 정밀한 측정, 실행, 거버넌스 효율성 및 기타 차원에 중점을 둡니다.

3. CMDB 플랫폼 구축

1. CMDB 구성 관리 라이브러리

CMDB 구성 관리 사무실은 주로 기본 파일링 기술 원장, 세부 자연 속성, 자연 관계 및 자원 소비 맵의 네 가지 측면을 중심으로 구축됩니다. 비즈니스에 해당하는 모델을 계층별로 구축한 다음 자동화된 감지 또는 표준화된 프로세스를 통해 실시간으로 구성 역학을 푸시해야 합니다.

해당 구성에는 협업을 촉진하기 위한 해당 시각적 인터페이스도 필요합니다. 궁극적으로 이러한 데이터는 APP 또는 해당 오프라인 시나리오를 통해 데이터 소비 시나리오를 촉진합니다.

2. ITIL 시대의 CMDB 위치 - 메타데이터 센터

개인적으로는 CMDB가 메타데이터 센터라고 생각합니다. 위 그림에 표시된 것처럼 당사의 구성 관리 데이터베이스 CMDB는 조직, 인력, 결정, 권한, 프로세스 등과 관련된 데이터를 정리하거나 조립합니다.

모니터링 플랫폼, 이메일, 문자 메시지, 운영 및 유지 관리 데이터베이스 등과 같은 많은 하위 도킹 플랫폼이 있습니다. 데이터가 취합된 후에는 데이터 출력, 자산 관리, 구성 관리 등 일련의 서비스, 플랫폼 구축을 위해 상위 계층(서비스 관리 계층과 유사한 플랫폼)으로 전달됩니다.

3. 새로운 시대의 CMBD 포지셔닝 - 애플리케이션 중심

,

애플리케이션 중심, 조직-프로젝트-인사 관계를 구현하고 이를 애플리케이션과 결합할 수 있습니다.

애플리케이션 실행 과정에서 해당 리소스(서버 리소스, 구성 센터, 관찰 가능성 지표 등)가 사용된 후 회사의 조직 구조에 따라 소속이 형성됩니다. 마지막으로 조직 구조 관점은 마이크로서비스를 참조합니다. 자원과 해당 자원을 형성하는 관점 관계 - 애플리케이션 토폴로지 및 물리적 토폴로지를 포함한 토폴로지.

4. 애플리케이션 중심 CMDB의 장점

picture

5. 런타임 시 애플리케이션과 메타데이터 센터의 관계

picture

위 그림은 CMDB를 보여줍니다. 기본 테스트 시설의 메타데이터, PaaS 관련 데이터 및 운영 데이터는 상위 계층(CI 플랫폼, CD 플랫폼, 서비스 운영 플랫폼, 서비스 운영 플랫폼)에 제공됩니다. 그림에 표시된 하위 플랫폼은 서비스 자원 지원 플랫폼을 구성합니다.

이러한 구성의 장점은 애플리케이션 생성, 애플리케이션 런타임(빌드, 릴리스, 확장, 청구), 애플리케이션 오프라인 후 리소스 재활용을 포함하여 애플리케이션의 전체 수명주기에 대한 기본 데이터 지원을 제공한다는 것입니다.

6. CMDB 구축의 4대 단계

사진

위 그림은 CMDB 구축의 4대 단계를 현재 서비스 지향에서 가치 지향으로 진행하고 있습니다.

부서 지향:

• CMDB 시스템 유무에 관계없이 실제로는 CMDB 요구 사항이 있으며 구성 정보는 부서별로 하나의 단위로 유지 관리됩니다.
• 정보가 격리되어 시기적절하지 않으며 무결성과 정확성을 보장할 수 없습니다.

데이터 기반:

• 모든 부서가 우려하는 데이터와 상호관계를 CMDB 관리에 통합하여 구성 관리 프로세스 시스템을 구축합니다.
• 불분명한 소비 시나리오로 인해 소비 가치와 생산 비용의 불균형이 발생합니다.
• 스테이션 B의 데이터 생산 비용은 그리 높지 않지만 구축해야 할 데이터 소비 제품이 많거나 비즈니스 측면에서 장면 요구 사항을 맞춤 설정하는 경우가 많으므로 비즈니스 측면 요구 사항을 완료하려면 CMDB를 맞춤 설정하고 개발에 참여해야 합니다. . 이로 인해 CMDB에는 300개가 넘는 OKACI가 있어 유지 관리가 불편해졌습니다.

현장 중심:

• 로컬 데이터 표준화 수준 및 높은 정확도
• 일회용 시나리오로 인해 전체 소비 가치가 높지 않고 생산 비용이 상대적으로 높습니다.

서비스 방향:

• 자동화, 모니터링, 작업 흐름 관리, 운영 및 유지 관리 분석 등 일상적인 운영 관리 및 제어를 지원하는 데이터 공급 서비스
• 다양한 데이터 생산/소비 방법을 도입하여 점차적으로 소비 가치의 균형을 유지합니다. 그리고 생산 비용.

가치 지향:

• CMDB는 서비스 용량 관리, 가용성 관리 등 서비스 및 비즈니스 개발을 전폭적으로 지원하여 IT 운영 및 유지 관리의 초석이 됩니다.
• 조직의 IT 관리 수준 향상을 적극적으로 촉진합니다.

7. CMDB 모델 구축 방법

Pictures

• 데이터 유형 정의: 호스트, 스위치, 애플리케이션 및 애플리케이션 구성 파일을 포함하여 구성 담당자가 요청을 받은 후 이를 조사합니다.
• 데이터 핵심 속성 정의: 호스트를 예로 들어 IP, 일련번호, 전산실, 클라우드 공급업체 등 리소스의 핵심 속성을 보고하거나 수집해야 합니다.
• 데이터 모델에서 직접적인 관계 구축: 포함 관계, 종속 관계, 실행 관계 등 리소스 간의 대응 관계를 정렬하여 리소스 토폴로지의 후속 생성을 용이하게 합니다. 예를 들어, 응용 프로그램이 하나의 데이터 유형을 사용하고 호스트가 다른 데이터 유형을 사용하는 경우 응용 프로그램은 실행 시 호스트에 의존하고 호스트는 차례로 응용 프로그램을 구성할 수 있습니다.
• 소비 시나리오 확인: 소비 시나리오를 확인한다는 것은 데이터가 어떤 단계에 사용되는지 확인하는 것을 의미합니다. 클러스터 배포에 사용되는 경우 애플리케이션 차원에서 관련 배포를 수행하거나 해당 운영 및 유지 관리 작업을 수행해야 할 수 있습니다.
• 데이터 사양 설정: 수명 주기(생성, 생산부터 배포까지)는 무엇입니까? 플랫폼은 데이터 상태의 변화를 어떻게 감지합니까?

요컨대, 데이터의 전체 라이프사이클을 출발점으로 삼아 속성을 결정하고, 관계를 명확히 하고, 소비 시나리오를 명확히 하고, 자동화된 프로세스를 사용하여 데이터의 실시간 및 정확성을 보장해야 합니다.

1) 모델 관계 정의

pictures

2) CI 관계 DEMO 예제

pictures

3) CMDB 구현 프레임워크

• 현재 상태 평가: 현재 CMDB 플랫폼이 있나요? 이 플랫폼은 얼마나 확립되어 있나요? 이 데이터의 품질은 어떻습니까? 조직 구조와 기술 구조는 무엇입니까? 향후 출시 과정에서 필요할 리소스의 상태는 어떻습니까?
• 프로젝트 시작: 시작할 때 CI 모델과 액세스 리소스의 관계, 이후 소비 시나리오, 데이터 소스 및 CI 이해관계자를 정의해야 합니다.
• 데이터 인스턴스화: 데이터 인스턴스화 감지를 수행하면 테스트 환경이 구축되고 CI 모델 또는 인스턴스화된 데이터를 가져옵니다.
• 데이터 검증: UG 환경에서 데이터 보고와 실제 출력을 비교하여 데이터 품질이 표준을 충족하는지 확인합니다. 데이터 품질이 표준에 도달한 후에는 프로덕션 환경의 데이터 상태를 감지할 수 있는 프로덕션 환경을 구축해야 합니다.
• 데이터 시나리오 소비: 데이터가 프로덕션 환경에 들어간 후, 운영 플랫폼 또는 SRE 플랫폼과 연결하여 데이터 소비 시나리오를 확인해야 합니다.

4) 표준화 우선

표준화 우선은 구현 전의 모든 사항이 표준화를 중심으로 구축된다는 의미입니다. 여기에는 계획 요구 사항, 프로세스 요구 사항, 조직 요구 사항 및 플랫폼 요구 사항과 같은 몇 가지 강력한 요구 사항이 포함됩니다.

사양 요구 사항:

• CMDB 플랫폼의 역할과 다른 비즈니스 시스템 간의 관계를 명확하게 정의합니다.
• 자원 관리 프로세스, 책임자 및 책임 플랫폼을 명확하게 정의합니다.
• 자원 및 편차의 기본 표준을 명확하게 정의합니다. 관리 방법 ;
• 서비스 비즈니스 시나리오 관점에서 구성 관리 기능을 계획하고 구축합니다.

프로세스 요구 사항:

• 리소스 상태를 실제로 반영할 수 있습니다.
• 모든 리소스 정보와 리소스 간의 관계를 완전히 포함합니다.
• 유일하고 신뢰할 수 있는 데이터 소스입니다.
• 데이터는 사용자와 시스템에서 편리하고 시기적절하게 얻을 수 있습니다.

조직 요구 사항:

• 통일된 구성 관리 역량 구축 기관을 확립합니다.
• 각 비즈니스 팀은 구성 소비 및 개선에 대한 책임을 명확히 합니다.
• 구성 관리 토론, 최적화 및 수요 수집을 위한 메커니즘을 형성합니다.

플랫폼 요구 사항:

• 자동 구성 검색 및 자동 유지 관리를 점진적으로 실현합니다.
• 리소스 상태 및 구성 변경 사항을 실시간으로 추적합니다.
• 모델은 유연하며 비즈니스 요구에 따라 실시간으로 확장 및 조정할 수 있습니다.
• 구성 시각화는 리소스 문제의 분석 및 신속한 위치 파악을 지원할 수 있습니다.

5) 폐쇄 루프 데이터 수명 주기 만들기

먼저 애플리케이션 속성을 결정합니다. 애플리케이션의 속성에는 애플리케이션의 중국어 및 영어 이름, 애플리케이션 수준, 고유 ID, 속성 비즈니스 및 비즈니스 도메인 등이 포함될 수 있습니다. 속성 내용은 주로 개인 정의에 따라 다릅니다. 애플리케이션이 정의된 후 애플리케이션은 다른 CI와 관계를 가질 수 있으므로 추가로 정렬해야 합니다.

둘째, 신청서의 부동산 소유자를 명확히 합니다. 애플리케이션에는 해당 책임자, R&D, SRE 등이 있습니다. 우리는 애플리케이션 구성 및 변경 검토를 보장하기 위해 애플리케이션 구성, 릴리스, 변경 및 사용자 주변의 기타 작업에 대한 해당 프로세스를 갖추고 있습니다.

마지막으로 예정된 수집 작업을 수행하여 애플리케이션의 최종 데이터 정확성을 보장합니다.

6) 구성 자동 검색 및 업데이트 촉진

위 그림에서 언급된 "리소스"는 여전히 서버 리소스와 같은 전통적인 의미의 리소스입니다. 이러한 자원은 일정한 방법을 통해 수집되어 최종적으로 자원관리 플랫폼에 보고됩니다.

• 수동 유지 관리 시나리오를 제거하는 완전한 구성 수집 기능을 구축합니다.
• 리소스 및 애플리케이션의 구성 정보를 자동으로 검색합니다.
• 프로세스, 관리 플랫폼 및 장비를 연결하여 실시간으로 구성 상태를 얻고 업데이트합니다. CMDB를 통해 사양을 사용하고 규정 준수 검사를 수행합니다.
• 구성 및 소비의 폐쇄 루프 실현을 촉진하고 소비 피드백을 통해 데이터 신뢰성을 자동으로 유지합니다.

위 내용은 데이터 자산 시스템을 구축할 수 없는 SRE는 좋은 유지 관리 담당자가 아닙니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!