کار روزمرهٔ دوآپس میان وضعیت یک میزبان و تاریخچهٔ تغییر کد رفت‌وبرگشت دارد. امشب پاسخ‌ها را به‌صورت فهرست فرمان حفظ نمی‌کنیم؛ برای Linux از مشاهده تا تغییر امن پیش می‌رویم و برای Git تفاوت مدل‌های شاخه‌سازی و روش حل تعارض را بر اساس جریان تیم توضیح می‌دهیم.

پرسش‌های ۴۱ تا ۴۵: مدیریت Linux#

۴۱. یک مهندس DevOps چه فرمان‌های پایهٔ Linux را باید بداند؟#

پاسخ کوتاه: گروه‌های مهم شامل پیمایش و فایل (pwd، ls، cp، mv)، متن (rg یا grep، sed، awk)، فرایند (ps، top)، منابع (df، du، free)، شبکه (ip، ss، curl) و سرویس (systemctl، journalctl) هستند.

مصاحبه‌کننده معمولاً کاربرد و ایمنی را می‌سنجد، نه تعداد نام‌ها را. پیش از حذف یا تغییر، مسیر و خروجی انتخاب را بررسی کنید؛ rm -rf پاسخ پیش‌فرض نیست. تفاوت df با du، پورت listening با اتصال برقرار، و process با service را توضیح دهید. گزینه‌ها میان توزیع‌ها و نسخه‌ها فرق می‌کنند، پس man و --help نیز بخشی از مهارت‌اند. یک سناریوی عیب‌یابی از حفظ فهرست ارزشمندتر است.

۴۲. shell scripting چیست؟#

پاسخ کوتاه: shell script فایل نسخه‌پذیری از فرمان‌ها، شرط، حلقه و تابع است که shell آن را تفسیر می‌کند. برای چسباندن ابزارها، کارهای تکراری و bootstrap سبک مناسب است، ولی برای منطق پیچیده ممکن است زبان دیگری خواناتر و آزمون‌پذیرتر باشد.

script قابل اعتماد باید ورودی را اعتبارسنجی کند، متغیرها را نقل‌قول کند، exit status را بررسی کند و پیام خطای قابل فهم بدهد. در Bash، set -euo pipefail می‌تواند بعضی خطاها را آشکارتر کند، اما جای فهم semantics و مدیریت صریح خطا را نمی‌گیرد. idempotence، dry-run و محدودکردن اثر برای عملیات زیرساختی مهم‌اند. دادهٔ حساس را در argument یا log آشکار نکنید.

۴۳. systemd چیست؟#

پاسخ کوتاه: systemd مدیر سیستم و سرویس در بسیاری از توزیع‌های Linux است. فرایند PID 1 را فراهم می‌کند و unitهایی مانند service، socket، timer، mount و target را با dependency و سیاست چرخهٔ عمر مدیریت می‌کند.

unit file «یک script شروع» ساده نیست؛ بخش‌های [Unit]، [Service] و [Install] dependency، روش اجرا و فعال‌سازی را جدا می‌کنند. After= ترتیب را بیان می‌کند و الزاماً dependency ایجاد نمی‌کند؛ برای آن معمولاً Requires= یا Wants= نیز مطرح است. systemd می‌تواند restart policy، user، capability و محدودیت resource اعمال کند. لاگ بسیاری از واحدها از journal با journalctl قابل بررسی است.

۴۴. سرویس‌ها را در Linux چگونه مدیریت می‌کنید؟#

پاسخ کوتاه: با systemctl status و is-active وضع را می‌بینیم، با start و stop اجرای فعلی را تغییر می‌دهیم، و با enable یا disable رفتار آغاز خودکار را تنظیم می‌کنیم. restart و reload یکسان نیستند.

reload از خود سرویس می‌خواهد تنظیم را بدون توقف کامل بازخوانی کند و فقط اگر پشتیبانی شود کار می‌کند؛ daemon-reload تعریف unitهای systemd را دوباره می‌خواند. پیش از restart روی production باید اثر وقفه و replicaهای سالم را سنجید. پس از تغییر، status، log، پورت و یک درخواست واقعی را بررسی کنید. enable --now فعال‌سازی و شروع را با هم انجام می‌دهد، اما موفقیت فرمان هنوز سلامت application را ثابت نمی‌کند.

۴۵. Filesystem Hierarchy در Linux چیست؟#

پاسخ کوتاه: Filesystem Hierarchy Standard یا FHS قرارداد جای‌گذاری انواع فایل در مسیرهایی مانند /etc برای تنظیم میزبان، /var برای دادهٔ متغیر، /usr برای برنامه و دادهٔ اشتراکی، /run برای وضعیت runtime و /home برای کاربران است.

ریشهٔ / آغاز درخت واحد است و filesystemهای دیگر در آن mount می‌شوند. /tmp برای دادهٔ موقت است و ماندگاری آن تضمین مشابه دادهٔ برنامه ندارد. /proc و /sys viewهای کرنل‌اند، نه فایل‌های عادی دیسک. توزیع‌ها و نرم‌افزارها ممکن است جزئیات متفاوت داشته باشند؛ هدف مصاحبه فهمیدن نوع داده و پیامد backup، مجوز و پرشدن filesystem است.

