چگونه شاخص‌های DORA عملکرد مهندسی نرم‌افزار را بدون ردیابی خروجی فردی می‌سنجند

تیم‌های مهندسی نرم‌افزاری که روزی چند بار کد به محیط عملیاتی می‌فرستند، اکنون هزاران بار سریع‌تر از تیم‌هایی که برنامه استقرار ماهانه دارند، سرویس‌ها را پس از قطعی‌های فاجعه‌بار بازیابی می‌کنند. این وارونگی در مدل سنتی ریسک فناوری اطلاعات — جایی که حرکت سریع‌تر در واقع به خرابی‌های بحرانی کمتری منجر می‌شود — یافته بنیادین چارچوب «تحقیق و ارزیابی دواپس» (DORA) است؛ چارچوبی که در دهه گذشته به استاندارد صنعت برای سنجش عملکرد تحویل نرم‌افزار تبدیل شده است.[1][7]

از نظر تاریخی، دپارتمان‌های مهندسی همیشه در تلاش بوده‌اند تا بهره‌وری را بدون تشویق به عادات مخرب، کمّی‌سازی کنند. شمارش خطوط کد به نرم‌افزارهای متورم ختم می‌شد؛ شمارش تیکت‌های بسته‌شده توسعه‌دهندگان را ترغیب می‌کرد تا باگ‌های پیش‌پاافتاده را گلچین کنند. چارچوب DORA که در سال ۲۰۱۴ توسط دکتر نیکول فورسگرن، جز هامبل و جین کیم توسعه یافت و در سال ۲۰۱۸ توسط گوگل خریداری شد، ردیابی خروجی فردی را به‌طور کامل کنار گذاشت. در عوض، این چارچوب سرعت و پایداری سیستمی کل پایپ‌لاین تحویل را با استفاده از چهار شاخص مشخص ارزیابی می‌کند.[1][2]

این چارچوب عملکرد را به دو دسته تقسیم می‌کند: سرعت (کدها با چه سرعتی حرکت می‌کنند) و پایداری (چقدر خوب اجرا می‌شوند). اولین شاخص سرعت، «فرکانس استقرار» است. این شاخص می‌سنجد که یک سازمان هر چند وقت یک‌بار کدها را با موفقیت در محیط عملیاتی منتشر می‌کند. در حالی که تیم‌های ضعیف بین ماهی یک‌بار تا هر شش ماه یک‌بار استقرار دارند، تیم‌های نخبه بر اساس تقاضا و اغلب با اجرای چندین استقرار در روز، کدها را مستقر می‌کنند.[3][4]

فرکانس بالای استقرار صرفاً یک شاخص نمایشی و توخالی نیست؛ بلکه فیزیک ریسک نرم‌افزار را از اساس تغییر می‌دهد. وقتی تیمی هر چند ساعت یک‌بار کد مستقر می‌کند، هر انتشار تنها شامل تعداد انگشت‌شماری تغییر است. اگر سیستم از کار بیفتد، تیم مهندسی دقیقاً می‌داند کدام دسته کوچک از کدها باعث خرابی شده است و همین امر، ایزوله کردن و بازگردانی آن را بسیار ساده می‌کند.[5][7]

با این حال، شعارهای تبلیغاتی فروشندگان ابزارهای یکپارچه‌سازی مداوم (CI) اغلب فرکانس بالای استقرار را به‌عنوان قابلیتی معرفی می‌کنند که به‌سادگی قابل خریداری است. اما در واقعیت، دستیابی به استقرارهای چندگانه روزانه نیازمند تست‌های خودکار سخت‌گیرانه و یک تغییر فرهنگی به‌سمت توسعه مبتنی بر ترانک (Trunk-based) است. یک شرکت نمی‌تواند یک پایپ‌لاین استقرار مدرن بخرد، آن را به یک کدبیس یکپارچه و قدیمی وصله کند و انتظار داشته باشد که فوراً به وضعیت نخبگان دست یابد.[6][7]

دومین شاخص سرعت، «زمان تحویل تغییرات» است. این شاخص مدت‌زمان بین لحظه ثبت کد (کامیت) توسط توسعه‌دهنده در مخزن تا لحظه‌ای که آن کد با موفقیت در محیط عملیاتی اجرا می‌شود را ردیابی می‌کند. تیم‌های نخبه زمان تحویل را زیر یک ساعت نگه می‌دارند، در حالی که تیم‌های ضعیف اغلب بین یک تا شش ماه زمان نیاز دارند تا یک تغییر واحد را از میان تست‌های دستی، بررسی‌های امنیتی و هیئت‌های مشاوره تغییرات عبور دهند.[1][3]

زمان تحویل در واقع اصطکاک درون بوروکراسی یک سازمان را می‌سنجد. زمان تحویل طولانی نشان می‌دهد که کدها به‌جای اینکه فعالانه روی آن‌ها کار شود، بیشتر چرخه حیات خود را در صف‌های انتظار می‌گذرانند. با بهینه‌سازی زمان تحویل، سازمان‌ها مجبور می‌شوند تست‌ها و تطابق‌های امنیتی خود را خودکار کرده و این بررسی‌ها را به مراحل اولیه‌تر فرآیند توسعه منتقل کنند.[4][7]

