مرحبا يا هبر! اسمي رومان ، وأريد أن أتحدث اليوم عن كيفية قيامنا في جامعة إنوبوليس بتطوير مقعد اختبار وخدمة لنظام Acronis Active Restore ، الذي سيصبح قريبًا جزءًا من خط منتجات الشركة. كل من يهتم بكيفية قيام الجامعة ببناء علاقات مع شركاء صناعيين ، أدعوكم إلى المضي قُدُماً.
بدأ تطوير Active Restore داخل Acronis ، لكننا ، بوصفنا طلابًا من جامعة Innopolis ، شاركنا في هذه العملية كجزء من مشروع تدريب صناعي. قام المنسق الخاص بي (وزميلي الآن) دولت تومبايف بكتابة مقال عن الفكرة ، وكذلك الهندسة المعمارية ،
في منصبه . سأتحدث اليوم عن كيفية تحضير الخدمة من Innopolis.
بدأ كل شيء في الصيف ، عندما علمنا أنه في الفصل الأول ، ستأتي إلينا شركات تكنولوجيا المعلومات وتقدم أفكارها للعمل العملي. وهكذا ، في كانون الأول (ديسمبر) 2018 ، قدّمنا 15 مشروعًا مختلفًا ، وفي نهاية الشهر وضعنا الأولويات ، اكتشفنا من هو الأفضل.
قام جميع الطلاب الجامعيين بملء نموذج حيث كان من الضروري اختيار أربعة مشاريع أردنا المشاركة فيها. كان من الضروري تحفيز لماذا أنا ولماذا بالضبط هذه المشاريع. على سبيل المثال ، أشرت إلى أن لدي بالفعل خبرة في برمجة النظام وتطويره في C / C ++. لكن الأهم من ذلك أن المشروع سمح لي بتطوير مهاراتي ومواصلة النمو.
بعد أسبوعين ، تم تكليفنا ، ومنذ بداية الفصل الدراسي الثاني ، بدأ العمل في المشروعات. تم تشكيل الفريق ، في الاجتماع الأول قمنا بتقييم نقاط القوة والضعف لبعضنا البعض وأدوارنا المعينة.
- رومان ريبكين هو مطور بيثون / سي + +.
- يوجين إيشوتين - مطور بيثون / سي + + ، مسؤول عن التفاعل مع الشركة.
- أناستازيا روديونوفا هي مطورة بيثون / سي + + المسؤولة عن كتابة الوثائق.
- براندون أكوستا - إعداد البيئة ، وإعداد منصة للتجارب والاختبار.
في الأسبوعين الأولين كان علينا أن نبدأ العملية. أنشأنا اتصالات مع العميل ، وصممنا متطلبات المشروع بشكل رسمي ، وأطلقنا عملية تكرارية ، ونهيئ بيئة العمل.
بالمناسبة ، بدأ عملنا مع الزبون في الغليان عندما بدأنا الاختيارية. والحقيقة هي أن أكرونيس يؤدي في جامعة إنوبوليس (وليس فقط) الموضوعات المختارة. ويقوم أليكسي كوستيوشكو ، المطور الرئيسي لفريق Kernel ، بتدريس دورتين على أساس مستمر: الهندسة العكسية و Windows Kernel Architecture and Drivers. بقدر ما أعرف ، يتم التخطيط أيضًا لدورة حول برمجة النظام والحوسبة متعددة الخيوط في المستقبل. ولكن الشيء الرئيسي هو أن جميع هذه الدورات مصممة بطريقة تساعد الطلاب على التعامل مع المشاريع الصناعية. إنهم يضخون بجدية في فهم مجال الموضوع وبالتالي يبسطون العمل في المشروع.
نتيجة لهذا ، بدأنا بقوة أكثر من الفرق الأخرى ، وأصبح التفاعل مع أكرونيس نفسه أكثر كثافة. لقد تصرف Alexey Kostyushko بالنسبة لنا في دور مالك المنتج ، وقد تلقينا منه المعرفة اللازمة في مجال الموضوع. بفضل خياراته الاختيارية ، تم ضخ مهاراتنا وكفاءاتنا القوية بقوة ، وأصبحنا مستعدين حقًا لإنجاز المهمة التي واجهتنا.
من الفكر إلى المشروع
كان الشهر الأول لجميع الفرق صعبا قدر الإمكان. فقد الجميع ، ولم يعرف من أين يبدأ - ربما بالوثائق أو ، على العكس ، الغوص في الشفرة. في البداية ، جاءت تعليقات متضاربة من القيمين والموجهين في الجامعة وممثلي الشركة.
عندما وقع كل شيء في مكانه (على الأقل في رأسي) ، أصبح من الواضح أن الموجهين من الجامعة ساعدونا في بناء علاقات داخلية في الفريق وإعداد الوثائق. لكن نقطة الاختراق الحقيقية كانت وصول دولت في شهر مارس. جلسنا فقط وعملنا في المشروع طوال عطلة نهاية الأسبوع. ثم نعيد التفكير في جوهر المشروع ، ونعيد تشغيله ، وأعدنا توزيع أولويات المهام وسرعان ما تقدمنا إلى الأمام. لقد فهمنا ما يجب القيام به لبدء التجربة (حولها لاحقًا) وتطوير الخدمة. منذ تلك اللحظة ، تحولت الفكرة العامة إلى خطة واضحة. بدأ التطوير الحقيقي للرمز ، وخلال أسبوعين قمنا بتطوير الإصدار الأول من منصة الاختبار ، بما في ذلك الأجهزة الافتراضية والخدمات الضرورية والرمز لأتمتة التجربة وجمع البيانات.
تجدر الإشارة إلى أنه بالتوازي مع المشروع الصناعي ، كانت هناك دورات تدريبية ساعدتنا في بناء بنية كفؤة لمشاريعنا وتنظيم إدارة الجودة. في البداية ، استغرقت هذه المهام 70-90 ٪ من الوقت في الأسبوع ، ولكن ، كما اتضح ، كان هناك حاجة إلى وقت لتجنب المشاكل في عملية التطوير. كان هدف الجامعة هو أن نتعلم بناء عملية التطوير بكفاءة ، وكانت الشركات ، كزبائن ، أكثر اهتمامًا بالنتيجة. هذا ، بالطبع ، أثار الكثير من الالتباس ، لكنه ساعد على الجمع بين المهارات النظرية والعملية. كفل التعقيد والحمل وجود الحافز ، مما أدى إلى نجاح المشروع.
في البداية ، شارك شخصان في فريقنا في تطوير محض ، وتولى شخص ما المستندات ، وانخرط شخص آخر في تهيئة البيئة. ومع ذلك ، انضم إلينا في وقت لاحق ثلاثة من العزاب الآخرين ، وأصبحنا فريقًا واحدًا. قررت الجامعة إطلاق مشروع اختبار صناعي لطلاب السنة الثالثة من الدراسة. أدى توسيع الفريق من 4 إلى 7 أشخاص إلى تسريع العملية إلى حد كبير ، لأن العزاب يمكنهم بسهولة أداء المهام المتعلقة بالتطوير. ساعدت Ekaterina Levchenko في كتابة شفرة الثعبان والنصوص دفعة لمقعد الاختبار. قام كل من Ansat Abirov و Ruslan Kim بدور المطورين ، حيث شاركا في اختيار الخوارزميات وتحسينها.
لقد عملنا بهذا التنسيق حتى نهاية مايو ، عندما تم إطلاق التجربة. في هذه اللحظة ، انتهى المشروع الصناعي للبكالوريوس. اثنان منهم بدأت التدريب أكرونيس واستمرت في العمل معنا. لذلك ، بعد مايو ، عملنا بالفعل كفريق واحد من 6 أشخاص.
قبلنا كان الفصل الدراسي الثالث ، والذي في Innopolis خالٍ من الأنشطة الأكاديمية. كان لدينا فقط 2 الاختيارية ، وقضى بقية الوقت في مشروع صناعي. كان في الفصل الدراسي الثالث أن العمل على الخدمة ذهب بشكل مكثف. سقطت عملية التطوير بالكامل على القضبان ، وأصبحت العروض والتقارير منتظمة. في هذا التنسيق ، عملنا لمدة 1.5 شهرًا ، وفي نهاية يوليو / تموز ، انتهينا تقريبًا من جزء التطوير من العمل.
التفاصيل الفنية
أولاً ، تمت صياغة متطلبات الخدمة ، والتي يجب أن تتفاعل بشكل مناسب مع برنامج تشغيل minifilter لنظام الملفات (وهو ما يمكنك قراءته
هنا ) وتم التفكير في بنيتها. مع التركيز على بساطة دعم الكود الإضافي ، قدمنا على الفور مقاربة معيارية. تشمل خدمتنا العديد من المديرين والوكلاء والمعالجات ، وحتى قبل بدء الترميز ، تم وضع القدرة على العمل في الوضع الموازي.
ومع ذلك ، بعد مناقشة الهندسة المعمارية في اجتماع مع شباب Acronis ، فقد تقرر إجراء تجربة أولاً ، ثم تولي الخدمة بنفسها. نتيجة لذلك ، استغرق التطوير 2.5 شهر فقط. باقي الوقت ، أجرينا تجربة للعثور على الحد الأدنى من قائمة الملفات التي يمكن تشغيل Windows عليها. في نظام حقيقي ، يتم إنشاء هذه المجموعة من الملفات باستخدام برنامج التشغيل ، ومع ذلك ، فقد قررنا العثور على هذه المجموعة بشكل استرشادي ، باستخدام طريقة تقسيم النصف ، للتحقق من تشغيل برنامج التشغيل.
موقف التجربة.
للقيام بذلك ، قمنا بوضع موقف في Python من جهازين ظاهريين. واحد منهم يعمل على لينكس ، والثاني تحميل ويندوز. تم تكوين قرصين لهما: Virtual HD1 و Virtual HD2. تم توصيل كلا محركي الأقراص بـ VM1 الذي تم تثبيت Linux عليه. على هذا الجهاز الظاهري على HD1 ، تم تثبيت تطبيق Killer ، والذي "تلف" HD2. يشير التلف إلى حذف بعض الملفات من القرص. كان HD2 عبارة عن قرص تمهيد لـ VM2 يعمل تحت Windows. بعد "تلف" القرص ، حاولنا بدء تشغيل VM2. إذا كان من الممكن القيام بذلك ، فإن الملفات المحذوفة من القرص تعتبر غير ضرورية للتشغيل.
من أجل أتمتة هذه العملية ، حاولنا حذف الملفات بشكل عشوائي ، ولكن كجزء من نهج تم التفكير فيه مسبقًا. تتكون الخوارزمية من 3 خطوات:
- قسّم قائمة الملفات إلى نصفين.
- حذف واحد من نصف الملفات.
- محاولة لبدء النظام. إذا بدأ النظام ، فقم بإضافة الملفات المحذوفة إلى قائمة غير الضرورية. خلاف ذلك ، نعود إلى الخطوة 1.
أولاً ، قررنا محاكاة الخوارزمية. افترض أن هناك 1،000،000 ملف في نظام الملفات. في هذه الحالة ، حدث البحث الأكثر فاعلية عن الملفات الهامة في الحالات التي كانت فيها الملفات الهامة حوالي 15٪ من الإجمالي.
طريقة تقسيم النصف.في البداية ، كانت هناك الكثير من المشاكل في التجربة. لمدة 2-3 أسابيع ، كان موقف الاختبار جاهزًا. و1.5 شهرًا أخرى اضطررت إلى اصطياد الأخطاء ، وإضافة الرمز وتطبيق الحيل المختلفة لجعل الحامل يعمل.
كان أصعب شيء هو اكتشاف خطأ مرتبط بعمليات تخزين القرص المؤقت. نجحت التجربة لمدة يومين وأسفرت عن نتائج متفائلة للغاية كانت أسرع بعدة مرات من المحاكاة. ومع ذلك ، فشل اختبار الملف الحرج ، لم يبدأ النظام. اتضح أنه أثناء الإغلاق القسري للجهاز الظاهري ، لم يتم تنفيذ عمليات الحذف التي تم تخزينها مؤقتًا بواسطة نظام الملفات ، وبالتالي لم يتم مسح القرص بالكامل. نتيجةً لذلك ، حصلت الخوارزمية على نتائج غير صحيحة ، وقمنا بتوتر جميع أيامنا لبضعة أيام لمعرفة كل ذلك.
في مرحلة معينة ، لاحظنا أنه أثناء التشغيل المستمر ، تم دفن الخوارزمية في أحد أجزاء نظام الملفات وبدأت في محاولة حذف الملفات نفسها (على أمل الحصول على نتيجة جديدة). حدث هذا في بعض الأحيان عندما استقرت الخوارزمية في المناطق التي كان معظمها ضروريًا ، أثناء اختيار الفاصل الزمني الخاطئ للحذف. في هذه المرحلة ، قررنا إضافة قائمة ملفات التعديل. وهذا هو ، مرة واحدة تكرارات قليلة ، تم خلط قائمة الملفات. وقد ساعد ذلك في إخراج الخوارزمية من هذه العصي.
عندما كان كل شيء جاهزًا ، أطلقنا هاتين VMs لمدة 3 أيام. في المجموع ، مرت حوالي 600 عملية تكرار ، من بينها أكثر من 20 عملية إطلاق ناجحة. أصبح من الواضح أنه يمكن تشغيل هذه التجربة لفترة طويلة ، وكذلك على أجهزة أكثر قوة ، للعثور على حجم الملف الأمثل لتشغيل Windows. أيضًا ، يمكن توزيع الخوارزمية عبر العديد من الأجهزة لزيادة تسريع هذه العملية
في حالتنا ، بالإضافة إلى Windows ، لم يكن هناك سوى Python وخدمتنا على القرص. في ثلاثة أيام تمكنا من تقليل عدد الملفات من 70 ألف إلى 50 ألف. تم تخفيض قائمة الملفات بنسبة 28٪ فقط ، ولكن أصبح من الواضح أن هذه الطريقة تعمل ، وتتيح لك تحديد الحد الأدنى من الملفات المطلوبة لتحميل نظام التشغيل.
هيكل الخدمة
دعونا نتطرق إلى هيكل الخدمة قليلاً. وحدة الخدمة الرئيسية هي مدير قائمة الانتظار. نظرًا لأننا نحصل على قائمة بالملفات من برنامج التشغيل ، نحتاج إلى استعادة الملفات من هذه القائمة. للقيام بذلك ، أنشأنا منعطف مع الأولويات.
لدينا قائمة من الملفات التي يتم استعادتها بدورها. وفي حالة ظهور طلبات وصول جديدة ، تتم استعادة الملفات المطلوبة بشكل عاجل في الأولوية. بفضل هذا ، في بداية قائمة الانتظار ، ستكون هناك تلك الملفات التي يحتاجها المستخدم الآن ، وفي نهاية قائمة الانتظار ستكون تلك الملفات التي قد تكون مطلوبة في المستقبل. ولكن مع العمل النشط للمستخدم ، يمكن تشكيل "قائمة انتظار للكائنات غير العادية" ، وكذلك قائمة من الملفات التي يتم استعادتها الآن. بالإضافة إلى ذلك ، يجب أن يتم تطبيق عملية البحث على كل قوائم الانتظار هذه دفعة واحدة. للأسف ، لم نعثر على مثل هذا التنفيذ لقائمة الانتظار التي يمكن أن تحدد عدة أولويات للملفات ، أثناء دعم البحث ، بالإضافة إلى تغيير الأولويات سريعًا. لم نكن نرغب في التكيف مع هياكل البيانات الحالية ، وبالتالي كان علينا أن نكتب هياكلنا الخاصة وأن نهيئ القدرة على العمل معها.
ستحتاج خدمتنا إلى التواصل أولاً مع برنامج التشغيل الذي عملت عليه Daulet ، وبعد ذلك بالمكونات المسؤولة عن استعادة الملفات ... لذلك ، بالنسبة للمبتدئين ، قررنا إنشاء محاكي صغير خاص بنا لنظام الاسترداد ، والذي يمكنه إصدار ملفات من محرك أقراص خارجي حتى يتمكنوا من استعادة واختبار الخدمة.
في المجموع ، تم توفير وضعي التشغيل - الوضع العادي ووضع الاسترداد. في الوضع العادي ، يرسل برنامج التشغيل إلينا قائمة بالملفات المتأثرة ببدء تشغيل نظام التشغيل. بعد ذلك ، أثناء تشغيل النظام ، يراقب برنامج التشغيل جميع عمليات الملفات ويرسل إشعارات إلى خدمتنا ، وهو بدوره يغير قائمة الملفات. في وضع الاسترداد ، يقوم برنامج التشغيل بإعلام الخدمة بأن استرداد النظام ضروري. تصطف الخدمة في قائمة الملفات ، وتقوم بتشغيل وكلاء البرامج الذين يطلبون الملفات من النسخة الاحتياطية ، وتبدأ عملية الاسترداد.
دبلوم ، دعوة عمل ومشاريع جديدة
عندما كانت الخدمة جاهزة واختبرت ، كان لدينا آخر نشاط في المشروع. كان من الضروري تحديث وهيكل جميع القطع الأثرية التي جمعناها ، وكذلك تقديم نتائجنا إلى العميل والجامعة. بالنسبة للشركة ، كانت هذه خطوة أخرى نحو تنفيذ المشروع ، بالنسبة للجامعة مع أطروحة التخرج لدينا.
بعد العرض التقديمي ، تم تقديم اقتراح للطلاب. وبعد بضعة أسابيع أذهب للعمل في أكرونيس. دفعت نتائج المشروع المطورين إلى الاعتقاد بأنه من الممكن جعل الخدمة أكثر كفاءة عن طريق خفضها إلى مستوى تطبيق Windows الأصلي. ولكن المزيد عن ذلك في المقال التالي.