Skip to main content
تجمع المشكلة مرات حدوث الأخطاء التي تشترك في بصمة واحدة. اقرأ ملخص المجموعة وحدوثًا واحدًا قبل أن تغيّر الحالة أو الأولوية أو المسؤول. تغيير الحالة أو الأولوية أو المسؤول يوثّق قرارًا للفريق. ولا يصلح البرنامج ولا يعيد كتابة الأحداث الملتقَطة. ثبّت LogBrew CLI وشغّل logbrew login قبل أن تبدأ.

​
المشكلات ومرات الحدوث

تُرجع قائمة المشكلات ملخصًا للمجموعة، وليس حدثًا كاملًا. اقرأ هذه الحقول قبل أن تفتح التفاصيل: عدد مرات الحدوث ليس عدد المستخدمين المتأثرين. تنطبق الأعداد والأوقات على النطاق المُرجَع، لا على تاريخ الأخطاء كله. ويحدّ عامل التصفية --since أو --until من مرات الحدوث التي يعدّها LogBrew. عندما تُبلغ عن عدد، فاذكر معه عوامل التصفية التي أنتجته.

​
قيم الحالة

كان اسم archived سابقًا ignored. يختار الاسمان المشكلات نفسها، ويُقبل كلاهما في الإدخال. يعرض logbrew read وlogbrew issues والإصداران 2 و3 من الـ API القيمة archived. أما الإصدار 1 من الـ API (الافتراضي)، وبثّ المتابعة المباشرة، واستجابة التحقيق في المشكلة فتعرض ignored. وتعرض لوحة التحكم هذه الحالات بالأسماء «غير محلولة» و«محلولة» و«مؤرشفة». تنطبق الحالة على المشكلة كلها، لا على حدوث واحد. تُظهر الخطورة درجة الإلحاح، وتوثّق الحالة القرار. أبقِ الاثنين منفصلين. يمكن أن تصبح مشكلة critical بالحالة resolved بعد إصلاح تم التحقق منه. وتحتفظ المشكلة archived بخطورتها الملتقَطة. لا يعيد LogBrew فتح مشكلة محلولة تلقائيًا. عندما يصل حدوث جديد بعد الحل، يُبلغ التحقيق عن lifecycle.effective_status بالقيمة regressed. وتبقى قيمة status هي resolved إلى أن يعيد شخص فتح المشكلة.

​
الأولوية

تحدد الأولوية الترتيب الذي يفرز به الفريق المشكلات: لكل مشكلة أولوية. إذا لم يحددها أحد، فإنها تتبع خطورة المشكلة: error وcritical تعطيان high، وwarning تعطي medium، وinfo تعطي low. عندما تغيّر قاعدة مشكلات الخطورة، تتبع الأولوية triage.effective_severity. وعندها تكون قيمة priority_source هي derived. وعندما يحدد شخص الأولوية، تبقى ثابتة وتكون قيمة priority_source هي manual. لعرض المشكلات التي يجب فحصها أولًا:

​
إسناد المشكلات

أسند المشكلة لتوضّح من المسؤول عن الخطوة التالية. عدد المسؤولين عن المشكلة 0 أو 1: حساب واحد أو فريق واحد.
1

اعرف من يمكن إسناد المشكلة إليه

تضم assignees كل حساب يستطيع قراءة المشروع، مع user_id وname وemail. وتضم teams كل فريق في المؤسسة التي يتبعها المشروع، مع team_id وslug وname. لا يمكنك إسناد مشكلة إلى حساب لا يستطيع قراءة المشروع، ولا إلى فريق من مؤسسة أخرى.
2

أسند المشكلة

استخدم me بدلًا من معرّف المستخدم لإسناد المشكلة إلى نفسك. واستخدم logbrew issues unassign "<issue_id>" --json لإزالة المسؤول. أضف --project لتغيير ما يصل إلى 100 مشكلة في مشروع واحد.
3

اقرأ مشكلاتك

استخدم --assignee my_teams لمشكلات فرقك، و--assignee "team:<team_id>" لفريق واحد، و--assignee none للمشكلات التي ليس لها مسؤول.
لإسناد المشكلات، تحتاج إلى صلاحية إدارة المشكلات في المشروع. وتسمح لك الصلاحية نفسها بتغيير الحالة والأولوية وقواعد الملكية وقواعد المشكلات والسجلات. وينشئ مالكو المؤسسة ومشرفوها الفرق ويختارون أعضاءها. ولا يمنح الفريق أعضاءه أي وصول إلى المشروع. عندما يفقد عضو الوصول إلى المشروع، لا تُظهر المشكلات المُسندة إليه أي مسؤول. وعندما يُحذف فريق، لا تُظهر المشكلات المُسندة إليه أي مسؤول كذلك. وتظهر هذه المشكلات في القراءات باستخدام --assignee none. إذا استعاد العضو الوصول، تُظهره المشكلات مسؤولًا مرة أخرى، ما لم يغيّر أحد المسؤول أو يُزِله في هذه الأثناء.

