IT 운영은 스크립팅을 넘어 자동화로 나아가야 합니다.

깜짝 퀴즈 - 어느 것이 더 무거운가요? 깃털 1파운드 아니면 돌 1파운드?

물론, 속임수 질문이죠. 파운드는 파운드입니다. 1파운드에 돌보다 깃털이 훨씬 더 많아요.

좋아요, 더 관련된 주제로 가면 어느 것이 더 빠른가요? 수동 명령을 통해 실행되는 스크립트인가, 아니면 API 호출을 통해 호출되는 스크립트인가?

이 시점에서 여러분은 답이 첫 번째 답과 같고 차이가 없다고 답했을 가능성이 높습니다. 적어도 눈에 띄는 차이는 없었습니다.

스크립트는 스크립트이며 실행 시간은 호출 방법에 따라 달라지지 않습니다. 수동 명령으로 시작하든 API를 통해 호출하든 스크립트는 실행되는 속도만큼 빠르게 실행됩니다. 기간.

이것이 중요한 이유는 자동화를 통해 운영 속도를 개선하는 것이 스크립팅에 관한 것이 아니라 프로세스에 관한 것이기 때문입니다. 이건 핸드오프에 대한 거예요. 프로세스의 개별 단계에 대한 스크립팅에만 집중한다면 배포를 최적화할 수 없습니다. 실질적인 개선을 보려면 더 높은 단계, 즉 과정 자체로 나아가야 합니다.

모든 산업에서 자동화의 목표는 거의 항상 최적화입니다. 2018년 애플리케이션 제공 현황 조사에서 디지털 전환 이니셔티브가 있는 응답자의 72%가 "IT 최적화"를 가장 기대되는 이점으로 꼽은 것을 확인했습니다. 목표는 최적화였습니다.

최적화란 병목 현상을 찾아 제거하는 것을 의미합니다. IT 세계에서 이는 거의 항상 운영 프로세스의 단계 간의 핸드오프입니다. 실제 작업, 즉 대본이 가치입니다. 이러한 스크립트가 실행되는 사이의 시간은 출력을 기다리는 사람들에게 지연과 좌절을 일으키는 원인이 되는 경우가 거의 대부분입니다. 대다수(52%)의 NetOps는 여전히 이런 방식으로 인프라를 관리합니다. 

각 운영 도메인이 프로세스에서 해당 역할을 스크립트로 작성하는 것만으로는 충분하지 않습니다. 방화벽 변경 스크립팅, 애플리케이션 서비스 프로비저닝 및 구성, 애플리케이션 인프라 구축은 모두 개별적으로 하면 좋은 일입니다. 하지만 그것은 시작에 불과해요. 이러한 개별 자동화 단계를 합치면 단일 운영 프로세스가 구성됩니다. 이를 자동화하는 것을 우리는 오케스트레이션이라고 부릅니다. 그리고 ITOps의 비효율성을 높이는 지연과 잘못된 핸드오프는 오케스트레이션에서 발생합니다. 

여기서 문화와 조직 구조가 중요합니다. 배포 프로세스의 첫 번째 단계(예: 앱 인프라 구축)에 참여하는 경우 다음 단계로 프로세스를 넘겨야 합니다. 이는 애플리케이션 서비스(로드 밸런싱 등) 프로비저닝 단계일 가능성이 높습니다.

이걸 누구에게 주시나요? 대기열에 들어가나요? 티켓을 생성해 주시나요? 어떻게 작동하나요?

이는 원활한 전환이어야 하며, 포괄적인 플레이북(레시피, 요리책, 매니페스트 등)에 의해 관리되거나 프로세스 실행을 감독하는 외부 시스템에 의해 관리되어야 합니다. 프로세스 실행에 수동 상호작용을 도입한다는 것은 실제로 자동화의 이점을 활용하지 못하고 스크립팅만 한다는 것을 의미합니다.

스크립트가 자동화 전략의 필수 구성 요소일 수 있지만 스크립트 자체는 자동화가 아닙니다. 스크립트를 구동하는 관리 프로세스와 통합되지 않기 때문입니다.

자동화를 활용해 IT를 최적화하려면 프로세스를 자동화해야 합니다. 그렇게 하면 대기 시간을 없애고 고정된 운영 프로세스(3단계의 승인 포함)를 찾아내 성과를 실제로 개선하고 속도를 의미 있게 높일 수 있기 때문입니다.   

자동화(스크립팅뿐만 아니라)는 민첩한 네트워크 목표에 한 걸음 더 다가가는 데 도움이 되는 성숙한 NetOps 관행의 신호입니다.