데브옵스란?

DevOps의 정의는 매우 복잡하므로 매번 다시 논의를 시작해야 합니다. Habré에만 이 주제에 관한 출판물이 수천 권 있습니다. 하지만 이 글을 읽고 계시다면 아마도 DevOps가 무엇인지 아실 것입니다. 왜냐하면 나는 그렇지 않기 때문이다. 안녕 내 이름은 알렉산더 티토프(@오스미노그) 그리고 DevOps에 대해 이야기하고 제 경험을 공유하겠습니다.

나는 내 이야기를 어떻게 유용하게 만들 수 있을지 오랫동안 고민해왔기 때문에 여기에는 내가 스스로에게 묻는 질문과 우리 회사의 고객에게 묻는 질문 등 많은 질문이 있을 것입니다. 이러한 질문에 답하면 이해가 더 좋아집니다. 내 관점에서는 왜 DevOps가 필요한지, 그것이 무엇인지 다시 내 관점에서, 그리고 내 관점에서는 DevOps로 다시 전환하고 있다는 것을 어떻게 이해할 수 있는지 알려드리겠습니다. 마지막 포인트는 질문을 통해서 보도록 하겠습니다. 직접 답변해 보면 회사가 DevOps로 전환하고 있는지, 어떤 면에서 문제가 있는지 이해할 수 있습니다.

한때 저는 인수합병의 물결을 타고 있었습니다. 처음에 저는 Qik이라는 작은 스타트업에서 일했고, 그 후 조금 더 큰 Skype라는 회사에 인수되었고, 그 다음에는 조금 더 큰 Microsoft라는 회사에 인수되었습니다. 그 순간, 저는 DevOps의 아이디어가 다양한 규모의 회사에서 어떻게 변화하고 있는지 알아보기 시작했습니다. 그 후 DevOps를 시장의 관점에서 바라보는 것에 관심을 갖게 되었고, 동료들과 함께 Express 42라는 회사를 설립하게 되었습니다. 현재 6년 동안 우리는 시장의 흐름을 따라 움직이고 있습니다.

무엇보다도 저는 DevOps Moscow 커뮤니티의 주최자 중 한 명이자 DevOps-Days 2017의 주최자이지만 2018년을 조직하지는 않았습니다. Express 42는 많은 회사와 협력하고 있습니다. 우리는 그곳에서 DevOps를 성장시키고, 그것이 어떻게 일어나는지 관찰하고, 결론을 도출하고, 분석하고, 모든 사람에게 우리의 결론을 알리고, DevOps 관행에 대해 사람들을 교육합니다. 일반적으로 우리는 이와 관련하여 경험과 전문성을 높이기 위해 최선을 다하고 있습니다.

DevOps를 사용해야 하는 이유

모든 사람을 괴롭히는 첫 번째 질문은 항상 – 왜? 많은 사람들은 DevOps가 단지 자동화이거나 모든 회사가 이미 갖고 있는 유사한 것이라고 생각합니다.

— 지속적인 통합이 있었습니다. 이는 이미 DevOps가 있다는 의미이며, 이 모든 기능이 필요한 이유는 무엇입니까? 그들은 해외에서 즐거운 시간을 보내고 있지만 우리가 일하는 것을 방해하고 있습니다!

9년에 걸쳐 커뮤니티와 방법론을 개발한 결과, 이것이 여전히 마케팅 글리터가 아니라는 것이 이미 분명해졌지만, 이것이 왜 필요한지는 아직 완전히 명확하지 않습니다. 다른 도구 및 프로세스와 마찬가지로 DevOps에는 궁극적으로 달성할 구체적인 목표가 있습니다.

이 모든 것은 세상이 변하고 있기 때문입니다. 그는 상트페테르부르크의 고전이 노래했듯이 특정 전략에 따라 A지점에서 B지점으로 회사가 꿈을 향해 직진할 때 기업 접근 방식에서 벗어나 이를 위해 구축된 특정 구조를 사용합니다.

원칙적으로 IT의 모든 것은 이 접근 방식에 따라 구축되어야 합니다. 여기서 IT는 프로세스 자동화에만 사용됩니다.

자동화는 자주 바뀌지 않습니다. 회사가 굳건한 틀에 박혀 있을 때 무엇을 바꿔야 할까요? 작동합니다. 만지지 마세요. 이제 세상의 접근 방식은 변화하고 있으며 Agile이라는 접근 방식은 끝점 B가 즉시 표시되지 않는다고 제안합니다.

회사가 시장을 통과하고 고객과 협력할 때 끊임없이 시장을 탐색하고 종점 B를 변경합니다. 더욱이 회사가 방향을 자주 바꿀수록 더 많은 시장을 선택하기 때문에 결국 성공할 수 있습니다. 틈새.

이 전략은 제가 최근에 알게 된 흥미로운 회사를 통해 입증되었습니다. 원박스쉐이브(One Box Shave)는 면도기와 면도용품을 한 박스에 담아 배송해주는 구독형 배송 서비스입니다. 그들은 다양한 클라이언트에 맞게 "상자"를 사용자 정의하는 방법을 알고 있습니다. 이는 특정 소프트웨어에 의해 수행되며, 제품을 생산하는 한국 공장에 주문을 보냅니다.

