CTO 관점에서: 운영 및 유지 관리/SRE 역량을 구축하는 방법

최근 제가 운영하는 SRETalk 공식 계정에도 운영 및 유지보수 직위 유지 여부에 대한 문제를 논의하는 기사가 많이 올라왔습니다. 업계의 많은 분들과도 이야기를 나눴고, CTO/CIO들이 참고할 수 있도록 소소한 생각을 적어보았습니다. 혼란스럽다면 이 글도 꼭 읽어보시길 권합니다. .

깊은 생각이고, 지루할 수도 있지만 진로선택과 팀빌딩에 도움이 될 것 같아요. 이 기사는 근거가 충분한 토론을 환영하지만 오만함을 환영하지는 않습니다. 또한 기사의 내용이 여러분에게 영감을 주고 CXO의 의사 결정에 새로운 사고를 가져올 수 있다면 좋습니다.

이 외에도 SRETalk 운영 및 유지 관리 책임자와의 인터뷰는 계속될 것이며, 참고용으로 더 다양한 의견이 나올 것입니다.

제목에 대하여

먼저 "운영 및 유지 관리/SRE 역량 구축 방법"이라는 제목에 대해 말씀드리겠습니다. 여기서는 팀 구축이 아니라 역량 구축에 관해 글을 쓰고 있습니다. 목표를 달성하려면 반드시 자체 팀 구성이 필요한 것은 아닙니다. 비용과 결과의 관점에서 볼 때 예측 가능성과 유지 관리에 대한 장기적인 투자의 관점에서 보면 결정이 잘못되면 신중한 의사 결정이 필요합니다. 이것은 나중에 논의될 것입니다.

운영 및 유지보수/SRE팀에 대해

한 가지 더 분명히 해야 할 점은 기사에 언급된 운영 및 유지보수/SRE팀은 모두 비즈니스를 담당하는 팀이며, 비즈니스의 성공이 최우선입니다. 일부 운영 및 유지 관리 팀에서는 일부 제품을 만들어 외부 상용화를 위해 수출했는데, 이는 그 자체로 사업이 되었습니다. 게다가 제가 예전 직장에서 경험한 바에 따르면 운영 및 유지 관리/SRE 팀의 접근 방식(외부)도 마찬가지입니다. 상용화 출력)은 바람직하지 않습니다. 특히 ToB 유전자가 없고 해당 ToB 조직 구성이 없는 회사에서는 더욱 그렇습니다.

운영관리/SRE능력은 어디서 구하나요

모든 것은 사업성공을 위한 것이기에(사업과 상관없이 승진이 가능한지, 상사를 속일 수 있는지는 별개의 문제) 운영과 유지관리가 무엇인지에 집중해보자 비즈니스에 필요한 기능(자세한 내용은 나중에 설명), 이러한 운영 및 유지 관리 기능을 어디서 획득해야 합니까? 일반적인 획득 방법에는 세 가지가 있습니다.

자체 구성 팀

첫 번째는 자체 구성 팀을 통해 관련 기능을 제공하는 것입니다. 이 방법은 일반적으로 모든 사람에게 가장 친숙합니다. 제품 + 서비스. 먼저 제품에 대해 이야기해 보겠습니다.

