ما هو الجحيم DevOps؟

نبذة عن تاريخ الوقت

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

كما يعلمنا تاو:

كان المبرمجون القدامى غامضين وعميقين. لا يمكننا أن نفهم أفكارهم ، فكل ما نفعله هو وصف مظهرهم:

• مدرك مثل الثعلب يعبر الماء
• تنبيه ، مثل الجنرال في ساحة المعركة
• نوع مثل مضيفة تحيي ضيوفها
• بسيطة ، مثل كتل الخشب غير المنحوتة
• معتم ، مثل حمامات السباحة السوداء في الكهوف المظلمة

ولدت المبرمج لغة الآلة. ولدت لغة الآلة المُجمّع. أنجب المجمع المترجم. الآن هناك آلاف اللغات. كل لغة لها غرضها ، مهما كانت متواضعة. كل لغة تعبر عن يين ويانغ للبرمجيات. كل لغة لها مكانها داخل البرنامج.

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

ثم بدأت الطبيعة البشرية ، وبدأنا نطلب المزيد. المزيد من السرعة ، المزيد من الميزات ، المزيد من المستخدمين ، المزيد من كل شيء.

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

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

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

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

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

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

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

أصبحت مشاريع البرمجيات عرضة للفشل لدرجة أنه تم قبولها كمعيار صناعي. أظهرت الإحصائيات أن أكثر من 50٪ من المشاريع كانت فاشلة ، ويبدو أنه لم يكن هناك شيء يمكن القيام به حيال ذلك (ZDNet ، CNet)

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

يستند بيان Agile إلى اثني عشر مبدأ:

1. إرضاء العملاء من خلال التسليم المبكر والمستمر للبرامج القيمة
2. نرحب بالمتطلبات المتغيرة ، حتى في وقت متأخر من التطوير
3. يتم تسليم برنامج العمل بشكل متكرر (أسابيع بدلاً من شهور)
4. تعاون يومي وثيق بين رجال الأعمال والمطورين
5. تم بناء المشاريع حول الأفراد المتحمسين ، الذين يجب الوثوق بهم
6. المحادثة وجهًا لوجه هي أفضل شكل من أشكال الاتصال (المشاركة في الموقع)
7. برنامج العمل هو المقياس الرئيسي للتقدم
8. تنمية مستدامة قادرة على الحفاظ على وتيرة ثابتة
9. الاهتمام المستمر بالتميز التقني والتصميم الجيد
10. البساطة - فن تعظيم حجم العمل غير المنجز - أمر ضروري
11. فرق التنظيم الذاتي
12. التكيف المنتظم مع الظروف المتغيرة

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

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

مدمن مخدرات على LSD (يقصد التورية) والمخاطرة بالنفي والنفي ، بحث بعض الأحفاد عن حلول خارج طبقتهم وصناعة البرمجيات. وجدوا الخلاص في أعمال شركة كبرى لتصنيع السيارات. كان نظام إنتاج Toyota مدهشًا في بساطته وكان من الواضح جدًا أنه يمكن تطبيق التصنيع الهزيل بسهولة في تطوير البرامج.

هناك 7 مبادئ لتطبيق Lean:

1. القضاء على النفايات
2. بناء الجودة في
3. خلق المعرفة (تضخيم التعلم)
4. تأجيل الالتزام (قرر في أقرب وقت ممكن)
5. تسليم في أسرع وقت ممكن
6. احترام الناس (تمكين الفريق)
7. تحسين الكل

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

بمجرد اعتماد فرق تطوير البرامج Agile و Lean ، لم يستغرق الأمر سوى خطوة واحدة أخرى لتطبيق مجموعة المبادئ الكاملة على تقنية المعلومات ككل - الأمر الذي أوصلنا أخيرًا إلى DevOps!

ادخل إلى DevOps - طريق سريع مكون من ثلاثة حارات

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

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

أفضل تفسير لحلول DevOps يقدمه Gene Kim ، وإذا لم تكن قد قرأت The Phoenix Project فأقترح أن تأخذ بعض الوقت وتفعله.

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

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

• المسار الأول - يعد أداء النظام ككل نقطة محورية رئيسية ويتم التأكيد عليه على أداء أي عنصر فردي في النظام

• المسار الثاني - تأكد من إرسال حلقة تغذية مرتدة ثابتة في اتجاه التيار وعدم تجاهلها

• المسار الثالث - رعاية التجارب والتحسين المستمر والفشل السريع

المسار الأول - الاستعداد للسرعة

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

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

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

لا تهتم مبادئ DevOps بالفريق الذي تنتمي إليه ، إذا كنت مهندس نظام أو DBA أو QA أو مسؤول شبكة. تنطبق نفس القواعد على الجميع ، ويتوقع من الجميع اتباع مبدأين بسيطين:

• حافظ على تدفق النظام دون انقطاع
• زيادة وتحسين سير العمل في جميع الأوقات

المسار الثاني - استعد

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

ومع ذلك ، فإن DevOps ليس يوتوبيا ، وإذا كان التسليم في اتجاه واحد ممكنًا ، فستكون طريقة الانحدار كافية. يعد تقييم المخرجات وإيصال التدفق أمرًا مهمًا للغاية لضمان الجودة. أول قناة اتصال "أولية" يجب تنفيذها هي Ops to Dev.

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

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

المسار الثالث - الاعوجاج 10

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

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

"ما يصلح للسيد لا يناسب المبتدئ. يجب أن تفهم تاو قبل تجاوز الهيكل ".

يشمل DevOps Third Way / Fast Lane تخصيص وقت للتجربة المستمرة على أساس يومي ، ومكافأة الفريق باستمرار على تحمل المخاطر ، وإدخال أخطاء في النظام لزيادة المرونة.

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

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

ملخص - قائمة مراجعة مؤسسة DevOps

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

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

خاتمة

لا يعني استخدام أدوات DevOps الحديثة مثل Chef و Docker و Ansible و Packer و Troposphere و Consul و Jenkins و SonarQube و AWS وما إلى ذلك أنك تطبق مبادئ DevOps. DevOps هي طريقة تفكير. نحن جميعًا جزء من نفس العملية ، ونشترك في نفس الوقت ونقدم القيمة معًا. يمكن لكل شخص يشارك في عملية تسليم البرنامج تسريع أو إبطاء النظام بأكمله. يمكن أن يؤدي الخطأ الذي تم إنشاؤه أثناء التطوير إلى تعطيل النظام وكذلك التكوين الخاطئ لجدار الحماية.

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