훌륭한 런북은 온콜 교대가 매끄럽게 진행되느냐, 아니면 새벽 3시에 대형 사고가 터지느냐를 가릅니다. Trupeer를 사용하면 무료 런북 템플릿으로 시작해 브랜드 가이드라인에 맞게 커스터마이즈하고, 긴 런북을 온콜 엔지니어가 몇 초 만에 훑어볼 수 있는 비디오 워크스루로 바꿔 IT 런북 작성에 드는 시간을 몇 시간이나 절약할 수 있습니다.

무료 런북 템플릿이란?

무료 런북 템플릿은 특정 운영 작업을 완료하기까지의 단계 순서를 재사용할 수 있는 구조입니다. 배포, 페일오버, 마이그레이션, 복구, 예정된 유지보수 윈도우 등이 여기에 해당합니다.

‘런북(runbook)’이라는 단어는 문자 그대로 받아들일 만합니다. 읽는 문서가 아니라 실행되는 문서입니다. 작업이 진행되는 동안 화면에 열려 있고, 순서대로 진행하며, 제출했을 때의 문구보다 실행 중 실제로 무엇을 하느냐에 따라 가치가 결정됩니다.

이 한 가지 사실이 좋은 런북과 좋은 절차 문서를 가르는 기준이며, 대부분의 템플릿이 놓치는 부분입니다. 템플릿은 무엇을 해야 하는지에 대한 잘 정리된 설명을 만들어내는데, 이는 필요하며 런북이 갖춰야 할 것의 대략 절반에 해당합니다.

나머지 절반은 런북이 ‘형식’이라는 점입니다. 실행되는 동안 채워집니다. 실제로 무슨 일이 일어났는지가, 중간에 합류한 사람이 그대로 이어갈 수 있는지, 아니면 다시 시작하거나 추측해야 하는지를 가르기 때문입니다.

그에 맞춰 형식도 따라야 합니다. 무료 런북 템플릿 Excel 파일은 결과 및 타임스탬프 열이 있는 단계 표에 적합하며, 대부분의 팀이 결국 이것을 사용하게 됩니다. 무료 런북 템플릿 Word 버전은 단계 주변에 풍부한 맥락과 문장이 필요한 런북에 적합하고, 무료 런북 템플릿 Microsoft Word 파일은 더 긴 이름 아래에서 동일한 역할을 합니다. 무료 런북 템플릿 PDF는 작업 문서가 아니라 완료된 런의 아카이브 기록입니다.

배포 런북인가요, 인시던트 런북인가요?

두 문서는 같은 이름을 공유하지만 서로 반대 방식으로 사용되므로, 무엇을 작성할지 먼저 결정하세요.

배포 런북 템플릿은 계획된 작업을 다룹니다. 릴리스, 마이그레이션, 컷오버, 예정된 유지보수 윈도우. 1단계부터 끝까지, 순서대로, 모두가 알고 있던 시점에 실행합니다. 보통 한 명 이상이 참여하며, 종종 교대 인수인계가 일어나는 시점에 걸쳐 진행됩니다. 핵심 설계 문제는 ‘순서, 상태, 핸드오버’입니다.

반면 인시던트 또는 온콜 런북은 계획되지 않은 작업을 다룹니다. 무언가 잘못되었고 누군가 진단 중입니다. 예측할 수 없는 시점에, 가능한 사람이 압박 속에서 입력하며, 순서대로 읽지 않습니다. 설계 문제는 관련 섹션을 빠르게 찾는 것이며, 이는 스크립트라기보다 조회 문서에 더 가깝습니다.

대부분의 공개 템플릿은 둘을 섞어 놓아 어느 쪽에도 제대로 맞지 않습니다. 번호가 매겨진 순서에 강제로 넣은 진단 런북은 중간에 입력할 수 없고, 증상 중심으로 구성된 배포 런북은 안전하게 만드는 ‘순서’가 사라집니다.

이 페이지는 주로 첫 번째에 관한 내용입니다. 계획된 작업을 순서대로 실행하되, 비싼 실패의 원인이 진단이 아니라 상태와 핸드오버에 있는 경우입니다.

