Jira CloudData Centerتصمیم فنی

Jira Cloud یا Data Center؟ راهنمای تصمیم جیرا برای شرکت‌های ایرانی

محمد مهیار احمدی۸ دقیقه مطالعه

این تصمیم برای بیشتر شرکت‌های ایرانی، یک تصمیم فنی نیست. هر دو گزینه از نظر قابلیت به‌اندازهٔ کافی خوب‌اند؛ چیزی که انتخاب را تعیین می‌کند دسترسی، پرداخت و توان نگهداری است.

این نوشته سعی می‌کند همان چیزی را بگوید که در جلسهٔ اول با مشتری می‌گویم، بدون تعارف.

اول: گزینه‌ها الان چیست

Atlassian محصول Jira Server — نسخهٔ تک‌سروری با لایسنس دائمی — را بازنشسته کرده و دیگر پشتیبانی نمی‌شود. اگر هنوز روی Server هستید، روی محصولی نشسته‌اید که وصلهٔ امنیتی نمی‌گیرد. عملاً دو گزینه باقی مانده:

  • Jira Cloud — میزبانی روی زیرساخت Atlassian، اشتراک ماهانه یا سالانه، به‌روزرسانی خودکار.
  • Jira Data Center — نصب روی زیرساخت خودتان، لایسنس سالانه، کنترل کامل و مسئولیت کامل.

تفاوت‌هایی که واقعاً روی طراحی اثر می‌گذارند

موضوعCloudData Center
به‌روزرسانیخودکار، بدون کنترل شما روی زماندست شماست، همراه با کار و ریسک
دسترسی به دیتابیسنداریددارید — برای عیب‌یابی و گزارش سنگین ارزشمند است
سقف فیلد سفارشیسقف عملی دارد و روی سرعت اثر می‌گذاردمحدودیت سخت‌گیرانه‌تری ندارد ولی سرعت باز هم افت می‌کند
Automationسقف اجرای ماهانه بر اساس پلنبدون سقف اجرا، ولی بار روی سرور خودتان
افزونه‌هابعضی افزونه‌های قدیمی نسخهٔ Cloud ندارندکتابخانهٔ افزونهٔ بالغ‌تر برای موارد سازمانی
نوع پروژهدو مدل: Team-managed و Company-managedفقط مدل Scheme‌محور
نگهداریتقریباً صفربکاپ، ارتقا، مانیتورینگ، تیم زیرساخت

Team-managed در برابر Company-managed

این تفاوت مخصوص Cloud است و بیشتر از چیزی که به نظر می‌رسد اهمیت دارد.

در پروژهٔ Team-managed خود تیم وضعیت‌ها، فیلدها و Board را می‌سازد، بدون نیاز به ادمین. سریع و لذت‌بخش است. مشکل این است که این کانفیگ مال همان پروژه است و با پروژه‌های دیگر مشترک نمی‌شود. وقتی پنج تیم پنج پروژهٔ Team-managed بسازند، مقایسهٔ بین آن‌ها عملاً غیرممکن می‌شود.

در پروژهٔ Company-managed، کانفیگ از طریق Schemeهای مشترک می‌آید — همان مدلی که در Data Center می‌شناسید. کندتر است ولی برای سازمانی که می‌خواهد گزارش یکپارچه بگیرد، تنها انتخاب منطقی است. طراحی Scheme و Workflow مشترک بین چند پروژه را در طراحی Workflow در Jira توضیح داده‌ام.

واقعیت شرکت‌های ایرانی

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

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

شرکت‌هایی که شعبه یا شرکت مادر خارج از ایران دارند، معمولاً از همان مسیر لایسنس را تهیه می‌کنند و مشکلشان حل می‌شود. برای بقیه، Data Center — با وجود هزینهٔ نگهداری بالاترش — معمولاً تصمیم کم‌ریسک‌تری است، چون هیچ وابستگی ماهانه‌ای به یک سرویس بیرونی ندارد.

هزینهٔ واقعی Data Center

