Операційна інструкція для невеликої команди

·3 хв читання

Runbook допомагає перейти від конкретного симптому до безпечного рішення.

Дві серверні вежі з перерваним шляхом і безперервним маршрутом відновлення.

Runbook допомагає перейти від конкретного симптому до безпечного рішення. Це не перелік усіх доступних команд. Пишіть для людини з очікуваними навичками, яка може бути втомленою або мало знати компонент.

Почніть із сигналу й впливу

Назвіть сповіщення, уражений маршрут та умови застосування. Дайте посилання на панель і поясніть ознаку, що відрізняє схожі причини. Додайте власника, дату перевірки й ескалацію. Документ має залишатися доступним під час відмови застосунку; його розміщення є частиною операційного дизайну.

Установіть передумови та межі зупинки

Опишіть права, вибір середовища й погодження важливих дій. Укажіть, коли непояснені дані, відсутня копія чи суперечливий результат вимагають зупинки та ескалації. Не записуйте секретів. Кожен крок потребує мети, очікуваного результату й наступного рішення, включно з впливом на незавершену роботу.

Додайте перевірку й підтримку

Для перезапуску, повторення чи перемикання поясніть дублювання й повернення. Перевірте маршрут клієнта та відкладену роботу, запишіть дії й наслідки. Нехай інша людина безпечно випробує інструкцію. Оновлюйте після змін та інцидентів. Коротка перевірена процедура надійніша за довгий покинутий документ.

Приклад і доказ приймання

Для зростання черги інструкція розрізняє відсутніх виконавців, повільного провайдера та одне завдання з повторною помилкою. Загальний перезапуск може сховати причину або посилити повторення. Назвіть спостереження для кожної гілки й наступну обмежену дію. Інша людина має обрати правильний маршрут та перевірити чергу і бізнес-результат. Незрозумілий вивід або відсутнє право стає покращенням документа. Приймання означає безпечне рішення з достатніми доказами, а не виконання всіх команд. Укажіть, коли зростання очікуване, наприклад під час погодженої пакетної роботи. Тоді правильною дією може бути спостереження замість втручання. Це відрізняє робочу інструкцію від механічного набору команд. Додайте ознаку завершення спостереження й час повторної оцінки, щоб рішення не втручатися залишалося контрольованим, а не перетворювалося на забуту проблему без власника.

Часті запитання

Чи додавати команди?

Так, перевірені та з передумовами, межами й очікуваним результатом.

Якої довжини має бути інструкція?

Стільки, скільки потребує конкретний шлях, без сторонніх деталей.

Хто має тестувати?

Інша людина з очікуваними доступами й навичками.

Що робити за відмінної реальності?

Зупиніться на визначеній межі, збережіть докази й ескалюйте.

Коли оновлювати?

Після змін, навчань та інцидентів, що змінюють припущення.

Від задуму до реалістичного обсягу робіт

Поділіться сценарієм користувача, інтеграціями й умовами запуску. Допоможемо підготувати оцінку з припущеннями та винятками.

Переглянути склад послуги →

Читати далі за темою

Чергування у стартапі без окремої SRE-команди

Невелика команда може мати корисне чергування, якщо обіцянки відповідають ресурсам.

Рівні серйозності інцидентів: матриця ескалації

Серйозність описує реальний або правдоподібний бізнес-вплив, а не драматичність повідомлення.

Відкат чи термінове виправлення під час інциденту

Під час інциденту обирайте дію, що найімовірніше поверне сервіс із контрольованим ризиком.