이 주제를 마무리하려면: 운영 및 유지 관리 작업을 더 이상 수행할 수 없다는 것이 사실입니까?

지난 금요일, Ma Chi와 Lai Wei가 온라인으로 대화를 나눴습니다. 주제는 '운영 및 유지보수 업무가 더 이상 불가능합니까?'였습니다. 저는 진행자로서 점화자이자 진행자입니다 :) 두 베테랑 분들이 각자의 의견을 나누는 것을 들으며 많은 유익을 얻었습니다. 잊지 않도록 오늘 꼭 녹화해두세요. 생방송 복습이라 할 수 있어요.

도구 플랫폼 정보

도구 플랫폼은 노동력의 일부를 대체할 것입니다. 이는 실제로 명백하며 소개가 필요하지 않습니다.

그런데 도구 플랫폼은 누가 구축할까요? 확인해 볼 가치가 있습니다. 모니터링 시스템, CI/CD 플랫폼, 카오스 엔지니어링 플랫폼, 미들웨어 서비스 등은 모두 플랫폼이며 PE라고 하는 플랫폼 엔지니어가 구축합니다. PE는 분명히 여러 그룹으로 나뉘며 각 PE 그룹은 제한된 수의 플랫폼을 담당합니다. 이렇게 분산된 PE팀은 인프라팀과 같은 대규모 팀으로 구성될 수도 있고, 여러 팀으로 분할될 수도 있습니다. 예를 들어 엔지니어링 성과와 관련된 PE팀은 성능 엔지니어링 부서 등 하나의 부서에 배치될 수 있습니다. ), 데이터베이스, 빅데이터 등 관련 PE팀을 하나의 부서(예: 데이터 부서)에 배치하고, 안정성 확보 관련 PE팀을 하나의 부서(운영 및 유지관리 부서 등)에 배치합니다.

이 조직의 부서는 회사마다 다를 수 있지만 관계는 그다지 크지 않습니다. PE 팀이 업무를 어떻게 수행해야합니까? PE팀의 핵심은 다음을 수행해야 합니다.

• 비즈니스 R&D팀이 셀프 서비스를 제공할 수 있도록 유용한 플랫폼을 구축합니다.
• 플랫폼은 모범 사례를 축적해야 합니다. 플랫폼은 비즈니스를 만족시켜야 하지만 업계 모범 사례도 있어야 합니다. 이론적으로 비즈니스 요구 사항이 업계 모범 사례와 충돌하는 경우 단기적으로는 업계 모범 사례가 최대한 활용되어야 합니다. 장기적으로 계획을 단계적으로 구현하고 이를 달성하기 위해 노력해야 합니다. 그렇지 않으면 점점 더 개인화된 것, 반패턴적인 것이 있으면 플랫폼 측은 점점 더 불편해질 것입니다. 결국에는 무너지고 다시 시작될 것입니다. 엉망이 될 것입니다
• 우리는 규칙과 규정을 사용하는 대신 플랫폼을 사용하여 사양을 구현해야 합니다. 상태 데이터를 저장하기 위해 로컬 디스크를 사용하지 않도록 비즈니스 프로그램에 요구하는 사양이 있습니다. 이를 레드라인 법칙으로 공표하지는 않았지만 컨테이너가 드리프트할 수 있도록 컨테이너를 정기적으로 다시 시작한다는 점을 비즈니스 측에 분명히 알려줍니다. 실제로 AWS를 사용해본 사람들은 AWS 가상 머신이 때때로 설명할 수 없는 이유로 다시 시작된다는 것을 알고 있을 것입니다. 신뢰할 수 없는 인프라에 대해 고가용성 애플리케이션을 제공하는 것은 플랫폼의 발전을 안내하는 것이 애플리케이션 개발자의 책임이기 때문입니다. 데이터베이스에 능숙한 아키텍트가 Hadoop에 능숙하지 않을 수 있고, Hadoop에 능숙한 아키텍트가 관찰성 시스템에 능숙하지 않을 수 있으며, 관찰성 시스템에 능숙한 아키텍트가 카오스 엔지니어링에 좋지 않을 수 있습니다.
• 하지만 모든 플랫폼이 하루 아침에 만들어지는 것은 아닙니다. 아직 이러한 플랫폼이 없다면 어떻게 해야 할까요? 회사는 COE를 먼저 모집해야 하며, COE가 플랫폼의 역량을 구축하는 동안 비즈니스 컨설턴트 역할을 하도록 해야 합니다. 비즈니스가 빠르게 발전하고 있으며, 플랫폼의 자체 개발이 너무 느리기 때문에 외부 공급업체에서 솔루션을 찾을 수도 있습니다. COE 자체도 상황에 따라 외부 솔루션을 찾을 수 있습니다.

