حتماً این روزا اسم DevOps به گوشتون خورده، نه؟ یعنی ترکیب دو بخش برنامه‌نویسی (Development) و عملیات (Operation) با هم تو یک تیم یا همکاری نزدیک؛ هدفش هم اینه که کارا سریع‌تر و کم‌خطاتر جلو بره. کلی شرکت دارن میرن سمت DevOps، اما یه سوال اساسی همیشه وجود داره: تو بین این همه مدل تیمی مختلف DevOps، کدومش بهتر جواب میده و چرا؟
خب، یه سری محقق اومدن یه پژوهش حسابی انجام دادن که ببینن واقعاً ساختار و مدل تیم تو عملکرد بهتر DevOps چقدر تاثیر داره. اینکه تیم‌ها جدا باشن یا یکی باشن، همکاریشون چقدر باشه و… اینا همه‌ش سوال بود تا الان.
چجوری این تحقیق رو انجام دادن؟
محقق‌ها یه مدل/framework درست کردن که بتونن تاثیر انواع ساختارهای تیم DevOps رو روی عملکردشون بسنجن. برای اینکار اومدن یه نظرسنجی جهانی گذاشتن، کلی متخصص DevOps رو هدف گرفتن (یعنی Targeted outreach، یعنی به صورت هدفمند با آدمای اون حوزه ارتباط گرفتن)، از شبکه‌های اجتماعی کمک گرفتن و با روش “snowball sampling” (یعنی یکی معرفی کنه به یکی دیگه و همین‌جوری ادامه پیدا کنه) پیام زدن. جمعاً ۳۸۰ پیام فرستادن، ۱۲۲ نفر جواب مثبت دادن، و ۱۰۵ نفر هم نظرسنجی رو کامل پر کردن؛ یعنی از بین کسایی که گفتن شرکت می‌کنیم، ۶۹.۷٪ مسیر رو تا آخر رفتن. عدد خوبیه!
معیارهایی که سنجیدن چی بود؟
پنج تا معیار یا همون metric برای سنجش عملکرد انتخاب کردن، که دوتاش جدید بود:
- Deployment Frequency: یعنی چند وقت یه بار بتونی آپدیت یا تغییر رو تو سیستم منتشر کنی (بذار میشه چند بار تو سال یا ماه کد رو رونمایی کنی)
- Number of Incidents: تعداد مشکلاتی که تو کار پیش میاد (یعنی چند بار سیستم دچار حوادث میشه)
- Number of Failures/Service Interruptions: تعداد دفعاتی که سیستم از کار میفته یا سرویس قطع میشه
- Mean Time to Recovery (MTTR): میانگین مدت زمانی که طول میکشه سیستم بعد از یه مشکل دوباره راه بیفته (یه جورایی میزان تیزهوشی و سرعت عمل تیمه)
- Lead Time (LT): مدت زمانی که طول میکشه تا یه تغییر از مرحله ایده تا اجرا برسه (یعنی از اول تا آخر پروسه چقدر زمان می‌بره)
تیم‌ها رو چجوری دسته‌بندی کردن؟
چهار مدل تیمی رو بررسی کردن:
- تیم برنامه‌نویسی و عملیات جدا با همکاری محدود
- تیم برنامه‌نویسی و عملیات جدا با همکاری زیاد
- یه تیم واحد که همه چی رو با هم انجام میدن
- یه مدل خاص (تو نتایج توضیحش مشخص‌تره)
نتایج چی نشون داد؟
- تقریباً همه‌ی مدل‌های DevOps کمک کردن عملکرد تیم بهتر بشه. فقط تیمایی که برنامه‌نویسی و عملیاتشون کاملاً جدا بود و همکاریشون کم بود (همون TeamType1)، رشد خاصی تو معیارای اصلی نداشتن. فقط تو MTTR یا همون زمان بهبود پس از حادثه یه پیشرفت داشتن.
- جالب اینجاست که اگه تیم‌ها جدا باشن ولی همکاری زیادی داشته باشن (TeamType2)، بیشترین پیشرفت رو تو مهمترین معیارها دارن: تعداد دفعات انتشار (DF)، تعداد حوادث (NoI)، و تعداد اختلالات سرویس (NoF/NoSI). یعنی انگار همکاری کلید طلاییه!
- تو بخش‌های Lead Time و زمان بهبود بعد از حادثه (MTTR)، نوع ساختار تیم خیلی فرق خاصی ایجاد نکرد، یعنی اکثر مدل‌ها نتایج مشابهی تو این دو مورد داشتن.
- اما! تو تعداد دفعات انتشار، تیم‌های جدای با همکاری زیاد از تیم‌های کاملاً یکپارچه هم بهتر بودن. یعنی اگه می‌خواید سریع و زیاد تغییر منتشر کنید، ترکیب “تیم جدا + همکاری بالا” جواب میده.
- اینو با روش آماری Cohen’s d سنجیدن (یعنی چقد تاثیرگذاری یه عامل نسبت به بقیه زیاده).
برداشت آخر
آخرش چی میشه؟ اینکه همکاری و تعامل بالا بین تیم‌های Dev و Ops مهمترین چیزه و ساختار تیمی هرچی باشه اگه تعامل کم باشه، موفقیت نصفه‌نیمه‌ست. پس فقط اینکه “تیم DevOps داشته باشیم” کافی نیست؛ باید مطمئن شید همکاری درست و حسابی دارن. اگه تیماتون جداست، روش کار کنید ارتباطشون نزدیک‌تر شه. اگه تیم کامل یکپارچه دارید و همچنان به مشکلات می‌خورید، شاید باید به ساختار همکاریتون نگاه کنید.
کلاً این تحقیق نشون داد DevOps رو هرطور اجرا کنید (به جز مدل جدا-جدا و بی‌تعامل!) از تیم‌های قدیمی بهتر جواب می‌گیرید، فقط بازم همکاری حرف اول رو میزنه! یه جورایی تکرار همون نصیحت قدیمی: “تیم خوب= همکاری خوب”.
منبع: +
