الاكتشاف: رسم النظام عبر جدار من المخططاتالتشخيص: قراءة لوحات البيانات لتحديد المشكلةالتصميم: مخططات أولية وواجهات للحلالتسليم: إطلاق المنتج النهائيالتطوير: تحسين مستمر بعد الإطلاقنظام قديم يُنقل إلى منصة جديدة جزءًا بعد جزء
تقييم · استبدال · تشغيل

تحديث المنصات

تحديث لنظام ما زال يدرّ مالًا ولا يمكن إيقافه من أجل إعادة كتابة. نستبدله حدًّا تلو الآخر، والمسار القديم يعمل في الظل حتى يُثبت الجديد نفسه على نفس الحِمل وفي نفس الشهر.

  • يعمل
    طوال العمل
  • حدّ
    تلو الآخر لا كله
  • ظل
    تشغيل قبل التحويل
  • رجوع
    متاح في كل خطوة

قطاعات تثق بنا

ما هو التحديث؟

التحديث هو نقل نظام عامل إلى شيء قابل للصيانة دون توقّف ودون فترة لا يُوثق فيها بأي من الإصدارين. وهي في معظمها مسألة ترتيب: أي حدٍّ نقطع أولًا، وكيف نُثبت البديل على حِمل حقيقي، ومتى يمكن أخيرًا حذف المسار القديم.

تحديث أم إعادة كتابة؟
إعادة الكتابة تطلب من الشركة أن تتوقف عن احتياج التعديلات لعام، وهذا ما لا يوافق عليه أي عمل بصدق.
هل الكود القديم هو المشكلة، أم العملية المحيطة به؟
غالبًا لا. المشكلة أن لا أحد يستطيع تعديله بأمان، وهذه مشكلة اختبار ونشر.

الخلاصة

  • يعمل دائمًا، يبقى النظام في الخدمة طوال العمل كله، دون أي تجميد متّفق عليه.

  • مُثبت في الظل، كل حدٍّ يخدم حِملًا حقيقيًا بصمت قبل أن يُسمح له بالإجابة.

  • رجوع مُجرَّب، لكل خطوة طريق رجوع نُفّذ عن قصد، لا مجرد كتابة على الورق.

  • يُحذف في تاريخ، يُطفأ المسار القديم بخطة مؤرّخة بدل أن يُترك يعمل للأبد.

  • ملكك للتغيير، يستطيع فريقك تعديل النتيجة دون الاتصال بنا، وهذا هو الاختبار الحقيقي.

لماذا التحديث

تركه كما هو يؤجّل الخطر فقط.

كيف تفشل إعادة الكتابة

  • يُتّفق على تجميد، ثم يُخترق بهدوء في الشهر الثاني.

  • يعمل النظامان سنوات لأن لا أحد يثق بأيّهما.

  • الإصدار الجديد يُختبر على بيانات مُختلقة لا حقيقية.

  • التحويل ليلة واحدة، ولا رجوع بعدها.

كيف نستبدل

  • يُختار الحدّ بقيمته، ويُسلَّم في أسابيع.

  • القديم والجديد يعملان معًا على نفس الحِمل الحقيقي.

  • يُقارَن الاثنان يوميًا حتى يتوقّف اختلافهما.

  • الرجوع مُجرَّب، فيصبح التحويل مملًّا.

ماذا نستبدل

تحديث يُسلَّم حدًّا بعد حدّ، والنظام ما زال يعمل.

  • تقييم الحدود

    أين يمكن قطع النظام، وبأي ترتيب، وقيمة كل قطع بعد إتمامه.

  • ترحيل البيانات

    المخطّط والتعبئة الرجعية والمطابقة التي تُثبت توافق المخزنين قبل رحيل القديم.

  • التشغيل في الظل

    المسار الجديد يخدم نفس الطلبات، وتُقارن أجوبته دون إرجاعها بعد.

  • إخراج من الخدمة

    المسار القديم يُطفأ بخطة مؤرّخة، وهذه هي النهاية الحقيقية الوحيدة للعمل.

ثلاثة مسارات

مسار واحد لكل مكوّن، يُختار بالدليل.

  • نقل

    إعادة استضافة

    النظام العامل يُنقل إلى بنية مُدارة، وكوده يُترك كما هو تمامًا.

    أسابيع، أقل خطر
  • الأكثر اختيارًاإعادة تشكيل

    استبدال بالحدّ

    حدٌّ واحد في كل مرة، القديم والجديد يتشاركان الحِمل الحي، ثم يُحذف المسار القديم.

    أشهر، بلا توقّف
  • إعادة بناء

    إعادة كتابة جزء

    فقط حيث يقاوم الكود كل مسار آخر، وفقط جزء صغير بما يكفي لإتمامه.

    نادر، بالاستثناء

المنظومة التي ننتقل إليها

حديثة، مدعومة جيدًا، مملّة عن قصد.

  • TypeScript
  • Node.js
  • PostgreSQL
  • Kubernetes
  • Docker
  • Kafka
  • Terraform
  • GitHub Actions

