يشارك كريس بايتارت ، المخضرم في DevOps ، الذي كان رائدًا في DevOpsDays ، تجربته ، وستفاجئك النتائج التي توصل إليها.
قبل عشر سنوات ، قمنا فجأة برحلة. لقد جمعنا بعضًا من أصدقائنا الجيدين في Ghent (بلجيكا) لمناقشة تجارب الحوسبة السحابية السريعة والمفتوحة المصدر والمبكرة. في عام 2009 ، ألقى جون Allspoe و Paul Hammond محاضرة في Velocity حول "10+ Deployments a Day: Dev and Ops Collaboration at Flickr" ( وهو أمر يستحق المشاهدة). بعد رؤية هذا الحديث ، قرر باتريك ديبوا تأسيس DevOpsDays.
هل صحيح أن عالم DevOps قد تغير كثيرًا خلال هذه السنوات العشر؟ لقد كنت أحضر أحداث DevOpsDays منذ بداية المؤتمر ، وخلال هذا الوقت اكتسبت خبرة كبيرة. في هذا المنشور ، سأشارك 10 برامج تعليمية قد تكون مفيدة لك أيضًا.
1. لا يوجد شيء اسمه مهندس DevOps
العديد من الفرق لديها شخص يحمل لقب مهندس DevOps ، وليس كل المتخصصين يحبون هذا اللقب. يعطي اسم المهنة هذا انطباعًا خاطئًا بأن DevOps هي وظيفة يمكن أن يقوم بها شخص واحد. في أغلب الأحيان ، مهندس DevOps هو مهندس Linux الذي ، مع بعض الحظ ، يمكنه حل مشاكل الأتمتة. عندما يبدأ القائمون بالتوظيف في البحث عن مهندس DevOps ، يجب على الباحثين عن العمل أن يسألوا أنفسهم الأسئلة الصحيحة: "ما الذي تريده الشركة حقًا من الباحث عن العمل؟ هل يبحثون عن مهندس تجميع؟ Senora الذي يفهم المتطلبات غير الوظيفية؟ متخصص في قسم العمليات قادر على التعامل مع الأتمتة أو غيره؟ في أغلب الأحيان ، تبحث الشركات عن متخصص يصرف انتباه بقية الموظفين عن عدم الامتثال للمبادئ والمتطلبات العملية لشركة Agile.
في المؤسسات التي بها أقسام DevOps كبيرة ، كقاعدة عامة ، لا يشارك أحد في DevOps. كلمة "DevOps" تتحدث فقط عن الانفصال عن باقي أعضاء الفريق ، ويمكن لمقدم الطلب الحصول على راتب جيد وتعلم مهارات جديدة في العمل ، لكنه لن "يقوم بـ DevOps".
2. فرق DevOps غير موجودة
لقد قلنا كثيرًا في الماضي أن هدف DevOps هو القضاء على الالتباس بين الفرق المختلفة. على وجه الخصوص ، بين المطورين وموظفي الإدارات التشغيلية. ومع ذلك ، فقد واجهنا مؤخرًا ظاهرة جديدة - ظهور العديد من فرق DevOps.
يبدو بناء فريق DevOps وكأنه ممارسة جديدة ، ولكن هناك تناقضات واضحة هنا. في إحدى المؤسسات ، سيتعامل هذا الفريق مع أدوات التطوير ، وفي مؤسسة أخرى ، يكون ذلك بمثابة جدار بين فريق التطوير ومتخصصي العمليات. المشكلة هي أن هذا الجدار يخلق الارتباك والإحباط ويقلل من مستوى التفاعل المفيد. يحل الفريق الذي يُطلق عليه اسم "DevOps" في أحسن الأحوال مجموعة متنوعة من المشكلات ويتحمل بعض المسؤولية عن الخدمات التي يعملون معها. عادةً ما تفضل الفرق المحترفة عدم إدراج كلمة "DevOps" في أسمائها.
من واقع خبرتي ، من المحتمل أن يؤدي استخدام كلمة "DevOps" في اسم الفريق إلى إعاقة تحقيق النتائج المرجوة.
3. مشاريع DevOps غير موجودة
جميع المشاريع محدودة. تقوم بتطوير ونشر الحل الخاص بك والمضي قدمًا. أيضًا ، على مدار السنوات العشر الماضية ، كان هناك حديث عن أن DevOps هو تحسين مستمر ، والتحسين المستمر لا نهاية له. في المقابل ، تكون نتيجة مشاريعك خدمات طويلة الأمد ، وتشير الخدمة إلى التسلسل "التطوير -> النشر -> الدعم الصحي"
فقط بعد أن ننظر إلى الخدمات خارج المشاريع يمكننا أن نرى الجوانب التي يتم نسيانها بسهولة: المتطلبات غير الوظيفية. تتضمن المتطلبات غير الوظيفية وظائف لا تتناسب مع سلوك معين. تحدد هذه المتطلبات أيضًا تقييمنا لأداء النظام. غالبًا ما تتضمن هذه المتطلبات جوانب تم تصنيفها على أنها DevOps: الموثوقية وقابلية الاستخدام وقابلية الصيانة وقابلية التوسع. كل هذه الخصائص مهمة لتحقيق نتائج الأعمال.
عند العمل في مشاريع قصيرة الأجل ، هناك خطر يتمثل في أنك لن تولي اهتمامًا كافيًا لهذا العمل. عندما تنتقل إلى المشروع التالي ، لن تفكر بعد الآن في المتطلبات غير الوظيفية للمشروع السابق ، حيث ستواجه تحديات جديدة ، ولن تزعجك بقية المشكلات. في المقابل ، عند إدارة خدمة ما ، فإنك تدخل حقًا في العمل ، ومن مصلحتك الفضلى تلميع كل شيء حتى يعمل كل شيء بسلاسة.
4. أدوات DevOps غير موجودة
بينما سيحاول العديد من البائعين بيع أدوات متنوعة لك ، بما في ذلك الأداة التي ستحل جميع مشاكلك ، فإن DevOps لا يتعلق بالأدوات. تدور DevOps حول الأشخاص وتفاعلاتهم. بعض الأدوات تساعد الناس حقًا على التعاون. في كثير من الأحيان ، يمكن أن تساعد الأدوات الأشخاص من خلفيات مختلفة على مشاركة نفس المصطلحات والأنظمة البيئية. ولكن كما هو الحال في كثير من الأحيان ، تعيق الأدوات طريق الاتصال الفعال.
يمكن للثقافة القائمة على الأدوات عزل الأشخاص بدلاً من مساعدتهم على التفاعل. الحقيقة هي أن الناس يصبحون مهووسين بسلسلة أدواتهم ويبتعدون عن أولئك الذين لا يستخدمونها. في حين أن بعض الأدوات يمكن أن تكون مفيدة للغاية من وجهة نظر فنية ، فإن عددًا من الأدوات الجديدة (يشار إليها تقليديًا باسم DevOps) قد وسعت الصدع بين المجموعات المختلفة. على سبيل المثال ، كثيرًا ما أسمع عبارة "يعمل هذا في الحاوية الخاصة بي". يستخدم المطورون هذه العبارة للإشارة إلى أن عملهم قد تم. لا تحل الحاويات في حد ذاتها مشاكل التشغيل البيني المرتبطة بتشغيل التطبيقات بكفاءة. لا يمكننا أن نسمح للأدوات بإبعادنا عن بعضنا البعض.
5. لا توجد شهادة في DevOps
لا يوجد اختبار للاختيار من متعدد يمكنه تأكيد قدرتك على التفاعل الفعال مع الزملاء. قد تتمتع المنظمات التي تقدم الشهادات بخبرة فنية مذهلة (وحتى اتصال فعال) ، ولكن لا يمكن أن تُظهر الشهادة أن شخصًا ما جيد في DevOps.
لسوء الحظ ، تتطلب فرق الإدارة شهادات في مجال يصعب التصديق عليه. كن على دراية بالبرامج والأجهزة المفضلة لديك ، واستكشف السحابة. دراسة في إحدى الجامعات المحلية، وقراءة الكتب التي يمكنك من خلالها تعلم الكثير، مثل ده مينغ ، Forsgren ، متواضع و غيرها الكثير... لكن لا تتوقع أن تكون الأفضل في DevOps بمجرد حصولك على الشهادة. يعتبر التعامل مع الزملاء أكثر أهمية.
6. لا يوجد خط أنابيب DevOps
"هل تم تنفيذ DevOps حتى الآن؟" "خط أنابيب DevOps يعمل." "خط أنابيب DevOps معطل". عندما أسمع هذه التصريحات ، أتفاجأ لأننا توصلنا إلى هذه المصطلحات. هل قمنا بإعادة صياغة العلامة التجارية لخط أنابيب النشر ، أم أن فرق DevOps في بعض الشركات تشارك في هذه البنية التحتية؟ أو ربما يكون ذلك بسبب اتصال المطورين فريق التشغيل إذا تم كسر خط الأنابيب؟
على الرغم من الأهمية الهائلة لتقنيات CI / CD ، إلا أنني متشكك بشأن استخدام مصطلح "خط أنابيب DevOps". إذا تعطل خط أنابيب التطوير ، فسيقع اللوم على فريق العمليات. لا يفكر المطورون في خط الأنابيب أثناء كتابة الاختبارات. المفهوم نفسه مضلل أيضًا. يتم إنشاء خطوط الأنابيب لكل خدمة أو تطبيق على حدة ، وليس عبر نطاق DevOps بأكمله. من خلال إنشاء خطوط أنابيب عامة ، فإننا نخاطر بتوسيع الفجوة بين الفرق ، وهذا ليس هدف DevOps على الإطلاق.
أوصي باستخدام تقنية رأيتها في مئات المؤسسات حول العالم: أشر إلى كل خط أنابيب فردي باعتباره خط أنابيب تطبيق X. ستجعل هذه المصطلحات من السهل معرفة التطبيق الذي يواجه مشكلات عند الاختبار أو النشر أو الترقية. سنعرف أيضًا الفريق الذي سيعمل على الإصلاحات في الملحق X (ربما بمساعدة أصدقاء من فريق العمليات).
7. ليس لدى DevOps أية معايير
أصعب من بين آلاف قصص DevOps هو التقييس. بالطريقة نفسها التي لا يمكننا بها اعتماد الأشخاص ، لا يوجد معيار عالمي في DevOps. لكل منظمة مسارها الخاص ، ويمكن أن تكون هذه المسارات مختلفة تمامًا. لا توجد وصفة سحرية تسرد الأدوات وتصف طرق إنشاء تدفقات الأتمتة التي ستصبح فجأة DevOps في مؤسستك.
يعني المعيار في DevOps أنك تطبق منهجية محددة تسمح لمؤسستك بالبدء في التعاون والابتعاد عن سياسات المكتب ، كما يجب أن تحسن جودة العمل وتزيد الروح المعنوية وتتيح لك تحقيق نتائج أفضل مع عدد أقل من الاضطرابات
يجب فهم DevOps على أنها مجموعة من الممارسات المشابهة للمنهجيةITIL . تذكر أن L في ITIL تعني المكتبة. ولا ينبغي اعتبار هذه المكتبة كدليل للعمل ، ولكن كقائمة بأفضل الممارسات التي تحتاج من خلالها إلى اختيار الأكثر ملاءمة لك. تم كره ITIL على وجه التحديد بسبب عمليات التنفيذ غير الناجحة ، حيث تم استخدام المكتبة على وجه التحديد كتعليمات خطوة بخطوة. سيؤدي التوحيد القياسي في DevOps إلى نفس النتائج.
8. لا يوجد شيء مثل DevSecOps
بدأنا DevOpsDays في عام 2009 وكان هذا المؤتمر مفتوحًا للجميع. بالطبع ، كان في البداية حدثًا للمطورين وموظفي الفرق التشغيلية ، ولكن جاء الجميع إلينا: مديرو قواعد البيانات ، والمختبرين ، ومحللي الأعمال ، والممولين ، وبالطبع المتخصصين في مجال الأمن. في عام 2012 ، تحدثنا في اجتماعات OWASP ، وتحدثنا عما قمنا به. مازحنا أن "S" في DevOps تعني الأمان ، تمامًا مثل "S" في HTTPS.
DevOps هو الأمان في جوهره. لقد وجدت أن مبادئ القرص المضغوط هي الأنسب لفرق الأمن. القرص المضغوط هو مطلب أمني: يجب أن تكون قادرًا على النشر في أي وقت ، وهذا سيمنحك القدرة على نشر وتنفيذ التحديثات التي تتطلبها مخاوف العمل أو الأمن.
من ناحية أخرى ، من المحزن أن نتوصل إلى كلمات تشمل الأشخاص المسؤولين عن الأمن. من ناحية أخرى ، من الجيد أننا ناقشنا هذا مرة أخرى. في الأساس ، لا يوجد فرق بين DevSecOps و DevOps. لطالما كانت السلامة جزءًا من التطوير والعمليات. يمكنني استخدام مصطلح DevSecOps لهذا ، ولكن من الأفضل استخدام مصطلح DevOps فقط.
9. لا يمكنك الانتقال إلى DevOps
هل سبق لك أن قابلت شركة تدلي ببيان مثل "نحن نقوم بمشروع DevOps في الربع الأخير من هذا العام ، وفي العام المقبل سننتقل إلى DevOps تمامًا" ، والتي نجحت حقًا؟ لذلك أنا لم أقابل.
لا يتوقف تقديم البرامج أبدًا ، وتتغير التكنولوجيا دائمًا ، وتحتاج دائمًا إلى الدعم ، و (من الناحية المثالية) يجب أن يظل النهج والموقف تجاه DevOps كما هو. بمجرد تحسين نهج التسليم الخاص بك ، سوف تحتاج إلى مزيد من التحسين. ليس بسبب تنفيذ جميع وظائف تطبيقك أو لأن النظام البيئي الذي يعيش فيه توقف عن التطور. سترغب في مواصلة التطوير لأن جودة عملك تنمو بشكل كبير ، وفي نفس الوقت تزداد جودة الحياة. ستستمر DevOps في التطور حتى بعد حصول بعض المهام على حالة "مكتمل".
10. هناك شيء مثل Dev-oops
لسوء الحظ ، لا يفهم الكثير من الناس أهمية التعاون. إنهم يبنون جدرانًا بين الفرق ، ويعتقدون أن الأدوات أكثر أهمية من الممارسات ، وتتطلب شهادة لكل شيء وكل شخص. يعتقدون أيضًا أن جميع العبارات التسعة السابقة غير صحيحة. وسيكافح هؤلاء الأشخاص إلى الأبد للنجاح فيما أسميه Dev-Oops.
يدور DevOps حول أدوات التفكير ويعتبر الفصل بين الفريق أكثر أهمية من مبادئ DevOps الحقيقية التي يمكن أن تحسن عملك. دعونا نسعى جاهدين للقيام DevOps ، وليس DevOops.
الهدف الرئيسي
لقد قمنا بتشغيل DevOpsDays لمدة 10 سنوات ، وخلال هذا الوقت تعلم الآلاف من الأشخاص الكثير من الأشياء المثيرة للاهتمام من بعضهم البعض في بيئة سهلة ومفتوحة. بعض المفاهيم التي أجدها تتعارض مع أهداف DevOps و agile شائعة. ركز على الحصول على خدماتك لمساعدة شركتك ولا تتوقف عن التعلم. ولا يتعلق الأمر بنسخ الأدوات وتطبيقها في مؤسستك. يتعلق الأمر بالتركيز على التحسين المستمر بكل الطرق.
تعرف على المزيد حول كيفية الحصول على مهنة رفيعة المستوى من الصفر أو Level Up في المهارات والراتب من خلال أخذ دورات SkillFactory المدفوعة عبر الإنترنت:
- دورة DevOps (12 شهرًا)
المزيد من الدورات
- - (8 )
- UX- (9 )
- Web- (7 )
- Machine Learning (12 )
- Data Science (12 )
- (9 )
- «Python -» (9 )