لینک کوتاه مطلب : https://hsgar.com/?p=3901

DevOps یک شکست است | lbr.

احتمالاً برای اکثر مردم یادآوری اولین باری که یک کلمه را شنیدند دشوار است، اما من به یاد دارم که کلمه “DevOps” را برای اولین بار شنیدم. من در سال 2013 با یکی از همکارانم آبجو می خوردم که تقریباً همه چیزهایی را که در آن زمان می دانستم به من آموخت. من به اندازه کافی خوش شانس بودم که او را به شغل جدیدی که شروع کردم، آوردم، جایی که او می توانست کارهای هوشمندانه زیادی انجام دهد و من می توانستم کت هایش را سوار کنم. ما در حال بحث در مورد برخی از مشکلاتی بودیم که در شرکت جدید دیده بودیم که احتمالاً اکنون برای اکثر مردم آشنا هستند: ما در هنگام تولید برنامه برای پشتیبانی از آن مشکل داشتیم.

او در مورد این صحبت می کرد که چگونه باید زودتر در چرخه زندگی شرکت کنیم تا مطمئن شویم که همه در یک صفحه هستیم. او با لهجه قابل تقلید استرالیایی خود کلمه “DevOps” را ذکر کرد و این به من چسبید.

سال 2013 برای بازی در DevOps نسبتاً دیر بود. اگر از بیشتر مردم در مورد منشأ این اصطلاح بپرسید، دو لحظه اساسی که به نظر می رسد همه با آن موافق هستند، ملاقات پاتریک دبویز و اندرو کلی شافر در کنفرانس چابک در تورنتو و صحبت های توسط جان آلسپاو و پل هاموند در Velocity ’09

در آن زمان ایده ها ساده بودند: اصلاح فرهنگ. از آن زمان، این اصطلاح زندگی خود را به خود گرفته است. ما اکنون “DevOps Engineer” را به عنوان عنوان شغلی داریم.

چیزی که همیشه در مورد DevOps به عنوان یک رشته برای من کنجکاو بوده این است که چقدر این اصطلاح به سمت عملیات حصار منحرف شده است. فکر می‌کنم هرکسی که این مطلب را می‌خواند موافق است که برای موفقیت «DevOps»، هر دو طرف شکاف باید شرکت کنند، اما اگر به تمام کنفرانس‌های روزهای DevOps که تا به حال در آن شرکت کرده‌ام فکر کنم، شواهد حکایتی دارم. گردآوری شده است که کنفرانس هستند به شدت با حضور عملیات، و کمتر با حضور توسعه دهندگان.

DevOps فقط عملیات است

پنج سال پس از آن مکالمه با دوست استرالیایی ام، من در جلسه دیگری در همان کارفرما نشسته بودم که یکی از همکاران در سطح مدیر که توسعه یکی از محصولات ما را رهبری می کرد، گفت که تیم های او «توسعه دهندگان واقعی» هستند. یادم می‌آید که با این موضوع به طرز باورنکردنی گیج شدم. آنها هرگز در مورد نیازهای عملیاتی خود با ما صحبت نکرده بودند، ما حتی نمی دانستیم که آنها چه می کنند – تنها چیزی که می دانستیم این بود که آنها از AWS ECS برای استقرار برنامه خود استفاده می کردند. اگر تیم عملیاتی ما حتی درگیر نبود، چگونه می‌توانستند «توسعه‌دهنده واقعی» باشند؟

وقتی شروع به گفتگو با توسعه دهندگان تیم کردم، متوجه منظور او شدم: توسعه دهندگان او تمام چرخه عمر برنامه را مدیریت می کردند. استفاده می کردند boto3 و نوشتن اسکریپت های استقرار برای ارسال نسخه های جدید. آن‌ها «مهندسین فول استک» را استخدام می‌کردند که در AWS و همچنین وظایف مهندس باطن مسلط بودند. به عنوان اولین پذیرنده ذهنیت مهندسی پلتفرم، من به نوعی گیج بودم که چرا این اتفاق می افتد. ما به خوبی در مسیر ساختن بودیم جاده سنگفرش شده به سبک نتفلیکس و تمام دلیل این امر آسان‌تر کردن زندگی آن‌ها، از بین بردن تمام دردهای استقرار و مدیریت چرخه حیات استقرار و زیرساخت‌ها بود. تنها منظور آنها از زمانی که می‌گفتند «توسعه‌کنندگان واقعی» هستند این بود که کار عملیاتی خودشان را انجام می‌دادند. چرا این کار را می کردند؟

