CShark عرض توضيحي
القائمة

وثائق شارك

وصف لعمليات صيانة دورة حياة برنامج CShark

الإجراء الخاص بتطوير CShark وتقديمه وصيانته واستكشاف الأخطاء وإصلاحها وتحسينه.

الإصدار 2.0.3

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

خيارات لمثيل CShark المقدم
البارامترات البارامترةمعنى
إصدار الإصدار2.0.3
التزام المصدر الكامل399717d1ed4c0e83e00150912a2a029eaec5c736
قناة التوريدstable
متغير المثيلdemo
اسم المجموعة الكاملةcshark-2.0.3-demo-ubuntu-24.04-amd64-offline.tar
SHA-256 مجموعة كاملةccb36a121bf8e1b756f1190f9369e490585082417829458b9bc62108620850c6
SHA-256 المفتاح العام0908f56ddcd6cd13fe95d81faae6543b9c5953937b164fb2c487eb00a5b8921d

1. الغرض من الوثيقة

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

1.1. التفاصيل التنظيمية

المعلومات التنظيمية حول صيانة CShark
البارامترات البارامترةمعنى
المنظمةجمعية ذات مسؤولية محدودة ‏"كومبيتينسيا"‏
عنوان تطوير البنية التحتية115280، موسكو، ش. لينينسكايا سلوبودا، 21 عاما، مبنى 1
عنوان مكان عمل المطور115280، موسكو، ش. لينينسكايا سلوبودا، 21 عاما، مبنى 1
عنوان الدعم الفني115280، موسكو، ش. لينينسكايا سلوبودا، 21 عاما، مبنى 1
ساعات عمل خدمة الدعم الفنيالاثنين - الجمعة، 09:00 - 18:00 بتوقيت موسكو
رقم هاتف الدعم الفني+7 495 532-61-18
مسؤول عن الدعمجمعية ذات مسؤولية محدودة ‏"كومبيتينسيا"‏

يتم تنفيذ وظائف التطوير والاختبار وDevOps وإدارة النظام، بالإضافة إلى الدعم الفني من قبل متخصصين من شركة COMPETENCE LLC. يتم أخذ مجموعة الوظائف في الاعتبار عند تخطيط العمل وفصل عمليات التطوير والتحقق والإصدار في الوقت المناسب.

2. مراحل دورة الحياة

دورة الحياة تشمل:

  1. جمع وتحليل المتطلبات؛
  2. تغيير التصميم؛
  3. تطوير الكود ومراجعته؛
  4. توليد الإصدار؛
  5. تجميع ومراقبة مجموعة التسليم؛
  6. التثبيت أو التحديث؛
  7. المراقبة التشغيلية؛
  8. معالجة الطلبات والعيوب؛
  9. الافراج عن الإصلاحات والتحسينات.
  10. وقف دعم الإصدار والهجرة.

يجب أن يكون لكل تغيير معرف، ووصف للغرض منه، ومعايير القبول، ورابط لنسخة التسليم.

3. المتطلبات وإدارة التغيير

تشمل مصادر المتطلبات الالتزامات التعاقدية والطلبات التشغيلية ومتطلبات السلامة ونتائج الاختبار وخطة المنتج.

التغيير قبل التنفيذ:

  • توصف بأنها نتيجة محددة قابلة للاختبار؛
  • مصنفة حسب الأولوية والمخاطر؛
  • تم اختبار توافقه مع البيانات وعمليات التكامل الحالية؛
  • يتلقى معايير القبول؛
  • المدرجة في خطة الإصدار.

4. التنمية

يتم تخزين كود المصدر في نظام التحكم في الإصدار. يتم التطوير في تغييرات معزولة مع التحليل الإلزامي للمكونات المتضررة.

للتغييرات استخدم:

  • التحليل والتنسيق الثابت؛
  • اختبارات الوحدة؛
  • اختبارات التكامل مع PostgreSQL وNATS الحقيقيين؛
  • واجهة برمجة تطبيقات العقد واختبارات الأحداث؛
  • التحقق من عمليات ترحيل قاعدة البيانات؛
  • اختبارات الواجهة؛
  • سيناريوهات النسخ الاحتياطي والاسترداد؛
  • التحقق من مجموعة التثبيت.

لا يعتبر التغيير كاملاً بمجرد تشغيله محليًا؛ مطلوب الشيكات القابلة للتكرار لتتناسب مع مخاطرها.

