چرا این موضوع مهم است؟
systemd فقط جایگزین یک init script نیست. Unit graph، socket activation، timer، mount و dependencyها را در یک مدل واحد قرار می‌دهد. همین مدل اجازه می‌دهد startup قابل پیش‌بینی‌تر و hardening سرویس granularتر شود.
در یک سیستم واقعی، قبل از انتخاب ابزار باید مدل ذهنی درستی از لایه‌ها داشته باشید. هر بار که یک مشکل را فقط با یک command یا تنظیم حفظی حل می‌کنیم، دانش به نسخه و محیط خاص گره می‌خورد. روش بهتر این است که ورودی، state، policy، مسیر داده و خروجی را مشخص کنیم. بعد ابزار را برای مشاهدهٔ یکی از این لایه‌ها انتخاب کنیم. این رویکرد باعث می‌شود وقتی نسخه یا توزیع عوض شد، هنوز بدانیم دنبال چه evidenceای هستیم.
مدل معماری
در موضوع مدیریت سرویس و sandboxing در systemd، componentها را روی یک مسیر ساده بکشید و مرز مسئولیت هرکدام را مشخص کنید. state پایدار، state runtime، dependency بیرونی و نقطهٔ اعمال policy را جدا کنید. وقتی diagram ساده دارید، خطا از یک «سیستم بزرگ و مبهم» به چند مرحلهٔ قابل آزمون تبدیل می‌شود.
روش عملی کار
با systemctl cat و systemctl show اول unit مؤثر را ببینید؛ بعد systemd-analyze security را به‌عنوان سرنخ استفاده کنید، نه حکم قطعی. هر ProtectSystem، PrivateTmp یا RestrictAddressFamilies باید با رفتار واقعی سرویس تست شود.
برای Production، تغییر باید قابل اندازه‌گیری و قابل برگشت باشد. baseline قبل از تغییر شامل نسخه، config مؤثر، log سالم، metric اصلی و یک تست end-to-end است. rollout را با canary شروع کنید؛ بعد از هر مرحله هم تست مثبت و هم تست منفی داشته باشید. اگر success criterion از قبل نوشته نشده باشد، بعد از اجرا به‌سادگی هر نتیجه‌ای را می‌توان «موفق» تفسیر کرد. rollback هم باید تمرین شود، نه اینکه فقط یک دستور روی کاغذ باشد.
از دید امنیت
امتیاز systemd-analyze security تضمین امنیت نیست. فعال‌کردن کورکورانهٔ گزینه‌ها هم می‌تواند سرویس را بشکند. باید نیاز فایل‌سیستم، شبکه، helper process و capabilityها را بشناسید.
از دید امنیت، کم‌کردن سطح دسترسی مهم است اما availability و قابلیت عیب‌یابی هم جزو امنیت عملیاتی‌اند. secretها، tokenها، capabilityها، network path و logهای حساس را جدا بررسی کنید. هر exception باید owner، دلیل و تاریخ بازبینی داشته باشد. کنترل‌هایی که هیچ‌کس نمی‌تواند اثرشان را مشاهده یا علتشان را توضیح دهد، در زمان incident به مانع تبدیل می‌شوند.
آزمایشگاه پیشنهادی
یک service ساده HTTP بسازید، baseline بگیرید و hardening directiveها را یکی‌یکی اضافه کنید. بعد هم test مثبت و هم test منفی اجرا کنید تا مطمئن شوید کاهش privilege واقعی است.
برای هر مرحله timestamp و خروجی را ذخیره کنید. یک failure کنترل‌شده ایجاد کنید تا مطمئن شوید monitoring واقعاً failure را می‌بیند. سپس سیستم را به baseline برگردانید و زمان recovery را ثبت کنید.
عیب‌یابی بر پایهٔ Evidence
Troubleshooting را با تغییر config شروع نکنید. اول محل دقیق failure را پیدا کنید: آیا ورودی وارد سیستم می‌شود؟ آیا state مورد انتظار ساخته شده؟ آیا policy اجازه می‌دهد؟ آیا خروجی از component خارج می‌شود؟ log، packet capture، metric و state API باید به یک timeline مشترک وصل شوند. نبودن event نیز evidence است؛ اگر request قبل از یک component دیده می‌شود و بعد از آن نه، دامنهٔ مسئله کوچک شده است.
Performance و ظرفیت
عملکرد را فقط با average نسنجید. p95/p99 latency، saturation، queue depth، retry و resource pressure تصویر بهتری می‌دهند. تغییری که در lab کوچک سریع است ممکن است زیر concurrency یا dataset واقعی bottleneck متفاوتی نشان دهد. capacity limitها را قبل از rollout بزرگ شناسایی کنید و alert را به thresholdهای قابل اقدام وصل کنید.
Production readiness
قبل از rollout نهایی، owner، change window، blast radius، success metric و rollback trigger باید مشخص باشند. اگر dependency خارجی دارید، رفتار هنگام timeout یا unavailable شدن آن را تست کنید. اگر config به چند host می‌رود، rollout مرحله‌ای و inventory دقیق لازم است. یک تغییر خوب باید observable، explainable و reversible باشد.
Runbook و انتقال دانش
در مستندسازی، فقط «چه دستورهایی اجرا شد» را ننویسید. سؤال، فرضیه، evidence مورد انتظار، نتیجه و دلیل تصمیم را ثبت کنید. اگر همکار دیگری بتواند با همان ورودی آزمایش را تکرار کند و به نتیجهٔ مشابه برسد، runbook ارزش عملیاتی دارد. اگر فقط نویسنده می‌داند چرا مرحله‌ای لازم است، دانش هنوز منتقل نشده است.
قبل از Production چه چیزی را اعتبارسنجی کنیم؟
نتیجهٔ Lab را مستقیم به Production تعمیم ندهید. یک change plan کوتاه بسازید که در آن دامنهٔ تغییر، owner، زمان اجرا، dependencyها، success metric و rollback trigger مشخص باشد. ابتدا روی canary یا درصد کوچکی از workload اجرا کنید و حداقل یک چرخهٔ واقعی restart، credential rotation یا deploy دوم را ببینید؛ بسیاری از خطاها در اولین اجرای سالم ظاهر نمی‌شوند. رفتار هنگام unavailable شدن dependency خارجی، پر شدن disk، timeout شبکه و ورودی نامعتبر را نیز بررسی کنید. اگر feature امنیتی است، test منفی باید نشان دهد مسیر غیرمجاز واقعاً بسته است؛ اگر feature performance است، benchmark باید با load و dataset نزدیک به واقعیت اجرا شود. در پایان، تصمیم rollout را با evidence ثبت کنید، نه با جملهٔ مبهم «به‌نظر خوب است».
نگهداری بلندمدت و بازبینی دوره‌ای
معماری بعد از deploy ثابت نمی‌ماند. نسخهٔ سیستم‌عامل، dependency، policy سازمان، certificate، endpoint و حجم workload تغییر می‌کنند. برای همین باید بازبینی دوره‌ای تعریف شود: نسخه‌های پشتیبانی‌نشده را پیدا کنید، exceptionهای قدیمی را ببندید، alertهای بی‌ارزش را حذف کنید و recovery را دوباره تمرین کنید. اگر configuration در Git نگهداری می‌شود، drift میان state واقعی و repository را اندازه بگیرید. اگر ابزار SaaS یا سرویس خارجی است، تغییر API، pricing، limit و مدل permission را دنبال کنید. مستندات باید تاریخ review داشته باشند تا تیم بداند کدام فرض‌ها هنوز معتبرند. نگهداری خوب یعنی سیستم بعد از شش ماه هم قابل توضیح و قابل بازیابی باشد، نه اینکه فقط روز اول deploy موفق بوده باشد.
جمع‌بندی
هدف این مقاله دربارهٔ مدیریت سرویس و sandboxing در systemd ارائهٔ یک دستور جادویی نیست؛ هدف ساختن مدل ذهنی است. وقتی معماری را بفهمید، baseline داشته باشید و تغییر را با evidence کوچک کنید، ابزارها قابل تعویض می‌شوند اما روش حل مسئله باقی می‌ماند. منبع اصلی این مقاله از Red Hat انتخاب شده تا جزئیات فنی قابل پیگیری باشند.
چک‌لیست سریع
- مسئله را در یک جمله تعریف کن.
- component و مرز اعتماد را مشخص کن.
- baseline را قبل از تغییر ذخیره کن.
- یک test مثبت و یک test منفی بساز.
- تغییر را با canary شروع کن.
- evidence را timestampدار نگه دار.
- rollback را واقعاً تمرین کن.
- نتیجه و exceptionها را در runbook ثبت کن.
وابستگی راه‌اندازی را از ترتیب اجرا جدا کنید
فرض کنید سرویس گزارش‌گیری به یک پایگاه داده محلی احتیاج دارد. نوشتن After تنها ترتیب اجرا را تعیین می‌کند: اگر هر دو واحد در تراکنش راه‌اندازی حضور داشته باشند، سرویس گزارش بعد از واحد پایگاه داده شروع می‌شود. این تنظیم به تنهایی پایگاه داده را فعال نمی‌کند. از طرف دیگر Requires یا Wants رابطه نیاز را بیان می‌کنند و بدون ترتیب مناسب، شروع هم‌زمان همچنان ممکن است. برای تشخیص مشکل باید دو پرسش جدا داشت: چه چیزی باعث وارد شدن واحد به تراکنش شده است و چه رابطه‌ای اجرای آن را عقب می‌اندازد؟
حتی پایان شروع واحد پایگاه داده الزاماً آماده بودن پاسخ‌گویی کاربردی آن نیست. سرویسی که فرایندش ایجاد شده ولی هنوز بازیابی داده را انجام می‌دهد ممکن است اتصال را رد کند. انتخاب Type مناسب و استفاده از اعلان آمادگی، در صورت پشتیبانی برنامه، این فاصله را روشن‌تر می‌کند. برنامه مصرف‌کننده نیز به مدیریت خطای اتصال و تلاش مجدد محدود نیاز دارد. افزودن یک تأخیر ثابت به ابتدای برنامه معمولاً مشکل را پنهان می‌کند، زیرا زمان بازیابی با اندازه داده و سرعت دیسک تغییر خواهد کرد.
سخت‌سازی بر پایه مسیرهای واقعی فایل
برای یک وب‌سرویس کوچک، فایل اجرایی، تنظیمات، محتوای ثابت، داده قابل نوشتن و فایل‌های موقت را فهرست کنید. اگر برنامه فقط در مسیر داده خود می‌نویسد، محدود کردن نوشتن در بقیه فایل‌سیستم تصمیم قابل آزمایشی است. اما برنامه‌ای که هنگام شروع فایل قفل، کش یا گواهی تولید می‌کند به استثناهای مشخص نیاز دارد. مسیرهای استثنا را از روی خطای واقعی و مستندات برنامه تعیین کنید؛ باز کردن کل یک شاخه بزرگ فقط برای خاموش شدن خطا، هدف محدودسازی را تضعیف می‌کند.
PrivateTmp فضای موقت خصوصی برای سرویس ایجاد می‌کند و ممکن است تبادل فایل از طریق مسیر موقت مشترک را مختل کند. بنابراین اگر یک تولیدکننده و مصرف‌کننده فایل دارید، ارتباط آنها را به دایرکتوری داده مشخص با مالکیت روشن منتقل کنید. همچنین ReadWritePaths مجوزهای عادی فایل را دور نمی‌زند: کاربری که بر اساس مالکیت و مجوز یونیکس امکان نوشتن ندارد، با اضافه شدن مسیر به این گزینه صاحب آن مجوز نمی‌شود. تفکیک محدودیت فضای نام از مجوز فایل، بسیاری از خطاهای ظاهراً متناقض را توضیح می‌دهد.
تشخیص حلقه راه‌اندازی و توقف ناقص
وقتی سرویس پشت سر هم راه‌اندازی می‌شود، ابتدا علت خروج فرایند اصلی را پیدا کنید. شماره وضعیت، سیگنال پایان، پیام‌های همان بازه زمانی و تعداد تلاش‌های مجدد را کنار هم بگذارید. سیاست Restart درمان خطای تنظیمات نیست؛ اگر برنامه به دلیل فایل گمشده خارج می‌شود، راه‌اندازی مکرر تنها گزارش را شلوغ می‌کند. محدودیت نرخ شروع نیز ممکن است پس از چند شکست مانع تلاش بعدی شود. رفع علت اصلی و سپس بازنشانی وضعیت شکست باید آگاهانه انجام شود، نه اینکه محدودیت محافظتی را بی‌دلیل حذف کنید.
توقف را هم مانند شروع آزمایش کنید. برنامه باید فرصت بستن اتصال‌ها و نوشتن داده لازم را داشته باشد، ولی نباید برای همیشه در حال توقف بماند. در یک محیط آزمایشی، درخواست طولانی ایجاد کنید و رفتار هنگام توقف سرویس را ثبت کنید. مشخص کنید آیا درخواست تکمیل می‌شود، خطای کنترل‌شده می‌گیرد یا نیمه‌کاره باقی می‌ماند. انتخاب زمان انتظار توقف باید با این رفتار کاربردی و زمان خاموش شدن میزبان سازگار باشد.
نگهداری تنظیمات بدون دستکاری فایل توزیع
برای تغییرات محلی از سازوکار override و drop-in استفاده کنید و فایل واحد متعلق به بسته را مستقیماً بازنویسی نکنید. پس از تغییر، پیکربندی مؤثر را دوباره ببینید؛ وجود چند قطعه تنظیم می‌تواند نتیجه‌ای متفاوت از فایل تازه ویرایش‌شده بسازد. بارگذاری دوباره تعریف واحد با راه‌اندازی مجدد خود برنامه یکی نیست و هر دو را باید متناسب با نوع تغییر انتخاب کرد. در گزارش تغییر، نام گزینه، نیاز برنامه و نتیجه آزمون مجاز و غیرمجاز را کنار هم ثبت کنید تا مدیر بعدی بتواند دلیل هر محدودیت را بفهمد.