이 제품은 Unilever가 1억 달러에 구입했습니다. 이제 질레트와 경쟁하며 미국 시장에서 상당한 소비자 점유율을 빼앗아갔습니다. One Box 면도기 내용:

— 블레이드가 4개요? 진심인가요? 이것이 필요한 이유는 무엇입니까? 면도 품질이 향상되지는 않습니다. 특별히 엄선된 크림, 향수, 그리고 4개의 날이 있는 고품질 면도기는 그 어리석은 10개의 질레트 날보다 훨씬 더 많은 문제를 해결합니다! 이제 곧 XNUMX이 될까요?

세상은 이렇게 변합니다. Unilever는 이를 가능하게 하는 멋진 IT 시스템을 보유하고 있다고 주장합니다. 결국 컨셉인거같아 출시 시간, 아직 아무도 이야기하지 않은 것입니다.

출시 기간의 핵심은 배포 빈도가 아닙니다. 자주 배포할 수 있지만 릴리스 주기가 길어집니다. 3개월의 릴리스 주기를 서로 겹쳐서 일주일 단위로 이동시키면 회사는 일주일에 한 번 배포하는 것으로 나타났습니다. 그리고 아이디어 구상부터 최종 구현까지 XNUMX개월이 소요됩니다.

출시 기간은 아이디어부터 최종 구현까지의 시간을 최소화하는 것입니다.

이 경우 소프트웨어는 시장과 상호 작용합니다. 이것이 One Box Shave 웹사이트가 클라이언트와 상호 작용하는 방식입니다. 영업사원도 없고 방문자가 클릭하고 소원을 남기는 웹사이트만 있을 뿐입니다. 따라서 새로운 내용이 지속적으로 사이트에 게시되고 원하는 대로 업데이트되어야 합니다. 예를 들어 한국에서는 러시아와 다르게 면도하고 소나무 향이 아닌 당근과 바닐라 향을 좋아합니다.

사이트의 내용을 빠르게 변경해야 하기 때문에 소프트웨어 개발도 크게 변화합니다. 소프트웨어를 통해 고객이 원하는 것이 무엇인지 알아내야 합니다. 이전에는 비즈니스 관리와 같은 몇 가지 우회 방법을 통해 이를 배웠습니다. 그런 다음 이를 설계하고 IT 시스템에 요구 사항을 적용했는데 모든 것이 멋졌습니다. 이제는 다릅니다. 엔지니어를 포함하여 프로세스에 관련된 모든 사람이 소프트웨어를 설계합니다. 기술 사양을 통해 시장이 어떻게 작동하는지 배우고 통찰력을 비즈니스와 공유하기 때문입니다.

예를 들어, Qik에서는 사람들이 서버에 연락처 목록을 업로드하는 것을 정말 좋아한다는 사실을 갑자기 알게 되었고, 그들은 우리에게 애플리케이션을 제공했습니다. 처음에 우리는 그것에 대해 생각하지 않았습니다. 전통적인 회사에서는 모든 사람들이 이것이 버그라고 판단했을 것입니다. 사양에서는 그것이 훌륭하게 작동해야 한다고 말하지 않고 일반적으로 무릎에 구현되었기 때문에 기능을 끄고 다음과 같이 말했을 것입니다. 가장 중요한 것은 주요 기능이 작동한다는 것입니다.” . 그리고 기술회사는 이를 기회로 보고 이에 맞춰 소프트웨어를 바꾸기 시작합니다.

1968년에 선구적인 사람인 멜빈 콘웨이(Melvin Conway)는 다음과 같은 아이디어를 공식화했습니다.

시스템을 만드는 조직은 해당 조직의 커뮤니케이션 구조를 복제하는 설계의 제약을 받습니다.

더 자세히 말하면, 다른 유형의 시스템을 만들기 위해서는 다른 유형의 회사 내에서도 소통 구조를 갖춰야 합니다. 귀하의 의사소통 구조가 최상위 계층적이라면 이는 매우 높은 시장 출시 시간 지표를 제공할 수 있는 시스템을 생성하는 것을 허용하지 않습니다.

읽다 콘웨이의 법칙에 대해 하나는 수 링크를 통해. DevOps 문화나 철학을 이해하는 것이 중요합니다. DevOps에서 근본적으로 바뀌는 유일한 것은 팀 간의 커뮤니케이션 구조입니다..

프로세스 관점에서 DevOps 이전에는 분석, 개발, 테스트, 운영 등 모든 단계가 선형이었습니다.
DevOps의 경우 이러한 모든 프로세스가 동시에 발생합니다.

시장 출시 기간이 이를 수행할 수 있는 유일한 방법입니다. 이전 프로세스에서 작업한 사람들에게는 이것이 다소 우주적이고 일반적으로 그렇습니다.

그렇다면 왜 DevOps가 필요한가요?

디지털 제품 개발을 위한. 회사에 디지털 제품이 없다면 DevOps는 필요하지 않습니다. 이는 매우 중요합니다.