Trupeer에서 이 템플릿을 커스터마이즈하는 방법

1단계: 템플릿 섹션 열기

메인 내비게이션에서 템플릿 섹션으로 이동하세요.

2단계: 템플릿 선택 후 열기

작업하려는 템플릿을 클릭해 열어보세요.

3단계: 템플릿 보기 확장

필요한 경우, 템플릿 보기를 확장해 전체 레이아웃과 세부 정보를 더 명확히 확인하세요.

4단계: 템플릿 편집

선택한 템플릿을 수정하기 시작하려면 Edit을 클릭하세요.

에디터에서 다음을 할 수 있습니다:

• 새 섹션 추가

• 서식 지정 규칙 정의 또는 업데이트

• 로고를 추가하고 위치 및 관련 설정을 조정

5단계: 커스터마이즈한 템플릿 저장

필요한 모든 변경을 마친 후 Save를 클릭해 업데이트된 템플릿을 본인 템플릿으로 저장하세요.

6단계: 미리보기 및 템플릿 미세 조정

커스터마이즈한 템플릿이 어떻게 보이는지 확인하려면 Preview를 여세요.

미리보기 화면에서 필요하다면 직접 조정을 계속할 수 있으며, 템플릿이 원하시는 그대로 정확히 표시되도록 할 수 있습니다.

런북 템플릿으로 다음을 할 수 있습니다:

• 작성 시간 절약: 운영 절차에 맞춰 구성된 구조로 빈 페이지를 건너뛰세요.

• MTTR 단축: 명확한 런북은 온콜 엔지니어가 인시던트를 더 빠르게 해결하도록 돕습니다.

• 브랜드 유지: Trupeer의 브랜드 키트를 사용해 로고, 글꼴, 색상을 적용하세요.

• 신규 엔지니어 교육: 비디오 워크스루와 런북을 함께 제공해 운영 담당자를 더 빠르게 온보딩하세요.

• 팀 전반 표준화: 모든 인시던트 유형에 동일한 런북 형식을 사용하세요.

• 글로벌 팀 지원: 한 번의 클릭으로 런북을 65+개 언어로 번역하세요.

중간 인수인계를 염두에 두고 런북을 작성하세요

여기서 중심으로 삼아야 할 설계 제약이 있습니다. 실행 중 어느 시점이 되면, 런북을 실행하는 사람은 처음 시작한 사람이 더 이상 아닐 수 있습니다.

교대가 끝납니다. 누군가 호출을 받습니다. 계획보다 윈도우가 길어집니다. 몇 시간 이상 지속되는 어떤 운영 작업에서는 이것이 예외가 아니라 정상이며, 런북이 값비싼 방식으로 실패하는 순간이 바로 여기입니다.

설계에 맞서야 할 질문은 정확합니다. 말로 브리핑하지 않아도, 두 번째 사람이 37단계에서 이를 이어받아 안전하게 진행할 수 있을까요?

‘예’라고 답하려면 대부분의 템플릿에 없는 네 가지가 필요합니다.

단계별 실제 결과 기록, 예상만이 아니라. 체크(틱)는 누군가 무언가를 클릭했다는 뜻입니다. 다음 사람이 무엇이 일어났는지 알려주지는 않습니다.

단계별 타임스탬프, 한 단계가 얼마나 오래 전에 실행됐는지가 종종 가장 진단적인 사실이기 때문입니다.

어떤 단계를 다시 실행해도 안전한지에 대한 명시적 표시. 인수인계를 받는 사람이 가장 먼저 묻는 질문은 이전 단계가 실제로 끝났는지 여부입니다. 반복해도 안전하다면, 그 질문은 더 이상 중요하지 않게 되며, 기록하는 데 드는 비용보다 훨씬 가치가 큽니다.

되돌릴 수 없는 지점의 명시. 그 이후에는 롤백을 더 이상 사용할 수 없습니다. 실행 중간에 도착한 누군가는 무엇이든 만지기 전에, 자신이 그 선의 어느 쪽에 있는지 알아야 합니다.

