لماذا تسجيل الموافقات والأدلة أهم من مجرد الحصول على "موافقة"

لقد حصلت للتو على موافقة شفهية من مديرك لنشر تغيير في قاعدة البيانات في وقت متأخر من الليل. قال "امضِ قدمًا"، قمت بالنشر، وبدا كل شيء على ما يرام. بعد أسبوع، حدث عطل. أثناء المراجعة البعدية، تقول إن مديرك وافق. يقول مديرك إنه لا يتذكر الموافقة على أي شيء من هذا القبيل. الآن أنت تتعامل مع مشكلتين: المشكلة الفنية التي تسببت في الانقطاع، ونزاع حول من أذن بالتغيير.

هذا السيناريو يتكرر أكثر مما يعترف به معظم الفرق. الموافقة حدثت، لكن لا يوجد سجل لها. لا دليل على من قال نعم، متى قالها، أو ماذا رأى قبل الموافقة. بدون هذا السجل، الموافقة قد لا تكون قد حدثت أبدًا.

ما يجب أن يلتقطه سجل الموافقة الحقيقي

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

إليك ما قد يبدو عليه سجل الموافقة الكامل في سجل تدقيق خط الأنابيب:

{
  "change_id": "DEPLOY-2024-11-05-142",
  "approver": {
    "name": "alice.chen",
    "role": "engineering_manager"
  },
  "timestamp": "2024-11-05T14:30:00Z",
  "evidence": [
    {
      "type": "test_results",
      "url": "https://ci.internal/pipeline/1234/test-report"
    },
    {
      "type": "security_scan",
      "summary": "0 critical, 2 high, 5 medium findings - all waived per policy"
    },
    {
      "type": "change_request",
      "url": "https://tickets.internal/CR-7890"
    }
  ]
}

من وافق

يحتاج خط الأنابيب إلى تسجيل هوية الشخص الذي منح الموافقة. ليس فقط الاسم، ولكن دوره في الفريق. هل كان قائد الفريق التقني، مدير الهندسة، أو مسؤول قاعدة البيانات؟ الدور مهم لأنه يخبرك ما إذا كان ذلك الشخص يمتلك السلطة للموافقة على هذا النوع من التغيير.

الأهم من ذلك، يحتاج النظام إلى التحقق من أن الموافقة جاءت بالفعل من ذلك الشخص، وليس من شخص آخر يستخدم حسابه. لهذا السبب يجب أن تعمل سير عمل الموافقة من خلال أنظمة متكاملة مع مصادقة فريقك، وليس من خلال رسائل الدردشة أو البريد الإلكتروني التي يمكن تزويرها أو إعادة توجيهها بسهولة. إذا كان بإمكان شخص ما نسخ ولصق رسالة "تمت الموافقة" من محادثة Slack، فليس لديك نظام موافقة. لديك لعبة لقطات شاشة.

متى تمت الموافقة

يجب أن يتضمن الطابع الزمني الدقائق والمنطقة الزمنية. قد يبدو هذا مبالغًا فيه حتى تحتاج إلى إعادة بناء تسلسل الأحداث أثناء التحقيق في حادث.

ضع في اعتبارك هذا الجدول الزمني:

• تم تقديم التغيير الساعة 14:00
• تم تقديم الموافقة الساعة 14:30
• النشر إلى الإنتاج الساعة 14:45
• تم اكتشاف الحادث الساعة 15:10

مع طوابع زمنية نظيفة، يمكنك رؤية كيف تطورت الأمور بالضبط. بدونها، أنت تخمن ما إذا كانت الموافقة قد جاءت قبل النشر أو بعده. الموافقة التي تحدث بعد النشر ليست موافقة على الإطلاق. إنها إشعار مقنع كحوكمة.

ما الأدلة التي استندوا إليها

