Jeff Smith와 함께하는 스매싱 팟캐스트 에피소드 42: DevOps란?

이 에피소드에서는 DevOps에 대해 이야기합니다. 그것은 무엇이며 웹 개발 활에 추가할 문자열입니까? Drew McLellan은 전문가 Jeff Smith와 대화하여 알아냅니다.

메모 표시

• 트위터의 제프
• Jeff의 저서 Operations Anti-Patterns, DevOps Solutions
• 달성 가능한 DevOps

주간 업데이트

• Matthew Talebi가 작성한 디자이너와 개발자 간의 격차 해소
• Gaurav Khanna가 작성한 TypeScript로 유연한 구성 요소를 빌드하는 데 유용한 React API
• Cosima Mielke가 작성한 일반적인 UI 문제를 위한 스마트 CSS 솔루션
• Nataliya Sambir가 작성한 UX/UI 디자이너 평가를 위한 팁과 요령
• Arijit Mondal이 작성한 Next.js 기반 전자 상거래 웹 사이트에서 CLS 문제 해결

성적 증명서

Drew McLellan: 그는 여정의 어느 단계에 있든 도달 가능한 수준의 DevOps 구현에 중점을 둔 DevOps 실무자입니다. 그는 디지털 광고 플랫폼 Centro의 프로덕션 운영 이사이자 대중 연설가로서 자신의 DevOps 지식을 전 세계 청중과 공유하고 있습니다. 그는 Manning Publishing을 위한 Operations Anti-Patterns, DevOps Solutions for Manning Publishing의 저자입니다. 이 책은 대부분의 개발자가 작업하는 불완전한 환경에서 DevOps 기술을 구현하는 방법을 보여줍니다. 따라서 우리는 그가 DevOps의 전문가라는 것을 알고 있지만 George를 알고 계셨습니까? 클루니는 그를 한 세대 최고의 종이비행기 제작자로 꼽는다. 내 Smashing 친구, Jeff Smith를 환영하십시오. 안녕하세요 제프입니다. 잘 지내고 있나요?

제프 스미스: 굉장해요, 드류, 어때요?

드류: 난 괜찮아. 감사합니다. 좋은 소식입니다. 그래서 저는 오늘 여러분의 주요 핵심 영역 중 하나인 DevOps라는 주제에 대해 이야기하고 싶었습니다. 우리 청취자 중 많은 사람들이 웹 및 앱 개발에 참여하지만 아마도 운영 측면에서 일어나는 일에 대해 느슨한 지식을 가지고 있을 뿐입니다. 나는 우리 중 더 큰 회사에서 일할 수 있는 사람들이 작업을 수행하는 전체 동료 팀을 갖게 될 것이라는 것을 알고 있습니다. 우리는 그들이 무엇을 하든 잘 하고 있다는 사실에 감사할 뿐입니다. 그러나 DevOps가 점점 더 많이 언급되는 것을 듣고 개발자로서 우리가 진정으로 이해해야 하는 것 중 하나처럼 느껴집니다. Jeff, DevOps란 무엇입니까?

Jeff: 따라서 20명에게 DevOps가 무엇인지 묻는다면 20가지 다른 대답을 얻을 수 있습니다. 그래서 나는 당신에게 그것에 대한 나의 견해를 줄 것입니다. 알겠습니다. 그리고 당신이 회의에서 이것을 언급한다면 누군가와 주먹다짐을 할 수 있다는 것을 압니다. 하지만 저에게 DevOps는 실제로 개발과 운영 간의 관계에 관한 것입니다. 하지만 실제로는 팀 간 관계와 우리가 작업을 구조화하는 방법, 더 중요하게는 목표와 인센티브를 구조화하여 그들이 공동의 목표를 향해 일할 수 있도록 조정되었습니다. 그리고 DevOps의 많은 핵심 아이디어와 개념은 개발팀과 운영팀이 항상 적대적이었던 구세계에서 비롯되었으며, 이러한 끊임없는 갈등이 있었습니다. 생각해보면 두 팀이 인센티브를 받는 방식 때문입니다. 한 팀은 변경 사항을 푸시하도록 장려됩니다. 다른 팀은 안정성을 유지하도록 인센티브를 받습니다. 즉, 변경 사항이 적습니다.

Jeff: 그렇게 하면 고유한 갈등이 발생하고 모든 것이 거기서 흘러나옵니다. 따라서 DevOps는 실제로 이러한 팀과 목표를 조정하여 공통 전략을 향해 노력하고 있는 동시에 양측의 관행을 채택하여 개발자가 운영에 대해 더 많이 이해하고 운영이 개발에 대해 더 많이 이해할 수 있도록 하는 것입니다. 상대방이 어디에서 왔는지에 대한 관점을 이해할 수 있도록 서로 공감합니다.

Jeff: 하지만 우리의 작업을 향상시키기 위해서이기도 합니다. 다시 말하지만, 내가 당신의 관점을 이해하고 그것을 내 작업에서 고려한다면, 그것은 우리 각자에게 훨씬 더 유익할 것이기 때문입니다. 그리고 자동화와 쉽게 재현할 수 있도록 접근하는 방법 측면에서 op가 개발자로부터 배울 수 있는 것이 많습니다. 이것이 바로 블렌딩과 스킬입니다. 그리고 지금 보고 있는 것은 이것이 다른 그룹 조합에 적용된다는 것입니다. 따라서 DevSecOps, DevSecFinOps, DevSecFinHROps와 같은 것을 듣게 됩니다. 그것은 계속해서 성장하고 성장하고 성장할 것입니다. 따라서 조직 전체에 적용할 수 있는 교훈입니다.

Drew: 그래서 우리가 개발자로서 이해하고 있는 몇 가지 개념을 취하고 우리의 아이디어를 조직에 더 널리 퍼뜨리는 동시에 모든 사람을 앞으로 나아가게 하기 위해 운영에서 우리가 할 수 있는 것을 배우는 것입니다.

제프: 물론이죠. 그리고 운영의 또 다른 측면은 도입부에서 약간 언급했지만 전담 운영 팀과 이와 유사한 것들이 있는 이러한 대규모 조직을 위한 것이라고 생각하지만 한 가지 생각해야 할 것은 조직에서 운영이 일어나고 있다는 것입니다. 크기에 관계없이. 당신이 그것을 하고 있는지, 아니면 별도의 팀이 그것을 하고 있지만 어떻게든 코드를 배포하고 있는지의 문제입니다. 어떻게 든 어딘가에 서버가 실행되고 있습니다. 따라서 작업은 규모에 관계없이 조직의 어딘가에 존재합니다. 문제는 누가 하느냐입니다. 개인 또는 단일 그룹인 경우 Ops가 수행하는 작업의 유형을 이해해야 하므로 DevOps가 훨씬 더 중요할 수 있습니다.

Drew: 전문 개발자로서 DevOps가 무엇이며 구현하는 것이 무엇을 의미하는지 잘 이해하는 것이 얼마나 중요하다고 생각하십니까?