DevOps는 순차적 소프트웨어 생산의 속도 제한을 극복합니다.. 그 안에서 모든 프로세스가 동시에 발생합니다.

난이도가 증가합니다. DevOps 전도사들이 이를 통해 소프트웨어 출시가 더 쉬워질 것이라고 말하는 것은 말도 안되는 소리입니다.

DevOps를 사용하면 상황이 더욱 복잡해집니다.

Avito 스탠드에서 열린 컨퍼런스에서는 비현실적인 작업인 Docker 컨테이너를 배포하는 것이 어떤 것인지 확인할 수 있었습니다. 복잡성이 엄청나므로 동시에 많은 공을 저글링해야 합니다.

DevOps는 회사의 프로세스와 조직을 완전히 변화시킵니다. — 더 정확하게 말하면 변화하는 것은 DevOps가 아니라 디지털 제품입니다. DevOps에 참여하려면 이 프로세스를 완전히 변경해야 합니다.

전문가를 위한 질문

당신은 무엇을 가지고 있습니까? 회사에서 일하면서 전문가로 성장하면서 스스로에게 물어볼 수 있는 질문들입니다.

디지털 제품을 만들기 위한 전략이 있나요? 만약 있다면 그것은 이미 좋은 것입니다. 이는 귀하의 회사가 DevOps로 전환하고 있음을 의미합니다.

귀하의 회사는 이미 디지털 제품을 만들고 있습니까? 이는 DevOps 관점에서 한 단계 더 높은 수준으로 올라가서 더 흥미롭게 작업을 수행할 수 있음을 의미합니다. 나는 단지 이런 관점에서 말하는 것이다.

귀하의 회사는 디지털 제품 틈새시장의 시장 리더 중 하나입니까? Spotify, Yandex, Uber는 현재 기술 발전의 정점에 있는 회사입니다.

스스로에게 이러한 질문을 던져 보세요. 모든 대답이 '아니오'라면 이 회사에서 DevOps를 수행해서는 안 됩니다. DevOps라는 주제가 정말 흥미롭다면 아마도... 다른 회사로 옮겨야 할까요? 귀하의 회사가 DevOps를 진행하고 싶지만 모든 질문에 "아니요"라고 대답했다면 이는 결코 변하지 않는 아름다운 코뿔소와 같습니다.

조직

앞서 말했듯이 콘웨이의 법칙에 따르면 회사의 조직은 변화합니다. 조직의 관점에서 DevOps가 회사 내부로 침투하는 것을 방지하는 것부터 시작하겠습니다.

"우물"의 문제

영어 단어 "Silo"는 여기서 러시아어로 "well"로 번역됩니다. 이 문제의 요점은 팀 간 정보 교환이 없습니다.. 각 팀은 탐색할 공통 지도를 구축하지 않고도 전문 지식을 깊이 파고듭니다.

어떤 면에서 이것은 모스크바에 막 도착했지만 아직 지하철 지도를 탐색하는 방법을 모르는 사람을 생각나게 합니다. Muscovites는 일반적으로 자신의 지역을 매우 잘 알고 있으며 모스크바 전역에서 지하철 지도를 사용하여 탐색할 수 있습니다. 모스크바에 처음 오시면 이런 기술도 없고 방향 감각을 잃으실 뿐입니다.

DevOps는 방향 감각 상실의 순간을 극복하고 모든 부서가 협력하여 공통 상호 작용 맵을 구축할 것을 제안합니다.

두 가지 요인이 이를 방해합니다.

기업 경영 시스템의 결과. 이는 별도의 계층적 "우물"에 구축됩니다. 예를 들어, 이 시스템을 지원하는 회사에는 특정 KPI가 있습니다. 반면, 자신의 전문 지식의 한계를 넘어서 전체 시스템을 탐색하는 데 어려움을 겪는 사람의 두뇌는 방해가 됩니다. 불편할 뿐입니다. 당신이 방콕 공항에 있다고 상상해 보세요. 빨리 길을 찾을 수 없을 것입니다. DevOps는 탐색하기도 어렵기 때문에 사람들은 거기에 도달하려면 가이드를 찾아야 한다고 말합니다.

그러나 가장 중요한 것은 DevOps 정신에 물들고 Fowler와 다른 많은 책을 읽은 엔지니어의 "우물"문제가 다음과 같은 사실로 표현된다는 것입니다. "우물"은 "명백한" 일을 하는 것을 허용하지 않습니다. 우리는 DevOps Moscow 이후에 자주 모여서 서로 이야기를 나누고 사람들은 다음과 같이 불평합니다.

— 우리는 단지 CI를 출시하고 싶었지만 경영진에서는 CI가 필요하지 않은 것으로 나타났습니다.

이런 일이 일어나는 이유는 바로 CI и 지속적인 전달 프로세스 많은 시험의 경계에 있습니다. 단순히 조직 차원의 '우물' 문제를 극복하지 않고서는 무슨 일을 해도, 아무리 서운해도 앞으로 나아갈 수 없습니다.

