10 مشكلات تشغيلية نستمر في إيجادها داخل مشغلي FTTH
قائمة مُختبَرة ميدانياً بالمشكلات التي نمشي إليها في اليوم الأول لكل نشر تقريباً — وأنماط إصلاحها.
في الـ 24 شهراً الماضية دخلنا إلى المكاتب الخلفية لمشغلين بقواعد مشتركين تتراوح من 8,000 إلى 220,000. المشكلات الرئيسية تختلف. المشكلات الأساسية متطابقة تقريباً. هذه هي القائمة المُختبَرة ميدانياً — وما نستمر في فعله بشأنها.
1. نظاما NMS، واحد لكل مورّد OLT
كلما استحوذ مشغل على آخر، يظهر نظاما NMS. كل واحد هو "مصدر الحقيقة" لعتاده الخاص. المهندسون يبقون كلا العلامتين مفتوحتين. تحدث الأخطاء في الوصلات. التوحيد على NMS محايد المورد يدفع نفسه خلال 9–12 شهراً في التراخيص وحدها وخلال 3–4 أشهر في تقليل الأخطاء.
2. CRM لا يعرف ماذا تفعل الشبكة
خدمة العملاء على الخط مع مشترك يشتكي، والإشارة الوحيدة التي لديهم من الشبكة هي "نشط" / "غير نشط". إذا كان WAN المشترك أعلى لكن WiFi في CPE مُعد بشكل خاطئ، فليس لدى الوكيل طريقة لمعرفة ذلك. سد هذه الفجوة في الإشارة هو أكبر خطوة متاحة لمعظم المشغلين.
3. التوفير يستغرق وقتاً أطول مما ينبغي بسبب API مفقود واحد
في تسعة من كل عشرة متاجر توفير يدوي، يوجد أداة واحدة بالضبط (غالباً وحدة تحكم OLT) لا تملك API قابل للاستخدام. لذا شخص ما يُشغّل سكربت CLI. كل شيء آخر مُؤتمَت. تكلفة ذلك السكربت الواحد هي أيام من التأخير وذيل طويل من الأخطاء الطباعية.
4. الطوبولوجيا في ثلاث جداول بيانات مختلفة
الميدان لديه Google Sheet. الهندسة لديها Visio. NMS لديه رسمه البياني المُكتشف تلقائياً. لا أحد منهم يتفق. RCA لا يمكن أن يعمل بدون طوبولوجيا قانونية — والطوبولوجيا القانونية تعني مُشتقة من LLDP/CDP من الشبكة الحية، مُعزّزة يدوياً فقط عند الوصلات.
5. البرنامج الثابت قديم جداً — أو حديث جداً
لا توجد سياسة متسقة. إما أن CPEs تُشغّل برنامجاً ثابتاً عمره 4 سنوات مع CVEs معروفة، أو تم دفعها قسراً إلى أحدث نسخة بيتا الشهر الماضي و2% منها الآن تتعطل كل 12 ساعة. الإصلاح هو سياسة نشر مرحلية مع بوابات صحة، مضمنة في ACS.
6. أرضية ضوضاء الإنذارات مرتفعة جداً
NMS نموذجي يُظهر 4,000–20,000 إنذار شهرياً. NOC نموذجي يقرأ 50. الباقي يُرمى على الأرض ويدفن إحصائياً الحقيقية. قمع الذكاء الاصطناعي القائم على الطوبولوجيا والارتباط التاريخي يقطع الحجم المرئي بنسبة 80–95% دون فقدان القابلة للتنفيذ.
7. لا نسخة احتياطية لتكوين OLT النشط — في أي مكان
دخلنا إلى مراكز عمليات حيث الجهاز الأكثر تكلفة على الشبكة ليس لديه نسخة احتياطية لتكوين تشغيلي بعيد "حاسوب المهندس المحمول". عندما يموت ذلك OLT في ليلة السبت، وقت الاستعادة أيام، لا ساعات. النسخ الاحتياطية اليومية المُؤتمتة إلى إصدارات بنمط git هي متطلب أساسي.
8. RADIUS هو نقطة الفشل الفردية السرية
في المشغل الذي قِسناه آخر مرة، كل دقيقة من عدم توفر RADIUS تُكلّف تقريباً 400 جلسة وموجة من المكالمات الواردة. كان RADIUS يعمل على VM واحدة، خلف موازن حمل واحد، بدون تجاوز فشل مُتجمّع. هذا، بشكل مؤلم، أشيع تكوين نجده.
9. التقارير تستغرق ثلاثة أيام لإنتاجها
تقرير تنفيذي شهري لا ينبغي أن يستغرق ثلاثة أيام من وقت المحلل. يفعل ذلك، لأن البيانات تعيش في أربع أدوات والمحلل هو التكامل. توليد التقارير بمساعدة الذكاء الاصطناعي مع سرديات قوالب يحوّل ذلك إلى ساعة — والمحلل يقضي الوقت المُدّخر على شيء يستطيع البشر وحدهم فعله.
10. "المعرفة" تعيش في رأس شخصين
كل مزود إنترنت لديه مهندس واحد على الأقل يعرف بالضبط أي منفذ OLT يحتوي على SFP المشكوك فيه وأي مشترك سيتصل دائماً ليلة الجمعة. تلك المعرفة ليست مكتوبة. عندما يُغيّر المهندس وظائف، ستة أشهر من الجودة التشغيلية تذهب معه. تدوين المعرفة القبلية في المنصة — كسياسة، كبروفايلات، كمراقبات — هو العمل الذي يؤجله معظم المشغلين ويندمون على تأجيله.
كيف نقيّم في اليوم الأول
عندما نتعامل مع مشغل جديد، نُجري تدقيقاً مدته 90 دقيقة مقابل هذه الأنماط العشرة. الناتج خارطة حرارة: أحمر (إصلاح ذو أولوية)، عنبري (طابور)، أخضر (سليم بالفعل). ثلاثة أو أقل من الأحمر نادر.
