ما هو Devops؟ | الدليل الكامل لمعرفة الـ DevOps (مع الأمثلة)
ما الذي تشترك فيه شركات مثل Amazon و Target و Esty و Netflix و Google و Walmart؟ بصرف النظر عن حقيقة أنهم شركات ناجحة إلى حد كبير ، فإنهم جميعًا يستخدمون طريقة تُعرف باسم DevOps في عملياتهم اليومية لزيادة الكفاءة وتحسين وقت التسليم. في دليل DevOps هذا ، سنحاول شرح ما هو DevOps وكيف يمكن أن يكون نعمة لعملك.
ما هو DevOps ولماذا يتم استخدامه على نطاق واسع؟
إذن ما هو DevOps بالضبط؟ لنأخذ مثالًا افتراضيًا صغيرًا للتوضيح. لنفترض أن هناك شركة ناشئة صغيرة تبني روبوتات تنظيف مدعومة بالذكاء الاصطناعي. هناك 3 مطورين (لنكن كسالى ونسميهم فقط الفريق D) الذين يكتبون وينفذون الكود لإنشاء الروبوتات وشخصين للعمليات (فريق O بالطبع) الذين يحافظون على البنية التحتية للروبوت في بيئة العالم الحقيقي ويقدمون الدعم لـ مستخدمي الروبوت.
لقد أمضى الفريق D للتو 8 أشهر في إنشاء أحدث روبوت. يمكنه التعرف على الأشخاص ، وأخذ الأوامر من أجهزة Alexa وبالطبع نظيف مثل الرئيس. قضى فريق D وقتًا في إنشاء هذا الروبوت في بيئة التطوير الخاضعة للرقابة ويبدو أن كل شيء يعمل بسلاسة. لا يمكن أن يكونوا أكثر فخرا.
يسلمون إبداعاتهم إلى Team O الذي يأخذها على الفور إلى العالم الحقيقي. هذا عندما تبدأ المشاكل. اتضح أن روبوت التنظيف المثالي ليس مثاليًا على الإطلاق. إنه لا يتعرف على الجميع ، حيث تتعطل القدرة على اتباع أوامر Alexa عندما يتم تقديمها من قبل أشخاص مختلفين ولا يمكن الوصول إلى الرفوف الصعبة وفراغها.
الفريق O غاضب ومحبط. لقد كانوا ينتظرون هذا الروبوت لفترة طويلة ولا يمكنهم تصديق أنها كارثة لا يمكن تخفيفها. من ناحية أخرى ، فإن الفريق D الآن في موقف دفاعي. إنهم يعتقدون أن كل شيء كان يعمل بشكل مثالي أثناء ظروف الاختبار الخاضعة للرقابة وأن الفوضى الملكية الآن يجب أن تكون بسبب سوء تنفيذ Team O.
في الختام ، هناك منتج دون المستوى الأمثل في السوق ، يبدو أن التصحيحات والتحسينات ستستغرق الآن تقريبًا نفس المدة التي استغرقها طرح المنتج ، ويكره فريقان كفؤان للغاية الآن بعضهما البعض ويكرهان وظائفهما.
هذا ، باختصار ، هو سبب إنشاء DevOps والسبب في أن أكثر من 70٪ من الشركات الصغيرة والمتوسطة (SMBs) (الشركات الصغيرة والمتوسطة) اعتمدت خدمات DevOps في شركاتهم في عام 2016. كان من الممكن تجنب الكثير من وجع القلب والإحباط وعدم الكفاءة لو كان فريق D وعملت Team O مع بعضهما البعض من الفكرة والتنفيذ إلى التسليم والدعم. بدلاً من ذلك ، عملوا في صوامع مع جدار وهمي بينهم.
لم يكن لفريق O أي دور عندما كان يتم كتابة الكود وكان الروبوت قيد الإنشاء بالفعل بينما كان الفريق D خارج الصورة تمامًا عندما خرج الروبوت إلى العالم الحقيقي وقام بتنظيف العديد من المنازل المختلفة. وكانت النتيجة روبوتًا لم يكن جاهزًا للسوق وفريق تطوير لا يزال لا يعرف تمامًا كيفية حل الأمور.
كما يمكنك أن تتخيل ، سيمر الكثير من الوقت قبل أن يصبح الروبوت جاهزًا للسوق أخيرًا. سيكون هناك عدد من التكرارات حيث يقوم الفريق D ببعض التغييرات ويقوم الفريق O بإرسال الروبوت إلى العالم الحقيقي. وليس فقط أثناء تطوير المنتج ، ستستمر هذه المشكلة نفسها عندما يحتاج الروبوت إلى صيانة وترقيات. نتيجة لذلك ، حتى الشركات الناشئة الصغيرة ينتهي بها الأمر إلى أن تصبح غير فعالة وبطيئة وهناك فرصة جيدة لخسارتها أمام الشركات الأخرى التي تحصل على منتجات فائقة الجودة في السوق بشكل أسرع.
كانت هذه هي المشكلة التي بدأت الشركات في رؤيتها خاصة وأن التكنولوجيا أصبحت أكثر تقدمًا. أدى عزل فرق عملياتهم وتطويرهم عن بعضهم البعض إلى إبطاء التسليم ومنتجات وخدمات أقل كفاءة. علاوة على ذلك ، لم تتم أتمتة العديد من العمليات في عمليات الشركة التي كان من السهل أتمتتها لزيادة الكفاءة لأن المطورين لم يكونوا على دراية بها.
وذلك عندما ظهر مفهوم DevOps وبدأ اعتماده على نطاق واسع. DevOps ليست سوى مجموعة من الفلسفات والممارسات والأدوات التي تساعد المؤسسة على تقديم منتجات أفضل بشكل أسرع من خلال تسهيل تكامل وظائف التطوير والعمليات. وهذا يمكّن الشركات مثل تلك الموجودة في مثالنا من خدمة عملائها وأسواقها بطريقة أفضل وتتمتع بميزة تنافسية.
يبدأ هذا من التصميم إلى عملية التطوير بأكملها وصولاً إلى دعم الإنتاج.
كيف تطورت DevOps؟
DevOps الآن في عامها العاشر. لقد مرت DevOps ، مثل معظم الفلسفات والأدوات التي لها تطبيقات عملية ، برحلة من مجرد مجموعة من الأفكار والمبادئ التي تم تجميعها معًا في نظام متكامل مع عملياته وأدواته الخاصة.
في عام 2007 ، كان مدير مشروع يدعى باتريك ديبوا يعمل مع الحكومة البلجيكية للمساعدة في عمليات ترحيل مراكز البيانات. لقد وجد العملية برمتها محبطة للغاية بسبب الجدار الفاصل بين المطورين وفريق العمليات مما جعل وظيفته أصعب بكثير والتسليم أبطأ بكثير.
كان Debois من أشد المؤمنين بالمنهجية الرشيقة التي تعزز التكرار المستمر للتطوير والاختبار طوال دورة حياة التطوير مما يساعد فرق التطوير على شحن منتجات أفضل بشكل أسرع. وأعرب عن اعتقاده أنه يجب تطبيق مبادئ مماثلة على فرق التطوير والعمليات التي تعمل معًا بشكل متزامن.
في عام 2008 ، اجتمع أندرو شافر (الذي عُرف لاحقًا باسم مبشر DevOps) وديبوا في مؤتمر لمناقشة الأفكار والمبادئ الأولية حول ما أطلقوا عليه فيما بعد "إدارة الأنظمة الرشيقة". لقد شكلوا أيضًا مجموعة إدارة رشيقة على google حيث تكمن البدايات الحقيقية لـ DevOps.
حدث تاريخي آخر في تاريخ تطور DevOps كان العرض التقديمي الشهير الآن من قبل موظفي Flickr John Allspaw (نائب الرئيس للعمليات الفنية آنذاك) وبول هاموند (مدير الهندسة آنذاك) في مؤتمر O'Reilly Velocity في عام 2009. مع مرح حتى الآن لقد أعاد هاموند وألسباو ، الذي لعب الأدوار القوي ، حقيقة أن هناك خسارة كبيرة في الأعمال بسبب الجدار الفاصل بين التطوير والعمليات وكان السبيل الوحيد للخروج هو التكامل السلس بين الاثنين.
أصبح هذا العرض التقديمي يُعرف باسم "اللحظة الحاسمة" لـ DevOps حيث سرعان ما استيقظ عالم التكنولوجيا على الحاجة إلى مثل هذا التكامل. ألهم العرض التقديمي Debois لتنظيم مؤتمر DevOps يسمى Devopsdays في بلجيكا ، والباقي ، كما يقولون ، هو تاريخ.
لحظة مهمة أخرى في تطور DevOps كانت أول مؤتمر DevOps في الولايات المتحدة. أقيم عام 2010 في ماونتن فيو ، كاليفورنيا ، مكة للتكنولوجيا. كانت هذه هي الإشارة الحاسمة إلى أن DevOps قد وصلت وكانت موجودة لتبقى. في الواقع ، في عام 2018 ، كان هناك أكثر من 30 مؤتمر DevOps في جميع أنحاء العالم.
كيف تستفيد الشركات والمؤسسات من استخدام DevOps ؟
السبب الذي جعل DevOps ترى مثل هذا التبني السريع هو أنه يحدث فرقًا كبيرًا حقًا في كيفية عمل شركة تقنية على مستوى أساسي للغاية. دعنا نلقي نظرة على بعض الفوائد التي تتحقق عندما تتبنى الشركة نهج DevOps.
الابتكارات المتسارعة
هذا هو السبب الرئيسي وراء ظهور DevOps. يتيح استخدام DevOps للشركات تطوير المنتجات ونشرها بشكل أسرع. كما رأينا في مثالنا السابق ، تصبح أوقات الدورات أطول بشكل ملحوظ عندما يكون هناك جدار بين التطوير والعمليات. عندما يتم دمج الاثنين ، من ناحية أخرى ، تكون التغييرات أصغر وتكون المشكلات التي يتعين حلها في كل مرة أقل تعقيدًا. علاوة على ذلك ، يمكن لأعضاء الفريق إجراء تغييرات على البرامج بسهولة نظرًا لأنهم يحتاجون فقط إلى إلقاء نظرة على أحدث رمز تمت إضافته وليس على الإطلاق. تسمح أشياء مثل الخدمات المصغرة والتسليم المستمر للفرق بالحصول على ملكية كاملة للمشاريع وتسليمها بشكل أسرع.
التعاون
كما أوضح مثالنا ، غالبًا ما يؤدي الجدار الفاصل بين التطوير والعمليات إلى بيئة لا يثق فيها الفريقان ببعضهما البعض ويتجول كل منهما بشكل أعمى قليلاً. هذا له تداعيات طويلة المدى على الروح المعنوية للفريق ومدى تحفيزهم للعمل نحو أهدافهم. ينتج عن نهج DevOps تعاون بين الفريقين حيث يعملان بشغف مشترك لتحقيق الأهداف المشتركة. هذا يخلق بيئة عمل أكثر إيجابية حيث يمكن الوصول إلى النتائج بشكل أسرع وأكثر كفاءة. هذا أيضًا له نتائج إيجابية أخرى مثل الرضا الوظيفي المعزز وانخفاض التناقص الوظيفي.
المصداقية
قبل DevOps ، كان تحديث أحد التطبيقات لتلبية احتياجات المستخدم المتغيرة بمثابة كابوس. كان هناك دائمًا احتمال أن يؤدي تحديث التطبيق إلى المساس بالجودة المطلوبة من قبل المستخدم.
باستخدام أدوات DevOps مثل التكامل والتسليم المستمر ، أصبح من السهل الآن اختبار وظائف البرنامج مع مراعاة الأمان والجودة. تساعد العمليات الأخرى مثل المراقبة والتسجيل في تتبع مقاييس الأداء في الوقت الفعلي التي تساعد في الحفاظ على موثوقية البرنامج.
الأمان
بدون DevOps ، يتعين عليك غالبًا إجراء مفاضلة بين السرعة والأمان مما يؤدي إلى زيادة وقت التسليم كثيرًا. مع DevOps ، يمكنك استخدام سياسات الامتثال المؤتمتة وعناصر التحكم الدقيقة وأساليب إدارة التكوين للحفاظ على السرعة دون المساومة على الأمان.
قابلية التوسع
بدأت DevOps في النمو حيث بدأت شركات مثل Google و Amazon و Youtube تجد صعوبة أكبر في إدارة تقنيتها على نطاق واسع بجدار يفصل بين التطوير والعمليات. تتيح لك الأتمتة والاتساق اللذين يأتيان مع DevOps إدارة الأنظمة المعقدة وتغييرها بشكل أكثر كفاءة.
ما هي الأمثلة لأفضل الممارسات لعمليات DevOps الفعالة؟
بينما لا تزال DevOps تعني أشياء مختلفة لأشخاص مختلفين ، فقد ظهرت مجموعة من أفضل الممارسات التي يجب أن تدمجها الشركات التي تبحث في اعتماد DevOps.
- المشاركة والتفاعل النشط
هذا هو المبدأ التوجيهي الأساسي لـ DevOps. يمكن أن تنجح DevOps فقط إذا كان كل من المطورين وموظفي العمليات والدعم ملتزمون حقًا بالتعاون واستخدام نهج متكامل لتحقيق الأهداف.
- الاختبار الآلي
يعد اختبار الانحدار الآلي شيئًا تتبناه فرق أجايل كثيرًا لأنه يساعد في إصلاح المشكلات على الفور وشحن رمز عالي الجودة. يعمل هذا بشكل جيد في DevOps أيضًا لأن الحاجة الماسة لموظفي العمليات تتمثل في أن الكود المشحون يجب أن يفي بمعايير جودة معينة.
- إدارة التكوين المتكاملة
في بيئة DevOps ، لا تنطبق إدارة التكوين فقط على الحل الحالي الذي يتم العمل عليه ولكن أيضًا على مشكلات التكوين بين الحل وبقية البنية التحتية للمؤسسة. تساعد إدارة التكوين المتكاملة فرق العمليات على رؤية التأثير المحتمل للإصدار الجديد بشكل أكثر وضوحًا مما يساعد في اتخاذ قرارات أفضل فيما يتعلق بموعد إصدار الإصدار.
- إدارة التغيير المتكاملة
من خلال إدارة التغيير المتكاملة ، تعمل فرق العمليات والتطوير معًا لفهم كيفية تأثير استخدام التقنيات المختلفة على المؤسسة ككل ، ثم العمل على إدارة ذلك.
- التكامل المستمر
مع التكامل المستمر ، يتم اختبار الكود وتحليله كلما تم التحقق من الكود المحدث في نظام التحكم في الإصدار. يوفر هذا ملاحظات فورية حول عيوب التعليمات البرمجية مما يسمح للمطورين ببناء حل عالي الجودة مع القليل من المخاطر.
- تخطيط النشر المتكامل
يعني نهج DevOps أن مهندسي العمليات سيشاركون عن كثب مع المطورين عندما يتعلق الأمر بالتخطيط لنشر المنتجات وفقًا لجدول النشر التنظيمي.
- الانتشار المستمر
مع النشر المستمر ، عندما يكون التكامل ناجحًا في وضع حماية واحد ، يتم ترقيته تلقائيًا إلى وضع الحماية التالي ويبدأ التكامل هناك. يستمر هذا حتى يصل إلى النقطة التي يتطلب فيها التحقق البشري. يحدث هذا عادة عند نقطة الانتقال من التطوير إلى العمليات.
- دعم الإنتاج
مع DevOps ، لا يعمل المطورون على الإصدارات الجديدة فحسب ، بل يعملون أيضًا على معالجة المشكلات الحرجة بحل قيد الإنتاج بالفعل. على الرغم من كونهم الفريق الثالث والأخير الذي يشارك في حل مشكلات الإنتاج ، إلا أنه أمر شائع إلى حد ما ويعطيهم أفكارًا حول مشكلات الإنتاج التي تساعدهم في تصميم حلول أفضل في المقام الأول.
- مراقبة التطبيق
يشير هذا إلى ممارسة المراقبة وحلول التسجيل في الوقت الفعلي بمجرد أن تكون قيد الإنتاج. يمنحنا هذا مقاييس أداء تعمل على تحسين موثوقية الحل وتمنع الفشل.
- لوحات المعلومات الآلية
يتيح لنا DevOps إنشاء لوحات معلومات آلية للعديد من المقاييس الرئيسية. لا يمكن أتمتة جميع المقاييس بالطبع ، ولكن يمكن رؤية العديد من المقاييس الرئيسية في الوقت الفعلي باستخدام لوحات المعلومات الآلية وتوفر ذكاء أعمال مهمًا.
ما هي أدوات DevOps؟
من أجل تنفيذ أفضل ممارسات DevOps الموضحة أعلاه ، تم تطوير أدوات معينة لأتمتة عمليات DevOps المختلفة وتسهيلها. ينما تلعب الأدوات المناسبة دورًا رئيسيًا في تنفيذ DevOps الفعال ، فإن مجرد استخدام الأدوات لا يعني اعتماد DevOps. تكون الأدوات ذات صلة فقط عند استخدامها كمرحلة أخيرة - بعد أن تتبنى المنظمة بالفعل فلسفة DevOps ويكون هناك التزام بتنفيذ أفضل ممارساتها.
على الرغم من أنه لم يكن من المفترض أن تدور DevOps حول الأدوات ، إلا أنه مع تطورها في السنوات القليلة الماضية ، أصبح عدد من التقنيات التي لم تكن جزءًا من المفهوم الأصلي جزءًا لا يتجزأ من DevOps. وفقًا لشركة الأبحاث Gartner ، أصبحت سلسلة الأدوات المرتبطة بالتقنيات مهمة الآن إذا أرادت DevOps إحداث التغيير المقصود منه. في السنوات الأخيرة ، حدث انفجار في أدوات DevOps لممارسات DevOps المختلفة. هنا ليست سوى أمثلة قليلة.
أدوات التحرير
- Jenkins
- Travis
- TeamCity
- Bamboo
- Puppet
- Chef
- Ansible
- Cfengine
- Saltstack
- Zookeeper
- Noah
- Mesos
- AWS
- OpenStack
- Vagrant
- Docker
- New Relic
- Sensu
- Spunk
- Nagios
- Jira
- Git
- Eclipse
أدوات الإختبارات
- JUnit
- Zephyr
- Selenium
- Vagrant
- SoapUI
مفتاح الاعتماد الفعال لـ DevOps
يعد اعتماد DevOps على مستوى المؤسسة منحدرًا زلقًا لأنه يتطلب تغييرًا فلسفيًا وثقافيًا مقترنًا بتطبيق عملي أكثر للأدوات وأفضل الممارسات. إذا كانت إحدى المؤسسات تطمح ببساطة إلى فلسفة التعاون والكفاءة وراء DevOps دون القيام بالعمل الشاق المتمثل في تنفيذها فعليًا على أرض الواقع ، فستظل DevOps فلسفة لا أكثر.
في الوقت نفسه ، فإن مجرد تبني ممارسات وأدوات DevOps دون تغلغل الفلسفة وثقافة DevOps عبر المؤسسة أمر غير مجدٍ أيضًا. يجب أن تكون نقطة البداية للاعتماد الناجح لـ DevOps داخل مؤسستك هي جعل فرق التطوير والعمليات لديك ملتزمة تمامًا بالقضية. يجب أن تظهر أفضل الممارسات وأدوات DevOps في الصورة فقط بعد أن يتم دمجهم بالكامل.
المقال الأصلي:
What is Devops? | The complete guide to DevOps (With Examples)
مقالات أخرى قد تهمّك :