البحث في الموقع

إن معظم المؤسسات في هذه الأيام تنتقل من نموذج أعمال المُحسن للموارد والذي يستند إلى النفقات الرأسمالية (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) للعملاء. تعدّ القيمة من أهم الأشياء الّتي تُرضي المستخدمين. تتضمن مؤشرات الأداء الرئيسية مثل تكرار النشر، والوقت اللازم لتطبيق التغييرات، ومعدل فشل التغيير، ووقت الاسترداد من الخطأ. سواء كنت تتعامل مع كل هذه الخطوات دفعة واحدة أو خطوة بخطوة أو حتى لو أنك ابتكرت خطة للانتقال وذلك بالاستعانة بكل الخطوات التي ناقشناها. تذكر دومًا أن تكون واقعيًا. أيّ من صور أحببتها؟ أيّ منها أحسست بأنها لا تضيف أي قيمة؟ وما الجزء الذي تعتقد بأنه مفقود؟ دعونا نتعاون لكشف الغموض عن DevOps ومساعدتك وموظفينك على التألق. يحتاج المستخدمون إلى فهم أنهم ليسوا وحدهم وأن يعرفوا بأنه يمكنهم الاعتماد على الممارسات المُجربة والمُثبت فعاليتها وعلى النهج التعليمي الواقعي. ترجمة -وبتصرف- للمقال Visualizing a DevOps mindset لصاحبه Willy-Peter Schaub

لقد أحدثت الحاويات (Containers) والخدمات المصغّرة (Microservices) ثورة في تطوير التطبيقات وإدارة البنية التحتية لها، وقدمت لنا تحديات أمنية جديدة دون أن تعالج التحديات السابقة. إذن ما هي أبرز التحديات الأمنية الجديدة؟ وما الذي يجب علينا فعله تجاهها؟ تقنيات جديدة وتحديات جديدة تُعدّ الخدمات المصغّرة (Microservices) من أشهر المعماريات البرمجية في وقتنا الحالي، والتي جاءت لتحل مشاكل الطريقة التقليدية في تطوير المشاريع والتي تُعرف باسم (Monolithic) وهي معمارية تجعل كلّ خدمات المشروع عبارة عن وحدات برمجية متراصّة ومتجانسة مع بعضها بعضًا وتعمل جميعها في وقت واحد. فإذا حدث مشكلة ما في أحد خدمات المشروع سوف تتأثر جميع الأجزء المتجانسة الأخرى أمّا (Microservices) قسّمت المشروع الواحد إلى عِدّة مشاريع منفصلة، وكلّ مشروع يكون عبارة عن خدمة مصغرة، وتعمل كل خدمة منهم بشكل مستقل عن الخدمة الأخرى مع إمكانية إتصال خدمة معينة بخدمة أخرى من خلال قنوات اتصال محددة. لقد غيّرت الخدمات المصغّرة كلّ شيء. إذ نلاحظ أن أغلب الشركات في وقتنا الحالي تتجه لوضع خارطة عملٍ معتمدة على الخدمات المصغّرة باستخدام بنى معمارية مثل البنية التحتية الثابتة (Immutable infrastructure)، أو البنية المعمارية التي لا تدعم التشارك (shared-nothing architecture)، أو التطبيقات المتوضعة في الحاويات (containerized applications). لقد كانت طريقة الكشف عن فعالية المشاريع في حالات معينة مثل العمل في نطاق صغير، أو في الإستقلالية، أو في تحقيق الإستدامة الذاتية تُعرف عند بناء الواجهة البرمجية API وتشغيلها على الآلة الوهمية (virtual machine) أو بداخل حاوية، أو حتى بتشغيلها على القرص الصلب (حيث يكون مُثبت عليه نظام التشغيل)، أما الآن فيمكننا الكشف عن فعالية هذه المشاريع باستخدام الخدمات المصغّرة بحيث يتم إختبار كلّ حالة على حدة ومعرفة فعالية المشاريع بدون بناء واجهة برمجية. وعلى الرغم من المزايا المتعددة لإستخدام الحاويات إلا أنها تقدم لنا مجموعة من التحديات أيضًا من بين تلك التحديات المباشرة التي تواجه الحاويات هي الزحف على الحاويات (container crawl)، وحماية الحاويات، وتعقب الخدمات المصغّرة، ومعرفة مصدر نُسخ الحاويات. إذًا ما تأثير ذلك على الأمن في بيئة الخدمات المصغّرة؟ إن التحديات الأمنية لا تزال موجودة في بيئة التطبيقات أحادية النواة monolithic applications، ولا نزال نحتاج إلى معرفتها وتحديدها لمعالجتها. بالإضافة إلى ذلك، نحتاج إلى النظر في التحديات الأمنية الإضافية التي تفرضها الخدمات المصغّرة وتقنيات الحاويات. ومن منظور أمني، زادت إمكانية التعرض للهجوم بشكل كبير في عالم الخدمات المصغّرة بالموازنة مع التطبيقات أحادية النواة. أن زيادة قابلية النشر للوحدات وللأجهزة البعيدة (مثل: الهواتف الذكية والأجهزة المحمولة والأجهزة اللاسلكية الأخرى) أدى إلى زيادة التعرض للخطر، وإحتمالية حدوث هجوم أمني على الأجهزة البعيدة، ومشكلات التكاملية. بالإضافة إلى ذلك، قد تحتوي نُسخ Docker الأساسية على ثغرات أمنية والتي قد تضر بالخدمات المصغّرة. لذا ينبغي إدارة مصدر نُسخ Docker لضمان صحتها وخلوها من الثغرات. ويشكّل نشر تحديثات الأمنية والترقيعات مع المحافظة على أدنى مدة زمنية لتعطل الحاويات تحديًا آخر يصعب تجاوزه. يمكن أن تضيف DevOps المزيد من التركيز على الاحتياجات الأمنية في عالم الخدمات المصغّرة. حيث تركز أدوات النشر والبناء المستمرة حاليًا على تبسيط عملية التسليم، على الرغم من عدم تركيزها كثيرًا على حماية DevOps . أفضل الممارسات الأمنية لمواجهة بعض التحديات المذكورة أنفًا، دعونا نُلق نظرة على أفضل الممارسات التي يمكن إتخاذها. كجزء من استراتيجية DevOps الفعالة، يجب دمج خطوات الحماية والتدقيق المستمرة في منهجية DevOps. ويجب أن يتضمن الاختبار المستمر مُميزات إختبار الأمان المختلفة ويجب إضافة التحقق من سلامة نُسخ الحاويات إلى منهجية DevOps. وكما يمكننا أيضًا استخدام السجلات الخاصة private registries والتي تضمن لنا أن النُسخ موثوق بها وموجودة داخل الشركة. وينبغي تعزيز المراقبة من خلال آليات للكشف عن حالات الشذوذ لاكتشاف أي استخدام خاطئ للموارد أو الأحداث الغير طبيعية مع الحاويات، كما ينبغي تعزيز جميع قدرات المراقبة لتتبع العمليات المعتمدة على وكيل (agent-based) والعمليات بدون وكيل (agentless). كما يجب تحديث إدارة الترقيعات (Patch management) وتحسينها لضمان ترقيع الحاويات بأحدث التحديثات مع ضمان الحد الأدنى من وقت التوقف عن العمل. ولقد قدم Docker آلية لتحديد مصدر النُسخ تسمى (Notary)، والتي تستند إلى TUF (اختصارًا إلى The Update (Framework الذي يُستخدم في توزيع وتحديث البرامج بشكل نموذجي). ولكن العديد من أخصائيي الحاويات في وقتنا الحالي لا يستخدمونه Notary وذلك لأنه لا يزال في مرحلة التطوير. كما أن Notary يتطلب عملية إدارة رئيسية خبيرة في الشركة. تعدّ المنطقة التي تقع بين الخدمات المصغّرة من المناطق التي تُرتكب فيها الأخطاء أمنية، ويمكن استخدام Gateway API (وهي برمجية تقع أمام الواجهة البرمجية وتعمل كنقطة دخول واحدة لمجموعة محددة من الخدمات المصغّرة) بفعالية في هذا الموقف. إن تشفير الرسائل باستخدام تشفير الرسائل التقليدي PKI (البنية التحتية للمفتاح العام Public Key Infrastructure وهو إطار التشفير والأمن السيبراني الذي يحمي الاتصالات بين الخادم والعميل) ليس خيارًا قابلًا للتوسعة في هذا الموقف. لذا بدلًا من ذلك، يمكننا استخدام JSON Web Token) JWT) وهو رمز مشفّر مع مجموعة من سياسات التأكيد assertion policies حول الطالب للخدمة (requestor).حيث يوقعّ خادم الهوية الرسائل برمز مُميز والذي يُمكن التحقق منه بواسطة نظام المستلم (recipient system). كما يمكن تشفير JWT رقميًا للحفاظ على سرية وسلامة التأكيدات (assertions) والتي تسمى حينَئِذٍ JSON Web Encryption) JWE). غالبًا ما تكون الحماية صعبة وباهظة الثمن. لذا حاول أن تجعل من الحماية سمة أساسية للبنية التحتية للخدمات المصغّرة لتوفير أفضل مستوى من الأمان والأداء. ترجمة -وبتصرف- للمقال Secured DevOps for microservices لصاحبه Sreekanth Nyamars

على مدار الأشهر القليلة الماضية، نشرت بعض المقالات الّتي تستكشف النقاط الأساسية الثلاث في تحولك الرقمي وهي المنتج والعملية والناس، وذلك لتمكينك من الانتقال من نموذج عمل مُحسن للموارد استنادًا إلى النفقات الرأسمالية (CAPEX) إلى نموذج مُحسن للسوق استنادًا إلى النفقات التشغيلية (OPEX). ومن الأمثلة على الانتقال من CAPEX إلى OPEX هو استخدام خدمات أمازون السحابية AWS بدلًا من إنشاء بنية تحتية من الصفر والتي ستُخدّم المشروع. ومن بين الفوائد الأخرى، يساعدك إتحاد الأشخاص والعمليات والمنتجات على رفع قيم العمل الأساسية، مثل زيادة قيمة الأعمال Business Value، مثل: زيادة قيمة الموظف، وقيمة العميل وقيمة الموارد وكثير من هذه القيم التي لا تقاس مباشرة بالقيم النقدية، بالإضافة إلى تقليل أوقات دورة التسليم، وتمكين الجميع من التعلم والتكيّف وتطوير مستواهم بشكل مستمر. يركز المهندسون (مثلي) عادة على المنتجات والأدوات والتقنيات. إذا أردنا النجاح في الانتقال إلى DevOps، فمن المهم أن ندرك أنه لا يمكنك شراء أو تركيب DevOps! المنتجات هي أدوات داعمة، وليست الحل السحري للأمر، فهي تتيح لك التركيز على النتائج، مثل الأتمتة، والتطابق، والموثوقية، والقدرة على الصيانة، وتمكين الميزات أو تعطيلها بشكل تدريجي، و تصور الخطوات اللازمة للانتقال من إنشاء المنتج إلى تسليمه إلى العميل النهائي أو ما يسمى flow of value. عندما نتحدث عن العملية، فإننا غالبًا ما نتجه نحو الأتمتة لرفع قيمة الكفاءة والاستقرار والثبات. ومن المهم أيضا تضمين أهداف الاحتفال بالنجاح سواءً كفريق أو منظمة، والتركيز على الجودة انطلاقًا من تصوّرها وتخيلها وانتهاءً بتحقيقها على أرض الواقع، وإنشاء عملية إدارة التغيير بحيث تكون سريعة الاستجابة وخفيفة، واحتضان البنيات المترابطة بشكل خفيف (loosely coupled architectures) لتمكين التطوير، والسعي إلى إصدار عدة مميزات جديدة في اليوم. إن جوهر هذا التحول هو تحول الناس وثقافتهم وليس المنتجات أو العمليات أو حتى حجم المنظمة. يحتاج الناس لأن يدركوا أهمية التحول وأن يعتنقوا فكرة DevOps، وأن يفهموا كيف ستتأثر مهامهم ووظائفهم، ويجب عليهم تحمل مسؤولية أدوارهم المنوطة إليهم في هذا التحول. ويجب عليهم أيضًا أن يدركوا أن DevOps لا تقتصر على التنمية والعمليات، حتى وإن كان اسمها بحد ذاته يدل على ذلك ويستبعد أصحاب المصلحة الآخرين.إنك تحتاج إلى إزالة جميع العوائق والمفاهيم الخاطئة داخل مؤسستك والتي تمنع من الانتقال إلى DevOps، وأن تجمع بين كلّ أصحاب المصلحة ومن جميع الأقسام في الشركة، بما في ذلك أقسام التطوير وخدمات البيانات والعمليات والأمان والأعمال إلى أن يتم تحقيق التحول إلى DevOps. ترجمة -وبتصرف- للمقال Breaking down walls between people, process, and products لصاحبه Willy-Peter Schaub

