هل من الصعب فهم النقطة الرئيسية عند الحديث عن DevOps؟ لقد جمعنا لك تشبيهات حية وصيغًا مذهلة ونصائح من الخبراء ستساعد حتى غير المتخصصين في الوصول إلى صلب الموضوع. في النهاية، المكافأة هي DevOps الخاصة بموظفي Red Hat.
نشأ مصطلح DevOps منذ 10 سنوات وتحول من هاشتاج على تويتر إلى حركة ثقافية قوية في عالم تكنولوجيا المعلومات، وهي فلسفة حقيقية تشجع المطورين على إنجاز الأمور بشكل أسرع والتجربة والتكرار للأمام. لقد أصبحت DevOps مرتبطة ارتباطًا وثيقًا بمفهوم التحول الرقمي. ولكن كما يحدث غالبًا مع مصطلحات تكنولوجيا المعلومات، اكتسبت DevOps على مدار السنوات العشر الماضية العديد من التعريفات والتفسيرات والمفاهيم الخاطئة حول نفسها.
لذلك، غالبًا ما يمكنك سماع أسئلة حول DevOps، هل هي نفس Agile؟ أم أن هذه بعض المنهجية الخاصة؟ أم أنها مجرد مرادف آخر لكلمة "التعاون"؟
يتضمن DevOps العديد من المفاهيم المختلفة (التسليم المستمر، والتكامل المستمر، والأتمتة، وما إلى ذلك)، لذا فإن استخلاص ما هو مهم قد يكون أمرًا صعبًا، خاصة عندما تكون شغوفًا بالموضوع. ومع ذلك، فإن هذه المهارة مفيدة للغاية، بغض النظر عما إذا كنت تحاول نقل أفكارك إلى رؤسائك أو ببساطة إخبار أحد أفراد عائلتك أو أصدقائك عن عملك. لذلك، دعونا نضع جانبًا الفروق الدقيقة في مصطلحات DevOps في الوقت الحالي ونركز على الصورة الكبيرة.
ما هو DevOps: 6 تعريفات وقياسات
لقد طلبنا من الخبراء شرح جوهر DevOps ببساطة وإيجاز قدر الإمكان حتى تصبح قيمته واضحة للقراء بأي مستوى من المعرفة التقنية. بناءً على نتائج هذه المحادثات، اخترنا التشبيهات الأكثر لفتًا للانتباه والصياغات المدهشة التي ستساعدك في بناء قصتك حول DevOps.
1. DevOps هي حركة ثقافية
"إن DevOps عبارة عن حركة ثقافية يدرك فيها الطرفان (مطورو البرامج ومتخصصو تشغيل أنظمة تكنولوجيا المعلومات) أن البرامج لا تحقق فوائد حقيقية حتى يبدأ شخص ما في استخدامها: العملاء، والعملاء، والموظفين، وليس الهدف"، كما تقول إيفلين أورليش، كبيرة الباحثين. محلل في معهد DevOps. "وبالتالي، يضمن كلا الطرفين معًا تسليم البرامج بسرعة وبجودة عالية."
2. تهدف DevOps إلى تمكين المطورين.
"تُمكّن DevOps المطورين من امتلاك التطبيقات وتشغيلها وإدارة التسليم من البداية إلى النهاية."
يقول جاي شنيب، مدير منصات DevOps في شركة التأمين Liberty Mutual: "عادةً ما يتم الحديث عن DevOps كوسيلة لتسريع تسليم التطبيقات إلى الإنتاج من خلال بناء وتنفيذ العمليات الآلية". "لكن بالنسبة لي، هذا شيء أكثر أهمية بكثير." يعمل DevOps على تمكين المطورين من امتلاك تطبيقات أو أجزاء محددة من البرامج وتشغيلها وإدارة تسليمها من البداية إلى النهاية. تعمل DevOps على التخلص من ارتباك المسؤولية وتوجيه جميع المشاركين في إنشاء بنية تحتية آلية يقودها المطورون.
3. تدور أحداث DevOps حول التعاون في إنشاء التطبيقات وتقديمها.
يقول جور ستاف، الرئيس ورئيس قسم أتمتة الأعمال الرقمية في BMC: "ببساطة، DevOps هو نهج لإنتاج البرامج وتسليمها حيث يعمل الجميع معًا".
4. DevOps عبارة عن مسار
"لا يمكن تجميع الناقل إلا إذا كانت جميع الأجزاء متوافقة معًا."
"أود أن أقارن DevOps بخط تجميع السيارات،" يتابع جور ستاف. - الفكرة هي تصميم جميع الأجزاء وتصنيعها مسبقًا بحيث يمكن تجميعها بعد ذلك دون تعديل فردي. لا يمكن تجميع الناقل إلا إذا كانت جميع الأجزاء متوافقة معًا. يجب على أولئك الذين يصممون ويبنون المحرك أن يفكروا في كيفية تركيبه على الجسم أو الإطار. أولئك الذين يصنعون المكابح يجب أن يفكروا في العجلات، وما إلى ذلك. وينبغي أن يكون الشيء نفسه صحيحا مع البرمجيات.
يجب على المطور الذي يقوم بإنشاء منطق أعمال أو واجهة مستخدم أن يفكر في قاعدة البيانات التي تخزن معلومات العميل، والتدابير الأمنية لحماية بيانات المستخدم، وكيف سيعمل كل هذا عندما تبدأ الخدمة في خدمة جمهور كبير من المستخدمين، ربما يصل إلى ملايين الدولارات ".
"إن جعل الناس يتعاونون ويفكرون في أجزاء العمل التي يقوم بها الآخرون بدلاً من التركيز فقط على مهامهم الخاصة هو أكبر عقبة يجب التغلب عليها. ويضيف جور ستاف: "إذا تمكنت من القيام بذلك، فلديك فرصة ممتازة للتحول الرقمي".
5. DevOps هو المزيج الصحيح من الأشخاص والعمليات والأتمتة
قدم جين جرول، المدير التنفيذي لمعهد DevOps، تشبيهًا رائعًا لشرح DevOps. على حد تعبيرها، "تشبه DevOps وصفة تحتوي على ثلاث فئات رئيسية من المكونات: الأشخاص والعمليات والأتمتة. يمكن أخذ معظم هذه المكونات من مجالات ومصادر أخرى: Lean، Agile، SRE، CI/CD، ITIL، القيادة، الثقافة، الأدوات. السر في DevOps، مثل أي وصفة جيدة، هو كيفية الحصول على النسب الصحيحة ومزيج هذه المكونات لزيادة سرعة وكفاءة إنشاء التطبيقات وإصدارها.
6. DevOps هو عندما يعمل المبرمجون مثل فريق الفورمولا 1
وأضاف: "السباق لم يتم التخطيط له من البداية إلى النهاية، بل على العكس من ذلك، من النهاية إلى البداية".
يقول كريس شورت، المدير الأول لتسويق المنصات السحابية في Red Hat وناشر نشرة DevOps'ish الإخبارية: "عندما أتحدث عما يمكن توقعه من مبادرة DevOps، أفكر في فريق سباق NASCAR أو Formula 1 كمثال". – قائد مثل هذا الفريق لديه هدف واحد: الحصول على أعلى مكان ممكن في نهاية السباق، مع الأخذ في الاعتبار الموارد المتاحة للفريق والتحديات التي حلت به. في هذه الحالة، يتم التخطيط للسباق ليس من البداية إلى النهاية، ولكن على العكس من ذلك، من النهاية إلى البداية. أولاً، يتم تحديد هدف طموح، ومن ثم يتم تحديد طرق تحقيقه. ثم يتم تقسيمها إلى مهام فرعية وتفويضها لأعضاء الفريق.
"يقضي الفريق الأسبوع بأكمله قبل السباق لإتقان نقطة التوقف. يقوم بتدريبات القوة وتمارين القلب للحفاظ على لياقته البدنية ليوم سباق مرهق. ممارسات العمل معًا لحل أي مشاكل قد تنشأ أثناء السباق. وبالمثل، يجب على فريق التطوير تدريب مهارة إصدار الإصدارات الجديدة بشكل متكرر. إذا كانت لديك مثل هذه المهارات ونظام أمان يعمل بشكل جيد، فإن إطلاق الإصدارات الجديدة في الإنتاج يحدث أيضًا في كثير من الأحيان. يقول شورت: «في هذه النظرة العالمية، زيادة السرعة تعني زيادة الأمان».
ويضيف شورت: "لا يتعلق الأمر بفعل "الشيء الصحيح"، بل يتعلق بإزالة أكبر عدد ممكن من الأشياء التي تقف في طريق النتيجة المرجوة". التعاون والتكيف بناءً على التعليقات التي تتلقاها في الوقت الفعلي. كن مستعدًا للحالات الشاذة واعمل على تحسين الجودة لتقليل تأثيرها على التقدم نحو هدفك. وهذا ما ينتظرنا في عالم DevOps.
كيفية توسيع نطاق DevOps: 10 نصائح من الخبراء
إن الأمر مجرد أن DevOps و DevOps الشامل شيئان مختلفان تمامًا. سنخبرك بكيفية التغلب على الحواجز في الطريق من الأول إلى الثاني.
بالنسبة للعديد من المؤسسات، تبدأ الرحلة إلى DevOps بسهولة وبشكل ممتع. يتم إنشاء فرق صغيرة متحمسة، ويتم استبدال العمليات القديمة بعمليات جديدة، ولن تستغرق النجاحات الأولى وقتًا طويلاً.
للأسف، هذه مجرد واجهة زائفة، وهم التقدم، كما يقول بن جرينيل، المدير الإداري ورئيس القسم الرقمي في شركة نورث هايلاند الاستشارية. من المؤكد أن المكاسب المبكرة مشجعة، لكنها لا تساعد في تحقيق الهدف النهائي المتمثل في اعتماد DevOps على نطاق واسع عبر المؤسسة.
ومن السهل أن نرى أن النتيجة هي ثقافة الانقسام بين "نحن" و"هم".
يوضح بن غرينيل: "في كثير من الأحيان، تطلق المؤسسات هذه المشاريع الرائدة معتقدة أنها ستمهد الطريق لأنظمة DevOps السائدة، دون النظر فيما إذا كان الآخرون سيكونون قادرين أو راغبين في اتباع هذا المسار". – عادةً ما يتم تعيين فرق تنفيذ مثل هذه المشاريع من “الفارانجيين” الواثقين من أنفسهم والذين قاموا بالفعل بشيء مماثل في أماكن أخرى، لكنهم جدد في مؤسستك. وفي الوقت نفسه، يتم تشجيعهم على كسر وتدمير القواعد التي تظل ملزمة لأي شخص آخر. ومن السهل أن نرى أن النتيجة هي ثقافة "نحن" و"هم" التي تمنع نقل المعرفة والمهارات.
"وهذه المشكلة الثقافية هي مجرد أحد الأسباب التي تجعل من الصعب توسيع نطاق DevOps. قال ستيف نيومان، مؤسس ورئيس مجلس إدارة Scalyr: "تواجه فرق DevOps تحديات تقنية متزايدة نموذجية لشركات تكنولوجيا المعلومات سريعة النمو".
"في العالم الحديث، تتغير الخدمات بمجرد ظهور الحاجة إليها. من الرائع تنفيذ الميزات الجديدة وتنفيذها باستمرار، ولكن تنسيق هذه العملية والقضاء على المشكلات التي تنشأ يمثل صداعًا حقيقيًا، كما يضيف ستيف نيومان. - في المؤسسات سريعة النمو، يكافح المهندسون في الفرق متعددة الوظائف للحفاظ على رؤية التغيير والتأثيرات المتتالية التي يخلقها على مستوى التبعية. علاوة على ذلك، لا يشعر المهندسون بالسعادة عندما يُحرمون من هذه الفرصة، ونتيجة لذلك، يصبح من الصعب عليهم فهم جوهر المشكلات التي تنشأ.
كيف يمكن التغلب على هذه التحديات الموضحة أعلاه والانتقال إلى الاعتماد الشامل لـ DevOps في مؤسسة كبيرة؟ يحث الخبراء على الصبر، حتى لو كان هدفك النهائي هو تسريع دورة تطوير البرامج والعمليات التجارية.
1. تذكر أن تغيير الثقافة يستغرق وقتًا.
جين جرول، المدير التنفيذي لمعهد DevOps: "في رأيي، يجب أن يكون التوسع في DevOps تدريجيًا ومتكررًا مثل التطوير السريع (ويلامس الثقافة بنفس القدر). تركز Agile و DevOps على الفرق الصغيرة. ولكن مع نمو هذه الفرق من حيث العدد والتكامل، ينتهي بنا الأمر إلى تبني المزيد من الأشخاص طرقًا جديدة للعمل، ونتيجة لذلك هناك تحول ثقافي هائل.
2. قضاء ما يكفي من الوقت في التخطيط واختيار المنصة
إيران كينسبرونر، المبشر التقني الرئيسي في Perfecto: «Чтобы масштабирование сработало, командам DevOps в начале надо научиться сочетать традиционные процессы, инструменты и навыки, а затем медленно взращивать каждую отдельную фазу DevOps и стабилизировать ее. Все начинается с тщательного планирования пользовательских историй (userstory) и потоков создания ценности (valuestream), после чего наступает этап написания ПО и контроля версий с использованием trunk-based development или других подходов, наиболее подходящих для ветвления и слияние кода».
"ثم تأتي مرحلة التكامل والاختبار، حيث تكون هناك حاجة بالفعل إلى منصة قابلة للتطوير للأتمتة. وهنا من المهم لفرق DevOps اختيار النظام الأساسي المناسب الذي يناسب مستوى مهاراتهم والأهداف النهائية للمشروع.
المرحلة التالية هي النشر إلى الإنتاج ويجب أن يكون ذلك مؤتمتًا بالكامل باستخدام أدوات التنسيق والحاويات. من المهم أن تكون لديك بيئات افتراضية في جميع مراحل DevOps (محاكي الإنتاج، وبيئة ضمان الجودة، وبيئة الإنتاج الفعلية) واستخدم دائمًا أحدث البيانات للاختبارات للحصول على الاستنتاجات ذات الصلة. يجب أن تكون التحليلات ذكية وقادرة على معالجة البيانات الضخمة من خلال تعليقات سريعة وقابلة للتنفيذ.
3. أخرج الذنب من المسؤولية.
جوردون هاف، مبشر ريد هات: "إن إنشاء نظام ومناخ يسمح بالتجربة ويشجعها يسمح بما يعرف بالفشل الناجح في تطوير البرمجيات الرشيقة. هذا لا يعني أنه لا يوجد أحد مسؤول عن الفشل. في الواقع، أصبح تحديد المسؤول أسهل، لأن "المسؤولية" لم تعد تعني "التسبب في وقوع حادث". أي أن جوهر المسؤولية يتغير نوعياً. وهناك أربعة عوامل تصبح حاسمة: مدى التعطيل، والنهج، وعمليات الإنتاج، والحوافز. (يمكنك قراءة المزيد عن هذه العوامل في مقالة جوردون هوف "دروس DevOps: 4 جوانب للتجارب الصحية.")
4. قم بتمهيد الطريق للأمام
بن غرينيل، المدير الإداري ورئيس القسم الرقمي في شركة North Highland الاستشارية: "ولتحقيق التوسع، أوصي بإطلاق برنامج "تمهيد الطريق" جنبًا إلى جنب مع المشاريع الرائدة. الهدف من هذا البرنامج هو تنظيف القمامة التي يتركها رواد DevOps وراءهم، مثل القواعد القديمة وأشياء من هذا القبيل، بحيث يظل الطريق إلى الأمام واضحًا.
"امنح الأشخاص الدعم التنظيمي والزخم من خلال التواصل الذي يتجاوز المجموعة الرائدة من خلال الاحتفال على نطاق واسع بنجاحات طرق العمل الجديدة. قم بتدريب الأشخاص المشاركين في الموجة التالية من مشاريع DevOps والذين يشعرون بالتوتر بشأن استخدام DevOps لأول مرة. وتذكر أن هؤلاء الأشخاص مختلفون تمامًا عن الرواد.
5. إضفاء الطابع الديمقراطي على الأدوات
ستيف نيومان، مؤسس ورئيس مجلس إدارة Scalyr: "لا ينبغي إخفاء الأدوات عن الناس، ويجب أن تكون سهلة التعلم نسبيًا لأي شخص يرغب في تخصيص الوقت لها. إذا كانت القدرة على الاستعلام عن السجلات مقتصرة على ثلاثة أشخاص "معتمدين" لاستخدام إحدى الأدوات، فسيكون لديك دائمًا ثلاثة أشخاص كحد أقصى متاحين للتعامل مع المشكلة، حتى لو كان لديك بيئة حوسبة كبيرة جدًا. بمعنى آخر، هناك عنق الزجاجة هنا يمكن أن يؤدي إلى عواقب (تجارية) خطيرة».
6. تهيئة الظروف المثالية للعمل الجماعي
توم كلارك، رئيس المنصة المشتركة في ITV: "يمكنك أن تفعل أي شيء، ولكن ليس كل شيء في وقت واحد. لذا، حدد أهدافًا كبيرة، وابدأ صغيرًا، ثم تقدم للأمام بتكرارات سريعة. بمرور الوقت، ستكتسب سمعة جيدة في إنجاز الأمور، لذلك سيرغب الآخرون في استخدام أساليبك أيضًا. ولا تقلق بشأن بناء فريق فعال للغاية. وبدلاً من ذلك، قم بتزويد الأشخاص بظروف عمل مثالية وستتبع ذلك الكفاءة.
7. لا تنسى قانون كونواي ولوحات كانبان
لوجان دايجل، مدير تسليم البرامج وإستراتيجية DevOps في CollabNetVersionOne: "من المهم أن نفهم عواقب قانون كونواي. في إعادة صياغتي الفضفاضة، ينص هذا القانون على أن المنتجات التي نقوم بإنشائها والعمليات التي نستخدمها للقيام بذلك، بما في ذلك DevOps، تبين أنها منظمة بنفس الطريقة التي يتم بها تنظيم منظمتنا.
"إذا كان هناك الكثير من الصوامع في المؤسسة، وتغيرت السيطرة عدة مرات عند تخطيط البرامج وإنشائها وإصدارها، فإن تأثير التوسع سيكون صفرًا أو قصير الأجل. إذا قامت إحدى المؤسسات ببناء فرق متعددة الوظائف حول المنتجات التي يتم تمويلها من خلال التركيز على السوق، فإن فرص النجاح تزيد بشكل كبير.
"أحد الجوانب المهمة الأخرى للقياس هو عرض جميع الأعمال الجارية (WIP، Workinprogress) على لوحات Kanban. عندما يكون لدى المؤسسة مكان حيث يمكن للأشخاص رؤية هذه الأشياء، فإن ذلك يشجع التعاون بشكل كبير، مما له تأثير إيجابي على التوسع.
8. ابحث عن الندبات القديمة
مانويل بايس، مستشار DevOps والمؤلف المشارك لـ Team Topologies: "إن أخذ ممارسات DevOps إلى ما هو أبعد من Dev وOps نفسها ومحاولة تطبيقها على وظائف أخرى ليس هو النهج الأمثل. ومن المؤكد أن هذا سيكون له بعض التأثير (على سبيل المثال، من خلال أتمتة التحكم اليدوي)، ولكن يمكن تحقيق الكثير إذا بدأنا بفهم عمليات التسليم والتعليقات.
"إذا كانت هناك ندوب قديمة في نظام تكنولوجيا المعلومات الخاص بالمؤسسة - الإجراءات وآليات الإدارة التي تم تنفيذها نتيجة لحوادث سابقة، ولكنها فقدت أهميتها (بسبب التغييرات في المنتجات أو التقنيات أو العمليات) - فمن المؤكد أنها تحتاج إلى إزالتها أو تنعيمها، بدلاً من أتمتة العمليات غير الفعالة أو غير الضرورية.
9. لا تولد خيارات DevOps
أنتوني إدواردز، مدير العمليات في Eggplant: "إن مصطلح DevOps غامض للغاية، لذا ينتهي الأمر بكل فريق بالحصول على نسخته الخاصة من DevOps. وليس هناك ما هو أسوأ عندما يكون لدى المؤسسة فجأة 20 نوعًا من DevOps التي لا تتوافق جيدًا معًا. من المستحيل أن يكون لكل فريق من فرق التطوير الثلاثة واجهة خاصة به بين التطوير وإدارة المنتج. ولا ينبغي أن يكون للمنتجات توقعاتها الفريدة الخاصة بها للتعامل مع الملاحظات عند نقلها إلى جهاز محاكاة الإنتاج. وإلا فلن تتمكن أبدًا من توسيع نطاق DevOps.
10. نشر القيمة التجارية لـ DevOps
ستيف نيومان، مؤسس ورئيس مجلس إدارة Scalyr: "اعمل على التعرف على قيمة DevOps. تعلم ولا تتردد في التحدث عن فوائد ما تفعله. يعد DevOps وسيلة رائعة لتوفير الوقت والمال (فكر فقط: وقت توقف أقل، ومتوسط وقت أقصر للتعافي)، ويجب على فرق DevOps التأكيد (والوعظ) بلا كلل على أهمية هذه المبادرات لنجاح الأعمال. وبهذه الطريقة يمكنك توسيع دائرة الأتباع وزيادة تأثير DevOps في المؤسسة.
BONUS
في ستصل DevOps الخاصة بنا في 13 سبتمبر - نعم، لدى Red Hat، باعتبارها شركة مصنعة للبرامج، فرق وممارسات DevOps الخاصة بها.
سوف يروي مهندسنا مارك بيرجر، الذي يقوم بتطوير خدمات الأتمتة الداخلية للمجموعات الأخرى في جميع أنحاء المؤسسة، قصته الخاصة باللغة الروسية الخالصة - كيف قام فريق Red Hat DevOps بترحيل التطبيقات من البيئات الافتراضية Hat Virtualization التي تديرها Ansible إلى تنسيق حاوية كامل على منصة OpenShift.
لكن هذا ليس كل شيء:
بمجرد قيام المؤسسات بنقل أعباء العمل إلى الحاويات، قد لا تعمل أساليب مراقبة التطبيقات التقليدية. وفي المحاضرة الثانية سنشرح دوافعنا لتغيير الطريقة التي نسجل بها ونظهر استمرار المسار الذي قادنا إلى أساليب التسجيل والمراقبة الحديثة.
المصدر: www.habr.com