گزارش DORA چیست؟ تاریخچه، شاخص‌ها و کاربرد آن در مدیریت فناوری اطلاعات

وقتی مدیر فناوری اطلاعات می‌پرسد «تیم ما واقعاً در تحویل نرم‌افزار خوب عمل می‌کند یا فقط زیاد کار می‌کند؟»، پاسخ را نمی‌توان فقط از تعداد تسک‌های بسته‌شده یا ساعت کار پیدا کرد. یکی از معتبرترین رویکردهای داده‌محور برای پاسخ به این سؤال، پژوهش‌های DORA است.

DORA چیست؟

DORA مخفف DevOps Research and Assessment است؛ یک برنامه پژوهشی که رابطه میان شیوه‌های توسعه و عملیات، عملکرد تحویل نرم‌افزار و نتایج سازمانی را بررسی می‌کند. DORA استاندارد انطباق یا گواهینامه نیست؛ بلکه چارچوبی پژوهش‌محور برای اندازه‌گیری و بهبود عملکرد تحویل نرم‌افزار است.

سابقه DORA

ریشه پژوهش‌های DORA به گزارش‌های State of DevOps در دهه ۲۰۱۰ برمی‌گردد. پژوهش سال ۲۰۱۴ تلاش کرد به شکل علمی ارتباط میان عملکرد فناوری و عملکرد سازمان را بررسی کند. در سال ۲۰۱۶ Nicole Forsgren، Jez Humble و Gene Kim شرکت DevOps Research and Assessment را تأسیس کردند. در ۲۰ دسامبر ۲۰۱۸ نیز DORA به Google Cloud پیوست و تحقیقات آن ادامه پیدا کرد.

مدلی که سال‌ها با چهار شاخص کلیدی DORA شناخته می‌شد، در سال ۲۰۲۴ با اضافه شدن Deployment Rework Rate به مدل پنج‌معیاره توسعه یافت.

گزارش DORA چه چیزی را اندازه می‌گیرد؟

مدل فعلی DORA عملکرد تحویل نرم‌افزار را از دو زاویه می‌سنجد: Throughput یا توان عبور تغییرات و Instability یا ناپایداری تغییرات. ترکیب این دو دیدگاه مهم است؛ سرعت بالا بدون پایداری و پایداری بدون توان تحویل مناسب، هیچ‌کدام تصویر کاملی از عملکرد نمی‌دهند.

پنج شاخص اصلی DORA

۱. Change Lead Time

مدت زمانی که یک تغییر از Commit شدن در Version Control تا استقرار موفق در Production طی می‌کند. این شاخص گلوگاه‌های تست، تأیید، Release و وابستگی میان تیم‌ها را آشکار می‌کند.

۲. Deployment Frequency

نشان می‌دهد تیم در یک بازه زمانی چند بار تغییرات را با موفقیت به Production می‌رساند. هدف فقط زیاد کردن تعداد Deploy نیست؛ بلکه انتشار تغییرات کوچک‌تر با ریسک کنترل‌شده و فرایند قابل تکرار است.

۳. Failed Deployment Recovery Time

اگر یک Deploy باعث اختلال شود، چه مدت طول می‌کشد سرویس دوباره به وضعیت سالم بازگردد؟ Rollback، Hotfix و Fix Forward همگی در این شاخص اهمیت دارند.

۴. Change Fail Rate

درصد تغییراتی که پس از ورود به Production باعث اختلال و نیازمند اقدام اصلاحی فوری می‌شوند.

فرمول ساده: تعداد Deployهای نیازمند اصلاح فوری ÷ کل Deployها × ۱۰۰

۵. Deployment Rework Rate

این شاخص نسبت استقرارهای برنامه‌ریزی‌نشده‌ای را می‌سنجد که در واکنش به رخدادهای Production و برای اصلاح باگ‌ها یا مشکلات کاربرمحور انجام می‌شوند. این معیار نشان می‌دهد چه مقدار از ظرفیت تیم صرف ایجاد ارزش جدید و چه مقدار صرف دوباره‌کاری می‌شود.