با این وجود، سرعت به‌تنهایی کافی نیست. این چارچوب سرعت را با دو شاخص پایداری متعادل می‌کند که اولین آن‌ها «میانگین زمان بازیابی» (MTTR) یا همان زمان بازگردانی سرویس است. این شاخص می‌سنجد که چقدر طول می‌کشد تا یک سازمان از یک خرابی در محیط عملیاتی، مانند قطعی برنامه‌ریزی‌نشده یا اختلال شدید در سرویس، بازیابی شود.[2][5]

تیم‌های نخبه به MTTR کمتر از یک ساعت دست می‌یابند. از آنجا که استقرارهای آن‌ها کوچک و مکرر است، بازگردانی سرویس اغلب به چیزی بیشتر از یک رول‌بک (بازگشت) یک‌کلیکی به وضعیت قبلی نیاز ندارد. تیم‌های ضعیف که استقرارهای عظیم و نادرشان هزاران تغییر را در هم می‌تند، ممکن است بین یک هفته تا یک ماه زمان ببرند تا گره یک خرابی بحرانی را باز کرده و عملیات عادی را بازیابی کنند.[1][6]

شاخص نهایی «نرخ شکست تغییرات» (CFR) است که درصد استقرارهایی را محاسبه می‌کند که باعث خرابی در محیط عملیاتی شده و نیازمند اصلاح فوری هستند. نکته کلیدی این است که CFR کیفیت خود فرآیند استقرار را می‌سنجد. تیم‌های نخبه CFR را بین ۰٪ تا ۱۵٪ نگه می‌دارند، در حالی که تیم‌های ضعیف شاهد نرخ شکستی بین ۴۶٪ تا ۶۰٪ هستند.[3][4]

کشف تعیین‌کننده تحقیقات DORA، که بر اساس نظرسنجی از بیش از ۳۳ هزار متخصص در طول هفت سال به‌دست آمده، این است که سرعت و پایداری یک بازی حاصل‌جمع صفر نیستند. مدیریت سنتی فناوری اطلاعات تصور می‌کرد که کاهش سرعت و افزودن دروازه‌های تایید دستی باعث افزایش ایمنی می‌شود. اما داده‌ها دقیقاً عکس این موضوع را ثابت می‌کنند: تیم‌هایی که سریع‌ترین استقرارها را دارند، کمترین خرابی‌ها را نیز تجربه کرده و سریع‌تر از همه از آن‌ها بازیابی می‌شوند.[1][2]

با وجود پشتوانه تجربی، پیاده‌سازی شاخص‌های DORA اغلب با نقص همراه است. این شاخص‌ها برای سنجش عملکرد تیم و سیستم طراحی شده‌اند، اما مدیریت اغلب سعی می‌کند از آن‌ها به‌عنوان سلاحی برای تعیین سهمیه عملکرد فردی استفاده کند. وقتی توسعه‌دهندگان بر اساس فرکانس استقرار شخصی‌شان ارزیابی شوند، ناگزیر با اسکریپت‌نویسی برای کامیت‌های خرد و بی‌معنی سیستم را دور می‌زنند و داده‌ها را عملاً بی‌فایده می‌کنند.[5][6]

علاوه بر این، استخراج دقیق شاخص‌های DORA از یک زنجیره ابزار ازهم‌گسیخته، خود یک چالش مهندسی قابل‌توجه است. همان‌طور که IBM و New Relic در راهنماهای پیاده‌سازی خود مستند کرده‌اند، ردیابی یک تغییر واحد از یک تیکت جیرا (Jira) تا یک کامیت گیت‌هاب (GitHub)، یک بیلد جنکینز (Jenkins) و یک حادثه پیجردیوتی (PagerDuty)، نیازمند یکپارچه‌سازی‌های پیچیده API و پایپ‌لاین‌های داده نرمال‌سازی‌شده است.[4][5]

بسیاری از سازمان‌ها به شاخص‌های جایگزین یا داده‌های خوداظهاری نظرسنجی‌ها بسنده می‌کنند که اغلب تصویری بیش‌ازحد خوش‌بینانه از توانمندی‌هایشان ترسیم می‌کند. مشاهده‌پذیری واقعی DORA نیازمند تله‌متری خودکار و غیرفعالی است که نتواند توسط تیم‌هایی که در تلاش برای رسیدن به اهداف دلخواه مدیریت هستند، دستکاری شود.[3][6]

در سال ۲۰۲۱، گوگل کلاد (Google Cloud) این چارچوب را گسترش داد تا شاخص پنجمی به نام «قابلیت اطمینان» (Reliability) را نیز در بر بگیرد که شامل اهداف در دسترس بودن، تاخیر و عملکرد است. این افزونه اذعان می‌کند که اگر سرویس زیربنایی نتواند انتظارات کاربر یا اهداف سطح سرویس را برآورده کند، استقرار سریع و ایمن کدها هیچ اهمیتی نخواهد داشت.[1][2]

چارچوب DORA همچنان دقیق‌ترین و مبتنی‌برشواهدترین مدل برای ارزیابی تحویل نرم‌افزار است. این چارچوب سازمان‌ها را مجبور می‌کند تا با واقعیت پایپ‌لاین‌های مهندسی خود روبه‌رو شوند و بحث‌های ذهنی درباره بهره‌وری توسعه‌دهندگان را با داده‌های عینی درباره نتایج سیستمی جایگزین کنند. مرز بعدی برای این صنعت، تعریف ظاهر عملکرد نخبگان نیست، بلکه ساخت تله‌متری خودکاری است که برای ردیابی آن بدون اتکا به نظرسنجی‌های دستی مورد نیاز است.[1][4][7]