دورة حياة أجهزة المؤسسة IT Asset Management

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

وسوف نناقش في هذا المقال ما يلي:

• مراحل دورة حياة جهاز المؤسسة العشر، وما يحدث في كل مرحلة ومن يملكها.
• ترقيم الأصول وملصقات QR، وما الذي يجب أن يحمله الرمز وما لا يجب.
• التجهيز دون لمس Zero-Touch، والتسليم المرتبط بتعيين الموظف، والجرد والفقد والإصلاح.
• الإرجاع عند المغادرة، والمسح حسب NIST SP 800-88، والإتلاف حسب نظام إدارة النفايات في السعودية.
• التراخيص باختصار، وجدول المسؤوليات RACI، والمقاييس.
• تجربة كاملة على Snipe-IT: من الاستلام وطباعة الملصق إلى الجرد بمسح الرمز بالمتصفح، ثم المغادرة والإتلاف، مع خطأين نصنعهما عمداً.

أما الفرق بين إدارة الأصول IT Asset Management وقاعدة بيانات الإعدادات CMDB فقد شرحناه في مقال ITSM، وإدارة الجهاز نفسه بعد تسجيله، أي السياسات والتشفير والتحديثات، شرحناها في مقال MDM:

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

مراحل دورة حياة الجهاز

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

التخطيط وقائمة الموديلات المعتمدة

أول قرار هو أن لا تشتري كل مرة جهازاً مختلفاً، والسبب أن عشرين موديلاً مختلفاً تعني عشرين نوعاً من التعريفات Drivers والقطع وشروط الضمان، وأن الفني لا يعرف أياً منها جيداً. ولذلك تكتب المؤسسة قائمة موديلات معتمدة Standard Catalogue صغيرة، تراجع مرة أو مرتين في السنة، مثل:

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

ولكل موديل في القائمة عمر تشغيلي متوقع تحدده المؤسسة نفسها حسب ميزانيتها وطبيعة العمل، ويسجل في السجل كتاريخ نهاية الخدمة End of Life، حتى تعرف من الآن كم جهازاً سوف يحتاج تجديداً في كل سنة.

الطلب والموافقة

الجهاز الجديد طلب خدمة Service Request من الكتالوج الذي شرحناه في كتالوج الخدمات، وليس رسالة إلى الفني، وفي النموذج حقول تجعل الطلب كاملاً من البداية:

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

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

الشراء

تفاصيل التعاقد والدفع عمل المشتريات والمالية، وما يهم تقنية المعلومات هنا هو ما يجب أن يصل مع الأجهزة، لأنه يدخل في السجل مباشرة:

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

الاستلام والترقيم

عند الاستلام يطابق الفني ما وصل مع أمر الشراء، ثم يولد لكل جهاز سجلاً وملصقاً. ورقم الأصل Asset Tag هو هوية الجهاز عند المؤسسة، وقواعد ترقيمه بسيطة ولكن مخالفتها مكلفة:

• بادئة ثابتة ورقم متسلسل بعدد خانات ثابت، مثل ARB-000101، والسبب أن الرقم المتسلسل لا يتغير مهما تغير الجهاز.
• لا تضع في الرقم معنى يتغير، مثل القسم أو المبنى، والسبب أن الجهاز ينتقل من قسم إلى قسم ويبقى رقمه.
• لا تعيد استخدام رقم جهاز أتلف، والسبب أن تاريخه في السجل وفي الفواتير وفي شهادة الإتلاف يجب أن يبقى لجهاز واحد.
• رقم الأصل غير الرقم التسلسلي للمصنع Serial Number، فالأول من عندك والثاني من المصنع، وتحتاج الاثنين في السجل.

أما الملصق فيحمل رقم الأصل مكتوباً ورمزاً يقرؤه الهاتف أو قارئ الباركود، والصورة التالية تبين ما يجب أن يحمله الرمز:

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

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

التجهيز

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

• Windows Autopilot: تصفه Microsoft في نظرة عامة على Windows Autopilot بأنه مجموعة تقنيات لتجهيز الأجهزة الجديدة وإعدادها مسبقاً، فيحول نسخة Windows المثبتة من المصنع إلى حالة جاهزة للعمل بدل إعادة تثبيتها، ويسجلها تلقائياً في Microsoft Entra ID وفي خدمة MDM.
• التسجيل التلقائي للأجهزة Automated Device Enrollment من Apple: وتقول Apple في صفحة التسجيل التلقائي إنه مصمم لكل أجهزة Apple التي تملكها المؤسسة، وإن الرقم التسلسلي للجهاز يجب أن يظهر في Apple Business أو Apple School Manager.
• التسجيل دون لمس Zero-Touch Enrollment في Android: وتقول Google في صفحة التسجيل دون لمس إن الجهاز يتحقق في أول تشغيل هل له إعداد مؤسسي فيبدأ التجهيز كجهاز مدار بالكامل، وإن الأجهزة المؤهلة يجب أن تشترى من موزع معتمد للمؤسسات وليس من متجر المستهلكين.

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

