DevOps 및 Chaos: 분산된 세계에서의 소프트웨어 제공

이스라엘 최초의 DevOps 인증 개시자이자 강사 중 한 명인 Otomato Software의 창립자이자 이사인 Anton Weiss는 작년에 연설했습니다. DevOpsDays 모스크바 카오스 이론과 카오스 엔지니어링의 주요 원리에 대해 설명하고, 미래의 이상적인 DevOps 조직이 어떻게 작동하는지 설명했습니다.

우리는 보고서의 텍스트 버전을 준비했습니다.

좋은 아침!

모스크바에서 열린 DevOpsDays는 2018년 연속으로 제가 이 무대에 서는 것은 이번이 두 번째입니다. 많은 분들이 이 방에 두 번째로 와 계십니다. 무슨 뜻이에요? 이는 러시아의 DevOps 운동이 성장하고 증가하고 있음을 의미하며, 가장 중요한 것은 XNUMX년 DevOps가 무엇인지에 대해 이야기할 때가 왔다는 것을 의미합니다.

2018년에 DevOps가 이미 직업이 되었다고 생각하는 분 손을 들어주세요. 그런 것이 있습니다. 작업 설명에 "DevOps 엔지니어"라고 표시된 DevOps 엔지니어가 있습니까? 회의실에 DevOps 관리자가 있나요? 그런 것은 없습니다. DevOps 설계자? 또한 아니오. 부족한. DevOps 엔지니어라고 말하는 사람이 아무도 없다는 것이 정말 사실인가요?

그럼 여러분 대부분은 이것이 안티 패턴이라고 생각하시나요? 그런 직업이 존재하면 안 된다고요? 우리는 무엇이든 생각할 수 있지만, 우리가 생각하는 동안 업계는 DevOps의 나팔 소리에 맞춰 엄숙하게 전진하고 있습니다.

DevDevOps라는 새로운 주제에 대해 들어본 적이 있는 사람은 누구입니까? 이는 개발자와 DevOps 간의 효과적인 협업을 가능하게 하는 새로운 기술입니다. 그리고 그다지 새로운 것은 아닙니다. 트위터로 판단하면 그들은 이미 4년 전부터 이에 대해 이야기하기 시작했습니다. 그리고 지금까지 이에 대한 관심이 점점 커지고 있는데, 즉 문제가 있습니다. 문제를 해결해야합니다.

우리는 창의적인 사람들입니다. 우리는 단지 안주하지 않습니다. 우리는 DevOps가 충분히 포괄적인 단어가 아니며 여전히 다양하고 흥미로운 요소가 부족하다고 말합니다. 그리고 우리는 비밀 실험실로 가서 DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps와 같은 흥미로운 돌연변이를 만들기 시작합니다.

논리는 철통같죠? 우리의 제공 시스템이 작동하지 않고 시스템이 불안정하며 사용자가 불만족스러워하고 소프트웨어를 제때 출시할 시간이 없으며 예산에도 맞지 않습니다. 이 모든 것을 어떻게 해결할까요? 새로운 단어를 찾아보겠습니다! "Ops"로 끝나고 문제가 해결됩니다.

그래서 저는 이 접근 방식을 "Ops, 그러면 문제가 해결되었습니다"라고 부릅니다.

우리가 왜 이 모든 것을 생각해 냈는지 생각해 보면 이 모든 것이 배경으로 사라집니다. 우리는 이 프로세스에서 소프트웨어 제공과 자체 작업을 방해받지 않고, 고통스럽지 않고, 효율적이고, 가장 중요하게는 가능한 한 즐겁게 만들기 위해 DevOps 전체를 고안했습니다.

DevOps는 고통 속에서 성장했습니다. 그리고 우리는 고통에 지쳤습니다. 그리고 이 모든 일이 일어나기 위해 우리는 효과적인 협업, 흐름 관행, 그리고 가장 중요한 것은 시스템 사고와 같은 상시적인 관행에 의존합니다. 이것이 없으면 DevOps가 작동하지 않기 때문입니다.