​
اعرف مالك المشكلة

تعرض النتيجة المالكين المقترحين، الأنسب أولًا، ومعهم suggested_assignee. ولكل مالك قيمة source: تعدّ inputs ما فحصه LogBrew من مسارات إطارات المكدّس والوحدات وقالب المسار والوسوم والقواعد. إذا كانت القائمة فارغة ولم تُظهر inputs أي مسارات، فهذا يعني أن المشكلة لا تحمل أدلة يمكن مطابقتها، لا أنها بلا مالك. اكتب قواعد الملكية في ملف نصي، قاعدة واحدة في كل سطر:
يطابق نمط path نهاية مسار إطار المكدّس، لذلك يطابق src/payments/** الإطارات داخل أي مجلد نشر. ويطابق * أي نص. المالكون عناوين بريد إلكتروني لحسابات أو #team-slug. وتأتي آخر قاعدة مطابِقة أولًا. ثم أرسل القواعد، أو ملف CODEOWNERS من GitHub، أو كليهما:
في CODEOWNERS، يشير البريد الإلكتروني إلى حساب، ويشير @org/team-slug إلى الفريق الذي يحمل ذلك الـ slug. والقواعد التي تذكر حسابًا بلا وصول إلى المشروع أو فريقًا غير معروف تفشل مع 422. ومالكو CODEOWNERS الذين لا يشيرون إلى أحد يظهرون في unresolved_owners. والملف الفارغ يمسح نصه.

​
اقرأ تاريخ المشكلة

يعرض التاريخ كل تغيير في الحالة والأولوية والمسؤول وقاعدة الخطورة، الأحدث أولًا، مع الحساب الذي أجراه. وينتهي بـ first_seen. والحساب الذي فقد الوصول إلى المشروع لا يبقى منه إلا معرّفه. استخدم --limit وقيم next_cursor لقراءة المزيد.

​
اقرأ صندوق الوارد

يعرض صندوق الوارد المشكلات التي أسندها إليك أو إلى فرقك أشخاص آخرون، الأحدث أولًا. وتعدّ unread الإسنادات التي جاءت بعد علامة القراءة. ويحرّك logbrew inbox read علامة القراءة إلى الآن. لا يرسل LogBrew بريدًا إلكترونيًا عن هذه الإسنادات. ولا يعرض صندوق الوارد إلا المشاريع التي تستطيع قراءتها الآن.

​
سير العمل الموصى به

1

اعرض المشكلات غير المحلولة في نطاق واحد

أبقِ عوامل التصفية نفسها في القراءات اللاحقة للقائمة. النتيجة الفارغة تعني أنه لا توجد مشكلة تطابق هذا النطاق، ولا تُثبت أن المشروع خالٍ من الأخطاء. انسخ معرّف المشكلة نفسه تمامًا، لا عنوانها.
2

اقرأ تفاصيل المشكلة

تأكد من أن المشروع المُرجَع صحيح قبل أن تتابع. تُرجع القراءات لقطة. اقرأ المشكلة مرة أخرى قبل أن تغيّر الحالة.
3

حقّق في حدوث واحد

لا تستخدم قراءات التفاصيل والتحقيق عوامل تصفية القائمة. قارن subject.project_id وevent.occurred_at والإصدار والبيئة بنطاقك. قد يكون الحدوث الموصى به أقدم من أحدث حدوث. اتبع التحقيق في مشكلة لمراجعة الأدلة كاملة.
4

اتبع أدلة التتبّع فقط عندما تكون متاحة

اقرأ التتبّع فقط عندما تكون قيمة correlations.trace.status هي available. استخدم معرّف التتبّع الوارد في الاستجابة. لا تختلق معرّفًا أبدًا.
لا تقبل قراءة التتبّع عامل تصفية زمنيًا. إذا كانت الحالة not_linked، فتابع بأدلة المشكلة.
5

تحقّق من النشر المرشّح

استخدم الحدوث الذي حقّقت فيه حدوثًا مرجعيًا. احصل على معرّف النشر من أدلة النشر أو من عملية الإصدار لديك.
عدم تكرار المشكلة خلال نافذة المراقبة لا يُثبت أن الإصلاح دائم. إذا كانت قيمة status هي insufficient_traffic أو unavailable، فأبقِ المشكلة unresolved. اتبع الإجراء التالي المُرجَع.
6

غيّر الحالة أو الأولوية أو المسؤول

شغّل أمرًا واحدًا. لا تطلب هذه الأوامر تأكيدًا، لذا تحقّق من معرّف المشكلة أولًا.
دون --project، يقبل كل أمر معرّف مشكلة واحدًا. تحقّق من رمز الخروج ومن قيم status وpriority وassignee المُرجَعة. إذا غابت النتيجة، فاقرأ المشكلة مرة أخرى قبل التغيير التالي.يمكن للبرامج النصية الأقدم استخدام logbrew set issue "<issue_id>" resolved والاختصارات resolve وignore وreopen. يضبط ignore الحالة archived.

​
تغيير عدة مشكلات دفعة واحدة

أضف --project لتغيير ما يصل إلى 100 مشكلة في مشروع واحد بأمر واحد:
يطبّق الأمر تغييرًا واحدًا على كل مشكلة. ولا يجوز أن يظهر معرّف المشكلة إلا مرة واحدة. يرفض الـ CLI أكثر من 100 معرّف أو أي معرّف مكرر قبل أن يرسل الطلب. وتحتوي النتيجة على عنصر واحد لكل مشكلة، بترتيب الأمر: لكل عنصر issue_id وoutcome وissue. وissue هي المشكلة بحالتها الحالية، أو null في حالة not_found. يمكنك تشغيل الأمر نفسه مرة أخرى بعد فشل في الشبكة. فالمشكلات التي تغيّرت تُظهر unchanged. لأكثر من 100 مشكلة، شغّل أوامر إضافية. وفي حالة النتيجة not_found، انسخ المعرّف مرة أخرى من قائمة مشكلات ذلك المشروع. راجع تحديث المشكلات دفعة واحدة لمعرفة طلب الـ API.

​
اختر الحالة التالية

  • أبقِها unresolved عندما يكون الإخفاق نشطًا أو لم يتم التحقق من الإصلاح. غياب التتبّع ليس سببًا لأرشفة المشكلة.
  • اضبط resolved بعد أن يقبل الفريق أدلة الإصلاح. الإصلاح المقترح ليس دليلًا.
  • اضبط archived لحالة مقبولة أو لإشارة خاصة بالاختبار فقط. ينطبق القرار على كل مرات حدوث المشكلة. لا يحتوي الأمر على حقل للسبب، لذا دوّن السبب في قيود العمل لدى فريقك.
  • أعد الفتح بالقيمة unresolved عندما يصل حدوث جديد بعد الحل. يحدده lifecycle.regression.first_reappeared_occurrence. قارنه بالحدوث الذي استُخدم للحل. لا تنشئ مشكلة مختلفة.

​
تسليم التحقيق

أعطِ الشخص التالي مراجع، لا تفريغًا خامًا للأحداث:
  • معرّف المشكلة وحالتها وأولويتها والمسؤول عنها وخطورتها.
  • المشروع والخدمة والبيئة والإصدار.
  • وقت أول ظهور ووقت آخر ظهور وعدد مرات الحدوث.
  • معرّف الحدوث المحدد وoccurrence_selection.reason.
  • fix.status وcause.status وقيمة provenance لكل منهما.
  • حالة التتبّع ومعرّفه، إن كانا متاحين.
  • حالة إعادة الإنتاج والأدلة المفقودة.
  • نتيجة التحقق من النشر المرشّح.
  • الإجراء التالي الذي أرجعته الاستجابة.
صنّف الأسباب والإصلاحات المقترحة على أنها مقترحات.

​
الاستعادة من أخطاء الـ CLI

تحقّق من رمز خروج العملية قبل أن تحلّل المخرجات. عند النجاح، يذهب JSON إلى المخرجات القياسية. خطأ التحليل ينتهي برمز الخروج 2. وخطأ وقت التشغيل ينتهي برمز الخروج 1. تذهب أخطاء JSON إلى الخطأ القياسي وتحتوي على ok: false وerror وmessage وnext. اعرض next على أنه إرشاد، ولا تشغّله تلقائيًا. مثلًا، الأمر logbrew issues archive "<issue_id_1>" "<issue_id_2>" --json لا يحتوي على --project. لذلك ينتهي برمز الخروج 2 قبل إرسال أي طلب، مع الخطأ invalid_issue_command. عندما يرفض الـ API طلبًا، تكون قيمة error هي api_error. اقرأ status لمعرفة حالة HTTP، وapi_code لمعرفة رمز خطأ الـ API. الاستجابة الفاشلة لا تُثبت أن تغيير الحالة أو الأولوية أو المسؤول لم يُحدث أثرًا. اقرأ المشكلة قبل أن تحاول مرة أخرى.

​
ما الذي يجعل المشكلة مفيدة

  • عنوان واضح ورسالة مقروءة.
  • بصمة ثابتة.
  • إطارات المكدّس، عندما تكون متاحة.
  • سياق الإصدار والبيئة والخدمة.
  • سياق التتبّع، عندما يُلتقَط مع الحدوث.
  • سمات صغيرة وذات صلة، لا تفريغات كاملة للحمولة.
راجع مرجع Telemetry API لمعرفة عوامل تصفية القوائم وعقود الاستجابات.