یک نقطه عطف

گفتگوی بعدی اساساً کل جهان بینی من را در مورد DevOps تغییر داد، اما تا سال ها بعد، زمانی که من به آن ملحق شدم. پولومی. ما در حال ساختن جاده آسفالته خود با ابزارهای آزمایش شده و آزمایش شده ای بودیم که امروزه افراد عملیاتی آن را می شناسند و دوست دارند، ما مقداری GitLab CI داشتیم، ما مقداری Terraform داشتیم، حتی شروع به پاشیدن تعدادی Kubernetes روی مشکل کردیم. کمی اینطوری شد:

سلام، باید از پلتفرم ما استفاده کنید! ما همه این موارد را اصلاح کرده‌ایم و خیلی بهتر از چیزهایی است که شما ساخته‌اید

ممنون، اما ما علاقه ای نداریم

اره چرا قابل اطمینان تر، سریعتر است و از ابزارهای استاندارد صنعتی استفاده می کند

بله، اما ما هیچ یک از این چیزها را نمی دانیم. ما چیزهایی را که ساخته ایم درک می کنیم.

ناامیدانه دستانم را بالا انداختم و راه افتادم، با این باور که روزی آنها خطای راه خود را خواهند دید و به التماس کمک خواهند کرد. بالاخره ما بودیم عملیات. ما می دانیم که چگونه نرم افزار را در فضای ابری اجرا کنیم.

هیچ کدام از اینها در این مرحله منحصر به فرد نبود. خرج کرده بودم سال ها تلاش برای آوردن توسعه دهندگان به میز و مالکیت سربار عملیاتی آنها. من سعی کرده بودم آنها را متقاعد کنم که در کنفرانس های روزهای DevOps شرکت کنند. من کیسه‌های قهوه‌ای داخلی را انجام داده بودم و توضیح می‌دادم که پلتفرمی که می‌سازیم چه کار می‌کند و چگونه به آنها کمک می‌کند. من دعوا کرده‌ام، دعوا کرده‌ام و به‌طور کلی راهم را در گفتگوهای توسعه‌دهندگان مورد آزار و اذیت قرار داده‌ام که به‌شدت تلاش می‌کردم ذهنیت «DevOps» را به کل شرکت بیاورم و روشی که توسط این تیم تفسیر شده بود این بود: «ما خودمان این کار را می‌کنیم، متشکرم».

حدود 18 ماه بعد، من در حال حرکت بودم. من 2 سال بعد از آن می گویم که اساساً چقدر در اشتباه بودم و DevOps همانطور که می دانیم یک شکست بزرگ است.

از زمان پیوستن پولومی، من دنیا را از دریچه ای متفاوت می بینم: دنیای توسعه دهندگان.

اگر شکست بخورم فقط غرور است

با نگاهی به گذشته، برای من واضح است که چرا این تلاش برای تغییر فرهنگ شکست خورد، اما در آن زمان نتوانستم آن را ببینم. با یادآوری ایده‌های DevOps در ابتدای راه‌اندازی، هدف از بین بردن اصطکاک بین توسعه‌دهندگان و عملیات‌ها بود: باید عملیات‌ها «نه» نگویند و توسعه‌دهندگان نگویند «yolo lets ship it» را متوقف کنند. آن ایده‌ها و اهداف هنوز هم اصیل هستند و سازمان‌ها هنوز هم باید به دنبال آن‌ها باشند، اما دنیای DevOps واقعاً چگونه است؟

در نهایت، ارزیابی من از DevOps در سال 2022 این است:

DevOps درباره افرادی است که در سمت عملیات حصار هستند و سعی می کنند توسعه دهندگان را متقاعد کنند تا کارها را به روش خود انجام دهند.

