DevOps, SRE, 플랫폼 엔지니어, 클라우드 역할 설명

기사 요약 DevOps 개념이 발전함에 따라 DevOps, SRE(사이트 안정성 엔지니어), 클라우드 엔지니어, 플랫폼 엔지니어 등 관련 역할의 책임에 대한 모호성이 증가하고 있습니다. 이러한 역할은 중복되지만 초점과 기술에는 미묘한 차이가 있습니다. DevOps는 개발팀과 운영팀 간의 협업을 강조하는 반면, SRE는 시스템 안정성에 중점을 두고 소프트웨어 엔지니어링 관행을 운영에 적용합니다. 클라우드 엔지니어는 클라우드 인프라 관리에 중점을 두고, 플랫폼 엔지니어는 내부 개발자 플랫폼을 만들어 개발자에게 셀프 서비스 운영 기능을 제공합니다. DevOps 관행의 이질성과 조직의 저항으로 인해 역할 사양이 불분명한 상태로 남아 있습니다. 따라서 채용 시 역할 기대치와 조직적 맥락을 명확히 하는 것이 중요합니다. 모든 운영 요구 사항이 충족되는지 확인하는 것은 개발자를 지원하고 DevOps의 잠재력을 최대한 실현하는 데 중요합니다.

원래 생각했던 것처럼 DevOps는 일련의 관행이라기보다는 철학에 가깝고 확실히 직위나 역할 사양이 아닙니다. 그러나 오늘날 DevOps 엔지니어, 사이트 안정성 엔지니어, 클라우드 엔지니어 및 플랫폼 엔지니어는 모두 수요가 높습니다. 이들의 기술이 중복되고 채용 담당자가 "CI/CD 파이프라인, 배포 엔지니어링, 클라우드 구성 및 Kubernetes

"와 같이 느슨하게 관련된 키워드를 뿌립니다. 저는 Kubiya.ai를 공동 창립했는데, 투자자들이 제 목표 시장을 더 잘 정의하도록 압력을 가했습니다. 예를 들어 SRE, 클라우드 및 플랫폼 엔지니어, 기타 최종 사용자였나요? 이러한 역할을 정의하는 데 구직자와 채용 담당자의 관심이 쏠리고 있습니다. Reddit 게시물부터 웹 세미나에 이르기까지 이는 뜨거운 논쟁을 불러일으키는 주제입니다.

이 기사에서는 내 생각을 제시하지만 해석의 여지가 많다는 점도 인정합니다. 많은 사람들에게 자극적인 주제이므로 화재가 발생할 위험이 있으니 다음으로 넘어가겠습니다.

먼저 다양한 역할에 대한 간략한 요약

DevOps, SRE, 클라우드 및 플랫폼 역할에 대한 개괄적인 보기

DevOps 역할은 팀워크와 도구를 사용하여 더 열심히 일하는 것이 아니라 개발자와 운영진을 하나로 묶어 출시 속도를 높이고, 시스템 안정성을 향상시키며, 모두가 같은 생각을 갖도록 하는

SRE 역할에 집중합니다. 시스템은 안정적이고 확장 가능합니다. 그들은 모든 것이 뒤에서 원활하게 실행되도록 하고 개발자와 긴밀히 협력하여 프로세스를 자동화하고 모든 문제에 신속하게 대응하는 엔지니어와 같습니다.

클라우드 엔지니어의 역할은 바로 클라우드 설계자와 같습니다. 그들은 클라우드 인프라를 효율적이고 안전하며 비용 효율적으로 설정 및 관리하는 데 중점을 두고 AWS 또는 Azure와 같은 도구를 사용하여 애플리케이션이 성공할 수 있는 환경을 만듭니다.

플랫폼 엔지니어의 역할은 클라우드 인프라를 구축하는 것과 같습니다. 개발자 친화적인 플랫폼으로, 관련된 모든 사람의 이익을 위해 워크플로 설정부터 성능 모니터링까지 개발자가 애플리케이션을 쉽게 관리할 수 있는 시스템을 설계하고 유지 관리합니다.

DevOps 방식은 시스템 안정성을 유지하면서 릴리스 속도를 높이고 출시 시간을 단축해야 하는 요구 사항을 충족하기 위해 발전했습니다. 또한, 별도의 개발 팀이 개별 서비스 및 애플리케이션에 대해 독립적으로 작업할 수 있으므로 더 빠른 프로토타이핑 및 반복이 가능합니다.

