S/۰۸ · خدمات
زیرساخت و DevOps
سرپا می‌ماند، حتی وقتی چیزی از کار می‌افتد.
کلاسترهای Kubernetes و پایپ‌لاین‌های اطرافشان: توزیع‌شده در چند منطقه، آماده برای بحران، تحت پایش شبانه‌روزی و به‌روزرسانی بدون توقف.
- اجرا روی
- سرورهای شما، کلاد یا هر دو
- طراحی‌شده برای
- دسترس‌پذیری بالا و بازیابی
- تحویل به شکل
- زیرساخت به‌صورت کد
- ۰۱
استقرار دلهره‌آور است و دیروقت شب انجام می‌شود.
- ۰۲
یک سرور که از کار بیفتد، کل کسب‌وکار می‌خوابد.
- ۰۳
نسخه‌ی پشتیبان دارید ولی هیچ‌وقت بازیابی‌اش نکرده‌اید.
- ۰۴
هزینه‌ی کلادتان سریع‌تر از ترافیکتان رشد می‌کند.
- D/۰۱
کلاستر Kubernetes
کلاستر را روی سرورهای خودتان، روی کلاد یا ترکیبی از هر دو می‌سازیم، با چیدمانی یکسان در همه‌جا: سه نود کنترل، گروه‌های جداگانه‌ی نود کاری، ingress، ذخیره‌سازی و گواهی‌ها. همه‌ی تنظیمات مکتوب می‌شود تا هر کسی در تیمتان بتواند کلاستر را دوباره بسازد، نه فقط کسی که راهش انداخته.
شامل
- سه نود کنترل و گروه‌های جداگانه‌ی نود کاری
- ingress، گواهی TLS و DNS، همه خودکار
- ذخیره‌سازی ماندگار با اسنپ‌شات زمان‌بندی‌شده
- دسترسی بر اساس نقش، بدون حساب ادمین مشترک
kubectl get nodes نود نقش ناحیه وضعیت نسخه cp-1 control-plane zone-a Ready v1.31.4 cp-2 control-plane zone-b Ready v1.31.4 cp-3 control-plane zone-c Ready v1.31.4 worker-1 worker zone-a Ready v1.31.4 worker-2 worker zone-b Ready v1.31.4 worker-3 worker zone-c Ready v1.31.4 - D/۰۲
دسترس‌پذیری بالا
هر بخش مهم دست‌کم دو بار و در ناحیه‌های جدا اجرا می‌شود، تا از دست رفتن یک سرور، یک رک یا حتی یک ناحیه‌ی کامل فقط یک هشدار باشد، نه قطعی. پیش از هر کاری روی هدف‌ها با شما به توافق می‌رسیم: چقدر توقف قابل‌قبول است و از دست دادن چقدر داده را می‌توانید تحمل کنید.
شامل
- سرویس‌های پخش‌شده در چند ناحیه، بدون نقطه‌ی شکست تکی
- تکثیر پایگاه داده با جابه‌جایی خودکار
- بررسی سلامت که نمونه‌های خراب را از چرخه خارج می‌کند
- هدف‌های دسترس‌پذیری که از اول توافق و بعد سنجیده می‌شوند
docs/topology.mmd - D/۰۳
بازیابی از بحران
نسخه‌ی پشتیبانی ارزش دارد که بشود بازیابی‌اش کرد. از داده‌ها و وضعیت کلاستر پشتیبان می‌گیریم، یک نسخه را بیرون از محل نگه می‌داریم و طبق برنامه بازیابی‌اش می‌کنیم و زمان هر قدم را می‌سنجیم. حاصل کار، زمان بازیابی‌ای است که واقعاً سنجیده شده، و فهرست کارهایی که هر جا تمرین لنگ زد باید انجام شود.
شامل
- پشتیبان رمزنگاری‌شده، با نسخه‌ای در یک مکان دوم
- بازیابی پایگاه داده به هر لحظه‌ی دلخواه
- تمرین بازیابی زمان‌بندی‌شده، با ثبت زمان‌ها
- راهنمای قدم‌به‌قدم برای بدترین روز
runbooks/restore-drill.md - وضعیت کلاستر از Velero روی یک کلاستر خالی بازیابی شد۱۴ دقیقه
- PostgreSQL تا ساعت ۹:۴۲، دو دقیقه پیش از خرابی، بازیابی شدRPO ۲ دقیقه
- نسخه‌ی بیرون از محل با کلید بازیابی باز شدتأییدشده
- DNS به ناحیه‌ی پشتیبان منتقل شدقدم دستی
- فایل‌های بارگذاری‌شده در ۳۸ دقیقه بازیابی شدند؛ هدف ۳۰ دقیقه بودبیش از هدف
- D/۰۴
پایپ‌لاین CI/CD
هر تغییر از یک مسیر ثابت می‌گذرد: تست، ساخت کانتینر، اسکن امنیتی و بعد انتشار مرحله‌ای که اگر خطاها بالا بروند خودش متوقف می‌شود. استقرار کاری روزمره می‌شود و برگشتن فقط یک فرمان است.
شامل
- تست و ساخت ایمیج برای هر merge request
- اسکن ایمیج پیش از رسیدن به محیط عملیاتی
- انتشار مرحله‌ای با Argo CD، با بازگشت خودکار
- محیط‌های جداگانه برای staging و production
pipeline #1842 · main $ git push origin main
✓ test go test ./... 212 passed 48s
✓ build registry.example.com/booking:3f9c2a1
✓ scan trivy: 0 critical, 0 high
✓ deploy staging · rollout complete 1m12s
✓ canary production 10% · errors 0.02%
✓ promote production 100% · argocd synced
- D/۰۵
پایش و هشدار
متریک‌ها و لاگ‌ها را یک‌جا جمع می‌کنیم و از آن‌ها داشبورد و فهرست کوتاهی از هشدارهای مهم می‌سازیم. هر هشدار می‌گوید چه چیزی خراب شده، مسئولش کیست و راهنمای اجرا کجاست، تا کسی که نیمه‌شب بیدارش کرده‌اند به‌جای حدس زدن دست به کار شود.
شامل
- متریک‌های Prometheus و داشبوردهای Grafana برای هر سرویس
- لاگ متمرکز در Loki، قابل جست‌وجو بر اساس درخواست
- هشدارهای دسته‌بندی‌شده بر اساس شدت و مسئول، با پیوند به راهنما
- هدف‌های سطح سرویس با بودجه‌ی خطا
grafana · booking · SLO دسترس‌پذیری · ۳۰ روز
۹۹٫۹۷٪
هدف ۹۹٫۹٪
تأخیر p95
۱۸۴ ms
زیر ۳۰۰ ms
بودجه‌ی خطای باقی‌مانده
۷۰٪
۱۳ از ۴۳ دقیقه مصرف‌شده
هشدارهای این هفته
۳
همه رسیدگی‌شده
- D/۰۶
زیرساخت به‌صورت کد
سرورها، شبکه‌ها، کلاسترها و اپلیکیشن‌های رویشان در یک مخزن تعریف می‌شوند و ابزارها اعمالشان می‌کنند، نه دست آدم. هر محیطی را می‌شود از صفر دوباره ساخت، هر تغییر مثل کد بازبینی می‌شود و هیچ چیز به حافظه‌ی یک نفر وابسته نیست.
شامل
- Terraform برای سرورها، شبکه‌ها و DNS
- چارت‌های Helm و Argo CD برای هر چیزی که در کلاستر اجرا می‌شود
- رازها رمزنگاری‌شده در مخزن، هرگز متن خام
- راهنمایی که یک مهندس تازه‌وارد را از صفر تا استقرار می‌برد
infra/ - infra/
- README.mdاز اینجا شروع کنید
- terraform/
- network.tfزیرشبکه‌ها، فایروال
- cluster.tfنودها، ناحیه‌ها
- dns.tfexample.com
- k8s/
- apps.yamlapp of apps
- values.yamlHelm
- secrets/رمزنگاری‌شده با SOPS
- restore-drill.mdبازیابی
- ۰۱
ارزیابی
چه چیزی کجا اجرا می‌شود، چقدر هزینه دارد و با خرابی هر بخش چه اتفاقی می‌افتد.
- ۰۲
طراحی
توپولوژی، جابه‌جایی خودکار و اهداف بازیابی را پیش از ساخت با شما نهایی می‌کنیم.
- ۰۳
مهاجرت
سرویس‌ها یکی‌یکی منتقل می‌شوند، با راه بازگشت در هر قدم.
- ۰۴
تمرین و تحویل
عمداً خرابش می‌کنیم، ثابت می‌کنیم بازیابی کار می‌کند و راهنماهای اجرا را تحویل می‌دهیم.
بیشتر پروژه‌های زیرساخت، بسته به تعداد سرویس‌هایی که منتقل می‌شوند و جایی که اجرا می‌شوند، شش تا ده هفته طول می‌کشند. هر سرویس تا وقتی به بستر جدید منتقل و بررسی نشده، روی بستر قبلی کار می‌کند.
- هفته‌ی ۱
نقشه‌برداری می‌کنیم: چه چیزی کجا اجرا می‌شود، چقدر هزینه دارد و با خرابی هر بخش چه می‌شود.
- هفته‌ی ۲
توپولوژی، اهداف بازیابی و ترتیب مهاجرت را با تیمتان نهایی می‌کنیم.
- هفته‌ی ۳ و ۴
کلاستر، پایپ‌لاین‌ها و پایش را به شکل کد می‌سازیم، اول در staging.
- هفته‌ی ۵ تا ۸
سرویس‌ها یکی‌یکی منتقل می‌شوند، هر کدام با راه بازگشتی که تست شده.
- هفته‌ی ۹ و ۱۰
تمرین خرابی و تمرین بازیابی، و بعد تحویل راهنماهای اجرا به تیمتان.
زیرساخت به‌صورت کد
مخزنی که همه‌ی سرورها، شبکه‌ها و کلاسترها را می‌سازد، در Git خودتان.
پایپ‌لاین‌ها
پایپ‌لاین‌های ساخت، تست و استقرار که بدون ما هم کار می‌کنند.
راهنماهای اجرا
راهنمای قدم‌به‌قدم برای استقرار، خرابی و بازیابی، آزموده در تمرین.
داشبورد و هشدار
پایشی که به تیمتان می‌گوید چه چیزی خراب است و مسئولش کیست.
اطلاعات ورود و دسترسی‌ها
همه‌ی حساب‌ها، کلیدها و گواهی‌ها به نام شما، و دسترسی ما در پایان کار حذف می‌شود.
یک تمرین پیگیری
سه ماه بعد برمی‌گردیم و یک تمرین بازیابی را با تیمتان اجرا می‌کنیم.
- Kubernetes
- Helm
- Argo CD
- Terraform
- Prometheus
- Grafana
- Loki
- Velero
به Kubernetes نیاز داریم؟
نه همیشه. برای چند سرویس، راه‌اندازی ساده‌تر بهتر است و همین را به شما می‌گوییم.
داخل ایران هم اجرا می‌شود؟
بله. زیرساخت را برای دیتاسنترهای داخلی، میرورهای خصوصی و شبکه‌هایی با اتصال بین‌المللی محدود طراحی می‌کنیم.
به‌روزرسانی‌ها چطور؟
به‌روزرسانی چرخشی و انتشار مرحله‌ای، تا کلاستر و اپلیکیشن‌هایتان بدون توقف به‌روز بمانند.
چقدر طول می‌کشد؟
برای بیشتر زیرساخت‌ها شش تا ده هفته. بررسی زیرساخت فعلی همراه با فهرست اولویت‌بندی‌شده‌ی اصلاحات حدود دو هفته طول می‌کشد.
بعد از تحویل، به شما وابسته می‌مانیم؟
نه. همه‌چیز در مخزن خودتان و مستند است و تیمتان پیش از رفتن ما تمرین‌ها را همراه ما اجرا می‌کند. اگر پشتیبانی مستمر بخواهید، جداگانه در دسترس است.
بگویید چه چیزی می‌سازید.
هر پروژه با یک مشاوره شروع می‌شود: شما ایده و هر چه می‌دانید را می‌آورید و ما از دلش طرحی درمی‌آوریم که بشود رویش ساخت.
رزرو مشاوره