كيف شَكّل نموذج الشلال (Waterfall)، والنموذج المرن (Agile)، وغيرها من أُطر التطوير الشكل الحالي DevOps؟ إليك ما اكتشفناه. إذا أردت أن تحلل حمض DevOps النووي، فما الذي ستعثر عليه في تقرير أسلافها؟ هذه المقالة ليست مقاربة منهجية، لذا فإن كنت تبحث عن نصيحة أو مناقشة حول أفضل المنهجيات المتبعة لهندسة البرمجيات، فيمكنك التوقف عن القراءة هنا. لأننا في هذا المقال سنبحث في التسلسل التاريخي للمنهجيات منذ نشأتها إلى وقتنا الحالي وسنتعرف كيف أصبحت DevOps في مقدمة التحولات الرقمية في يومنا الحالي. لقد تطورت DevOps عبر الكثير من التجربة والخطأ، مع سعي الشركات للاستجابة لطلبات العملاء وتحسين الجودة والصمود في السوق مع ازدياد التنافسية بشكل متصاعد. ومما يزيد هذا التحدي صعوبةً هو انتقال الاقتصاد العالمي القائم على المنتجات إلى الاقتصاد العالمي القائم على الخدمات والذي أدى اتصال الناس بطرق جديدة. أصبحت دورة حياة تطوير البرمجيات المبنية على الخدمات والخدمات المصغرّة متزايدة التعقيد، كلًا من المتصلة ببعضها بعضًا و المجمعّة. لذا فإن DevOps دفعت للتطور بشكل أسرع وأكبر من أي وقت مضى، وإن سرعة التغيير هذه ستمحو المنهجيات التقليدية الأبطأ مثل نموذج الشلال (waterfall). بالتأكيد نحن لا نقلل من شأن نموذج الشلال فالعديد من المنظمات لديها أسباب وجيهة للاستمرار في استخدامه. لذا ينبغي على المنظمات الواعية أن تهدف إلى الابتعاد عن العمليات أو المنهجيات التي تُهدر الوقت، وإن الكثير من الشركات الناشئة تمتلك ميزة تنافسية على الشركات التي تستخدم نهجًا تقليديًا في عملياتها اليومية. والجدير بالذكر أن أغلب النماذج الحالية من نموذج التصميم الرشيق (Lean) ونموذج (Kanban) ونموذج التصميم المستمر (Continuous) ونموذج التصميم المرن (agile) تتتبع مبادئ وعمليات تعود إلى أوائل الأربعينات، لذا لا يمكن أن ندعي DevOps أنها فكرة جديدة كليًا. دعنا نعود بالزمن لبضع سنوات وننظر إلى نماذج تطوير البرمجيات مثل نموذج الشلال، والنموذج الرشيق، والنموذج المرن. يوضح الشكل التالي المخطط الزمني لتطور دورة حياة تطوير البرمجيات. (تذكر أننا لا نبحث عن أفضل طريقة ولكننا نحاول فهم المنحى الذي أحدث تأثيرًا إيجابيًا على هندسة البرمجيات والتي قمنا بتجميعها منذ 67 عامًا والتطور الذي حصل على مرِّ هذه السنوات حتى وصولنا لعقلية DevOps). نموذج الشلال التقليدي (Waterfall) من وجهة نظرنا، تأتي أقدم الممارسات من نموذج الشلال، الذي قُدم لأول مرة من قبل الدكتور وينستون دبليو رويس في ورقة نشرت في السبعينيات. يؤكد نموذج الشلال على النهج التقدم المنطقي والتتابعي من خلال مراحل جمع المتطلبات والتحليل وصياغة الشيفرة البرمجية والاختبار وهذه المراحل في إتجاه واحد أي يجب عليك إكمال كل مرحلة على حدة، وذلك باستكمال جميع المعايير المطلوبة في المرحلة وبعدها تستطيع أن تبدأ بالمرحلة التالية. يفيد نموذج الشلال في المشاريع التي تحتاج إلى تسلسلات صارمة والتي لها مجال مفصل ويمكن التنبؤ به أو المشاريع التي القائمة على الأحداث. وخلافا للاعتقاد السائد، فإنه يسمح أيضا للفرق بتجربة وإجراء تغييرات في التصميم في وقت مبكر خلال مرحلة جمع المتطلبات ومرحلة التحليل، ومراحل التصميم. نموذج التصميم الرشيق (Lean) رغم أن التصميم الرشيق يعود إلى عام 1450 في مدينة البندقية، إلا أننا سنبدأ عندما قامت تويوتا بإنشاء نظام إنتاج تويوتا، الذي طوره المهندسون اليابانيون بين عامي 1948 و 1972. ونشرت تويوتا وصفًا رسميًا للنظام في عام 1992. يستند نموذج التصميم الرشيق إلى خمسة مبادئ: القيمة ومجرى القيمة والتدفق والسحب والكمال. ويكمن جوهر هذا النهج في فهم ودعم تدفق قيم فعال والتخلص من العمليات التي لا تضيف قيمة وتعدّ هدرًا وضياعًا وتقديم قيمة مستمرة للمستخدم. ويهدف أيضًا لإسعاد المستخدمين بدون انقطاع. نموذج Kaizen تعتمد kaizen على التحسينات الإضافية وتتكون دورة حياة kaizen المراحل التالية: التخطيط ->التنفيذ->التحقق->التصحيح. وتهدف عقلية kaizen للتوجه للتحسين المستمر. طُوّر مفهوم kaizen في الأصل لتحسين تدفق وعمليات خط التجميع، وهو يضيف أيضًا قيمة عبر سلسلة التوريد. وكان نظام إنتاج تويوتا واحدًا من أوائل المنفذين لنموذج kaizen والتحسين المستمر. يعمل كل من kaizen و DevOps معا بشكل جيد في البيئات التي ينتقل فيها سير العمل من التصميم إلى الإنتاج. يركز kaizen على مجالين: التدفق (هو التوجه نحو تدفق المواد والمعلومات) العملية (وهي تعني تحسين وضعية عمل الشخص) التسليم المستمر (Continuous Delivery) وقد ألهمت kaizen تطوير العمليات والأدوات لأتمتة الإنتاج. وقد تمكنت الشركات من تسريع الإنتاج وتحسين الجودة والتصميم والبناء والاختبار والتسليم عن طريق تقليل مصادر الهدر (بما في ذلك الثقافة والعقلية) والتوجه نحو الأتمتة قدر الإمكان وذلك باستخدام الآلات والبرمجيات والروبوتات. كما أن معظم فلسفة kaizen تنطبق أيضا على الممارسات التجارية والبرمجيات غير المحدودة ونشر التسليم المستمر لمبادئ وأهداف DevOps. نموذج التصميم المرن (Agile) ظهر بيان تطوير البرمجيات المرنة في عام 2001، والذي كتبه مجموعة من الشبان الطموحين النهج المتبع في التطوير. إن النموذج المرن لا يقوم على إهمال الحيطة والحذر، أو كسر خطط التصميم، أو بناء برمجية بخشونة أو بشكل عشوائي. وإنما هو أن تكون قادر على الإنشاء والاستجابة للتغييرات. يعتمد نموذج المرن على اثني عشر مبدأً والتي تقدر الأفراد والتعاون فيما بينهم والبرمجيات الصالحة للاستعمال والتعاون مع العملاء، والاستجابة للتغيير. النموذج المرن المنضبط (Disciplined Agile Delivery) ومنذ أن ظل البيان المرن ثابتًا لمدة 20 عامًا، بحث العديد من الممارسين للنموذج عن طرق لإضافة خيارات إضافية ومخصصة إلى النهج. بالإضافة إلى ذلك، يركز البيان المرن بشكل كبير على التطوير، لذا تكونت الحاجة الماسّة إلى الحلول بدلًا من الشيفرات البرمجية أو البرمجيات وخصيصًا في بيئة التطوير السريعة اليوم. شارك سكوت أمبلر وماركس بريز في تأليف عملية تسليم المرنة المنضبطة وإطار عمل مرن ومنضبط، استنادًا إلى خبرتهما في شركة Rational و IBM والمنظمات التي تحتاج فيها الفرق إلى مزيد من الخيارات المتاحة أو الشركات التي لم تكن ذات خبرة بما يكفي لتنفيذ المنهجية الرشيقة (lean)، أو حيث لا يتناسب دورة حياة البرمجية مع سياق النهج. تأتي أهمية النموذج المرن النضبط أو ما يعرف DAD (اختصارًا للعبارة Disciplined agile delivery) و DA (اختصارًا للعبارة Disciplined agile) من أنه يسمح لنا باتخاذ قرارت حول العمليات بشكل مبسط من أجل تقديم حلول تدريجية ومتكررة. ويعتمد DAD على العديد من ممارسات تطوير البرمجيات المرنة (Agile)، بما في ذلك ممارسات Scrum، وممارسات نموذج الرشيق (Lean)، وغيرها. إن الاستخدام المكثف للنمذجة الرشيقة وإعادة تحليل، بما في ذلك تشجيع الأتمتة من خلال نموذج التطوير القائم على الاختبار TDD (اختصارًا للعبارة Test-driven Development)، والتصميم الرشيق مثل Kanban و XP و Scrum و Rup من خلال اختيار واحدة من خمس دورات حياة رشيقة، وإدخال مفاهيم هيكلية المالك (Architecture Owner)، يكتسب الممارسين لنموذج المرن مجموعة من الأفكار وطرق التفكير وعمليات وأدوات لتحقيق DevOps بنجاح. نموذج DevOps وعلى المدى الذي يمكننا أن نجمع فيه، ظهرت DevOps خلال سلسلة من DevOpsDays في بلجيكا في عام 2009، لتصبح الأساس للعديد من التحولات الرقمية. يعرّف مدير DevOps الأساسي في شركة مايكروسوفت Donovan Brown نموذج DevOps بأنه والآن لنعود إلى سؤالنا الأصلي: إذا أردت أن تحلل حمض DevOps النووي، فما الذي ستعثر عليه في تقرير أسلافها؟ إننا ننظر إلى التاريخ الذي يعود إلى 80 و48 و26 و17 عامًا، ولكن في وقتنا الحالي إن البيئة اليومية سريعة الإيقاع وغالبًا ما تكون مضطربة. بطبيعتنا نحن البشر نختبر ونجرب باستمرار ونتعلم ونتكيّف ونورّث نقاط القوة ونحل نقاط الضعف تيمّنًا بجيناتنا الوراثية. يمكنك استخدام القياس عن بعد الذي تجمعه من مشاهدة الحل الخاص بك في الإنتاج وذلك لإدارة التجارب، وتأكيد الفرضيات، وترتيب أولويات الأعمال المتراكمة لديك. بمعنى آخر، يرث Devops من مجموعة متنوعة من الأطر والمنهجيات التي أثبتت جدارتها وتطورها، ويمكّنك من تحويل ثقافتك، واستخدام المنتجات كأدوات مساعدة، والأهم من ذلك، إرضاء عملائك. إن كنت مرتاحًا مع نموذج التصميم الرشيق أو المرن، فإنك حتمًا ستستمتع بفوائد DevOps. وإن كنت تستخدم نموذج الشلال فإن عقلية DevOps ستساعدك كثير في تعزيز التطوير. نموذج eDevOps في عام 2016، صاغ Brent Reed مصطلح eDevOps (لا توجد له مراجع في Google أو ويكيبيديا حتى هذه اللحظة)، وهو يُعرف بأنه "طريقة للعمل (Way of Work) التي تجلب التحسين المستمر في الشركة بسلاسة، من خلال الأشخاص والعمليات والأدوات. وجد برانت أن النموذج المرن فشل في شركات تقنية المعلومات فالشركات التي اعتمدت تفكيرًا رشيقًا كانت لا تحقق قيمة (Value) للعملاء ولم تحقق أيضًا التركيز والسرعة التي توقعوها خبراء النموذج المرن الموثوق بهم في مجال تكنولوجيا المعلومات. وعندما شعر بالإحباط لرؤية "برج عاجي" تم فيه فصل فريق خدمات تقنية المعلومات المستقل عن فرق الدعم في مجال الهندسة والتطوير والعمليات ومكتب المساعدة، عندها طبق معرفته السابقة بنموذج التسليم الرشيق المنضبط (DAD)، وأضاف بعض الأهداف والتطبيقات العملية لمجموعة أدوات DAD، من ضمنها: التركيز على الثقافة ودفعها من خلال عقلية التحسين المستمر (Kaizen)، والجمع بين الناس حتى عندما يكونون في غرفة واحدة. السرعة من خلال الأتمتة (TDD + إعادة تحليل كل شئ ممكن)، إزالة الهدر واعتماد نهج TOGAF، أو JBGE (وهو جيد إلى حدٍ ما) من أجل التوثيق تقديم القيمة (Value) من خلال النمذجة (نمذجة التصميم) و (shift left) لتمكين الكشف عن الأنماط المتضاربة أثناء المشاركة من خلال أنماط التعاون في مستودع رقمي أكثر تنوعا واستراتيجيا حديث باستخدام خبرته مع AI في IBM، صمم برنت نموذج eDevOps الذي يقوم بشكل متزايد بأتمتة لوحات التحكم لأغراض القياس وصنع القرار بحيث يتم التحسين المستمر من خلال النشر المستمر (أتمتة العمليات من مرحلة التطوير إلى مرحلة الإنتاج) لجلب الإمكانيات الحقيقية لأي منظمة. إن برنامج التحول الفعال إلى eDevOps الذي يُبنى على التحول المنضبط إلى DevOps يُمكننا من القيام بما يلي: تحويل نظام الأعمال إلى Bizdevops) DevOps). تحويل نظام الأمن إلى SecDevOps) DevOps). تحويل نظام المعلومات إلى DataDevOps) DevOps). تقديم خدمات تقنية مترابطة بشكل خفيف والتي تجمع بين جميع أصحاب المصلحة. بناء حلول قابلة للاستخدام كل أسبوعين أو أسرع. جمع وقياس وتحليل وعرض وأتمتة الرؤية القابلة للتنفيذ من خلال عمليات DevOps من المفهوم من خلال الاستخدام المباشر للإنتاج. تحسين مستمر امتثالًا بنموذج Kaizen ونموذج الرشيق منضبط. المرحلة التالية في تطوير DevOps في النهاية هل تعدّ DevOps مجموعة من العبارات الطنانة والأفكار التقنية التي تُلقى على الشركات؟ سوف ندرك بكل تأكيد مع مرور الوقت كيف DevOps سيتقدم ويتطور. ومع ذلك، فإن حمض DevOps النووي يجب أن يستمر في النضج وأن يُنقح، ويجب أن يفهم المطورون أنه ليس الحل السحري ولا علاج لكل الأمراض والحلّ لكل المشاكل. إذن ما هي العلاقة بين DevOps وبقية النماذج السابقة DevOps != Agile != Lean Thinking != Waterfall DevOps != Tools !=Technology إن DevOps تحتوي على ممارسات من النموذج المرن (Agile) ونموذج التصميم الرشيق (Lean) ونموذج الشلال (Waterfall). ترجمة -وبتصرف- للمقال Analyzing the DNA of DevOps لصاحبيه Willy-Peter Schaub و Brent Aaron Reed