이 네 가지를 추가하면, 말로 하는 핸드오버가 더 이상 핵심 메커니즘이 되지 않습니다. 문서가 핸드오버가 되며, 피곤함, 급박함, 또는 부재가 생겨도 살아남는 유일한 버전이 됩니다.

런북 템플릿에 반드시 포함되어야 하는 것

총 9가지 구성 요소. 가운데 네 가지가 런북과 절차 문서를 갈라놓습니다.

마지막 항목은 특히 주의할 만합니다. ‘사이트가 올라왔는지 확인’처럼 작성된 검증 단계는 사이트가 올라와 있을 때는 통과하지만, 아래에 설명된 실패 상황에서는 잘못 통과합니다.

무료 런북 템플릿: 그대로 복사할 수 있는 구조

플레이스홀더가 아니라 실제 예시로 채워져 있습니다. 이는 주문 관리 시스템 마이그레이션에서 발췌한 내용입니다.

여기서 복사하세요.

헤더 및 윈도우. 런 이름, 날짜, 예정 윈도우, 중단 데드라인, 그리고 이 런북의 버전.

주문 관리 마이그레이션. 6월 14일 토요일. 윈도우 06:00~20:00. 중단 데드라인 16:00, 이후에는 진행 상황과 무관하게 롤백합니다. 런북 v9.

이 런의 역할. 문서에 숫자로 표시.

실행: K Ferreira 06:00~14:00, 이후 D Attwood 14:00~20:00. 되돌릴 수 없는 지점 승인: 엔지니어링 책임자, 07700 900xxx. 에스컬레이션: 온콜 플랫폼 리드, 07700 900xxx. ‘진행’ 의사결정의 비즈니스 담당자: 트레이딩 디렉터.

사전 조건. 1단계 이전에 모두 확인.

전체 데이터베이스 백업을 수행하고 스탠바이 인스턴스에서 복원을 테스트했습니다. 목요일부터 코드 동결이 적용 중입니다. 두 실행자 모두 오늘 프로덕션 접근 권한이 검증되었으며, 가정하지 않았습니다. 6월 7일에 스테이징에서 롤백을 리허설했습니다.

상태 라인. 진행하면서 업데이트하고 상단에 유지.

현재 37단계. 13:48부터 실행 중. 실행자: K Ferreira. 되돌릴 수 없는 지점은 아직 통과하지 않았습니다.

단계 표.

롤백. 37단계까지(포함) 사용 가능. 실행 전 백업에서 복원, DNS 재지정, 인입 워커 재시작. 6월 7일에 D Attwood가 스테이징에서 리허설했습니다.

핸드오버 섹션. 누구도 떠나기 전에 작성.

35단계까지 완료. 34단계는 첫 시도에서 개수 불일치로 인해 조용히 실패했으며, 재실행해 성공적으로 완료했습니다. 현재 개수는 84,120으로 일치합니다. 36단계 이후 인덱스 개수는 한 번 실패했으므로 다시 확인하세요. 진행 중인 작업 없음. 되돌릴 수 없는 지점은 통과하지 않았으며, 롤백은 여전히 사용 가능합니다.

검증. 실패할 만큼 충분히 구체적이어야 합니다.

사이트 로드. 카테고리 페이지의 상품 개수 합계가 84,120. 샘플 주문 10건을 끝에서 끝까지 배치. 5개의 알려진 계정에 대해 주문 이력이 표시됨. 결제 정산 리포트를 실행하고 일치함을 확인.

여기서 복사하세요.

런북 예시: 61단계와 10분 핸드오버

온라인 리테일러인 Tamworth Retail Group은 토요일에 예정된 14시간 윈도우 동안 주문 관리 시스템을 마이그레이션했습니다.

런북은 61단계로 구성되어 있었습니다. 검토되었고 스테이징에서 리허설도 진행했으며, 실제로 매우 신중하게 작성된 문서였습니다. 단계 표에는 세 가지 열이 있었습니다: 단계 번호, 작업, 그리고 체크 박스.

첫 번째 엔지니어는 1~37단계를 실행한 뒤, 교대가 바뀌는 시점에 약 10분 동안 구두로 인수인계를 하고 집에 갔습니다. 긴 하루 끝이었습니다.

