الإيرادات تتوقف بتوقف النظام
إذا كان عملاؤكم يتعاملون عبر برمجيتكم، فكل توقف يعني خسارة مباشرة في الإيرادات — وهذا يضرب بأقسى صورة خلال أوقات الذروة، أي حين يكون الدخل في أعلى مستوياته.
04 كيف نعمل
اليوم الذي يتوقف فيه النظام هو اليوم الذي يُحدث فرقاً.
الأعطال نادراً ما تقع في التوقيت المناسب. الإتاحة هي الفارق بين مشكلة يعالجها مهندسوكم بهدوء، ومشكلة يعلنها عملاؤكم بدلاً منكم.
ابدأ مشروعكالأعطال أمر طبيعي. أما التوقف عن الخدمة فخيار يمكن تفاديه.
الأعطال تقع لا محالة. العتاد يتلف، والشبكات تنقطع، ومزوّدو الخدمات الخارجيون تمر عليهم أيام سيئة، ومسارات في الشيفرة لم يتوقعها أحد تُستدعى في النهاية. مهما بلغت العناية، لا يمكن جعل العطل مستحيلاً — فالإتاحة ليست منع وقوعه، بل تحديد ما يحدث بعده.
في نظام سيئ التصميم، يكفي عطل واحد لإسقاط كل شيء، لأن كل جزء فيه يعتمد على سلامة سائر الأجزاء. أما في نظام جيد التصميم، فالعطل محتوى: الجزء المتضرر يعيد التشغيل أو يُتجاوز، وبقية النظام يواصل خدمة العملاء الذين لا يدركون أصلاً أن خللاً وقع.
النصف الآخر من المعادلة هو المعرفة. كثير من الفرق لا تكتشف توقف نظامها إلا حين يخبرها عميل بذلك. المراقبة والتنبيه منذ اليوم الأول يغيّران هذا الواقع — فالتدهور يُكتشف وهو ما يزال طفيفاً، وتسمعون منّا ونحن بصدد الإصلاح فعلاً.
كيف تعرف أن هذه مشكلتك
كل مشروع يبدأ بمكالمة تحديد نطاق- ↳ علمتم بتوقف الخدمة من أحد عملائكم
- ↳ عطل في مكوّن واحد يسقط النظام بأكمله
- ↳ النشر يستوجب إيقاف الموقع عن العمل
- ↳ لا توجد تنبيهات، أو أن التنبيهات تُهمَل
- ↳ الاستعادة تعتمد على تواجد شخص واحد بعينه
- ↳ لا أحد يعرف كم من الوقت تستغرقه الاستعادة من النسخة الاحتياطية
كيف نحقق ذلك
- إشراف OTP
- عند تعطّل عملية، يعيد المشرف تشغيلها خلال أجزاء من الثانية. وبقية النظام لا تلاحظ ذلك.
- Oban
- المهام الخلفية تُحفظ في Postgres ضمن معاملتكم. أي تعطّل أثناء الدفع يعني إعادة المحاولة، لا ضياع العملية.
- مراقبة من اليوم الأول
- نحن من يبلغكم بأي تراجع في الأداء والإصلاح جارٍ — لا عميل غاضب.
ثمن تجاهل المشكلة
أثر السمعة يبقى بعد انتهاء العطل
الحادثة تدوم ساعة واحدة. أما الانطباع بأن منتجكم غير موثوق فيدوم أطول بكثير، وينتشر عبر قنوات لا سيطرة لكم عليها.
الاستعادة بلا خطة تستغرق وقتاً أطول بكثير
الفرق التي لم تختبر عملية الاستعادة من قبل تكتشف أثناء العطل أن النسخة الاحتياطية ناقصة، أو أن لا أحد يملك بيانات الدخول اللازمة. الارتجال يحوّل الدقائق إلى ساعات.
الأعطال الصامتة هي الأخطر
بلا مراقبة، يمر التدهور دون أن يُلاحَظ حتى يصبح خطيراً. المشكلات التي تتراكم ببطء — قرص يمتلئ تدريجياً، أو تسرّب في مجمّع الاتصالات — تكلفتها زهيدة إن عولجت مبكراً، وباهظة إن تُركت حتى تُسقط النظام.
الأسئلة التي تُطرح علينا
- هل نحتاج إلى نسبة إتاحة 99.99%؟
- شبه مؤكد أنكم لا تحتاجون ذلك، والسعي وراء هذا الرقم مكلف. المهم هو مواءمة الهدف مع طبيعة النشاط: نظام يستقبل مدفوعات على مدار الساعة له متطلبات مختلفة عن أداة داخلية تُستخدم في ساعات العمل فقط. نفضّل أن نحدد الهدف الذي تحتاجونه فعلاً على أن نبيعكم رقماً.
- ماذا يحدث حين يتعطل شيء فعلاً؟
- المكوّنات الخاضعة للإشراف تعيد التشغيل تلقائياً في أجزاء من الثانية، فتُمتَص معظم الأعطال دون أن يلاحظها أحد. أما ما هو أكبر من ذلك، فالتنبيه يصلنا مباشرة — فتسمعون منّا ونحن بصدد الإصلاح، لا من عميل غاضب.
- هل تعني الإتاحة العالية دفع تكلفة بنية تحتية مكررة؟
- ليس بالضرورة. جزء كبير من الصمود يأتي من التصميم لا من العتاد: أعطال محتواة، مهام خلفية آمنة عند إعادة المحاولة، وطبقة تخزين مؤقت أمام تطبيقكم. التكرار يساعد، لكنه ليس الحل الأول ولا الأرخص.
- هل يمكنكم النشر دون إيقاف الموقع؟
- نعم. الإصدارات تُطرح تدريجياً مع بقاء النسخة السابقة تعمل إلى أن تثبت النسخة الجديدة سلامتها، والتراجع عن إصدار عملية اعتيادية لا حالة طارئة. النشر لا ينبغي أبداً أن يستوجب نافذة صيانة.
- كيف تعرفون أن النظام سليم؟
- مقاييس أداء، وسجلّات، وتتبّع للأخطاء، كلها مهيأة منذ البداية، مع تنبيهات على المؤشرات التي تُنذر بمشكلة لا على تلك التي تكتفي بتأكيدها بعد وقوعها. حين يتعطل شيء، يكون السؤال أين — لا هل.
اليوم الذي يتوقف فيه النظام هو اليوم الذي يُحدث فرقاً.
أخبرونا أين تكمن المشكلة. مكالمة قصيرة، وجواب صريح حول ما إذا كنا الفريق المناسب، ونطاق عمل يمكنكم وضع ميزانية له.
ابدأ مشروعك hello@elixiria.ma