ما يحدث حقًا عند تحديث تطبيق يعمل في الإنتاج

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

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

المشكلات الأربع التي لا تختفي أبدًا

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

يوضح الرسم البياني أدناه كيف يتفرع نشر واحد إلى المشكلات الأربع الأساسية وتأثيراتها اللاحقة.

flowchart TD A[نشر إصدار جديد] --> B[توقف عن العمل] A --> C[أخطاء في الإصدار الجديد] A --> D[عدم توافق البيانات] A --> E[فخ التراجع] B --> F[خسارة الإيرادات] B --> G[إحباط المستخدم] C --> H[انهيار تحت الحمل] C --> I[خطأ في الإنتاج] D --> J[فساد البيانات] D --> K[الكود القديم لا يقرأ البيانات الجديدة] E --> L[فقدان البيانات] E --> M[تسوية يدوية]

التوقف عن العمل

المشكلة الأكثر وضوحًا. توقف الإصدار القديم. تبدأ الإصدار الجديد. في الفترة بينهما، لا شيء يعمل. بالنسبة لأداة داخلية يستخدمها خمسة أشخاص، قد تكون ثلاثون ثانية من التوقف مقبولة. بالنسبة لصفحة دفع تعالج آلاف الطلبات في الدقيقة، حتى ثلاث ثوانٍ تعني معاملات مفقودة، ومستخدمين محبطين، وتأثيرًا حقيقيًا على الإيرادات.

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

الأخطاء في الإصدار الجديد

لقد اختبرت الإصدار الجديد. اجتازت بيئة الاختبار. لكن الإنتاج ليس بيئة اختبار. قد يحتوي الكود الجديد على خطأ يظهر فقط تحت أنماط حركة المرور الحقيقية. قد يستهلك ذاكرة أكثر من المتوقع وينهار تحت الحمل. قد يتفاعل مع بيانات الإنتاج بطرق لم تلتقطها أدوات الاختبار الخاصة بك.

تظهر بعض الأخطاء فورًا. يستغرق البعض الآخر ساعات للظهور، وعندها يكون الضرر قد انتشر بالفعل عبر نظامك.

عدم توافق البيانات

هذا هو القاتل الصامت. نادرًا ما تعمل التطبيقات بمفردها. إنها تتصل بقواعد البيانات، وذاكرة التخزين المؤقت، وطوابير الرسائل، والخدمات الأخرى. قد يكتب الإصدار الجديد البيانات بتنسيق مختلف قليلاً، أو يضيف عمودًا، أو يغير كيفية تفسيره لحقل.

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

فخ التراجع

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

هل تحذفها؟ تحتفظ بها بتنسيق لا يستطيع الكود القديم قراءته؟ تحولها مرة أخرى؟ كل خيار له عواقب. التراجع النظيف نادر. معظم عمليات التراجع تتضمن بعض فقدان البيانات، أو بعض التسوية اليدوية، أو بعض فترة من عدم الاتساق.

لماذا هذه المشكلات ليست اختيارية

لا يمكنك القضاء على هذه المشكلات الأربع. كل نشر يقدمها. ما يمكنك التحكم فيه هو مدى تأثيرها على مستخدميك ومدى سرعة تعافيك عندما يحدث خطأ ما.

هنا يأتي دور استراتيجيات النشر. استراتيجية النشر لا تتعلق بأي زر تضغط أو أي أداة تهيئ. إنها تتعلق بإجراء مقايضات مدروسة بين السرعة والأمان والتعقيد. تتعامل الاستراتيجيات المختلفة مع المشكلات الأربع بشكل مختلف.

ما تفعله استراتيجية النشر الجيدة حقًا

تجيب استراتيجية النشر على ثلاثة أسئلة عملية:

  • كيف تجعل الإصدار الجديد متاحًا دون إزالة الإصدار القديم مبكرًا جدًا؟
  • كيف تحد من نطاق الانفجار إذا كان الإصدار الجديد معطلاً؟
  • كيف تعود إلى حالة عمل دون فقدان البيانات أو إفساد نظامك؟

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

فحص واقعي سريع

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

الفرق التي تتجاوز هذا النمط ليس لديها بالضرورة أدوات أفضل أو مهندسين أكثر. لديهم فهم أوضح لأي من المشكلات الأربع هو الأكثر أهمية لتطبيقهم المحدد. نظام الدفع يهتم أكثر بسلامة البيانات. موقع المحتوى يهتم أكثر بوقت التشغيل. التطبيق المحمول يهتم أكثر بقابلية التراجع لأنه لا يمكنك إجبار المستخدمين على التحديث.

قائمة تحقق عملية قبل اختيار استراتيجية

قبل أن تختار استراتيجية نشر، أجب على هذه الأسئلة بصراحة. ستخبرك إجاباتك بالمقايضات التي يجب إجراؤها.

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

الخلاصة

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