Страхотният runbook е разликата между гладна дежурна смяна и бедствие в 3:00 ч. с през нощта. С Trupeer можете да спестите часове при писане на IT runbooks, като започнете с безплатен шаблон за runbook, персонализирате го с вашите brand guidelines и превърнете дългите runbooks в видео разходки, които дежурните инженери могат да прегледат за секунди.

Какво е безплатен шаблон за runbook?

Безплатният шаблон за runbook е повторяемa структура за последователността от стъпки, която изпълнява конкретна оперативна задача: внедряване, failover, миграция, възстановяване, планиран прозорец за поддръжка.

Думата runbook си заслужава да се разбира буквално. Това е документ, който се „изпълнява“, а не се „чете“. Отворен е на екран, докато работата се случва; преминава се през него по ред и стойността му е изцяло в това, което прави по време на изпълнение, а не в това, което казва, когато бъде подаден/записан.

Този един факт отличава добрия runbook от добрия документ за процедура и е нещото, което повечето шаблони пропускат. Те създават добре организирано описание на това какво да се прави — необходимо е и е приблизително половината от това, което един runbook трябва да има.

Другата половина е, че runbook-ът е форма. Тя се попълва, докато се изпълнява, защото записът за това какво реално се е случило е разликата между операция, към която някой може да се включи по средата, и такава, която трябва да бъде рестартирана или гадаена.

Форматът следва това. Безплатният шаблон за runbook Excel файл пасва на таблицата със стъпки с колоните за резултат и времеви печат (timestamp) и е това, което повечето екипи в крайна сметка използват. Безплатният шаблон за runbook Word версия пасва на runbooks с много контекст и проза около стъпките, а безплатният шаблон за runbook Microsoft Word файл е същото нещо под по-дългото си име. Безплатният шаблон за runbook PDF е архивиран запис на завършен run, а не работещ документ.

Runbook за внедряване или runbook за инцидент?

Два документа споделят името и се използват по противоположни начини, затова решете кой от тях пишете.

A deployment runbook template покрива планирана работа. Релийз, миграция, cutover, планиран прозорец за поддръжка. Изпълнява се от стъпка първа до края, по ред, в момент, за който всички са знаели, обикновено от повече от един човек и често през смяна на дежурство. Проблемът при дизайна е последователността, състоянието и предаването (handover).

An incident or on call runbook покрива непланирана работа. Нещо не е наред и някой диагностицира. Въвежда се в непредсказуем момент, от когото има на разположение, под натиск, и не се чете по ред. Проблемът при дизайна е да се намери бързо релевантната секция, което го доближава повече до документ за справка, отколкото до сценарий.

Повечето публикувани шаблони смесват двете и не обслужват добре нито едното, нито другото. Диагностичен runbook, принуден в номерирана последователност, не може да бъде въведен по средата, а deployment runbook, организиран като набор от симптоми, губи подредбата, която го прави безопасен.

Тази страница е основно за първото. Планирана работа, изпълнявана по ред, където скъпите провали са за състоянието и предаването, а не за диагностиката.

Как да персонализирате този шаблон в Trupeer

Стъпка 1: Отворете секцията Templates

Отидете до секцията Templates от главната навигация.

Стъпка 2: Изберете и отворете шаблон

Кликнете върху който и да е шаблон, с който искате да работите, за да го отворите.

Стъпка 3: Разгънете изгледа на шаблона

Ако е нужно, разгънете изгледа на шаблона, за да виждате пълната структура и детайлите ясно.

Стъпка 4: Редактирайте шаблона

Кликнете върху Edit, за да започнете да променяте избрания шаблон.

В редактора можете да:

• Добавяте нови секции

• Дефинирате или актуализирате правила за форматиране

• Добавяте лого и настройвате позицията му и свързаните настройки

Стъпка 5: Запазете персонализирания си шаблон

След като направите всички необходими промени, кликнете върху Save, за да запазите актуализирания шаблон като свой.

Стъпка 6: Прегледайте и фино настройте шаблона

Когато искате да видите как изглежда вашият персонализиран шаблон, отворете Preview.

От екрана за преглед можете да продължите да правите корекции директно, ако е нужно, като гарантирате, че шаблонът изглежда точно както искате.

С шаблон за runbook можете да:

