۲۹ شهریور ۱۴۰۳

Techboy

اخبار و اطلاعات روز تکنولوژی

به finops در مورد تصمیمات معماری ابری نظر بدهید

برای نبرد در اتاق کنفرانس آماده شوید. یک برنامه ابر finops خوب باید معماری راه حل های ابری را برای کاهش هزینه و بهینه سازی ارزش ابر بررسی کند.

برای نبرد در اتاق کنفرانس آماده شوید. یک برنامه ابر finops خوب باید معماری راه حل های ابری را برای کاهش هزینه و بهینه سازی ارزش ابر بررسی کند.

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

زمان آن فرا رسیده است که بپذیریم که در ابتدای راه‌اندازی ابر، تیم‌های ما در مورد چگونگی رسیدگی به مشکلات خاص شرکت‌مان به بهترین شکل ماهر یا آگاه نبودند. شاید معماران ابری ما اکنون متوجه شده اند که با انتخاب و پیکربندی پشته فناوری می توانستند انتخاب های بهتری داشته باشند. دید آینده ۲۰/۲۰ است، درست است؟ با این حال، هنگامی که مورد سوال قرار می گیرد، تمایل طبیعی آنها به دفاع است. آنها معمولاً هر گونه انتقاد سازنده یا غیر سازنده را با نسخه ای از “این کار می کند، اینطور نیست؟” پس می زنند.

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

چگونه پایگاه داده NoSQL MongoDB به چمن پایگاه داده رابطه ای نفوذ می کند

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

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

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

مایکروسافت فابریک از دریاچه داده به پلتفرم کاربردی تکامل می یابد

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

نمونه‌هایی از توصیه‌های بالقوه finops:

  • از یک لایه امنیتی واحد که همه ابرها را در بر می گیرد به جای امنیت جداگانه برای هر مارک ابری استفاده کنید. این امر باعث صرفه جویی در هزینه های عملیاتی و همچنین کاهش تعداد مهارت های مورد نیاز کارکنان می شود.
  • پایگاه‌های اطلاعاتی را برای ساده‌سازی استقرار پایگاه داده در یک مدل پایگاه داده برای کاهش پیچیدگی و به حداقل رساندن مهارت‌های اضافی که ممکن است مورد نیاز باشد، ترکیب کنید.
  • سیستم‌های مدیریت عملکرد را ارائه دهید که تعادل بار بهتری را ارائه می‌دهند که می‌تواند تعداد سرویس‌های محاسباتی اختصاص‌یافته را کاهش دهد.
  • از AIops برای عملیات بین ابری استفاده کنید.
  • از اتوماسیون برای حذف تعداد انسان های مورد نیاز برای نظارت فعال بر سیستم های مبتنی بر ابر استفاده کنید.

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

چگونه Oracle با به‌روزرسانی‌های Autonomous Data Warehouse با AWS، Snowflake مقابله می‌کند

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

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