کتاب مدیریت لینوکس ۲ نسخه PDF انگلیسی

معرفی Linux Administration 2

فایل این محصول با نام Linux Administration 2.pdf ثبت شده است. اطلاعات موجود نویسنده یا ویرایش قطعی را مشخص نمی‌کند؛ بنابراین این توضیحات فقط بر موضوع واقعی فایل یعنی ادامه مباحث مدیریت لینوکس تمرکز دارد. اگر مدیریت پایه شامل User، Service و File System باشد، سطح پیشرفته‌تر بیشتر به پایداری عملیاتی، ظرفیت، امنیت، Storage، Network، Automation، Monitoring و Recovery می‌پردازد.

در محیط واقعی، Administrator باید بتواند یک سیستم را نه فقط «روشن نگه دارد»، بلکه رفتار آن را اندازه‌گیری کند، Failure را پیش‌بینی کند، Change را کنترل کند و در صورت Incident سریع به وضعیت سالم بازگردد. این دید، محور اصلی مدیریت حرفه‌ای Linux است.

مدیریت عملیاتی چیست؟

Operations یعنی نگهداری Service در شرایط واقعی. Reliability، Performance، Security و Recoverability باید هم‌زمان دیده شوند. بهبود یک بخش نباید بخش دیگر را بدون ارزیابی تخریب کند.

Baseline سیستم

قبل از تشخیص مشکل باید بدانیم رفتار عادی چیست. Baseline شامل مصرف CPU، Memory، Disk، Network و Latency سرویس در شرایط طبیعی است.

بدون Baseline، تشخیص اینکه یک Metric واقعاً غیرعادی است دشوار می‌شود.

Capacity Planning

Capacity Planning بررسی می‌کند منابع فعلی تا چه زمانی پاسخ‌گو هستند. Growth داده، Traffic، CPU و Storage باید Trend شوند.

افزایش منابع تنها راه‌حل نیست؛ گاهی Optimization یا Architecture بهتر هزینه کمتری دارد.

Load Average

Load Average باید همراه تعداد CPU و نوع Workload تفسیر شود. عدد بالا می‌تواند از CPU یا انتظار I/O ناشی شود.

دیدن Load بدون بررسی Process و I/O به نتیجه‌گیری اشتباه منجر می‌شود.

I/O Monitoring

Disk I/O یکی از Bottleneckهای رایج Database و Serviceهاست. Latency، Queue و Throughput برای تحلیل مهم‌اند.

مصرف Disk بالا الزاماً مشکل نیست؛ مهم این است که Application به Latency مورد نیاز برسد.

Inode

File System ممکن است فضای آزاد داشته باشد اما Inode آن تمام شود. این وضعیت در سیستم‌هایی با میلیون‌ها File کوچک رخ می‌دهد.

Monitoring باید هم Capacity حجمی و هم تعداد Inode را ببیند.

File Descriptor

Processها برای File، Socket و Pipe از File Descriptor استفاده می‌کنند. رسیدن به Limit می‌تواند Connection جدید را Fail کند.

افزایش Limit بدون پیدا کردن علت Leak راه‌حل کامل نیست.

Process States

Process می‌تواند Running، Sleeping، Stopped یا Zombie باشد. State اطلاعات ارزشمندی درباره رفتار سیستم می‌دهد.

Zombie معمولاً نشان می‌دهد Parent وضعیت Child پایان‌یافته را Collect نکرده است.

OOM

وقتی Memory شدیداً کم شود، Kernel ممکن است برای حفظ سیستم Processی را متوقف کند. بررسی Log و Memory Pattern برای تشخیص OOM ضروری است.

صرفاً Restart کردن Application علت Memory Leak یا ظرفیت ناکافی را حل نمی‌کند.

Kernel Logs

پیام‌های Kernel می‌توانند خطاهای Driver، Disk، Network یا Memory را نشان دهند. در Failureهای سطح پایین باید Log Application و Kernel کنار هم دیده شوند.

Boot Process

شناخت Boot از Firmware و Bootloader تا Kernel و Init System برای Troubleshooting سیستم‌هایی که بالا نمی‌آیند ضروری است.

هر مرحله Failure Signature متفاوتی دارد.

Bootloader