پرسش‌های ۴۶ تا ۵۰: Git#

۴۶. Git چیست؟#

پاسخ کوتاه: Git سامانهٔ کنترل نسخهٔ توزیع‌شده است. هر clone معمولاً تاریخچه و objectهای repository را دارد؛ commit یک snapshot محتوامحور با والد و metadata است و branch اشاره‌گری متحرک به commit محسوب می‌شود.

Git با GitHub یا GitLab یکسان نیست؛ آن‌ها hosting و همکاری پیرامون Git می‌دهند. working tree، index و repository سه وضعیت مهم‌اند: فایل را تغییر می‌دهید، محتوای انتخابی را stage می‌کنید و commit می‌سازید. hash برای یکپارچگی و هویت object مفید است، اما امضای commit مفهوم دیگری دارد. secret را با حذف در commit بعدی واقعاً از تاریخچه پاک نمی‌کنید و باید credential را نیز باطل کنید.

۴۷. branching strategy چیست؟#

پاسخ کوتاه: branching strategy قرارداد تیم دربارهٔ عمر شاخه‌ها، نقطهٔ ادغام، review، release و hotfix است. هدف، کاهش تعارض و روشن‌کردن مسیر تغییر تا production است؛ خود Git یک راهبرد واحد تحمیل نمی‌کند.

معیار انتخاب شامل تعداد نسخه‌های هم‌زمان، cadence انتشار، اندازهٔ تیم، الزامات review و کیفیت CI است. شاخهٔ بلندعمر merge دردناک و بازخورد دیر می‌سازد؛ شاخهٔ کوتاه بدون feature flag نیز ممکن است کد ناقص را آشکار کند. ruleهای protected branch، الزام آزمون و شیوهٔ merge باید با راهبرد هماهنگ باشند. نام شاخه به‌تنهایی کنترل فرایند نیست.

۴۸. Git Flow چیست؟#

پاسخ کوتاه: Git Flow مدلی با شاخه‌های بلندعمر main و develop و شاخه‌های feature، release و hotfix است. برای محصولی با نسخه‌های برنامه‌ریزی‌شده و نگه‌داری چند خط انتشار می‌تواند نظم ایجاد کند.

هزینهٔ آن تعداد merge و فاصلهٔ بیشتر تا یکپارچه‌سازی است. برای سرویس وب با انتشار روزانه، این تشریفات اغلب بیش از نیاز است. hotfix باید دوباره به شاخه‌های مرتبط برگردد تا اصلاح گم نشود. Git Flow را «روش استاندارد Git» معرفی نکنید؛ یک مدل تاریخی و اختیاری است. اگر تیم آن را انتخاب می‌کند، منبع حقیقت نسخه و automation انتشار باید دقیق باشد.

۴۹. trunk-based development چیست؟#

پاسخ کوتاه: در trunk-based development اعضا تغییرهای کوچک را با فاصلهٔ کوتاه در شاخهٔ اصلی ادغام می‌کنند؛ شاخهٔ feature اگر باشد کوتاه‌عمر است. CI سریع و feature flag امکان می‌دهند کد ناقص اما غیرفعال ادغام شود.

این مدل به معنی commit مستقیم و بی‌بازبینی نیست. pull request کوچک، pair programming یا review پس از commit می‌تواند کنترل کیفیت بدهد. شرط موفقیت، آزمون قابل اعتماد، build سریع و توان جداکردن deploy از release است. ادغام پرتکرار اندازهٔ تعارض را کم می‌کند، اما اگر trunk مرتب شکسته بماند، مزیت از بین می‌رود. تیم باید قاعدهٔ repair یا revert فوری داشته باشد.

۵۰. تعارض merge را چگونه حل می‌کنید؟#

پاسخ کوتاه: ابتدا git status و diff سه‌طرفه را می‌بینم، قصد هر دو تغییر را با نویسندگان روشن می‌کنم، فایل را به نتیجهٔ درست و نه صرفاً بدون marker ویرایش می‌کنم، آن را stage می‌کنم و merge یا rebase را ادامه می‌دهم.

پس از حل متن، آزمون و build لازم است؛ Git نمی‌تواند تعارض معنایی را تشخیص دهد. اگر مسیر اشتباه است، git merge --abort یا git rebase --abort بازگشت امن‌تری از دست‌کاری نامطمئن تاریخچه است. روی شاخهٔ مشترک، force push و بازنویسی تاریخچه باید طبق قرارداد تیم باشد. انتخاب خودکار «ours» یا «theirs» بدون فهم تغییر، حل تعارض محسوب نمی‌شود.

جمع‌بندی مصاحبه‌ای#

برای Linux ابتدا مشاهده، سپس تغییر و در پایان اعتبارسنجی را توضیح دهید. برای Git نیز هدف تیم را پیش از نام راهبرد بگویید. یک پاسخ حرفه‌ای پیامد را می‌بیند: restart ممکن است وقفه بسازد، حذف ممکن است برگشت‌ناپذیر باشد و merge موفق ممکن است رفتار برنامه را شکسته باشد.

منابع#