Jeff: 특히 DevOps 여정의 이 단계에서 매우 중요하다고 생각합니다. 그리고 그것이 중요하다고 생각하는 이유는 우리가 상대방이 하는 일을 이해할 때 항상 더 효율적이라고 생각하기 때문입니다. 그러나 다른 것은 설계 개발 및 기술 구현 중에 운영상의 문제를 고려할 수 있다는 것입니다. 제 경력에서 배운 한 가지는 개발자가 우주의 주인이라고 생각하고 컴퓨터와 관련된 모든 것을 이해한다고 생각했지만 실제로는 그렇지 않다는 것이 밝혀졌습니다. 이해의 측면에서 운영팀에 아웃소싱하는 많은 것들이 있으며 때로는 프로덕션 배포에 최적이 아닐 수 있는 특정 디자인 선택 또는 구현 선택이 발생합니다.

Jeff: 개발 및 테스트 및 이와 유사한 작업에서는 괜찮을지 모르지만 일단 프로덕션 단계에 이르면 약간 다른 방식의 게임이 됩니다. 따라서 그들이 전체 전문 지식을 소유해야 한다는 것은 아니지만 최소한 자신이 모르는 것을 알 수 있을 만큼 충분히 알아야 합니다. 따라서 그들은 개발팀이 선택하는 것을 볼 수 있는 일반적인 패턴이기 때문에 조기에 운영에 참여할 때를 압니다. 선택이라는 사실조차 인지하지 못하기 때문에 선택을 하라고 말하지는 않겠지만, 운영에 대한 차선책 결정으로 이어지는 일이 발생하고 개발이 전혀 인식하지 못했습니다. 따라서 작전에 대해 조금 더 많은 지식을 갖고 있는 것만으로도 충분하다고 할 수 있습니다. 앞으로 나아가기 전에 작전팀의 관점을 파악하기 위해 이에 대한 정보를 제공해야 할 수도 있습니다. 출시하는 모든 제품과 관련하여 분명히 많은 시간과 에너지, 안정성을 절약할 수 있습니다.

Drew: 우리가 디자인과 dev 사이에 있는 것처럼 dev와 ops 사이의 관계에 대해 이야기하는 방식과 너무 많은 유사점을 봅니다. 여기서 디자이너는 인터페이스가 어떻게 작동하고 보이는지 작업하고 잘 이해하게 될 것입니다. 그것이 실제로 어떻게 개발 역할에 구축될 것인지에 대한 정보와 개발자를 컨설팅에 참여시키는 것은 명확한 의사 소통과 서로가 하는 일에 대한 이해를 갖는 것만으로도 전체 솔루션을 실제로 개선할 수 있습니다. DevOps에서도 동일한 원칙이 적용되는 것 같습니다. 정말 듣기 좋은 소식입니다.

Drew: DevOps에 대해 들은 것을 생각할 때 Kubernetes, Docker, Jenkins, CircleCI와 같은 용어를 듣습니다. 나는 수년 동안 Kubernetes에 대해 들어왔습니다. 나는 아직도 그것이 무엇인지 전혀 모르지만, 당신이 말하는 것으로부터 DevOps는 단지 ... 우리는 여기서 단지 도구에 대해 이야기하는 것이 아닙니다, 그렇지 않습니까? 그러나 워크플로에 대한 프로세스 및 커뮤니케이션 방법에 대한 자세한 내용이 맞습니까?

제프: 물론입니다. 그래서 지난 20년 동안 제 만트라는 항상 사람 처리 도구였습니다. 당신은 사람들이 비전에 구매하도록합니다. 거기에서 그 비전을 달성하기 위해 프로세스가 어떤 모습일지 정의합니다. 그런 다음 프로세스가 무엇이든 모델링할 도구를 가져옵니다. 그래서 저는 항상 DevOps 대화의 끝 부분에 도구를 넣습니다. 주로 그러한 동의가 없으면 중요하지 않기 때문입니다. 저는 사상 최대의 지속적 배포 파이프라인을 생각해 낼 수 있었지만, 사람들이 모든 변경 사항을 프로덕션으로 바로 배송한다는 아이디어에 동의하지 않는다면 문제가 되지 않겠습니까? 도구가 무슨 소용입니까? 따라서 이러한 도구는 우리가 정의한 몇 가지 공통 목표를 달성하기 위한 표준화된 방법이기 때문에 분명히 대화의 일부입니다.

Jeff: 하지만 정의된 목표가 조직에 의미가 있는지 확인해야 합니다. 지속적인 배포가 적합하지 않을 수 있습니다. 변경 사항이 나올 때마다 변경 사항을 배송하고 싶지 않을 수도 있습니다. 그리고 당신이 그렇게 하고 싶지 않은 많은 회사와 조직과 이유가 있습니다. 따라서 지속적인 배포 파이프라인과 같은 것이 적합하지 않을 수 있습니다. 따라서 도구도 중요하지만 조직에 가치를 제공하는 것이 무엇인지에 초점을 맞춘 다음 이를 달성하는 데 필요한 도구를 모델링하고 구현하는 것이 더 중요합니다.

Jeff: 하지만 온라인에 접속하여 모두가 무엇을 하고 있는지 알아내지 마세요. 오, 만약 우리가 DevOps를 하려면 도구 체인이기 때문에 Docker와 Kubernetes로 전환해야 합니다. 아니, 그게 아니야. 그런 것들이 필요하지 않을 수도 있습니다. 모든 사람이 Google은 아닙니다. 모두가 넷플릭스는 아니다. Netflix 및 Google의 게시물 읽기를 중지하세요. 그만 읽어주세요. 그것은 사람들을 흥분시키고 그들이 좋아하기 때문에 이것이 우리가 해야 할 일입니다. 그리고 그들은 여러분이 가지고 있는 문제와는 매우 다른 문제를 해결하고 있습니다.

Drew: 그래서 제가 새로운 프로젝트를 시작한다고 하면 아마도 저는 소프트웨어를 서비스 제품으로 만드는 스타트업 비즈니스일 것입니다. 세 명의 개발자가 있고 빈 Git 저장소가 있고 IPO에 대한 꿈이 있습니다. 이 제품을 구축하기 위한 DevOps 접근 방식에 대해 모두 참여하려면 사람과 프로세스 측면에서 갖추어야 하는 빌딩 블록의 이름은 무엇이며 어디서부터 시작해야 합니까?

Jeff: 귀하의 구체적인 예에서 가장 먼저 시작할 수 있는 것은 가능한 한 대부분을 펀트하고 Heroku와 같은 것을 사용하는 것입니다. 이 모든 AWS 제품, Docker 제품에 너무 열광하기 때문에 실제로는 성공적인 제품을 구축하는 것이 너무 어렵습니다. DevOps 부분에 초점을 맞추고 있다는 생각은 실제로 문제가 될 때까지 가능한 한 많은 것을 아웃소싱한다고 말하고 싶습니다. 그러나 당신이 괜찮다고 말하는 지점에 있다면, 우리는 이 물건을 집으로 가져갈 준비가 되어 있고 다음 단계로 나아갈 준비가 되어 있습니다. 가장 먼저 시작해야 할 부분은 통증이 있는 곳이 어디냐는 것입니다. 당신에게 문제를 일으키는 것들은 무엇입니까?