• 제품 요구 사항이 일반적인 요구 사항인 경우 해당 제품은 직접 사용할 수 있는 오픈 소스 프로젝트일 가능성이 높습니다. 오픈소스 프로젝트의 지속성(오픈소스 프로젝트 개발자가 상업 기업으로부터 수입 지원을 받는지, 대부분의 개인 오픈소스 프로젝트는 수입 없이 죽게 되는지), 활동(프로젝트가 수년간 업데이트되지 않았는지) 등을 고려해야 합니다. ?제안된 문제와 PR은 적시 처리되나요? 보통 일주일 내 처리가 활발하다고 볼 수 있습니다. 생태계 번영(기여에 참여하는 사람이 많나요? 많은 기업에서 사용하고 있나요?)
• 오픈 소스 프로젝트에는 2차 개발이 필요합니까? ? 보조 개발 코드를 메인 트렁크에 다시 병합할 수 있다면 이는 일반적으로 보조 개발 코드가 보편적이고 오픈 소스 프로젝트 팀에서 인식되었음을 의미합니다. 메인 트렁크에 다시 병합할 수 없는 경우, 특히 특성이 변경된 후에는 후속 유지 관리가 번거로울 수 있습니다. 일반적으로 오픈 소스 프로젝트의 API를 기반으로 일부 글루 코드를 만들고 이를 내부 시스템과 통합하는 것이 가능합니다. 결국 오픈 소스 코드는 수정되지 않았으며 후속 오픈 소스 프로젝트 업그레이드도 계속 유지될 수 있습니다. 물론, 오픈 소스를 사용하지 않는 완전히 자체 개발된 제품도 있습니다(일부 오픈 소스 lib 라이브러리와 핵심 제품 로직은 자체 개발되었습니다). 관련 제품은 직접 개발해야 합니다. 그러나 자체 연구 후에 장기적인 유지 관리 문제를 고려해야 합니다. 일반적으로 R&D 담당자는 처음부터 시작하는 것을 좋아합니다. 규모가 작고 승진이나 급여 인상도 불가능하므로 바꾸기 쉬울 것입니다. 운영 및 유지 관리 트랙의 경우 오픈 소스 커뮤니티에는 눈부신 제품 배열이 있고 자체 개발이 필요한 제품은 소수에 불과할 수 있으므로 다시 생각해 보십시오.
• 두 번째는 서비스입니다. 여기서 말하는 서비스는 비즈니스 측면으로 수출되는 전문가의 경험을 말합니다. 예를 들어 자체 구축된 팀이 모니터링 제품을 구축하는 경우 이 팀은 모니터링 제품에 문제가 발생하면 이를 신속하게 해결해야 합니다. 실제로 회사 내 미들 및 백엔드 팀은 강한 서비스 감각을 갖고 업계의 모범 사례를 이해해야 합니다. 그렇지 않으면 쉽게 비즈니스에 이끌려 모범 사례와 반대 방향으로 갈 수 있습니다. 업계에서는 다 문제다.

서비스의 핵심은 사람에 대한 의존입니다(물론 모범 사례를 제품으로 확고히 할 수 있다면 좋습니다). 관리자로서 이 팀이 좋은 서비스를 제공하려면 많은 사람의 문제를 고려해야 합니다. 예를 들어, 관련 인재를 채용할 수 있는지, 관련 인재를 유지할 수 있는지(개발 공간, 급여 등), 자체 구축된 팀의 각 방향에서 최소 2명이 서로 보완할 수 있는지, 비용이 여유가 있다.

제3자 공급업체

제3자 공급업체를 통해 운영 및 유지 관리 역량을 확보하는 것도 또 다른 방법입니다. 공급업체의 결과물에는 분명히 제품 + 서비스라는 두 부분이 포함됩니다. 제품은 오픈 소스와 폐쇄 소스의 두 가지 유형으로 구분됩니다.

• 오픈 소스 제품은 일반적으로 더 많은 사용자와 다듬어야 할 시나리오가 있지만 일부 롱테일 요구 사항은 일반적으로 오픈 소스가 아닙니다. 그 이유는 오픈 소스 팀이 이러한 롱테일 요구 사항을 과금 항목으로 취급하거나 오픈 소스 팀은 이러한 롱테일 요구 사항이 충분히 일반적이지 않으며 제품에 넣을 가치가 없다고 생각합니다.
• 비공개 소스 제품은 일반적으로 청중이 적고, 제품을 다듬는 데 도움을 줄 수 있는 오픈 소스 사용자가 많지 않기 때문에 오랫동안 상업 고객이 다듬어야 하거나, 비공개 소스 제품 공급업체의 힘이 매우 강합니다. 품질 관리 시스템은 좋지 않습니다. 제품이 완전히 테스트되면 대기업의 공급 업체를 찾아야 합니다. 또한, 테스터와 최종 사용자는 결국 두 그룹의 사람들입니다. 공급업체가 강력한 역량을 갖고 있는 경우 품질 보증 팀은 이 연마 과정을 더 짧게 만들 것입니다.
• 오픈소스든 클로즈드소스든 공급업체가 제품을 함께 제공하므로 당사자 A로서 제품이 어떻게 일치하는지 직접 테스트하고 빠르게 피드백을 받을 수 있습니다. 개발하는 데는 여러 달이 걸릴 수도 있고 심지어 1~2년이 걸릴 수도 있으며, 개발 후 제품이 실제로 기대에 부응하는지 여부는 여러 요인에 의해 결정되며 결과는 예측할 수 없습니다.

두 번째는 서비스입니다. 공급업체는 일반적으로 자체 구축한 팀보다 이점이 있습니다. 그 이유는 다음과 같습니다.

