DevNetOps란?

DevNetOps란?

DevNetOps는 DevOps의 철학, 원칙, 동작을 NetOps(네트워크 운영)에 적용한 것입니다. DevOps의 철학은 1980~2000년에 발생한 소프트웨어 엔지니어링 문화와 린 생산방식(lean manufacturing)에서 유래했습니다. 이러한 원칙을 보통 CALMS(Culture, Automation, Lean, Measurement, Sharing)라 합니다.

가장 많이 인용되는 DevOps 원칙은 확장된 계획, 개발, 테스트 주기가 긴 순차적 단계로 발생한다는 폭포식 방법론에 대응하는 것입니다. DevOps 핸드북에 문서화된 바와 같이, DevOps 연구 결과 IT 및 제조 산업이 소규모 구축 작업을 자주 진행할수록 운영 속도와 민첩성, 품질이 개선된다는 사실이 밝혀졌습니다.

비즈니스 목표를 빠르게 달성하려는 조직은 안정성을 최우선 과제로 삼아야 합니다. 지속 가능성이 없는 속도는 실패로 이어지고, 빠른 실패는 반복을 통해 조직의 개선이 가능한 경우에만 유익합니다. 이와 함께 최근 인기를 끌고 있는 DevOps 구현 방식은 SRE(사이트 안정성 엔지니어) 역할입니다. DevNetOps는 이와 비슷한 NRE(network reliability engineer) 역할로 구현됩니다.

DevNetOps 파이프라인이란?

DevNetOps 파이프라인

DevNetOps 파이프라인

DevNetOps 파이프라인은 개발과 구축 간 리드 시간을 단축하고 최소한의 구축 변경으로 작업 주기를 단축하여 속도를 높이기 위해 엔지니어링 변경 및 프로덕션 구축 간 작업 진행을 자동화합니다.

코드 저장소를 버전화하여 진보적 개발과 테스트의 CI(연속 통합) 파이프라인을 트리거합니다. 일련의 자동 및 수동 평가를 통해 전송 페이로드 후보를 가상 환경, 시뮬레이션, 랩에서 테스트하여 안정적인 전송을 실현합니다. CD(연속 전송) 파이프라인은 전송 작업을 상시 구축 가능한 상태로 유지시킵니다. 연속 구축은 스테이징, 프로덕션의 순으로 자동 푸시됩니다.

그러나 변경 사항을 런타임 환경(스테이징 및 프로덕션)으로 푸시하기 전에 먼저 미세한 아키텍처 변경 단위와 변경 불가능한 인프라를 이해하는 것이 중요합니다. 대규모의 일회성 변경은 안전하지 않을 뿐더러 형성 및 검증에 오랜 시간이 걸립니다. 또한 소형 변경 패킷과 비교했을 때 문제를 파악하기가 더 어렵습니다.

연속 구축 전에 변경 불가능한 인프라를 파악하는 것도 중요합니다. 미리 구축한 후 엔지니어가 실제 구축된 것을 변경하는 것은 효율적이지도 유용하지도 않습니다. 안전하게 변경 사항을 테스트하고 문제 개선 방법을 결정하려면 프로덕션 런타임을 재현할 수 있어야 합니다.

DevNetOps의 마지막 구성 요소는 연속 모니터링, 측정, 대응입니다. 서비스 수준 지표에 대한 프로덕션 과정 중 피드백은 네트워크의 일시적 상태를 후속 또는 사전 조절하는 데 사용됩니다. 분석된 측정, 인시던트, 외부 변경 요청은 지속적인 개선 사항을 코드화된 상태의 네트워킹 시스템으로 피드백합니다.

자동화된 DevNetOps 파이프라인 요약

툴링

프로세스

인재

코드로서의 네트워크

구성 기밀, 아티팩트, gitOps 저장소

브랜칭, 리뷰, 페어링, 민첩성

코드 기술(반드시 프로그래밍일 필요는 없음)

파이프라인 오케스트레이션

파이프라인 CI/CD 툴, 테스트 프레임워크

TDD, 측정 평가

개발 및 디버깅 기술, 파이프라인 프로

변경 불가능한 미세 아키텍처

ZTP, 벤더를 위한 결과물 완성

소규모 단계적 진행/구축

비개입 CLI/TTY

업그레이드 오케스트레이션

ZTD, 가상화, 랩, 트래픽 배출

스테이징 및 시뮬레이션 카나리아 분석

시간 단위의 유지 보수, 롤 백 또는 포워드

복원력 설계 및 연습

트래픽 생성, DoS, Chaos Monkey

카오스 윈도우, 문서 제한

이해를 위한 강제 실패

연속 측정

빅 데이터 분석, ML, ITops 통합

인시던트 플레이북, 용량 계획

통계, 지표, 효율별 관리

연속 대응

자동 교정, FaaS, 예측적 통계

자가 구동 감독

원격 측정, 지표, 자가 치유 엔지니어링

지속적인 개선

업그레이드, 기능, 수정, 변경

지역적 교훈을 글로벌 지식으로 기록

사후 적극적인 열린 사고

DevNetOps의 이점

  • 안정성 엔지니어링은 소규모 구축 작업을 자주 진행하여 팀과 회사의 성과를 높이는 팀 문화 및 행동 양식과 조화를 이룹니다1.
  • DevNetOps는 벤더 시스템, 특히 소프트웨어 업그레이드 및 패치의 신속한 통합을 지원합니다. 또한 벤더가 소규모 페이로드를 빠른 빈도로 전송하도록 설득하여 기능과 수정의 긴 리드 시간이 가지는 문제를 해결하도록 합니다. 또한 벤더의 출시 기간과 운영업체의 구축 기간의 차이를 크게 좁혀줍니다.
  • DevNetOps는 엔지니어의 스트레스(구축에 대한 걱정)을 줄여주고 직무 만족도를 높여줍니다.

NRE와 DevNetOps, DevOps의 관계는?

DevOps와 DevOps 엔지니어는 비즈니스 애플리케이션 개발 및 운영과 관련이 있습니다. 일부 SDN(소프트웨어 정의 네트워킹) 유형의 경우 애플리케이션 클러스터 실행 시 네트워킹을 위한 역할이 있습니다. 그러나 기업 및 서비스 프로바이더 내부에도 소프트웨어 애플리케이션 및 플랫폼의 개발 및 실행 영역과 분리된 네트워크가 있습니다2. 대기업 애플리케이션에 초점을 맞춘 NetOps 네트워크의 몇 가지 예는 다음과 같습니다. 광역 백본, 전송, 백홀 및 데이터 센터 언더레이 네트워크

DevOps와 DevNetOps를 구분하려면 팀과 회사 간이 아닌 벤더와 고객 간 네트워킹의 Dev-Ops를 분리해야 합니다. 기능 및 제품에 대한 신속한 반복 실험과 같은 DevOps의 일부 목표는 네트워크 기본 인프라의 일반적인 목표가 아닙니다. 그럼에도 불구하고 DevOps의 원칙과 장점은 네트워킹에 동일하게 적용됩니다.

DevNetOps는 DevOps와 마찬가지로 여러 가지 철학과 원칙, 모범 사례의 집합이며 NRE(네트워크 안정성 엔지니어링)는 이를 구현합니다. “Dev”와 “엔지니어링”의 목표는 같습니다. DevOps의 원칙은 지속적인 학습을 위해 반복과 혁신의 속도를 높이지만, NRE는 가장 중요한 목표인 안정성에 집중합니다. 다음은 보완을 위한 두 가지 목표입니다. 그 이유에 대해 알아보십시오.