비즈니스가 기하급수적으로 성장하고 있는데, 사용성 구축이 이렇게 안정적일 수 있을까요?

1. 문제점과 과제

2017년 이후 vivo의 기계 규모와 서비스 수가 크게 늘어났으며 이는 차트에서도 확인할 수 있습니다. 기계 크기는 5배 정도 늘었고, 서비스 수는 기본적으로 10배 이상 늘어났다. 기간은 2017년부터 2022년까지다.

규모가 커짐에 따라 과제와 복잡성도 확실히 증가할 것입니다. 생체 내 일반적인 과제는 주로 변경 과제와 실패 과제로 나뉩니다.

1. 여전히 수동 변경 시나리오가 있습니다.

단일 릴리스 시간이 비교적 깁니다.

대규모 비즈니스 마이그레이션 시나리오가 많습니다. Google SRE에는 오류의 70%가 변경으로 인해 발생한다는 개념이 있습니다. 이러한 상황은 생체 내에서도 존재하며, 이러한 변화는 온라인 안정성에 큰 영향을 미칠 것입니다.

2. 고장 문제

장비실 수준의 고장 위험(대기업 및 중소기업에서는 광케이블 파손 또는 내부 장비실 고장 등이 발생함)

급속한 비즈니스 성장이 크게 증가했습니다. 용량 요구 사항.

이 챌린지에서 우리는 비즈니스의 안정성을 보장하기 위해 가용성 기능과 가용성 단계의 두 가지 차원으로 구축을 나누었습니다.
• 2. 가용성 역량 구축

1. 결함 기반 전체 수명주기 개발

가용성 역량 구축은 전체 수명주기 결함 관리를 기반으로 하며 장애를 포괄합니다. 발생, 탐지, 대응, 복구, 검토 및 예방 조치. 결함 발생부터 복구까지의 시간을 MTTR이라고 하며, 안정에서 불안정까지의 시간을 MTTF라고 하며 총 3개입니다. 지표.

결함 관리는 다음 4가지 사항에 지나지 않습니다.

결함 발생을 방지하는 방법은 무엇입니까?

가능한 한 빨리 결함을 감지하는 방법은 무엇입니까?

결점을 빨리 치료하는 방법은 무엇입니까?

결함이 복구된 후 후속 조치는 어떻게 되나요?

• 주로 비즈니스 가용성을 고려하여 실패 빈도와 비즈니스에 미치는 영향 시간에 주의해야 합니다. 따라서 오류 빈도를 줄이고, 오류를 신속하게 찾아내고, 오류 기간을 단축하고, 신속한 오류 해결을 달성하는 것이 전체 고가용성 기능 구축의 일반적인 아이디어입니다. 저희가 시행한 대책을 소개하겠습니다:

2. 오류 발생 분석

우선 오류 예방을 위해서는 먼저 오류가 발생하는 이유를 이해해야 합니다. 서비스 관점과 전체 링크 관점.

1) 서비스 관점

서비스는 요청된 입력에 지나지 않으며 일반적으로 해당 출력만 필요합니다. 실제 상황에서는 서비스의 올바른 응답에 영향을 미치는 많은 측면이 있습니다. 일부 고전적인 시나리오에서는 영향을 미치는 요소가 요약되었습니다

용량 측면에서: 비즈니스 요청이 기하급수적으로 증가하여 단일 서비스의 출력이 비정상적으로 발생합니다.

서비스 측면에서: 소프트웨어 자체가 버그가 돌고 그 결과 서비스가 망가집니다.

하드웨어: 호스트 하드웨어, 전산실, 네트워크로 인한 이상.

• 2) 전체 링크 관점

용량 계층: 갑작스러운 요청 증가, 전체 링크의 용량 부족으로 인한 서비스 이상 현상 발생

서비스 계층: 서비스 서비스와 공동으로 구성해야 합니다. 잘못된 구성 설정으로 인해 전체 링크에 이상이 발생할 수도 있습니다.

업스트림 및 다운스트림 종속성: 일부 주요 서비스에 이상이 있으면 전체 링크에 이상이 발생합니다.

• 전체 링크의 안정성 관점에서 볼 때, 업스트림 및 다운스트림 종속성, 용량 부족, 비정상적인 서비스 구성은 모두 안정성에 영향을 미치는 중요한 요소입니다.

3. 장애 예방 구축

서비스와 풀링크의 두 가지 관점에서 장애 요인을 분석한 후 장애 예방 구축에 대응하는 아이디어가 있습니다.

• 전체 링크 이상: 업스트림과 다운스트림의 강점과 약점을 분석하고, 전체 링크의 안정성을 보장하기 위해 주요 서버에 대한 특별한 보호를 제공해야 합니다.
• 변경 예외: 변경 사항을 생성합니다. 프로세스 사양 및 변경 관리 플랫폼;
• 인프라 예외: 고가용성 아키텍처를 사용하여 단일 위험 지점을 제거하고 중복 재해 복구를 구현합니다.