التسليم للموظف

التسليم Check-out هو اللحظة التي يصبح فيها للجهاز صاحب، وهو جزء من مهام التعيين Joiner التي شرحناها في مقال JML، أي أن طلب التعيين الذي يفتح الحسابات هو نفسه الذي يطلب الجهاز. وفي التسليم ثلاثة أمور:

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

التشغيل والجرد والفقد والإصلاح

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

• التحديثات Patching: من نظام إدارة الأجهزة، وليس من سجل الأصول، ولكن حالة التحديث تفيد الجرد، فالجهاز الذي لم يتصل بنظام الإدارة منذ ستين يوماً سؤال يجب أن يسأل.
• مزامنة الجرد Inventory Sync: نظام إدارة الأجهزة أو وكيل مثل osquery يعرف الرقم التسلسلي والموديل والمستخدم الحالي، ومقارنته بالسجل تكشف الأجهزة التي تغير صاحبها دون تسليم مسجل.
• الجرد Audit: فني يمر على المكاتب ويمسح الملصقات، فيسجل النظام أن الجهاز شوهد في هذا الموقع في هذا اليوم، وسوف نراه عملياً في التجربة.
• الإصلاح والضمان: تتغير حالة الجهاز إلى «في الإصلاح» ويسجل رقم مطالبة الضمان، ويعطى الموظف جهازاً بديلاً من المخزون بتسليم مسجل أيضاً.
• النقل Moves: انتقال الموظف إلى مبنى آخر يعني تحديث الموقع، وانتقال الجهاز إلى موظف آخر يعني إرجاعاً ثم تسليماً، وليس تعديلاً لاسم الموظف في السجل.

أما الفقد أو السرقة فلها خطوات ثابتة يجب أن تكون مكتوبة قبل أن تحدث:

1. يبلغ الموظف فوراً بتذكرة أو اتصال، ويسجل الوقت والمكان.
2. يقفل الجهاز عن بعد من نظام إدارة الأجهزة، ثم يمسح إذا لم يعد خلال المدة التي تحددها السياسة.
3. تلغى جلسات الموظف وتوكناته على ذلك الجهاز، وتغير كلمة مروره، كما شرحنا في مقال BYOD.
4. تتغير حالة الجهاز في السجل إلى «مفقود أو مسروق» مع رقم البلاغ إن وجد، ولا يحذف السجل.
5. يقيم فريق الأمن هل كان على الجهاز بيانات حساسة غير مشفرة، والسبب أن التشفير هو الذي يحول الفقد من حادثة تسرب إلى خسارة جهاز فقط.

التجديد

عندما يقترب الجهاز من نهاية عمره المحدد في القائمة المعتمدة، أو تتكرر أعطاله، يدخل مرحلة التجديد Refresh، ولها ثلاثة مسارات:

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

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

الإرجاع عند المغادرة

الإرجاع هو توأم التسليم، وهو جزء من مهام المغادرة Leaver في مقال JML، ولاحظ أن الترتيب مهم هنا: قائمة ما يحمله الموظف تخرج من السجل قبل آخر يوم، وليس بعده. وخطوات الإرجاع هي:

1. تقرير من السجل بكل ما هو مسلم للموظف من أجهزة وملحقات ومقاعد تراخيص، يصل إلى مديره والموارد البشرية قبل آخر يوم.
2. استلام الأجهزة بمحضر يقابل إقرار الاستلام، مع حالتها.
3. تغيير حالة الجهاز في السجل إلى «بانتظار المسح»، وليس إلى «جاهز للتسليم»، والسبب أن الجهاز الذي لم يمسح ليس جاهزاً لأحد.
4. إذا لم يعد الجهاز، يقفل ويمسح عن بعد، ويبقى في السجل باسم الموظف المغادر حتى يعود أو يغلق ملفه بقرار من الإدارة، فلا يختفي من التقارير.

المسح حسب NIST SP 800-88

المرجع الأشهر لمسح وسائط التخزين هو دليل NIST SP 800-88، وقد صدرت النسخة Rev. 2 في سبتمبر 2025 وحلت محل Rev. 1 الصادرة في ديسمبر 2014. ويقسم الدليل التطهير Sanitization إلى ثلاث طرق كما في الجدول التالي:

ومن التغييرات المهمة في Rev. 2 كما في قائمة التغييرات في آخر نص الدليل:

• المسح العادي Clear لا يحتاج الكتابة فوق القرص عدة مرات، والدليل يقول صراحة إن هذا يرد على متطلبات DoD 5220.22-M القديمة التي تفرض عدداً من مرات الكتابة وأنماطها.
• حذفت الملاحق التي كانت تصف تقنيات المسح لكل نوع من الوسائط، ويحيل الدليل الآن إلى معيار IEEE 2883 لاختيار تقنية التطهير المناسبة لكل نوع.
• يذكر الدليل أن المسح التشفيري Cryptographic Erase لافت لسرعته، ولكن فعاليته تعتمد على جودة التشفير وشروط مسبقة يفصلها، وأنه قد يكون الخيار الوحيد للتخزين المنطقي مثل التخزين السحابي.
• إزالة المغناطيسية Degaussing لا تستخدم مع وسائط غير مغناطيسية مثل أقراص SSD.

ويطلب الدليل بعد التطهير شهادة تطهير Certificate of Sanitization لكل وسيط، ورقية أو إلكترونية، وفيها على الأقل الحقول التالية كما في القسم 4.6:

• الشركة المصنعة والموديل والرقم التسلسلي، ورقم الأصل الذي تعطيه المؤسسة إن وجد.
• نوع الوسيط ومصدره، والتصنيف قبل التطهير اختيارياً.
• الطريقة، أي Clear أو Purge أو Destroy، والتقنية المستخدمة، والأداة مع إصدارها.
• طريقة التحقق، واسم من قام بالتحقق والاعتماد ومنصبه والتاريخ والمكان وطريقة التواصل معه.

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

الإتلاف وإعادة التدوير في السعودية

بعد المسح يخرج الجهاز إلى جهة إعادة تدوير أو إتلاف، وفي السعودية ينظم ذلك نظام إدارة النفايات الصادر بالمرسوم الملكي رقم (م/3) بتاريخ 5/1/1443هـ الموافق 13 أغسطس 2021، ولائحته التنفيذية التي ينشرها المركز الوطني لإدارة النفايات في صفحة اللوائح التنفيذية. وما يهم قسم تقنية المعلومات منها، دون أن يكون هذا استشارة قانونية، ما يلي:

• تعرف اللائحة نفايات المعدات الكهربائية والإلكترونية WEEE بأنها تشمل مكوناتها وملحقاتها وقت التخلص منها، وتذكر من أمثلتها الهواتف والشواحن وآلات الطباعة والحواسيب.
• منتج النفايات يبقى مالكها ومسؤولاً عنها حتى تنقل إلى مقدم خدمة مرخص، وتنتقل المسؤولية عند إكمال وثيقة النقل Transportation Document وتوقيعها من الطرفين، كما في المواد 37 و38 و41.
• على منتج النفايات أن يتحقق من تراخيص مقدم الخدمة قبل أن يسلمه النفايات، كما في المادة 40.
• وتعرف اللائحة وثيقة التخلص Disposal Document بأنها وثيقة يمنحها مقدم الخدمة لمنتج النفايات بعد التخلص الآمن منها.

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

التراخيص باختصار

إدارة الأصول IT Asset Management لا تقتصر على العتاد، فالتراخيص أصول لها عدد مقاعد وتاريخ انتهاء وتكلفة، وأخطاؤها نوعان: مقاعد مدفوعة لا يستخدمها أحد، ومقاعد مستخدمة أكثر مما اشتريت. وأهم ما تفعله هنا ثلاثة أمور:

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

من المسؤول عن كل مرحلة؟

جدول RACI يحدد لكل مرحلة أربعة أدوار: المنفذ Responsible، والمسؤول النهائي Accountable وهو شخص واحد فقط، ومن يستشار Consulted، ومن يبلغ Informed. والجدول التالي مثال لمؤسسة متوسطة، والسبب في كتابته أن أغلب الأجهزة الضائعة في الدورة تضيع بين قسمين يظن كل منهما أن الآخر مسؤول:

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

المقاييس

المقاييس هنا قليلة وكلها تقيس صحة السجل، وأهمها:

• دقة السجل Inventory Accuracy: نسبة الأجهزة التي وجدت في الجرد كما هي في السجل، أي نفس الموقع ونفس الصاحب.
• الأجهزة التي بلا صاحب: أجهزة في حالة «مسلم» دون موظف نشط، أو أجهزة لم تظهر في أي جرد منذ مدة طويلة.
• أجهزة المغادرين التي لم تعد: عددها وعمرها، وهذا أهم رقم أمنياً في القائمة.
• وقت التجهيز Time to Provision: من الموافقة على الطلب إلى تسليم الجهاز جاهزاً للموظف، ويقيس أثر التجهيز دون لمس.
• الجرد المتأخر: الأجهزة التي فات موعد جردها.

