조직을 위해 ITIL, DevOps 및 SRE가 함께 작동하는 방법
게시 됨: 2020-03-02누군가 귀하의 조직이 어떤 유형의 "상점"인지 물으면 ITIL, DevOps 또는 SRE라고 자신 있게 대답할 수 있습니까?
일부 사람들은 그렇게 할 수 있지만 대기업이라면 특히 SRE가 DevOps의 핵심 구현이 되었기 때문에 이러한 운영 모델 중 몇 가지의 조합이 답일 것입니다. ITIL은 DevOps 및 SRE 원칙과 함께 효과적으로 작동할 수 있지만 언뜻 보기에는 서로 다른 종으로 보입니다.
비결은 조직의 다양한 운영 모델이나 도구 체인에 관계없이 팀 간에 가시성, 커뮤니케이션 및 협업이 공유되도록 하는 것입니다. 이렇게 하면 서로 다른 팀이 각 방법론의 모범 사례를 사용하면서 정렬 상태를 유지할 수 있습니다.
ITIL은 무엇입니까? 낯설다면...
ITIL은 정보 기술 인프라 라이브러리 (Information Technology Infrastructure Library)의 약자로 정보 기술에 대한 모범 사례의 단일 소스를 만들기 위해 개발된 방법론입니다. Sarah K. White와 Lynn Greiner에 따르면:
“1980년대에 영국 정부의 중앙 컴퓨터 통신국(CCTA)에서 개발한 ITIL은 처음에는 30권 이상의 책으로 구성되었으며 시간이 지남에 따라 개발 및 출시되었으며 여러 출처(벤더의 최고 관행) 전 세계.”
ITIL은 현재 네 번째 버전으로 업데이트되었으며 접근 방식은 9권으로 압축되었습니다. 이 책들은 현대 기술 시대를 반영하지만 여전히 ITIL의 원래 핵심 이상에 매우 중점을 두고 있습니다. 이러한 이상에는 "프로세스 자동화, 서비스 관리 개선 및 IT 부서를 비즈니스에 통합"이 포함됩니다. ITIL은 전통적으로 매우 하향식이며 고도로 구조화된 프로세스 중심 방법론이며 오늘날 가장 많이 채택되는 IT 프레임워크 중 하나로 남아 있습니다.
ITIL의 주요 사례에는 서비스 카탈로그 및 설계, 모니터링 및 이벤트 관리, 사고 및 문제 관리, 릴리스 관리, 구성 관리 등이 포함됩니다. 이러한 모든 관행은 운영 모델에 관계없이 유지되지만 서로 다른 아키텍처 요구 사항 및 워크플로의 맥락에서 다르게 나타날 수 있습니다. 이러한 관행은 DevOps 또는 SRE 매장으로 강력하게 식별되는 조직에도 종종 가치가 있습니다.
ITIL과 ITSM의 관계는 무엇입니까?
ITSM 또는 정보 기술 보안 관리는 회사가 IT 서비스를 관리하는 방법에 대한 프로세스입니다. 이 프로세스는 매우 고객 중심적이며 일반적으로 5단계로 구성됩니다.
- 서비스 전략
- 서비스 디자인
- 서비스 전환
- 서비스 운영
- 지속적인 서비스 개선
ITIL은 ITSM 사례를 구현하기 위한 프레임워크입니다. 이 프레임워크는 조직 중립적이므로 IT가 집중하는 유일한 고객이 내부 고객인 경우에도 거의 모든 비즈니스에 적용할 수 있습니다. 매우 밀접하게 연결되어 있기 때문에 ITIL과 ITSM이 많은 문제에서 일치하는 것은 놀라운 일이 아닙니다.
itiltraining.com에 따르면:
“지속적인 개선이 매우 중요합니다. 여기에는 프로세스, IT 서비스 및 IT 인프라를 지속적으로 측정하고 개선하는 작업이 포함됩니다. 그렇게 하면 효율성, 효과성, 비용 효율성이 극대화됩니다.”
ITIL이 DevOps와 작동하는 방식
ITIL 프로세스를 따를 때 초점은 IT를 조직의 비즈니스 목표에 맞추는 것입니다. 이는 조직 전체의 사일로를 무너뜨리는 DevOps 철학과 잘 맞습니다. 또한 이러한 사일로를 무너뜨리면 커뮤니케이션의 병목 현상을 제거할 수 있으므로 팀이 고객이 원하는 기능을 더 빨리 제공하고 CAMS 모델(문화, 자동화, 측정, 공유)을 더 밀접하게 준수할 수 있습니다. 그러나 이것이 조직에 적용될 때 실제로 어떻게 보일까요?
언제 어떤 것을 사용합니까?
조직은 다양한 상황에서 ITIL 및 DevOps에 의존하여 다양한 시나리오에 가장 효율적인 솔루션을 제시할 것입니다. 예를 들어 워크플로, 코드 푸시, 자동화 및 모니터링에 맞춰 조정해야 하는 개발 팀과 운영 팀 간에 DevOps 모범 사례를 활용하는 것이 합리적일 수 있습니다.
그러나 영업 및 IT와 같이 서로 다른 속도로 실행될 수 있는 조직의 여러 부서 간에 통신할 때는 ITIL 방식이 유용할 수 있습니다. 아래 그래프는 두 가지 방법론이 서로 다른 상황에서 어떻게 적용될 수 있는지에 대한 몇 가지 예를 보여줍니다.