회사 내 프로세스의 각 참여자: 백엔드 및 프론트엔드 개발자, 테스트, DBA, 운영, 네트워크는 각자의 방향으로 파고들고, 관리자 외에는 누구도 공통 지도를 갖고 있지 않습니다. 관리자는 어떻게든 이들을 "분할"을 사용하여 모니터링하고 관리합니다. 그리고 정복” 방법.

사람들은 별이나 깃발을 위해 싸우고 있으며 모두가 자신의 전문 지식을 파고 있습니다.

결과적으로 이 모든 것을 함께 연결하고 공통 파이프라인을 구축하는 작업이 발생하고 더 이상 별과 깃발을 위해 싸울 필요가 없으면 질문이 생깁니다. 어쨌든 무엇을 해야 할까요? 우리는 어떻게든 합의에 도달해야 하는데, 학교에서는 누구도 그렇게 하는 방법을 가르쳐주지 않았습니다. 우리는 학교 때부터 배웠습니다: XNUMX학년 - 와! - XNUMX학년과 비교! 여기도 마찬가지입니다.

당신의 회사에서도 마찬가지인가요?

이를 확인하려면 다음 질문을 스스로에게 물어볼 수 있습니다.

팀은 공통 도구를 사용하고 이러한 공통 도구의 변경에 기여합니까?

팀은 얼마나 자주 재편성됩니까? 한 팀의 일부 전문가가 다른 팀으로 이동합니까? DevOps 환경에서는 이것이 정상이 됩니다. 왜냐하면 때로는 사람이 다른 전문 분야가 수행하는 작업을 단순히 이해할 수 없기 때문입니다. 그는 다른 부서로 이동하여 그곳에서 XNUMX주 동안 일하면서 이 부서와의 상호 작용 및 방향 지도를 스스로 작성했습니다.

변화위원회를 구성해서 변화를 주는 것이 가능합니까? 아니면 최고 경영진의 강력한 손길과 방향이 필요한가? 나는 최근에 잘 알려지지 않은 한 은행이 주문을 통해 도구를 구현하는 방법을 Facebook에 썼습니다. 우리는 주문을 작성하고 XNUMX년 동안 이를 구현한 다음 무슨 일이 일어나는지 확인합니다. 물론 이것은 길고 슬픈 일입니다.

관리자가 회사의 성과를 고려하지 않고 개인의 성과를 받는 것이 얼마나 중요합니까?

이러한 질문에 스스로 답해 보면 회사에 그러한 문제가 있는지가 더 분명해질 것입니다.

코드형 인프라

이 문제가 통과된 후 DevOps에서 더 발전하기 어려운 첫 번째 중요한 관행은 다음과 같습니다. 코드로서의 인프라.

대부분의 경우 코드형 인프라는 다음과 같이 인식됩니다.

— bash의 모든 것을 자동화하고 관리자가 수동 작업을 덜도록 스크립트로 스스로를 보호합시다!

그러나 그것은 사실이 아닙니다.

코드형 인프라란 작업하는 IT 시스템의 상태를 지속적으로 이해하기 위해 코드 형태로 설명하는 것을 의미합니다.

다른 팀과 함께 모든 사람이 이해할 수 있고 탐색하고 탐색할 수 있는 코드 형태의 지도를 만듭니다. Chef, Ansible, Salt 또는 Kubernetes에서 YAML 파일을 사용하는 등 무엇을 했는지는 중요하지 않습니다. 차이가 없습니다.

컨퍼런스에서 2GIS의 동료는 개별 시스템의 구조를 설명하는 Kubernetes용 내부 항목을 어떻게 만들었는지 설명했습니다. 500개의 시스템을 설명하려면 이 설명을 생성하는 별도의 도구가 필요했습니다. 이 설명이 있으면 모든 사람이 서로 확인하고, 변경 사항을 모니터링하고, 변경 방법과 개선 방법, 누락된 사항을 확인할 수 있습니다.

개별 bash 스크립트는 일반적으로 이러한 이해를 제공하지 않습니다. 제가 일했던 회사 중 한 곳에서는 스크립트를 작성할 때 "쓰기 전용" 스크립트라는 이름도 있었지만 더 이상 읽을 수 없습니다. 나는 이것이 당신에게도 친숙하다고 생각합니다.

코드로서의 인프라 인프라의 현재 상태를 설명하는 코드. 많은 제품, 인프라 및 서비스 팀이 이 코드를 위해 함께 작업하며 가장 중요한 것은 이 코드가 실제로 어떻게 작동하는지 모두 이해해야 한다는 것입니다.

코드는 모범적인 코드 관행에 따라 유지됩니다.: 공동 개발, 코드 검토, XP 프로그래밍, 테스트, 풀 요청, 코드 인프라용 CI - 이 모든 것이 적합하고 사용될 수 있습니다.

코드는 모든 엔지니어의 공통 언어가 됩니다.

코드에서 인프라를 변경하는 데 시간이 많이 걸리지 않습니다.. 예, 인프라 코드에도 기술적 부채가 있을 수 있습니다. 일반적으로 팀은 스파게티 코드처럼 작성하고 bash 스크립트를 혼합하는 스크립트 묶음 또는 Ansible 형태로 "코드로서의 인프라"를 구현하기 시작한 지 XNUMX년 반 후에 이 문제에 직면합니다!

