با مفهوم right-sizing و demand -drivenn آشنا شویم :
مفهوم right-sizingدر دواپس
در واقع Right-Sizing یعنی انتخاب و تنظیم دقیق ظرفیت منابع (زیرساخت، سرویسها، حتی تیمها) بر اساس نیاز واقعی و نه حدس یا پیشفرض.
این مفهوم بیشتر در Cloud و Kubernetes مهم است، چون منابع بهصورت پویا قابل افزایش یا کاهش هستند.
اصول اصلی Right-Sizing:
1. پایش مداوم مصرف منابع
• با ابزارهایی مثل Prometheus + Grafana یا CloudWatch مصرف CPU، RAM، I/O و ترافیک بررسی میشود.
2. تحلیل رفتار کاری (Workload Analysis)
• بررسی اینکه سرویس در چه بازههایی بار سنگین دارد و چه زمانی Idle است.
3. بهینهسازی بر اساس دادهها
• کاهش سایز VM یا Container وقتی که منابع اضافه بلااستفاده است.
• افزایش سایز وقتی که Bottleneck ایجاد میشود.
4. Cycle of Continuous Optimization
• این کار یکباره نیست؛ باید به صورت چرخهای انجام شود چون نیازها تغییر میکنند.
مثال در Kubernetes:
resources:
requests:
cpu: "250m"
memory: "256Mi"
limits:
cpu: "500m"
memory: "512Mi"
یعنی سرویس حداقل ۲۵۰m CPU و ۲۵۶Mi RAM رزرو میکند و حداکثر میتواند تا سقف ۵۰۰m CPU و ۵۱۲Mi RAM رشد کند.
۲. Demand-Driven Ops
Demand-Driven Ops یعنی عملیات و تأمین منابع براساس تقاضای واقعی کاربران یا سیستم، نه بر اساس ظرفیت ثابت یا پیشبینیهای غیرواقعی.
در این مدل، سیستم خود را بهصورت خودکار با تغییرات تقاضا وفق میدهد.
ویژگیها:
1. Elasticity
• مقیاسپذیری پویا (Scaling up/down یا in/out) در پاسخ به افزایش یا کاهش بار.
2. Event-Driven Scaling
• افزایش منابع بر اساس رویدادها مثل Spike ترافیک، Queue طولانی، یا افزایش Latency.
3. Integration با Business Metrics
• علاوه بر شاخصهای فنی، به شاخصهای کسبوکار هم توجه میشود (مثلاً تعداد سفارشها یا پرداختها در یک دقیقه).
4. Avoid Static Capacity Planning
• ظرفیت از قبل تعیین نمیشود؛ بلکه بر اساس داده لحظهای تنظیم میشود.
مثال:
• اگر نرخ درخواست به API به بالای ۱۰۰۰ Request/sec برسد → Auto-Scale تا ۵ Replica
• اگر صف پیام در Kafka بیشتر از ۵۰۰۰ پیام شود → افزایش تعداد Consumerها
بهترین رویکرد در DevOps ترکیب هر دو است:
• Right-Sizing → نقطه شروع بهینه برای منابع پایه
• Demand-Driven Ops → واکنش سریع به تغییرات غیرمنتظره
📌 یعنی:
• ابتدا منابع پایه را با Right-Sizing مشخص میکنیم
• سپس Auto-Scaling یا Event-Driven Scaling را برای پوشش تغییرات ناگهانی اضافه میکنیم
#fitops #devops
https://t.iss.one/unixmens
مفهوم right-sizingدر دواپس
در واقع Right-Sizing یعنی انتخاب و تنظیم دقیق ظرفیت منابع (زیرساخت، سرویسها، حتی تیمها) بر اساس نیاز واقعی و نه حدس یا پیشفرض.
این مفهوم بیشتر در Cloud و Kubernetes مهم است، چون منابع بهصورت پویا قابل افزایش یا کاهش هستند.
اصول اصلی Right-Sizing:
1. پایش مداوم مصرف منابع
• با ابزارهایی مثل Prometheus + Grafana یا CloudWatch مصرف CPU، RAM، I/O و ترافیک بررسی میشود.
2. تحلیل رفتار کاری (Workload Analysis)
• بررسی اینکه سرویس در چه بازههایی بار سنگین دارد و چه زمانی Idle است.
3. بهینهسازی بر اساس دادهها
• کاهش سایز VM یا Container وقتی که منابع اضافه بلااستفاده است.
• افزایش سایز وقتی که Bottleneck ایجاد میشود.
4. Cycle of Continuous Optimization
• این کار یکباره نیست؛ باید به صورت چرخهای انجام شود چون نیازها تغییر میکنند.
مثال در Kubernetes:
resources:
requests:
cpu: "250m"
memory: "256Mi"
limits:
cpu: "500m"
memory: "512Mi"
یعنی سرویس حداقل ۲۵۰m CPU و ۲۵۶Mi RAM رزرو میکند و حداکثر میتواند تا سقف ۵۰۰m CPU و ۵۱۲Mi RAM رشد کند.
۲. Demand-Driven Ops
Demand-Driven Ops یعنی عملیات و تأمین منابع براساس تقاضای واقعی کاربران یا سیستم، نه بر اساس ظرفیت ثابت یا پیشبینیهای غیرواقعی.
در این مدل، سیستم خود را بهصورت خودکار با تغییرات تقاضا وفق میدهد.
ویژگیها:
1. Elasticity
• مقیاسپذیری پویا (Scaling up/down یا in/out) در پاسخ به افزایش یا کاهش بار.
2. Event-Driven Scaling
• افزایش منابع بر اساس رویدادها مثل Spike ترافیک، Queue طولانی، یا افزایش Latency.
3. Integration با Business Metrics
• علاوه بر شاخصهای فنی، به شاخصهای کسبوکار هم توجه میشود (مثلاً تعداد سفارشها یا پرداختها در یک دقیقه).
4. Avoid Static Capacity Planning
• ظرفیت از قبل تعیین نمیشود؛ بلکه بر اساس داده لحظهای تنظیم میشود.
مثال:
• اگر نرخ درخواست به API به بالای ۱۰۰۰ Request/sec برسد → Auto-Scale تا ۵ Replica
• اگر صف پیام در Kafka بیشتر از ۵۰۰۰ پیام شود → افزایش تعداد Consumerها
بهترین رویکرد در DevOps ترکیب هر دو است:
• Right-Sizing → نقطه شروع بهینه برای منابع پایه
• Demand-Driven Ops → واکنش سریع به تغییرات غیرمنتظره
📌 یعنی:
• ابتدا منابع پایه را با Right-Sizing مشخص میکنیم
• سپس Auto-Scaling یا Event-Driven Scaling را برای پوشش تغییرات ناگهانی اضافه میکنیم
#fitops #devops
https://t.iss.one/unixmens
Telegram
Academy and Foundation unixmens | Your skills, Your future
@unixmens_support
@yashar_esm
[email protected]
یک کانال علمی تکنولوژی
فلسفه متن باز-گنو/لینوکس-امنیت - اقتصاد
دیجیتال
Technology-driven -بیزینس های مبتنی بر تکنولوژی
Enterprise open source
ارایه دهنده راهکارهای ارتقای سازمانی - فردی - تیمی
@yashar_esm
[email protected]
یک کانال علمی تکنولوژی
فلسفه متن باز-گنو/لینوکس-امنیت - اقتصاد
دیجیتال
Technology-driven -بیزینس های مبتنی بر تکنولوژی
Enterprise open source
ارایه دهنده راهکارهای ارتقای سازمانی - فردی - تیمی
با مفهوم fitops و معنا آن آشنا شویم :
این مفهوم بیشتر به فلسفه Right-Sizing و Demand-Driven Ops در DevOps مربوط میشود؛ یعنی زیرساخت، تیم و فرایندها نه بزرگتر از نیاز واقعی باشند و نه کوچکتر، بلکه بهصورت پویا و تطبیقی با نیاز فعلی و پیشبینی آینده هماهنگ شوند.
مفهوم FitOps در DevOps
میتوان گفت FitOps یک رویکرد عملیاتی است که تمرکزش روی تناسب بهینه منابع، فرایندها و ظرفیت تیم با نیاز واقعی کسبوکار و محصول است.
اصول اصلی:
1. Right-Sizing منابع
• استفاده از منابع (CPU، RAM، Storage، تعداد سرویسها و حتی تعداد اعضای تیم) متناسب با بار واقعی و قابل پیشبینی.
• مثال: Auto Scaling در Kubernetes یا Cloud.
2. Avoid Overengineering
• ساختن سیستمهای پیچیدهتر از آنچه نیاز است، ممنوع!
• DevOps باید راهکار را ساده و مقیاسپذیر طراحی کند، ولی فقط به اندازهای که اکنون و در آینده نزدیک لازم است.
3. Feedback Loop مداوم
• با مانیتورینگ و Observability، نیازها را بهطور مستمر ارزیابی و منابع را تنظیم کنیم.
4. Elastic Processes
• فرایندها باید انعطافپذیر باشند و با تغییر نیازهای محصول یا تیم، تغییر کنند (مثل CI/CD Pipelines که بتوانند سریعتر یا کندتر شوند).
5. Cost–Performance Balance
• شبیه FinOps، ولی با نگاه فنی: هدف رسیدن به بهترین کارایی با کمترین هزینه، نه صرفاً کمکردن هزینه.
ابزارها و تکنیکها
برای اجرای FitOps در DevOps، معمولاً اینها استفاده میشوند:
• Kubernetes Horizontal/Vertical Pod Autoscaler → برای تنظیم پویا منابع
• Terraform + Monitoring Integration → برای تغییر سریع زیرساخت طبق بار
• Prometheus / Grafana → برای رصد دقیق و تصمیمگیری
• Load Testing (مثل k6, JMeter) → برای تعیین ظرفیت بهینه
• Service Mesh Metrics (مثل Istio) → برای بررسی واقعی مصرف سرویسها
مزایا
• جلوگیری از هدررفت منابع و هزینهها
• افزایش انعطافپذیری تیم و زیرساخت
• پاسخ سریعتر به تغییرات نیاز بازار یا کاربران
#fitops #devops
https://t.iss.one/unixmens
این مفهوم بیشتر به فلسفه Right-Sizing و Demand-Driven Ops در DevOps مربوط میشود؛ یعنی زیرساخت، تیم و فرایندها نه بزرگتر از نیاز واقعی باشند و نه کوچکتر، بلکه بهصورت پویا و تطبیقی با نیاز فعلی و پیشبینی آینده هماهنگ شوند.
مفهوم FitOps در DevOps
میتوان گفت FitOps یک رویکرد عملیاتی است که تمرکزش روی تناسب بهینه منابع، فرایندها و ظرفیت تیم با نیاز واقعی کسبوکار و محصول است.
اصول اصلی:
1. Right-Sizing منابع
• استفاده از منابع (CPU، RAM، Storage، تعداد سرویسها و حتی تعداد اعضای تیم) متناسب با بار واقعی و قابل پیشبینی.
• مثال: Auto Scaling در Kubernetes یا Cloud.
2. Avoid Overengineering
• ساختن سیستمهای پیچیدهتر از آنچه نیاز است، ممنوع!
• DevOps باید راهکار را ساده و مقیاسپذیر طراحی کند، ولی فقط به اندازهای که اکنون و در آینده نزدیک لازم است.
3. Feedback Loop مداوم
• با مانیتورینگ و Observability، نیازها را بهطور مستمر ارزیابی و منابع را تنظیم کنیم.
4. Elastic Processes
• فرایندها باید انعطافپذیر باشند و با تغییر نیازهای محصول یا تیم، تغییر کنند (مثل CI/CD Pipelines که بتوانند سریعتر یا کندتر شوند).
5. Cost–Performance Balance
• شبیه FinOps، ولی با نگاه فنی: هدف رسیدن به بهترین کارایی با کمترین هزینه، نه صرفاً کمکردن هزینه.
ابزارها و تکنیکها
برای اجرای FitOps در DevOps، معمولاً اینها استفاده میشوند:
• Kubernetes Horizontal/Vertical Pod Autoscaler → برای تنظیم پویا منابع
• Terraform + Monitoring Integration → برای تغییر سریع زیرساخت طبق بار
• Prometheus / Grafana → برای رصد دقیق و تصمیمگیری
• Load Testing (مثل k6, JMeter) → برای تعیین ظرفیت بهینه
• Service Mesh Metrics (مثل Istio) → برای بررسی واقعی مصرف سرویسها
مزایا
• جلوگیری از هدررفت منابع و هزینهها
• افزایش انعطافپذیری تیم و زیرساخت
• پاسخ سریعتر به تغییرات نیاز بازار یا کاربران
#fitops #devops
https://t.iss.one/unixmens
Telegram
Academy and Foundation unixmens | Your skills, Your future
@unixmens_support
@yashar_esm
[email protected]
یک کانال علمی تکنولوژی
فلسفه متن باز-گنو/لینوکس-امنیت - اقتصاد
دیجیتال
Technology-driven -بیزینس های مبتنی بر تکنولوژی
Enterprise open source
ارایه دهنده راهکارهای ارتقای سازمانی - فردی - تیمی
@yashar_esm
[email protected]
یک کانال علمی تکنولوژی
فلسفه متن باز-گنو/لینوکس-امنیت - اقتصاد
دیجیتال
Technology-driven -بیزینس های مبتنی بر تکنولوژی
Enterprise open source
ارایه دهنده راهکارهای ارتقای سازمانی - فردی - تیمی
Enterprise AI has reached a turning point. For years, organizations have invested heavily in artificial intelligence, launching countless pilot projects and experimental models. Many AI projects show promise, but scaling these successes, integrating AI into core operations, and consistently extracting value across the enterprise remain significant challenges.This is why an open, collaboratively-developed, standard AI operating system (AI OS) is vital. Built on open source technology, this system will provide the essential production and run time environment for customizing and running AI model
via Red Hat Blog https://ift.tt/omVIHLG
via Red Hat Blog https://ift.tt/omVIHLG
Redhat
Developing a standard AI OS: Unlocking production-grade AI at enterprise scale
Discover the strategic necessity of a standard AI operating system (AI OS) for enterprise AI. Learn how Red Hat is building foundational components for scalable, production-grade AI, and how the AI OS will unlock unprecedented levels of efficiency, scalability…
We're seeing a significant trend: more organizations are bringing their large language model (LLM) infrastructure in-house. Whether for latency, compliance, or data privacy, self-hosting with open source models on your own hardware puts you in control of your AI journey. However, scaling LLMs from experimentation to a production-grade service introduces significant cost and complexity.A new open source framework, llm-d, backed by a powerhouse of contributors including Red Hat, IBM, and Google, is designed to address these challenges. It focuses on the core of the problem: AI inference—the pr
via Red Hat Blog https://ift.tt/svlukLS
via Red Hat Blog https://ift.tt/svlukLS
Redhat
What is llm-d and why do we need it?
We're seeing a significant trend: more organizations are bringing their large language model (LLM) infrastructure in-house.
Red Hat Recognized as a Leader for Second Consecutive Year in 2025 Gartner® Magic Quadrant™ for Container ManagementRed Hat OpenShift was recognized for the solution’s Completeness of Vision and in Ability to Execute in the Container Management Magic Quadrant. According to Gartner, Leaders execute well against their current vision and are well positioned for tomorrow. Learn more Computerworld - Why your entire workforce should become AI expertsAI isn’t just for data scientists anymore. In this episode of Today in Tech, Red Hat Distinguished Engineer Mo Duffy discusses how businesses c
via Red Hat Blog https://ift.tt/0gRTWqp
via Red Hat Blog https://ift.tt/0gRTWqp
Redhat
Friday Five — August 15, 2025 | Red Hat
The Friday Five is a weekly Red Hat blog post with 5 of the week's top news items and ideas from or about Red Hat and the technology industry.