اشتباه رایج این است که فقط لایسنس را مقایسه می‌کنند. هزینهٔ واقعی Data Center شامل این‌هاست:

  • سرور و ذخیره‌سازی، معمولاً با معماری چندگره‌ای اگر پایداری مهم است
  • بکاپ منظم و — مهم‌تر — تست بازیابی. بکاپی که هیچ‌وقت بازیابی نشده، بکاپ نیست.
  • ارتقای دوره‌ای، که برای Jira کار سبکی نیست و باید روی محیط آزمایشی تمرین شود
  • زمان یک نفر که مالک این سیستم باشد — حتی اگر پاره‌وقت

قاعدهٔ سرانگشتی من: اگر تیم زیرساخت اختصاصی ندارید و تعداد کاربرانتان زیر صد نفر است، هزینهٔ نگهداری Data Center معمولاً از صرفه‌جویی‌اش بیشتر می‌شود — مگر اینکه مسئلهٔ دسترسی یا محرمانگی داده، تصمیم را از قبل گرفته باشد.

چک‌لیست تصمیم

پنج سؤال که جواب‌دادنشان معمولاً تصمیم را روشن می‌کند:

  1. آیا مسیر پرداخت ارزی پایدار و قانونی دارید؟ اگر نه، Cloud یک ریسک ماهانه است.
  2. آیا داده‌های شما محدودیت قانونی برای خروج از کشور دارند؟ اگر بله، تصمیم گرفته شده است.
  3. آیا کسی مالک نگهداری سرور خواهد بود؟ اگر جواب «همان آدم شبکه، در کنار کارهای دیگرش» است، Data Center انتخاب خوبی نیست.
  4. آیا به افزونه‌ای وابسته‌اید که فقط یک نسخه دارد؟ فهرست افزونه‌های فعلی‌تان را قبل از تصمیم بررسی کنید.
  5. چند کاربر دارید و در دو سال آینده چند نفر می‌شوید؟ پله‌های قیمتی هر دو مدل در نقاط مشخصی جهش دارند.

اگر تصمیم به مهاجرت گرفتید

مهاجرت در هر جهتی ممکن است، ولی چیزهایی هستند که معمولاً کامل منتقل نمی‌شوند. این‌ها را قبل از شروع بدانید تا وسط کار غافلگیر نشوید:

  • افزونه‌ها. دادهٔ داخل افزونه‌ها اغلب مسیر مهاجرت جدا دارد، و بعضی افزونه‌ها اصلاً معادل ندارند.
  • Automation. قوانین معمولاً باید بازسازی شوند، مخصوصاً آن‌هایی که به قابلیت‌های مخصوص یک پلتفرم تکیه دارند.
  • تاریخچهٔ کامل. بسته به روش مهاجرت، بخشی از تاریخچهٔ تغییرات ممکن است ساده‌سازی شود.
  • ادغام‌ها. هر چیزی که با API یا وب‌هوک وصل شده، آدرس و روش احراز هویتش عوض می‌شود.

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

جمع‌بندی

برای بیشتر شرکت‌های ایرانی، انتخاب بین Cloud و Data Center با دو سؤال حل می‌شود: مسیر پرداخت پایدار دارید یا نه، و کسی مالک نگهداری سرور هست یا نه. بقیهٔ تفاوت‌ها مهم‌اند ولی تعیین‌کننده نیستند. بعد از تصمیم، اولین کاری که واقعاً وقت آزاد می‌کند حذف کار دستی است: قوانین Automation در Jira.

اگر تازه با این ابزار آشنا می‌شوید، قبل از این تصمیم جیرا چیست؟ را بخوانید. و اگر می‌خواهید این تصمیم را با نگاه به وضعیت مشخص خودتان بگیرید و بعد ساختار درست روی همان پلتفرم ساخته شود، پیاده‌سازی و راه‌اندازی Jira از همین‌جا شروع می‌شود.

سؤالی دربارهٔ همین موضوع دارید؟

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

پرسیدن در واتساپ

خواندن بعدی

درخواست جلسهتماس