• 공급업체는 더 많은 고객 시나리오를 접해왔고, ToB 회사에서는 오랜 기간 축적된 업계 노하우가 이 회사의 핵심 경쟁력이기 때문에 공급업체는 앞으로도 우수한 고객으로부터 경험을 배우고 피드할 것입니다. 덜 발전된 고객에게는 선순환과 모든 당사자가 윈윈할 수 있는 상황이 제공됩니다.
• 또한 공급업체가 더 많은 시나리오를 보고 제품에 대한 더 나은 추상화를 만들어 제품을 더 다양하고 제품처럼 만들 수 있기 때문입니다. 자체 제작 팀이 만든 제품은 일반적으로 더 도구 지향적입니다. 대개.
• 공급업체가 운영 및 유지 관리 분야에서 사업을 시작하는 이유는 실제로 인력을 채용할 때 자체 구축된 팀에 비해 일반적으로 더 나은 최고 수준의 지식을 갖추고 있기 때문일 가능성이 높습니다. 가장 강력한 그룹의 사람들이 사업을 시작했거나, 너무 비싸거나, 오기를 꺼린다는 것을 알게 될 것입니다.

또한 비용 문제에 대해 이야기해 보겠습니다. 공급업체의 비용은 인력을 직접 채용하는 것보다 비용 효율적일 가능성이 높습니다(적절한 인력을 채용하는 경우). 그렇지 않으면 비즈니스 논리가 유지되지 않습니다. 이 원칙은 명백하므로 다시는 반복하지 않을 것입니다.

제3자 공급업체로부터 운영 및 유지 관리 역량을 확보하는 것은 자체 구성 팀에게는 압도적인 것 같습니다. 그럼에도 불구하고 다음 기사를 읽어야 합니까? 사실 반드시 그런 것은 아닙니다. 특정 운영 및 유지 관리 능력에 있어서 더 중요한 것은 제품 능력이나 서비스 능력입니다. 가장 필요한 것은 제품 능력이나 서비스 능력입니다. 나중에 사업적인 측면에서 살펴보도록 하겠습니다.

비즈니스에 필요한 기술 지원 역량은 무엇인가요?

운영 및 유지 관리는 본질적으로 일종의 기술 지원 기능으로 인프라 팀과 매우 유사하며 일부는 운영 및 유지 관리 팀에 배치될 수 있습니다. 인프라팀에 넣는 것은 큰 문제가 되지 않습니다. 심지어 회사에서 직접 비즈니스 R&D 팀에 넣는 경우도 있습니다. 필요합니다.

이 사진은 실제로 문제를 매우 잘 설명합니다. 조금 더 자세히 설명하겠습니다.

• 신뢰할 수 있는 기본 환경 및 구성 요소: 비즈니스 프로그램을 실행하려면 기본 네트워크, 하드웨어, 운영 체제, 데이터베이스, 미들웨어 등이 필요합니다. 이러한 환경과 구성 요소는 안정적이고 신뢰할 수 있어야 합니다.
• 빠르고 안전하게 변경하는 능력: 개발자로서 기능을 작성하거나 버그를 수정하면 신속하게 제공하고 싶지만 변경은 쉽게 실패로 이어질 수 있다는 점은 이해하기 쉽습니다. 가능
• 신뢰성 보장 기능: 소프트웨어 배포 생산 환경 이후에는 다양한 문제에 직면할 수 있습니다. 사전에 위험을 수량화하는 방법, 문제를 신속하게 발견하고 찾아내고 손실을 신속하게 방지하는 방법이 가장 중요할 수 있습니다. 비즈니스 측면에서 운영 및 유지 관리 측면까지
• 가장 중요한 모범 사례: 비즈니스는 이러한 기능을 어떻게 사용합니까? 업계 모범 사례인가요? 회사 내 대부분의 다른 운영에 대한 모범 사례입니까? 비즈니스에 피드백하려면 기본 지원팀이 필요합니다

각 능력을 획득하는 방법

위에 언급된 네 가지 능력은 어떻게 획득해야 합니까? 이제 그것을 분해하고 분해하여 이야기합시다.

신뢰할 수 있는 기본 환경 및 구성 요소

우선 기본 하드웨어 환경에 대해 이야기해 보겠습니다. 물론 클라우드와 자체 구축이라는 두 가지 옵션이 있습니다. 정책에 따라 직접 수행해야 하는 경우에는 방법이 없습니다. 정책이 우선합니다. 스스로 선택할 수 있다면 이 시대에는 클라우드로 가는 것이 가장 적합할 것입니다. 회사가 매우 크고 머신이 많지 않은 이상 직접 구축하는 것이 유리할 수 있습니다. 참고로 여기서 말하는 내용은 가능입니다. 비용을 계산할 때 하드웨어 비용뿐만 아니라 인건비도 포함해야 한다는 점을 기억하세요.