중요한 일이야: 아직 이 제품을 사용해보지 않으셨다면 꼭 기억해두세요 Ansible은 bash가 아닙니다.! 문서를 주의 깊게 읽고 그들이 작성한 내용을 연구하십시오.

코드형 인프라는 인프라 코드를 별도의 계층으로 분리하는 것입니다.

우리 회사에서는 매우 명확하고 단순한 3개의 기본 레이어를 구분하지만 그 수가 더 많을 수도 있습니다. 인프라 코드를 보고 이 조건이 있는지 여부를 알 수 있습니다. 강조 표시된 레이어가 없으면 시간을 들여 약간의 리팩터링을 수행해야 합니다.


기본 레이어 - 이는 OS, 백업 및 기타 하위 수준이 구성되는 방식입니다(예: Kubernetes가 기본 수준에서 배포되는 방식).

서비스 수준 - 개발자에게 제공하는 서비스는 다음과 같습니다. 서비스로 로깅, 서비스로 모니터링, 서비스로 데이터베이스, 서비스로 밸런서, 서비스로 큐, 서비스로 지속적 전달 - 개별 팀이 제공하는 여러 서비스 개발에 제공할 수 있습니다. 이 모든 내용은 구성 관리 시스템의 별도 모듈에서 설명되어야 합니다.

애플리케이션이 만들어지는 계층 이전 두 레이어 위에 어떻게 펼쳐지는지 설명합니다.

통제 질문

귀사에는 공통 인프라 저장소가 있습니까? 인프라의 기술 부채를 관리하고 있습니까? 인프라 저장소에서 개발 방식을 사용합니까? 귀하의 인프라가 여러 레이어로 분할되어 있습니까? Base-service-APP 다이어그램을 확인할 수 있습니다. 변화를 주는 것이 얼마나 어려운가요?

변경하는 데 하루 반이 걸렸다면 이는 기술적인 부채가 있어 이를 해결해야 함을 의미합니다. 방금 인프라 코드에서 기술적 부채 레이크를 발견했습니다. 일부 CCTL을 변경하려면 인프라 코드의 절반을 다시 작성해야 했던 그런 이야기를 많이 기억합니다. 창의성과 모든 것을 자동화하려는 욕구로 인해 모든 것이 모든 곳에서 부식되고 모든 핸들이 제거되었다는 사실로 이어졌기 때문입니다. 리팩터링이 필요합니다.

지속적인 전달

차변과 신용을 비교해 보겠습니다. 먼저 매우 기본적인 인프라에 대한 설명이 나옵니다. 모든 것을 자세히 설명할 필요는 없지만 작업을 수행하려면 몇 가지 기본적인 설명이 필요합니다. 그렇지 않으면 다음에 지속적 전달로 무엇을 해야 할지 명확하지 않습니다. DevOps에 오면 이러한 모든 사례가 동시에 전개되지만, 이는 보유하고 있는 항목과 이를 관리하는 방법을 이해하는 것부터 시작됩니다. 이것이 바로 코드로서의 인프라(Infrastructure as Code)의 실천입니다.

보유하고 있는 코드와 이를 관리하는 방법이 명확해지면 개발자 코드를 프로덕션 환경으로 최대한 빨리 보내는 방법을 파악하기 시작합니다. 내 말은 개발자와 함께 - 우리는 "우물"의 문제를 기억합니다. 즉, 이것을 생각해내는 것은 개인이 아니라 팀입니다.

우리가 함께 있을 때 반야 ​​에브투코비치 첫 번째 책을 보았다 제즈 험블 그리고 작가 그룹 "지속적인 배송"2009년에 발매된 , 우리는 제목을 러시아어로 번역하는 방법에 대해 오랫동안 고민했습니다. “지속적으로 전달하다”로 번역하고 싶었는데, 아쉽게도 “지속적인 전달”로 번역되었습니다. 우리 이름에는 압력과 함께 러시아인이있는 것 같습니다.

지속적으로 수단을 제공

제품 저장소에 있는 코드는 언제든지 프로덕션 환경으로 다운로드할 수 있습니다.. 그는 위축되지 않을 수도 있지만 항상 그럴 준비가 되어 있습니다. 그래서 늘 설명하기 힘든 불안감을 안고 코드를 작성하게 됩니다. 인프라 코드를 출시할 때 자주 나타납니다. 약간의 불안감이 존재해야 합니다. 이는 코드를 약간 다르게 작성할 수 있는 두뇌 프로세스를 촉발합니다. 이는 개발 내의 규칙에 기록되어야 합니다.

일관되게 제공하려면 인프라 플랫폼 전체에서 실행되는 아티팩트 형식이 필요합니다. 인프라 플랫폼 전반에 걸쳐 다양한 형식의 '생활 낭비'를 하게 되면 통합되어 유지 관리가 어려워지고 기술 부채 문제가 발생합니다. 유물의 형식을 조정해야 합니다. 이것은 또한 공동 작업이기도 합니다. 우리 모두가 함께 모여 두뇌를 바스락거리고 이 형식을 생각해 내야 합니다.