Jeff: 어떤 사람들에게는 자동화된 테스트만큼 간단합니다. 이봐, 누군가가 커밋을 할 때마다 테스트를 실행해야 한다는 생각은 때때로 우리가 이미 작성한 단위 테스트에 의해 포착되는 물건을 배송하기 때문입니다. 따라서 지속적인 통합으로 시작할 수 있습니다. 배포를 완료하는 데 몇 시간이 걸리고 매우 수동적일 수 있습니다. 그런 다음 여기에서 초점을 맞추고 다음과 같이 말합니다. 좋아요, 이것을 원 버튼 클릭으로 만들 수 있으려면 어떤 자동화가 필요할까요? 그러나 나는 장군을 처방하는 것을 싫어합니다. 이것은 당신이 시작하는 곳입니다. 단지 당신의 특정한 상황과 특정한 고통점이 다를 것이기 때문입니다. 그리고 문제는 그것이 골칫거리라면 당신에게 소리쳐야 한다는 것입니다. 그것은 당신에게 절대적으로 소리쳐야 합니다.

Jeff: 누군가가 이렇게 말하는 것 중 하나여야 합니다. 오, 당신의 조직에서 짜증나는 것은 무엇입니까? 그리고 그것은 오, 그것이 무엇인지 정확히 알고 있습니다. 따라서 이러한 관점에서 접근하면 DevOps 도구 상자에서 압축을 풀고 작업을 시작해야 하는 측면에서 다음 단계가 매우 명확해집니다. 그런 다음 계속해서 오는 이러한 최소한의 점진적 변경이 되며 새로운 기능을 얻을 때 표준 이하의 항목에 대한 욕구가 매우 작아지는 것을 알 수 있습니다. 예, 배포하는 데 3시간이 걸리고 괜찮습니다. 당신은 그것에 약간의 노력을 기울였습니다. 그리고 다음에 알다시피, 당신은 3주 안에, 당신은 이런 사람이 됩니다. 배포에 여전히 30분이 걸린다는 것이 믿기지 않습니다. 이것을 30분에서 어떻게 줄일 수 있습니까? 당신의 식욕은 개선을 위해 만족할 수 없게 됩니다. 그래서 일이 거기서 흘러나옵니다.

Drew: 나는 최근에 당신이 DevOps의 네 가지 기둥이라고 부르는 것을 강조하는 당신의 책을 읽었습니다. 그리고 언급한 것처럼 그 중 어느 것도 도구가 아니지만 원하는 경우 DevOps에 대해 다음과 같은 네 가지 주요 초점 영역이 있습니다. 나는 그 중 첫 번째가 문화라는 것을 알아차렸고, 그 점에 매우 놀랐습니다. 첫째, 저는 당신이 도구에 대해 더 많이 이야기할 것이라고 기대했고 이제 그 이유를 이해하지만 문화에 관해서는 이상하게 보입니다. 처음에 가지고 있는 것. 기술적 접근을 위한 기반이 있습니다. 문화는 조직 내에서 DevOps 구현이 얼마나 성공적일 수 있는지에 어떤 영향을 줍니까?

Drew: … 조직 내에서 DevOps 구현이 얼마나 성공적일 수 있는지.

Jeff: 문화는 생각해보면 정말 모든 것의 기반입니다. 문화가 중요하기 때문에 책에서 조금 더 깊이 들어가지만 문화는 실제로 조직 내 규범의 무대를 설정합니다. 오른쪽. 자동화된 테스트 없이 PR을 제출하면 큰 문제가 되지 않는 회사에 다녔을 것입니다. 사람들은 그것을 받아들이고 앞으로 나아갑니다.

제프: 하지만 그것이 근본적인 죄인 다른 조직이 있습니다. 오른쪽. 만약 당신이 그것을 했다면, "와, 너 미쳤어? 뭐하세요? 여기에는 테스트 케이스가 없습니다.” 오른쪽. 그래도 그게 문화다. 그것이 바로 “이것은 우리가 하는 일이 아니다”라고 말하는 규범을 강요하는 문화입니다.

Jeff: 누구나 자동화된 테스트 사례를 갖게 될 것이라는 문서를 작성할 수 있지만 조직의 문화는 사람들 사이에서 그 메커니즘을 시행하는 것입니다. 그것은 문화가 왜 그렇게 중요한지를 보여주는 하나의 작은 예일 뿐입니다. 두려움의 문화, 응징의 문화인 조직이 있다면. 실수를 하면 모독이 되는 것과 같습니다. 오른쪽. 그것은 반역에 해당합니다. 오른쪽.

Jeff: 당신은 위험하거나 잠재적으로 실패할 수 있는 모든 것에 불리한 행동을 조직에서 만듭니다. 그리고 그것은 테이블에 많은 기회를 남기게 됩니다. 반면에 실패로부터 배우는 것을 포용하는 문화를 만들면 사람들이 실험할 수 있는 심리적 안전에 대한 아이디어를 포용합니다. 그리고 그들이 틀리면 안전하게 실패하고 다시 시도하는 방법을 알아낼 수 있습니다. 실험의 문화를 얻게 됩니다. 사람들이 새로운 아이디어에 열려 있는 조직을 얻게 됩니다.

Jeff: 저는 우리 모두가 "글쎄, 이것이 완료되는 방식입니다. 그리고 아무도 그것을 바꾸지 않습니다.” 오른쪽. 세상은 끊임없이 변하기 때문에 당신은 그것을 원하지 않습니다. 그것이 우리가 문화를 최우선으로 하는 이유입니다. 왜냐하면 조직 내에서 많은 행동이 존재하는 문화 때문에 존재하기 때문입니다.

Jeff: 그리고 문제는 문화적 행위자가 좋거나 나쁘다는 것입니다. 오른쪽. 아이러니하게도 책에서도 이에 대해 이야기하고 있습니다. 조직 문화를 바꾸는 데 생각보다 많은 사람이 필요하지 않다는 것입니다. 오른쪽. 왜냐하면 대부분의 사람들은 어떤 종류의 변화에 ​​관해서도 비방하는 사람이 있고 그 다음에는 지지자가 있고 그 다음에는 울타리를 지키는 사람이 있기 때문입니다. 그리고 대부분의 사람들은 펜스 시터입니다. 오른쪽. 저울을 실제로 기울이는 데는 소수의 지지자만 필요합니다. 그러나 같은 의미에서 저울을 기울이는 데는 소수의 비방자만 필요합니다.

Jeff: 문화를 더 좋게 바꾸는 데는 많은 시간이 필요하지 않습니다. 그리고 그 에너지를 투입하면 고위 리더가 아니더라도 실제로 팀 문화에 영향을 미칠 수 있으며, 이는 결국 부서의 문화에 영향을 미치고 결국 조직의 문화에 영향을 미치게 됩니다.

Jeff: 이러한 아이디어와 행동을 큰 소리로 지지하고 "이것이 우리가 여기서 얻는 이점입니다."라고 말함으로써 개별 기여자로서 이러한 문화적 변화를 만들 수 있습니다. 그렇기 때문에 문화가 전면에 나서야 한다고 생각하는 이유는 모든 사람이 이 아이디어에 동의해야 하고 조직으로서 가치가 있고 이를 지원한다는 것을 이해해야 하기 때문입니다.