5. مراقبة الجودة

قبل إطلاق الإصدار، يتم تنفيذ ما يلي:

  1. التحقق من مجموعة كاملة من الاختبارات الآلية؛
  2. التحقق من تجميع صور الحاوية؛
  3. التحقق من OpenAPI والعميل الذي تم إنشاؤه؛
  4. المسح بحثًا عن التسريبات السرية؛
  5. التحقق من عمليات الترحيل على قاعدة بيانات نظيفة وموجودة؛
  6. اختبار سريع للمثيل الذي تم نشره؛
  7. الفحص البصري لنصوص المستخدم المعدلة؛
  8. التحقق من أرشيف التسليم والمجاميع الاختبارية؛
  9. تحديث الوثائق.

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

6. مجموعة الإصدار والتسليم

روابط النسخة:

  • معرف كود المصدر؛
  • إصدارات صور الحاوية؛
  • مراجعة مخطط قاعدة البيانات؛
  • بيان الأرشيف؛
  • المجاميع الاختبارية؛
  • المثبت.
  • الوثائق وقائمة التغييرات.

بالنسبة للحلقة المغلقة، يتم إنشاء مجموعة غير متصلة بالإنترنت باستخدام صور Docker المحلية وتبعيات APT. تم اختبار المجموعة على Ubuntu Server 24.04 LTS AMD64 النظيف دون الوصول إلى المستودعات الخارجية.

7. التسليم والتركيب

يتم التسليم من خلال خادم آمن أو عن طريق نقل أرشيف غير متصل بالإنترنت. يتم فحص SHA-256 قبل التفريغ. يقوم المثبت بإعادة التحقق من صحة البيان الداخلي، وتثبيت التبعيات، وتطبيق عمليات الترحيل، وإجراء اختبار سريع.

يتم حفظ نتائج التثبيت والسجلات لأغراض التشخيص. في حالة حدوث خطأ، تتوقف الحاويات ولا يتم حذف البيانات تلقائيًا.

8. تحديث النظام

عملية التحديث الحالية هي عملية إدارية خاضعة للرقابة:

  1. الالتزام بالنسخة المثبتة؛
  2. التحقق من المساحة الحرة وحالة النظام؛
  3. إنشاء نسخة احتياطية والتحقق منها؛
  4. الحصول على مجموعة محددة من الإصدار الجديد؛
  5. التحقق من المجاميع الاختبارية وملاحظات الإصدار؛
  6. التحقق من توافق مخطط البيانات؛
  7. تطبيق عمليات الترحيل في خطوة منفصلة؛
  8. تبديل الحاويات إلى إصدار جديد؛
  9. إجراء فحص الصحة واختبار الدخان؛
  10. سجل نتيجة التحديث.

يعد التحديث التلقائي من واجهة المستخدم ميزة واعدة. قبل إصداره، يتم إجراء التحديث بواسطة مسؤول النظام وفقًا للتعليمات المعتمدة.

9. إدارة الهجرات والتراجعات

يعمل Core فقط مع مخطط قاعدة بيانات متوافق. إذا كان المخطط خلف إصدار التطبيق، فسيتم حظر بدء التشغيل حتى يتم تطبيق عمليات الترحيل.

قبل التحديث، يتم تحديد إمكانية التراجع القابل للعكس. بالنسبة للتغييرات الضيقة (عمليات الترحيل المتوافقة)، قد يتم تشغيل الإصدار السابق مؤقتًا على المخطط الجديد. بالنسبة للتغيير غير المتوافق، يتم تنفيذ التراجع فقط باستخدام خطة منفصلة، ​​واستعادة نسخة احتياطية تم التحقق منها.

10. مراقبة العمليات

تتم مراقبة حالة النظام من خلال:

  • /api/health;
  • حالات الحاوية؛
  • مقاييس النشر ومعالجة الأحداث؛
  • عمق قائمة انتظار البوابة؛
  • دولة ناتس؛
  • توفر PostgreSQL وS3؛
  • المجلات الأساسية والبوابة والبنية التحتية؛
  • مساحة حرة على القرص؛
  • حالة الجهاز.

يتم تعيين قيم الحد الأدنى وتوجيه التنبيه في اللوائح التشغيلية لمنشأة معينة.

11. تسجيل الطلبات وتصنيفها

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

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

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

12. استكشاف الأخطاء وإصلاحها

