운영 및 유지 보수 포럼은 운영 및 유지 보수 분야의 베테랑을 초대하여 인터뷰와 초대를 통해 심오한 통찰력을 제공하여 선진적인 공감대를 형성하고 업계가 더 나은 발전을 이룰 수 있도록 장려합니다.
이번 호에는 Wang Mingsong을 초대합니다. Wang 상사는 업계에서 널리 인정받는 클라우드 네이티브 애플리케이션 실행에 대한 "4가지 규칙"을 제시했습니다. 2019년부터 Boss Wang 회사의 모든 IDC 사업이 클라우드로 이전되었습니다. 규모는 작지 않지만 SRE 팀은 NetFlix처럼 매우 작습니다. 이번 강의에서는 시니어 클라우드의 운영과 유지관리가 어떻게 이루어지는지 살펴보겠습니다.
현실적이고 수준 높은 "운영 및 유지보수 포럼" 제7호입니다. 시작하겠습니다!
시작하기 전에 왕보스님의 자기 소개를 부탁드립니다. 귀하의 업무 이력, 특히 클라우드 사용 경험에 대해 이야기하고 몇 가지 배경 정보를 제공하겠습니다.
2005년쯤에 입문으로 생각되던 학교에서 BBS 운영 및 유지보수 업무를 했습니다. 졸업 후, 저는 P1급을 시작으로 산업 전반에 걸친 운영 및 유지보수를 시작으로 지금은 쇠퇴하고 있는 대형 인터넷 기업(편집자주:바이두 참조)에 입사했습니다. 2010년에 도망쳐 모바일 인터넷 스타트업에 입사했어요. 당시에는 기본적으로 시스템 네트워크 케이블링부터 전산실 IT까지 다 했었는데, 중소기업이라 해도 서버 조달주기가 좀 길어서 시작하게 됐어요. 그때는 클라우드 사용을 고려해 보세요.
2011년부터 vmware 기반의 Suguang Cloud를 한동안 사용해왔는데, 개인적으로 사용감이나 경제성이 좋지 않을 수도 있습니다. IDC보다 기계를 설치하는 것이 더 빠릅니다. 그러면 네트워크도 이상해서 트러블이 많이 발생합니다. 동시에 샨다클라우드도 한동안 사용해봤는데 경험치는 수곤보다 좋았지만 실제로는 VPS 수준이었습니다. vpc 레이어가 완료되지 않은 것 같습니다. 너무 중요한 리소스를 감히 올려 놓지 못하고, 계속해서 뽑고 나서 사용을 멈췄습니다(어쩌면 제가 잘못 사용했기 때문인지 모니터링이 쉽지 않습니다).
저는 2013년부터 ucloud를 사용하기 시작했습니다. 주로 가상 머신을 사용하고 그 외에는 많이 사용하지 않습니다. 하지만 vpc 제품은 그 당시에 사용 가능해야 했고 일부 중요한 비즈니스가 위로 이동되었을 것입니다.
2014년에 해외사업을 시작하면서 AWS를 사용하게 되었습니다. 2019년에는 IDC의 모든 사업이 클라우드로 마이그레이션되었습니다.
WeChat 그룹에서 토론을 하다가 왕보스를 처음 만났습니다. 왕보스는 네 가지 클라우드 네이티브 애플리케이션 방식을 제안했습니다. 그는 이 네 가지가 구현되는 한 애플리케이션은 기본적으로 클라우드가 될 것이라고 믿습니다. 그룹 내 친구들 저도 그 말에 깊이 공감하고 이름을 '사왕'으로 지었습니다. 왕보스는 SRETalk 독자들에게 '사왕'의 본질을 공유해 주실 수 있나요?
스웨덴 마공의 저장소(https://github.com/lipingtababa/cloud-native-best-practices)에 클라우드 네이티브 4명의 왕에 대한 자세한 버전을 올렸습니다. 누구나 문제를 제기할 수 있습니다. 네 클라우드 네이티브 왕의 콘텐츠도
간략 버전이 수시로 업데이트됩니다.
이 네 가지 항목 실제로 출발점은 비용, 성능 및 안정성을 고려하면서 기본적으로 애플리케이션의 무상태성과 데이터 보안에 관한 것입니다. 애플리케이션 범위는 클라우드 컴퓨팅에만 국한되지 않습니다. . 기존 IDC도 참조로 구현할 수 있습니다.
편집자 주: 이 단순화된 버전은 별 것 아닌 것처럼 보이지만 실제로는 많은 내용이 포함되어 있습니다. "Cloud Native King Si Tiao" 링크를 클릭할 수 없으면 저장소로 이동하세요. 위에서 "Cloud Native King Si Tiao.md"를 찾으세요.
"사왕"에는 R&D에서 조정해야 할 몇 가지 모범 사례가 나열되어 있습니다. 회사 내에서 구현할 때 장애물이 있나요? 어떻게 해결하셨나요?
거의 어려움이 없었지만, 그건 우리 각자의 사정이 있었기 때문이었습니다.
당시 우리는 클라우드로 갈 수밖에 없었고 비용 관리도 어려운 목표였기 때문에 선택할 수 있는 다른 회유 경로가 없었습니다.
우리는 팀에서 분리된 새로운 회사이므로 전환하는 데 1년밖에 걸리지 않았습니다. 경영진이 제시한 목표는 수천 대의 기존 시스템에서 실행되는 수익성 있는 비즈니스를 원활하게 통합하는 것입니다. 당시 우리는 해외 사업만 하고 있었기 때문에 비클라우드 솔루션은 전혀 고려하지 않았습니다. 하지만 경영진에서는 여전히 이전에 IDC를 사용할 때보다 클라우드 비용이 더 낮아야 한다고 요구했습니다.
원래 아키텍처를 클라우드로 직접 옮기면 경영진이 설정한 비용 목표는 절대 달성되지 않을 것입니다(pigsty의 Feng 상사는 클라우드에 비해 기존 IDC의 비용 이점을 입증하기 위해 유사한 기사를 많이 썼습니다). 그 당시 유일한 선택은 기존 아키텍처를 클라우드에 적응하도록 변환하여 마이그레이션 후 비용, 성능 및 안정성 목표를 달성할 수 있도록 하는 것이었습니다.
한편, R&D가 모델 선택 및 비용 최적화에 전적으로 참여하면 모두가 합의에 도달할 수 있습니다.
퍼블릭 클라우드 선정을 시작하기까지 약 1년 정도 시간을 투자하고, 클라우드를 더 잘 활용하는 방법을 배우기 위해 구체적으로 교육에 참여하며 점차 나만의 방법론을 형성해 나갔습니다. 마이그레이션 전에는 R&D 핵심 구성원을 지도하여 관련 교육을 실시한 후, 실제 마이그레이션 중에도 AWS에서 더 전문적인 솔루션을 제공했다는 사실을 이해할 수 있었습니다. 설계. 따라서 "사왕"의 콘텐츠를 구현하는 것은 상대적으로 쉽습니다. 예:
1. EBS에 데이터를 저장하는 것은 비용이 많이 들기 때문에 다양한 솔루션의 학습과 비교를 통해 S3에 데이터를 저장하는 것이 매우 경제적입니다. , R&D는 이러한 상황을 매우 명확하게 만들었으므로 프로그램 수정에 대한 더 큰 의지를 갖게 될 것입니다.
2. Role은 보안 요구 사항입니다. AWS SDK에서 매우 잘 지원하기 때문에 처음 시작할 때 Role을 사용하든 ak sk를 사용하든 처음부터 잘 제어하면 문제가 없습니다. 연구 개발을 위해.
3. 호스팅 서비스에 관해서는 사실 R&D에서는 운영 및 유지 관리나 기존 서비스의 이용 여부에 관심을 두지 않습니다. 우리의 운영과 유지 관리가 우리의 집착을 버릴 수 있다면 이것으로 충분할 것입니다.
4. 서버에 데이터를 저장하지 마세요. 사실, 우리는 상대적으로 큰 경쟁을 겪었습니다.
이번 마이그레이션은 AWS에 대한 완전한 플랫폼 지원을 갖춘 IDC 환경에서 AWS 파트너의 도움으로 새로운 아키텍처는 AWS 모범 사례에 따라 설계되었으며 이전 사용 습관 및 요구 사항을 충족합니다.
하지만 재건축으로 인해 여전히 사용법에는 차이가 있습니다. ASG를 사용하기 때문에 축소 또는 오류 마이그레이션 중에 서버가 직접 종료됩니다. 영구 데이터를 저장해야 할 경우 R&D는 기본적으로 서버에 온라인 비즈니스 데이터가 존재하지 않는 것으로 받아들일 수 있습니다. .
이러한 설계로 인해 서버 스토리지 요구 사항이 100G를 초과하면 내 승인이 필요합니다. EBS 비용이 많이 절약되었습니다
나중에 R&D 팀이 K8S를 배포하면서 이에 대해 더 깊이 이해하게 되었습니다. 결국 컨테이너에 있는 데이터는 손실될 것입니다.
최근 일부 기사에서는 ROI를 종합적으로 측정하고 클라우드로 전환하는 것이 더 비용 효율적이라고 생각한다고 밝혔습니다. 예를 들어 RoR의 아버지의 기사와 지난호 Tuyou Games의 Zou 씨의 기사가 있습니다. 운영 및 유지 관리 Baijia 포럼 귀하는 클라우드를 더 깊이 있게 사용하려는 경향이 있는 것 같습니다. 귀하의 생각을 모든 사람과 공유할 수 있습니까?
사실 저는 "모범 사례"를 옹호해 왔지만 "모범 사례는 투자자나 경영의 황제의 기술"이라는 사실도 여러분과 소통했습니다. 사람들의 일자리가 최적화될 수 있습니다. 일자리를 파괴하지 않고 최적화가 이루어지면 선택의 여지가 더 많아질 것입니다.
클라우드로 갈지 클라우드로 갈지는 관심분야, 경영 지원 강도, 역사적 수하물에 따라 다릅니다. 제가 조우씨나 DHH의 입장이었다면 현재의 견해를 고수하지 않을 수도 있습니다. 나는 클라우드를 고수할 수 있다:
한편으로는 경영진이 유휴 자산의 손실을 입었다는 것을 인정합니다. 나는 오랫동안 유휴 IDC 자원의 최적화를 해왔기 때문에 그렇습니다. 해외에 자체 전산실을 구축하는 것은 특별하지 않습니다. 클라우드로의 전환은 기본적으로 경영진이 지원하는 유일한 솔루션입니다.
한편, 위에서 언급한 것처럼 우연히 우리 아키텍처가 완전히 변형되었으며, 변형 비용은 경영진이 지원하므로 클라우드의 장점을 최대한 활용할 수 있습니다.
마지막으로, 우리의 비즈니스 모델에는 아직 장기적으로 안정적인 고부하 및 무상태 비즈니스가 없습니다. 이러한 종류의 비즈니스는 전통적인 IDC에 더 적합합니다.
Zou씨나 DHH가 기존 시스템 아키텍처를 전환하는 데 드는 비용이 너무 높다고 생각합니다. 운영 및 유지 관리 부서의 인건비를 줄일 수 있더라도 다른 인력도 필요하기 때문에 지원을 받기 어려울 수 있습니다. 부서.
하지만 새로운 회사나 새로운 프로젝트라면 클라우드보다 더 적합한 시나리오는 없다고 생각합니다. 적절한 클라우드 공급업체를 선택하고 클라우드 네이티브 아키텍처를 사용하여 비즈니스를 구현하면 비즈니스 전체가 유연해집니다. 성능과 비용 측면에서요.
많은 친구들이 클라우드 킬링, 잠금 등에 대해 불평했습니다. 하지만 투자자나 경영진 입장에서는 모든 요소가 비즈니스 수익성을 달성하기 위한 것이며, 사람/클라우드/IDC 등은 모두 비즈니스를 달성하기 위한 요소입니다. 적시에 귀하의 요구를 충족하는 요소를 얻을 수 있는 것(이것이 더 중요합니다). 클라우드 요소를 얻는 것이 이보다 쉬울 수는 없습니다. 몇 번의 클릭만으로 비용을 지불할 수 있지만 언제든지 사용을 중단할 수 있습니다. 하지만 사람들은 어떻습니까? 사람을 구하기 어렵고, 품질을 결정하기가 어렵습니다. 표준화되어 있지 않으며, 가격 변동(급여 인상)이 발생합니다. 직장을 그만둘 때도 마찬가지다. 사람들은 매우 창의적일 수 있지만 표준화와 기계적인 지루한 일에 있어서는 SaaS 서비스는 물론이고 기계의 반대자가 될 수 없습니다.
Mr. Zou의 상황에서 비즈니스 팀이 프로그램 아키텍처를 변환할 의지가 없다면 그의 현재 선택은 모범 사례입니다. 안정적이고 부하가 높은 비즈니스를 위해 비용 측면에서 이점이 있는 IDC를 선택하고 기계를 구입하는 대신 임대하는 것입니다. 클라우드에서 유연한 비즈니스를 수행하세요.
37signals의 Basecamp의 경우 제품의 가격 모델 설정에 따라 클라우드로 마이그레이션하는 것이 약간 번거롭다고 판단됩니다. 현재 대부분의 SaaS 서비스는 사용량이나 사용자 수에 따라 비용을 지불하지만 Basecamp는 주로 한 달에 199달러에 불과한 무제한 패키지를 판매합니다. 이 가격 책정 모델은 클라우드의 탄력성을 완전히 활용하여 수익을 창출할 수 없으며 저가 리소스만 초과 예약할 수 있음을 의미합니다. 이 가격 책정 모델이 바뀌지 않으면 아무리 아키텍처를 최적화해도 클라우드에 적합하지 않을 수 있습니다.
최근 "운영 및 유지관리의 미래는 플랫폼 엔지니어링이다"라는 기사가 있었습니다. 이 견해에 동의하시나요? 플랫폼 엔지니어링에서 귀하의 팀은 어떤 역할과 경계를 갖고 있습니까? 소위 플랫폼 엔지니어링(특히 멀티클라우드 환경에서)을 어떻게 계획하시나요?
Ruan Yifeng이 썼나요 아니면 Charity Majors가 썼나요? 하지만 저는 이 두 기사를 이전에 읽은 적이 없고, 단지 간략하게 살펴보았습니다. 나는 이것에 전적으로 동의하지 않으며 개인적으로 내부 플랫폼 엔지니어링을 시도하지 않습니다.
우선 제가 동의하지 않는 점부터 말씀드리겠습니다. 해당 기사에는 개념에 대한 오해가 있습니다.
먼저 DevOps는 입장이 아닙니다. 오랫동안 이해하려고 노력해 왔고, 최종적으로는 개발 모델이라는 느낌이 들었습니다. 하지만 이 개발 모델의 핵심은 R&D이며, 모든 요소는 효율적인 R&D 반복 서비스에 집중되어야 합니다. 기사에서는 처음에는 DevOps가 직위라고 믿었지만 나중에는 이 직위가 비즈니스 개발을 위한 것이라고 믿었습니다. 이는 부적절한 이해라고 생각합니다.
둘째, 운영 및 유지 관리에는 미래에 대한 풍부한 탐구가 있습니다. 변화는 새로운 주제가 아닙니다. 운영 및 유지 관리 산업은 지난 10년 동안 많은 운영 및 유지 관리 분야에서 다음 단계로의 전환을 위해 노력해 왔습니다. 일부는 CI/CD에 참여하려고 하고 일부는 CI/CD에 참여하려고 합니다. 일부는 모니터링 연구 개발을 시도하고 일부는 자동화된 운영 및 유지 관리 플랫폼을 개발하려고 하며 일부는 새로운 분야에 참여하려고 합니다( K8s, 빅데이터, AI, 클라우드 컴퓨팅 등), 일부는 다른 하위 프로젝트(DBA, 네트워크 보안 등)로 이동을 시도하고 있습니다.
이러한 변환 중 다수가 DevOps 개발 모델을 지원하는 것을 볼 수 있습니다.
플랫폼 엔지니어링은 구현 모델일 수도 있지만, 운영 및 유지 관리 그룹의 제품력과 R&D 수준으로 인해 플랫폼 엔지니어링을 혼자서 하는 것은 재미만 있을 뿐이고 안정성조차 보장할 수 없어 증가만 할 뿐입니다. 책임을 질 가능성. 하지만 이를 위해 좀 더 전문적인 제작 및 연구팀이 투입된다면, 한편으로는 사업을 제대로 하지 못하고, 다른 한편으로는 주요 사업수입과 무관한 경우 지원을 받기 어려울 것입니다. , 그것은 단지 자급자족을 위한 플랫폼일 뿐이며, 수입도 없이 제품을 만들기 위해 그렇게 많은 사람을 모집하는 것은 경제적이지 않으며, 더욱이 이러한 접근 방식은 참여의 의미가 없습니다. 기존의 운영 및 유지보수가 가능하며 이를 변형이라고 볼 수 없습니다.
그래서 올바른 접근 방식은 성숙한 플랫폼과 도구(오픈 소스/유료 자체 구축, SaaS 사용 가능)를 사용하는 것입니다. 이러한 플랫폼을 기반으로 일부 사용자 정의 및 2차 개발을 수행할 수 있지만 이를 재발명하지는 마세요. 바퀴.
마지막으로 그 기사에 나오는 플랫폼에 대한 나의 이해도 다릅니다.
플랫폼 자체가 SaaS 형태로 제공될 수 있으며, 2차 통합이 필요하지 않은 이유는 현재 국내 SaaS 환경이 좋지 않고, 소프트웨어 서비스가 이에 관심을 기울이지 않는다는 점입니다. 상호 통합 및 호환성이 있지만 규모가 크고 포괄적인 것을 선호합니다. 해외를 살펴보면 해외 틈새 분야에 SaaS나 소프트웨어가 많이 있다는 것을 알 수 있는데, 이는 매우 훌륭하고 다른 소프트웨어와 통합될 수 있습니다. 생태계가 매우 좋아서 통합 구성이 쉽고 그렇지 않습니다. 보조 개발에 많은 작업량이 필요합니다.
반면, 플랫폼의 사용자는 R&D여야 하며, R&D는 이를 전달하거나 승인하기 위한 운영 및 유지관리가 필요 없이 직접 사용할 수 있어야 합니다.
그래서 앞으로는 꼭 플랫폼을 사용해야 합니다. 우리가 직접 만든 장난감이 아니라, 제작팀과 연구팀이 직접 사용하는 플랫폼이니까요. 운영 및 유지보수 담당자가 중앙에 서서 마이크 역할을 하는 것보다
그래서 플랫폼 엔지니어링을 위해서는 성숙한 소프트웨어나 SaaS 서비스를 적극적으로 활용하고, 제작팀과 연구팀이 직접 사용할 수 있도록 최대한 제공하는 쪽을 선택합니다.
운영 및 유지보수는 비용과 보안을 기준으로 꼭 필요한 체크포인트만 만들고, 정책, 권한, 감사를 통해 관리하여 제작팀과 연구팀이 올바르게 사용할 수 있도록 합니다.
왕보스의 작업 모델에서는 아주 선배들만 필요하다고 생각합니다. R&D 코치 역할을 맡기에는 신선한 피가 너무 어리지만, 신선한 피가 없으면 장기적인 계획을 유지할 수 없습니다. . 당신의 경험을 공유해주실 수 있나요? 팀을 어떻게 구성했나요?
이 질문은 저도 아직 해결하지 못했기 때문에 좋은 질문입니다. 이는 이 작업 모델에서는 문제가 되지 않습니다.
많은 기업과 다양한 직종에서 선배 인재에 대한 수요가 있는데, 그들 모두 지금 제가 직면하고 있는 것과 같은 문제에 직면해 있습니다. 어떤 유형의 작업에 선배 인재가 필요하지 않습니까? 업무 내용이 매우 표준화되어 있고, 회사의 요구 사항도 높지 않으며, 누구나 필요에 따라 명확한 지시를 내리고 잘 할 수 있다고 생각합니다. 기계도 할 수 있습니다.
조우씨는 전통적인 운영과 유지관리가 청소와 비슷하다는 말이 있습니다. 작업 내용은 중요하지만 가치는 높지 않습니다. 나는 이 말에 전적으로 동의합니다. 이것이 현재 우리가 운영 및 유지 관리에 직면하고 있는 딜레마입니다. 그럼 청소팀이 자체적으로 청소 도구를 개발하나요, 아니면 구매하나요?
숙성된 제품과 외부 서비스를 많이 사용하기 때문에 다양한 자동, 반자동 청소도구를 이용한 청소처럼 청소 업무도 보다 안정적으로 출력할 수 있습니다. 하지만 사람의 청소능력이 부족해서 걸레질이 지저분하거나, 전문성이 부족해서 간단한 스캔만 하고 일을 넘겨주는 것에 대해 걱정할 필요는 없습니다. 청소에는 기존 도구보다 이러한 도구를 잘 작동하는 데 약간 더 많은 학습이 필요하고 어려움이 있지만 성숙한 도구가 세부 사항을 보호하기 때문에 전체 SOP는 이전보다 적습니다.
그러니 가치가 낮은 업무 콘텐츠에 시간을 낭비하지 마세요. 이러한 유형의 작업은 규모의 경제, 좋은 기능 및 SLA를 갖춘 전문 소프트웨어로 완료되어야 합니다. 우리는 기업, 경영진, 투자자가 더 관심을 갖는 분야에 업무를 집중해야 합니다.
우리는 왕보스가 항상 "반인간"인 "운영 및 유지 자기 혁명"을 옹호해 왔다는 것을 알고 있습니다. 이에 대한 생각에 대해 말씀해 주시겠습니까?
지금 우리가 볼 수 있는 사실은 운영 및 유지 관리가 호황을 누리고 있는 산업이 아니라는 것입니다. 대부분의 회사에는 회사 시스템 운영을 지원하는 대규모 운영 및 유지 관리 부서가 없으며 사람도 한 명만 필요할 수도 있습니다. IT, 네트워크 관리, 보안 및 기타 업무를 담당합니다. 우리는 개선의 여지가 없습니다. 운영 및 유지 관리 책임자는 거의 없으며 현재 관리하는 사람 수로는 기본적으로 운영 및 유지 관리 책임자라고 부를 수 있습니다.
현재 업계도 마찬가지입니다. 많은 교육 과정을 통해 빠른 운영과 유지 관리가 가능하며, 이는 충분하고 저렴합니다. 중급 수준의 운영 및 유지 관리는 네트워크 엔지니어나 DBA와는 다릅니다. 우리의 기술 스택은 매우 복잡하며 우리의 능력을 표시할 수 있는 권위 있는 인증이 없습니다. 진로를 개척하고 건강한 인재시장을 형성합니다. 따라서 우리의 운영 및 유지 관리에 대한 시장의 포지셔닝은 실제로 "비즈니스 코드를 작성하지 않는 기술"이 우리의 가장 정확한 포지셔닝일 수 있습니다.
DevOps의 개념에 따르면 생산과 연구에 혼란을 가하기보다는 비즈니스 전달 속도를 높이고 좋은 서비스를 제공해야 합니다. 그러나 운영 및 유지 관리의 의미와 작업은 DevOps에만 국한되지 않습니다. 이것이 내 견해가 다른 많은 사람들과 다른 점입니다.
한편으로 운영 및 유지 관리는 회사 디지털 자산의 "감시자"입니다. 이러한 관점에서 운영 및 유지 관리는 경영진과 투자자의 이익을 대표하며 회사의 디지털 자산이 제대로 보호될 수 있도록 보호합니다. 다양한 규제 요구 사항을 충족하고 다양한 내부 감사에 참여하는 데 사용됩니다. 생산팀과 연구팀에 대한 경영진의 견제와 균형이다. 이는 실제로 초기 작동 및 유지 관리의 의미입니다.
반면에 나라에서는 음식으로 보답합니다. 규제 요구 사항은 점점 더 엄격해지고 있습니다. 네트워크 보안, 데이터 보안, 개인 정보 보호 등 관련 업무를 담당하는 전담 인력이 필요합니다. 소규모 기업의 경우 이러한 작업을 운영 및 유지 관리가 동시에 수행해야 하며, 특히 데이터 보안을 직접 담당하는 디지털 자산의 운영 및 유지 관리가 포함되어야 합니다. 이는 새로운 시대의 운영 및 유지 관리를 위한 요구 사항입니다.
그래서 이것을 이해하고 싶다면 데브옵스와 플랫폼은 모두 운영과 유지관리 업무의 작은 부분이라는 것을 알게 될 것입니다. , 관리 및 감독 측면에서 좋은 일을 하세요.
위 내용은 자기혁명의 '사왕'을 실천하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
