collaboration devops
DevOps에서의 협업 :
DevOps에서 소량의 전송 증가 이전 튜토리얼에서 자세히 설명했습니다.
DevOps의 핵심은 협업이라는 것을 알고 있습니다. 따라서 DevOps라는 단어가 도착했습니다.
읽어보기 => 심층 DevOps 자습서
협업은 프로그램의 모든 문제를 해결하기 위해 하나의 팀으로 모이는 것입니다. 이로 인해 프로그램 목표 유지 고객의 집중을 방해하고 비난없이 가능한 한 빨리 자신의 문제로 소유함으로써 문제를 해결합니다.
협업은 모든 사람에게 서로 대화하고, 얼굴을 맞대고 만나고, 회의, 토론에 서로 참여하고, 서로의 작업을 이해하고, 의존하고, 업무에 투명성을 유지하고, 문제를 예방하기 위해 사전에 작업하도록 가르칩니다.
비디오 파트 2 블록 5 : 협업 – 15 분 36 초
성적 증명서:
협업이라는 용어는 DevOps에서 계속해서 반복되며 Devops의 만트라는 협업입니다. 이제 소프트웨어 개발 및 DevOps 컨텍스트에서 '협업'이 실제로 무엇을 의미하는지 이해하겠습니다.
펜을 어떻게 시험 해볼래
제 말에 따르면, 조직이 말하는 즉시 DevOps를 구현하고 있습니다. 자동으로 devops 연습에 연결된 협업에 대한 생각이 모든 사람의 마음에서 시작되고 협업에 더 집중하고 경계하게 만들고 협업이 필요하다고 느끼기 시작합니다. . 이것이 바로 협업의 마법입니다.
따라서 프로젝트 시작부터 DevOps 협업을 시작하는 것은 조직과 팀에 매우 중요합니다. 내 말은, 프로그램의 팀원입니다.
DevOps 컨텍스트에서 실제로 협업이 무엇을 의미하는지 알 수 있도록 Dev가 Ops와 협업하고 Ops가 개발팀과 협업하는 것을 본 몇 가지 사례를 설명하겠습니다.
이것은 인스턴스 1의 표현입니다.
운영팀이 특정 지역의 특정 클러스터 설정에 소프트웨어를 설치하는 데 문제를 발견 한 설치 스크립트 또는 구성 스크립트에 알 수없는 문제가있는 경우가있었습니다.
알 수없는 오류가 발생했고 개발 환경에서는 발생하지 않았던 순수한 프로덕션 문제였으며 운영 팀은 설정과 관련된 문제라고 생각하고 해결해야한다고 스스로 해결하는 데 많은 노력을 기울였습니다. 그것은 꽤 오랫동안 해결되지 않았습니다.
그런 다음 즉시 Dev 팀이 도움을 요청하지 않고 참여했습니다. 시간대는 다르지만 프로덕션 사이트를 제어했습니다. 일반적으로 프로덕션에 대한 액세스 권한이 모든 사람에게 제공되지는 않습니다. Ops는 오류를 공유합니다. 세부 사항 또는 팀이 디버깅 목적으로 필요한 기타 정보.
그러나이 상황은 실시간으로 문제를 분석하는 데 헌신적으로 몇 시간을 보냈고 즉각적인 해결 방법을 제공 한 개발 팀 구성원 중 한 명에게 액세스 권한을 부여해야하므로 문제가 신속하게 해결되었습니다.
이것은 개발 팀이 자발적으로 문제를 소유하고 운영 팀이 문제를 해결하도록 도왔던 협업의 한 예입니다. 이것은 순수한 협업 사례입니다.
마찬가지로, 다른 예에서 제가 그린 것을 다이어그램으로 보여 드리겠습니다. 또 다른 예는 특정 사이트에서 소프트웨어를 업그레이드 한 후 며칠 동안 작업이 잘 작동했고 갑자기 응용 프로그램의 성능이 저하되기 시작했습니다.
최종 사용자는 이러한 속도 저하로 인해 심각한 거래 손실에 직면하기 시작했습니다. 많은 불만 전화가 CSR에 전달되기 시작했습니다. 즉, 고객 서비스 담당자가 문제에 대해 팀과 후속 조치를 취하기 시작했습니다.
이 경우 즉시 개발팀과 운영팀이 함께 모였고 운영팀이 개발팀에 제공 한 정보 및 원격 측정 세부 정보를 바탕으로 문제를 디버깅하고 부하 공유 측면에 문제가 있음을 식별 할 수있었습니다. 따라서 성능이 느 렸습니다.
그래서 두 팀 모두 협력하여 문제를 해결하고 몇 시간 내에 정상 상태로 돌아 왔습니다. 그래서 여기에서 Dev와 Ops는 함께 나와서 문제를 해결하기 위해 함께 협력했습니다. Dev가 Ops 문제를 말하고 Ops는 Dev의 문제라고 생각하고 Dev 팀은이를보고 수정해야한다고 생각했습니다.
이것은 누구의 문제인지에 관계없이 비난 게임을하는 대신 모든 사람이 문제를 소유하고 최종 사용자가 고통을 받고 있으며 문제가 필요하다는 점을 염두에두고 누구의 문제인지 알아내는 데 시간을 낭비하는 명확한 협업 사례입니다. 곧 수정됩니다.
따라서 여기서도 문제는 프로덕션 문제 일 필요가 없으며, 일상적인 문제처럼 간단한 사내 소프트웨어 개발 문제, 디자인 문제, 아키텍처 문제 또는 단순한 문제 일 수 있습니다. 도구 문제.
프로그램과 관련된 문제 또는 팀이 고객에게 피해를 주거나 프로그램 속도를 늦추는 것으로 알고있는 문제는 개발 문제 또는 운영 문제 또는 테스트 문제라는 문제를 분리하는 대신 모든 사람이 소유해야합니다. 가능한 한 빨리 문제를 해결하는 데 기여하는 것이 협업입니다.
따라서 DevOps 컨텍스트에서의 협업은 개발 및 운영이 함께 결합되고 협력하여 가능한 한 빨리 문제를 해결하고 고객 초점을 염두에 두는 것입니다.
협업은 Dev와 Ops 모두가 라이브에서 일어나는 일을 소유하고, 모니터링 및 로깅과 성능 검사를 최우선으로하여 특히 최종 사용자의 이익을 위해 프로덕션에서 발생하는 문제를 해결하는 것입니다.
또는 간단히 말해서, 프로그램 목표를 달성하기 위해 문제를 해결하기 위해 지속적으로 협력하는 전체 팀이 공동 작업이라고 말할 수 있습니다. 반복합니다. 고객 중심을 염두에두고 프로그램 목표를 달성하기 위해 문제를 해결하기 위해 끊임없이 협력하는 것은 협업입니다.
그런 다음 질문이 생깁니다.이 협업을 어떻게 개발하고 서로 멀리 떨어져있는 팀 간의 협업을 언제 시작해야합니까 ??
분명히 우리는 Dev와 Ops가 같은 위치에있을 수 없다는 것을 알고 있습니다. 운영 팀은 작업 사이트 또는 데이터 센터에 더 가까워 야하고 개발자는 소프트웨어 개발 센터에 더 가까워 야합니다. 그렇다면 두 팀 간의 지속적인 협력을 어떻게 달성 할 수 있을까요 ??
우선 프로젝트 시작부터 DevOps 협업을 시작하는 것은 조직과 팀에 매우 중요합니다. 여기서 말하는 팀은 프로그램의 팀원입니다.
다음 몇 가지를 연습하면 팀 간의 격차를 해소하고 가상 팀의 제약을 극복하고 협업을 달성하는 데 도움이됩니다.
이제 협업을 달성하는 데 도움이되는 관행을 살펴 보겠습니다.
운영 팀의 모든 관련 회의 및 토론에 개발을 포함하고 그 반대의 경우도 마찬가지입니다.
이를 통해 이들을 하나로 모을뿐만 아니라 각 작업 영역, 일상적인 문제, 작업이 서로 어떻게 영향을 미치는지, 나중에 문제를 방지하기 위해 각 구성원이 처리해야하는 중요한 사항이 무엇인지 이해하는 데 도움이됩니다. 따라서 그들을 더 가깝게 만들고 매번 서로간에 편안한 토론을 시작합니다.
DevOps 사례를 도입하기 전에 개발 팀은 운영에 소프트웨어를 제공하는 데 전혀 신경 쓰지 않았습니다. 그들이 예전에 인프라, 구성, 서버 설정, 네트워크 구성, 라이브 공연 모니터링 등과 같은 것에 대해 무지하거나 전혀 신경 쓰지 않았다는 것을 알고 있습니다.
그들은 이러한 모든 활동이 운영팀의 책임이며 개발팀은 이에 대해 전혀 몰랐던 것이라고 생각했습니다. 이전에 개발 팀을위한 제공은 운영 팀에게만 제공하는 것을 의미했지만 DevOps 관행에서 제공은 운영뿐만 아니라 프로덕션으로 전달하는 것을 의미합니다.
마찬가지로 ops는 개발 팀이 생성하는 코드를 신경 쓰지 않았습니다. 소프트웨어 설치, 기능 또는 프로덕션 성능 문제 중에 직면하는 모든 문제는 단순히 개발 팀에 비용을 전달하고 수정하고 돌려달라고 요청했습니다.
따라서 서로의 작업을 알고 자신의 작업을 이해하고 사이클 전반에 걸쳐 서로 문제를 소유하는 것은 팀이 문제를 신속하게 해결하는 데 도움이됩니다.
그들은 문제가 어디에 있는지, 프로그램에서 무슨 일이 일어나고 있는지, 그리고 프로덕션에서 문제의 원인이 무엇인지 알고 있기 때문에 큰 어려움없이 직접 가서 수정할 수 있습니다.
따라서 협업이란 개발 팀이 인프라와 구성을 이해해야하고 운영 팀이 코드, 품질, 제공 및 일정에 대해 신경을 써야한다는 것을 의미합니다.
서로에 대한 의존성을 이해하면 작업 속도를 높이고 정시에 제공하는 데 도움이됩니다.
소프트웨어 설치와 마찬가지로 운영 팀은 설치와 관련된 문제를 해결하기 위해 개발 팀에 의존합니다. 마찬가지로, 코딩하는 동안 개발 팀은 운영 팀이 코딩 프로세스 중에주의를 기울이기 위해 제공하는 라이브에 존재하는 많은 전제 조건에 의존합니다.
다른 예 테스트 팀은 테스트를 위해 프로덕션에서 샘플 라이브 데이터를 제공하기 위해 운영 팀에 의존합니다. 개발 환경 등에서 설정할 환경 설정 세부 사항
따라서 두 팀은 서로 협력하고 서로에 대한 종속성을 이해하고 시간대 요인을 염두에두고 지연없이 데이터 또는 정보를 제때 제공해야합니다.
팀이 프로그램에 대한 모든 것을 이해하고 오해를 피하는 데 도움이되는 소스 제어 또는 버전 제어와 같은 DevOps 관행을 채택하여 투명성을 유지하십시오.
따라서 이것은 기본적으로 팀 내에서 투명성을 유지하는 것입니다.
팀 구성원은 개인 또는 특정 정보에 의존 할 필요가 없습니다. 누군가가 클러스터의 특정 노드에 설정된 구성을 알고 싶어하는지 말하면 운영 팀이 깨어날 때까지 기다릴 필요가 없습니다. 이러한 세부 정보를 제공하는 대신 버전 관리 도구로 이동하여이 정보를 가져 와서 지연없이 작업을 완료 할 수 있습니다.
특히 다른 사람의 실수로부터 배우는 것이 협업의 가장 큰 특징입니다. 이미 다른 사람이 저지른 실수를 반복하지 않도록합니다.
따라서 개발은 운영에서 배우고 운영은 새로운 기술, 도구 또는 더 간단하고 더 나은 방식으로 무언가를 수행하는 개발에서 배우는 것입니다. 둘 다 같은 페이지에 있으므로 서로 학습하여 서로 협력합니다.
운영은 항상 개발 팀이 매우 느리고 제 시간에 제공 할 수 없다고 느끼곤했습니다. 이제는 매일 개발 팀과 상호 작용하고 있기 때문에 지연의 원인을 이해합니다. 요구 사항, 설계 문제, 코딩 문제 또는 기타 도구 문제.
심지어 그들은 개선을위한 가치있는 제안을하고 있습니다.
또한 프로덕션 또는 개발 사이트에서 문제가 발생하는 경우 DevOps는이 문제를 도입 한 사람 또는 팀을 찾는 것보다 먼저 문제를 해결하는 문화를 도입합니다. 그래서 모든 사람들은 누가 문제의 원인인지 알아내는 데 시간을 낭비하기보다 문제 해결에 집중하려고합니다.
따라서 각자의 문제를 비난하지 말고 각자의 문제로 생각하고 함께 해결하고 문제를 지원하고 문제 동안 서로를 지원하는 것은 다시 공동 작업입니다.
그래서 게임을 비난하는 것을 그만두고 게임을 비난하는 것이 다시 한 번 협업의 특징이라고 말할 수 있습니다.
모두가 같은 방향으로 공통적으로 생각하기 시작하면, 같은 사고 방식과 같은 측면과 관행에 대한 작업은 새로운 기능이 개발 될 때마다 모든 사람이이를 테스트하는 방법, 배포 방법, 모니터링 방법, 협업입니다.
따라서 팀 내에서 공통적으로 생각하는 것이 다시 한 번 협업의 특징입니다.
이제 휴식을 취하고 다음 비디오에서 협업에 대해 조금 더 이해하겠습니다.
이전 튜토리얼 | NEXT 튜토리얼