아티팩트는 딜리버리 파이프라인을 통해 이동하면서 프로덕션 환경에 맞게 지속적으로 개선되고 변경됩니다. 아티팩트가 파이프라인을 따라 이동할 때 프로덕션에 넣은 아티팩트가 직면하는 것과 유사한 몇 가지 불편한 문제에 지속적으로 직면합니다. 기존 개발에서 롤아웃을 수행하는 시스템 관리자가 이 작업을 수행했다면 DevOps 프로세스에서는 항상 이런 일이 발생합니다. 여기에서는 몇 가지 테스트를 통해 테스트했고, 여기에서는 거의 비슷한 Kubernetes 클러스터에 던졌습니다. 프로덕션으로 전환한 후 갑자기 로드 테스트를 시작했습니다.

이것은 팩맨 게임을 다소 연상시킵니다. 유물은 일종의 이야기를 겪습니다. 동시에, 코드가 실제로 스토리를 통과하는지, 그리고 그것이 어떻게든 제작과 관련이 있는지를 제어하는 ​​것이 중요합니다. 프로덕션의 스토리를 Continuous Delivery 프로세스로 끌어올 수 있습니다. 무언가가 떨어졌을 때 이랬습니다. 이제 이 시나리오를 시스템 내부에 프로그래밍해 보겠습니다. 코드가 이 시나리오를 거칠 때마다 다음 번에는 이 문제가 발생하지 않습니다. 귀하는 귀하의 고객에게 도달하기 훨씬 전에 이에 대해 알게 될 것입니다.

다양한 배포 전략. 예를 들어 AB 테스트 또는 카나리아 배포를 사용하여 다양한 클라이언트에서 코드를 다르게 테스트하고, 코드 작동 방식에 대한 정보를 얻고, 코드가 100억 명의 사용자에게 출시되기 훨씬 이전에 얻을 수 있습니다.

'일관되게 제공'은 다음과 같습니다.

전달 프로세스 Dev, CI, Test, PreProd, Prod는 별도의 환경이 아니며, 이는 아티팩트가 통과하는 내화 합계가 있는 단계 또는 스테이션입니다.

기본 서비스 앱으로 설명된 인프라 코드가 있으면 도움이 됩니다. 모든 스크립트를 잊지 마세요, 이 아티팩트의 코드로 기록해 둡니다. 유물 홍보 그리고 가면서 바꾸세요.

자기 점검을 위한 질문

95%의 경우 기능 설명부터 실제 제품 출시까지의 시간이 일주일 미만입니까? 파이프라인의 각 단계에서 아티팩트의 품질이 향상됩니까? 겪는 이야기가 있나요? 다양한 배포 전략을 사용합니까?

모든 대답이 '예'라면, 당신은 정말 멋진 사람입니다! 댓글에 답변을 적어주세요. 기쁠 것입니다.)

피드백

이것은 가장 어려운 수행입니다. DevOpsConf 컨퍼런스에서 Infobip의 동료가 이에 대해 이야기하면서 그의 말은 약간 혼란스러웠습니다. 왜냐하면 이는 모든 것을 모니터링해야 한다는 사실에 대해 실제로 매우 복잡한 관행이기 때문입니다!

예를 들어, 오래 전 제가 Qik에서 근무하면서 모든 것을 모니터링해야 한다는 것을 깨달았습니다. 우리는 이렇게 했고, 현재 Zabbix에는 150개의 항목이 있으며 지속적으로 모니터링됩니다. 기술 디렉터는 관자놀이를 손가락으로 비틀었습니다.

- 얘들아, 왜 불명확한 내용으로 서버를 강간하는 거야?

그런데 이것이 정말 멋진 전략임을 보여주는 사건이 발생했습니다.

서비스 중 하나가 지속적으로 충돌하기 시작했습니다. 처음에는 충돌이 발생하지 않았습니다. 흥미롭게도 코드는 비즈니스 기능이 거의 없는 기본 브로커였기 때문에 거기에 추가되지 않았습니다. 단순히 개별 서비스 간에 메시지를 보냈습니다. 4개월 동안 서비스가 바뀌지 않더니 갑자기 "세그먼트 오류" 오류로 인해 서비스가 중단되기 시작했습니다.

우리는 충격을 받아 Zabbix에서 차트를 열었고 일주일 반 전에 이 브로커가 사용하는 API 서비스의 요청 동작이 크게 변경된 것으로 나타났습니다. 다음으로 우리는 특정 유형의 메시지를 보내는 빈도가 변경되었음을 확인했습니다. 나중에 우리는 이것이 안드로이드 클라이언트라는 것을 알게 되었습니다. 우리는 물었다:

— 여러분, 일주일 반 전에 무슨 일이 있었나요?