هذا هو الجزء الذي تنساه معظم الفرق. شخص ما وافق على تغيير، لكن ماذا رأى بالفعل قبل النقر على "موافقة"؟ هل راجع نتائج الاختبار؟ قرأ سجل التغييرات؟ تحقق مما إذا كان التغيير يؤثر على أنظمة أخرى؟ أم أنه وثق فقط أن كل شيء على ما يرام؟

يجب أن يلتقط خط الأنابيب الأدلة التي شكلت القرار. يمكن أن يكون هذا:

• رابط لتشغيل خط الأنابيب يوضح اجتياز جميع البوابات
• لقطة شاشة لنتائج فحص الأمان
• وثيقة طلب التغيير التي تمت مراجعتها
• ملخص لما تم فحصه وتأكيده

عندما تلتقط هذه الأدلة، تتوقف الموافقة عن كونها ختمًا مطاطيًا وتصبح قرارًا قابلًا للتحقق. يمكن لأي شخص أن ينظر لاحقًا ويرى بالضبط ما كان معروفًا في وقت الموافقة، وليس فقط أن شخصًا ما قال نعم.

بناء سجل التدقيق

تشكل هذه المعلومات الثلاثة معًا سجل التدقيق الخاص بك. سجل التدقيق هو السجل الكامل لما حدث لتغيير من البداية إلى النهاية: من قام به، من راجعه، أي بوابات اجتازها، من وافق عليه، متى تم نشره، وما إذا كان النشر ناجحًا أم فاشلاً.

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

ثانيًا، والأكثر عملية، يجعل التحقيق في الحوادث أسرع وأقل إرهاقًا. عندما يحدث خطأ ما، لا تحتاج إلى تعقب الأشخاص وسؤال "من فعل هذا؟" أو "لماذا سُمح لهذا بالمرور؟" الإجابات مسجلة بالفعل. يمكنك التركيز على إصلاح المشكلة بدلاً من إعادة بناء ما حدث.

جعله يعمل عمليًا

معظم أدوات CI/CD الحديثة تلتقط بالفعل بعض هذه المعلومات. GitLab CI/CD و GitHub Actions و Jenkins مع الإضافات المناسبة يمكنها تسجيل من وافق على تغيير ومتى. لكن جزء الأدلة يتطلب عادةً جهدًا يدويًا من الشخص الذي يمنح الموافقة.

الحل بسيط لكنه يتطلب انضباطًا: اجعل من العادة أنه قبل الموافقة، يضيف الموافق تعليقًا مع رابط أو ملخص لما راجعه. بدون هذه العادة، ستقول سجلات الموافقة الخاصة بك فقط "تمت الموافقة" بدون سياق. هذا أفضل قليلاً من عدم وجود سجل على الإطلاق.

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

قائمة مراجعة سريعة لسجلات الموافقة الخاصة بك

إذا كنت تقوم بإعداد أو مراجعة عملية الموافقة الخاصة بك، فراجع هذه النقاط:

• هل يسجل خط الأنابيب هوية الموافق ودوره؟
• هل الطابع الزمني دقيق بما يكفي لإعادة بناء تسلسل الأحداث؟
• هل الأدلة التي شكلت الموافقة يتم التقاطها تلقائيًا أم يدويًا؟
• هل يمكن لشخص يراجع سجل التدقيق بعد ستة أشهر أن يفهم لماذا تمت الموافقة على هذا التغيير؟
• هل نظام الموافقة متكامل مع مصادقة فريقك، وليس مجرد رسالة دردشة؟

الخلاصة

الموافقة بدون سجل ليست موافقة. إنها محادثة قد يتذكرها الجميع بشكل مختلف. عندما تلتقط من وافق، ومتى وافقوا، وما الأدلة التي رأوها، فإنك تحول عبارة "حسنًا، امضِ قدمًا" غير الرسمية إلى قرار يمكن مراجعته وتدقيقه والدفاع عنه. هذا هو الفرق بين عملية تبدو وكأنها تحتوي على ضوابط وتلك التي تمتلكها بالفعل.