عوامل نجاح DevOps: الثقافة وواجهات برمجة التطبيقات والأمان

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

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

وكانت المشكلة هي أن عمليات التطوير وتكنولوجيا المعلومات لها أهداف متنافسة.

تهتم التنمية بالاستجابة السريعة، في حين يُنظر إلى العمليات على أنها تفضل الاستقرار. الموثوقية والأمان - وأفضل طريقة لتحقيق هذه الأهداف هي عدم تقديم ميزات جديدة أو التغييرات.

أدخل DevOps، وهو مزيج من "التطوير" و"العمليات"، وهي فلسفة الإنتاج التي يحاول الجمع بين أفضل ما في العالمين - التجريب والتكرار مع قدر من يتحكم.

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

DevOps كثقافة

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

على هذا النحو، قال Ucci إن DevOps يجب أن يتم التعامل معها على أنها تمرين إيجابي لإدارة التغيير.

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

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

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

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

"الفكرة هي إذا كنت تقوم بسباقات السرعة بشكل منتظم كفريق، فستحصل على تعلمات يتم مشاركتها عبر الفريق. وهذا في الواقع جزء من تطبيق DevOps."

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

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

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

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

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

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

"من خلال تجربتي، فإن DevOps هو شيء يجب أن يكون نوعًا من المسعى من القاعدة إلى القمة. قال O'Dea: "من الأفضل أن تقوم بتعيين مهندسي DevOps في فرق التطوير بأنفسهم ثم العمل مع فريق DevOps المركزي للمساعدة في تطوير الأدوات وإنشاء المراقبة".

"هذه واحدة من الفلسفات المهيمنة التي كنا نحاول دفعها في Cylance - خاصة ونحن ننمو وننظر في مجالات مساحة المنتجات الأخرى. نحن نحاول إنشاء جهات اتصال DevOps. الفرق التي تضم مهندسًا واحدًا أو اثنين على دراية بنوع دور DevOps أو تطوير المكدس الكامل، فهي أكثر قابلية للتكيف وأفضل في العمل معها فريق DevOps والأدوات المتاحة لإنجاح هذا المشروع وتجنب العزلة والاقتتال الداخلي الذي يمكن أن يحدث عند محاولة فرض [DevOps] على المهندسين."

وقال O'Dea إنه من خلال وجود جهات اتصال DevOps، يمكن للمطورين بناء منتجاتهم وتحسينها بسرعة طوال دورة التطوير والإصدار لأن معظمها في أيديهم.

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

وأشار أودي إلى أنه مع وصول Cylance إلى مستوى معين من النضج، يجب وضع الضوابط والتوازنات موضع التنفيذ.

قال O'Dea: "لقد حصلت على ضمان الجودة، وحصلت على الامتثال الأمني، وذلك عندما بدأنا بشكل أساسي في تقديم فريق Cylance DevOps الذي أصبح مسؤولاً عن الدفعة النهائية للإصدار".

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

اعترف O'Dea أنه ليس من السهل العثور على المواهب التي يمكنها ارتداء قبعات متعددة. وقال أوديا إن الجمع بين مجموعة مهارات العمليات ومجموعة مهارات التطوير هو في الواقع مهارة في حد ذاتها.

وقال: "عليك أن تبحث عن الماس الخام". "أحد الأشياء التي اكتشفتها في منصبي القيادي في فريق Cylance DevOps هو أن أحد أفضل السمات وأكثرها قيمة لمهندسي [DevOps] - أولئك الذين قمت بتعيينهم - كانت انتقائية إلى حد ما خلفية. إذا نظرت إلى [أنا]، فقد عملت كمهندس برمجيات، وعملت كدعم فني، وعملت كمسؤول تكنولوجيا المعلومات."

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

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

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

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

تحسين DevOps من خلال واجهات برمجة التطبيقات

براد دريسديل، من عند مولسوفت حذر مكتب APAC التابع لـ CTO من أن DevOps ليس حلاً سحريًا.

وقال لـ ZDNet: "[DevOps] ليس الدواء الشافي لحل جميع مشكلاتك". "ما نشهده هو أنه نظرًا لإمكانية تسليم المشاريع بشكل أسهل وأسرع، تكرر المؤسسات الكثير من نفس الجهد في كل مشروع."

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

وفقًا لـDrysdale، فإن الجمع بين DevOps ونهج الاتصال القائم على واجهة برمجة التطبيقات يسمح للشركات بتقديم إمكانات جديدة، وإطلاق منتجات جديدة، والمحور بسرعة.

"لنفترض أن Project One كان يتطلب الحصول على بعض بيانات العملاء من نظام قديم قديم، ثم من خلال التطوير العمل ومبادرة DevOps، [الشركة] قادرة على نقل معلومات العميل من الكمبيوتر المركزي إلى الهاتف المحمول جهاز. قد يكون لدى المشروع الثاني متطلبات مماثلة حيث يتم أخذ بيانات العميل من الحاسوب المركزي بحيث يمكن عرضها على موقع ويب أو ساعة Apple Watch. ولكن إذا قاموا ببناء هذا المشروع بمعزل عن المشروع الأول، فستبدأ المشكلة في الظهور".

"هناك الكثير من العمل المتكرر الذي يتم إنجازه عبر المشاريع، ونعتقد أن هذا هو ما يبطئ مكون تسليم تكنولوجيا المعلومات."

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

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

