الموافقة البشرية لوكلاء DevOps

التغييرات الخطرة تنتظر موافقة المهندس المناوب.

يقرر المهندس على هاتفه قبل أن يغيّر وكيلك البنية التحتية.

كيف يحصل وكيل DevOps على موافقة المهندس المناوب؟

يسأل Pushary المهندس المناوب على هاتفه. ضع استدعاءً واحدًا قبل الترحيل أو إعادة التشغيل أو خفض السعة. يوافق المهندس أو يرفض من شاشة القفل بينما ينتظر الوكيل. إذا لم تصل إجابة في الوقت المحدد، لا يُنفّذ التغيير. يُحفظ كل قرار مع صاحبه ووقته لمراجعة الحادث لاحقًا.

ما يحتاج إلى موافقة

إجراءات لا ينبغي تنفيذها تلقائيًا

runMigration(name)
ترحيل يصعب التراجع عنه يستحق مراجعة بشرية، حتى ليلًا. الوكيل لا يتحمل هذه المسؤولية تلقائيًا.
scaleDown(service, replicas)
خفض السعة أثناء مشكلة شُخّصت خطأ قد يحول البطء إلى انقطاع كامل.
rotateSecret(name)
تغيير مفتاح قد يعطّل كل خدمة ما زالت تستخدم القيمة القديمة. هذا يحتاج إلى تقدير، لا إلى حد رقمي فقط.
deleteResource(arn)
قد يبقى مورد يبدو غير مستخدم ضروريًا. لا ينبغي لوكيل التنظيف حذفه دون مراجعة.
promoteToProduction(sha)
عند النشر يتأثر المستخدمون الحقيقيون بالخطأ، بدلًا من أن تكتشفه الاختبارات قبل وصوله إليهم.

الكود

استدعاء واحد ضمن خطوتك الحالية

اربط الإجراء المعني بالموافقة، لا الوكيل كله. تستمر المهام الآمنة دون سؤال أحد.

bash
pip install pushary
استدعاء واحد
import 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، يمكن أن يصل السؤال إليه أيضًا. تُحفظ الإجابات في مكان واحد بدل تشتتها في سجل القنوات. يبقى منطقك هو الذي يحدد الإجراءات التي تحتاج إلى موافقة؛ لا تتغير سياسة المناوبة أو إدارة التغيير لديك.

للمزيد: كتاب Google عن SRE: هندسة الإصدارات وإدارة التغيير.

$99/ شهريًا، خطة Partner

أضفه إلى منتجك. لا يحتاج مستخدموك إلى حساب Pushary ولا يدفعون لنا شيئًا.

What the Partner plan covers

أسئلة شائعة

إجابات عن أسئلتك

هل يستمر الانتظار بعد نشر نسخة جديدة؟
يبقى الطلب، لكن الانتظار داخل العملية لا يبقى. يحفظ Pushary الطلب المفتوح. سجّل معرّف القرار قبل إعادة التشغيل واستأنف عبر webhook موقّع أو بالاستعلام من API.
هل يمكن توجيه السؤال وفق جدول المناوبة؟
نعم. يختار منطق الجدول لديك معرّف الشخص الصحيح. دون إجابة يبقى التغيير محجوبًا، ويمكن للوكيل سؤال مهندس ثانٍ وفق مسار التصعيد الحالي.
كيف نتجنب سؤال أحد عن كل تغيير بسيط؟
اعتمد على قابلية التراجع ونطاق التأثير. يمكن للخطوات السهلة التراجع أن تعمل ثم تُراجع. أما الصعبة فتسأل أولًا. القائمة القصيرة تُقرأ بعناية أكبر.
ما السجل الذي يمكن تقديمه للمدقق؟
يحفظ الطلب السؤال والمعلومات المعروضة والإجابة والشخص والوقت. يمكن الاستعلام عنه وتصديره: 90 يومًا في Partner Launch و365 في Partner Growth. ويمكن لعنوان callback استقبال الإجابات عبر webhooks موقّعة لحفظها في نظام الأدلة لديك.

اترك القرار للإنسان في الخطوة التي تحتاج إليه.

اربط كل مستخدم مرة واحدة، واسأل باستدعاء واحد، ولا تنفّذ إلا بعد الموافقة. تُحفظ كل إجابة.

Start free