이에 대한 응답으로 UI를 어떻게 재설계했는지에 대한 흥미로운 이야기를 들었습니다. HTTP 라이브러리를 변경했다고 즉시 말하는 사람은 거의 없습니다. Android 클라이언트의 경우 이는 화장실에서 비누를 바꾸는 것과 같으며 기억하지 못합니다. 그 결과, 40분 간의 대화 끝에 우리는 그들이 HTTP 라이브러리를 변경했으며 기본 타이밍도 변경되었음을 알게 되었습니다. 이로 인해 API 서버의 트래픽 동작이 변경되어 브로커 내에서 경쟁이 발생하고 충돌이 발생하는 상황이 발생했습니다.

심층 모니터링 없이는 일반적으로 이 항목을 여는 것이 불가능합니다.. 조직에 여전히 "우물" 문제가 있다면, 모두가 서로에게 돈을 던지는 문제는 수년 동안 지속될 수 있습니다. 문제 해결이 불가능하므로 서버를 다시 시작하면 됩니다. 보유한 모든 이벤트를 모니터링, 추적, 추적하고 모니터링을 테스트로 사용하면 코드를 작성하고 모니터링 방법을 코드 형태로 즉시 표시합니다(우리는 이미 코드형 인프라를 보유하고 있습니다). 손바닥에. 이렇게 복잡한 문제도 쉽게 추적할 수 있습니다.

프로덕션이 아닌 전달 프로세스의 각 단계에서 아티팩트에 어떤 일이 발생하는지에 대한 모든 정보를 수집합니다.

모니터링을 CI에 업로드하면 몇 가지 기본 사항이 이미 표시됩니다. 나중에 Test, PredProd 및 로드 테스트에서 확인할 수 있습니다. 지표, 통계뿐만 아니라 로그(애플리케이션 출시 방법, 이상 현상) 등 모든 단계에서 정보를 수집합니다. 모든 것을 수집합니다.

그렇지 않으면 알아내기가 어려울 것입니다. DevOps가 더 복잡하다고 이미 말씀드렸습니다. 이러한 복잡성에 대처하려면 일반적인 분석이 필요합니다..

자제를 위한 질문

모니터링 및 로깅이 귀하를 위한 개발 도구입니까? 코드를 작성할 때 당신을 포함한 개발자들은 코드를 모니터링하는 방법에 대해 생각합니까?

고객으로부터 문제에 대해 들었습니까? 모니터링과 로깅을 통해 클라이언트를 더 잘 이해하게 되었나요? 모니터링과 로깅을 통해 시스템을 더 잘 이해하고 있나요? 단순히 시스템의 추세가 커지는 것을 확인하고 앞으로 3주 안에 모든 것이 사라질 것임을 이해했기 때문에 시스템을 변경합니까?

이 세 가지 구성 요소가 있으면 회사에 어떤 종류의 인프라 플랫폼이 있는지 생각해 볼 수 있습니다.

인프라 플랫폼

요점은 모든 회사가 가지고 있는 서로 다른 도구 세트라는 것이 아닙니다.

인프라 플랫폼의 핵심은 모든 팀이 이러한 도구를 사용하고 함께 개발한다는 것입니다.

인프라 플랫폼의 개별 부분 개발을 담당하는 별도의 팀이 있다는 것은 분명합니다. 그러나 동시에 모든 엔지니어는 인프라 플랫폼의 개발, 성능 및 홍보에 대한 책임을 집니다. 내부 수준에서는 일반적인 도구가 됩니다..

모든 팀은 인프라 플랫폼을 개발하고 이를 자체 IDE처럼 신중하게 취급합니다.. IDE에서는 모든 것을 멋지고 빠르게 만들기 위해 다양한 플러그인을 설치하고 단축키를 구성합니다. Sublime, Atom 또는 Visual Studio Code를 열면 코드 오류가 쏟아져 나와 작업이 전혀 불가능하다는 것을 깨닫고 즉시 슬픔을 느끼고 IDE를 수정하기 위해 달려갑니다.

인프라 플랫폼을 동일한 방식으로 취급하십시오. 뭔가 문제가 있다는 것을 이해하고 스스로 고칠 수 없다면 요청을 남겨주세요. 간단한 것이 있으면 직접 편집하고 끌어오기 요청을 보내면 사람들이 그것을 고려하여 추가할 것입니다. 이는 개발자의 머리 속에 있는 엔지니어링 도구에 대한 약간 다른 접근 방식입니다.

인프라 플랫폼은 지속적인 품질 개선을 통해 개발에서 클라이언트로 아티팩트의 이전을 보장합니다.. IP는 프로덕션 코드에서 발생하는 일련의 스토리로 프로그래밍됩니다. 수년간의 개발 기간 동안 이러한 이야기가 많이 있으며 그중 일부는 독특하고 귀하에게만 관련되어 있으므로 Google에서 검색할 수 없습니다.

이 시점에서 인프라 플랫폼은 경쟁 우위가 됩니다., 경쟁사의 도구에는 없는 기능이 내장되어 있기 때문입니다. IP가 깊어질수록 출시 기간 측면에서 경쟁 우위가 커집니다. 여기에 표시됨 공급업체 잠금 문제: 다른 사람의 플랫폼을 사용할 수 있지만 다른 사람의 경험을 사용하면 그것이 자신과 얼마나 관련이 있는지 이해하지 못할 것입니다. 예, 모든 회사가 Amazon과 같은 플랫폼을 구축할 수 있는 것은 아닙니다. 이는 회사의 경험이 시장에서의 위치와 관련되어 있어 공급업체 잠금을 사용할 수 없는 어려운 선입니다. 이것 역시 생각해 보는 것이 중요합니다.