تجربة عملية: دورة حياة كاملة على Snipe-IT

الآن سوف نطبق الدورة كلها على نظام حقيقي، وقد اخترنا Snipe-IT، وهو نظام مفتوح المصدر لإدارة الأصول IT Asset Management برخصة AGPL-3.0 كما في مستودعه، ومكتوب بلغة PHP على إطار Laravel، والإصدار الذي استخدمناه هو v8.8.0 الصادر في 30 سبتمبر 2026. والسيناريو كما يلي: نستلم ثلاثة حواسيب من أمر شراء، ونطبع ملصقاً لأحدها، ونسلمه لموظفة اسمها سارة مع مقعد ترخيص، ثم يجرده فني بمسح رمز QR من المتصفح، ثم تغادر سارة فيعود الجهاز ويمسح ويتلف بسجل كامل، وبعد ذلك نصنع خطأين عمداً: رقماً مكرراً، وجهازاً لم يعد بعد مغادرة صاحبه.

التثبيت

ملف Docker Compose التالي مبني على ملف المشروع نفسه مع تثبيت الإصدارات، وقاعدة البيانات MariaDB 11.4.7 هي الإصدار الذي يثبته المشروع في ملفه، والمنفذ مربوط على 127.0.0.1 فقط:

# Snipe-IT lab for the device lifecycle article (test data only)
#   docker compose -p lab-itam up -d
name: lab-itam

services:
  app:
    image: snipe/snipe-it:v8.8.0
    container_name: lab-itam-snipe
    restart: unless-stopped
    volumes:
      - storage:/var/lib/snipeit
    ports:
      - "127.0.0.1:18310:80"
    depends_on:
      db:
        condition: service_healthy
    env_file:
      - snipe.env

  db:
    image: mariadb:11.4.7
    container_name: lab-itam-db
    restart: unless-stopped
    volumes:
      - db_data:/var/lib/mysql
    environment:
      MYSQL_DATABASE: snipeit
      MYSQL_USER: snipeit
      MYSQL_PASSWORD: lab-db-pass-2026
      MYSQL_ROOT_PASSWORD: lab-root-pass-2026
    healthcheck:
      test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
      interval: 5s
      timeout: 10s
      retries: 60
      start_period: 600s

volumes:
  db_data:
    name: lab-itam-db-data
  storage:
    name: lab-itam-storage

في الإعداد أعلاه لاحظ التالي:

• زدنا مهلة فحص الصحة Healthcheck لقاعدة البيانات مع start_period طويل، والسبب أن أول تشغيل ينشئ قاعدة البيانات ثم يشغل Snipe-IT عند بدايته 488 ملف ترحيل Migration، وعلى جهاز التجربة، وكان مشغولاً بتجارب أخرى في الوقت نفسه، فشل الفحص القصير قبل أن تجهز القاعدة.
• ملف المتغيرات snipe.env فيه المتغير APP_KEY، وهو مفتاح التشفير الخاص بالتطبيق، ولاحظ أن ملف المثال .env.docker في المستودع يأتي بقيمة جاهزة لهذا المفتاح، فلا تنسخها كما هي، وإنما ولد مفتاحك بالأمر التالي:

docker run --rm --entrypoint php snipe/snipe-it:v8.8.0 /var/www/html/artisan key:generate --show

وعند أول زيارة يحول Snipe-IT كل صفحة إلى /setup حتى تنشئ حساب المدير وإعدادات الموقع، وفي هذه الصفحة اخترنا البادئة ARB- وعدد الخانات 6 لأرقام الأصول، أي القاعدة التي شرحناها في الترقيم.

مفتاح ال API: خطأ في أول محاولة

كل خطوات التجربة تعمل عبر REST API، ولذلك نحتاج مفتاحاً شخصياً Personal API Token للمدير، وفي Snipe-IT أمر لذلك، ولكن أول محاولة على التثبيت الجديد أعادت هذا الخطأ:

docker exec -u docker lab-itam-snipe php /var/www/html/artisan snipeit:make-api-key --user_id=1 --name=itam-lab

   LogicException 

  Invalid key supplied

والسبب أن مجلد مفاتيح OAuth في ال Volume كان فارغاً، فهذه المفاتيح لم تولد عند التشغيل، وبعد توليدها ظهر خطأ ثان هو Personal access client not found. Please create one.، والحل بأمرين ثم إعادة الأمر الأول:

docker exec -u docker lab-itam-snipe php /var/www/html/artisan passport:keys
docker exec -u docker lab-itam-snipe php /var/www/html/artisan passport:client --personal \
  --name="Snipe-IT Personal Access Client" --no-interaction