직업 선택에 관하여: 시스템 운영 및 유지 관리 엔지니어와 네트워크 운영 및 유지 관리 엔지니어에게는 실제로 그러한 직위의 자리를 차지할 방법이 없습니다. 시대의 수레바퀴가 굴러가는군요 여러분 모두 역사의 먼지입니다.

MySQL, Redis, MongoDB, Kafka, ElasticSearch, Nginx, Kubernetes 등과 같은 구성 요소에 대해 이야기해 보겠습니다. 분명히 세 가지 옵션이 있습니다. 클라우드 PaaS 제품을 사용하거나 직접 수행하거나 자체 하드웨어를 제공하고 공급업체에서 제공 솔루션과 서비스. 각 선택에 대해 각각 검토합니다.

• 클라우드 PaaS 제품: 규모가 작고 관련 인재 보유가 없다면 클라우드 PaaS 제품을 사용하는 것이 더 적절합니다. 빠르게 역량을 구축하고 사용하도록 선택할 수 있습니다. PaaS 제품을 구매하는 클라우드 당사자 A는 일반적으로 이미 클라우드 및 Kubernetes와 유사한 런타임 환경에서 가상 머신을 사용하고 있습니다. 그런데 PaaS 제품을 구매하는 것도 비교적 원활하며 새로운 공급업체와 연결할 필요가 없습니다.
• Do it yourself: 특정 구성 요소가 매우 큰 경우 Kafka와 같이 직접 구축해야 할 수도 있습니다. 2명, 마스터 1명, 백업 1명을 고용하는 것도 나쁘지 않습니다. 문제가 발생하면 모든 것을 확인하십시오. 베이징에 있는 경우 연간 비용은 약 100만 달러입니다. 하드웨어 및 구성 요소에서 이 비용을 어느 정도 절약할 수 있습니까? 물론 일상적인 문제는 해결할 수 있지만 높은 문제는 해결할 수 없는 저비용의 운영 및 유지 관리 엔지니어(강조 추가, 여기에는 운영 및 유지 관리 엔지니어가 필요할 수 있지만 순위가 높지 않음)를 채용할 수도 있습니다. - 수준이 높은 문제의 경우 외부 도움을 요청할 수 있습니다. 공급자에게 전문적인 서비스를 제공합니다.
• 자체 하드웨어 생산 + 공급업체가 솔루션 및 서비스 제공: 클라우드 공급업체의 PaaS 제품과 비교할 때 타사 공급업체는 일반적으로 더 비용 효율적이고 응답 속도가 빠릅니다. 그러나 각 공급업체가 처리할 수 있는 구성 요소가 너무 많습니다. 제품 수가 제한되어 있습니다. 여러 모델의 경우 당사자 A로서 동시에 여러 공급업체를 처리해야 할 수 있으므로 약간 번거롭습니다. 통합 모니터링, 장애 위치 파악, FinOps 관련 제품 등 클라우드 간 협업이 필요한 제품의 경우 기업이 멀티 클라우드나 하이브리드 클라우드 아키텍처를 사용한다면 타사 공급업체가 더 적합할 가능성이 높습니다.

직업 선택에 대해 : 다양한 부품 분야의 선배 전문가의 경우 첫 번째 선택은 클라우드 제조업체에서 일하거나 경험을 수출하기 위해 사업을 시작하는 것이고, 두 번째 선택은 자체 부품을 만드는 대형 공장에 가는 것입니다. . 일반 중소 공장에서는 높은 급여를 받기가 어렵습니다. 결국 제3자 전문 서비스는 매우 비용 효율적입니다.

빠르고 안전하게 변경하는 능력

비즈니스 R&D에서 가장 흔히 발생하는 변경은 바이너리 및 구성 변경이며, 물론 기본 환경 및 구성 요소의 변경도 있습니다.

