Jira Cloud یا Data Center؟ راهنمای تصمیم جیرا برای شرکتهای ایرانی
این تصمیم برای بیشتر شرکتهای ایرانی، یک تصمیم فنی نیست. هر دو گزینه از نظر قابلیت بهاندازهٔ کافی خوباند؛ چیزی که انتخاب را تعیین میکند دسترسی، پرداخت و توان نگهداری است.
این نوشته سعی میکند همان چیزی را بگوید که در جلسهٔ اول با مشتری میگویم، بدون تعارف.
اول: گزینهها الان چیست
Atlassian محصول Jira Server — نسخهٔ تکسروری با لایسنس دائمی — را بازنشسته کرده و دیگر پشتیبانی نمیشود. اگر هنوز روی Server هستید، روی محصولی نشستهاید که وصلهٔ امنیتی نمیگیرد. عملاً دو گزینه باقی مانده:
- Jira Cloud — میزبانی روی زیرساخت Atlassian، اشتراک ماهانه یا سالانه، بهروزرسانی خودکار.
- Jira Data Center — نصب روی زیرساخت خودتان، لایسنس سالانه، کنترل کامل و مسئولیت کامل.
تفاوتهایی که واقعاً روی طراحی اثر میگذارند
| موضوع | Cloud | Data 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 معمولاً از صرفهجوییاش بیشتر میشود — مگر اینکه مسئلهٔ دسترسی یا محرمانگی داده، تصمیم را از قبل گرفته باشد.
چکلیست تصمیم
پنج سؤال که جوابدادنشان معمولاً تصمیم را روشن میکند:
- آیا مسیر پرداخت ارزی پایدار و قانونی دارید؟ اگر نه، Cloud یک ریسک ماهانه است.
- آیا دادههای شما محدودیت قانونی برای خروج از کشور دارند؟ اگر بله، تصمیم گرفته شده است.
- آیا کسی مالک نگهداری سرور خواهد بود؟ اگر جواب «همان آدم شبکه، در کنار کارهای دیگرش» است، Data Center انتخاب خوبی نیست.
- آیا به افزونهای وابستهاید که فقط یک نسخه دارد؟ فهرست افزونههای فعلیتان را قبل از تصمیم بررسی کنید.
- چند کاربر دارید و در دو سال آینده چند نفر میشوید؟ پلههای قیمتی هر دو مدل در نقاط مشخصی جهش دارند.
اگر تصمیم به مهاجرت گرفتید
مهاجرت در هر جهتی ممکن است، ولی چیزهایی هستند که معمولاً کامل منتقل نمیشوند. اینها را قبل از شروع بدانید تا وسط کار غافلگیر نشوید:
- افزونهها. دادهٔ داخل افزونهها اغلب مسیر مهاجرت جدا دارد، و بعضی افزونهها اصلاً معادل ندارند.
- Automation. قوانین معمولاً باید بازسازی شوند، مخصوصاً آنهایی که به قابلیتهای مخصوص یک پلتفرم تکیه دارند.
- تاریخچهٔ کامل. بسته به روش مهاجرت، بخشی از تاریخچهٔ تغییرات ممکن است سادهسازی شود.
- ادغامها. هر چیزی که با API یا وبهوک وصل شده، آدرس و روش احراز هویتش عوض میشود.
پیشنهاد همیشگی من: مهاجرت را فرصت پاکسازی بدانید. انتقال بیست Workflow یتیم و صد فیلد بیاستفاده به محیط جدید، یعنی بردن همان مشکل به جای تازه.
جمعبندی
برای بیشتر شرکتهای ایرانی، انتخاب بین Cloud و Data Center با دو سؤال حل میشود: مسیر پرداخت پایدار دارید یا نه، و کسی مالک نگهداری سرور هست یا نه. بقیهٔ تفاوتها مهماند ولی تعیینکننده نیستند. بعد از تصمیم، اولین کاری که واقعاً وقت آزاد میکند حذف کار دستی است: قوانین Automation در Jira.
اگر تازه با این ابزار آشنا میشوید، قبل از این تصمیم جیرا چیست؟ را بخوانید. و اگر میخواهید این تصمیم را با نگاه به وضعیت مشخص خودتان بگیرید و بعد ساختار درست روی همان پلتفرم ساخته شود، پیادهسازی و راهاندازی Jira از همینجا شروع میشود.
سؤالی دربارهٔ همین موضوع دارید؟
بپرسید. اگر جوابش کوتاه باشد همانجا میگویم و اگر نیاز به بررسی داشته باشد، میگویم چه چیزی لازم است.
پرسیدن در واتساپخواندن بعدی
طراحی Workflow در جیرا: از وضعیتهای اضافه تا فرایندی که گزارش میدهد
طراحی Workflow در جیرا: چرا وضعیتهای اضافه گزارش را بیاعتبار میکنند، تفاوت status و statusCategory و resolution، و چهار ابزار روی هر Transition.
خواندنقوانین Automation در جیرا که بیشترین کار دستی را حذف میکنند
هشت قانون Automation در جیرا که واقعاً وقت آزاد میکنند، بههمراه سه اشتباهی که باعث میشود اتوماسیون به جای کمک، دردسر بسازد.
خواندن