시스템이란 무엇입니까?

그리고 우리가 이미 시스템 사고에 대해 이야기하고 있다면 시스템이 무엇인지 상기해 봅시다.

당신이 혁명적인 해커라면 당신에게 시스템은 분명히 악한 것입니다. 그것은 당신 위에 걸려 있고 당신이 원하지 않는 일을 하도록 강요하는 구름입니다.

시스템 사고의 관점에서 볼 때 시스템은 부분으로 구성된 전체입니다. 이런 의미에서 우리 각자는 시스템입니다. 우리가 일하는 조직은 시스템입니다. 그리고 당신과 내가 만들고 있는 것은 시스템이라고 불립니다.

이 모든 것은 하나의 대규모 사회 기술 시스템의 일부입니다. 그리고 이 사회 기술 시스템이 어떻게 함께 작동하는지 이해해야만 이 문제에서 무언가를 진정으로 최적화할 수 있을 것입니다.

시스템 사고의 관점에서 시스템은 다양한 흥미로운 속성을 가지고 있습니다. 첫째, 부품으로 구성됩니다. 즉, 동작이 부품의 동작에 따라 달라집니다. 게다가 모든 부분은 상호의존적이기도 합니다. 시스템에 더 많은 부분이 있을수록 그 동작을 이해하거나 예측하기가 더 어렵다는 것이 밝혀졌습니다.

행동적인 관점에서 보면 또 다른 흥미로운 사실이 있습니다. 시스템은 개별 부분이 할 수 없는 일을 할 수 있습니다.

시스템 사고의 창시자 중 한 명인 러셀 애코프(Russell Ackoff) 박사가 말했듯이, 이는 사고 실험을 통해 매우 쉽게 증명할 수 있습니다. 예를 들어, 방에 있는 누가 코드 작성 방법을 알고 있나요? 손이 많이 가고 이것은 우리 직업의 주요 요구 사항 중 하나이기 때문에 정상입니다. 당신은 작성하는 방법을 알고 있지만 당신의 손이 당신과 별도로 코드를 작성할 수 있습니까? "코드를 쓰는 것은 내 손이 아니라 내 뇌가 코드를 쓰는 것입니다."라고 말하는 사람들이 있습니다. 당신의 두뇌는 당신과 별도로 코드를 작성할 수 있습니까? 아마도 그렇지 않을 것입니다.

뇌는 놀라운 기계입니다. 우리는 뇌가 어떻게 작동하는지 10%도 알지 못합니다. 하지만 뇌는 우리 몸이라는 시스템과 별도로 기능할 수 없습니다. 그리고 이것은 증명하기 쉽습니다. 두개골을 열고 뇌를 꺼내 컴퓨터 앞에 놓고 간단한 것을 쓰도록하십시오. 예를 들어 Python의 "Hello, world"입니다.

어떤 부분도 개별적으로 수행할 수 없는 작업을 시스템이 수행할 수 있다면 이는 해당 동작이 해당 부분의 동작에 의해 결정되지 않는다는 의미입니다. 그러면 그것은 무엇에 의해 결정되는가? 이는 이러한 부분 간의 상호 작용에 의해 결정됩니다. 따라서 부품이 많을수록 상호 작용이 복잡할수록 시스템 동작을 이해하고 예측하기가 더 어려워집니다. 그리고 이는 시스템을 혼란스럽게 만듭니다. 왜냐하면 시스템의 어느 부분에서든 가장 사소하고 눈에 보이지 않는 변화라도 완전히 예측할 수 없는 결과를 초래할 수 있기 때문입니다.

초기 조건에 대한 이러한 민감도는 미국 기상학자인 Ed Lorenz에 의해 처음 발견되고 연구되었습니다. 이후 이는 '나비효과'로 불리며 '카오스 이론'이라는 과학사상 운동의 발전으로 이어졌다. 이 이론은 20세기 과학의 주요 패러다임 전환 중 하나가 되었습니다.