먼저 바이너리 및 구성 변경에 대해 이야기해 보겠습니다. 어떻게 빠르고 안전하게 반복할 수 있나요? 단계적으로 수행할 수 있습니다. 회사가 아직 비교적 작은 경우에는 도구 구성에 너무 많은 관심을 기울일 필요가 없습니다. 사양과 프로세스만 설정하면 됩니다. 어떤 계정이 배포되는지, 어떤 디렉터리에, 로그를 넣는 방법, 프로세스를 호스팅하는 방법, 모든 변경 사항이 롤링 가능해야 하는 등의 표준 측면. 프로세스 측면에서: 변경 알림 메커니즘, 온라인 다중 모듈 협업 메커니즘 및 비롤백 승인 메커니즘 등이 필요합니다.

그러면 지난 분기에 특정 팀이 변경한 횟수, 롤백 비율은 얼마인지, 실패율은 얼마인지 등 과거 변경 사항에 대한 정량적 데이터가 필요합니다. 잘하지 않으면 다음 분기에는 실패할 것입니다.

회사가 지속적으로 성장하면 변화 플랫폼을 구축하고 플랫폼에 표준화된 시스템을 구현하고 정량적 데이터를 생산하는 데 인력을 투자할 수 있습니다. 전통적인 물리적 머신과 가상 머신의 시대에는 회사마다 상황이 다르기 때문입니다. 거의 볼 수 없는 상업적 변화 시스템을 갖춤. 물론, 쿠버네티스가 등장한 이후에는 근본적인 차이점 중 상당수가 숨겨졌습니다. 쿠버네티스를 기반으로 변경을 수행하는 플랫폼은 훨씬 더 다양해졌고 관련 제품도 나오기 시작했습니다.

프로덕션 환경의 변경은 테스트 환경 및 공동 디버깅 환경의 변경과 동일하지 않습니다. 프로덕션 환경의 안정성 요구 사항은 더 엄격한 반면, 테스트 환경 및 공동 디버깅 환경의 요구 사항은 상대적으로 낮습니다. 소위 CI/CD 시스템은 대부분 테스트 환경과 공동 디버깅 환경을 위해 설계되었습니다. 프로덕션 환경에 CD를 구현할 수 있는 회사는 소수에 불과합니다.

Focus: 테스트 및 공동 디버깅 환경을 위한 CI/CD 시스템은 R&D 효율성을 높이는 데 더 중점을 두고 있습니다. 생산 환경을 위한 변경 시스템은 안정성을 보장하고 표준화된 시스템을 구현하는 데 더 중점을 둡니다. 초기 단계에서는 회사가 작기 때문에 규칙과 규정에 의존하는 것만으로도 충분합니다. 나중에는 함께 작동하려면 규칙과 규정 + 변화 플랫폼이 필요합니다.

이 규제 시스템은 누가 결정하나요? 변화 플랫폼은 누가 개발할 것인가?

사양의 공식화는 실제로 초기 단계입니다. 운영 및 유지 관리 팀이 존재하기 전에 사양이 개발되었을 수 있으므로 CTO 및 하위 Core 팀이 공식화할 가능성이 높습니다. 아직 공식화되지 않았다면 운영 및 유지관리 책임자(운영 및 유지보수 책임자가 있습니다)가 주도적으로 공식화할 수 있으며, CTO 산하 Core팀이 이를 검토하고(모두 참여), 마지막으로 CTO가 하향식으로 결정을 내리고 모두가 실행합니다.

운영 및 유지 관리팀에서 개발하는 변경 플랫폼 개발이 더 적합합니다. 나중에 다른 플랫폼을 도입하고 전담 운영 및 유지 관리 팀을 구성할 예정입니다. (운영 및 유지 관리에는 차이가 없습니다.) 여기서 얘기하는 것이 SRE인데 관리도 가능합니다.) 이 팀은 SRE팀이라고 부르는 것이 적절합니다. 플랫폼을 바꾸려면 회사의 사양을 구현해야 하기 때문에 아웃소싱하는 경우가 상대적으로 적습니다. 회사가 일정 규모에 도달한 후에는 오픈 소스 기반의 자체 연구 및 축적이 가능성이 높은 선택입니다.

직업 선택 정보: 변화 관리는 기업의 중요한 부분이며 안정성 시스템에도 도움이 됩니다. 이는 전형적인 DevOps 입장이며, 상한선은 아마도 P7+ 수준일 것입니다(순전히 개인적인 의견이며 참고용으로만 사용함).

다른 하나는 일반적으로 MySQL 테이블 구조, Nginx 구성, DNS, VIP 등과 같은 기본 구성 요소 및 환경에 대한 변경입니다. 이러한 변경 사항은 구성 요소 관리 및 제어 플랫폼에 내부화될 수 있으므로 구성 요소 기능 공급자가 변경을 제공할 수 있습니다. 진입점과 관리 및 제어 기능.

