الانتقال من ManageEngine Service Desk Plus — دليل ميداني

كل عملية انتقال لنظام إدارة خدمات تقنية المعلومات هي مشروع أركيولوجي صغير. عشر سنوات من سجل التذاكر، وثلاثة أو أربعة أجيال من الحقول المخصصة، وقاعدة اتفاقية مستوى خدمة نصف منسية لا تنطبق إلا خلال فترة التجميد في نهاية السنة المالية — كل هذا يجب أن يصمد أمام النقل، وإلا فقد فريق العمليات ذاكرته المؤسسية. كُتب هذا الدليل للمهندس أو مدير تقنية المعلومات الذي كُلِّف بنسخة من ManageEngine Service Desk Plus (SDP) وطُلب منه نقلها إلى LinaDesk قبل دورة التجديد القادمة.

نفترض أن لديك SDP مثبتاً محلياً (الإصدار 14xxx أو 15xxx)، وعدد تذاكر تاريخية يتراوح بين 5,000 و200,000، ومستودع مستخدمين مرتبط بـ Active Directory، وحفنة صغيرة من عمليات التكامل عبر البريد الإلكتروني/LDAP. إذا كانت نسختك من SDP هي إصدار MSP، أو كنت تشغّل نسخة Enterprise مع وحدة CMDB ممتلئة بكثافة، فسيحتاج بعض التخطيط أدناه إلى توسعة — لكن شكل العمل يبقى كما هو.

لماذا تنتقل المؤسسات بعيداً عن SDP

قبل الحديث عن الآليات، الأسباب — لأنها تحدد قرارات التخطيط لاحقاً. عملياً، تصل الفرق التي تبدأ عملية انتقال من SDP إلى LinaDesk إلى واحد أو أكثر من الأسباب التالية:

• قانون KVKK ومكان إقامة البيانات. تقع النسخة السحابية من SDP على بنية تحتية تابعة لـ Zoho خارج تركيا. أما نسختها المحلية فهي مقبولة على هذا الصعيد، لكن نموذج الترخيص يوجّه العملاء نحو السحابة عند التجديد. تفضّل المؤسسات التركية الملزَمة بالمادة 9 من قانون KVKK (النقل عبر الحدود) مزوداً محلياً خاضعاً للسيطرة التركية كتأمين ضد الانتقال القسري إلى السحابة.
• مسار تكلفة الفني الواحد. ارتفع سعر SDP لكل فني بشكل مطّرد منذ عام 2022، ويتراكم التسعير المُجزّأ (إضافات لإدارة التغيير، والمشاريع، وCMDB). يزيل البديل ذو الترخيص الثابت مفاجآت لحظة التجديد.
• سهولة استخدام الواجهة واختصارات لوحة المفاتيح. تسبق واجهة SDP معايير تصميم حقبة Linear. تشعر الفرق التي يعيش فيها فنيو الدعم من المستوى الأول في قائمة الانتظار طوال اليوم بذلك يومياً.
• عمليات النشر المعزولة عن الشبكة أو على شبكات مصنّفة. لا يمكن للعملاء الحكوميين والدفاعيين تشغيل إضافات SDP السحابية؛ يجب أن تعمل كل قدرة يحتاجونها داخل محيطهم الآمن.

يهم السبب لأنه يحدد ما يُنقَل. عادةً ما يحافظ الانتقال المدفوع بقانون KVKK على كل شيء، لأن المدققين سيسألون عنه. أما الانتقال المدفوع بالتكلفة فسيترك بسرور الميزات التي لا يستخدمها أحد.

المرحلة 1 — الاستكشاف (أسبوعان)

مرحلة الاستكشاف موجودة لمنع أسوأ نتيجتين لعملية انتقال ITSM: بيانات مفقودة يتّضح لاحقاً أنها مهمة، وبيانات منقولة يتّضح لاحقاً أنها عديمة القيمة. أسبوعان قد يبدوان طويلَين — لكنهما ليسا كذلك.

جرد نسخة SDP

قم بجرد صادق. من لوحة إدارة SDP، سجّل ما يلي في جدول بيانات مشترك:

• إجمالي عدد الطلبات، مقسّماً حسب الحالة (مفتوحة، معلّقة، محلولة، مغلقة) وحسب سنة الإنشاء.
• جميع قوالب الطلبات قيد الاستخدام — بما فيها تلك التي لا يتذكر أحد من أنشأها.
• جميع الحقول المخصصة، لكل وحدة. سجّل نوع الحقل، وما إذا كان إلزامياً، وأي القوالب تشير إليه.
• جميع سياسات اتفاقية مستوى الخدمة، مع تعريفات ساعات العمل، ومستويات التصعيد، ومعايير المطابقة.
• جميع قواعد الأتمتة (Business Rules، Field & Form Rules، Custom Triggers، Time Triggers).
• جميع قوالب البريد الإلكتروني وقواعد الإشعارات.
• جميع سير عمل الموافقات.
• جميع الأدوار، مع تخطيط الصلاحيات.
• كل تكامل: LDAP/AD، خوادم البريد الإلكتروني، SCCM/أدوات الاستكشاف، واجهات برمجة تطبيقات الجهات الخارجية.

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

