تُعد الولاية بيانًا ثابتًا لما يجب على Coroid القيام به عندما لا يطلب أحد ذلك: هدف معين، المشاريع التي يشملها، ميزانية أسبوعية أو شهرية، ووقت التوقف عن التنفيذ. الطلبات الواردة من أنظمتك — مثل مدخل العمل API، والعمليات الآلية، والتكاملات، وأدوات المراقبة — تُقبل وفقًا للولايات النشطة لديك، بينما طلبات الأشخاص لا تُقبل بهذه الطريقة؛ انظر إلى الطلبات التي تغطيها كل ولاية.
تحدد الولاية العمل الذي يمكن بدءه، لكنها لا تسمح لـ Coroid بدمج أو نشر أي شيء. انظر إلى ما يقرره Coroid، وما يظل تحت مسؤوليتك.
متى تكون الولاية مناسبة؟
اكتب ولاية عندما يصل العمل إلى Coroid دون أن يطلب أحد تنفيذ كل جزء منه، وتريد تحديد مقدار ما يمكن إنجازه مسبقًا:
- أداة تتبع أخطاء أو مراقبة تقوم بالإبلاغ عن الحوادث عبر مدخل العمل API؛
- رسائل من GitHub، أو من Slack، Telegram، أو Jira، تُنقل إلى تصنيف العمل تحولها العمليات الآلية إلى طلبات؛
- أداة دعم أو ملاحظات تنقل ما يبلغ عنه العملاء؛
- ماسح ضوئي أو مهمة تكامل مستمر تقوم بتسجيل النتائج واحدة تلو الأخرى.
بدون ولاية، تُعامل هذه الطلبات مثل أي طلبات أخرى: بمجرد تصنيفها، تُضاف إلى قائمة الانتظار لنفس مساحات العمل الخاصة بالوكلاء التي يطلبها الأشخاص، دون ميزانية خاصة بها. وقد تملأ تنبيهات أسبوع مزدحم قائمة الانتظار لديك. أما الولاية فتحدد لها حدودًا: المشاريع التي يمكنها التأثير عليها، مقدار الإنفاق الأسبوعي أو الشهري، وعدد مساحات العمل التي يمكنها استخدامها في نفس الوقت.
كيف تسير عملية الطلب؟
يصل دون تدخل بشري
- تنبيه من أداة تتبع الأخطاء، يُرسل إلى نظام استقبال العمل API مع إشارته.
- مشكلة في GitHub، عبر أتمتة تأهيل العمل.
- تقرير من عميل عبر أداة الدعم الخاصة بك، يمر عبر نظام استقبال العمل API.
الطلب الذي يقدمه شخص ما في New Work يمر أيضًا عبر مرحلة التأهيل، لكن لا يوجد تكليف يعيقه.
التأهيل
تنقية البيانات، التحقق من الإصدار الحالي، إزالة التكرارات، التحقق، التقييم وتحديد المسار.
القبول
احرص على أن تكون مسارات API خالية من الاستثناءات غير المعالجة.
- المشاريع
- فواتير API
- الميزانية
- 100 دولار أمريكي و10 ساعات عمل للوكلاء أسبوعيًا
- حصص التكليف
- واحدة من أصل اثنتين قيد الاستخدام، نصف حصص الوكلاء الأربعة
- هل يتم التعامل مع نفس الحادثة بالفعل في أي مشروع؟
- هل وجد التقييم أن السلوك مقصود؟
- هل توجد حصة متاحة ضمن حصة التكليف؟
- هل لا تزال هناك ميزانية متبقية هذا الأسبوع؟
- هل يمكن قياس النتيجة، أم أن التكليف يسمح بعمل لا يمكن قياسه؟
يتم إنشاء المهمة بحصة محجوزة وجزء من ميزانية الأسبوع.
مرتبط بالعمل الذي يتعامل معه بالفعل. لا يتم إنشاء شيء جديد.
السلوك مقصود. لا يتم إنشاء أي شيء.
يتم التحقق منه كل دقيقة. يتم قبوله عندما تتوفر حصة أو ميزانية، أو ينتهي بعد انتظار أسبوع كامل.
بعد القبول
مهمة
مواصفات، خطة وكود، مثل أي مهمة أخرى.
التحقق
اختبارات، بوابات جودة، ضمان الجودة والمراجعة.
طلب سحب
على فرع منفصل، مقابل فرعك.
عقد النتائج
لا حدث جديد لهذه الحادثة لمدة 24 ساعة بعد 500 طلب على مساراتها.
خذ الولاية الموضحة في الرسم البياني، المخصصة لمشروع الفوترة API. تُصدر أداة تتبع الأخطاء فيه تنبيهًا عن استثناء جديد في تصدير الفواتير. يقوم رابط الويب الخاص بقاعدة التنبيه، عبر وسيط صغير من عندك، بتسجيله في مدخل العمل API، مع استخدام معرف الحالة في الأداة كبصمة للإشارة، والمسار المتأثر، و500 طلب كمقياس للتعرض قبل اعتبار الإصلاح ناجحًا.
- التصنيف يتم كما هو الحال مع أي طلب: إزالة البيانات السرية والشخصية، التحقق من الإصدار الحالي، البحث عن تكرارات، التحقق من التقرير وتقييمه.
- القبول يبحث عن الولاية التي تغطي مشروع الفوترة API ويتحقق، بالترتيب، مما يلي: هل يتم التعامل مع نفس الحالة بالفعل، سواء هنا أو في مشروع آخر؛ هل أظهر التقييم أن السلوك متوقع؛ هل توجد مساحة متاحة في إحدى الولايتين؛ هل توجد ميزانية متاحة لهذا الأسبوع؛ وهل يمكن قياس النتيجة؟
- تم قبوله، يصبح الطلب مهمة لها مساحة محجوزة وجزء من ميزانية الأسبوع، ثم يمر عبر المسار المعتاد — تحديد المواصفات، الكود، الاختبارات، بوابات الجودة، المراجعة — حتى يصبح pull request.
- يقوم شخص ما بدمجه النتيجة الخاصة بالمهمة عقد النتيجة يسجل ما يجب أن يحققه هذا الدمج: عدم ظهور حدث جديد متعلق بهذه الحالة بعد 500 طلب على المسار، ولمدة 24 ساعة.
إذا تم إطلاق نفس التنبيه مرة أخرى، فإن الطلب الثاني يُؤجل تم حله بالفعل ومرتبط بالأول. إذا تسبب نشر خاطئ في ظهور ست مشكلات جديدة دفعة واحدة، فلن يتم تشغيل أكثر من اثنتين ضمن الولاية في نفس الوقت؛ أما البقية فهي مؤجلة، ثم يتم قبولها واحدة تلو الأخرى عندما تتحرر مساحات الولاية. وتظل المساحتان المتبقيتان للوكلاء متاحتين لطلبات فريقك في قسم العمل الجديد.
أمثلة على الولايات
منع تراكم أخطاء الإنتاج
تقوم خدمات API الخاصة بك بتسجيل الأخطاء في أداة تتبع الأخطاء، ويتم إصلاحها عندما يتوفر وقت لدى أحد المستخدمين.
| إعداد | قيمة |
|---|---|
| نوع | جاري التنفيذ |
| هدف | الحفاظ على مسارات نظام الفوترة التابع لـ API خالية من الاستثناءات غير المعالجة |
| مشاريع | نظام الفوترة التابع لـ API |
| ميزانية | 100 دولار أمريكي و10 ساعات عمل للوكلاء في الأسبوع |
| قبول العمل الذي لا يمكن قياس نتيجته | مغلق |
| تاريخ المراجعة | بعد أربعة أسابيع |
تصل الطلبات من أداة تتبع الأخطاء عبر نظام استقبال العمل API، وكل طلب يحتوي على
signal يحدد معرف المشكلة في أداة التتبع، والمسارات، وعدد الطلبات. وتصبح كل مشكلة على الأكثر جزءًا واحدًا من العمل، بغض النظر عن عدد مرات تكرارها. ولا تتجاوز تكلفة أسبوع سيء 100 دولار أمريكي. أما التنبيه المرسل بدون مسارات فينتظر بدلاً من أن يبدأ، لأنه لا يمكن معرفة ما إذا كان إصلاحه قد نجح؛ أرسل المسارات، أو قم بتفعيل قبول
العمل الذي لا يمكن قياس نتيجته.
العمل على إصلاح الأخطاء المبلغ عنها في GitHub
يقوم المستخدمون بفتح مشكلات في مستودع تطبيق الويب الخاص بك بشكل أسرع مما يمكن لأي شخص تصنيفها.
| إعداد | قيمة |
|---|---|
| نوع | جاري التنفيذ |
| هدف | إصلاح الأخطاء التي يبلغ عنها المستخدمون في تطبيق الويب |
| مشاريع | تطبيق ويب |
| ميزانية | 200 دولار أمريكي و30 ساعة عمل للوكلاء شهريًا |
| قبول مهام لا يمكن قياس نتائجها | تشغيل |
أ تقييم المهام تقوم آلية الأتمتة في إصدارات GitHub الجديدة بإنشاء طلب لكل مشكلة. يمنع التقييم حدوث تكرارات، ويصدر تقارير عن مشاكل تم إصلاحها بالفعل في الإصدار الحالي أو عن عدم إمكانية إعادة إنتاجها. يتم تشغيل مفتاح القابلية للقياس لأن المشكلة لا تحدد مسارات أو حركة مرور، مما يجعل من المستحيل قياس عقد النتائج؛ وعند إيقاف تشغيل المفتاح، ستنتظر كل مشكلة. تُفتح المشاكل التي يطلقها أشخاص لديهم صلاحيات كتابة بشكل تلقائي؛ بينما تنتظر الباقية أن يبدأ أحدهم تنفيذها، كما هو موضح في عند بدء تنفيذ المهمة.
التصرف بناءً على تقارير العملاء
تجمع أداة الدعم الخاصة بك تقارير من العملاء، وتصل التقارير العاجلة إلى قسم الهندسة متأخرة.
| إعداد | قيمة |
|---|---|
| نوع | جاري التنفيذ |
| هدف | إصلاح ما يبلغ عنه العملاء في بوابة العملاء |
| مشاريع | بوابة العملاء |
| ميزانية | 150 دولار أمريكي و15 ساعة عمل للوكلاء أسبوعيًا |
| قبول مهام لا يمكن قياس نتائجها | تشغيل |
تسجل أداة الدعم كل تقرير عبر نظام استقبال المهام API باستخدام حساب خدمة. يرفض التقييم ما لا يمكن إعادة إنتاجه، ويحدد التوجيه سقفًا يمنع أسبوعًا مزدحمًا من التقارير من استهلاك أكثر من نصف حصص الوكلاء أو تجاوز ميزانيته.
إنهاء عملية التنظيف قبل الموعد النهائي
تصل نهاية دورة حياة حزمة تطوير البرامج الخاصة بالدفع التي تستخدمها في الربع القادم، وتنتشر استدعاءاتها المتقادمة عبر خدمتين.
| إعداد | قيمة |
|---|---|
| نوع | محدود |
| هدف | إزالة كل استدعاءات حزمة تطوير البرامج الخاصة بالدفع المتقادمة |
| الهدف | أقل من 0 استدعاء لحزمة تطوير البرامج الخاصة بالدفع المتقادمة |
| مشاريع | صفحة الدفع، الفوترة API |
| ميزانية | 300 دولار أمريكي و40 ساعة عمل للوكلاء شهريًا |
| قبول مهام لا يمكن قياس نتائجها | تشغيل |
يقوم مهمة CI بإنشاء طلب واحد لكل موقع استدعاء، حيث تُستخدم معلومات الملف والسطر كبصمة للإشارة، وبالتالي يتم ربط أي موقع استدعاء يظهر مجددًا في التشغيل التالي بالعمل الذي يتعامل معه بالفعل. لا تقوم Coroid بقراءة الهدف بعد؛ عندما يختفي آخر استدعاء، اختر إكمال بنفسك.
عندما لا تحتاج إلى تفويض
- العمل الذي يطلبه الأفراد. تتم قبول الطلبات التي تم إنشاؤها في قسم العمل الجديد أو المستوردة عندما تتوافق مع الشروط، دون تأجيلها أبدًا، ودون استهلاك ميزانية التفويض.
- جداول زمنية ومتابعة الربط. يقومون بإنشاء مهام مباشرة، دون الحاجة إلى مرحلة التأهيل، لذا لا تحدّهم أي تفويضات. بدلاً من ذلك، خصص لهم أولوية أقل؛ انظر جداول زمنية.
- مبادرة لمرة واحدة. العمل ذو الشكل المعروف والنهاية المحددة هو خطة، وليس تفويضًا.
- تفويضات متداخلة. عندما تغطي عدة تفويضات نشطة نفس المشروع، فإن أقدم تفويض هو من يحكم طلباته. يجب تخصيص كل مشروع لتفويض واحد.
أماكن وجود التفويضات
فتح ضبط الجودة ← تفويضات. كل نطاق في ضبط الجودة — الإعداد الافتراضي للمؤسسة وكل مشروع — يرتبط بنفس القائمة، لأن التفويض ينتمي إلى المؤسسة ويحدد مشاريعه بنفسه. فتح نطاق مشروع لا يُقيّد القائمة.
يقوم المالكون والمشرفون بإنشاء التفويضات وتعديلها. يمكن للأعضاء قراءتها. أما الوكلاء وحسابات الخدمة فلا يمكنهم تعديل أي تفويض على الإطلاق.
ما يحتويه التفويض
النوع. التفويضات المحدودة لها هدف ونهاية عند تحقيقه، مثل «خفض عدد الثغرات الأمنية المفتوحة إلى الصفر». التفويضات المستمرة هي أعمال صيانة، مثل «الحفاظ على خلو مسارات الإنتاج من الاستثناءات غير المعالجة»؛ لها تاريخ مراجعة بدلاً من هدف محدد.
الهدف. جملة واحدة توضح ما يجب أن يكون عليه الوضع. هي الطريقة التي يقرأ بها الأفراد التفويض؛ أما عملية القبول فتتم وفقًا للنطاق والميزانية والحالة.
خط الأساس. المقياس الذي يتم قياس التفويض بناءً عليه، ومصدره. أنت تحدد اسم المقياس، ويتم جمع القراءات بواسطة Coroid، ولا يتم إدخالها يدويًا. كما أنها لا تظهر في ملفات تصدير الإعدادات. يعرض التفويض الجديد لا توجد قراءة حتى الآن.
الهدف. بالنسبة للتفويض المحدود: المقياس والقيمة اللتان تعنيان اكتمال العمل.
الأولويات. واحدة لكل سطر. عندما يتنافس العمل على القدرة، تكون الأولوية الأولى هي الحاسمة.
النطاق.
- مشاريع. المشاريع التي يغطيها التكليف. إذا لم يتم تحديد أي مشروع، فإنه يغطي كل مشاريع المؤسسة، بما في ذلك المشاريع التي سيتم إنشاؤها لاحقًا. حدد المشاريع المراد تضمينها؛ يجب أن يذكر التكليف المخصص لمستودع واحد اسم ذلك المشروع.
- المناطق. أنماط المسارات داخل تلك المشاريع، واحدة لكل سطر، على سبيل المثال
apps/api-*/src/**. القيمة الفارغة تعني أي مكان. - فئات التغيير. أنواع التغييرات التي ينطبق عليها التكليف، على سبيل المثال
exception_fix. - السماح بقبول الأعمال التي لا يمكن قياس نتائجها. معطل بشكل افتراضي. عندما يكون معطلًا، فإن الطلب الذي عقد النتيجة لا يمكن قياسه يظل في انتظار التنفيذ بدلاً من البدء.
الميزانية. المبلغ الذي يمكن لـ Coroid إنفاقه على التكليف في كل فترة، بالدولار الأمريكي وساعات العمل للوكيل، أسبوعيًا أو شهريًا. تبدأ الأسبوعية يوم الاثنين الساعة 00 بتوقيت UTC؛ وتبدأ الشهرية في أول يوم من الشهر. تُفتح الميزانية تلقائيًا مرة أخرى.:00 UTC؛ وتبدأ الشهرية في أول يوم من الشهر. تُفتح الميزانية تلقائيًا مرة أخرى.
شروط التوقف. يتوقف عند نفاد الميزانية، أو عند تحقيق الهدف، أو بعد عدد معين من النتائج غير الحاسمة المتتالية، أو في تاريخ محدد.
تاريخ المراجعة. بالنسبة لتكليف قيد التنفيذ: التاريخ الذي يقوم فيه شخص ما بتجديده أو إنهائه.
قاعدة الانحراف. بالنسبة لتكليف قيد التنفيذ: حد أقصى للمقياس الأساسي. تجاوزه في فترة معينة يستوجب إرسال تنبيه إلى صاحب الصلاحية.
الحالة والإصدارات
يبدأ التكليف كـ مسودة. نشر يجعله نشط، وفقط التكاليف النشطة هي التي تسمح بقبول الأعمال.
| إجراء | تأثير |
|---|---|
| إيقاف / استئناف | يوقف قبول الأعمال ويستأنفه؛ الأعمال الجارية ستكتمل. |
| تعليق | يوقف قبول الطلبات حتى يتم تحديد سبب ذلك. |
| إكمال | ينهي تطبيق التوجيه الذي تم تحقيق هدفه. |
| إلغاء | ينهيه بشكل نهائي؛ لا يمكن إعادة تفعيل تطبيق التوجيه الملغى، لكن إصداراته وتاريخه يظلان محفوظين. |
تعديل تطبيق توجيه منشور يؤدي إلى نشر إصدار جديد؛ تظل الإصدارات السابقة محفوظة مع معلومات عن من نشرها ومتى.
كل عملية نشر وتغيير في الحالة تُعد قرارًا متعلقًا بتطبيق التوجيه.
المنشأ، مع ذكر الشخص الذي أنشأه، بالإضافة إلى حدث مسجل في سجل التدقيق الخاص بمنظمتك (mandate.created، mandate.published،
mandate.paused وما إلى ذلك).
الطلبات التي يغطيها تطبيق التوجيه
يغطي تطبيق التوجيه الطلبات التي تصل دون وجود شخص في Coroid: من نظام استقبال العمل API، ومن عمليات الأتمتة والتكامل مثل GitHub أو تذاكر Jira، بالإضافة إلى عمليات المراقبة.
الطلب الذي يقدمه شخص ما في عمل جديد، أو الطلبات المستوردة، لا تخضع لتطبيق التوجيه؛ فهي تُقبل دائمًا عند توافقها مع الشروط، ولا يتم تأجيلها، ولا تستهلك ميزانية تطبيق التوجيه. لأن الشخص طلبها بنفسه؛ تقوم وحدات توزيع الوكلاء بوضعها في قائمة الانتظار ببساطة.
يتم مطابقة الطلب غير المراقب مع أقدم تطبيق توجيه نشط تشمل مشاريعه مشروع الطلب، أو التطبيق الذي يغطي جميع المشاريع. أما الطلب الذي لا يغطيه أي تطبيق توجيه فيُقبل كطلب عادي.
ما يحدده قرار القبول
القبول هو الخطوة الأخيرة من التأهيل. ولا يقوم باستدعاء أي نموذج؛ فبالنسبة لكل طلب يقرر أحد الخيارات التالية:
- مقبول. يتم إنشاء العمل، مع تخصيص مساحة لوحدة الوكيل، وفي إطار تطبيق توجيه، تخصيص جزء من ميزانيته. أما بدء تنفيذه تلقائيًا فيعتمد على مصدره، كما هو موضح في متى يبدأ العمل.
- تم حله مسبقًا. نفس الإشارة — أي نفس المشكلة في نظام التتبع أو المراقبة، أو نفس العطل — يتم التعامل معها بالفعل ضمن طلب آخر في أي مشروع بالمنظمة؛ يتم ربط الطلب بهذا العمل، دون إنشاء أي شيء جديد.
- لا حاجة لتغيير. وجد تقييم التأهيل أن السلوك المبلغ عنه مقصود؛ لذا لا يتم إنشاء أي شيء.
- مؤجل. الطلب مقبول لكن لا ينبغي بدء تنفيذه الآن: فمساحة وحدات الوكلاء المخصصة له في تطبيق التوجيه مشغولة، أو ميزانيته للفترة الحالية قد استُهلكت، أو لا يمكن قياس نتيجته وTطبيق التوجيه لا يسمح بذلك.
كل قرار وسببه يتم تسجيله مع الطلب.
الطلبات المؤجلة
Coroid يتفقد الطلبات المؤجلة كل دقيقة ويقبلها فور توفر مساحة أو ميزانية، وفقًا للنسخة الحالية من التكليف. رفع ميزانية التكليف، أو إيقاف تكليف آخر يشغل مساحات، يحرر طلبًا مؤجلًا في الفحص التالي. لا توجد طريقة لتجاوز ذلك وبدء تنفيذ طلب مباشرةً.
الطلب الذي انتظر لأكثر من الفترة المحددة في تكليفه — أسبوع أو شهر — أو الذي لم يعد تكليفه نشطًا، ينتهي دون تنفيذ.
كيفية مشاركة القدرة بين مهام التكليف
يمكن لمهام التكليف أن تشغل ما يصل إلى نصف سعة منظمتك. مساحات الوكلاء في نفس الوقت، بما في ذلك العمل الجاري والعمل المقبول لكنه لم يبدأ بعد. يظل الباقي متاحًا لطلبات المستخدمين. إذا كان خطتك تحتوي على مساحات غير محدودة، فإن نفس النسبة تُطبق على ميزانية الإنفاق الشهرية بدلاً من ذلك.
الطلب المقبول يحتفظ بحجزه لمدة 30 دقيقة حتى يبدأ تنفيذ مهمته. بعد ذلك، ينتهي الحجز: الطلب الذي لم يتم إنشاء عمله بعد يعود إلى حالة مؤجلة، والمهمة الموجودة تنتظر مساحة مثل أي طلب آخر.
في ملف تصدير الإعدادات
تنتقل التكاليف ضمن ملف تصدير الإعدادات: النوع، الهدف، الوجهة، الأولويات، النطاق، الميزانية، شروط التوقف، تاريخ المراجعة وقاعدة الانحراف. تتم مطابقة المشاريع عبر مفتاحها الثابت، وصاحب الدور عبر دوره. لا تنتقل خطوط الأساس أبدًا؛ فهي مقاييس للمنظمة التي جاءت منها. التكليف ذو الهدف الجديد يصل كمسودة ليقوم الشخص بنشره. أما التكليف الذي يتطابق هدفه مع تكليف موجود، فيتم تحديثه: كمسودة إذا كانت لا تزال مسودة، وإلا كنسخة منشورة جديدة.