في خضم السباق المحموم نحو الرقمنة، أصبحت فرق التطوير تمثّل العمود الفقري للعديد من المؤسّسات. لقد أصبح يتعين على أفرادها إلى جانب فرق العمليات القيام بمهمّات أكثر من أي وقت مضى. غالبًا ما تقود هذه الفرق الابتكار والتغيير في نفس الوقت الذي تحافظ فيه على النظام القديم وتضمن أداء المنتجات أو الخدمات باستمرار. إن المؤسّسات التي تسمح لفرق التطوير والعمليات لديها بالمرونة والسرعة في التحرك واستثمار الفرص تكون في الغالب مؤسّسات ناجحة، وهذا ما يجعل العديد من المنظمات تعطي الأولوية لبناء وتعزيز ثقافة DevOps. تجمع ثقافة DevOps بين فريق التطوير (DEVelopment) وفريق العمليات (OPerationS) في هيكل واحد سعياً لإنشاء البرامج بسرعة و بأقل نسبة من الأخطاء. إن ثقافة DevOps هي تحوّل كبير من الثقافة التقليدية لتكنولوجيا المعلومات؛ فبدلاً من أن يعمل فريقا التطوير والعمليات بشكل منفصل، تسهّل ثقافة DevOps التواصل بينهما من خلال جعلهما يعملان على أهداف مشتركة. ويتطلب الأمر أن يفهم كل منهما الأهداف ويتمكّنا من العمل سويًا لإنجاح الأعمال. يمكن أن تساهم الثقافة السليمة لدى فريق DevOps في عوائد ضخمة للمؤسسة. أفادت دراسة شملت 4600 فريق لتكنولوجيا المعلومات أن أولئك الذين يتبنون ثقافة DevOps نشروا برامج أكثر مائتي مرة من الفرق ذات الأداء المنخفض. لقد أمضوا نصف الوقت اللازم فقط لإصلاح مشكلات الأمان، وحققوا زمن استردادٍ أقلّ لبرامجهم ، وكان معدل فشل التغيير لديهم أقلّ ثلاث مرات. وبالتالي، يمكن لجميع المنظمات تقريبًا أن تجد بعض المزايا في تبني ثقافة DevOps، ولكن ماهي هذه الثقافة؟ وما هي تجلياتها؟ احرص على قياس أداء فريقك ومساءلته وكن شفافًا إنه من المهمّ للغاية، في كل مرحلة، وضع مؤشرات أداء رئيسية واضحة (KPIs). يجب أن يعرف أعضاء الفريق دائمًا ما هو مُتوقّع منهم وكيف يلائم المشروع الكلي. لا تؤدي هذه الشفافية إلى تحسين التواصل فحسب، بل يمكن أن تفيد أيضًا في مساءلة الفريق. في الماضي، كانت العديد من الشركات تميل إلى عزل العمّال عن الأهداف و التصورات العامّة. ولا تتمّ مشاركة عناصر المشروع إلا على أساس "الحاجة إلى المعرفة". لكن فرق DevOps المميزة تخطت هذا المفهوم بشكل كامل. يجب أن يعلم الجميع كيف تعمل الأنظمة وكيف تتوافق الأشياء معًا. توفر أدوات التعاون مثل Microsoft Azure DevOps Server وبدائل أخرى ذات مصادر مفتوحة للفرق صورة واضحة لمراحل المشروع خلال التخطيط والتطوير والاختبار والنشر. ينبغي أن تتأكد من أن كل عضو في الفريق يفهم الهدف المشترك. كلما زاد فهم أعضاء الفريق لدورهم ومدى ملاءمته للآخرين، زادت كفاءة أدائهم. أنت بهذا تريد أعضاء الفريق أن يعملوا بنوع من المراقبة المتبادلة عبر المجموعات الوظيفية. أتمِت ما تستطيع يتمثل جزء كبير من ثقافة DevOps في التشغيل التلقائي قدر الإمكان وتوحيد منصات الإنتاج. يساعد التقييس والأتمتة في جعل عمليات النشر أكثر قابلية للتنبؤ بها وأقل عرضة للأخطاء البشرية. اعمل على أتمتة أي شيء يمكنك كجزء من سيرورة العمل، بما في ذلك البنية التحتية القابلة للتطوير والالتزام ومسلسل التسليم المستمر. على سبيل المثال، تسمح أدوات مثل Docker لفرق التطوير بأتمتة عمليات نشر التطبيقات بسرعة ملحوظة. من خلال تقليل المهام اليدوية والمتكررة، ستزيد من تطوّرك وسرعة اختبارك مع تقليل الأخطاء بشكل ملموس. بالإضافة إلى ذلك، من خلال التخلص من المهام الشاقة والمتكررة، ستحرّر أيضًا فريقك ليستطيع العمل على مهام رفيعة المستوى وتقلّل من التعب والإرهاق لديه. اخلق ثقافة التعاون يمكن أن يكون اعتماد ثقافة DevOps فرصة لكسر الجدران بين المستوى الإداري ووحدات العمل تمامًا. في بعض الأحيان يكون لفريق التطوير وفريق العمليات أولويات مختلفة، وهذا جيد، لكن يجب أن تعمل الشركات على إنشاء جسر تواصل بينهما. في ثقافات تكنولوجيا المعلومات الأخرى، يُقسّم تطوير البرامج لتحقيق السرعة عن طريق عزل أعضاء الفريق إلى أجزاء من المشاريع. يركز فريق التطوير على البرامج الجديدة والمبتكرة، بينما يعمل فريق العمليات على تخفيف المخاطر والحفاظ على النظام. لكن يمكن أن تخلق هذه الأولويات بعض الصدامات. تعمل ثقافة DevOps على مدّ الجسور بين هذه الأولويات عبر التواصل المبكر والمستمر. من خلال الجمع بين الفرق من بداية تطوير البرنامج، يمكنهم تحديد المخاطر والأخطاء والأعطاب قبل إرسال البرنامج إلى فرق العمليات. لن تنتظر الفرق حتى النهاية لتجتمع معًا ثم تُحدّد المشكلات التي كان يمكن حلها في وقت مبكر من دورة التطوير. تعني هذه المقاربة التشاركية أنه يمكن تطوير البرنامج بشكل أسرع مع وجود نسبة أقل من الأخطاء. بالإضافة إلى التحول الثقافي، ستحتاج الفرق إلى أدوات تطوير DevOps جديدة، مثل سجلات JFrog و Go ، والتي تتيح التقسيم والتعاون. إذ توفّر أدوات مثل هذه رؤية أوضح فضلا عن التواصل بين أعضاء الفريق. يخلق وجود مهام العمليات والتطوير عند نفس الفريق التعاون بين أفراده. بالإضافة إلى تعزيز الشعور الإيجابي بالفريق وأهميته، يمكن لثقافة DevOps أيضًا مساعدة أعضاء الفريق على تنمية مهاراتهم على المستوى الفردي أو إظهار مواهب أخرى. من خلال الجمع بين التطوير والعمليات، يكون قادة الفريق قادرين على تحديد طريقة تفكير الناس خارج مجال خبرتهم المحددة. يمكن أن يساعد تحدي أعضاء الفريق في التفكير فيما وراء أهدافهم ومعالجة المشكلات بشكل تعاوني الأفراد على إضافة مهارات أو رؤى إضافية إلى العملية الإجمالية. وقد يساعد هذا القادة في العثور على أعضاء الفريق اليوم الذين يستطيعون أن يصبحوا قادة فرق الغد. ضع أهدافاً واقعية وشفافة لا يوجد شيء أكثر إحباطًا لفرق DevOps من الأهداف غير الواقعية. إذا شعروا أن ما يطلب منهم القيام به أمر مستحيل، فمن المحتمل ألا يقدموا لك قصارى جهدهم. ومن خلال زيادة التواصل والرؤية بين الفرق، سيتمكن المديرون من وضع أهداف واقعية يمكن تحقيقها بشكل معقول. علاوة على ذلك، يفهم أفراد DevOps أيضًا بالعمل معًا جنبًا إلى جنب أداء الفريق بأكمله. عندها يكونون قادرين على معرفة أين تتأخر المشروعات أو ما إذا كانت تتقدم بشكل صحيح في إطار المسلسل برمّته. إن التخلي عن فكرة الفرق المنفصلة يمكّن الأفراد من التدخل والمساعدة عندما تكون أي لبنة رئيسية في خطر. من خلال رؤية العملية بكاملها، يكون حماسهم والتزامهم بالمشروع أكبر وتكون قدرتهم على إحداث تغيير إيجابي عند الحاجة وضمان تسليم المزيد من المشاريع في الوقت المحدد أعلى. هيّئ بيئة مشتركة للتعلّم والتحسين المستمر تتّسم أفضل فرق DevOps بالمرونة وتبحث باستمرار عن طرق للتحسّن. ويتجلى جزء مهمّ من التحسين المستمر في تكوين حلقات رسمية وغير رسمية للتواصل. يكتسي هذا الأخذ والعطاء أهمية بالغة بين الفرق والفروع المتخصّصة. فبالتواصل المنتظم بين وحدات الإنتاج والتطوير والتصميم والإدارة، يمكنك تقليل الوقت اللازم للتطوير. كما أن هذا يُمكّن كلّ فرد في فريق DevOps من التعرف على دوره في المنتج الإجمالي. يحب الناس أن يكونوا جزءًا من الفرق الناجحة التي تحقّق أهدافها وتتجاوزها باستمرار. إن النجاح يولد النجاح. وفي الوقت نفسه، من الأرجح أن يغادر أعضاء الفريق الذين لا يشعرون بالتحدي في عملهم أو الحصول على تقدير لمساهمتهم. لثقافة DevOps مزايا متنوعة ختامًا، تعدّ الفرق السريعة والمرنة والمبتكرة حيوية لنجاح الأعمال، ويمكن لثقافة DevOps أن تساعد في دفعها قُدماً نحو الأمام. فهي توفر تواصلًا أقوى، وترسم أهدافًا موحدة وشفافة، وتضع جداول زمنية واقعية. من خلال تشجيع الأتمتة وتوحيد العمليات، تُتيح DevOps أيضًا إنتاج برامج أسرع بأخطاء أقلّ. كما أنها تساهم في إيجاد أعضاء فريق سعداء ومتمكّنين يستطيعون المساهمة بأساليب جديدة. ربّما يكون اعتماد ثقافة DevOps هو الميزة التنافسية التي تحتاج إليها مؤسستك. ترجمة -وبتصرف- للمقال Why every dev team should adopt a DevOps culture in 2019 لصاحبه Matt Shealy