مقابلة فريق العمليات

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

تخطيط تبعيات التكامل

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

المرحلة 2 — تخطيط البيانات

نموذج بيانات SDP ونموذج LinaDesk قريبان من بعضهما لكنهما ليسا متطابقين. الجدول أدناه هو التخطيط الذي نستخدمه كنقطة انطلاق؛ التخصيص يضيف صفوفاً دائماً.

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

المرحلة 3 — التصدير

يتيح SDP ثلاث طرق لإخراج البيانات: عمليات التصدير المجدولة المدمجة، وواجهة REST API الإصدار 3، والوصول المباشر إلى قاعدة البيانات. للثلاثة جميعاً مكانها.

واجهة REST API v3 للبيانات المهيكلة

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

سكربت PowerShell بسيط لسحب جميع الطلبات، صفحة تلو الأخرى، إلى مجلد من ملفات JSON:

# requires SDP TECHNICIAN_KEY with read access
$sdpUri  = "https://sdp.internal/api/v3/requests"
$authKey = $env:SDP_TECHNICIAN_KEY
$outDir  = "C:\migration\raw\requests"
New-Item -ItemType Directory -Force -Path $outDir | Out-Null

$rowsPerPage = 100
$rowIndex    = 1

do {
  $inputData = @{
    list_info = @{
      row_count   = $rowsPerPage
      start_index = $rowIndex
      get_total_count = $true
      fields_required = @(
        "id","subject","description","status","priority",
        "created_time","resolved_time","closed_time",
        "requester","technician","group","category","subcategory","item",
        "udf_fields")
    }
  } | ConvertTo-Json -Depth 6 -Compress

  $resp = Invoke-RestMethod `
    -Uri "$sdpUri?input_data=$([uri]::EscapeDataString($inputData))" `
    -Headers @{ "authtoken" = $authKey } `
    -Method GET

  $resp.requests | ForEach-Object {
    $_ | ConvertTo-Json -Depth 12 |
      Out-File -Encoding utf8 "$outDir\req_$($_.id).json"
  }

  $total     = $resp.list_info.total_count
  $rowIndex += $rowsPerPage
} while ($rowIndex -le $total)

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

القراءة المباشرة من قاعدة البيانات للمرفقات المؤرشفة

يخزّن SDP المرفقات خارج حمولة الطلب. تُعيد الواجهة البرمجية البيانات الوصفية دون الملفات الثنائية نفسها. للحصول على البايتات الفعلية، استخدم إما نقطة نهاية مرفق الملف لكل سجل (بطيئة، لكنها تحترم الصلاحيات)، أو اقرأ من جدول FileAttachment في SDP بالإضافة إلى مجلد Attachments على القرص. في النسخ الكبيرة (100 ألف تذكرة فأكثر مع مرفقات)، يكون الخيار الثاني هو الواقعي الوحيد — خطط لعملية rsync ليلية.

المرحلة 4 — الحفاظ على سجل التذاكر

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

يدعم LinaDesk إنشاء تذاكر بتاريخ سابق عبر نقطة نهاية الاستيراد الجماعي. القاعدة هي:

تحمل كل تذكرة، وتعليق، وانتقال حالة، وسجل تدقيق طابعها الزمني الأصلي بتوقيت UTC. لا يُسمَح لأي شيء في مسار الاستيراد بالكتابة فوقه.

بشكل ملموس: حقل created_time.value في SDP هو سلسلة نصية بتوقيت يونكس بالميلي ثانية. حوّله إلى UTC بصيغة ISO-8601 ومرّره كـ CreatedAtUtc. افعل الشيء نفسه لحقلَي resolved_time وclosed_time، ولوقت إنشاء كل ملاحظة على حدة. إذا كانت الملاحظة تحمل updated_time مختلفاً عن created_time، احتفظ بكليهما — تتحقق فرق التدقيق من ذلك أحياناً.

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

المرحلة 5 — إعادة ربط AD / LDAP

يكاد يكون المستخدمون دائماً أصعب عملية ربط في الانتقال. يحدد SDP هوية المستخدم داخلياً عبر REQUESTERID. يحدد Active Directory هوية الشخص نفسه عبر objectGUID. يستخدم LinaDesk حقل ExternalId (الذي نوصي بتعيينه ليكون objectGUID من AD).

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

1. UPN (اسم أساسي للمستخدم). يصمد أمام إعادة تسمية AD والانتقال بين الغابات. استخدمه كعملية الربط الأساسية.
2. عنوان البريد الإلكتروني. بديل احتياطي إذا كان UPN مفقوداً.
3. sAMAccountName. الملاذ الأخير، لأن تفرّده غير مضمون بين الغابات المختلفة.

كل مستخدم يفشل في جميع عمليات الربط الثلاث ينتهي به المطاف في ملف orphans.csv. في كل عملية انتقال حقيقية نفذناها، يحتوي هذا الملف بين 20 و400 صف — أشخاص غادروا الشركة، وحسابات خدمة لم تُربَط قط بـ AD، وطالبو خدمة أرسلوا تذكرة واحدة عبر البريد الإلكتروني في عام 2018. قرّر مصيرهم يدوياً. لا تتخطَّ هذه الخطوة: هؤلاء "الأيتام" ما زالوا يمتلكون تذاكر تاريخية، ويجب أن تظهر أسماؤهم بشكل صحيح في التقارير.

المرحلة 6 — إعادة تخطيط سياسات اتفاقية مستوى الخدمة

نموذج اتفاقية مستوى الخدمة في SDP هو محرك قواعد مسطّح: مطابقة حسب معايير الطلب، وتطبيق نوافذ الاستجابة/الحل مقابل تقويم ساعات العمل. نموذج LinaDesk قريب لكنه ليس مطابقاً:

• Operational Hours في SDP ↔ WorkCalendar في LinaDesk.
• Holidays في SDP ↔ WorkCalendarHoliday في LinaDesk.
• معايير SLA في SDP ↔ شروط SlaPolicyMatch في LinaDesk.
• مستويات التصعيد في SDP ↔ سلسلة SlaEscalation في LinaDesk.

الفجوة المهمة الوحيدة تتعلق بـالإيقافات المؤقتة الجزئية. يسمح SDP بإيقاف اتفاقية مستوى الخدمة مؤقتاً عندما تكون التذكرة في حالة Waiting for Requester. يتطلب LinaDesk نمذجة السلوك نفسه صراحةً كمصفوفة PauseOnStatus في سياسة اتفاقية مستوى الخدمة. نفّذ هذا التخطيط في سكربت الانتقال بدلاً من الأمل في أن تتطابق القيم الافتراضية — كل نسخة SDP فحصناها كانت تحتوي على حالة إيقاف مؤقت واحدة على الأقل غير افتراضية.

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

المرحلة 7 — البوابة، والهوية البصرية، وقوالب الإشعارات

هذه العناصر لا تُنقَل. بل تُعاد بناؤها.

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

الأمر نفسه ينطبق على قوالب الإشعارات. استخرج كل قالب بريد إلكتروني من SDP كملف HTML مع قائمة متغيرات، ثم أعد بناءها في محرر قوالب LinaDesk. صيغة المتغيرات في LinaDesk هي على نمط {{Ticket.Number}}؛ بينما في SDP هي $Request.RequestID. تُرجَم الصيغة آلياً؛ ويُراجَع النص يدوياً.

المرحلة 8 — التشغيل المتوازي لأربعة أسابيع

الانتقال النهائي في عطلة نهاية أسبوع واحدة قمار محض. أما تشغيل SDP وLinaDesk بالتوازي لأربعة أسابيع فليس كذلك — إذ يحوّل القمار إلى تمرين هندسي.

التسلسل الذي نوصي به:

1. الأسبوع -4: نشر LinaDesk. استيراد البيانات التاريخية. يمتلك جميع فنيي المستوى الأول بيانات دخول وأكملوا جلسة تدريب مدتها 90 دقيقة. يظل توجيه البريد الإلكتروني يشير إلى SDP.
2. الأسبوع -3: تشغيل عمليات إعادة استيراد ليلية مقابل واجهة الفروقات (delta API) في SDP، مع إبقاء LinaDesk ضمن فارق 24 ساعة عن SDP. يُطلَب من الفنيين فحص عشر تذاكر جديدة يومياً في LinaDesk وتسجيل الأخطاء. تبقى البوابة معطّلة.
3. الأسبوع -2: توجيه 15 بالمئة من البريد الوارد إلى LinaDesk. يتعامل الفنيون مع كلتا القائمتين. تُولَّد التقارير بشكل مزدوج وتُقارَن.
4. الأسبوع -1: توجيه 50 بالمئة من البريد الوارد إلى LinaDesk. فتح النسخة التجريبية من البوابة لمجموعة صغيرة من طالبي الخدمة التجريبيين. أي تباين في المستوى P0/P1 يوقف الانتقال النهائي.
5. عطلة نهاية أسبوع الانتقال النهائي: إعادة استيراد الفروقات النهائية. تحويل توجيه البريد الإلكتروني بالكامل إلى LinaDesk. فتح البوابة لجميع طالبي الخدمة. تحويل SDP إلى وضع القراءة فقط؛ يبقى متصلاً لمدة 90 يوماً لأغراض التدقيق.

فترة القراءة فقط التي تمتد 90 يوماً مهمة. تطرح الجهات التنظيمية (والتدقيق الداخلي) أحياناً أسئلة تتطلب رؤية شكل التذكرة في النظام المصدر في تاريخ محدد. حذف SDP في اليوم التالي للانتقال النهائي خطأ رأيناه مرتين، وانتهى في المرتين بمحادثة قانونية غير مريحة بشأن تجميد البيانات.

قائمة التحقق بعد الانتقال

قبل توقيعك على الإنجاز:

• تطابق عدد التذاكر: SDP.count(status=Closed, year=2024) يساوي LinaDesk.count(status=Closed, CreatedAtUtc between 2024-01-01 and 2024-12-31) ضمن هامش ±0.1%.
• حساب طالبي الخدمة اليتامى: كل مستخدم في orphans.csv إما لديه سجل بديل في LinaDesk أو استُبعِد صراحةً، وتُظهر تذاكره التاريخية اسم طالب الخدمة محفوظاً في متن التذكرة.
• تكافؤ تقارير اتفاقية مستوى الخدمة: اسحب تقرير الامتثال لاتفاقية مستوى الخدمة للربع السابق من SDP ومن LinaDesk؛ يجب أن تكون الأرقام ضمن هامش ±1%. الفروقات الأكبر تشير إلى خطأ في إعداد التقويم أو حالة الإيقاف المؤقت.
• سلامة المرفقات: أخذ عيّنة من 200 تذكرة عشوائية على مدى السنوات الخمس الأخيرة والتحقق من أن كل مرفق يفتح بنجاح.
• بحث قاعدة المعرفة: ابحث عن أكثر خمس مقالات مشاهدةً في قاعدة المعرفة داخل LinaDesk وتأكد من ظهورها ضمن أفضل خمس نتائج.
• التكاملات: تحقّق من أن كل webhook أُعيد توجيهه، وكل مزامنة LDAP، وكل استدعاء API صادر قد عمل بنجاح مرتين على الأقل.

أخطاء شائعة

ميزات موجودة في SDP لكن غير موجودة في LinaDesk الإصدار 1

القائمة الصادقة. لا يشمل LinaDesk v1 ما يلي:

• وحدة إدارة المشاريع. تُستخدَم وحدة Projects الفرعية في SDP من قِبل حوالي 15% من عملاء SDP؛ إذا كنت أحدهم، فهذا قرار يتعلق بنطاق العمل، لا حلاً مؤقتاً.
• طبقة تعدد المستأجرين لشركات MSP. LinaDesk مصمم ليكون أحادي المستأجر — يشغّل كل عميل نسخته الخاصة.
• تطبيق جوال أصلي. واجهة الويب في LinaDesk متجاوبة مع الجوال، لكن الغلاف الأصلي مدرج في خارطة طريق الإصدار 1.2، لا في الإصدار 1.

إذا كان أي من هذه العناصر أساسياً لعملياتك، فحلّها خلال مرحلة الاستكشاف، لا في الأسبوع السابق للانتقال النهائي.

التقليل من تقدير نطاق انتقال الحقول المخصصة

كل عملية انتقال فحصناها كانت تحتوي على حقل مخصص واحد على الأقل مملوء في 60% من التذاكر التاريخية لكن في 3% فقط من تذاكر العام الأخير. توقف شخص ما عن استخدامه منذ سنوات ولم يزله أحد. انقله على أي حال — البيانات اليتيمة تبقى بيانات مرئية للتدقيق.

الوثوق بواجهة تصدير "النطاق الزمني" في SDP

تحدّ واجهة التصدير في SDP بصمت عدد الصفوف عند 5,000 في بعض الإصدارات وعند 10,000 في إصدارات أخرى، دون ظهور أي خطأ — فقط ملف CSV مقتطَع. استخدم دائماً الواجهة البرمجية لأي شيء يتجاوز بضع مئات من الصفوف.

قراءات ذات صلة

• لماذا تشهد أنظمة إدارة خدمات تقنية المعلومات المحلية لحظة صعود في 2026
• تصميم تقويمات اتفاقية مستوى الخدمة التي تصمد أمام تغييرات الورديات والعطلات الرسمية
• LinaDesk مقابل ServiceNow وManageEngine وFreshservice — جدول مقارنة
• الأمان والامتثال في LinaDesk