Bootloader Kernel و Parameterهای Boot را بارگذاری می‌کند. تغییر اشتباه Configuration می‌تواند سیستم را غیرقابل Boot کند.

قبل از تغییر باید مسیر Recovery مانند Console یا Rescue Environment در دسترس باشد.

Kernel Parameters

بعضی رفتارهای Runtime با Parameterهای Kernel کنترل می‌شوند. Tuning باید بر اساس Measurement انجام شود، نه Copy کردن تنظیمات تصادفی از اینترنت.

هر تغییر باید مستند، قابل بازگشت و مرتبط با Problem مشخص باشد.

System Limits

Limitهای User و Process برای محافظت از منابع سیستم استفاده می‌شوند. تعداد Process، Open File و Memory از نمونه‌های رایج‌اند.

Limit بسیار پایین Service را Fail می‌کند و Limit بی‌حساب نیز می‌تواند Protection را کاهش دهد.

Service Dependencies

سرویس‌ها مستقل نیستند. Web Application ممکن است به DNS، Database، Storage و Certificate وابسته باشد.

در Incident باید Dependency Map وجود داشته باشد تا Root Cause سریع‌تر پیدا شود.

Health Check

Running بودن Process به معنی Healthy بودن Service نیست. Health Check باید Function واقعی مانند اتصال Database یا پاسخ API را بررسی کند.

Monitoring Metrics

Metric خوب باید قابل اقدام باشد. CPU، Memory و Disk مفیدند، اما Latency، Error Rate و Request Rate اغلب به تجربه کاربر نزدیک‌تر هستند.

Logs، Metrics و Traces

هر سه نوع Observability پاسخ متفاوتی می‌دهند. Metric Trend را نشان می‌دهد، Log Context می‌دهد و Trace مسیر Request را در سیستم توزیع‌شده روشن می‌کند.

Alert Design

Alert باید به Failure واقعی یا Risk نزدیک باشد. Alert روی هر Spike کوچک باعث خستگی تیم می‌شود.

Severity و Ownership Alert باید روشن باشد.

Runbook

Runbook مراحل بررسی Incident رایج را ثبت می‌کند. هدف حذف فکر کردن نیست؛ هدف جلوگیری از فراموش شدن Checkهای مهم در فشار Incident است.

Incident Response

در Incident ابتدا Impact کنترل می‌شود، سپس Root Cause بررسی می‌شود. تغییرات عجولانه متعدد Evidence را از بین می‌برند.

Timeline دقیق Event و Changeها برای Postmortem ارزشمند است.

Postmortem

Postmortem باید روی علت سیستماتیک تمرکز کند، نه سرزنش فرد. سؤال اصلی این است که چرا سیستم اجازه داد خطا به Incident تبدیل شود.

Action Item باید Owner و Deadline داشته باشد.

High Availability

High Availability با حذف Single Point of Failure ساخته می‌شود. فقط داشتن دو Server کافی نیست؛ Failover، Data Consistency و Health Detection نیز لازم‌اند.

Redundancy

Redundancy احتمال Downtime ناشی از Failure یک Component را کاهش می‌دهد، اما Complexity را افزایش می‌دهد. Component اضافه باید خودش Monitor و Test شود.

Load Balancing

Load Balancer Traffic را میان چند Backend توزیع می‌کند. Health Check و Session Strategy روی Reliability اثر دارند.

DNS Reliability

DNS بخشی از Availability سرویس است. TTL، Provider و Failover Strategy باید متناسب با معماری انتخاب شوند.

Network Troubleshooting

عیب‌یابی شبکه بهتر است Layer-by-layer انجام شود: Link، Address، Route، DNS، Port و Application. این روش از حدس‌های پراکنده جلوگیری می‌کند.

Latency

Latency می‌تواند در Network، Disk، Database یا Application ایجاد شود. اندازه‌گیری End-to-End و سپس شکستن مسیر به بخش‌ها روش مناسب تشخیص است.

Packet Loss

Packet Loss می‌تواند Throughput و Connection Quality را کاهش دهد. باید مشخص شود Loss در Host، مسیر شبکه یا Provider رخ می‌دهد.

Firewall Policy

Firewall باید بر اصل Deny by Default و Allow نیازهای مشخص تکیه کند. Ruleهای قدیمی و بدون Owner باید Audit شوند.