سناریو: وقتی مدیر فکر می‌کند تیم توسعه کند است

فرض کنید یک شرکت خدمات مالی سامانه مشتریان خود را دائماً توسعه می‌دهد. مدیر کسب‌وکار از تأخیر ویژگی‌های جدید ناراضی است. توسعه می‌گوید تست و تأیید طول می‌کشد، عملیات از افزایش Release نگران است و امنیت نیز بر کنترل تغییر تأکید دارد.

به‌جای ادامه بحث بر اساس نظر افراد، تیم پنج شاخص DORA را برای همان سرویس اندازه می‌گیرد.

این اعداد صرفاً سناریوی آموزشی هستند و Benchmark رسمی DORA محسوب نمی‌شوند.

نتیجه روشن است: مشکل فقط سرعت برنامه‌نویسی نیست. Change Lead Time بالا نشان می‌دهد تغییرات در مسیر تحویل معطل می‌شوند و نرخ شکست و دوباره‌کاری بالا نیز بخشی از ظرفیت تیم را مصرف می‌کند.

از عدد تا اقدام اصلاحی

تیم Value Stream را بررسی می‌کند و متوجه می‌شود بخش بزرگی از Regression Test دستی است، Releaseها بزرگ هستند، Rollback استاندارد وجود ندارد و تغییرات کم‌ریسک و پرریسک از یک مسیر تأیید عبور می‌کنند.

1. خودکارسازی تست‌های پرتکرار و حیاتی؛
2. کوچک‌تر کردن Batch تغییرات؛
3. تعریف Risk-based Change Approval؛
4. ایجاد Rollback قابل تست؛
5. اتصال داده Pipeline به Change و Incident؛
6. بازبینی ماهانه شاخص‌های DORA.

سه ماه بعد، در سناریوی فرضی، وضعیت چنین می‌شود:

ارزش DORA در این نیست که برای همه سازمان‌ها یک عدد ثابت تعیین کند؛ ارزش آن در مشاهده روند، پیدا کردن گلوگاه و سنجش اثر اقدامات بهبود است.

DORA چه ارتباطی با GRC دارد؟

حاکمیت

مدیریت می‌تواند مشخص کند کدام سرویس‌ها حیاتی‌اند، Owner هر شاخص چه کسی است و چه سطحی از افت عملکرد نیازمند Escalation و تصمیم مدیریتی است.

ریسک

Change Fail Rate، Failed Deployment Recovery Time و Rework Rate می‌توانند شاخص هشدار ریسک عملیاتی باشند. در مدیریت ریسک MedaGRC می‌توان این شاخص‌ها را به Risk Register، مالک ریسک و برنامه پاسخ متصل کرد.

کنترل

کنترل‌هایی مثل Automated Testing، Peer Review، Change Approval، Segregation of Duties، Canary Deployment و Rollback را می‌توان به ریسک‌ها متصل کرد و اثربخشی آن‌ها را با روند شاخص‌های DORA سنجید.

Evidence و ممیزی

داده‌های CI/CD، سوابق Deploy، Change Record، Incident، Approval و نتایج تست می‌توانند به‌عنوان Evidence نگهداری شوند. این موضوع در مدیریت ممیزی و انطباق اهمیت زیادی دارد.

نمونه ثبت یک ریسک DORA در MedaGRC

• ریسک: افزایش اختلال سرویس ناشی از تغییرات ناموفق Production
• شاخص هشدار: Change Fail Rate
• Owner: مدیر مهندسی یا DevOps
• کنترل‌های مرتبط: تست خودکار، Code Review، Change Approval و Rollback
• Evidence: خروجی CI/CD، Deploy، Incident و Change Ticket
• اقدام اصلاحی: افزایش پوشش تست، کوچک‌سازی Release و بهبود Rollback
• بازبینی: ماهانه تا بازگشت روند به محدوده مورد انتظار