신뢰성 보장 능력

이 능력은 매우 중요합니다. SRE는 Site Reliability Engineering의 약자로, Site Reliability Engineering입니다. CTO 입장에서는 소프트웨어를 프로덕션 환경에 배포할 때 향후 다양한 문제가 발생할 수 있으므로 신뢰성을 보장할 수 있는 엔지니어링 시스템을 갖추기를 바랍니다. 이는 매우 큰 주제이므로 이 기사에서는 자세히 설명하지 않고 해당 내용과 책임이 누구에게 있는지만 명확히 설명합니다.

소위 신뢰성은 실패에 맞서 싸우는 과정입니다. 따라서 우리는 여전히 실패의 수명주기를 살펴보고 수명주기의 각 링크에서 시작하여 실패를 물리치거나 심지어 요람에서 목을 조르기도 합니다.

실패가 시작되기 전에

미리 예방하고 위험을 관리하는 데 많은 노력이 필요합니다. 예를 들어, 경보 완전성 기준을 수립하고 각 사업 부문에 대한 정량적 평가를 실시하며, 결함 등급 및 책임에 대한 기준을 수립하고 각 사업의 핵심 기능과 서비스 모듈 간의 대응 관계를 사전에 정리하고 수립합니다. 글로벌 안정성 보기 또는 워룸은 오류가 있는 모듈이나 인터페이스를 신속하게 식별하는 데 사용됩니다. 오류 계획을 분류하고 정기적인 훈련을 수행하여 혼란스러운 엔지니어링을 수행합니다.

여기에는 아키텍처 최적화 등 비즈니스 R&D가 해결해야 할 문제가 있습니다. 나머지에 대해서는 다음과 같이 제안합니다. 운영 및 유지 관리 팀이 주도하고 R&D가 협력하도록 하세요. 예를 들어 CTO 산하 핵심팀은 각 사업별로 운영 및 유지보수 직위와 기술직을 모두 맡을 가능성이 높다. 명목상 CTO는 운영 및 유지보수 직위를 주도적으로 승인하고 결정을 내릴 것이다. 각 사업별 R&D 직위는 물론, 실제 운영에 있어서는 운영 및 유지보수 1위 자리에서 향후 실제 운영을 할 수 있는 능력 있는 사람을 찾을 수도 있고, 각 사업 부문에도 의지할 수 있는 사람이 있을 수도 있다. 인터페이스 지원을 제공하는 기술 1위 위치에 있습니다.

아키텍처 최적화를 제외하고 이러한 다른 것들은 모두 수평적인 문제입니다. 모든 사람을 하나로 모으고 이러한 방법론과 모범 사례를 공유하는 데 도움이 되는 몇 가지 방법론과 모범 사례가 있을 수 있습니다. 물론 이런 안정적인 가상조직을 만들어 공동으로 추진할 수 있는 R&D팀을 직접 찾아볼 수 있느냐는 질문을 하는 분들도 계실 겁니다. 실제로 시도해 볼 수 있습니다. 하지만 몇 가지 문제가 있습니다:

• 각 비즈니스 라인에는 일반적으로 한두 명의 인터페이스 인력만 있습니다. 인력이 적고 작업량이 많아지면 이 사람은 비즈니스 코드 개발과 안정성 작업의 균형을 맞추는 데 어려움을 겪을 가능성이 높습니다. an SRE
• SRE라면 실제로 기업 R&D 인력과 평가 체계가 다릅니다. KPI는 어떻게 결정하나요? 그리고 이 사람은 소속감이 좋지 않을 수도 있습니다
• 이 사람이 안정성과 비즈니스 연구 및 개발이라는 두 가지를 동시에 처리하면 사람들의 관성이 생길 수 있습니다. 비즈니스 연구 및 개발 작업을 수행하십시오. 비즈니스 연구 및 개발에 문제가 발생하면 게으르고 안정성 작업을 수행하고 싶습니다

초점: 사전 예방 및 위험 관리, CXO에게 운영 및 유지 관리 책임자에게 문의하십시오. 큰 협력을 주고 위에서 아래로 밀어내십시오. 이 문제를 해결하기 위한 SRE 엔지니어 역할에는 매우 전문적인 고급 인력이 필요한 것으로 보입니다. 아마도 경력이 있는 R&D 팀에서 SRE를 채용하는 경우에는 5년 이내에 인지 능력이 따라가지 못할 가능성이 높습니다. CXO는 좋은 선택입니다.