4. 고장방지

앞서 전반적인 분석과 구성 아이디어에 대해 이야기했는데, 실제로는 비보에서는 어떻게 하는 걸까요?

전체 링크를 기반으로 구축 보증을 제공했습니다. 전체 링크는 액세스 계층, 비즈니스 로직 계층, 미들웨어 계층, 스토리지 계층 및 인프라 계층으로 구성됩니다.

1) 단위화: 서비스 호출 감소

2) 다중 입구: 과거에는 많은 기업이 IDC의 다중 입구 기능을 구축한 후 단일 액세스 레이어만 사용했습니다.

3) 과부하 보호: 비즈니스 용량이 갑자기 증가할 경우 액세스 레이어 서비스는 설정에 따라 일부 버스트 요청을 적극적으로 거부할 수 있습니다. 과도한 요청을 방지하기 위해 트래픽으로 인해 다음 서비스가 중단됩니다.

4) 회로 차단기 및 다운그레이드: 종속 서비스의 독점 다운그레이드는 비정상적인 서비스의 영향을 보호하고 눈사태 효과를 피할 수 있습니다.

5. 오류 검색

현재 사전 예방적 오류 감지율은 클라이언트를 포함하여 90%에 도달할 수 있습니다. 모니터링, 서버 모니터링 및 기본 모니터링:

1) 클라이언트 모니터링: 자체 구축된 다이얼 테스트 시스템, 우회 시뮬레이션된 사용자 액세스를 통해 각 서비스의 가용성 모니터링

2) 서버 모니터링: 도메인 이름 모니터링 포함, 서비스 간 로그 모니터링 및 호출 모니터링은 주로 메트릭/로그/추적입니다.

3) 기본 모니터링: 주로 메트릭 방식으로 호스트의 하드웨어 리소스 사용량을 모니터링합니다.

6. 문제 해결

에는 주로 오류 분석 및 오류 처리가 포함됩니다.

• 오류 분석: 모니터링 시스템과 연계하여 기본 서비스 장애 분석, 도메인 이름 가용성 분석 등을 지원합니다.
• 오류 처리: 계획 수립, 훈련, 등.

7. 결함 검토

결함 검토는 전체 고가용성 구축 주기에서 매우 중요한 부분입니다.

업무 기반의 SLA 분류를 통해 업무의 안정성을 확보하고, 업무의 모든 실패를 기록하고, 역량 강화 및 검증:

1) 업무 분류: 운영 및 유지 관리 리소스는 매우 제한되어 있으므로 모든 비즈니스에 동일한 SLA가 적용되도록 보장해야 합니다. 따라서 비즈니스의 평판과 수익을 기준으로 이를 핵심, 중요, 일반의 4가지 비즈니스 수준으로 구분합니다. , 기타 각 사업에 대한 운영 및 유지 관리 인력 및 지원에 대한 투자를 안내합니다.

2) 오류 기록: 검토 효율성을 향상시키는 동시에 후속 분석을 위한 온라인 비즈니스 오류를 추적하여 비즈니스 최적화를 안내합니다.

3) 결함 개선: 카오스 엔지니어링 기반의 후방 검증을 수행하여 개선 조치가 적용되었는지 확인합니다.

이것이 우리의 결함 검토 관행입니다. 또한 이러한 기능과 관행을 플랫폼에 구현하고 플랫폼을 통해 결함 검토 작업을 관리했습니다.

8. 용량 관리

용량 문제로 인해 발생하는 온라인 장애는 어느 정도 보장됩니다. 우리는 주로 리소스 탄력적 확장성과 리소스 전달, 운영 및 관리 기능이라는 두 가지 측면에서 기능을 향상시킵니다.

• 자원 탄력적 확장성: 하이브리드 클라우드 기반 자원 보장 기능을 구축하여 자원 탄력성을 대폭 향상합니다.

• 자원 전달 및 운영 관리 기능: 자원 공급 및 추적을 보장하는 자원의 전체 수명주기 관리 메커니즘을 구축합니다. 예산관리, 수요관리, 조달관리, 재고운영관리 등 활용 효율성을 극대화합니다.

3. 사용성 단계 구축

사용성 역량 구축 후, 사용성 구축을 표준화 단계, 프로세스 단계, 플랫폼 단계의 3단계로 나눕니다.

1. 표준화 단계

왜 표준화를 구축해야 할까요?

표준화는 비즈니스 운영 및 유지 관리의 복잡성을 크게 줄여 운영 및 유지 관리 비용을 절감할 수 있습니다. 우리는 하드웨어와 소프트웨어 수준 모두에서 많은 표준화 작업을 수행했습니다.

• 하드웨어 수준: 컴퓨터실 표준화, 네트워크 표준화(공용 네트워크, 활성 인터넷 액세스, 인트라넷 전용선)
• 소프트웨어 수준: OS 표준화, 호스트 환경 표준화, 서비스 디렉터리 표준화, 에이전트 표준화, nginx 클러스터에 대한 액세스 표준화, 서비스 기능 표준화(미들웨어 서비스).

