عندما شرع فريق منصة جديد في تنفيذ خريطة الطريق الخاصة به من خلال سير العمل القسري مع الوثائق الضعيفة، تراجعت تجربة المطورين. جاء النجاح من تبسيط الحوكمة، وإعطاء الأولوية لما يهم، ونشر الامتثال بشكل تدريجي من خلال الوقاية والكشف والتواصل، كما أوضح دافيد دي باوليس في مقطع الفيديو الخاص بمحادثته “الطريق إلى الامتثال” من قمة Dev في ميونيخ. أدى التعاطف والتركيز والهدف المشترك إلى التبني الناجح.
وقال دي باوليس إنه عندما أصبحت الحاجة إلى فريق منصة مخصص واضحة، شكلت المنظمة فريقًا من خلال الجمع بين المطورين ذوي الخبرة الذين يتمتعون بخلفيات قوية في DevOps والسحابة من فرق المنتجات. كان الفريق طموحًا، حيث قام بصياغة خرائط طريق لكتالوج الخدمة ووضع تصور لمنصة مطور داخلية ومركز للتميز السحابي.
ومع ذلك، خلقت هذه التغييرات احتكاكًا. وأوضح دي باوليس أن المطورين واجهوا فجأة مسارات عمل جديدة وحسابات AWS متعددة ومفاهيم غير مألوفة:
لقد اعتادوا على امتلاك حساب واحد، وكانت الأذونات أوسع وأكثر مرونة. والآن يتعين عليهم تبديل السياقات وتحديث التكوينات وتعلم مهارات جديدة.
وفي الوقت نفسه، كانت الوثائق في كثير من الأحيان طويلة وعفا عليها الزمن ويصعب التنقل فيها. ونتيجة لذلك، قدم المطورون طلبات متكررة وأعربوا عن إحباطهم إزاء تراجع تجربة المطورين. وقال دي باوليس: “لا أحد يحب أن تتم رعايته ويقال له ما يجب فعله”، مشيراً إلى أن فرق الأمن والمنصة غالباً ما تقع في هذا الفخ. نادراً ما ينجح التبني القسري؛ وأضاف أن التوافق حول هدف مشترك يفعل ذلك.
أحد الأمثلة الملموسة هو وضع علامات على الموارد. لقد فشلت مبادرة وضع العلامات السابقة، مما أدى إلى ترك الملكية وإسناد التكلفة والحوكمة غير متسقة ويدوية إلى حد كبير. أعاد فريق دي باوليس بدء الجهود من خلال نهج مختلف: التبسيط أولاً. لقد قاموا بتقليل عدد العلامات المطلوبة وتوحيدها باستخدام سياسات علامات AWS وسياسات التحكم في الخدمة للتحقق من صحة المدخلات ومنع إنشاء موارد غير مميزة. بالتوازي، استخدموا معيار وضع العلامات على الموارد في AWS Security Hub لاكتشاف الموارد الموجودة التي كانت بالفعل خارج نطاق الامتثال.
من خلال الجمع بين الوقاية والكشف والإخطار، قدم الفريق وضع العلامات مع قدر أقل من التعطيل ومشاركة أكبر، كما قال دي باوليس:
قم بالإبلاغ أولاً، ثم قم بالتنفيذ بهدوء بعد ذلك، وبعد ذلك فقط انتقل إلى التنفيذ الأكثر صرامة. وقد أثبت هذا النهج إمكانية إعادة استخدامه عبر مبادرات الامتثال الداخلي الأخرى.
وكان الدرس الرئيسي هو التركيز. يمكن لفرق النظام الأساسي والأمان القيام بأشياء كثيرة، ولكن ليس كل شيء في وقت واحد. وأوضح دي باوليس أن تحديد الحد الأدنى من نموذج الحوكمة القابل للتطبيق وتحديد أولويات ما يهم حقًا الأعمال أمر ضروري:
إذا كان لديك الآلاف من النتائج الأمنية، فأنت بحاجة إلى البدء من مكان ما. ركز على ما هو مهم وعاجل، لكن لا تتجاهل ما هو مهم وليس عاجلاً بعد، وإلا ستصبح أزمة فيما بعد.
وقد ثبت أن مشاركة السياق والغرض أمر بالغ الأهمية. عندما أدركت الفرق أن مبادرات الامتثال مرتبطة بنجاح الشركة وثقة العملاء، أصبحوا أكثر استعدادًا لدعمها وحتى دمجها في خرائط الطريق الخاصة بهم.
وقال دي باوليس إن الامتثال عبارة عن رحلة. يستغرق الأمر وقتًا وصبرًا وتعاطفًا والكثير من التواصل. إنه يعمل بشكل أفضل عندما يتم تضمينه في سير العمل اليومي ويتم التعامل معه كمسؤولية مشتركة:
إن الشفافية والتعاطف والطرح التدريجي أمر مهم بقدر أهمية التكنولوجيا نفسها. عندما تنظر الفرق إلى الامتثال باعتباره شيئًا يساعدهم على التحرك بشكل أسرع وأكثر أمانًا مدعومًا بالكشف الواضح وحواجز الحماية المعقولة، فإن الاعتماد يتبع ذلك بشكل طبيعي.
وخلص إلى أن التغيير دائمًا ما يكون فوضويًا في المنتصف، لكنه يستحق العناء في النهاية.
أجرت InfoQ مقابلة مع Davide de Paolis حول رحلة الامتثال الخاصة بهم.
InfoQ: كيف تستخدم السياسات التقنية لتنفيذ الامتثال في مؤسستك؟
دافيد دي باوليس: نحن نتعامل مع السياسات باعتبارها حواجز حماية، وليس كأصفاد. الهدف هو جعل المسار المتوافق هو الأسهل. نحن نستخدم أدوات AWS الأصلية مثل سياسات التحكم في الخدمة، وتكوين AWS، وSecurity Hub، وسياسات وضع العلامات لترميز التوقعات مباشرة في النظام الأساسي.
ومع ذلك، فإن السياسات وحدها لا تخلق الامتثال. كيف يتم تقديمهم مهم. نحن نعطي الأولوية للشفافية والملكية المشتركة والتواصل الواضح حول “السبب”. كلما أمكن، نعتمد على الكشف الآلي والتنفيذ التدريجي بدلاً من الحظر الصارم المفاجئ. إلى جانب عقلية العميل الداخلي، فإن هذا يجعل الامتثال شيئًا تتماشى معه الفرق بشكل طبيعي.
InfoQ: ما هو الأسلوب الذي اتبعته في طرح العلامات، وكيف تم ذلك؟
دي باوليس: في البداية، تعاملنا مع وضع العلامات على أنه “مجرد بيانات وصفية”، على افتراض أن الفرق ستتبناها بمجرد تحديد القواعد. هذا لم ينجح. لا ينجح وضع العلامات إلا عندما يكون مرتبطًا بشكل واضح بالنتائج التي يهتم بها المطورون، مثل رؤية التكلفة والملكية والمساءلة.
لقد بدأنا بمجموعة بسيطة ومحددة من العلامات المطلوبة وجعلنا من السهل تطبيقها عبر البنية التحتية كرمز والإعدادات الافتراضية للنظام الأساسي. لقد ركزنا على الرؤية أولاً، وأظهرنا للفرق ما هو مفقود وسبب أهميته. وفي وقت لاحق فقط قمنا بإدخال حواجز حماية أقوى من خلال السياسات. لقد تحسن الاعتماد بشكل ملحوظ بمجرد أن رأت الفرق أن وضع العلامات هو عامل تمكين، وليس بيروقراطية.
InfoQ: كيف يمكنك توصيل التغييرات والتعاون مع الفرق؟
دي باوليس: التواصل جزء من المنصة. نشرح السياق والتأثير قبل التنفيذ ونتواصل مبكرًا لتجنب المفاجآت.
بالنسبة للمبادرات الأكبر حجمًا، نستخدم نموذج *Tour of Duty*، حيث ينضم المهندسون مؤقتًا إلى فريق النظام الأساسي (أو العكس). يوفر هذا تعليقات عملية ويساعد على نشر السياق مرة أخرى في فرق المنتج. نستخدم أيضًا طلبات التعليقات والوثائق الداخلية وجلسات الأسئلة والأجوبة المباشرة، ونقوم بتعديلها باستمرار بناءً على التعليقات.
والأهم من ذلك، أننا نؤطر التغييرات على أنها تعاون وليس إنفاذًا. وقد ساعد هذا التحول في نقلنا من ديناميكية “المنصة مقابل المنتج” إلى الملكية المشتركة.