تقریباً تمام ابزارهایی که به‌عنوان «ابزار DevOps» به بازار عرضه می‌شوند بر روی عملیات متمرکز هستند. اگر /r/devops را مرور کنید، پست پس از پست افرادی را خواهید دید که در مورد عملیات و ابزار عملیاتی صحبت می کنند. اگر به شرح شغل مهندس DevOps نگاه کنید، به طور قابل توجهی شبیه به نقش مدیر سیستم در سال 2013 است، اما با برخی از کانتینرها و مدیریت ارائه‌دهنده ابری به‌جای racking و stacking سرورها.

اگر قرار بود DevOps در مورد تغییر فرهنگ کلی باشد، نمی توان آن را به عنوان یک حرکت موفق تلقی کرد. مردم در سمت عملیات حصار با خوشحالی می گویند “خب، ما تلاش می کنیم!” اما منظور آنها از آن این است که آنها تلاش می‌کنند به سمت ملاحظات عملیاتی حرکت کنند – این یک خیابان دو طرفه نیست.

این ارزش را دارد که به عنوان یک فرد عملیاتی به خاطر بسپاریم کمترین 5/1 در هر سازمان مهندسی معین. تلاش برای متقاعد کردن آخرین توسعه دهندگان برای انجام کارها “به روش عملیات” و “استفاده از ابزار عملیات” در نهایت یک کار احمقانه است. ما نیاز به تغییر داریم.

در مورد آن جه می توانیم انجام دهیم؟

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

گاهی اوقات به خاطر سپردن آن سخت است، اما به عنوان افراد متمرکز بر عملیات، نقش ما این است که توسعه دهندگان را قادر و تسهیل کنیم تا ویژگی ها را در دست مشتریان (یا هر هدف تجاری دیگری که ممکن است داشته باشند) داشته باشند. ایجاد مسیر کمترین مقاومت، بخش مهمی از جعل و حفظ سرعت برای توسعه‌دهندگانی است که محصولات و ویژگی‌ها را حمل می‌کنند، و اینکه توسعه‌دهندگان یاد بگیرند و تمام اقدامات عملیاتی را حفظ کنند، مقیاس‌پذیر یا امکان‌پذیر نیست.

اگر تا اینجا خوانده اید و موافقید که “DevOps” تلاشی برای آوردن توسعه دهندگان از پشت حصار به دنیای عملیات بوده است، و شما همچنین موافق باشید که تا حد زیادی آن تلاش شکست خورده است، ممکن است موافق باشید که ما به یک اصطلاح جدید نیاز داریم.

بنابراین من یکی را بیرون می اندازم. بیایید تلاش کنیم SoftOps.

اگر اولین فکر شما این است که “این یک نام مزخرف است” پس حق با شماست، اما این نام مزخرفی است که به یاد خواهید آورد.

SoftOps این ایده است که ما قصد داریم شیوه های عملیاتی را با تمرکز بر بهبود زندگی توسعه دهندگان ایجاد کنیم. قرار نیست بگو آنها چه کاری انجام دهند، ما می رویم پرسیدن آن‌ها کاری را که می‌خواهند انجام دهند، از نظر عملیاتی، و سپس آن را تا جایی که ممکن است برایشان آسان کنیم.

روزهای “دانلود این ابزار، خواندن این صفحه مرد 48 صفحه و به PM خود بگویید که ضرب الاجل های سرعت خود را از دست داده اید” گذشته است و علاوه بر آن، روزهای “فقط آن را به من بدهید و من می دهم” گذشته است. این کار را برای شما انجام دهد.

SoftOps این ایده است که شما توسعه دهندگان را به عنوان مشتری اصلی خود در اولویت قرار دهید. ایجاد شیوه‌های عملیاتی که با دنیای توسعه‌دهندگان صحبت می‌کند، باید (در تئوری) توسعه‌دهندگان را به میز مذاکره بیاورد تا به طور مشترک کار کنند. شاید اگر تنها بر روی آن هدف تمرکز کنیم، در نهایت مشکلاتی را که DevOps در سال 2009 تلاش کرده بود حل کنیم.

کی با منه؟

لینک منبع

ارسال یک پاسخ

آدرس ایمیل شما منتشر نخواهد شد.