2. 프로세스 및 표준화된 시공

우선, 운영 및 유지 관리 프로세스의 더 나은 사례와 방법을 프로세스 메커니즘과 사양으로 침전시키겠습니다. 운영 및 유지 관리에 대한 군사 규정, 장애 대응 메커니즘, 공무 규정, 대규모 이벤트 보장 규정 등을 포함하여 비즈니스 안정성이 질서 있고 통제 가능하게 보장됩니다.

예를 들어 대규모 행사에 대한 보증 사양이 확립되지 않은 경우 대규모 운영 활동이나 춘절 빨간 봉투 배포 활동이 있을 때 온라인 장애가 발생하기 쉽습니다. 2018년에는 대규모 행사가 설립되어 설날 등 대형 보험을 통해 원활한 운영을 보장할 수 있습니다.

3. 플랫폼 및 시스템 구축

플랫폼 및 시스템 구축 측면에서 CMDB는 일반적으로 더 나은 프로세스 메커니즘을 플랫폼으로 더욱 발전시키는 기반으로 사용됩니다. 플랫폼, 모니터링 플랫폼, 서비스 툴 플랫폼 등을 변경하여 비즈니스 안정성을 지원합니다.

4. 가용성 결과 및 전망

2022년까지 전반적인 비즈니스 안정성 운영 및 유지 관리가 질서 있고 효율적으로 이루어지며 비즈니스 가용성이 이전 3 9에서 현재 4 9로 증가하고 비즈니스 수는 기준을 충족하는 항목도 이전 8개에서 현재 24개로 늘어납니다.

이 가용성 결과는 주로 가용성 역량 구축 및 가용성 단계 구성을 통해 달성됩니다.

• 가용성 역량 구축: 결함 예방, 결함 발견, 결함 치료, 결함 검토
• 가용성 단계 구축 : 표준화, 프로세스/표준화, 플랫폼/자동화

향후에는 다중 활성 원격 및 컨테이너/클라우드 네이티브의 가용성 보장에 중점을 둘 것입니다.

더 순수한 물리적 머신과 클라우드 네이티브의 가용성 보장을 예로 들면서, 가상 머신을 추가하고 나중에 퍼블릭 클라우드를 추가하여 비용을 더욱 절감했습니다. 동시에 우리는 물리적 하드웨어 리소스에 대한 직접적인 의존성을 줄이기 위해 리소스를 통합하고 유연하게 예약하는 컨테이너 및 클라우드 네이티브 작업도 진행하고 있습니다. 따라서 다양한 인프라에 대한 고가용성 기능을 구축해야 합니다.

사용성 구축으로 또 무엇을 할 수 있나요?

저는 개인적으로 우리가 가용성뿐만 아니라 비즈니스의 품질 및 운영 비용도 고려한다고 믿습니다. 이후 비즈니스의 운영 및 유지 관리 보증은 세련된 운영 보증 단계로 들어갈 것입니다.

Q&A

Q1: 사용성 구축을 구현하면서 겪는 가장 큰 어려움은 무엇입니까?

A1: 첫 번째 요점은 기본 기술 역량의 구성 사양입니다. 이러한 사양을 준수하지 않으면 비즈니스 가용성 결과에 큰 불확실성이 발생하므로 팀을 위해 특정 사양을 공식화해야 하며, 또한 확실한 바닥 유지 메커니즘;

두 번째 요점은 상위 수준의 인식입니다. 각 비즈니스는 서로 다른 단계에서 서로 다른 요구 사항을 갖고 있습니다. 안정성이 제대로 이루어지지 않으면 비즈니스, 평판 및 수익에 영향을 미칩니다. 상위 레벨의 승인을 받은 후에는 사용성 구축도 추진하기가 더 쉽습니다.

Q2: CMDB 구현 과정에서 개발 담당자, 호스트, 기타 정보 외에 실제 과정에서 어떤 정보가 연관됐나요? 예를 들어 미들웨어 정보와 관련된 것인가?

A2: 현재 많은 시스템이 CMDB를 기반으로 하고 있으며, Dubbo와 같은 미들웨어 서비스도 CMDB를 기반으로 구축될 예정입니다. 또한 서비스 검색 및 거버넌스를 위해 CMDB를 기반으로 합니다.

강사 소개

Zhou Jiali는 현재 vivo의 운영 및 유지 관리 책임자로, vivo 인터넷 사업의 운영 및 유지 관리를 담당하고 있습니다. 바이두와 텐센트에서 근무한 이 사람은 클라이언트, 국제화, 빅데이터 알고리즘 등 오프라인 사업 운영 및 유지관리 경험이 있다. vivo 입사 후 비즈니스 고가용성 구축을 주도하여 비즈니스 가용성을 99.99% 수준으로 향상시켰습니다.

위 내용은 비즈니스가 기하급수적으로 성장하고 있는데, 사용성 구축이 이렇게 안정적일 수 있을까요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!