실패 시작 후 영향 줄이기

실패가 발생하면 우리의 주요 목표는 영향을 줄이는 것입니다. 관련 팀들이 즉각적으로 협업해 직접적인 원인을 신속하게 찾아내고, 손실을 신속하게 중단한 뒤, 이후 천천히 근본 원인을 조사했습니다. 여기에는 다음과 같은 작업 내용이 포함됩니다.

• 결함 정의: 일반적으로 비즈니스 지표에 문제가 있다는 것은 주문량 감소, 차량 공유 호출량 감소, 결제량 감소 등 결함이 시작되었음을 의미합니다. 상사는 이러한 지표에 특별한 주의를 기울일 것입니다. 특정 시스템의 CPU가 너무 높거나 디스크가 가득 차면 K8s 유형 시스템에서도 자동으로 문제를 해결할 수 있습니다. 이는 일반적으로 고객의 주요 프로세스에 영향을 미치지 않으며 상사는 주의를 기울이지 않습니다. 혼동하지 않으려면 결함과 문제의 정의를 구분해야 합니다. 비즈니스 라인마다 지표가 다르지만 전체적인 방법론은 동일합니다.
• 장애 대응: 사업 연구 및 개발을 위한 장애 경보 수신자인가? 아니면 SRE? 아니면 OnCall 센터인가요? 회사마다 업무 방식에 큰 차이가 있습니다. 제 개인적인 생각은 처리 능력이 있는 사람에게 직접 보내는 것입니다. 흑백은 없습니다. 알람마다 처리 메커니즘이 다릅니다. 예를 들어 기본 네트워크에 문제가 있으면 분명히 네트워크 엔지니어에게 전송됩니다. 해당 운영 및 유지 관리 및 R&D에 전송합니다. 중간에 다시 전송하지 말고 Zhang San이 처리할 수 없어 Li Si에 연락하면 시간 낭비가 됩니다. 시간에 맞춰 끝내십시오.
• 빠른 위치 확인: 효과적인 결함 위치 확인 시스템은 매우 유용합니다. 오류 위치 시스템은 일반적으로 관측 가능성 데이터를 기반으로 구축되며 조종석 수준 제품으로 간주될 수 있습니다. Observability 데이터는 방대합니다. 정렬하고 활용하지 않으면 이 방대한 데이터를 가치 있는 정보로 전환할 수 없습니다. 포지셔닝 관점에서 일반적으로 필요한 것은 관찰성 시스템 + 결함 위치 + 지속적인 작동입니다. 여기서 확장하기에는 내용이 너무 많습니다. 자세히 논의하고 싶다면 저에게 연락하십시오. 나에게 연락하는 방법을 모르십니까? SRETalk 공식 계정에서 자세한 내용을 알아보세요.
• 빠른 손실 중지: 손실을 빠르게 중지하려면 완전한 계획이 있어야 합니다. 각각의 실패를 검토할 때 CTO와 운영 및 유지 관리 책임자는 계획의 효율성, 즉 실패 여부에 주의를 기울이는 것이 좋습니다. 기존 계획을 사용하여 손실을 막는 것은 여전히 ​​​​비용을 절약하는 솔루션입니다. 지금 저장했다면 계획이 충분히 완료되지 않았다는 의미입니다.

좋아요, 위의 내용은 열정이 가득합니다. 하지만 다시 질문으로 돌아가서, 이 작업에 대해 CTO는 누구에게 결과를 요청해야 할까요? 제가 제안하는 것은 SRE 팀입니다(운영 및 유지 관리와 SRE라는 단어는 이 문서에 여러 번 등장하며 기본적으로 이 문서에서 같은 의미입니다. 여기서 운영 및 유지 관리는 단순한 운영이 아닙니다). 분명히 SRE가 모든 결함을 해결할 수는 없습니다. 대부분의 결함은 다른 팀의 사람들에게 의존해야 하지만 CTO가 항상 A팀과 B팀에 갈 수는 없습니다. 따라서 SRE는 CTO의 Shang Fang을 들고 전반적인 안정성 구축을 주도해야 합니다. 각 비즈니스는 수출 인터페이스의 최선의 협력이 필요합니다. 소위 안정성 구축에는 사전 예방적 위험 관리, 사고 발생 시 전반적인 조정이 포함됩니다. , 사후 회복 또한 SRE의 가장 큰 가치입니다.

Best Practices

