DevOps 및 SRE에 대해 다시 한 번

채팅 토론을 기반으로 함 AWS 민스크 커뮤니티

최근 DevOps와 SRE의 정의를 둘러싸고 실제 전투가 벌어졌습니다.
나를 포함하여 이 주제에 대한 여러 가지 논의가 이미 나를 초조하게 만들었다는 사실에도 불구하고 나는 이 주제에 대한 나의 견해를 Habra 커뮤니티 법원에 제출하기로 결정했습니다. 관심있는 분들은 고양이에 오신 것을 환영합니다. 그리고 모든 것이 새로 시작되게 하세요!

선사 시대

그래서 고대에는 소프트웨어 개발자와 서버 관리자로 구성된 팀이 따로 살았습니다. 첫 번째는 코드를 성공적으로 작성했고, 두 번째는 첫 번째에게 전달된 따뜻하고 애정 어린 단어를 사용하여 서버를 설정하고 정기적으로 개발자에게 와서 포괄적인 "모든 것이 내 컴퓨터에서 작동합니다"라는 응답을 받았습니다. 비즈니스는 소프트웨어를 기다리고 있었고 모든 것이 유휴 상태였으며 주기적으로 중단되었으며 모두가 긴장했습니다. 특히 이 모든 혼란에 대한 비용을 지불한 사람. 영광스러운 램프 시대. 글쎄요, 여러분은 DevOps가 어디서 왔는지 이미 알고 계십니다.

DevOps 관행의 탄생

그런 다음 진지한 사람들이 와서 말했습니다. 이것은 산업이 아니기 때문에 그렇게 일할 수 없습니다. 그리고 그들은 수명주기 모델을 도입했습니다. 예를 들어 V 모델이 있습니다.

그래서 우리는 무엇을 봅니까? 비즈니스에는 개념이 있고, 솔루션을 설계하고, 개발자가 코드를 작성하면 실패합니다. 누군가는 어떻게든 제품을 테스트하고, 누군가는 최종 사용자에게 제품을 전달하며, 이 기적 모델의 결과물 어딘가에는 바닷가에서 약속된 날씨를 기다리는 외로운 비즈니스 고객이 앉아 있습니다. 우리는 이 프로세스를 확립할 수 있는 방법이 필요하다는 결론에 도달했습니다. 그리고 우리는 이를 구현할 수 있는 관행을 만들기로 결정했습니다.

실천이 무엇인지에 대한 서정적 여담
실천이란 기술과 규율의 결합을 의미합니다. 예를 들어 Terraform 코드를 사용하여 인프라를 설명하는 관행이 있습니다. 규율은 코드로 인프라를 설명하는 방법이며 개발자의 머리에 있으며 기술은 테라폼 자체입니다.

그리고 그들은 이를 DevOps 관행이라고 부르기로 결정했습니다. 제 생각에는 개발부터 운영까지를 의미하는 것 같습니다. 우리는 CI/CD 방식, IaC 원칙에 기반한 방식 등 수천 가지의 기발한 아이디어를 생각해 냈습니다. 그리고 나서 개발자는 코드를 작성하고 DevOps 엔지니어는 시스템 설명을 코드 형태로 작업 시스템으로 변환합니다(예, 코드는 안타깝게도 단지 설명일 뿐 시스템의 구현은 아닙니다). 전달은 계속됩니다. 등등. 어제의 관리자들은 새로운 방식을 숙지하고 자랑스럽게 DevOps 엔지니어로 재교육을 받았으며 모든 것이 거기에서 시작되었습니다. 그리고 저녁이 되고 아침이 되니... 죄송합니다. 거기부터는 아닙니다.

또 다 좋지는 않네요, 하느님 감사합니다

모든 것이 진정되고 다양한 교활한 "방법론자"가 DevOps 관행에 대한 두꺼운 책을 쓰기 시작하자마자 악명 높은 DevOps 엔지니어가 누구인지, DevOps가 생산 문화라는 점에 대한 논쟁이 조용히 불붙었고 불만이 다시 발생했습니다. 갑자기 소프트웨어 제공이 결코 사소한 작업이 아니라는 것이 밝혀졌습니다. 각 개발 인프라에는 자체 스택이 있으며, 이를 조립해야 하는 곳, 환경을 배포해야 하는 곳, 여기에서는 Tomcat이 필요하고, 여기에는 교활하고 복잡한 실행 방법이 필요합니다. 일반적으로 머리가 쿵쿵거립니다. 그리고 이상하게도 문제는 주로 프로세스 구성에 있는 것으로 밝혀졌습니다. 병목 현상과 같은 이 전달 기능은 프로세스를 차단하기 시작했습니다. 또한 누구도 작업을 취소하지 않았습니다. V 모델에서는 보이지 않지만 오른쪽에는 여전히 전체 수명주기가 있습니다. 따라서 어떻게든 인프라를 유지하고, 모니터링을 모니터링하고, 사고를 해결하고, 배송도 처리해야 합니다. 저것들. 개발과 운영 모두에 한 발을 딛고 있었는데 갑자기 개발 및 운영으로 밝혀졌습니다. 그리고 마이크로서비스에 대한 일반적인 과대광고가 있었습니다. 그리고 그들과 함께 로컬 시스템의 개발이 클라우드로 이동하기 시작했습니다. 로컬에서 무언가를 디버깅하려고 시도하면 수십, 수백 개의 마이크로 서비스가 있는 경우 지속적인 제공이 생존 수단이 됩니다. '소규모 회사'로서는 괜찮았는데, 그래도? Google은 어떻습니까?

