Academy and Foundation unixmens | Your skills, Your future

اختلال گسترده سرویس‌های مایکروسافت در نوامبر ۲۰۲۶، بار دیگر اهمیت پایداری زیرساخت‌های فناوری اطلاعات (Infrastructure Reliability) را نشان داد. در این رخداد، سرویس‌هایی مانند Outlook، Microsoft Teams و برخی دیگر از محصولات Microsoft 365 با اختلال مواجه شدند.

بر اساس گزارش‌های اولیه، از دسترس خارج شدن تعدادی از سرورها و مشکلات مرتبط با پردازش ارتباطات امن، در کنار تغییرات پیکربندی شبکه، در زنجیره این اختلال نقش داشتند. این اتفاق نشان داد که حتی در زیرساخت‌های عظیمی مانند مایکروسافت، یک مشکل در لایه زیرساخت می‌تواند به اختلال گسترده در سرویس‌های وابسته منجر شود.

اما سؤال مهم این است: نقش DevOps در جلوگیری از چنین اتفاقاتی چیست؟

دواپس صرفاً مجموعه‌ای از ابزارها برای خودکارسازی استقرار نرم‌افزار نیست؛ بلکه رویکردی مهندسی برای افزایش پایداری، کنترل تغییرات و کاهش ریسک عملیاتی است.

در چنین شرایطی، چند اصل اهمیت ویژه‌ای دارند:

* Change Management: اعمال تغییرات زیرساختی به‌صورت کنترل‌شده و با امکان بازگشت سریع (Rollback).

* Canary Deployment: انتشار تدریجی تغییرات روی بخش کوچکی از زیرساخت پیش از تعمیم آن به کل سیستم.

* Observability: تحلیل هم‌زمان Metrics، Logs و Traces برای شناسایی رفتارهای غیرعادی پیش از تبدیل شدن به بحران.

* High Availability: طراحی معماری به‌گونه‌ای که خرابی یک سرور یا حتی یک دیتاسنتر باعث توقف کل سرویس نشود.

* Chaos Engineering: شبیه‌سازی سناریوهای خرابی برای ارزیابی رفتار واقعی سیستم در شرایط بحرانی.

* Capacity Planning: بررسی ظرفیت زیرساخت در شرایطی که بخشی از منابع از دسترس خارج می‌شوند.

در کنار این موارد، مهندسی قابلیت اطمینان سایت (SRE) با استفاده از مفاهیمی مانند SLI، SLO، SLA و Error Budget کمک می‌کند پایداری سرویس به شاخصی قابل اندازه‌گیری و قابل مدیریت تبدیل شود.

نکته مهم این است که هیچ زیرساختی مصون از خرابی نیست؛ حتی زیرساخت‌های مایکروسافت. تفاوت معماری‌های بالغ در این است که چگونه خرابی را شناسایی، محدود و مدیریت می‌کنند.

به اعتقاد من، بلوغ واقعی DevOps زمانی مشخص می‌شود که به‌جای تمرکز صرف بر سرعت Deploy و توسعه، بتوانیم زیرساختی طراحی کنیم که در برابر خطا، تغییرات ناموفق و خرابی اجزا تاب‌آوری داشته باشد.

چراکه در معماری Enterprise، مسئله فقط بالا نگه داشتن سرویس نیست؛ مسئله حفظ تداوم کسب‌وکار در شرایطی است که زیرساخت مطابق انتظار رفتار نمی‌کند.

When I joined Red Hat 27 years ago, we shipped Linux in boxes to retailers. A lot has changed since then. We’ve grown, evolved, and helped shape an industry that never stands still. But through it all, one thing has remained constant: the people who make Red Hat what it is. The way we show up for each other, bring different perspectives to the table, and make room for people to be themselves is at the heart of our culture. In a world that moves faster every day, taking the time to connect, celebrate one another, and give back matters more than ever.That’s what makes We Are Red Hat Week so

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

Moving from vSphere to bare-metal Red Hat OpenShiftRed Hat OpenShift has supported bare metal from the start. But for much of its history, most deployments ran on top of an existing virtualization layer like VMware vSphere or Nutanix. That’s shifting. As more organizations adopt Red Hat OpenShift Virtualization and run virtual machines (VMs) directly on the platform, bare-metal deployments have become a much larger part of production workloads. That changes what you might expect from the console.When you transition from traditional virtualization to containerized environments, your mental mo

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