اتوماسیون تیکت جیرا

اگر ادمین جیرا سرویس دسک (Jira Service Management) در یک سازمان با حجم روزانه بالای تیکت هستید، احتمالاً این صحنه برایتان آشناست: صف تیکت‌های ورودی هر روز شلوغ‌تر می‌شود، تیم پشتیبانی وقت زیادی صرف خواندن و دسته‌بندی دستی درخواست‌ها می‌کند و SLA‌ها به‌خاطر تأخیر در ارجاع اولیه نقض می‌شوند. اتوماسیون تیکت جیرا دقیقاً همین گلوگاه را هدف می‌گیرد: با تعریف چند قانون درست، جیرا خودش تیکت‌ها را می‌خواند، دسته‌بندی می‌کند و به تیم یا فرد درست ارجاع می‌دهد — بدون این‌که یک انسان لازم باشد هر تیکت را دستی باز و بررسی کند. در این راهنما، فراتر از معرفی سطحی قابلیت Automation جیرا، به شما نشان می‌دهیم چطور قوانین واقعی و قابل‌اجرا بسازید، چطور خطاهای رایج را در Audit Log دیباگ کنید و چه محدودیت‌های فنی‌ای در مقیاس سازمانی باید در نظر بگیرید.

چرا اتوماسیون تیکت جیرا برای تیم‌های پشتیبانی ایرانی حیاتی است؟

در بسیاری از سازمان‌های ایرانی که از Jira Service Management برای IT Helpdesk یا پشتیبانی مشتری استفاده می‌کنند، فرآیند ارجاع خودکار تیکت هنوز به‌صورت نیمه‌دستی انجام می‌شود: یک نفر (معمولاً سرپرست تیم) هر صبح صف تیکت‌ها را مرور می‌کند و بر اساس تجربه شخصی تصمیم می‌گیرد کدام تیکت به کدام تیم برود. این روش سه مشکل جدی دارد:

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

راه‌حل، جایگزینی این تصمیم‌گیری دستی با قوانین اتوماسیون جیرا است که بر اساس معیارهای مشخص (نوع درخواست، کامپوننت، کلمات کلیدی در عنوان یا توضیحات، اولویت) به‌صورت لحظه‌ای و بدون دخالت انسان تصمیم می‌گیرند.

معماری قوانین اتوماسیون جیرا: Trigger، Condition، Action و Branch

پیش از ساخت هر قانون، باید چهار بلوک سازنده Automation در سیستم تیکتینگ جیرا را دقیق بشناسید (برای مرور کامل این بلوک‌ها، مستندات رسمی Atlassian درباره اجزای قوانین اتوماسیون منبع خوبی است):

1. Trigger (محرک) — رویدادی که قانون را فعال می‌کند؛ برای اتوماسیون تیکت معمولاً Issue Created یا در پروژه‌های سرویس دسک، Form submitted است.
2. Condition (شرط) — فیلتری که تعیین می‌کند آیا قانون باید ادامه پیدا کند یا نه؛ مثلاً «Request Type برابر است با X».
3. Action (اقدام) — کاری که در صورت برقرار بودن شرط انجام می‌شود؛ مثل Assign کردن تیکت، تغییر Component، یا ارسال نوتیفیکیشن.
4. Branch (شاخه) — امکان اجرای شرط‌ها و اقدامات جداگانه روی زیرمجموعه‌ای از آیتم‌ها (مثلاً فقط روی ساب‌تسک‌های یک تیکت).

نکته‌ای که اغلب راهنماهای عمومی نادیده می‌گیرند این است که ترتیب Condition‌ها روی عملکرد قانون تأثیر مستقیم دارد. بهتر است ابتدا سبک‌ترین و سریع‌ترین شرط‌ها (مثل مقایسه یک فیلد ساده) را قرار دهید و شرط‌های سنگین‌تر (مثل جستجوی متنی در توضیحات یا فراخوانی Webhook خارجی) را در انتها بگذارید؛ این کار زمان اجرای هر قانون را کاهش می‌دهد و در پروژه‌هایی با ترافیک بالا اهمیت واقعی دارد.

۵ سناریوی عملی ارجاع خودکار تیکت که همین امروز می‌توانید پیاده کنید

