🔵 عنوان مقاله
Grafana Operator — Kubernetes Operator for Grafana
🟢 خلاصه مقاله:
Grafana Operator یک Operator در Kubernetes است که استقرار، پیکربندی و مدیریت Grafana را به‌صورت اعلامی و مقیاس‌پذیر انجام می‌دهد. با تعریف داشبوردها، Data Sourceها و سیاست‌های هشدار به‌صورت کُد و ذخیره آن‌ها در Git، تغییرات به‌صورت خودکار و قابل ردیابی اعمال می‌شوند و با الگوی GitOps هم‌راستا هستند. این ابزار وظایف چرخه عمر مانند نصب، ارتقا، بازیابی و اصلاح انحراف پیکربندی را خودکار می‌کند، از RBAC و Secrets برای کنترل دسترسی و مدیریت امن تنظیمات حساس استفاده می‌کند و با حلقه آشتی، پایداری و خودترمیمی را تضمین می‌کند. نتیجه، کاهش خطاهای دستی، سهولت ممیزی و یکپارچگی مدیریت Grafana در سناریوهای چندتیمی و چندکلاستری است.
#GrafanaOperator #Grafana #Kubernetes #K8s #Operators #DevOps #GitOps #Observability
🟣لینک مقاله:
https://ku.bz/j31586sqq
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Grafana Operator — Kubernetes Operator for Grafana
🟢 خلاصه مقاله:
Grafana Operator یک Operator در Kubernetes است که استقرار، پیکربندی و مدیریت Grafana را به‌صورت اعلامی و مقیاس‌پذیر انجام می‌دهد. با تعریف داشبوردها، Data Sourceها و سیاست‌های هشدار به‌صورت کُد و ذخیره آن‌ها در Git، تغییرات به‌صورت خودکار و قابل ردیابی اعمال می‌شوند و با الگوی GitOps هم‌راستا هستند. این ابزار وظایف چرخه عمر مانند نصب، ارتقا، بازیابی و اصلاح انحراف پیکربندی را خودکار می‌کند، از RBAC و Secrets برای کنترل دسترسی و مدیریت امن تنظیمات حساس استفاده می‌کند و با حلقه آشتی، پایداری و خودترمیمی را تضمین می‌کند. نتیجه، کاهش خطاهای دستی، سهولت ممیزی و یکپارچگی مدیریت Grafana در سناریوهای چندتیمی و چندکلاستری است.
#GrafanaOperator #Grafana #Kubernetes #K8s #Operators #DevOps #GitOps #Observability
🟣لینک مقاله:
https://ku.bz/j31586sqq
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - grafana/grafana-operator: An operator for Grafana that installs and manages Grafana instances, Dashboards and Datasources…
An operator for Grafana that installs and manages Grafana instances, Dashboards and Datasources through Kubernetes/OpenShift CRs - grafana/grafana-operator
Forwarded from Gopher Job
A Data Structure Algorithms Low Level Design and High Level Design collection of resources.
مجموعه‌ای از منابع برای طراحی low level و high level توی مصاحبه‌های الگوریتمی و برنامه‌نویسی
#DSA #LLD #HLD #Algorithm #Interview #Leetcode #Question
https://github.com/arpit20adlakha/Data-Structure-Algorithms-LLD-HLD
مجموعه‌ای از منابع برای طراحی low level و high level توی مصاحبه‌های الگوریتمی و برنامه‌نویسی
#DSA #LLD #HLD #Algorithm #Interview #Leetcode #Question
https://github.com/arpit20adlakha/Data-Structure-Algorithms-LLD-HLD
GitHub
GitHub - arpit20adlakha/Data-Structure-Algorithms-LLD-HLD: A Data Structure Algorithms Low Level Design and High Level Design collection…
A Data Structure Algorithms Low Level Design and High Level Design collection of resources. - arpit20adlakha/Data-Structure-Algorithms-LLD-HLD
👍1
یکی از جذاب ترین خبر برای باری کسانی که باگ بانتی کار میکنند یا علاقه دارند به این موضوع
مجموعه‌ای از ایجنت های هوش مصنوعی‌به اسم Strix که مثل یک هکر واقعی عمل می‌کنن! کد شما رو به‌صورت پویا اجرا می‌کنن، حفره‌های امنیتی رو پیدا می‌کنن، و حتی با نمونه‌ی واقعی (Proof-of-Concept) اون‌ها رو تأیید می‌کنه!
چرا مهمه؟
بزرگ‌ترین مشکل تست امنیتی سنتی اینه که با سرعت توسعه‌ی نرم‌افزار هماهنگ نیست.
اما Strix مستقیماً در جریان کاری شما ادغام می‌شه:
اجرای خودکار در CI/CD برای کشف آسیب‌پذیری‌ها قبل از انتشار!
دریافت PoC واقعی به‌جای هشدارهای اشتباه تحلیل‌های ایستا
تست کامل حملات تزریقی، کنترل دسترسی و باگ‌های منطقی
و بهترین بخش ماجرا:
نیازی نیست کارشناس امنیت باشید!
Strix با یک جعبه‌ابزار کامل هک میاد از HTTP Proxy و مرورگر خودکار گرفته تا محیط اجرای Python برای توسعه‌ی Exploit.
مثل اینه که یک تیم امنیتی حرفه‌ای در سرعت خط CI/CD شما کار کنه!( البته فکر کنم بزرگنمایی شده ولی خب قطعا ارزش تست داره )!
یک نکته ی مهم دیگه هم اینه که میتونید اونو بصورت داکر و لوکال ران کنید !
آموزش نصب و توضیحات اولیه به فارسی:
https://github.com/xPOURY4/strix/blob/main/README_FA.md
نسخه اصلی:
https://github.com/usestrix/strix
@ | <POURYA/>
مجموعه‌ای از ایجنت های هوش مصنوعی‌به اسم Strix که مثل یک هکر واقعی عمل می‌کنن! کد شما رو به‌صورت پویا اجرا می‌کنن، حفره‌های امنیتی رو پیدا می‌کنن، و حتی با نمونه‌ی واقعی (Proof-of-Concept) اون‌ها رو تأیید می‌کنه!
چرا مهمه؟
بزرگ‌ترین مشکل تست امنیتی سنتی اینه که با سرعت توسعه‌ی نرم‌افزار هماهنگ نیست.
اما Strix مستقیماً در جریان کاری شما ادغام می‌شه:
اجرای خودکار در CI/CD برای کشف آسیب‌پذیری‌ها قبل از انتشار!
دریافت PoC واقعی به‌جای هشدارهای اشتباه تحلیل‌های ایستا
تست کامل حملات تزریقی، کنترل دسترسی و باگ‌های منطقی
و بهترین بخش ماجرا:
نیازی نیست کارشناس امنیت باشید!
Strix با یک جعبه‌ابزار کامل هک میاد از HTTP Proxy و مرورگر خودکار گرفته تا محیط اجرای Python برای توسعه‌ی Exploit.
مثل اینه که یک تیم امنیتی حرفه‌ای در سرعت خط CI/CD شما کار کنه!( البته فکر کنم بزرگنمایی شده ولی خب قطعا ارزش تست داره )!
یک نکته ی مهم دیگه هم اینه که میتونید اونو بصورت داکر و لوکال ران کنید !
آموزش نصب و توضیحات اولیه به فارسی:
https://github.com/xPOURY4/strix/blob/main/README_FA.md
نسخه اصلی:
https://github.com/usestrix/strix
@ | <POURYA/>
GitHub
strix/README_FA.md at main · xPOURY4/strix
✨ Open-source AI hackers for your apps 👨🏻💻. Contribute to xPOURY4/strix development by creating an account on GitHub.
👍1
🔵 عنوان مقاله
Safeguarding OKE: Passwordless kubectl Access with OCI Instance Principals
🟢 خلاصه مقاله:
این آموزش نشان می‌دهد چگونه با تکیه بر OCI Instance Principals و بدون نیاز به رمز یا کلیدهای بلندمدت، دسترسی kubectl به یک کلاستر OKE را فعال کنیم. ایده اصلی این است که بارهای کاری روی Compute به‌عنوان پرینسیپل خودِ ماشین احراز هویت شوند و با استفاده از توکن‌های کوتاه‌عمر به API کلاستر دسترسی بگیرند. برای این کار، ابتدا ماشین‌ها را در یک dynamic group قرار می‌دهیم، سپس با IAM policies محدود و دقیق، فقط کمینه مجوزهای لازم برای کلاستر (مثلاً use روی cluster) را در سطح یک compartment یا حتی یک کلاستر خاص می‌دهیم. روی همان ماشین، OCI CLI کنار kubectl نصب می‌شود و kubeconfig طوری پیکربندی می‌گردد که از OCI CLI exec plugin استفاده کند؛ در نتیجه هر بار kubectl اجرا می‌شود، توکن موقتی را از OCI با مکانیزم Instance Principals می‌گیرد و نیازی به ذخیره رمز/کلید نیست. در نهایت با تنظیم RBAC داخل کلاستر، دسترسی‌ها دقیقاً به نقش‌هایی که تعریف کرده‌ایم محدود می‌شود. این الگو امنیت را افزایش می‌دهد، از افشای اعتبارنامه‌ها جلوگیری می‌کند، گردش توکن‌ها را خودکار می‌سازد و برای سناریوهای CI/CD و زیرساخت‌های موقتی در OCI بسیار مناسب است.
#Kubernetes #OKE #OracleCloud #OCI #IAM #kubectl #DevOps #CloudSecurity
🟣لینک مقاله:
https://ku.bz/ZpCQLpM4V
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Safeguarding OKE: Passwordless kubectl Access with OCI Instance Principals
🟢 خلاصه مقاله:
این آموزش نشان می‌دهد چگونه با تکیه بر OCI Instance Principals و بدون نیاز به رمز یا کلیدهای بلندمدت، دسترسی kubectl به یک کلاستر OKE را فعال کنیم. ایده اصلی این است که بارهای کاری روی Compute به‌عنوان پرینسیپل خودِ ماشین احراز هویت شوند و با استفاده از توکن‌های کوتاه‌عمر به API کلاستر دسترسی بگیرند. برای این کار، ابتدا ماشین‌ها را در یک dynamic group قرار می‌دهیم، سپس با IAM policies محدود و دقیق، فقط کمینه مجوزهای لازم برای کلاستر (مثلاً use روی cluster) را در سطح یک compartment یا حتی یک کلاستر خاص می‌دهیم. روی همان ماشین، OCI CLI کنار kubectl نصب می‌شود و kubeconfig طوری پیکربندی می‌گردد که از OCI CLI exec plugin استفاده کند؛ در نتیجه هر بار kubectl اجرا می‌شود، توکن موقتی را از OCI با مکانیزم Instance Principals می‌گیرد و نیازی به ذخیره رمز/کلید نیست. در نهایت با تنظیم RBAC داخل کلاستر، دسترسی‌ها دقیقاً به نقش‌هایی که تعریف کرده‌ایم محدود می‌شود. این الگو امنیت را افزایش می‌دهد، از افشای اعتبارنامه‌ها جلوگیری می‌کند، گردش توکن‌ها را خودکار می‌سازد و برای سناریوهای CI/CD و زیرساخت‌های موقتی در OCI بسیار مناسب است.
#Kubernetes #OKE #OracleCloud #OCI #IAM #kubectl #DevOps #CloudSecurity
🟣لینک مقاله:
https://ku.bz/ZpCQLpM4V
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
Safeguarding OKE: Passwordless kubectl Access with OCI Instance Principals
Using OCI Instance Principals to enable passwordless kubectl access to OKE significantly improves CI/CD pipeline security
🔵 عنوان مقاله
K8z: the Kubernetes manager
🟢 خلاصه مقاله:
ک8z به‌عنوان یک مدیر یکپارچه برای Kubernetes معرفی می‌شود که چرخه عمر کلاسترها را در محیط‌های چندابر و on‑prem ساده می‌کند، در عین حال برای تیم‌های پلتفرم «گاردریل» فراهم می‌سازد و تجربه توسعه‌دهنده را روان‌تر می‌کند. هسته اصلی آن بر جریان‌های declarative و ادغام با GitOps تکیه دارد، با پشتیبانی از Helm و الگوهای کاربردی، ارتقا/بازگشت، و انتشار تدریجی مانند canary و blue/green. در حوزه امنیت و انطباق، کنترل متمرکز دسترسی با RBAC و SSO (مانند OIDC)، اعمال سیاست با OPA Gatekeeper یا Kyverno، و مدیریت امن اسرار از طریق Vault یا سرویس‌های KMS برجسته است؛ همچنین ثبت وقایع و دید هزینه‌ها فراهم می‌شود. برای قابلیت اتکا و مشاهده‌پذیری، اتصال آماده به Prometheus و Grafana، بررسی سلامت، مقیاس‌پذیری خودکار و پشتیبان‌گیری/بازیابی (شامل etcd و حجم‌های ماندگار) پوشش داده شده است. K8z پلتفرمی توسعه‌پذیر با API، CLI و افزونه‌ها ارائه می‌کند و با ابزارهایی مانند Terraform یکپارچه می‌شود تا بدون قفل‌شدن در تامین‌کننده، نیازهای تیم‌های Platform Engineering، SRE و اپلیکیشن را از تامین تا عملیات روز دوم پاسخ دهد.
#Kubernetes #DevOps #PlatformEngineering #GitOps #CloudNative #SRE #Containers #Observability
🟣لینک مقاله:
https://k8z.dev
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
K8z: the Kubernetes manager
🟢 خلاصه مقاله:
ک8z به‌عنوان یک مدیر یکپارچه برای Kubernetes معرفی می‌شود که چرخه عمر کلاسترها را در محیط‌های چندابر و on‑prem ساده می‌کند، در عین حال برای تیم‌های پلتفرم «گاردریل» فراهم می‌سازد و تجربه توسعه‌دهنده را روان‌تر می‌کند. هسته اصلی آن بر جریان‌های declarative و ادغام با GitOps تکیه دارد، با پشتیبانی از Helm و الگوهای کاربردی، ارتقا/بازگشت، و انتشار تدریجی مانند canary و blue/green. در حوزه امنیت و انطباق، کنترل متمرکز دسترسی با RBAC و SSO (مانند OIDC)، اعمال سیاست با OPA Gatekeeper یا Kyverno، و مدیریت امن اسرار از طریق Vault یا سرویس‌های KMS برجسته است؛ همچنین ثبت وقایع و دید هزینه‌ها فراهم می‌شود. برای قابلیت اتکا و مشاهده‌پذیری، اتصال آماده به Prometheus و Grafana، بررسی سلامت، مقیاس‌پذیری خودکار و پشتیبان‌گیری/بازیابی (شامل etcd و حجم‌های ماندگار) پوشش داده شده است. K8z پلتفرمی توسعه‌پذیر با API، CLI و افزونه‌ها ارائه می‌کند و با ابزارهایی مانند Terraform یکپارچه می‌شود تا بدون قفل‌شدن در تامین‌کننده، نیازهای تیم‌های Platform Engineering، SRE و اپلیکیشن را از تامین تا عملیات روز دوم پاسخ دهد.
#Kubernetes #DevOps #PlatformEngineering #GitOps #CloudNative #SRE #Containers #Observability
🟣لینک مقاله:
https://k8z.dev
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
k8z.dev
K8Z | The Kubernetes Manager
The Kubernetes Manager for iOS and MacOS.
🔵 عنوان مقاله
Cluster Template: Talos + Flux: Kubernetes deployment
🟢 خلاصه مقاله:
این مقاله یک Cluster Template برای استقرار Kubernetes معرفی می‌کند که با ترکیب Talos و Flux روند راه‌اندازی و به‌روزرسانی را ساده و تکرارپذیر می‌کند. Talos به‌عنوان سیستم‌عامل مینیمال و ایمنِ ویژه‌ی Kubernetes به‌کار می‌رود و پیکربندی‌ها به‌صورت کد نگهداری می‌شوند. Flux با رویکرد GitOps مخزن Git را رصد کرده و وضعیت کلاستر را به‌صورت خودکار با مانیفست‌های اعلامی همگام می‌کند. جریان کاری شامل راه‌اندازی نودها با Talos، اتصال Flux به مخزن، و اعمال خودکار تغییرات با هر Commit است؛ بازگشت به عقب نیز صرفاً با Revert یک Commit انجام می‌شود. نتیجه، استقرار یکنواخت، کاهش Drift، و مدیریت ساده‌تر روز دوم در مقیاس‌های مختلف است.
#Kubernetes #Talos #FluxCD #GitOps #ClusterTemplate #DevOps #CloudNative
🟣لینک مقاله:
https://ku.bz/8VP9H3B5B
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Cluster Template: Talos + Flux: Kubernetes deployment
🟢 خلاصه مقاله:
این مقاله یک Cluster Template برای استقرار Kubernetes معرفی می‌کند که با ترکیب Talos و Flux روند راه‌اندازی و به‌روزرسانی را ساده و تکرارپذیر می‌کند. Talos به‌عنوان سیستم‌عامل مینیمال و ایمنِ ویژه‌ی Kubernetes به‌کار می‌رود و پیکربندی‌ها به‌صورت کد نگهداری می‌شوند. Flux با رویکرد GitOps مخزن Git را رصد کرده و وضعیت کلاستر را به‌صورت خودکار با مانیفست‌های اعلامی همگام می‌کند. جریان کاری شامل راه‌اندازی نودها با Talos، اتصال Flux به مخزن، و اعمال خودکار تغییرات با هر Commit است؛ بازگشت به عقب نیز صرفاً با Revert یک Commit انجام می‌شود. نتیجه، استقرار یکنواخت، کاهش Drift، و مدیریت ساده‌تر روز دوم در مقیاس‌های مختلف است.
#Kubernetes #Talos #FluxCD #GitOps #ClusterTemplate #DevOps #CloudNative
🟣لینک مقاله:
https://ku.bz/8VP9H3B5B
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - onedr0p/cluster-template: A template for deploying a Talos Kubernetes cluster including Flux for GitOps
A template for deploying a Talos Kubernetes cluster including Flux for GitOps - onedr0p/cluster-template
🔵 عنوان مقاله
Terraform & Ansible: Unifying infrastructure provisioning and configuration management (3 minute read)
🟢 خلاصه مقاله:
این یکپارچگی جدید با معرفی Terraform actions، همکاری Terraform و Ansible را عمیق‌تر می‌کند و یک مسیر یکپارچه از تامین زیرساخت تا پیکربندی و عملیات Day 2+ فراهم می‌کند. Terraform می‌تواند مستقیماً گردش‌های کاری Ansible را پس از ایجاد زیرساخت اجرا کند و با اشتراک موجودی یکسان (inventory) و خروجی‌های Terraform، از ناسازگاری و اسکریپت‌های سفارشی جلوگیری کند. نتیجه، خودکارسازی روان‌تر و کاهش اصطکاک عملیاتی به‌ویژه در محیط‌های هیبرید و چندابری است؛ ضمن اینکه کارهای مداوم مانند نصب وصله‌ها، اعمال انطباق، استقرار برنامه و رفع drift نیز به‌صورت منظم و قابل تکرار انجام می‌شوند.
#Terraform #Ansible #InfrastructureAsCode #DevOps #Automation #MultiCloud #ConfigurationManagement #Day2Operations
🟣لینک مقاله:
https://www.hashicorp.com/en/blog/terraform-ansible-unifying-infrastructure-provisioning-configuration-management?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Terraform & Ansible: Unifying infrastructure provisioning and configuration management (3 minute read)
🟢 خلاصه مقاله:
این یکپارچگی جدید با معرفی Terraform actions، همکاری Terraform و Ansible را عمیق‌تر می‌کند و یک مسیر یکپارچه از تامین زیرساخت تا پیکربندی و عملیات Day 2+ فراهم می‌کند. Terraform می‌تواند مستقیماً گردش‌های کاری Ansible را پس از ایجاد زیرساخت اجرا کند و با اشتراک موجودی یکسان (inventory) و خروجی‌های Terraform، از ناسازگاری و اسکریپت‌های سفارشی جلوگیری کند. نتیجه، خودکارسازی روان‌تر و کاهش اصطکاک عملیاتی به‌ویژه در محیط‌های هیبرید و چندابری است؛ ضمن اینکه کارهای مداوم مانند نصب وصله‌ها، اعمال انطباق، استقرار برنامه و رفع drift نیز به‌صورت منظم و قابل تکرار انجام می‌شوند.
#Terraform #Ansible #InfrastructureAsCode #DevOps #Automation #MultiCloud #ConfigurationManagement #Day2Operations
🟣لینک مقاله:
https://www.hashicorp.com/en/blog/terraform-ansible-unifying-infrastructure-provisioning-configuration-management?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
🔵 عنوان مقاله
Why keep your index set lean (8 minute read)
🟢 خلاصه مقاله:
** ایندکس‌های اضافی در Postgres هزینه پنهان اما جدی دارند: نوشتن‌ها را کند میکنند چون هر INSERT/UPDATE باید همه آن‌ها را به‌روزرسانی کند، زمان برنامه‌ریزی را بالا می‌برند و به‌خاطر رقابت برای cache می‌توانند خواندن‌ها را هم کند کنند. علاوه بر اتلاف فضای دیسک، کار autovacuum بیشتر می‌شود و WAL بیشتری تولید می‌شود که هزینه‌های نگهداری و پشتیبان‌گیری را بالا می‌برد. راهکار این است که ایندکس‌های بلااستفاده یا تکراری حذف و ایندکس‌های متورم بازسازی شوند، و با پایش منظم، مجموعه‌ای کم‌حجم و کارآمد از ایندکس‌ها حفظ شود.
#Postgres #Indexing #DatabasePerformance #WAL #Autovacuum #SQL #DBA #DevOps
🟣لینک مقاله:
https://postgres.ai/blog/20251110-postgres-marathon-2-013-why-keep-your-index-set-lean?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Why keep your index set lean (8 minute read)
🟢 خلاصه مقاله:
** ایندکس‌های اضافی در Postgres هزینه پنهان اما جدی دارند: نوشتن‌ها را کند میکنند چون هر INSERT/UPDATE باید همه آن‌ها را به‌روزرسانی کند، زمان برنامه‌ریزی را بالا می‌برند و به‌خاطر رقابت برای cache می‌توانند خواندن‌ها را هم کند کنند. علاوه بر اتلاف فضای دیسک، کار autovacuum بیشتر می‌شود و WAL بیشتری تولید می‌شود که هزینه‌های نگهداری و پشتیبان‌گیری را بالا می‌برد. راهکار این است که ایندکس‌های بلااستفاده یا تکراری حذف و ایندکس‌های متورم بازسازی شوند، و با پایش منظم، مجموعه‌ای کم‌حجم و کارآمد از ایندکس‌ها حفظ شود.
#Postgres #Indexing #DatabasePerformance #WAL #Autovacuum #SQL #DBA #DevOps
🟣لینک مقاله:
https://postgres.ai/blog/20251110-postgres-marathon-2-013-why-keep-your-index-set-lean?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
PostgresAI
#PostgresMarathon 2-013: Why keep your index set lean | PostgresAI
Your API is slowing down. You check your database and find 42 indexes on your users table. Which ones can you safely drop? How much performance are they costing you? Let's look at what actually happens in Postgres when you have too many indexes.
Forwarded from Linux Labdon
کاهش هزینه سیستم‌های هوش مصنوعی با Semantic Caching
با رشد مدل‌های زبانی بزرگ و پیشرفته، هزینه و زمان پاسخ‌دهی هم به شدت افزایش پیدا کرده. مدل‌هایی مثل GPT-5 یا Claude برای کارهای پیچیده فوق‌العاده‌اند، ولی استفاده از اون‌ها هم پرهزینه و هم کند محسوب می‌شه. از طرف دیگه، AI Agentها واقعاً «توکن‌خور» هستن؛ یعنی برای انجام یک کار معمولاً چندین مرحله طی می‌کنن: تحقیق، برنامه‌ریزی، عمل و بازتاب و تکرار. همین باعث می‌شه چندین بار با مدل تماس بگیرن و در نتیجه هزینه و تأخیر افزایش پیدا کنه و متن‌های طولانی‌تر تولید بشه. برای مثال، یه بنچمارک اخیر از TheAgentCompany در ۲۰۲۵ نشون داده اجرای کامل یک Agent گاهی تا ۶.۸ دلار هزینه داره.
یکی از مشکلات اصلی در دنیای واقعی، تکراری بودن سوال‌هاست، مخصوصاً توی پشتیبانی مشتری. کاربران دائماً سوال‌های مشابهی می‌پرسن: مثل «چطور پولم رو پس بگیرم؟» یا «شرایط بازگشت وجه چیه؟» و Agent مجبور می‌شه هر بار پاسخ رو از صفر تولید کنه. نتیجه‌ش افزایش هزینه، طولانی شدن زمان پاسخ و فشار بیشتر روی سیستم‌های RAG و زیرساخت‌هاست.
در نگاه اول، ممکنه فکر کنیم کش کلاسیک کفایت می‌کنه. ایده‌ی کش ساده اینه که اگر یک سوال قبلاً پاسخ داده شده، دوباره سراغ مدل نریم. ولی مشکل اینجاست که کش سنتی دنبال Exact Match یا تطابق دقیق متنه. سوال‌هایی که از نظر معنی یکی هستن ولی عبارت‌هاشون فرق می‌کنه، مثل: «می‌خوام پولم رو پس بگیرم»، «چطور می‌تونم درخواست بازگشت وجه بدم؟» و «سیاست بازگشت پولتون چیه؟»، همه Cache Miss می‌شن و کش عملاً استفاده نمی‌شه.
اینجاست که Semantic Caching وارد می‌شه. به جای تطابق کلمه‌به‌کلمه، کش به معنی و مفهوم جمله نگاه می‌کنه. مزیت اصلی‌ش اینه که Recall و Hit Rate بالاتره و احتمال استفاده از کش و صرفه‌جویی خیلی بیشتر می‌شه. البته چالشش هم اینه که گاهی ممکنه جواب بی‌ربط بده یا همون «False Positive» رخ بده.
روش کار Semantic Caching ساده است ولی هوشمندانه: ابتدا سوال کاربر به Embedding یا بردار عددی تبدیل می‌شه. بعد با بردارهای موجود در کش با Semantic Search مقایسه می‌شه. اگر فاصله معنایی کم باشه، پاسخ از کش برگردونده می‌شه؛ در غیر این صورت به RAG یا LLM می‌ریم. در نهایت سوال و پاسخ جدید هم ذخیره می‌شه تا دفعه بعدی قابل استفاده باشه.
پیاده‌سازی Semantic Caching با چالش‌هایی همراهه؛ مثل دقت (Accuracy) که آیا کش جواب درست میده، کارایی (Performance) و میزان Cache Hit، سرعت سرویس‌دهی، آپدیت‌پذیری کش و اینکه آیا می‌تونیم کش رو گرم، تازه‌سازی یا پاکسازی کنیم. همچنین مشاهده‌پذیری (Observability) مهمه تا بتونیم hit rate، latency، صرفه‌جویی هزینه و کیفیت کش رو بسنجیم.
معیارهای اصلی سنجش کش شامل Cache Hit Rate هست که نشون میده چند درصد درخواست‌ها از کش پاسخ داده می‌شن و Precision/Recall/F1 Score که کیفیت و دقت پاسخ‌ها رو مشخص می‌کنه. برای بهبود دقت و کارایی کش هم می‌تونیم Threshold فاصله رو تنظیم کنیم، Reranker اضافه کنیم مثل Cross-encoder یا LLM-as-a-judge، از Fuzzy Matching برای تایپوها استفاده کنیم و فیلترهای اضافی مثل تشخیص پرسش‌های زمان‌محور (Temporal) یا تشخیص کد (Python، Java و…) اعمال کنیم تا سوالات اشتباه وارد کش نشن.
یه مثال واقعی از این تکنولوژی پروژه waLLMartCache در Walmart هست. اون‌ها با نوآوری‌هایی مثل Load Balancer برای توزیع کش روی چند Node و Dual-tiered Storage که L1 = Vector DB و L2 = In-memory Cache مثل Redis هست، هم سرعت و هم دقت رو بالا بردن. Multi-tenancy هم باعث شده چند تیم یا اپلیکیشن از یک زیرساخت مشترک استفاده کنن. Decision Engine هم شامل تشخیص کد و زمانه و اگر سوال مناسب کش نباشه مستقیماً به LLM یا RAG می‌ره. نتیجه‌ش رسیدن به دقت نزدیک ۹۰٪ بوده.
<Reza Jafari/>
👉 https://t.iss.one/addlist/AJ7rh2IzIh02NTI0
با رشد مدل‌های زبانی بزرگ و پیشرفته، هزینه و زمان پاسخ‌دهی هم به شدت افزایش پیدا کرده. مدل‌هایی مثل GPT-5 یا Claude برای کارهای پیچیده فوق‌العاده‌اند، ولی استفاده از اون‌ها هم پرهزینه و هم کند محسوب می‌شه. از طرف دیگه، AI Agentها واقعاً «توکن‌خور» هستن؛ یعنی برای انجام یک کار معمولاً چندین مرحله طی می‌کنن: تحقیق، برنامه‌ریزی، عمل و بازتاب و تکرار. همین باعث می‌شه چندین بار با مدل تماس بگیرن و در نتیجه هزینه و تأخیر افزایش پیدا کنه و متن‌های طولانی‌تر تولید بشه. برای مثال، یه بنچمارک اخیر از TheAgentCompany در ۲۰۲۵ نشون داده اجرای کامل یک Agent گاهی تا ۶.۸ دلار هزینه داره.
یکی از مشکلات اصلی در دنیای واقعی، تکراری بودن سوال‌هاست، مخصوصاً توی پشتیبانی مشتری. کاربران دائماً سوال‌های مشابهی می‌پرسن: مثل «چطور پولم رو پس بگیرم؟» یا «شرایط بازگشت وجه چیه؟» و Agent مجبور می‌شه هر بار پاسخ رو از صفر تولید کنه. نتیجه‌ش افزایش هزینه، طولانی شدن زمان پاسخ و فشار بیشتر روی سیستم‌های RAG و زیرساخت‌هاست.
در نگاه اول، ممکنه فکر کنیم کش کلاسیک کفایت می‌کنه. ایده‌ی کش ساده اینه که اگر یک سوال قبلاً پاسخ داده شده، دوباره سراغ مدل نریم. ولی مشکل اینجاست که کش سنتی دنبال Exact Match یا تطابق دقیق متنه. سوال‌هایی که از نظر معنی یکی هستن ولی عبارت‌هاشون فرق می‌کنه، مثل: «می‌خوام پولم رو پس بگیرم»، «چطور می‌تونم درخواست بازگشت وجه بدم؟» و «سیاست بازگشت پولتون چیه؟»، همه Cache Miss می‌شن و کش عملاً استفاده نمی‌شه.
اینجاست که Semantic Caching وارد می‌شه. به جای تطابق کلمه‌به‌کلمه، کش به معنی و مفهوم جمله نگاه می‌کنه. مزیت اصلی‌ش اینه که Recall و Hit Rate بالاتره و احتمال استفاده از کش و صرفه‌جویی خیلی بیشتر می‌شه. البته چالشش هم اینه که گاهی ممکنه جواب بی‌ربط بده یا همون «False Positive» رخ بده.
روش کار Semantic Caching ساده است ولی هوشمندانه: ابتدا سوال کاربر به Embedding یا بردار عددی تبدیل می‌شه. بعد با بردارهای موجود در کش با Semantic Search مقایسه می‌شه. اگر فاصله معنایی کم باشه، پاسخ از کش برگردونده می‌شه؛ در غیر این صورت به RAG یا LLM می‌ریم. در نهایت سوال و پاسخ جدید هم ذخیره می‌شه تا دفعه بعدی قابل استفاده باشه.
پیاده‌سازی Semantic Caching با چالش‌هایی همراهه؛ مثل دقت (Accuracy) که آیا کش جواب درست میده، کارایی (Performance) و میزان Cache Hit، سرعت سرویس‌دهی، آپدیت‌پذیری کش و اینکه آیا می‌تونیم کش رو گرم، تازه‌سازی یا پاکسازی کنیم. همچنین مشاهده‌پذیری (Observability) مهمه تا بتونیم hit rate، latency، صرفه‌جویی هزینه و کیفیت کش رو بسنجیم.
معیارهای اصلی سنجش کش شامل Cache Hit Rate هست که نشون میده چند درصد درخواست‌ها از کش پاسخ داده می‌شن و Precision/Recall/F1 Score که کیفیت و دقت پاسخ‌ها رو مشخص می‌کنه. برای بهبود دقت و کارایی کش هم می‌تونیم Threshold فاصله رو تنظیم کنیم، Reranker اضافه کنیم مثل Cross-encoder یا LLM-as-a-judge، از Fuzzy Matching برای تایپوها استفاده کنیم و فیلترهای اضافی مثل تشخیص پرسش‌های زمان‌محور (Temporal) یا تشخیص کد (Python، Java و…) اعمال کنیم تا سوالات اشتباه وارد کش نشن.
یه مثال واقعی از این تکنولوژی پروژه waLLMartCache در Walmart هست. اون‌ها با نوآوری‌هایی مثل Load Balancer برای توزیع کش روی چند Node و Dual-tiered Storage که L1 = Vector DB و L2 = In-memory Cache مثل Redis هست، هم سرعت و هم دقت رو بالا بردن. Multi-tenancy هم باعث شده چند تیم یا اپلیکیشن از یک زیرساخت مشترک استفاده کنن. Decision Engine هم شامل تشخیص کد و زمانه و اگر سوال مناسب کش نباشه مستقیماً به LLM یا RAG می‌ره. نتیجه‌ش رسیدن به دقت نزدیک ۹۰٪ بوده.
<Reza Jafari/>
👉 https://t.iss.one/addlist/AJ7rh2IzIh02NTI0
❤2
🔵 عنوان مقاله
Kubernetes Headaches: Unsticking StatefulSets from EBS ReadWriteMany Drama
🟢 خلاصه مقاله:
با اجرای سرویس‌های دارای حالت روی Kubernetes، خیلی زود محدودیت اصلی نمایان می‌شود: EBS در AWS برای ReadWriteMany طراحی نشده و همین باعث گیرکردن StatefulSetها، Pending شدن پادها و مشکل در اتصال ولوم‌ها بین نودها می‌شود. راه‌حل‌ها سه مسیر اصلی دارند: یا ماهیت ReadWriteOnce را بپذیرید و هر replica را در همان AZ و کنار EBS خودش نگه دارید (با تنظیمات topology و ReadWriteOncePod)، یا به یک RWX واقعی مهاجرت کنید (EFS با EFS CSI و Access Pointها، یا سیستم‌های توزیع‌شده مانند Rook Ceph/Longhorn/OpenEBS)، یا معماری برنامه را طوری بازطراحی کنید که نیاز به RWX از بین برود (sharding، استفاده از S3 برای blobها، و stream کردن WAL/backup).
برای مهاجرت امن: از VolumeSnapshot یا Jobهای کپی داده (rsync) بین PVCهای قدیم (EBS) و جدید (EFS/RWX) استفاده کنید، StatefulSet را به‌صورت ترتیبی scale down کنید، persistentVolumeClaimRetentionPolicy را برای حفظ PVCها تنظیم کنید، StorageClass را در volumeClaimTemplates عوض کنید و سپس به‌تدریج scale up کنید. رعایت PDB، readiness، fsGroup، و IRSA برای درایورهای CSI حیاتی است و باید قبل از سوییچ نهایی، کارایی و برگشت‌پذیری را با fio و پشتیبان‌گیری (Velero/اسنپ‌شات‌ها) تست کرد. به‌طور خلاصه: یا با EBS و تک‌نویسنده کنار بیایید، یا به EFS/ذخیره‌سازی توزیع‌شده بروید؛ تلاش برای RWX با EBS معمولاً فقط مشکل را عقب می‌اندازد.
#Kubernetes #StatefulSet #EBS #EFS #RWX #CSI #AWS #CloudStorage
🟣لینک مقاله:
https://ku.bz/Zg29dRHx4
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Kubernetes Headaches: Unsticking StatefulSets from EBS ReadWriteMany Drama
🟢 خلاصه مقاله:
با اجرای سرویس‌های دارای حالت روی Kubernetes، خیلی زود محدودیت اصلی نمایان می‌شود: EBS در AWS برای ReadWriteMany طراحی نشده و همین باعث گیرکردن StatefulSetها، Pending شدن پادها و مشکل در اتصال ولوم‌ها بین نودها می‌شود. راه‌حل‌ها سه مسیر اصلی دارند: یا ماهیت ReadWriteOnce را بپذیرید و هر replica را در همان AZ و کنار EBS خودش نگه دارید (با تنظیمات topology و ReadWriteOncePod)، یا به یک RWX واقعی مهاجرت کنید (EFS با EFS CSI و Access Pointها، یا سیستم‌های توزیع‌شده مانند Rook Ceph/Longhorn/OpenEBS)، یا معماری برنامه را طوری بازطراحی کنید که نیاز به RWX از بین برود (sharding، استفاده از S3 برای blobها، و stream کردن WAL/backup).
برای مهاجرت امن: از VolumeSnapshot یا Jobهای کپی داده (rsync) بین PVCهای قدیم (EBS) و جدید (EFS/RWX) استفاده کنید، StatefulSet را به‌صورت ترتیبی scale down کنید، persistentVolumeClaimRetentionPolicy را برای حفظ PVCها تنظیم کنید، StorageClass را در volumeClaimTemplates عوض کنید و سپس به‌تدریج scale up کنید. رعایت PDB، readiness، fsGroup، و IRSA برای درایورهای CSI حیاتی است و باید قبل از سوییچ نهایی، کارایی و برگشت‌پذیری را با fio و پشتیبان‌گیری (Velero/اسنپ‌شات‌ها) تست کرد. به‌طور خلاصه: یا با EBS و تک‌نویسنده کنار بیایید، یا به EFS/ذخیره‌سازی توزیع‌شده بروید؛ تلاش برای RWX با EBS معمولاً فقط مشکل را عقب می‌اندازد.
#Kubernetes #StatefulSet #EBS #EFS #RWX #CSI #AWS #CloudStorage
🟣لینک مقاله:
https://ku.bz/Zg29dRHx4
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
Kubernetes Headaches: Unsticking StatefulSets from EBS ReadWriteMany Drama
Note: This post assumes some familiarity with AWS EKS, Kubernetes StatefulSets, and EBS volumes.
🔵 عنوان مقاله
topolvm: capacity-aware CSI
🟢 خلاصه مقاله:
TopoLVM یک درایور CSI برای Kubernetes است که با استفاده از LVM روی Linux، دیسک‌های محلی هر نود را به PersistentVolumeهای پویا و قابل اطمینان تبدیل می‌کند. ویژگی اصلی آن «آگاه از ظرفیت» بودن است؛ یعنی ظرفیت آزاد واقعی هر نود را می‌شناسد و آن را به Scheduler اعلام می‌کند تا Podهایی که PVC دارند فقط روی نودهایی زمان‌بندی شوند که واقعا توان تامین آن حجم را دارند. این رویکرد از حلقه‌های شکست در زمان‌بندی و خطاهای دیرهنگام Provisioning جلوگیری می‌کند.
TopoLVM معمولا شامل یک Controller، یک Node Plugin و مولفه سبک lvmd روی هر نود است. StorageClassها می‌توانند به Volume Groupها یا Device Classهای متفاوت نگاشت شوند تا لایه‌های کارایی مختلف ارائه شود. پشتیبانی از حجم‌های فایل‌سیستمی و Block، توسعه حجم (در صورت پشتیبانی Kubernetes)، و تنظیمات Thin/Thick provisioning در LVM فراهم است. در کلاسترهایی که Storage Capacity Tracking را پشتیبانی میکنند، اطلاعات ظرفیت از طریق اشیای StorageCapacity در دسترس Scheduler قرار می‌گیرد.
این راه‌حل برای سناریوهای ذخیره‌سازی محلی با کارایی بالا و نیاز به Locality مناسب است؛ مانند محیط‌های Bare Metal و Edge. از آن‌جا که Volumeها محلی‌اند، تاب‌آوری معمولا از طریق تکرار در سطح اپلیکیشن تامین می‌شود. در مقایسه با درایورهای ذخیره‌سازی شبکه‌ای، TopoLVM بر ظرفیت قابل پیش‌بینی روی نود، Provisioning سریع و کنترل مستقیم عملیاتی با LVM تمرکز دارد.
#Kubernetes #CSI #TopoLVM #LVM #Storage #PersistentVolume #CapacityAware #DevOps
🟣لینک مقاله:
https://ku.bz/nW4zYDCHT
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
topolvm: capacity-aware CSI
🟢 خلاصه مقاله:
TopoLVM یک درایور CSI برای Kubernetes است که با استفاده از LVM روی Linux، دیسک‌های محلی هر نود را به PersistentVolumeهای پویا و قابل اطمینان تبدیل می‌کند. ویژگی اصلی آن «آگاه از ظرفیت» بودن است؛ یعنی ظرفیت آزاد واقعی هر نود را می‌شناسد و آن را به Scheduler اعلام می‌کند تا Podهایی که PVC دارند فقط روی نودهایی زمان‌بندی شوند که واقعا توان تامین آن حجم را دارند. این رویکرد از حلقه‌های شکست در زمان‌بندی و خطاهای دیرهنگام Provisioning جلوگیری می‌کند.
TopoLVM معمولا شامل یک Controller، یک Node Plugin و مولفه سبک lvmd روی هر نود است. StorageClassها می‌توانند به Volume Groupها یا Device Classهای متفاوت نگاشت شوند تا لایه‌های کارایی مختلف ارائه شود. پشتیبانی از حجم‌های فایل‌سیستمی و Block، توسعه حجم (در صورت پشتیبانی Kubernetes)، و تنظیمات Thin/Thick provisioning در LVM فراهم است. در کلاسترهایی که Storage Capacity Tracking را پشتیبانی میکنند، اطلاعات ظرفیت از طریق اشیای StorageCapacity در دسترس Scheduler قرار می‌گیرد.
این راه‌حل برای سناریوهای ذخیره‌سازی محلی با کارایی بالا و نیاز به Locality مناسب است؛ مانند محیط‌های Bare Metal و Edge. از آن‌جا که Volumeها محلی‌اند، تاب‌آوری معمولا از طریق تکرار در سطح اپلیکیشن تامین می‌شود. در مقایسه با درایورهای ذخیره‌سازی شبکه‌ای، TopoLVM بر ظرفیت قابل پیش‌بینی روی نود، Provisioning سریع و کنترل مستقیم عملیاتی با LVM تمرکز دارد.
#Kubernetes #CSI #TopoLVM #LVM #Storage #PersistentVolume #CapacityAware #DevOps
🟣لینک مقاله:
https://ku.bz/nW4zYDCHT
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - topolvm/topolvm: Capacity-aware CSI plugin for Kubernetes
Capacity-aware CSI plugin for Kubernetes. Contribute to topolvm/topolvm development by creating an account on GitHub.
🔵 عنوان مقاله
Most Cloud-Native Roles are Software Engineers
🟢 خلاصه مقاله:
این مقاله بازار کار cloud-native در سال ۲۰۲۵ را بررسی می‌کند و نشان می‌دهد که حدود ۴۷٪ از موقعیت‌های مرتبط با Kubernetes به عنوان Software Engineer آگهی می‌شوند؛ در حالی‌که نقش‌های DevOps، Platform، DevSecOps و SRE سهم کمتری دارند. این روند بیانگر استخدامِ مهندس‌محور و حرکت به‌سمت shift-left است: از توسعه‌دهندگان انتظار می‌رود علاوه بر توسعه، با Kubernetes و بخشی از زیرساخت، امنیت و تحویل نیز درگیر باشند. برای متقاضیان، تسلط بر Kubernetes همراه با مهارت‌های CI/CD، IaC، observability و اصول امنیت ضروری‌تر شده است و در عین حال همکاری نزدیک با تیم‌های DevOps/Platform/SRE همچنان اهمیت دارد.
#CloudNative #Kubernetes #SoftwareEngineering #DevOps #SRE #DevSecOps #PlatformEngineering #TechJobs2025
🟣لینک مقاله:
https://ku.bz/q44QpvhQ6
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Most Cloud-Native Roles are Software Engineers
🟢 خلاصه مقاله:
این مقاله بازار کار cloud-native در سال ۲۰۲۵ را بررسی می‌کند و نشان می‌دهد که حدود ۴۷٪ از موقعیت‌های مرتبط با Kubernetes به عنوان Software Engineer آگهی می‌شوند؛ در حالی‌که نقش‌های DevOps، Platform، DevSecOps و SRE سهم کمتری دارند. این روند بیانگر استخدامِ مهندس‌محور و حرکت به‌سمت shift-left است: از توسعه‌دهندگان انتظار می‌رود علاوه بر توسعه، با Kubernetes و بخشی از زیرساخت، امنیت و تحویل نیز درگیر باشند. برای متقاضیان، تسلط بر Kubernetes همراه با مهارت‌های CI/CD، IaC، observability و اصول امنیت ضروری‌تر شده است و در عین حال همکاری نزدیک با تیم‌های DevOps/Platform/SRE همچنان اهمیت دارد.
#CloudNative #Kubernetes #SoftwareEngineering #DevOps #SRE #DevSecOps #PlatformEngineering #TechJobs2025
🟣لینک مقاله:
https://ku.bz/q44QpvhQ6
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Cloud Native Now
Most Cloud-Native Roles are Software Engineers
Cloud-native hiring: 47% of roles are Software Engineers, while SRE positions have dropped ~30% since 2023. Lead-level jobs outnumber junior ones. Skills are the differentiator.cloudnativenow.com/you-are-more-likely-to-land-a-lead-level-cloud-native-role…
❤1
🔵 عنوان مقاله
Inside Duolingo's FinOps Journey: Turning Cloud Spend into Engineering Insight (3 minute read)
🟢 خلاصه مقاله:
خلاصه‌ای از مسیر FinOps در Duolingo نشان می‌دهد که این شرکت با وارد کردن آگاهی مالی به جریان کاری مهندسی، هزینه‌های ابری را به بینشی عملی برای توسعه‌دهندگان تبدیل کرده است. با نمایش بلادرنگِ اثر مالی تغییرات در کنار متریک‌های عملیاتی، استفاده از تگ‌گذاری و مالکیت منابع، هشدارهای خودکار و گاردریل‌های بودجه، و حتی مقایسه «cost diff» در CI/CD، تیم‌ها می‌توانند پیش از استقرار، پیامدهای هزینه‌ای انتخاب‌های معماری و کد را بسنجند. این رویکرد فرهنگ سازمان را به سمتی برده که «کارایی» هم‌سطح «عملکرد» و «پایداری» به‌عنوان یک معیار اصلی کیفیت دیده می‌شود و تصمیم‌گیری‌ها—از برنامه‌ریزی ظرفیت تا آزمایش و بازطراحی—با زبانی مشترک میان مهندسی و مالی انجام می‌گیرد. نتیجه، کاهش اتلاف، پیش‌بینی‌پذیری بهتر و سیستم‌هایی سریع، پایدار و آگاه از هزینه است.
#FinOps #CloudCost #Duolingo #CostOptimization #DevOps #EngineeringExcellence #CloudOps #SoftwareQuality
🟣لینک مقاله:
https://www.infoq.com/news/2025/10/duolingo-finops-engineering/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Inside Duolingo's FinOps Journey: Turning Cloud Spend into Engineering Insight (3 minute read)
🟢 خلاصه مقاله:
خلاصه‌ای از مسیر FinOps در Duolingo نشان می‌دهد که این شرکت با وارد کردن آگاهی مالی به جریان کاری مهندسی، هزینه‌های ابری را به بینشی عملی برای توسعه‌دهندگان تبدیل کرده است. با نمایش بلادرنگِ اثر مالی تغییرات در کنار متریک‌های عملیاتی، استفاده از تگ‌گذاری و مالکیت منابع، هشدارهای خودکار و گاردریل‌های بودجه، و حتی مقایسه «cost diff» در CI/CD، تیم‌ها می‌توانند پیش از استقرار، پیامدهای هزینه‌ای انتخاب‌های معماری و کد را بسنجند. این رویکرد فرهنگ سازمان را به سمتی برده که «کارایی» هم‌سطح «عملکرد» و «پایداری» به‌عنوان یک معیار اصلی کیفیت دیده می‌شود و تصمیم‌گیری‌ها—از برنامه‌ریزی ظرفیت تا آزمایش و بازطراحی—با زبانی مشترک میان مهندسی و مالی انجام می‌گیرد. نتیجه، کاهش اتلاف، پیش‌بینی‌پذیری بهتر و سیستم‌هایی سریع، پایدار و آگاه از هزینه است.
#FinOps #CloudCost #Duolingo #CostOptimization #DevOps #EngineeringExcellence #CloudOps #SoftwareQuality
🟣لینک مقاله:
https://www.infoq.com/news/2025/10/duolingo-finops-engineering/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
InfoQ
Inside Duolingo’s FinOps Journey: Turning Cloud Spend into Engineering Insight
Duolingo's FinOps journey integrates financial awareness into engineering, empowering developers to link costs with performance. By leveraging real-time data, teams prioritize innovations for maximum impact. This collaborative culture shift transformed cost…
🔵 عنوان مقاله
SR-IOV Network Device Plugin
🟢 خلاصه مقاله:
این افزونه با بهره‌گیری از SR-IOV امکان تخصیص مستقیم VFهای یک NIC فیزیکی به Podها را در Kubernetes فراهم می‌کند تا به کارایی نزدیک به سخت‌افزار، تأخیر پایین و سربار CPU کم برسند. افزونه به‌صورت DaemonSet روی نودها اجرا می‌شود، دستگاه‌های SR-IOV را کشف کرده و از طریق Device Plugin API به‌عنوان منابع قابل‌درخواست در اختیار kubelet می‌گذارد؛ با درخواست Pod یک VF به‌طور انحصاری تخصیص می‌یابد و جداسازی و پیش‌بینی‌پذیری کارایی تضمین می‌شود. پیکربندی شبکه با SR-IOV CNI و معمولاً Multus انجام می‌شود و بسته به نیاز، VF می‌تواند به درایورهایی مانند vfio-pci برای DPDK یا درایورهای کرنلی متصل شود؛ همچنین در صورت پشتیبانی سخت‌افزار، RDMA قابل استفاده است. استقرار نیازمند فعال‌سازی SR-IOV و IOMMU، NIC سازگار، ایجاد VFها و Linux است و در بسیاری از سناریوها SR-IOV Network Operator مدیریت خودکار و سیاست‌گذاری را ساده می‌کند. این راهکار برای CNFها، NFV، تحلیل بلادرنگ و محیط‌های با حساسیت بالا به تأخیر کاربردی است و به‌صورت استاندارد با اکوسیستم CNI در Kubernetes ادغام می‌شود.
#SRIOV #Kubernetes #CNI #Multus #DPDK #NFV #Networking #CloudNative
🟣لینک مقاله:
https://ku.bz/jVg_1VS-k
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
SR-IOV Network Device Plugin
🟢 خلاصه مقاله:
این افزونه با بهره‌گیری از SR-IOV امکان تخصیص مستقیم VFهای یک NIC فیزیکی به Podها را در Kubernetes فراهم می‌کند تا به کارایی نزدیک به سخت‌افزار، تأخیر پایین و سربار CPU کم برسند. افزونه به‌صورت DaemonSet روی نودها اجرا می‌شود، دستگاه‌های SR-IOV را کشف کرده و از طریق Device Plugin API به‌عنوان منابع قابل‌درخواست در اختیار kubelet می‌گذارد؛ با درخواست Pod یک VF به‌طور انحصاری تخصیص می‌یابد و جداسازی و پیش‌بینی‌پذیری کارایی تضمین می‌شود. پیکربندی شبکه با SR-IOV CNI و معمولاً Multus انجام می‌شود و بسته به نیاز، VF می‌تواند به درایورهایی مانند vfio-pci برای DPDK یا درایورهای کرنلی متصل شود؛ همچنین در صورت پشتیبانی سخت‌افزار، RDMA قابل استفاده است. استقرار نیازمند فعال‌سازی SR-IOV و IOMMU، NIC سازگار، ایجاد VFها و Linux است و در بسیاری از سناریوها SR-IOV Network Operator مدیریت خودکار و سیاست‌گذاری را ساده می‌کند. این راهکار برای CNFها، NFV، تحلیل بلادرنگ و محیط‌های با حساسیت بالا به تأخیر کاربردی است و به‌صورت استاندارد با اکوسیستم CNI در Kubernetes ادغام می‌شود.
#SRIOV #Kubernetes #CNI #Multus #DPDK #NFV #Networking #CloudNative
🟣لینک مقاله:
https://ku.bz/jVg_1VS-k
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - k8snetworkplumbingwg/sriov-network-device-plugin: SRIOV network device plugin for Kubernetes
SRIOV network device plugin for Kubernetes. Contribute to k8snetworkplumbingwg/sriov-network-device-plugin development by creating an account on GitHub.
❤1
چجوری بفهمیم ایمیج‌های Docker کی نسخه جدید میدن
خیلی وقتا سرویس‌های داکری روی نسخه‌های قدیمی ایمیج می‌مونن و کسی هم به این زودی متوجه نمی‌شه!
برای همین ابزاری هست به اسم DIUN که کارش فقط یه چیزه:
بفهمه ایمیجی که داری استفاده می‌کنی، نسخه جدید داده یا نه.
حالا DIUN چطوری اینو تشخیص میده؟
خیلی ساده:
به docker.sock وصل می‌شه، می‌فهمه چه کانتینرهایی داری و از چه ایمیج‌هایی استفاده می‌کنی. بعد Digest همونا رو با Digest رجیستری مقایسه می‌کنه :)))
اگر فرق داشت، یعنی نسخهٔ جدید منتشر شده.
برای استفاده هم فقط کافیه یه کانتینر DIUN کنار سرویس‌هات بیاری بالا.
حالا DIUN میتونه خروجی رو به هرجایی که API میده بفرسته:
تلگرام، Slack و...
جزئیاتش اینجاست:
https://hashbang.nl/blog/receive-notifications-when-updates-to-docker-images-are-released-using-diun
البته تو محیط‌های بزرگ تر معمولاً از ابزارهایی مثل Renovate یا watchtower استفاده می‌کنن،
ولی DIUN یه گزینه راحت و کار راه اندازه برای اینکه سریع بفهمی ایمیج جدید اومده یا نه!
@ | <Amir Haji Mohammad Sadegh/>
خیلی وقتا سرویس‌های داکری روی نسخه‌های قدیمی ایمیج می‌مونن و کسی هم به این زودی متوجه نمی‌شه!
برای همین ابزاری هست به اسم DIUN که کارش فقط یه چیزه:
بفهمه ایمیجی که داری استفاده می‌کنی، نسخه جدید داده یا نه.
حالا DIUN چطوری اینو تشخیص میده؟
خیلی ساده:
به docker.sock وصل می‌شه، می‌فهمه چه کانتینرهایی داری و از چه ایمیج‌هایی استفاده می‌کنی. بعد Digest همونا رو با Digest رجیستری مقایسه می‌کنه :)))
اگر فرق داشت، یعنی نسخهٔ جدید منتشر شده.
برای استفاده هم فقط کافیه یه کانتینر DIUN کنار سرویس‌هات بیاری بالا.
حالا DIUN میتونه خروجی رو به هرجایی که API میده بفرسته:
تلگرام، Slack و...
جزئیاتش اینجاست:
https://hashbang.nl/blog/receive-notifications-when-updates-to-docker-images-are-released-using-diun
البته تو محیط‌های بزرگ تر معمولاً از ابزارهایی مثل Renovate یا watchtower استفاده می‌کنن،
ولی DIUN یه گزینه راحت و کار راه اندازه برای اینکه سریع بفهمی ایمیج جدید اومده یا نه!
@ | <Amir Haji Mohammad Sadegh/>
Hashbang
Receive notifications when updates to docker images are released using DIUN
👍2
🔵 عنوان مقاله
Using LLMs to filter out false positives from static code analysis (5 minute read)
🟢 خلاصه مقاله:
**Datadog قابلیت فیلتر هوشمند «مثبت کاذب» را به ابزار Static Code Analysis اضافه کرده است. این ویژگی با تکیه بر Bits AI و LLMها، یافته‌های امنیتی را به «احتمالاً واقعی» یا «احتمالاً مثبت کاذب» دسته‌بندی می‌کند تا نویز کاهش یابد، تریاژ سریع‌تر شود و تیم‌های توسعه و امنیت بتوانند روی آسیب‌پذیری‌های واقعاً مهم تمرکز کنند و رفع آن‌ها را سریع‌تر پیش ببرند.
#StaticCodeAnalysis #Datadog #BitsAI #LLM #DevSecOps #ApplicationSecurity #CodeScanning #FalsePositives
🟣لینک مقاله:
https://www.datadoghq.com/blog/using-llms-to-filter-out-false-positives/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Using LLMs to filter out false positives from static code analysis (5 minute read)
🟢 خلاصه مقاله:
**Datadog قابلیت فیلتر هوشمند «مثبت کاذب» را به ابزار Static Code Analysis اضافه کرده است. این ویژگی با تکیه بر Bits AI و LLMها، یافته‌های امنیتی را به «احتمالاً واقعی» یا «احتمالاً مثبت کاذب» دسته‌بندی می‌کند تا نویز کاهش یابد، تریاژ سریع‌تر شود و تیم‌های توسعه و امنیت بتوانند روی آسیب‌پذیری‌های واقعاً مهم تمرکز کنند و رفع آن‌ها را سریع‌تر پیش ببرند.
#StaticCodeAnalysis #Datadog #BitsAI #LLM #DevSecOps #ApplicationSecurity #CodeScanning #FalsePositives
🟣لینک مقاله:
https://www.datadoghq.com/blog/using-llms-to-filter-out-false-positives/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Datadog
Using LLMs to filter out false positives from static code analysis | Datadog
Datadog’s false positive filtering for SAST uses Bits AI to reduce noise, improve accuracy, and help teams focus on real security vulnerabilities.
❤2
🔵 عنوان مقاله
How We Rebuilt Our Vault Architecture with Raft, Snapshots, and DR
🟢 خلاصه مقاله:
ما معماری Vault را با تکیه بر سه رکن Raft، Snapshots و DR بازطراحی کردیم تا پیچیدگی عملیاتی را کاهش دهیم، وابستگی‌های بیرونی را حذف کنیم و تاب‌آوری را افزایش دهیم. با مهاجرت به ذخیره‌سازی یکپارچه مبتنی بر Raft، کلاستر ساده‌تر و قابل‌اعتمادتر شد و مسیر مهاجرت با محیط staging، تمرین‌های بازیابی، معیارهای rollback و پایش لحظه‌ای کنترل شد. Snapshots به‌طور خودکار زمان‌بندی و رمزنگاری شدند، در فضای ذخیره‌سازی ایمن نگهداری و با تمرین‌های دوره‌ای بازیابی راستی‌آزمایی شدند تا RPO شفاف و بازیابی قابل پیش‌بینی باشد. برای DR یک کلاستر ثانویه در دامنه خرابی جدا راه‌اندازی و با تکرار DR، برنامه failover با RTO مشخص و مانیتورینگ تأخیر تکرار، سلامت Raft و تازگی Snapshotها پیاده‌سازی شد. با امنیت لایه‌به‌لایه، least-privilege برای مقصد پشتیبان، مستندسازی و خودکارسازی بررسی‌ها، به عملیات پایدارتر و بازیابی سریع‌تر رسیدیم و اطمینان به سکوی مدیریت اسرار افزایش یافت.
#Vault #Raft #DisasterRecovery #Snapshots #DevOps #SRE #HighAvailability #Infrastructure
🟣لینک مقاله:
https://ku.bz/zPwwpmMyV
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
How We Rebuilt Our Vault Architecture with Raft, Snapshots, and DR
🟢 خلاصه مقاله:
ما معماری Vault را با تکیه بر سه رکن Raft، Snapshots و DR بازطراحی کردیم تا پیچیدگی عملیاتی را کاهش دهیم، وابستگی‌های بیرونی را حذف کنیم و تاب‌آوری را افزایش دهیم. با مهاجرت به ذخیره‌سازی یکپارچه مبتنی بر Raft، کلاستر ساده‌تر و قابل‌اعتمادتر شد و مسیر مهاجرت با محیط staging، تمرین‌های بازیابی، معیارهای rollback و پایش لحظه‌ای کنترل شد. Snapshots به‌طور خودکار زمان‌بندی و رمزنگاری شدند، در فضای ذخیره‌سازی ایمن نگهداری و با تمرین‌های دوره‌ای بازیابی راستی‌آزمایی شدند تا RPO شفاف و بازیابی قابل پیش‌بینی باشد. برای DR یک کلاستر ثانویه در دامنه خرابی جدا راه‌اندازی و با تکرار DR، برنامه failover با RTO مشخص و مانیتورینگ تأخیر تکرار، سلامت Raft و تازگی Snapshotها پیاده‌سازی شد. با امنیت لایه‌به‌لایه، least-privilege برای مقصد پشتیبان، مستندسازی و خودکارسازی بررسی‌ها، به عملیات پایدارتر و بازیابی سریع‌تر رسیدیم و اطمینان به سکوی مدیریت اسرار افزایش یافت.
#Vault #Raft #DisasterRecovery #Snapshots #DevOps #SRE #HighAvailability #Infrastructure
🟣لینک مقاله:
https://ku.bz/zPwwpmMyV
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
How We Rebuilt Our Vault Architecture with Raft, Snapshots, and DR
Author: Moshe Levine, DevOps Team Lead, BioCatch. Follow Moshe on Medium at https://medium.com/@moshlevine.
🔵 عنوان مقاله
Debugging the One-in-a-Million Failure: Migrating Pinterest’s Search Infrastructure to Kubernetes
🟢 خلاصه مقاله:
** این مقاله روایت مهاجرت زیرساخت جست‌وجوی Pinterest به Kubernetes است و چگونگی برخورد تیم با یک خطای بسیار نادر را شرح می‌دهد؛ خطایی که در محیط‌های آزمایشی دیده نمی‌شد اما در بار واقعی تولید، به‌صورت افزایش‌های مقطعی در تاخیر و تایم‌اوت‌های پراکنده بروز می‌کرد. تیم با تقویت مشاهده‌پذیری، هم‌بند کردن لاگ‌ها، متریک‌ها و تریس‌ها، و اجرای آزمایش‌های کنترل‌شده و تدریجی روی پیکربندی‌ها، مسئله را مانند یک معمای سیستم‌های توزیع‌شده واکاوی کرد. نتیجه نشان داد مشکل ناشی از برهم‌کنش چند عامل بود: زمان‌بندی ارکستریشن، محدودیت‌های منابع، و سیاست‌های retry/timeout که در شرایط خاص همدیگر را تقویت می‌کردند. راه‌حل شامل مجموعه‌ای از بهبودهای کوچک اما مکمل بود—از تنظیم دقیق درخواست/سقف منابع و آماده‌سازی سرویس تا هموار کردن رفتار autoscaling، بهینه‌سازی زمان‌بندی readiness، و مقاوم‌سازی سیاست‌های backoff و فشار معکوس. درس‌های کلیدی نیز بر مهاجرت‌های مبتنی بر SLO، آینه‌سازی ترافیک تولید، آزمایش خرابی متمرکز بر رخدادهای Kubernetes، و اتوماسیون علائم هشداردهنده برای تشدیدهای نادر تاکید دارند. در نهایت، مهاجرت مزایای مقیاس‌پذیری و یکنواختی استقرار را به‌همراه داشت و نشان داد که در مقیاس بزرگ، رخدادهای «یک در میلیون» باید به‌طور نظام‌مند دیده، سنجیده و مهار شوند.
#Kubernetes #Pinterest #SearchInfrastructure #DistributedSystems #Debugging #ReliabilityEngineering #Migration #ProductionIncidents
🟣لینک مقاله:
https://ku.bz/BS18f9fpM
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Debugging the One-in-a-Million Failure: Migrating Pinterest’s Search Infrastructure to Kubernetes
🟢 خلاصه مقاله:
** این مقاله روایت مهاجرت زیرساخت جست‌وجوی Pinterest به Kubernetes است و چگونگی برخورد تیم با یک خطای بسیار نادر را شرح می‌دهد؛ خطایی که در محیط‌های آزمایشی دیده نمی‌شد اما در بار واقعی تولید، به‌صورت افزایش‌های مقطعی در تاخیر و تایم‌اوت‌های پراکنده بروز می‌کرد. تیم با تقویت مشاهده‌پذیری، هم‌بند کردن لاگ‌ها، متریک‌ها و تریس‌ها، و اجرای آزمایش‌های کنترل‌شده و تدریجی روی پیکربندی‌ها، مسئله را مانند یک معمای سیستم‌های توزیع‌شده واکاوی کرد. نتیجه نشان داد مشکل ناشی از برهم‌کنش چند عامل بود: زمان‌بندی ارکستریشن، محدودیت‌های منابع، و سیاست‌های retry/timeout که در شرایط خاص همدیگر را تقویت می‌کردند. راه‌حل شامل مجموعه‌ای از بهبودهای کوچک اما مکمل بود—از تنظیم دقیق درخواست/سقف منابع و آماده‌سازی سرویس تا هموار کردن رفتار autoscaling، بهینه‌سازی زمان‌بندی readiness، و مقاوم‌سازی سیاست‌های backoff و فشار معکوس. درس‌های کلیدی نیز بر مهاجرت‌های مبتنی بر SLO، آینه‌سازی ترافیک تولید، آزمایش خرابی متمرکز بر رخدادهای Kubernetes، و اتوماسیون علائم هشداردهنده برای تشدیدهای نادر تاکید دارند. در نهایت، مهاجرت مزایای مقیاس‌پذیری و یکنواختی استقرار را به‌همراه داشت و نشان داد که در مقیاس بزرگ، رخدادهای «یک در میلیون» باید به‌طور نظام‌مند دیده، سنجیده و مهار شوند.
#Kubernetes #Pinterest #SearchInfrastructure #DistributedSystems #Debugging #ReliabilityEngineering #Migration #ProductionIncidents
🟣لینک مقاله:
https://ku.bz/BS18f9fpM
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
Debugging the One-in-a-Million Failure: Migrating Pinterest’s Search Infrastructure to Kubernetes
Samson Hu, Shashank Tavildar, Eric Kalkanger, Hunter Gatewood
Forwarded from AI Labdon
مدل opus 4.5 دیروز اومد. بینظیره. بهترین مدل دنیا برای coding با اختلاف زیاد.
یک اتفاق مهم دیگه اینکه Anthropic برای اولین بار قیمت بهترین مدل خودش رو به یک سوم تا یک پنجم قیمت قبلی کاهش داده!!
هر میلیون اینپوت از ۲۵ دلار شده ۵ دلار و هر میلیون output هم از ۷۵ دلار شده ۱۵ دلار!
<Amin Anvary/>
👉 https://t.iss.one/addlist/AJ7rh2IzIh02NTI0
یک اتفاق مهم دیگه اینکه Anthropic برای اولین بار قیمت بهترین مدل خودش رو به یک سوم تا یک پنجم قیمت قبلی کاهش داده!!
هر میلیون اینپوت از ۲۵ دلار شده ۵ دلار و هر میلیون output هم از ۷۵ دلار شده ۱۵ دلار!
<Amin Anvary/>
👉 https://t.iss.one/addlist/AJ7rh2IzIh02NTI0
❤1
🔵 عنوان مقاله
How to Prevent Failures with Kubernetes Topology Spread Constraints
🟢 خلاصه مقاله:
این مقاله نشان می‌دهد چرا استفاده از Pod Topology Spread Constraints در زمان rolling updates می‌تواند باعث توزیع ناعادلانه پادها شود و در پایان استقرار، یک یا چند ناحیه بیش‌ازحد شلوغ بماند. علت این است که Scheduler در هنگام جای‌گذاری پادهای جدید، پادهای قدیمی و جدید را با هم در نظر می‌گیرد؛ بنابراین پادهای تازه را به نواحی «فعلاً» کم‌تراکم می‌فرستد، اما با حذف تدریجی پادهای قدیمی، همان نواحی از نسخه جدید اشباع می‌شوند.
راه‌حل پیشنهادی استفاده از matchLabelKeys (برای نمونه با کلید pod-template-hash) است تا Scheduler هر نسل از پادها را فقط نسبت به هم‌نسل‌های خودش پخش کند. بدین ترتیب هر ReplicaSet به‌طور مستقل متعادل می‌شود و چون نسل قبلی نیز از قبل متعادل بوده، مجموع پادها در طول و پس از rollout یکنواخت باقی می‌ماند.
برای اجرای درست، از پشتیبانی Kubernetes v1.25+ نسبت به matchLabelKeys مطمئن شوید، topologyKey مناسب (مثلاً topology.kubernetes.io/zone) و maxSkew معقول انتخاب کنید و سیاست whenUnsatisfiable را بسته به نیاز سخت‌گیرانه (DoNotSchedule) یا منعطف (ScheduleAnyway) تنظیم کنید.
#Kubernetes #PodTopologySpreadConstraints #TopologySpread #RollingUpdates #DevOps #SRE #HighAvailability #matchLabelKeys
🟣لینک مقاله:
https://ku.bz/RypzHZTrM
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
How to Prevent Failures with Kubernetes Topology Spread Constraints
🟢 خلاصه مقاله:
این مقاله نشان می‌دهد چرا استفاده از Pod Topology Spread Constraints در زمان rolling updates می‌تواند باعث توزیع ناعادلانه پادها شود و در پایان استقرار، یک یا چند ناحیه بیش‌ازحد شلوغ بماند. علت این است که Scheduler در هنگام جای‌گذاری پادهای جدید، پادهای قدیمی و جدید را با هم در نظر می‌گیرد؛ بنابراین پادهای تازه را به نواحی «فعلاً» کم‌تراکم می‌فرستد، اما با حذف تدریجی پادهای قدیمی، همان نواحی از نسخه جدید اشباع می‌شوند.
راه‌حل پیشنهادی استفاده از matchLabelKeys (برای نمونه با کلید pod-template-hash) است تا Scheduler هر نسل از پادها را فقط نسبت به هم‌نسل‌های خودش پخش کند. بدین ترتیب هر ReplicaSet به‌طور مستقل متعادل می‌شود و چون نسل قبلی نیز از قبل متعادل بوده، مجموع پادها در طول و پس از rollout یکنواخت باقی می‌ماند.
برای اجرای درست، از پشتیبانی Kubernetes v1.25+ نسبت به matchLabelKeys مطمئن شوید، topologyKey مناسب (مثلاً topology.kubernetes.io/zone) و maxSkew معقول انتخاب کنید و سیاست whenUnsatisfiable را بسته به نیاز سخت‌گیرانه (DoNotSchedule) یا منعطف (ScheduleAnyway) تنظیم کنید.
#Kubernetes #PodTopologySpreadConstraints #TopologySpread #RollingUpdates #DevOps #SRE #HighAvailability #matchLabelKeys
🟣لینک مقاله:
https://ku.bz/RypzHZTrM
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
How to Prevent Failures with Kubernetes Topology Spread Constraints
How to Prevent Failures with Kubernetes Topology Spread Constraints Introduction In modern cloud-native environments, ensuring high availability and fault tolerance for your applications is critical …