카오스 이론

혼돈을 연구하는 사람들은 스스로를 혼돈학자라고 부릅니다.

사실 이 보고서를 쓰게 된 이유는 복잡한 분산 시스템과 대규모 국제기구와 일하면서 어느 순간 내가 이런 사람이라는 걸 깨달았기 때문이다. 나는 혼돈학자입니다. 이것은 기본적으로 "여기서 무슨 일이 일어나고 있는지 이해가 안 되고 어떻게 해야 할지 모르겠습니다."라고 말하는 영리한 방법입니다.

여러분 중 많은 분들도 종종 이런 느낌을 받으시리라 생각합니다. 그래서 여러분도 역시 혼돈학자입니다. 혼돈학자 길드에 여러분을 초대합니다. 친애하는 혼돈학자 여러분, 여러분과 제가 연구할 시스템을 "복잡 적응 시스템"이라고 합니다.

적응성이란 무엇입니까? 적응성은 이러한 적응 시스템에서 부품의 개별적 및 집합적 동작이 변경되고 자체 구성되어 시스템의 이벤트 또는 일련의 미세 이벤트에 반응하는 것을 의미합니다. 즉, 시스템은 자기 조직화를 통해 변화에 적응합니다. 그리고 이러한 자기 조직화 능력은 자유롭고 자율적인 행위자의 자발적이고 완전히 분산된 협력에 기반을 두고 있습니다.

이러한 시스템의 또 다른 흥미로운 특성은 자유롭게 확장 가능하다는 것입니다. 혼돈학자이자 엔지니어로서 의심할 여지 없이 우리의 관심을 끄는 것은 무엇입니까? 그렇다면 복잡한 시스템의 동작이 해당 부분의 상호 작용에 의해 결정된다면 우리는 무엇에 관심을 가져야 할까요? 상호 작용.

두 가지 더 흥미로운 결과가 있습니다.


첫째, 우리는 부품을 단순화함으로써 복잡한 시스템을 단순화할 수 없다는 것을 이해합니다. 둘째, 복잡한 시스템을 단순화하는 유일한 방법은 부품 간의 상호 작용을 단순화하는 것입니다.

우리는 어떻게 상호 작용합니까? 당신과 나는 모두 인간 사회라는 거대한 정보 시스템의 일부입니다. 우리는 공통 언어를 가지고 있다면, 그것을 찾으면 그것을 통해 상호 작용합니다.

그러나 언어 자체는 복잡한 적응 시스템입니다. 따라서 보다 효율적이고 간단하게 상호 작용하려면 일종의 프로토콜을 만들어야 합니다. 즉, 우리 사이의 정보 교환을 더 간단하고 예측 가능하며 이해하기 쉽게 만드는 일련의 기호와 동작입니다.

복잡성, 적응성, 분산화, 혼돈을 향한 추세는 모든 것에서 추적될 수 있다고 말하고 싶습니다. 그리고 당신과 내가 구축하고 있는 시스템과 우리가 일부인 시스템에서.

근거 없는 이야기가 아니라 우리가 만드는 시스템이 어떻게 변화하고 있는지 살펴보겠습니다.

이 말을 기다리고 있었다는 걸 이해합니다. 우리는 DevOps 컨퍼런스에 참석하고 있습니다. 오늘 이 단어는 약 XNUMX만 번 들을 것이며 밤에는 그것에 대한 꿈을 꾸게 될 것입니다.

마이크로서비스는 DevOps 관행에 대한 대응으로 등장한 최초의 소프트웨어 아키텍처로, 시스템을 더욱 유연하고 확장 가능하게 만들고 지속적인 제공을 보장하도록 설계되었습니다. 그녀는 이것을 어떻게 하는가? 서비스의 양을 줄임으로써 이러한 서비스가 처리하는 문제의 범위를 줄이고 배달 시간을 줄입니다. 즉, 시스템의 일부를 줄이고 단순화하고 그 수를 늘리므로 이러한 부품 간의 상호 작용의 복잡성이 변함없이 증가합니다. 즉, 해결해야 할 새로운 문제가 발생합니다.