계획

이는 DevOps 회사의 모든 관행과 프로세스를 설정하는 데 도움이 되는 인프라 플랫폼의 기본 다이어그램입니다.

그것이 무엇으로 구성되어 있는지 살펴 보겠습니다.

자원 조정 시스템, 애플리케이션 및 기타 서비스에 CPU, 메모리, 디스크를 제공합니다. 이 위에 - 낮은 수준의 서비스: 모니터링, 로깅, CI/CD 엔진, 아티팩트 스토리지, 시스템 코드로서의 인프라.

더 높은 수준의 서비스: 서비스로서의 데이터베이스, 서비스로서의 큐, 서비스로서의 로드 밸런스, 서비스로서의 이미지 크기 조정, 서비스로서의 빅데이터 팩토리. 이 위에 - 지속적으로 수정되는 코드를 클라이언트에 전달하는 파이프라인.

귀하는 귀하의 소프트웨어가 클라이언트에서 어떻게 작동하는지에 대한 정보를 받고 이를 변경하고 이 코드를 다시 제공하고 정보를 수신하므로 인프라 플랫폼과 소프트웨어를 지속적으로 개발합니다.

다이어그램에서 전달 파이프라인은 여러 단계로 구성됩니다. 그러나 이것은 예시로 제공된 개략도이므로 하나씩 반복할 필요가 없습니다. 단계는 마치 서비스인 것처럼 서비스와 상호 작용합니다. 플랫폼의 각 블록에는 리소스 할당 방법, 애플리케이션 시작 방법, 리소스 작업 방법, 모니터링 및 변경 방법 등 고유한 스토리가 있습니다.

플랫폼의 각 부분이 이야기를 담고 있다는 것을 이해하고, 이 벽돌이 어떤 이야기를 담고 있는지 스스로에게 물어보는 것이 중요합니다. 아마도 벽돌을 버리고 제XNUMX자 서비스로 대체해야 할 수도 있습니다. 예를 들어 브릭 대신 Okmeter를 설치할 수 있습니까? 아마도 그 사람들은 이미 우리보다 훨씬 더 많은 전문 지식을 개발했을 것입니다. 하지만 그렇지 않을 수도 있습니다. 아마도 우리에게는 고유한 전문 지식이 있을 수 있으므로 Prometheus를 설치하고 더욱 발전시켜야 할 것입니다.

플랫폼 생성

이는 복잡한 의사소통 과정입니다. 기본 관행이 있으면 요구 사항과 표준을 개발하고 이를 다양한 도구와 접근 방식으로 지속적으로 변경하는 다양한 엔지니어와 전문가 간의 커뮤니케이션을 시작합니다. DevOps에서 우리가 갖고 있는 문화는 여기서 중요합니다.

문화를 통해 모든 것이 매우 간단합니다. 협업과 소통이 중요해요즉, 서로 공통된 분야에서 일하고 싶은 욕구, 하나의 도구를 함께 휘두르고 싶은 욕구입니다. 여기에는 로켓 과학이 없습니다. 모든 것이 매우 간단하고 진부합니다. 예를 들어, 우리 모두는 입구에 살고 깨끗하게 유지합니다. 그런 수준의 문화입니다.

당신은 무엇을 가지고 있습니까?

다시 한 번 스스로에게 질문할 수 있습니다.

인프라 플랫폼이 전용인가요? 개발 책임자는 누구입니까? 인프라 플랫폼의 경쟁 우위를 이해하고 있습니까?

이런 질문을 끊임없이 스스로에게 물어야 합니다. 제XNUMX자 서비스로 전송할 수 있는 것이 있으면 전송해야 하며, 제XNUMX자 서비스가 귀하의 이동을 차단하기 시작하면 내부에 시스템을 구축해야 합니다.

그래서 데브옵스...

... 이것은 복잡한 시스템이므로 다음이 있어야 합니다.

• 디지털 제품.
• 이 디지털 제품을 개발하는 비즈니스 모듈입니다.
• 코드를 작성하는 제품 팀.
• 지속적인 전달 방식.
• 서비스로서의 플랫폼.
• 서비스로서의 인프라.
• 코드로서의 인프라.
• DevOps에 내장된 안정성 유지를 위한 별도의 방법입니다.
• 모든 것을 설명하는 피드백 실습입니다.

이 다이어그램을 사용하여 회사에 이미 어떤 형태로든 가지고 있는 내용(개발했거나 아직 개발해야 함)을 강조할 수 있습니다.

몇 주 안에 끝날 거예요 DevOpsConf 2019. RIT++의 일부로. 지속적인 전달, 코드형 인프라, DevOps 혁신에 대한 많은 멋진 보고서를 찾을 수 있는 컨퍼런스에 오십시오. 티켓 예약, 마지막 가격 마감일은 20월 XNUMX일입니다.

출처 : habr.com