34단계는 상품 카탈로그 재인덱싱이었고, 작업에 약 40분이 걸렸습니다. 그는 이를 시작했고 오류가 보이지 않아 체크했습니다. 하지만 실제로는 약 80% 지점에서 실패했는데도 아무것도 보고되지 않았습니다.

두 번째 엔지니어는 체크가 첫 37단계까지 표시된 61단계 목록을 들고 도착했습니다. 어떤 단계가 무엇을 만들어냈는지에 대한 기록은 없었고, 타임스탬프도 없었으며, 어떤 단계를 안전하게 반복할 수 있는지에 대한 표시도 없었습니다. 문서 관점에서는 38단계 이전의 모든 것이 그저 ‘완료된 것’이었습니다.

그녀는 계속 진행했습니다. 카탈로그는 부분적으로만 인덱싱되어, 사이트를 다시 열었을 때 대략 12%의 상품이 보이지 않았습니다.

마지막의 스모크 테스트는 사이트가 로드되는 것을 확인해 통과했습니다. 하지만 상품 개수를 카탈로그 개수와 비교하지 않았기 때문에 통과한 것입니다.

아무도 알아차리지 못했습니다. 월요일 아침, 그로부터 31시간 뒤였습니다. 분기 중 가장 바쁜 거래 주말이었습니다. 전년 같은 주말 대비 추정된 손실 주문은 약 24만 4천 파운드였습니다.

그들은 롤백할 수 없었습니다. 되돌릴 수 없는 지점은 41단계에서 이미 통과되었고, 관련자 모두 원칙적으로는 알고 있었지만, 실제로는 그 일이 발생한 단계가 아니라 1페이지의 한 문단에 기록되어 있었습니다.

재작성은 단계를 추가하지 않았습니다. 열을 추가했습니다. 모든 단계에 대해 실제 결과, 타임스탬프, 그리고 다시 실행해도 안전한지 표시를 넣었습니다. 상단에는 상태 라인을 추가했습니다. 되돌릴 수 없는 지점은 굵은 글씨로 소개가 아니라 해당 단계 자체로 이동했습니다. 그리고 누구도 떠나기 전에 완료해야 하는 핸드오버 섹션을 추가해, 10분짜리 대화를 4줄의 문장으로 바꿨습니다.

다음 마이그레이션에서는 교대가 9번째 시간에 발생했습니다. 핸드오버는 4분이 걸렸습니다. 인수인계를 받은 엔지니어는 확신이 없던 3단계를 다시 실행했는데, 특히 그 단계들이 ‘다시 실행해도 안전’으로 표시되어 있었기 때문입니다. 그리고 런은 윈도우 안에서 끝났습니다.

주의 차원에서 3단계를 다시 실행하는 데는 몇 분이 듭니다. 하지만 그렇게 하지 못하는 것이 주말 전체를 날리는 비용이 됩니다.

6단계로 런북 작성하기

1. 작업을 실행하면서 단계 작성, 기억에 의존하지 마세요. 책상에서 작성한 런북에는 작성자가 기억하는 단계만 들어가고, 손이 자동으로 하는 단계는 빠지기 쉽습니다.

2. 모든 단계에 예상 결과를 부여하세요. 작동했다는 뜻이 무엇인지 보게 될 것입니다. 예상 결과가 없는 단계는 작성자 외에는 누구도 검증할 수 없습니다.

3. 모든 단계를 ‘다시 실행해도 안전’ 또는 ‘아님’으로 표시하세요. 아래에 설명합니다. 추가 비용이 가장 적은 열이면서, 핸드오버 시 가장 가치가 큽니다.

4. 되돌릴 수 없는 지점을 단계에, 굵게 표시하세요. 소개에 두지 마세요. 소개는 필요하지 않은 사람이 한 번 읽고 끝내기 쉽습니다.

5. 런 중에 채우게 될 열을 추가하세요. 실제 결과와 타임스탬프. 문서에 없다면 어디에도 기록되지 않습니다.