كيف تسير · طريقتنا

طريقة سياسول بمراحلها الخمس، مطبّقة على هذه الخدمة.

  1. 01

    نكتشف

    معظم المشاريع التقنية بتفشل قبل أول سطر كود بكتير — بتفشل عند السؤال نفسه.

  2. 02

    نشخّص

    كل عملية بطيئة ليها مسؤول وتكلفة.

  3. 03

    نصمّم

    المعمارية قرارات هتعيش معاها.

  4. 04

    نسلّم

    السوفتوير اللي مش في الإنتاج تكلفة بس.

  5. 05

    نطوّر

    التسليم هو الهدف، مش النهاية.

أين نعمل

قريبون حيث يهمّ، وبلغتين في كل مكان

  • مصر: القاهرة (المقر) والتسليم في كل المحافظات

  • السعودية: الرياض، وفرق تعمل بتوقيت العميل

  • الخليج وما بعده: عربي وإنجليزي، ومعيار تسليم واحد

التكلفة والتعاون

التحديث: التكلفة وشكل التعاون

التكلفة تتبع عدد الحدود وحجم البيانات التي يجب نقلها. نسعّر التقييم وحده، لأن أي رقم قبل الخريطة تخمين.

  • ثابت · أسبوعان إلى ثلاثة

    تقييم الحدود

    خريطة حدود القطع مرتّبة، ومعها رقم لكل حدّ.

  • بالحدّ · يُسعّر من الخريطة

    تسليم الحدود

    حدٌّ واحد يُستبدل ويُثبت في الظل، ويُؤرّخ حذف القديم.

  • شهري · مخصّص

    فريق مدمج

    فريق دائم يعمل على الخريطة إلى جانب فريقك.

لماذا يأتوننا بالنظام الذي لا يريد أحد لمسه.

لأننا مستعدّون لترك معظمه كما هو. فالمطلوب جعل النظام قابلًا للتغيير لا جعله ملكنا، فيسمّي التقييم الحدود الجديرة بالقطع ويقول أي الأجزاء ينبغي أن تبقى. ومن أبقوه يعمل هم دليلنا الرئيسي، ويبقون مالكيه حين نغادر.

FAQ

ما تسأله الفرق قبل البدء في تحديث المنصات.

01نستمر في تسليم الميزات أثناء ذلك؟

نعم، والخطة تفترض ذلك. فأي ترتيب يحتاج تجميد الميزات يُترك في الشهر الثاني، لذا يُحدّد كل حدٍّ ليترك بقية النظام سليمة وقابلة للإصدار أثناء استبداله.

02ما معنى التشغيل في الظل فعلًا؟

يستقبل المسار الجديد نسخة من الطلبات الحقيقية ويحسب جوابه، فيُسجَّل ويُقارن بالجواب الحي دون إرجاعه. وتُفحص الفروق يوميًا حتى لا يبقى فرق؛ وعندها فقط يبدأ الخدمة.

03متى نرى شيئًا؟

يستغرق التقييم أسبوعين إلى ثلاثة وينتهي بخريطة تستطيع العمل بها دوننا. وأول حدٍّ يُسلَّم عادةً بعد أربعة إلى ستة أسابيع، مبكّرًا عن قصد: فخطة نتيجتها الأولى بعد أشهر لا يمكن تصحيحها في وقتها.

04وإن قال التقييم ألّا نحدّث؟

فليقل ذلك، وهذا تقييم ناجح. فبعض الأنظمة مستقرة ومفهومة وقليلة التغيير، والجواب الصادق أن يُصرف المال في مكان آخر. وهذه النتيجة أرخص من اكتشافها في الشهر الثامن.

05هل تعملون مع فريقنا الحالي؟

نعم، ومعرفتهم هي المدخل الأساسي. فمن صانوا النظام يعرفون أين يقاوم التغيير، وهو بالضبط ما يبحث عنه التقييم. واستبدالهم بنا يرمي أفضل دليل متاح.

06هل يُطفأ النظام القديم تمامًا؟

هذا هو تعريف الإنجاز، ويُكتب في الخطة بتاريخ لا كطموح. فتحديثٌ ينتهي والنظامان يعملان لم ينتهِ؛ بل أنتج نظامًا ثانيًا يُصان.

07من يملك النتيجة عند رحيلكم؟

أنت، والتسليم مستند مؤرّخ وجولة شرح. الحسابات السحابية والمستودعات وأدلة التشغيل ومسار المناوبة باسمك من الحدّ الأول، لا تُنقل في النهاية كإجراء شكلي.

خدمات ذات صلة

كثيرًا ما تُقترن بهذه

اعرف أكثر

من المدوّنة

جاهز لاستبدال النظام دون إيقافه أبدًا؟

أخبرنا بما يفعله النظام اليوم ومن يعتمد عليه. نعود بخريطة حدود وترتيب عمل ورقم.

احجز تقييمًا