어떤 모델 패키지가 더 적합한지, 어떤 네트워킹 방식이 더 적합한지, 회사가 어떤 구성 요소를 더 잘 제어하고 더 나은 지원을 받을 수 있는지 등의 내용이 많이 있습니다(내부든 팀 또는 타사 공급업체), 회사에서 권장하거나 요구하는 프로그래밍 언어 및 프레임워크는 무엇이며, 업계에서 권장하는 액세스 레이어 솔루션은 무엇입니까? 변화 계획은 무엇입니까? 관찰 가능성을 어떻게 수행합니까? 기타 등등

훌륭한 비즈니스 R&D 팀의 이러한 실용적인 방법이 잘 이해되고 있다는 것은 부인할 수 없지만, 비즈니스 라인이 더 많아지면 수준이 혼합되고 수준이 낮은 팀에는 필연적으로 코칭 역할을 하는 사람이 필요하다는 것도 부인할 수 없습니다. , 아무 일도 일어나지 않을 것입니다. 수평적 기술 팀으로서 SRE 팀은 이 문제를 담당하는 데 특히 적합합니다. 하지만 분명히 이것은 신규 이민자가 채울 수 없는 고급 직위입니다. 비즈니스를 수행할 고위 인력을 모집하는 것은 CTO가 이 출발점을 사용하지 않는다면 BP는 기술 스택의 통합을 촉진하는 효과적인 수단입니다. 글쎄요, 기술 시스템이 번창할 것입니다. 그 뒤에는 다양한 거버넌스 딜레마가 있습니다.

위 4가지 지원 역량, 사업측에서는 이를 어떻게 확보해야 하는지, CTO는 어떻게 조율해야 하는지, 다양한 팀은 어떻게 협력해야 하는지, 그게 전부입니다. 아래에 두 가지 요약을 더 만들어 보겠습니다.

요약 1: CTO는 비즈니스 라인이 이러한 지원 역량을 확보하도록 어떻게 도울 수 있습니까?

물론 CTO가 모든 일을 직접 할 필요는 없지만, CTO는 정책을 발표하고 전체 군대의 총사령관이 되어야 합니다. 수평적인 업무는 SRE팀에 맡기고, 각 팀의 인터페이스 담당자들이 열심히 협력하는 것이 모범사례일 가능성이 높습니다. 수평적 업무 목표가 비즈니스 팀의 자체 폐쇄 루프로 완전히 분산되면 수평 팀이 가져오는 경험 전파 능력을 누릴 수 없게 됩니다. 게다가 엉덩이가 머리를 결정하는데, 올바른 위치에 있지 않으면 원하는 것을 할 수 없게 됩니다. 이 단어를 너무 강하게 사용해서 죄송합니다. 의도는 좋으니 직접 경험해 보시기 바랍니다.

그리고 FinOps라는 주제에 대해 조금 덧붙이고 싶습니다. FinOps도 수평적 역량에 맡겨야 할까요? 반드시 그런 것은 아닙니다. 비즈니스 자체가 이익과 손실을 책임지게 하는 것이 좋다고 생각합니다. IT 지출은 지출의 대부분을 차지하므로 CEO는 수익 및 순과 관련된 KPI를 매우 중요하게 생각해야 합니다. 비즈니스 GM에게 이익을 줍니다. 비즈니스 GM은 할 수 있습니다. 자체 폐쇄 루프는 타협입니다.

요약 2: 오퍼레이션/SRE에서의 직업 선택을 위한 제안

직급과 ​​급여 기대치가 너무 높지 않다면 비교적 기본적인 오퍼레이션 작업을 수행할 수 있습니다. 10 년. 직위와 연봉에 대한 기대치가 높다면 먼저 특정 틈새 시장을 깊이 파고들어 업계 전문가가 되는 것이 효과적인 길이다. 그 후에는 여러 기술 방향을 통합하고 폭넓게 발전하는 데 중점을 둘 것입니다. 그 후에는 사업을 시작하거나 고위 임원이 됩니다.

이 기사의 저자

Qin Xiaohui, Open-Falcon 및 Nightingale의 기업 R&D, Geek Time의 "운영 및 유지 관리 모니터링 시스템 실용 노트" 작성자​​, 공개 계정 SRETalk 관리자, Kuaimao의 기업 파트너 네뷸라, 창업의 방향은 안정성을 확보하는 것입니다. 필요하신 사항이 있으시면 언제든지 연락주세요​​.

위 내용은 CTO 관점에서: 운영 및 유지 관리/SRE 역량을 구축하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!