Academy and Foundation unixmens | Your skills, Your future
https://www.linkedin.com/posts/yashar-esmaildokht_google-borg-kubernetes-ugcPost-7238515381378666496-IuDf?utm_source=share&utm_medium=member_android
ابزار Kubernetes و چالشهای آن: چرا ترکیب OpenShift/KubeSphere با KubeVirt بهترین گزینه برای سازمانهاست؟
مقدمه
بسیاری تصور میکنند گوگل از Kubernetes در زیرساخت داخلی خود استفاده میکند. در حالی که واقعیت این است که گوگل همچنان از سیستمهای پیشرفتهتر خود یعنی Borg و Omega بهره میبرد؛ زیرا این سیستمها برای مدیریت دیتاسنترهای عظیم گوگل طراحی شدهاند و در مقیاسهای فراتر از Kubernetes کارایی بالاتری دارند. Kubernetes در واقع بر اساس تجربیات همان پروژهها ساخته شد و به صورت متنباز ارائه گردید تا جامعه جهانی از آن استفاده کند.
اما نکته مهم اینجاست: Kubernetes در دنیای سازمانی امروز، با وجود قدرت و انعطافپذیری بالا، همچنان چالشبرانگیز است.
چرا Kubernetes چالشبرانگیز است؟
پیچیدگی عملیاتی: نصب، مدیریت و نگهداری Kubernetes حتی برای تیمهای حرفهای آسان نیست.
نیاز به مهارت بالا: تیمها باید دانش عمیق در مفاهیم Networking، Storage، Security و CI/CD داشته باشند.
چالشهای امنیتی: بهصورت پیشفرض امنیت Kubernetes در سطح Enterprise کافی نیست.
مدیریت چندخوشهای (Multi-Cluster): برای سازمانهای بزرگ به یک کابوس مدیریتی تبدیل میشود.
هزینه آموزش و یادگیری: ورود تیمهای جدید زمانبر و پرهزینه است
چرا گوگل هنوز Borg و Omega را ترجیح میدهد؟
مقیاسپذیری فراتر از Kubernetes: در دیتاسنترهای گوگل که میلیونها کانتینر اجرا میشود، Borg و Omega بهینهتر هستند.
ثبات و تجربه عملیاتی: گوگل بیش از یک دهه این سیستمها را بهبود داده و آنها را در بالاترین سطح تولیدی استفاده میکند.
کاستومایز اختصاصی: Borg و Omega کاملاً بر اساس نیازهای خاص گوگل طراحی شدهاند، در حالی که Kubernetes یک پلتفرم عمومی برای جامعه جهانی است.
راهحل سازمانها: OpenShift و KubeSphere
برای بیشتر سازمانها، استفاده مستقیم از Kubernetes بدون ابزارهای تکمیلی منجر به مشکلات جدی میشود. اینجا است که OpenShift و KubeSphere وارد میدان میشوند:
OpenShift (Red Hat):
امنیت سازمانی قوی (SELinux، RBAC پیشرفته).
تجربه توسعهدهنده کامل (داشبورد، CI/CD داخلی).
پشتیبانی رسمی و Enterprise از سوی Red Hat/IBM.
KubeSphere:
نصب ساده و رابط کاربری کاربرپسند.
مدیریت چند خوشهای (Multi-Cluster) با قابلیتهای گسترده.
ماژولهای آماده برای DevOps، نظارت، و Service Mesh.
انتخاب مناسب برای سازمانهایی که به سادگی و انعطاف نیاز دارند.
نقش KubeVirt: اتصال VMها و Containerها
یکی از مشکلات رایج سازمانها این است که هنوز بارهای کاری Legacy (روی VMها) دارند.
با KubeVirt:
میتوان ماشینهای مجازی و کانتینرها را در یک بستر مشترک مدیریت کرد.
مهاجرت تدریجی از VM به Container بدون نیاز به دو پلتفرم جداگانه امکانپذیر میشود.
هزینه زیرساخت کاهش پیدا میکند و تیمها فقط یک ابزار مدیریت نیاز دارند.
در حالی که گوگل همچنان برای دیتاسنترهای داخلی خود از Borg و Omega استفاده میکند، Kubernetes به عنوان استاندارد جهانی معرفی شده است. با این وجود، Kubernetes بهتنهایی برای سازمانها بسیار چالشبرانگیز است.
راهحل درست برای ورود به دنیای Cloud-Native در سطح سازمانی، استفاده از پلتفرمهای تکمیلی مثل OpenShift یا KubeSphere و ترکیب آنها با KubeVirt است. این ترکیب نهتنها مشکلات پیچیدگی و امنیت را کاهش میدهد، بلکه امکان همگرایی کامل میان بارهای کاری سنتی (VM) و مدرن (Container) را فراهم میکند.
#kubernetes #devops #clustering #k8s #linux #security #google #borg #omega
https://t.iss.one/unixmens
مقدمه
بسیاری تصور میکنند گوگل از Kubernetes در زیرساخت داخلی خود استفاده میکند. در حالی که واقعیت این است که گوگل همچنان از سیستمهای پیشرفتهتر خود یعنی Borg و Omega بهره میبرد؛ زیرا این سیستمها برای مدیریت دیتاسنترهای عظیم گوگل طراحی شدهاند و در مقیاسهای فراتر از Kubernetes کارایی بالاتری دارند. Kubernetes در واقع بر اساس تجربیات همان پروژهها ساخته شد و به صورت متنباز ارائه گردید تا جامعه جهانی از آن استفاده کند.
اما نکته مهم اینجاست: Kubernetes در دنیای سازمانی امروز، با وجود قدرت و انعطافپذیری بالا، همچنان چالشبرانگیز است.
چرا Kubernetes چالشبرانگیز است؟
پیچیدگی عملیاتی: نصب، مدیریت و نگهداری Kubernetes حتی برای تیمهای حرفهای آسان نیست.
نیاز به مهارت بالا: تیمها باید دانش عمیق در مفاهیم Networking، Storage، Security و CI/CD داشته باشند.
چالشهای امنیتی: بهصورت پیشفرض امنیت Kubernetes در سطح Enterprise کافی نیست.
مدیریت چندخوشهای (Multi-Cluster): برای سازمانهای بزرگ به یک کابوس مدیریتی تبدیل میشود.
هزینه آموزش و یادگیری: ورود تیمهای جدید زمانبر و پرهزینه است
چرا گوگل هنوز Borg و Omega را ترجیح میدهد؟
مقیاسپذیری فراتر از Kubernetes: در دیتاسنترهای گوگل که میلیونها کانتینر اجرا میشود، Borg و Omega بهینهتر هستند.
ثبات و تجربه عملیاتی: گوگل بیش از یک دهه این سیستمها را بهبود داده و آنها را در بالاترین سطح تولیدی استفاده میکند.
کاستومایز اختصاصی: Borg و Omega کاملاً بر اساس نیازهای خاص گوگل طراحی شدهاند، در حالی که Kubernetes یک پلتفرم عمومی برای جامعه جهانی است.
راهحل سازمانها: OpenShift و KubeSphere
برای بیشتر سازمانها، استفاده مستقیم از Kubernetes بدون ابزارهای تکمیلی منجر به مشکلات جدی میشود. اینجا است که OpenShift و KubeSphere وارد میدان میشوند:
OpenShift (Red Hat):
امنیت سازمانی قوی (SELinux، RBAC پیشرفته).
تجربه توسعهدهنده کامل (داشبورد، CI/CD داخلی).
پشتیبانی رسمی و Enterprise از سوی Red Hat/IBM.
KubeSphere:
نصب ساده و رابط کاربری کاربرپسند.
مدیریت چند خوشهای (Multi-Cluster) با قابلیتهای گسترده.
ماژولهای آماده برای DevOps، نظارت، و Service Mesh.
انتخاب مناسب برای سازمانهایی که به سادگی و انعطاف نیاز دارند.
نقش KubeVirt: اتصال VMها و Containerها
یکی از مشکلات رایج سازمانها این است که هنوز بارهای کاری Legacy (روی VMها) دارند.
با KubeVirt:
میتوان ماشینهای مجازی و کانتینرها را در یک بستر مشترک مدیریت کرد.
مهاجرت تدریجی از VM به Container بدون نیاز به دو پلتفرم جداگانه امکانپذیر میشود.
هزینه زیرساخت کاهش پیدا میکند و تیمها فقط یک ابزار مدیریت نیاز دارند.
در حالی که گوگل همچنان برای دیتاسنترهای داخلی خود از Borg و Omega استفاده میکند، Kubernetes به عنوان استاندارد جهانی معرفی شده است. با این وجود، Kubernetes بهتنهایی برای سازمانها بسیار چالشبرانگیز است.
راهحل درست برای ورود به دنیای Cloud-Native در سطح سازمانی، استفاده از پلتفرمهای تکمیلی مثل OpenShift یا KubeSphere و ترکیب آنها با KubeVirt است. این ترکیب نهتنها مشکلات پیچیدگی و امنیت را کاهش میدهد، بلکه امکان همگرایی کامل میان بارهای کاری سنتی (VM) و مدرن (Container) را فراهم میکند.
#kubernetes #devops #clustering #k8s #linux #security #google #borg #omega
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
ارایه دهنده راهکارهای ارتقای سازمانی - فردی - تیمی
👍2
At VeeamON 2024, Veeam announced that in the upcoming version (likely v13), the Veeam Backup & Replication (VBR) Server will be available for Linux systems, in addition to Windows.
Historically, VBR has required a Windows installation. This move to support Linux is a long-awaited shift that many in the community have requested.
Deployment and design details mentioned in the post (though subject to change):
Expected delivery as an OVA (virtual appliance).
Likely based on a hardened Rocky Linux 9.2, managed by Veeam.
It will include a web-based console—though it's unclear if the traditional Windows console will also be available.
Initially, the Linux option may not support other distributions, focusing solely on Rocky Linux at launch.
Feature parity with the Windows version is hoped for, but not guaranteed.
Broader Context & Updates Since Then
Veeam Backup & Replication Version Info
The latest official release is v12.3.1.1139, released on March 19, 2025.
Wikipedia
As of that version, the Linux deployment of the VBR server was not yet available. VBR still runs on Windows in v12.
v13 Rolling Out with Linux Support
On September 3, 2025, Veeam officially released Veeam Backup & Replication 13 (v13)—but only as a Linux-based Software Appliance (VSA). The Windows installer is still pending and expected to come out in the coming months.
Available formats:
OVA (pre-built virtual appliance) for VMware vSphere (requires ESXi 7.0 U2 or later).
ISO for physical host or alternate hypervisor installations—with system requirements including:
x86-64 CPU with at least 8 cores.
Minimum 16 GB RAM, plus ~500 MB per concurrent job.
Two 240 GiB disks (for OS and installation).
Network: 1 Gbps+ local or 1 Mbps+ WAN connection.
Some existing Windows component dependencies still remain. For example, a Windows mount server is required for certain restore scenarios.
Due to the architecture changes in v13, Veeam has extended support for v12 (including its agents and plugins) to 4 years instead of the usual 3
#veeam #linux #backup
Historically, VBR has required a Windows installation. This move to support Linux is a long-awaited shift that many in the community have requested.
Deployment and design details mentioned in the post (though subject to change):
Expected delivery as an OVA (virtual appliance).
Likely based on a hardened Rocky Linux 9.2, managed by Veeam.
It will include a web-based console—though it's unclear if the traditional Windows console will also be available.
Initially, the Linux option may not support other distributions, focusing solely on Rocky Linux at launch.
Feature parity with the Windows version is hoped for, but not guaranteed.
Broader Context & Updates Since Then
Veeam Backup & Replication Version Info
The latest official release is v12.3.1.1139, released on March 19, 2025.
Wikipedia
As of that version, the Linux deployment of the VBR server was not yet available. VBR still runs on Windows in v12.
v13 Rolling Out with Linux Support
On September 3, 2025, Veeam officially released Veeam Backup & Replication 13 (v13)—but only as a Linux-based Software Appliance (VSA). The Windows installer is still pending and expected to come out in the coming months.
Available formats:
OVA (pre-built virtual appliance) for VMware vSphere (requires ESXi 7.0 U2 or later).
ISO for physical host or alternate hypervisor installations—with system requirements including:
x86-64 CPU with at least 8 cores.
Minimum 16 GB RAM, plus ~500 MB per concurrent job.
Two 240 GiB disks (for OS and installation).
Network: 1 Gbps+ local or 1 Mbps+ WAN connection.
Some existing Windows component dependencies still remain. For example, a Windows mount server is required for certain restore scenarios.
Due to the architecture changes in v13, Veeam has extended support for v12 (including its agents and plugins) to 4 years instead of the usual 3
#veeam #linux #backup
rate elk.pdf
162.8 KB
بررسی نرخ مربوط به داده و فرمول اختصاص محاسبه تقریبی رم
نسبت به نرخ داده در elasticsearch
بنده این فرمول را نسبت به ساختار های و معماری های مربوط به elasticsearch ، پردازش و تحلیل نموده که نرخ مربوطه حاصل گردیده است .
امید هست ، مورد استفاده ، جامعه It , devops , bigdata کشور قرار گیرد .
پذیرای هرگونه از پیشنهادات و نظرات و انتقادات شما عزیزان میباشم .
#data #elk #elasticsearch #linux #bigdata #log #etl
#yashar_esmaildokht
https://t.iss.one/unixmens
نسبت به نرخ داده در elasticsearch
بنده این فرمول را نسبت به ساختار های و معماری های مربوط به elasticsearch ، پردازش و تحلیل نموده که نرخ مربوطه حاصل گردیده است .
امید هست ، مورد استفاده ، جامعه It , devops , bigdata کشور قرار گیرد .
پذیرای هرگونه از پیشنهادات و نظرات و انتقادات شما عزیزان میباشم .
#data #elk #elasticsearch #linux #bigdata #log #etl
#yashar_esmaildokht
https://t.iss.one/unixmens
خرید Isovalent توسط سیسکو؛ گامی استراتژیک در آیندهی شبکه و امنیت چندابری
مقدمه
در دنیای فناوری اطلاعات، خریدها و ادغامهای استراتژیک اغلب مسیر آیندهی صنعت را شکل میدهند. یکی از مهمترین خریدهای اخیر در حوزه شبکه و امنیت، خرید شرکت Isovalent توسط سیسکو (Cisco Systems) است؛ حرکتی که نه تنها جایگاه سیسکو در بازار شبکههای ابری و چندابری را تقویت میکند، بلکه آیندهی فناوریهای مبتنی بر eBPF را نیز رقم خواهد زد.
پیشینه خرید
در ۲۱ دسامبر ۲۰۲۳، سیسکو اعلام کرد که قصد خرید Isovalent را دارد.
این معامله در ۱۲ آوریل ۲۰۲۴ نهایی شد.
با این خرید، سیسکو مالکیت فناوریهای کلیدی Isovalent مانند Cilium و Tetragon را به دست آورد؛ ابزارهایی که بهویژه در دنیای Cloud Native و محیطهای چندابری بهسرعت در حال تبدیل شدن به استاندارد صنعتی هستند.
فعالیت Isovalent و نقش آن در صنعت
در واقع Isovalent شرکتی پیشرو در توسعهی راهکارهای شبکه و امنیت مبتنی بر eBPF است. eBPF (Extended Berkeley Packet Filter) یک فناوری قدرتمند در هسته لینوکس است که امکان نظارت، مشاهدهپذیری (observability)، و اعمال سیاستهای امنیتی در سطح پایین سیستمعامل را بدون نیاز به تغییر کد کرنل فراهم میکند.
محصولات کلیدی Isovalent
1. Cilium:
یک پلتفرم متنباز برای شبکهسازی Cloud Native در Kubernetes.
قابلیتهایی مانند شبکهسازی امن، load balancing و observability را ارائه میدهد.
2. Tetragon:
یک ابزار امنیتی پیشرفته مبتنی بر eBPF.
امکان تشخیص تهدیدات لحظهای، مانیتورینگ امنیتی عمیق و اجرای سیاستهای امنیتی پویا را فراهم میکند.
انگیزههای سیسکو از این خرید
1. تقویت موقعیت در بازار چندابری (Multicloud):
بسیاری از سازمانها امروزه از چندین ارائهدهنده ابر استفاده میکنند. سیسکو با Cilium و Tetragon میتواند یک لایه مشترک شبکه و امنیت بر فراز تمام ابرها ایجاد کند.
2. افزایش توان امنیتی:
با eBPF، سیسکو میتواند قابلیتهای امنیتی را از سطح سختافزار و شبکههای سنتی به سطح نرمافزار و workloadها منتقل کند.
3. نوآوری در Observability و Performance:
ترکیب فناوریهای Isovalent با محصولات سیسکو، امکان پایش لحظهای و بهینهسازی عملکرد در مقیاس بالا را فراهم میکند.
4. همافزایی با اکوسیستم متنباز:
خرید Isovalent به معنای ورود جدیتر سیسکو به دنیای پروژههای متنباز است که برای نوآوری در زیرساختهای ابری حیاتی است.
تأثیرات این خرید بر صنعت
تقویت جایگاه eBPF بهعنوان ستون فقرات شبکهسازی و امنیت در محیطهای ابری.
رقابت شدیدتر با شرکتهایی مانند VMware، Google و Red Hat در حوزه Cloud Native Networking.
ایجاد یکپارچگی بیشتر بین زیرساختهای سنتی شبکه سیسکو و جهان Cloud Native و Kubernetes
خرید Isovalent توسط سیسکو را میتوان یک حرکت استراتژیک و آیندهنگرانه دانست که مسیر تحول در شبکهسازی ابری، امنیت workloadها و observability را تغییر خواهد داد. سیسکو با این اقدام، نهتنها قدرت خود را در بازار شبکههای سازمانی تثبیت میکند، بلکه خود را بهعنوان یکی از بازیگران اصلی در دنیای چندابری و Cloud Native مطرح میسازد.
#cisco #isovation #linux #kernel #ebpf #tetragon #cilium
https://t.iss.one/unixmens
مقدمه
در دنیای فناوری اطلاعات، خریدها و ادغامهای استراتژیک اغلب مسیر آیندهی صنعت را شکل میدهند. یکی از مهمترین خریدهای اخیر در حوزه شبکه و امنیت، خرید شرکت Isovalent توسط سیسکو (Cisco Systems) است؛ حرکتی که نه تنها جایگاه سیسکو در بازار شبکههای ابری و چندابری را تقویت میکند، بلکه آیندهی فناوریهای مبتنی بر eBPF را نیز رقم خواهد زد.
پیشینه خرید
در ۲۱ دسامبر ۲۰۲۳، سیسکو اعلام کرد که قصد خرید Isovalent را دارد.
این معامله در ۱۲ آوریل ۲۰۲۴ نهایی شد.
با این خرید، سیسکو مالکیت فناوریهای کلیدی Isovalent مانند Cilium و Tetragon را به دست آورد؛ ابزارهایی که بهویژه در دنیای Cloud Native و محیطهای چندابری بهسرعت در حال تبدیل شدن به استاندارد صنعتی هستند.
فعالیت Isovalent و نقش آن در صنعت
در واقع Isovalent شرکتی پیشرو در توسعهی راهکارهای شبکه و امنیت مبتنی بر eBPF است. eBPF (Extended Berkeley Packet Filter) یک فناوری قدرتمند در هسته لینوکس است که امکان نظارت، مشاهدهپذیری (observability)، و اعمال سیاستهای امنیتی در سطح پایین سیستمعامل را بدون نیاز به تغییر کد کرنل فراهم میکند.
محصولات کلیدی Isovalent
1. Cilium:
یک پلتفرم متنباز برای شبکهسازی Cloud Native در Kubernetes.
قابلیتهایی مانند شبکهسازی امن، load balancing و observability را ارائه میدهد.
2. Tetragon:
یک ابزار امنیتی پیشرفته مبتنی بر eBPF.
امکان تشخیص تهدیدات لحظهای، مانیتورینگ امنیتی عمیق و اجرای سیاستهای امنیتی پویا را فراهم میکند.
انگیزههای سیسکو از این خرید
1. تقویت موقعیت در بازار چندابری (Multicloud):
بسیاری از سازمانها امروزه از چندین ارائهدهنده ابر استفاده میکنند. سیسکو با Cilium و Tetragon میتواند یک لایه مشترک شبکه و امنیت بر فراز تمام ابرها ایجاد کند.
2. افزایش توان امنیتی:
با eBPF، سیسکو میتواند قابلیتهای امنیتی را از سطح سختافزار و شبکههای سنتی به سطح نرمافزار و workloadها منتقل کند.
3. نوآوری در Observability و Performance:
ترکیب فناوریهای Isovalent با محصولات سیسکو، امکان پایش لحظهای و بهینهسازی عملکرد در مقیاس بالا را فراهم میکند.
4. همافزایی با اکوسیستم متنباز:
خرید Isovalent به معنای ورود جدیتر سیسکو به دنیای پروژههای متنباز است که برای نوآوری در زیرساختهای ابری حیاتی است.
تأثیرات این خرید بر صنعت
تقویت جایگاه eBPF بهعنوان ستون فقرات شبکهسازی و امنیت در محیطهای ابری.
رقابت شدیدتر با شرکتهایی مانند VMware، Google و Red Hat در حوزه Cloud Native Networking.
ایجاد یکپارچگی بیشتر بین زیرساختهای سنتی شبکه سیسکو و جهان Cloud Native و Kubernetes
خرید Isovalent توسط سیسکو را میتوان یک حرکت استراتژیک و آیندهنگرانه دانست که مسیر تحول در شبکهسازی ابری، امنیت workloadها و observability را تغییر خواهد داد. سیسکو با این اقدام، نهتنها قدرت خود را در بازار شبکههای سازمانی تثبیت میکند، بلکه خود را بهعنوان یکی از بازیگران اصلی در دنیای چندابری و Cloud Native مطرح میسازد.
#cisco #isovation #linux #kernel #ebpf #tetragon #cilium
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
ارایه دهنده راهکارهای ارتقای سازمانی - فردی - تیمی
دواپس و مسیر های ورود به آن
#devops #linux #infra #infrastructure #system #design #network #programmer #developer
https://t.iss.one/unixmens
#devops #linux #infra #infrastructure #system #design #network #programmer #developer
https://t.iss.one/unixmens
Academy and Foundation unixmens | Your skills, Your future
دواپس دیگر یک نقش صرفاً فنی نیست؛ بلکه ترکیبی از فرهنگ، ابزار و تجربههای عملی است که به سازمانها کمک میکند سرعت، کیفیت و پایداری را همزمان بهبود دهند. اما اینکه یک فرد از چه مسیری وارد این حوزه شود، تأثیر زیادی بر عمق و گستره مهارتهای او خواهد داشت. بهطور…
بهعبارت دیگر، متخصص زیرساخت کسی است که هم شبکه را میشناسد، هم کدنویسی بلد است، هم از سیستمها شناخت عمیق دارد، و هم میتواند کل این پازل را در قالب یک معماری منسجم کنار هم بچیند.
در واقع زیرساختیها تنها مجری نیستند. به دلیل درک جامع خود، میتوانند نقش مشاور استراتژیک ایفا کنند و راهکارهایی ارائه دهند که از نظر اقتصادی، امنیتی و عملیاتی بهترین نتیجه را برای سازمان به همراه داشته باشد.
اما چرا ؟
🔹 دلیلش ساده است:
وقتی سالها با سیستمعامل، استوریج، دیتابیس، شبکه لینوکسی، HA، replication و tuning کار کردهای، بهصورت تجربی یاد میگیری که:
چطور منابع محدود (CPU, RAM, Disk I/O, Network) را بین سرویسها طراحی و بهینه کنی.
چطور برای scalability، سیستم را افقی (scale-out) یا عمودی (scale-up) توسعه دهی.
چه الگوهایی برای High Availability و Fault Tolerance وجود دارد.
چطور داده را در مقیاس بالا توزیع و ایمن نگه دارد
تفاوت با بقیه مسیرها
برنامهنویسها بیشتر روی design در سطح کد (Design Patterns, Microservices Architecture) تمرکز دارند، اما وقتی صحبت از زیرساخت و ظرفیت سیستم میشود، عمق لازم را ندارند.
متخصصان شبکه هم system design را معمولاً فقط در لایهی ارتباطات میشناسند (topology، routing، segmentation) نه در کل stack.
اما متخصص زیرساخت، وقتی از system design صحبت میکند، یعنی دید End-to-End دارد:
از block storage و replication گرفته تا شبکه، دیتابیس و اپلیکیشن.
چرا این در DevOps مهم است؟
چون DevOps فقط ابزار نیست؛ DevOps یعنی طراحی یک سیستم پایدار، مقیاسپذیر و قابلاعتماد.
اگر system design بلد نباشی، صرفاً ابزارها را به هم میدوزی.
ولی اگر system design را بفهمی، ابزارها را بر اساس نیاز واقعی سیستم انتخاب و ترکیب میکنی.
به همین خاطر کسی که از زیرساخت آمده، معمولاً در تیم DevOps نقش معمار (Architect) را هم میتواند بر عهده بگیرد، در حالی که بقیه مسیرها بیشتر در نقش مجری یا توسعهدهنده باقی میمانند.
#devops #linux #infra #infrastructure #system #design #network #programmer #developer
https://t.iss.one/unixmens
در واقع زیرساختیها تنها مجری نیستند. به دلیل درک جامع خود، میتوانند نقش مشاور استراتژیک ایفا کنند و راهکارهایی ارائه دهند که از نظر اقتصادی، امنیتی و عملیاتی بهترین نتیجه را برای سازمان به همراه داشته باشد.
اما چرا ؟
🔹 دلیلش ساده است:
وقتی سالها با سیستمعامل، استوریج، دیتابیس، شبکه لینوکسی، HA، replication و tuning کار کردهای، بهصورت تجربی یاد میگیری که:
چطور منابع محدود (CPU, RAM, Disk I/O, Network) را بین سرویسها طراحی و بهینه کنی.
چطور برای scalability، سیستم را افقی (scale-out) یا عمودی (scale-up) توسعه دهی.
چه الگوهایی برای High Availability و Fault Tolerance وجود دارد.
چطور داده را در مقیاس بالا توزیع و ایمن نگه دارد
تفاوت با بقیه مسیرها
برنامهنویسها بیشتر روی design در سطح کد (Design Patterns, Microservices Architecture) تمرکز دارند، اما وقتی صحبت از زیرساخت و ظرفیت سیستم میشود، عمق لازم را ندارند.
متخصصان شبکه هم system design را معمولاً فقط در لایهی ارتباطات میشناسند (topology، routing، segmentation) نه در کل stack.
اما متخصص زیرساخت، وقتی از system design صحبت میکند، یعنی دید End-to-End دارد:
از block storage و replication گرفته تا شبکه، دیتابیس و اپلیکیشن.
چرا این در DevOps مهم است؟
چون DevOps فقط ابزار نیست؛ DevOps یعنی طراحی یک سیستم پایدار، مقیاسپذیر و قابلاعتماد.
اگر system design بلد نباشی، صرفاً ابزارها را به هم میدوزی.
ولی اگر system design را بفهمی، ابزارها را بر اساس نیاز واقعی سیستم انتخاب و ترکیب میکنی.
به همین خاطر کسی که از زیرساخت آمده، معمولاً در تیم DevOps نقش معمار (Architect) را هم میتواند بر عهده بگیرد، در حالی که بقیه مسیرها بیشتر در نقش مجری یا توسعهدهنده باقی میمانند.
#devops #linux #infra #infrastructure #system #design #network #programmer #developer
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
ارایه دهنده راهکارهای ارتقای سازمانی - فردی - تیمی
دوستان دواپسی نکته ای را از یاد نبریم
دواپس نصب سریع ابزار ها نیست .
دواپس سرعت بخشیدن به کارهای تکراری و toil work هست
دواپس یعنی داشتن درک system design .
از یاد نبریم وقتی شغل هایی که مفهوم engineer را یدک میکشن . به معنای ، implementation ، problem solving, optimisation, upgradation هست .
این یعنی دانستن معماری ، تحلیل ، و درک ماهیت اجزا و قابلیت حل مشکلات هست .
هدف نصب و استقرار به جای ۱ ساعت در ۱۰ دقیقه و ندانستن اجزا و رفع اون نیست .
اون مورد سرعت و اتومیشن هم برای bcp و drp هست ، در واقع شناخت اجزای سیستم و قابلیت حل مسائل در شرایط حساس مانند BCP/DRP.
مهندس DevOps بودن، یعنی درک این که ارزش ما فقط در سرعت نصب ابزار نیست، بلکه در توانایی طراحی، تحلیل و حل مسائل پیچیده زیرساختی و سازمانی است.
وهمچنین درک ساختار در موضوعات operation , prosessing , tecnical بخش جدانشدنی از این مسیر است.
#devops #linux #culture #team
https://t.iss.one/unixmens
دواپس نصب سریع ابزار ها نیست .
دواپس سرعت بخشیدن به کارهای تکراری و toil work هست
دواپس یعنی داشتن درک system design .
از یاد نبریم وقتی شغل هایی که مفهوم engineer را یدک میکشن . به معنای ، implementation ، problem solving, optimisation, upgradation هست .
این یعنی دانستن معماری ، تحلیل ، و درک ماهیت اجزا و قابلیت حل مشکلات هست .
هدف نصب و استقرار به جای ۱ ساعت در ۱۰ دقیقه و ندانستن اجزا و رفع اون نیست .
اون مورد سرعت و اتومیشن هم برای bcp و drp هست ، در واقع شناخت اجزای سیستم و قابلیت حل مسائل در شرایط حساس مانند BCP/DRP.
مهندس DevOps بودن، یعنی درک این که ارزش ما فقط در سرعت نصب ابزار نیست، بلکه در توانایی طراحی، تحلیل و حل مسائل پیچیده زیرساختی و سازمانی است.
وهمچنین درک ساختار در موضوعات operation , prosessing , tecnical بخش جدانشدنی از این مسیر است.
#devops #linux #culture #team
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
ارایه دهنده راهکارهای ارتقای سازمانی - فردی - تیمی
Two bugs discovered in the NVIDIA Linux Open GPU Kernel Modules (drivers) and they can be exploited to gain root level access. The bugs can be triggered by an attacker controlling a local unprivileged process. Their security implications were confirmed via a proof of concept that achieves kernel read and write primitives. Those bugs are already fixed and use your Linux distributions package manager to apply security updates to your nvidia drivers on Linux servers and desktops
Link
#security
#kernel #exploite #linux
https://t.iss.one/unixmens
Link
#security
#kernel #exploite #linux
https://t.iss.one/unixmens
مفهوم ارتقا و رشد پایدار
چگونه انسان و ماشین در هم تنیده اند !؟؟
در واقع من دواپس هستم یا دواپس من !!؟
در فلسفهٔ هگل، فرایند دیالکتیکی از سه مرحله تشکیل میشود:
1. تز (Thesis) – گزاره یا ایدهٔ اولیه
2. آنتیتز (Antithesis) – نفی یا تقابل با ایدهٔ اولیه
3. سنتز (Synthesis) – مرحلهٔ فراتر که از دلِ تضادِ میان تز و آنتیتز زاده میشود و هر دو را در سطحی بالاتر رفع (Aufhebung) میکند.
🔹 توضیح بیشتر:
در نگاه هگل، حرکت تاریخ، اندیشه و هستی همگی دیالکتیکی هستند؛ یعنی رشد و تکامل از راه تضاد و نفی رخ میدهد.
سنتز نه صرفاً سازش، بلکه ادغام خلاقانه و برتری یافتن بر هر دو سوی تضاد است.
مثلاً:
تز: آزادی فردی
آنتیتز: نظم اجتماعی
سنتز: نظامی که هم آزادی فرد را حفظ میکند و هم نظم جامعه را برقرار میسازد (مانند دولت عقلانی در فلسفه هگل).
اگر بخواهیم ساده بگوییم:
> تز میگوید «الف»،
آنتیتز میگوید «نه الف»،
سنتز میگوید «هم الف و هم نه الف، اما در سطحی بالاتر».
واژهی Aufhebung یکی از عمیقترین و چندلایهترین مفاهیم در فلسفهی هگل است — واژهای که ترجمهی سادهای ندارد و سه معنای همزمان را در خود دارد:
1. نفی کردن (لغو) – چیزی از بین میرود یا رد میشود.
2. حفظ کردن (نگهداشتن) – با وجود نفی، جوهر و ارزش درونی آن چیز حفظ میشود.
3. بالا بردن (ارتقا دادن) – کل فرآیند در سطحی بالاتر و غنیتر ادامه مییابد.
هگل عمداً از واژهای استفاده میکند که این سه معنا را همزمان در خود داشته باشد. چون از دید او، در دیالکتیک هیچ چیز «کاملاً نابود» نمیشود؛ بلکه نفی میشود تا در سطحی بالاتر حفظ گردد.
🔹 نمونهی ساده:
در رشد انسان:
کودک → نوجوان → بزرگسال
"بزرگسال" هم کودک نیست (نفی)، هم تجربهها و ویژگیهای دوران کودکی را در خود دارد (حفظ)، و هم آنها را به سطحی بالاتر از آگاهی و تعقل رسانده (ارتقا).
🔹 در سطح فلسفی:
وقتی یک «تز» با «آنتیتز» روبهرو میشود، تضاد آنها در «سنتز» از بین نمیرود، بلکه در سنتز رفع (Aufgehoben) میشود؛ یعنی هم نفی میشود، هم حفظ، و هم ارتقا.
به تعبیر زیبای هگل:
در واقع Aufhebung روحِ دیالکتیک است؛ همان چیزی که از تضاد، زندگی میسازد.
1. تز (Thesis)
ایده یا وضعیت اولیه.
در این مرحله، یک گزاره یا واقعیت مطرح میشود.
مثلاً: «فرد باید آزاد باشد.»
2. آنتیتز (Antithesis)
ایدهای در تضاد با تز پدیدار میشود.
مثلاً: «جامعه باید نظم داشته باشد؛ آزادی کامل موجب هرجومرج میشود.»
3. سنتز (Synthesis)
اینجاست که تضاد میان تز و آنتیتز، بهجای حذف یکی از آنها،
در سطحی بالاتر رفع (Aufhebung) میشود.
این "رفع" یعنی:
نفی → تز و آنتیتز دیگر به شکل قبلی وجود ندارند.
حفظ → جوهر هر دو در سنتز باقی میماند.
ارتقا → نتیجه، سطح بالاتری از فهم و واقعیت را نمایندگی میکند.
مثلاً:
آزادیِ فردی درونِ نظمِ اجتماعی — جایی که آزادی و نظم نه متضاد، بلکه مکملاند.
مثال روزمره برای درک سادهتر:
تز: احساسات مهمتر از عقلاند.
آنتیتز: عقل مهمتر از احساسات است.
سنتز (Aufhebung): عقل و احساس باید در تعادل باشند؛ هر دو لازماند.
نکتهٔ کلیدی:
در نظام هگل، این چرخه فقط یکبار اتفاق نمیافتد (تکرار پذیر و ادامه دار )
بلکه پیوسته تکرار میشود و هر سنتز، خود به تزِ مرحلهی بعد تبدیل میشود.
به این ترتیب، آگاهی، تاریخ، و جهان بهصورت مارپیچی صعودی رشد میکنند.
رجوع شود به مفاهیم cmmi , agile ، scrum یا devops process
#devops #linux
https://t.iss.one/unixmens
چگونه انسان و ماشین در هم تنیده اند !؟؟
در واقع من دواپس هستم یا دواپس من !!؟
در فلسفهٔ هگل، فرایند دیالکتیکی از سه مرحله تشکیل میشود:
1. تز (Thesis) – گزاره یا ایدهٔ اولیه
2. آنتیتز (Antithesis) – نفی یا تقابل با ایدهٔ اولیه
3. سنتز (Synthesis) – مرحلهٔ فراتر که از دلِ تضادِ میان تز و آنتیتز زاده میشود و هر دو را در سطحی بالاتر رفع (Aufhebung) میکند.
🔹 توضیح بیشتر:
در نگاه هگل، حرکت تاریخ، اندیشه و هستی همگی دیالکتیکی هستند؛ یعنی رشد و تکامل از راه تضاد و نفی رخ میدهد.
سنتز نه صرفاً سازش، بلکه ادغام خلاقانه و برتری یافتن بر هر دو سوی تضاد است.
مثلاً:
تز: آزادی فردی
آنتیتز: نظم اجتماعی
سنتز: نظامی که هم آزادی فرد را حفظ میکند و هم نظم جامعه را برقرار میسازد (مانند دولت عقلانی در فلسفه هگل).
اگر بخواهیم ساده بگوییم:
> تز میگوید «الف»،
آنتیتز میگوید «نه الف»،
سنتز میگوید «هم الف و هم نه الف، اما در سطحی بالاتر».
واژهی Aufhebung یکی از عمیقترین و چندلایهترین مفاهیم در فلسفهی هگل است — واژهای که ترجمهی سادهای ندارد و سه معنای همزمان را در خود دارد:
1. نفی کردن (لغو) – چیزی از بین میرود یا رد میشود.
2. حفظ کردن (نگهداشتن) – با وجود نفی، جوهر و ارزش درونی آن چیز حفظ میشود.
3. بالا بردن (ارتقا دادن) – کل فرآیند در سطحی بالاتر و غنیتر ادامه مییابد.
هگل عمداً از واژهای استفاده میکند که این سه معنا را همزمان در خود داشته باشد. چون از دید او، در دیالکتیک هیچ چیز «کاملاً نابود» نمیشود؛ بلکه نفی میشود تا در سطحی بالاتر حفظ گردد.
🔹 نمونهی ساده:
در رشد انسان:
کودک → نوجوان → بزرگسال
"بزرگسال" هم کودک نیست (نفی)، هم تجربهها و ویژگیهای دوران کودکی را در خود دارد (حفظ)، و هم آنها را به سطحی بالاتر از آگاهی و تعقل رسانده (ارتقا).
🔹 در سطح فلسفی:
وقتی یک «تز» با «آنتیتز» روبهرو میشود، تضاد آنها در «سنتز» از بین نمیرود، بلکه در سنتز رفع (Aufgehoben) میشود؛ یعنی هم نفی میشود، هم حفظ، و هم ارتقا.
به تعبیر زیبای هگل:
در واقع Aufhebung روحِ دیالکتیک است؛ همان چیزی که از تضاد، زندگی میسازد.
1. تز (Thesis)
ایده یا وضعیت اولیه.
در این مرحله، یک گزاره یا واقعیت مطرح میشود.
مثلاً: «فرد باید آزاد باشد.»
2. آنتیتز (Antithesis)
ایدهای در تضاد با تز پدیدار میشود.
مثلاً: «جامعه باید نظم داشته باشد؛ آزادی کامل موجب هرجومرج میشود.»
3. سنتز (Synthesis)
اینجاست که تضاد میان تز و آنتیتز، بهجای حذف یکی از آنها،
در سطحی بالاتر رفع (Aufhebung) میشود.
این "رفع" یعنی:
نفی → تز و آنتیتز دیگر به شکل قبلی وجود ندارند.
حفظ → جوهر هر دو در سنتز باقی میماند.
ارتقا → نتیجه، سطح بالاتری از فهم و واقعیت را نمایندگی میکند.
مثلاً:
آزادیِ فردی درونِ نظمِ اجتماعی — جایی که آزادی و نظم نه متضاد، بلکه مکملاند.
مثال روزمره برای درک سادهتر:
تز: احساسات مهمتر از عقلاند.
آنتیتز: عقل مهمتر از احساسات است.
سنتز (Aufhebung): عقل و احساس باید در تعادل باشند؛ هر دو لازماند.
نکتهٔ کلیدی:
در نظام هگل، این چرخه فقط یکبار اتفاق نمیافتد (تکرار پذیر و ادامه دار )
بلکه پیوسته تکرار میشود و هر سنتز، خود به تزِ مرحلهی بعد تبدیل میشود.
به این ترتیب، آگاهی، تاریخ، و جهان بهصورت مارپیچی صعودی رشد میکنند.
رجوع شود به مفاهیم cmmi , agile ، scrum یا devops process
#devops #linux
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
ارایه دهنده راهکارهای ارتقای سازمانی - فردی - تیمی