IT와 조직의 나머지 부분 간의 조정
ITIL과 DevOps 모범 사례를 혼합하여 채택한 결과 조직 전체의 목표에 더 잘 부합합니다. IT와 조직의 나머지 부분이 완전히 독립적인 엔터티로 기능할 때 한쪽은 항상 과중하고 지원이 부족하다고 느낄 것입니다. 가상의 조직이 IT 통합과 관련하여 고군분투하는 모습을 다룬 소설 "The Phoenix Project"에서 이것이 핵심 갈등이 됩니다.
이 책에서 IT는 R&D 및 판매 이니셔티브의 성공에 대해 부분적으로 책임이 있었습니다. R&D에서는 재고를 보충하고 적시에 신제품을 출시하기 위해 정확한 데이터와 재고 보고가 필요했습니다. 영업에는 효과적인 CRM, 전화/음성 메일 및 MRP 시스템이 필요했습니다. 그렇지 않으면 고객 주문을 추가하거나 변경할 수 없고 고객 상태를 관리할 방법이 없습니다.
부서 간 커뮤니케이션 없이는 이러한 필요한 변경을 계획할 방법이 없었습니다. 오히려 부서들이 서로에게 무리한 요구를 했고, 공이 자주 떨어졌고, 회사 수익은 곤두박질쳤다.
이 갈등은 IT가 조직의 나머지 부분과 조정하고 의사 소통하고 다른 부서장이 IT 이니셔티브에 대한 높은 수준의 동의를 제공했을 때 해결되었습니다. 사일로를 허물고 함께 일함으로써 이러한 문제 중 많은 부분이 해결되었습니다.
때때로 IT 이니셔티브와 비즈니스 이니셔티브의 타이밍이 비동기적으로 보입니다. 그러나 조직은 ITIL 및 DevOps 모범 사례를 활용하여 일관된 일정을 만들 수 있습니다. 아래는 이러한 프로세스가 전체 조직을 만족시키기 위해 동시에 작동할 수 있는 방법을 보여주는 그래프입니다.

소유권 공유 및 지속적인 개선
프로세스 개선 외에도 조직에서 DevOps와 ITIL 프레임워크 간의 조정을 생성하면 사고 방식의 전환이라는 또 다른 중요한 이점도 얻을 수 있습니다. DevOps는 공유 소유권과 지속적인 개선을 장려하여 ITIL 프레임워크에 새로운 혁신을 가져옵니다.
조직의 사일로가 최소화되면 조직의 목표가 개인의 목표가 됩니다. 모두가 비즈니스의 성공과 실패를 소유하고 있습니다. 왜냐하면 그들은 모두 같은 팀의 구성원이고 같은 결과를 지향하기 때문입니다. 부서는 더 이상 서로 경쟁하지 않습니다. 지속적인 개선은 회사 문화의 일부가 되며, 실패를 축하하고 학습 기회로 인식합니다.
발견: 탐색하면서 소프트웨어 안정성이 회사의 최우선 과제인 방법을 알아보십시오!
ITIL이 SRE와 함께 작동하는 방식
DevOps와 ITIL이 어떻게 연계되는지 살펴보았으므로 이제 SRE와 ITIL이 연계되는 방식에 대해 이야기할 차례입니다. SRE는 DevOps의 구현이므로 이러한 정렬 중 많은 부분이 유사합니다. 세 가지 방법론 모두의 모범 사례를 사용하여 조직이 최고의 효율성을 발휘하도록 도울 수 있습니다. 실제로 ITIL과 SRE는 실제로 훌륭한 조합을 만들 수 있습니다.
첫 번째 이유는 간단합니다. 모든 조직은 행복한 고객을 원하며 ITIL과 SRE는 이를 실현하기 위해 서로 다른 기능이 함께 작동하도록 도울 수 있습니다. 소프트웨어 수명 주기 전반에 걸쳐 안정성을 포함하면 고객 만족도를 높일 수 있습니다. 7가지 기본 원칙을 소개하는 ITIL의 최신 개정판을 통해 SRE와 ITIL은 더욱 긴밀하게 연계됩니다.