إزالة بعض الالتباس حول مفهوم DevOps. يتعرف الكثير من الناس على DevOps للمرّة الأولى عند رؤيتهم لإحدى انتاجاتها وتساؤلهم عن كيفية حدوث ذلك. إذ أنه ليس من الضروري فهم فيما إذا كان شيء ما يشكل جزءًا من DevOps للبدء بتنفيذه، لكن معرفة ذلك – ومعرفة ما الذي يجعل من DevOps استراتيجية مهمة- يمكن أن تشّكل الفارق بين كونك قائدًا أو تابعًا في مجالٍ ما. ربما سمعت عن بعض النتائج المدهشة التي تُنسب إلى DevOps، مثل بيئات الإنتاج عالية المرونة والتي يمكنها التعامل مع الآلاف من الإصدارات يوميًا بينما تدور أداة "Chaos Monkey" (وهي أداة برمجية طُوّرت بواسطة مهندسي Netflix لاختبار مرونة واسترداد خدمات Amazon Web Services [اختصارًا AWS] الخاصة بهم) حول هذه الاصدارات لفصل الأشياء بشكل عشوائي. هذا أمر مثير للإعجاب، ولكنه في حد ذاته يُمثل حالة عمل ضعيفة، مثقلة بشكل أساسي بإثبات سلبي (proving a negative): أن بيئة DevOps مرنة لأنه لم يُلاحظ فشل خطير ... حتى الآن. يوجد الكثير من الالتباس حول مفهوم DevOps ولا يزال الكثير من الناس يحاولون فهم ذلك. إليك مثال عن شخص ما عبر حسابي على موقع التواصل الاجتماعي LinkedIn: يتابع هذا المنشور المتخصصون في المجال التقني على موقع LinkedIn عبر شريحة واسعة من الإجابات. فكيف ترد؟ جذور DevOps في التصميم الرشيق (lean) والتصميم المرن (agile) تُعد DevOps أسهل للفهم إذا بدأنا باستراتيجيات هنري فورد وتحسينات نظام إنتاج تويوتا لنموذج فورد. وضمن هذا التاريخ ظهور منهجية التصميم الرشيق (lean)، والتي دُرست جيدًا. قام جيمس ب. ووماك ودانييل جونز في كتاب Lean Thinking بتلخيصها إلى خمسة مبادئ: تحديد القيمة المرغوبة من قبل العميل. تحديد سلسلة القيم لكل منتج يوفر هذه القيمة ويلغي جميع الخطوات المهدورة اللازمة حاليًا لتوفيره. جعل تدفق المنتج متواصلًا من خلال خطوات القيمة المضافة المتبقية. ادخال السحب بين جميع الخطوات التي يكون فيها التدفق المستمر ممكنًا. إدارة نحو الاكتمال بحيث ينخفض باستمرار عدد الخطوات ومقدار الوقت والمعلومات اللازمة لخدمة العملاء. تسعى منهجية التصميم الرشيق إلى إزالة الهدر باستمرار وزيادة تدفق القيمة إلى العميل. يمكن التعرف عليها بسهولة وفهمها من خلال مبدأ أساسي للتصميم الرشيق وهو مبدأ: تدفق القطعة الواحدة. يمكننا القيام بعدد من الأنشطة لمعرفة السبب في أن تحريك قطعة منفردة في كل مرة أسرع من تحريك قطع متعددة دفعة واحدة؛ إن لعبة Penny Game و لعبة الطائرة Airplane Game أمثلة على ذلك. ففي لعبة Penny، إذا استغرقت دفعة الـ 20 بنس دقيقتين للوصول إلى العميل، فسيحصل على كامل الدُفعة بعد دقيقتين من الانتظار. بينما إذا نقلت بنس واحد في كل مرة، فسيحصل العميل على أول بنس في غضون خمس ثوانٍ ويستمر في الحصول عليهم بنس تلو الآخر حتى يصل البنس العشرين بعد 25 ثانية تقريبًا. وهذا يعتبر فرقًا كبيرًا، ولكن ليس كل شيء في الحياة بسيط ويمكن التنبؤ به كما هو الحال هنا في مثال البنس في لعبة بيني. ومن هنا أتت «المنهجية المرنة» (agile). بالتأكيد نرى مبادئ Lean تنسحب على فرق Agile عالية الأداء، ولكن هذه الفِرق تحتاج إلى ما هو أكثر من مبادئ Lean للقيام بعملها. تركز عملية التصميم المرن Agile من أجل التمكن من التعامل مع عدم القدرة على التنبؤ وتباين مهام تطوير البرامج النموذجية، على المعرفة الصحيحة والتشاور والقرار والعمل على ضبط المسار في مواجهة الوقائع المتغيرة باستمرار. على سبيل المثال، تزيد الأطر الرشيقة (مثل «فريق سكروم» [scrum]) من الوعي بالمهام مثل الجاهزية اليومية والمراجعة الزمنية. فإذا أصبح فريق سكروم مدركًا لحقيقة جديدة، فإن الإطار يسمح له ويشجعه على ضبط المسار إن لزم الأمر. تحتاج الفِرق لاتخاذ هذه الأنواع من القرارات، إلى أن تكون منظمة ذاتيًا في بيئة عالية الثقة. تحقق فرق التصميم المرن عالية الأداء التي تعمل بهذه الطريقة تدفقًا سريعًا للقيمة مع ضبط للمسار بشكل مستمر، مزيلةً بذلك مضيعة الوقت في السير بالاتجاه الخاطئ. حجم الدفعة الأمثل يساعد فهم اقتصاديات حجم الدُفعات على فهم قوة DevOps في تطوير البرمجيات. تأمل الرسم التوضيحي الأمثل لمنحنى U التالي من كتاب دونالد راينترسن مبادئ تدفق تطوير المنتجات Principles of Product Development Flow: يمكن تفسير ذلك بتشبيه حول التسوق في البقالية. افترض أنك بحاجة إلى شراء بعض البيض وتعيش في مكان يبعد 30 دقيقة من المتجر. إن شراء بيضة واحدة (أقصى اليسار على الرسم التوضيحي) في المرة الواحدة يعني رحلة لمدة 30 دقيقة في كل مرة تريد فيها شراءها. هذه هي تكلفة المعاملة (transaction cost). قد تمثل تكلفة الحجز (holding cost) البيض التالف وشغل المساحة في الثلاجة لفترة من الزمن. التكلفة الإجمالية (total cost) هي تكلفة المعاملة مضافًا إليها تكلفة الحجز في الثلاجة. يفسر منحنى U هذا السبب، بالنسبة لمعظم الناس، بإن شراء أكثر من 12 بيضة (دزينة) في وقت واحد هو الحجم الأمثل للدفعة. إذا كنت تعيش بجوار المتجر، فستكلفك القليل من المشي إلى هناك، وربما تشتري كرتونًا أصغر حجمًا في كل مرة لتوفير مساحة في الثلاجة والاستمتاع بالبيض الطازج. يمكن لهذا الرسم التوضيحي لتحسن منحنى U توضيح سبب زيادة الإنتاجية بشكل كبير في تحويلات المنهجية المرنة الناجحة. تأمل في تأثير تحويل agile على صنع القرار في المنظمة. تكون سلطة اتخاذ القرار مركزية في المنظمات الهرمية التقليدية. هذا يؤدي إلى اتخاذ عدد أكبر من القرارات وبتواتر أقل ومن قبل عدد أقل من الأشخاص. حيث ستعمل المنهجية المرنة (agile) على تقليل تكلفة معاملات المؤسسة بشكل فعال لاتخاذ القرارات من خلال تطبيق اللامركزية على القرارات إلى المكان الذي تكون فيه المعرفة والمعلومات متوفرة بشكلها الأمثل: أي إلى فرق agile ذات الوثوقية العالية والتنظيم الذاتي. توضح الرسوم المتحركة التالية كيف يؤدي خفض تكلفة المعاملة إلى تغيير الحجم الأمثل للدُفعة إلى اليسار. لا يمكنك التقليل من قيمة المؤسسة في اتخاذ قرارات أسرع بشكل متكرر. أين تكون DevOps أكثر ملائمة؟ إن الأتمتة هي إحدى الأشياء التي تشتهر بها DevOps. يوضح الرسم التوضيحي السابق قيمة الأتمتة بتفصيل كبير. نقلل من خلال الأتمتة تكاليف معاملاتنا إلى ما يقارب الصفر، ونحصل بشكل أساسي على الاختبارات والنشر مجانًا. يتيح لنا ذلك الاستفادة من أحجام دُفعات العمل الأصغر والأصغر. إن دُفعات العمل الأصغر يسهل فهمها والالتزام بها واختبارها ومراجعتها ومعرفة وقت إنجازها. كما تنطوي أحجام الدُفعات الأصغر هذه أيضًا على تباين وخطر أقل، مما يجعلها أسهل للنشر واستكشاف الأخطاء وإصلاحها واستردادها عند حدوث خطأ ما. يمكننا من خلال الأتمتة المدمجة مع أنشطة agile القوية أن نجعل تدفق تطوير ميزاتنا قريبًا جدًا من تدفق قطعة واحدة، مما يوفر قيمة سريعة للعملاء بشكل متواصل. تُفهم DevOps بشكل أكثر تقليدية كطريقة لهدم جدران الالتباس بين فرق التطوير dev والعمليات ops. تُطوّر فرق التطوير في هذا النموذج ميزات جديدة، بينما تحافظ فرق العمليات على استقرار النظام وتشغيله بسلاسة. يحدث الالتباس لأن الميزات الجديدة من التطوير تُحدث تغييرًا في النظام، مما يزيد من خطر توقف الخدمة والذي لا يشعر فريق العمليات بالمسؤولية عنه -لكن عليه التعامل معه على أي حال. لا تكتفي DevOps فقط بمحاولة جعل الناس يعملون معًا فحسب، بل أيضًا بمحاولة إجراء تغييرات أكثر تكرارًا في بيئة معقدة وبشكل آمن. يمكننا إلقاء نظرة على أبحاث Ron Westrum للبحث في موضوع تحقيق السلامة في المنظمات المعقدة. فقد وجد عند البحث عن سبب كون بعض المنظمات أكثر أمانًا من غيرها أن ثقافة المنظمة هي التي تنبئ بسلامتها. وحدّد ثلاثة أنواع من الثقافة: «المرضيّة أو غير المُتوقعة» (Pathological)، و«البيروقراطية» (Bureaucratic)، و«الابداعية» (Generative). فوجد أن الثقافة المرضيّة كانت تنبئ بسلامة أقل وأن الثقافة الإبداعية كانت تنبئ بمزيد من السلامة (على سبيل المثال، عدد أقل بكثير من حوادث الطيران أو وفيات المستشفى عن طريق الخطأ في مجالات بحثه الرئيسية). تُحقق فرق DevOps الفعالة ثقافة ابداعية باستخدام أنشطة lean و agile، مما يدل على أن السرعة والأمان متكاملان، أو وجهان لعملة واحدة. تحقق DevOps من خلال تقليل الأحجام المثالية لدُفعات القرارات والميزات لتصبح صغيرة جدًا تدفقًا أسرع للمعلومات وللقيمة في الوقت الذي تزيل فيه الهدر وتقلل المخاطر. وفقا لبحث Westrum، يمكن أن يحدث التغيير بسهولة عند تحسين السلامة والموثوقية في نفس الوقت. عندما يتم الوثوق بفريق agile و DevOps لاتخاذ قراراته الخاصة، سنمتلك حينها الأدوات والتقنيات التي تشتهر بها DevOps اليوم: التشغيل الآلي والتسليم المتواصل. تٌقلل من خلال هذه الأتمتة تكاليف المعاملات أكثر من السابق، ويتحقق تدفق هائل على مبدأ القطعة الواحدة مما يخلق إمكانات لآلاف القرارات والإصدارات في اليوم، كما يجري في مؤسسات DevOps عالية الأداء. التدفق وردود الأفعال (التغذية الراجعة) والتعلم لا تتوقف DevOps عند هذا الحد. لقد كنا نتحدث بشكل رئيسي عن تحقيق DevOps لتدفق ثوري، ولكن يتم زيادة تضخيم أنشطة lean و agile من خلال جهود مماثلة تحقق حلقات تغذية راجعة أسرع كما تحقق تعلمًا أسرع. يشرح المؤلفون في كتاب DevOps Handbook بالتفصيل كيف يُنجز DevOps وفوق تدفقه السريع القياس عن بُعد عبر كامل تدفق القيمة لديه للتغذية الراجعة السريعة والمتواصلة. ستستفيد علاوة على ذلك فرق DevOps عالية الأداء باستمرار من التعلم والتحسين المستمر في أسس مؤسساتها، وذلك من خلال الاستفادة من رشقات «كايزن» (kaizen) الرشيقة و«الأثر الرجعي» (retrospectives) لـسكروم، مما سيؤدي إلى تحقيق ثورة في التصنيع في مجال تطوير منتجات البرمجيات. ابدأ بتقييم DevOps تتمثل الخطوة الأولى في الاستفادة من DevOps، إما بعد دراسة طويلة أو بمساعدة مستشار ومدرب من DevOps، في إجراء تقييم عبر مجموعة من الأبعاد الموجودة دائما في فرق DevOps عالية الأداء. يجب أن يحدّد التقييم قواعد الفريق الضعيفة أو غير الموجودة التي تحتاج إلى تحسين. قيّم نتائج التقييم لإيجاد مكاسب سريعة – التركيز على مجالات ذات فرص عالية للنجاح والتي ستؤدي إلى تحسينات شديدة التأثير. المكاسب السريعة مهمة لاكتساب الزخم اللازم لمعالجة المجالات الأكثر تحديًّا. يجب أن تولد الفرق أفكارًا يمكن تجربتها بسرعة والبدء في تحريك البوصلة باتجاه DevOps. يجب على الفريق مع مرور بعض الوقت إعادة تقييم الأبعاد نفسها لقياس التحسينات وتحديد مجالات تركيز جديدة عالية التأثير مجدّدا بأفكار جديدة من الفريق. سنلقي النظر في الجزء الثاني من هذه المقالة على نتائج استبيان DevOps في مجتمع «دروبال» (Drupal) ونرى أين يمكننا إيجاد المكاسب السريعة. ترجمة وبتصرف للمقال: Why DevOps is the most important tech strategy today لصاحبه: Kelly Albrecht. اقرأ أيضًا المقال السابق: رحلة المطور عبر DevOps كامل مقالات السلسلة.