드류: 네. 삶의 방식이 되어야 한다고 생각합니다.

제프: 맞습니다.

드류: 네. 저는 자동화 분야에 정말 관심이 많습니다. 왜냐하면 제 경력을 통틀어 지금까지 도입된 자동화 중 도움이 되지 않는 것을 본 적이 없기 때문입니다. 오른쪽. 제 말은, 이상한 점을 제외하고는 무언가가 자동화되어 잘못되는 경우가 있습니다. 일반적으로 앉아서 수동으로 하던 일을 자동화하는 데 시간을 할애하면 항상 시간을 절약하고 머리 공간을 절약할 수 있으며 어깨에 부담이 될 뿐입니다.

Drew: DevOps 접근 방식을 취할 때 워크플로 내에서 어떤 종류의 자동화를 원하십니까? 수동으로 작업을 완료하는 것보다 어떤 이점을 기대할 수 있습니까?

Jeff: 자동화의 경우 자동화가 삶을 더 좋게 만들지 못한 경우는 거의 없습니다. 오른쪽. 사람들이 직면하는 문제는 자동화를 구축할 시간을 찾는 것입니다. 오른쪽. 그리고 일반적으로 현재 직장에서 실제로 요청의 요점입니다. 오른쪽. 언젠가는 "이 작업을 수동으로 중단하고 자동화할 것입니다."라고 말해야 하기 때문입니다.

Jeff: 그리고 "그거 알아? 2주가 소요됩니다. 보통 몇 시간 안에 처리된다는 것을 알고 있지만 자동화된 요청이기 때문에 2주가 걸릴 것입니다.” 자동화하는 것을 식별하는 측면에서. Central에서는 기본적으로 4주 동안 들어온 다양한 유형의 요청을 모두 샘플링하는 프로세스를 사용합니다. 그리고 계획된 작업, 계획되지 않은 작업, 부가 가치 작업, 고된 작업으로 분류합니다. 수고는 별로 도움이 되지 않는 일이지만, 어떤 이유에서인지 우리 조직에서 해야 합니다.

Jeff: 그런 다음 다음과 같은 항목을 식별합니다. 이것을 단순화하기 위해 우리가 무엇을 할 수 있습니까?” 그리고 일부 기준은 프로세스의 위험이었습니다. 오른쪽. 자동화된 데이터베이스 장애 조치는 자주 수행하지 않기 때문에 약간 무섭습니다. 그리고 인프라가 변경됩니다. 오른쪽. 우리는 "얼마나 자주 이 일을 하고 있습니까?"라고 말합니다. 1년에 한 번 수행한다면 자동화할 가치가 거의 없기 때문에 자동화할 가치가 없을 수 있습니다. 하지만 그것이 우리가 한 달에 두세 번 받는 것 중 하나라면, 좋습니다. 한번 살펴보겠습니다. 괜찮아.

Jeff: 이제 속도를 높이기 위해 우리가 할 수 있는 일은 무엇입니까? 그리고 문제는 자동화에 대해 이야기할 때 우리는 즉시 "버튼을 클릭하면 이 일이 마술처럼 완료될 것입니다."라고 말했습니다. 오른쪽. 하지만 불안하다면 자동화에서 할 수 있는 다양한 단계가 있습니다. 오른쪽. 예를 들어 일반적으로 실행하는 10개의 다른 CLI 명령과 함께 10개의 단계가 있다고 가정해 보겠습니다. 자동화의 첫 번째 단계는 해당 명령을 실행하거나 최소한 해당 명령을 표시하는 것처럼 간단할 수 있습니다. 오른쪽. "이봐, 이것이 내가 실행할 일이다. 괜찮은 것 같아?” "네." "괜찮아. 이것이 내가 얻은 결과입니다. 제가 진행해도 될까요?” "네." "괜찮아. 이것이 내가 얻은 결과입니다.” 오른쪽.

Jeff: 그렇게 하면 여전히 약간의 제어가 가능합니다. 당신은 편안함을 느낍니다. 그리고 20번의 처형 후에, 당신은 당신이 그냥 치고 있다는 것을 깨닫습니다. 예, 예, 예, 예, 예, 예. 당신은 말합니다, "알았어. 이 모든 것을 하나로 묶어서 하나로 만들자.” 그것은 당신이 깊숙한 곳으로 뛰어 들어 그것을 클릭하고 찢어진 곳에서 바로 잊어 버려야하는 것과 다릅니다. 편안함을 느낄 때까지 단계를 밟을 수 있습니다.

Jeff: 자동화 작업의 일환으로 수행한 작업 유형은 간단합니다. 처리 시간을 단축하고 작업 수준을 줄이는 방법은 무엇입니까? 첫날은 100%가 아닐 수도 있지만 목표는 항상 100%에 도달하는 것입니다. 우리는 우리가 편안하다고 느끼는 부분을 자동화할 작은 청크로 시작할 것입니다. 네. 우리는 이것이 효과가 있을 것이라고 확신합니다. 이 부분은 우리가 약간 까다롭기 때문에 진행하기 전에 사람의 확인을 받아야 할 것입니다.

Jeff: 자동화에 대해 이야기하면서 살펴봤던 또 다른 사항은 특정 프로세스에 어떤 가치를 더하고 있습니까? 그리고 이것은 특히 ops에서 두드러집니다. 많은 경우 op가 프로세스의 중개자 역할을 하기 때문입니다. 그렇다면 그들의 참여는 액세스 문제에 지나지 않습니다. 오른쪽. ops가 액세스 권한이 있는 유일한 사람이기 때문에 ops가 수행해야 하는 것과 같습니다.

Jeff: 글쎄요, 사람들이 할 수 있도록 액세스 권한을 어떻게 아웃소싱합니까? 현실은 개발자가 프로덕션 액세스 권한을 갖는 것에 대해 걱정하는 것이 아니기 때문입니다. 오른쪽. 우리는 개발자가 제한 없는 프로덕션 액세스 권한을 갖는 것에 대해 걱정하고 있습니다. 그리고 그것은 정말로 안전에 관한 것입니다. 오른쪽. 내 도구 상자에 날카로운 칼만 있다면 그것을 누구에게 줄지 매우 조심해야 하는 것과 같습니다. 그러나 사람들이 작업에 적합한 도구를 선택할 수 있도록 도구 상자를 숟가락과 망치와 섞어서 사용할 수 있다면 그것을 빌려주는 것이 훨씬 쉽습니다.

Jeff: 예를 들어, 사람들이 어떤 이유로든 프로덕션 환경에서 임시 Ruby 스크립트를 실행해야 하는 프로세스가 있었습니다. 오른쪽. 데이터를 정리해야 하고, 잘못된 기록을 수정해야 합니다. 그리고 그것은 항상 내 팀을 통해 올 것입니다. 이 티켓을 승인할 수 없기 때문에 여기에 가치를 추가하지 않습니다. 오른쪽. 나는 아무 생각이 없다. 당신이 소프트웨어를 작성했는데 내가 당신의 어깨 위에 앉아서 "글쎄, 나는 그것이 안전하다고 생각합니다"라고 말하는 것이 무슨 소용이 있습니까? 오른쪽. 나는 당신이 입력하라고 말한 것을 정확히 입력하고 있기 때문에 입력에 값을 추가하지 않았습니다. 오른쪽.