docker exec -u docker lab-itam-snipe php /var/www/html/artisan snipeit:make-api-key \
  --user_id=1 --name=itam-lab --key-only

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

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

السكربت itam.mjs في مجلد التجربة يستخدم Node.js دون أي حزمة، ويحتوي أمراً لكل مرحلة. والأمر الأول ينشئ ما تحتاجه الدورة: حالات الأصل Status Labels، وحقولاً مخصصة لسجل المسح، وفئة الحواسيب والشركة المصنعة والموديل بعمر 48 شهراً، وموقعين، وموظفين، وترخيصاً بثلاثة مقاعد:

node itam.mjs setup

والمخرج سوف يكون كما يلي:

setup done
/statuslabels Lost or Stolen(undeployable), Disposed(archived), In Repair(undeployable), Pending Wipe(pending), Pending(pending), Ready to Deploy(deployable), Archived(archived)

ولاحظ أن كل حالة في Snipe-IT لها نوع يحدد ما يسمح به النظام، فالحالة من نوع deployable يمكن تسليمها، وpending لا يمكن تسليمها حتى تنتهي، وarchived تخرج الجهاز من القوائم اليومية دون أن تحذف سجله، ولهذا جعلنا «Pending Wipe» من النوع الثاني و«Disposed» من النوع الثالث. أما الحقول المخصصة فكل حقل منها يصبح عموداً في جدول الأصول، وأسماء الأعمدة كما يعيدها ال API هي التي نستخدمها في الكتابة:

MAC Address _snipeit_mac_address_1
Wipe Method _snipeit_wipe_method_2
Wipe Tool _snipeit_wipe_tool_3
Wiped By _snipeit_wiped_by_4
Wipe Date _snipeit_wipe_date_5
Certificate No _snipeit_certificate_no_6

الاستلام

الأمر التالي ينشئ سجلاً لكل حاسوب من «مذكرة التسليم»، أي رقم الأصل والرقم التسلسلي وأمر الشراء والتكلفة وتاريخ الشراء ومدة الضمان 36 شهراً:

node itam.mjs receive

created id=1 ARB-000101 serial=PF5LAB01
created id=2 ARB-000102 serial=PF5LAB02
created id=3 ARB-000103 serial=PF5LAB03

الملصق ورمز QR

محرك الملصقات الجديد في Snipe-IT يولد ملف PDF بقوالب جاهزة لأشرطة Brother وDymo وZebra وأوراق Avery، وفي التجربة اخترنا قالب Tapes\Brother\TZe_24mm_A وحقول رقم الأصل والرقم التسلسلي والموديل. وغيرنا هذه الإعدادات مباشرة في جدول الإعدادات في قاعدة البيانات لأن التجربة مؤتمتة، ومكانها في الاستخدام العادي صفحة إعدادات الملصقات Labels في إعدادات المدير. ويحدد الإعداد label2_2d_target ما يحمله رمز QR، والقيمة الافتراضية hardware_id أي رابط صفحة الأصل، ومن الخيارات الأخرى في الكود رابط بحسب رقم الأصل ht_tag، أو رقم الأصل أو الرقم التسلسلي كنص لقارئ الباركود.

ثم نزلنا ملصق الحاسوب الأول بجلسة المدير، أي بعد تسجيل الدخول من نموذج الدخول وحفظ الكوكي Cookie في ملف cookies.txt، وحولناه إلى صورة وقرأنا رمزه في Container من Image بايثون بأداتي pdftoppm وzbarimg، كما في السكربت decode-label.sh:

curl -s -b cookies.txt -o label-1.pdf http://127.0.0.1:18310/hardware/1/label
sh decode-label.sh "$PWD"

label-1-1.png
QR-Code:http://127.0.0.1:18310/hardware/1
scanned 1 barcode symbols from 1 images in 0.18 seconds

اختصرنا المخرج أعلاه إلى الأسطر المهمة، وحذفنا منه سطري تحذير عن dbus تطبعهما الأداة داخل Container ولا علاقة لهما بالقراءة. والصورة التالية هي الملصق نفسه كما ولده Snipe-IT:

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

التسليم ومقعد الترخيص

node itam.mjs checkout ARB-000101 sara
node itam.mjs seat sara
node itam.mjs checkout ARB-000102 khalid

ARB-000101 | PF5LAB01 | ThinkPad T14 Gen 5 | status: Ready to Deploy (deployed) | assigned: sara | location: Building B, Floor 2 | last audit: -
Office Suite (subscription): seats 3, free 2, expires 2027-09-30
ARB-000102 | PF5LAB02 | ThinkPad T14 Gen 5 | status: Ready to Deploy (deployed) | assigned: khalid | location: Building B, Floor 2 | last audit: -