"بهذه الطريقة، لا تكون تكنولوجيا المعلومات المركزية على المسار الحرج لتوفير 100 بالمائة من الإمكانات - وهذا ما يسرع الأمور."

أعرب إيمز عن مشاعر مماثلة، قائلاً إن واجهات برمجة التطبيقات (API) تسمح للشركات "بالاستفادة من الأتمتة والتنسيق، والوصول إلى السوق بشكل أسرع، وتجنب بناء الأشياء التي تم إنشاؤها بشكل أفضل في مكان آخر، واسمح بشكل أساسي لبرامجك بالتوسع بشكل أفضل."

عند تطبيق نهج الاتصال المعتمد على DevOps وواجهة برمجة التطبيقات (API)، قال Drysdale إنه من الأفضل البدء من الأعلى إلى الأسفل. على سبيل المثال، إذا قررت شركة تأمين ناضجة تخضع للتحول الرقمي إنشاء تطبيق جوال لـ عملائها، فإنها ستحتاج أولاً إلى تحديد ما يتطلبه هذا التطبيق ليعمل - مثل الوصول إلى العميل بيانات.

"يجب أن توفر وجهة نظر واحدة للعميل - معلوماته الشخصية، والحالة الحالية لسياسته، وحالة المطالبات المعلقة. وقال درايسديل: "تأتي هذه المعلومات من مجموعة كاملة من الأنظمة من جميع أنحاء المنظمة".

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

"إذا كانت مؤسسة جديدة، فمن المحتمل ألا تكون واجهات برمجة التطبيقات (APIs) موجودة، لذا يتعين عليهم بنائها مع أخذ الجمهور الرقمي في الاعتبار وتصميمها مع الحوكمة والأمن المدمجين."

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

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

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

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

قال O'Dea إن Cylance كانت تستخدم نهج DevOps الذي تقوده واجهة برمجة التطبيقات (API) منذ بدايتها قبل أربع سنوات ونصف، وقد ساعدتها حقيقة أن العديد من الأدوات كانت متاحة بالفعل عندما بدأت.

وقال أوديا إن جميع إصدارات برامج Cylance تمر اليوم بعملية تلقائية بدءًا من لحظة التحقق من الكود الجديد إلى لحظة إصداره.

"منذ المواقع الأولى التي أطلقناها، كنا مصممين على التأكد من أن [كل ما فعلناه] قابل للتكرار وقابل للتكرار أنه يمكننا دائمًا العودة وإنشاء خادم ويب آخر أو خادم تطبيقات آخر أو خادم إنشاء آخر،" O'Dea قال.

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

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

ومن خلال القيام بذلك، تمكنت شركة Verizon من تقليل الوقت المستغرق لتوفير الخدمات المُدارة من ستة أسابيع إلى بضع ساعات فقط، كما قال إيمز. بالإضافة إلى ذلك، خفضت DevOps التكاليف التشغيلية لشركة Verizon بأكثر من 35 بالمائة وزادت من حل مشكلات المستوى الأول بنسبة 83 بالمائة.

وقال سميث أيضًا إن تطبيق DevOps سمح للشركة بأتمتة قدر كبير من عبء العمل، "تقليل المخاطر، وزيادة السرعة، وتحسين الموثوقية".

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

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

DevOps والأمن ليسا على خلاف مع بعضهما البعض

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

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

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

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

قال Ucci إن DevOps يدور حول ربط التطوير التكراري باختبار الاستقرار والأمان.

"ما يمكن أن يوفره إطار عمل DevOps هو أنه، بدءًا من كلمة "go" عندما تقوم بقص الجزء الصغير من التعليمات البرمجية للمشاركة في عملية شاملة التطبيق، يمكنك أيضًا إعداد القدرات الأمنية التي تريد التأكد من الحفاظ عليها والالتزام بها على طول الطريق". قال.

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

يتضمن التكامل المستمر - أحد الجوانب الأساسية لعملية DevOps - إنشاء التعليمات البرمجية واختبارها مقابل مجموعة مُجهزة من مجموعات اختبار الوحدة والتكامل، وإنشاء التقارير التي تتضمن العناصر الناتجة، O'Dea قال.

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

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

وقال O'Dea إن Cylance تستخدم صور نظام التشغيل الأساسية - التي أنشأها فريق DevOps - لجميع تطبيقاتها.

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

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

"لقد كانت البنية التحتية كرمز في Cylance بمثابة نعمة كبيرة لقدرتنا على التحقق من أمننا التشغيلي على أساس يومي."

وأشار O'Dea أيضًا إلى أهمية التوثيق منذ اللحظة التي تصبح فيها DevOps جزءًا من جهود التطوير التي تبذلها الشركة.

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

"من المهم أن يكون لديك وثائق، على الرغم من أن لديك كميات كبيرة من الأتمتة. لقد سمعت الكثير من مهندسي DevOps خارج مؤسسة Cylance يقولون إن التعليمات البرمجية ذاتية التوثيق وهذا ليس صحيحًا بالضرورة. عندما تصل إلى نقطة كبيرة حيث يكون لديك 40 أو 50 نظامًا فرعيًا تديره و10 أو 12 شخصًا يقومون بذلك، لن يكون لدى الأشخاص الوقت الكافي لقراءة التعليمات البرمجية. أنت حقًا بحاجة إلى بذل جهد قوي في التوثيق."