Jeff: 그리고 최악의 경우입니다. 결국 당신이 티켓을 제출하고 내가 점심을 먹고 돌아오기를 기다리고 있기 때문에 저는 정말 당신을 위한 장애물일 뿐입니다. 점심을 먹고 돌아왔지만 다른 할 일이 있습니다. 우리는 "이를 개발자에게 제공하는 동시에 우리가 가질 수 있는 이러한 감사 문제를 해결할 수 있도록 이 작업을 어떻게 자동화합니까?"라고 말했습니다.

Jeff: JIRA 티켓에 지정된 명령 실행을 자동화하는 봇이 있는 JIRA 워크플로에 넣었습니다. 그런 다음 JIRA 티켓에 여러 선임 엔지니어 중 한 명의 승인이 필요하다고 지정할 수 있습니다. 오른쪽.

Jeff: 엔지니어가 컨텍스트를 가지고 있기 때문에 엔지니어가 다른 엔지니어의 작업을 승인하는 것이 더 합리적입니다. 오른쪽. 그들은 작업을 기다리며 주위에 앉아 있을 필요가 없습니다. 누군가가 요청한 대로 누군가가 승인할 때 문서화되고 있는 JIRA에 정의된 명확한 워크플로가 있기 때문에 감사 부분에 대한 답변이 제공됩니다. 그리고 우리는 그 명령을 가져와 터미널에서 그 명령을 그대로 실행하는 자동화가 있습니다. 오른쪽.

Jeff: 내가 잘못 입력한 것에 대해 걱정할 필요가 없습니다. 내가 티켓을 잘못 잡았다고 걱정할 필요는 없습니다. 그 결과 티켓의 처리 시간이 10배 증가했습니다. 오른쪽. 개발자는 차단 해제됩니다. 우리 팀은 이 일에 얽매이지 않습니다. 실제로 자동화를 개발하고 자동화에 대한 액세스를 얻는 데 필요한 권한을 부여하는 데 1~2주 투자했습니다.

Jeff: 이제 완전히 제거되었습니다. 그리고 개발은 실제로 그 기능의 일부를 조직의 하위 부분에 아웃소싱할 수 있습니다. 그들은 그것을 고객 관리에 밀어 넣었습니다. 고객 관리 부서에서 이 레코드가 무엇이든 업데이트해야 하고 개발이 필요하지 않다는 것을 알고 있는 것과 같습니다. 그들은 우리가 이 기능에 대해 승인한 표준 스크립트를 제출할 수 있습니다. 그리고 그들은 개발과 똑같은 워크플로를 통해 그것을 실행할 수 있습니다. 정말 주위에 은혜입니다.

Jeff: 그러면 조직 전체에서 업무를 점점 더 낮추게 됩니다. 그렇게 하면 이 작업을 실행하는 멋지고 값비싼 개발자가 있기 때문에 작업이 더 저렴해지고 저렴해집니다. 오른쪽. 또는 고객과 직접 작업하는 고객 관리 담당자가 문제를 수정하는 고객과 통화하는 동안 직접 실행하도록 할 수 있습니다.

Jeff: 자동화는 모든 조직의 핵심이라고 생각합니다. 제가 마지막으로 말씀드릴 요점은 전문 지식을 내보낼 수도 있다는 것입니다. 오른쪽. 이제 명령줄에서 많은 명령을 수행해야 하는 경우 이 작업을 수행하는 방법을 알고 있는 유일한 사람일 수 있습니다. 하지만 이것을 자동화에 넣으면 누구에게나 줄 수 있습니다. 그리고 사람들은 최종 결과가 무엇인지 알고 있지만 모든 중간 단계를 알 필요는 없습니다. 나는 그것을 조직에 전달하고 내 전문 지식을 가져 와서 내보낼 수 있는 것으로 코드화함으로써 내 가치를 10배나 늘렸습니다.

Drew: 자주 발생하는 작업을 자동화하는 것에 대해 말씀하셨습니다. 너무 드물게 발생하는 작업을 자동화하여 개발자가 작업 속도를 다시 파악하는 데 꽤 오랜 시간이 걸린다는 주장이 있습니까? 모두가 잊었기 때문입니다. 너무 오래되었습니다. 1년이 지났는데 아마 아무도 해보지 않았을 것입니다. 그런 종류의 일을 자동화하는 것에 대한 논쟁도 있습니까?

Jeff: 균형 잡기가 힘든 작업입니다. 오른쪽. 그리고 저는 항상 케이스 바이 케이스로 가져가라고 말합니다. 제가 그렇게 말하는 이유는 DevOps의 진언 중 하나가 고통스러운 일이라면 더 자주 하라는 것입니다. 오른쪽. 더 자주 할수록 더 많은 근육 기억이 생겨 운동을 하고 이러한 꼬임을 고칠 수 있기 때문입니다.

Jeff: 매우 드물게 발생하는 작업을 자동화할 때 볼 수 있는 문제는 해당 자동화 실행 사이에 환경 환경이 변경되는 경향이 있다는 것입니다. 오른쪽. 결국 발생하는 것은 코드가 환경에 대한 특정 가정을 하고 이러한 가정이 더 이상 유효하지 않다는 것입니다. 따라서 자동화는 결국 중단됩니다.

Drew: 그리고 두 가지 문제가 있습니다.

제프: 맞아. 오른쪽. 정확히. 정확히. 그리고 당신은 "제가 잘못 입력했나요? 아니면 이것은? 아니, 이것은 실제로 고장났습니다.” 그래서-

Jeff: 잘못 입력했거나 이것이 아니요, 이것은 실제로 고장난 것입니다. 따라서 자주 발생하지 않는 작업을 자동화할 때 우리는 실제로 사례별로 이해하여 이것이 작동하지 않을 경우 어떤 위험이 있는지 이해합니다. 잘못 이해하면 상태가 좋지 않은 것입니까, 아니면 이 작업을 완료하지 않았기 때문입니까? 따라서 이것이 정상적으로 실패하고 부정적인 영향을 미치지 않도록 할 수 있다면 자동화를 시도해 볼 가치가 있습니다. 왜냐하면 최소한 누군가가 코드를 읽고 이해할 수 있을 것이기 때문에 무슨 일이 진행되어야 하는지에 대한 이해의 틀이 있기 때문입니다. 알겠습니다. 이것이 우리가 하고 있는 일입니다. 그리고 이것이 더 이상 작동하지 않는 이유를 이해하지 못하지만 이것이 작성되었을 때 적어도 디자인 타임에 기반하여 어떤 일이 일어나기로 되어 있었는지 명확하게 이해하고 있습니다.

