CloudOps: ITIL과 퍼블릭 클라우드 간의 격차를 해소하는 방법

(CloudOps: ITIL과 퍼블릭 클라우드 간의 격차를 해소하는 방법)

출처 : https://www.contino.io/insights/cloudops

CloudOps: How to Bridge the Gap Between ITIL and the Public Cloud | Contino | Global Transformation Consultancy

 

---

3줄 요약

CloudOps란? CloudOps의 충돌 CloudOps로 이동하는 방법 : 클라우드를 위한 ITIL 혁신 지속적 변경모델 1. Create a New Space for Cloud-Native Change to Take Place 2. Bake Quality in From Idea to Operation 3. Bake Traceability in from the Outset

 

 

---

CloudOps란?
 

클라우드 환견에 적용되는 IT 운영 방식

클루우드 환경에서 Application과 Workload를 지속 가능하게 구축, 배포 및 유지 관리하기 위한 일련의 관리 및 프로세스

 

 

CloudOps의 충돌

기존 운영과 CloudOps간 갈등의 원인은 변화의 속도

 

ITIL의 정신은

• 위험을 회피하고 변화를 통제하는 것
• 변화를 제한함으로써 어떤 대가를 치르더라도 실패를 피함
• 서버를 조달하고 유지하는 방식과 일치 → On-Premises 환경에서 동작
• 몇 년동안 동일한 서버를 운영해야 하므로 제어된 상태로 유지하는 것이 중요
• 변화를 하기 전에 ITIL 프로세스의 종류에 반영 필요
  • Change approval board
  • Raising tickets in relevant system
  • Going through various workflows and approval processes

 

클라우드에서는 작동하지 않음

• 위험과 실패를 위해 특별히 설계 → 변화가 수용되고 예상됨
• Cloud native application은 내결함성과 신석하게 변경되도록 설계됨
• 이는 아이디어 → 소프트웨어 자체의 구조에 적용됨
• 급격한 변화에 관한 것
  • 크라우드 Native application 개발팀은 하루에 50회 이상 배포할 수 있음
• 변경 배포가 기존 환경보다 빠르게 발생함
  • 인프라의 선언적 특성, 사전 예방적 수정을 구현하는 기능 및 반복적인 개발에 필요한 빠른 피드백 주기
• 즉, 다른 시스템에 들어가서 티켓을 올리는 것은 작동하지 않음 → 모든 것을 느리게 함
• ITIL 문제의 예
  • 개발자가 라이브에서 문제 감지
  • 수정 사하을 코딩하고 즉시 배포하기를 원함
  • 다른 부서의 다른 사람이 수동으로 승인해야 하는 시스템에서 요청을 제기하는 경우 모든 것이 무너짐
  • 클라우드 전체 목적을 무효화함

 

CloudOps로 이동하는 방법 : 클라우드를 위한 ITIL 혁신

 

대부분은 ITIL 조직/방식으로 일하고 있음 → 클라우드로 전환해야 함 (신속한 변경을 위해)

핵심 아이디어

• 기존 ITIL 조직 내에서 클라우드 네이티브 작업방식을 위한 공간을 만들어야 함
  • 빠른 변화를 가능하게 하는 새로운 행동을 걸 수 있는 고리
  • 누가 무엇을 하고 있는지, 어떤 팀이 새로운 행동에 적합한지, 어떤 워크로드를 빠르게 변경할 수 있는지 추적하면서 보안 유지
  • 필요로하는 통제 (표준변경모델과 구별하여 '지속적 변경 모델')

 

지속적 변경모델

이 모델을 사용하면 변경 사항을 효과적으로 추적

 

Tree Key Takeaways

• 변화가 일어날 수 있는 여지를 허용하라
  • 이전 세상에서는 변화를 피하고 변화가 통제된 방식으로 영향을 받도록 통제
  • 새로운 세상에서는 변화를 위한 공간을 만들고 변화를 수용하며 그에 따라 프로세스와 애플리케이션을 설계함
