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 نیاز داریم؟
نه همیشه. برای چند سرویس، راهاندازی سادهتر بهتر است و همین را به شما میگوییم.
داخل ایران هم اجرا میشود؟
بله. برای دیتاسنترهای داخلی، آینهها و واقعیتهای اتصال بینالمللی طراحی میکنیم.
بهروزرسانیها چطور؟
بهروزرسانی چرخشی و انتشار مرحلهای، تا کلاستر و اپلیکیشنهایتان بدون توقف بهروز بمانند.
چقدر طول میکشد؟
برای بیشتر زیرساختها شش تا ده هفته. بررسی زیرساخت فعلی همراه با فهرست اولویتبندیشدهی اصلاحات حدود دو هفته طول میکشد.
بعد از تحویل، به شما وابسته میمانیم؟
نه. همهچیز در مخزن خودتان و مستند است و تیمتان پیش از رفتن ما تمرینها را همراه ما اجرا میکند. اگر پشتیبانی ادامهدار بخواهید، آن یک انتخاب جداگانه است.
بگویید چه چیزی میسازید.
هر پروژه با یک جلسهی مشاوره شروع میشود: شما ایده و هر آنچه میدانید را میآورید، ما آن را به طرحی تبدیل میکنیم که بشود رویش ساخت.
رزرو مشاوره