Google의 SRE

Google이 와서 가장 큰 선인장을 먹고 결정했습니다. 우리에게는 이것이 필요하지 않고 신뢰성이 필요합니다. 그리고 신뢰성도 관리되어야 합니다. 그리고 신뢰성을 관리해줄 전문가가 필요하다고 판단했습니다. SR엔지니어들에게 전화해서 '그만하면 됐어, 평소대로 잘 해라'고 했어요. 여기는 SLI, 여기는 SLO, 모니터링은 여기입니다. 그리고 그는 수술에 코를 찔렀습니다. 그리고 그는 "신뢰할 수 있는 DevOps" SRE라고 불렀습니다. 모든 것이 괜찮은 것 같지만 Google이 감당할 수 있는 한 가지 더러운 해킹이 있습니다. SR 엔지니어의 위치에는 자격을 갖춘 개발자인 사람을 고용하고 약간의 숙제를 하고 작업 시스템의 기능을 이해하는 것입니다. 더욱이 Google 자체는 그러한 사람들을 고용하는 데 문제가 있습니다. 주로 여기에서 자체적으로 경쟁하기 때문에 비즈니스 논리를 누군가에게 설명해야합니다. 릴리스 엔지니어인 SR에게 전달이 할당되었습니다. 엔지니어는 안정성을 관리합니다(물론 직접적으로는 아니지만 인프라에 영향을 주고, 아키텍처를 변경하고, 변경 사항 및 지표를 추적하고, 사고를 처리함으로써). 좋아요, 그럴 수 있어요 책을 쓰다. 하지만 만약 당신이 Google이 아니지만 신뢰성이 여전히 문제가 된다면 어떻게 될까요?

DevOps 아이디어 개발

바로 그때 lxc에서 성장한 Docker가 등장했고 Docker Swarm 및 Kubernetes와 같은 다양한 오케스트레이션 시스템과 DevOps 엔지니어가 한숨을 쉬었습니다. 관행의 통합으로 전달이 단순화되었습니다. 개발자에게 전달을 아웃소싱하는 것도 가능해질 정도로 단순화되었습니다. 이것이 바로 development.yaml입니다. 컨테이너화는 문제를 해결합니다. 그리고 CI/CD 시스템의 성숙도는 이미 하나의 파일을 작성하는 수준에 이르렀으며 개발자가 직접 처리할 수 있습니다. 그런 다음 우리는 적어도 누군가와 함께 우리 자신의 SRE를 만들 수 있는 방법에 대해 이야기하기 시작합니다.

SRE가 Google에 없습니다.

글쎄요, 우리는 배달을 했습니다. 숨을 내쉴 수 ​​있는 것 같습니다. 관리자가 프로세서 로드를 보고, 시스템을 조정하고, 머그잔에서 이해할 수 없는 것을 평화롭고 조용하게 마셨던 옛날로 돌아갈 수 있는 것 같습니다... 중지하세요. 이것이 우리가 모든 일을 시작한 이유가 아닙니다(안타깝습니다!). 갑자기 Google의 접근 방식을 통해 우수한 사례를 쉽게 채택할 수 있다는 사실이 밝혀졌습니다. 중요한 것은 프로세서 로드도 아니고 디스크를 얼마나 자주 변경하거나 클라우드에서 비용을 최적화하는지도 아니지만 비즈니스 지표는 똑같이 악명 높습니다. SLx. 그리고 누구도 인프라 관리를 제거하지 않았으며 사고를 해결하고 주기적으로 임무를 수행하며 일반적으로 비즈니스 프로세스를 파악해야 합니다. 그리고 여러분, 좋은 수준에서 조금씩 프로그래밍을 시작하세요. Google은 이미 여러분을 기다리고 있습니다.

요약. 갑자기, 그러나 당신은 이미 읽기에 지쳤고 기사에 대한 댓글로 저자에게 침을 뱉고 글을 쓰는 것을 기다릴 수 없습니다. 제공 방식으로서의 DevOps는 항상 그래왔고 앞으로도 그럴 것입니다. 그리고 그것은 아무데도 가지 않을 것입니다. 일련의 운영 관행인 SRE는 이러한 전달을 매우 성공적으로 만듭니다.

출처 : habr.com