Zuoyebang Nie An: 운영 및 유지 관리 혁신 방법, Zuoyebang의 OPaS 아이디어 듣기
- PHPz앞으로
- 2023-06-08 21:12:271033검색
창간호에 양징징 사장님이 재미있는 의견을 많이 냈는데, 몇몇 분들은 그만 두라고 설득하기 위한 운영 및 유지보수 안내였다고 글을 남겨주셨는데요. 열린 마음을 갖고 수백 가지 학파의 의견을 듣고 자신의 경력과 인생 계획을 세우십시오. 둘 다 들으면 깨달아지지만, 자기 귀에 맞는 것만 들으면 어두워진다는 말이 있다. 생각과 충돌이 아쉽네요.
이것은 현실적이고 수준 높은 "운영 및 유지 보수 포럼"의 두 번째 호입니다. 시작하겠습니다!
게스트 소개
이번 호에는 Zuoyebang의 운영 및 유지 관리 책임자인 Nie An을 초대합니다. Nie An은 Alibaba, Xiaomi, Didi 및 Zuoyebang에서 근무한 베테랑입니다. 10년의 운영 경험. 유지보수/R&D/관리 경험.
핵심 사항에 대한 간략한 설명
- 전통적인 운영 및 유지 관리는 산업 제품을 서비스로 조립하여 사용자에게 전달하고 서비스 운영을 유지하는 일을 담당하며 비즈니스에 대한 의존도가 높은 것이 특징입니다
- 현장의 위기, 클라우드 네이티브 시대의 퍼블릭 클라우드의 광범위한 사용, 마이크로서비스 아키텍처 및 DevOps가 실제로 달성되었으며 도구 시스템이 계속 번영하고 전통적인 운영 및 유지 관리 책임이 지속적으로 아웃소싱, 이전 및 교체되고 있으며 도메인 위기가 발생했습니다
- 조직 구조, 협업 방식이 점차 모두의 협업에서 플랫폼 셀프 서비스로 업그레이드되었습니다. 유지 관리의 주요 주제는 수평적 협업에서 서비스 제품 및 기술 중간 플랫폼으로 변경되었습니다.
- 운영 및 유지 관리는 기술적으로 셀프 서비스를 통해 전환됩니다. 플랫폼, 외부 운영 및 유지 관리 서비스 기능 OPaS(OP as Service)가 제공되며, 이는 객체와 장면의 두 가지 레이어로 구분됩니다. 객체가 동형으로 유지되면 지속 가능한 운영 및 유지 관리 아키텍처가 형성됩니다
- 유지보수 중심 전환의 핵심은 역할 인식입니다. 운영 및 유지보수 인력은 비즈니스에 의존하는 운영 역할에서 하이퍼서비스 관점의 독립적인 운영 및 유지보수 서비스 제공자로 조정되어야 합니다. 큰 잠재력
- 구성요소 운영 및 유지보수, 구성요소 자체를 제어하는 것은 순수한 운영 및 유지관리 관리에서 한 단계 더 나아가 양파 모델, 즉 자원 전달, 구축 및 관리 플랫폼을 기반으로 전문 분야에 깊이 들어갑니다. 부품 자체의 분야
- 운영 및 유지보수 개발, 반복적인 플랫폼 반복 작업에서 벗어나 공공 운영 및 유지보수 센터에 집중, 전문적인 기술과 높은 레버리지를 수행
운영 및 유지보수 단계
인터넷 운영 및 유지보수, IT 아래 그림과 같이 순수 수작업, 표준화, 플랫폼화, 디지털 지능화 등 여러 단계를 거쳤습니다. 그 중 DevOps는 기술 중심의 조직 변화이자 비전문적인 변화입니다.
운영 및 유지 관리의 개발 역사에서 다음과 같은 몇 가지 특징을 볼 수 있습니다.
- 상속. 새로운 단계는 이전 단계의 우수한 경험을 계승하고 발전시키며 개념, 기술, 조직을 혁신하는 경우가 많습니다
- 예를 들어 플랫폼화는 표준화 단계의 결과를 계승하고 강화하며, 디지털 지능은 표준화 단계의 결과를 계승합니다. 플랫폼화와 빅데이터 기술 도입을 동시에
- 책임 이전. DevOps는 DevOps 이후의 운영 및 유지 관리 모델의 분수령입니다. object
- 반면에는 운영과 유지보수, R&D의 통합을 강조하며 운영과 유지보수의 책임은 점차 비즈니스 연구개발로 이관됩니다
- 특정 분야의 개발 역사를 배우면 역사에서 배우고 추세를 활용할 수 있도록 해주세요.
전통적인 운영 및 유지 관리
전통적인 운영 및 유지 관리 모델에서 서비스 개체는 기본적으로 세 가지 계층으로 나눌 수 있습니다. 가장 낮은 계층은 주로 컴퓨팅, 네트워크, 스토리지로 구성된 하드웨어 인프라 IaaS이고, 중간 계층은 운영 체제, 가상화 기술, 코드 프레임워크, 미들웨어 등을 포함한 소프트웨어 인프라입니다. 계층, 주로 애플리케이션 서비스.
. 비용, 안전, 효율성 및 기타 다차원 목표(운영). 어느 정도 전통적인 운영 및 유지 관리는 가치를 창출하기 위해 비즈니스에 의존해야 합니다. 많은 기업은 비즈니스를 이해하는지 여부를 운영 및 유지 관리 작업자에 대한 주요 평가 중 하나로 간주합니다(의존성). 클라우드 컴퓨팅과 클라우드 네이티브 기술의 대중화로 인해 기존의 운영 및 유지 관리 모델은 많은 어려움에 직면했습니다. 예를 들어 위에서 언급한 것처럼 인프라를 퍼블릭 클라우드와 클라우드 네이티브로 아웃소싱한 후, 운영 및 유지 관리 책임은 비즈니스 연구 개발에 이관되고, 플랫폼은 노동. 이러한 추세와 사실에 직면하여 운영 및 유지 관리 실무자는 몇 가지 변화를 취해야 합니다. 먼저 조직 구조에 대해 이야기해 보겠습니다. 장기적으로 클라우드 네이티브 시대의 기업의 조직 형태는 다음과 같은 부분으로 구성될 것입니다.
조직 구조
최상위 최종 사용자는 회사의 Party A 고객과 잠재적 수익 창출 그룹입니다. 비즈니스 팀은 최종 사용자를 담당하며 역할에는 제품, 비즈니스, 마케팅, 마케팅 등이 포함됩니다. 비즈니스 연구 및 개발은 주로 SaaS 애플리케이션/서비스를 제공하는 비즈니스 팀에 직접 서비스를 제공합니다. 플랫폼 연구 및 개발은 비즈니스 연구 및 개발을 지원하고 다양한 PaaS 기능을 제공하며 클라우드 공급업체를 캡슐화합니다. 또한 비용 운영 FinOps, 효율성 운영 EP, 관리 팀 IT 등과 같은 교차 기능 조직도 있을 것입니다.
새로운 조직 구조에서 모든 사람의 궁극적인 목표는 자신의 일을 하고 최종 사용자에게 좋은 서비스를 제공하는 것입니다. 비즈니스 팀은 비즈니스 가치에 더 많은 관심을 기울이고 R&D 시스템은 서비스 품질에 중점을 둡니다. 정보기술의 발전에 따라 현재 다기능 조직에서 수행하고 있는 기능은 점차 플랫폼 R&D팀으로 세분화될 것이며, 조직의 주요 협업 방식은 모두의 협업에서 플랫폼 셀프서비스로 업그레이드될 것입니다. 운영 및 유지 관리에는 다음과 같은 새로운 업무 목표가 있습니다. 운영 및 유지 관리의 주요 주제는 수평적 협업이 아닌 관리 플랫폼, 자원 및 기술 센터입니다. 운영 및 유지 관리는 첨단 기술을 활용하고 비즈니스 역량을 강화하며 기업의 운영 개선을 지원해야 합니다. 효율성.
운영 및 유지 관리 혁신, 목표는 셀프 서비스 플랫폼을 통해 상위 팀에 운영 및 유지 관리 서비스를 제공하는 것입니다. 본질은 운영 및 유지 관리 OPaS(OP as Service)입니다. . 내용 차이에 따라 운영 및 유지보수 작업은 아래 그림과 같이 객체 관리와 장면 관리라는 두 가지 범주로 나눌 수 있습니다.
시나리오 관리는 운영 및 유지 관리 시나리오를 기반으로 다양한 운영 및 유지 관리 개체의 수명주기 단계를 관리하는 수평 모드입니다. 제공/변경, 모니터링/측정, 멀티 클라우드, 비용 등을 포함한 운영 및 유지 관리 시나리오의 분류는 비즈니스 연구 및 개발의 작업 습관과 매우 유사하며 몇 가지 빈도가 높은 시나리오를 다루며 유사합니다. 다른 회사에서. 각 유형의 운영 및 유지 관리 시나리오에는 작업 주문 센터, 데이터 센터, FinOps 플랫폼 등과 같은 독립적인 시나리오 관리 플랫폼이 있습니다. 시나리오 관리는 객체 관리를 기반으로 하며, 모델 통합, 데이터 집계, 관리 및 제어 API 등을 통합하여 운영 및 유지 관리 객체를 관리합니다. 현장 관리의 목표는 셀프 서비스 비즈니스 관리 기능을 제공하고 내부 개발자 플랫폼 IDP를 구축하는 것입니다.
운영 및 유지보수 객체를 생성하는 일반적인 방법으로는 자체 조사, 오픈소스 구축, 외부 조달(퍼블릭 클라우드) 등이 있습니다. 각 운영 및 유지 관리 개체는 전례 없는 규모와 복잡성으로 다양한 범주, 클러스터, 인스턴스 등으로 세분화될 수 있습니다. 운영 및 유지 관리 대상의 관리 특성을 동형화해야만 대규모로 저렴한 비용으로 운영 및 유지 관리 서비스를 구축 및 유지할 수 있으며 이를 통해 대규모 운영 및 유지 관리(기술적 레버리지 효과)를 실현할 수 있습니다. 운영 및 유지 관리 개체의 전체 운영 및 유지 관리 전제의 기초입니다.
동형 유지보수
동형 유지보수는 모든 특성이 아닌 운영 및 유지보수 대상의 관리 특성을 목표로 합니다. 동형성을 유지하는 방법은 증분 조절, 재고 수리, 핵분열 방지이다. 아래 그림에서 볼 수 있듯이 플랫폼은 수요를 전달하고 증분을 제어하고, 재고를 수리하기 위한 측정을 통해 거버넌스를 추진하며, 표준화된 서비스 프레임워크와 측정이 사양과 사양을 엄격하게 준수하여 기술 시스템의 대규모 분열을 방지하는 데 사용됩니다. 또한 개선을 위해 질문에 대한 측정 또는 플랫폼 입력이 필요하며 이 세 가지가 서로를 보완합니다. 사양은 서비스 사양(서비스 거버넌스에 해당), 관리 사양(운영 및 유지 관리 제어에 해당) 및 기타 유형으로 구분됩니다.
동형 유지 관리는 명확한 주요 책임을 지닌 조직적 업무 분업에 의존합니다. 예를 들어, 운영 및 유지 관리는 관리에 중점을 두고, 현 상태 거버넌스, 경보 대응, CD 등 비즈니스 도구를 제거하여 비즈니스 R&D에 반환합니다. 비즈니스 R&D는 서비스의 비비즈니스 로직을 제거하고 비즈니스 구현에 중점을 둡니다. 서비스 검색 및 트래픽 제어와 같은 구현은 서비스 프레임워크와 같은 중간 기능에 중점을 두고 관리 기능을 제거하고 이를 수요 전달과 같은 운영 및 유지 관리에 넘겨줍니다. 변경 제어 등 문화의 영향은 무시할 수 없습니다. 운영 및 아키텍처는 개인화된 요구 사항에 대한 SLA 약속을 제공하지 않고 표준 애플리케이션에 대해 즉시 사용 가능한 관찰 기능을 제공하는 등 커뮤니케이션 및 지침을 통해 개념을 출력하고 사용자 습관을 배양합니다.
운영 및 유지 관리 대상의 동형 유지 관리를 기반으로 운영 및 유지 관리에 대한 상향 지원 서비스 중심 기술 시스템은 아래와 같이 지속 가능한 운영 및 유지 관리 아키텍처를 형성했습니다. 현재 기술 수준에서 셀프 서비스 플랫폼을 기반으로 한 운영 및 유지 관리 서비스는 요구 사항의 70%를 해결할 수 있으며, 나머지 30%는 여전히 수요 전달, 문제 해결, 결과 승인, 정책 준수 등 수작업이 필요합니다. 기술과 개념이 발전함에 따라 운영 및 유지보수 서비스의 비중은 더욱 높아질 것으로 예상됩니다.
참고: 이 문서의 서비스 프레임워크에는 N년 전의 코드 프레임워크 및 코드 라이브러리뿐만 아니라 현재 널리 사용되는 마이크로서비스 거버넌스, 전환 단계 및 명명도 포함됩니다.
Transformation Practice
서비스 OPaS로서의 운영 및 유지 관리
애플리케이션 운영 및 유지 관리라고도 하는 비즈니스 운영 및 유지 관리는 클라우드 네이티브에 가장 가깝고 가장 큰 영향을 받습니다. 사양 수립, 프로세스 구축, 글로벌 관리 등 기존의 팀 간 책임 외에도 비즈니스 운영 및 유지 관리는 서비스 중심 방향으로 전환되어야 합니다.
- 먼저, 역할. 인식이 바뀌어야 합니다. 비즈니스에 의존하여 가치를 창출하는 운영 역할에서 독립적인 가치를 지닌 운영 및 유지 관리 서비스 제공업체로 조정하세요. 역할 변화가 핵심입니다
- 조직적으로 주요 책임을 재분배합니다. 비즈니스 R&D는 애플리케이션을 담당하는 주체이며, 운영 및 유지 관리는 애플리케이션을 담당하는 주체도 아니고 플러그인 보모도 아니며 애플리케이션에 대한 관리 기능 제공자가 운영 및 유지 관리를 사용합니다. 운영 작업을 스스로 완료하는 서비스
- 메커니즘 측면에서 평가는 시스템을 재구성합니다. 비즈니스 운영 및 유지 관리 직위의 성과는 더 이상 비즈니스 팀과 비즈니스 연구 및 개발에 강하게 구속되지 않고 서비스 중심의 운영 및 유지 관리에 더 중점을 두고 주관적 평가를 덜 강조하고 기술 평가를 더 강조합니다. 둘째, 운영 및 유지 관리 혁신은 네 단계로 이루어집니다. 목적을 명확하게 한다 --> 추상적인 공통성 --> 플랫폼 구축 --> 대규모 운영 및 유지보수
- 추상적인 공통점이 어려움이자 핵심입니다. 수많은 애플리케이션, 복잡한 기술 스택, 개인화된 기능이 많이 있습니다. 개인화된 사례에 빠지지 않으려면 애플리케이션의 공통 관리 특성을 추상화해야 합니다. 엄밀히 말하면 애플리케이션의 공통적인 특징은 운영 및 유지 관리의 대상입니다
- 구축 플랫폼은 애플리케이션 관리 플랫폼을 말하며, 대규모 운영 및 유지 관리는 지속 가능한 최종 상태입니다
- 셋째, 애플리케이션 개체는 동형을 유지합니다. 서비스 중심의 역량 강화와 더불어 운영 및 유지보수 인력의 주 에너지를 동형 유지보수에 투자해야 합니다
- Operation and Maintenance as Service OPaS(OP as Service)는 비즈니스 운영 및 유지보수 관점에서 제시하는 목표입니다. 전환의 중간 단계에서는 일반적인 방향을 지적했지만 경로가 상대적으로 추상적이었습니다. 나중에 OPaS는 ICSP+IDP 운영 및 유지 관리 아키텍처로 점차 개선되어 전체 운영으로 적용 범위가 확장되었습니다. 그리고 유지보수 팀이 있어야만 명확한 경로와 출발점이 생겼습니다.
-
하이퍼서비스 관점(비즈니스 운영 및 유지관리)
서비스화 외에도 비즈니스 운영 및 유지관리에서도 하이퍼서비스 관점(현재 시나리오로 이름 변경) 구축이 이어질 수 있습니다. 클라우드 네이티브 하의 DevOps 기술 퍼즐은 완성되지 않았습니다. 애플리케이션 + 컴퓨팅 부분만 완성되었으며 다른 방향, 특히 상향 비즈니스 관점, 부서 관점, 회사 관점 등의 역량에 격차가 있습니다. 하이퍼서비스 관점. 하이퍼서비스 관점에서 볼 때, 비즈니스 R&D 인력은 일반적으로 부서장이나 설계자가 주도할 능력이나 동기가 없지만 자신의 부서를 관리할 수 있지만 직무에 제한이 있고 전체로 확장하기가 어렵습니다. 상황. 반면, 하이퍼서비스 관점은 비교할 수 없는 경험, 이해 및 인지적 이점을 갖춘 전통적인 비즈니스 운영 및 유지 관리의 오래된 전쟁터입니다. 비즈니스 운영 및 유지 관리는 클라우드 네이티브 분야의 격차를 메울 수 있을 뿐만 아니라 비즈니스 운영 및 유지 관리의 전문적인 이점을 최대한 활용하고 혁신의 기회를 활용할 수 있는 하이퍼서비스 관점의 구축을 주도합니다. 아래와 같이 win-win 선택이 될 것입니다.
최고 서비스 관점: 다음을 포함하되 이에 국한되지 않음:
- 요구 사항 전달: 작업 주문 센터, 오케스트레이션 엔진, 실행 엔진
- 변경 제어: 5가지 포괄 규칙, 중앙 집중식 관리 및 제어, 오케스트레이션 승인 , 실행 승인, 서비스 측정항목 확인 및 변경
- 관찰 측정항목: 비즈니스 관점에서 관찰 및 측정 데이터를 집계 및 표시하여 애플리케이션 세분화에 대한 드릴다운을 지원합니다.
- 멀티 클라우드 아키텍처: 전체 클라우드에 대한 측정, 거버넌스, 계획 및 훈련 전체 기술 시스템
- 비용 관리: 전사 IT 전반에 걸쳐 FinOps 방향에 맞춰 자원의 과금, 할당, 관리 및 제어, 최적화를 독립적으로 구성
- : 회사 전체 관점에서 운영 및 유지 관리 사양을 수립하고 감독합니다. 소규모 팀의 반복적인 굴뚝
- etc.
을 피하기 위한 프로세스 구현 DevOps 기술 퍼즐을 살펴보면 CDN, 개체와 같은 기본 서비스에 대한 지원에 차이가 있습니다. 스토리지, MQ, EMR은 완벽하지 않으며 서비스 프레임워크(인증, 검색, 통신, 인식, 흐름)가 적용되는 한 운영 및 유지 관리 측면에서 2022년에는 아직 탐색 단계입니다. control)은 Cloud Native로 관리하더라도 방사됩니다.
Onion 모델(클라우드 서비스, 미들웨어, 빅데이터 운영 및 유지 관리)
클라우드 서비스, 미들웨어, 빅데이터 및 기타 운영 및 유지 관리 개체, 기술 스택이 융합되어 전문적으로 집중됩니다. 운영 및 유지 관리 인력의 전환을 구현할 때 양파 모델을 따를 수 있습니다.
- 첫 번째 단계는 자원 전달을 기반으로 원래의 운영 및 유지 관리 개체를 자원 개체로 변환하고 보장된 서비스 기능을 업스트림에 전달하고 작업 가치의 수익을 확립합니다
- 두 번째 단계는 투자 관리 플랫폼을 구축하고 자원 개체의 수명주기를 잘 관리하며 자신을 해방시키기 위해 많은 노력을 기울여야 합니다. 플랫폼은 ToC를 셀프 서비스하고 디커플링을 달성할 수 있어야 합니다. 세 번째 단계는 전문 분야에 깊이 들어가는 것입니다. 구성요소 자체부터 아키텍처, 코드, 성능까지, 운영, 유지보수 등 모든 측면에서 전문성을 향상시킵니다. 이 단계가 이루어지면 운영 및 유지 관리는 단순한 관리자가 아닌 이 분야의 서비스 전문가가 되었습니다. 양파 모델은 데이터베이스, 빅데이터, 미들웨어 및 기타 위치에서 먼저 검증되었으며 나중에 서비스에서 사용되었습니다. 도 성공했습니다. 예를 들어 우리 회사의 클라우드 서비스 운영 및 유지 관리 CloudOps 팀은 양파 모델에 따라 변환을 구현합니다.
- 이 팀은 Tencent, Alibaba, Baidu 등 여러 클라우드 공급업체에 분산된 다양한 클라우드 서비스를 대상으로 합니다.
2년 전, 신속한 비즈니스 발전(리소스 전달)을 지원하기 위해 다양한 수동 방식을 통해 기계, 스토리지 및 기타 자원을 외부에 제공했습니다.
- 이후 기계, 스토리지 및 기타 자원을 관리하기 위한 멀티 클라우드 관리 플랫폼을 구축하기 시작했습니다. 대역폭, 객체 스토리지, CDN과 같은 클라우드 서비스의 수명주기. 이 과정에서 CloudOps 관리 플랫폼은 회사 내부의 보조 클라우드 서비스 공급자인 ICSP(플랫폼 기능)로 성공적으로 전환되었습니다.
- 다음으로 퍼블릭 클라우드 제품에 대한 학습, 인식, 선택 및 진화를 지속적으로 강화할 것입니다. , 이 분야(부품 자체)에 대한 전문성 확립을 위해 노력합니다
- 운영 및 유지 관리 중간 플랫폼(운영 및 유지 관리 개발)
- 사업 운영 및 유지 관리, 부품 운영 및 유지 관리, 시스템 운영 및 유지 관리(자원 네트워크 클라우드 서비스) 등의 역할이 개발 작업에 참여하기 시작했고, 운영 및 유지 관리 개발 DevOps 팀에 남는 공간이 점차 줄어들었고, 전환 과정에서 업무 분담이 불분명해졌습니다. 조직 구조 및 기술 아키텍처의 업그레이드 예측을 참조하여 OpDev의 포지셔닝을 재조정했습니다. OpDev는 개발 아웃소싱이나 운영 및 유지 관리 인력의 종속이 되어서는 안 되며 자체적인 독립적 서비스를 가져야 합니다. 결과적으로 원래의 운영 및 유지 관리 플랫폼은 두 부분으로 분할되었습니다. 한 부분은 기능 반복에 중점을 두어 재사용할 수 없었고, IDP 리소스 콘솔, ICSP 시나리오 관리 도구, 다른 부분은 아래와 같이 통합 계정 IAM, 작업 주문 조정 엔진, 모니터링 지표 수집기 등과 같은 운영 및 유지 관리 중간 플랫폼이 OpDev를 담당하는 것으로 추상화되었습니다.
운영 및 유지 관리 중간 플랫폼은 원래 운영 및 유지 관리 플랫폼의 하위 집합으로, 도메인 지식을 다시 구축할 필요가 없으며 상대적으로 높은 코드 품질 요구 사항을 갖습니다(기본 구성 요소와 동일). 이것이 OpDev 아동화 위치의 장점입니다. 책임이 중앙 집중화되고 축소됨에 따라 OpDev는 동시에 축소되고 더 높은 영향력을 달성해야 합니다.
몇 가지 교훈
- 우리는 변화와 보수 사이에서 타협해야 합니다. 전통적인 운영 및 유지 관리에서 서비스 제공업체로의 전환은 하루아침에 이루어지지 않으며 모든 직원이 항상 뒤처지는 경우도 없습니다(현재 기술 수준은 약 73%). 자원이 집중되면 백엔드 인력은 더 많은 가치 수익을 얻게 됩니다
- R&D 역량 차별화 그라데이션. 운영 및 유지 관리에서 개발로 전환하는 능력은 고르지 않아야 합니다. 비즈니스 요구 사항의 반복에서 시작하고, 품질을 보장하기 위해 설계 및 승인을 엄격하게 제어하고, 엔지니어링 이론을 의식적으로 보완하고, 뛰어난 운영 및 유지 관리 중간 단계를 갖추고 있어야 합니다. 하단 레이어의 청결을 보장하는 기능
- 플랫폼만이 유일한 옵션은 아닙니다. 플랫폼은 서비스 기능을 수행하는 가장 강력한 방법이지만 확실히 유일한 방법은 아닙니다. 조직, 문화, 규범, 프로세스, 플랫폼 모두 필수입니다(단, 이전 비용이 약간 높을 수 있음)
- 운영 및 유지 관리 대상을 명확하게 합니다. 운영 및 유지 관리, 특히 애플리케이션 운영 및 유지 관리에 있어서 관리 대상은 애플리케이션 자체가 아니라 애플리케이션의 공통 특성일수록 애플리케이션 운영 및 유지 관리(레버리지)의 가치가 커집니다. 조직의 보증은 무시할 수 없습니다. 조직 구조는 주요 생산력입니다. CTO는 주요 책임을 명확하게 하고, 독립적인 수용 기관을 설정하고, 측정 및 거버넌스 주기 등 명확한 목표를 갖고, 명확한 업무 분담을 가져야 합니다. 운영 및 유지보수 혁신을 위한 조직 보장
- 순수한 프로젝트 사고를 조심하세요. 운영 및 유지 관리는 단기적으로 가치를 폭발시키고 성취감을 얻기 위해 일부 프로젝트에 참여해야 하지만 사람들이 쉽게 화를 내고 가치를 0으로 만들기 위해서는 의식적인 설계 목표와 서비스 축적이 필요합니다. 프로젝트 과정에서의 역량
- 긴급상황보다 예방이 더 효과적입니다. 건축분야에서는 안정성 문제를 해결해야 하며, 비상대응보다 예방이 더 효과적입니다. MTBF 연장을 우선으로 하고, 이어서 MTTR을 단축합니다
수요 전달의 진화
퍼블릭 클라우드이든 내부 K8S 플랫폼이든 수요 전달 작업은 많습니다. 이러한 유형의 ToM(ToManager) 전달 플랫폼은 필요한 제약이 부족한 경우가 많으며 경험이 풍부한 사람에게만 공개될 수 있습니다.
작업 분업을 최적화하고 효율성을 향상시키기 위해 "작업 주문 정렬 + 승인"을 통해 운영 및 유지 관리 평면 ToC(ToRD)를 구현할 수 있으며 워크플로/작업 주문 자체가 모범 사례에 강력하게 통합됩니다. 연구 및 개발에 안전하게 공개될 수 있는 운영 및 유지관리 관리입니다. 이는 운영 및 유지관리 역량의 서비스화를 위한 중요한 방향이다. 셀프 서비스 제공의 진화 경로는 다음과 같습니다.
현재 요구 사항에서 기술 솔루션까지의 커뮤니케이션 링크는 셀프 서비스 또는 자동화가 상대적으로 어렵고 앞으로 더 많은 시도가 필요합니다.
규모 운영 및 유지 관리의 한계점
규모 운영 및 유지 관리의 경제적 본질은 한계 비용입니다. 이는 "운영 및 유지 관리의 한계 비용 감소 vs. 동형 유지 관리의 한계 비용 증가"의 상호 작용입니다. 아래 그림에서 볼 수 있듯이 운영 및 유지 관리 개체 수가 적을 때 운영 및 유지 관리 비용이 대부분을 차지합니다. 예를 들어 운영 및 유지 관리 개체 수가 증가할 때 플랫폼 구축 및 수동 작업, 동형 유지 관리 등이 있습니다. 주요 비용을 구성하며 한계 전환점은 기술, 개념 및 기타 환경 요인에 의해 영향을 받습니다.
클라우드 네이티브 기술은 동형 유지의 어려움을 줄이고(동형 유지 관리 곡선이 오른쪽으로 이동하도록 촉진), 운영 및 유지 관리 서비스 기능을 향상하고(운영 및 유지 관리 곡선이 아래쪽으로 이동하도록 촉진), 운영 및 유지보수 인력을 확보하여 비용을 절감하고 더 많은 운영 및 유지보수 대상을 관리할 수 있어 생산 효율성이 크게 향상됩니다.
위 내용은 Zuoyebang Nie An: 운영 및 유지 관리 혁신 방법, Zuoyebang의 OPaS 아이디어 듣기의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!