تیم DevOps در مثال ها و کتاب ها وجود ندارد، بلکه تیم پلتفرم و تیم SRE وجود دارد، علت ایجاد تیم دواپس در سازمان ها و استارت آپ های ایرانی عدم شناخت سازمان از دواپس و ابعاد آن می باشد، و طبق معمول برداشتی آزاد از یک مجموعه تکنولوژی و Practice است. (اضافه کردن تیمی دیگر به نام DevOps باعث افزایش hands off ها شده و بر طبق lean باعث هدر رفت انرژی بیشتری در سازمان می گردد). گواه این موضوع تفاوت Practice های دواپس و فریمورکی مثل اسکرام است.
در این مقاله تلاش شده عواقب تشکیل تیم های نامناسب دواپس برای مهندسان عزیز تشریح گردد، در انتهای روز، عواقب و ضرر و زیان هایی که سازمان از پیاده سازی غلط تیم هایی با نام دواپس می نماید نه به نام تصمیم گیران و مدیران سازمان، بلکه به نام مهندسان و لایه پایین سازمان که دیواری کوتاه تر از دیگران دارند نوشته خواهد شد! پس وظیفه شما است که به عنوان یک مهندس از رزومه و آبروی کاری خود دفاع کنید (شجاعت و صداقت جزء نیازمندی های اصلی ایجاد Practice های دواپس هستند ).
در اسکرام تمامی رویدادها و محصولات و نقش تعریف شده است، ولی در دواپس نقشی به نام تیم دواپس تعریف نشده است و فقط به اصول و تجربیات موفق سازمان ها اشاره شده است، در نتیجه تیمی به نام دواپس وجود ندارد، ولی موضوعی که بیشتر از همه مورد تاکید قرار می گیرد تیم پلتفرم است. پلتفرم به عنوان یکی از مهم ترین دارایی های سازمان، مجموعه ایی از تکنولوژی و فرهنگ و فرآیند است که برگ برنده سازمان به نسبت رقبا است، مثل پیاده سازی ساختار Cloud native در سازمان.
در تصویر زیر چند روش نامناسب و بهترین چند روش مناسب نمایش داده شده اند.
- روش اشتباه A: که یکی از معمول ترین وضعیت های موجود در ایران است، و معمولا مدل و فرهنگ زیرساخت باعث فاصله بسیار زیاد با تیم توسعه می گردد، این وضعیت معمولا با اخراج و صدمه یکی از طرفین تصمیم گیری به پایان می رسد، علتی که باعث بروز مشکلات از سمت زیرساخت می گردد و نه تیم توسعه این است که،درصد تغییرات تیم توسعه بسیار بیشتر است و با گذشت ۱۵ سال از ارائه فریمورک ایی مثل اسکرام و مشخص شدن نتایج آنها زمان آن رسیده که روش فعالیت تیم زیرساخت نیز تغییر نماید. (آسیب شدید به سازمان)
- روش اشتباه B: معمول ترین و ساده ترین روشی که در ایران استفاده می گردد، که البته بر خلاف اصول دواپس می باشد و باعث اضافه شدن یک تیم دیگر و پیچیده تر شدن ارتباطات سازمانی می گردد در حالی که ارزش افزوده ایی برای سازمان ایجاد نمی کند، سازمان به جای رفع مشکل و تغییر فرهنگ سازمانی اقدام به استفاده نکردن از تجربیات موجود در دواپس می نماید، ولی متاسفانه اسم آن تیم را دواپس می گذارد!
- روش اشتباه C: در حالت پیاده سازی اشتباه A، اگر پیروز جنگ بین زیرساخت و توسعه، تیم زیرساخت باشد، معمولا تیم توسعه و افراد فعالی که هنوز اخراج نشده اند، اقدام به تشکیل هسته دواپس در درون تیم توسعه می نمایند که دسترسی محدودی به زیرساخت ها دارد. (این روش هم در انتها می تواند با محدود شدن عمدی و یا سهوی تیم دواپس توسط تیم زیرساخت باعث ارائه نتایج ضعیف شده و مهندسانی که عضو تیم دواپس هستند تخریب شده و از شرکت اخراج می گردند)
- روش درست 1: نتیجه حذف تیم دواپس در روش درست شماره ۵ و تحویل مسئولیت ها و فرایندها به تیم های Dev و Ops
- روش درست 2: در این روش تیم توسعه و تیم زیرساخت یکپارچه شده و با کمک یکدیگر مسئول اجرا، توسعه و نگهداری از سروس می باشند.
- روش درست 3: این حالت در سازمان هایی که بخش زیرساخت دارای ساختار قدیمی بوده و یا تغییرات را به کندی اعمال می نماید و یا زیرساخت را به Cloud منتقل نموده اجرا می گردد. تیم زیرساخت به صورت PaaS عمل خواهد نمود و سایر مسولیت ها بر عهده تیم دواپس خواهد بود.
- روش درست 4: تیم دواپس کم کم تبدیل به تیم پلتفرم خواهد شد، و به عنوان یک خدمت پلتفرم ایجاد شده را در اختیار سازمان قرار خواهد داد.
- روش درست 5: این ساختار معمولا در سازمان هایی که به تازگی شروع به حرکت به سمت دواپس نموده اند مشاهده می گردد، و تیم موقت دواپس وظیفه تحویل Practice های دواپس به هر دو تیم dev و ops را بر عهده دارد، و پس از تغییر فرهنگ و فرایند و ابزار سازمان، تیم دواپس منحل می گردد.
تیم دواپس در ایران
در ایران، با توجه به شرایط خاص حاکم بر سازمان های دولتی و نیمه دولتی و خصوصی باید نکات زیر را در نظر بگیرید.
- اگر سازمان شما دچار جنگ قدرت بین مدیران و یا تیم های مختلف است، معمولا بهینه سازی فرایندها و اجرای دواپس جز منافع سرپرستان و مدیران نخواهد بود، در نتیجه شما حتما باید به سمت ایجاد یک تیم مستقل DevOps یا همان Anti-type B حرکت کنید، در غیر اینصورت شانس شما جهت پیاده سازی دواپس به حداقل می رسد.
- به شکل خیلی ساده و با بررسی پیاده سازی فریمورک هایی مثل اسکرام در سازمان، می توان به این نتیجه رسید که آیا اعتماد نمودن به ساختار سازمان نتیجه بخش خواهد بود یا خیر. اگر نتیجه بخش است لطفا به فکر ایجاد یک تیم مستقل دواپس نباشید.
- معمولا در سازمان های دولتی پیاده سازی دواپس تقریبا غیر ممکن است.
- در سازمان های نیمه خصوصی نیز کار بسیار سختی پیش روی شما خواهد بود و بسته به شرایط سازمان ممکن است مدیران با دانشی حضور داشته باشند و از تغییرات استقبال نمایند.
- در بخش خصوصی عامل اصلی تعیین کننده، مدل درآمدی سازمان است و نقش تعیین کننده ایی را ایفا می نماید، اگر درآمد سازمان شما به شکلی از جای دیگری تامین می گردد ( به غیر از فروش محصولات و خدمات )، معمولا مدیران حاضر دارای دانش کافی نیستند و زمینه برای اعمال نظر شخصی آنها فراهم است، زیرا درآمد و موفقیت شرکت اولویت اصلی نیست، در چنین سازمان هایی اجرای دواپس بسته به سلیقه و نظر چنین مدیرانی ماهیتی متغیر می یابد، و حتی مفهوم دواپس و اسکرام را دچار تغییر می نمایند. در چنین سازمان های خصوصی حتما به فکر ایجاد یک تیم مستقل دواپس زیر نظر مدیر عامل باشید.