ولاحظ أن اسم الحالة بقي «Ready to Deploy» بعد التسليم، ولكن النوع بين القوسين أصبح deployed، والسبب أن Snipe-IT يحسب أن الجهاز مسلم من وجود صاحب له وليس من اسم الحالة، فلا تنشئ حالة باسم «Deployed» وتغيرها يدوياً، لأنها سوف تختلف مع الحقيقة في أول مرة ينسى فيها أحد تغييرها.

الجرد بمسح الرمز من المتصفح

الآن نمثل الفني الذي يمر على المكاتب ويمسح الملصق بهاتفه، وقد كتبنا ذلك بسكربت Playwright هو audit.mjs، يعمل في Container من Image الرسمية mcr.microsoft.com/playwright:v1.64.0-noble ويفتح الرابط الذي قرأناه من الرمز مرتين: مرة دون تسجيل دخول، كأن شخصاً وجد الجهاز ومسح الرمز، ومرة بحساب الفني، ثم يفتح صفحة الجرد ويكتب ملاحظة ويحفظ:

sh run-pw.sh scan http://127.0.0.1:18310/hardware/1

logged out: http://127.0.0.1:18310/hardware/1 → http://127.0.0.1:18310/login title="IT Assets Lab"
logged in: http://127.0.0.1:18310/hardware/1 title="View Asset ARB-000101 :: IT Assets Lab"
after audit: http://127.0.0.1:18310/hardware
message: Success: × Asset audit successfully logged.

السطر الأول هو المهم أمنياً: من يمسح الرمز دون حساب يصل إلى صفحة الدخول فقط، فلا يرى اسم صاحبة الجهاز ولا أي بيانات أخرى. والصورة التالية تبين صفحة الجرد قبل الحفظ:

ولاحظ في الصفحة خيار «Update Asset Location»، فإذا لم تختره يسجل الموقع في سجل الجرد فقط ولا يتغير موقع الأصل نفسه، وهذا مكتوب في الصفحة. والصورة التالية تبين صفحة الأصل بعد الجرد:

وفي الصورة أعلاه لاحظ التالي:

• نهاية الضمان 2029-10-01 ونهاية العمر 2030-10-01 حسبهما النظام من تاريخ الشراء ومدة الضمان 36 شهراً وعمر الموديل 48 شهراً، فلا يكتبهما أحد يدوياً.
• تاريخ الجرد التالي بقي 2026-10-13، أي اليوم نفسه، والسبب أننا لم نضبط تكرار الجرد في إعدادات التنبيهات Alerts كما تقول الصفحة، فاضبطه قبل أول جولة جرد حتى يظهر تقرير الجرد المتأخر بشكل صحيح.
• حقول المسح الخمسة ظاهرة وفارغة، وسوف تمتلئ عند الإتلاف.

المغادرة

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

if (cmd === 'leaver') {
    // Leaver: list what the person holds, check each asset in as Pending Wipe, then deactivate the account
    const u = await user(args[0]);
    const held = (await api('GET', `/users/${u.id}/assets`)).rows || [];
    console.log(`${u.username} holds ${held.length} asset(s): ${held.map(h => h.asset_tag).join(', ') || '-'}`);
    const pending = await statusId('Pending Wipe');
    const store = await one('/locations', 'HQ IT Store');
    for (const h of held) {
        await write('POST', `/hardware/${h.id}/checkin`, { status_id: pending, location_id: store.id, note: 'Leaver ticket #4532: returned at exit interview' });
        console.log(line(await byTag(h.asset_tag)));
    }
    const lic = (await api('GET', `/users/${u.id}/licenses`)).rows || [];
    console.log(`licence seats still held: ${lic.map(l => l.name).join(', ') || '-'}`);
    await write('PATCH', `/users/${u.id}`, { activated: false });
    const after = await user(args[0]);
    console.log(`${after.username} activated=${after.activated} assets_count=${after.assets_count}`);
}

node itam.mjs leaver sara

sara holds 1 asset(s): ARB-000101
ARB-000101 | PF5LAB01 | ThinkPad T14 Gen 5 | status: Pending Wipe (pending) | assigned: - | location: HQ IT Store | last audit: 2026-10-13 09:26 PM
licence seats still held: Office Suite (subscription)
sara activated=false assets_count=0

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

المسح والإتلاف بسجل كامل

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

node itam.mjs dispose ARB-000101 WD-2026-0031