Network Segmentation

همه Serverها نباید به همه چیز دسترسی داشته باشند. Segmentation دامنه اثر Compromise را محدود می‌کند.

SSH Hardening

مدیریت SSH شامل Key مناسب، محدود کردن Accountها، Log کردن Access و محافظت از Credential است. Private Key حساس باید Permission محدود داشته باشد.

Secrets Management

Password و Token نباید در Script یا Repository ذخیره شوند. Secret باید با ابزار و Policy مناسب مدیریت و Rotate شود.

Patch Strategy

Patch باید بر اساس Risk اولویت‌بندی شود. سیستم Internet-facing و Vulnerability بحرانی نیازمند واکنش سریع‌تر است.

Patch بدون Test نیز می‌تواند Availability را تهدید کند؛ بنابراین Balance لازم است.

Vulnerability Management

فهرست Package و Serviceهای فعال باید شناخته شود تا Vulnerability مرتبط قابل ردیابی باشد. Asset ناشناخته Patch نمی‌شود.

Configuration Drift

وقتی Serverها به مرور با تغییرات دستی متفاوت می‌شوند، Drift ایجاد می‌شود. Drift Troubleshooting و Deployment را دشوار می‌کند.

Configuration as Code یکی از راه‌های کاهش این مشکل است.

Automation ایمن

Automation می‌تواند خطا را کاهش دهد اما یک Bug را نیز در صدها Server تکرار کند. بنابراین Test، Rollout مرحله‌ای و Rollback ضروری‌اند.

Idempotency

عملیات Idempotent با اجرای مجدد نتیجه نامطلوب اضافی ایجاد نمی‌کند. این ویژگی برای Configuration Management بسیار مهم است.

Version Control

Config و Script باید در Version Control باشند تا تاریخچه، Review و Rollback ممکن شود. Secret نباید داخل Repository قرار گیرد.

Storage Reliability

Storage باید از نظر Capacity، Performance و Failure بررسی شود. SMART یا ابزارهای Vendor می‌توانند نشانه‌های Hardware را ارائه دهند.

LVM عملیاتی

LVM انعطاف Resize و Snapshot می‌دهد. با این حال Snapshot طولانی یا پرشده می‌تواند مشکل ایجاد کند و باید Monitor شود.

Snapshot

Snapshot برای نقطه بازگشت کوتاه‌مدت مفید است، اما معمولاً Backup مستقل محسوب نمی‌شود. Failure Storage اصلی ممکن است Snapshot را نیز از بین ببرد.

RAID Monitoring

RAID خراب اگر Monitor نشود ممکن است مدت‌ها در حالت Degraded بماند و Failure Disk دوم Data را تهدید کند.

Alert روی Degraded Array ضروری است.

Backup Verification

Backup بدون Verification اعتمادپذیر نیست. Checksum، Job Status و Restore Test باید بخشی از فرآیند باشند.

Restore Drill

تمرین Restore نشان می‌دهد Documentation، Credential و Backup واقعاً کار می‌کنند. اولین Restore نباید روز Disaster باشد.

Disaster Recovery

DR فراتر از Backup است. باید مشخص باشد در از دست رفتن کامل Server یا Site چگونه Service بازسازی می‌شود.

Dependencyها، DNS، Certificate و Secret نیز بخشی از Recovery هستند.

RPO و RTO

RPO مقدار Data Loss قابل قبول و RTO زمان بازگشت قابل قبول را تعریف می‌کند. معماری Backup و HA باید از این اهداف پیروی کند.

Database Operations

Administrator عمومی باید بداند Database به Disk، Memory، Network و Backup چگونه وابسته است. تغییر File بدون ابزار Database می‌تواند Corruption ایجاد کند.

Log Retention

Retention باید بین نیاز Troubleshooting، Compliance و Storage تعادل ایجاد کند. Log حساس نیز باید Access Control داشته باشد.

Centralized Logging

ارسال Log به سیستم مرکزی باعث می‌شود Failure یک Server Evidence را از بین نبرد و Search میان چند Host آسان‌تر شود.

Time Sync

