Red Hat Enterprise Linux (RHEL) has a storied history, standing at the intersection of our customers, communities and partners, helping each achieve their goals while answering key end user needs, from enterprise-grade development practices and system security enhancements to a stronger software supply chain and end-to-end support backed by Red Hat’s unique expertise.. In 2021 we announced no-cost RHEL options for developers, in certain use cases, which include our proactive analytic capability, Red Hat Insights. Since then, we have listened to and learned from individuals and organizations

via Red Hat Blog https://ift.tt/qVMh6j1

محصول azure devops برای git repository از معماری استفاده میکنه . که بهینه نیست . azure devops ریپوزیتوری را روی دیتابیس ذخیره میکنه .
که به نظر من منطقی نیست .
در اینجا دلایل را بررسی میکنیم . نکته ای هم داشتید بگید .

1. کاهش کارایی و Latency بالا
عملیات Git (مثل clone, fetch, push) به شدت به I/O سریع نیاز دارد.
خواندن و نوشتن اشیای Git (blobs, trees, commits) در دیتابیس به جای سیستم فایل باعث افزایش overhead کوئری‌ها و تراکنش‌ها می‌شود.
دیتابیس‌های رابطه‌ای برای داده‌های باینری کوچک بهینه نیستند و باعث افزایش زمان پاسخ (latency) می‌شوند.
چندین لایه abstraction و parsing (مثلاً تبدیل داده‌ها به قالب دیتابیسی) باعث می‌شود عملکرد به نسبت سیستم فایل مستقیم پایین‌تر باشد.
2. وابستگی شدید به Availability و سلامت دیتابیس
دیتابیس به عنوان Single Point of Failure (نقطه شکست واحد) عمل می‌کند. اگر دیتابیس Down شود، دسترسی به تمام ریپوزیتوری‌ها قطع می‌شود.
حتی با وجود کلاسترینگ و Replica، Failover چند ثانیه یا بیشتر طول می‌کشد که در آن زمان کاربران نمی‌توانند به ریپوزیتوری‌ها دسترسی داشته باشند.
پیچیدگی مدیریت Transaction Logها و replication می‌تواند باعث کندی یا مشکلات synchronization شود.
3. محدودیت‌های مقیاس‌پذیری
دیتابیس‌های SQL رابطه‌ای معمولاً برای بارهای بسیار بزرگ و توزیع‌شده (مثلاً چند هزار کاربر همزمان) محدودیت دارند.
شاردینگ و توزیع داده‌های Git در دیتابیس پیچیده‌تر و سخت‌تر از سیستم فایل است.
در حجم‌های بسیار بالا، کوئری‌های پیچیده و تراکنش‌های زیاد باعث ایجاد bottleneck در دیتابیس می‌شوند.
4. پیچیدگی Backup و Restore
اگرچه گرفتن Backup یکپارچه برای کل سرویس ساده‌تر است، اما بازیابی فقط یک ریپوزیتوری یا Branch خاص در دیتابیس سخت‌تر است.
دیتابیس ممکن است به دلیل حجم داده‌های باینری و حجم بالا، عملیات Backup را سنگین و زمان‌بر کند.
بازیابی ناقص ممکن است باعث ایجاد inconsistency در ریپوزیتوری‌ها شود.
5. پیچیدگی Transaction Management
دیتابیس‌های رابطه‌ای برای مدیریت تراکنش‌های همزمان ساخته شده‌اند، اما عملیات Git مثل push یا merge شامل نوشتن‌های پراکنده و نامنظم است که مدیریت آنها در دیتابیس پیچیده است.
تراکنش‌های طولانی و همزمان ممکن است منجر به deadlock یا contention بالا در دیتابیس شوند.
6. عدم تطابق کامل با مدل توزیع‌شده Git
ا Git ذاتاً یک سیستم Distributed است که هر کلاینت نسخه کامل ریپوزیتوری را دارد و می‌تواند مستقل کار کند.
ذخیره‌سازی متمرکز در دیتابیس باعث می‌شود کارایی عملیات توزیع‌شده کاهش یابد و برخی مزایای Git مانند کار آفلاین کامل کمتر شود.
هر عملیات نیاز به ارتباط و اعتبارسنجی با دیتابیس مرکزی دارد.
7. افزایش بار روی شبکه و منابع سرور
درخواست‌های مکرر به دیتابیس برای خواندن و نوشتن داده‌های Git، باعث افزایش ترافیک شبکه بین سرورهای اپلیکیشن و دیتابیس می‌شود.
بار زیاد روی دیتابیس نیازمند منابع سخت‌افزاری بالاتر (CPU، RAM، Disk I/O) است که هزینه نگهداری را افزایش می‌دهد.

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

10. عدم تطابق با عملیات بهینه Git
ا Git با طراحی روی سیستم فایل و استفاده از ساختارهای باینری و فشرده (pack files) برای ذخیره اشیاء، بهینه‌سازی‌های خاصی انجام می‌دهد.
ذخیره داده‌ها در دیتابیس رابطه‌ای باعث می‌شود که این ساختارهای بهینه‌شده قابل استفاده نباشند و به صورت نرمالایز شده یا بلاک‌های کوچک‌تر ذخیره شوند که به کارایی ضربه می‌زند.