마이크로서비스는 끝이 아닙니다. 일반적으로 마이크로서비스는 이미 어제의 일입니다. 서버리스가 다가오고 있기 때문입니다. 모든 서버가 소실되었으며, 서버도 없고, 운영 체제도 없고, 순수 실행 코드만 있습니다. 구성은 별개이고 상태는 별개이며 모든 것이 이벤트에 의해 제어됩니다. 아름다움, 청결함, 고요함, 사건 없음, 아무 일도 일어나지 않음, 완전한 질서.

복잡성은 어디에 있습니까? 물론 어려움은 상호작용에 있습니다. 하나의 기능이 그 자체로 얼마나 많은 일을 할 수 있나요? 다른 기능과 어떻게 상호 작용합니까? 메시지 큐, 데이터베이스, 밸런서. 오류가 발생했을 때 일부 이벤트를 어떻게 다시 생성합니까? 질문은 많고 답변은 적습니다.

마이크로서비스와 서버리스는 우리 괴짜들이 클라우드 네이티브라고 부르는 것입니다. 그것은 모두 클라우드에 관한 것입니다. 그러나 클라우드는 확장성 측면에서도 본질적으로 제한되어 있습니다. 우리는 그것을 분산 시스템으로 생각하는 데 익숙합니다. 실제로 클라우드 제공업체의 서버는 어디에 있습니까? 데이터 센터에서. 즉, 여기에는 일종의 중앙 집중식, 매우 제한적인 분산 모델이 있습니다.

오늘날 우리는 사물 인터넷이 더 이상 단순한 예측에 불과하지 않으며 향후 XNUMX~XNUMX년 내에 인터넷에 연결된 수십억 개의 장치가 우리를 기다리고 있다는 사실을 알고 있습니다. 유용하고 쓸모없는 엄청난 양의 데이터가 클라우드에 병합되어 클라우드에서 업로드됩니다.

클라우드는 지속되지 않을 것이므로 우리는 엣지 컴퓨팅이라는 것에 대해 점점 더 이야기하고 있습니다. 아니면 “포그 컴퓨팅”이라는 놀라운 정의도 마음에 듭니다. 그것은 낭만주의와 신비주의의 신비주의에 가려져 있습니다.

포그 컴퓨팅. 요점은 구름이 중앙에 집중된 물, 증기, 얼음, 돌 덩어리라는 것입니다. 그리고 안개는 대기 중에 우리 주변에 흩뿌려지는 물방울입니다.

안개 패러다임에서 대부분의 작업은 이러한 물방울에 의해 완전히 자율적으로 또는 다른 물방울과 협력하여 수행됩니다. 그리고 그들은 정말로 압박을 받을 때만 클라우드를 선택합니다.

즉, 다시 분산화, 자율성, 그리고 물론 많은 분들이 이미 이 모든 것이 어디로 가는지 이해하고 계십니다. 왜냐하면 블록체인을 언급하지 않고는 분산화에 대해 말할 수 없기 때문입니다.

암호화폐에 투자한 사람들이라고 믿는 사람들이 있습니다. 예를 들어, 나처럼 믿기는 하지만 두려워하는 사람들이 있습니다. 그리고 믿지 않는 사람들도 있습니다. 여기서는 다르게 치료할 수 있습니다. 기술이 있고, 새로운 미지의 물질이 있고, 문제가 있습니다. 여느 신기술과 마찬가지로, 이는 답변보다 더 많은 질문을 제기합니다.

블록체인을 둘러싼 과대광고는 이해할 수 있습니다. 골드러시를 제외하고, 기술 자체는 더 밝은 미래, 즉 더 많은 자유, 더 많은 자율성, 분산된 글로벌 신뢰에 대한 놀라운 약속을 담고 있습니다. 원하지 않는 것은 무엇입니까?