Jeff: 하지만 실패로 인해 데이터가 변경되거나 이와 유사한 상황에 처한 경우 일반적으로 주의를 기울이지 않고 수동으로 유지합니다. 자동화 스크립트가 있고 합류 문서를 찾을 수 있기 때문입니다. 이 스크립트를 실행하는 것은 3년 전의 일입니다. 저는 그 스크립트를 100% 신뢰하고 실행하는 경향이 있습니다. 오른쪽. 4년 전에 문서화된 일련의 수동 단계인 경우 여기에서 약간의 확인을 수행해야 합니다. 오른쪽? 이 단계를 조금 진행하고 몇 사람과 이야기하겠습니다. 그리고 때때로 우리가 프로세스를 디자인할 때, 그 사고 프로세스를 강요하는 것은 가치가 있습니다, 그렇죠? 그리고 당신은 인간의 구성요소와 그들이 어떻게 행동할 것인지에 대해 생각해야 합니다. 그리고 때때로 사람들이 지금 이 일을 해야 한다고 생각하게 하기 위해 프로세스를 좀 더 복잡하게 만드는 것이 가치가 있습니까?

Drew: 일종의 시스템 모니터링 및 측정을 통해 자동화해야 할 항목을 식별하는 다른 방법이 있습니까? 제 말은, 저는 DevOps에 대해 생각하고 대시보드를 좋은 그래프 중 하나로 생각합니다. 그리고 그 대시보드에는 단순히 아름답게 보이는 것보다 훨씬 더 많은 것이 있다고 확신하지만, 보기 좋은 대시보드를 갖는 것은 항상 좋은 일입니다. 그러한 종류의 결정을 내리는 데 도움이 되도록 시스템의 상태를 측정하는 방법이 있습니까?

제프: 물론입니다. 그리고 그런 종류는 캠의 메트릭 부분으로 이어집니다. 그렇죠. 우리가 시스템이 효율적으로 작동하는지 알기 위해 추적하는 것은 무엇입니까? 메트릭의 일반적인 함정 중 하나는 성공을 확인하는 대신 오류를 찾는 것입니다. 그리고 그것은 매우 다른 두 가지 관행입니다. 맞습니까? 따라서 시스템을 통해 무언가가 흐를 수 있고 반드시 오류가 발생하는 것은 아니지만 전체 프로세스를 정상적으로 진행해야 하는 것은 아닙니다. 따라서 메시지 대기열에 메시지를 드롭하면 "이 메시지는 검색 및 처리되었습니다."라는 해당 메트릭이 있어야 합니다. 그렇지 않다면 곧 불균형이 생기고 시스템이 제대로 작동하지 않을 것입니다. 나는 우리가 나쁜 상태에 빠질 때 자동화되어야 하는 다양한 것들을 이해하는 방법으로 메트릭을 사용할 수 있다고 생각합니다.

제프: 그렇지? 많은 경우 정리를 위해 취해야 하는 매우 간단한 단계이기 때문입니다. 그렇죠? 잠시 동안 작업을 수행한 사람들에게는 맞습니다. 디스크 공간 경고, 모두가 그것에 대해 알고 있습니다. 오, 디스크가 가득 찼습니다. 오, 우리는 월말과 청구가 실행되고 청구가 항상 로그를 채운다는 것을 잊어버렸습니다. 그리고 VAR 로그가 모든 디스크 공간을 소비하므로 로그 회전을 실행해야 합니다. 오른쪽? 당신의 취향에 따라 그것을 위해 새벽 3시에 일어날 수도 있습니다. 그러나 그것이 행동이라는 것을 우리가 알고 있다면, 우리의 메트릭은 우리에게 그것에 대한 단서를 줄 수 있어야 합니다. 그리고 우리는 단순히 로그 회전 명령을 자동화할 수 있습니다. 그렇죠? 아, 이 임계값에 도달했습니다. 로그 회전 명령을 실행하십시오. 경보가 해제되는지 봅시다. 그렇다면 삶을 계속하십시오. 그렇지 않다면 우리가 누군가를 깨울 수도 있습니다. 맞죠.

Jeff: 인프라 자동화에서도 이를 훨씬 더 많이 볼 수 있습니다. "초당 요청이 이론적 최대값에 도달하고 있습니까? 클러스터를 확장해야 할 수도 있습니다. 로드 밸런서 풀에 3~4개의 노드를 추가해야 할 수도 있습니다." 누군가 개입할 필요 없이 그렇게 할 수 있습니다. 우리는 이러한 메트릭을 보고 해당 조치를 취한 다음 특정 임계값 아래로 내려가면 해당 인프라를 계약할 수 있지만 이러한 메트릭이 있어야 하고 모니터링 환경에 연결해야 그렇게 할 수 있습니다. 그리고 여기에서 대화의 전체 메트릭 부분이 시작됩니다.

Jeff: 또한 다른 사람들과 그 정보를 공유할 수 있다는 점도 좋습니다. 데이터가 있으면 공유된 현실에서 이야기를 시작할 수 있기 때문입니다. 그렇죠. 바쁘다는 것은 일반적인 용어이지만 초당 5,200개 요청은 상당한 수준이기 때문입니다. 우리 모두가 추론할 수 있는 더 구체적입니다. 그리고 제 생각에 용량이나 기타 사항에 대해 대화를 나눌 때 이런 손으로 휘두르는 용어를 사용합니다. 대신 대시보드를 보고 매우 구체적인 값을 제공하고 모든 사람이 해당 대시보드에 액세스할 수 있도록 할 수 있습니다. 그들은 알 수 없는 이유로 우리만 접근할 수 있는 일부 작전 벽 뒤에 숨겨져 있지 않습니다.

Drew: So while sort of monitoring and using metrics as a decision-making tool for the businesses is one aspect of it, it sounds like the primary aspect is having the system monitor itself, perhaps, and to respond maybe with some of these automations as the system as a whole gives itself feedback on onto what's happening.

Jeff: Absolutely. Feedback loops are a key part of any real system design, right, and understanding the state of the system at any one time. So while it's easy in the world where everything is working fine, the minute something goes bad, those sorts of dashboards and metrics are invaluable to have, and you'll quickly be able to identify things that you have not instrumented appropriately. 오른쪽. So one of the things that we always talk about in incident management is what questions did you have for the system that couldn't be answered, right. So what is it, or you're like, “Oh man, if we only knew how many queries per second were going on right now.” 오른쪽.

Jeff: Well, okay. How do we get that for next time? How do we make sure that that's radiated somewhere? And a lot of times it's hard when you're thinking green field to sit down and think of all the data that you might want at any one time. But when you have an incident, it becomes readily apparent what data you wish you had. So it's important to sort of leverage those incidents and failures and get a better understanding of information that's missing so that you can improve your incident management process and your metrics and dashboarding.

Drew: One of the problems we sometimes face in development is that teammate members, individual team members hold a lot of knowledge about how a system works and if they leave the company or if they're out sick or on vacation, that knowledge isn't accessible to the rest of the team. It seems like the sort of DevOps approach to things is good at capturing a lot of that operational knowledge and building it into systems. So that sort of scenario where an individual has got all the information in their head that doesn't happen so much. 그것이 공정한 평가입니까?