6. 롤백을 포함해 리허설하세요. 기록만 해둔 롤백은 가정입니다. 실행할 사람과 함께 스테이징에서 리허설하세요. 작성한 사람과가 아니라, 실제로 실행할 사람과요.

1단계는 유용한 런북과 그럴듯한 런북을 가르는 단계입니다. 실행하면서 작성하면 문서에 없는 클릭, 이미 클립보드에 있던 자격 증명, 열려 있어야 했던 탭 같은 것들이 잡힙니다.

다시 실행해도 안전한 단계와 되돌릴 수 없는 지점 표시하기

이 두 가지 표시는 핸드오버에서 대부분의 일을 해내며, 일반적인 템플릿에는 둘 다 등장하지 않습니다.

다시 실행해도 안전. 각 단계마다 두 번 실행해도 해가 없는지 확인하세요. 중지된 서비스를 재시작하거나, 인덱스를 다시 실행하거나, 이미 적용된 구성을 다시 적용하는 경우라면 보통 ‘예’입니다. 고객 이메일을 보내거나 카운터를 증가시키거나, 중복 제거를 하지 않는 테이블에 행을 마이그레이션하는 경우라면 보통 ‘아니요’입니다.

가치는 인수인계를 받는 사람이 답할 수 없는 질문을 제거하는 데 있습니다. 이전 단계가 끝났는지 여부. 반복해도 무해하다면 그 답을 압박 속에서 불완전한 정보로 확인할 필요가 없습니다.

어떤 단계가 다시 실행해도 안전하지 않다면, 먼저 무엇을 확인해야 하는지 말해 주세요. ‘아니요, 반복하기 전에 행 개수를 확인하세요’는 ‘아니요’보다 훨씬 유용합니다. 문서를 읽는 사람은 이미 뭔가를 해야 한다고 판단했기 때문입니다.

되돌릴 수 없는 지점. 상태를 바꾸는 모든 런에는 하나가 있습니다. 그 이후에는 롤백이 더 이상 가능하지 않거나, 앞으로 진행하는 것보다 롤백이 더 이상 비용 효율적이지 않은 단계입니다.

그 지점을 단계에 표시하되, 스크롤하는 사람이 한눈에 구분할 수 있도록 시각적으로 뚜렷하게 하세요. 이를 통과시키는 권한이 있는 사람의 이름을 적고, 실제 결과 열에 통과된 시간을 기록합니다. 많은 런에는 하나가 아니라 여러 개가 있을 수 있는데, 그 경우 각각 표시하고 무엇을 닫는지(차단하는지)도 함께 적으세요.

단계를 표시하는 것만으로 끝내지 않고 ‘넘어감(통과)’을 기록해야 하는 이유는, 인시던트 이후에는 언제 결정이 되돌릴 수 없게 되었는지 묻는 질문이 생기지만 아무도 기억하지 못하기 때문입니다.

런북 템플릿 변형

구조는 유지되고, 강조점만 이동합니다.

배포 런북 템플릿. 위의 예시입니다. 순차적이며 계획된 작업이고, 종종 교대를 가로지르며, 핸드오버 설계가 가장 중요하게 작동하는 변형입니다.

재해 복구 런북. 드물게, 최악의 조건에서 실행되므로 사용 사이에 눈에 보이지 않게 품질이 떨어집니다. 구분되는 요구사항은 ‘정기 리허설’입니다. 1년 동안 실행되지 않은 DR 런북은 틀렸다고 가정해야 하기 때문입니다.

온콜 및 인시던트 런북. 순서대로 실행하는 것이 아니라 예측 불가능한 시점에 입력합니다. 순서가 아니라 증상으로 구성하고, 각 항목은 짧게 유지하며, 포함하기보다 더 깊은 자료로 연결하세요.

예정된 유지보수 런북. 정기적으로 반복되므로, 누군가가 이후가 아니라 실행 중에 업데이트한다는 전제가 있다면 실제 사용을 통해 진짜로 개선되는 유일한 변형입니다.

온보딩 및 오프보딩 런북. 팀이 처음 작성하는 런북인 경우가 많습니다. 순서는 안정적이고, 단계를 놓쳤을 때(특히 오프보딩에서) 발생하는 비용은 불편이 아니라 보안 문제이기 때문입니다.