• Bake in quality from idea to operation
  • 이전 세상에서는 애플리케이션의 품질을 보장하기 위해 테스트 및 강화단계가 있었음
  • 새로운 세상에서는 CI 및 CD 파이프라인을 통해 모든 커밋에 품질을 적용함
• Bake in traceability from the outset
  • 이전 세상에서는 릴리스 노트와 구현 절차를 작성하는 것이 힘들고 일관성이 없었음
  • 새로운 세상에서는 SDLC 관리도구에 대한 모든 변경사항에 대한 추적 가능성을 제공
    → 애플리캐이션 수명 내내 실시간으로 어떤 순간에 누가 변경했는지 알 수 있음

 

1. Create a New Space for Cloud-Native Change to Take Place

이 분야에서 성공을 경험한 방법 = 새로운 변경 유형을 보강하는 것

 

ITIL의 세가지 변경 유형

• Standard
  • 위험이 낮고 비교적 일반적이며 지정된 절차 또는 작업 지침을 따르는 사전승인된 변경
• Normal
  • 완전성, 정확성 및 서비스 중단 가능성을 최소화 하기위해 전체 범위의 평가 및 승인 필요
  • 동료 또는 기술 승인, 변경관리, 변경 자문 위원회(CAB)승인 등
• Emergency
  • 그룹 및 동료검토 및 승인을 건너뛰고 CAB 승인그룹의 승인을 위해 바로 승인상태로 이동하는 높은 우선순위

 

검토 또는 승인이 필요하지 않는 기록 시스템 (예. ServiceNow)에서 자동으로 생성된 변경요청(RFC)로 변경할 수 있도록 "지속 변경"유형 추가를 제안함

• 표준 접근 방식을 통해 변경사항을 성공적으로 배포할 수 있는 능력이 입중된 팀을 위해 예약됨
• CI/CD 파이프라인에 필요한 제어를 자동화하여 실패를 피할 수 있는 능력을 입증해야 함
• 변경도 작게 유지하고 자주 수행해야 함

두가지 이점 존재

• 첫째, 진정한 클라우드 네이티브 변경과 모놀리식/전통 변경을 쉽게 분할할 수 있음
• 둘째, 올다른 CI/CD hygiene을 보장해야 하는 응용 프로그램을 강조 표시하여 새로운 패러다임을 운영하는 팀에만 주의를 집중할 수도 있음

전반적으로 ITIL 공간에서 운영중인 팀과, 클라우드에서 빠르게 진행할 수 있는 팀을 추적할 수 있음

 

몇 가지 팁

• Never Break Ranks 
  • 변경의 심각성 또는 긴급성으로 모서리를 잘라내고 라이브 구성을 수동으로 변경할 수 있도록 허용하는 것이 가치 있다고 결정되었음
  • 클라우드에서는 멈춰야 함 !!!
  • 어떤 유형의 변경이 이루어지든 동일한 자동 배포 프로세스를 사용해야 함
    • 긴급상황이라는 사실은 변경의 우선순위와만 관련되어야 함
    • 다른 모든 것은 동일하게 유지되어야 함
       
• We do not skip steps in the cloud-native world, we automate them.
  • 진정한 클라우드 네이티브 애플리케이션으로 작업하고 있따면 조직은 '설계'/'구축'을 담당하는 팀이 '실행'도 책임지게 하는 조치를 취해야 함
  • 기존의 개발/앱 지원팀 분할을 제거함 → SRE 원칙에 크게 의존함
• Analyse Your Platform/Application Structure
  • 급격한 변화가 일어날 수 있는 여지 허용 후 변화유형을 안전하게 사용할 수 있는 위치의 이해가 필요
  • 플랫폼의 논리적 구성요소
    

    

  • 완전한 것은 아니지만 CMDB 항목의 일부로 고려해야 할 구성요소 유형을 설명하는 역할
     