이에 따라 전 세계적으로 점점 더 많은 엔지니어들이 분산형 애플리케이션을 개발하기 시작하고 있습니다. 그리고 이는 “아아, 블록체인은 제대로 구현되지 않은 분산 데이터베이스일 뿐이야”라고 간단히 말해서 무시할 수 없는 힘입니다. 또는 회의론자들은 "블록체인을 실제로 적용할 수 있는 방법은 없습니다."라고 말합니다. 생각해보면 150년 전에는 전기에 대해서도 같은 말을 했습니다. 그리고 어떤 면에서는 그들의 말이 옳기도 했습니다. 오늘날 전기로 가능해진 일이 19세기에는 전혀 가능하지 않았기 때문입니다.

그런데 화면에 어떤 종류의 로고가 있는지 누가 알겠어요? 하이퍼레저입니다. 이는 Linux Foundation의 후원으로 개발 중인 프로젝트이며 일련의 블록체인 기술을 포함합니다. 이것이 바로 오픈 소스 커뮤니티의 진정한 강점입니다.

카오스엔지니어링

그래서 우리가 개발하고 있는 시스템은 점점 더 복잡해지고, 점점 더 혼란스러워지고, 점점 더 적응력이 좋아지고 있습니다. 넷플릭스는 마이크로서비스 시스템의 선구자입니다. 그들은 이것을 가장 먼저 이해한 사람들 중 하나였으며 유인원 군대(Simian Army)라고 불리는 도구 세트를 개발했는데, 그 중 가장 유명한 것은 다음과 같습니다. 카오스 몽키. 그는 다음과 같이 알려지게 된 것을 정의했습니다. "카오스 엔지니어링의 원리".

그건 그렇고, 보고서 작업 과정에서 우리는 이 텍스트를 러시아어로 번역까지 했으므로 다음으로 이동하십시오. 링크, 읽기, 댓글 달기, 꾸짖기.

간단히 말해서 카오스공학의 원리는 다음과 같다. 복잡한 분산 시스템은 본질적으로 예측할 수 없으며 본질적으로 버그가 있습니다. 오류는 불가피합니다. 즉, 우리는 이러한 오류를 받아들이고 완전히 다른 방식으로 이러한 시스템을 사용해야 함을 의미합니다.

우리 시스템의 적응성, 자체 조직 능력, 생존 능력을 테스트하기 위해 우리는 생산 시스템에 이러한 오류를 도입하려고 노력해야 합니다.

그리고 그것은 모든 것을 변화시킵니다. 시스템을 프로덕션에 출시하는 방법뿐만 아니라 시스템을 개발하고 테스트하는 방법도 포함됩니다. 코드가 안정화되거나 동결되는 과정은 없으며, 반대로 끊임없이 불안정해지는 과정이 있습니다. 우리는 시스템을 죽이고 시스템이 계속 살아남는 것을 보려고 노력하고 있습니다.

분산 시스템 통합 프로토콜

따라서 이를 위해서는 우리 시스템이 어떻게든 변경되어야 합니다. 더욱 안정적이 되려면 부품 간의 상호 작용을 위한 몇 가지 새로운 프로토콜이 필요합니다. 그래서 이러한 부분들이 동의하고 일종의 자기 조직화를 이룰 수 있습니다. 그리고 모든 종류의 새로운 도구, 새로운 프로토콜이 등장합니다. 저는 이를 "분산 시스템의 상호 작용을 위한 프로토콜"이라고 부릅니다.

내가 무슨 말을하는거야? 먼저, 프로젝트 오픈 트레이싱. 일부에서는 복잡한 분산 시스템을 디버깅하는 데 꼭 필요한 도구인 일반 분산 추적 프로토콜을 만들려고 시도합니다.