در این حالت DORA دیگر فقط یک داشبورد DevOps نیست؛ به بخشی از چرخه Risk، Control و Improvement تبدیل می‌شود.

چگونه DORA را در سازمان اجرا کنیم؟

1. با یک سرویس شروع کنید. شاخص‌های DORA در سطح Application یا Service معنا پیدا می‌کنند.
2. تعریف شاخص‌ها را ثابت کنید. Deploy، Failure، Recovery و Rework باید تعریف مشخص داشته باشند.
3. منابع داده را مشخص کنید. Git، CI/CD، Change Management، Service Desk و Monitoring مهم‌ترین منابع هستند.
4. Baseline بسازید. قبل از تعیین هدف چند هفته داده واقعی جمع کنید.
5. یک گلوگاه را انتخاب کنید. همه‌چیز را هم‌زمان اصلاح نکنید.
6. شاخص را به Risk و Control وصل کنید. اینجا داده فنی به تصمیم مدیریتی تبدیل می‌شود.
7. روند را ببینید. یک عدد منفرد برای قضاوت کافی نیست.

اشتباهات رایج در استفاده از DORA

DORA را KPI فردی نکنید. این شاخص‌ها برای سنجش سیستم تحویل نرم‌افزار هستند، نه رتبه‌بندی برنامه‌نویسان.

سرویس‌های نامشابه را مستقیم مقایسه نکنید. یک Core Banking و یک سایت محتوایی شرایط ریسک یکسانی ندارند.

فقط یک شاخص را هدف نگیرید. افزایش Deployment Frequency بدون توجه به Failure و Recovery می‌تواند نتیجه معکوس داشته باشد.

داشبورد بدون Action Plan نسازید. باید مشخص باشد وقتی شاخص از محدوده مورد انتظار خارج شد چه کسی اقدام می‌کند.

DORA و Change Management؛ مکمل یکدیگر

DevOps به معنای حذف کنترل تغییر نیست. فرایند بالغ، شدت کنترل را با ریسک تغییر متناسب می‌کند. تغییرات کم‌ریسک و تکرارشونده می‌توانند از کنترل‌های خودکار عبور کنند و تغییرات حساس تأیید دقیق‌تری داشته باشند.

این نگاه با مفهوم کنترل مبتنی بر ریسک در چارچوب‌ها و استانداردهای MedaGRC نیز سازگار است.

آیا DORA فقط برای شرکت‌های نرم‌افزاری است؟

خیر. هر سازمانی که نرم‌افزار یا سرویس دیجیتال را توسعه و تغییر می‌دهد می‌تواند از این شاخص‌ها استفاده کند؛ بانک، بیمه، فروشگاه آنلاین، سازمان دولتی، شرکت صنعتی یا تیم داخلی فناوری اطلاعات.

سخن پایانی

DORA قرار نیست به مدیر فناوری اطلاعات بگوید تیم او «خوب» است یا «بد». ارزش DORA در سؤال دقیق‌تری است: سیستم تحویل نرم‌افزار ما نسبت به گذشته بهتر شده است یا خیر؟

وقتی Change Lead Time، Deployment Frequency، Change Fail Rate، Failed Deployment Recovery Time و Deployment Rework Rate در کنار Incident، Change، Risk، Control و Evidence قرار بگیرند، مدیر می‌تواند بفهمد چه اتفاقی افتاده، چرا رخ داده، چه ریسکی ایجاد کرده، کدام کنترل مؤثر نبوده و آیا اقدام اصلاحی نتیجه داده است.

برای مطالب بیشتر، مرکز مقالات MedaGRC را ببینید.

منابع رسمی

• DORA Software Delivery Performance Metrics
• A History of DORA Software Delivery Metrics
• DORA Research 2014
• DORA Joins Google Cloud