11. افزایش پیچیدگی مدیریت همزمانی (Concurrency Control)
در یک سیستم توزیع شده، هزاران کاربر ممکن است همزمان روی یک ریپوزیتوری کار کنند.
دیتابیس باید توانایی مدیریت تراکنش‌های همزمان پیچیده را داشته باشد که باعث افزایش پیچیدگی و احتمال بروز مشکلات همزمانی مانند lock contention می‌شود.
12. مشکلات مرتبط با عملیات Garbage Collection و Cleanup
اGit دارای مکانیزمی است به نام garbage collection برای پاکسازی داده‌های بلااستفاده (dangling commits, blobs) که روی سیستم فایل سریع و مستقیم انجام می‌شود.
پیاده‌سازی مشابه در دیتابیس به دلیل پیچیدگی‌های تراکنش و ایزوله‌سازی داده‌ها دشوارتر است و ممکن است باعث افزایش حجم دیتابیس و کاهش عملکرد شود.
13. چالش‌های مربوط به مقیاس‌گذاری افقی (Horizontal Scaling)
سیستم فایل به راحتی می‌تواند در محیط‌های توزیع شده با استفاده از ابزارهایی مانند NFS یا GlusterFS توزیع شود.
دیتابیس‌های رابطه‌ای معمولاً به سختی و با پیچیدگی زیاد مقیاس‌پذیر افقی می‌شوند که برای بارهای سنگین Git می‌تواند محدودیت ایجاد کند.

14. پیچیدگی در اشکال‌زدایی (Debugging) و نگهداری
در صورت بروز مشکل در داده‌های Git، تشخیص و رفع خطا در دیتابیس پیچیده‌تر از فایل‌های ساده Git است.
اشکال‌زدایی شامل بررسی تراکنش‌ها، لاگ‌های دیتابیس و تطابق داده‌ها در جداول مختلف است که نیازمند دانش تخصصی دیتابیس و Git به صورت همزمان است.
15. افزایش هزینه‌های زیرساختی
دیتابیس‌های قدرتمند با سخت‌افزار مناسب برای تحمل بارهای سنگین Git نیاز به سرمایه‌گذاری بیشتری دارند.
هزینه‌های نگهداری، لایسنس‌ها (اگر SQL Server باشد) و نیروی انسانی متخصص برای مدیریت دیتابیس زیاد است.
16. وابستگی به تکنولوژی‌های خاص
این روش باعث می‌شود سازمان به شدت وابسته به استک تکنولوژی خاصی (مانند SQL Server و ساختار Azure DevOps) شود و مهاجرت به پلتفرم یا مدل دیگر دشوار شود.
این Vendor Lock-in ممکن است در آینده محدودیت‌های استراتژیک ایجاد کند.



17. ریسک بروز Inconsistency داده‌ها
در محیط‌هایی که تراکنش‌های زیاد و همزمان انجام می‌شود، خطر بروز ناسازگاری بین جداول یا رکوردهای دیتابیس وجود دارد که منجر به corrupted repository می‌شود.
بازیابی این ناسازگاری‌ها معمولاً پیچیده و پرهزینه است.
18. مشکلات مربوط به به‌روزرسانی همزمان Branch ها
در Git معمولی، Branchها و commitها مستقل و توزیع‌شده هستند و تغییرات به صورت لوکال روی کلاینت انجام می‌شود.
در سیستم دیتابیس‌محور، به‌روزرسانی‌های همزمان روی Branchها ممکن است نیاز به قفل‌های دیتابیسی داشته باشد که باعث افزایش انتظار (wait times) و کاهش throughput می‌شود.

#azure #devops

Coming out of The Crash, we understood the problem more deeply—because we’d lived it.We had stretched a working bot to cover a new use case and data source—and watched it strain under the weight of unclear expectations, sprawling content, and retrieval blind spots. But those hard lessons gave us the clarity to regroup. We didn’t need to start over. We needed to design with intention and sharper focus.This phase is where we stop assuming, start scoping tightly, and make intentional choices that reflect the realities of our data, users, and goals.AI challenge: Construct a chatbot that ca

via Red Hat Blog https://ift.tt/OnlIiDF

این چه استدلالی هست که دارید انجام میدید . خود کلود فلر از waf های اپن سورس و کاستوم شده خودش استفاده میکند . در مورد پروژه modsecurity , مطالعه ای داشته باشید . که الان تحت مدیریت و سرویس دهی owasp هست .
Owasp
هم که معرف حضور هست .

بررسی کنید owasp core rule set را

برید OWASP Coraza WAF را بررسی کنید . که فورکی از modsecurity است .
خود وف f5 هم بیسش modsecurity هست

وف naxsi را هم بررسی کنید
https://coraza.io/

https://coreruleset.org/

#security #waf

unixmens

https://t.iss.one/unixmens

The World Economic Forum has identified upskilling as an important initiative for organizations over the next decade, predicting that at least 50% of the current workforce will lack the skills they need to keep pace with industry changes and demands. To remain competitive, organizations must embrace continuous, flexible learning models. Upskilling and cross-skilling initiatives are crucial for both talent retention and for equipping teams with the necessary expertise to navigate an AI-driven future. By fostering a culture of collective intelligence and supporting internal subject-matter expert

via Red Hat Blog https://ift.tt/GwcoLqH

با مفهوم 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

با مفهوم 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

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

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