• Provide Change Type Guidance for Each Component
  • 시스템 구성요소 결정 후 플랫폼 구성요소에서 수행할 수 있는 다양한 변경작업에 대해 고객에게 지침을 주는 것이 유용
    • 미션크리티컬 구송요소에 대한 제어를 유지하면서 가능한 많은 변경 공간 확보 가능
    • 어떤 구성요소를 빠르게 변경할 수 있고 더 느린 ITIL 프로세스를 거쳐야 하는지 세분화된 수준에서 결정할 수 있음
      일부항목은 여전히 주의 깊게 제어할 필요 있음 (결재 앱의 삭제 변경 등 중요 앱)
      

      

  • 완전 자동화된 '연속된 변경' 유형을 사용하기 위한 최소 기준 형성
  • 특정 배포에 추가 위험이나 이상이 있는 경우 개발팀은 더 정밀한 조시가 필요한 변경 유형을 선택해야 함
  • 이를 통해서 빠른 변경의 호보가 지덩 → 팀에 해당 변경 모델에 대한 자격 갖추도록 하는데 필요한 제어 및 자동화 마련되었는지 확인 필요

 

 

2. Bake Quality in From Idea to Operation

필요한 보안 및 테스트 제어를 자동화 하는 것은 지속적인 변경 모델에 대한 팀의 자격을 갖추는데 필요한 부분이 되어야 함

 

As with any software team the CI stack is where we should be looking to implement our checks and balances to ensure the quality of our product

배포를 위한 특정 권한은 자동으로 얻지 않음 → CI Stack이 중요해짐

• CI Stack
  • 제품의 품질을 보장하기 위한 견제와 균형을 구현해야 하는 곳
  • 자동화된 품질 및 규정 준수 검사를 지원하기 위해 노력하는 공간

 

변화의 속도가 너무 빨라 운영부서를 통한 효율성을 유지하려면 자동화만이 유일한 방법

 

'지속적인'변경 자격을 갖추기 위한 최소 요구사항

• 자동화된 동료검토
• 자동화된 버전관리
• 자동화된 빌드
• 자동 스타일 검사
• 자동화된 정적 코드 분석
• 자동화된 보안 테스트
• 자동화된 단위 테스트
• 자동화된 배포
• 자동화된 행동 기반 테스트

→ 클라우드 네이티브로의 진입을 위해서는 작업이 효율적으로 수행될 수 있도록 자동화가 제공되어야 함

 

3. Bake Traceability in from the Outset

모든 일에 대한 기록을 유지해야 함 → 전체 기술 스택에 대한 추적성을 보장함

변경이 더 자주 발생함에 따라 플랫폼과 시스템의 상태를 항상 확인할 수 있는 것이 필수적

• 변경한 이유 (Jira ticket)
• 누가 생성하고 승인했는지 (Git commit)
• 무엇을 변경했는지 (Git commit)
• 변경이 이루어진 시간 (CI/CD Timestamp)
• 변경 사항 구현 방법 (CI/CD audit log)

이런 속성은 변경사항에 대해 즉시 사용할 수 있어야 함
→ 애플리케이션 수준 뿐 아니라 공유서비스 및 프로비저닝 수준에서도 마찬가지임

 

자동화된 Legacy 통합 구현

최소한 처음에는 기존 Legacy 운영관리 시스템 무시할 수 없음

• 첫번째 클라우드 네이티브 워크로드로 처음 클라우드로 이동할 때 전체 운영자산의 0.1% 미만 차지
• 기존 프로세스 및 도구와 통합해야 하는 경우 많이 발생
• 시스템에 최신 API 있느 경우
  • Legacy 시스템에 대한 자동 업데이트 허용하기 위해 해당 API와 통합하는 단계 수행 필요
• 최신 API 제공하지 않는 경우
  • 대체 솔루션을 찾아야 함
• 일반적인 통합은 변경 기록의 나머지 부분과 견경된 이유를 연결 → Jira/Rally 및 ServiceNow 같은 제품 통합