규제 대상 시스템, 금융 처리 또는 안전 관련 제어를 다루는 어떤 것이든, 런북은 보통 자체 승인 및 기록 보관 요구사항이 있는 변경 관리 프로세스 안에 위치하며, 이 페이지의 어떤 내용보다 그 규정이 우선합니다.

런북, 작업 지침, 또는 SOP?

서로 겹치지만 분리할 가치가 있는 문서가 세 가지 있습니다. 잘못 선택하면 올바른 내용이더라도 사용 불가능한 형태로 만들어지기 때문입니다.

표준 운영 절차(SOP)는 누가 무엇을 어떤 순서로 하는지의 수준에서 프로세스를 다룹니다. 보통 역할을 가로지르며, 종종 며칠에 걸치기도 합니다. 이해를 위해 읽습니다.

작업 지침(work instruction)은 수행하는 사람을 위해 한 가지 작업을 자세히 다루며, 이를 잘 모르는 사람도 따라 할 수 있도록 작성됩니다. 작업 지침 템플릿이 해당 문서를 다룹니다.

런북(runbook)은 작업 지침이면서 동시에 실행 기록입니다. 동시에 따라 하면서 채워 넣고, 보통 정의된 순서로 여러 작업에 걸쳐 있으며, 열은 흔적을 남기기 위해 존재합니다.

문서를 작업 전에 읽고 작업 후에 제출한다면 절차입니다. 작업 중에 열어두고, 시작 때와 끝에서 내용이 달라지면 런북입니다.

런북을 최신 상태로 유지하기

런북은 대부분의 문서보다 더 빨리 낡습니다. 시스템이 바뀌는 것을 설명하기 때문이며, 실패하는 런이 일어나기 전까지는 그 낡음이 보이지 않습니다.

실제로 작동하는 메커니즘은 실행 후가 아니라 실행 중 업데이트하는 것입니다. 런북을 실행하는 사람이 문서를 열어둔 상태에서, 12단계가 이제 추가 확인이 필요하다는 사실을 방금 발견하고, 그 사실을 가장 먼저(그리고 유일하게) 알게 됩니다. 그 다음 10초 후에 반영하거나, 다음 런에서 한 시간의 혼란이 생깁니다.

문서 상단에서 그 점을 명시적으로 말해 정당화하고, 실제 실행 이후에도 변경되지 않은 런북을 품질의 신호로 보기보다 약간 의심스럽게 취급하세요.

자동화는 또 다른 경로이며, 이에 대해서는 냉정하게 바라볼 필요가 있습니다. 런북 단계의 자동화를 하면 사람의 실수와 문서 문제를 함께 제거할 수 있어, 적용되는 곳에서는 실제로 더 좋습니다. 하지만 자동화가 제거하지 않는 것은 주변 문서의 필요성입니다. 자동화가 실패하면 누군가는 무엇을 해야 하는지 알아야 하고, 그 사람은 예전보다 덜 숙련되어 있을 가능성이 큽니다. 단계를 자동화하되 런북을 유지하고, 런북이 자동화된 부분이 실패했을 때의 대응까지 포함하는지 확인하세요.

무료 런북 템플릿으로 해결할 수 없는 것

기억에 의존해 작성한 런북. 어떤 템플릿도 작성자가 생각 없이 하는 단계를 드러내지 못합니다. 실행하면서 작성할 때만 가능합니다.

리허설되지 않은 롤백. 한 번도 실행되지 않은 롤백 계획은 가정이며, 실패한 마이그레이션의 한가운데에서 테스트하기에는 부적절합니다.

이름만 붙인 체크리스트. 무료 런북 템플릿 무료 다운로드로 유통되는 것의 대부분은 체크 박스가 있는 번호 절차입니다. 이는 다른 문서이며 더 약합니다.

실패할 수 없는 검증. ‘사이트가 올라왔는지 확인’은 사이트가 올라와 있을 때는 통과하고, 잘못된 경우에도 통과합니다. 모든 검증 단계는 실패한다고 상상할 수 있을 만큼 충분히 구체적이어야 합니다.