در ادامه پنج قانون کاربردی می‌آید که مستقیماً روی صف تیکت‌های سرویس دسک شما قابل پیاده‌سازی است. هر سناریو شامل Trigger، Condition و Action دقیق است تا بتوانید بدون آزمون‌وخطا آن را در محیط Automation جیرا بسازید.

سناریوی ۱: ارجاع بر اساس نوع درخواست (Request Type)

ساده‌ترین و پایدارترین روش دسته‌بندی. وقتی کاربر یک فرم مشخص (مثلاً «درخواست دسترسی») را پر می‌کند، جیرا از قبل می‌داند نوع تیکت چیست.

1. Trigger: Issue Created
2. Condition: Request Type is "درخواست دسترسی"
3. Action: Assign issue to → تیم امنیت/زیرساخت

سناریوی ۲: ارجاع بر اساس Component فنی

وقتی درخواست‌کننده در فرم مشخص می‌کند مشکل مربوط به کدام سیستم است (مثلاً «شبکه»، «سخت‌افزار»، «نرم‌افزار حسابداری»)، از فیلد Component برای مسیریابی مستقیم به کارشناس متخصص همان حوزه استفاده کنید.

سناریوی ۳: دسته‌بندی بر اساس کلمات کلیدی در عنوان یا توضیحات

برای تیکت‌هایی که فرم ساختاریافته ندارند (مثلاً ایمیل‌هایی که مستقیماً به تیکت تبدیل می‌شوند)، می‌توانید Condition از نوع Issue fields condition با عملگر contains تعریف کنید تا کلماتی مثل «قطعی»، «کند شدن» یا «خطای پرداخت» را در متن جست‌وجو کند و بر اساس آن اولویت و تیم را تعیین کند.

سناریوی ۴: تشدید خودکار بر اساس نقض آستانه SLA

از Trigger اختصاصی SLA threshold breached (مخصوص Jira Service Management) استفاده کنید تا وقتی تیکتی به ۸۰٪ از زمان SLA خود نزدیک می‌شود، به‌صورت خودکار Priority آن افزایش یابد و به سرپرست تیم اطلاع داده شود — پیش از آن‌که نقض واقعی اتفاق بیفتد.

سناریوی ۵: توزیع بار بین اعضای تیم (Round-Robin)

به‌جای ارجاع همه تیکت‌های یک دسته به یک نفر ثابت، از اکشن Assign to round-robin یا ترکیب Smart Values برای چرخش بین چند عضو تیم استفاده کنید تا بار کاری به‌طور یکنواخت توزیع شود. این الگو به‌ویژه در داشبوردهای پشتیبانی مشتریان در جیرا که حجم تیکت بین چند کارشناس مشترک است، بسیار کاربردی است.

در تمرین‌های میدانی روی پروژه‌های سرویس دسک، معمول‌ترین اشتباه ادمین‌ها این است که یک قانون واحد و پیچیده برای همه سناریوها می‌سازند؛ در حالی که چند قانون کوچک و مجزا که هرکدام یک مسئولیت مشخص دارند، هم دیباگ‌کردن را ساده‌تر می‌کنند و هم احتمال تداخل بین قوانین را کاهش می‌دهند.

اگر تیم شما هنوز این قوانین را به‌صورت دستی پیکربندی نکرده و می‌خواهید بدانید کدام ترکیب از Trigger/Condition/Action برای ساختار سازمانی خودتان بهینه است، می‌توانیم در قالب یک نشست مشاوره‌ای، وضعیت فعلی گردش‌کار تیکت‌های شما را بررسی کنیم و نقشه راه اجرای آن را با هم بچینیم — این دقیقاً همان چیزی است که در آموزش پیشرفته و کانفیگ جیرا بلوط روی آن کار می‌کنیم.

استفاده از JQL و Smart Values برای قوانین اتوماسیون پیشرفته‌تر

بیشتر محتوای موجود درباره اتوماسیون جیرا در همین سطح (شرط‌های ساده بر اساس یک فیلد) متوقف می‌شود. اما برای ادمین‌های حرفه‌ای، ترکیب Automation با JQL (Jira Query Language) و Smart Values امکانات بسیار دقیق‌تری فراهم می‌کند:

