서비스 / 06
매니지드 딜리버리 및 운영
고객사 팀이 준비될 때까지 운영하고, 되면 손을 뗍니다.
저희가 만든 플랫폼을 SLA 걸고 운영하다가, 계약에 적힌 일정대로 고객사에 넘깁니다.
오픈은 비용 곡선의 끝이 아니라 시작입니다. 많은 조직이 운영할 준비가 되기 한참 전에 만들 준비부터 끝냅니다. 온콜 로테이션, 장애 대응, 용량 계획, 보안 패치. 전부 아직 조직도에 없는 사람이 필요한 일입니다.
그 역량이 갖춰질 때까지 합의한 SLA로 플랫폼을 운영합니다. 중요한 건 이관이 계약서에 적힌다는 점입니다. 담당 역할, 날짜가 박힌 일정, 그리고 기능이 하나씩 넘어갈 때마다 내려가는 수수료. 3년 차에도 저희가 운영하고 있다면 뭔가 잘못된 거고, 그 징후는 양쪽 다 미리 보게 됩니다.
장기 위탁을 원하셔도 됩니다. 다만 그건 저희가 만들어 놓은 종속이 아니라 고객의 선택이라는 점을 분명히 해둡니다.
핵심 역량
운영 및 지원
서비스 크레딧이 실제로 걸린 SLA를 기준으로 24/7 온콜과 장애·문제 관리를 합니다.
지속적 딜리버리
오픈했다고 제품이 멈추지 않도록 같은 2주 주기로 기능 개발을 이어갑니다.
역량 이전
페어 운영과 섀도 로테이션을 돌리고, 기능을 하나씩 고객사로 옮기는 일정을 날짜까지 정해 관리합니다.
보안 운영
패치 주기와 취약점 관리, 감사 증빙을 점검 직전에 몰아서 모으지 않고 평소에 유지합니다.
함께 읽을 자료
딜리버리 성과5 분
응답 23,000건을 견뎌낸 네 개의 지표
속도와 안정성은 맞바꾸는 관계가 아닙니다. 지난 20년간 소프트웨어 딜리버리에 관해 나온 이야기 중 가장 쓸모 있는 발견입니다.
출처: Nicole Forsgren, Jez Humble & Gene Kim, Accelerate: The Science of Lean Software and DevOps, IT Revolution, 2018
운영 모델5 분
콘웨이의 법칙을 실제로 인력 배치할 수 있는 형태로
네 가지 팀 유형과 세 가지 상호작용 방식. 이 책이 최적화하는 제약은 인지 부하인데, 그건 아무도 예산에 잡지 않는 항목입니다.
출처: Matthew Skelton & Manuel Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow, IT Revolution, 2019
운영4 분
장애 리뷰 전에 읽어야 할 네 쪽짜리 글
쿡이 쓴 건 의료 현장 이야기입니다. 그런데 프로덕션 시스템을 운영해본 사람이라면 18개 항목을 전부 곧바로 알아봅니다.
출처: Richard I. Cook, MD, How Complex Systems Fail, Cognitive Technologies Laboratory, University of Chicago, 1998
다음 서비스
디지털 전략 및 전환
보고서와 실제 출시 사이에서 멈춘 프로그램이 있으신가요?
어디서 막혔는지 알려주세요. 영업일 기준 이틀 안에 저희 생각을 정리해 회신드립니다. 저희가 맞는 파트너가 아니라면 그것도 그대로 말씀드립니다.