هل من الصعب الحصول على نقطة عند الحديث عن DevOps؟ لقد اجتمعنا من أجلك أوجه تشبيه حية وصيغ إيقاعية ومشورة خبراء ستساعد حتى غير المتخصصين على الوصول إلى هذه النقطة. في النهاية ، المكافأة هي DevOps لـ Red Hat.
نشأ مصطلح DevOps منذ 10 أعوام وانتقل من علامة التجزئة على Twitter إلى حركة ثقافية قوية في عالم تكنولوجيا المعلومات ، وهي فلسفة حقيقية تشجع المطورين على تحقيق النتائج بشكل أسرع وتجربة والمضي قدمًا باستخدام طريقة التكرار. أصبحت DevOps مرتبطة ارتباطًا وثيقًا بمفهوم التحول الرقمي. ولكن كما هو الحال غالبًا مع مصطلحات تكنولوجيا المعلومات ، فقد تمكنت DevOps ، على مدار عقد من الزمان ، من الحصول على الكثير من التعاريف والتفسيرات والمفاهيم الخاطئة.
لذلك ، حول DevOps ، يمكنك غالبًا سماع أسئلة مثل ، هل هو نفس المرونة؟ أم أنها نوع من المنهجية الخاصة؟ أم أنها مجرد مرادف آخر لكلمة "تعاون"؟
تتضمن DevOps العديد من المفاهيم المختلفة (التسليم المستمر والتكامل المستمر والأتمتة وما إلى ذلك) ، لذلك قد يكون عزل الشيء الرئيسي أمرًا صعبًا ، خاصةً عندما تكون جزئيًا في الموضوع. ومع ذلك ، فإن هذه المهارة مفيدة للغاية ، ولا يهم إذا كنت تحاول نقل أفكارك إلى رؤسائك أو مجرد إخبار أقاربك أو أصدقائك عن عملك. لذلك ، الآن ، ضع الفروق الدقيقة للمصطلحات في DevOps والتركيز على الصورة الكبيرة.
ما هو DevOps: 6 التعاريف والقياسات
لقد طلبنا من الخبراء شرح جوهر DevOps بأقصى قدر ممكن من الدقة والإيجاز حتى تصبح قيمتها واضحة للقارئ مع أي مستوى من التدريب التقني. استنادًا إلى نتائج هذه المحادثات ، اخترنا أكثر المقارنات الصياغية وإيقاعات الإيقاع إثارة والتي ستساعدك على بناء قصتك حول DevOps.
1. DevOps هي حركة ثقافية
"DevOps هي حركة ثقافية يتعرف فيها الطرفان (مطورو البرمجيات ومتخصصو تشغيل أنظمة تكنولوجيا المعلومات) على أن البرنامج لا يحقق فوائد حقيقية حتى يبدأ شخص ما في استخدامه: العملاء ، العملاء ، الموظفون ، يقول إيفلين أورليخ ، كبير المحللين في معهد ديف أوبس ، ليس هذا هو الهدف. "لذلك ، يوفر كلا هذين الطرفين معًا تسليمًا سريعًا وعالي الجودة للبرامج."
2. DevOps هو ما يمكّن المطورين
"تُمكّن DevOps المطورين من ملكية التطبيقات وإطلاقها وإدارة التسليم من البداية إلى النهاية""عادة ما يتحدثون عن DevOps كوسيلة لتسريع تسليم التطبيقات للإنتاج من خلال بناء وتطبيق العمليات الآلية" ، قال جاي شنيب ، مدير DevOps Platforms ، شركة Liberty Mutual Insurance Company. "ولكن بالنسبة لي هو شيء أكثر أهمية بكثير." يمنح DevOps للمطورين سلطة امتلاك التطبيقات أو أجزاء معينة من البرنامج وتشغيلها وإدارة التسليم من البداية إلى النهاية. تعمل DevOps على التخلص من تشويش المسؤولية وتؤدي جميع المشاركين في العملية إلى إنشاء بنية تحتية تلقائية وقائمة على التطوير. "
3. DevOps هو تعاون في إنشاء وتسليم التطبيقات
قال جور ستاف ، رئيس ورئيس قسم أتمتة الأعمال الرقمية في BMC: "ببساطة ، فإن DevOps هي مثل هذه الطريقة لإنتاج وتسليم البرامج عندما يعمل الجميع معًا".
4. DevOps هو خط أنابيب
"لا يمكن تجميع ناقل الحركة إلا إذا كانت جميع الأجزاء مناسبة معًا.""سأقارن DevOps مع خط تجميع السيارة" ، يتابع غور ستاف. - الفكرة هي التصميم المسبق وإجراء كافة التفاصيل بحيث يمكن تجميعها لاحقًا دون ملاءمة فردية. لا يمكن تجميع ناقل الحركة إلا إذا كانت جميع الأجزاء مناسبة معًا. يجب على أولئك الذين يقومون بتصميم المحرك وصنعه التفكير في كيفية تثبيته على الهيكل أو الإطار. يجب على أولئك الذين يصنعون المكابح أن يفكروا في العجلات وما إلى ذلك. يجب أن يكون هو نفسه مع البرنامج.
يجب أن يفكر المطور الذي ينشئ منطقًا تجاريًا أو واجهة مستخدم في قاعدة بيانات تخزّن معلومات حول العملاء ، وتدابير الأمان لحماية بيانات المستخدم ، وكيف ستعمل عندما تبدأ الخدمة في تقديم خدمة كبيرة ، وربما حتى ملايين الدولارات. جمهور المستخدم. "
"لجعل الناس يتعاونون ويفكرون في أجزاء العمل التي يؤديها الآخرون ، ولا يركزون فقط على مهامهم الخاصة - فهذه هي العقبة الكبرى التي يجب التغلب عليها. يضيف غور ستاف: "إذا نجحت ، فأمامك فرص ممتازة للتحول الرقمي".
5. DevOps هو المزيج الصحيح من الأشخاص والعمليات والأتمتة
عرضت Jayne Groll ، المدير التنفيذي لمعهد DevOps ، تشبيهًا كبيرًا لشرح DevOps. وفقا لها ، "DevOps يشبه وصفة الطهي التي توجد فيها ثلاث فئات رئيسية من المكونات: الناس ، والعمليات ، والأتمتة. يمكن أن تؤخذ معظم هذه المكونات من مناطق ومصادر أخرى: Lean و Agile و SRE و CI / CD و ITIL والقيادة والثقافة والأدوات. يكمن سر DevOps ، وكذلك أي وصفة جيدة ، في كيفية اختيار النسب الصحيحة ومزج هذه المكونات لزيادة سرعة وفعالية العمل عند إنشاء التطبيقات وإصدارها. "
6. DevOps - هذا عندما يعمل المبرمجون كفريق فورمولا 1
"السباق مخطط له ليس من البداية إلى النهاية ، بل من النهاية إلى النهاية."يقول كريس شورت ، المدير العام للتسويق في منصة Red Hat's وناشر قائمة DevOps'ish البريدية: "عند الحديث عما يمكن توقعه من مبادرة DevOps ، سأذكر فريق سباق NASCAR أو Formula 1 كمثال". - يكون لرئيس هذا الفريق هدف واحد: أخذ أقصى مكان ممكن وفقًا لنتائج السباق ، مع مراعاة الموارد المتاحة للفريق والمحاكمات التي سقطت على حصته. علاوة على ذلك ، لم يتم التخطيط للسباق من البداية إلى النهاية ، ولكن من النهاية إلى البداية. الهدف الأول هو الطموح ، ومن ثم يتم تحديد طرق لتحقيق ذلك. ثم يتم تقسيمهم إلى مهام فرعية ويتم تفويضهم إلى أعضاء الفريق. "
"قبل أسبوع كامل من السباق ، يشحذ الفريق محطة الحفرة. وهو يشارك في تدريب القوة والقلب ليكون في حالة جيدة في يوم سباق مرهق. انه يعمل على اتخاذ إجراءات مشتركة لحل أي مشاكل قد تنشأ في السباق. وبالمثل ، يجب على فريق التطوير تدريب مهارات إصدار إصدارات جديدة بشكل متكرر. مع هذه المهارات ونظام أمان يعمل بشكل جيد ، يحدث أيضًا إطلاق إصدارات جديدة في الإنتاج في كثير من الأحيان. في إطار هذه النظرة إلى العالم ، تعني زيادة السرعة زيادة في الأمن.
يضيف شورت "الهدف من ذلك هو عدم القيام بـ" الشيء الصحيح "، بل القضاء على أكبر عدد ممكن من الأشياء التي تقف في طريق النتيجة المرجوة. تعاون وتكيف بناءً على الملاحظات التي تتلقاها في الوقت الفعلي. كن مستعدًا للحالات الشاذة والعمل على تحسين الجودة لتقليل تأثيرها على الحركة نحو الهدف. هذا ما ينتظرنا في عالم DevOps. "
كيفية توسيع DevOps: 10 نصائح الخبراء
فقط DevOps و DevOps الهائل هما شيئان مختلفان تمامًا. سنخبرك بكيفية التغلب على الحواجز من الأولى إلى الثانية.بالنسبة للعديد من المؤسسات ، يبدأ الطريق إلى DevOps بسهولة وبشكل جيد. يتم إنشاء فرق عاطفية صغيرة ، ويتم استبدال العمليات القديمة بعمليات جديدة ولن تكون النجاحات الأولى طويلة.
للأسف ، هذه مجرد تألق مزيف ، وهم التقدم ، وفقًا لما قاله بن غرينيل ، المدير الإداري ورئيس قسم التكنولوجيا الرقمية في شركة الاستشارات الشمالية هايلاند. من المؤكد أن الانتصارات المبكرة مشجعة ، ولكنها لا تساعد في تحقيق الهدف النهائي ، وهو الاستخدام الضخم لـ DevOps في المنظمة.
من السهل أن نرى أنه نتيجة لذلك ، تتشكل ثقافة الانفصال إلى "نحن" و "هم"."في كثير من الأحيان ، تطلق المنظمات مثل هذه المشاريع الرائدة ، معتقدة أنها ستمهد الطريق أمام DevOps الجماهيرية ، دون تردد ، يمكنها ، وسيريد آخرون ، السير بهذه الطريقة" ، يشرح بن غرينيل. - يتم عادةً تعيين فرق لتنفيذ مثل هذه المشروعات من "الفايكنج" الواثقين من أنفسهم والذين قاموا بالفعل بشيء مماثل في أماكن أخرى ، لكنهم جددوا في مؤسستك. في الوقت نفسه ، يتم تشجيعهم على كسر وتدمير القواعد التي لا تزال ملزمة للجميع. من السهل أن نرى أنه نتيجة لذلك ، تتشكل ثقافة الانفصال إلى "نحن" و "هم" ، مما يعوق نقل المعرفة والمهارات. "
"وهذه القضية الثقافية ليست سوى واحدة من الأسباب التي يصعب تطويرها DevOps. وقال ستيف نيومان ، مؤسس ورئيس مجلس إدارة Scalyr ، تواجه فرق DevOps نمو الصعوبات التقنية البحتة التي تتميز بها الشركات سريعة النمو التي اعتمدت على تكنولوجيا المعلومات.
"في العالم الحديث ، تتغير الخدمات بمجرد ظهور هذه الحاجة. ويضيف ستيف نيومان أن الاستمرار في تطبيق الميزات الجديدة وتنفيذها أمر رائع بالطبع ، ولكن تنسيق هذه العملية وحل المشكلات يمثل مشكلة حقيقية. - في المؤسسات سريعة النمو ، يكافح المهندسون كجزء من الفرق متعددة الوظائف للاحتفاظ بالقدرة على تتبع التغييرات والآثار المتتالية التي يولدونها على مستوى التبعية. علاوة على ذلك ، فإن المهندسين ليسوا سعداء على الإطلاق عندما يُحرمون من هذه الفرصة ونتيجة لذلك يصبح من الصعب عليهم فهم جوهر المشكلات التي تنشأ ".
كيف تتغلب على هذه الصعوبات الموضحة أعلاه والانتقال إلى الاستخدام المكثف لـ DevOps في مؤسسة كبيرة؟ يحثك الخبراء على التحلي بالصبر ، حتى لو كان هدفك النهائي هو تسريع دورة تطوير البرمجيات والعمليات التجارية.1. تذكر أن التغيير الثقافي يستغرق وقتًا
جين جرول ، المدير التنفيذي لمعهد ديفوبس: "في رأيي ، ينبغي أن يكون امتداد ديفوبس متدرجًا ومتكررًا مثل التنمية السريعة (ويؤثر أيضًا على الثقافة). تركز Agile و DevOps على الفرق الصغيرة. لكن مع تزايد عدد هذه الفرق وتكاملها ، أصبح المزيد والمزيد من الأشخاص يطبقون أساليب عمل جديدة ، ونتيجة لذلك ، هناك تحول ثقافي واسع النطاق. "
2. قضاء ما يكفي من الوقت في التخطيط واختيار منصة
Eran Kinsbruner ، قائد المبشرين الفنيين ، Perfecto: "من أجل التوسع في العمل ، تحتاج فرق DevOps أولاً إلى تعلم كيفية الجمع بين العمليات والأدوات والمهارات التقليدية ، ثم تنمو ببطء كل مرحلة من مراحل DevOps واستقرارها. كل شيء يبدأ بالتخطيط الدقيق لقصص المستخدم وتدفقات القيمة (valueestream) ، تليها مرحلة كتابة البرامج والتحكم في الإصدار باستخدام التطوير القائم على الجذع أو الأساليب الأخرى الأكثر ملاءمة للتفرع المتكامل ودمج الكود. "
ثم تأتي مرحلة التكامل والاختبار ، حيث تكون هناك حاجة بالفعل إلى منصة التشغيل الآلي للتحجيم. وهنا من المهم لفرق DevOps أن تختار المنصة المناسبة التي تلبي مستوى مهاراتهم والأهداف النهائية للمشروع.
المرحلة التالية هي النشر في بيئة الإنتاج ، ويجب أن تكون آلية بالكامل باستخدام أدوات وحاويات الأوركسترا. في الوقت نفسه ، من المهم وجود بيئات افتراضية في جميع مراحل DevOps (محاكاة لبيئة الإنتاج ، وبيئة مراقبة الجودة ، وفي الواقع ، بيئة إنتاج) واستخدام دائمًا فقط أحدث البيانات للاختبارات من أجل الحصول على الاستنتاجات ذات الصلة. يجب أن تكون Analytics ذكية وقادرة على معالجة البيانات الضخمة بتعليقات سريعة وفعالة. "
3. تخلص من طعم المذنب
Gordon Haff ، مبشر RedHat: "إن إنشاء نظام وجو يتيح ويشجع على التجريب يسمح لنا بإدراك ما يسمى بالفشل الناجح في تطوير البرمجيات الرشيقة. هذا لا يعني أن لا أحد مسؤول عن الإخفاقات. في الواقع ، من الأسهل تأسيس شخص مسؤول ، لأن "المسؤولية" لم تعد تعني "أن تصبح السبب وراء الحادث". وهذا هو ، جوهر المسؤولية يتغير نوعيا. في هذه الحالة ، أصبحت أربعة عوامل مهمة للغاية: حجم الفشل والنُهج وعمليات الإنتاج والحوافز ". (لمعرفة المزيد حول هذه العوامل ، راجع دروس DevOps من Gordon Huff: 4 جوانب من التجارب الصحية.)
4. مسح الطريق إلى الأمام
بن غرينيل ، المدير الإداري ورئيس قسم التكنولوجيا الرقمية في شركة North Highland Consulting: "من أجل التوسع ، أوصي ، إلى جانب المشاريع الرائدة ، بإطلاق برنامج Clearing Path. الهدف من هذا البرنامج هو تنظيف القمامة التي تبقى مع رواد DevOps ، مثل القواعد التي فقدت أهميتها وأشياء أخرى مماثلة ، بحيث يظل المسار إلى الأمام واضحًا. "
"أعط الناس الدعم التنظيمي وأعطوا دفعة من خلال التواصل الذي يتجاوز المجموعة الرائدة ، والاحتفال على نطاق واسع بنجاح أساليب العمل الجديدة. تدريب الأشخاص الذين يشاركون في الموجة التالية من مشاريع DevOps والذين يشعرون بالقلق من استخدام DevOps لأول مرة. وتذكر أن هؤلاء الناس مختلفون تمامًا عن الرواد ".
5. جعل الأدوات أكثر ديمقراطية
ستيف نيومان ، مؤسس ورئيس Scalyr: "لا ينبغي إخفاء الأدوات عن الأشخاص ، ويجب أن يكون من السهل نسبيًا تعلمها لأي شخص مستعد لقضاء بعض الوقت في هذا. إذا تم توفير القدرة على طلب السجلات فقط لثلاثة أشخاص "معتمدين" للعمل مع نوع من الأدوات ، سيكون لديك دائمًا ثلاثة أشخاص كحد أقصى يمكنهم التعامل مع المشكلة المقابلة ، حتى إذا كانت لديك بيئة حوسبية كبيرة جدًا. بمعنى آخر ، هناك عنق الزجاجة الذي يمكن أن يؤدي إلى عواقب وخيمة (بالنسبة للأعمال). "
6. خلق الظروف المثالية للعمل الجماعي
توم كلارك ، رئيس المنصة المشتركة في ITV: "يمكنك أن تفعل أي شيء ، ولكن ليس كل ذلك مرة واحدة. لذلك ، ضع أهدافًا كبيرة ، وابدأ صغيرًا والمضي قدمًا بتكرار سريع. بمرور الوقت ، ستكتسب سمعة كفريق ينجح ، لذلك سيرغب الآخرون أيضًا في استخدام أساليبك. ولا تطارد بناء فريق فعال للغاية. بدلاً من ذلك ، وفر للناس ظروف عمل مثالية وستأتي الكفاءة من تلقاء نفسها. "
7. لا تنسى كونواي القانون ومجالس كانبان
لوغان ديغل ، مدير تسليم واستراتيجية CollabNetVersionOne DevOps: "من المهم أن نفهم عواقب قانون كونواي. في إعادة صياغة حرة ، ينص هذا القانون على أن المنتجات التي نقوم بإنشائها والعمليات التي نستخدمها ، بما في ذلك DevOps ، تتحول إلى نفس مؤسستنا. "
"إذا كانت المنظمة مجزأة إلى حد كبير ، وعند تخطيط البرامج وإنشائها وإصدارها ، تنتقل الإدارة من يد إلى يد عدة مرات ، وسيكون تأثير التحجيم صفريًا أو قصير الأجل. إذا قامت المؤسسة بتكوين فرق متعددة الوظائف حول المنتجات التي يتم تمويلها بتوجيه السوق ، فإن فرص النجاح تزداد بشكل كبير. "
"هناك جانب آخر مهم من التوسع وهو عرض على لوحات kanban جميع الأعمال الجارية (WIP ، workinprogress). عندما تظهر منظمة في مكان يستطيع الناس فيه رؤية مثل هذه الأشياء ، فإنها تحفز التعاون إلى حد كبير ، مما يكون له تأثير إيجابي على التوسع. "
8. ابحث عن الندبات القديمة
مانويل بايس ، مستشار DevOps ومؤلف مشارك لفريق طبولوجيا الفريق: "لا يمكن وصف ممارسات DevOps بأكثر من Devi Ops نفسها ومحاولة تطبيقها على وظائف أخرى ، بالطريقة المثلى. سيوفر هذا بلا شك تأثيرًا معينًا (على سبيل المثال ، بسبب أتمتة التحكم اليدوي) ، لكن يمكن تحقيق الكثير إذا بدأنا بفهم عمليات التسليم والتعليقات.
"إذا كانت هناك ندوب قديمة في نظام تكنولوجيا المعلومات بالمؤسسة - الإجراءات وآليات الإدارة التي تم تنفيذها كنتيجة للحوادث الماضية ، ولكنها فقدت أهميتها (بسبب التغيير في المنتجات أو التقنيات أو العمليات) ، فمن المؤكد أنها تحتاج إلى إزالتها أو تنعيمها ، وليس أتمتة العمليات غير الفعالة أو غير الضرورية. "
9. لا تفرخ خيارات DevOps
أنتوني إدواردز ، مدير إنتاج Eggplant: “DevOps مصطلح غامض للغاية ، لذلك كل فريق لديه نسخته الخاصة من DevOps. وليس هناك ما هو أسوأ عندما يظهر 20 نوعًا من DevOps على الفور في المؤسسة ، والتي لا تتوافق جيدًا. لا يمكن أن يكون لكل فريق من فرق التطوير الثلاثة واجهة خاصة به بين التطوير وإدارة المنتجات. نظرًا لأنه من المستحيل على المنتجات أن تتمتع بتوقعاتها الفريدة فيما يتعلق بمعالجة الملاحظات عند نقل بيئة الإنتاج إلى جهاز المحاكاة. وإلا ، فلن تتمكن أبدًا من تطوير DevOps. "
10. الوعظ بقيمة DevOps للعمل
ستيف نيومان ، مؤسس ورئيس مجلس إدارة شركة Scalyr: "العمل على إدراك قيمة DevOps. تعلم وتتردد في الحديث عن فوائد ما تفعله. توفر DevOps الوقت والمال بشكل لا يصدق (فكر فقط: وقت تعطل أقل ، ووقت أقصر من وقت الاسترداد) ، ويجب على فرق DevOps التأكيد بلا كلل (ووعظ) على أهمية هذه المبادرات لنجاح الأعمال. حتى تتمكن من توسيع دائرة الأتباع وتعزيز تأثير DevOps في المنظمة. "
BONUS
في 13 سبتمبر ، ستصل DevOps الخاصة بنا إلى Red Hat Forum Russia - نعم ، Red Hat ، كشركة مصنعة للبرامج ، لديها فرق وممارسات DevOps الخاصة بها.سيخبر مهندسنا مارك بيرجر ، الذي يقوم بتطوير خدمات الأتمتة الداخلية لمجموعات أخرى في جميع أنحاء المنظمة ، قصته باللغة الروسية البحتة - كيف قام فريق Red Hat DevOps بترحيل التطبيقات من البيئات التي تديرها Virtual Virtual من Ansible إلى تنسيق حاوية كامل على منصة OpenShift.
ولكن هذا ليس كل شيء:بعد أن تنقل المنظمات أعباء العمل إلى الحاويات ، قد لا تعمل طرق مراقبة التطبيقات التقليدية. في التقرير الثاني ، سنشرح دوافعنا لتغيير طريقة التسجيل وإظهار استمرار المسار الذي أدى بنا إلى أساليب حديثة في المراقبة والرصد.