الموافقة البشرية لوكلاء DevOps
التغييرات الخطرة تنتظر موافقة المهندس المناوب.
يقرر المهندس على هاتفه قبل أن يغيّر وكيلك البنية التحتية.
كيف يحصل وكيل DevOps على موافقة المهندس المناوب؟
يسأل Pushary المهندس المناوب على هاتفه. ضع استدعاءً واحدًا قبل الترحيل أو إعادة التشغيل أو خفض السعة. يوافق المهندس أو يرفض من شاشة القفل بينما ينتظر الوكيل. إذا لم تصل إجابة في الوقت المحدد، لا يُنفّذ التغيير. يُحفظ كل قرار مع صاحبه ووقته لمراجعة الحادث لاحقًا.
ما يحتاج إلى موافقة
إجراءات لا ينبغي تنفيذها تلقائيًا
- runMigration(name)
- ترحيل يصعب التراجع عنه يستحق مراجعة بشرية، حتى ليلًا. الوكيل لا يتحمل هذه المسؤولية تلقائيًا.
- scaleDown(service, replicas)
- خفض السعة أثناء مشكلة شُخّصت خطأ قد يحول البطء إلى انقطاع كامل.
- rotateSecret(name)
- تغيير مفتاح قد يعطّل كل خدمة ما زالت تستخدم القيمة القديمة. هذا يحتاج إلى تقدير، لا إلى حد رقمي فقط.
- deleteResource(arn)
- قد يبقى مورد يبدو غير مستخدم ضروريًا. لا ينبغي لوكيل التنظيف حذفه دون مراجعة.
- promoteToProduction(sha)
- عند النشر يتأثر المستخدمون الحقيقيون بالخطأ، بدلًا من أن تكتشفه الاختبارات قبل وصوله إليهم.
الكود
استدعاء واحد ضمن خطوتك الحالية
اربط الإجراء المعني بالموافقة، لا الوكيل كله. تستمر المهام الآمنة دون سؤال أحد.
pip install pusharyimport os
from pushary import PusharyServer
px = PusharyServer(api_key=os.environ["PUSHARY_API_KEY"])
def remediate(incident, plan):
# Read-only diagnosis and reversible fixes run unattended.
if plan.reversible and plan.blast_radius == "single-pod":
return apply(plan)
decision = px.decisions.ask(
external_id=incident.on_call_id,
type="confirm",
question=f"{plan.summary}\nBlast radius: {plan.blast_radius}. Reversible: {plan.reversible}.",
)
if not decision["approved"]:
return page_secondary(incident, reason="human declined automated remediation")
return apply(plan)من يقرر
اتخاذ القرار لا يتطلب الجلوس أمام المكتب
المهندس المناوب ليس دائمًا أمام الطرفية. يفيد السؤال في قناة الدردشة إذا كان يتابعها وتصله إشعاراتها. وإلا يبقى التغيير محجوبًا بينما تستمر المشكلة. يصل Pushary إلى هاتفه باستخدام معرّف المستخدم في جدول المناوبة.
نرسل الموافقات إلى Slack بالفعل. ما الفرق؟
تُظهر الرسالة السؤال. لكن انتظار الوكيل لقرار يتطلب أيضًا جوابًا يستطيع الكود استخدامه، ومهلة، وطلبات محفوظة بعد إعادة التشغيل، وسجلًا للقرارات. إذا اكتفيت برسالة دردشة فعليك بناء هذه الأجزاء. وتصبح مهمة خاصة عند نشر إصلاح أثناء حادث. يحفظ Pushary الطلب ويعيد الإجابة إلى كودك. إذا كان فريقك يستخدم Slack، يمكن أن يصل السؤال إليه أيضًا. تُحفظ الإجابات في مكان واحد بدل تشتتها في سجل القنوات. يبقى منطقك هو الذي يحدد الإجراءات التي تحتاج إلى موافقة؛ لا تتغير سياسة المناوبة أو إدارة التغيير لديك.
أضفه إلى منتجك. لا يحتاج مستخدموك إلى حساب Pushary ولا يدفعون لنا شيئًا.
أسئلة شائعة
إجابات عن أسئلتك
هل يستمر الانتظار بعد نشر نسخة جديدة؟
هل يمكن توجيه السؤال وفق جدول المناوبة؟
كيف نتجنب سؤال أحد عن كل تغيير بسيط؟
ما السجل الذي يمكن تقديمه للمدقق؟
الموافقة البشرية لمنتجات أخرى
اترك القرار للإنسان في الخطوة التي تحتاج إليه.
اربط كل مستخدم مرة واحدة، واسأل باستدعاء واحد، ولا تنفّذ إلا بعد الموافقة. تُحفظ كل إجابة.
Start free