انتهت أيام فرق التطوير وفرق العمليات المنعزلة. ما علاقة المطوًر «بور سوتر» (Burr Sutter وكتابه، The Phoenix Project؟ كما أوضح سوتر في حديثه المقتضب الذي استمر لمدة خمس دقائق في مؤتمر All Things Open 2016، فإنهم يشتركون في شغفهم بالتقنيين العمليين – وهم المطورون الذين يصممون شيفرات رائعة والمشغلون الذين يقومون بتطوير البنية التحتية لتشغيلها. وتابع سوتير قائلًا أن أيام فِرق التطوير وفرق العمليات المنعزلة انتهت، وأن مستقبل البرامج أن يعمل الجميع معا لإنشاء أعمال ذات قيمة أفضل وبشكل أسرع. استشهادًا برواية جين كيم The Phoenix Project حول إطلاق مبادرة تكنولوجيا المعلومات على نطاق واسع باستخدام مبادئ الـ DevOps، فقد شارك سوتر "مشروع Phoenix" الخاص به. حيث أراد أحد العملاء نظامًا جديدًا غير مرئي ينقله من واجهة المستخدم ذات النمط القديم إلى الويب، مما يتيح الخدمة الذاتية للعملاء عبر الويب. أخبر سوتر المدير التنفيذي أنّه وبالنظر إلى نطاق المشروع والقيود الزمنية المفروضة فإن الفريق "لن يكون لديه وقت حتى للنوم." فكان رد رئيسه تقريبًا: «يمكنك النوم عندما تكون ميتًا». بدأ سوتر وفريقه العمل بتطوير مخطط تفصيلي يركز على النواتج الأسبوعية، مع البقاء على اتصال دائم مع العميل، وتقديم نسخ تجريبية أسبوعية، ثم الانتقال مباشرة إلى الإنتاج. لكن "أبواب الجحيم فتحت" بعد خطأ أتلف نقاط بيع العميل وتكاملات الطرف الثالث. قال سوتر: "لقد فهمنا سريعًا أن السبيل الوحيد للخروج من هذا المأزق هو في المتابعة والمضي قدمًا – كلنا معًا– المطورين، وموظفي العمليات، ومديري قواعد البيانات، وموظفينا- الفريق بأكمله". أوجد الفريق التصحيحات سريعًا خلال ليلةٍ واحدة، وتأكّد من أن كل مطوّر عرف كيف كانت تُستخدَم شيفرته، وقام بفحص منتظم مع فريق العمليات، وخصّص أيام السبت بأكملها لإصلاح الأخطاء. استغرق الأمر مع فريق التطوير يومي سبت فقط للبدء في كتابة شيفرة أفضل بكثير وأكثر استقرارًا، وكان مستعدًا للذهاب في صباح اليوم التالي عندما بدأ العمل على الإنترنت. أوصى سوتر في الختام بكتابين من أشهر كتب جين كيم هما: The Phoenix Project و The DevOps Handbook. ترجمة وبتصرف للمقال: A developer's journey through DevOps. اقرأ أيضًا المقال التالي: لماذا تعد DevOps الاستراتيجية التقنية الأكثر أهمية اليوم المقال السابق: أفضل 5 لغات برمجة لـ DevOps كامل مقالات السلسلة.

نجمع هنا خمسًا من أفضل لغات البرمجة لـ DevOps وبعضًا من الموارد التعليمية المفيدة لكلٍ منها. ركزتُ على البنية التحتية لغالب حياتي المهنية، وقد تبدلت المهارات التقنية المحدّدة المطلوبة بمرور الزمن. سأضع في هذه المقالة، خمسًا من أفضل لغات البرمجة في مجال DevOps، والموارد التي كانت مفيدة للغاية بالنسبة لي، حيث كنت أُضيف هذه المهارات التطويرية إلى مجموعة أدوات البنية التحتية خاصتي. لا تُعد معرفة كيفية تجميع الخوادم وتكدسها مهارة في الطلب في هذه المرحلة. فمعظم مشاريع الأعمال لا تبني مراكز بيانات مادية لها. وبدلاً من ذلك، تُصمم وتبني مقدِرات الخدمة التي تُستضاف في البيئات السحابية العامة. تُهيئ البنية التحتية وتُنشر وتُدار من خلال التعليمات البرمجية. وهذا هو جوهر تصميم الـ DevOps - فعندما تتمكن المؤسسة من تحديد بنيتها التحتية في سطور من التعليمات البرمجية، يصبح عندها أتمتة معظم المهام (إن لم تكن جميعها) في مركز البيانات أمرًا ممكنًا. تتيح المستويات المتقدمة للأتمتة تمكين أنشطة «التركيب المتواصل / التسليم المتواصل» (Continuous Integration /Continuous Delivery CI/CD) التي لم تكن متاحة من قبل. تجعل مهام سير عمل CI / CD هذه من التسليم عملية سلسة خالية من الاحتكاك – حيث يستطيع المطور دفع شفرته إلى مستودع مصدري، وتتولى البنية التحتية تلقائيًا نشرها لدعم عمليات الاختبار التي يمكن أن تدفع تطبيق ما حتى مرحلة الإنتاج تلقائيا دون تدخل بشري. فعمل تقني يزحف تحت قبة أرضية مرتفعة لتوصيل كابلات الشبكة الجديدة لم يعد ضمن المسار الحرج لنشر تطبيق الإنتاج. تقوم فرق البنية التحتية الآن بتحويل قدراتها بعيدًا عن خوادم الأرفف والتكديس إلى دعم قنوات CI / CD، مما يعني شيفرة التعلم. تُنشر ملفات القوالب المضمنة في YAML والبرامج النصية لنشر البنية التحتية في بايثون والتطبيقات في جافا سكريبت من خلال القنوات المحددة في Groovy. تقترب شيفرة التطبيق نفسه من البنية التحتية. يمكن الآن لمطوري التطبيقات إنشاء «إجرائيات» (routines) في تطبيقاتهم لتوسيع نطاق ومعالجة حالات الفشل من خلال واجهات برمجة التطبيقات الخاصة بالبنية التحتية. وهذا هو السبب في أنني بدأت في استثمار فترة جيدة من وقتي في تعلم الشيفرة. قررت التركيز على تعلم لغات التطوير المشاركة في DevOps، واخترت خمسًا من أكثر اللغات أهمية وهي: Python و Ruby و Java Script و Go و C. أنا لست في هذه المرحلة مطورًا يعمل بدوام كامل بأي حال من الأحوال، كما أني لست متأكدًا حتى من أنه بإمكاني تسمية نفسي هاويا. لكني وصلت إلى ما هو أكثر من المعرفة الأساسية بفضل الموارد التي أقدمها في هذا المقال. بايثون Python أصبحت بايثون لغة متعددة الأغراض في البنية التحتية. وقد استُخدمت لبناء مشاريع البنية التحتية السحابية مثل OpenStack، وحتى لدعم تطبيقات الويب من خلال أطر عمل مثل Django. إن بايثون هي لغة سلسة لتلبية مجموعة واسعة من الاستخدامات. Codecademy: بدأت تعلم بايثون في موقع Codecademy. الذي يُقدِّم تمهيدًا رائعًا لبايثون. تدريب Safari Books عبر الإنترنت: انتقلتُ منه إلى المقدمة الممتازة لجيسيكا ماكلار في دورة Introduction to Python في مكتبة Safari Books Online. إن خدمة Safari مكلفة، ولكن غالبًا ما تكون هناك حسومات على مبيعات الأعضاء يمكن أن تمنحك خصمًا قد يصل إلى 50٪. تحتوي SafariBooks أيضًا على مقاطع فيديو لمؤتمرات O'Reilly، بما في ذلك المحادثات والمختبرات. حيث توفر المحادثات فرصة لإيجاد مواضيع هامّة في كل لغة. مقاطع الفيديو الخاصة بالمؤتمرات عبر الإنترنت: ابحث عبر الإنترنت وستجد محادثات مثيرة للاهتمام في مؤتمرات مطوّري برامج مختلفة حول كيفية استخدام اللغات بطرق ربما لم تفكر فيها من قبل. تتوفر على سبيل المثال على YouTube مقاطع فيديو مؤتمر PyCon. روبي Ruby تُستخدم روبي في عدد من مشاريع البنية التحتية. على سبيل المثال إن تطبيق ManageIQ، هو تطبيق Ruby on Rails. كثيرا ما كنت أمازح العملاء خلال وظيفتي في Red Hat، بأنه مع ManageIQ (و CloudForms)، يكون المستخدمون على بعد 10 سطور فقط من شيفرة Ruby للقيام بأي شيء. Codecademy: حصلت على معرفتي في روبي بشكل رئيسي من هذا الموقع، كما هو الحال مع بايثون. التوثيق الرسمي: إن المصدر الآخر الذي ساعدني على فهم روبي بشكل عملي أكثر (أي بالنسبة لوظيفتي) هو كتاب بيتر ماكووان Mastering CloudForms Automation (متوفر بتنسيق PDF مجاني). وساعد العمل مع state machines لـ CloudForms وأتمتة سير العمل المتقدمة في تشكيل فهمي للبنى داخل روبي. الحلقات الصوتية: استمعت أيضًا إلى Ruby on Rails Podcast، و Ruby Rogues. جافا سكريبت JavaScript تستمر منصة ومشاريع النظام البيئي لأطر جافا سكربت والمشاريع في النمو بوتيرة مذهلة. حيث تحتل حيزا ضخما من مساحة الاعمال على الإنترنت، سواء تلك المستخدمة من جانب العميل أو من أطر العمل المستخدمة من جانب الخادم. FreeCodeCamp: ما زلت أتعلم لغة جافا سكريبت، خاصة من خلال FreeCodeCamp. الذي يحتوي على برنامج مجاني ممتاز يوفر أمثلة في العالم الحقيقي ويدفع الطلاب إلى ما هو أبعد من تجربة كتابة الكلمات التقليدية. ستتلقى مع تقدمك في البرنامج، إرشادات أقل إلزاميةً وبدلاً من ذلك ستُكلف بمهام لإكمالها. كانت الدروس التي تعلمتها بشكل أكثر اكتمالا في رحلتي كانت من مبدأ "ابدأ من الجزء الأصعب". والذي لا أستطيع أن أوصي به بدرجة كافية. التوثيق الرسمي: إن التوثيق الرسمي هو مرجعي الأول لأي شيء غامض يواجهني أثناء رحلتي في تعلم جافاسكربت. الحلقات الصوتية: أستمع أيضًا إلى الملفات الصوتية التي تركز على جافا سكريبت، مثل JavaScript Jabber و FiveJS. Go طُرحت لغة Go في عام 2009، وحققت نجاحًا كبيرًا في السوق منذ طرحها. كان مصممو اللغة يركزون على عمل لغة مكتوبة ثابتة مقروءة، كما تقدم أيضًا أداءً جيدًا على نطاق واسع. golang.org: لقد بدأت مع Go، بدءًا من الجولة التعليمية الموجودة في golang.org. قناة Google Developers على YouTube: بدأت أيضًا بمشاهدة مقاطع الفيديو على قناة Google Developers channel، بما في ذلك Go for Pythonistas و Get Started with Go و Go Programming. تدريب Safari Books Online: ركزتُ بشكل أكبر على Go في عام 2017 لأنها تدعم عددًا من تقنيات الويب المهمة مثل Docker و Kubernetes وغيرها. يعد مسار التعلم في Safari Books Online مصدرًا رائعًا آخر، بما في ذلك Master Google's Go. السي C حاولت تعلم لغة C مرات عديدة. في كل مرة كنت أقترب فيها من C لم يكن لدي هدف معين في الحسبان. أردت فقط تعلم اللغة لأن الكثير من الشيفرات في العالم مكتوبة بلغة C، والعديد من« البنى» (constructs) في هذه اللغة يُعاد استخدامها في لغات أخرى. تعلمت سريعًا عند انضمامي إلى Red Hat، أن هناك مقولة موجودة في مجتمع «البرمجيات الحرة والمفتوحة المصدر» (FOSS) لفترة طويلة جدًا وهي: أفضل التوثيق هو الشيفرة نفسها. وأدركت أنني بحاجة إلى تعلم لغة C عند محاولتي فهم مشاريع مثل KVM و libvirt و QEMU، وذلك لفهم ما يحدث في المستوى التأسيسي. تعلم C بالطريقة الصعبة: لتعلم C تعلمت طريقة Learn C the Hard Way والتي أثبتت أنها طريقة مميَّزة للغة. أحب أسلوب كتابة المؤلف والنهج المعبر لتمارين كتابة الشيفرة. يمكنك قراءة الكتاب مجانًا عبر الإنترنت، أو شراء الكتاب للحصول على أمثلة التعليمات البرمجية وملفات الفيديوأيضًا. يُركز عملي الحالي على التحدث مع العملاء حول الحلول السحابية، لكنني استثمرت في مجتمع تكنولوجيا المعلومات لفترة طويلة وأشعر بأنني مضطر لتقديم رد. أحد الأشياء التي ركزت عليها في عام 2017 هو المساعدة في تثقيف موظفي تقنية المعلومات الحاليين حول الاتجاهات السائدة في سوق العمل، وكيفية المشاركة في عالم تكنولوجيا المعلومات الجديد الذي بدأ التركيز عليه. آمل أن تكون قادرًا على أخذ بعض الموارد المتوفرة في هذه المقالة وتحويل البند في سيرتك الذاتية الذي يقول "بناء الخوادم" إلى "بناء الشيفرة". ما هي لغات البرمجة التي تركز على تعلمها الآن؟ أخبرنا عن الموارد التي كانت أكثر فائدة لك في رحلتك البرمجية الخاصة. ترجمة وبتصرف للمقال: Top 5 programming languages for DevOps لصاحبه:Chris Saunders. اقرأ أيضًا المقال التالي: رحلة المطور عبر DevOps المقال السابق: ثلاث خطوات لتأمين DevOps مفتوح المصدر كامل مقالات السلسلة.

تُستخدَم كلمة DevOps (اختصارٌ للكلمتين Development و Operations) لوصف مجموعةٍ من أنشطة التكنولوجيا الحديثة التي تسعى إلى تقريب مطوري البرمجيات وموظفي العمليات من بعضهم بعضًا بشكلٍ أوثق بغية العمل بصورة أكثر تعاونية على نفس المشروع. الهدف من ذلك هو خلال كسر الحواجز التقليدية الموجودة بين هذين الفريقين التقنيين، مما يمكِّن المؤسسات من تقليل الوقت وزيادة الانخراط في تقديم ونشر إصدارات جديدة من البرمجيات. سيؤدي هذا الجهد بديهيًا إلى دورات تطوير أقصر مما قد يوفر الوقت والمال بشكل مثالي، ويمنح المؤسسة ميزة تنافسية تُنافِس بها المؤسسات الأخرى التي تعتمد دورات التطوير الطويلة والأكثر تقليديةً. لماذا ينبغي اتباع استراتيجية DevOps؟ لم تعد عملية الابتكار السريع موضوعًا اختياريًا. فبغض النظر عن مجال عمل مؤسستك، أصبح من شبه المؤكّد أنّه مجال يشهد تقلبات في الأنشطة التجارية التقليدية نتيجة الانتقال إلى الاقتصاد القائم على البرمجيات. فبدءًا من النقل إلى التصنيع، ومن التعدين إلى الزراعة، ومن التمويل إلى الرعاية الصحية، تجعل البيانات الضخمة، والحوسبة السحابية، والتطبيقات المحمولة، وعدد كبير من التقنيات الأخرى من البرمجيات هي ما يشكل الفارق الرئيسي بين الأعمال والمؤسسات التي تتقدم إلى الأمام وتلك التي تتراجع وتتخلف عن الركب. حتى وإن لم تكن مؤسستك تنافس في سوق البرمجيات قبل عقد من الزمن، فهي اليوم كذلك، والطريقة للمضي قدمًا هي في استخدام حلول أفضل للتقدم بشكل أسرع. كيف أبدأ؟ تتمثل الخطوات الأولى في مجال DevOps في فحص ثقافتك وممارساتك، وتحديد العوائق التي تحول دون التواصل والتنسيق بين الفريق، واتخاذ الخطوات اللازمة لتوطيد التواصل بين فِرق التطوير والعمليات لديك. إن تحقيق ذلك يمثل تحدّيًا لا يمكنك بلوغه بين عشية وضحاها. ابدأ بإلقاء نظرة على منهجياتك الحالية ثم قم بتنقيحها وتقويمها. على الرغم من أنّ DevOps يتمحور بشكل رئيسي حول الثقافة التنظيمية، فإنّ تحديد أدوات البرامج الصحيحة والمناسبة يعدّ خطوةً مهمةً أيضًا. فهل تستخدم مؤسستك أدوات للتحكم بالإصدار والمراجعة مثل Git لمساعدتك في إدارة الشيفرة البرمجية؟ هل تعتمد أدوات البناء و «التركيب المتواصل» (continuous integration) لجعل التحرك من المصدر وحتى الاختبار سلسًا قدر الإمكان؟ وماذا عن الأدوات المستخدمة لأتمتة الاختبار وتحزيم البرامج تلقائيًا، أو لاختبارات النشر والحماية؟ هل تبحث عن طرق لإدارة البنية الأساسيّة الخاصّة بك مثل الشيفرة البرمجية باستخدام «أدوات إدارة التكوين» (configuration management tools)، لتوسيع نطاق البيئات وتكرارها بسهولة؟ وماذا عن أدوات المراقبة لمتابعة كامل العملية بدءًا من التطوير وحتى الإنتاج؟ تستفيد DevOps من إيجاد الأدوات المناسبة للحفاظ على عمل فِرق التطوير والعمليات الخاصة بك معًا وتحركها بشكل أسرع إذا كنت بحاجةٍ إلى دليل لحماية تقنية «حاويات لينكس» (Linux container)، ألق نظرة على قائمة التحقق المرجعيّة هذه: 4 خطوات لبدء رحلتك مع الحاويات. دورة علوم الحاسوب دورة تدريبية متكاملة تضعك على بوابة الاحتراف في تعلم أساسيات البرمجة وعلوم الحاسوب اشترك الآن أين يمكنني تعلم المزيد؟ سننشر عددًا من المقالات تشرح ماهية DevOps وتُعرِّفك عليها؛ راجع الوسم «تعرف على DevOps» أو بعضًا من المقالات الأكثر شيوعًا أدناه. ما الهدف من DevOps؟: توضح نظرة موجزة لتاريخ DevOps الحاجة إلى التفكير بطريقة مختلفة حول العمل التعاوني في مجال تكنولوجيا المعلومات. 3 خطوات لحماية DevOps مفتوحة المصدر: المفتاح الرئيسي لتأمين تطوير التطبيق هو «الإزاحة نحو اليسار» (shift left) - انقل اختبار الأمان بعيدًا عن مرحلة الإنتاج المتأخرة وعُد إلى التصميم والتطوير. أفضل 5 لغات برمجة لـ DevOps: نجمع هنا خمسًا من أفضل لغات البرمجة لـ DevOps وبعضًا من الموارد التعليمية المفيدة لكل منها. رحلة المطور عبر DevOps: انتهت أيام التطوير المنعزلة لفرق التشغيل والعمليات. لماذا تعد DevOps الاستراتيجية التقنية الأكثر أهمية اليوم: إزالة بعض الالتباس حول مفهوم DevOps. تقنيات DevOps المحميّة «للخدمات المصغرة» (microservices): أحدثت الحاويات والخدمات المصغّرة ثورةً في تطوير التطبيقات وإدارة البنية التحتية. ربما يمكنك أيضًا إيجاد الفائدة في هذه الموارد الخارجية التي توفّر المزيد من المعلومات. التحديث بسرعة تطبيقات المصدر المفتوح باستخدام DevOps 9 عبارات مفتاحية لـ DevOps تحديث أسرع اعتمادا على DevOps كتاب إلكتروني مجاني: كتاب إلكتروني مجاني: DevOps with OpenShi. ترجمة وبتصرف للمقال: What is DevOps اقرأ أيضًا المقال التالي: ما الهدف من DevOps؟

إنّ المفتاح الرئيسي لتأمين تطوير تطبيق ما هو "الإزاحة نحو اليسار" - انقل اختبار الأمان بعيدًا عن مرحلة الإنتاج المتأخرة وعُد إلى التصميم والتطوير. حقيقةً، لم يعد أحد الآن يكتب شيفرته الخاصّة، أليس كذلك؟ نذهب إلى GitHub (أحد مواقع خدمات استضافة مستودعات المشاريع مفتوحة المصدر يوفر طرائق لتتبع القضايا التي تُنشِئها وتسمح للمستخدمين بإنشائها)، وننزل بعضًا من المكتبات، ونتجنب إعادة اختراع العجلات غير الضرورية، نجمع هذه العجلات بالشكل الذي يناسبنا لإنشاء برامج جديدة. ثم نُنزّل بعضًا من الأطر الأمامية لجعلها تبدو جميلةً وسريعة الاستجابة ونحن خارج السياق. وجدت خلال مراجعتي للتطبيقات، سواء تلك الموجودة في شركتي أو في شركات أخرى، أن أكثر من 90٪ من الشيفرة التي تشكل تطبيقًا هذه الأيام هي عبارة عن أشياء استعرناها، ولم نكتبها بأنفسنا. يفحص معظمنا شيفرته بحثًا عن العيوب مستخدمًا «أدوات التحليل الثابتة» (static analysis tools)، لكن ماذا عن كل المواضيع التي لم نكتبها بأنفسنا؟ كيف يمكننا معرفة ما في داخلها بالفعل؟ وبمجرد معرفتنا لذلك، ما هي الإجراءات التي نتخذها إما لتنظيفها أو لإبقائها محدّثة؟ كيف يمكننا تجنب التعرض للاختراق لأننا ندع شيئا مفتوحًا يعمل في الخلفية باستخدامنا لتلك المكتبة القوية المزدحمة التي تفعل ذاك الشيء الجميل الذي لا يمكننا الاستغناء عنه؟ الطريقة القديمة أُبرمج منذ 20 عامًا تقريبًا، وهي فترة طويلة وكافية لرؤية التطور بدءًا من النماذج التقليدية لتخطيط البرامج كالنماذج الشلالية أو الحلزونية إلى نماذج «البرمجة الفائقة» (Xtreme Programing)، والنماذج المرنة Agile و تطوير العمليات DevOps الآن. في الماضي كانت دورات التطوير الطويلة والافتقار إلى أي تدريب حقيقي وعدم جدوى الأدوات في تحديد العيوب الأمنية حيث تجري تقييمات الأمان بشكل أساسي في المراحل اللاحقة من دورة حياة تطوير البرمجيات وأكثرها يتم على شكل أنشطة يدوية. وعادةً ما يكون الدافع وراء بدء المراجعة يتعلق بتدقيق أو بعميل يطلب تأكيد بياناته في أنظمتك (والتي قليلًا ما تحدث). بالنظر إلى هذا النهج قليل التكرار والمتعلق بالتقييم الأمني، فإنّه غالبًا ما تُخفّض أولوية العيوب القائمة على الأمان والاختبارات للعثور عليها. ركّزت مجموعات أمن المعلومات على "النتائج"، وعلى تشغيل أدوات لإنتاج التقارير عند الطلب لطمئنة المدققين بأن الأمور تجري على ما يرام. أعطيت الميزات والفاعلية الوظيفية الأولوية على حل الخلل الذي لن يراه المستخدمون العاديون أبدًا، ولن يُطلعهم أحد عليه، أليس كذلك؟ أضف إلى هذا السيناريو حقيقة أنه حتى مع إضافة عمال تقنيين جُدد إلى السوق يوميًا، فإن القليل منهم مُدّرب على أنشطة كتابة الشيفرة الدفاعية، ويمكنك أن ترى كيف يمكن أن ينتهي بنا الأمر إلى حدوث مشكلة. إن الخبر الجيد هنا هو أنه الآن يوجد استراتيجيات حقيقية لإيضاح المشكلة وطرق حلها. الطريقة الجديدة عالم اليوم هو عالم الأتمتة و«التكرار المتواصل» (continuous iteration). نسمي هذه العملية بـ "DevOps" لأنها تمزج تطوير البرمجيات وتعريف وأتمتة البنية التحتية لإنشاء نماذج للنشر والعمليات التي تُمكّن ذاتيًا. عندما نضيف أمانًا إلى ذلك، فإننا نطبق نفس التوقعات بأن نؤتمت كل شيء تلقائيًا ونعرّف «الأنماط» (patterns) والعمليات بحيث يمكن تكرارها باستمرار. وبهذا يكون انتهى بنا الأمر إلى ما أحب أن أسميه "DevSecOps". (DevSecOps هي اختصار لمصطلح التطوير والأمن والعمليات. هدفها هو جعل كل شخص مسؤولاً عن الأمان بهدف تنفيذ القرارات والإجراءات الأمنية بنفس المستوى والسرعة كما في قرارات وإجراءات التطوير والعمليات.) إن المفتاح الرئيسي في هذا النهج الجديد هو "الإزاحة نحو اليسار"، ونقل اختبار الأمان وجهود تركيب المصدر المفتوح بعيدًا عن مرحلة الإنتاج المتأخرة والعودة نحو التصميم والتطوير. كما هو الحال في DevOps، التي تُمكّن المطورين من تعريف« بُنى» (architecture) معتمدة على البرمجيات وإصدارها ونشرها باستخدام الأتمتة، تمنح DevSecOps المطورين نفس الأدوات والتقنيات والعمليات للقيام بالشيء نفسه من أجل أمان البرنامج. الخطوة 1: البدء في التصميم إنّ الطريقة الأكبر التي تخرج بها التطبيقات مفتوحة المصدر عن مسارها بسرعة، تتمثل في عدم التفكير في بنيّة التطبيق قبل البدء بكتابة الشيفرة. هل ما زلت تستخدم نسخة "Struts" عمرها سنتين لتطبيقك الجديد فقط لمجرد أنّها مثبّتة على جهازك المحلي مسبقًا، متبقيةً من مشاريعك العشرة السابقة التي أنجزتها؟ تأكّد في كل مرّة تبدأ فيها مشروعًا جديدًا بأنّك تستخدم الإصدار الأحدث والأكثر موثوقية من إطار العمل الذي تعتمده. استخدم أدوات مجانيّة أو أدوات غير مكلفة مثل SourceClear لتحديد «فاتورة المواد» (Bill Of Materials- BOM) في تطبيقك وكن متأكدًا من أنها تفي بالمطلوب قبل بدء العمل. سيوفر عليك لك المتاعب لاحقًا. الخطوة 2: أتمتة كل شيء بالنسبة لي كمطور، إنه من أكثر الأمور إزعاجًا قدوم شخص ما إلى عندما أكون مشغولًا بشيء آخر يتوجب على إنجازه في يومي المثقل بالأعمال. فإذا كنت تتوقع من المطورين استخدام أداة أو البحث في موقع ويب أو طلب إذن من شخص ما في كل مرّة يقومون فيها بالنشر، فسيجدون حتمًا طريقةً لتجنب ذلك. من ناحية أخرى، إذا كنت تستطيع أتمتة عملية تشغيل شيء ما، أو التحقق من قائمة معينة، أو إخطار مجموعة ما، عندها سيواصل المطورين التركيز على ما يجلب للشركة أموالًا أو ما يضيف قيمةً للعميل. يود InfoSec أن يقول: "الأمان هو مهمة الجميع" ولكن غالبًا ما ينسى أن القيمة المضافة تأتي في المرتبة الأولى. إذا لم نتمكن من إضافة قيمة لعملائنا أو المساهمين معنا، فلن يكون هناك أي شيء لحمايته وتأمينه. (InfoSec هي مجموعة من العمليات التي تحافظ على سرية وسلامة وتوافر بيانات الأعمال بأشكالها المختلفة.) تتمثل الفكرة الرئيسية هنا بالقيام بذلك خارج النطاق وجعله شفافًا. يجب أن يكون غير متزامن وغير مرئي أو سيصبح نقطة عناء وإجهاد لشخص ما. الخطوة 3: تطوير "مواطنين جيدين" وليس "بنى جيدة" أخيرًا، لكي يتحقق DevSecOps بالفعل، علينا العمل على تغيير طريقة التفكير حول سياسة أمن المعلومات InfoSec وعمليات النشر المتعلقة بذلك. كانت تبدو معظم نماذج النشر التي تتضمن الأمان في الماضي كالتالي: تصميم -> كتابة شيفرة -> اختبار التكامل -> ضمان الجودة QA -> مراجعة InfoSec -> الإنتاج. ( QA: هي اختصار للكلمتين Quality Assurance) ولكن عندما تكون دورات DevOps مُحتملة خلال ساعات أو حتى دقائق، فكيف يمكنك مراجعة InfoSec قبل مرحلة الإنتاج؟ الجواب: ليس أنت من يفعل ذلك. واسمحوا لي أن أصيغ السؤال على هذا النحو: إذا كان المطورون يحصلون على معلومات جيدة في وقت مبكر لأنك عملت على أتمتة تحليل الشفرة الثابتة، ووفرتَ طريقة تلقائية لإنشاء فاتورة المواد BOM لأطر عمل المصادر المفتوحة لديك، وقدّمت ذلك مبكرًا في دورة حياة تطوير البرمجيات منذ مرحلة التطوير أو حتى التصميم، فما الذي تختبره بالضبط في هذه البنية؟ أنت ببساطة تسأل عما إذا كانوا قد اتخذوا الإجراءات التي يعرفونها أصلًا. اسأل نفسك الآن السؤال التالي، "هل تثق بهم؟" لاحظ، إذا كنت تقدم المعلومات في وقت مبكر بما فيه الكفاية، فبإمكانك إزالة "مراجعة InfoSec" بالفعل عندما يحين وقت النشر. ماذا؟ وهذا صحيح. يمكن ببساطة في هذه المرحلة أن تسأل عملية التحكم في التغيير الخاصة بك الأسئلة التالية: "هل أُكمِلت مراجعات الأمان التلقائية لهذا التطبيق في كل مرحلة من المراحل؟" "هل حلّ المطورون العيوب الحرجة كما هو متوقع على أسس ثابتة؟" "هل كان آخر تقييم مكتمل يصل إلى مستوى توقعاتنا (سياستنا)؟" إذا كان بإمكانك الإجابة بنعم على هذه الأسئلة، فإن ما عليك فعله هو الوثوق في أن فريق التطوير يعمل بشكل نموذجي (مواطنين جيدين)، والحرص على إنتاج نوعية جيدة، والتصرف بطريقة مسؤولة. سيبدو نموذجنا الجديد مشابها لهذا: تصميم مستنير -> مراجعة الشيفرة الآلية -> ضمان الجودة -> IT -> مواطن جيد؟ -> النشر. ترجمة وبتصرف للمقال: 3 steps to secure, open source DevOps لصاحبه: Jet Anderson. اقرأ أيضًا المقال التالي: أفضل 5 لغات برمجة لـ DevOps المقال السابق: ما هي الغاية من DevOps؟ كامل مقالات السلسلة.

يساعدك التغيير الحقيقي في الثقافة التنظيمية على ردم الفجوات التي اعتقدت أنه ليس بالإمكان تجاوزها. فكّر في آخر مرّة حاولت فيها تغيير عادةٍ شخصية. من المحتمل أن تصل إلى نقطة تحتاج فيها إلى تغيير طريقة تفكيرك وجعل هذه العادة أقل جزء من هويتك. هذا صعب — مع أنك تحاول فقط تغيير طرق تفكيرك الخاصة. لذلك، ربما حاولت وضع نفسك في مواقف جديدة. حيث يمكن أن تساعدنا المواقف الجديدة فعليًا في خلق عادات جديدة، والتي بدورها تؤدي إلى طرق جديدة للتفكير. هذا ما يتعلق بالتغيير الناجح: إنه يتعلق بالتوقعات بقدر ما يتعلق بالنتائج. عليك أن تعرف سبب تغييرك وأين تتجه (وليس فقط كيف ستفعل ذلك)، لأن التغيير فقط من أجل التغيير غالبًا ما يكون محدود الأجل وقصير النظر. فكّر الآن في التغييرات التي تحتاجها مؤسسة تعمل في مجال تكنولوجيا المعلومات. ربما فكّرتَ في اعتماد شيء مثل DevOps. يحتوي هذا الشيء الذي نسميه "DevOps" على ثلاثة مكونات: الأشخاص والعملية والأدوات. يمثل الناس والعملية الأساس لأي منظمة. لذلك، يتطلب اعتماد DevOps إجراء تغييرات أساسية في جوهر معظم المنظمات، وليس فقط تعلم أدوات جديدة. ويمكن أن يكون التغيير قصير النظر، كما هو الحال في أي تغيير، إذا كنت تركز على التغيير كحل لنقطة محددة على سبيل المثال - "الحصول على أداة أفضل لعمل تنبيه"، - فمن المحتمل أن تتوصل إلى رؤية محدودة للمشكلة. قد توفر طريقة التفكير هذه أداة تحتوي على مزيد من الأجراس والصفارات وطريقة أفضل للتعامل مع الإدارة عند الطلب. لكن لا يمكنها معالجة حقيقة أن التنبيهات لا تصل إلى الفريق المطلوب، أو أن تلك الإخفاقات لا تزال موجودةً لأن أحدًا لا يعرف كيفية إصلاح الخدمة. تخلق الأداة الجديدة (أو على الأقل فكرة الأداة الجديدة) فرصة لإجراء مناقشة حول المشاكل الأساسية التي شوهت نظرة فريقك في المراقبة. حيث تتيح لك الأداة الجديدة إجراء تغييرات أكبر - تغييرات على معتقداتك وممارساتك - والتي تُعدُّ أكثر أهمية كأساس لمؤسستك. يتطلب إحداث تغيير أعمق أساليب جديدة لمفهوم التغيير المُشترَك. ونحتاج أولًا إلى فهم محرك التغيير بشكل أفضل لاكتشاف هذه الأساليب. إزالة الحواجز لفهم الحاجة إلى DevOps، التي تحاول إعادة تجميع كيانات "الانقسام" التقليدية "للتطوير" و "العمليات"، يجب علينا أولاً أن نفهم كيف حدث الانقسام. بمجرد "معرفة استخدامه"، يمكننا أن نرى الانقسام على حقيقته- ونزيله إذا لزم الأمر. يوجد اليوم أكثر من نظرية للإدارة، ولكن يمكننا تتبع أصول معظم نظريات الإدارة الحديثة لفريدريك وينسلو تايلور. كان تايلور مهندسًا ميكانيكيًا أنشأ نظامًا لقياس كفاءة العمال في مصنع للفولاذ. اعتقد تايلور أنه بالإمكان تطبيق التحليل العلمي على العمال في المصنع، ليس فقط لتحسين المهام الفردية، ولكن أيضًا لإثبات أن هناك طريقة أفضل يمكن اكتشافها لأداء أي مهمة. يمكننا بسهولة رسم شجرة تاريخية اعتمادًا على وضع تايلور في الجذر. ظهرت من جهود تايلور المبكرة في أواخر الثمانينات من القرن الماضي برامج دراسة الحركة الزمنية وغيرها من برامج تحسين الجودة التي امتدت في عشرينيات القرن العشرين حتى يومنا هذا، حيث نرى منهجيات معايير سيجما الستة (Six Sigma) والتصنيع الرشيق (Lean) وما شابه. وتُهيمن على ثقافة الأعمال السائدة اليوم منهجيات: من من الأعلى إلى الأسفل (Top-down)، والإدارة موجَّهة النمط (directive-style management)، والمقترنة بالنهج النظامية لدراسة العملية. إنها تركز في المقام الأول على الفاعلية كمقياس رئيسي لنجاح العمال. إذا كان تايلور هو الأصل لشجرتنا التاريخية، فإن فرعنا الرئيسي التالي في الصندوق سيكون الفريد سلون (Alfred P. Sloan) من جنرال موتورز في العشرينات من القرن الفائت. إن هيكلية Sloan التي أُنشئت في جنرال موتورز، لن تظل قويةً فقط حتى عام الـ 2000، بل أنها أيضًا ستكون النموذج الرئيسي للشركة على مدار الخمسين عامًا القادمة. كانت جنرال موتورز في عام 1920 تعاني من أزمة في الإدارة -أو بالأحرى أزمة بسبب نقص الإدارة. كتب سلون كتابه «"الدراسة التأسيسية"» (Organizational Study) لمجلس الإدارة، مقترحًا هيكلًا جديدًا لعدد وافر من أقسام جينرال موتورز. يركّز هذا الهيكل الجديد على مفهوم "العمليات اللامركزية مع التحكم المركزي". ستعمل الآن الأقسام الفردية، المرتبطة بعلامات تجارية مثل شيفروليه وكاديلاك وبويك بشكل مستقل في حين توفر الإدارة المركزية الوسائل اللازمة لتوجيه الاستراتيجية والتحكم المالي. صعدت جنرال موتورز نتيجة توصيات سلون (وتوجيهات لاحقة كمدير تنفيذي) إلى مركز رائد في صناعة السيارات الأمريكية. حيث خلقت خطة سلون شركة ناجحة للغاية من واحدة على شفا كارثة. من وجهة النظر المركزية، فالوحدات المستقلة عبارة عن صناديق سوداء. يتم تعيين الحوافز والأهداف في المستويات العليا، والفرق في المستوى الأسفل من أجل التنفيذ. لا تزال فكرة تايلور حول "أفضل الممارسات" - السلوكيات القياسية التبادلية والتكرارية - تحتل مكانًا في مُثُل الإدارة الحالية، حيث تقترن بالنموذج الهرمي للهيكل المؤسسي لسلون، الذي يدعو إلى انقسامات صلبة للإدارة وصوامع من أجل السيطرة القصوى. يمكننا الإشارة إلى العديد من الدراسات الإدارية التي تثبت ذلك. لكن ثقافة الأعمال لا تُنشَأ وتُنشَر فقط من خلال قراءة الكتب. الثقافة التنظيمية هي نتاج أناس حقيقيين في مواقف فعلية يقومون بسلوكيات ملموسة تدفع المعايير الثقافية عبر الزمن. هذه هي الطريقة التي تتعزز بها أشياء مثل نظريات Taylorism و Sloanianism وتصبح ثابتة. إن تمويل قطاع التكنولوجيا هو مثال على ذلك. إليك طريقة عمل الحلقة: يستثمر المستثمرون فقط في الشركات التي يعتقدون أنها يمكن أن تحقق رؤيتهم الخاصة للنجاح. لا ينشأ هذا النموذج للنجاح بالضرورة من الشركة نفسها (وأهدافها الخاصة)، إنه يأتي من أفكار مجلس الإدارة حول الصيغة التي يجب أن تبدو عليها الشركة الناجحة. يأتي العديد من المستثمرين من الشركات التي نجت من اختبارات ومتاعب إدارة الأعمال، ونتيجة لذلك لديهم مخططات مختلفة لما يمكنه جعل الشركة ناجحة. إنهم يمولون الشركات التي يمكن تعليمها لتقليد نماذجهم للنجاح. لذا فإن الشركات التي ترغب في الحصول على تمويل تتعلم محاكاتهم. وبهذه الطريقة، فإن حاضنة بدء التشغيل هي وسيلة مباشرة لاستنساخ بنية وثقافة يفترض أنهما مثاليتان. انقسام "Dev" و "Ops" ليس نتيجة الشخصية أو المهارات المتباينة أو القبعة السحرية الموضوعة على رؤوس الموظفين الجدد، إنها نتيجة ثانوية للنظريات للتيلورية والسلانية. وإن الحدود الواضحة والفاصلة بين المسؤوليات والأشخاص هي وظيفة إدارية مقرونة بالتركيز على كفاءة العمال. كان بالإمكان تقسيم الإدارة بسهولة إلى حدود المنتج أو المشروع بدلاً من المهارات، ولكن يخبرنا تاريخ نظرية إدارة الأعمال حتى اليوم أن التجميع القائم على المهارات هو الطريقة "الأفضل" لتحقيق الكفاءة. لسوء الحظ، تخلق تلك الحدود توترات، وهذه التوترات هي نتيجة مباشرة للأهداف المتعارضة التي حددتها حلقات إدارة مختلفة ذات أهداف مختلفة. فمثلًا: الرشاقة ⟷ الاستقرار استقطاب مستخدمين جدد ⟷ خبرة المستخدمين الحاليين الحصول على ميزات التطبيق ⟷ تطبيق متاح للاستخدام النجاح في المنافسة ⟷ حماية الإيرادات إصلاح المشكلات التي تظهر ⟷ منع المشكلات قبل حدوثها يمكننا أن نرى اليوم اعترافًا متزايدًا بين كبار قادة المنظمات بأن ثقافة الأعمال الحالية (وبالتالي مجموعة التوترات التي تنتجها) تمثل مشكلة خطيرة. في تقرير Gartner لعام 2016، قال 57 بالمائة من المشاركين أن التغيير الثقافي كان أحد التحديات الرئيسية التي ستواجه الشركة حتى عام 2020. إن ظهور أساليب جديدة مثل المنهجية المرنة و DevOps كوسيلة للتأثير على التغييرات التنظيمية يعكس هذا الاعتراف. الارتفاع في «"تكنولوجيا معلومات الظل"» (shadow IT) هو الوجه الآخر للعملة. حيث تربط التقديرات الحديثة ما يقرب من 30 في المئة من إنفاق تكنولوجيا المعلومات خارج سيطرة منظمة تكنولوجيا المعلومات. هذه ليست سوى بعضًا من "الاهتمامات الثقافية" التي تواجهها الشركات. فالحاجة إلى التغيير واضحة، لكن الطريق إلى الأمام لا يزال محكومًا بقرارات الماضي. المقاومة ليست عديمة الجدوى عادةً ما يكون التغيير استجابة تنظيمية لخطأ ما. وبهذا المعنى، إذا كان التوتر (حتى الشدائد) هو المحفز الطبيعي للتغيير، فإن مقاومة التغيير هي مؤشر للنجاح. لكن التركيز المفرط على المسارات الناجحة يمكن أن يجعل المنظمات غير مرنة، وبليدة، وجامدة. إن تقييم سياسة التوجيه من خلال النتائج الفعّالة هو أحد أعراض هذه الصلابة المتزايدة. أدى النجاح في أقسام تقنية المعلومات التقليدية إلى زيادة سماكة جدران تقنية المعلومات. الأقسام الأخرى هي الآن "عملاء"، وليست زملاء عمل. تنشئ محاولات إزاحة تكنولوجيا المعلومات بعيدًا عن كونها مركزًا للتكلفة نموذجَ تشغيلٍ جديد يفصل تكنولوجيا المعلومات عن باقي أهداف العمل. وهذا بدوره يخلق المقاومة التي تحدّ من خفة الحركة أو الرشاقة، ويزيد من الاحتكاك، ويقلل من الاستجابة. التعاون يحصل على الرف لصالح "توجيه الخبراء". والنتيجة هي أن النظرة الانعزالية لتكنولوجيا المعلومات لا يمكن إلا أن تضر أكثر مما تنفع. وبما أن "البرمجيات تجتاح العالم"، يصبح تكنولوجيا المعلومات أكثر وأكثر أهمية للنجاح العام للمنظمة. تدرك مؤسسات تكنولوجيا المعلومات ذات التفكير المتقدم هذا وتقوم بالفعل بإجراء تغييرات متعمدة على قواعد العمل، بدلاً من التعامل مع التغيير على أنه شيء تخافه. على سبيل المثال، تشاور موقع Facebook مع عالم الأنثروبولوجيا «روبن دنبار» (Robin Dunbar) حول أسلوب تعامله المجموعات الاجتماعية، ولكنه أدرك مع نمو الشركة تأثير ذلك على المجموعات الداخلية (وليس فقط المستخدمين الخارجيين للموقع). نالت ثقافة زابوس الكثير من الثناء لدرجة أن المنظمة أنشأت قسمًا يركّز على تدريب الآخرين على وجهات نظرهم حول القيم الأساسية وثقافة الشركات. وبالطبع يعد هذا الكتاب مرافقًا لـكتاب The Open Organization، وهو كتاب يوضح كيف يمكن للمبادئ المفتوحة المطبقة على الإدارة - كالشفافية والمشاركة والمجتمع - إعادة إنشاء المنظمة بما يناسب عصرنا المترابط سريع الخطى. حل للتغيير أخبرني أحد الزملاء ذات مرّة أنّه بإمكانه شرح DevOps لمدير المشروع باستخدام مفردات إطار عمل مكتبة البنية التحتية لتكنولوجيا المعلومات فقط. في حين أن هذه الأطر تبدو متعارضة، فإنها في الواقع تركز على إدارة التغيير والمخاطر. أنها ببساطة تقدّم عمليات وأدوات مختلفة لمثل هذا النوع من الإدارة. من المهم ملاحظة هذه النقطة عند التحدث عن DevOps خارج إطار تقنية المعلومات. فبدلاً من التركيز على أعطال العملية وإخفاقاتها، أظهر كيف أن التغييرات الأصغر تقدّم مخاطر أقل وما شابه ذلك. وهذه طريقة قوية لتسليط الضوء على الفوائد التي تغير ثقافة الفريق: إن التركيز على القدرات الجديدة بدلاً من المشاكل القديمة هو عامل فعال للتغيير، خاصة عند تتبنى إطار مرجعي لشخص آخر. لا يتعلق التغيير فقط بإعادة بناء المنظمة؛ إنه يتعلق أيضًا بطرق جديدة لردم الفجوات التي لا يمكن تجاوزها تاريخيًا - حل لتلك التوترات التي حدّدتها سابقًا برفض وضع أشياء مثل "الرشاقة" و "الاستقرار" كقوى متبادلة. إن إنشاء فرق متداخلة تركز على النتائج أكثر من الوظائف يمثل أحد الاستراتيجيات في العمل. ويعد الجمع بين فرق مختلفة يعتمد كل منها على الآخر حول مشروع أو هدف واحد من أكثر الطرق شيوعًا. تسفر إزالة الاحتكاك بين هذه الفرق وتحسين الاتصالات عن تحسينات هائلة - حتى أثناء التمسك بهياكل الإدارة في صومعة الحديد (لا يلزم هدم الصوامع إذا أمكن إتقانها). حيث لا تعد مقاومة التغيير في هذه الحالات مؤشرًا على النجاح. احتضان التغيير هو المؤشر. إن هذه ليست "أفضل الممارسات". هي ببساطة طريقة لفحص الحدود الخاصة بك. كل منظمة لديها حدود فريدة من نوعها أنشأها الأشخاص داخلها. وبمجرد "معرفة استخدامها"، يمكنك أن تقرّر ما إذا كانت تحتاج إلى إزالة أو إلى تخصيص. ترجمة وبتصرف للمقال: What's the point of DevOps لصاحبه: Matt Micene. اقرأ أيضًا المقال التالي: ثلاث خطوات لتأمين DevOps مفتوح المصدر المقال السابق: ما المقصود بـ DevOps؟ كامل مقالات السلسلة.