• Спестите часове от писане: Пропуснете празната страница със структура, създадена за ops процедури.

• Намалите MTTR: Ясните runbooks помагат на дежурните инженери да разрешават инциденти по-бързо.

• Останете в бранд: Приложете логото, шрифтовете и цветовете си с brand kit-а на Trupeer.

• Обучите нови инженери: Сдвоявайте runbooks с видео разходки, за да включвате по-бързо ops екипа.

• Стандартизирайте между екипите: Използвайте една и съща форма на runbook за всеки тип инцидент.

• Достигнете глобални екипи: Превеждайте runbooks на 65+ езика с един клик.

Напишете runbook-а, за да бъде предаден по средата

Ето ограничението в дизайна, около което си струва да се изгради. В даден момент по време на изпълнение човекът, който изпълнява runbook-а, ще престане да бъде човекът, който го е започнал.

Сменя се дежурството. Някой е извикан. Прозорецът се оказва по-дълъг от планираното. При всяка операция, която трае повече от няколко часа, това е нормално, а не изключение, и точно в този момент runbooks се провалят скъпо.

Въпросът, срещу който трябва да се проектира, е точен. Може ли втори човек да го поеме на стъпка тридесет и седем, без устен брифинг, и да продължи безопасно?

Отговорът „да“ изисква четири неща, които повечето шаблони нямат.

Записан реален резултат за всяка стъпка, не само очакван. „Отметка“ означава, че някой е кликнал нещо. Това не казва на следващия човек какво се е случило.

Времеви печат (timestamp) за всяка стъпка, защото колко отдавна е изпълнена дадена стъпка често е най-диагностичният факт, който е наличен.

Ясно маркиране кои стъпки са безопасни за повторно изпълнение. Първият въпрос на всеки, който поема, е дали предходната стъпка действително е приключила. Ако стъпката е безопасна за повторение, тогава този въпрос спира да има значение — и това си струва много повече, отколкото струва да се запише.

Ясна точка без връщане. След която rollback вече не е наличен. Някой, който пристига по средата на изпълнението, трябва да знае от коя страна на тази линия е, преди да докосне каквото и да било.

Добавете тези четири и устното предаване престава да е механизмът. Документът става предаването — и това е единствената версия, която оцелява, когато някой е уморен, бърза или просто не е на разположение.

Какво трябва да съдържа шаблонът за runbook

Девет компонента. Средните четири са тези, които отделят runbook от процедура.

Последната заслужава внимание. Стъпки за проверка, написани като „потвърдете, че сайтът е онлайн“, минават, когато сайтът е онлайн и когато е „счупен“, което е провалът, описан по-долу.

Безплатен шаблон за runbook: структурата, която да копирате

Попълнена с реален пример, а не с плейсхолдъри. Това е извадка от миграция на система за управление на поръчки.

Копирайте оттук.

Заглавие и прозорец. Име на run, дата, планиран прозорец, краен срок за прекратяване (abort deadline) и версията на този runbook.

Миграция на система за управление на поръчки. Събота, 14 юни. Прозорец 06:00 до 20:00. Краен срок за прекратяване 16:00, след което връщаме назад независимо от напредъка. Runbook v9.

Роли за този run. С номера в документа.

Изпълнява: K Ferreira 06:00 до 14:00, след това D Attwood 14:00 до 20:00. Точка без връщане, одобрена от: Head of Engineering, 07700 900xxx. Ескалация: lead на дежурната платформа, 07700 900xxx. Бизнес контакт за решението „go“: Trading Director.

Предпоставки. Всички потвърдени преди стъпка първа.

Направен е пълен бекъп на базата данни и възстановяването е тествано на standby инстанцията. Code freeze е в сила от четвъртък. И двамата изпълнители имат проверен production достъп днес, не е предположение. Rollback е репетиран на staging на 7 юни.

Линия със статус. Актуализира се, докато вървите, и се държи в горната част.

В момента сме на стъпка 37. Стартирано в 13:48. Изпълнител: K Ferreira. Точката без връщане все още не е премината.

Таблица със стъпки.

Rollback. Наличен до и включително стъпка 37. Възстановяване от бекъпа преди run-а, пренасочване на DNS, рестартиране на работниците за прием. Репетирано на staging на 7 юни от D Attwood.

