Get best of the week

المهنة DevOps-engineer: وجهة نظر مسؤول النظام



أعمل كمهندس DevOps في Parallels. أنا أدعم تطوير الخدمات المختلفة ، وأكتب نصوصًا لنشرها تلقائيًا ، وأتواصل بشكل وثيق مع فريق التطوير. سأخبرك كيف يتم ترتيب العمل ، والمبلغ الذي يدفعونه ، وما هو نهج DevOps لتطوير البرامج.

بدأ كل شيء مع حقيقة أنه أصبح مملاً بالنسبة لي للعمل كمسؤول نظام ، أردت شيئًا جديدًا. حاولت تطوير 1C ، لكنني أدركت بسرعة أن هذا لم يكن ملكي. لقد تعلم Python ، وحسّن مهاراته في أنظمة Unix ، وذهب لإجراء مقابلة في Parallels. ثم لم أكن أعرف شيئًا عن DevOps ، لقد جئت للتو وقلت: أريد أن أعمل لك. بعد شهرين أخذوني.

ما هو DevOps؟


إذا سألت 5 أشخاص عن DevOps ، فستحصل على 5 إجابات مختلفة. بالنسبة إلى الإنجيليين ، هذه ثقافة ، أو بالأحرى تحول في التفكير. للمهندسين ، مجموعة من الحلول والأدوات. للمديرين ، منهجية. للمجندين - مهنة. وبالنسبة إلى أي شخص آخر ، فمن المحتمل أنها مجرد كلمة طنانة.

الحقيقة ، كالعادة ، في مكان ما بينهما. DevOps هو كل ما سبق ، معًا. وتتمثل مهمتها الرئيسية في تسريع تسليم المنتج من الأعمال التجارية إلى المستهلك. المصطلح نفسه صاغه مستشار تكنولوجيا المعلومات المستقل باتريك ديبوا منذ حوالي اثني عشر عامًا. لقد أراد تحطيم الجدار الاستعاري بين المطورين (dev) و sysadmins (ops) ، ودمجهم في وحدة واحدة فعالة ، والتي يمكن أن تنشئ برنامجًا أسرع ، وتطرح الإصدارات بشكل أكثر تكرارًا وبأخطاء أقل.

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



دقيقة من الاحصائيات مملة. وفقًا لبحث DORA (بحث وتقييم DevOps) ، فإن الفرق متعددة الوظائف التي تستخدم نهج DevOps:

  • 208 مرات نشر التعليمات البرمجية في كثير من الأحيان ؛
  • 106 مرات تقليل الوقت من الالتزام إلى النشر ؛
  • 2.604 مرة استعادة أنظمة أسرع بعد الفشل.
  • 7 مرات أقل من فرصة الفشل نفسه نتيجة للتغييرات.

بالطبع ، لا يؤدي الجمع بين dev و ops وحده إلى مثل هذه الكفاءة. يتضمن نهج DevOps استخدام العديد من أدوات التطوير والاختبار والنشر الجديدة لتنظيم CI \ CD (مفهوم التكامل المستمر والتسليم). من أشهرها:

  • Git و GitHub - أنظمة إدارة شفرة المصدر ؛
  • Jenkins - خادم أتمتة لإنشاء خطوط أنابيب CI / CD ؛
  • Docker - برنامج لأتمتة النشر وإدارة التطبيقات في البيئات مع دعم للحاويات ؛
  • Kubernetes - نظام تنسيق الحاويات المفتوحة ؛
  • الشيف والدمى والأنيبل - أدوات للتكوين والنشر التلقائي ؛
  • السيلينيوم - حل أتمتة الاختبار ؛
  • بروميثيوس وناجيوس - برنامج مراقبة الخادم ؛
  • Grafana هو حل لجمع وتحليل المقاييس.

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

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

جوهر مهندس DevOps


على المستوى الأساسي ، يعد مهندس DevOps متخصصًا تقنيًا يفهم جميع المراحل الرئيسية لدورة حياة تطوير البرامج ، ويصحح الاختناقات في العمليات ، ويعدل البيئة:

  • يكتب رمزًا لنشر التطبيق تلقائيًا
  • مسؤول جزئيًا عن توفرها ، ليس شخصيًا كمسؤول نظام ، ولكن مع فريقه ؛
  • يتحمل واجبا على بنيته التحتية (يفهم الأخطاء ، أحيانا مع مبرمج).

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

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

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

هذه أيضا وظيفتي.


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

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

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

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

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

كم يكسب مهندسو DevOps؟


يعتمد راتب مهندس DevOps على المهارات ومكان العمل ومنطقة الإقامة. راتب أخصائي يعمل في موسكو هو الأعلى في روسيا ، 130-350 ألف روبل في الشهر. تقدم شركات سان بطرسبرج 100-300 ألف روبل في هذا الموقف. في مناطق أخرى من بلادنا ، هم على استعداد لدفع 70-120 ألف روبل.

يتراوح متوسط ​​الدخل السنوي في الولايات ، كما يقول بعض الموارد البشرية ، من 100 إلى 125 ألف دولار أمريكي ، وفقًا للبيانات الصادرة عن Puppet. في أستراليا ونيوزيلندا - 75-100 ألف دولار أمريكي. في أوروبا - 50-75 ألف دولار أمريكي. في آسيا ، لا يتلقى مهندسو DevOps أكثر من 25 ألف دولار أمريكي سنويًا.

More articles:


All Articles