وقتی finops معماری بد ابری را پیدا کند چه اتفاقی می‌افتد؟

روش ها و ابزارهای Finops می توانند ناکارآمدی ها و فرصت های بهینه سازی را تشخیص دهند. در اینجا به شما می پردازیم که وقتی ضایعات را در استقرارهای ابری پیدا می کنید، چه کاری انجام دهید.

فیناپ‌های ابری، روشی که مدیریت مالی و عملیات ابری را ترکیب می‌کند، در بهینه‌سازی هزینه‌های ابری و اطمینان از استفاده کارآمد از منابع مؤثر است. این یکی از مهم ترین روندهای نوظهور در رایانش ابری است، و من به مقدار زیادی آن را در این وبلاگ پوشش داده ام.

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

تحلیل و بهینه سازی هزینه

تیم‌های Cloud finops به داده‌های دقیق هزینه ابر دسترسی دارند. این به آنها امکان می دهد الگوهای هزینه را تجزیه و تحلیل کنند و شیوه های ضعیف معماری ابر را شناسایی کنند که به بهینه سازی غیرضروری و هدر دادن پول کمک می کند.

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

سیستم‌های مشاهده‌پذیری Finops می‌توانند داده‌های هزینه را تجزیه و تحلیل کنند و منابع یا خدمات خاصی را مشخص کنند که باعث افزایش هزینه‌ها می‌شود. این معمولاً منجر به بهبودهای بالقوه معماری و صرفه جویی قابل توجه در هزینه می شود.

ارزیابی عملکرد و مقیاس پذیری

تیم‌های Cloud finops می‌توانند عملکرد و مقیاس‌پذیری زیرساخت ابری را ارزیابی کنند. نظارت بر شاخص‌های کلیدی عملکرد مانند زمان پاسخ، تأخیر و توان عملیاتی می‌تواند تنگناها یا مناطقی را شناسایی کند که معماری فعلی مقیاس‌پذیری و عملکرد را محدود می‌کند.

از آنجایی که finops معمولاً این موضوع را از طریق پول خرج شده ردیابی می‌کند، تشخیص اینکه اشتباهات معماری دقیقاً چقدر برای شرکت هزینه دارد آسان است. غیرعادی نیست که متوجه شوید یک سیستم ابری مستقر شده ۱۰ برابر بیشتر از آنچه که باید هزینه دارد. این اعداد و ارقام برای اکثر مشاغل نگران کننده هستند. به یاد داشته باشید، تمام آن پول می‌توانست در جاهای دیگر خرج شده باشد، مانند نوآوری‌ها.

برخی از سیستم‌های finops می‌توانند زیان خالص این اشتباهات معماری را محاسبه کنند. در بسیاری از موارد، حتی می توانید کاهش خالص ارزش کسب و کار را مشاهده کنید.

یک مثال: استفاده از تنها یک ارائه‌دهنده ابر عمومی بدون در نظر گرفتن سایرین که ممکن است راه‌حل‌های بهتری داشته باشند، مانند پایگاه داده‌ای که می‌تواند پنج برابر سریع‌تر عمل کند، عملکرد و صرفه‌جویی بهتری را برای حدود ۵۰ برنامه کاربردی که از آن استفاده می‌کنند، ارائه می‌کند. پایگاه داده بهتر می توانست یک سوم هزینه داشته باشد، عملکردی پنج برابر داشته باشد و ۱۵ میلیون دلار در سال در سود بهره وری صرفه جویی کند. بدتر میشود. این ۱۵ میلیون دلار می‌توانست برای توسعه یک خط تولید جدید استفاده شود که شرکت می‌توانست آن را به ۱۰۰ میلیون دلار درآمد تبدیل کند. این ممکن است یک مثال افراطی به نظر برسد، اما من چیزهایی مانند این را دیده‌ام که پس از تجزیه و تحلیل معماری ابر، فرصت‌های از دست رفته، ناکارآمدی‌ها، و غیره آشکار شد. این رایج‌تر از آن چیزی است که بسیاری تصور می‌کنند.

کنترل آسیب

بسیار خوب، اکنون سؤالی که اکثر متخصصان ابر نمی‌خواهند با آن مقابله کنند: چه می‌شود اگر معماری ابری شما ناکارآمدی‌های عمده داشته باشد؟

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

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

با این حال، اشتباهات استراتژیک بیشتری وجود دارد، مانند استفاده از یک ارائه دهنده ابر واحد (به مثال بالا مراجعه کنید). شاید در آن زمان ایده خوبی به نظر می رسید. شاید یک فروشنده با چندین عضو هیئت مدیره رابطه داشته است یا دلایل سیاسی برای انتخاب های محدود وجود داشته است. متأسفانه، شرکت همچنان با بدهی فنی زیادی روبرو می شود که می شد از آن جلوگیری کرد.

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