الصورة الرمزية: تذكرة دعم Tarvo
أسوأ وقت لكتابة تقرير حادثة DevOps هو بعد أن يتم تنبيه آخر.
خلال المكالمة، يكون شكل الحادث واضحًا. يشرح شخص ما ما الذي تعطل. تسأل عما تغير. تتحقق من السجلات، تعيد تشغيل خدمة، تعيد نشر، تختبر الوصول، تؤكد الاستعادة، وتخبر العميل بما سيحدث بعد ذلك.
ثم تنتهي المكالمة.
تتشتت التفاصيل في Slack، تاريخ المحطة، تعليقات التذاكر، لقطات المراقبة، والذاكرة.
تقرير حادثة DevOps من مكالمة يكون مفيدًا فقط إذا حافظ على الحادث بينما لا يزال الحادث حيًا.
عندما تكون مكالمة الحادث هي مصدر الحقيقة
حوّل مكالمات الدعم إلى سجلات حادثة نظيفة
تلتقط Superscribe Phone مكالمات الدعم الفني وتساعد في هيكلة المخرجات إلى ملاحظات الحادث، تحديثات التذاكر، ملخصات العملاء، المتابعات، وسياق قابل للفوترة.
النص المكتوب ليس تقرير حادثة
نص المكالمة الخام أفضل من لا شيء.
يمكن أن يثبت ما قيل. يمكن أن يساعدك في استعادة تفصيل. يمكن أن يمنع فشل الذاكرة الكلي.
لكن تقرير الحادث يحتاج إلى شكل مختلف.
يجب أن يجيب التقرير على:
- ما الذي تعطل
- من أو ما الذي تأثر
- متى بدأت المشكلة
- ما الذي تغير قبل ظهور المشكلة
- ما الذي تم التحقق منه
- ما الذي تم تغييره
- ما الذي أعاد الخدمة
- ما الذي لا يزال غير محلول
- ما الذي يجب أن يعرفه العميل
- ما الذي يجب أن تفعله الفريق بعد ذلك
تلك التفاصيل لا تصل بالترتيب خلال المكالمة.
قد يذكر العميل الزناد الرئيسي في منتصف الطريق. قد يتغير السبب المشتبه به ثلاث مرات. قد يحدث الإصلاح قرب النهاية. قد تكون المتابعة جملة واحدة قبل أن يعلق الجميع.
يتبع النص المحادثة.
يتبع تقرير الحادث العمل.
يجب أن يبدو المسودة الأولى المفيدة أقرب إلى هذا:
الحادث: أخطاء تسجيل الدخول إلى لوحة التحكم في الاتحاد الأوروبي
الخدمة المتأثرة: خدمة المصادقة / لوحة التحكم الخاصة بالعميل
الأعراض المبلغ عنها: رأى المستخدمون أخطاء 502 بعد تسجيل الدخول
السبب المحتمل: تحديث الخدمة تم شحنه قبل المكالمة
الإجراءات المتخذة: تم فحص السجلات، تأكيد الأخطاء، التراجع عن النشر، إعادة تعيين الذاكرة المؤقتة، اختبار تسجيل الدخول
حالة الحل: تم التخفيف، نراقب تكرار المشكلة
مالك المتابعة: الهندسة لمراجعة فحص الهجرة
تحديث آمن للعميل: تم استعادة الوصول ونحن نراقب الخدمة
سياق قابل للفوترة: استكشاف الأخطاء، التراجع، التحقق، ومراجعة المتابعة
هذا العنصر هو ما يريده تارفو. ليس ملخص اجتماع الذكاء الاصطناعي.
ما يجب أن يتضمنه تقرير الحادث القائم على المكالمات
بالنسبة لعمل DevOps والبنية التحتية، يكون التقرير المفيد عادةً قصيرًا ومنظمًا وقابلًا للمراجعة.
1. ملخص الحادث
ابدأ بالإصدار البسيط.
سيء:
- “الموقع كان معطلاً.”
أفضل:
- “لوحة التحكم الخاصة بالعميل عادت بأخطاء 502 للمستخدمين في منطقة الاتحاد الأوروبي بعد النشر. تم استعادة الخدمة بعد التراجع وإعادة تعيين الذاكرة المؤقتة.”
يجب أن يكون الملخص قابلاً للقراءة من قبل شخص لم يكن في المكالمة.
2. الخدمة أو النظام المتأثر
اذكر الخدمة، البيئة، العميل، الجهاز، الشبكة، قائمة الانتظار، الوظيفة، نقطة النهاية، أو التكامل المعني.
هذا يبدو بديهيًا حتى تراجع التذاكر القديمة التي تقول “مشكلة API” دون سياق مفيد.
3. الجدول الزمني
حوادث DevOps هي مشاكل زمنية.
يجب أن يفصل سجل المكالمة الجيد:
- وقت الإبلاغ الأول
- وقت البدء المحتمل
- وقت التصعيد
- الإجراءات المتخذة
- وقت الاسترداد
- مالك المتابعة
لا يحتاج الجدول الزمني إلى أن يصبح تشريحًا رسميًا في كل مرة. يحتاج فقط إلى هيكل كافٍ يمكنك من فهم ما حدث لاحقًا.
4. التغييرات والسبب المحتمل
هنا تفشل العديد من التقارير.
الدليل المفيد غالبًا ما يكون تعليقًا جانبيًا:
- “قمنا بشحن تغيير المصادقة هذا الصباح.”
- “تم تجديد الشهادة ليلة أمس.”
- “تم تحديث قاعدة جدار الحماية قبل الغداء.”
- “انتقل العميل إلى مكاتب جديدة أمس.”
- “بدأت الطابور يتزايد بعد عملية الاستيراد.”
إذا كانت المكالمة تلتقط تلك التفاصيل ولكن التقرير لا يفعل، فإن سجل الحادث يكون أضعف من المحادثة.
لا تترك الزناد في النص.
اسحب تفاصيل الحادث المفيدة إلى السجل.
تساعد Superscribe في تحويل مكالمات استكشاف الأخطاء المعقدة إلى ملاحظات منظمة للتذاكر، ملخصات الحوادث، تحديثات العملاء، وأعمال المتابعة.
5. الإجراءات المتخذة
هذا ليس مجرد تفاصيل داخلية. إنه دليل على العمل.
التقط ما تم فعله فعلاً:
- تحقق من السجلات
- راجع النشر
- اختبر نقطة النهاية
- أعد تشغيل الخدمة
- استعد التغيير
- امسح الطابور
- حدث DNS
- أكد وصول المستخدم
- أضف المراقبة
بالنسبة للمستشارين ومقدمي خدمات إدارة تكنولوجيا المعلومات، فإن هذا يدعم أيضًا مسار الفوترة. “تم إصلاح المشكلة” ليست مفيدة مثل تسلسل الفحوصات والتغييرات الفعلي.
6. الحل والحالة الحالية
يجب أن يجعل التقرير الحالة واضحة.
- تم الحل
- تم التخفيف
- المراقبة
- حل بديل موجود
- تصعيد البائع مفتوح
- تتطلب صيانة متابعة
هذا يمنع المشكلة الكلاسيكية في الدعم حيث يتذكر الجميع المكالمة بشكل مختلف.
7. ملخص آمن للعميل
الملاحظة الداخلية وملاحظة العميل ليستا نفس الشيء.
ملاحظة داخلية:
- النشر تسبب في أخطاء خدمة المصادقة في منطقة الاتحاد الأوروبي
- استعادة التراجع سجل الدخول
- تحتاج إلى مراجعة حول فحص الهجرة
ملخص آمن للعميل:
- وجدنا مشكلة تؤثر على تسجيل الدخول لبعض مستخدمي الاتحاد الأوروبي بعد تحديث الخدمة. تم استعادة الوصول. نحن نراجع التغيير ونراقب حدوثه مرة أخرى.
يجب أن تساعد سير العمل الجيد في إنشاء كلاهما، ثم تتيح للإنسان المراجعة قبل إرسال أي شيء.
لماذا هذا مهم لفرق DevOps الصغيرة
تم بناء أنظمة إدارة الحوادث الكبيرة للعمليات الأكبر.
إنها تتعامل مع جداول الاستدعاء، صفحات الحالة، سياسات التصعيد، التحليلات، ومسارات الامتثال.
غالبًا ما تحتاج فرق DevOps الصغيرة إلى جسر أبسط.
يحتاجون إلى مكالمة استكشاف الأخطاء الحية لتصبح السجل النظيف الأول.
هذا مهم عندما:
- يتصل عميل قبل وجود التذكرة
- يحدث الإصلاح بينما يتحدث الجميع
- المهندس هو أيضًا مالك الحساب
- يجب على نفس الشخص توثيق العمل وشرحه وفوترة العمل
- يبدأ الحادث التالي قبل كتابة الأول
تحتوي المكالمة بالفعل على تقرير الحادث. المشكلة هي استخراجها دون فقدان الوقت أو الدقة.
مكان Superscribe
تم تصميم Superscribe Phone للمكالمات التي تخلق متابعة.
بالنسبة لـ DevOps ودعم تكنولوجيا المعلومات، يعني ذلك أن المحادثة الهاتفية يمكن أن تصبح سياق حادث منظم: الجدول الزمني، النظام المتأثر، الإجراءات المتخذة، الحل، الخطوات التالية، تحديث العميل، وملاحظة قابلة للفوترة.
يمكن أن تتحرك المخرجات نحو التذاكر، الملخصات، المتابعات، واجهات برمجة التطبيقات، OpenAI، MCP، أو سير عمل الوكلاء. النقطة ليست تخزين المزيد من التسجيلات. النقطة هي تقليل العمل على الصفحة الفارغة بعد المكالمة.
سير العمل ذات الصلة: تقارير الحوادث التلقائية من مكالمات الدعم, نسخ المكالمات لشركات تكنولوجيا المعلومات الصغيرة, أفضل تطبيق لملاحظات مكالمات دعم تكنولوجيا المعلومات، و كيف يتوقف مستشارو تكنولوجيا المعلومات عن فقدان الوقت القابل للفوترة بعد مكالمات الدعم.
قبل أن تسرق التنبيهات التالية التفاصيل
اجعل مكالمات الحوادث تنتج التقرير الأول
استخدم Superscribe Phone عندما تحتاج المكالمات الفنية إلى أن تصبح ملاحظات حادث مراجعة، تحديثات للعميل، مهام متابعة، وسياق قابل للفوترة.
اختبار بسيط:
إذا كان عليك إعادة تشغيل المكالمة، مسح Slack، فحص تاريخ الصدفة، وإعادة كتابة بريد العميل من الذاكرة، فإن خطوة الالتقاط قد فشلت.
يبدأ سير العمل الأفضل للحوادث في المكالمة.
ليس بعد أن يكون الجميع قد انتقل بالفعل.