مهندس DevOpsپاسخ‌های مصاحبه

من پایپ‌لاین‌هایی طراحی می‌کنم که سریع، قابل‌اطمینان و امن باشند. مراحل معمولاً شامل موارد زیر است: تریگر از کنترل سورس، کش کردن وابستگی‌ها، تحلیل ایستا (SAST، linting)، تست‌های واحد و یکپارچه‌سازی، ساخت و کانتینرسازی، اسکن امنیتی (اسکن ایمیج کانتینر، حسابرسی وابستگی‌ها)، استقرار در محیط staging، تست‌های smoke، و استقرار تولید با قفل (gated production deployment). من محافظت شاخه (branch protection) را اعمال می‌کنم، بازبینی همتراز را الزامی می‌کنم و اجرای همهٔ چک‌ها را قبل از ادغام (merge) اجباری می‌کنم. Pipeline-as-code (Jenkinsfile، GitHub Actions YAML) تضمین می‌کند که پایپ‌لاین همراه با اپلیکیشن نسخه‌بندی شود.

من طراحی و راهبری کلاسترهای Kubernetes را روی EKS، GKE و روی زیرساخت‌های محلی (on-premises) انجام داده‌ام. با مفاهیم اصلی (Pods، Deployments، Services، ConfigMaps، Secrets، Ingress)، الگوهای میانی (StatefulSets، HorizontalPodAutoscaler، PodDisruptionBudgets) و عملیات کلاستر (آپگرید، مدیریت گروه‌های نود، RBAC) آشنا هستم. از Helm برای ریلیزهای تمپلیت‌شده و از ArgoCD برای استقرار مداوم مبتنی بر GitOps استفاده می‌کنم. همچنین سیاست‌های شبکه، استانداردهای امنیت پاد و OPA Gatekeeper برای اعمال سیاست‌ها را پیاده‌سازی کرده‌ام.

من Terraform را به‌عنوان ابزار اصلی IaC خود استفاده می‌کنم — کدی ماژولار و قابل‌استفادهٔ مجدد می‌نویسم با state از راه دور در S3/GCS، قفل state از طریق DynamoDB/GCS locks، و متغیرهای مخصوص محیط. همه‌چیز را در Git نسخه‌بندی می‌کنم، از pull request برای تغییرات زیرساختی استفاده می‌کنم و برای تغییرات تولیدی تأیید یک مهندس دوم را الزامی می‌کنم. قبل از هر merge در CI اجرای terraform plan را انجام می‌دهم تا تغییرات ناخواسته شناسایی شوند. برای مدیریت پیکربندی از Ansible استفاده می‌کنم. IaC برای بازتولیدپذیری و بازیابی از فاجعه غیرقابل مذاکره است.

من سه ستون مشاهده‌پذیری را پیاده‌سازی می‌کنم: متریک‌ها (Prometheus، Datadog، CloudWatch)، لاگ‌ها (ELK stack، Loki، CloudWatch Logs)، و تریس‌ها (Jaeger، Zipkin، AWS X-Ray). برای هر سرویس حیاتی SLO تعریف می‌کنم و هشداردهی را بر اساس آن SLOها ایجاد می‌کنم — نه صرفاً بر اساس آستانه‌های فنی که ممکن است با تجربهٔ کاربر هم‌راستا نباشند. برای هر آلارتی runbook می‌نویسم تا مهندس on-call بداند چگونه پاسخ دهد. مشاهده‌پذیری خوب یعنی توان پاسخ به «چه چیزی اشتباه است و چرا» ظرف چند دقیقه، نه چند ساعت.

من از یک فرایند پاسخ به حادثهٔ ساخت‌یافته پیروی می‌کنم. شدت حادثه را اعلام می‌کنم (P1-P4)، یک فرماندهٔ حادثه و یک مسئول ارتباطات تعیین می‌کنم. تیم مهندسی روی کاهش اثر متمرکز می‌شود — بازگردانی (rollback)، افزایش مقیاس یا اعمال hotfix — و نه تحلیل علت ریشه‌ای در حین حادثه. وضعیت را در بازه‌های زمانی منظم به ذی‌نفعان اطلاع‌رسانی می‌کنم. پس از حل، یک بازبینی بدون سرزنش (blameless post-mortem) انجام می‌دهیم: بازسازی خط زمانی، تحلیل علت ریشه‌ای با استفاده از 5-Whys، و تعیین آیتم‌های عملی با صاحب و تاریخ انجام. یادگیری از حوادث باعث رشد سیستم‌ها می‌شود.

امنیت را به سمت چپ می‌برم — در هر مرحلهٔ پایپ‌لاین یکپارچه می‌شود، نه اینکه در انتها اضافه شود. SAST (Semgrep، SonarQube) را در CI اجرا می‌کنم، SCA (Snyk، Dependabot) برای آسیب‌پذیری‌های وابستگی، اسکن ایمیج کانتینر (Trivy، Twistlock) و اسکن IaC (Checkov، tfsec) را در pull requestها قرار می‌دهم. اسرار را از طریق Vault یا AWS Secrets Manager مدیریت می‌کنم — هرگز در متغیرهای محیطی یا کد. اصل کمترین امتیاز (least-privilege) در IAM را اعمال می‌کنم، از حساب‌های سرویس استفاده می‌کنم و به‌طور منظم دسترسی‌ها را بررسی می‌کنم. امنیت مسئولیت مهندسی است، نه یک تحویل از InfoSec.

Blue-green: دو محیط تولید یکسان نگه می‌دارم. بعد از استقرار در محیط غیرفعال و اجرای smoke testها، ترافیک را از طریق لود بالانسر جابه‌جا می‌کنم. بازگردانی یک سوئیچ ترافیک است — بازیابی تقریباً آنی است. Canary: درصدی از ترافیک (معمولاً در ابتدا 5–10%) را به نسخهٔ جدید می‌فرستم و نرخ خطا، تاخیر و معیارهای تجاری را نسبت به خط پایه مانیتور می‌کنم. اگر آستانه‌ها شکسته شود، به‌صورت خودکار rollback انجام می‌دهم. از feature flagها همراه با canary برای کنترل بیشتر استفاده می‌کنم. استراتژی درست بستگی به ریسک تغییر دارد.

من به‌طور منظم استفادهٔ منابع را ممیزی می‌کنم — نمونه‌های بلااستفاده، دیتابیس‌های بیش‌ابعاد و ظرفیت رزروشدهٔ بدون استفاده منابع هدررفتهٔ رایج هستند. از autoscaling برای تطبیق ظرفیت با تقاضا استفاده می‌کنم و برای بارهای batch و توسعه از spot/preemptible instances استفاده می‌کنم. هر منبع را تگ می‌کنم تا تخصیص هزینه مشخص باشد و داشبوردهای هزینه را هفته‌ای با سرپرستان مهندسی بازبینی می‌کنم. از ابزارهایی مثل AWS Cost Explorer، Infracost (در CI) و CloudHealth برای دید و تشخیص ناهنجاری‌ها استفاده می‌کنم. بهینه‌سازی هزینه یک فرایند مداوم مهندسی است، نه یک پروژهٔ یک‌باره.