• با شرط JQL condition می‌توانید منطق‌های ترکیبی پیچیده بنویسید، مثلاً: project = SD AND priority in (Highest, High) AND "Request Type" = "قطعی سرویس" تا فقط تیکت‌های واقعاً بحرانی مسیر تشدید را طی کنند.
• با Smart Value مثل {{issue.reporter.displayName}} یا {{issue.description}} می‌توانید محتوای پویا را در نوتیفیکیشن‌ها، کامنت‌های خودکار یا حتی در تصمیم مسیریابی استفاده کنید.
• عبارات شرطی Smart Value مانند {{#if}} به شما اجازه می‌دهند منطق if/else را مستقیم داخل یک اکشن پیاده کنید، بدون نیاز به ساخت چند Branch جداگانه.

این لایه از پیکربندی معمولاً همان جایی است که تیم‌های فنی بعد از چند ماه استفاده از اتوماسیون ساده، به آن نیاز پیدا می‌کنند — وقتی قوانین ساده دیگر جوابگوی پیچیدگی واقعی گردش‌کار سازمان نیستند. برای مرور نمونه‌های بیشتر از قوانین آماده و کاربردی، این مقاله انجمن رسمی Atlassian با ۱۰ قانون اتوماسیون پرکاربرد نقطه شروع خوبی است. همچنین راهنمای رسمی Atlassian درباره اتوماسیون در Jira Service Management به‌روزترین قابلیت‌های این بخش را پوشش می‌دهد.

جدول مقایسه: روش‌های مختلف مسیریابی تیکت در جیرا

دیباگ و رفع خطای قوانین اتوماسیون با Audit Log

یکی از رایج‌ترین سوالاتی که ادمین‌های تازه‌کار جیرا می‌پرسند این است: «چرا قانونی که ساختم اجرا نشد؟» پاسخ تقریباً همیشه در Audit Log اتوماسیون است، بخشی که خیلی از راهنماهای عمومی حتی اشاره‌ای به آن نمی‌کنند. برای دیباگ سیستماتیک:

1. از صفحه پروژه، وارد Project settings → Automation شوید و روی قانون مدنظر کلیک کنید.
2. تب Audit log را باز کنید — این بخش هر بار اجرای قانون را به همراه نتیجه هر Condition (عبور یا رد) نمایش می‌دهد.
3. اگر قانون اصلاً در لاگ ظاهر نشده، مشکل از Trigger است (مثلاً قانون روی پروژه یا نوع Issue اشتباه فعال شده).
4. اگر قانون اجرا شده اما در یک Condition متوقف شده، مقدار واقعی فیلد را در همان لحظه با مقداری که در شرط انتظار داشتید مقایسه کنید — تفاوت‌های ظاهراً کوچک (مثل فاصله اضافه یا حروف بزرگ/کوچک در مقدار متنی) رایج‌ترین علت شکست است.
5. برای قوانینی که به Webhook یا سرویس خارجی متکی هستند، کد پاسخ HTTP را در همان Audit Log بررسی کنید؛ بسیاری از شکست‌ها به‌خاطر timeout یا احراز هویت نامعتبر است، نه اشکال منطقی در قانون.

نکته عملی: همیشه بعد از ساخت یک قانون جدید، آن را روی چند تیکت واقعی (یا با قابلیت Simulate در صورت وجود) تست کنید، نه این‌که مستقیم روی محیط Production فعال کنید و منتظر بمانید ببینید چه اتفاقی می‌افتد.

محدودیت‌ها و ملاحظات مقیاس: Global Rules در برابر Project Rules

وقتی تعداد قوانین اتوماسیون در سازمان شما از چند ده مورد عبور می‌کند، دو موضوع فنی اهمیت پیدا می‌کند که در محتوای عمومی کمتر به آن پرداخته می‌شود:

• محدودیت اجرای اتوماسیون (Automation execution limits) — پلن اشتراک سازمان (Free، Standard، Premium، Enterprise) سقف مشخصی برای تعداد اجرای قوانین در ماه تعیین می‌کند. اگر چند قانون سنگین روی هر تیکت اجرا شوند، ممکن است زودتر از حد انتظار به این سقف برسید.
• تفاوت Global Rule و Project Rule — قوانین سراسری (Global) روی همه پروژه‌ها اجرا می‌شوند و مدیریت متمرکزی دارند، اما دیباگ‌کردن آن‌ها سخت‌تر است چون باید بدانید کدام پروژه باعث فعال‌شدن قانون شده. برای گردش‌کارهای اختصاصی یک تیم، معمولاً Project Rule انتخاب امن‌تری است چون بلست ریدیوس (blast radius) خطای احتمالی محدود به همان پروژه می‌ماند.

توصیه عملی: قوانین حیاتی و تکرارشونده بین چند پروژه (مثل نوتیفیکیشن‌های استاندارد یا SLA) را در سطح Global بسازید، اما منطق اختصاصی هر تیم پشتیبانی را در همان پروژه نگه دارید تا تغییرات یک تیم روی تیم دیگر اثر جانبی نگذارد.

چک‌لیست اجرایی: از صفر تا اتوماسیون تیکت در سرویس دسک جیرا

1. ابتدا Request Type‌ها و Component‌های پروژه را استاندارد و کامل کنید — اتوماسیون روی داده نامرتب، نتیجه نامرتب می‌دهد.
2. لیستی از سناریوهای پرتکرار ارجاع دستی تهیه کنید (همان‌هایی که تیم شما هر روز تکرار می‌کند).
3. برای هر سناریو، یک قانون مجزا و ساده بسازید؛ از ساخت یک قانون غول‌پیکر با ده‌ها شرط خودداری کنید.
4. هر قانون را روی چند تیکت واقعی تست کنید و نتیجه را در Audit Log بررسی کنید.
5. پس از اطمینان از عملکرد صحیح، قانون را فعال (Enable) کنید و یک هفته اول را از نزدیک پایش کنید.
6. هر ماه یک بار، Audit Log قوانین پرتکرار را مرور کنید تا نرخ شکست غیرعادی یا Condition‌های منقضی‌شده (مثل ارجاع به کارمندی که دیگر در تیم نیست) را شناسایی کنید.

اشتباهات رایج در پیاده‌سازی اتوماسیون تیکت جیرا و راه پیشگیری

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

اشتباه ۱: ساخت یک قانون واحد برای همه‌چیز

وقتی همه منطق مسیریابی — از تشخیص نوع درخواست تا تعیین اولویت و اطلاع‌رسانی — در یک قانون واحد با ده‌ها Condition و Branch جمع می‌شود، هر تغییر کوچک ریسک شکستن کل زنجیره را دارد. راه‌حل ساده این است که هر قانون، دقیقاً یک مسئولیت داشته باشد؛ اگر توضیح دادن کارکرد یک قانون به همکار جدید بیش از دو جمله طول می‌کشد، احتمالاً باید آن را به چند قانون کوچک‌تر تقسیم کنید.

اشتباه ۲: نادیده گرفتن تیکت‌های Edge Case

قوانینی که فقط برای «حالت معمول» طراحی شده‌اند، معمولاً تیکت‌های بدون Request Type مشخص (مثل تیکت‌های ایجادشده از طریق ایمیل خام یا API) را نادیده می‌گیرند و این تیکت‌ها بی‌صاحب در صف باقی می‌مانند. همیشه یک قانون «Catch-all» با اولویت پایین‌تر بسازید که هر تیکتی که در هیچ‌کدام از Conditionهای دیگر جا نگرفت را به یک صف بازبینی دستی (Triage Queue) ارجاع دهد، نه این‌که بدون صاحب رها شود.

اشتباه ۳: عدم به‌روزرسانی قوانین هم‌زمان با تغییر ساختار تیم

یکی از رایج‌ترین منابع خطای «خاموش» — یعنی خطایی که هیچ هشداری تولید نمی‌کند اما نتیجه اشتباه می‌دهد — این است که یک قانون تیکت‌ها را به فردی ارجاع می‌دهد که دیگر در آن تیم نیست یا سازمان را ترک کرده. چون این نوع خطا هیچ ارور فنی تولید نمی‌کند، فقط با مرور دوره‌ای Audit Log و لیست اعضای فعال هر تیم قابل شناسایی است، همان چیزی که در چک‌لیست پایش ماهانه به آن اشاره شد.

اشتباه ۴: تست نکردن روی داده واقعی

قوانینی که فقط با یک یا دو تیکت آزمایشی ساخته‌شده توسط خود ادمین تست می‌شوند، اغلب در برابر تنوع واقعی ورودی کاربران (غلط املایی، فیلدهای خالی، مقادیر غیرمنتظره) شکست می‌خورند. قبل از فعال‌سازی نهایی، قانون را روی نمونه‌ای از تیکت‌های واقعی چند هفته اخیر (به‌صورت شبیه‌سازی یا در محیط Staging) اجرا کنید.

نتیجه‌گیری

اتوماسیون تیکت جیرا یک پروژه یک‌باره نیست؛ یک فرآیند تدریجی است که با چند قانون ساده شروع می‌شود و با رشد سازمان، به سمت ترکیب JQL، Smart Values و حتی طبقه‌بندی هوشمند پیش می‌رود. نقطه شروع درست، استانداردسازی Request Type و Component‌هاست؛ بدون این پایه، هیچ قانون اتوماسیونی — هرقدر هم پیچیده — نتیجه پایداری نخواهد داد. اگر همین امروز می‌خواهید شروع کنید، از یک سناریوی پرتکرار و کم‌ریسک (مثل ارجاع بر اساس Request Type) آغاز کنید، آن را کامل تست کنید، سپس به‌تدریج سناریوهای پیچیده‌تر مثل تشدید خودکار SLA یا مسیریابی مبتنی بر JQL را اضافه کنید.

سوالات متداول درباره اتوماسیون تیکت جیرا

آیا اتوماسیون تیکت جیرا در نسخه Free هم در دسترس است؟

بله، Jira Service Management در پلن Free هم امکان ساخت قوانین اتوماسیون در سطح پروژه را می‌دهد، اما سقف تعداد اجرای ماهانه قوانین به‌مراتب پایین‌تر از پلن‌های Standard و Premium است. برای تیم‌های پشتیبانی با حجم تیکت بالا، رسیدن زودهنگام به این سقف یک محدودیت واقعی است که باید از ابتدا در طراحی قوانین لحاظ شود.

تفاوت اتوماسیون تیکت با Workflow Transition در جیرا چیست؟

Workflow، مسیر مجاز حرکت یک تیکت بین وضعیت‌ها (مثل Open، In Progress، Resolved) را تعریف می‌کند، اما خودش هیچ تصمیمی نمی‌گیرد. اتوماسیون لایه‌ای است که روی Workflow می‌نشیند و بر اساس شرط‌ها، تصمیم می‌گیرد چه زمانی و چگونه یک تیکت باید بین این وضعیت‌ها حرکت کند یا به چه کسی ارجاع شود.

آیا می‌توان اتوماسیون تیکت را بین چند پروژه جیرا به‌اشتراک گذاشت؟

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

چرا قانون اتوماسیونی که ساختم روی برخی تیکت‌ها اجرا نمی‌شود؟

رایج‌ترین دلیل، عدم تطابق دقیق مقدار فیلد در Condition با مقدار واقعی تیکت است (مثلاً فاصله اضافه یا نام متفاوت یک Request Type). این موضوع را همیشه از طریق Audit Log قانون بررسی کنید تا دقیقاً ببینید کدام Condition تیکت را متوقف کرده است.

آیا اتوماسیون تیکت جیرا می‌تواند جایگزین کامل تیم پشتیبانی انسانی شود؟

خیر. اتوماسیون فقط لایه دسته‌بندی، مسیریابی و اقدامات تکراری اداری را حذف می‌کند؛ تشخیص و حل واقعی مشکل همچنان بر عهده کارشناس انسانی است. هدف اتوماسیون این است که کارشناسان زمان بیشتری برای حل مسئله داشته باشند، نه این‌که نیاز به آن‌ها از بین برود.

برای شروع اتوماسیون تیکت، از کجا باید Request Typeها و Componentها را استاندارد کرد؟

بهترین نقطه شروع، مرور صف تیکت‌های سه تا شش ماه اخیر و دسته‌بندی آن‌ها بر اساس موضوع تکراری است. اگر بیش از پنج تا ده تیکت مشابه با یک الگوی مشخص پیدا کردید، آن الگو کاندید مناسبی برای تعریف یک Request Type یا Component اختصاصی است.