중단 데드라인이 없는 윈도우. 데드라인이 없으면 일이 잘못될 때 계속 진행됩니다. 멈추는 것이 항상 다음 단계보다 더 비싸게 느껴지기 때문입니다. 아무도 투자하지 않은 상태에서 시작하기 전에 데드라인을 설정하세요.

설명하지 말고 런을 보여주세요

런북은 드물게 실행하는 사람들이 실행합니다. 마이그레이션은 1년에 두 번 일어납니다. DR 테스트는 매년 발생합니다. 실행하는 사람은 이전에 한 번 해본 적이 있을 수 있고, 아예 없을 수도 있습니다.

바로 이런 상황에서 ‘서술형 절차 문서’가 가장 나쁘게 작동합니다. 독자는 산문으로부터 화면과 콘솔 상태의 순서를 다시 구성해야 하고, 작성자가 의도한 것과 독자가 떠올리는 것 사이의 간격에 문서화되지 않은 단계가 숨어들기 때문입니다.

Trupeer AI가 이를 해결합니다. 누군가가 스테이징에서 한 번 실제로 런을 수행하면서 기록을 남기면, 출력물은 이미 캡처되어 배치된 스크린샷이 포함된 단계별 워크스루 문서가 됩니다. 여기에 비디오도 함께 제공되며, 모두 사용자의 자체 브랜딩 안에서 구성됩니다. 문서 버전이 런북이 됩니다. 비디오는 실행하는 사람이 하루 전 준비로 시청하는 자료이며, 현재는 아무도 만들 시간이 없는 준비를 대신해줍니다.

기록하세요. 브랜딩하세요. 번역하세요. Trupeer하세요.

런북에 특히 중요한 두 가지가 그 뒤를 따릅니다. 리허설은 추가 작업이 아니라 문서화를 부산물로 만들어내며, 신뢰성 있게 문서화가 일어나는 유일한 버전입니다. 그리고 인프라가 바뀌면 리허설을 다시 녹화하는 것이 스크린샷을 편집하는 것보다 빠르기 때문에, 런북은 중요한 순간에 더 최신 상태일 가능성이 커집니다.

해당 자료는 사용자의 지식 베이스에 배치되며, 다음 교대조에 있는 사람에게는 교육 자료로도 활용됩니다. 런 주변의 검증 증거와 품질 게이트는 QA 플랜에 포함되어야 합니다. 다른 문서와의 일관성은 브랜드 키트를 한 번 설정하는 문제이며, 설정 방법은 문서 템플릿 설정 가이드에서 다룹니다.

자주 묻는 질문

무료 런북 템플릿 Excel 버전이 있나요?

Excel은 대부분의 팀이 결국 사용하게 되는 형식이며, 문서에 잘 맞습니다. 런북의 핵심은 작업하는 동안 채우는 표이기 때문입니다. 무료 런북 템플릿 Excel 파일은 단계, 예상 결과, 실제 결과, 타임스탬프, 그리고 다시 실행해도 안전 열을 자연스럽게 처리하며, 런 중에 여러 사람이 같은 시트를 볼 수 있게 해줍니다.

실용적인 설정이 두 가지 있습니다. 헤더 행을 고정하고, 상태 라인을 그 위의 첫 두 행에 배치해 스크롤해도 계속 보이게 하세요. 현재 단계가 화면에서 벗어나는 무료 런북 템플릿 Excel 파일은 핸드오버 가치의 대부분을 잃습니다.

무료 런북 템플릿 Word 버전이 있나요?

Word는 단계 주변에 상당한 맥락이 필요한 런북에 적합합니다. 예를 들어 아키텍처 노트, 결정 이력, 에스컬레이션 상세 등이요. 무료 런북 템플릿 Word 파일은 먼저 서술형 섹션을 구성한 뒤, 그 다음에 단계 표를 만드세요.

