لماذا يجب أن يترك كل موافقة نشر أثرًا قابلًا للتدقيق

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

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

الموافقة ليست مجرد خانة اختيار

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

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

• من وافق على هذا؟
• ما المعلومات التي استخدمها لاتخاذ القرار؟
• ما التغيير الدقيق الذي وافق عليه؟

هذه العناصر الثلاثة تشكل أثرًا للتدقيق. بدونها، لا توجد طريقة لإعادة بناء ما حدث عندما تسوء الأمور. والأمور ستسوء.

الركائز الثلاث للأدلة القابلة للتدقيق

من وافق

هذا يعني فردًا محددًا يمكن التعرف عليه. ليس اسم فريق. ليس "مهندس المناوبة". شخص محدد اسمه ودوره ومسؤوليته واضحة.

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

ما بنوا عليه قرارهم

يجب أن تشير الموافقة إلى الأدلة التي دعمت القرار. يمكن أن تكون:

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

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

ما التغيير الذي تمت الموافقة عليه

هذا يتطلب مرجعًا مباشرًا للتغيير المحدد. رقم طلب سحب (Pull Request). هاش commit. رابط لسجل تغيير مع التفاصيل الكاملة.

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

ما يتم تجاهله في الغالب

عادةً تتذكر الفرق تسجيل الموافقات للتغييرات التي تمت. لكن ماذا عن التغييرات التي تم رفضها؟

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

التغييرات المرفوضة لا تقل أهمية عن المقبولة. إنها تمثل قرارات شكلت ما وصل في النهاية إلى الإنتاج. عاملها بنفس الدقة التوثيقية.

كيف يجب أن تلتقط الـ Pipelines الأدلة

إن CI/CD pipeline هو المكان الطبيعي لالتقاط هذه الأدلة. ليس مرفقات البريد الإلكتروني. ليس PDF في مجلدات مشتركة. ليس لقطات شاشة ملصقة في صفحة wiki. الـ pipeline نفسه يجب أن يسجل كل شيء تلقائيًا.

إليك كيف يعمل عمليًا:

على سبيل المثال، يمكن لـ GitLab CI pipeline تعريف وظيفة موافقة يدوية تسجل أثر التدقيق في ملف منظم:

approve-production:
  stage: deploy
  when: manual
  only:
    - main
  script:
    - |
      echo "{\"approver\":\"$GITLAB_USER_LOGIN\",\
            \"timestamp\":\"$(date -u +%Y-%m-%dT%H:%M:%SZ)\",\
            \"commit\":\"$CI_COMMIT_SHA\",\
            \"pipeline_id\":\"$CI_PIPELINE_ID\"}" > audit-log.json
    - cat audit-log.json
  artifacts:
    paths:
      - audit-log.json
    expire_in: never

عندما يصل تغيير إلى بوابة موافقة يدوية، يتوقف الـ pipeline ويُعلم الموافق. يراجع الموافق التغيير، مع أي نتائج اختبارات أو فحوصات أو بيانات مراقبة مرفقة بتشغيل الـ pipeline. عندما يوافق أو يرفض، يسجل الـ pipeline:

• هوية الموافق (من نظام المصادقة)
• الطابع الزمني
• القطع الأثرية أو هاش commit الجاري نشرها
• روابط للأدلة التي راجعها
• أي تعليقات أضافها

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

لماذا هذا مهم للتدقيقات

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

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

قائمة تحقق عملية للموافقات القابلة للتدقيق

قبل أن تعتبر عملية الموافقة مكتملة، تحقق من هذه النقاط:

• كل موافقة تسجل الفرد المحدد الذي وافق، وليس مجموعة أو دورًا
• كل موافقة ترتبط بالأدلة التي دعمت القرار
• كل موافقة تشير إلى التغيير الدقيق (هاش commit، رقم PR، أو سجل تغيير)
• التغييرات المرفوضة مسجلة بنفس تفاصيل المقبولة
• الـ pipeline يلتقط هذه البيانات تلقائيًا، وليس من خلال توثيق يدوي
• السجلات مخزنة بجانب قطع النشر الأثرية، وليس في أنظمة منفصلة

الخلاصة

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