إن معظم المؤسسات في هذه الأيام تنتقل من نموذج أعمال المُحسن للموارد والذي يستند إلى النفقات الرأسمالية (CAPEX) إلى نموذج أعمال المُحسن للسوق والذي يستند إلى النفقات التشغيلية (OPEX). ولكن ما الذي يقود هذا التحول؟ في الحقيقة أن الهدف الأساسي من هذا التحول هو تقليل الوقت اللازم للتسوق وإسعاد الزبائن باستمرار عن طريق تقديم قيمة (Value) لهم وتُعرف القيمة بأنها منتج أو خدمة معينة والتي يكون الزبون مستعدًا للدفع مقابلها.
مرحبا بك في التحول الرقمي. هل أنت مستعد لتبني عقلية DevOps في شركتك؟
لقد أشار مدير DevOps السيد Donovan Brown إلى أن DevOps
اقتباسهي إتحاد الأشخاص والعمليات والمنتجات لتمكين التسليم المستمر لتقديم القيمة للعملاء.
إن DevOps هي رحلة تعلم وتطوير بشكل مستمر، مع وجهة لن تصل إليها أبدًا. ولهذا فإن جميع الصور الواردة في هذا المقال على شكل رمز اللانهاية.
ولكوني شخصًا ذو عقلية مرئية (visual-minded)، فقد أنشأت عرضًا تقديميًا يحتوي على صور من أجل مخيم تدريب DevOps العالمي GDBC (Global DevOps Bootcamp) وهذا الحدث السنوي الذي تنسقه المجتمعات المحلية في جميع أنحاء العالم وذلك لخلق بيئة استكشافية وتعاونية لاستعراض مبادئ التحول الرقمي ورؤى DevOps.
دعنا نستكشف سريعًا أربعة من الصور المرجعية (والتي تدعى أيضًا بالصور المرئية والإنفوجرافيك). واذا أردت التعمق أكثر يمكنك مراجعة كتاب The DevOps Handbook، لكُتّابه Gene Kim، و Jez Humble، وPatrick Debois، وJohn Willis.
الممارسات
بناءً على استطلاع قامت به شركة مايكروسوفت على مستوى العالم لتحديد أهم المجالات التي يجب التركيز عليها في DevOps والمجالات التي تحتاج إلى تحسين، والذي جاء فيه أن جميع المشاركين الذين يستخدمون DevOps يركزون على نفس الممارسات في استخدام DevOps ونفس التقنيات لتحقيق DevOps و سوف نستعرضها في الصورتين التاليتين. في الصورة الأولى نلاحظ الممارسات الخمس الأولى الرئيسية:
يشجع كبار المختصين في الأداء (Performers) على تعزيز عقلية استسراع النمو، والمكافأة على الابتكار، والتعاون، والتجريب، والتعلم، والتعاطف مع المستخدمين. والسعي لعملية تسليم تطبيقات سريعة الاستجابة، والجدولة المرنة، والتجارب التكرارية. ورصد المشاكل والتعرف عليها وتخفيفها، والقضاء باستمرار على الاختناقات التي تهدر الأداء، وقياس مؤشرات الأداء المهمة وذلك لتحسين المخرجات، مثل معدل فشل التغيير المنخفض (CFR Change Failure Rate)، والوقت الأدنى للاستعادة من الفشل ( Minimal Time To Recover MTTR)، ويجب دومًا أن نحرص على معالجة المشكلات من جذورها. وأخيرًا، لنأتي إلى التكنولوجيا، والتي هي أداة تمكين ستكون محور الصورة التالية.
نلاحظ في هذه الصورة التقنيات التي تركز عليها DevOps:
يقوم نظام التحكم في النُسخ (Version Control System) بإدارة إصدارات التطبيق واعداداته، والبنية الأساسية، وغيرها من الشيفرات البرمجية للتطبيق. وهو يتيح التعاون بين الفِرق ومراقبة الأنشطة مثل عمليات النشر (Deployments). يستخدم كبار المختصين في الأداء نسخ فرعية من التطبيق وذلك لعزل التغييرات قصيرة الأجل ومعاينتها قبل أن يتم دمجها في النسخة الأساسية (Master)، ويستمر مراجعة وتدقيق طلبات الدمج باستمرار ويتم إصدار النُسخ على أساس ذلك.
يجب أن يُنظر للاختبار على أنه نشاط مستمر، وأن يُدمج في مخطط سير العمل للمطور وذلك من أجل تحقيق التكامل المستمر مع التغيّرات (Continuous Integration CI) والتسليم المستمر للتطبيق (Continuous Delivery CD).
يتيح لك التخزين السحابي توفير البنية التحتية اللازمة والفعّالة وذلك للتحرك بأقصى سرعة ممكنة عند الضرورة وذلك تجنبًا للوقت المبذول في بناء البنية التحتية المناسبة للشركة.
وأخيرًا، تمكنك المراقبة من تكوين فرضية، أو التحقق من صحة التجارب، أو دحضها، واكتشاف المشاكل بشكل استباقي قبل حدوثها وفهم حالة التطبيق.
يسرد الشريط الأسود الموجود على يمين الصورة المنتجات التي يجب أخذها في عين الاعتبار عند البحث عن تقنية للتطوير والإنتاج والهندسة المشتركة وبيئات أخرى. حاول أن تقيّم المنتجات المدرجة وحدّث هذه القائمة بانتظام لأن هذا الجزء متغير وإلزامي بنفس الوقت من أجل اختصار الوقت.
العادات
بناءً على قصة تحوّل 65,000 مهندس إلى DevOps بمساعدة فريق خدمات Visual Studio، تركز هذه الصورة على العادات الخمس الرئيسية التي تعلموها أثناء تحولهم إلى DevOps. يعدّ التركيز على العملاء، والاستقلال الذاتي للفِرق، وتنسيق الشركة، والتركيز على عادات Shift Left، هي عوامل التطوير لمنهجية التصميم المرن (Agile)، كما أن عقلية الإنتاج أولًا والبنية التحتية مثل الموارد المرنة جميعهم خواص تتفرد بها عقلية DevOps.
يعدّ التركيز على العملاء جزءًا من سعينا لإمتاعهم وهاجسنا بتقديم خدمة قيّمة لهم. ويجب أن تُصغ إلى المستخدمين بشكل نشط أي أن تسمع لمشاكلهم واقتراحاتهم، وتمكين الميزات وتعطيلها تدريجيًا، وإجراء التجارب المستمرة، وقياس مؤشرات الأداء الرئيسية. واستخدام المُراجعات المتوفرة لتحسين الأداء أو المنتج ومحاولة الإستفادة بأكبر قدر منها وزيادة التأثير على العملاء إلى أقصى حد.
تُعد عادات Shift left طريقةً لاختبار البرمجيات والنظام، ويتم إجراء الاختبار في وقت مُبكر من دورة الحياة (أي تم نقله إلى اليسار في الجدول الزمني للمشروع). ويشجع shift left على المراجعات، والتحقق من الصحة، والموافقات على كل من الاختبار والأمان في أقرب وقت ممكن في دورة توصيل الميزات وذلك لزيادة الجودة وتمكين أسلوب الفشل السريع (أحد أهداف هذه الفلسفة هي تقليل الخسائر، وذلك عندما يكشف الاختبار وجود شيء ما لا يعمل فالأفضل دومًا تجربة شيء آخر بسرعة. أي تجاوز الفشل بسرعة). عندما يتجاوز الأعطال الفنية الحد المحدد مسبقًا (مثلا خمسة أخطاء لكل مهندس)، يجب تشجيع الفِرق التي تعمل على المميزات على تعليق العمل حتى يتم جميع الأخطاء الموجودة.
إن استقلالية الفريق وتنسيق الشركة يهتمان بما تقوم الشركة بإنشائه وكيفية إنشائه وسبب إنشائه. لذا ستحتاج إلى وتيرة عمل سريعة ونشاط دائم داخل الشركة لتمكين فِرق القيادة وفِرق المميزات من التعاون بشفافية وفعالية. تمتلك أكثر فرق المميزات فعالية خاصية تحويل الفكرة إلى نتائج، مع الاستقلال الذاتي للقرارات حول كيفية تطويرها ودعمها لخصائص ومميزات هذه الفكرة.
إن عقلية الإنتاج أولًا لا تُميّز كيفية التعامل مع المميزات والأخطاء خلال التطوير والاختبار والدعم الفني. وإنما كل شيء يجب أن يكون مُؤتمت، ومُحرر، ومُحسن في الإنتاج. ويتم الاعتماد على النشر الدائري والحلقات (ring-based deployment and rings) والتي تنص على عرض التغييرات لمستخدمين محددين ومراقبتها والتحقق من صحتها قبل عرضها على جميع المستخدمين وذلك للحد من الأخطاء التي تنتج أثناء إحداث تغييرات في المميزات المطروحة، ومعالجة جميع المشكلات من جذورها، وتذكر أن تكون واضحًا عند حدوث مشكلة معينة وتوضيحها وما هو السبب الرئيسي لظهورها والحل الذي استخدمته لتجاوزها (لان المستخدم سيكون أكثر تفهما في حال كان لديه معرفة بسبب حدوث المشكلة والآلية المتبعة في حلها).
تصف البنية التحتية مثل الموارد المرنة كيفية تكيّف الحلول المطروحة مع الخدمات السحابية والحاويات (container) والخدمات المصغّرة (Microservices). يجب تبني تحوّل عملي يكون منطقيًا لشركتك وأهدافك ومنتجاتك وثقافتك. كما هو الحال مع العادات السابقة، من المهم أن نُفضّل البنية الاستقلالية على بنية الوصفية وألا نُغير كل شيء في وقت واحد.
الشروع في العمل
يجمع التصور الأخير بين كل ما سبق ويقترح خمس خطوات للبدء مع Devops.
أفضّل أن أبدأ بالتقييم لقدرته في تحديد المناطق الرئيسية التي يمكن تحسينها.
توفر التقييمات معيارًا لعقلية وأداء DevOps مقارنة بباقي المنهجيات المتبعة في قطاع الصناعات الأخرى. من المهم أن نفهم أي جزء من عملك يسير على ما يرام وأي جزء يحتاج لأن تستثمر فيه لنقله إلى المستوى التالي. إن كُلًا من التقييمات التابعة لشركة DORA و تقييمات شركة مايكروسوفت بالنسبة Devops هي تقييمات رائعة للبداية. بالإضافة إلى ذلك، إجمع أدوات القياس لاستخدامها كقاعدة لقياس التقدم - على سبيل المثال، معدل تكرار النشر (Deployment Frequency) والوقت اللازم لتطبيق التغييرات (lead time for changes)، ومتوسط وقت الإصلاح (mean time to repair)، ومعدل فشل التغيير (change failure rate).
إن التحدي الأكبر الذي سوف يواجهك هو الناس وثقافاتهم. يحتاج كل شخص لأن يعتنق فكرة التحول الرقمي، وأن يفهم كيف سيتأثر في هذا التغيير، وأن يُشجع على رفع مستوى الشفافية, ويجب عليه المشاركة بشكل فعّال وأن يتحمل المسؤولية الكاملة للقيمة المضافة للخدمة المتوقعة منهم. ويشمل هذا التحدي أيضًا مجلس قيادة الشركة والذي يحتاج لأن يقدم الدعم والإلهام والتمكين وتوجيه الموظفين لرؤية واضحة. وبناء عليه ستقوم إما بإنجاح هذا التحول كفريق واحد أو بإفشاله.
وبدون وجود أشخاص ملتزمين وثقافة تجريبية، فإن بقية رحلة التحول إلى DevOps ستفشل.
إن العملية (Process) هي نظامك الهندسي، والذي يقوم بتمكين الفرق من إصلاح المشاكل بشكل مباشر، واستخدام الإدارة والتطوير الرشيق (lean management and development)، وتقديم خدمة قيّمة باستمرار. ويوفر نظام الهندسة المشترك الثبات، ويخول فِرق المميزات، ويتيح ويشجع الجميع على دعم بعضهم بعضًا والمساهمة فيه. يجب أن تتضمن أهم أهداف عملياتك التركيز على الجودة، واحتضان البنيات خفيفة الترابط (loosely coupled architectures) لتمكين التطوير، والإدارة الخفيفة، والأتمتة، والإصدارات المتعددة في اليوم، والاحتفال بالنجاح كفريق وكشركة.
المنتجات هي أسهل وصلة في السلسلة. فهي تمكن الجميع من التركيز على ما هو مهم ألا وهو توفير قيمة (Value) للعملاء. تعدّ القيمة من أهم الأشياء الّتي تُرضي المستخدمين. تتضمن مؤشرات الأداء الرئيسية مثل تكرار النشر، والوقت اللازم لتطبيق التغييرات، ومعدل فشل التغيير، ووقت الاسترداد من الخطأ. سواء كنت تتعامل مع كل هذه الخطوات دفعة واحدة أو خطوة بخطوة أو حتى لو أنك ابتكرت خطة للانتقال وذلك بالاستعانة بكل الخطوات التي ناقشناها. تذكر دومًا أن تكون واقعيًا.
اقتباسيمكن تحقيق التحسين للجميع إذا قدمت القيادة دعمًا ثابتًا، وأن يلتزم أعضاء الفريق بالعمل. - Accelerate: The Science of Lean Software and DevOps
أيّ من صور أحببتها؟ أيّ منها أحسست بأنها لا تضيف أي قيمة؟ وما الجزء الذي تعتقد بأنه مفقود؟ دعونا نتعاون لكشف الغموض عن DevOps ومساعدتك وموظفينك على التألق. يحتاج المستخدمون إلى فهم أنهم ليسوا وحدهم وأن يعرفوا بأنه يمكنهم الاعتماد على الممارسات المُجربة والمُثبت فعاليتها وعلى النهج التعليمي الواقعي.
ترجمة -وبتصرف- للمقال Visualizing a DevOps mindset لصاحبه Willy-Peter Schaub
أفضل التعليقات
لا توجد أية تعليقات بعد
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.