تتضمن عملية الإزالة ما يلي:

  1. تسجيل الاستئناف؛
  2. حفظ الحالة الأصلية والسجلات؛
  3. تصنيف التأثير؛
  4. التشغيل على حامل آمن؛
  5. توطين السبب.
  6. إعداد الإصلاح؛
  7. اختبارات الانحدار؛
  8. إصدار نسخة منقحة؛
  9. التثبيت وفقا لنافذة متفق عليها؛
  10. تأكيد النتيجة من قبل المستخدم.
  11. تحديث قاعدة المعرفة.

يُسمح بإجراء تغييرات يدوية على البيانات فقط وفقًا لإجراء متفق عليه مع نسخة احتياطية وسجل الأوامر والتحقق اللاحق.

13. النسخ الاحتياطي والاستعادة

تشتمل بيانات الأعمال على قاعدة بيانات PostgreSQL ووسائط في وحدة تخزين متوافقة مع S3.

الجدول الزمني الأساسي الموصى به:

  • قاعدة البيانات - يوميا؛
  • نسخة كاملة من الوسائط - أسبوعية؛
  • استعادة الاختبار - بعد تغيير الإجراء وبشكل دوري وفقًا للوائح التشغيل.

تعتبر النسخة متحقق منها فقط بعد استعادتها إلى بيئة مؤقتة والتحقق من عدادات التحكم. تم التحقق من الوسائط وفقًا لـ SHA-256 وملخص البيان النهائي.

14. إدارة الأمن

تتضمن عملية الدعم ما يلي:

  • تحديث الصور الأساسية والتبعيات؛
  • تحليل الضعف؛
  • تناوب الأسرار.
  • التحقق من حقوق المستخدم؛
  • تدقيق الإجراءات الإدارية؛
  • التحكم في فترات تخزين البيانات؛
  • استبعاد الأسرار والبيانات الشخصية من التقارير العامة؛
  • توثيق التصحيحات الأمنية.

قد يتم إصدار التحديثات الأمنية الهامة خارج الدورة المجدولة.

15. تحسينات البرمجيات

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

تشمل مجالات التطوير المستقبلية التحديثات الآلية، وتطوير قوالب الشاشة الرئيسية، وعمليات التكامل الإضافية، والبنية التحتية للشحن والوحدات التجارية. ولا تعتبر من ميزات الإصدار الحالي حتى إصدار منفصل.

16. التوثيق

عندما يتغير السلوك، يتم تحديث ما يلي:

  • تعليمات التثبيت
  • وصف الخصائص الوظيفية؛
  • دليل التعليمات
  • دليل التشغيل للمسؤولين؛
  • OpenAPI وعقود الأحداث؛
  • ملاحظات الإصدار؛
  • تعليمات النسخ الاحتياطي والاستعادة.

تقوم الوثائق بتخزين التاريخ الحالي ومعرف الإصدار الذي يشير إليه.

17. الموظفين المطلوبين للمرافقة

أدوار وكفاءات ومهام موظفي الدعم
الدورالكفاءات الأساسيةالمهام النموذجية
مسؤول النظامUbuntu، وDocker Compose، والشبكة، وTLS، والنسخ الاحتياطيةالتثبيت والتحديث والمراقبة والاسترداد
مدير CSharkالأدوار والطوبولوجيا والأجهزة والإعداداتالتكوين ودعم المستخدم
أخصائي الدعمتشخيصات الويب/واجهة برمجة التطبيقات (API)، وجمع السجلات، والاتصالاتالتسجيل والمعالجة الأولية للطلبات
مطور الواجهة الخلفيةبايثون، FastAPI، PostgreSQL، NATS، الهجراتإصلاح منطق الأعمال والتكامل
مطور الواجهة الأماميةTypeScript، React، واجهات الويبتصحيح وتطوير البرامج النصية للمستخدم
مهندس الجودةتصميم الاختبار وواجهة برمجة التطبيقات/واجهة المستخدم وعمليات التحقق من الانحدارتأكيد الإصلاحات والإصدارات
مهندس ديف أوبسCI/CD، الصور، إمكانية الملاحظة، سلسلة التوريدالتجميع واستنساخ التسليم
أخصائي أمن المعلوماتإدارة الثغرات الأمنية، والتدقيق، وحماية البياناتتقييم المخاطر ومراقبة التدابير الوقائية
محلل أو مالك المنتجالمتطلبات والقبولتحديد الأولويات والسيطرة على النتائج

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

18. إهمال الإصدار

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