더- 정책 에이전트 열기. 우리는 시스템에 어떤 일이 일어날지 예측할 수 없다고 말합니다. 즉, 관찰 가능성, 관찰 가능성을 높여야 합니다. Opentracing은 시스템에 관찰성을 제공하는 도구 제품군에 속합니다. 그러나 시스템이 우리가 기대하는 대로 작동하는지 여부를 확인하려면 관찰 가능성이 필요합니다. 예상되는 동작을 어떻게 정의합니까? 일종의 정책, 규칙 세트를 정의함으로써 가능합니다. Open Policy Agent 프로젝트는 액세스부터 리소스 할당까지 다양한 범위에 걸쳐 이러한 규칙 세트를 정의하기 위해 노력하고 있습니다.

앞서 말했듯이 우리 시스템은 점점 더 이벤트 중심으로 변하고 있습니다. 서버리스는 이벤트 중심 시스템의 좋은 예입니다. 시스템 간에 이벤트를 전송하고 추적하려면 이벤트에 대해 이야기하는 방법, 이벤트를 서로 전송하는 방법에 대한 공통 언어, 공통 프로토콜이 필요합니다. 이것이 바로 프로젝트라고 불리는 것입니다. 클라우드 이벤트.

우리 시스템을 휩쓸고 끊임없이 불안정하게 만드는 끊임없는 변화의 흐름은 소프트웨어 아티팩트의 지속적인 흐름입니다. 이러한 지속적인 변경 흐름을 유지하려면 소프트웨어 아티팩트가 무엇인지, 어떻게 테스트되는지, 어떤 검증을 통과했는지에 대해 이야기할 수 있는 일종의 공통 프로토콜이 필요합니다. 이것이 바로 프로젝트라고 불리는 것입니다. 그라페아스. 즉, 소프트웨어 아티팩트에 대한 공통 메타데이터 프로토콜입니다.

마지막으로, 시스템이 완전히 독립적이고 적응적이며 자체 조직화되기를 원한다면 시스템에 자체 식별 권한을 부여해야 합니다. 프로젝트 호출 뱉어내다 이것이 바로 그가 하는 일입니다. 이 역시 Cloud Native Computing Foundation이 후원하는 프로젝트입니다.

이 모든 프로젝트는 초기 단계이고, 모두 우리의 사랑과 검증이 필요합니다. 이것은 모두 오픈 소스, 테스트, 구현입니다. 이는 기술이 어디로 향하고 있는지 보여줍니다.

그러나 DevOps는 주로 기술에 관한 것이 아니라 항상 사람들 간의 협업에 관한 것입니다. 따라서 우리가 개발하는 시스템이 바뀌기를 원한다면 우리 자신도 바뀌어야 합니다. 사실 우리는 어차피 변화하고 있기 때문에 선택의 여지가 별로 없습니다.

멋진 것이 있습니다 книга 영국 작가 레이첼 보츠먼(Rachel Botsman)은 인류 역사 전반에 걸친 신뢰의 진화에 대해 글을 썼습니다. 그녀는 원시 사회에서 처음에는 신뢰가 지역적이었다고 말합니다. 즉, 우리는 개인적으로 아는 사람들만 신뢰했습니다.

그런 다음 매우 오랜 기간이있었습니다. 신뢰가 중앙 집중화되어 우리가 동일한 공공 기관이나 국가 기관에 속해 있다는 사실을 바탕으로 모르는 사람들을 신뢰하기 시작한 암흑기였습니다.

그리고 이것이 바로 현대 세계에서 우리가 보는 것입니다. 신뢰는 점점 더 분산되고 분산되고 있으며 정보 흐름의 자유와 정보의 가용성에 기반을 두고 있습니다.

생각해보면 이러한 신뢰를 가능하게 하는 바로 이 접근성이 바로 여러분과 제가 구현하고 있는 것입니다. 이는 과거의 중앙 집중식 계층적 IT 조직이 더 이상 작동하지 않기 때문에 협업 방식과 이를 수행하는 방식이 모두 변경되어야 함을 의미합니다. 그들은 죽기 시작합니다.

