🔵 عنوان مقاله
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

🔵 عنوان مقاله
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

مدل opus 4.5 دیروز اومد. بینظیره. بهترین مدل دنیا برای coding با اختلاف زیاد.
یک اتفاق مهم دیگه اینکه Anthropic برای اولین بار قیمت بهترین مدل خودش رو به یک سوم تا یک پنجم قیمت قبلی کاهش داده!!
هر میلیون اینپوت از ۲۵ دلار شده ۵ دلار و هر میلیون output هم از ۷۵ دلار شده ۱۵ دلار!

<Amin Anvary/>

👉 https://t.iss.one/addlist/AJ7rh2IzIh02NTI0

🔵 عنوان مقاله
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

🔵 عنوان مقاله
Bringing Node.js HTTP servers to Cloudflare Workers (4 minute read)

🟢 خلاصه مقاله:
** Cloudflare Workers با افزودن APIهای client و server از طریق node:http و با فعال‌سازی پرچم nodejs_compat، امکان اجرای مستقیم برنامه‌های Node.js را فراهم کرده است. این قابلیت پلی بین مدل سرورهای سبک Node.js (مانند http.createServer و الگوی req/res) و مدل رسیدگی به درخواست در Workers می‌سازد؛ در این روش، شماره پورت به‌عنوان شناسه برای نگاشت سرور Node.js به خط لوله داخلی درخواست‌ها استفاده می‌شود. نتیجه این است که برنامه‌های مبتنی بر Express.js و Koa می‌توانند بدون بازنویسی اساسی، به‌صورت سراسری روی لبه اجرا شوند و از مزایای zero cold start و مقیاس‌پذیری خودکار بهره ببرند.

#CloudflareWorkers #Nodejs #Express #Koa #Serverless #EdgeComputing #HTTP #JavaScript

🟣لینک مقاله:
https://blog.cloudflare.com/bringing-node-js-http-servers-to-cloudflare-workers/?utm_source=tldrdevops

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
Numaflow: serverless event platform

🟢 خلاصه مقاله:
**Numaflow یک پلتفرم serverless برای پردازش رویدادهاست که ساخت و اجرای پایپ‌لاین‌های داده‌ی رویدادمحور را بدون دردسر مدیریت زیرساخت ممکن می‌کند. با تعریف جریان‌های شفاف بین منبع، پردازش و مقصد، توسعه‌دهنده فقط منطق کسب‌وکار را به‌صورت توابع سبک پیاده‌سازی می‌کند و پلتفرم مقیاس‌پذیری افقی، مدیریت فشار، بازیابی خطا و پایش را بر عهده می‌گیرد. Numaflow برای سناریوهای کم‌تأخیر و جریان‌های آنی طراحی شده، الگوهای بی‌حالت و حالت‌دار (مثل پنجره‌بندی) را پشتیبانی می‌کند و روی محیط‌های cloud-native مانند Kubernetes به‌صورت قابل‌حمل اجرا می‌شود. نتیجه، چابکی بیشتر تیم‌ها و کاهش هزینه از طریق مقیاس‌پذیری خودکار و scale-to-zero برای کاربردهایی مانند تحلیل بلادرنگ، ETL جریانی، تشخیص ناهنجاری/تقلب و پردازش IoT است.

#Numaflow #Serverless #EventDriven #DataPipelines #StreamingData #CloudNative #Kubernetes #RealTimeAnalytics

🟣لینک مقاله:
https://ku.bz/JNLMwJpSx

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon