Get best of the week

من هو DevOps ومتى لا تكون هناك حاجة إليه



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

يشير البعض إلى DevOps في سيرتهم الذاتية ، على الرغم من أنهم لا يعرفون دائمًا ويفهمون جوهر المصطلح. يعتقد شخص ما أنه بعد دراسة Ansible و GitLab و Jenkins و Terraform وما شابه ذلك (يمكن أن تستمر القائمة حسب رغبتك) ، ستصبح على الفور "تطوراً". هذا ، بالطبع ، ليس كذلك.

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

من هو DevOps


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

DevOps ليس متخصصًا يمكنك توظيفه ، وليس مجموعة من المرافق ، وليس قسم تطوير به مهندسون.

DevOps هي فلسفة ومنهجية.

بمعنى آخر ، هذه مجموعة من الممارسات التي تساعد المطورين على التفاعل بنشاط مع مسؤولي النظام. أي ، لربط ودمج عمليات العمل في بعضها البعض.

مع ظهور DevOps ، ظل هيكل وأدوار المتخصصين كما هو (هناك مطورون ، وهناك مهندسون) ، لكن قواعد التفاعل تغيرت. طمس الحدود بين الأقسام.

يمكن وصف أهداف DevOps بثلاث طرق:

  • يجب تحديث البرنامج بانتظام.
  • يجب أن يتم البرنامج بسرعة.
  • يجب نشر البرنامج بشكل ملائم وفي وقت قصير.

ليس لدى DevOps أداة واحدة. لا يعني تكوين العديد من المنتجات وتسليمها واستكشافها ظهور DevOps في الشركة. هناك الكثير من الأدوات والجميع متورطون في مراحل مختلفة ، لكنهم يخدمون هدفًا مشتركًا واحدًا.


وهذا جزء فقط من أدوات DevOps.

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

من تجربة المقابلة ، أرى الصورة التالية: المتخصصون الذين يعتبرون DevOps وظيفة عادة ما يكون لديهم سوء فهم مع الزملاء .

كان هناك مثال حي. جاء شاب إلى المقابلة مع مجموعة من الكلمات الذكية في السيرة الذاتية. في أماكن العمل الثلاثة الأخيرة ، كان لديه خبرة 5-6 أشهر. غادر شركتين ناشئتين لأنهما "لم يخلعا". وبالنسبة للشركة الثالثة ، قال إنه لا أحد يفهمها: يقوم المطورون بكتابة الرمز على Windows ، والمدير يجبر هذا الرمز على "الالتفاف" في Docker عادية ومدمجة في خط أنابيب CI / CD. أخبر الرجل الكثير من الأشياء السلبية عن وظيفته الحالية وزملائه - أردت أن أجيب: "لذا لن تبيع الفيل".

ثم سألته سؤالاً ، وهو أحد الأسئلة الأولى في قائمتي لكل مرشح.

- ماذا تعني DevOps لك شخصيًا؟
- بشكل عام أو كيف أتصور ذلك؟

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

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

المنهجية والفلسفة DevOps


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

منهجية DevOps هي مجرد وسيلة لتحقيق أهدافك.

الآن حول ما هي فلسفة DevOps. وربما هذا هو السؤال الأكثر صعوبة.

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

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

حاولت إضفاء الطابع الرسمي على بعض "مسلمات" هذه الفلسفة. اتضح ما يلي:

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

أعتقد أن "افتراضاتي" هي موضوع منفصل للمناقشة. ولكن الآن هناك شيء للبناء عليه.

ماذا يفعل DevOps


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

لا يمكنني التحدث عن سوق العمل الغربي بشكل مؤكد 100٪. لكني أعرف الكثير عن سوق DevOps في روسيا. بالإضافة إلى مئات المقابلات ، شاركت على مدار العام ونصف العام الماضي في مئات من العروض التقنية المسبقة لخدمة "تنفيذ DevOps" للشركات والمصارف الروسية الكبيرة.

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



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

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

أيضا ، يحتاج مهندس DevOps إلى استخدام مورد إداري من وقت لآخر. على سبيل المثال ، للتغلب على "مقاومة البيئة" - عندما يكون الفريق غير جاهز لقبول أدوات ومنهجية DevOps.

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

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

عندما لا تكون هناك حاجة إلى DevOps


هناك حالات عندما لا تكون هناك حاجة إلى DevOps. هذه حقيقة - يجب فهمها وقبولها.

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

مطلوب DevOps عندما يعتمد رضا العميل ورغبته في العودة إليك مرة أخرى على توفر خدمات المعلومات هذه للتفاعل مع العميل ونوعيته واستهدافه.

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

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


انظر الآن إلى عملك وفكر في ذلك: إلى أي مدى تعتمد شركتك وأرباحها على منتجات تكنولوجيا المعلومات التي توفر التفاعل مع العميل؟

إذا كانت شركتك تبيع الأسماك في متجر صغير وكان منتج تكنولوجيا المعلومات الوحيد هو تكوينان 1C: Enterprise (المحاسبة و UNF) ، فمن الصعب التحدث عن DevOps.

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

إن حجم وحجم العائد المالي السنوي ليس المعيار الرئيسي لتحديد ما إذا كانت شركتك بحاجة إلى DevOps.

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

زبائنهم قائمة محدودة من تجار السيارات. ويتم إرفاق أخصائي من الشركة المصنعة لكل منهما. يحدث كل سير العمل الداخلي من خلال SAP ERP. إن الموظفين الداخليين هم في الواقع عملاء لنظام المعلومات. لكن إدارة هذا IP تتم عن طريق الوسائل الكلاسيكية لإدارة أنظمة الكتلة. مما يستبعد إمكانية استخدام ممارسات DevOps.

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

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

المعيار الرئيسي لفهم ما إذا كانت هناك حاجة إلى DevOps: مدى أهمية منتجات تكنولوجيا المعلومات للشركة والعملاء.

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

أي ألعاب موجودة بفضل التمويل: مباشر أو غير مباشر من اللاعبين. في Playgendary ، نقوم بتطوير ألعاب مجانية للهواتف المحمولة يشارك فيها أكثر من 200 شخص بشكل مباشر. كيف نستخدم DevOps؟

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

الآن نحن نستخدم بنشاط Jenkins كأداة لأنابيب CI / CD لتشغيل جميع خطوط أنابيب التجميع مع Unity ثم نشرها في App Store و Play Market. المزيد من صندوق الأدوات الكلاسيكي:

  • Asana - لإدارة المشاريع. التكامل المكوّن مع Jenkins.
  • Google Meet - لمكالمات الفيديو.
  • سلاك - للاتصالات والتنبيهات المختلفة ، بما في ذلك الإخطارات من جنكينز.
  • التلاقي الأطلسي - للتوثيق والعمل الجماعي.

في المستقبل القريب ، سنقدم تحليل رمز ثابت باستخدام SonarQube وإجراء اختبار واجهة المستخدم الآلي باستخدام أدوات السيلينيوم في مرحلة التكامل المستمر.

بدلا من الاستنتاج


أريد أن أختتم بالفكر التالي: لكي أصبح مهندس DevOps ذو مؤهلات عالية ، من الضروري تعلم كيفية التواصل مع الناس بحيوية.

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

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

More articles:


All Articles