ITIL 4의 7가지 원칙
다음은 ITIL 4의 7가지 원칙입니다. 더 자세히 논의해 보겠습니다.
1. 있는 곳에서 시작하라
SRE 모범 사례를 채택하는 것은 모든 사람에게 적합하지 않으며 모든 사람이 어딘가에서 시작합니다. 첫 번째 단계를 수행하고 진행하면서 구현하고 반복하는 것이 가장 중요합니다.
2. 간단하고 실용적으로 유지
단순성에 대한 Google SRE 책의 장에는 다음과 같이 나와 있습니다.
“인생의 다른 모든 것과 달리 '지루함'은 실제로 소프트웨어와 관련하여 긍정적인 속성입니다! 우리는 우리 프로그램이 자발적이고 흥미로운 것을 원하지 않습니다. 우리는 그들이 대본을 고수하고 예상대로 비즈니스 목표를 달성하기를 바랍니다.”
소프트웨어 및 비즈니스 운영의 단순성은 통신을 간소화하고 속도를 높이며 안정성이 손상되지 않도록 합니다. 적은 것이 더 많습니다.
3. 최적화 및 자동화
SRE의 목표 중 하나는 수고가 많은 프로세스를 자동화하고 계획되지 않은 작업 대신 혁신에 집중할 수 있도록 개발자 시간을 확보하는 것입니다. 이를 통해 워크플로를 최적화하고 새로운 기능을 더 빨리 제공할 수 있습니다.
4. 피드백을 통해 반복적으로 진행
SRE는 가장 중요하고 사용자 중심적인 메트릭에 대한 경고를 설정합니다. 연결된 메트릭, 경고 및 SLO는 모두 고객 요구 사항을 충족하기 위해 반복됩니다.
5. 협업 및 가시성 증진
SRE는 문화적으로 협력적입니다. 그것은 실패에서 배우는 것을 중요하게 여기고 각 팀원이 조직에 가장 적합하다고 생각하는 일을 하고 있다는 것을 신뢰하는 나무랄 데 없는 업무 문화에 중점을 둡니다.
6. 가치에 집중
고객이 없으면 소프트웨어의 가치도 없습니다. 비즈니스 가치는 고객이 제품에서 원하고 필요한 것을 얻을 때 생성됩니다. SRE 모범 사례는 제품이 고객에게 가치를 제공할 수 있을 만큼 충분히 신뢰할 수 있는지 확인하여 조직에 가치를 제공합니다.
7. 총체적으로 생각하고 일하라
사일로를 허물고 전체적 수준에서 확장성과 안정성에 초점을 맞춤으로써 SRE는 조직을 성숙시키는 데 상당한 이점을 제공할 수 있습니다. 비즈니스 전반의 성공은 모든 팀 구성원의 손에 달려 있으며 SRE는 회사의 제품, 시스템 및 절차가 고객 표준을 충족할 뿐만 아니라 초과할 만큼 충분히 탄력적임을 확인하기 위해 노력합니다.
유연하고 신속한 변경 관리
ITIL의 모범 사례 중 하나는 CAB(변경 승인 위원회)에서 감독하는 조정된 변경 관리입니다. 그러나 Mindbridge Kaimar Karu의 파트너가 언급한 바와 같이:
“CAB가 모든 단일 변경 요청을 검토하게 하는 것은 효율적이지 않으며, 특히 일부 조직에서 비용이 시간당 수만 번 배포될 수 있는 경우에는 확실히 상식적이지 않습니다. 그러나 비즈니스의 일부가 영향을 받을 수 있기 때문에 컨설팅이 필요한 경우 알려지지 않은 위험의 변경 요청을 CAB에서 검토하도록 하는 것이 좋습니다.”
SRE는 이를 도울 수 있으며 SRE의 핵심 원칙은 훨씬 더 유연하고 신속한 변경 관리를 촉진하는 데 도움이 됩니다. 온콜 방식을 통해 팀은 프로덕션 코드에 대해 24시간 내내 더 많은 책임을 질 수 있습니다. 롤백은 신속한 수정의 일부로 자동화할 수 있습니다. 인시던트 사후 분석은 SLO와 같은 중요한 학습 통찰력을 촉진하여 팀이 중요한 것을 정렬하고 현대적인 서비스 관리의 폭발하는 복잡성을 해소하는 데 도움이 됩니다.
또한 오류 예산은 새 기능을 출시하는 것이 안전한 시기에 대한 개발 팀의 지침을 만듭니다. 오류 예산에 여유가 있으면 변경이 승인되지만 오류 예산이 소진되거나 거의 소진되면 변경이 다음 창으로 연기됩니다.
이렇게 추가된 유연성은 SRE 리더십 사고방식에서도 영감을 받았습니다. 명령 및 제어 철학 대신 SRE는 끊임없이 변화하는 환경에서 유연성의 필요성을 인식하고 제어보다 컨텍스트에 중점을 둡니다. 즉, 업무상 중요한 기능을 제공해야 하는 경우 해당 기능이 제공됩니다.
ITIL, DevOps 및 SRE 드림 팀
일부 조직에서는 이러한 방법론 중 하나만을 사용하여 운영하지만 많은 조직에서는 이 세 가지 방법을 혼합하여 비즈니스 및 IT 목표를 조정하여 안전하고 안정적인 서비스를 만드는 가장 효율적인 방법을 찾습니다. 다음은 각 방법론의 강점을 그래프로 나타낸 것입니다. 동일한 원칙을 기반으로 하고 동일한 결과를 달성하기 위해 노력하고 있지만 방법론은 실제로 다르고 매우 상호 보완적입니다.
ITIL | 데브옵스 | SRE | |
철학과 문화 | IT를 비즈니스 요구 사항에 맞춰 공생 관계 구축 위험 완화를 위한 명령 및 제어 및 프로세스 기반 | 팀워크 향상 및 사일로 제거 개발과 운영 간의 연계를 만들고 사일로를 최소화하는 것을 목표로 합니다. 팀이 배포 속도와 품질을 개선하는 데 도움이 되는 경우가 많습니다. | 수고를 덜어주고 조작성을 고려한 디자인 효율성을 극대화하기 위해 운영을 소프트웨어 문제로 취급합니다. 고신뢰성이 필요한 대규모 분산 서비스를 지원하는 데 이상적입니다. |
주요 사례 및 도구 | 용량 계획 서비스 카탈로그/CMDB 문제 관리 변경 관리/자문 위원회 | 용량 계획 통화 마이크로서비스 CI/CD 코드로서의 인프라 모니터링 및 로깅 통신 및 협업 | DevOps 핵심 사례를 점진적 출시, SLO 및 오류 예산과 함께 일치시키기 관찰 가능성 카오스 엔지니어링 |
팀워크 | 중앙 집중식 프로세스 및 가시성의 전통적인 모델. 작업은 일반적으로 대기열에 있습니다('폭포'). 중앙 NOC 팀을 통해 전달된 사고 | 개발 및 운영은 전체 서비스 수명 주기 동안 점점 더 동일한 프로세스와 도구를 공유합니다. 일반적으로 이는 개발자가 빌드한 항목에 대해 대기 중이지만 L2 지원을 위해 작업에 참여할 수 있음을 의미합니다. | SRE는 종종 신뢰성 지향적인 관행을 수립하기 위해 컨설턴트의 역할을 합니다. 소프트웨어 엔지니어와 SRE의 역할은 공유 프로세스와 결과에 맞춰 수렴됩니다. |
주요 조치 | 가용성, 사건 #개, 에스컬레이션 #개 등 | 가용성, 배포 빈도 등 | SLO 및 가용성, 배포 빈도 등 오류 예산 |
결론
팀에 가장 적합한 관행을 식별하고 시행착오를 거쳐 조직이 최대 효율성으로 운영되도록 보장하는 궁극적인 조합을 찾을 수 있습니다.
추가 콘텐츠: 계속 학습하세요. 당신의 회사가 흠 없는 문화의 혜택을 누릴 수 있는 방법을 알아보십시오.