DevOps 조직 기초

미래의 이상적인 DevOps 조직은 각각 자율적인 개인으로 구성된 자율적인 팀으로 구성된 분산형 적응형 시스템입니다. 이러한 팀은 전 세계에 분산되어 있으며 매우 투명한 통신 프로토콜을 사용하여 비동기 통신을 사용하여 서로 효과적으로 협업합니다. 정말 아름답지 않나요? 매우 아름다운 미래입니다.

물론 문화적 변화 없이는 이 중 어느 것도 불가능합니다. 우리는 변혁적 리더십, 개인적 책임, 내부 동기를 갖추어야 합니다.

이는 정보 투명성, 비동기식 커뮤니케이션, 변혁적 리더십, 분산화 등 DevOps 조직의 기초입니다.

탈진

우리가 속한 시스템과 우리가 구축하는 시스템은 점점 더 혼란스러워지고 있으며, 우리 인간이 이러한 생각에 대처하기 어렵고 통제에 대한 환상을 포기하기가 어렵습니다. 우리는 그들을 계속해서 통제하려고 노력하는데, 이는 종종 탈진으로 이어집니다. 나는 내 경험에 비추어 이렇게 말합니다. 나 역시 화상을 입었고, 예상치 못한 생산 실패로 인해 장애를 입기도 했습니다.

번아웃은 본질적으로 통제할 수 없는 것을 통제하려고 할 때 발생합니다. 우리가 탈진하면 새로운 일을 하려는 욕구를 잃기 때문에 모든 것이 그 의미를 잃습니다. 우리는 방어적인 태도를 취하고 우리가 가진 것을 방어하기 시작합니다.

내가 자주 상기시키고 싶은 엔지니어링 직업은 무엇보다도 창의적인 직업입니다. 무언가를 창조하려는 욕구를 잃으면 우리는 재로 변하고 재로 변합니다. 사람도 소진되고 조직 전체도 소진됩니다.

제 생각에는 혼돈의 창조력을 받아들이고 그 원칙에 따라 협력을 구축하는 것만이 우리 직업에서 좋은 것을 잃지 않는 데 도움이 될 것입니다.

이것이 제가 여러분에게 바라는 것입니다. 여러분의 일을 사랑하고 우리가 하는 일을 사랑하는 것입니다. 이 세상은 정보를 먹고 살기 때문에 우리는 정보를 먹일 수 있는 영광을 누리고 있습니다. 그러니 혼돈을 연구하고, 혼돈학자가 되자, 가치를 가져오고, 새로운 것을 창조합시다. 음, 이미 알고 있듯이 문제는 피할 수 없으며, 문제가 나타나면 간단히 "Ops!"라고 말하면 문제가 해결됩니다.

카오스 몽키 외에 무엇이 있나요?

사실 이 악기들은 모두 너무 어리다. 동일한 Netflix가 스스로 도구를 만들었습니다. 나만의 도구를 만드세요. 다른 사람이 이미 구축한 다른 도구를 찾으려고 하기보다는 카오스 엔지니어링의 원칙을 읽고 해당 원칙에 따라 생활하세요.

시스템이 어떻게 고장나는지 이해하고, 고장을 시작하고, 어떻게 유지되는지 확인하십시오. 이것이 먼저 온다. 그리고 도구를 찾을 수 있습니다. 모든 종류의 프로젝트가 있습니다.

구성 요소를 단순화하여 시스템을 단순화할 수 없다고 말씀하시다가 즉시 구성 요소 자체를 단순화하고 상호 작용을 복잡하게 하여 시스템을 단순화하는 마이크로서비스로 전환하신 순간을 잘 이해하지 못했습니다. 이는 본질적으로 서로 모순되는 두 부분입니다.