Clock هماهنگ برای ساخت Timeline Incident حیاتی است. اختلاف زمان میان Hostها می‌تواند تحلیل Event را دشوار کند.

Certificates

Certificate تاریخ انقضا دارد و Expiry یکی از Failureهای قابل پیشگیری است. Monitoring Expiration باید خودکار باشد.

Resource Quotas

Quota مانع مصرف بی‌حد Resource توسط User یا Workload می‌شود. Limit باید بر اساس نیاز واقعی تنظیم شود.

Containers

Containerها Kernel Host را به اشتراک می‌گذارند و جایگزین فهم Linux نیستند. Network، Storage، Process و Permission همچنان اهمیت دارند.

Container Logs

Log داخل Container نباید بدون Strategy رشد کند. خروجی بهتر است به Logging System منتقل و Retention مدیریت شود.

Virtualization

در VM باید تفاوت Resource فیزیکی و مجازی فهمیده شود. Overcommit Host می‌تواند Performance چند Guest را هم‌زمان تحت تأثیر قرار دهد.

Cloud Linux

در Cloud بخشی از Hardware توسط Provider مدیریت می‌شود اما OS، User، Package، Service و بسیاری از تنظیمات امنیتی همچنان مسئولیت کاربر هستند.

Immutable Infrastructure

به‌جای تغییر مکرر Server، می‌توان Image جدید ساخت و Instance را جایگزین کرد. این رویکرد Drift را کاهش می‌دهد.

Maintenance Window

تغییرات پرریسک باید در زمان برنامه‌ریزی‌شده انجام شوند. Communication و Rollback بخشی از Maintenance موفق‌اند.

Change Validation

پس از تغییر فقط «Command موفق شد» کافی نیست. Health، Metric و Function سرویس باید بررسی شوند.

Rollback

Rollback باید قبل از Change طراحی شود. اگر بازگشت به Version قبلی نیاز به Data Migration دارد، موضوع پیچیده‌تر است.

Documentation عملیاتی

مستندات باید کوتاه، به‌روز و قابل اجرا باشند. Runbook قدیمی در Incident می‌تواند از نبود مستندات بدتر باشد.

امنیت و Availability

Security و Availability دشمن هم نیستند؛ تنظیم درست باید هر دو را در نظر بگیرد. Control امنیتی که Service را بدون Plan از دسترس خارج کند طراحی ضعیفی دارد.

روش Troubleshooting

ابتدا Problem را دقیق تعریف کنید: چه چیزی Fail شده، چه کسی تحت تأثیر است و از چه زمانی. سپس آخرین Change و Evidence بررسی شوند.

هر بار یک Hypothesis را Test کنید و از تغییر هم‌زمان چند متغیر خودداری کنید.

روش مطالعه پیشنهادی

یک Lab با دو یا سه VM بسازید. Monitoring، Backup، Firewall و Service Dependency ایجاد کنید. سپس Failureهای کنترل‌شده مانند پر شدن Disk یا توقف Service را تمرین کنید.

برای هر تمرین Runbook و Postmortem کوتاه بنویسید؛ این کار مهارت عملیاتی را بسیار سریع‌تر از حفظ Commandها افزایش می‌دهد.

این فایل برای چه کسانی مناسب است؟

• مدیران Linux که مبانی را می‌دانند.
• DevOps و SREهای تازه‌کار.
• مدیران VPS و Hosting.
• Backend Developerهایی که با Production کار می‌کنند.
• دانشجویان علاقه‌مند به Operations و Cloud.

جمع‌بندی

Linux Administration 2 را می‌توان به‌عنوان ادامه طبیعی مدیریت پایه لینوکس دید: تمرکز از Command و تنظیمات اولیه به Reliability، Monitoring، Security، Capacity، Automation و Recovery منتقل می‌شود. در این سطح، مهم‌ترین مهارت توانایی مشاهده سیستم و تصمیم‌گیری بر اساس Evidence است.

سیستم خوب فقط سیستمی نیست که امروز کار می‌کند؛ باید قابل Monitor، قابل Patch، قابل Backup و قابل Recovery باشد. مطالعه این فایل در کنار Lab، Incident Simulation و Restore Drill می‌تواند دید عملی لازم برای مدیریت محیط‌های واقعی Linux، Cloud و Production را تقویت کند.