Jeff: It is. I think we've probably, I think as an industry we might have overstated its efficacy. And the only reason I say that is when our systems are getting so complicated, right? Gone are the days where someone has the entire system in their head and can understand it from beginning to end. Typically, there's two insidious parts of it. One, people typically focus on one specific area and someone doesn't have the whole picture, but what's even more insidious is that we think we understand how the system works. 오른쪽. And it's not until an incident happens that the mental model that we have of the system and the reality of the system come into conflict. And we realize that there's a divergence, right? So I think it's important that we continuously share knowledge in whatever form is efficient for folks, whether it be lunch and learns, documentation, I don't know, presentations, anything like that to sort of share and radiate that knowledge.

Jeff: But we also have to prepare and we have to prepare and define a reality where people may not completely understand how the system works. 오른쪽. And the reason I think it's important that we acknowledge that is because you can make a lot of bad decisions thinking you know how the system behaves and being 100% wrong. 오른쪽. So having the wherewithal to understand, okay, we think this is how the system works. We should take an extra second to verify that somehow. 오른쪽. I think that's super important in these complicated environments in these sprawling complex microservice environments. Whereas it can be very, it's easy to be cavalier if you think, oh yeah, this is definitely how it works. And I'm going to go ahead and shut the service down because everything's going to be fine. And then everything topples over. So just even being aware of the idea that, you know what, we may not know a hundred percent how this thing works.

Jeff: So let's take that into account with every decision that we make. I think that's key. And I think it's important for management to understand the reality of that as well because for management, it's easy for us to sit down and say, “Why didn't we know exactly how this thing was going to fail?” And it's like, because it's complicated, right, because there's 500 touch points, right, where these things are interacting. And if you change one of them, it changes the entire communication pattern. So it's hard and it's not getting any easier because we're getting excited about things like microservices. We're getting excited about things like Kubernetes. We're giving people more autonomy and these are just creating more and more complicated interfaces into these systems that we're managing. And it's becoming harder and harder for anyone to truly understand them in their entirety.

Drew: We've talked a lot about a professional context, big organizations and small organizations too. But I know many of us work on smaller side projects or maybe we volunteer on projects and maybe you're helping out someone in the community or a church or those sorts of things. Can a DevOps approach benefit those smaller projects or is it just really best left to big organizations to implement?

Jeff: I think DevOps can absolutely benefit those smaller projects. And specifically, because I think sort of some of the benefits that we've talked about get amplified in those smaller projects. 오른쪽? So exporting of expertise with automation is a big one, right? If I am… Take your church example, I think is a great one, right? If I can build a bunch of automated tests suites to verify that a change to some HTML doesn't break the entire website, right, I can export that expertise so that I can give it to a content creator who has no technical knowledge whatsoever. 오른쪽. They're a theologian or whatever, and they just want to update a new Bible verse or something, right. But I can export that expertise so that they know that I know when I make this content change, I'm supposed to run this build button.

Jeff: And if it's green, then I'm okay. And if it's red, then I know I screwed something up. 오른쪽. So you could be doing any manner of testing in there that is extremely complicated. 오른쪽. It might even be something as simple as like, hey, there's a new version of this plugin. And when you deploy, it's going to break this thing. 오른쪽. So it has nothing to do with the content, but it's at least a red mark for this content creator to say “Oh, something bad happened. I shouldn't continue. 오른쪽. Let me get Drew on the phone and see what's going on.” 오른쪽. And Drew can say, “Oh right. This plugin is upgraded, but it's not compatible with our current version of WordPress or whatever.” 오른쪽. So that's the sort of value that we can add with some of these DevOps practices, even in a small context, I would say specifically around automation and specifically around some of the cultural aspects too.

Jeff: Right? So I've been impressed with the number of organizations that are not technical that are using get to make changes to everything. 오른쪽. And they don't really know what they're doing. They just know, well, this is what we do. This is the culture. And I add this really detailed commit message here. And then I push it. They are no better than us developers. They know three get commands, but it's the ones they use over and over and over again. But it's been embedded culturally and that's how things are done. So everyone sort of rallies around that and the people that are technical can take that pattern.

Jeff: … around that and the people that are technical can take that pattern and leverage it into more beneficial things that might even be behind the scenes that they don't necessarily see. So I think there's some value, definitely. It's a matter of how deep you want to go, even with the operations piece, right? Like being able to recreate a WordPress environment locally very easily, with something like Docker. They may not understand the technology or anything, but if they run Docker Compose Up or whatever, and suddenly they're working on their local environment, that's hugely beneficial for them and they don't really need to understand all the stuff behind it. In that case, it's worthwhile, because again, you're exporting that expertise.

Drew: We mentioned right at the beginning, sort of putting off as much sort of DevOps as possible. You mentioned using tools like Heroku. And I guess that sort of approach would really apply here on getting started with, with a small project. What sort things can platforms like Heroku offer? I mean, obviously, I know you're not a Heroku expert or representative or anything, but those sorts of platforms, what sort of tools are they offering that would help in this context?

Jeff: So for one, they're basically taking that operational context for you and they're really boiling it down into a handful of knobs and levers, right? So I think what it offers is one, it offers a very clear set of what we call the yellow brick road path, where it's like, “If you go this route, all of this stuff is going to be handled for you and it's going to make your life easier. If you want to go another route, you can, but then you got to solve for all this stuff yourself.” So following the yellow brick road route helps because one, they're probably identifying a bunch of things that you hadn't even thought of. So if you're using their database container or technology, guess what? You're going to get a bunch of their metrics for free. You're going to get a lot of their alerting for free. You didn't do anything. You didn't think anything. It's just when you need it, it's there. And it's like, “Oh wow, that's super are helpful.”

Jeff: Two, when it comes to performance sizing and flexibility, this becomes very easy to sort of manage because the goal is, you're a startup that's going to become wildly successful. You're going to have hockey stick growth. And the last thing you necessarily really want to be doing is figuring out how to optimize your code for performance, while at the same time delivering new features. So maybe you spend your way out of it. You say, “Well, we're going to go up to the next tier. I could optimize my query code, but it's much more efficient for me to be spending time building this next feature that's going to bring in this new batch of users, so let's just go up to the next tier,” and you click button and you move on.

Jeff: So being able to sort of spend your way out of certain problems, I think it's hugely beneficial because tech debt gets a bad rap, but tech debt is no different than any debt. It's the trade off of acquiring something now and dealing with the pain later. And that's a strategic decision that you have to make in every organization. So unchecked tech debt is bad, right? But tech debt generally, I think, is a business choice and Heroku and platforms like that enable you to make that choice when it comes to infrastructure and performance.

Drew: You've written a book, Operations, Anti-Patterns, DevOps Solutions, for Manning. I can tell it's packed with years of hard-earned experience. The knowledge sort of just leaps out from the page. And I can tell it's been a real labor of love. It's packed full of information. Who's your sort of intended audience for that book? Is it mostly those who are already working in DevOps, or is it got a broader-