맞습니다. 마이크로서비스는 일반적으로 매우 논란이 많은 주제입니다. 실제로 부품을 단순화하면 유연성이 향상됩니다. 마이크로서비스는 무엇을 제공하나요? 유연성과 속도를 제공하지만 단순함을 제공하지는 않습니다. 그들은 난이도를 높입니다.

그렇다면 DevOps 철학에서 마이크로서비스는 그리 좋은 것이 아닌가요?

모든 재화에는 반대면이 있습니다. 유연성이 증가하여 더 빠르게 변경할 수 있다는 이점이 있지만 복잡성이 증가하여 전체 시스템이 취약해집니다.

그럼에도 불구하고 상호 작용을 단순화하는 것, 아니면 부품을 단순화하는 것 중 무엇이 더 강조됩니까?

물론 상호 작용을 단순화하는 것이 강조됩니다. 왜냐하면 우리가 귀하와 협력하는 방식의 관점에서 이를 살펴보면 우선 작업을 단순화하는 것이 아니라 상호 작용을 단순화하는 데 주의를 기울여야 하기 때문입니다. 우리 각자는 따로따로. 작업을 단순화한다는 것은 로봇으로 변하는 것을 의미하기 때문입니다. 여기 맥도날드에서는 지시가 있을 때 정상적으로 작동합니다. 여기에 버거를 넣고, 여기에 소스를 붓습니다. 이것은 우리의 창의적인 작업에서는 전혀 작동하지 않습니다.

당신이 말한 모든 것이 경쟁이 없는 세상에 살고 있다는 것이 사실입니까? 그곳의 혼돈은 너무나 친절하고 이 혼돈 속에는 모순이 없으며 누구도 먹거나 죽이고 싶어하지 않는다는 것이 사실입니까? 경쟁과 DevOps는 어떻게 진행되어야 합니까?

글쎄, 그것은 우리가 말하는 경쟁의 종류에 따라 다릅니다. 직장 내 경쟁인가요, 아니면 회사 간 경쟁인가요?

서비스가 여러 회사가 아니기 때문에 존재하는 서비스의 경쟁에 대하여. 우리는 새로운 형태의 정보환경을 만들어가고 있으며, 어떤 환경도 경쟁 없이는 살아갈 수 없습니다. 경쟁은 어디에서나 존재합니다.

같은 Netflix를 롤모델로 삼습니다. 그들은 왜 이것을 생각해 냈습니까? 경쟁력을 갖춰야 했기 때문입니다. 이러한 유연성과 이동 속도는 바로 경쟁이 치열한 요구 사항이며 시스템에 혼란을 가져옵니다. 즉, 혼돈은 우리가 원해서 의식적으로 하는 일이 아니라, 세상이 요구하기 때문에 일어나는 일이다. 우리는 적응하기만 하면 됩니다. 그리고 혼돈은 바로 경쟁의 결과입니다.

이것은 혼돈이 말하자면 목표가 없다는 것을 의미합니까? 아니면 우리가 보고 싶지 않은 목표인가요? 우리는 집에 있고 다른 사람들의 목표를 이해하지 못합니다. 사실 경쟁은 우리가 명확한 목표를 갖고 있고 다음 순간에 우리가 어디로 갈지 알고 있기 때문에 발생합니다. 내 관점에서는 이것이 DevOps의 본질입니다.

또한 질문을 살펴보십시오. 우리 모두는 같은 목표를 가지고 있다고 생각합니다. 생존하고 함께하는 것입니다.
최고의 즐거움. 그리고 모든 조직의 경쟁 목표는 동일합니다. 생존은 종종 경쟁을 통해 이루어지며, 이에 대해 당신이 할 수 있는 일은 아무것도 없습니다.

올해 컨퍼런스 DevOpsDays 모스크바 7월 11일 Technopolis에서 개최됩니다. XNUMX월 XNUMX일까지 보고서 신청을 받고 있습니다. Напишите 당신이 말하고 싶다면 우리에게.

참가자 등록이 열려 있으며 티켓 비용은 7000 루블입니다. 우리와 함께하세요!

출처 : habr.com