Runbook چیست؟ راهنمای عملیاتی بعد از تحویل پروژه

بعد از تحویل یک سیستم، معمولاً یک نفر در تیم عملیات همهٔ پاسخ‌ها را در ذهن دارد. تا وقتی آن نفر هست، همه چیز خوب پیش می‌رود؛ اما به‌محض غیبت یا خروج او، سازمان در برابر نخستین خطا فلج می‌شود. ریشهٔ این وابستگی، نبود یک سند ساده است: راهنمای عملیاتی.

Runbook (راهنمای عملیاتی) همان سند است: مجموعهٔ رویه‌های گام‌به‌گام برای راه‌اندازی، توقف، پایش و رفع اشکال یک سیستم. در این مقاله می‌بینید Runbook دقیقاً چیست، چه تفاوتی با SOP و Playbook دارد، چه چیزی باید در آن باشد، چطور نوشته می‌شود و چگونه می‌توان بخشی از آن را خودکار کرد.

Runbook چیست؟ (پاسخ سریع)

Runbook (راهنمای عملیاتی) مجموعهٔ رویه‌ها و عملیات روتینی است که تیم عملیات برای راه‌اندازی، توقف، پایش و رفع اشکال یک سیستم انجام می‌دهد. این سند می‌تواند الکترونیکی یا چاپی باشد و معمولاً شامل مراحل اجرا، پیام‌های خطا و واکنش درست، و گاهی فلوچارت است. هدف آن امکان‌پذیر کردن ادارهٔ سیستم توسط فردی با دانش پیش‌نیاز، حتی بدون حضور سازندهٔ سیستم است.

Runbook چه چیزی را پوشش می‌دهد؟

یک Runbook عملی، دست‌کم این دسته‌ها را پوشش می‌دهد:

• راه‌اندازی و توقف: ترتیب صحیح روشن و خاموش کردن اجزا.
• پایش و بررسی سلامت: چه چیزی را کجا و چند وقت یک‌بار بررسی کنیم.
• رفع اشکال تکراری: پیام‌های خطای رایج و واکنش درست به هر یک.
• عملیات دوره‌ای: پشتیبان‌گیری، پاک‌سازی، بازبینی ظرفیت.
• سناریوهای خاص: درخواست‌های ویژه و شرایط اضطراری.
• مسیر ارجاع: اگر مرحله‌ها جواب نداد، به چه کسی اطلاع دهیم.

Runbook با SOP و Playbook چه تفاوتی دارد؟

این سه اصطلاح نزدیک‌اند و اغلب اشتباه می‌شوند:

• رویهٔ عملیاتی استاندارد (SOP): سند سطح بالا که «چه باید کرد و چرا» را توضیح می‌دهد.
• Runbook: سند سطح اجرا که «چگونه، گام‌به‌گام» را برای عملیات روزمره نشان می‌دهد.
• Playbook: مجموعهٔ واکنش‌ها برای یک سناریوی خاص؛ اغلب برای رخدادهای بزرگ یا میان‌تیمی.

نکته مهم: Runbook جای SOP و Playbook را نمی‌گیرد؛ مکمل آن‌هاست. برای داشتن عملیات قابل‌اتکا، هر سه سطح لازم است.

یک Runbook خوب چه بخش‌هایی دارد؟

قالب پیشنهادی:

1. شناسه و هدف: نام سیستم، نسخه و هدف سند.
2. دامنه و پیش‌نیازها: چه چیزی پوشش داده می‌شود و به چه دسترسی‌هایی نیاز است.
3. نمای کلی معماری: تصویری کوتاه از اجزا و وابستگی‌ها.
4. رویه‌های عملیاتی: راه‌اندازی، توقف، پایش، پشتیبان‌گیری.
5. عیب‌یابی: پیام‌های خطا و گام‌های رفع.
6. معیار موفقیت هر رویه: از کجا بفهمیم عملیات درست انجام شد.
7. مسیر ارجاع: چه زمانی و به چه کسی ارجاع دهیم.
8. تاریخ بازبینی و مالک: چه کسی سند را به‌روز نگه می‌دارد.

جدول نمونهٔ Runbook

ترفند کاربردی: برای هر رویه یک معیار موفقیت قابل‌مشاهده بنویسید؛ «انجام شد» بدون معیار، بی‌معنی است.

Runbook Automation چیست؟

خودکارسازی Runbook (Runbook Automation) یعنی تعریف، ساخت و اجرای نرم‌افزاری همان رویه‌هایی که پیش‌تر دستی انجام می‌شد. مزیت آن کاهش زمان و خطای انسانی در کارهای تکراری است. با این حال، همه چیز را نباید خودکار کرد:

• کارهای تکراری، پرتکرار و کم‌ابهام، گزینه‌های خوبی برای خودکارسازی‌اند.
• گام‌های نیازمند قضاوت، تصمیم حساس یا تأیید انسانی باید دستی بمانند.
• خودکارسازی بدون Runbook مستند، فقط یک جعبهٔ سیاه می‌سازد.

چک‌لیست آماده بودن Runbook قبل از تحویل

مثال‌های واقعی و قابل‌اندازه‌گیری

• سرویس داخلی با یک متخصص کلیدی: پیش از Runbook، رفع خطای اتصال به‌طور میانگین ساعتی طول می‌کشید و به همان فرد وابسته بود. با Runbook و مسیر ارجاع، تیم پشتیبانی می‌توانست گام‌های اولیه را در چند دقیقه انجام دهد.
• سامانهٔ گزارش‌گیری: با مستندسازی رویهٔ پشتیبان‌گیری و آزمون بازیابی، زمان بازگردانی سرویس به‌طور قابل‌توجهی کاهش یافت.
• تحویل اپلیکیشن: نوشتن Runbook باعث شد آموزش نیروی جدید پشتیبانی از چند روز به چند ساعت برسد.
• خودکارسازی رویهٔ روزانه: خودکار کردن یک بررسی سلامت پرتکرار، زمان کار دستی روزانهٔ تیم را به‌طور محسوس کاهش داد و خطای انسانی را کم کرد.

مزایا، معایب و Trade-off

Trade-off اصلی: Runbook هرچه دقیق‌تر باشد، عملیات یکنواخت‌تر و وابستگی کمتر، اما نگهداری آن سنگین‌تر است. راه میانه، «کوتاه ولی به‌روز» است: رویه‌های پرتکرار را کامل بنویسید و جزئیات نادر را به مستندات فنی ارجاع دهید.

اشتباهات رایج

1. نوشتن Runbook پس از تحویل: سندی که بعد از رفتن تیم پروژه نوشته شود، همیشه ناقص‌تر است.
2. طولانی و مبهم نوشتن: Runbook خوانده‌نشدنی، در عمل وجود ندارد.
3. نبود معیار موفقیت: بدون معیار، اپراتور نمی‌داند کار را درست انجام داده است.
4. نبود مسیر ارجاع: Runbook بدون ارجاع، در خطاهای خارج از پوشش رها می‌کند.
5. آزمون‌نکردن رویه‌ها: رویهٔ آزمون‌نشده در لحظهٔ بحران شکست می‌خورد.
6. فراموش‌کردن به‌روزرسانی: Runbook کهنه، گاهی خطرناک‌تر از نبود آن است.

نکات کاربردی

• نکته مهم: Runbook را هم‌زمان با ساخت سیستم بنویسید؛ هنگام تحویل فقط آن را بازبینی کنید.
• ترفند کاربردی: برای هر رویه یک مالک و تاریخ بازبینی بگذارید.
• اشتباه رایج: خودکارسازی پیش از تثبیت رویهٔ دستی.
• قبل از شروع این را بدانید: اگر یک رویه را نمی‌توانید گام‌به‌گام توضیح دهید، هنوز برای مستندسازی یا خودکارسازی آماده نیست.
• نکته مهم: Runbook نسخهٔ رمزنگاری‌شده و کنترل‌دسترسی‌شده ندارد؛ نسخهٔ عملیاتی باید برای تیم پشتیبان همیشه در دسترس باشد.
• ترفند کاربردی: بعد از هر خطای مهم، یک ردیف به Runbook اضافه کنید؛ بهترین Runbookها تدریجی رشد می‌کنند.

دوایتفای و Runbook

Runbook فقط وقتی زنده می‌ماند که نگهداری و پیگیری آن بخشی از کار روزمره باشد. دوایتفای بستری است که این نگهداری را ساختار می‌دهد: تسک و زیرتسک چندلایه، چک‌لیست، مسئول تسک، ددلاین و تسک‌های تکرارشونده، وضعیت و پیشرفت کارها، وابستگی‌های WBS، مستندات پروژه، ریسک‌ها و محدودیت‌ها، Milestone و یادآورها، و گزارش‌های کاری و عملکرد. می‌توانید بازبینی دوره‌ای Runbook را به‌صورت تسک تکرارشونده تعریف کنید و رویه‌های عملیاتی را در مستندات پروژه نگه دارید. Doitify Copilot و AI Coach هم در ساخت و مدیریت این تسک‌ها، چک‌لیست‌ها و گزارش‌ها کمک می‌کنند. دوایتفای محصول ماست و این معرفی فقط در همین بخش مرتبط آمده است.

چطور Runbook را در تیم کوچک پیاده کنیم؟

تیم‌های کوچک گاهی Runbook را «کار سازمانی» می‌دانند. اما برای آن‌ها نسخهٔ سبک، بیشترین ارزش را دارد:

• از پرتکرارترین رویه شروع کنید: یک رویهٔ روزانه که هر هفته انجام می‌شود، بهترین نقطهٔ شروع است.
• در یک فایل ساده بنویسید: نیاز به ابزار پیچیده نیست؛ چند صفحهٔ گام‌به‌گام کافی است.
• بعد از هر خطا یک ردیف اضافه کنید: Runbook به‌طور طبیعی و با تجربه رشد می‌کند.
• مالک مشخص بگذارید: یک نفر مسئول به‌روز نگه‌داشتن آن باشد.

اشتباه رایج: تلاش برای نوشتن Runbook کامل در یک روز و رهاکردن آن. رشد تدریجی Runbook، پایدارتر از نوشتن یک‌بارهٔ جامع است.

Runbook را چطور بنویسیم که در لحظهٔ بحران واقعاً خوانده شود؟

پاسخ سریع: Runbook باید در کمترین زمان ممکن قابل‌اجرا باشد، نه قابل‌خواندن. ساختار آن را بر پایهٔ «نشانه، تشخیص، اقدام، تأیید» بچینید و برای هر گام یک معیار موفقیت قابل‌مشاهده بگذارید.

1. با نشانهٔ مشکل شروع کنید. «اگر سرویس X پاسخ نمی‌دهد» بهتر از عنوان فنی خشک است.
2. تشخیص را کوتاه بنویسید. دو تا سه بررسی سریع که وضعیت را روشن می‌کند.
3. اقدام را شماره‌گذاری کنید. هر گام یک عمل، نه چند عمل.
4. معیار موفقیت بگذارید. از کجا بفهمیم درست انجام شد.
5. مسیر ارجاع را کنار هر سناریو بیاورید. وقتی گام‌ها جواب نداد، چه کسی و چگونه.

سناریوی عددی: در یک سرویس داخلی، میانگین رفع خطای اتصال پیش از Runbook حدود ۹۰ دقیقه بود و همه به یک متخصص وابسته بودند. با Runbook گام‌به‌گام و مسیر ارجاع، تیم پشتیبانی توانست گام‌های اولیه را در حدود ۱۵ دقیقه انجام دهد و فقط موارد خاص به متخصص برسد. یعنی بخش بزرگی از بار رفع اشکال از مسیر بحرانی خارج شد.

Trade-off: Runbook جزئی‌تر، اپراتور را مستقل‌تر می‌کند اما نگه‌داری آن سنگین‌تر است. راه میانه، رویه‌های پرتکرار را کامل و موارد نادر را به مستندات فنی ارجاع دهید.

نکته مهم: Runbook را با جمله‌های امری کوتاه بنویسید؛ در لحظهٔ بحران، کسی حوصلهٔ متن توضیحی ندارد.

ترفند کاربردی: Runbook را با فردی خارج از تیم تست کنید؛ اگر او بدون پرسیدن سؤال بتواند رویه را اجرا کند، سند آماده است.

قبل از شروع این را بدانید: رویه‌ای که در محیط واقعی آزموده نشده، در لحظهٔ نیاز ممکن است نادرست باشد؛ آزمون، بخشی از نوشتن است.

چطور Runbook را با تغییر سیستم هم‌گام نگه داریم؟

Runbook کهنه، گاهی خطرناک‌تر از نبود آن است، چون اپراتور را با گام‌های منقضی به مسیر اشتباه می‌فرستد. سه اقدام ساده: نخست، هر تغییر مهم سیستم یک «شرط به‌روزرسانی Runbook» داشته باشد؛ دوم، بازبینی دوره‌ای (مثلاً فصلی) به‌صورت تسک تکرارشونده تعریف شود؛ سوم، بعد از هر خطای واقعی یک ردیف به سند اضافه شود. تجربه نشان می‌دهد Runbookهایی که تدریجی و در جریان کار رشد می‌کنند، پایدارتر از سندهای یک‌بارهٔ جامع هستند.

جمع‌بندی

Runbook سندی است که عملیات را از وابستگی به حافظهٔ افراد آزاد می‌کند. یک Runbook خوب کوتاه، گام‌به‌گام، دارای معیار موفقیت و مسیر ارجاع، و مستند به مالک و تاریخ بازبینی است. آن را هم‌زمان با ساخت سیستم بنویسید، پیش از تحویل بیازمایید و فقط بخش‌های تکراری و کم‌ابهام را خودکار کنید. ساده‌ترین آزمون کیفیت این است: اگر متخصص اصلی فردا نباشد، آیا تیم عملیات می‌تواند با این سند سیستم را اداره کند؟

اگر موضوع Runbook برایتان مفید بود، پیشنهاد می‌کنیم نرم افزار مدیریت هزینه پروژه ها و بهترین جایگزین Microsoft Planner برای مدیریت کار تیمی را هم بخوانید.