DevOps 이동

[아카이브됨] 최종 업데이트 제작: 목, 16 4월 2026    소스
 

개발자에게 뿌리 접근권을 부여하는 것 이상의 것!

또는 그것도 아닙니다. 관련 리뷰: Big idea behind the… “이동” 단순히 개발자에게 더 많은 로프를 제공하는 것이 아닙니다.; 그것’개발자와 기업 내 운영 팀 간의 더 나은 커뮤니케이션 라인을 보장하는 방법에 대해 설명합니다. 이 중 대부분은 새로운 것이 아니라 사실’이전 세기 동안 전통적인 산업 (esp. 자동차) 공급망 내에서 kaizen 우호 운동의 재해시. 간판 보드는 고객과 비즈니스 파트너 모두를 만족시키는 고품질 제품을 배송하기 위한 일상적인 공동 노력을 다루는 조류 눈 대시보드(워크플로 재고 관리자로 두 배 증가)의 최신 재해시입니다.

제약 조건 관리는 프로세스의 핵심입니다. 먼저 시스템의 모든 병목 현상을 식별함으로써 이러한 리소스를 최적화하여 효과를 극대화하는 데 집중할 수 있습니다. 이러한 영역을 넘어서는 최적화는 거의 항상 귀찮게 할 가치가 없습니다. — 워크플로우는 여전히 해당 리소스에 의해 제한됩니다.

트렁크 기반 개발

일정이 잡힌 주기에서 자동화된 테스트, 프로모션 및 릴리스 프로세스를 통해 점진적 변화를 장려하는 것은 볼 롤링을 얻는 좋은 방법이지만, SaaS/PaaS 배포에서 품질 관리의 상당 부분은 채택과 관련이 있습니다. 트렁크 기반 개발 및 그 branch by abstraction 개념. (특징 및 단점에 대한 자세한 내용은 링크를 참조하십시오.).

본질적으로, 장기간의 다중우주(Multiverse of long-term) git 가지는 그 모든 지역 개발 작업 (및 테스트!)의 결합이 적어도 그 부분의 합만큼 큰 전체로 이어질 것이라는 심리적 소설을 만듭니다. 경험은 기존 프로덕션/릴리스 브랜치 소스 코드에서 광범위한 새로운 기능 세트를 incrementally, in-situ로 설계해야 함을 나타내는 더 나은 판단자입니다. 기본적으로, 당신은 생물학 세계의 물리학의 한계 내에서 개발 전략을 설계, 이는 말한다:

        Surgery on a patient must result
        in good outcomes (at all times) for
        that patient, not just for siblings
        or future generations.

CI/CD 파이프라인

트렁크 기반 개발은 지난 20년 동안 성장한 모든 결과 자동 변경 제어 파이프라인의 기초입니다.

Code Is Law(개발 + 인프라 + 구성).

약간 역사적인 관점 먼저; 펀치 라인은이 네 단락을 따릅니다. 이 부분의 본문은 아파치가 거의 항상 그 시간보다 앞서 왔다는 것입니다.

관련 리뷰: Back in the pre-CFEngine 일, 아파치 소프트웨어 재단은 모든 IT 구성 파일과 지원 스크립트를 CVS, 그리고 이후 Subversion에 보관했다. 또한 실행한 각 서비스는 “런북” 관리자를 실습 유지 관리 작업으로 안내합니다.

워크플로는 이상적이지 않았습니다. 로컬로 패치된 FreeBSD 포트 트리를 처음부터 배포 가능한(이진) 패키지로 구축하는 것 외에도 직원들은 버전 제어를 커밋하고, 대상 서버에 로그인하고, 체크아웃을 업데이트하고, 잠재적으로 서비스를 재시작함으로써 운영에 변경사항을 배포할 때 discipline을 적용하기가 어려워야 했습니다. — 이 모든 반복적인 수고는 손으로 이루어졌다. 실제로 대부분의 시스템 관리자는 대상 서버에서 직접 해킹하여 해당 서버에서 커밋한 경우’트리가 다시 업데이트됨에 따라 많은 병합 충돌이 발생할 위험이 있습니다(그때 또는 다른 직원에 의해 실행된 이후 작업으로 인해 특정 시점에). 협업 운영 팀을 위한 의심스러운 비밀번호 관리 보안을 갖춘 투명하지 않은 워크플로우입니다.

요즘은 모든 것을 A git-백업된 인형 소스 트리, 일반 업스트림 우분투 패키지를 사용하여 클라우드에 직접 프로비저닝/배포/구성(예정된 이후 IT-ops 작업에 다소 현대적인 접근 방식) git Puppet 마스터의 pull은 결국 Puppet 에이전트가 체크인할 때 업데이트를 배치합니다. 그러나 CI/CD는 현재까지도 진행 중인 작업입니다.

