المحتوى عن 'تعرف على devops'.



مزيد من الخيارات

  • ابحث بالكلمات المفتاحية

    أضف وسومًا وافصل بينها بفواصل ","
  • ابحث باسم الكاتب

نوع المُحتوى


التصنيفات

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

التصنيفات

  • PHP
    • Laravel
    • ووردبريس
  • جافاسكريبت
    • Node.js
    • jQuery
    • AngularJS
    • Cordova
  • HTML
    • HTML5
  • CSS
  • SQL
  • سي شارب #C
    • منصة Xamarin
  • بايثون
    • Flask
    • Django
  • لغة روبي
    • Sass
    • إطار عمل Bootstrap
    • إطار العمل Ruby on Rails
  • لغة Go
  • لغة جافا
  • لغة Kotlin
  • برمجة أندرويد
  • لغة Swift
  • لغة R
  • لغة TypeScript
  • سير العمل
    • Git
  • صناعة الألعاب
    • Unity3D
  • مقالات برمجة عامة

التصنيفات

  • تجربة المستخدم
  • الرسوميات
    • إنكسكيب
    • أدوبي إليستريتور
    • كوريل درو
  • التصميم الجرافيكي
    • أدوبي فوتوشوب
    • أدوبي إن ديزاين
    • جيمب
  • التصميم ثلاثي الأبعاد
    • 3Ds Max
    • Blender
  • مقالات تصميم عامة

التصنيفات

  • خواديم
    • الويب HTTP
    • قواعد البيانات
    • البريد الإلكتروني
    • DNS
    • Samba
  • الحوسبة السّحابية
    • Docker
  • إدارة الإعدادات والنّشر
    • Chef
    • Puppet
    • Ansible
  • لينكس
  • FreeBSD
  • حماية
    • الجدران النارية
    • VPN
    • SSH
  • مقالات DevOps عامة

التصنيفات

  • التسويق بالأداء
    • أدوات تحليل الزوار
  • تهيئة محركات البحث SEO
  • الشبكات الاجتماعية
  • التسويق بالبريد الالكتروني
  • التسويق الضمني
  • التسويق بالرسائل النصية القصيرة
  • استسراع النمو
  • المبيعات
  • تجارب ونصائح

التصنيفات

  • إدارة مالية
  • الإنتاجية
  • تجارب
  • مشاريع جانبية
  • التعامل مع العملاء
  • الحفاظ على الصحة
  • التسويق الذاتي
  • مقالات عمل حر عامة

التصنيفات

  • الإنتاجية وسير العمل
    • مايكروسوفت أوفيس
    • ليبر أوفيس
    • جوجل درايف
    • شيربوينت
    • Evernote
    • Trello
  • تطبيقات الويب
    • ووردبريس
    • ماجنتو
  • أندرويد
  • iOS
  • macOS
  • ويندوز

التصنيفات

  • شهادات سيسكو
    • CCNA
  • شهادات مايكروسوفت
  • شهادات Amazon Web Services
  • شهادات ريدهات
    • RHCSA
  • شهادات CompTIA
  • مقالات عامة

أسئلة وأجوبة

  • الأقسام
    • أسئلة ريادة الأعمال
    • أسئلة العمل الحر
    • أسئلة التسويق والمبيعات
    • أسئلة البرمجة
    • أسئلة التصميم
    • أسئلة DevOps
    • أسئلة البرامج والتطبيقات
    • أسئلة الشهادات المتخصصة

التصنيفات

  • ريادة الأعمال
  • العمل الحر
  • التسويق والمبيعات
  • البرمجة
  • التصميم
  • DevOps

تمّ العثور على 6 نتائج

  1. إزالة بعض الالتباس حول مفهوم 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 كامل مقالات السلسلة.
  2. انتهت أيام فرق التطوير وفرق العمليات المنعزلة. ما علاقة المطوًر «بور سوتر» (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 كامل مقالات السلسلة.
  3. تُستخدَم كلمة 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؟
  4. نجمع هنا خمسًا من أفضل لغات البرمجة لـ 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 مفتوح المصدر كامل مقالات السلسلة.
  5. إنّ المفتاح الرئيسي لتأمين تطوير تطبيق ما هو "الإزاحة نحو اليسار" - انقل اختبار الأمان بعيدًا عن مرحلة الإنتاج المتأخرة وعُد إلى التصميم والتطوير. حقيقةً، لم يعد أحد الآن يكتب شيفرته الخاصّة، أليس كذلك؟ نذهب إلى 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؟ كامل مقالات السلسلة.
  6. يساعدك التغيير الحقيقي في الثقافة التنظيمية على ردم الفجوات التي اعتقدت أنه ليس بالإمكان تجاوزها. فكّر في آخر مرّة حاولت فيها تغيير عادةٍ شخصية. من المحتمل أن تصل إلى نقطة تحتاج فيها إلى تغيير طريقة تفكيرك وجعل هذه العادة أقل جزء من هويتك. هذا صعب — مع أنك تحاول فقط تغيير طرق تفكيرك الخاصة. لذلك، ربما حاولت وضع نفسك في مواقف جديدة. حيث يمكن أن تساعدنا المواقف الجديدة فعليًا في خلق عادات جديدة، والتي بدورها تؤدي إلى طرق جديدة للتفكير. هذا ما يتعلق بالتغيير الناجح: إنه يتعلق بالتوقعات بقدر ما يتعلق بالنتائج. عليك أن تعرف سبب تغييرك وأين تتجه (وليس فقط كيف ستفعل ذلك)، لأن التغيير فقط من أجل التغيير غالبًا ما يكون محدود الأجل وقصير النظر. فكّر الآن في التغييرات التي تحتاجها مؤسسة تعمل في مجال تكنولوجيا المعلومات. ربما فكّرتَ في اعتماد شيء مثل 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؟ كامل مقالات السلسلة.