Секция за предаване (handover). Попълва се, преди да си тръгне някой.

Завършено до стъпка 35. Стъпка 34 се провали „тихо“ при първия опит с несъответствие в броя и беше повторно изпълнена успешно; броевете вече съвпадат при 84,120. Наблюдавайте отново броя на индекса след стъпка 36, тъй като веднъж вече се е провалил. Няма нищо в процес. Точката без връщане не е премината, rollback все още е наличен.

Проверка (Verification). Достатъчно конкретна, за да се провали.

Сайтът се зарежда. Броят на продуктите на страниците с категории се сумира до 84,120. Десет примерни поръчки, поставени край до край. Историята на поръчките е видима за пет известни акаунта. Стартира се отчет за съгласуване на плащанията и съвпада.

Копирайте оттук.

Пример за runbook: шестдесет и една стъпки и предаване за десет минути

Tamworth Retail Group, онлайн търговец на дребно, мигрира системата си за управление на поръчки по време на планиран прозорец от четиринадесет часа в събота.

Runbook-ът имаше шестдесет и една стъпки. Беше прегледан, репетиран на staging и беше наистина внимателен документ. Таблицата със стъпки имаше три колони: номер на стъпката, действие и отметка.

Първият инженер изпълни стъпки от първа до тридесет и седем, предаде устно за около десет минути при смяната на дежурството и си тръгна след дълъг ден.

Стъпка тридесет и четири беше преконфигуриране (re-index) на продуктовия каталог — задача, която отнема около четиридесет минути. Той я стартира, не видя грешки и я отметна. Всъщност тя се провали на около осемдесет процента и не отчете нищо.

Вторият инженер пристигна с списък от шестдесет и една стъпки, с отметки срещу първите тридесет и седем. Нямаше запис какво е произвела която и да е стъпка, нямаше timestamp-и и нямаше индикация кои стъпки могат безопасно да се повторят. Всичко преди стъпка тридесет и осем, според документа, просто беше направено.

Тя продължи. Каталогът беше частично индексиран, което означаваше, че приблизително дванадесет процента от продуктите бяха невидими на сайта, когато той беше отворен отново.

Димният тест в края потвърди, че сайтът се зарежда. Той не сравни броя на продуктите с броя на каталога, така че тестът мина.

Никой не забеляза, докато не дойде понеделник сутринта, тридесет и един часа по-късно, през най-натоварения търговски уикенд на тримесечието. Оценените загубени поръчки спрямо същия уикенд предходната година бяха около двеста и четиридесет хиляди паунда.

Не можеха да върнат назад. Точката без връщане беше премината на стъпка четиридесет и една и макар всички участващи да знаеха това по принцип, беше записано в параграф на първа страница, а не в самата стъпка, където се случи.

Преработката не добави стъпки. Добави колони. Реален резултат, timestamp и маркировка „безопасно за повторно изпълнение“ за всяка стъпка. Линия със статус в горната част. Точката без връщане се премести от уводната част към самата стъпка, с удебелен шрифт. И секция за предаване, която трябва да бъде попълнена, преди някой да си тръгне — така десетминутен разговор се превърна в четири написани реда.

При следващата миграция смяната на дежурството се случи в деветия час. Предаването отне четири минути. Инженерът, който поемаше, повтори три стъпки, за които не беше сигурна — конкретно защото бяха маркирани като безопасни за повторно изпълнение — и runbook-ът приключи в рамките на прозореца.

Повторното изпълнение на три стъпки от предпазливост струва няколко минути. Невъзможността да се повторят — струва цял уикенд.

Как да напишете runbook за шест стъпки

1. Напишете стъпките, като изпълнявате задачата, а не по памет. Runbook, написан на бюро, съдържа стъпките, които авторът си спомня, и пропуска тези, които ръцете му правят автоматично.

2. Дайте на всяка стъпка очакван резултат. Това, което ще видите, означава, че е работило. Стъпка без очакван резултат не може да бъде проверена от никого, освен от нейния автор.

3. Маркирайте всяка стъпка като безопасна за повторно изпълнение или не. Покрито по-долу. Това е най-евтината колона за добавяне и най-ценната по време на предаване.

4. Поставете точката без връщане в самата стъпка, с удебелен шрифт. Не в уводната част, където ще бъде прочетена веднъж от човек, който не е този, който има нужда от нея.