한편, ASF (실제 아파치 소프트웨어 TLP 프로젝트)의 초기 획기적인 CI와 같은 이니셔티브는 아파치 검프샘 루비와 같은 훌륭한 동료들의 두뇌 아이였다. 어떤 범프는 Subversion 저장소에있는 모든 코드베이스의 트렁크의 HEAD (모든 부서의 HEAD 포함)를 정기적으로 체크 아웃, 빌드 및 테스트했다 (그러나 CVS로 거슬러 올라가는 날짜) 모든 프로젝트에 대해 성공적으로 빌드하는 방법을 알아낼 수 있었다 (자바 프로젝트에 의해 및 원래 큰 제한). 보고서는 각 개발 커뮤니티에 자동으로 전송되고 후순위를 위해 보관되었습니다. 이 통찰력 있는 토일 자동화 활동은 현재까지 계속 진행되고 있습니다! 자체 Gump 서버를 실행하지 않는 모든 엔터프라이즈 규모의 개발 커뮤니티는 The ASF(IMO; don)의 최첨단 상태보다 20y 뒤처져 있습니다.’t는 /trunk|master/ …의 오픈 소스 버전 고정 소프트웨어 모듈 종속성을 시작합니다.

여기’s 요약의 요점: 모든 소스(개발, 인프라 및 구성)는 모든 DevOps 담당자가 검토할 수 있는 버전 제어(동일한 저장소를 공유하는 것은 아님)에 속하며 패치 개정과 운용 배치 간의 전체 테스트 자동화 파이프라인 집합의 일부입니다. IaC / CaC 설정에서 변경 사항을 테스트 / 프로비저닝 / 배포하는 예술의 상태에 대한 설문 조사는 내 친구이자 시각적인 Paul Hammant에 있습니다.’s 웹사이트 여기. 좀 봐 주세요!

가상화 대 컨테이너화: a 애완동물 vs. 가축 Redux

Docker와 같은 컨테이너 시스템은 일반적으로 쿠버네티스와 같은 MicroService 아키텍처(MSA) 애플리케이션 클러스터 프레임워크를 지원하는 데 사용되는 커스터마이징 가능한 재배포 가능한 가상화 기술입니다. 가상화 시스템이 중단된 곳에서 리눅스 커널 기반 VM을 위해 (완전히) 격리된 VM당 운영 체제에 대한 무제한 지원을 거래합니다.’s는 그들이 실행하는 부모 리눅스 호스트와 상당히 더 프로그래밍 가능한 사용자 정의 및 통합을 가지고 있습니다. 또한 여러 종속성 체인 및 원시 실행 서버 배포에서 광범위한 재사용을 위해 아티팩토리와 같은 중앙 배포 서비스에 재구축 및 업로드할 수 있습니다.

수직 및 수평 확장

중앙 서버에서 다운로드할 수 있는 재구성 가능한 컨테이너는 기본 가상화 기술로 실현하기 어려운 가능성을 제공합니다.’단일 서버에 고정됨’수요에 맞게 서비스를 확장하기 위한 하드웨어 제한 즉, 온디맨드 호스트 모음에 동일한 컨테이너를 배치하여 수평 확장은 Docker를 기반으로 즉시 달성 가능한 최고 수준의 MSA 프레임워크 기능입니다. same 호스트에 CPU 코어보다 수십 개의 컨테이너를 배포하는 것과 같습니다.

측정, 억제 및 제어 소방 노력, 실제 및 실행 모두

인식해야 할 또 다른 주요 사항 중 하나는 생산성 추적 측정 지표에서 계획된 작업과 계획되지 않은 작업을 구분하고 해당 작업에 리소스가 할당되는 방식을 구분하는 것입니다. 계획되지 않은 작업은 싸움에 대한 금액이며, 이러한 작업에 너무 많은 시간(약 20% 이상)이 소비되는 경우 기업의 실제 비즈니스 요구인 계획된 작업이 백로그됩니다.

시스템의 병목 현상은 계획되지 않은 작업에 거의 대처할 수 없으므로 증가된 로드와 결과적인 백로그를 처리할 수 있는 충분한 추가 리소스를 확보하는 것이 중요합니다.

2020년 초 COVID-19의 주요 장애물 교훈 중 하나는 IT 측면에서 병원 역량으로서 최소한 DevOps 인력 배치와 관련하여 too lean과 같은 것이 있다는 것입니다 (하드웨어는 또 다른 이야기입니다). 비오는 날을 계획하고, “중복” 정기적 인 준비 훈련과 결합 된 직원 또는 교차 교육 이니셔티브는 의사를 멀리 할뿐만 아니라 실제로 미션 크리티컬입니다.

프로그램 시작하기

관리 수준에서 개발 및 운영 변경 사이의 글로벌 변경 관리 관점은 필수적입니다. 두 팀 모두 서로를 알아야 한다.’s 변경 계획 세부정보가 함께 제공되는 것이 이상적입니다. 훌륭한 일 팀이 데이터 기반의 투명한 협업 문화에서 개발 및 운영 직원의 건강한 혼합일 때 발생할 수 있습니다.

다양한 이해 관계자를 생성에 포함시키는 철학과 유형 작업 제품의 진화devops 팀만 서버 엔지니어링 작업에 대한 제어와 책임을 공유하는 것 이상으로 의미가 있습니다. 이 교훈은 현대 기업 세계에서 계속 반복되고 있으며, 창조적 인 인간 표현을위한 새로운 영역은 비즈니스 부문에서 형성되고, 함께 사업을하는 오래된 방식을 재창조합니다.