외부 공급업체 정보

누구나 직관적으로 다음과 같은 사실을 느낄 것입니다. 유럽과 미국 기업은 SaaS 서비스를 구매할 의향이 더 많은 반면, 국내 기업은 오픈 소스를 기반으로 자체 서비스를 구축하려는 의향이 더 높습니다. 국내 기업의 철학이 좋지 않아서일까요? 설마. 핵심 문제는 국내 여러 분야에서 신뢰할 수 있는 ToB 업체와 제품이 부족하다는 점이다. ToB 회사가 당사자 A에게 다음을 제공할 수 있다고 상상해 보십시오.

뛰어난 고급 방법론

• 안정적이고 사용하기 쉬운 제품
• 고객이 최상의 솔루션을 더 잘 구현하도록 돕는 우수하고 안정적인 고객 성공 팀 실제로
• 측면에서 가격면에서는 A측이 직접 인력을 모집하고 자체 연구하는 것보다 저렴합니다
• CXO가 나쁘지 않은 한 그는 반드시 그러한 외부 공급자를 도입할 것입니다. 그런데 이런 ToB회사가 있나요? 이것은 큰 물음표입니다. 우리는 고객에게 관측 가능한 제품을 제공하고 그러한 공급자가 되기 위해 노력하기 위해 Kuaimao Nebula를 만들었습니다. 업계의 ToB 동료들이 함께 협력해 나가길 바랍니다!

직업 선택 문제를 확대해 지금은 특정 부문에서 좋은 공급업체가 없을 수도 있지만 3년 후에는 어떨까요? 지금부터 5년은 어떨까요? 외국이 이미 주도권을 잡았나요? 중국에 잠재력이 좋은 공급업체가 있나요? 이미 가지고 계시다면, 형제님, 아직도 감히 이 틈새 분야에 전념하시겠습니까? 우리는 미리 몇 가지 계획을 세웠어야 했나요?

물론, 미래에 대한 예측에 있어서 우리는 대개 너무 낙관적이거나 너무 비관적입니다. 시간 추정에 있어서 우리는 대개 너무 앞선 예측과 너무 뒤떨어진 예측을 합니다. 그렇죠, 형제여, 그것은 당신이 어떻게 판단하느냐에 달려 있습니다.

긴급 오류 처리 정보

OnCall 오류 응답을 R&D에서 처리해야 하나요? 아니면 운영 및 유지 관리? 이 질문은 매우 흥미롭습니다. Ma Chi는 온라인 오류의 80%가 변경과 관련되어 있으며 R&D가 이에 대해 더 잘 알고 있다고 믿습니다. 이는 R&D가 문제의 80%에 더 빠르게 대응할 수 있음을 의미합니다.

비즈니스 연구 및 개발은 이렇습니다. 데이터베이스 변경, 기본 네트워크 변경, 액세스 레이어 변경은 모두 동일합니다. 변경을 수행하는 사람이 자신의 서비스에 대한 장애 경보에 대응하는 것이 더 합리적입니다.

사실 이는 두 가지 전제 조건에 달려 있습니다.

1. 모니터링과 관찰 가능성이 충분히 이루어지고, 변경으로 인한 문제는 이 플랫폼을 통해 적시에 발견될 수 있습니다. 여러분, 모든 회사가 완전한 관찰 가능성을 갖추고 있기를 바랍니다. 관찰 시스템
2. 변경으로 인해 발생한 문제는 즉시 반영됩니다. 일부 변경으로 인해 발생한 문제가 일주일 뒤에만 나타나면 변경한 사람이 스스로를 의심하기 어려울 것입니다

실제로는 그럴 수 있습니다. 두 가지 상황에서 변경 사항을 처리합니다. 후속 서비스 안정성 모니터링은 변경한 사람의 책임입니다. Daily OnCall은 또 다른 시나리오이므로 별도로 처리해야 합니다. 그렇다면 매일 OnCall을 수행해야 하는 사람은 누구입니까? 결함 위치 파악 및 손실 중지에 직접 참여할 수 있는 사람이어야 합니다. OnCall 담당자가 경보를 받고 다른 사람에게 연락해야 하는 경우 결함 중지의 적시성이 너무 낮습니다.