5. Добавете колоните, които попълвате по време на run-а. Реален резултат и timestamp. Ако ги няма в документа, няма да бъдат записани никъде.

6. Репетирайте го, включително rollback. Rollback, който е само написан, е предположение. Репетирайте на staging с човека, който ще го изпълни, а не с този, който го е написал.

Стъпка първа е тази, която отделя полезните runbooks от правдоподобните. Писането, докато се прави, улавя недокументирания клик, идентификационните данни (credential), които вече са били в клипборда, и таб-а, който е трябвало да е отворен.

Маркиране на стъпки като безопасни за повторно изпълнение и точката без връщане

Тези две маркировки вършат по-голямата част от работата при предаване и нито една не присъства в типичен шаблон.

Безопасно за повторно изпълнение. За всяка стъпка: може ли да се изпълни два пъти, без да причини вреда. Рестартиране на спрян service, повторно индексиране, повторно прилагане на конфигурация, която вече е приложена: обикновено да. Изпращане на имейл на клиент, увеличаване на брояч, мигриране на редове в таблица, която не прави deduplication: обикновено не.

Стойността е, че премахва въпроса, на който човекът, който поема, не може да отговори. Предходната стъпка приключи ли. Ако отговорът няма значение, защото повторението е безвредно, тогава никой не трябва да го установява под натиск с непълна информация.

Когато дадена стъпка не е безопасна за повторно изпълнение, кажете какво да се провери първо. „Не, проверете броя на редовете преди повторение“ е много по-полезно от „Не“, защото човекът, който я чете, вече е решил, че трябва да направи нещо.

Точката без връщане. Всеки run, който променя състояние, има такава. Това е стъпката, след която rollback вече не е наличен или вече не е по-евтин от продължаването напред.

Маркирайте я в стъпката, визуално различима, така че човек, който скролва, да вижда от коя страна е. Назовете кой одобрява преминаването и запишете часа, в който е премината, в колоната за реален резултат. Много runbooks имат повече от една — в такъв случай маркирайте всяка и кажете какво „затваря“.

Причината да се записва преминаването, а не само да се маркира стъпката, е че след инцидент се задава въпросът кога решението е станало необратимо и никой не помни.

Варианти на шаблона за runbook

Структурата остава, а акцентът се измества.

Шаблон за deployment runbook. Примерът по-горе. Последователен, планиран, често обхващащ смяна, и вариантът, при който дизайнът на предаването е най-важен.

Runbook за disaster recovery. Изпълнява се рядко и при най-лошите условия, затова „старее“ невидимо между използванията. Отличителното изискване е планираната репетиция, тъй като disaster recovery runbook, който не е изпълняван в рамките на година, трябва да се приема за грешен.

On call и incident runbook. Въвежда се в непредсказуем момент, вместо да се изпълнява по ред. Организирайте по симптоми, а не по последователност, дръжте всяко вписване кратко и линквайте към по-дълбокия материал, вместо да го съдържате.

Runbook за планирана поддръжка. Повтаря се редовно, което го прави единственият вариант, който реално се подобрява с използването — при условие че някой го актуализира по време на run-а, вместо да планира да го направи след това.

Runbook за onboarding и offboarding. Често това е първият runbook, който екипът пише, защото последователността е стабилна и цената от пропускане на стъпка, особено при offboarding, е проблем със сигурността, а не неудобство.

За всичко, което покрива регулирани системи, финансови обработки или контрол, свързан с безопасността, runbook-ът обикновено стои в рамките на процес за управление на промени с отделни изисквания за одобрение и водене на записи, и те управляват, а не нищо от тази страница.

Runbook, work instruction или SOP?

Три документа се припокриват и си струва да бъдат разделени, защото ако изберете грешно, ще получите правилното съдържание във форма, която не може да се използва.

A standard operating procedure покрива процеса на ниво кой какво прави и в какъв ред, обикновено обхващащ роли и често обхващащ дни. Чете се за разбиране.

A work instruction покрива една задача в детайл за човека, който я изпълнява, и е написана да бъде следвана от някой, който може да не е запознат с нея. work instructions template покрива този документ.