Jeff: It's got a broader… So one of the motivations for the book was that there were plenty of books for people that we're already doing DevOps. 무슨 말인지 알아? So we were kind of talking to ourselves and high-fiving each other, like, “Yeah, we're so advanced. 엄청난." But what I really wanted to write the book for were people that were sort of stuck in these organizations. I don't want to use the term stuck. That's unfair, but are in these organizations that maybe aren't adopting DevOps practices or aren't at the forefront of technology, or aren't necessarily cavalier about blowing up the way they do work today, and changing things.

Jeff: 주로 개별 기여자와 중간 관리자에게 다음과 같이 말하고 싶었습니다. DevOps의 일부 이점을 얻을 수 있는 전체 판매 혁명입니다." 그래서 그들에게 이렇게 말하는 것은 일종의 러브레터였습니다. 직접 할 수 있습니다. 그리고 DevOps를 도구 및 Kubernetes로 생각하기 때문에 DevOps와 관련이 없다고 생각할 수 있는 이 모든 것들이 있습니다.” 모든 조직은 아닙니다... 주 정부와 같이 이 뉴욕주를 위한다면 하룻밤 사이에 Kubernetes를 구현하지 않을 것입니다. 오른쪽? 그러나 팀이 서로 대화하는 방법, 협력하는 방법, 서로의 문제를 이해하는 방법, 자동화를 통해 이러한 문제를 해결하는 방법을 구현할 수 있습니다. 일상 생활을 개선할 수 있는 영향력 범위 내에 있는 것들입니다.

Jeff: 정말이지 그 사람들에게 보내는 편지였습니다. 하지만 거기에는 DevOps 조직에 있는 사람들이 “이봐, 이것은 여전히 ​​우리에게 유용합니다. " 그리고 많은 사람들이 이 책을 읽고 DevOps 조직에 속해 있지 않고 직책을 변경해야 한다는 사실을 빠르게 식별할 수 있다고 생각합니다. 그리고 그것은 꽤 많이 발생합니다. 그래서 그들은 이렇게 말합니다. "이제 우리는 DevOps 엔지니어지만 이 책에서 이야기하는 이러한 종류의 관행을 하고 있지 않으며 어떻게 해야 합니까?"

Drew: 당신의 책이 그 중 하나인 것 같지만 DevOps를 시작하려는 사람들이 참고할 수 있는 다른 리소스가 있습니까? 이런 것들을 배울 수 있는 좋은 곳이 있나요?

제프: 네. Emily Freeman의 DevOps For Dummies는 시작하기에 좋은 곳이라고 생각합니다. 핵심 개념과 아이디어, 그리고 우리가 추구하는 바를 정리하는 데 정말 훌륭합니다. 그래서 그것은 시작하기에 좋은 장소가 될 것입니다. 피닉스 프로젝트는 분명히 Gene Kim의 또 다른 훌륭한 소스라고 생각합니다. 그리고 훌륭합니다. DevOps 환경에 있지 않을 때 발생할 수 있는 문제 유형에 대한 단계를 설정합니다. 그리고 그것은 우리가 모든 유형의 조직에서 계속해서 볼 수 있는 이러한 패턴과 성격을 강조하는 훌륭한 일을 합니다. 그런 부분들을 부각시켜주는 역할을 하는 것 같아요. 그리고 만약 당신이 그 책을 읽는다면, 나는 당신이 페이지에서 "네, 그렇습니다. 이. 이." 그래서, 그것은 또 다른 좋은 장소입니다.

Jeff: 그런 다음 DevOps 핸드북에 대해 자세히 알아보겠습니다. 이런 말을 해서 기분이 나빴지만 Google SRE 핸드북은 또 다른 멋진 곳이었습니다. 귀하가 Google이 아니므로 모든 것을 구현해야 한다고 생각하지는 마세요. 하지만 Google의 아이디어와 전략 중 많은 부분이 어떤 조직에도 적합하며, "알겠습니다. 운영 환경을 좀 더 효율적으로 만들겠습니다."라고 말합니다. 즉, 운영 역할을 하는 개발자에게 특히 두드러질 것이라고 생각합니다. 이러한 문제 중 일부를 해결하기 위한 프로그래밍 방식의 접근 방식에 초점을 맞추기 때문입니다.

Drew: 그래서 저는 DevOps에 대해 모두 배웠습니다. 최근에 무엇을 배웠습니까, 제프?

제프: 쿠버네티스. 응. Kubernetes는 우리에게 일종의 독서와 지식의 원천이었습니다. 그래서 우리는 현재 Centro에서 개발자에게 권한을 부여하는 수단으로 이를 구현하려고 합니다. 우리는 우리가 있는 곳에서 한 걸음 더 나아가고자 합니다. 우리는 많은 자동화를 갖추고 있지만 현재 새 서비스를 온보딩하는 것과 관련하여 우리 팀은 서비스의 특성에 따라 여전히 그것에 상당히 관여하고 있습니다. 그리고 우리는 그 일을 하고 싶지 않습니다. 우리는 개발자가 개념에서 코드, 배포에 이르기까지 아이디어를 취할 수 있기를 원하며 시스템 내에서 운영 전문 지식이 성문화된 곳에서 그렇게 할 수 있기를 바랍니다. 따라서 시스템을 통해 이동할 때 시스템이 사용자를 안내합니다. 그래서 우리는 Kubernetes가 그렇게 하는 데 도움이 될 도구라고 생각합니다.

Jeff: 엄청나게 복잡합니다. 그리고 그것은 일종의 물린 큰 조각입니다. 배포가 어떻게 생겼는지 알아볼까요? Kubernetes 내에서 이러한 운영자를 어떻게 활용합니까? 이 새로운 세상에서 CICD는 어떤 모습일까요? 그래서 많이 읽었는데 이 분야에서 계속 배우고 있는 거잖아요? 당신이 그 분야에 얼마나 오래 있었는지, 얼마나 오랫동안 그 일을 했는지는 중요하지 않습니다. 당신은 이 분야의 어딘가 어딘가에서 바보입니다. 그래서, 그것은 당신이 적응하는 것입니다.

Drew: 글쎄요. 몇 년이 지난 후에도 스택의 위치를 ​​어느 정도 이해하긴 했지만 Kubernetes가 무엇을 하고 있는지는 전혀 모릅니다.

제프: 나도 가끔 비슷해. 모든 것을 조금씩 하고 있는 것 같죠? 21세기 DNS입니다.

Drew: 청취자인 당신이 Jeff에게서 더 많은 정보를 듣고 싶다면 그가 어둡고 괴상한 Twitter에서 그를 찾을 수 있으며 그의 책과 과거 프레젠테이션 및 블로그 게시물에 대한 링크는 그의 사이트인 arrivalabledevops.com에서 찾을 수 있습니다. 오늘 함께해주셔서 감사합니다, 제프. 이별의 말은 없었나요?

Jeff: 계속 배우고, 그냥 나가서, 계속 배우고 동료들과 이야기하십시오. 얘기해, 얘기해, 얘기해 함께 일하는 사람들과 대화를 많이 할수록 이해도가 높아지고 공감도 더 잘 되며, 조직 내에서 특히 싫어하는 사람이 있다면 먼저 말을 걸어야 합니다.