먼저 알람은 사람마다 다른 알람으로 처리되어야 합니다. 연구개발이나 운영, 유지관리에 모든 경보를 두는 것은 불합리합니다.

변경 릴리스에 대해

비즈니스 연구 및 개발이 자유롭게 버전을 릴리스할 수 있도록 하는 것이 궁극적인 목표에 공감대가 있지만, 우리도 통제되고 싶고, 안전하게 릴리스하고 싶고, 비즈니스 연속성을 보장하고 싶습니다. 출시하면서. 이로 인해 CI/CD 시스템에 대한 요구 사항이 매우 높아졌습니다.

상관하지 않는다면 시스템의 맨 아래 계층을 변경하는 것은 단지 여러 컴퓨터에서 일괄적으로 스크립트를 실행하는 문제일 뿐입니다. 하지만 위의 요구 사항을 추가하면 훨씬 더 어려워지고 체계적인 프로젝트가 됩니다.

비즈니스 연구 및 개발 측면에서는 관찰 가능한 지점을 만드는 것이 필요하며, 문제를 적시에 감지하고 알람 이후 출시 프로세스를 자동으로 차단하는 모니터링 시스템도 필요합니다. 블루-그린 릴리스 및 카나리아 릴리스 수단이 필요하며 일부 자동 코드 검색 및 보안 검색 기능이 필요합니다. 변경 사항을 롤백할 수 있도록 R&D를 맹목적으로 요구하는 것은 부적절합니다. 변경사항은 안전합니다. 기본적으로 CI/CD 역량 수준은 기업의 기술력을 가늠할 수 있습니다.

귀사에서 여전히 운영 및 유지 관리를 위한 선하증권을 R&D에 제공하고, 운영 및 유지 관리가 온라인으로 운영되는 경우 그렇게 하는 것이 합리적인지 고려해야 합니다. 물론 위의 접근 방식은 인터넷 접근 방식에 가깝고 모든 회사에 적합하지 않을 수 있습니다. 이 라이브 방송은 아이디어만 제공하므로 직접 고려해야 합니다.

물론, 이 이상적인 상황을 어떻게 달성할 수 있을까요? 이러한 이상적인 상황이 이루어지기 전에 우리는 어떻게 단계별로 진행해야 할까요? 생방송에서는 시간 문제가 논의되지 않았습니다. 회사의 비즈니스가 Kubernetes에서 실행하기에 적합한 경우 Kubernetes를 사용하여 그러한 시스템을 구축하는 것이 상대적으로 쉽고 최대한 빨리 조치를 취할 수 있습니다. 회사의 비즈니스가 물리적 머신이나 가상 머신 환경에서 실행되어야 한다면 먼저 통합 변경 릴리스 플랫폼을 개발한 다음 격차를 메우고 점진적으로 개선해야 합니다.

비용 최적화에 대해

두 손님은 많은 이야기를 나누지는 않았지만 이 문제에 대해 모두가 매우 신중했습니다. 모두에게 상기시키세요:

1. 사람이 하드웨어보다 더 비쌉니다. 인력이 5천만 달러가 들고 하드웨어 비용이 4천만 달러를 절약하는 일을 하지 마십시오.
2. 비즈니스에 충분한 컴퓨팅 성능을 사용하면 긴장됩니다. , 이 배치에 대한 예산은 승인되지 않습니다. 용량이 실패하면 고객 경험이 손상되고 여론이 부정적이 되며 이익이 손실보다 클 것입니다
3. 어리석은 예는 하드웨어 비용은 300만개, 구매량은 3000만개인데 유지가 불가능하네요

요약

이 단계에서는 아직 셀프 서비스 플랫폼+COE를 사용하는 플랫폼 시스템이 그렇게 완성되지 않았습니다. +운영 및 유지 관리 시스템을 구축하기 위한 BP(비즈니스 파트너) 아키텍처는 안정적이고 구현 가능한 것으로 보입니다. 미래에는 플랫폼이 충분히 좋아지면 BP 인력을 줄일 수 있습니다(BP는 점차 COE를 수행할 수 있는 능력을 얻었습니다). 플랫폼이 계속 완성되면 음, 운영 및 COE는 계속해서 줄어들 수 있습니다. 유지 관리 및 R&D가 필요하지 않을 수도 있습니다.

위 내용은 이 주제를 마무리하려면: 운영 및 유지 관리 작업을 더 이상 수행할 수 없다는 것이 사실입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!