A runbook е work instruction, която е и запис за изпълнение. Следва се и се попълва едновременно; обикновено обхваща няколко задачи в дефиниран ред и колоните му съществуват, за да оставят следа.

Ако документът ви се чете преди работа и се подава след това, това е процедура. Ако е отворен по време на работа и в края е различен от това, което е било в началото, това е runbook.

Поддържане на runbooks актуални

Runbooks „стареят“ по-бързо от повечето документация, защото описват системи, които се променят, и това „стареене“ е невидимо, докато не дойде run-ът, който се провали.

Механизмът, който реално работи, е актуализиране по време на изпълнение, а не след него. Който изпълнява runbook-а, има документа отворен, току-що е открил, че стъпка дванадесет сега изисква допълнително потвърждение, и е единственият човек, който някога ще знае това евтино. Десет секунди по-късно или един час объркване при следващия run.

Направете това легитимно, като го кажете изрично в горната част на документа и като третирате непроменен runbook след реално изпълнение като леко подозрителен, а не като знак за качество.

Автоматизацията е другият път и си струва да сте ясни за нея. Автоматизирането на стъпка от runbook премахва едновременно човешката грешка и проблема с документацията — и това е наистина по-добре там, където се прилага. Това, което не премахва, е нуждата от околния документ, защото някой все още трябва да знае какво да прави, когато автоматизацията се провали, и този човек вече е по-малко практикуван, отколкото е бил. Автоматизирайте стъпките, запазете runbook-а и се уверете, че runbook-ът покрива автоматизираната част, когато се провали.

Какво не може да поправи безплатният шаблон за runbook

Runbook, написан по памет. Нито един шаблон не показва стъпките, които авторът прави без да мисли. Само писането, докато изпълнявате.

Rollback, който не е репетиран. План за rollback, който никога не е изпълняван, е хипотеза, а средата на провалена миграция е лошо място, където да го тествате.

Чеклист, който носи името. Повечето от това, което циркулира като безплатен шаблон за runbook за безплатно изтегляне, е номерирана процедура с отметки, което е различен и по-слаб документ.

Проверка, която не може да се провали. „Потвърдете, че сайтът е онлайн“ минава, когато сайтът е онлайн и когато е грешен. Всяка стъпка за проверка трябва да е достатъчно конкретна, за да можете да си представите как се проваля.

Прозорец без краен срок за прекратяване. Без такъв, run, който върви зле, продължава, защото спирането винаги изглежда по-скъпо от следващата стъпка. Задайте крайния срок, преди да започнете, когато никой не е инвестирал.

Покажете runbook-а, вместо да го описвате

Runbooks се изпълняват от хора, които ги изпълняват рядко. Миграция се случва два пъти годишно. Тест за disaster recovery се случва веднъж годишно. Човекът, който го изпълнява, го е правил веднъж преди това — възможно е и никога.

Точно това е случаят, в който писаната процедура служи най-зле, защото читателят трябва да реконструира последователност от екрани и състояния на конзолата от проза, а разликата между това, което авторът е имал предвид, и това, което читателят си представя, е мястото, където недокументираната стъпка се крие.

Trupeer AI го затваря. Някой изпълнява run-а веднъж, на staging, докато записва, и резултатът е написана стъпка по стъпка разходка със заснети и поставени вече скрийншотове, заедно с видео, във вашия собствен бранд. Писмената версия става runbook. Видеото е това, което човекът, който изпълнява, гледа деня преди това — подготовката, която никой в момента няма време да произведе.

Запишете го. Брандирайте го. Преведете го. Trupeer-нете го.

Следват две неща, които са важни конкретно за runbooks. Репетицията произвежда документацията като страничен продукт, а не като допълнителна задача — и това е единствената версия на документацията, която надеждно се случва. И когато инфраструктурата се промени, повторното записване на репетицията е по-бързо от редактиране на скрийншотове, така че runbook-ът е по-вероятно да е актуален в момента, когато има значение.

Материалът стои във вашия knowledge base и се удвоява като обучение за всеки, който е на смяна следващ. Доказателствата за проверка и quality gates около run-а трябва да са в QA plan. Съгласуването с останалите ви документи е въпрос на настройване на brand kit веднъж, а настройката е покрита в document template setup guide.

Често задавани въпроси

Има ли безплатен шаблон за runbook в Excel?