소프트웨어 릴리스에 중점을 둔 개발 팀과 시스템 안정성 및 보안에 중점을 둔 별도의 고유한 운영 팀으로 인해 많은 기업이 추구하는 속도가 저하되고 개발자가 성능 문제가 발생하기 전에 항상 예방할 수는 없습니다. 원래 구상했던 대로 DevOps는 일련의 규범적 관행이라기보다는 철학에 가깝습니다. 너무 많아서 그러한 관행의 양과 성격에 대한 합의조차 이루어지지 않았습니다. 어떤 사람들은 "DevOps의 4가지 기둥"을 인용하고, 어떤 사람들은 "5가지 기둥"을 인용하며, 어떤 사람들은 6개, 7개, 8개 또는 9개의 기둥을 인용합니다. 선택할 수 있습니다.

다양한 조직에서는 DevOps를 다양한 방식으로 구현합니다(전혀 그렇지 않은 경우도 많습니다). 여기서 우리는 우리가 처해 있는 업무 규범 딜레마를 예상할 수 있습니다. DevOpsDays 창립자인 Patrick Debois는 다음과 같이 지적합니다. "정의가 없는 것은 좋거나 나쁩니다. 사람들은... DevOps가 의미하는 바를 이해하기 위해 지금 정말 어려움을 겪고 있습니다. 그러나 반면에 모든 것을 기록해 두지 않는다는 것은 이동이 가능하다는 것을 의미합니다.

DevOps에 대한 답은 사일로를 허물고 도구, 문화적 변화, 공유 지표를 통해 더 광범위한 협업을 장려하는 것입니다. 개발자는 자신이 구축한 것을 소유하게 됩니다. 즉, 엔드투엔드를 배포하고 모니터링하고 문제를 해결할 수 있습니다. 운영팀은 개발자 요구 사항을 더 잘 이해하고, 제품 수명 주기 초기에 참여하고, 개발자 셀프 서비스를 촉진하기 위한 교육, 도구 및 보호책을 제공합니다.

DevOps에 없는 한 가지는 역할 지정입니다. 오늘날에는 많은 조직에서 "DevOps 엔지니어"를 적극적으로 채용하고 있습니다. 더 나쁜 것은 직위를 정의하는 것이 무엇인지에 대해 알려진 바가 거의 없다는 것입니다. 추구하는 기술 세트는 직위마다 크게 다릅니다. "사이트 안정성 엔지니어", "플랫폼 엔지니어", "클라우드 엔지니어" 등 관련되고 중복되는 역할은 이미 불투명한 상황을 만들고 있습니다.

우리가 어떻게 여기까지 왔나요? 이러한 역할 간의 실제 차이점은 무엇입니까(있는 경우)?

새로운 IT 역할의 출현

DevOps가 주목을 받으면서 DevOps 생태계의 역할과 책임은 점점 더 모호해지고 있습니다. 이러한 모호함은 사이트 안정성 엔지니어(SRE), 클라우드 엔지니어, 플랫폼 엔지니어와 같은 관련 역할의 출현으로 이어졌습니다. 각 캐릭터는 고유한 초점과 기술을 가지고 있습니다.

대규모 시스템 관리에 대한 Google의 접근 방식에서 영감을 받은 SRE는 소프트웨어 엔지니어링 방식과 운영을 결합하여 서비스 안정성과 성능을 보장합니다. 클라우드 엔지니어는 클라우드 인프라 배포 및 관리에 중점을 두고 AWS, Azure 또는 Google Cloud와 같은 플랫폼을 활용하여 확장성과 효율성을 최적화합니다. 반면, 플랫폼 엔지니어는 사내 개발자 플랫폼을 설계하고 유지 관리하는 데 중점을 두고 개발자에게 애플리케이션 수명주기의 운영 측면을 관리할 수 있는 셀프 서비스 기능을 제공합니다.

이러한 역할 간에는 중복이 있지만 각각의 전문 분야와 중점 분야가 다릅니다. SRE는 안정성과 탄력성을 우선시하고, 클라우드 엔지니어는 클라우드 인프라 관리에 중점을 두고, 플랫폼 엔지니어는 개발자 중심 플랫폼을 만드는 데 중점을 둡니다. 조직이 팀을 효과적으로 구성하고 소프트웨어 제공 파이프라인에서 DevOps 원칙의 잠재력을 최대한 활용하려면 이러한 역할의 미묘한 차이를 이해하는 것이 중요합니다.

DevOps 저항 및 혼란

내 경험에 따르면 DevOps의 원래 비전을 달성하는 것, 즉 전문화와 협업 및 공유 간의 최적의 균형을 달성하는 것은 많은 조직에서 어려운 과제였습니다.