ARB-000101 | PF5LAB01 | ThinkPad T14 Gen 5 | status: Disposed (archived) | assigned: - | location: HQ IT Store | last audit: 2026-10-13 09:26 PM
  Wipe Method: Purge (NIST SP 800-88 Rev. 2)
  Wipe Tool: NVMe Format, Secure Erase (vendor BIOS tool)
  Wiped By: it.tech1
  Wipe Date: 2026-10-13
  Certificate No: WD-2026-0031

ثم نعرض تاريخ الجهاز كاملاً من سجل النشاط:

node itam.mjs history ARB-000101

2026-10-13 08:47 PM | create new | - | 
2026-10-13 09:01 PM | checkout | Sara Lab | Joiner ticket #4410, laptop for sara
2026-10-13 09:01 PM | update | - |  | changed: Current Location
2026-10-13 09:26 PM | audit | - | Annual audit, scanned QR on desk B2-14 | changed: next_audit_date
2026-10-13 09:35 PM | checkin from | Sara Lab | Leaver ticket #4532: returned at exit interview | changed: Current Location, Status Label
2026-10-13 09:35 PM | update | - |  | changed: notes, wipe_method, wipe_tool, wiped_by, wipe_date, certificate_no, Status Label

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

اكسرها: رقم أصل مكرر ورقم تسلسلي مكرر

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

node itam.mjs dup-tag
node itam.mjs dup-serial ARB-000199

{"status":"error","messages":{"asset_tag":["The asset tag must be unique."]}}
{"status":"success","messages":"Asset created successfully. :)","created":"ARB-000199 serial=PF5LAB02"}

رقم الأصل المكرر رفض، أما الرقم التسلسلي المكرر فقبل دون أي تحذير، والسبب أن التحقق من تفرد الرقم التسلسلي في Snipe-IT مربوط بإعداد اسمه «Unique serial numbers» في الإعدادات العامة، وقيمته الافتراضية في التثبيت الجديد معطلة، كما رأينا في جدول الإعدادات وفي كود التحقق نفسه. فعلنا الإعداد، ثم كررنا المحاولة برقم أصل جديد:

{"status":"error","messages":{"serial":["The serial must be unique."]}}

الآن رفض التكرار الجديد، ولكن الجهاز المكرر الذي دخل قبل التفعيل بقي، والبحث بالرقم التسلسلي PF5LAB02 أعاد سجلين هما ARB-000102 وARB-000199، والأسوأ أن أي تعديل على السجل المكرر، ولو كان إضافة ملاحظة، رفض بالخطأ نفسه:

error {'serial': ['The serial must be unique.']}

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

اكسرها: موظف غادر ولم يعد جهازه

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

node itam.mjs deactivate khalid
node itam.mjs delete-user khalid
node itam.mjs unreturned

khalid activated=false assets_count=1
{"status":"error","messages":{"assigned_assets":["This user still has an asset assigned. Please check it in first."]}}
UNRETURNED ARB-000102 serial=PF5LAB02 → khalid (deactivated), checked out 2026-10-13 09:01 PM
2 assigned asset(s) checked, 1 held by deactivated users

في المخرج أعلاه لاحظ التالي:

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

النسخ الاحتياطي: الأمر المدمج لم يعمل

في Snipe-IT أمر مدمج للنسخ الاحتياطي اسمه snipeit:backup يأخذ قاعدة البيانات والملفات المرفوعة، وعندما شغلناه على التثبيت نفسه فشل كما يلي:

Starting backup...
Dumping database snipeit...
Backup failed because: The dump process failed with a none successful exitcode.
Exitcode
========
127: Command not found
...
sh: 1: /usr/bin/mariadb-dump: not found

اختصرنا أسطراً فارغة من المخرج أعلاه. والسبب أن ملف المتغيرات يستخدم DB_CONNECTION=mariadb كما في ملف المثال في المستودع، فيبحث الأمر عن mariadb-dump، بينما في ال Image نفسها توجد أداة mysqldump فقط. والحل الذي استخدمناه هو أخذ النسخة من Container قاعدة البيانات نفسه، ثم أخذ نسخة من ال Volume الذي فيه الملفات المرفوعة ومفاتيح OAuth:

docker exec lab-itam-db sh -c \
  'mariadb-dump --single-transaction -usnipeit -p"$MYSQL_PASSWORD" snipeit' | gzip > snipeit.sql.gz

وفي التجربة كان حجم النسخة المضغوطة 21,543 بايت، وتذكر أن النسخة التي لم تجرب استعادتها ليست نسخة، كما شرحنا في النسخ الاحتياطي بقاعدة 3-2-1 واختبار الاستعادة.

إزالة التجربة

docker compose -p lab-itam down -v
docker volume rm lab-itam-pw
docker image rm snipe/snipe-it:v8.8.0 mariadb:11.4.7

متى يناسبك Snipe-IT؟

بعد التجربة هذه خلاصة نقاط القوة والضعف كما رأيناها:

• نقاط القوة: يركز على سجل الأصول ودورة حياتها فقط، وفيه التسليم والإرجاع والجرد والحقول المخصصة والتراخيص وسجل نشاط كامل، وواجهة REST API تغطي كل خطوة في التجربة، وملصقات PDF بقوالب جاهزة، ويدعم الدخول عبر LDAP وSAML كما في كوده وأوامره.
• نقاط الضعف: لا يكتشف الأجهزة وحده، فيحتاج مصدراً آخر مثل نظام إدارة الأجهزة أو وكيل جرد، وليس فيه نظام تذاكر، وفي التثبيت عبر Docker رأينا ثلاث مشكلات تحتاج انتباهاً: مفتاح التطبيق في ملف المثال، ومفاتيح OAuth لل API، وأمر النسخ الاحتياطي.

فإذا كنت تريد التذاكر والأصول وقاعدة بيانات الإعدادات في نظام واحد مع وكيل جرد، فقد يناسبك GLPI الذي جربنا تذاكره في مقارنة أنظمة التذاكر، وإذا كان عندك نظام تذاكر جيد وتريد سجل أصول دقيقاً بجانبه، فـ Snipe-IT مناسب.

أخطاء شائعة

• سجل يبدأ من التسليم وليس من الاستلام، فلا يعرف أحد كم جهازاً في المخزن.
• رقم أصل يحمل اسم القسم أو المبنى، ثم يتغير القسم ويبقى الرقم مضللاً.
• اسم الموظف ورقم هاتفه على الملصق.
• تفعيل تفرد الرقم التسلسلي بعد الاستيراد وليس قبله.
• تعطيل حساب المغادر دون إرجاع جهازه ومقاعد تراخيصه، ودون تقرير يكشف ذلك.
• إعادة الجهاز إلى حالة «جاهز للتسليم» قبل مسحه.
• الكتابة فوق القرص عدة مرات ظناً أنها أكثر أماناً، بينما Rev. 2 من NIST SP 800-88 تقول إن المسح العادي لا يحتاج ذلك، وأن التطهير بأوامر الجهاز نفسه هو المطلوب للبيانات الحساسة.
• تسليم الأجهزة لجهة إعادة تدوير دون التحقق من ترخيصها ودون وثيقة نقل وشهادة تطهير في السجل.
• طباعة الملصقات قبل تثبيت العنوان النهائي للنظام.

الخلاصة

• دورة حياة الجهاز عشر مراحل حول سجل واحد يولد عند الاستلام ويبقى بعد الإتلاف، والتسليم والإرجاع هما نقطتا الربط مع دورة حياة الموظف JML.
• رقم الأصل متسلسل بلا معنى ولا يعاد استخدامه، والملصق يحمل رابطاً إلى السجل أو رقم الأصل، وليس بيانات الموظف.
• التجهيز دون لمس يعتمد على تسجيل المورد للأجهزة في Windows Autopilot أو Automated Device Enrollment أو Android Zero-Touch، فيبدأ من مرحلة الشراء.
• NIST SP 800-88 Rev. 2 الصادرة في سبتمبر 2025 تقسم التطهير إلى Clear وPurge وDestroy، وتطلب شهادة لكل وسيط، وفي السعودية يسلم الجهاز لمقدم خدمة مرخص بوثيقة نقل بحسب اللائحة التنفيذية لنظام إدارة النفايات.
• في التجربة على Snipe-IT v8.8.0 قبل النظام رقماً تسلسلياً مكرراً لأن التفرد معطل افتراضياً، وبقي مقعد الترخيص محجوزاً بعد تعطيل حساب المغادرة، وبقي جهاز المغادر الآخر عند حساب معطل حتى كشفه التقرير.

وفي مقالات قادمة بإذن الله سوف نتعمق في أدوات هذه المرحلة، مثل Fleet مع osquery للجرد الآلي وأدوات الإدارة عن بعد:

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

سجل التحديثات

• أكتوبر 2026: كتابة المقال مع تجربة حقيقية على Snipe-IT v8.8.0 (snipe/snipe-it:v8.8.0، PHP 8.3.6 وApache 2.4.58) مع MariaDB 11.4.7، وPlaywright 1.64.0 في mcr.microsoft.com/playwright:v1.64.0-noble، وقراءة رمز QR بأداتي poppler-utils وzbar-tools في python:3.13.16-slim، وNode.js 22.14.0 للسكربت على Docker Engine 29.8.0، ومعلومات NIST SP 800-88 Rev. 2 واللائحة التنفيذية لنظام إدارة النفايات وصفحات Microsoft وApple وGoogle كما هي في 13 أكتوبر 2026.