Excel е това, което повечето екипи в крайна сметка използват, и пасва добре на документа, защото основата на runbook е таблица, която попълвате, докато работите. Безплатният шаблон за runbook Excel файл обработва стъпката, очаквания резултат, реалния резултат, timestamp-а и колоните за безопасно повторно изпълнение по естествен начин и позволява на няколко души да виждат един и същ лист по време на run.

Две практични настройки. Заключете реда със заглавието и поставете линията със статус в първите два реда над него, за да остава видима при скрол. Безплатният шаблон за runbook Excel файл, при който текущата стъпка скролва извън видимост, губи по-голямата част от стойността си при предаване.

Има ли безплатен шаблон за runbook в Word?

Word пасва на runbooks с обилен контекст около стъпките: бележки за архитектура, история на решенията, детайли за ескалация. Изградете безплатния шаблон за runbook Word файл първо с наративните секции и след това с таблицата със стъпки.

Ограничението е попълването по време на run. Таблица в Word се обновява по-бавно от клетка в spreadsheet и по време на жива миграция това триене е достатъчно, за да спре хората да записват реалните резултати. Много екипи държат контекста в Word документ с шаблон за runbook, а таблицата със стъпки — в spreadsheet, свързан от него.

Има ли безплатен шаблон за runbook в Microsoft Word?

Да, и важи същият компромис. Безплатният шаблон за runbook Microsoft Word файл е правилният избор, когато runbook-ът се преглежда и одобрява като част от процес за управление на промени, тъй като документите се вписват по-добре в workflow-и за одобрение, отколкото spreadsheet-ите.

Ако изберете този път, добавете колоните за реален резултат и timestamp така или иначе. Runbook, одобрен без тях, ще бъде изпълнен без тях и записът, от който се нуждаете, няма да съществува.

Има ли шаблон за deployment runbook?

Шаблонът за deployment runbook е последователният вариант, покрит през цялата тази страница: планирана работа, изпълнявана по ред, обикновено обхващащ смяна.

Четири неща отличават добрия вариант от generic шаблон. Точката без връщане е маркирана в стъпката, а не в уводната част. Маркировка „безопасно за повторно изпълнение“ за всяка стъпка. Колони за реален резултат и timestamp. И секция за предаване, която се попълва, преди някой да си тръгне. Почти нито един публикуван шаблон няма нито едно от тези четири.

Има ли безплатен шаблон за runbook PDF?

PDF е архивът, а не работещият документ. След като run-ът приключи, експортирайте попълнения runbook като безплатен шаблон за runbook PDF и го прикачете към записа за промяната, тъй като завършен runbook с timestamp-и и реални резултати е най-доброто доказателство за това какво се е случило.

Не изпълнявайте от PDF. Документът трябва да бъде написан по време на run-а и всичко, което не можете да въведете, няма да бъде записано.

Има ли безплатно изтегляне на шаблон за runbook, което си струва да се използва?

Самата таблица отнема десет минути за изграждане, така че безплатното изтегляне на шаблон за runbook спестява малко, а повечето публикувани са документи за процедура с етикет runbook.

Проверете едно нещо, преди да приемете който и да е от тях. Вижте дали таблицата със стъпки има колона за това какво реално се е случило. Ако има само отметка, имате чеклист, а целият аргумент на тази страница е, че разликата между тези два документа е това, от което зависи предаването.

Колко дълъг трябва да е runbook-ът?

Колкото run-ът — а при съществена миграция това наистина са десетки стъпки. Дължината не е проблемът при runbooks.

Нещото, което трябва да контролирате, е размерът на стъпката. Стъпката трябва да е едно действие с един наблюдаем резултат. Стъпки, които събират няколко действия, не могат да бъдат предадени по средата, защото следващият човек не може да разбере колко от „пакета“ се е случило, и точно това е ситуацията, която документът съществува да предотврати.

Кой трябва да пише runbook-а?

Този, който ще го изпълнява, като го пише, докато го изпълнява в среда, която не е production. Runbook, написан от архитект и изпълнен от инженер, ще липсват точно стъпките, които архитектът не изпълнява лично.

След това накарайте втори човек да изпълни черновата на staging без помощ от автора. Всяка въпрос, който трябва да зададат, е дефект, а поправката е да го запишете, вместо да отговаряте.