Puppet의 2021년 DevOps 현황 보고서에 따르면 응답자 중 18%만이 자신을 "고도로 발달된" DevOps 실무자라고 생각하는 것으로 나타났습니다. DevOps 토폴로지 팀이 설명했듯이 이러한 이점 중 일부는 특별한 상황에서 비롯됩니다. 예를 들어, Netflix 및 Facebook과 같은 조직은 단일 웹 기반 제품을 보유하고 있으므로 제품 스트림 간의 차이가 줄어들어 개발자와 운영 직원이 더욱 분리됩니다.

시스템 성능을 손상시키는 소프트웨어를 거부할 수 있는 권한을 갖고 있는 Google의 SRE 팀(나중에 자세히 설명!)과 같이 엄격한 협업 조건과 표준을 부과하는 다른 업체도 있습니다.

DevOps 개발 수준이 낮은 많은 사람들은 변화에 대한 조직의 저항, 기술 부족, 자동화 부족 또는 레거시 아키텍처로 인해 DevOps의 가능성을 완전히 실현하는 데 어려움을 겪고 있습니다. 따라서 그룹은 DevOps 토폴로지에 설명된 일부 DevOps "안티 유형"을 포함하여 DevOps 구현에 대한 다양한 접근 방식을 채택할 것입니다.

많은 사람들에게 개발과 운영은 여전히 ​​고립되어 있습니다. 다른 사람들에게 DevOps는 개발에 참여하고 배포 파이프라인, 구성 관리 등을 담당하지만 운영과는 격리된 도구 팀이 될 것입니다. 다른 사람들에게 DevOps는 DevOps 엔지니어가 운영 팀에 고용되고 기술 기대치가 확대되는 SysAdmin의 단순한 재창조가 될 것이지만 실제 문화적 변화는 일어나지 않습니다.

퍼블릭 클라우드 사용의 급속한 채택으로 인해 셀프 서비스 DevOps 접근 방식의 전망에 대한 신뢰도 높아졌습니다. 그러나 온디맨드 방식으로 인프라를 프로비저닝하고 프로비저닝할 수 있다는 것은 개발자가 애플리케이션과 서비스를 엔드 투 엔드로 배포하고 실행할 수 있도록 하는 것과는 거리가 멀습니다. 불행히도 모든 조직이 이를 이해하는 것은 아니므로 많은 조직의 자동화는 인프라 자동화 및 구성 관리 수준에서 지연됩니다.

DevOps에는 매우 다양한 형태가 있으므로 DevOps 역할 사양이 명확하게 정의되지 않은 것은 놀라운 일이 아닙니다. 어떤 조직에서는 CI/CD 파이프라인 생성과 같은 좁은 의미의 배포 엔지니어링과 동의어일 수도 있지만, 다른 한편으로는 인프라 작성 능력을 갖춘 운영의 재창조일 수도 있습니다. 코딩을 위한 추가 기술 , 배포 자동화 및 내부 도구. 다른 사람들에게는 그 사이에 회색 음영이 있을 수 있으므로 여기에 DevOps 직무 역할의 어지러운 목록이 있습니다.

SRE, 클라우드 엔지니어 및 플랫폼 엔지니어 역할

따라서 채용 조직에 따라 DevOps 엔지니어는 완전히 배포 중심의 엔지니어일 수도 있고 보다 현대적인 시스템 관리자일 수도 있습니다.

다른 관련 역할인 SRE, 클라우드 엔지니어, 플랫폼 엔지니어는 어떻습니까? 각 질문에 대한 내 생각은 다음과 같습니다.

Site Reliability Engineer

SRE의 개념은 Google의 Ben Traynor에 의해 도입되었습니다. 그는 이를 다음과 같이 설명했습니다. 그렇게 하면 얻을 수 있어?" 아이디어는 사람들이 운영 및 소프트웨어 개발 기술을 결합하여 생산 시스템을 설계하고 실행하도록 하는 것입니다.

SRE(사이트 안정성 엔지니어)는 소프트웨어 엔지니어링 실무와 운영 책임을 결합하여 시스템과 서비스의 안정성, 확장성 및 성능을 보장합니다. 그들은 인프라를 관리 및 모니터링하고, 소프트웨어를 배포하고, 사고에 사전에 대응하는 자동화된 솔루션을 설계 및 구현하는 것을 전문으로 합니다. SRE는 개발팀과 긴밀히 협력하여 안정성 표준을 확립 및 시행하고, 서비스 수준 목표(SLO)를 정의하며, 오류 예산 책정과 같은 관행을 구현하여 혁신과 시스템 안정성의 균형을 맞춥니다. 이들의 목표는 지속적인 개선과 반복을 통해 프로덕션 환경의 가용성과 탄력성을 높게 유지하는 것입니다.