제한은 런 중에 채우는 부분입니다. Word 표는 스프레드시트 셀보다 업데이트가 느리고, 실제 라이브 마이그레이션 중에는 그 마찰만으로도 사람들이 실제 결과를 기록하는 것을 멈추게 만들 수 있습니다. 많은 팀은 런북 템플릿 Word 문서에는 맥락을 두고, 단계 표는 그 문서에서 연결된 스프레드시트에 둡니다.

무료 런북 템플릿 Microsoft Word 버전이 있나요?

네, 그리고 동일한 트레이드오프가 적용됩니다. 무료 런북 템플릿 Microsoft Word 파일은 변경 프로세스의 일부로 검토 및 승인되는 런북이라면 올바른 선택입니다. 문서는 스프레드시트보다 승인 워크플로에 더 잘 맞기 때문입니다.

그 경로를 선택한다면, 어쨌든 실제 결과와 타임스탬프 열을 추가하세요. 이 열 없이 승인된 런북은 이 열 없이 실행될 것이며, 필요했던 기록은 존재하지 않게 됩니다.

배포 런북 템플릿이 있나요?

배포 런북 템플릿은 이 페이지 전반에서 다루는 순차형 변형입니다. 계획된 작업을 순서대로 실행하며, 보통 교대를 가로지릅니다.

좋은 템플릿을 일반 템플릿과 구분하는 네 가지가 있습니다. 소개가 아니라 단계에 표시된 되돌릴 수 없는 지점. 모든 단계에 적용된 다시 실행해도 안전 표시. 실제 결과 및 타임스탬프 열. 그리고 누구도 떠나기 전에 완료되는 핸드오버 섹션. 공개된 템플릿 중 이 네 가지를 모두 가진 것은 거의 없습니다.

무료 런북 템플릿 PDF가 있나요?

PDF는 작업 문서가 아니라 아카이브입니다. 런이 완료되면, 채워진 런북을 무료 런북 템플릿 PDF로 내보내고 변경 기록에 첨부하세요. 타임스탬프와 실제 결과가 포함된 완료된 런북은, 당신이 갖게 될 것 중 ‘무슨 일이 일어났는지’에 대한 최고의 증거이기 때문입니다.

PDF에서 실행하지 마세요. 문서는 런 중에 작성되어야 하며, 입력할 수 없는 내용은 기록되지 않습니다.

무료 런북 템플릿 무료 다운로드로 사용해볼 만한 것이 있나요?

표 자체를 만드는 데 10분이 걸리므로 무료 런북 템플릿 무료 다운로드는 절약되는 것이 많지 않고, 대부분의 공개 자료는 런북 라벨이 붙은 절차 문서입니다.

그중 어떤 것을 채택하기 전에 한 가지를 확인하세요. 단계 표에 실제로 무슨 일이 일어났는지에 대한 열이 있는지 보세요. 체크 박스만 있다면 체크리스트이며, 이 페이지 전체의 논지는 그 둘의 차이가 핸드오버에 달려 있다는 것입니다.

런북은 얼마나 길어야 하나요?

런이 걸리는 만큼이면 됩니다. 특히 상당한 마이그레이션이라면 실제로 수십 단계가 될 수 있습니다. 런북의 길이는 문제가 아닙니다.

관리해야 할 것은 ‘단계 크기’입니다. 한 단계는 하나의 작업과 하나의 관찰 가능한 결과여야 합니다. 여러 작업을 한데 묶은 단계는 중간에 인수인계할 수 없습니다. 다음 사람이 묶음 중 얼마나 진행됐는지 알 수 없기 때문이며, 문서가 존재하는 정확한 이유가 바로 그것을 막기 위함입니다.

런북은 누가 작성해야 하나요?

실행할 사람이 작성해야 합니다. 프로덕션이 아닌 환경에서 실제로 수행하면서 작성하세요. 아키텍트가 작성하고 엔지니어가 실행하면, 아키텍트가 직접 수행하지 않은 단계가 정확히 빠지게 됩니다.

그 다음, 두 번째 사람이 작성자의 도움 없이 스테이징에서 초안을 실행하게 하세요. 그들이 물어봐야 하는 모든 질문은 결함이며, 해결책은 답하는 것이 아니라 기록해두는 것입니다.