بزرگترین طنز این است که DevOps قصد داشت به توسعه دهندگان کمک کند تا با عملیات صحبت کنند، و بالعکس، با این حال توسعه دهندگان حتی از درک نحوه عملکرد کدشان در زمان اجرا دورتر هستند.
تیم‌های مهندسی و توسعه، از استارت‌آپ‌ها گرفته تا شرکت‌های بزرگ، در 12 ماه گذشته با رویدادهای اقتصادی سختی روبرو بوده‌اند. اخراج در مقیاس بزرگ و تجدید ساختار شرکت، تیم‌ها را مجبور کرده است که در هنگام ساخت، مقیاس‌بندی و بهره‌برداری از سیستم‌های در مقیاس بزرگ «با کمتر کار بیشتری انجام دهند». با این حال هنوز باید پیشرفت کرد، و ارزش هنوز باید بالاتر از زنجیره نشان داده شود.
پس از سال‌ها استفاده از ابزارها و خدمات بی‌شماری برای حفظ سطوح بالای عملکرد و امنیت، با نظارت کمی بر طراحی یا هزینه‌ها، خماری DevOps واقعی است. یک شرکت معمولی همچنان از بیش از 100 ابزار SaaS استفاده می‌کند و بسیاری از شرکت‌ها هنوز در حال سرمایه‌گذاری بر روی ابزارها و فناوری‌های جدید هستند تا به آنها کمک کند طوفان اقتصادی فعلی را پشت سر بگذارند (گزارش باتری 2023).
تیم هایی که می توانند این زمان را برای ارزیابی و ساده سازی زرادخانه خود اختصاص دهند، تیم هایی هستند که در طرف مقابل ظاهر می شوند و هزینه ها را کاهش می دهند و کارایی را بهبود می بخشند و در عین حال مزیت رقابتی به دست می آورند.
بنابراین، بهترین دارو برای خماری DevOps ما چیست؟ ابتدا بیایید بفهمیم که چگونه به اینجا رسیدیم.
DevOps سپس: زمان مهمانی، عالی!
DevOps در طول زمان گسترش اقتصادی لجام گسیخته با منابع مالی و استفاده آسان، محصولات SaaS با استفاده از پرداخت برای پشتیبانی از آن پدیدار شد. مشکل از دو جهت بوده است:
- توسعه دهندگان به استفاده از راه حل هایی ادامه می دهند که کامل نیستند، تا زمانی که به اندازه کافی برای نیازهایشان مفید باشند. با این حال، زمانی که بودجه ها تنگ می شود (مانند امروز)، این ابزارها یا خدمات ممکن است باعث استرس مالی غیر ضروری شوند.
- و زحمت توسعه‌دهنده تا حد زیادی نادیده گرفته شد، زیرا ما فریاد می‌زدیم که «سریع حرکت کنیم و چیزها را بشکنیم!» اما امروز، طبق گزارش Developer Coefficient توسط Stripe، توسعه‌دهندگان بیش از 17 ساعت در هفته را صرف رسیدگی به مسائل تعمیر و نگهداری، مانند اشکال‌زدایی و بازسازی می‌کنند.
DevOps now: بیدار شدن با خماری
تصور کنید اکنون با یک درخواست از خواب بیدار می شوید بیشتر با کمتر انجام دهید، خواه این کاهش اندازه تیم باشد یا درخواست کاهش صورتحساب های ابر و ابزار. با از دست دادن اعضای تیم، ممکن است دانش سازمانی را که امکان اجرای برنامه های کاربردی کلیدی را فراهم می کند، از دست بدهید. این ضرر می تواند منجر به صدها هزار دلار در قطع، درآمد از دست رفته و جریمه های نظارتی شود. علی‌رغم این چالش‌ها، ممکن است همچنان از شما انتظار می‌رود که SLA پنج گانه را برای دستیابی به اهداف رشد تهاجمی حفظ کنید.
این فقط مهندسان و اپراتورها نیستند که با خماری DevOps بیدار می شوند. مدیران اجرایی، از جمله مدیران عامل، مدیران ارشد اجرایی، مدیران ارشد مالی، و رهبران مهندسی، همچنین نگاه دقیق‌تری به هزینه‌های عملیاتی در رابطه با فروش و رشد دارند. بسیاری در حال حاضر مشاورانی را استخدام می کنند تا به آنها کمک کنند هزینه های ابری خود را با بقیه هزینه های عملیاتی خود (مانند مشاهده پذیری و پلت فرم های داده) ترسیم کنند تا راه هایی برای کاهش هزینه های لازم بیابند.
خماری چه قیمتی برای ما دارد؟
این بستگی به شرایطی دارد که تیم توسعه شما تحت آن کار می کند. در اینجا چند محیط رایج وجود دارد:
- پایگاه های کد قدیمی پیچیده
- یک پلت فرم میکروسرویس که به طور تصاعدی در حال رشد است
- یک پروژه تبدیل دیجیتال ترکیبی و متوقف شده که هیولای یکپارچه و ریز خدمات فرانکشتاین است.
بیایید هر کدام را تجزیه کنیم.
هزینه یک پایگاه کد قدیمی
وقتی پایگاه کد یک شرکت تبدیل به یکپارچه می شود که هیچ کس به راحتی نمی تواند آن را درک کند، انتشار ویژگی های جدید بسیار بیشتر طول می کشد زیرا اضافه کردن ویژگی ها و ایجاد تغییرات زمانی که افکت های بالادستی و پایین دستی ناشناخته زیادی وجود دارد بسیار سخت تر است. این تاخیر می تواند هم برای تیم توسعه و هم برای کاربران نهایی که مشتاقانه منتظر اجرای ویژگی های جدید هستند ناامید کننده باشد.
هزینه یک پلت فرم میکروسرویس
در طرف دیگر طیف، برنامه های کاربردی بومی Kubernetes و Lambda در دوران رشد به قیمت تمام شده، زمانی که پول نقد با سرعت شگفت انگیز سوزانده می شد، افزایش یافت. هنگام اجرای چندین محصول در زیرساخت مشترک زیربنایی، نسبت دادن به هر محصول COGS (هزینه کالاهای فروخته شده) به طور قابل توجهی دشوارتر می شود. این تغییر به معماری میکروسرویس ها برای بهبود سرعتی که توسعه دهندگان می توانند برنامه های جدید را ارائه دهند، انجام شد. با این حال، با کاهش بودجه، تیم‌های Ops/DevOps/Platform که قبلاً محدود شده‌اند، اکنون مدیریت مداوم این پلتفرم‌ها را بر روی تیم‌های توسعه‌دهنده بیش از حد تحت فشار قرار می‌دهند.
هزینه یک پلت فرم ترکیبی یکپارچه + میکروسرویس
و در نهایت، در میانه این دو حالت افراطی، تیم‌هایی هستند که هم با یکپارچگی قدیمی، مجموعه‌ای از ریزسرویس‌ها و حفظ پنج SLA خود با هر تغییر کد گیر کرده‌اند. اکنون تیم‌ها با چالش‌های شکستن تغییرات کد، مشکلات مقیاس‌بندی، و تعداد و پیچیدگی روزافزون سرویس‌های وابسته مواجه هستند. و آنها تمام ابزارهای قابل مشاهده را برای درک بهتر نحوه عملکرد کد در زمان اجرا به کار می گیرند.
افزایش مقیاس خودکار آسان است، کاهش مقیاس خودکار آسان نیست
در حالی که درک چگونگی افزایش مقیاس زیرساخت با افزایش استفاده شما مهم است، تعیین چگونگی کاهش مقیاس زمانی که استفاده کاهش می یابد می تواند چالش برانگیز باشد. و بسیاری از تیم‌ها هرگز وقت خود را صرف برنامه‌ریزی برای سناریویی نکردند که در آن با کاهش استفاده، نیاز به کاهش زیرساخت‌ها داشته باشند.
اگر هزینه تحویل برنامه شما از فروش و درآمد شما جدا شود، ممکن است شرکت شما بیش از حد لازم پول خرج کند. این می تواند اتفاق بیفتد اگر صورت حساب های ابری و قابلیت مشاهده شما ثابت بماند، حتی با کاهش سرعت کسب و کار.
درمان خماری DevOps
هر شرکت نرم افزاری از تیم توسعه خود می خواهد که هزینه های زیرساختی را کاهش دهد. با این حال، همان مشکلات باقی می‌ماند: کد بد باعث ایجاد انسداد، قطعی و ناکارآمدی می‌شود که سالانه صدها هزار و گاهی میلیون‌ها هزینه برای کسب‌وکار دارد.
ابتدا بیایید به هزینه های عملیاتی بپردازیم.
به عنوان تنها فشارسنج ما برای هزینه های عملیاتی، فراتر از هزینه های ابری نگاه کنید. هزینه های ارائه یک ویژگی محصول می تواند در بسیاری از خدمات و در بین تیم ها وجود داشته باشد.
- با یک صفحه گسترده یا لیست شروع کنید و همه برنامه های کاربردی دیگری را که برای ارائه کل برنامه استفاده می کنید، حساب کنید.
- ارزش واقعی هر ویژگی یا محصول را برای کاربر و کسب‌وکار شناسایی کنید، نه فقط ادعای فروش و بازاریابی که انجام می‌دهند.
- مناطق همپوشانی بین برنامه ها و تیم ها را پیدا کنید. این یک فرصت عالی برای شناسایی و شکستن موانع فنی و سازمانی ایجاد شده است.
برخی از هزینه‌های ارائه برنامه شما در سرویس‌های SaaS شخص ثالث که از مدل‌های پرداخت به ازای استفاده یا اشتراک پیروی می‌کنند، اما به‌عنوان هزینه معمول ابری شما ثبت نمی‌شوند، پنهان می‌شوند. به‌ویژه، ابزارهای مشاهده‌پذیری و زیرساخت داده‌ها، هزینه‌های زیرساخت غیر ابری را هدایت می‌کنند.
- سرویس‌هایی مانند DataDog و NewRelic هزینه‌های بسیار بالایی در رابطه با معیارهای سفارشی دارند و هنگامی که یک معیار اضافه شود، بعید است که بعداً حذف شود. این هزینه های اساسی را به محصول یا تیمی که از آن پشتیبانی می کند، شناسایی و نسبت دهید.
- بررسی و درک کنید که کدام تیم مالک کدام منابع داده است. به جایی که داده ها در برنامه ها و سرویس های شما در حال حرکت هستند توجه داشته باشید. بسیاری از هزینه های بیش از حد ناشی از عدم درک توسعه دهندگان از اثرات هزینه انتقال داده بین خدمات است.
- محل کار این ابزارها در حال حاضر را مشخص کنید. در محیط‌های تولید گران‌قیمت که نگهداری از این ابزارها پرهزینه است و درمان مشکلات گران‌تر است؟ مهاجرت این ابزارها را زودتر در فرآیند توسعه در نظر بگیرید، جایی که رفع اشتباهات ارزان است و هزینه اجرای ابزارهای توسعه دهنده کمتر است.
اشکال زدایی در تولید ممکن است بهترین راه برای حل مشکل به نظر برسد، اما این پس از اینکه کاربران شما قبلاً تحت تأثیر قرار گرفته اند، یا پس از تغییر کد بحرانی هزینه های AWS شما را افزایش می دهد. برای موثر بودن خیلی دیر است.
در مرحله بعد، به اهمیت تحلیل کد و طراحی اپلیکیشن می پردازیم.
کیفیت کد و طراحی بر هزینه ها تأثیر می گذارد. توسعه دهندگان ارشد شما آن را می دانند، اما ممکن است برای CFO شما بسیار کمتر آشکار باشد. این را در نظر بگیرید:
- یک توسعه دهنده کد جدیدی را به برنامه شما اضافه می کند، مانند یک ویژگی جدید یا رفع اشکال.
- این تغییر کد، یک تماس مکرر با یک پایگاه داده ایجاد می کند و پرس و جوهای پایگاه داده را افزایش می دهد.
- افزایش پرس و جوها باعث از دست رفتن عملکرد برنامه و پایگاه داده می شود.
- یک SRE که توسط یک توسعه‌دهنده حذف شده است، نسبت به عملکرد ضعیف هشدار داده می‌شود و زیرساخت‌های زیربنایی را برای پشتیبانی از حجم کار افزایش می‌دهد.
- هزینه ارائه این برنامه اکنون دوبرابر شده است زیرا تیم SRE ابر را بر سر مشکل پرتاب کرده و پایگاه داده را به نمونه بزرگتری افزایش داده است.
بزرگتر کردن یک پایگاه داده سریع و آسان است، اما در واقع، ما به سادگی یک مشکل کیفیت کد را پنهان کردیم و هزینه کلی خود را بدون ارائه هیچ ارزش اضافی به کاربر افزایش دادیم. با گذشت زمان، کد مملو از مشکلات عملکردی می شود که در واقعیت، هرگز رفع نمی شوند. کیفیت کد و همچنین نتیجه شما آسیب می بیند.
به عنوان مثال، این نوع مشکل پرس و جو N+1 SQL فقط برای پایگاه‌های داده و برنامه‌های کاربردی با عملکرد آهسته مشکلی ایجاد نمی‌کند. سرویس‌های امروزی به صورت پرداختی هستند، که در آن هر درخواست API هزینه مشخصی دارد، و تماس ناخواسته همان API به طور مکرر، صورت‌حساب‌ها را بالا میبرد.
در نهایت، اجازه دهید اذعان کنیم که این به بهبود مستمر نیاز دارد.
به یاد داشته باشید، تمام خماری ها در نهایت برطرف می شوند. سناریوی ایده آل این است که شما و تیم تان می توانید شروع به بررسی و ارزیابی ابزارها و خدمات خود کنید و سپس شاهد بهبود عملکرد و هزینه های ارائه برنامه خود باشید. پس چه کاری می توانید انجام دهید تا مطمئن شوید که اوضاع به همین شکل باقی می ماند؟
به یاد داشته باشید که این یک فرآیند ثابت نیست. این چیزی است که ما را وارد این آشفتگی کرد. بررسی و ارزیابی ابزارها و خدمات خود را به عنوان یک مرحله سه ماهه تبدیل کنید. حتی بهتر از آن، این کار را در جریان کاری توسعه محصول خود بگنجانید. کمی مدیریت نرم‌افزاری با اصطکاک کم می‌تواند راه درازی را در جهت حاکم شدن در تغییرات بیهوده و پرهزینه کد انجام دهد، و گنجاندن آن در CI/CD شما به معنای حل مشکلات در مراحل اولیه است.
حتی اگر امروز نمی‌توانید سرمایه‌گذاری زیادی در بهینه‌سازی انجام دهید، درک اینکه چگونه نرم‌افزار شما در زمان تغییر تغییر می‌کند، برای جلوگیری از افزایش هزینه‌های عملیاتی بسیار مهم است. از ابزارهایی برای کمک به تجزیه و تحلیل نرم افزار خود در مرحله توسعه و آزمایش استفاده کنید تا مشکلات عملکرد را زود شناسایی کنید و آن ابزارها را در دست توسعه دهندگان قرار دهید تا بتوانند تأثیر عملیاتی تغییرات کدی که ایجاد می کنند را بهتر درک کنند.