서비스 안정성 SLA(서비스 수준 계약)의 정의는 개발 팀이 소프트웨어 배포가 승인되기 전에 소프트웨어가 엄격한 운영 표준을 충족한다는 사전 증거를 제공하도록 하는 데 중요합니다. 또한 SRE는 개발자가 이러한 목적으로 사용할 수 있는 표준화된 CI/CD 파이프라인 및 클라우드 인프라 플랫폼을 설계하고 실행하는 것을 포함하여 인프라 시스템을 더욱 확장 가능하고 유지 관리 가능하게 만들기 위해 노력합니다.

보시다시피 이는 일부 사람들이 정의하는 DevOps 엔지니어와 상당히 겹칩니다. 아마도 차이점에 대해 생각하는 한 가지 방법은 다음과 같습니다. 이와 대조적으로 DevOps의 원래 목적은 릴리스 속도를 높이는 것이었고 SRE의 목표는 증가하는 시스템 규모와 제품 복잡성의 맥락에서 보다 안정적인 시스템을 구축하는 것입니다. 그래서 어찌 보면 둘은 중간에서 만난 셈이다.

클라우드 엔지니어

클라우드 기능이 계속 성장함에 따라 일부 조직에서는 클라우드 엔지니어를 위한 전담 역할을 만들었습니다. 마찬가지로, 엄격하고 빠른 규칙은 없지만 클라우드 엔지니어는 일반적으로 클라우드 인프라 배포 및 관리에 중점을 두고 클라우드 네이티브 애플리케이션을 위한 환경을 구축하는 방법을 알고 있습니다. 그들은 AWS/Azure/Google Cloud Platform의 전문가가 될 것입니다. DevOps 엔지니어와의 책임 중복 정도에 따라 Terraform, Kubernetes 등에 능숙할 수도 있습니다.

또한 클라우드 엔지니어는 클라우드 기술에 대한 전문 지식을 활용하여 확장 가능하고 탄력적인 클라우드 아키텍처를 설계, 구현 및 유지 관리함으로써 애플리케이션과 시스템이 클라우드 환경에서 효율적이고 안전하게 실행되도록 보장합니다. 클라우드 엔지니어는 자동화, 모니터링 및 비용 최적화 전략을 연구하여 조직의 클라우드 컴퓨팅 이점을 극대화할 수도 있습니다.

클라우드 채택이 계속 발전함에 따라 클라우드 엔지니어의 역할은 이전에 인프라 엔지니어로 알려졌던 업무를 포괄하며 초기에는 클라우드 및 온프레미스 인프라 관리에 중점을 둡니다.

플랫폼 엔지니어

내부 개발자 플랫폼(IDP)은 개발자 생산성과 시스템 제어 및 안정성의 균형을 맞추는 과제에 대한 최신 솔루션으로 등장했습니다. 플랫폼 엔지니어는 인프라 프로비저닝 및 컨테이너 오케스트레이션, 모니터링, 경고 및 관찰 가능성 등 전체 애플리케이션 수명주기의 운영 측면을 독립적으로 관리할 수 있는 셀프 서비스 기능을 개발자에게 제공하기 위해 IDP를 설계하고 유지 관리합니다.

많은 개발자는 적어도 전통적인 의미에서는 작업을 전혀 수행하고 싶어하지 않습니다. 창의적인 아티스트로서 개발자는 인프라 작동 방식에 대해 걱정하고 싶지 않습니다. 따라서 플랫폼을 표준과 프로세스를 강제하기보다는 강력한 셀프 서비스 개발자 경험을 창출하여 제어할 수 있는 제품으로 보는 것이 중요합니다.

명료화: 역할 기대 명확화

그렇다면 이러한 다양한 역할에 대한 후보자는 어디에 있습니까? 아마도 현재로서는(적어도 DevOps 구현 방법이 보다 보편화될 때까지) 유일한 현실적인 대답은 인터뷰 중에 필요한 모든 것을 물어보고 채용될 역할 기대치와 조직적 맥락을 명확히 하는 것입니다.

채용 담당자의 경우 다양한 이유로 폭넓은 네트워크를 구축하고 채용 공고를 인기 키워드로 채우기로 결정할 수 있습니다. 그러나 궁극적으로 후보자의 경험과 능력에 대한 세부 사항은 인터뷰 과정과 참고인과의 대화 중에 나타나야 합니다.

제 생각에는 DevOps, 플랫폼 엔지니어, 클라우드 엔지니어, SRE 등 개발자의 운영 요구 사항을 모두 지원하면 개발자가 최고의 차세대 제품을 만드는 데 집중하는 데 도움이 될 것입니다.

위 내용은 DevOps, SRE, 플랫폼 엔지니어, 클라우드 역할 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!